redonkable
/
alistair23-linux
1
0
Fork 0
Code Releases Activity

Merge branches 'for-5.1/upstream-fixes', 'for-5.2/core', 'for-5.2/ish', 'for-5.2/logitech', 'for-5.2/macally', 'for-5.2/picolcd', 'for-5.2/sensor' and 'for-5.2/u2fzero' into for-linus

hifive-unleashed-5.2
Jiri Kosina 2019-05-06 15:45:18 +02:00
parent 39b3c3a5fb 4ceabaf790 2eb3c3e6ea 640d4ea83c 161f62cd07 70cd8121ca 77f9f77218 59579a8d17
commit 63b6f0b827
4141 changed files with 138612 additions and 78628 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.clang-format
View File

@ -240,6 +240,7 @@ ForEachMacros:
- 'for_each_set_bit'
- 'for_each_set_bit_from'
- 'for_each_sg'
- 'for_each_sg_dma_page'
- 'for_each_sg_page'
- 'for_each_sibling_event'
- '__for_each_thread'
@ -289,7 +290,6 @@ ForEachMacros:
- 'idr_for_each_entry_ul'
- 'inet_bind_bucket_for_each'
- 'inet_lhash2_for_each_icsk_rcu'
- 'iov_for_each'
- 'key_for_each'
- 'key_for_each_safe'
- 'klp_for_each_func'
@ -360,6 +360,7 @@ ForEachMacros:
- 'radix_tree_for_each_slot'
- 'radix_tree_for_each_tagged'
- 'rbtree_postorder_for_each_entry_safe'
- 'rdma_for_each_port'
- 'resource_list_for_each_entry'
- 'resource_list_for_each_entry_safe'
- 'rhl_for_each_entry_rcu'

4
.mailmap
View File

@ -156,6 +156,8 @@ Morten Welinder <welinder@darter.rentec.com>
Morten Welinder <welinder@troll.com>
Mythri P K <mythripk@ti.com>
Nguyen Anh Quynh <aquynh@gmail.com>
Nicolas Pitre <nico@fluxnic.net> <nicolas.pitre@linaro.org>
Nicolas Pitre <nico@fluxnic.net> <nico@linaro.org>
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Patrick Mochel <mochel@digitalimplant.org>
Paul Burton <paul.burton@mips.com> <paul.burton@imgtec.com>
@ -224,3 +226,5 @@ Yakir Yang <kuankuan.y@gmail.com> <ykk@rock-chips.com>
Yusuke Goda <goda.yusuke@renesas.com>
Gustavo Padovan <gustavo@las.ic.unicamp.br>
Gustavo Padovan <padovan@profusion.mobi>
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>

22
Documentation/ABI/obsolete/sysfs-class-dax 100644
View File

@ -0,0 +1,22 @@
What: /sys/class/dax/
Date: May, 2016
KernelVersion: v4.7
Contact: linux-nvdimm@lists.01.org
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
system. Device DAX is strict, precise and predictable.
Specifically this interface:
1/ Guarantees fault granularity with respect to a given
page size (pte, pmd, or pud) set at configuration time.
2/ Enforces deterministic behavior by being strict about
what fault scenarios are supported.
The /sys/class/dax/ interface enumerates all the
device-dax instances in the system. The ABI is
deprecated and will be removed after 2020. It is
replaced with the DAX bus interface /sys/bus/dax/ where
device-dax instances can be found under
/sys/bus/dax/devices/

14
Documentation/ABI/stable/sysfs-driver-mlxreg-io
View File

@ -21,7 +21,19 @@ Description: These files show with which CPLD versions have been burned
The files are read only.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/
cpld3_version
fan_dir
Date: December 2018
KernelVersion: 5.0
Contact: Vadim Pasternak <vadimpmellanox.com>
Description: This file shows the system fans direction:
forward direction - relevant bit is set 0;
reversed direction - relevant bit is set 1.
The files are read only.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/
jtag_enable
Date: November 2018
KernelVersion: 5.0

23
Documentation/ABI/testing/debugfs-wilco-ec 100644
View File

@ -0,0 +1,23 @@
What: /sys/kernel/debug/wilco_ec/raw
Date: January 2019
KernelVersion: 5.1
Description:
Write and read raw mailbox commands to the EC.
For writing:
Bytes 0-1 indicate the message type:
00 F0 = Execute Legacy Command
00 F2 = Read/Write NVRAM Property
Byte 2 provides the command code
Bytes 3+ consist of the data passed in the request
At least three bytes are required, for the msg type and command,
with additional bytes optional for additional data.
Example:
// Request EC info type 3 (EC firmware build date)
$ echo 00 f0 38 00 03 00 > raw
// View the result. The decoded ASCII result "12/21/18" is
// included after the raw hex.
$ cat raw
00 31 32 2f 32 31 2f 31 38 00 38 00 01 00 2f 00 .12/21/18.8...

32
Documentation/ABI/testing/sysfs-class-chromeos 100644
View File

@ -0,0 +1,32 @@
What: /sys/class/chromeos/<ec-device-name>/flashinfo
Date: August 2015
KernelVersion: 4.2
Description:
Show the EC flash information.
What: /sys/class/chromeos/<ec-device-name>/kb_wake_angle
Date: March 2018
KernelVersion: 4.17
Description:
Control the keyboard wake lid angle. Values are between
0 and 360. This file will also show the keyboard wake lid
angle by querying the hardware.
What: /sys/class/chromeos/<ec-device-name>/reboot
Date: August 2015
KernelVersion: 4.2
Description:
Tell the EC to reboot in various ways. Options are:
"cancel": Cancel a pending reboot.
"ro": Jump to RO without rebooting.
"rw": Jump to RW without rebooting.
"cold": Cold reboot.
"disable-jump": Disable jump until next reboot.
"hibernate": Hibernate the EC.
"at-shutdown": Reboot after an AP shutdown.
What: /sys/class/chromeos/<ec-device-name>/version
Date: August 2015
KernelVersion: 4.2
Description:
Show the information about the EC software and hardware.

74
Documentation/ABI/testing/sysfs-class-chromeos-driver-cros-ec-lightbar 100644
View File

@ -0,0 +1,74 @@
What: /sys/class/chromeos/<ec-device-name>/lightbar/brightness
Date: August 2015
KernelVersion: 4.2
Description:
Writing to this file adjusts the overall brightness of
the lightbar, separate from any color intensity. The
valid range is 0 (off) to 255 (maximum brightness).
What: /sys/class/chromeos/<ec-device-name>/lightbar/interval_msec
Date: August 2015
KernelVersion: 4.2
Description:
The lightbar is controlled by an embedded controller (EC),
which also manages the keyboard, battery charging, fans,
and other system hardware. To prevent unprivileged users
from interfering with the other EC functions, the rate at
which the lightbar control files can be read or written is
limited.
Reading this file will return the number of milliseconds
that must elapse between accessing any of the lightbar
functions through this interface. Going faster will simply
block until the necessary interval has lapsed. The interval
applies uniformly to all accesses of any kind by any user.
What: /sys/class/chromeos/<ec-device-name>/lightbar/led_rgb
Date: August 2015
KernelVersion: 4.2
Description:
This allows you to control each LED segment. If the
lightbar is already running one of the automatic
sequences, you probably won’t see anything change because
your color setting will be almost immediately replaced.
To get useful results, you should stop the lightbar
sequence first.
The values written to this file are sets of four integers,
indicating LED, RED, GREEN, BLUE. The LED number is 0 to 3
to select a single segment, or 4 to set all four segments
to the same value at once. The RED, GREEN, and BLUE
numbers should be in the range 0 (off) to 255 (maximum).
You can update more than one segment at a time by writing
more than one set of four integers.
What: /sys/class/chromeos/<ec-device-name>/lightbar/program
Date: August 2015
KernelVersion: 4.2
Description:
This allows you to upload and run custom lightbar sequences.
What: /sys/class/chromeos/<ec-device-name>/lightbar/sequence
Date: August 2015
KernelVersion: 4.2
Description:
The Pixel lightbar has a number of built-in sequences
that it displays under various conditions, such as at
power on, shut down, or while running. Reading from this
file displays the current sequence that the lightbar is
displaying. Writing to this file allows you to change the
sequence.
What: /sys/class/chromeos/<ec-device-name>/lightbar/userspace_control
Date: August 2015
KernelVersion: 4.2
Description:
This allows you to take the control of the lightbar. This
prevents the kernel from going through its normal
sequences.
What: /sys/class/chromeos/<ec-device-name>/lightbar/version
Date: August 2015
KernelVersion: 4.2
Description:
Show the information about the lightbar version.

6
Documentation/ABI/testing/sysfs-class-chromeos-driver-cros-ec-vbc 100644
View File

@ -0,0 +1,6 @@
What: /sys/class/chromeos/<ec-device-name>/vbc/vboot_context
Date: October 2015
KernelVersion: 4.4
Description:
Read/write the verified boot context data included on a
small nvram space on some EC implementations.

23
Documentation/ABI/testing/sysfs-class-watchdog
View File

@ -49,3 +49,26 @@ Contact: Wim Van Sebroeck <wim@iguana.be>
Description:
It is a read only file. It is read to know about current
value of timeout programmed.
What: /sys/class/watchdog/watchdogn/pretimeout
Date: December 2016
Contact: Wim Van Sebroeck <wim@iguana.be>
Description:
It is a read only file. It specifies the time in seconds before
timeout when the pretimeout interrupt is delivered. Pretimeout
is an optional feature.
What: /sys/class/watchdog/watchdogn/pretimeout_avaialable_governors
Date: February 2017
Contact: Wim Van Sebroeck <wim@iguana.be>
Description:
It is a read only file. It shows the pretimeout governors
available for this watchdog.
What: /sys/class/watchdog/watchdogn/pretimeout_governor
Date: February 2017
Contact: Wim Van Sebroeck <wim@iguana.be>
Description:
It is a read/write file. When read, the currently assigned
pretimeout governor is returned. When written, it sets
the pretimeout governor.

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

@ -109,3 +109,10 @@ Description:
write operation (since a 4k random write might turn
into a much larger write due to the zeroout
operation).
What: /sys/fs/ext4/<disk>/journal_task
Date: February 2019
Contact: "Theodore Ts'o" <tytso@mit.edu>
Description:
This file is read-only and shows the pid of journal thread in
current pid-namespace or 0 if task is unreachable.

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

@ -86,6 +86,13 @@ Description:
The unit size is one block, now only support configuring in range
of [1, 512].
What: /sys/fs/f2fs/<disk>/umount_discard_timeout
Date: January 2019
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description:
Set timeout to issue discard commands during umount.
Default: 5 secs
What: /sys/fs/f2fs/<disk>/max_victim_search
Date: January 2014
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>

121
Documentation/DMA-API-HOWTO.txt
View File

@ -146,114 +146,75 @@ What about block I/O and networking buffers? The block I/O and
networking subsystems make sure that the buffers they use are valid
for you to DMA from/to.
DMA addressing limitations
DMA addressing capabilities
==========================
Does your device have any DMA addressing limitations? For example, is
your device only capable of driving the low order 24-bits of address?
If so, you need to inform the kernel of this fact.
By default, the kernel assumes that your device can address 32-bits of DMA
addressing. For a 64-bit capable device, this needs to be increased, and for
a device with limitations, it needs to be decreased.
By default, the kernel assumes that your device can address the full
32-bits. For a 64-bit capable device, this needs to be increased.
And for a device with limitations, as discussed in the previous
paragraph, it needs to be decreased.
Special note about PCI: PCI-X specification requires PCI-X devices to support
64-bit addressing (DAC) for all transactions. And at least one platform (SGI
SN2) requires 64-bit consistent allocations to operate correctly when the IO
bus is in PCI-X mode.
Special note about PCI: PCI-X specification requires PCI-X devices to
support 64-bit addressing (DAC) for all transactions. And at least
one platform (SGI SN2) requires 64-bit consistent allocations to
operate correctly when the IO bus is in PCI-X mode.
For correct operation, you must set the DMA mask to inform the kernel about
your devices DMA addressing capabilities.
For correct operation, you must interrogate the kernel in your device
probe routine to see if the DMA controller on the machine can properly
support the DMA addressing limitation your device has. It is good
style to do this even if your device holds the default setting,
because this shows that you did think about these issues wrt. your
device.
The query is performed via a call to dma_set_mask_and_coherent()::
This is performed via a call to dma_set_mask_and_coherent()::
int dma_set_mask_and_coherent(struct device *dev, u64 mask);
which will query the mask for both streaming and coherent APIs together.
If you have some special requirements, then the following two separate
queries can be used instead:
which will set the mask for both streaming and coherent APIs together. If you
have some special requirements, then the following two separate calls can be
used instead:
The query for streaming mappings is performed via a call to
The setup for streaming mappings is performed via a call to
dma_set_mask()::
int dma_set_mask(struct device *dev, u64 mask);
The query for consistent allocations is performed via a call
The setup for consistent allocations is performed via a call
to dma_set_coherent_mask()::
int dma_set_coherent_mask(struct device *dev, u64 mask);
Here, dev is a pointer to the device struct of your device, and mask
is a bit mask describing which bits of an address your device
supports. It returns zero if your card can perform DMA properly on
the machine given the address mask you provided. In general, the
device struct of your device is embedded in the bus-specific device
struct of your device. For example, &pdev->dev is a pointer to the
device struct of a PCI device (pdev is a pointer to the PCI device
struct of your device).
Here, dev is a pointer to the device struct of your device, and mask is a bit
mask describing which bits of an address your device supports. Often the
device struct of your device is embedded in the bus-specific device struct of
your device. For example, &pdev->dev is a pointer to the device struct of a
PCI device (pdev is a pointer to the PCI device struct of your device).
If it returns non-zero, your device cannot perform DMA properly on
this platform, and attempting to do so will result in undefined
behavior. You must either use a different mask, or not use DMA.
These calls usually return zero to indicated your device can perform DMA
properly on the machine given the address mask you provided, but they might
return an error if the mask is too small to be supportable on the given
system. If it returns non-zero, your device cannot perform DMA properly on
this platform, and attempting to do so will result in undefined behavior.
You must not use DMA on this device unless the dma_set_mask family of
functions has returned success.
This means that in the failure case, you have three options:
This means that in the failure case, you have two options:
1) Use another DMA mask, if possible (see below).
2) Use some non-DMA mode for data transfer, if possible.
3) Ignore this device and do not initialize it.
1) Use some non-DMA mode for data transfer, if possible.
2) Ignore this device and do not initialize it.
It is recommended that your driver print a kernel KERN_WARNING message
when you end up performing either #2 or #3. In this manner, if a user
of your driver reports that performance is bad or that the device is not
even detected, you can ask them for the kernel messages to find out
exactly why.
It is recommended that your driver print a kernel KERN_WARNING message when
setting the DMA mask fails. In this manner, if a user of your driver reports
that performance is bad or that the device is not even detected, you can ask
them for the kernel messages to find out exactly why.
The standard 32-bit addressing device would do something like this::
The standard 64-bit addressing device would do something like this::
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
dev_warn(dev, "mydev: No suitable DMA available\n");
goto ignore_this_device;
}
Another common scenario is a 64-bit capable device. The approach here
is to try for 64-bit addressing, but back down to a 32-bit mask that
should not fail. The kernel may fail the 64-bit mask not because the
platform is not capable of 64-bit addressing. Rather, it may fail in
this case simply because 32-bit addressing is done more efficiently
than 64-bit addressing. For example, Sparc64 PCI SAC addressing is
more efficient than DAC addressing.
If the device only supports 32-bit addressing for descriptors in the
coherent allocations, but supports full 64-bits for streaming mappings
it would look like this:
Here is how you would handle a 64-bit capable device which can drive
all 64-bits when accessing streaming DMA::
int using_dac;
if (!dma_set_mask(dev, DMA_BIT_MASK(64))) {
using_dac = 1;
} else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) {
using_dac = 0;
} else {
dev_warn(dev, "mydev: No suitable DMA available\n");
goto ignore_this_device;
}
If a card is capable of using 64-bit consistent allocations as well,
the case would look like this::
int using_dac, consistent_using_dac;
if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
using_dac = 1;
consistent_using_dac = 1;
} else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
using_dac = 0;
consistent_using_dac = 0;
} else {
if (dma_set_mask(dev, DMA_BIT_MASK(64))) {
dev_warn(dev, "mydev: No suitable DMA available\n");
goto ignore_this_device;
}

43
Documentation/DMA-API.txt
View File

@ -195,6 +195,14 @@ Requesting the required mask does not alter the current mask. If you
wish to take advantage of it, you should issue a dma_set_mask()
call to set the mask to the value returned.
::
size_t
dma_direct_max_mapping_size(struct device *dev);
Returns the maximum size of a mapping for the device. The size parameter
of the mapping functions like dma_map_single(), dma_map_page() and
others should not be larger than the returned value.
Part Id - Streaming DMA mappings
--------------------------------
@ -530,8 +538,8 @@ that simply cannot make consistent memory.
dma_free_attrs(struct device *dev, size_t size, void *cpu_addr,
dma_addr_t dma_handle, unsigned long attrs)
Free memory allocated by the dma_alloc_attrs(). All parameters common
parameters must identical to those otherwise passed to dma_fre_coherent,
Free memory allocated by the dma_alloc_attrs(). All common
parameters must be identical to those otherwise passed to dma_free_coherent,
and the attrs argument must be identical to the attrs passed to
dma_alloc_attrs().
@ -566,8 +574,7 @@ boundaries when doing this.
int
dma_declare_coherent_memory(struct device *dev, phys_addr_t phys_addr,
dma_addr_t device_addr, size_t size, int
flags)
dma_addr_t device_addr, size_t size);
Declare region of memory to be handed out by dma_alloc_coherent() when
it's asked for coherent memory for this device.
@ -581,12 +588,6 @@ dma_addr_t in dma_alloc_coherent()).
size is the size of the area (must be multiples of PAGE_SIZE).
flags can be ORed together and are:
- DMA_MEMORY_EXCLUSIVE - only allocate memory from the declared regions.
Do not allow dma_alloc_coherent() to fall back to system memory when
it's out of memory in the declared region.
As a simplification for the platforms, only *one* such region of
memory may be declared per device.
@ -605,23 +606,6 @@ unconditionally having removed all the required structures. It is the
driver's job to ensure that no parts of this memory region are
currently in use.
::
void *
dma_mark_declared_memory_occupied(struct device *dev,
dma_addr_t device_addr, size_t size)
This is used to occupy specific regions of the declared space
(dma_alloc_coherent() will hand out the first free region it finds).
device_addr is the *device* address of the region requested.
size is the size (and should be a page-sized multiple).
The return value will be either a pointer to the processor virtual
address of the memory, or an error (via PTR_ERR()) if any part of the
region is occupied.
Part III - Debug drivers use of the DMA-API
-------------------------------------------
@ -696,6 +680,9 @@ dma-api/disabled This read-only file contains the character 'Y'
happen when it runs out of memory or if it was
disabled at boot time
dma-api/dump This read-only file contains current DMA
mappings.
dma-api/error_count This file is read-only and shows the total
numbers of errors found.
@ -717,7 +704,7 @@ dma-api/num_free_entries The current number of free dma_debug_entries
dma-api/nr_total_entries The total number of dma_debug_entries in the
allocator, both free and used.
dma-api/driver-filter You can write a name of a driver into this file
dma-api/driver_filter You can write a name of a driver into this file
to limit the debug output to requests from that
particular driver. Write an empty string to
that file to disable the filter and see

4
Documentation/DMA-ISA-LPC.txt
View File

@ -52,8 +52,8 @@ Address translation
-------------------
To translate the virtual address to a bus address, use the normal DMA
API. Do _not_ use isa_virt_to_phys() even though it does the same
thing. The reason for this is that the function isa_virt_to_phys()
API. Do _not_ use isa_virt_to_bus() even though it does the same
thing. The reason for this is that the function isa_virt_to_bus()
will require a Kconfig dependency to ISA, not just ISA_DMA_API which
is really all you need. Remember that even though the DMA controller
has its origins in ISA it is used elsewhere.

12
Documentation/RCU/lockdep-splat.txt
View File

@ -14,9 +14,9 @@ being the real world and all that.
So let's look at an example RCU lockdep splat from 3.0-rc5, one that
has long since been fixed:
===============================
[ INFO: suspicious RCU usage. ]
-------------------------------
=============================
WARNING: suspicious RCU usage
-----------------------------
block/cfq-iosched.c:2776 suspicious rcu_dereference_protected() usage!
other info that might help us debug this:
@ -24,11 +24,11 @@ other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
3 locks held by scsi_scan_6/1552:
#0: (&shost->scan_mutex){+.+.+.}, at: [<ffffffff8145efca>]
#0: (&shost->scan_mutex){+.+.}, at: [<ffffffff8145efca>]
scsi_scan_host_selected+0x5a/0x150
#1: (&eq->sysfs_lock){+.+...}, at: [<ffffffff812a5032>]
#1: (&eq->sysfs_lock){+.+.}, at: [<ffffffff812a5032>]
elevator_exit+0x22/0x60
#2: (&(&q->__queue_lock)->rlock){-.-...}, at: [<ffffffff812b6233>]
#2: (&(&q->__queue_lock)->rlock){-.-.}, at: [<ffffffff812b6233>]
cfq_exit_queue+0x43/0x190
stack backtrace:

4
Documentation/acpi/aml-debugger.txt
View File

@ -23,7 +23,7 @@ kernel.
The resultant userspace tool binary is then located at:
tools/acpi/power/acpi/acpidbg/acpidbg
tools/power/acpi/acpidbg
It can be installed to system directories by running "make install" (as a
sufficiently privileged user).
@ -35,7 +35,7 @@ kernel.
# mount -t debugfs none /sys/kernel/debug
# modprobe acpi_dbg
# tools/acpi/power/acpi/acpidbg/acpidbg
# tools/power/acpi/acpidbg
That spawns the interactive AML debugger environment where you can execute
debugger commands.

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

@ -251,7 +251,7 @@ Configuring the kernel
Compiling the kernel
--------------------
- Make sure you have at least gcc 3.2 available.
- Make sure you have at least gcc 4.6 available.
For more information, refer to :ref:`Documentation/process/changes.rst <changes>`.
Please note that you can still run a.out user programs with this kernel.

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

@ -1197,9 +1197,10 @@
arch/x86/kernel/cpu/cpufreq/elanfreq.c.
elevator= [IOSCHED]
Format: {"cfq" | "deadline" | "noop"}
See Documentation/block/cfq-iosched.txt and
Documentation/block/deadline-iosched.txt for details.
Format: { "mq-deadline" | "kyber" | "bfq" }
See Documentation/block/deadline-iosched.txt,
Documentation/block/kyber-iosched.txt and
Documentation/block/bfq-iosched.txt for details.
elfcorehdr=[size[KMG]@]offset[KMG] [IA64,PPC,SH,X86,S390]
Specifies physical address of start of kernel core
@ -1845,6 +1846,11 @@
to let secondary kernels in charge of setting up
LPIs.
irqchip.gicv3_pseudo_nmi= [ARM64]
Enables support for pseudo-NMIs in the kernel. This
requires the kernel to be built with
CONFIG_ARM64_PSEUDO_NMI.
irqfixup [HW]
When an interrupt is not handled search all handlers
for it. Intended to get systems with badly broken
@ -1996,6 +2002,12 @@
Built with CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y,
the default is off.
kpti= [ARM64] Control page table isolation of user
and kernel address spaces.
Default: enabled on cores which need mitigation.
0: force disabled
1: force enabled
kvm.ignore_msrs=[KVM] Ignore guest accesses to unhandled MSRs.
Default is 0 (don't ignore, but inject #GP)
@ -5066,6 +5078,14 @@
or other driver-specific files in the
Documentation/watchdog/ directory.
watchdog_thresh=
[KNL]
Set the hard lockup detector stall duration
threshold in seconds. The soft lockup detector
threshold is set to twice the value. A value of 0
disables both lockup detectors. Default is 10
seconds.
workqueue.watchdog_thresh=
If CONFIG_WQ_WATCHDOG is configured, workqueue can
warn stall conditions and dump internal state to

3
Documentation/admin-guide/md.rst
View File

@ -756,3 +756,6 @@ These currently include:
The cache mode for raid5. raid5 could include an extra disk for
caching. The mode can be "write-throuth" and "write-back". The
default is "write-through".
ppl_write_hint
NVMe stream ID to be set for each PPL write request.

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

@ -6,83 +6,211 @@ Perf Events and tool security
Overview
--------
Usage of Performance Counters for Linux (perf_events) [1]_ , [2]_ , [3]_ can
impose a considerable risk of leaking sensitive data accessed by monitored
processes. The data leakage is possible both in scenarios of direct usage of
perf_events system call API [2]_ and over data files generated by Perf tool user
mode utility (Perf) [3]_ , [4]_ . The risk depends on the nature of data that
perf_events performance monitoring units (PMU) [2]_ collect and expose for
performance analysis. Having that said perf_events/Perf performance monitoring
is the subject for security access control management [5]_ .
Usage of Performance Counters for Linux (perf_events) [1]_ , [2]_ , [3]_
can impose a considerable risk of leaking sensitive data accessed by
monitored processes. The data leakage is possible both in scenarios of
direct usage of perf_events system call API [2]_ and over data files
generated by Perf tool user mode utility (Perf) [3]_ , [4]_ . The risk
depends on the nature of data that perf_events performance monitoring
units (PMU) [2]_ and Perf collect and expose for performance analysis.
Collected system and performance data may be split into several
categories:
1. System hardware and software configuration data, for example: a CPU
model and its cache configuration, an amount of available memory and
its topology, used kernel and Perf versions, performance monitoring
setup including experiment time, events configuration, Perf command
line parameters, etc.
2. User and kernel module paths and their load addresses with sizes,
process and thread names with their PIDs and TIDs, timestamps for
captured hardware and software events.
3. Content of kernel software counters (e.g., for context switches, page
faults, CPU migrations), architectural hardware performance counters
(PMC) [8]_ and machine specific registers (MSR) [9]_ that provide
execution metrics for various monitored parts of the system (e.g.,
memory controller (IMC), interconnect (QPI/UPI) or peripheral (PCIe)
uncore counters) without direct attribution to any execution context
state.
4. Content of architectural execution context registers (e.g., RIP, RSP,
RBP on x86_64), process user and kernel space memory addresses and
data, content of various architectural MSRs that capture data from
this category.
Data that belong to the fourth category can potentially contain
sensitive process data. If PMUs in some monitoring modes capture values
of execution context registers or data from process memory then access
to such monitoring capabilities requires to be ordered and secured
properly. So, perf_events/Perf performance monitoring is the subject for
security access control management [5]_ .
perf_events/Perf access control
-------------------------------
To perform security checks, the Linux implementation splits processes into two
categories [6]_ : a) privileged processes (whose effective user ID is 0, referred
to as superuser or root), and b) unprivileged processes (whose effective UID is
nonzero). Privileged processes bypass all kernel security permission checks so
perf_events performance monitoring is fully available to privileged processes
without access, scope and resource restrictions.
To perform security checks, the Linux implementation splits processes
into two categories [6]_ : a) privileged processes (whose effective user
ID is 0, referred to as superuser or root), and b) unprivileged
processes (whose effective UID is nonzero). Privileged processes bypass
all kernel security permission checks so perf_events performance
monitoring is fully available to privileged processes without access,
scope and resource restrictions.
Unprivileged processes are subject to a full security permission check based on
the process's credentials [5]_ (usually: effective UID, effective GID, and
supplementary group list).
Unprivileged processes are subject to a full security permission check
based on the process's credentials [5]_ (usually: effective UID,
effective GID, and supplementary group list).
Linux divides the privileges traditionally associated with superuser into
distinct units, known as capabilities [6]_ , which can be independently enabled
and disabled on per-thread basis for processes and files of unprivileged users.
Linux divides the privileges traditionally associated with superuser
into distinct units, known as capabilities [6]_ , which can be
independently enabled and disabled on per-thread basis for processes and
files of unprivileged users.
Unprivileged processes with enabled CAP_SYS_ADMIN capability are treated as
privileged processes with respect to perf_events performance monitoring and
bypass *scope* permissions checks in the kernel.
Unprivileged processes with enabled CAP_SYS_ADMIN capability are treated
as privileged processes with respect to perf_events performance
monitoring and bypass *scope* permissions checks in the kernel.
Unprivileged processes using perf_events system call API is also subject for
PTRACE_MODE_READ_REALCREDS ptrace access mode check [7]_ , whose outcome
determines whether monitoring is permitted. So unprivileged processes provided
with CAP_SYS_PTRACE capability are effectively permitted to pass the check.
Unprivileged processes using perf_events system call API is also subject
for PTRACE_MODE_READ_REALCREDS ptrace access mode check [7]_ , whose
outcome determines whether monitoring is permitted. So unprivileged
processes provided with CAP_SYS_PTRACE capability are effectively
permitted to pass the check.
Other capabilities being granted to unprivileged processes can effectively
enable capturing of additional data required for later performance analysis of
monitored processes or a system. For example, CAP_SYSLOG capability permits
reading kernel space memory addresses from /proc/kallsyms file.
Other capabilities being granted to unprivileged processes can
effectively enable capturing of additional data required for later
performance analysis of monitored processes or a system. For example,
CAP_SYSLOG capability permits reading kernel space memory addresses from
/proc/kallsyms file.
perf_events/Perf privileged users
---------------------------------
Mechanisms of capabilities, privileged capability-dumb files [6]_ and
file system ACLs [10]_ can be used to create a dedicated group of
perf_events/Perf privileged users who are permitted to execute
performance monitoring without scope limits. The following steps can be
taken to create such a group of privileged Perf users.
1. Create perf_users group of privileged Perf users, assign perf_users
group to Perf tool executable and limit access to the executable for
other users in the system who are not in the perf_users group:
::
# groupadd perf_users
# ls -alhF
-rwxr-xr-x 2 root root 11M Oct 19 15:12 perf
# chgrp perf_users perf
# ls -alhF
-rwxr-xr-x 2 root perf_users 11M Oct 19 15:12 perf
# chmod o-rwx perf
# ls -alhF
-rwxr-x--- 2 root perf_users 11M Oct 19 15:12 perf
2. Assign the required capabilities to the Perf tool executable file and
enable members of perf_users group with performance monitoring
privileges [6]_ :
::
# setcap "cap_sys_admin,cap_sys_ptrace,cap_syslog=ep" perf
# setcap -v "cap_sys_admin,cap_sys_ptrace,cap_syslog=ep" perf
perf: OK
# getcap perf
perf = cap_sys_ptrace,cap_sys_admin,cap_syslog+ep
As a result, members of perf_users group are capable of conducting
performance monitoring by using functionality of the configured Perf
tool executable that, when executes, passes perf_events subsystem scope
checks.
This specific access control management is only available to superuser
or root running processes with CAP_SETPCAP, CAP_SETFCAP [6]_
capabilities.
perf_events/Perf unprivileged users
-----------------------------------
perf_events/Perf *scope* and *access* control for unprivileged processes is
governed by perf_event_paranoid [2]_ setting:
perf_events/Perf *scope* and *access* control for unprivileged processes
is governed by perf_event_paranoid [2]_ setting:
-1:
Impose no *scope* and *access* restrictions on using perf_events performance
monitoring. Per-user per-cpu perf_event_mlock_kb [2]_ locking limit is
ignored when allocating memory buffers for storing performance data.
This is the least secure mode since allowed monitored *scope* is
maximized and no perf_events specific limits are imposed on *resources*
allocated for performance monitoring.
Impose no *scope* and *access* restrictions on using perf_events
performance monitoring. Per-user per-cpu perf_event_mlock_kb [2]_
locking limit is ignored when allocating memory buffers for storing
performance data. This is the least secure mode since allowed
monitored *scope* is maximized and no perf_events specific limits
are imposed on *resources* allocated for performance monitoring.
>=0:
*scope* includes per-process and system wide performance monitoring
but excludes raw tracepoints and ftrace function tracepoints monitoring.
CPU and system events happened when executing either in user or
in kernel space can be monitored and captured for later analysis.
Per-user per-cpu perf_event_mlock_kb locking limit is imposed but
ignored for unprivileged processes with CAP_IPC_LOCK [6]_ capability.
but excludes raw tracepoints and ftrace function tracepoints
monitoring. CPU and system events happened when executing either in
user or in kernel space can be monitored and captured for later
analysis. Per-user per-cpu perf_event_mlock_kb locking limit is
imposed but ignored for unprivileged processes with CAP_IPC_LOCK
[6]_ capability.
>=1:
*scope* includes per-process performance monitoring only and excludes
system wide performance monitoring. CPU and system events happened when
executing either in user or in kernel space can be monitored and
captured for later analysis. Per-user per-cpu perf_event_mlock_kb
locking limit is imposed but ignored for unprivileged processes with
CAP_IPC_LOCK capability.
*scope* includes per-process performance monitoring only and
excludes system wide performance monitoring. CPU and system events
happened when executing either in user or in kernel space can be
monitored and captured for later analysis. Per-user per-cpu
perf_event_mlock_kb locking limit is imposed but ignored for
unprivileged processes with CAP_IPC_LOCK capability.
>=2:
*scope* includes per-process performance monitoring only. CPU and system
events happened when executing in user space only can be monitored and
captured for later analysis. Per-user per-cpu perf_event_mlock_kb
locking limit is imposed but ignored for unprivileged processes with
CAP_IPC_LOCK capability.
*scope* includes per-process performance monitoring only. CPU and
system events happened when executing in user space only can be
monitored and captured for later analysis. Per-user per-cpu
perf_event_mlock_kb locking limit is imposed but ignored for
unprivileged processes with CAP_IPC_LOCK capability.
perf_events/Perf resource control
---------------------------------
Open file descriptors
+++++++++++++++++++++
The perf_events system call API [2]_ allocates file descriptors for
every configured PMU event. Open file descriptors are a per-process
accountable resource governed by the RLIMIT_NOFILE [11]_ limit
(ulimit -n), which is usually derived from the login shell process. When
configuring Perf collection for a long list of events on a large server
system, this limit can be easily hit preventing required monitoring
configuration. RLIMIT_NOFILE limit can be increased on per-user basis
modifying content of the limits.conf file [12]_ . Ordinarily, a Perf
sampling session (perf record) requires an amount of open perf_event
file descriptors that is not less than the number of monitored events
multiplied by the number of monitored CPUs.
Memory allocation
+++++++++++++++++
The amount of memory available to user processes for capturing
performance monitoring data is governed by the perf_event_mlock_kb [2]_
setting. This perf_event specific resource setting defines overall
per-cpu limits of memory allowed for mapping by the user processes to
execute performance monitoring. The setting essentially extends the
RLIMIT_MEMLOCK [11]_ limit, but only for memory regions mapped
specifically for capturing monitored performance events and related data.
For example, if a machine has eight cores and perf_event_mlock_kb limit
is set to 516 KiB, then a user process is provided with 516 KiB * 8 =
4128 KiB of memory above the RLIMIT_MEMLOCK limit (ulimit -l) for
perf_event mmap buffers. In particular, this means that, if the user
wants to start two or more performance monitoring processes, the user is
required to manually distribute the available 4128 KiB between the
monitoring processes, for example, using the --mmap-pages Perf record
mode option. Otherwise, the first started performance monitoring process
allocates all available 4128 KiB and the other processes will fail to
proceed due to the lack of memory.
RLIMIT_MEMLOCK and perf_event_mlock_kb resource constraints are ignored
for processes with the CAP_IPC_LOCK capability. Thus, perf_events/Perf
privileged users can be provided with memory above the constraints for
perf_events/Perf performance monitoring purpose by providing the Perf
executable with CAP_IPC_LOCK capability.
Bibliography
------------
@ -94,4 +222,9 @@ Bibliography
.. [5] `<https://www.kernel.org/doc/html/latest/security/credentials.html>`_
.. [6] `<http://man7.org/linux/man-pages/man7/capabilities.7.html>`_
.. [7] `<http://man7.org/linux/man-pages/man2/ptrace.2.html>`_
.. [8] `<https://en.wikipedia.org/wiki/Hardware_performance_counter>`_
.. [9] `<https://en.wikipedia.org/wiki/Model-specific_register>`_
.. [10] `<http://man7.org/linux/man-pages/man5/acl.5.html>`_
.. [11] `<http://man7.org/linux/man-pages/man2/getrlimit.2.html>`_
.. [12] `<http://man7.org/linux/man-pages/man5/limits.conf.5.html>`_

157
Documentation/admin-guide/tainted-kernels.rst
View File

@ -1,59 +1,164 @@
Tainted kernels
---------------
Some oops reports contain the string **'Tainted: '** after the program
counter. This indicates that the kernel has been tainted by some
mechanism. The string is followed by a series of position-sensitive
characters, each representing a particular tainted value.
The kernel will mark itself as 'tainted' when something occurs that might be
relevant later when investigating problems. Don't worry too much about this,
most of the time it's not a problem to run a tainted kernel; the information is
mainly of interest once someone wants to investigate some problem, as its real
cause might be the event that got the kernel tainted. That's why bug reports
from tainted kernels will often be ignored by developers, hence try to reproduce
problems with an untainted kernel.
1) ``G`` if all modules loaded have a GPL or compatible license, ``P`` if
Note the kernel will remain tainted even after you undo what caused the taint
(i.e. unload a proprietary kernel module), to indicate the kernel remains not
trustworthy. That's also why the kernel will print the tainted state when it
notices an internal problem (a 'kernel bug'), a recoverable error
('kernel oops') or a non-recoverable error ('kernel panic') and writes debug
information about this to the logs ``dmesg`` outputs. It's also possible to
check the tainted state at runtime through a file in ``/proc/``.
Tainted flag in bugs, oops or panics messages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You find the tainted state near the top in a line starting with 'CPU:'; if or
why the kernel was tainted is shown after the Process ID ('PID:') and a shortened
name of the command ('Comm:') that triggered the event::
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
Oops: 0002 [#1] SMP PTI
CPU: 0 PID: 4424 Comm: insmod Tainted: P W O 4.20.0-0.rc6.fc30 #1
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:my_oops_init+0x13/0x1000 [kpanic]
[...]
You'll find a 'Not tainted: ' there if the kernel was not tainted at the
time of the event; if it was, then it will print 'Tainted: ' and characters
either letters or blanks. In above example it looks like this::
Tainted: P W O
The meaning of those characters is explained in the table below. In tis case
the kernel got tainted earlier because a proprietary Module (``P``) was loaded,
a warning occurred (``W``), and an externally-built module was loaded (``O``).
To decode other letters use the table below.
Decoding tainted state at runtime
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At runtime, you can query the tainted state by reading
``cat /proc/sys/kernel/tainted``. If that returns ``0``, the kernel is not
tainted; any other number indicates the reasons why it is. The easiest way to
decode that number is the script ``tools/debugging/kernel-chktaint``, which your
distribution might ship as part of a package called ``linux-tools`` or
``kernel-tools``; if it doesn't you can download the script from
`git.kernel.org <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/tools/debugging/kernel-chktaint>`_
and execute it with ``sh kernel-chktaint``, which would print something like
this on the machine that had the statements in the logs that were quoted earlier::
Kernel is Tainted for following reasons:
* Proprietary module was loaded (#0)
* Kernel issued warning (#9)
* Externally-built ('out-of-tree') module was loaded (#12)
See Documentation/admin-guide/tainted-kernels.rst in the the Linux kernel or
https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html for
a more details explanation of the various taint flags.
Raw taint value as int/string: 4609/'P W O '
You can try to decode the number yourself. That's easy if there was only one
reason that got your kernel tainted, as in this case you can find the number
with the table below. If there were multiple reasons you need to decode the
number, as it is a bitfield, where each bit indicates the absence or presence of
a particular type of taint. It's best to leave that to the aforementioned
script, but if you need something quick you can use this shell command to check
which bits are set::
$ for i in $(seq 18); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done
Table for decoding tainted state
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
=== === ====== ========================================================
Bit Log Number Reason that got the kernel tainted
=== === ====== ========================================================
0 G/P 1 proprietary module was loaded
1 _/F 2 module was force loaded
2 _/S 4 SMP kernel oops on an officially SMP incapable processor
3 _/R 8 module was force unloaded
4 _/M 16 processor reported a Machine Check Exception (MCE)
5 _/B 32 bad page referenced or some unexpected page flags
6 _/U 64 taint requested by userspace application
7 _/D 128 kernel died recently, i.e. there was an OOPS or BUG
8 _/A 256 ACPI table overridden by user
9 _/W 512 kernel issued warning
10 _/C 1024 staging driver was loaded
11 _/I 2048 workaround for bug in platform firmware applied
12 _/O 4096 externally-built ("out-of-tree") module was loaded
13 _/E 8192 unsigned module was loaded
14 _/L 16384 soft lockup occurred
15 _/K 32768 kernel has been live patched
16 _/X 65536 auxiliary taint, defined for and used by distros
17 _/T 131072 kernel was built with the struct randomization plugin
=== === ====== ========================================================
Note: The character ``_`` is representing a blank in this table to make reading
easier.
More detailed explanation for tainting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0) ``G`` if all modules loaded have a GPL or compatible license, ``P`` if
any proprietary module has been loaded. Modules without a
MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by
insmod as GPL compatible are assumed to be proprietary.
2) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all
1) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all
modules were loaded normally.
3) ``S`` if the oops occurred on an SMP kernel running on hardware that
2) ``S`` if the oops occurred on an SMP kernel running on hardware that
hasn't been certified as safe to run multiprocessor.
Currently this occurs only on various Athlons that are not
SMP capable.
4) ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all
3) ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all
modules were unloaded normally.
5) ``M`` if any processor has reported a Machine Check Exception,
4) ``M`` if any processor has reported a Machine Check Exception,
``' '`` if no Machine Check Exceptions have occurred.
6) ``B`` if a page-release function has found a bad page reference or
some unexpected page flags.
5) ``B`` If a page-release function has found a bad page reference or some
unexpected page flags. This indicates a hardware problem or a kernel bug;
there should be other information in the log indicating why this tainting
occured.
7) ``U`` if a user or user application specifically requested that the
6) ``U`` if a user or user application specifically requested that the
Tainted flag be set, ``' '`` otherwise.
8) ``D`` if the kernel has died recently, i.e. there was an OOPS or BUG.
7) ``D`` if the kernel has died recently, i.e. there was an OOPS or BUG.
9) ``A`` if the ACPI table has been overridden.
8) ``A`` if an ACPI table has been overridden.
10) ``W`` if a warning has previously been issued by the kernel.
9) ``W`` if a warning has previously been issued by the kernel.
(Though some warnings may set more specific taint flags.)
11) ``C`` if a staging driver has been loaded.
10) ``C`` if a staging driver has been loaded.
12) ``I`` if the kernel is working around a severe bug in the platform
11) ``I`` if the kernel is working around a severe bug in the platform
firmware (BIOS or similar).
13) ``O`` if an externally-built ("out-of-tree") module has been loaded.
12) ``O`` if an externally-built ("out-of-tree") module has been loaded.
14) ``E`` if an unsigned module has been loaded in a kernel supporting
13) ``E`` if an unsigned module has been loaded in a kernel supporting
module signature.
15) ``L`` if a soft lockup has previously occurred on the system.
14) ``L`` if a soft lockup has previously occurred on the system.
16) ``K`` if the kernel has been live patched.
15) ``K`` if the kernel has been live patched.
The primary reason for the **'Tainted: '** string is to tell kernel
debuggers if this is a clean kernel or if anything unusual has
occurred. Tainting is permanent: even if an offending module is
unloaded, the tainted value remains to indicate that the kernel is not
trustworthy.
16) ``X`` Auxiliary taint, defined for and used by Linux distributors.
17) ``T`` Kernel was build with the randstruct plugin, which can intentionally
produce extremely unusual kernel structure layouts (even performance
pathological ones), which is important to know when debugging. Set at
build time.

4
Documentation/arm/kernel_mode_neon.txt
View File

@ -6,7 +6,7 @@ TL;DR summary
* Use only NEON instructions, or VFP instructions that don't rely on support
code
* Isolate your NEON code in a separate compilation unit, and compile it with
'-mfpu=neon -mfloat-abi=softfp'
'-march=armv7-a -mfpu=neon -mfloat-abi=softfp'
* Put kernel_neon_begin() and kernel_neon_end() calls around the calls into your
NEON code
* Don't sleep in your NEON code, and be aware that it will be executed with
@ -87,7 +87,7 @@ instructions appearing in unexpected places if no special care is taken.
Therefore, the recommended and only supported way of using NEON/VFP in the
kernel is by adhering to the following rules:
* isolate the NEON code in a separate compilation unit and compile it with
'-mfpu=neon -mfloat-abi=softfp';
'-march=armv7-a -mfpu=neon -mfloat-abi=softfp';
* issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the calls
into the unit containing the NEON code from a compilation unit which is *not*
built with the GCC flag '-mfpu=neon' set.

5
Documentation/arm64/booting.txt
View File

@ -188,6 +188,11 @@ Before jumping into the kernel, the following conditions must be met:
the kernel image will be entered must be initialised by software at a
higher exception level to prevent execution in an UNKNOWN state.
- SCR_EL3.FIQ must have the same value across all CPUs the kernel is
executing on.
- The value of SCR_EL3.FIQ must be the same as the one present at boot
time whenever the kernel is executing.
For systems with a GICv3 interrupt controller to be used in v3 mode:
- If EL3 is present:
ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.

5
Documentation/arm64/pointer-authentication.txt
View File

@ -78,6 +78,11 @@ bits can vary between the two. Note that the masks apply to TTBR0
addresses, and are not valid to apply to TTBR1 addresses (e.g. kernel
pointers).
Additionally, when CONFIG_CHECKPOINT_RESTORE is also set, the kernel
will expose the NT_ARM_PACA_KEYS and NT_ARM_PACG_KEYS regsets (struct
user_pac_address_keys and struct user_pac_generic_keys). These can be
used to get and set the keys for a thread.
Virtualization
--------------

1
Documentation/arm64/silicon-errata.txt
View File

@ -82,3 +82,4 @@ stable kernels.
| Qualcomm Tech. | Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
| Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 |
| Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 |
| Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 |

25
Documentation/block/biovecs.txt
View File

@ -117,3 +117,28 @@ Other implications:
size limitations and the limitations of the underlying devices. Thus
there's no need to define ->merge_bvec_fn() callbacks for individual block
drivers.
Usage of helpers:
=================
* The following helpers whose names have the suffix of "_all" can only be used
on non-BIO_CLONED bio. They are usually used by filesystem code. Drivers
shouldn't use them because the bio may have been split before it reached the
driver.
bio_for_each_segment_all()
bio_first_bvec_all()
bio_first_page_all()
bio_last_bvec_all()
* The following helpers iterate over single-page segment. The passed 'struct
bio_vec' will contain a single-page IO vector during the iteration
bio_for_each_segment()
bio_for_each_segment_all()
* The following helpers iterate over multi-page bvec. The passed 'struct
bio_vec' will contain a multi-page IO vector during the iteration
bio_for_each_bvec()
rq_for_each_bvec()

7
Documentation/cgroup-v1/memory.txt
View File

@ -70,7 +70,7 @@ Brief summary of control files.
memory.soft_limit_in_bytes # set/show soft limit of memory usage
memory.stat # show various statistics
memory.use_hierarchy # set/show hierarchical account enabled
memory.force_empty # trigger forced move charge to parent
memory.force_empty # trigger forced page reclaim
memory.pressure_level # set memory pressure notifications
memory.swappiness # set/show swappiness parameter of vmscan
(See sysctl's vm.swappiness)
@ -459,8 +459,9 @@ About use_hierarchy, see Section 6.
the cgroup will be reclaimed and as many pages reclaimed as possible.
The typical use case for this interface is before calling rmdir().
Because rmdir() moves all pages to parent, some out-of-use page caches can be
moved to the parent. If you want to avoid that, force_empty will be useful.
Though rmdir() offlines memcg, but the memcg may still stay there due to
charged file caches. Some out-of-use page caches may keep charged until
memory pressure happens. If you want to avoid that, force_empty will be useful.
Also, note that when memory.kmem.limit_in_bytes is set the charges due to
kernel pages will still be seen. This is not considered a failure and the

130
Documentation/core-api/flexible-arrays.rst
View File

@ -1,130 +0,0 @@
===================================
Using flexible arrays in the kernel
===================================
Large contiguous memory allocations can be unreliable in the Linux kernel.
Kernel programmers will sometimes respond to this problem by allocating
pages with :c:func:`vmalloc()`. This solution not ideal, though. On 32-bit
systems, memory from vmalloc() must be mapped into a relatively small address
space; it's easy to run out. On SMP systems, the page table changes required
by vmalloc() allocations can require expensive cross-processor interrupts on
all CPUs. And, on all systems, use of space in the vmalloc() range increases
pressure on the translation lookaside buffer (TLB), reducing the performance
of the system.
In many cases, the need for memory from vmalloc() can be eliminated by piecing
together an array from smaller parts; the flexible array library exists to make
this task easier.
A flexible array holds an arbitrary (within limits) number of fixed-sized
objects, accessed via an integer index. Sparse arrays are handled
reasonably well. Only single-page allocations are made, so memory
allocation failures should be relatively rare. The down sides are that the
arrays cannot be indexed directly, individual object size cannot exceed the
system page size, and putting data into a flexible array requires a copy
operation. It's also worth noting that flexible arrays do no internal
locking at all; if concurrent access to an array is possible, then the
caller must arrange for appropriate mutual exclusion.
The creation of a flexible array is done with :c:func:`flex_array_alloc()`::
#include <linux/flex_array.h>
struct flex_array *flex_array_alloc(int element_size,
unsigned int total,
gfp_t flags);
The individual object size is provided by ``element_size``, while total is the
maximum number of objects which can be stored in the array. The flags
argument is passed directly to the internal memory allocation calls. With
the current code, using flags to ask for high memory is likely to lead to
notably unpleasant side effects.
It is also possible to define flexible arrays at compile time with::
DEFINE_FLEX_ARRAY(name, element_size, total);
This macro will result in a definition of an array with the given name; the
element size and total will be checked for validity at compile time.
Storing data into a flexible array is accomplished with a call to
:c:func:`flex_array_put()`::
int flex_array_put(struct flex_array *array, unsigned int element_nr,
void *src, gfp_t flags);
This call will copy the data from src into the array, in the position
indicated by ``element_nr`` (which must be less than the maximum specified when
the array was created). If any memory allocations must be performed, flags
will be used. The return value is zero on success, a negative error code
otherwise.
There might possibly be a need to store data into a flexible array while
running in some sort of atomic context; in this situation, sleeping in the
memory allocator would be a bad thing. That can be avoided by using
``GFP_ATOMIC`` for the flags value, but, often, there is a better way. The
trick is to ensure that any needed memory allocations are done before
entering atomic context, using :c:func:`flex_array_prealloc()`::
int flex_array_prealloc(struct flex_array *array, unsigned int start,
unsigned int nr_elements, gfp_t flags);
This function will ensure that memory for the elements indexed in the range
defined by ``start`` and ``nr_elements`` has been allocated. Thereafter, a
``flex_array_put()`` call on an element in that range is guaranteed not to
block.
Getting data back out of the array is done with :c:func:`flex_array_get()`::
void *flex_array_get(struct flex_array *fa, unsigned int element_nr);
The return value is a pointer to the data element, or NULL if that
particular element has never been allocated.
Note that it is possible to get back a valid pointer for an element which
has never been stored in the array. Memory for array elements is allocated
one page at a time; a single allocation could provide memory for several
adjacent elements. Flexible array elements are normally initialized to the
value ``FLEX_ARRAY_FREE`` (defined as 0x6c in <linux/poison.h>), so errors
involving that number probably result from use of unstored array entries.
Note that, if array elements are allocated with ``__GFP_ZERO``, they will be
initialized to zero and this poisoning will not happen.
Individual elements in the array can be cleared with
:c:func:`flex_array_clear()`::
int flex_array_clear(struct flex_array *array, unsigned int element_nr);
This function will set the given element to ``FLEX_ARRAY_FREE`` and return
zero. If storage for the indicated element is not allocated for the array,
``flex_array_clear()`` will return ``-EINVAL`` instead. Note that clearing an
element does not release the storage associated with it; to reduce the
allocated size of an array, call :c:func:`flex_array_shrink()`::
int flex_array_shrink(struct flex_array *array);
The return value will be the number of pages of memory actually freed.
This function works by scanning the array for pages containing nothing but
``FLEX_ARRAY_FREE`` bytes, so (1) it can be expensive, and (2) it will not work
if the array's pages are allocated with ``__GFP_ZERO``.
It is possible to remove all elements of an array with a call to
:c:func:`flex_array_free_parts()`::
void flex_array_free_parts(struct flex_array *array);
This call frees all elements, but leaves the array itself in place.
Freeing the entire array is done with :c:func:`flex_array_free()`::
void flex_array_free(struct flex_array *array);
As of this writing, there are no users of flexible arrays in the mainline
kernel. The functions described here are also not exported to modules;
that will probably be fixed when somebody comes up with a need for it.
Flexible array functions
------------------------
.. kernel-doc:: include/linux/flex_array.h

12
Documentation/core-api/generic-radix-tree.rst 100644
View File

@ -0,0 +1,12 @@
=================================
Generic radix trees/sparse arrays
=================================
.. kernel-doc:: include/linux/generic-radix-tree.h
:doc: Generic radix trees/sparse arrays
generic radix tree functions
----------------------------
.. kernel-doc:: include/linux/generic-radix-tree.h
:functions:

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

@ -28,6 +28,7 @@ Core utilities
errseq
printk-formats
circular-buffers
generic-radix-tree
memory-allocation
mm-api
gfp_mask-from-fs-io

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

@ -356,10 +356,6 @@ Read-Copy Update (RCU)
.. kernel-doc:: include/linux/rcupdate.h
.. kernel-doc:: include/linux/rcupdate_wait.h
.. kernel-doc:: include/linux/rcutree.h
.. kernel-doc:: kernel/rcu/tree.c
.. kernel-doc:: kernel/rcu/tree_plugin.h

10
Documentation/core-api/memory-allocation.rst
View File

@ -1,4 +1,4 @@
.. _memory-allocation:
.. _memory_allocation:
=======================
Memory Allocation Guide
@ -113,9 +113,11 @@ see :c:func:`kvmalloc_node` reference documentation. Note that
If you need to allocate many identical objects you can use the slab
cache allocator. The cache should be set up with
:c:func:`kmem_cache_create` before it can be used. Afterwards
:c:func:`kmem_cache_alloc` and its convenience wrappers can allocate
memory from that cache.
:c:func:`kmem_cache_create` or :c:func:`kmem_cache_create_usercopy`
before it can be used. The second function should be used if a part of
the cache might be copied to the userspace. After the cache is
created :c:func:`kmem_cache_alloc` and its convenience wrappers can
allocate memory from that cache.
When the allocated memory is no longer needed it must be freed. You
can use :c:func:`kvfree` for the memory allocated with `kmalloc`,

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

@ -35,7 +35,7 @@ users will want to use a plain ``GFP_KERNEL``.
:doc: Reclaim modifiers
.. kernel-doc:: include/linux/gfp.h
:doc: Common combinations
:doc: Useful GFP flag combinations
The Slab Cache
==============

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

@ -13,6 +13,10 @@ Integer types
If variable is of Type, use printk format specifier:
------------------------------------------------------------
char %hhd or %hhx
unsigned char %hhu or %hhx
short int %hd or %hx
unsigned short int %hu or %hx
int %d or %x
unsigned int %u or %x
long %ld or %lx
@ -21,6 +25,10 @@ Integer types
unsigned long long %llu or %llx
size_t %zu or %zx
ssize_t %zd or %zx
s8 %hhd or %hhx
u8 %hhu or %hhx
s16 %hd or %hx
u16 %hu or %hx
s32 %d or %x
u32 %u or %x
s64 %lld or %llx

15
Documentation/core-api/xarray.rst
View File

@ -85,7 +85,7 @@ which was at that index; if it returns the same entry which was passed as
If you want to only store a new entry to an index if the current entry
at that index is ``NULL``, you can use :c:func:`xa_insert` which
returns ``-EEXIST`` if the entry is not empty.
returns ``-EBUSY`` if the entry is not empty.
You can enquire whether a mark is set on an entry by using
:c:func:`xa_get_mark`. If the entry is not ``NULL``, you can set a mark
@ -131,17 +131,23 @@ If you use :c:func:`DEFINE_XARRAY_ALLOC` to define the XArray, or
initialise it by passing ``XA_FLAGS_ALLOC`` to :c:func:`xa_init_flags`,
the XArray changes to track whether entries are in use or not.
You can call :c:func:`xa_alloc` to store the entry at any unused index
You can call :c:func:`xa_alloc` to store the entry at an unused index
in the XArray. If you need to modify the array from interrupt context,
you can use :c:func:`xa_alloc_bh` or :c:func:`xa_alloc_irq` to disable
interrupts while allocating the ID.
Using :c:func:`xa_store`, :c:func:`xa_cmpxchg` or :c:func:`xa_insert`
will mark the entry as being allocated. Unlike a normal XArray, storing
Using :c:func:`xa_store`, :c:func:`xa_cmpxchg` or :c:func:`xa_insert` will
also mark the entry as being allocated. Unlike a normal XArray, storing
``NULL`` will mark the entry as being in use, like :c:func:`xa_reserve`.
To free an entry, use :c:func:`xa_erase` (or :c:func:`xa_release` if
you only want to free the entry if it's ``NULL``).
By default, the lowest free entry is allocated starting from 0. If you
want to allocate entries starting at 1, it is more efficient to use
:c:func:`DEFINE_XARRAY_ALLOC1` or ``XA_FLAGS_ALLOC1``. If you want to
allocate IDs up to a maximum, then wrap back around to the lowest free
ID, you can use :c:func:`xa_alloc_cyclic`.
You cannot use ``XA_MARK_0`` with an allocating XArray as this mark
is used to track whether an entry is free or not. The other marks are
available for your use.
@ -209,7 +215,6 @@ Assumes xa_lock held on entry:
* :c:func:`__xa_erase`
* :c:func:`__xa_cmpxchg`
* :c:func:`__xa_alloc`
* :c:func:`__xa_reserve`
* :c:func:`__xa_set_mark`
* :c:func:`__xa_clear_mark`

2
Documentation/dev-tools/kcov.rst
View File

@ -22,7 +22,7 @@ Configure the kernel with::
CONFIG_KCOV=y
CONFIG_KCOV requires gcc built on revision 231296 or later.
CONFIG_KCOV requires gcc 6.1.0 or later.
If the comparison operands need to be collected, set::

3
Documentation/device-mapper/cache.txt
View File

@ -206,6 +206,9 @@ Optional feature arguments are:
in a separate btree, which improves speed of shutting
down the cache.
no_discard_passdown : disable passing down discards from the cache
to the origin's data device.
A policy called 'default' is always registered. This is an alias for
the policy we currently think is giving best all round performance.

114
Documentation/device-mapper/dm-init.txt 100644
View File

@ -0,0 +1,114 @@
Early creation of mapped devices
====================================
It is possible to configure a device-mapper device to act as the root device for
your system in two ways.
The first is to build an initial ramdisk which boots to a minimal userspace
which configures the device, then pivot_root(8) in to it.
The second is to create one or more device-mappers using the module parameter
"dm-mod.create=" through the kernel boot command line argument.
The format is specified as a string of data separated by commas and optionally
semi-colons, where:
- a comma is used to separate fields like name, uuid, flags and table
(specifies one device)
- a semi-colon is used to separate devices.
So the format will look like this:
dm-mod.create=<name>,<uuid>,<minor>,<flags>,<table>[,<table>+][;<name>,<uuid>,<minor>,<flags>,<table>[,<table>+]+]
Where,
<name> ::= The device name.
<uuid> ::= xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | ""
<minor> ::= The device minor number | ""
<flags> ::= "ro" | "rw"
<table> ::= <start_sector> <num_sectors> <target_type> <target_args>
<target_type> ::= "verity" | "linear" | ... (see list below)
The dm line should be equivalent to the one used by the dmsetup tool with the
--concise argument.
Target types
============
Not all target types are available as there are serious risks in allowing
activation of certain DM targets without first using userspace tools to check
the validity of associated metadata.
"cache": constrained, userspace should verify cache device
"crypt": allowed
"delay": allowed
"era": constrained, userspace should verify metadata device
"flakey": constrained, meant for test
"linear": allowed
"log-writes": constrained, userspace should verify metadata device
"mirror": constrained, userspace should verify main/mirror device
"raid": constrained, userspace should verify metadata device
"snapshot": constrained, userspace should verify src/dst device
"snapshot-origin": allowed
"snapshot-merge": constrained, userspace should verify src/dst device
"striped": allowed
"switch": constrained, userspace should verify dev path
"thin": constrained, requires dm target message from userspace
"thin-pool": constrained, requires dm target message from userspace
"verity": allowed
"writecache": constrained, userspace should verify cache device
"zero": constrained, not meant for rootfs
If the target is not listed above, it is constrained by default (not tested).
Examples
========
An example of booting to a linear array made up of user-mode linux block
devices:
dm-mod.create="lroot,,,rw, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" root=/dev/dm-0
This will boot to a rw dm-linear target of 8192 sectors split across two block
devices identified by their major:minor numbers. After boot, udev will rename
this target to /dev/mapper/lroot (depending on the rules). No uuid was assigned.
An example of multiple device-mappers, with the dm-mod.create="..." contents is shown here
split on multiple lines for readability:
vroot,,,ro,
0 1740800 verity 254:0 254:0 1740800 sha1
76e9be054b15884a9fa85973e9cb274c93afadb6
5b3549d54d6c7a3837b9b81ed72e49463a64c03680c47835bef94d768e5646fe;
vram,,,rw,
0 32768 linear 1:0 0,
32768 32768 linear 1:1 0
Other examples (per target):
"crypt":
dm-crypt,,8,ro,
0 1048576 crypt aes-xts-plain64
babebabebabebabebabebabebabebabebabebabebabebabebabebabebabebabe 0
/dev/sda 0 1 allow_discards
"delay":
dm-delay,,4,ro,0 409600 delay /dev/sda1 0 500
"linear":
dm-linear,,,rw,
0 32768 linear /dev/sda1 0,
32768 1024000 linear /dev/sda2 0,
1056768 204800 linear /dev/sda3 0,
1261568 512000 linear /dev/sda4 0
"snapshot-origin":
dm-snap-orig,,4,ro,0 409600 snapshot-origin 8:2
"striped":
dm-striped,,4,ro,0 1638400 striped 4 4096
/dev/sda1 0 /dev/sda2 0 /dev/sda3 0 /dev/sda4 0
"verity":
dm-verity,,4,ro,
0 1638400 verity 1 8:1 8:2 4096 4096 204800 1 sha256
fb1a5a0f00deb908d8b53cb270858975e76cf64105d412ce764225d53b8f3cfd
51934789604d1b92399c52e7cb149d1b3a1b74bbbcb103b2a0aaacbed5c08584

2
Documentation/devicetree/bindings/Makefile
View File

@ -15,7 +15,7 @@ DT_TMP_SCHEMA := processed-schema.yaml
extra-y += $(DT_TMP_SCHEMA)
quiet_cmd_mk_schema = SCHEMA $@
cmd_mk_schema = $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $(filter-out FORCE, $^)
cmd_mk_schema = $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $(real-prereqs)
DT_DOCS = $(shell \
cd $(srctree)/$(src) && \

3
Documentation/devicetree/bindings/arm/atmel-sysregs.txt
View File

@ -21,7 +21,8 @@ Its subnodes can be:
RSTC Reset Controller required properties:
- compatible: Should be "atmel,<chip>-rstc".
<chip> can be "at91sam9260" or "at91sam9g45" or "sama5d3"
<chip> can be "at91sam9260", "at91sam9g45", "sama5d3" or "samx7"
it also can be "microchip,sam9x60-rstc"
- reg: Should contain registers location and length
- clocks: phandle to input clock.

114
Documentation/devicetree/bindings/arm/l2c2x0.txt
View File

@ -1,114 +0,0 @@
* ARM L2 Cache Controller
ARM cores often have a separate L2C210/L2C220/L2C310 (also known as PL210/PL220/
PL310 and variants) based level 2 cache controller. All these various implementations
of the L2 cache controller have compatible programming models (Note 1).
Some of the properties that are just prefixed "cache-*" are taken from section
3.7.3 of the Devicetree Specification which can be found at:
https://www.devicetree.org/specifications/
The ARM L2 cache representation in the device tree should be done as follows:
Required properties:
- compatible : should be one of:
"arm,pl310-cache"
"arm,l220-cache"
"arm,l210-cache"
"bcm,bcm11351-a2-pl310-cache": DEPRECATED by "brcm,bcm11351-a2-pl310-cache"
"brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
offset needs to be added to the address before passing down to the L2
cache controller
"marvell,aurora-system-cache": Marvell Controller designed to be
compatible with the ARM one, with system cache mode (meaning
maintenance operations on L1 are broadcasted to the L2 and L2
performs the same operation).
"marvell,aurora-outer-cache": Marvell Controller designed to be
compatible with the ARM one with outer cache mode.
"marvell,tauros3-cache": Marvell Tauros3 cache controller, compatible
with arm,pl310-cache controller.
- cache-unified : Specifies the cache is a unified cache.
- cache-level : Should be set to 2 for a level 2 cache.
- reg : Physical base address and size of cache controller's memory mapped
registers.
Optional properties:
- arm,data-latency : Cycles of latency for Data RAM accesses. Specifies 3 cells of
read, write and setup latencies. Minimum valid values are 1. Controllers
without setup latency control should use a value of 0.
- arm,tag-latency : Cycles of latency for Tag RAM accesses. Specifies 3 cells of
read, write and setup latencies. Controllers without setup latency control
should use 0. Controllers without separate read and write Tag RAM latency
values should only use the first cell.
- arm,dirty-latency : Cycles of latency for Dirty RAMs. This is a single cell.
- arm,filter-ranges : <start length> Starting address and length of window to
filter. Addresses in the filter window are directed to the M1 port. Other
addresses will go to the M0 port.
- arm,io-coherent : indicates that the system is operating in an hardware
I/O coherent mode. Valid only when the arm,pl310-cache compatible
string is used.
- interrupts : 1 combined interrupt.
- cache-size : specifies the size in bytes of the cache
- cache-sets : specifies the number of associativity sets of the cache
- cache-block-size : specifies the size in bytes of a cache block
- cache-line-size : specifies the size in bytes of a line in the cache,
if this is not specified, the line size is assumed to be equal to the
cache block size
- cache-id-part: cache id part number to be used if it is not present
on hardware
- wt-override: If present then L2 is forced to Write through mode
- arm,double-linefill : Override double linefill enable setting. Enable if
non-zero, disable if zero.
- arm,double-linefill-incr : Override double linefill on INCR read. Enable
if non-zero, disable if zero.
- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
if non-zero, disable if zero.
- arm,prefetch-drop : Override prefetch drop enable setting. Enable if non-zero,
disable if zero.
- arm,prefetch-offset : Override prefetch offset value. Valid values are
0-7, 15, 23, and 31.
- arm,shared-override : The default behavior of the L220 or PL310 cache
controllers with respect to the shareable attribute is to transform "normal
memory non-cacheable transactions" into "cacheable no allocate" (for reads)
or "write through no write allocate" (for writes).
On systems where this may cause DMA buffer corruption, this property must be
specified to indicate that such transforms are precluded.
- arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310).
- arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310).
- arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
will randomly hang unless outer sync operations are disabled.
- prefetch-data : Data prefetch. Value: <0> (forcibly disable), <1>
(forcibly enable), property absent (retain settings set by firmware)
- prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable),
<1> (forcibly enable), property absent (retain settings set by
firmware)
- arm,dynamic-clock-gating : L2 dynamic clock gating. Value: <0> (forcibly
disable), <1> (forcibly enable), property absent (OS specific behavior,
preferably retain firmware settings)
- arm,standby-mode: L2 standby mode enable. Value <0> (forcibly disable),
<1> (forcibly enable), property absent (OS specific behavior,
preferably retain firmware settings)
- arm,early-bresp-disable : Disable the CA9 optimization Early BRESP (PL310)
- arm,full-line-zero-disable : Disable the CA9 optimization Full line of zero
write (PL310)
Example:
L2: cache-controller {
compatible = "arm,pl310-cache";
reg = <0xfff12000 0x1000>;
arm,data-latency = <1 1 1>;
arm,tag-latency = <2 2 2>;
arm,filter-ranges = <0x80000000 0x8000000>;
cache-unified;
cache-level = <2>;
interrupts = <45>;
};
Note 1: The description in this document doesn't apply to integrated L2
cache controllers as found in e.g. Cortex-A15/A7/A57/A53. These
integrated L2 controllers are assumed to be all preconfigured by
early secure boot code. Thus no need to deal with their configuration
in the kernel at all.

248
Documentation/devicetree/bindings/arm/l2c2x0.yaml 100644
View File

@ -0,0 +1,248 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/l2c2x0.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM L2 Cache Controller
maintainers:
- Rob Herring <robh@kernel.org>
description: |+
ARM cores often have a separate L2C210/L2C220/L2C310 (also known as PL210/
PL220/PL310 and variants) based level 2 cache controller. All these various
implementations of the L2 cache controller have compatible programming
models (Note 1). Some of the properties that are just prefixed "cache-*" are
taken from section 3.7.3 of the Devicetree Specification which can be found
at:
https://www.devicetree.org/specifications/
Note 1: The description in this document doesn't apply to integrated L2
cache controllers as found in e.g. Cortex-A15/A7/A57/A53. These
integrated L2 controllers are assumed to be all preconfigured by
early secure boot code. Thus no need to deal with their configuration
in the kernel at all.
allOf:
- $ref: /schemas/cache-controller.yaml#
properties:
compatible:
enum:
- arm,pl310-cache
- arm,l220-cache
- arm,l210-cache
# DEPRECATED by "brcm,bcm11351-a2-pl310-cache"
- bcm,bcm11351-a2-pl310-cache
# For Broadcom bcm11351 chipset where an
# offset needs to be added to the address before passing down to the L2
# cache controller
- brcm,bcm11351-a2-pl310-cache
# Marvell Controller designed to be
# compatible with the ARM one, with system cache mode (meaning
# maintenance operations on L1 are broadcasted to the L2 and L2
# performs the same operation).
- marvell,aurora-system-cache
# Marvell Controller designed to be
# compatible with the ARM one with outer cache mode.
- marvell,aurora-outer-cache
# Marvell Tauros3 cache controller, compatible
# with arm,pl310-cache controller.
- marvell,tauros3-cache
cache-level:
const: 2
cache-unified: true
cache-size: true
cache-sets: true
cache-block-size: true
cache-line-size: true
reg:
maxItems: 1
arm,data-latency:
description: Cycles of latency for Data RAM accesses. Specifies 3 cells of
read, write and setup latencies. Minimum valid values are 1. Controllers
without setup latency control should use a value of 0.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- minItems: 2
maxItems: 3
items:
minimum: 0
maximum: 8
arm,tag-latency:
description: Cycles of latency for Tag RAM accesses. Specifies 3 cells of
read, write and setup latencies. Controllers without setup latency control
should use 0. Controllers without separate read and write Tag RAM latency
values should only use the first cell.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- minItems: 1
maxItems: 3
items:
minimum: 0
maximum: 8
arm,dirty-latency:
description: Cycles of latency for Dirty RAMs. This is a single cell.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 1
maximum: 8
arm,filter-ranges:
description: <start length> Starting address and length of window to
filter. Addresses in the filter window are directed to the M1 port. Other
addresses will go to the M0 port.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- items:
minItems: 2
maxItems: 2
arm,io-coherent:
description: indicates that the system is operating in an hardware
I/O coherent mode. Valid only when the arm,pl310-cache compatible
string is used.
type: boolean
interrupts:
# Either a single combined interrupt or up to 9 individual interrupts
minItems: 1
maxItems: 9
cache-id-part:
description: cache id part number to be used if it is not present
on hardware
$ref: /schemas/types.yaml#/definitions/uint32
wt-override:
description: If present then L2 is forced to Write through mode
type: boolean
arm,double-linefill:
description: Override double linefill enable setting. Enable if
non-zero, disable if zero.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 0, 1 ]
arm,double-linefill-incr:
description: Override double linefill on INCR read. Enable
if non-zero, disable if zero.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 0, 1 ]
arm,double-linefill-wrap:
description: Override double linefill on WRAP read. Enable
if non-zero, disable if zero.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 0, 1 ]
arm,prefetch-drop:
description: Override prefetch drop enable setting. Enable if non-zero,
disable if zero.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 0, 1 ]
arm,prefetch-offset:
description: Override prefetch offset value.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 0, 1, 2, 3, 4, 5, 6, 7, 15, 23, 31 ]
arm,shared-override:
description: The default behavior of the L220 or PL310 cache
controllers with respect to the shareable attribute is to transform "normal
memory non-cacheable transactions" into "cacheable no allocate" (for reads)
or "write through no write allocate" (for writes).
On systems where this may cause DMA buffer corruption, this property must
be specified to indicate that such transforms are precluded.
type: boolean
arm,parity-enable:
description: enable parity checking on the L2 cache (L220 or PL310).
type: boolean
arm,parity-disable:
description: disable parity checking on the L2 cache (L220 or PL310).
type: boolean
arm,outer-sync-disable:
description: disable the outer sync operation on the L2 cache.
Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
will randomly hang unless outer sync operations are disabled.
type: boolean
prefetch-data:
description: |
Data prefetch. Value: <0> (forcibly disable), <1>
(forcibly enable), property absent (retain settings set by firmware)
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 0, 1 ]
prefetch-instr:
description: |
Instruction prefetch. Value: <0> (forcibly disable),
<1> (forcibly enable), property absent (retain settings set by
firmware)
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 0, 1 ]
arm,dynamic-clock-gating:
description: |
L2 dynamic clock gating. Value: <0> (forcibly
disable), <1> (forcibly enable), property absent (OS specific behavior,
preferably retain firmware settings)
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 0, 1 ]
arm,standby-mode:
description: L2 standby mode enable. Value <0> (forcibly disable),
<1> (forcibly enable), property absent (OS specific behavior,
preferably retain firmware settings)
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 0, 1 ]
arm,early-bresp-disable:
description: Disable the CA9 optimization Early BRESP (PL310)
type: boolean
arm,full-line-zero-disable:
description: Disable the CA9 optimization Full line of zero
write (PL310)
type: boolean
required:
- compatible
- cache-unified
- reg
additionalProperties: false
examples:
- |
cache-controller@fff12000 {
compatible = "arm,pl310-cache";
reg = <0xfff12000 0x1000>;
arm,data-latency = <1 1 1>;
arm,tag-latency = <2 2 2>;
arm,filter-ranges = <0x80000000 0x8000000>;
cache-unified;
cache-level = <2>;
interrupts = <45>;
};
...

70
Documentation/devicetree/bindings/arm/pmu.txt
View File

@ -1,70 +0,0 @@
* ARM Performance Monitor Units
ARM cores often have a PMU for counting cpu and cache events like cache misses
and hits. The interface to the PMU is part of the ARM ARM. The ARM PMU
representation in the device tree should be done as under:-
Required properties:
- compatible : should be one of
"apm,potenza-pmu"
"arm,armv8-pmuv3"
"arm,cortex-a73-pmu"
"arm,cortex-a72-pmu"
"arm,cortex-a57-pmu"
"arm,cortex-a53-pmu"
"arm,cortex-a35-pmu"
"arm,cortex-a17-pmu"
"arm,cortex-a15-pmu"
"arm,cortex-a12-pmu"
"arm,cortex-a9-pmu"
"arm,cortex-a8-pmu"
"arm,cortex-a7-pmu"
"arm,cortex-a5-pmu"
"arm,arm11mpcore-pmu"
"arm,arm1176-pmu"
"arm,arm1136-pmu"
"brcm,vulcan-pmu"
"cavium,thunder-pmu"
"qcom,scorpion-pmu"
"qcom,scorpion-mp-pmu"
"qcom,krait-pmu"
- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu
interrupt (PPI) then 1 interrupt should be specified.
Optional properties:
- interrupt-affinity : When using SPIs, specifies a list of phandles to CPU
nodes corresponding directly to the affinity of
the SPIs listed in the interrupts property.
When using a PPI, specifies a list of phandles to CPU
nodes corresponding to the set of CPUs which have
a PMU of this type signalling the PPI listed in the
interrupts property, unless this is already specified
by the PPI interrupt specifier itself (in which case
the interrupt-affinity property shouldn't be present).
This property should be present when there is more than
a single SPI.
- qcom,no-pc-write : Indicates that this PMU doesn't support the 0xc and 0xd
events.
- secure-reg-access : Indicates that the ARMv7 Secure Debug Enable Register
(SDER) is accessible. This will cause the driver to do
any setup required that is only possible in ARMv7 secure
state. If not present the ARMv7 SDER will not be touched,
which means the PMU may fail to operate unless external
code (bootloader or security monitor) has performed the
appropriate initialisation. Note that this property is
not valid for non-ARMv7 CPUs or ARMv7 CPUs booting Linux
in Non-secure state.
Example:
pmu {
compatible = "arm,cortex-a9-pmu";
interrupts = <100 101>;
};

87
Documentation/devicetree/bindings/arm/pmu.yaml 100644
View File

@ -0,0 +1,87 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/pmu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Performance Monitor Units
maintainers:
- Mark Rutland <mark.rutland@arm.com>
- Will Deacon <will.deacon@arm.com>
description: |+
ARM cores often have a PMU for counting cpu and cache events like cache misses
and hits. The interface to the PMU is part of the ARM ARM. The ARM PMU
representation in the device tree should be done as under:-
properties:
compatible:
items:
- enum:
- apm,potenza-pmu
- arm,armv8-pmuv3
- arm,cortex-a73-pmu
- arm,cortex-a72-pmu
- arm,cortex-a57-pmu
- arm,cortex-a53-pmu
- arm,cortex-a35-pmu
- arm,cortex-a17-pmu
- arm,cortex-a15-pmu
- arm,cortex-a12-pmu
- arm,cortex-a9-pmu
- arm,cortex-a8-pmu
- arm,cortex-a7-pmu
- arm,cortex-a5-pmu
- arm,arm11mpcore-pmu
- arm,arm1176-pmu
- arm,arm1136-pmu
- brcm,vulcan-pmu
- cavium,thunder-pmu
- qcom,scorpion-pmu
- qcom,scorpion-mp-pmu
- qcom,krait-pmu
interrupts:
# Don't know how many CPUs, so no constraints to specify
description: 1 per-cpu interrupt (PPI) or 1 interrupt per core.
interrupt-affinity:
$ref: /schemas/types.yaml#/definitions/phandle-array
description:
When using SPIs, specifies a list of phandles to CPU
nodes corresponding directly to the affinity of
the SPIs listed in the interrupts property.
When using a PPI, specifies a list of phandles to CPU
nodes corresponding to the set of CPUs which have
a PMU of this type signalling the PPI listed in the
interrupts property, unless this is already specified
by the PPI interrupt specifier itself (in which case
the interrupt-affinity property shouldn't be present).
This property should be present when there is more than
a single SPI.
qcom,no-pc-write:
type: boolean
description:
Indicates that this PMU doesn't support the 0xc and 0xd events.
secure-reg-access:
type: boolean
description:
Indicates that the ARMv7 Secure Debug Enable Register
(SDER) is accessible. This will cause the driver to do
any setup required that is only possible in ARMv7 secure
state. If not present the ARMv7 SDER will not be touched,
which means the PMU may fail to operate unless external
code (bootloader or security monitor) has performed the
appropriate initialisation. Note that this property is
not valid for non-ARMv7 CPUs or ARMv7 CPUs booting Linux
in Non-secure state.
required:
- compatible
...

7
Documentation/devicetree/bindings/clock/actions,owl-cmu.txt
View File

@ -2,13 +2,14 @@
The Actions Semi Owl Clock Management Unit generates and supplies clock
to various controllers within the SoC. The clock binding described here is
applicable to S900 and S700 SoC's.
applicable to S900, S700 and S500 SoC's.
Required Properties:
- compatible: should be one of the following,
"actions,s900-cmu"
"actions,s700-cmu"
"actions,s500-cmu"
- reg: physical base address of the controller and length of memory mapped
region.
- clocks: Reference to the parent clocks ("hosc", "losc")
@ -19,8 +20,8 @@ Each clock is assigned an identifier, and client nodes can use this identifier
to specify the clock which they consume.
All available clocks are defined as preprocessor macros in corresponding
dt-bindings/clock/actions,s900-cmu.h or actions,s700-cmu.h header and can be
used in device tree sources.
dt-bindings/clock/actions,s900-cmu.h or actions,s700-cmu.h or
actions,s500-cmu.h header and can be used in device tree sources.
External clocks:

1
Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt
View File

@ -10,6 +10,7 @@ Required Properties:
- GXL (S905X, S905D) : "amlogic,meson-gxl-aoclkc"
- GXM (S912) : "amlogic,meson-gxm-aoclkc"
- AXG (A113D, A113X) : "amlogic,meson-axg-aoclkc"
- G12A (S905X2, S905D2, S905Y2) : "amlogic,meson-g12a-aoclkc"
followed by the common "amlogic,meson-gx-aoclkc"
- clocks: list of clock phandle, one for each entry clock-names.
- clock-names: should contain the following:

1
Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt
View File

@ -9,6 +9,7 @@ Required Properties:
"amlogic,gxbb-clkc" for GXBB SoC,
"amlogic,gxl-clkc" for GXL and GXM SoC,
"amlogic,axg-clkc" for AXG SoC.
"amlogic,g12a-clkc" for G12A SoC.
- clocks : list of clock phandle, one for each entry clock-names.
- clock-names : should contain the following:
* "xtal": the platform xtal

23
Documentation/devicetree/bindings/clock/exynos5433-clock.txt
View File

@ -50,6 +50,8 @@ Required Properties:
IPs.
- "samsung,exynos5433-cmu-cam1" - clock controller compatible for CMU_CAM1
which generates clocks for Cortex-A5/MIPI_CSIS2/FIMC-LITE_C/FIMC-FD IPs.
- "samsung,exynos5433-cmu-imem" - clock controller compatible for CMU_IMEM
which generates clocks for SSS (Security SubSystem) and SlimSSS IPs.
- reg: physical base address of the controller and length of memory mapped
region.
@ -168,6 +170,12 @@ Required Properties:
- aclk_cam1_400
- aclk_cam1_552
Input clocks for imem clock controller:
- oscclk
- aclk_imem_sssx_266
- aclk_imem_266
- aclk_imem_200
Optional properties:
- power-domains: a phandle to respective power domain node as described by
generic PM domain bindings (see power/power_domain.txt for more
@ -469,6 +477,21 @@ Example 2: Examples of clock controller nodes are listed below.
power-domains = <&pd_cam1>;
};
cmu_imem: clock-controller@11060000 {
compatible = "samsung,exynos5433-cmu-imem";
reg = <0x11060000 0x1000>;
#clock-cells = <1>;
clock-names = "oscclk",
"aclk_imem_sssx_266",
"aclk_imem_266",
"aclk_imem_200";
clocks = <&xxti>,
<&cmu_top CLK_DIV_ACLK_IMEM_SSSX_266>,
<&cmu_top CLK_DIV_ACLK_IMEM_266>,
<&cmu_top CLK_DIV_ACLK_IMEM_200>;
};
Example 3: UART controller node that consumes the clock generated by the clock
controller.

23
Documentation/devicetree/bindings/clock/fixed-clock.txt
View File

@ -1,23 +0,0 @@
Binding for simple fixed-rate clock sources.
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "fixed-clock".
- #clock-cells : from common clock binding; shall be set to 0.
- clock-frequency : frequency of clock in Hz. Should be a single cell.
Optional properties:
- clock-accuracy : accuracy of clock in ppb (parts per billion).
Should be a single cell.
- clock-output-names : From common clock binding.
Example:
clock {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1000000000>;
clock-accuracy = <100>;
};

44
Documentation/devicetree/bindings/clock/fixed-clock.yaml 100644
View File

@ -0,0 +1,44 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Binding for simple fixed-rate clock sources
maintainers:
- Michael Turquette <mturquette@baylibre.com>
- Stephen Boyd <sboyd@kernel.org>
properties:
compatible:
const: fixed-clock
"#clock-cells":
const: 0
clock-frequency: true
clock-accuracy:
description: accuracy of clock in ppb (parts per billion).
$ref: /schemas/types.yaml#/definitions/uint32
clock-output-names:
maxItems: 1
required:
- compatible
- "#clock-cells"
- clock-frequency
additionalProperties: false
examples:
- |
clock {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1000000000>;
clock-accuracy = <100>;
};
...

28
Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
View File

@ -1,28 +0,0 @@
Binding for simple fixed factor rate clock sources.
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "fixed-factor-clock".
- #clock-cells : from common clock binding; shall be set to 0.
- clock-div: fixed divider.
- clock-mult: fixed multiplier.
- clocks: parent clock.
Optional properties:
- clock-output-names : From common clock binding.
Some clocks that require special treatments are also handled by that
driver, with the compatibles:
- allwinner,sun4i-a10-pll3-2x-clk
Example:
clock {
compatible = "fixed-factor-clock";
clocks = <&parentclk>;
#clock-cells = <0>;
clock-div = <2>;
clock-mult = <1>;
};

56
Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml 100644
View File

@ -0,0 +1,56 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/fixed-factor-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Binding for simple fixed factor rate clock sources
maintainers:
- Michael Turquette <mturquette@baylibre.com>
- Stephen Boyd <sboyd@kernel.org>
properties:
compatible:
enum:
- allwinner,sun4i-a10-pll3-2x-clk
- fixed-factor-clock
"#clock-cells":
const: 0
clocks:
maxItems: 1
clock-div:
description: Fixed divider
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 1
clock-mult:
description: Fixed multiplier
$ref: /schemas/types.yaml#/definitions/uint32
clock-output-names:
maxItems: 1
required:
- compatible
- clocks
- "#clock-cells"
- clock-div
- clock-mult
additionalProperties: false
examples:
- |
clock {
compatible = "fixed-factor-clock";
clocks = <&parentclk>;
#clock-cells = <0>;
clock-div = <2>;
clock-mult = <1>;
};
...

24
Documentation/devicetree/bindings/clock/fixed-mmio-clock.txt 100644
View File

@ -0,0 +1,24 @@
Binding for simple memory mapped io fixed-rate clock sources.
The driver reads a clock frequency value from a single 32-bit memory mapped
I/O register and registers it as a fixed rate clock.
It was designed for test systems, like FPGA, not for complete, finished SoCs.
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "fixed-mmio-clock".
- #clock-cells : from common clock binding; shall be set to 0.
- reg : Address and length of the clock value register set.
Optional properties:
- clock-output-names : From common clock binding.
Example:
sysclock: sysclock@fd020004 {
#clock-cells = <0>;
compatible = "fixed-mmio-clock";
reg = <0xfd020004 0x4>;
};

29
Documentation/devicetree/bindings/clock/imx8mm-clock.txt 100644
View File

@ -0,0 +1,29 @@
* Clock bindings for NXP i.MX8M Mini
Required properties:
- compatible: Should be "fsl,imx8mm-ccm"
- reg: Address and length of the register set
- #clock-cells: Should be <1>
- clocks: list of clock specifiers, must contain an entry for each required
entry in clock-names
- clock-names: should include the following entries:
- "osc_32k"
- "osc_24m"
- "clk_ext1"
- "clk_ext2"
- "clk_ext3"
- "clk_ext4"
clk: clock-controller@30380000 {
compatible = "fsl,imx8mm-ccm";
reg = <0x0 0x30380000 0x0 0x10000>;
#clock-cells = <1>;
clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>,
<&clk_ext3>, <&clk_ext4>;
clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
"clk_ext3", "clk_ext4";
};
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mm-clock.h
for the full list of i.MX8M Mini clock IDs.

1
Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
View File

@ -16,6 +16,7 @@ Required properties :
"qcom,rpmcc-msm8974", "qcom,rpmcc"
"qcom,rpmcc-apq8064", "qcom,rpmcc"
"qcom,rpmcc-msm8996", "qcom,rpmcc"
"qcom,rpmcc-msm8998", "qcom,rpmcc"
"qcom,rpmcc-qcs404", "qcom,rpmcc"
- #clock-cells : shall contain 1

2
Documentation/devicetree/bindings/display/sitronix,st7735r.txt
View File

@ -20,7 +20,7 @@ Example:
backlight: backlight {
compatible = "gpio-backlight";
gpios = <&gpio 44 GPIO_ACTIVE_HIGH>;
}
};
...

2
Documentation/devicetree/bindings/display/ssd1307fb.txt
View File

@ -36,7 +36,6 @@ ssd1307: oled@3c {
reg = <0x3c>;
pwms = <&pwm 4 3000>;
reset-gpios = <&gpio2 7>;
reset-active-low;
};
ssd1306: oled@3c {
@ -44,7 +43,6 @@ ssd1306: oled@3c {
reg = <0x3c>;
pwms = <&pwm 4 3000>;
reset-gpios = <&gpio2 7>;
reset-active-low;
solomon,com-lrremap;
solomon,com-invdir;
solomon,com-offset = <32>;

4
Documentation/devicetree/bindings/dma/dma.txt
View File

@ -16,6 +16,9 @@ Optional properties:
- dma-channels: Number of DMA channels supported by the controller.
- dma-requests: Number of DMA request signals supported by the
controller.
- dma-channel-mask: Bitmask of available DMA channels in ascending order
that are not reserved by firmware and are available to
the kernel. i.e. first channel corresponds to LSB.
Example:
@ -29,6 +32,7 @@ Example:
#dma-cells = <1>;
dma-channels = <32>;
dma-requests = <127>;
dma-channel-mask = <0xfffe>
};
* DMA router

57
Documentation/devicetree/bindings/dma/fsl-qdma.txt 100644
View File

@ -0,0 +1,57 @@
NXP Layerscape SoC qDMA Controller
==================================
This device follows the generic DMA bindings defined in dma/dma.txt.
Required properties:
- compatible: Must be one of
"fsl,ls1021a-qdma": for LS1021A Board
"fsl,ls1043a-qdma": for ls1043A Board
"fsl,ls1046a-qdma": for ls1046A Board
- reg: Should contain the register's base address and length.
- interrupts: Should contain a reference to the interrupt used by this
device.
- interrupt-names: Should contain interrupt names:
"qdma-queue0": the block0 interrupt
"qdma-queue1": the block1 interrupt
"qdma-queue2": the block2 interrupt
"qdma-queue3": the block3 interrupt
"qdma-error": the error interrupt
- fsl,dma-queues: Should contain number of queues supported.
- dma-channels: Number of DMA channels supported
- block-number: the virtual block number
- block-offset: the offset of different virtual block
- status-sizes: status queue size of per virtual block
- queue-sizes: command queue size of per virtual block, the size number
based on queues
Optional properties:
- dma-channels: Number of DMA channels supported by the controller.
- big-endian: If present registers and hardware scatter/gather descriptors
of the qDMA are implemented in big endian mode, otherwise in little
mode.
Examples:
qdma: dma-controller@8390000 {
compatible = "fsl,ls1021a-qdma";
reg = <0x0 0x8388000 0x0 0x1000>, /* Controller regs */
<0x0 0x8389000 0x0 0x1000>, /* Status regs */
<0x0 0x838a000 0x0 0x2000>; /* Block regs */
interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "qdma-error",
"qdma-queue0", "qdma-queue1";
dma-channels = <8>;
block-number = <2>;
block-offset = <0x1000>;
fsl,dma-queues = <2>;
status-sizes = <64>;
queue-sizes = <64 64>;
big-endian;
};
DMA clients must use the format described in dma/dma.txt file.

4
Documentation/devicetree/bindings/dma/k3dma.txt
View File

@ -3,7 +3,9 @@
See dma.txt first
Required properties:
- compatible: Should be "hisilicon,k3-dma-1.0"
- compatible: Must be one of
- "hisilicon,k3-dma-1.0"
- "hisilicon,hisi-pcm-asp-dma-1.0"
- reg: Should contain DMA registers location and length.
- interrupts: Should contain one interrupt shared by all channel
- #dma-cells: see dma.txt, should be 1, para number

2
Documentation/devicetree/bindings/dma/snps-dma.txt
View File

@ -23,8 +23,6 @@ Deprecated properties:
Optional properties:
- is_private: The device channels should be marked as private and not for by the
general purpose DMA channel allocator. False if not passed.
- multi-block: Multi block transfers supported by hardware. Array property with
one cell per channel. 0: not supported, 1 (default): supported.
- snps,dma-protection-control: AHB HPROT[3:1] protection setting.

2
Documentation/devicetree/bindings/dma/sprd-dma.txt
View File

@ -31,7 +31,7 @@ DMA clients connected to the Spreadtrum DMA controller must use the format
described in the dma.txt file, using a two-cell specifier for each channel.
The two cells in order are:
1. A phandle pointing to the DMA controller.
2. The channel id.
2. The slave id.
spi0: spi@70a00000{
...

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

@ -37,10 +37,11 @@ Required properties:
Required properties for VDMA:
- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
Optional properties:
- xlnx,include-sg: Tells configured for Scatter-mode in
the hardware.
Optional properties for AXI DMA:
- xlnx,sg-length-width: Should be set to the width in bits of the length
register as configured in h/w. Takes values {8...26}. If the property
is missing or invalid then the default value 23 is used. This is the
maximum value that is supported by all IP versions.
- xlnx,mcdma: Tells whether configured for multi-channel mode in the hardware.
Optional properties for VDMA:
- xlnx,flush-fsync: Tells which channel to Flush on Frame sync.

25
Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt 100644
View File

@ -0,0 +1,25 @@
Aspeed AST2500 SoC EDAC node
The Aspeed AST2500 SoC supports DDR3 and DDR4 memory with and without ECC (error
correction check).
The memory controller supports SECDED (single bit error correction, double bit
error detection) and single bit error auto scrubbing by reserving 8 bits for
every 64 bit word (effectively reducing available memory to 8/9).
Note, the bootloader must configure ECC mode in the memory controller.
Required properties:
- compatible: should be "aspeed,ast2500-sdram-edac"
- reg: sdram controller register set should be <0x1e6e0000 0x174>
- interrupts: should be AVIC interrupt #0
Example:
edac: sdram@1e6e0000 {
compatible = "aspeed,ast2500-sdram-edac";
reg = <0x1e6e0000 0x174>;
interrupts = <0>;
};

3
Documentation/devicetree/bindings/eeprom/at24.txt
View File

@ -75,6 +75,8 @@ Optional properties:
- address-width: number of address bits (one of 8, 16).
- num-addresses: total number of i2c slave addresses this device takes
Example:
eeprom@52 {
@ -82,4 +84,5 @@ eeprom@52 {
reg = <0x52>;
pagesize = <32>;
wp-gpios = <&gpio1 3 0>;
num-addresses = <8>;
};

20
Documentation/devicetree/bindings/gpio/gateworks,pld-gpio.txt 100644
View File

@ -0,0 +1,20 @@
Gateworks PLD GPIO controller bindings
The GPIO controller should be a child node on an I2C bus,
see: i2c/i2c.txt for details.
Required properties:
- compatible: Should be "gateworks,pld-gpio"
- reg: I2C slave address
- gpio-controller: Marks the device node as a GPIO controller.
- #gpio-cells: Should be <2>. The first cell is the gpio number and
the second cell is used to specify optional parameters.
Example:
pld@56 {
compatible = "gateworks,pld-gpio";
reg = <0x56>;
gpio-controller;
#gpio-cells = <2>;
};

4
Documentation/devicetree/bindings/gpio/gpio-eic-sprd.txt
View File

@ -33,7 +33,7 @@ Required properties:
"sprd,sc9860-eic-latch",
"sprd,sc9860-eic-async",
"sprd,sc9860-eic-sync",
"sprd,sc27xx-eic".
"sprd,sc2731-eic".
- reg: Define the base and range of the I/O address space containing
the GPIO controller registers.
- gpio-controller: Marks the device node as a GPIO controller.
@ -86,7 +86,7 @@ Example:
};
pmic_eic: gpio@300 {
compatible = "sprd,sc27xx-eic";
compatible = "sprd,sc2731-eic";
reg = <0x300>;
interrupt-parent = <&sc2731_pmic>;
interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;

1
Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
View File

@ -16,6 +16,7 @@ Required properties:
nxp,pca9574
nxp,pca9575
nxp,pca9698
nxp,pcal6416
nxp,pcal6524
nxp,pcal9555a
maxim,max7310

12
Documentation/devicetree/bindings/gpio/gpio.txt
View File

@ -67,6 +67,18 @@ Optional standard bitfield specifiers for the last cell:
https://en.wikipedia.org/wiki/Open_collector
- Bit 3: 0 means the output should be maintained during sleep/low-power mode
1 means the output state can be lost during sleep/low-power mode
- Bit 4: 0 means no pull-up resistor should be enabled
1 means a pull-up resistor should be enabled
This setting only applies to hardware with a simple on/off
control for pull-up configuration. If the hardware has more
elaborate pull-up configuration, it should be represented
using a pin control binding.
- Bit 5: 0 means no pull-down resistor should be enabled
1 means a pull-down resistor should be enabled
This setting only applies to hardware with a simple on/off
control for pull-down configuration. If the hardware has more
elaborate pull-down configuration, it should be represented
using a pin control binding.
1.1) GPIO specifier best practices
----------------------------------

38
Documentation/devicetree/bindings/gpio/intel,ixp4xx-gpio.txt 100644
View File

@ -0,0 +1,38 @@
Intel IXP4xx XScale Networking Processors GPIO
This GPIO controller is found in the Intel IXP4xx processors.
It supports 16 GPIO lines.
The interrupt portions of the GPIO controller is hierarchical:
the synchronous edge detector is part of the GPIO block, but the
actual enabling/disabling of the interrupt line is done in the
main IXP4xx interrupt controller which has a 1:1 mapping for
the first 12 GPIO lines to 12 system interrupts.
The remaining 4 GPIO lines can not be used for receiving
interrupts.
The interrupt parent of this GPIO controller must be the
IXP4xx interrupt controller.
Required properties:
- compatible : Should be
"intel,ixp4xx-gpio"
- reg : Should contain registers location and length
- gpio-controller : marks this as a GPIO controller
- #gpio-cells : Should be 2, see gpio/gpio.txt
- interrupt-controller : marks this as an interrupt controller
- #interrupt-cells : a standard two-cell interrupt, see
interrupt-controller/interrupts.txt
Example:
gpio0: gpio@c8004000 {
compatible = "intel,ixp4xx-gpio";
reg = <0xc8004000 0x1000>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};

4
Documentation/devicetree/bindings/hwmon/adc128d818.txt
View File

@ -26,7 +26,7 @@ Required node properties:
Optional node properties:
- ti,mode: Operation mode (see above).
- ti,mode: Operation mode (u8) (see above).
Example (operation mode 2):
@ -34,5 +34,5 @@ Example (operation mode 2):
adc128d818@1d {
compatible = "ti,adc128d818";
reg = <0x1d>;
ti,mode = <2>;
ti,mode = /bits/ 8 <2>;
};

20
Documentation/devicetree/bindings/i2c/i2c-iop3xx.txt 100644
View File

@ -0,0 +1,20 @@
i2c Controller on XScale platforms such as IOP3xx and IXP4xx
Required properties:
- compatible : Must be one of
"intel,iop3xx-i2c"
"intel,ixp4xx-i2c";
- reg
- #address-cells = <1>;
- #size-cells = <0>;
Optional properties:
- Child nodes conforming to i2c bus binding
Example:
i2c@c8011000 {
compatible = "intel,ixp4xx-i2c";
reg = <0xc8011000 0x18>;
interrupts = <33 IRQ_TYPE_LEVEL_LOW>;
};

1
Documentation/devicetree/bindings/i2c/i2c-mtk.txt → Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt
View File

@ -10,6 +10,7 @@ Required properties:
"mediatek,mt6589-i2c": for MediaTek MT6589
"mediatek,mt7622-i2c": for MediaTek MT7622
"mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623
"mediatek,mt7629-i2c", "mediatek,mt2712-i2c": for MediaTek MT7629
"mediatek,mt8173-i2c": for MediaTek MT8173
- reg: physical base address of the controller and dma base, length of memory
mapped region.

0
Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt → Documentation/devicetree/bindings/i2c/i2c-stu300.txt
View File

0
Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt → Documentation/devicetree/bindings/i2c/i2c-sun6i-p2wi.txt
View File

0
Documentation/devicetree/bindings/i2c/i2c-vt8500.txt → Documentation/devicetree/bindings/i2c/i2c-wmt.txt
View File

21
Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt 100644
View File

@ -0,0 +1,21 @@
STMPE ADC driver
----------------
Required properties:
- compatible: "st,stmpe-adc"
Optional properties:
Note that the ADC is shared with the STMPE touchscreen. ADC related settings
have to be done in the mfd.
- st,norequest-mask: bitmask specifying which ADC channels should _not_ be
requestable due to different usage (e.g. touch)
Node name must be stmpe_adc and should be child node of stmpe node to
which it belongs.
Example:
stmpe_adc {
compatible = "st,stmpe-adc";
st,norequest-mask = <0x0F>; /* dont use ADC CH3-0 */
};

9
Documentation/devicetree/bindings/input/cypress,tm2-touchkey.txt
View File

@ -1,13 +1,19 @@
Samsung tm2-touchkey
Required properties:
- compatible: must be "cypress,tm2-touchkey"
- compatible:
* "cypress,tm2-touchkey" - for the touchkey found on the tm2 board
* "cypress,midas-touchkey" - for the touchkey found on midas boards
* "cypress,aries-touchkey" - for the touchkey found on aries boards
- reg: I2C address of the chip.
- interrupts: interrupt to which the chip is connected (see interrupt
binding[0]).
- vcc-supply : internal regulator output. 1.8V
- vdd-supply : power supply for IC 3.3V
Optional properties:
- linux,keycodes: array of keycodes (max 4), default KEY_PHONE and KEY_BACK
[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
Example:
@ -21,5 +27,6 @@ Example:
interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
vcc-supply=<&ldo32_reg>;
vdd-supply=<&ldo33_reg>;
linux,keycodes = <KEY_PHONE KEY_BACK>;
};
};

25
Documentation/devicetree/bindings/input/ilitek,ili2xxx.txt 100644
View File

@ -0,0 +1,25 @@
Ilitek ILI210x/ILI251x touchscreen controller
Required properties:
- compatible:
ilitek,ili210x for ILI210x
ilitek,ili251x for ILI251x
- reg: The I2C address of the device
- interrupts: The sink for the touchscreen's IRQ output
See ../interrupt-controller/interrupts.txt
Optional properties for main touchpad device:
- reset-gpios: GPIO specifier for the touchscreen's reset pin (active low)
Example:
touchscreen@41 {
compatible = "ilitek,ili251x";
reg = <0x41>;
interrupt-parent = <&gpio4>;
interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
reset-gpios = <&gpio5 21 GPIO_ACTIVE_LOW>;
};

36
Documentation/devicetree/bindings/input/msm-vibrator.txt 100644
View File

@ -0,0 +1,36 @@
* Device tree bindings for the Qualcomm MSM vibrator
Required properties:
- compatible: Should be one of
"qcom,msm8226-vibrator"
"qcom,msm8974-vibrator"
- reg: the base address and length of the IO memory for the registers.
- pinctrl-names: set to default.
- pinctrl-0: phandles pointing to pin configuration nodes. See
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
- clock-names: set to pwm
- clocks: phandle of the clock. See
Documentation/devicetree/bindings/clock/clock-bindings.txt
- enable-gpios: GPIO that enables the vibrator.
Optional properties:
- vcc-supply: phandle to the regulator that provides power to the sensor.
Example from a LG Nexus 5 (hammerhead) phone:
vibrator@fd8c3450 {
reg = <0xfd8c3450 0x400>;
compatible = "qcom,msm8974-vibrator";
vcc-supply = <&pm8941_l19>;
clocks = <&mmcc CAMSS_GP1_CLK>;
clock-names = "pwm";
enable-gpios = <&msmgpio 60 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&vibrator_pin>;
};

28
Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt 100644
View File

@ -0,0 +1,28 @@
STMicroelectronics STPMIC1 Onkey
Required properties:
- compatible = "st,stpmic1-onkey";
- interrupts: interrupt line to use
- interrupt-names = "onkey-falling", "onkey-rising"
onkey-falling: happens when onkey is pressed; IT_PONKEY_F of pmic
onkey-rising: happens when onkey is released; IT_PONKEY_R of pmic
Optional properties:
- st,onkey-clear-cc-flag: onkey is able power on after an
over-current shutdown event.
- st,onkey-pu-inactive: onkey pull up is not active
- power-off-time-sec: Duration in seconds which the key should be kept
pressed for device to power off automatically (from 1 to 16 seconds).
see See Documentation/devicetree/bindings/input/keys.txt
Example:
onkey {
compatible = "st,stpmic1-onkey";
interrupt-parent = <&pmic>;
interrupts = <IT_PONKEY_F 0>,<IT_PONKEY_R 1>;
interrupt-names = "onkey-falling", "onkey-rising";
power-off-time-sec = <10>;
};

13
Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
View File

@ -1,11 +1,12 @@
FocalTech EDT-FT5x06 Polytouch driver
=====================================
There are 3 variants of the chip for various touch panel sizes
There are 5 variants of the chip for various touch panel sizes
FT5206GE1 2.8" .. 3.8"
FT5306DE4 4.3" .. 7"
FT5406EE8 7" .. 8.9"
FT5506EEG 7" .. 8.9"
FT5726NEI 5.7” .. 11.6"
The software interface is identical for all those chips, so that
currently there is no need for the driver to distinguish between the
@ -19,6 +20,7 @@ Required properties:
or: "edt,edt-ft5306"
or: "edt,edt-ft5406"
or: "edt,edt-ft5506"
or: "evervision,ev-ft5726"
or: "focaltech,ft6236"
- reg: I2C slave address of the chip (0x38)
@ -42,6 +44,15 @@ Optional properties:
- offset: allows setting the edge compensation in the range from
0 to 31.
- offset-x: Same as offset, but applies only to the horizontal position.
Range from 0 to 80, only supported by evervision,ev-ft5726
devices.
- offset-y: Same as offset, but applies only to the vertical position.
Range from 0 to 80, only supported by evervision,ev-ft5726
devices.
- touchscreen-size-x : See touchscreen.txt
- touchscreen-size-y : See touchscreen.txt
- touchscreen-fuzz-x : See touchscreen.txt

12
Documentation/devicetree/bindings/input/touchscreen/goodix.txt
View File

@ -3,6 +3,7 @@ Device tree bindings for Goodix GT9xx series touchscreen controller
Required properties:
- compatible : Should be "goodix,gt1151"
or "goodix,gt5688"
or "goodix,gt911"
or "goodix,gt9110"
or "goodix,gt912"
@ -18,11 +19,14 @@ Optional properties:
- irq-gpios : GPIO pin used for IRQ. The driver uses the
interrupt gpio pin as output to reset the device.
- reset-gpios : GPIO pin used for reset
- touchscreen-inverted-x
- touchscreen-inverted-y
- touchscreen-size-x
- touchscreen-size-y
- touchscreen-swapped-x-y
- touchscreen-inverted-x : X axis is inverted (boolean)
- touchscreen-inverted-y : Y axis is inverted (boolean)
- touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
(swapping is done after inverting the axis)
The touchscreen-* properties are documented in touchscreen.txt in this
directory.
Example:

8
Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt
View File

@ -1,13 +1,17 @@
* Sitronix st1232 touchscreen controller
* Sitronix st1232 or st1633 touchscreen controller
Required properties:
- compatible: must be "sitronix,st1232"
- compatible: must contain one of
* "sitronix,st1232"
* "sitronix,st1633"
- reg: I2C address of the chip
- interrupts: interrupt to which the chip is connected
Optional properties:
- gpios: a phandle to the reset GPIO
For additional optional properties see: touchscreen.txt
Example:
i2c@00000000 {

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

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

10
Documentation/devicetree/bindings/input/touchscreen/sx8654.txt
View File

@ -1,10 +1,17 @@
* Semtech SX8654 I2C Touchscreen Controller
Required properties:
- compatible: must be "semtech,sx8654"
- compatible: must be one of the following, depending on the model:
"semtech,sx8650"
"semtech,sx8654"
"semtech,sx8655"
"semtech,sx8656"
- reg: i2c slave address
- interrupts: touch controller interrupt
Optional properties:
- reset-gpios: GPIO specification for the NRST input
Example:
sx8654@48 {
@ -12,4 +19,5 @@ Example:
reg = <0x48>;
interrupt-parent = <&gpio6>;
interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
reset-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
};

175
Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
View File

@ -1,175 +0,0 @@
* ARM Generic Interrupt Controller, version 3
AArch64 SMP cores are often associated with a GICv3, providing Private
Peripheral Interrupts (PPI), Shared Peripheral Interrupts (SPI),
Software Generated Interrupts (SGI), and Locality-specific Peripheral
Interrupts (LPI).
Main node required properties:
- compatible : should at least contain "arm,gic-v3" or either
"qcom,msm8996-gic-v3", "arm,gic-v3" for msm8996 SoCs
to address SoC specific bugs/quirks
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. Must be a single cell with a value of at least 3.
If the system requires describing PPI affinity, then the value must
be at least 4.
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts. Other values are reserved for future use.
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
range [0-15].
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = edge triggered
4 = level triggered
The 4th cell is a phandle to a node describing a set of CPUs this
interrupt is affine to. The interrupt must be a PPI, and the node
pointed must be a subnode of the "ppi-partitions" subnode. For
interrupt types other than PPI or PPIs that are not partitionned,
this cell must be zero. See the "ppi-partitions" node description
below.
Cells 5 and beyond are reserved for future use and must have a value
of 0 if present.
- reg : Specifies base physical address(s) and size of the GIC
registers, in the following order:
- GIC Distributor interface (GICD)
- GIC Redistributors (GICR), one range per redistributor region
- GIC CPU interface (GICC)
- GIC Hypervisor interface (GICH)
- GIC Virtual CPU interface (GICV)
GICC, GICH and GICV are optional.
- interrupts : Interrupt source of the VGIC maintenance interrupt.
Optional
- redistributor-stride : If using padding pages, specifies the stride
of consecutive redistributors. Must be a multiple of 64kB.
- #redistributor-regions: The number of independent contiguous regions
occupied by the redistributors. Required if more than one such
region is present.
- msi-controller: Boolean property. Identifies the node as an MSI
controller. Only present if the Message Based Interrupt
functionnality is being exposed by the HW, and the mbi-ranges
property present.
- mbi-ranges: A list of pairs <intid span>, where "intid" is the first
SPI of a range that can be used an MBI, and "span" the size of that
range. Multiple ranges can be provided. Requires "msi-controller" to
be set.
- mbi-alias: Address property. Base address of an alias of the GICD
region containing only the {SET,CLR}SPI registers to be used if
isolation is required, and if supported by the HW.
Sub-nodes:
PPI affinity can be expressed as a single "ppi-partitions" node,
containing a set of sub-nodes, each with the following property:
- affinity: Should be a list of phandles to CPU nodes (as described in
Documentation/devicetree/bindings/arm/cpus.yaml).
GICv3 has one or more Interrupt Translation Services (ITS) that are
used to route Message Signalled Interrupts (MSI) to the CPUs.
These nodes must have the following properties:
- compatible : Should at least contain "arm,gic-v3-its".
- msi-controller : Boolean property. Identifies the node as an MSI controller
- #msi-cells: Must be <1>. The single msi-cell is the DeviceID of the device
which will generate the MSI.
- reg: Specifies the base physical address and size of the ITS
registers.
Optional:
- socionext,synquacer-pre-its: (u32, u32) tuple describing the untranslated
address and size of the pre-ITS window.
The main GIC node must contain the appropriate #address-cells,
#size-cells and ranges properties for the reg property of all ITS
nodes.
Examples:
gic: interrupt-controller@2cf00000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
interrupt-controller;
reg = <0x0 0x2f000000 0 0x10000>, // GICD
<0x0 0x2f100000 0 0x200000>, // GICR
<0x0 0x2c000000 0 0x2000>, // GICC
<0x0 0x2c010000 0 0x2000>, // GICH
<0x0 0x2c020000 0 0x2000>; // GICV
interrupts = <1 9 4>;
msi-controller;
mbi-ranges = <256 128>;
gic-its@2c200000 {
compatible = "arm,gic-v3-its";
msi-controller;
#msi-cells = <1>;
reg = <0x0 0x2c200000 0 0x20000>;
};
};
gic: interrupt-controller@2c010000 {
compatible = "arm,gic-v3";
#interrupt-cells = <4>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
interrupt-controller;
redistributor-stride = <0x0 0x40000>; // 256kB stride
#redistributor-regions = <2>;
reg = <0x0 0x2c010000 0 0x10000>, // GICD
<0x0 0x2d000000 0 0x800000>, // GICR 1: CPUs 0-31
<0x0 0x2e000000 0 0x800000>; // GICR 2: CPUs 32-63
<0x0 0x2c040000 0 0x2000>, // GICC
<0x0 0x2c060000 0 0x2000>, // GICH
<0x0 0x2c080000 0 0x2000>; // GICV
interrupts = <1 9 4>;
gic-its@2c200000 {
compatible = "arm,gic-v3-its";
msi-controller;
#msi-cells = <1>;
reg = <0x0 0x2c200000 0 0x20000>;
};
gic-its@2c400000 {
compatible = "arm,gic-v3-its";
msi-controller;
#msi-cells = <1>;
reg = <0x0 0x2c400000 0 0x20000>;
};
ppi-partitions {
part0: interrupt-partition-0 {
affinity = <&cpu0 &cpu2>;
};
part1: interrupt-partition-1 {
affinity = <&cpu1 &cpu3>;
};
};
};
device@0 {
reg = <0 0 0 4>;
interrupts = <1 1 4 &part0>;
};

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

@ -0,0 +1,279 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/interrupt-controller/arm,gic-v3.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Generic Interrupt Controller, version 3
maintainers:
- Marc Zyngier <marc.zyngier@arm.com>
description: |
AArch64 SMP cores are often associated with a GICv3, providing Private
Peripheral Interrupts (PPI), Shared Peripheral Interrupts (SPI),
Software Generated Interrupts (SGI), and Locality-specific Peripheral
Interrupts (LPI).
allOf:
- $ref: /schemas/interrupt-controller.yaml#
properties:
compatible:
oneOf:
- items:
- enum:
- qcom,msm8996-gic-v3
- const: arm,gic-v3
- const: arm,gic-v3
interrupt-controller: true
"#address-cells":
enum: [ 0, 1, 2 ]
"#size-cells":
enum: [ 1, 2 ]
ranges: true
"#interrupt-cells":
description: |
Specifies the number of cells needed to encode an interrupt source.
Must be a single cell with a value of at least 3.
If the system requires describing PPI affinity, then the value must
be at least 4.
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts. Other values are reserved for future use.
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
range [0-15].
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = edge triggered
4 = level triggered
The 4th cell is a phandle to a node describing a set of CPUs this
interrupt is affine to. The interrupt must be a PPI, and the node
pointed must be a subnode of the "ppi-partitions" subnode. For
interrupt types other than PPI or PPIs that are not partitionned,
this cell must be zero. See the "ppi-partitions" node description
below.
Cells 5 and beyond are reserved for future use and must have a value
of 0 if present.
enum: [ 3, 4 ]
reg:
description: |
Specifies base physical address(s) and size of the GIC
registers, in the following order:
- GIC Distributor interface (GICD)
- GIC Redistributors (GICR), one range per redistributor region
- GIC CPU interface (GICC)
- GIC Hypervisor interface (GICH)
- GIC Virtual CPU interface (GICV)
GICC, GICH and GICV are optional.
minItems: 2
maxItems: 4096 # Should be enough?
interrupts:
description:
Interrupt source of the VGIC maintenance interrupt.
maxItems: 1
redistributor-stride:
description:
If using padding pages, specifies the stride of consecutive
redistributors. Must be a multiple of 64kB.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint64
- multipleOf: 0x10000
exclusiveMinimum: 0
"#redistributor-regions":
description:
The number of independent contiguous regions occupied by the
redistributors. Required if more than one such region is present.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- maximum: 4096 # Should be enough?
msi-controller:
description:
Only present if the Message Based Interrupt functionnality is
being exposed by the HW, and the mbi-ranges property present.
mbi-ranges:
description:
A list of pairs <intid span>, where "intid" is the first SPI of a range
that can be used an MBI, and "span" the size of that range. Multiple
ranges can be provided.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
- items:
minItems: 2
maxItems: 2
mbi-alias:
description:
Address property. Base address of an alias of the GICD region containing
only the {SET,CLR}SPI registers to be used if isolation is required,
and if supported by the HW.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- items:
minItems: 1
maxItems: 2
ppi-partitions:
type: object
description:
PPI affinity can be expressed as a single "ppi-partitions" node,
containing a set of sub-nodes.
patternProperties:
"^interrupt-partition-[0-9]+$":
properties:
affinity:
$ref: /schemas/types.yaml#/definitions/phandle-array
description:
Should be a list of phandles to CPU nodes (as described in
Documentation/devicetree/bindings/arm/cpus.yaml).
required:
- affinity
dependencies:
mbi-ranges: [ msi-controller ]
msi-controller: [ mbi-ranges ]
required:
- compatible
- interrupts
- reg
patternProperties:
"^gic-its@": false
"^interrupt-controller@[0-9a-f]+$": false
# msi-controller is preferred, but allow other names
"^(msi-controller|gic-its|interrupt-controller)@[0-9a-f]+$":
type: object
description:
GICv3 has one or more Interrupt Translation Services (ITS) that are
used to route Message Signalled Interrupts (MSI) to the CPUs.
properties:
compatible:
const: arm,gic-v3-its
msi-controller: true
"#msi-cells":
description:
The single msi-cell is the DeviceID of the device which will generate
the MSI.
const: 1
reg:
description:
Specifies the base physical address and size of the ITS registers.
maxItems: 1
socionext,synquacer-pre-its:
description:
(u32, u32) tuple describing the untranslated
address and size of the pre-ITS window.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- items:
minItems: 2
maxItems: 2
required:
- compatible
- msi-controller
- "#msi-cells"
- reg
additionalProperties: false
additionalProperties: false
examples:
- |
gic: interrupt-controller@2cf00000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
interrupt-controller;
reg = <0x2f000000 0x10000>, // GICD
<0x2f100000 0x200000>, // GICR
<0x2c000000 0x2000>, // GICC
<0x2c010000 0x2000>, // GICH
<0x2c020000 0x2000>; // GICV
interrupts = <1 9 4>;
msi-controller;
mbi-ranges = <256 128>;
msi-controller@2c200000 {
compatible = "arm,gic-v3-its";
msi-controller;
#msi-cells = <1>;
reg = <0x2c200000 0x20000>;
};
};
interrupt-controller@2c010000 {
compatible = "arm,gic-v3";
#interrupt-cells = <4>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
interrupt-controller;
redistributor-stride = <0x0 0x40000>; // 256kB stride
#redistributor-regions = <2>;
reg = <0x2c010000 0x10000>, // GICD
<0x2d000000 0x800000>, // GICR 1: CPUs 0-31
<0x2e000000 0x800000>, // GICR 2: CPUs 32-63
<0x2c040000 0x2000>, // GICC
<0x2c060000 0x2000>, // GICH
<0x2c080000 0x2000>; // GICV
interrupts = <1 9 4>;
msi-controller@2c200000 {
compatible = "arm,gic-v3-its";
msi-controller;
#msi-cells = <1>;
reg = <0x2c200000 0x20000>;
};
msi-controller@2c400000 {
compatible = "arm,gic-v3-its";
msi-controller;
#msi-cells = <1>;
reg = <0x2c400000 0x20000>;
};
ppi-partitions {
part0: interrupt-partition-0 {
affinity = <&cpu0 &cpu2>;
};
part1: interrupt-partition-1 {
affinity = <&cpu1 &cpu3>;
};
};
};
device@0 {
reg = <0 4>;
interrupts = <1 1 4 &part0>;
};
...

171
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
View File

@ -1,171 +0,0 @@
* ARM Generic Interrupt Controller
ARM SMP cores are often associated with a GIC, providing per processor
interrupts (PPI), shared processor interrupts (SPI) and software
generated interrupts (SGI).
Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
Secondary GICs are cascaded into the upward interrupt controller and do not
have PPIs or SGIs.
Main node required properties:
- compatible : should be one of:
"arm,arm1176jzf-devchip-gic"
"arm,arm11mp-gic"
"arm,cortex-a15-gic"
"arm,cortex-a7-gic"
"arm,cortex-a9-gic"
"arm,eb11mp-gic"
"arm,gic-400"
"arm,pl390"
"arm,tc11mp-gic"
"brcm,brahma-b15-gic"
"nvidia,tegra210-agic"
"qcom,msm-8660-qgic"
"qcom,msm-qgic2"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 3.
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts.
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
range [0-15].
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = low-to-high edge triggered
2 = high-to-low edge triggered (invalid for SPIs)
4 = active high level-sensitive
8 = active low level-sensitive (invalid for SPIs).
bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
the 8 possible cpus attached to the GIC. A bit set to '1' indicated
the interrupt is wired to that CPU. Only valid for PPI interrupts.
Also note that the configurability of PPI interrupts is IMPLEMENTATION
DEFINED and as such not guaranteed to be present (most SoC available
in 2014 seem to ignore the setting of this flag and use the hardware
default value).
- reg : Specifies base physical address(s) and size of the GIC registers. The
first region is the GIC distributor register base and size. The 2nd region is
the GIC cpu interface register base and size.
Optional
- interrupts : Interrupt source of the parent interrupt controller on
secondary GICs, or VGIC maintenance interrupt on primary GIC (see
below).
- cpu-offset : per-cpu offset within the distributor and cpu interface
regions, used when the GIC doesn't have banked registers. The offset is
cpu-offset * cpu-nr.
- clocks : List of phandle and clock-specific pairs, one for each entry
in clock-names.
- clock-names : List of names for the GIC clock input(s). Valid clock names
depend on the GIC variant:
"ic_clk" (for "arm,arm11mp-gic")
"PERIPHCLKEN" (for "arm,cortex-a15-gic")
"PERIPHCLK", "PERIPHCLKEN" (for "arm,cortex-a9-gic")
"clk" (for "arm,gic-400" and "nvidia,tegra210")
"gclk" (for "arm,pl390")
- power-domains : A phandle and PM domain specifier as defined by bindings of
the power controller specified by phandle, used when the GIC
is part of a Power or Clock Domain.
Example:
intc: interrupt-controller@fff11000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
#address-cells = <1>;
interrupt-controller;
reg = <0xfff11000 0x1000>,
<0xfff10100 0x100>;
};
* GIC virtualization extensions (VGIC)
For ARM cores that support the virtualization extensions, additional
properties must be described (they only exist if the GIC is the
primary interrupt controller).
Required properties:
- reg : Additional regions specifying the base physical address and
size of the VGIC registers. The first additional region is the GIC
virtual interface control register base and size. The 2nd additional
region is the GIC virtual cpu interface register base and size.
- interrupts : VGIC maintenance interrupt.
Example:
interrupt-controller@2c001000 {
compatible = "arm,cortex-a15-gic";
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x2c001000 0x1000>,
<0x2c002000 0x2000>,
<0x2c004000 0x2000>,
<0x2c006000 0x2000>;
interrupts = <1 9 0xf04>;
};
* GICv2m extension for MSI/MSI-x support (Optional)
Certain revisions of GIC-400 supports MSI/MSI-x via V2M register frame(s).
This is enabled by specifying v2m sub-node(s).
Required properties:
- compatible : The value here should contain "arm,gic-v2m-frame".
- msi-controller : Identifies the node as an MSI controller.
- reg : GICv2m MSI interface register base and size
Optional properties:
- arm,msi-base-spi : When the MSI_TYPER register contains an incorrect
value, this property should contain the SPI base of
the MSI frame, overriding the HW value.
- arm,msi-num-spis : When the MSI_TYPER register contains an incorrect
value, this property should contain the number of
SPIs assigned to the frame, overriding the HW value.
Example:
interrupt-controller@e1101000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
#address-cells = <2>;
#size-cells = <2>;
interrupt-controller;
interrupts = <1 8 0xf04>;
ranges = <0 0 0 0xe1100000 0 0x100000>;
reg = <0x0 0xe1110000 0 0x01000>,
<0x0 0xe112f000 0 0x02000>,
<0x0 0xe1140000 0 0x10000>,
<0x0 0xe1160000 0 0x10000>;
v2m0: v2m@8000 {
compatible = "arm,gic-v2m-frame";
msi-controller;
reg = <0x0 0x80000 0 0x1000>;
};
....
v2mN: v2m@9000 {
compatible = "arm,gic-v2m-frame";
msi-controller;
reg = <0x0 0x90000 0 0x1000>;
};
};

223
Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml 100644
View File

@ -0,0 +1,223 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/interrupt-controller/arm,gic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Generic Interrupt Controller v1 and v2
maintainers:
- Marc Zyngier <marc.zyngier@arm.com>
description: |+
ARM SMP cores are often associated with a GIC, providing per processor
interrupts (PPI), shared processor interrupts (SPI) and software
generated interrupts (SGI).
Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
Secondary GICs are cascaded into the upward interrupt controller and do not
have PPIs or SGIs.
allOf:
- $ref: /schemas/interrupt-controller.yaml#
properties:
compatible:
oneOf:
- items:
- enum:
- arm,arm11mp-gic
- arm,cortex-a15-gic
- arm,cortex-a7-gic
- arm,cortex-a5-gic
- arm,cortex-a9-gic
- arm,eb11mp-gic
- arm,gic-400
- arm,pl390
- arm,tc11mp-gic
- nvidia,tegra210-agic
- qcom,msm-8660-qgic
- qcom,msm-qgic2
- items:
- const: arm,arm1176jzf-devchip-gic
- const: arm,arm11mp-gic
- items:
- const: brcm,brahma-b15-gic
- const: arm,cortex-a15-gic
interrupt-controller: true
"#address-cells":
enum: [ 0, 1 ]
"#size-cells":
const: 1
"#interrupt-cells":
const: 3
description: |
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts.
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
range [0-15].
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = low-to-high edge triggered
2 = high-to-low edge triggered (invalid for SPIs)
4 = active high level-sensitive
8 = active low level-sensitive (invalid for SPIs).
bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
the 8 possible cpus attached to the GIC. A bit set to '1' indicated
the interrupt is wired to that CPU. Only valid for PPI interrupts.
Also note that the configurability of PPI interrupts is IMPLEMENTATION
DEFINED and as such not guaranteed to be present (most SoC available
in 2014 seem to ignore the setting of this flag and use the hardware
default value).
reg:
description: |
Specifies base physical address(s) and size of the GIC registers. The
first region is the GIC distributor register base and size. The 2nd region
is the GIC cpu interface register base and size.
For GICv2 with virtualization extensions, additional regions are
required for specifying the base physical address and size of the VGIC
registers. The first additional region is the GIC virtual interface
control register base and size. The 2nd additional region is the GIC
virtual cpu interface register base and size.
minItems: 2
maxItems: 4
interrupts:
description: Interrupt source of the parent interrupt controller on
secondary GICs, or VGIC maintenance interrupt on primary GIC (see
below).
maxItems: 1
cpu-offset:
description: per-cpu offset within the distributor and cpu interface
regions, used when the GIC doesn't have banked registers. The offset
is cpu-offset * cpu-nr.
$ref: /schemas/types.yaml#/definitions/uint32
clocks:
minItems: 1
maxItems: 2
clock-names:
description: List of names for the GIC clock input(s). Valid clock names
depend on the GIC variant.
oneOf:
- const: ic_clk # for "arm,arm11mp-gic"
- const: PERIPHCLKEN # for "arm,cortex-a15-gic"
- items: # for "arm,cortex-a9-gic"
- const: PERIPHCLK
- const: PERIPHCLKEN
- const: clk # for "arm,gic-400" and "nvidia,tegra210"
- const: gclk #for "arm,pl390"
power-domains:
maxItems: 1
required:
- compatible
- reg
patternProperties:
"^v2m@[0-9a-f]+$":
description: |
* GICv2m extension for MSI/MSI-x support (Optional)
Certain revisions of GIC-400 supports MSI/MSI-x via V2M register frame(s).
This is enabled by specifying v2m sub-node(s).
properties:
compatible:
const: arm,gic-v2m-frame
msi-controller: true
reg:
maxItems: 1
description: GICv2m MSI interface register base and size
arm,msi-base-spi:
description: When the MSI_TYPER register contains an incorrect value,
this property should contain the SPI base of the MSI frame, overriding
the HW value.
$ref: /schemas/types.yaml#/definitions/uint32
arm,msi-num-spis:
description: When the MSI_TYPER register contains an incorrect value,
this property should contain the number of SPIs assigned to the
frame, overriding the HW value.
$ref: /schemas/types.yaml#/definitions/uint32
required:
- compatible
- msi-controller
- reg
additionalProperties: false
additionalProperties: false
examples:
- |
// GICv1
intc: interrupt-controller@fff11000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
#address-cells = <1>;
interrupt-controller;
reg = <0xfff11000 0x1000>,
<0xfff10100 0x100>;
};
- |
// GICv2
interrupt-controller@2c001000 {
compatible = "arm,cortex-a15-gic";
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x2c001000 0x1000>,
<0x2c002000 0x2000>,
<0x2c004000 0x2000>,
<0x2c006000 0x2000>;
interrupts = <1 9 0xf04>;
};
- |
// GICv2m extension for MSI/MSI-x support
interrupt-controller@e1101000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
#address-cells = <2>;
#size-cells = <2>;
interrupt-controller;
interrupts = <1 8 0xf04>;
ranges = <0 0 0 0xe1100000 0 0x100000>;
reg = <0x0 0xe1110000 0 0x01000>,
<0x0 0xe112f000 0 0x02000>,
<0x0 0xe1140000 0 0x10000>,
<0x0 0xe1160000 0 0x10000>;
v2m0: v2m@8000 {
compatible = "arm,gic-v2m-frame";
msi-controller;
reg = <0x0 0x80000 0 0x1000>;
};
//...
v2mN: v2m@9000 {
compatible = "arm,gic-v2m-frame";
msi-controller;
reg = <0x0 0x90000 0 0x1000>;
};
};
...

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

@ -16,6 +16,7 @@ Required properties:
- "renesas,irqc-r8a7793" (R-Car M2-N)
- "renesas,irqc-r8a7794" (R-Car E2)
- "renesas,intc-ex-r8a774a1" (RZ/G2M)
- "renesas,intc-ex-r8a774c0" (RZ/G2E)
- "renesas,intc-ex-r8a7795" (R-Car H3)
- "renesas,intc-ex-r8a7796" (R-Car M3-W)
- "renesas,intc-ex-r8a77965" (R-Car M3-N)

14
Documentation/devicetree/bindings/iommu/nvidia,tegra20-gart.txt
View File

@ -1,14 +0,0 @@
NVIDIA Tegra 20 GART
Required properties:
- compatible: "nvidia,tegra20-gart"
- reg: Two pairs of cells specifying the physical address and size of
the memory controller registers and the GART aperture respectively.
Example:
gart {
compatible = "nvidia,tegra20-gart";
reg = <0x7000f024 0x00000018 /* controller registers */
0x58000000 0x02000000>; /* GART aperture */
};

127
Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt 100644
View File

@ -0,0 +1,127 @@
Xilinx IPI Mailbox Controller
========================================
The Xilinx IPI(Inter Processor Interrupt) mailbox controller is to manage
messaging between two Xilinx Zynq UltraScale+ MPSoC IPI agents. Each IPI
agent owns registers used for notification and buffers for message.
+-------------------------------------+
| Xilinx ZynqMP IPI Controller |
+-------------------------------------+
+--------------------------------------------------+
ATF | |
| |
| |
+--------------------------+ |
| |
| |
+--------------------------------------------------+
+------------------------------------------+
| +----------------+ +----------------+ |
Hardware | | IPI Agent | | IPI Buffers | |
| | Registers | | | |
| | | | | |
| +----------------+ +----------------+ |
| |
| Xilinx IPI Agent Block |
+------------------------------------------+
Controller Device Node:
===========================
Required properties:
--------------------
IPI agent node:
- compatible: Shall be: "xlnx,zynqmp-ipi-mailbox"
- interrupt-parent: Phandle for the interrupt controller
- interrupts: Interrupt information corresponding to the
interrupt-names property.
- xlnx,ipi-id: local Xilinx IPI agent ID
- #address-cells: number of address cells of internal IPI mailbox nodes
- #size-cells: number of size cells of internal IPI mailbox nodes
Internal IPI mailbox node:
- reg: IPI buffers address ranges
- reg-names: Names of the reg resources. It should have:
* local_request_region
- IPI request msg buffer written by local and read
by remote
* local_response_region
- IPI response msg buffer written by local and read
by remote
* remote_request_region
- IPI request msg buffer written by remote and read
by local
* remote_response_region
- IPI response msg buffer written by remote and read
by local
- #mbox-cells: Shall be 1. It contains:
* tx(0) or rx(1) channel
- xlnx,ipi-id: remote Xilinx IPI agent ID of which the mailbox is
connected to.
Optional properties:
--------------------
- method: The method of accessing the IPI agent registers.
Permitted values are: "smc" and "hvc". Default is
"smc".
Client Device Node:
===========================
Required properties:
--------------------
- mboxes: Standard property to specify a mailbox
(See ./mailbox.txt)
- mbox-names: List of identifier strings for each mailbox
channel.
Example:
===========================
zynqmp_ipi {
compatible = "xlnx,zynqmp-ipi-mailbox";
interrupt-parent = <&gic>;
interrupts = <0 29 4>;
xlnx,ipi-id = <0>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
/* APU<->RPU0 IPI mailbox controller */
ipi_mailbox_rpu0: mailbox@ff90400 {
reg = <0xff990400 0x20>,
<0xff990420 0x20>,
<0xff990080 0x20>,
<0xff9900a0 0x20>;
reg-names = "local_request_region",
"local_response_region",
"remote_request_region",
"remote_response_region";
#mbox-cells = <1>;
xlnx,ipi-id = <1>;
};
/* APU<->RPU1 IPI mailbox controller */
ipi_mailbox_rpu1: mailbox@ff990440 {
reg = <0xff990440 0x20>,
<0xff990460 0x20>,
<0xff990280 0x20>,
<0xff9902a0 0x20>;
reg-names = "local_request_region",
"local_response_region",
"remote_request_region",
"remote_response_region";
#mbox-cells = <1>;
xlnx,ipi-id = <2>;
};
};
rpu0 {
...
mboxes = <&ipi_mailbox_rpu0 0>,
<&ipi_mailbox_rpu0 1>;
mbox-names = "tx", "rx";
};
rpu1 {
...
mboxes = <&ipi_mailbox_rpu1 0>,
<&ipi_mailbox_rpu1 1>;
mbox-names = "tx", "rx";
};

11
Documentation/devicetree/bindings/media/i2c/adv748x.txt
View File

@ -48,7 +48,16 @@ are numbered as follows.
TXA source 10
TXB source 11
The digital output port nodes must contain at least one endpoint.
The digital output port nodes, when present, shall contain at least one
endpoint. Each of those endpoints shall contain the data-lanes property as
described in video-interfaces.txt.
Required source endpoint properties:
- data-lanes: an array of physical data lane indexes
The accepted value(s) for this property depends on which of the two
sources are described. For TXA 1, 2 or 4 data lanes can be described
while for TXB only 1 data lane is valid. See video-interfaces.txt
for detailed description.
Ports are optional if they are not connected to anything at the hardware level.

20
Documentation/devicetree/bindings/media/i2c/melexis,mlx90640.txt 100644
View File

@ -0,0 +1,20 @@
* Melexis MLX90640 FIR Sensor
Melexis MLX90640 FIR sensor support which allows recording of thermal data
with 32x24 resolution excluding 2 lines of coefficient data that is used by
userspace to render processed frames.
Required Properties:
- compatible : Must be "melexis,mlx90640"
- reg : i2c address of the device
Example:
i2c0@1c22000 {
...
mlx90640@33 {
compatible = "melexis,mlx90640";
reg = <0x33>;
};
...
};

38
Documentation/devicetree/bindings/media/i2c/mt9m001.txt 100644
View File

@ -0,0 +1,38 @@
MT9M001: 1/2-Inch Megapixel Digital Image Sensor
The MT9M001 is an SXGA-format with a 1/2-inch CMOS active-pixel digital
image sensor. It is programmable through I2C interface.
Required Properties:
- compatible: shall be "onnn,mt9m001".
- clocks: reference to the master clock into sensor
Optional Properties:
- reset-gpios: GPIO handle which is connected to the reset pin of the chip.
Active low.
- standby-gpios: GPIO handle which is connected to the standby pin of the chip.
Active high.
The device node must contain one 'port' child node with one 'endpoint' child
sub-node for its digital output video port, in accordance with the video
interface bindings defined in:
Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
&i2c1 {
camera-sensor@5d {
compatible = "onnn,mt9m001";
reg = <0x5d>;
reset-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
standby-gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
clocks = <&camera_clk>;
port {
mt9m001_out: endpoint {
remote-endpoint = <&vcap_in>;
};
};
};
};

6
Documentation/devicetree/bindings/media/i2c/ov5645.txt
View File

@ -26,9 +26,9 @@ Example:
&i2c1 {
...
ov5645: ov5645@78 {
ov5645: ov5645@3c {
compatible = "ovti,ov5645";
reg = <0x78>;
reg = <0x3c>;
enable-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio5 20 GPIO_ACTIVE_LOW>;
@ -37,7 +37,7 @@ Example:
clocks = <&clks 200>;
clock-names = "xclk";
clock-frequency = <23880000>;
clock-frequency = <24000000>;
vdddo-supply = <&camera_dovdd_1v8>;
vdda-supply = <&camera_avdd_2v8>;

45
Documentation/devicetree/bindings/media/imx7-csi.txt 100644
View File

@ -0,0 +1,45 @@
Freescale i.MX7 CMOS Sensor Interface
=====================================
csi node
--------
This is device node for the CMOS Sensor Interface (CSI) which enables the chip
to connect directly to external CMOS image sensors.
Required properties:
- compatible : "fsl,imx7-csi";
- reg : base address and length of the register set for the device;
- interrupts : should contain CSI interrupt;
- clocks : list of clock specifiers, see
Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
- clock-names : must contain "axi", "mclk" and "dcic" entries, matching
entries in the clock property;
The device node shall contain one 'port' child node with one child 'endpoint'
node, according to the bindings defined in:
Documentation/devicetree/bindings/media/video-interfaces.txt.
In the following example a remote endpoint is a video multiplexer.
example:
csi: csi@30710000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx7-csi";
reg = <0x30710000 0x10000>;
interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_CLK_DUMMY>,
<&clks IMX7D_CSI_MCLK_ROOT_CLK>,
<&clks IMX7D_CLK_DUMMY>;
clock-names = "axi", "mclk", "dcic";
port {
csi_from_csi_mux: endpoint {
remote-endpoint = <&csi_mux_to_csi>;
};
};
};

90
Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt 100644
View File

@ -0,0 +1,90 @@
Freescale i.MX7 Mipi CSI2
=========================
mipi_csi2 node
--------------
This is the device node for the MIPI CSI-2 receiver core in i.MX7 SoC. It is
compatible with previous version of Samsung D-phy.
Required properties:
- compatible : "fsl,imx7-mipi-csi2";
- reg : base address and length of the register set for the device;
- interrupts : should contain MIPI CSIS interrupt;
- clocks : list of clock specifiers, see
Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
- clock-names : must contain "pclk", "wrap" and "phy" entries, matching
entries in the clock property;
- power-domains : a phandle to the power domain, see
Documentation/devicetree/bindings/power/power_domain.txt for details.
- reset-names : should include following entry "mrst";
- resets : a list of phandle, should contain reset entry of
reset-names;
- phy-supply : from the generic phy bindings, a phandle to a regulator that
provides power to MIPI CSIS core;
Optional properties:
- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
value when this property is not specified is 166 MHz;
- fsl,csis-hs-settle : differential receiver (HS-RX) settle time;
The device node should contain two 'port' child nodes with one child 'endpoint'
node, according to the bindings defined in:
Documentation/devicetree/bindings/ media/video-interfaces.txt.
The following are properties specific to those nodes.
port node
---------
- reg : (required) can take the values 0 or 1, where 0 shall be
related to the sink port and port 1 shall be the source
one;
endpoint node
-------------
- data-lanes : (required) an array specifying active physical MIPI-CSI2
data input lanes and their mapping to logical lanes; this
shall only be applied to port 0 (sink port), the array's
content is unused only its length is meaningful,
in this case the maximum length supported is 2;
example:
mipi_csi: mipi-csi@30750000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx7-mipi-csi2";
reg = <0x30750000 0x10000>;
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_IPG_ROOT_CLK>,
<&clks IMX7D_MIPI_CSI_ROOT_CLK>,
<&clks IMX7D_MIPI_DPHY_ROOT_CLK>;
clock-names = "pclk", "wrap", "phy";
clock-frequency = <166000000>;
power-domains = <&pgc_mipi_phy>;
phy-supply = <&reg_1p0d>;
resets = <&src IMX7_RESET_MIPI_PHY_MRST>;
reset-names = "mrst";
fsl,csis-hs-settle = <3>;
port@0 {
reg = <0>;
mipi_from_sensor: endpoint {
remote-endpoint = <&ov2680_to_mipi>;
data-lanes = <1>;
};
};
port@1 {
reg = <1>;
mipi_vc0_to_csi_mux: endpoint {
remote-endpoint = <&csi_mux_from_mipi_vc0>;
};
};
};

13
Documentation/devicetree/bindings/media/mediatek-vcodec.txt
View File

@ -66,6 +66,15 @@ vcodec_dec: vcodec@16000000 {
"vencpll",
"venc_lt_sel",
"vdec_bus_clk_src";
assigned-clocks = <&topckgen CLK_TOP_VENC_LT_SEL>,
<&topckgen CLK_TOP_CCI400_SEL>,
<&topckgen CLK_TOP_VDEC_SEL>,
<&apmixedsys CLK_APMIXED_VCODECPLL>,
<&apmixedsys CLK_APMIXED_VENCPLL>;
assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL_370P5>,
<&topckgen CLK_TOP_UNIVPLL_D2>,
<&topckgen CLK_TOP_VCODECPLL>;
assigned-clock-rates = <0>, <0>, <0>, <1482000000>, <800000000>;
};
vcodec_enc: vcodec@18002000 {
@ -105,4 +114,8 @@ vcodec_dec: vcodec@16000000 {
"venc_sel",
"venc_lt_sel_src",
"venc_lt_sel";
assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>,
<&topckgen CLK_TOP_VENC_LT_SEL>;
assigned-clock-parents = <&topckgen CLK_TOP_VENCPLL_D2>,
<&topckgen CLK_TOP_UNIVPLL1_D2>;
};

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