Merge branch 'master' into fixes
We have a fix to apply on top of commit 96d4f267e4 ("Remove 'type'
argument from access_ok() function"), so merge master to get it.
This commit is contained in:
Michael Ellerman
commit
d538d94f0c
|
|
@ -15,6 +15,7 @@
|
|||
*.bin
|
||||
*.bz2
|
||||
*.c.[012]*.*
|
||||
*.dt.yaml
|
||||
*.dtb
|
||||
*.dtb.S
|
||||
*.dwo
|
||||
|
|
|
|||
|
|
@ -244,7 +244,7 @@ Description:
|
|||
|
||||
What: /sys/block/<disk>/queue/zoned
|
||||
Date: September 2016
|
||||
Contact: Damien Le Moal <damien.lemoal@hgst.com>
|
||||
Contact: Damien Le Moal <damien.lemoal@wdc.com>
|
||||
Description:
|
||||
zoned indicates if the device is a zoned block device
|
||||
and the zone model of the device if it is indeed zoned.
|
||||
|
|
@ -259,6 +259,14 @@ Description:
|
|||
zone commands, they will be treated as regular block
|
||||
devices and zoned will report "none".
|
||||
|
||||
What: /sys/block/<disk>/queue/nr_zones
|
||||
Date: November 2018
|
||||
Contact: Damien Le Moal <damien.lemoal@wdc.com>
|
||||
Description:
|
||||
nr_zones indicates the total number of zones of a zoned block
|
||||
device ("host-aware" or "host-managed" zone model). For regular
|
||||
block devices, the value is always 0.
|
||||
|
||||
What: /sys/block/<disk>/queue/chunk_sectors
|
||||
Date: September 2016
|
||||
Contact: Hannes Reinecke <hare@suse.com>
|
||||
|
|
@ -268,6 +276,6 @@ Description:
|
|||
indicates the size in 512B sectors of the RAID volume
|
||||
stripe segment. For a zoned block device, either
|
||||
host-aware or host-managed, chunk_sectors indicates the
|
||||
size of 512B sectors of the zones of the device, with
|
||||
size in 512B sectors of the zones of the device, with
|
||||
the eventual exception of the last zone of the device
|
||||
which may be smaller.
|
||||
|
|
|
|||
|
|
@ -98,3 +98,35 @@ Description:
|
|||
The backing_dev file is read-write and set up backing
|
||||
device for zram to write incompressible pages.
|
||||
For using, user should enable CONFIG_ZRAM_WRITEBACK.
|
||||
|
||||
What: /sys/block/zram<id>/idle
|
||||
Date: November 2018
|
||||
Contact: Minchan Kim <minchan@kernel.org>
|
||||
Description:
|
||||
idle file is write-only and mark zram slot as idle.
|
||||
If system has mounted debugfs, user can see which slots
|
||||
are idle via /sys/kernel/debug/zram/zram<id>/block_state
|
||||
|
||||
What: /sys/block/zram<id>/writeback
|
||||
Date: November 2018
|
||||
Contact: Minchan Kim <minchan@kernel.org>
|
||||
Description:
|
||||
The writeback file is write-only and trigger idle and/or
|
||||
huge page writeback to backing device.
|
||||
|
||||
What: /sys/block/zram<id>/bd_stat
|
||||
Date: November 2018
|
||||
Contact: Minchan Kim <minchan@kernel.org>
|
||||
Description:
|
||||
The bd_stat file is read-only and represents backing device's
|
||||
statistics (bd_count, bd_reads, bd_writes) in a format
|
||||
similar to block layer statistics file format.
|
||||
|
||||
What: /sys/block/zram<id>/writeback_limit
|
||||
Date: November 2018
|
||||
Contact: Minchan Kim <minchan@kernel.org>
|
||||
Description:
|
||||
The writeback_limit file is read-write and specifies the maximum
|
||||
amount of writeback ZRAM can do. The limit could be changed
|
||||
in run time and "0" means disable the limit.
|
||||
No limit is the initial state.
|
||||
|
|
|
|||
|
|
@ -21,6 +21,15 @@ Description: Holds a comma separated list of device unique_ids that
|
|||
If a device is authorized automatically during boot its
|
||||
boot attribute is set to 1.
|
||||
|
||||
What: /sys/bus/thunderbolt/devices/.../domainX/iommu_dma_protection
|
||||
Date: Mar 2019
|
||||
KernelVersion: 4.21
|
||||
Contact: thunderbolt-software@lists.01.org
|
||||
Description: This attribute tells whether the system uses IOMMU
|
||||
for DMA protection. Value of 1 means IOMMU is used 0 means
|
||||
it is not (DMA protection is solely based on Thunderbolt
|
||||
security levels).
|
||||
|
||||
What: /sys/bus/thunderbolt/devices/.../domainX/security
|
||||
Date: Sep 2017
|
||||
KernelVersion: 4.13
|
||||
|
|
|
|||
|
|
@ -92,6 +92,15 @@ Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
|
|||
Description:
|
||||
Controls the number of trials to find a victim segment.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/migration_granularity
|
||||
Date: October 2018
|
||||
Contact: "Chao Yu" <yuchao0@huawei.com>
|
||||
Description:
|
||||
Controls migration granularity of garbage collection on large
|
||||
section, it can let GC move partial segment{s} of one section
|
||||
in one GC cycle, so that dispersing heavy overhead GC to
|
||||
multiple lightweight one.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/dir_level
|
||||
Date: March 2014
|
||||
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
|
||||
|
|
|
|||
|
|
@ -58,15 +58,6 @@ specify the ``GFP_`` flags (see kmalloc()) for the allocation (the
|
|||
implementation may choose to ignore flags that affect the location of
|
||||
the returned memory, like GFP_DMA).
|
||||
|
||||
::
|
||||
|
||||
void *
|
||||
dma_zalloc_coherent(struct device *dev, size_t size,
|
||||
dma_addr_t *dma_handle, gfp_t flag)
|
||||
|
||||
Wraps dma_alloc_coherent() and also zeroes the returned memory if the
|
||||
allocation attempt succeeded.
|
||||
|
||||
::
|
||||
|
||||
void
|
||||
|
|
@ -717,12 +708,15 @@ dma-api/num_errors The number in this file shows how many
|
|||
dma-api/min_free_entries This read-only file can be read to get the
|
||||
minimum number of free dma_debug_entries the
|
||||
allocator has ever seen. If this value goes
|
||||
down to zero the code will disable itself
|
||||
because it is not longer reliable.
|
||||
down to zero the code will attempt to increase
|
||||
nr_total_entries to compensate.
|
||||
|
||||
dma-api/num_free_entries The current number of free dma_debug_entries
|
||||
in the allocator.
|
||||
|
||||
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
|
||||
to limit the debug output to requests from that
|
||||
particular driver. Write an empty string to
|
||||
|
|
@ -742,10 +736,15 @@ driver filter at boot time. The debug code will only print errors for that
|
|||
driver afterwards. This filter can be disabled or changed later using debugfs.
|
||||
|
||||
When the code disables itself at runtime this is most likely because it ran
|
||||
out of dma_debug_entries. These entries are preallocated at boot. The number
|
||||
of preallocated entries is defined per architecture. If it is too low for you
|
||||
boot with 'dma_debug_entries=<your_desired_number>' to overwrite the
|
||||
architectural default.
|
||||
out of dma_debug_entries and was unable to allocate more on-demand. 65536
|
||||
entries are preallocated at boot - if this is too low for you boot with
|
||||
'dma_debug_entries=<your_desired_number>' to overwrite the default. Note
|
||||
that the code allocates entries in batches, so the exact number of
|
||||
preallocated entries may be greater than the actual number requested. The
|
||||
code will print to the kernel log each time it has dynamically allocated
|
||||
as many entries as were initially preallocated. This is to indicate that a
|
||||
larger preallocation size may be appropriate, or if it happens continually
|
||||
that a driver may be leaking mappings.
|
||||
|
||||
::
|
||||
|
||||
|
|
|
|||
|
|
@ -31,14 +31,13 @@
|
|||
#define YBLANK 38
|
||||
#define XOFFSET 8
|
||||
#define XPULSE 144
|
||||
#define YOFFSET (63+3)
|
||||
#define YPULSE (63+6)
|
||||
#define YOFFSET 3
|
||||
#define YPULSE 6
|
||||
#define DPI 72
|
||||
#define VFREQ 60 /* Hz */
|
||||
#define TIMING_NAME "Linux XGA"
|
||||
#define ESTABLISHED_TIMING2_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
|
||||
#define HSYNC_POL 0
|
||||
#define VSYNC_POL 0
|
||||
#define CRC 0x55
|
||||
|
||||
#include "edid.S"
|
||||
|
|
|
|||
|
|
@ -31,14 +31,13 @@
|
|||
#define YBLANK 42
|
||||
#define XOFFSET 48
|
||||
#define XPULSE 112
|
||||
#define YOFFSET (63+1)
|
||||
#define YPULSE (63+3)
|
||||
#define YOFFSET 1
|
||||
#define YPULSE 3
|
||||
#define DPI 72
|
||||
#define VFREQ 60 /* Hz */
|
||||
#define TIMING_NAME "Linux SXGA"
|
||||
/* No ESTABLISHED_TIMINGx_BITS */
|
||||
#define HSYNC_POL 1
|
||||
#define VSYNC_POL 1
|
||||
#define CRC 0xa0
|
||||
|
||||
#include "edid.S"
|
||||
|
|
|
|||
|
|
@ -31,14 +31,13 @@
|
|||
#define YBLANK 50
|
||||
#define XOFFSET 64
|
||||
#define XPULSE 192
|
||||
#define YOFFSET (63+1)
|
||||
#define YPULSE (63+3)
|
||||
#define YOFFSET 1
|
||||
#define YPULSE 3
|
||||
#define DPI 72
|
||||
#define VFREQ 60 /* Hz */
|
||||
#define TIMING_NAME "Linux UXGA"
|
||||
/* No ESTABLISHED_TIMINGx_BITS */
|
||||
#define HSYNC_POL 1
|
||||
#define VSYNC_POL 1
|
||||
#define CRC 0x9d
|
||||
|
||||
#include "edid.S"
|
||||
|
|
|
|||
|
|
@ -31,14 +31,13 @@
|
|||
#define YBLANK 39
|
||||
#define XOFFSET 104
|
||||
#define XPULSE 176
|
||||
#define YOFFSET (63+3)
|
||||
#define YPULSE (63+6)
|
||||
#define YOFFSET 3
|
||||
#define YPULSE 6
|
||||
#define DPI 96
|
||||
#define VFREQ 60 /* Hz */
|
||||
#define TIMING_NAME "Linux WSXGA"
|
||||
/* No ESTABLISHED_TIMINGx_BITS */
|
||||
#define HSYNC_POL 1
|
||||
#define VSYNC_POL 1
|
||||
#define CRC 0x26
|
||||
|
||||
#include "edid.S"
|
||||
|
|
|
|||
|
|
@ -31,14 +31,13 @@
|
|||
#define YBLANK 45
|
||||
#define XOFFSET 88
|
||||
#define XPULSE 44
|
||||
#define YOFFSET (63+4)
|
||||
#define YPULSE (63+5)
|
||||
#define YOFFSET 4
|
||||
#define YPULSE 5
|
||||
#define DPI 96
|
||||
#define VFREQ 60 /* Hz */
|
||||
#define TIMING_NAME "Linux FHD"
|
||||
/* No ESTABLISHED_TIMINGx_BITS */
|
||||
#define HSYNC_POL 1
|
||||
#define VSYNC_POL 1
|
||||
#define CRC 0x05
|
||||
|
||||
#include "edid.S"
|
||||
|
|
|
|||
|
|
@ -28,14 +28,13 @@
|
|||
#define YBLANK 28
|
||||
#define XOFFSET 40
|
||||
#define XPULSE 128
|
||||
#define YOFFSET (63+1)
|
||||
#define YPULSE (63+4)
|
||||
#define YOFFSET 1
|
||||
#define YPULSE 4
|
||||
#define DPI 72
|
||||
#define VFREQ 60 /* Hz */
|
||||
#define TIMING_NAME "Linux SVGA"
|
||||
#define ESTABLISHED_TIMING1_BITS 0x01 /* Bit 0: 800x600 @ 60Hz */
|
||||
#define HSYNC_POL 1
|
||||
#define VSYNC_POL 1
|
||||
#define CRC 0xc2
|
||||
|
||||
#include "edid.S"
|
||||
|
|
|
|||
|
|
@ -45,14 +45,5 @@ EDID:
|
|||
|
||||
#define YPIX vdisp
|
||||
#define YBLANK vtotal-vdisp
|
||||
#define YOFFSET (63+(vsyncstart-vdisp))
|
||||
#define YPULSE (63+(vsyncend-vsyncstart))
|
||||
|
||||
The CRC value in the last line
|
||||
#define CRC 0x55
|
||||
also is a bit tricky. After a first version of the binary data set is
|
||||
created, it must be checked with the "edid-decode" utility which will
|
||||
most probably complain about a wrong CRC. Fortunately, the utility also
|
||||
displays the correct CRC which must then be inserted into the source
|
||||
file. After the make procedure is repeated, the EDID data set is ready
|
||||
to be used.
|
||||
#define YOFFSET vsyncstart-vdisp
|
||||
#define YPULSE vsyncend-vsyncstart
|
||||
|
|
|
|||
|
|
@ -15,10 +15,21 @@ clean:
|
|||
%.o: %.S
|
||||
@cc -c $^
|
||||
|
||||
%.bin: %.o
|
||||
%.bin.nocrc: %.o
|
||||
@objcopy -Obinary $^ $@
|
||||
|
||||
%.bin.ihex: %.o
|
||||
%.crc: %.bin.nocrc
|
||||
@list=$$(for i in `seq 1 127`; do head -c$$i $^ | tail -c1 \
|
||||
| hexdump -v -e '/1 "%02X+"'; done); \
|
||||
echo "ibase=16;100-($${list%?})%100" | bc >$@
|
||||
|
||||
%.p: %.crc %.S
|
||||
@cc -c -DCRC="$$(cat $*.crc)" -o $@ $*.S
|
||||
|
||||
%.bin: %.p
|
||||
@objcopy -Obinary $^ $@
|
||||
|
||||
%.bin.ihex: %.p
|
||||
@objcopy -Oihex $^ $@
|
||||
@dos2unix $@ 2>/dev/null
|
||||
|
||||
|
|
|
|||
|
|
@ -47,9 +47,11 @@
|
|||
#define mfgname2id(v1,v2,v3) \
|
||||
((((v1-'@')&0x1f)<<10)+(((v2-'@')&0x1f)<<5)+((v3-'@')&0x1f))
|
||||
#define swap16(v1) ((v1>>8)+((v1&0xff)<<8))
|
||||
#define lsbs2(v1,v2) (((v1&0x0f)<<4)+(v2&0x0f))
|
||||
#define msbs2(v1,v2) ((((v1>>8)&0x0f)<<4)+((v2>>8)&0x0f))
|
||||
#define msbs4(v1,v2,v3,v4) \
|
||||
(((v1&0x03)>>2)+((v2&0x03)>>4)+((v3&0x03)>>6)+((v4&0x03)>>8))
|
||||
((((v1>>8)&0x03)<<6)+(((v2>>8)&0x03)<<4)+\
|
||||
(((v3>>4)&0x03)<<2)+((v4>>4)&0x03))
|
||||
#define pixdpi2mm(pix,dpi) ((pix*25)/dpi)
|
||||
#define xsize pixdpi2mm(XPIX,DPI)
|
||||
#define ysize pixdpi2mm(YPIX,DPI)
|
||||
|
|
@ -200,9 +202,9 @@ y_msbs: .byte msbs2(YPIX,YBLANK)
|
|||
x_snc_off_lsb: .byte XOFFSET&0xff
|
||||
/* Horizontal sync pulse width pixels 8 lsbits (0-1023) */
|
||||
x_snc_pls_lsb: .byte XPULSE&0xff
|
||||
/* Bits 7-4 Vertical sync offset lines 4 lsbits -63)
|
||||
Bits 3-0 Vertical sync pulse width lines 4 lsbits -63) */
|
||||
y_snc_lsb: .byte ((YOFFSET-63)<<4)+(YPULSE-63)
|
||||
/* Bits 7-4 Vertical sync offset lines 4 lsbits (0-63)
|
||||
Bits 3-0 Vertical sync pulse width lines 4 lsbits (0-63) */
|
||||
y_snc_lsb: .byte lsbs2(YOFFSET, YPULSE)
|
||||
/* Bits 7-6 Horizontal sync offset pixels 2 msbits
|
||||
Bits 5-4 Horizontal sync pulse width pixels 2 msbits
|
||||
Bits 3-2 Vertical sync offset lines 2 msbits
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
# Makefile for Sphinx documentation
|
||||
#
|
||||
|
||||
subdir-y :=
|
||||
subdir-y := devicetree/bindings/
|
||||
|
||||
# You can set these variables from the command line.
|
||||
SPHINXBUILD = sphinx-build
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ If you want to use SELinux, chances are you will want
|
|||
to use the distro-provided policies, or install the
|
||||
latest reference policy release from
|
||||
|
||||
http://oss.tresys.com/projects/refpolicy
|
||||
https://github.com/SELinuxProject/refpolicy
|
||||
|
||||
However, if you want to install a dummy policy for
|
||||
testing, you can do using ``mdp`` provided under
|
||||
|
|
|
|||
|
|
@ -818,6 +818,10 @@ Smack supports some mount options:
|
|||
specifies a label to which all labels set on the
|
||||
filesystem must have read access. Not yet enforced.
|
||||
|
||||
smackfstransmute=label:
|
||||
behaves exactly like smackfsroot except that it also
|
||||
sets the transmute flag on the root of the mount
|
||||
|
||||
These mount options apply to all file system types.
|
||||
|
||||
Smack auditing
|
||||
|
|
|
|||
|
|
@ -56,11 +56,13 @@ v1 is available under Documentation/cgroup-v1/.
|
|||
5-3-3-2. IO Latency Interface Files
|
||||
5-4. PID
|
||||
5-4-1. PID Interface Files
|
||||
5-5. Device
|
||||
5-6. RDMA
|
||||
5-6-1. RDMA Interface Files
|
||||
5-7. Misc
|
||||
5-7-1. perf_event
|
||||
5-5. Cpuset
|
||||
5.5-1. Cpuset Interface Files
|
||||
5-6. Device
|
||||
5-7. RDMA
|
||||
5-7-1. RDMA Interface Files
|
||||
5-8. Misc
|
||||
5-8-1. perf_event
|
||||
5-N. Non-normative information
|
||||
5-N-1. CPU controller root cgroup process behaviour
|
||||
5-N-2. IO controller root cgroup process behaviour
|
||||
|
|
@ -1610,6 +1612,176 @@ through fork() or clone(). These will return -EAGAIN if the creation
|
|||
of a new process would cause a cgroup policy to be violated.
|
||||
|
||||
|
||||
Cpuset
|
||||
------
|
||||
|
||||
The "cpuset" controller provides a mechanism for constraining
|
||||
the CPU and memory node placement of tasks to only the resources
|
||||
specified in the cpuset interface files in a task's current cgroup.
|
||||
This is especially valuable on large NUMA systems where placing jobs
|
||||
on properly sized subsets of the systems with careful processor and
|
||||
memory placement to reduce cross-node memory access and contention
|
||||
can improve overall system performance.
|
||||
|
||||
The "cpuset" controller is hierarchical. That means the controller
|
||||
cannot use CPUs or memory nodes not allowed in its parent.
|
||||
|
||||
|
||||
Cpuset Interface Files
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
cpuset.cpus
|
||||
A read-write multiple values file which exists on non-root
|
||||
cpuset-enabled cgroups.
|
||||
|
||||
It lists the requested CPUs to be used by tasks within this
|
||||
cgroup. The actual list of CPUs to be granted, however, is
|
||||
subjected to constraints imposed by its parent and can differ
|
||||
from the requested CPUs.
|
||||
|
||||
The CPU numbers are comma-separated numbers or ranges.
|
||||
For example:
|
||||
|
||||
# cat cpuset.cpus
|
||||
0-4,6,8-10
|
||||
|
||||
An empty value indicates that the cgroup is using the same
|
||||
setting as the nearest cgroup ancestor with a non-empty
|
||||
"cpuset.cpus" or all the available CPUs if none is found.
|
||||
|
||||
The value of "cpuset.cpus" stays constant until the next update
|
||||
and won't be affected by any CPU hotplug events.
|
||||
|
||||
cpuset.cpus.effective
|
||||
A read-only multiple values file which exists on all
|
||||
cpuset-enabled cgroups.
|
||||
|
||||
It lists the onlined CPUs that are actually granted to this
|
||||
cgroup by its parent. These CPUs are allowed to be used by
|
||||
tasks within the current cgroup.
|
||||
|
||||
If "cpuset.cpus" is empty, the "cpuset.cpus.effective" file shows
|
||||
all the CPUs from the parent cgroup that can be available to
|
||||
be used by this cgroup. Otherwise, it should be a subset of
|
||||
"cpuset.cpus" unless none of the CPUs listed in "cpuset.cpus"
|
||||
can be granted. In this case, it will be treated just like an
|
||||
empty "cpuset.cpus".
|
||||
|
||||
Its value will be affected by CPU hotplug events.
|
||||
|
||||
cpuset.mems
|
||||
A read-write multiple values file which exists on non-root
|
||||
cpuset-enabled cgroups.
|
||||
|
||||
It lists the requested memory nodes to be used by tasks within
|
||||
this cgroup. The actual list of memory nodes granted, however,
|
||||
is subjected to constraints imposed by its parent and can differ
|
||||
from the requested memory nodes.
|
||||
|
||||
The memory node numbers are comma-separated numbers or ranges.
|
||||
For example:
|
||||
|
||||
# cat cpuset.mems
|
||||
0-1,3
|
||||
|
||||
An empty value indicates that the cgroup is using the same
|
||||
setting as the nearest cgroup ancestor with a non-empty
|
||||
"cpuset.mems" or all the available memory nodes if none
|
||||
is found.
|
||||
|
||||
The value of "cpuset.mems" stays constant until the next update
|
||||
and won't be affected by any memory nodes hotplug events.
|
||||
|
||||
cpuset.mems.effective
|
||||
A read-only multiple values file which exists on all
|
||||
cpuset-enabled cgroups.
|
||||
|
||||
It lists the onlined memory nodes that are actually granted to
|
||||
this cgroup by its parent. These memory nodes are allowed to
|
||||
be used by tasks within the current cgroup.
|
||||
|
||||
If "cpuset.mems" is empty, it shows all the memory nodes from the
|
||||
parent cgroup that will be available to be used by this cgroup.
|
||||
Otherwise, it should be a subset of "cpuset.mems" unless none of
|
||||
the memory nodes listed in "cpuset.mems" can be granted. In this
|
||||
case, it will be treated just like an empty "cpuset.mems".
|
||||
|
||||
Its value will be affected by memory nodes hotplug events.
|
||||
|
||||
cpuset.cpus.partition
|
||||
A read-write single value file which exists on non-root
|
||||
cpuset-enabled cgroups. This flag is owned by the parent cgroup
|
||||
and is not delegatable.
|
||||
|
||||
It accepts only the following input values when written to.
|
||||
|
||||
"root" - a paritition root
|
||||
"member" - a non-root member of a partition
|
||||
|
||||
When set to be a partition root, the current cgroup is the
|
||||
root of a new partition or scheduling domain that comprises
|
||||
itself and all its descendants except those that are separate
|
||||
partition roots themselves and their descendants. The root
|
||||
cgroup is always a partition root.
|
||||
|
||||
There are constraints on where a partition root can be set.
|
||||
It can only be set in a cgroup if all the following conditions
|
||||
are true.
|
||||
|
||||
1) The "cpuset.cpus" is not empty and the list of CPUs are
|
||||
exclusive, i.e. they are not shared by any of its siblings.
|
||||
2) The parent cgroup is a partition root.
|
||||
3) The "cpuset.cpus" is also a proper subset of the parent's
|
||||
"cpuset.cpus.effective".
|
||||
4) There is no child cgroups with cpuset enabled. This is for
|
||||
eliminating corner cases that have to be handled if such a
|
||||
condition is allowed.
|
||||
|
||||
Setting it to partition root will take the CPUs away from the
|
||||
effective CPUs of the parent cgroup. Once it is set, this
|
||||
file cannot be reverted back to "member" if there are any child
|
||||
cgroups with cpuset enabled.
|
||||
|
||||
A parent partition cannot distribute all its CPUs to its
|
||||
child partitions. There must be at least one cpu left in the
|
||||
parent partition.
|
||||
|
||||
Once becoming a partition root, changes to "cpuset.cpus" is
|
||||
generally allowed as long as the first condition above is true,
|
||||
the change will not take away all the CPUs from the parent
|
||||
partition and the new "cpuset.cpus" value is a superset of its
|
||||
children's "cpuset.cpus" values.
|
||||
|
||||
Sometimes, external factors like changes to ancestors'
|
||||
"cpuset.cpus" or cpu hotplug can cause the state of the partition
|
||||
root to change. On read, the "cpuset.sched.partition" file
|
||||
can show the following values.
|
||||
|
||||
"member" Non-root member of a partition
|
||||
"root" Partition root
|
||||
"root invalid" Invalid partition root
|
||||
|
||||
It is a partition root if the first 2 partition root conditions
|
||||
above are true and at least one CPU from "cpuset.cpus" is
|
||||
granted by the parent cgroup.
|
||||
|
||||
A partition root can become invalid if none of CPUs requested
|
||||
in "cpuset.cpus" can be granted by the parent cgroup or the
|
||||
parent cgroup is no longer a partition root itself. In this
|
||||
case, it is not a real partition even though the restriction
|
||||
of the first partition root condition above will still apply.
|
||||
The cpu affinity of all the tasks in the cgroup will then be
|
||||
associated with CPUs in the nearest ancestor partition.
|
||||
|
||||
An invalid partition root can be transitioned back to a
|
||||
real partition root if at least one of the requested CPUs
|
||||
can now be granted by its parent. In this case, the cpu
|
||||
affinity of all the tasks in the formerly invalid partition
|
||||
will be associated to the CPUs of the newly formed partition.
|
||||
Changing the partition state of an invalid partition root to
|
||||
"member" is always allowed even if child cpusets are present.
|
||||
|
||||
|
||||
Device controller
|
||||
-----------------
|
||||
|
||||
|
|
@ -1879,8 +2051,10 @@ following two functions.
|
|||
|
||||
wbc_init_bio(@wbc, @bio)
|
||||
Should be called for each bio carrying writeback data and
|
||||
associates the bio with the inode's owner cgroup. Can be
|
||||
called anytime between bio allocation and submission.
|
||||
associates the bio with the inode's owner cgroup and the
|
||||
corresponding request queue. This must be called after
|
||||
a queue (device) has been associated with the bio and
|
||||
before submission.
|
||||
|
||||
wbc_account_io(@wbc, @page, @bytes)
|
||||
Should be called for each data segment being written out.
|
||||
|
|
@ -1899,7 +2073,7 @@ the configuration, the bio may be executed at a lower priority and if
|
|||
the writeback session is holding shared resources, e.g. a journal
|
||||
entry, may lead to priority inversion. There is no one easy solution
|
||||
for the problem. Filesystems can try to work around specific problem
|
||||
cases by skipping wbc_init_bio() or using bio_associate_blkcg()
|
||||
cases by skipping wbc_init_bio() and using bio_associate_blkg()
|
||||
directly.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
.. _admin_devices:
|
||||
|
||||
Linux allocated devices (4.x+ version)
|
||||
======================================
|
||||
|
|
|
|||
|
|
@ -110,8 +110,8 @@ If your query set is big, you can batch them too::
|
|||
|
||||
~# cat query-batch-file > <debugfs>/dynamic_debug/control
|
||||
|
||||
A another way is to use wildcard. The match rule support ``*`` (matches
|
||||
zero or more characters) and ``?`` (matches exactly one character).For
|
||||
Another way is to use wildcards. The match rule supports ``*`` (matches
|
||||
zero or more characters) and ``?`` (matches exactly one character). For
|
||||
example, you can match all usb drivers::
|
||||
|
||||
~# echo "file drivers/usb/* +p" > <debugfs>/dynamic_debug/control
|
||||
|
|
@ -258,7 +258,7 @@ this boot parameter for debugging purposes.
|
|||
|
||||
If ``foo`` module is not built-in, ``foo.dyndbg`` will still be processed at
|
||||
boot time, without effect, but will be reprocessed when module is
|
||||
loaded later. ``dyndbg_query=`` and bare ``dyndbg=`` are only processed at
|
||||
loaded later. ``ddebug_query=`` and bare ``dyndbg=`` are only processed at
|
||||
boot.
|
||||
|
||||
|
||||
|
|
@ -301,7 +301,7 @@ The ``dyndbg`` option is a "fake" module parameter, which means:
|
|||
|
||||
For ``CONFIG_DYNAMIC_DEBUG`` kernels, any settings given at boot-time (or
|
||||
enabled by ``-DDEBUG`` flag during compilation) can be disabled later via
|
||||
the sysfs interface if the debug messages are no longer needed::
|
||||
the debugfs interface if the debug messages are no longer needed::
|
||||
|
||||
echo "module module_name -p" > <debugfs>/dynamic_debug/control
|
||||
|
||||
|
|
|
|||
|
|
@ -76,6 +76,7 @@ configure specific aspects of kernel behavior to your liking.
|
|||
thunderbolt
|
||||
LSM/index
|
||||
mm/index
|
||||
perf-security
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
|
|
|
|||
|
|
@ -331,7 +331,7 @@
|
|||
APC and your system crashes randomly.
|
||||
|
||||
apic= [APIC,X86] Advanced Programmable Interrupt Controller
|
||||
Change the output verbosity whilst booting
|
||||
Change the output verbosity while booting
|
||||
Format: { quiet (default) | verbose | debug }
|
||||
Change the amount of debugging information output
|
||||
when initialising the APIC and IO-APIC components.
|
||||
|
|
@ -486,10 +486,14 @@
|
|||
cut the overhead, others just disable the usage. So
|
||||
only cgroup_disable=memory is actually worthy}
|
||||
|
||||
cgroup_no_v1= [KNL] Disable one, multiple, all cgroup controllers in v1
|
||||
Format: { controller[,controller...] | "all" }
|
||||
cgroup_no_v1= [KNL] Disable cgroup controllers and named hierarchies in v1
|
||||
Format: { { controller | "all" | "named" }
|
||||
[,{ controller | "all" | "named" }...] }
|
||||
Like cgroup_disable, but only applies to cgroup v1;
|
||||
the blacklisted controllers remain available in cgroup2.
|
||||
"all" blacklists all controllers and "named" disables
|
||||
named mounts. Specifying both "all" and "named" disables
|
||||
all v1 hierarchies.
|
||||
|
||||
cgroup.memory= [KNL] Pass options to the cgroup memory controller.
|
||||
Format: <string>
|
||||
|
|
@ -1686,12 +1690,12 @@
|
|||
By default, super page will be supported if Intel IOMMU
|
||||
has the capability. With this option, super page will
|
||||
not be supported.
|
||||
ecs_off [Default Off]
|
||||
By default, extended context tables will be supported if
|
||||
the hardware advertises that it has support both for the
|
||||
extended tables themselves, and also PASID support. With
|
||||
this option set, extended tables will not be used even
|
||||
on hardware which claims to support them.
|
||||
sm_off [Default Off]
|
||||
By default, scalable mode will be supported if the
|
||||
hardware advertises that it has support for the scalable
|
||||
mode translation. With this option set, scalable mode
|
||||
will not be used even on hardware which claims to support
|
||||
it.
|
||||
tboot_noforce [Default Off]
|
||||
Do not force the Intel IOMMU enabled under tboot.
|
||||
By default, tboot will force Intel IOMMU on, which
|
||||
|
|
|
|||
|
|
@ -4,13 +4,13 @@
|
|||
Concepts overview
|
||||
=================
|
||||
|
||||
The memory management in Linux is complex system that evolved over the
|
||||
years and included more and more functionality to support variety of
|
||||
The memory management in Linux is a complex system that evolved over the
|
||||
years and included more and more functionality to support a variety of
|
||||
systems from MMU-less microcontrollers to supercomputers. The memory
|
||||
management for systems without MMU is called ``nommu`` and it
|
||||
management for systems without an MMU is called ``nommu`` and it
|
||||
definitely deserves a dedicated document, which hopefully will be
|
||||
eventually written. Yet, although some of the concepts are the same,
|
||||
here we assume that MMU is available and CPU can translate a virtual
|
||||
here we assume that an MMU is available and a CPU can translate a virtual
|
||||
address to a physical address.
|
||||
|
||||
.. contents:: :local:
|
||||
|
|
@ -21,10 +21,10 @@ Virtual Memory Primer
|
|||
The physical memory in a computer system is a limited resource and
|
||||
even for systems that support memory hotplug there is a hard limit on
|
||||
the amount of memory that can be installed. The physical memory is not
|
||||
necessary contiguous, it might be accessible as a set of distinct
|
||||
necessarily contiguous; it might be accessible as a set of distinct
|
||||
address ranges. Besides, different CPU architectures, and even
|
||||
different implementations of the same architecture have different view
|
||||
how these address ranges defined.
|
||||
different implementations of the same architecture have different views
|
||||
of how these address ranges are defined.
|
||||
|
||||
All this makes dealing directly with physical memory quite complex and
|
||||
to avoid this complexity a concept of virtual memory was developed.
|
||||
|
|
@ -48,8 +48,8 @@ appropriate kernel configuration option.
|
|||
|
||||
Each physical memory page can be mapped as one or more virtual
|
||||
pages. These mappings are described by page tables that allow
|
||||
translation from virtual address used by programs to real address in
|
||||
the physical memory. The page tables organized hierarchically.
|
||||
translation from a virtual address used by programs to the physical
|
||||
memory address. The page tables are organized hierarchically.
|
||||
|
||||
The tables at the lowest level of the hierarchy contain physical
|
||||
addresses of actual pages used by the software. The tables at higher
|
||||
|
|
@ -121,8 +121,8 @@ Nodes
|
|||
Many multi-processor machines are NUMA - Non-Uniform Memory Access -
|
||||
systems. In such systems the memory is arranged into banks that have
|
||||
different access latency depending on the "distance" from the
|
||||
processor. Each bank is referred as `node` and for each node Linux
|
||||
constructs an independent memory management subsystem. A node has it's
|
||||
processor. Each bank is referred to as a `node` and for each node Linux
|
||||
constructs an independent memory management subsystem. A node has its
|
||||
own set of zones, lists of free and used pages and various statistics
|
||||
counters. You can find more details about NUMA in
|
||||
:ref:`Documentation/vm/numa.rst <numa>` and in
|
||||
|
|
@ -149,9 +149,9 @@ for program's stack and heap or by explicit calls to mmap(2) system
|
|||
call. Usually, the anonymous mappings only define virtual memory areas
|
||||
that the program is allowed to access. The read accesses will result
|
||||
in creation of a page table entry that references a special physical
|
||||
page filled with zeroes. When the program performs a write, regular
|
||||
page filled with zeroes. When the program performs a write, a regular
|
||||
physical page will be allocated to hold the written data. The page
|
||||
will be marked dirty and if the kernel will decide to repurpose it,
|
||||
will be marked dirty and if the kernel decides to repurpose it,
|
||||
the dirty page will be swapped out.
|
||||
|
||||
Reclaim
|
||||
|
|
@ -181,8 +181,8 @@ pressure.
|
|||
The process of freeing the reclaimable physical memory pages and
|
||||
repurposing them is called (surprise!) `reclaim`. Linux can reclaim
|
||||
pages either asynchronously or synchronously, depending on the state
|
||||
of the system. When system is not loaded, most of the memory is free
|
||||
and allocation request will be satisfied immediately from the free
|
||||
of the system. When the system is not loaded, most of the memory is free
|
||||
and allocation requests will be satisfied immediately from the free
|
||||
pages supply. As the load increases, the amount of the free pages goes
|
||||
down and when it reaches a certain threshold (high watermark), an
|
||||
allocation request will awaken the ``kswapd`` daemon. It will
|
||||
|
|
@ -190,7 +190,7 @@ asynchronously scan memory pages and either just free them if the data
|
|||
they contain is available elsewhere, or evict to the backing storage
|
||||
device (remember those dirty pages?). As memory usage increases even
|
||||
more and reaches another threshold - min watermark - an allocation
|
||||
will trigger the `direct reclaim`. In this case allocation is stalled
|
||||
will trigger `direct reclaim`. In this case allocation is stalled
|
||||
until enough memory pages are reclaimed to satisfy the request.
|
||||
|
||||
Compaction
|
||||
|
|
@ -200,7 +200,7 @@ As the system runs, tasks allocate and free the memory and it becomes
|
|||
fragmented. Although with virtual memory it is possible to present
|
||||
scattered physical pages as virtually contiguous range, sometimes it is
|
||||
necessary to allocate large physically contiguous memory areas. Such
|
||||
need may arise, for instance, when a device driver requires large
|
||||
need may arise, for instance, when a device driver requires a large
|
||||
buffer for DMA, or when THP allocates a huge page. Memory `compaction`
|
||||
addresses the fragmentation issue. This mechanism moves occupied pages
|
||||
from the lower part of a memory zone to free pages in the upper part
|
||||
|
|
@ -208,15 +208,16 @@ of the zone. When a compaction scan is finished free pages are grouped
|
|||
together at the beginning of the zone and allocations of large
|
||||
physically contiguous areas become possible.
|
||||
|
||||
Like reclaim, the compaction may happen asynchronously in ``kcompactd``
|
||||
daemon or synchronously as a result of memory allocation request.
|
||||
Like reclaim, the compaction may happen asynchronously in the ``kcompactd``
|
||||
daemon or synchronously as a result of a memory allocation request.
|
||||
|
||||
OOM killer
|
||||
==========
|
||||
|
||||
It may happen, that on a loaded machine memory will be exhausted. When
|
||||
the kernel detects that the system runs out of memory (OOM) it invokes
|
||||
`OOM killer`. Its mission is simple: all it has to do is to select a
|
||||
task to sacrifice for the sake of the overall system health. The
|
||||
selected task is killed in a hope that after it exits enough memory
|
||||
will be freed to continue normal operation.
|
||||
It is possible that on a loaded machine memory will be exhausted and the
|
||||
kernel will be unable to reclaim enough memory to continue to operate. In
|
||||
order to save the rest of the system, it invokes the `OOM killer`.
|
||||
|
||||
The `OOM killer` selects a task to sacrifice for the sake of the overall
|
||||
system health. The selected task is killed in a hope that after it exits
|
||||
enough memory will be freed to continue normal operation.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,97 @@
|
|||
.. _perf_security:
|
||||
|
||||
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]_ .
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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 unprivileged users
|
||||
-----------------------------------
|
||||
|
||||
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.
|
||||
|
||||
>=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.
|
||||
|
||||
>=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.
|
||||
|
||||
>=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.
|
||||
|
||||
Bibliography
|
||||
------------
|
||||
|
||||
.. [1] `<https://lwn.net/Articles/337493/>`_
|
||||
.. [2] `<http://man7.org/linux/man-pages/man2/perf_event_open.2.html>`_
|
||||
.. [3] `<http://web.eece.maine.edu/~vweaver/projects/perf_events/>`_
|
||||
.. [4] `<https://perf.wiki.kernel.org/index.php/Main_Page>`_
|
||||
.. [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>`_
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ those errors are correctable.
|
|||
Types of errors
|
||||
---------------
|
||||
|
||||
Most mechanisms used on modern systems use use technologies like Hamming
|
||||
Most mechanisms used on modern systems use technologies like Hamming
|
||||
Codes that allow error correction when the number of errors on a bit packet
|
||||
is below a threshold. If the number of errors is above, those mechanisms
|
||||
can indicate with a high degree of confidence that an error happened, but
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ only valid reason for deferring the publication of a fix is to accommodate
|
|||
the logistics of QA and large scale rollouts which require release
|
||||
coordination.
|
||||
|
||||
Whilst embargoed information may be shared with trusted individuals in
|
||||
While embargoed information may be shared with trusted individuals in
|
||||
order to develop a fix, such information will not be published alongside
|
||||
the fix or on any other disclosure channel without the permission of the
|
||||
reporter. This includes but is not limited to the original bug report
|
||||
|
|
|
|||
|
|
@ -133,6 +133,26 @@ If the user still wants to connect the device they can either approve
|
|||
the device without a key or write a new key and write 1 to the
|
||||
``authorized`` file to get the new key stored on the device NVM.
|
||||
|
||||
DMA protection utilizing IOMMU
|
||||
------------------------------
|
||||
Recent systems from 2018 and forward with Thunderbolt ports may natively
|
||||
support IOMMU. This means that Thunderbolt security is handled by an IOMMU
|
||||
so connected devices cannot access memory regions outside of what is
|
||||
allocated for them by drivers. When Linux is running on such system it
|
||||
automatically enables IOMMU if not enabled by the user already. These
|
||||
systems can be identified by reading ``1`` from
|
||||
``/sys/bus/thunderbolt/devices/domainX/iommu_dma_protection`` attribute.
|
||||
|
||||
The driver does not do anything special in this case but because DMA
|
||||
protection is handled by the IOMMU, security levels (if set) are
|
||||
redundant. For this reason some systems ship with security level set to
|
||||
``none``. Other systems have security level set to ``user`` in order to
|
||||
support downgrade to older OS, so users who want to automatically
|
||||
authorize devices when IOMMU DMA protection is enabled can use the
|
||||
following ``udev`` rule::
|
||||
|
||||
ACTION=="add", SUBSYSTEM=="thunderbolt", ATTRS{iommu_dma_protection}=="1", ATTR{authorized}=="0", ATTR{authorized}="1"
|
||||
|
||||
Upgrading NVM on Thunderbolt device or host
|
||||
-------------------------------------------
|
||||
Since most of the functionality is handled in firmware running on a
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ tagged list.
|
|||
The boot loader must pass at a minimum the size and location of the
|
||||
system memory, and the root filesystem location. The dtb must be
|
||||
placed in a region of memory where the kernel decompressor will not
|
||||
overwrite it, whilst remaining within the region which will be covered
|
||||
overwrite it, while remaining within the region which will be covered
|
||||
by the kernel's low-memory mapping.
|
||||
|
||||
A safe location is just above the 128MiB boundary from start of RAM.
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ out s3c2410 API, then here are some notes on the process.
|
|||
as they have the same arguments, and can either take the pin specific
|
||||
values, or the more generic special-function-number arguments.
|
||||
|
||||
3) s3c2410_gpio_pullup() changes have the problem that whilst the
|
||||
3) s3c2410_gpio_pullup() changes have the problem that while the
|
||||
s3c2410_gpio_pullup(x, 1) can be easily translated to the
|
||||
s3c_gpio_setpull(x, S3C_GPIO_PULL_NONE), the s3c2410_gpio_pullup(x, 0)
|
||||
are not so easy.
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Introduction
|
|||
versions.
|
||||
|
||||
The S3C2416 and S3C2450 devices are very similar and S3C2450 support is
|
||||
included under the arch/arm/mach-s3c2416 directory. Note, whilst core
|
||||
included under the arch/arm/mach-s3c2416 directory. Note, while core
|
||||
support for these SoCs is in, work on some of the extra peripherals
|
||||
and extra interrupts is still ongoing.
|
||||
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ Debugging
|
|||
suspending, which means that use of printascii() or similar direct
|
||||
access to the UARTs will cause the debug to stop.
|
||||
|
||||
2) Whilst the pm code itself will attempt to re-enable the UART clocks,
|
||||
2) While the pm code itself will attempt to re-enable the UART clocks,
|
||||
care should be taken that any external clock sources that the UARTs
|
||||
rely on are still enabled at that point.
|
||||
|
||||
|
|
|
|||
|
|
@ -65,7 +65,6 @@ Description of Contents:
|
|||
3.2.3 I/O completion
|
||||
3.2.4 Implications for drivers that do not interpret bios (don't handle
|
||||
multiple segments)
|
||||
3.2.5 Request command tagging
|
||||
3.3 I/O submission
|
||||
4. The I/O scheduler
|
||||
5. Scalability related changes
|
||||
|
|
@ -708,93 +707,6 @@ is crossed on completion of a transfer. (The end*request* functions should
|
|||
be used if only if the request has come down from block/bio path, not for
|
||||
direct access requests which only specify rq->buffer without a valid rq->bio)
|
||||
|
||||
3.2.5 Generic request command tagging
|
||||
|
||||
3.2.5.1 Tag helpers
|
||||
|
||||
Block now offers some simple generic functionality to help support command
|
||||
queueing (typically known as tagged command queueing), ie manage more than
|
||||
one outstanding command on a queue at any given time.
|
||||
|
||||
blk_queue_init_tags(struct request_queue *q, int depth)
|
||||
|
||||
Initialize internal command tagging structures for a maximum
|
||||
depth of 'depth'.
|
||||
|
||||
blk_queue_free_tags((struct request_queue *q)
|
||||
|
||||
Teardown tag info associated with the queue. This will be done
|
||||
automatically by block if blk_queue_cleanup() is called on a queue
|
||||
that is using tagging.
|
||||
|
||||
The above are initialization and exit management, the main helpers during
|
||||
normal operations are:
|
||||
|
||||
blk_queue_start_tag(struct request_queue *q, struct request *rq)
|
||||
|
||||
Start tagged operation for this request. A free tag number between
|
||||
0 and 'depth' is assigned to the request (rq->tag holds this number),
|
||||
and 'rq' is added to the internal tag management. If the maximum depth
|
||||
for this queue is already achieved (or if the tag wasn't started for
|
||||
some other reason), 1 is returned. Otherwise 0 is returned.
|
||||
|
||||
blk_queue_end_tag(struct request_queue *q, struct request *rq)
|
||||
|
||||
End tagged operation on this request. 'rq' is removed from the internal
|
||||
book keeping structures.
|
||||
|
||||
To minimize struct request and queue overhead, the tag helpers utilize some
|
||||
of the same request members that are used for normal request queue management.
|
||||
This means that a request cannot both be an active tag and be on the queue
|
||||
list at the same time. blk_queue_start_tag() will remove the request, but
|
||||
the driver must remember to call blk_queue_end_tag() before signalling
|
||||
completion of the request to the block layer. This means ending tag
|
||||
operations before calling end_that_request_last()! For an example of a user
|
||||
of these helpers, see the IDE tagged command queueing support.
|
||||
|
||||
3.2.5.2 Tag info
|
||||
|
||||
Some block functions exist to query current tag status or to go from a
|
||||
tag number to the associated request. These are, in no particular order:
|
||||
|
||||
blk_queue_tagged(q)
|
||||
|
||||
Returns 1 if the queue 'q' is using tagging, 0 if not.
|
||||
|
||||
blk_queue_tag_request(q, tag)
|
||||
|
||||
Returns a pointer to the request associated with tag 'tag'.
|
||||
|
||||
blk_queue_tag_depth(q)
|
||||
|
||||
Return current queue depth.
|
||||
|
||||
blk_queue_tag_queue(q)
|
||||
|
||||
Returns 1 if the queue can accept a new queued command, 0 if we are
|
||||
at the maximum depth already.
|
||||
|
||||
blk_queue_rq_tagged(rq)
|
||||
|
||||
Returns 1 if the request 'rq' is tagged.
|
||||
|
||||
3.2.5.2 Internal structure
|
||||
|
||||
Internally, block manages tags in the blk_queue_tag structure:
|
||||
|
||||
struct blk_queue_tag {
|
||||
struct request **tag_index; /* array or pointers to rq */
|
||||
unsigned long *tag_map; /* bitmap of free tags */
|
||||
struct list_head busy_list; /* fifo list of busy tags */
|
||||
int busy; /* queue depth */
|
||||
int max_depth; /* max queue depth */
|
||||
};
|
||||
|
||||
Most of the above is simple and straight forward, however busy_list may need
|
||||
a bit of explaining. Normally we don't care too much about request ordering,
|
||||
but in the event of any barrier requests in the tag queue we need to ensure
|
||||
that requests are restarted in the order they were queue.
|
||||
|
||||
3.3 I/O Submission
|
||||
|
||||
The routine submit_bio() is used to submit a single io. Higher level i/o
|
||||
|
|
|
|||
|
|
@ -1,291 +0,0 @@
|
|||
CFQ (Complete Fairness Queueing)
|
||||
===============================
|
||||
|
||||
The main aim of CFQ scheduler is to provide a fair allocation of the disk
|
||||
I/O bandwidth for all the processes which requests an I/O operation.
|
||||
|
||||
CFQ maintains the per process queue for the processes which request I/O
|
||||
operation(synchronous requests). In case of asynchronous requests, all the
|
||||
requests from all the processes are batched together according to their
|
||||
process's I/O priority.
|
||||
|
||||
CFQ ioscheduler tunables
|
||||
========================
|
||||
|
||||
slice_idle
|
||||
----------
|
||||
This specifies how long CFQ should idle for next request on certain cfq queues
|
||||
(for sequential workloads) and service trees (for random workloads) before
|
||||
queue is expired and CFQ selects next queue to dispatch from.
|
||||
|
||||
By default slice_idle is a non-zero value. That means by default we idle on
|
||||
queues/service trees. This can be very helpful on highly seeky media like
|
||||
single spindle SATA/SAS disks where we can cut down on overall number of
|
||||
seeks and see improved throughput.
|
||||
|
||||
Setting slice_idle to 0 will remove all the idling on queues/service tree
|
||||
level and one should see an overall improved throughput on faster storage
|
||||
devices like multiple SATA/SAS disks in hardware RAID configuration. The down
|
||||
side is that isolation provided from WRITES also goes down and notion of
|
||||
IO priority becomes weaker.
|
||||
|
||||
So depending on storage and workload, it might be useful to set slice_idle=0.
|
||||
In general I think for SATA/SAS disks and software RAID of SATA/SAS disks
|
||||
keeping slice_idle enabled should be useful. For any configurations where
|
||||
there are multiple spindles behind single LUN (Host based hardware RAID
|
||||
controller or for storage arrays), setting slice_idle=0 might end up in better
|
||||
throughput and acceptable latencies.
|
||||
|
||||
back_seek_max
|
||||
-------------
|
||||
This specifies, given in Kbytes, the maximum "distance" for backward seeking.
|
||||
The distance is the amount of space from the current head location to the
|
||||
sectors that are backward in terms of distance.
|
||||
|
||||
This parameter allows the scheduler to anticipate requests in the "backward"
|
||||
direction and consider them as being the "next" if they are within this
|
||||
distance from the current head location.
|
||||
|
||||
back_seek_penalty
|
||||
-----------------
|
||||
This parameter is used to compute the cost of backward seeking. If the
|
||||
backward distance of request is just 1/back_seek_penalty from a "front"
|
||||
request, then the seeking cost of two requests is considered equivalent.
|
||||
|
||||
So scheduler will not bias toward one or the other request (otherwise scheduler
|
||||
will bias toward front request). Default value of back_seek_penalty is 2.
|
||||
|
||||
fifo_expire_async
|
||||
-----------------
|
||||
This parameter is used to set the timeout of asynchronous requests. Default
|
||||
value of this is 248ms.
|
||||
|
||||
fifo_expire_sync
|
||||
----------------
|
||||
This parameter is used to set the timeout of synchronous requests. Default
|
||||
value of this is 124ms. In case to favor synchronous requests over asynchronous
|
||||
one, this value should be decreased relative to fifo_expire_async.
|
||||
|
||||
group_idle
|
||||
-----------
|
||||
This parameter forces idling at the CFQ group level instead of CFQ
|
||||
queue level. This was introduced after a bottleneck was observed
|
||||
in higher end storage due to idle on sequential queue and allow dispatch
|
||||
from a single queue. The idea with this parameter is that it can be run with
|
||||
slice_idle=0 and group_idle=8, so that idling does not happen on individual
|
||||
queues in the group but happens overall on the group and thus still keeps the
|
||||
IO controller working.
|
||||
Not idling on individual queues in the group will dispatch requests from
|
||||
multiple queues in the group at the same time and achieve higher throughput
|
||||
on higher end storage.
|
||||
|
||||
Default value for this parameter is 8ms.
|
||||
|
||||
low_latency
|
||||
-----------
|
||||
This parameter is used to enable/disable the low latency mode of the CFQ
|
||||
scheduler. If enabled, CFQ tries to recompute the slice time for each process
|
||||
based on the target_latency set for the system. This favors fairness over
|
||||
throughput. Disabling low latency (setting it to 0) ignores target latency,
|
||||
allowing each process in the system to get a full time slice.
|
||||
|
||||
By default low latency mode is enabled.
|
||||
|
||||
target_latency
|
||||
--------------
|
||||
This parameter is used to calculate the time slice for a process if cfq's
|
||||
latency mode is enabled. It will ensure that sync requests have an estimated
|
||||
latency. But if sequential workload is higher(e.g. sequential read),
|
||||
then to meet the latency constraints, throughput may decrease because of less
|
||||
time for each process to issue I/O request before the cfq queue is switched.
|
||||
|
||||
Though this can be overcome by disabling the latency_mode, it may increase
|
||||
the read latency for some applications. This parameter allows for changing
|
||||
target_latency through the sysfs interface which can provide the balanced
|
||||
throughput and read latency.
|
||||
|
||||
Default value for target_latency is 300ms.
|
||||
|
||||
slice_async
|
||||
-----------
|
||||
This parameter is same as of slice_sync but for asynchronous queue. The
|
||||
default value is 40ms.
|
||||
|
||||
slice_async_rq
|
||||
--------------
|
||||
This parameter is used to limit the dispatching of asynchronous request to
|
||||
device request queue in queue's slice time. The maximum number of request that
|
||||
are allowed to be dispatched also depends upon the io priority. Default value
|
||||
for this is 2.
|
||||
|
||||
slice_sync
|
||||
----------
|
||||
When a queue is selected for execution, the queues IO requests are only
|
||||
executed for a certain amount of time(time_slice) before switching to another
|
||||
queue. This parameter is used to calculate the time slice of synchronous
|
||||
queue.
|
||||
|
||||
time_slice is computed using the below equation:-
|
||||
time_slice = slice_sync + (slice_sync/5 * (4 - prio)). To increase the
|
||||
time_slice of synchronous queue, increase the value of slice_sync. Default
|
||||
value is 100ms.
|
||||
|
||||
quantum
|
||||
-------
|
||||
This specifies the number of request dispatched to the device queue. In a
|
||||
queue's time slice, a request will not be dispatched if the number of request
|
||||
in the device exceeds this parameter. This parameter is used for synchronous
|
||||
request.
|
||||
|
||||
In case of storage with several disk, this setting can limit the parallel
|
||||
processing of request. Therefore, increasing the value can improve the
|
||||
performance although this can cause the latency of some I/O to increase due
|
||||
to more number of requests.
|
||||
|
||||
CFQ Group scheduling
|
||||
====================
|
||||
|
||||
CFQ supports blkio cgroup and has "blkio." prefixed files in each
|
||||
blkio cgroup directory. It is weight-based and there are four knobs
|
||||
for configuration - weight[_device] and leaf_weight[_device].
|
||||
Internal cgroup nodes (the ones with children) can also have tasks in
|
||||
them, so the former two configure how much proportion the cgroup as a
|
||||
whole is entitled to at its parent's level while the latter two
|
||||
configure how much proportion the tasks in the cgroup have compared to
|
||||
its direct children.
|
||||
|
||||
Another way to think about it is assuming that each internal node has
|
||||
an implicit leaf child node which hosts all the tasks whose weight is
|
||||
configured by leaf_weight[_device]. Let's assume a blkio hierarchy
|
||||
composed of five cgroups - root, A, B, AA and AB - with the following
|
||||
weights where the names represent the hierarchy.
|
||||
|
||||
weight leaf_weight
|
||||
root : 125 125
|
||||
A : 500 750
|
||||
B : 250 500
|
||||
AA : 500 500
|
||||
AB : 1000 500
|
||||
|
||||
root never has a parent making its weight is meaningless. For backward
|
||||
compatibility, weight is always kept in sync with leaf_weight. B, AA
|
||||
and AB have no child and thus its tasks have no children cgroup to
|
||||
compete with. They always get 100% of what the cgroup won at the
|
||||
parent level. Considering only the weights which matter, the hierarchy
|
||||
looks like the following.
|
||||
|
||||
root
|
||||
/ | \
|
||||
A B leaf
|
||||
500 250 125
|
||||
/ | \
|
||||
AA AB leaf
|
||||
500 1000 750
|
||||
|
||||
If all cgroups have active IOs and competing with each other, disk
|
||||
time will be distributed like the following.
|
||||
|
||||
Distribution below root. The total active weight at this level is
|
||||
A:500 + B:250 + C:125 = 875.
|
||||
|
||||
root-leaf : 125 / 875 =~ 14%
|
||||
A : 500 / 875 =~ 57%
|
||||
B(-leaf) : 250 / 875 =~ 28%
|
||||
|
||||
A has children and further distributes its 57% among the children and
|
||||
the implicit leaf node. The total active weight at this level is
|
||||
AA:500 + AB:1000 + A-leaf:750 = 2250.
|
||||
|
||||
A-leaf : ( 750 / 2250) * A =~ 19%
|
||||
AA(-leaf) : ( 500 / 2250) * A =~ 12%
|
||||
AB(-leaf) : (1000 / 2250) * A =~ 25%
|
||||
|
||||
CFQ IOPS Mode for group scheduling
|
||||
===================================
|
||||
Basic CFQ design is to provide priority based time slices. Higher priority
|
||||
process gets bigger time slice and lower priority process gets smaller time
|
||||
slice. Measuring time becomes harder if storage is fast and supports NCQ and
|
||||
it would be better to dispatch multiple requests from multiple cfq queues in
|
||||
request queue at a time. In such scenario, it is not possible to measure time
|
||||
consumed by single queue accurately.
|
||||
|
||||
What is possible though is to measure number of requests dispatched from a
|
||||
single queue and also allow dispatch from multiple cfq queue at the same time.
|
||||
This effectively becomes the fairness in terms of IOPS (IO operations per
|
||||
second).
|
||||
|
||||
If one sets slice_idle=0 and if storage supports NCQ, CFQ internally switches
|
||||
to IOPS mode and starts providing fairness in terms of number of requests
|
||||
dispatched. Note that this mode switching takes effect only for group
|
||||
scheduling. For non-cgroup users nothing should change.
|
||||
|
||||
CFQ IO scheduler Idling Theory
|
||||
===============================
|
||||
Idling on a queue is primarily about waiting for the next request to come
|
||||
on same queue after completion of a request. In this process CFQ will not
|
||||
dispatch requests from other cfq queues even if requests are pending there.
|
||||
|
||||
The rationale behind idling is that it can cut down on number of seeks
|
||||
on rotational media. For example, if a process is doing dependent
|
||||
sequential reads (next read will come on only after completion of previous
|
||||
one), then not dispatching request from other queue should help as we
|
||||
did not move the disk head and kept on dispatching sequential IO from
|
||||
one queue.
|
||||
|
||||
CFQ has following service trees and various queues are put on these trees.
|
||||
|
||||
sync-idle sync-noidle async
|
||||
|
||||
All cfq queues doing synchronous sequential IO go on to sync-idle tree.
|
||||
On this tree we idle on each queue individually.
|
||||
|
||||
All synchronous non-sequential queues go on sync-noidle tree. Also any
|
||||
synchronous write request which is not marked with REQ_IDLE goes on this
|
||||
service tree. On this tree we do not idle on individual queues instead idle
|
||||
on the whole group of queues or the tree. So if there are 4 queues waiting
|
||||
for IO to dispatch we will idle only once last queue has dispatched the IO
|
||||
and there is no more IO on this service tree.
|
||||
|
||||
All async writes go on async service tree. There is no idling on async
|
||||
queues.
|
||||
|
||||
CFQ has some optimizations for SSDs and if it detects a non-rotational
|
||||
media which can support higher queue depth (multiple requests at in
|
||||
flight at a time), then it cuts down on idling of individual queues and
|
||||
all the queues move to sync-noidle tree and only tree idle remains. This
|
||||
tree idling provides isolation with buffered write queues on async tree.
|
||||
|
||||
FAQ
|
||||
===
|
||||
Q1. Why to idle at all on queues not marked with REQ_IDLE.
|
||||
|
||||
A1. We only do tree idle (all queues on sync-noidle tree) on queues not marked
|
||||
with REQ_IDLE. This helps in providing isolation with all the sync-idle
|
||||
queues. Otherwise in presence of many sequential readers, other
|
||||
synchronous IO might not get fair share of disk.
|
||||
|
||||
For example, if there are 10 sequential readers doing IO and they get
|
||||
100ms each. If a !REQ_IDLE request comes in, it will be scheduled
|
||||
roughly after 1 second. If after completion of !REQ_IDLE request we
|
||||
do not idle, and after a couple of milli seconds a another !REQ_IDLE
|
||||
request comes in, again it will be scheduled after 1second. Repeat it
|
||||
and notice how a workload can lose its disk share and suffer due to
|
||||
multiple sequential readers.
|
||||
|
||||
fsync can generate dependent IO where bunch of data is written in the
|
||||
context of fsync, and later some journaling data is written. Journaling
|
||||
data comes in only after fsync has finished its IO (atleast for ext4
|
||||
that seemed to be the case). Now if one decides not to idle on fsync
|
||||
thread due to !REQ_IDLE, then next journaling write will not get
|
||||
scheduled for another second. A process doing small fsync, will suffer
|
||||
badly in presence of multiple sequential readers.
|
||||
|
||||
Hence doing tree idling on threads using !REQ_IDLE flag on requests
|
||||
provides isolation from multiple sequential readers and at the same
|
||||
time we do not idle on individual threads.
|
||||
|
||||
Q2. When to specify REQ_IDLE
|
||||
A2. I would think whenever one is doing synchronous write and expecting
|
||||
more writes to be dispatched from same context soon, should be able
|
||||
to specify REQ_IDLE on writes and that probably should work well for
|
||||
most of the cases.
|
||||
|
|
@ -64,7 +64,7 @@ guess, the kernel will put the process issuing IO to sleep for an amount
|
|||
of time, before entering a classic poll loop. This mode might be a
|
||||
little slower than pure classic polling, but it will be more efficient.
|
||||
If set to a value larger than 0, the kernel will put the process issuing
|
||||
IO to sleep for this amont of microseconds before entering classic
|
||||
IO to sleep for this amount of microseconds before entering classic
|
||||
polling.
|
||||
|
||||
iostats (RW)
|
||||
|
|
@ -194,4 +194,31 @@ blk-throttle makes decision based on the samplings. Lower time means cgroups
|
|||
have more smooth throughput, but higher CPU overhead. This exists only when
|
||||
CONFIG_BLK_DEV_THROTTLING_LOW is enabled.
|
||||
|
||||
zoned (RO)
|
||||
----------
|
||||
This indicates if the device is a zoned block device and the zone model of the
|
||||
device if it is indeed zoned. The possible values indicated by zoned are
|
||||
"none" for regular block devices and "host-aware" or "host-managed" for zoned
|
||||
block devices. The characteristics of host-aware and host-managed zoned block
|
||||
devices are described in the ZBC (Zoned Block Commands) and ZAC
|
||||
(Zoned Device ATA Command Set) standards. These standards also define the
|
||||
"drive-managed" zone model. However, since drive-managed zoned block devices
|
||||
do not support zone commands, they will be treated as regular block devices
|
||||
and zoned will report "none".
|
||||
|
||||
nr_zones (RO)
|
||||
-------------
|
||||
For zoned block devices (zoned attribute indicating "host-managed" or
|
||||
"host-aware"), this indicates the total number of zones of the device.
|
||||
This is always 0 for regular block devices.
|
||||
|
||||
chunk_sectors (RO)
|
||||
------------------
|
||||
This has different meaning depending on the type of the block device.
|
||||
For a RAID device (dm-raid), chunk_sectors indicates the size in 512B sectors
|
||||
of the RAID volume stripe segment. For a zoned block device, either host-aware
|
||||
or host-managed, chunk_sectors indicates the size in 512B sectors of the zones
|
||||
of the device, with the eventual exception of the last zone of the device which
|
||||
may be smaller.
|
||||
|
||||
Jens Axboe <jens.axboe@oracle.com>, February 2009
|
||||
|
|
|
|||
|
|
@ -164,11 +164,14 @@ reset WO trigger device reset
|
|||
mem_used_max WO reset the `mem_used_max' counter (see later)
|
||||
mem_limit WO specifies the maximum amount of memory ZRAM can use
|
||||
to store the compressed data
|
||||
writeback_limit WO specifies the maximum amount of write IO zram can
|
||||
write out to backing device as 4KB unit
|
||||
max_comp_streams RW the number of possible concurrent compress operations
|
||||
comp_algorithm RW show and change the compression algorithm
|
||||
compact WO trigger memory compaction
|
||||
debug_stat RO this file is used for zram debugging purposes
|
||||
backing_dev RW set up backend storage for zram to write out
|
||||
idle WO mark allocated slot as idle
|
||||
|
||||
|
||||
User space is advised to use the following files to read the device statistics.
|
||||
|
|
@ -220,6 +223,17 @@ line of text and contains the following stats separated by whitespace:
|
|||
pages_compacted the number of pages freed during compaction
|
||||
huge_pages the number of incompressible pages
|
||||
|
||||
File /sys/block/zram<id>/bd_stat
|
||||
|
||||
The stat file represents device's backing device statistics. It consists of
|
||||
a single line of text and contains the following stats separated by whitespace:
|
||||
bd_count size of data written in backing device.
|
||||
Unit: 4K bytes
|
||||
bd_reads the number of reads from backing device
|
||||
Unit: 4K bytes
|
||||
bd_writes the number of writes to backing device
|
||||
Unit: 4K bytes
|
||||
|
||||
9) Deactivate:
|
||||
swapoff /dev/zram0
|
||||
umount /dev/zram1
|
||||
|
|
@ -237,11 +251,60 @@ line of text and contains the following stats separated by whitespace:
|
|||
|
||||
= writeback
|
||||
|
||||
With incompressible pages, there is no memory saving with zram.
|
||||
Instead, with CONFIG_ZRAM_WRITEBACK, zram can write incompressible page
|
||||
With CONFIG_ZRAM_WRITEBACK, zram can write idle/incompressible page
|
||||
to backing storage rather than keeping it in memory.
|
||||
User should set up backing device via /sys/block/zramX/backing_dev
|
||||
before disksize setting.
|
||||
To use the feature, admin should set up backing device via
|
||||
|
||||
"echo /dev/sda5 > /sys/block/zramX/backing_dev"
|
||||
|
||||
before disksize setting. It supports only partition at this moment.
|
||||
If admin want to use incompressible page writeback, they could do via
|
||||
|
||||
"echo huge > /sys/block/zramX/write"
|
||||
|
||||
To use idle page writeback, first, user need to declare zram pages
|
||||
as idle.
|
||||
|
||||
"echo all > /sys/block/zramX/idle"
|
||||
|
||||
From now on, any pages on zram are idle pages. The idle mark
|
||||
will be removed until someone request access of the block.
|
||||
IOW, unless there is access request, those pages are still idle pages.
|
||||
|
||||
Admin can request writeback of those idle pages at right timing via
|
||||
|
||||
"echo idle > /sys/block/zramX/writeback"
|
||||
|
||||
With the command, zram writeback idle pages from memory to the storage.
|
||||
|
||||
If there are lots of write IO with flash device, potentially, it has
|
||||
flash wearout problem so that admin needs to design write limitation
|
||||
to guarantee storage health for entire product life.
|
||||
To overcome the concern, zram supports "writeback_limit".
|
||||
The "writeback_limit"'s default value is 0 so that it doesn't limit
|
||||
any writeback. If admin want to measure writeback count in a certain
|
||||
period, he could know it via /sys/block/zram0/bd_stat's 3rd column.
|
||||
|
||||
If admin want to limit writeback as per-day 400M, he could do it
|
||||
like below.
|
||||
|
||||
MB_SHIFT=20
|
||||
4K_SHIFT=12
|
||||
echo $((400<<MB_SHIFT>>4K_SHIFT)) > \
|
||||
/sys/block/zram0/writeback_limit.
|
||||
|
||||
If admin want to allow further write again, he could do it like below
|
||||
|
||||
echo 0 > /sys/block/zram0/writeback_limit
|
||||
|
||||
If admin want to see remaining writeback budget since he set,
|
||||
|
||||
cat /sys/block/zram0/writeback_limit
|
||||
|
||||
The writeback_limit count will reset whenever you reset zram(e.g.,
|
||||
system reboot, echo 1 > /sys/block/zramX/reset) so keeping how many of
|
||||
writeback happened until you reset the zram to allocate extra writeback
|
||||
budget in next setting is user's job.
|
||||
|
||||
= memory tracking
|
||||
|
||||
|
|
@ -251,16 +314,17 @@ pages of the process with*pagemap.
|
|||
If you enable the feature, you could see block state via
|
||||
/sys/kernel/debug/zram/zram0/block_state". The output is as follows,
|
||||
|
||||
300 75.033841 .wh
|
||||
301 63.806904 s..
|
||||
302 63.806919 ..h
|
||||
300 75.033841 .wh.
|
||||
301 63.806904 s...
|
||||
302 63.806919 ..hi
|
||||
|
||||
First column is zram's block index.
|
||||
Second column is access time since the system was booted
|
||||
Third column is state of the block.
|
||||
(s: same page
|
||||
w: written page to backing store
|
||||
h: huge page)
|
||||
h: huge page
|
||||
i: idle page)
|
||||
|
||||
First line of above example says 300th block is accessed at 75.033841sec
|
||||
and the block's state is huge so it is written back to the backing
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ properties:
|
|||
8. The array can iterated over. The objects will not necessarily come out in
|
||||
key order.
|
||||
|
||||
9. The array can be iterated over whilst it is being modified, provided the
|
||||
9. The array can be iterated over while it is being modified, provided the
|
||||
RCU readlock is being held by the iterator. Note, however, under these
|
||||
circumstances, some objects may be seen more than once. If this is a
|
||||
problem, the iterator should lock against modification. Objects will not
|
||||
|
|
@ -42,7 +42,7 @@ properties:
|
|||
|
||||
10. Objects in the array can be looked up by means of their index key.
|
||||
|
||||
11. Objects can be looked up whilst the array is being modified, provided the
|
||||
11. Objects can be looked up while the array is being modified, provided the
|
||||
RCU readlock is being held by the thread doing the look up.
|
||||
|
||||
The implementation uses a tree of 16-pointer nodes internally that are indexed
|
||||
|
|
@ -273,7 +273,7 @@ The function will return ``0`` if successful and ``-ENOMEM`` if there wasn't
|
|||
enough memory.
|
||||
|
||||
It is possible for other threads to iterate over or search the array under
|
||||
the RCU read lock whilst this function is in progress. The caller should
|
||||
the RCU read lock while this function is in progress. The caller should
|
||||
lock exclusively against other modifiers of the array.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
.. _memory-allocation:
|
||||
|
||||
=======================
|
||||
Memory Allocation Guide
|
||||
=======================
|
||||
|
|
|
|||
|
|
@ -46,11 +46,20 @@ The Slab Cache
|
|||
.. kernel-doc:: mm/slab.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/slab_common.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/util.c
|
||||
:functions: kfree_const kvmalloc_node kvfree
|
||||
|
||||
More Memory Management Functions
|
||||
================================
|
||||
Virtually Contiguous Mappings
|
||||
=============================
|
||||
|
||||
.. kernel-doc:: mm/vmalloc.c
|
||||
:export:
|
||||
|
||||
File Mapping and Page Cache
|
||||
===========================
|
||||
|
||||
.. kernel-doc:: mm/readahead.c
|
||||
:export:
|
||||
|
|
@ -58,23 +67,28 @@ More Memory Management Functions
|
|||
.. kernel-doc:: mm/filemap.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/memory.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/vmalloc.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/page_alloc.c
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: mm/mempool.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/dmapool.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/page-writeback.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/truncate.c
|
||||
:export:
|
||||
|
||||
Memory pools
|
||||
============
|
||||
|
||||
.. kernel-doc:: mm/mempool.c
|
||||
:export:
|
||||
|
||||
DMA pools
|
||||
=========
|
||||
|
||||
.. kernel-doc:: mm/dmapool.c
|
||||
:export:
|
||||
|
||||
More Memory Management Functions
|
||||
================================
|
||||
|
||||
.. kernel-doc:: mm/memory.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/page_alloc.c
|
||||
|
|
|
|||
|
|
@ -412,6 +412,24 @@ Examples::
|
|||
|
||||
Passed by reference.
|
||||
|
||||
Time and date (struct rtc_time)
|
||||
-------------------------------
|
||||
|
||||
::
|
||||
|
||||
%ptR YYYY-mm-ddTHH:MM:SS
|
||||
%ptRd YYYY-mm-dd
|
||||
%ptRt HH:MM:SS
|
||||
%ptR[dt][r]
|
||||
|
||||
For printing date and time as represented by struct rtc_time structure in
|
||||
human readable format.
|
||||
|
||||
By default year will be incremented by 1900 and month by 1. Use %ptRr (raw)
|
||||
to suppress this behaviour.
|
||||
|
||||
Passed by reference.
|
||||
|
||||
struct clk
|
||||
----------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,15 +1,6 @@
|
|||
Programming Interface
|
||||
=====================
|
||||
|
||||
Please note that the kernel crypto API contains the AEAD givcrypt API
|
||||
(crypto_aead_giv\* and aead_givcrypt\* function calls in
|
||||
include/crypto/aead.h). This API is obsolete and will be removed in the
|
||||
future. To obtain the functionality of an AEAD cipher with internal IV
|
||||
generation, use the IV generator as a regular cipher. For example,
|
||||
rfc4106(gcm(aes)) is the AEAD cipher with external IV generation and
|
||||
seqniv(rfc4106(gcm(aes))) implies that the kernel crypto API generates
|
||||
the IV. Different IV generators are available.
|
||||
|
||||
.. class:: toc-title
|
||||
|
||||
Table of contents
|
||||
|
|
|
|||
|
|
@ -157,10 +157,6 @@ applicable to a cipher, it is not displayed:
|
|||
|
||||
- rng for random number generator
|
||||
|
||||
- givcipher for cipher with associated IV generator (see the geniv
|
||||
entry below for the specification of the IV generator type used by
|
||||
the cipher implementation)
|
||||
|
||||
- kpp for a Key-agreement Protocol Primitive (KPP) cipher such as
|
||||
an ECDH or DH implementation
|
||||
|
||||
|
|
@ -174,16 +170,7 @@ applicable to a cipher, it is not displayed:
|
|||
|
||||
- digestsize: output size of the message digest
|
||||
|
||||
- geniv: IV generation type:
|
||||
|
||||
- eseqiv for encrypted sequence number based IV generation
|
||||
|
||||
- seqiv for sequence number based IV generation
|
||||
|
||||
- chainiv for chain iv generation
|
||||
|
||||
- <builtin> is a marker that the cipher implements IV generation and
|
||||
handling as it is specific to the given cipher
|
||||
- geniv: IV generator (obsolete)
|
||||
|
||||
Key Sizes
|
||||
---------
|
||||
|
|
@ -218,10 +205,6 @@ the aforementioned cipher types:
|
|||
|
||||
- CRYPTO_ALG_TYPE_ABLKCIPHER Asynchronous multi-block cipher
|
||||
|
||||
- CRYPTO_ALG_TYPE_GIVCIPHER Asynchronous multi-block cipher packed
|
||||
together with an IV generator (see geniv field in the /proc/crypto
|
||||
listing for the known IV generators)
|
||||
|
||||
- CRYPTO_ALG_TYPE_KPP Key-agreement Protocol Primitive (KPP) such as
|
||||
an ECDH or DH implementation
|
||||
|
||||
|
|
@ -338,18 +321,14 @@ uses the API applicable to the cipher type specified for the block.
|
|||
|
||||
The following call sequence is applicable when the IPSEC layer triggers
|
||||
an encryption operation with the esp_output function. During
|
||||
configuration, the administrator set up the use of rfc4106(gcm(aes)) as
|
||||
the cipher for ESP. The following call sequence is now depicted in the
|
||||
ASCII art above:
|
||||
configuration, the administrator set up the use of seqiv(rfc4106(gcm(aes)))
|
||||
as the cipher for ESP. The following call sequence is now depicted in
|
||||
the ASCII art above:
|
||||
|
||||
1. esp_output() invokes crypto_aead_encrypt() to trigger an
|
||||
encryption operation of the AEAD cipher with IV generator.
|
||||
|
||||
In case of GCM, the SEQIV implementation is registered as GIVCIPHER
|
||||
in crypto_rfc4106_alloc().
|
||||
|
||||
The SEQIV performs its operation to generate an IV where the core
|
||||
function is seqiv_geniv().
|
||||
The SEQIV generates the IV.
|
||||
|
||||
2. Now, SEQIV uses the AEAD API function calls to invoke the associated
|
||||
AEAD cipher. In our case, during the instantiation of SEQIV, the
|
||||
|
|
|
|||
|
|
@ -4,6 +4,8 @@
|
|||
|
||||
.. highlight:: none
|
||||
|
||||
.. _devtools_coccinelle:
|
||||
|
||||
Coccinelle
|
||||
==========
|
||||
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@ Development tools for the kernel
|
|||
================================
|
||||
|
||||
This document is a collection of documents about development tools that can
|
||||
be used to work on the kernel. For now, the documents have been pulled
|
||||
together without any significant effot to integrate them into a coherent
|
||||
be used to work on the kernel. For now, the documents have been pulled
|
||||
together without any significant effort to integrate them into a coherent
|
||||
whole; patches welcome!
|
||||
|
||||
.. class:: toc-title
|
||||
|
|
|
|||
|
|
@ -4,15 +4,25 @@ The Kernel Address Sanitizer (KASAN)
|
|||
Overview
|
||||
--------
|
||||
|
||||
KernelAddressSANitizer (KASAN) is a dynamic memory error detector. It provides
|
||||
a fast and comprehensive solution for finding use-after-free and out-of-bounds
|
||||
bugs.
|
||||
KernelAddressSANitizer (KASAN) is a dynamic memory error detector designed to
|
||||
find out-of-bound and use-after-free bugs. KASAN has two modes: generic KASAN
|
||||
(similar to userspace ASan) and software tag-based KASAN (similar to userspace
|
||||
HWASan).
|
||||
|
||||
KASAN uses compile-time instrumentation for checking every memory access,
|
||||
therefore you will need a GCC version 4.9.2 or later. GCC 5.0 or later is
|
||||
required for detection of out-of-bounds accesses to stack or global variables.
|
||||
KASAN uses compile-time instrumentation to insert validity checks before every
|
||||
memory access, and therefore requires a compiler version that supports that.
|
||||
|
||||
Currently KASAN is supported only for the x86_64 and arm64 architectures.
|
||||
Generic KASAN is supported in both GCC and Clang. With GCC it requires version
|
||||
4.9.2 or later for basic support and version 5.0 or later for detection of
|
||||
out-of-bounds accesses for stack and global variables and for inline
|
||||
instrumentation mode (see the Usage section). With Clang it requires version
|
||||
7.0.0 or later and it doesn't support detection of out-of-bounds accesses for
|
||||
global variables yet.
|
||||
|
||||
Tag-based KASAN is only supported in Clang and requires version 7.0.0 or later.
|
||||
|
||||
Currently generic KASAN is supported for the x86_64, arm64, xtensa and s390
|
||||
architectures, and tag-based KASAN is supported only for arm64.
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
|
@ -21,12 +31,14 @@ To enable KASAN configure kernel with::
|
|||
|
||||
CONFIG_KASAN = y
|
||||
|
||||
and choose between CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE. Outline and
|
||||
inline are compiler instrumentation types. The former produces smaller binary
|
||||
the latter is 1.1 - 2 times faster. Inline instrumentation requires a GCC
|
||||
version 5.0 or later.
|
||||
and choose between CONFIG_KASAN_GENERIC (to enable generic KASAN) and
|
||||
CONFIG_KASAN_SW_TAGS (to enable software tag-based KASAN).
|
||||
|
||||
KASAN works with both SLUB and SLAB memory allocators.
|
||||
You also need to choose between CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE.
|
||||
Outline and inline are compiler instrumentation types. The former produces
|
||||
smaller binary while the latter is 1.1 - 2 times faster.
|
||||
|
||||
Both KASAN modes work with both SLUB and SLAB memory allocators.
|
||||
For better bug detection and nicer reporting, enable CONFIG_STACKTRACE.
|
||||
|
||||
To disable instrumentation for specific files or directories, add a line
|
||||
|
|
@ -43,85 +55,85 @@ similar to the following to the respective kernel Makefile:
|
|||
Error reports
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
A typical out of bounds access report looks like this::
|
||||
A typical out-of-bounds access generic KASAN report looks like this::
|
||||
|
||||
==================================================================
|
||||
BUG: AddressSanitizer: out of bounds access in kmalloc_oob_right+0x65/0x75 [test_kasan] at addr ffff8800693bc5d3
|
||||
Write of size 1 by task modprobe/1689
|
||||
=============================================================================
|
||||
BUG kmalloc-128 (Not tainted): kasan error
|
||||
-----------------------------------------------------------------------------
|
||||
BUG: KASAN: slab-out-of-bounds in kmalloc_oob_right+0xa8/0xbc [test_kasan]
|
||||
Write of size 1 at addr ffff8801f44ec37b by task insmod/2760
|
||||
|
||||
Disabling lock debugging due to kernel taint
|
||||
INFO: Allocated in kmalloc_oob_right+0x3d/0x75 [test_kasan] age=0 cpu=0 pid=1689
|
||||
__slab_alloc+0x4b4/0x4f0
|
||||
kmem_cache_alloc_trace+0x10b/0x190
|
||||
kmalloc_oob_right+0x3d/0x75 [test_kasan]
|
||||
init_module+0x9/0x47 [test_kasan]
|
||||
do_one_initcall+0x99/0x200
|
||||
load_module+0x2cb3/0x3b20
|
||||
SyS_finit_module+0x76/0x80
|
||||
system_call_fastpath+0x12/0x17
|
||||
INFO: Slab 0xffffea0001a4ef00 objects=17 used=7 fp=0xffff8800693bd728 flags=0x100000000004080
|
||||
INFO: Object 0xffff8800693bc558 @offset=1368 fp=0xffff8800693bc720
|
||||
|
||||
Bytes b4 ffff8800693bc548: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
|
||||
Object ffff8800693bc558: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
||||
Object ffff8800693bc568: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
||||
Object ffff8800693bc578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
||||
Object ffff8800693bc588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
||||
Object ffff8800693bc598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
||||
Object ffff8800693bc5a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
||||
Object ffff8800693bc5b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
||||
Object ffff8800693bc5c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
|
||||
Redzone ffff8800693bc5d8: cc cc cc cc cc cc cc cc ........
|
||||
Padding ffff8800693bc718: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
|
||||
CPU: 0 PID: 1689 Comm: modprobe Tainted: G B 3.18.0-rc1-mm1+ #98
|
||||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
|
||||
ffff8800693bc000 0000000000000000 ffff8800693bc558 ffff88006923bb78
|
||||
ffffffff81cc68ae 00000000000000f3 ffff88006d407600 ffff88006923bba8
|
||||
ffffffff811fd848 ffff88006d407600 ffffea0001a4ef00 ffff8800693bc558
|
||||
CPU: 1 PID: 2760 Comm: insmod Not tainted 4.19.0-rc3+ #698
|
||||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
|
||||
Call Trace:
|
||||
[<ffffffff81cc68ae>] dump_stack+0x46/0x58
|
||||
[<ffffffff811fd848>] print_trailer+0xf8/0x160
|
||||
[<ffffffffa00026a7>] ? kmem_cache_oob+0xc3/0xc3 [test_kasan]
|
||||
[<ffffffff811ff0f5>] object_err+0x35/0x40
|
||||
[<ffffffffa0002065>] ? kmalloc_oob_right+0x65/0x75 [test_kasan]
|
||||
[<ffffffff8120b9fa>] kasan_report_error+0x38a/0x3f0
|
||||
[<ffffffff8120a79f>] ? kasan_poison_shadow+0x2f/0x40
|
||||
[<ffffffff8120b344>] ? kasan_unpoison_shadow+0x14/0x40
|
||||
[<ffffffff8120a79f>] ? kasan_poison_shadow+0x2f/0x40
|
||||
[<ffffffffa00026a7>] ? kmem_cache_oob+0xc3/0xc3 [test_kasan]
|
||||
[<ffffffff8120a995>] __asan_store1+0x75/0xb0
|
||||
[<ffffffffa0002601>] ? kmem_cache_oob+0x1d/0xc3 [test_kasan]
|
||||
[<ffffffffa0002065>] ? kmalloc_oob_right+0x65/0x75 [test_kasan]
|
||||
[<ffffffffa0002065>] kmalloc_oob_right+0x65/0x75 [test_kasan]
|
||||
[<ffffffffa00026b0>] init_module+0x9/0x47 [test_kasan]
|
||||
[<ffffffff810002d9>] do_one_initcall+0x99/0x200
|
||||
[<ffffffff811e4e5c>] ? __vunmap+0xec/0x160
|
||||
[<ffffffff81114f63>] load_module+0x2cb3/0x3b20
|
||||
[<ffffffff8110fd70>] ? m_show+0x240/0x240
|
||||
[<ffffffff81115f06>] SyS_finit_module+0x76/0x80
|
||||
[<ffffffff81cd3129>] system_call_fastpath+0x12/0x17
|
||||
dump_stack+0x94/0xd8
|
||||
print_address_description+0x73/0x280
|
||||
kasan_report+0x144/0x187
|
||||
__asan_report_store1_noabort+0x17/0x20
|
||||
kmalloc_oob_right+0xa8/0xbc [test_kasan]
|
||||
kmalloc_tests_init+0x16/0x700 [test_kasan]
|
||||
do_one_initcall+0xa5/0x3ae
|
||||
do_init_module+0x1b6/0x547
|
||||
load_module+0x75df/0x8070
|
||||
__do_sys_init_module+0x1c6/0x200
|
||||
__x64_sys_init_module+0x6e/0xb0
|
||||
do_syscall_64+0x9f/0x2c0
|
||||
entry_SYSCALL_64_after_hwframe+0x44/0xa9
|
||||
RIP: 0033:0x7f96443109da
|
||||
RSP: 002b:00007ffcf0b51b08 EFLAGS: 00000202 ORIG_RAX: 00000000000000af
|
||||
RAX: ffffffffffffffda RBX: 000055dc3ee521a0 RCX: 00007f96443109da
|
||||
RDX: 00007f96445cff88 RSI: 0000000000057a50 RDI: 00007f9644992000
|
||||
RBP: 000055dc3ee510b0 R08: 0000000000000003 R09: 0000000000000000
|
||||
R10: 00007f964430cd0a R11: 0000000000000202 R12: 00007f96445cff88
|
||||
R13: 000055dc3ee51090 R14: 0000000000000000 R15: 0000000000000000
|
||||
|
||||
Allocated by task 2760:
|
||||
save_stack+0x43/0xd0
|
||||
kasan_kmalloc+0xa7/0xd0
|
||||
kmem_cache_alloc_trace+0xe1/0x1b0
|
||||
kmalloc_oob_right+0x56/0xbc [test_kasan]
|
||||
kmalloc_tests_init+0x16/0x700 [test_kasan]
|
||||
do_one_initcall+0xa5/0x3ae
|
||||
do_init_module+0x1b6/0x547
|
||||
load_module+0x75df/0x8070
|
||||
__do_sys_init_module+0x1c6/0x200
|
||||
__x64_sys_init_module+0x6e/0xb0
|
||||
do_syscall_64+0x9f/0x2c0
|
||||
entry_SYSCALL_64_after_hwframe+0x44/0xa9
|
||||
|
||||
Freed by task 815:
|
||||
save_stack+0x43/0xd0
|
||||
__kasan_slab_free+0x135/0x190
|
||||
kasan_slab_free+0xe/0x10
|
||||
kfree+0x93/0x1a0
|
||||
umh_complete+0x6a/0xa0
|
||||
call_usermodehelper_exec_async+0x4c3/0x640
|
||||
ret_from_fork+0x35/0x40
|
||||
|
||||
The buggy address belongs to the object at ffff8801f44ec300
|
||||
which belongs to the cache kmalloc-128 of size 128
|
||||
The buggy address is located 123 bytes inside of
|
||||
128-byte region [ffff8801f44ec300, ffff8801f44ec380)
|
||||
The buggy address belongs to the page:
|
||||
page:ffffea0007d13b00 count:1 mapcount:0 mapping:ffff8801f7001640 index:0x0
|
||||
flags: 0x200000000000100(slab)
|
||||
raw: 0200000000000100 ffffea0007d11dc0 0000001a0000001a ffff8801f7001640
|
||||
raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000
|
||||
page dumped because: kasan: bad access detected
|
||||
|
||||
Memory state around the buggy address:
|
||||
ffff8800693bc300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
|
||||
ffff8800693bc380: fc fc 00 00 00 00 00 00 00 00 00 00 00 00 00 fc
|
||||
ffff8800693bc400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
|
||||
ffff8800693bc480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
|
||||
ffff8800693bc500: fc fc fc fc fc fc fc fc fc fc fc 00 00 00 00 00
|
||||
>ffff8800693bc580: 00 00 00 00 00 00 00 00 00 00 03 fc fc fc fc fc
|
||||
^
|
||||
ffff8800693bc600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
|
||||
ffff8800693bc680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
|
||||
ffff8800693bc700: fc fc fc fc fb fb fb fb fb fb fb fb fb fb fb fb
|
||||
ffff8800693bc780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
|
||||
ffff8800693bc800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
|
||||
ffff8801f44ec200: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
|
||||
ffff8801f44ec280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
|
||||
>ffff8801f44ec300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03
|
||||
^
|
||||
ffff8801f44ec380: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
|
||||
ffff8801f44ec400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
|
||||
==================================================================
|
||||
|
||||
The header of the report discribe what kind of bug happened and what kind of
|
||||
access caused it. It's followed by the description of the accessed slub object
|
||||
(see 'SLUB Debug output' section in Documentation/vm/slub.rst for details) and
|
||||
the description of the accessed memory page.
|
||||
The header of the report provides a short summary of what kind of bug happened
|
||||
and what kind of access caused it. It's followed by a stack trace of the bad
|
||||
access, a stack trace of where the accessed memory was allocated (in case bad
|
||||
access happens on a slab object), and a stack trace of where the object was
|
||||
freed (in case of a use-after-free bug report). Next comes a description of
|
||||
the accessed slab object and information about the accessed memory page.
|
||||
|
||||
In the last section the report shows memory state around the accessed address.
|
||||
Reading this part requires some understanding of how KASAN works.
|
||||
|
|
@ -138,18 +150,24 @@ inaccessible memory like redzones or freed memory (see mm/kasan/kasan.h).
|
|||
In the report above the arrows point to the shadow byte 03, which means that
|
||||
the accessed address is partially accessible.
|
||||
|
||||
For tag-based KASAN this last report section shows the memory tags around the
|
||||
accessed address (see Implementation details section).
|
||||
|
||||
|
||||
Implementation details
|
||||
----------------------
|
||||
|
||||
Generic KASAN
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
From a high level, our approach to memory error detection is similar to that
|
||||
of kmemcheck: use shadow memory to record whether each byte of memory is safe
|
||||
to access, and use compile-time instrumentation to check shadow memory on each
|
||||
memory access.
|
||||
to access, and use compile-time instrumentation to insert checks of shadow
|
||||
memory on each memory access.
|
||||
|
||||
AddressSanitizer dedicates 1/8 of kernel memory to its shadow memory
|
||||
(e.g. 16TB to cover 128TB on x86_64) and uses direct mapping with a scale and
|
||||
offset to translate a memory address to its corresponding shadow address.
|
||||
Generic KASAN dedicates 1/8th of kernel memory to its shadow memory (e.g. 16TB
|
||||
to cover 128TB on x86_64) and uses direct mapping with a scale and offset to
|
||||
translate a memory address to its corresponding shadow address.
|
||||
|
||||
Here is the function which translates an address to its corresponding shadow
|
||||
address::
|
||||
|
|
@ -162,12 +180,38 @@ address::
|
|||
|
||||
where ``KASAN_SHADOW_SCALE_SHIFT = 3``.
|
||||
|
||||
Compile-time instrumentation used for checking memory accesses. Compiler inserts
|
||||
function calls (__asan_load*(addr), __asan_store*(addr)) before each memory
|
||||
access of size 1, 2, 4, 8 or 16. These functions check whether memory access is
|
||||
valid or not by checking corresponding shadow memory.
|
||||
Compile-time instrumentation is used to insert memory access checks. Compiler
|
||||
inserts function calls (__asan_load*(addr), __asan_store*(addr)) before each
|
||||
memory access of size 1, 2, 4, 8 or 16. These functions check whether memory
|
||||
access is valid or not by checking corresponding shadow memory.
|
||||
|
||||
GCC 5.0 has possibility to perform inline instrumentation. Instead of making
|
||||
function calls GCC directly inserts the code to check the shadow memory.
|
||||
This option significantly enlarges kernel but it gives x1.1-x2 performance
|
||||
boost over outline instrumented kernel.
|
||||
|
||||
Software tag-based KASAN
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Tag-based KASAN uses the Top Byte Ignore (TBI) feature of modern arm64 CPUs to
|
||||
store a pointer tag in the top byte of kernel pointers. Like generic KASAN it
|
||||
uses shadow memory to store memory tags associated with each 16-byte memory
|
||||
cell (therefore it dedicates 1/16th of the kernel memory for shadow memory).
|
||||
|
||||
On each memory allocation tag-based KASAN generates a random tag, tags the
|
||||
allocated memory with this tag, and embeds this tag into the returned pointer.
|
||||
Software tag-based KASAN uses compile-time instrumentation to insert checks
|
||||
before each memory access. These checks make sure that tag of the memory that
|
||||
is being accessed is equal to tag of the pointer that is used to access this
|
||||
memory. In case of a tag mismatch tag-based KASAN prints a bug report.
|
||||
|
||||
Software tag-based KASAN also has two instrumentation modes (outline, that
|
||||
emits callbacks to check memory accesses; and inline, that performs the shadow
|
||||
memory checks inline). With outline instrumentation mode, a bug report is
|
||||
simply printed from the function that performs the access check. With inline
|
||||
instrumentation a brk instruction is emitted by the compiler, and a dedicated
|
||||
brk handler is used to print bug reports.
|
||||
|
||||
A potential expansion of this mode is a hardware tag-based mode, which would
|
||||
use hardware memory tagging support instead of compiler instrumentation and
|
||||
manual shadow memory manipulation.
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ and booting a kernel.
|
|||
|
||||
On some systems, hot-plug tests could hang forever waiting for cpu and
|
||||
memory to be ready to be offlined. A special hot-plug target is created
|
||||
to run full range of hot-plug tests. In default mode, hot-plug tests run
|
||||
to run the full range of hot-plug tests. In default mode, hot-plug tests run
|
||||
in safe mode with a limited scope. In limited mode, cpu-hotplug test is
|
||||
run on a single cpu as opposed to all hotplug capable cpus, and memory
|
||||
hotplug test is run on 2% of hotplug capable memory instead of 10%.
|
||||
|
|
@ -89,9 +89,9 @@ Note that some tests will require root privileges.
|
|||
Install selftests
|
||||
=================
|
||||
|
||||
You can use kselftest_install.sh tool installs selftests in default
|
||||
location which is tools/testing/selftests/kselftest or a user specified
|
||||
location.
|
||||
You can use the kselftest_install.sh tool to install selftests in the
|
||||
default location, which is tools/testing/selftests/kselftest, or in a
|
||||
user specified location.
|
||||
|
||||
To install selftests in default location::
|
||||
|
||||
|
|
@ -109,7 +109,7 @@ Running installed selftests
|
|||
Kselftest install as well as the Kselftest tarball provide a script
|
||||
named "run_kselftest.sh" to run the tests.
|
||||
|
||||
You can simply do the following to run the installed Kselftests. Please
|
||||
You can simply do the following to run the installed Kselftests. Please
|
||||
note some tests will require root privileges::
|
||||
|
||||
$ cd kselftest
|
||||
|
|
@ -139,7 +139,7 @@ Contributing new tests (details)
|
|||
default.
|
||||
|
||||
TEST_CUSTOM_PROGS should be used by tests that require custom build
|
||||
rule and prevent common build rule use.
|
||||
rules and prevent common build rule use.
|
||||
|
||||
TEST_PROGS are for test shell scripts. Please ensure shell script has
|
||||
its exec bit set. Otherwise, lib.mk run_tests will generate a warning.
|
||||
|
|
|
|||
|
|
@ -146,7 +146,7 @@ The target is named "raid" and it accepts the following parameters:
|
|||
[data_offset <sectors>]
|
||||
This option value defines the offset into each data device
|
||||
where the data starts. This is used to provide out-of-place
|
||||
reshaping space to avoid writing over data whilst
|
||||
reshaping space to avoid writing over data while
|
||||
changing the layout of stripes, hence an interruption/crash
|
||||
may happen at any time without the risk of losing data.
|
||||
E.g. when adding devices to an existing raid set during
|
||||
|
|
|
|||
|
|
@ -0,0 +1,2 @@
|
|||
*.example.dts
|
||||
processed-schema.yaml
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
DT_DOC_CHECKER ?= dt-doc-validate
|
||||
DT_EXTRACT_EX ?= dt-extract-example
|
||||
DT_MK_SCHEMA ?= dt-mk-schema
|
||||
DT_MK_SCHEMA_FLAGS := $(if $(DT_SCHEMA_FILES), -u)
|
||||
|
||||
quiet_cmd_chk_binding = CHKDT $(patsubst $(srctree)/%,%,$<)
|
||||
cmd_chk_binding = $(DT_DOC_CHECKER) $< ; \
|
||||
$(DT_EXTRACT_EX) $< > $@
|
||||
|
||||
$(obj)/%.example.dts: $(src)/%.yaml FORCE
|
||||
$(call if_changed,chk_binding)
|
||||
|
||||
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, $^)
|
||||
|
||||
DT_DOCS = $(shell cd $(srctree)/$(src) && find * -name '*.yaml')
|
||||
DT_SCHEMA_FILES ?= $(addprefix $(src)/,$(DT_DOCS))
|
||||
|
||||
extra-y += $(patsubst $(src)/%.yaml,%.example.dts, $(DT_SCHEMA_FILES))
|
||||
extra-y += $(patsubst $(src)/%.yaml,%.example.dtb, $(DT_SCHEMA_FILES))
|
||||
|
||||
$(obj)/$(DT_TMP_SCHEMA): $(DT_SCHEMA_FILES) FORCE
|
||||
$(call if_changed,mk_schema)
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
Altera's SoCFPGA platform device tree bindings
|
||||
---------------------------------------------
|
||||
|
||||
Boards with Cyclone 5 SoC:
|
||||
Required root node properties:
|
||||
compatible = "altr,socfpga-cyclone5", "altr,socfpga";
|
||||
|
||||
Boards with Arria 5 SoC:
|
||||
Required root node properties:
|
||||
compatible = "altr,socfpga-arria5", "altr,socfpga";
|
||||
|
||||
Boards with Arria 10 SoC:
|
||||
Required root node properties:
|
||||
compatible = "altr,socfpga-arria10", "altr,socfpga";
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/altera.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Altera's SoCFPGA platform device tree bindings
|
||||
|
||||
maintainers:
|
||||
- Dinh Nguyen <dinguyen@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- altr,socfpga-cyclone5
|
||||
- altr,socfpga-arria5
|
||||
- altr,socfpga-arria10
|
||||
- const: altr,socfpga
|
||||
...
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
Altera SOCFPGA Clock Manager
|
||||
|
||||
Required properties:
|
||||
- compatible : "altr,clk-mgr"
|
||||
- reg : Should contain base address and length for Clock Manager
|
||||
|
||||
Example:
|
||||
clkmgr@ffd04000 {
|
||||
compatible = "altr,clk-mgr";
|
||||
reg = <0xffd04000 0x1000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/altera/socfpga-clk-manager.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Altera SOCFPGA Clock Manager
|
||||
|
||||
maintainers:
|
||||
- Dinh Nguyen <dinguyen@kernel.org>
|
||||
|
||||
description: test
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: altr,clk-mgr
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
examples:
|
||||
- |
|
||||
clkmgr@ffd04000 {
|
||||
compatible = "altr,clk-mgr";
|
||||
reg = <0xffd04000 0x1000>;
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -17,4 +17,11 @@ Required sub-node properties:
|
|||
- compatible : should be "amlogic,meson-gxbb-scp-shmem" for SRAM based shared
|
||||
memory on Amlogic GXBB SoC.
|
||||
|
||||
Sensor bindings for the sensors based on SCPI Message Protocol
|
||||
--------------------------------------------------------------
|
||||
SCPI provides an API to access the various sensors on the SoC.
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "amlogic,meson-gxbb-scpi-sensors".
|
||||
|
||||
[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
|
||||
|
|
|
|||
|
|
@ -91,8 +91,10 @@ Board compatible values (alphabetically, grouped by SoC):
|
|||
|
||||
- "amlogic,p230" (Meson gxl s905d)
|
||||
- "amlogic,p231" (Meson gxl s905d)
|
||||
- "phicomm,n1" (Meson gxl s905d)
|
||||
|
||||
- "amlogic,p241" (Meson gxl s805x)
|
||||
- "libretech,aml-s805x-ac" (Meson gxl s805x)
|
||||
|
||||
- "amlogic,p281" (Meson gxl s905w)
|
||||
- "oranth,tx3-mini" (Meson gxl s905w)
|
||||
|
|
|
|||
|
|
@ -158,14 +158,24 @@ Security Module (SECUMOD)
|
|||
|
||||
The Security Module macrocell provides all necessary secure functions to avoid
|
||||
voltage, temperature, frequency and mechanical attacks on the chip. It also
|
||||
embeds secure memories that can be scrambled
|
||||
embeds secure memories that can be scrambled.
|
||||
|
||||
The Security Module also offers the PIOBU pins which can be used as GPIO pins.
|
||||
Note that they maintain their voltage during Backup/Self-refresh.
|
||||
|
||||
required properties:
|
||||
- compatible: Should be "atmel,<chip>-secumod", "syscon".
|
||||
<chip> can be "sama5d2".
|
||||
- reg: Should contain registers location and length
|
||||
- gpio-controller: Marks the port as GPIO controller.
|
||||
- #gpio-cells: There are 2. The pin number is the
|
||||
first, the second represents additional
|
||||
parameters such as GPIO_ACTIVE_HIGH/LOW.
|
||||
|
||||
|
||||
secumod@fc040000 {
|
||||
compatible = "atmel,sama5d2-secumod", "syscon";
|
||||
reg = <0xfc040000 0x100>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,15 +0,0 @@
|
|||
Calxeda Platforms Device Tree Bindings
|
||||
-----------------------------------------------
|
||||
|
||||
Boards with Calxeda Cortex-A9 based ECX-1000 (Highbank) SOC shall have the
|
||||
following properties.
|
||||
|
||||
Required root node properties:
|
||||
- compatible = "calxeda,highbank";
|
||||
|
||||
|
||||
Boards with Calxeda Cortex-A15 based ECX-2000 SOC shall have the following
|
||||
properties.
|
||||
|
||||
Required root node properties:
|
||||
- compatible = "calxeda,ecx-2000";
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/calxeda.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Calxeda Platforms Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Rob Herring <robh@kernel.org>
|
||||
description: |+
|
||||
Bindings for boards with Calxeda Cortex-A9 based ECX-1000 (Highbank) SOC
|
||||
or Cortex-A15 based ECX-2000 SOCs
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: '/'
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- calxeda,highbank
|
||||
- calxeda,ecx-2000
|
||||
|
|
@ -1,490 +0,0 @@
|
|||
=================
|
||||
ARM CPUs bindings
|
||||
=================
|
||||
|
||||
The device tree allows to describe the layout of CPUs in a system through
|
||||
the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
|
||||
defining properties for every cpu.
|
||||
|
||||
Bindings for CPU nodes follow the Devicetree Specification, available from:
|
||||
|
||||
https://www.devicetree.org/specifications/
|
||||
|
||||
with updates for 32-bit and 64-bit ARM systems provided in this document.
|
||||
|
||||
================================
|
||||
Convention used in this document
|
||||
================================
|
||||
|
||||
This document follows the conventions described in the Devicetree
|
||||
Specification, with the addition:
|
||||
|
||||
- square brackets define bitfields, eg reg[7:0] value of the bitfield in
|
||||
the reg property contained in bits 7 down to 0
|
||||
|
||||
=====================================
|
||||
cpus and cpu node bindings definition
|
||||
=====================================
|
||||
|
||||
The ARM architecture, in accordance with the Devicetree Specification,
|
||||
requires the cpus and cpu nodes to be present and contain the properties
|
||||
described below.
|
||||
|
||||
- cpus node
|
||||
|
||||
Description: Container of cpu nodes
|
||||
|
||||
The node name must be "cpus".
|
||||
|
||||
A cpus node must define the following properties:
|
||||
|
||||
- #address-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
|
||||
Definition depends on ARM architecture version and
|
||||
configuration:
|
||||
|
||||
# On uniprocessor ARM architectures previous to v7
|
||||
value must be 1, to enable a simple enumeration
|
||||
scheme for processors that do not have a HW CPU
|
||||
identification register.
|
||||
# On 32-bit ARM 11 MPcore, ARM v7 or later systems
|
||||
value must be 1, that corresponds to CPUID/MPIDR
|
||||
registers sizes.
|
||||
# On ARM v8 64-bit systems value should be set to 2,
|
||||
that corresponds to the MPIDR_EL1 register size.
|
||||
If MPIDR_EL1[63:32] value is equal to 0 on all CPUs
|
||||
in the system, #address-cells can be set to 1, since
|
||||
MPIDR_EL1[63:32] bits are not used for CPUs
|
||||
identification.
|
||||
- #size-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: must be set to 0
|
||||
|
||||
- cpu node
|
||||
|
||||
Description: Describes a CPU in an ARM based system
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- device_type
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: must be "cpu"
|
||||
- reg
|
||||
Usage and definition depend on ARM architecture version and
|
||||
configuration:
|
||||
|
||||
# On uniprocessor ARM architectures previous to v7
|
||||
this property is required and must be set to 0.
|
||||
|
||||
# On ARM 11 MPcore based systems this property is
|
||||
required and matches the CPUID[11:0] register bits.
|
||||
|
||||
Bits [11:0] in the reg cell must be set to
|
||||
bits [11:0] in CPU ID register.
|
||||
|
||||
All other bits in the reg cell must be set to 0.
|
||||
|
||||
# On 32-bit ARM v7 or later systems this property is
|
||||
required and matches the CPU MPIDR[23:0] register
|
||||
bits.
|
||||
|
||||
Bits [23:0] in the reg cell must be set to
|
||||
bits [23:0] in MPIDR.
|
||||
|
||||
All other bits in the reg cell must be set to 0.
|
||||
|
||||
# On ARM v8 64-bit systems this property is required
|
||||
and matches the MPIDR_EL1 register affinity bits.
|
||||
|
||||
* If cpus node's #address-cells property is set to 2
|
||||
|
||||
The first reg cell bits [7:0] must be set to
|
||||
bits [39:32] of MPIDR_EL1.
|
||||
|
||||
The second reg cell bits [23:0] must be set to
|
||||
bits [23:0] of MPIDR_EL1.
|
||||
|
||||
* If cpus node's #address-cells property is set to 1
|
||||
|
||||
The reg cell bits [23:0] must be set to bits [23:0]
|
||||
of MPIDR_EL1.
|
||||
|
||||
All other bits in the reg cells must be set to 0.
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: should be one of:
|
||||
"arm,arm710t"
|
||||
"arm,arm720t"
|
||||
"arm,arm740t"
|
||||
"arm,arm7ej-s"
|
||||
"arm,arm7tdmi"
|
||||
"arm,arm7tdmi-s"
|
||||
"arm,arm9es"
|
||||
"arm,arm9ej-s"
|
||||
"arm,arm920t"
|
||||
"arm,arm922t"
|
||||
"arm,arm925"
|
||||
"arm,arm926e-s"
|
||||
"arm,arm926ej-s"
|
||||
"arm,arm940t"
|
||||
"arm,arm946e-s"
|
||||
"arm,arm966e-s"
|
||||
"arm,arm968e-s"
|
||||
"arm,arm9tdmi"
|
||||
"arm,arm1020e"
|
||||
"arm,arm1020t"
|
||||
"arm,arm1022e"
|
||||
"arm,arm1026ej-s"
|
||||
"arm,arm1136j-s"
|
||||
"arm,arm1136jf-s"
|
||||
"arm,arm1156t2-s"
|
||||
"arm,arm1156t2f-s"
|
||||
"arm,arm1176jzf"
|
||||
"arm,arm1176jz-s"
|
||||
"arm,arm1176jzf-s"
|
||||
"arm,arm11mpcore"
|
||||
"arm,cortex-a5"
|
||||
"arm,cortex-a7"
|
||||
"arm,cortex-a8"
|
||||
"arm,cortex-a9"
|
||||
"arm,cortex-a12"
|
||||
"arm,cortex-a15"
|
||||
"arm,cortex-a17"
|
||||
"arm,cortex-a53"
|
||||
"arm,cortex-a57"
|
||||
"arm,cortex-a72"
|
||||
"arm,cortex-a73"
|
||||
"arm,cortex-m0"
|
||||
"arm,cortex-m0+"
|
||||
"arm,cortex-m1"
|
||||
"arm,cortex-m3"
|
||||
"arm,cortex-m4"
|
||||
"arm,cortex-r4"
|
||||
"arm,cortex-r5"
|
||||
"arm,cortex-r7"
|
||||
"brcm,brahma-b15"
|
||||
"brcm,brahma-b53"
|
||||
"brcm,vulcan"
|
||||
"cavium,thunder"
|
||||
"cavium,thunder2"
|
||||
"faraday,fa526"
|
||||
"intel,sa110"
|
||||
"intel,sa1100"
|
||||
"marvell,feroceon"
|
||||
"marvell,mohawk"
|
||||
"marvell,pj4a"
|
||||
"marvell,pj4b"
|
||||
"marvell,sheeva-v5"
|
||||
"nvidia,tegra132-denver"
|
||||
"nvidia,tegra186-denver"
|
||||
"nvidia,tegra194-carmel"
|
||||
"qcom,krait"
|
||||
"qcom,kryo"
|
||||
"qcom,kryo385"
|
||||
"qcom,scorpion"
|
||||
- enable-method
|
||||
Value type: <stringlist>
|
||||
Usage and definition depend on ARM architecture version.
|
||||
# On ARM v8 64-bit this property is required and must
|
||||
be one of:
|
||||
"psci"
|
||||
"spin-table"
|
||||
# On ARM 32-bit systems this property is optional and
|
||||
can be one of:
|
||||
"actions,s500-smp"
|
||||
"allwinner,sun6i-a31"
|
||||
"allwinner,sun8i-a23"
|
||||
"allwinner,sun9i-a80-smp"
|
||||
"amlogic,meson8-smp"
|
||||
"amlogic,meson8b-smp"
|
||||
"arm,realview-smp"
|
||||
"brcm,bcm11351-cpu-method"
|
||||
"brcm,bcm23550"
|
||||
"brcm,bcm2836-smp"
|
||||
"brcm,bcm-nsp-smp"
|
||||
"brcm,brahma-b15"
|
||||
"marvell,armada-375-smp"
|
||||
"marvell,armada-380-smp"
|
||||
"marvell,armada-390-smp"
|
||||
"marvell,armada-xp-smp"
|
||||
"marvell,98dx3236-smp"
|
||||
"mediatek,mt6589-smp"
|
||||
"mediatek,mt81xx-tz-smp"
|
||||
"qcom,gcc-msm8660"
|
||||
"qcom,kpss-acc-v1"
|
||||
"qcom,kpss-acc-v2"
|
||||
"renesas,apmu"
|
||||
"renesas,r9a06g032-smp"
|
||||
"rockchip,rk3036-smp"
|
||||
"rockchip,rk3066-smp"
|
||||
"ste,dbx500-smp"
|
||||
|
||||
- cpu-release-addr
|
||||
Usage: required for systems that have an "enable-method"
|
||||
property value of "spin-table".
|
||||
Value type: <prop-encoded-array>
|
||||
Definition:
|
||||
# On ARM v8 64-bit systems must be a two cell
|
||||
property identifying a 64-bit zero-initialised
|
||||
memory location.
|
||||
|
||||
- qcom,saw
|
||||
Usage: required for systems that have an "enable-method"
|
||||
property value of "qcom,kpss-acc-v1" or
|
||||
"qcom,kpss-acc-v2"
|
||||
Value type: <phandle>
|
||||
Definition: Specifies the SAW[1] node associated with this CPU.
|
||||
|
||||
- qcom,acc
|
||||
Usage: required for systems that have an "enable-method"
|
||||
property value of "qcom,kpss-acc-v1" or
|
||||
"qcom,kpss-acc-v2"
|
||||
Value type: <phandle>
|
||||
Definition: Specifies the ACC[2] node associated with this CPU.
|
||||
|
||||
- cpu-idle-states
|
||||
Usage: Optional
|
||||
Value type: <prop-encoded-array>
|
||||
Definition:
|
||||
# List of phandles to idle state nodes supported
|
||||
by this cpu [3].
|
||||
|
||||
- capacity-dmips-mhz
|
||||
Usage: Optional
|
||||
Value type: <u32>
|
||||
Definition:
|
||||
# u32 value representing CPU capacity [4] in
|
||||
DMIPS/MHz, relative to highest capacity-dmips-mhz
|
||||
in the system.
|
||||
|
||||
- rockchip,pmu
|
||||
Usage: optional for systems that have an "enable-method"
|
||||
property value of "rockchip,rk3066-smp"
|
||||
While optional, it is the preferred way to get access to
|
||||
the cpu-core power-domains.
|
||||
Value type: <phandle>
|
||||
Definition: Specifies the syscon node controlling the cpu core
|
||||
power domains.
|
||||
|
||||
- dynamic-power-coefficient
|
||||
Usage: optional
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A u32 value that represents the running time dynamic
|
||||
power coefficient in units of uW/MHz/V^2. The
|
||||
coefficient can either be calculated from power
|
||||
measurements or derived by analysis.
|
||||
|
||||
The dynamic power consumption of the CPU is
|
||||
proportional to the square of the Voltage (V) and
|
||||
the clock frequency (f). The coefficient is used to
|
||||
calculate the dynamic power as below -
|
||||
|
||||
Pdyn = dynamic-power-coefficient * V^2 * f
|
||||
|
||||
where voltage is in V, frequency is in MHz.
|
||||
|
||||
Example 1 (dual-cluster big.LITTLE system 32-bit):
|
||||
|
||||
cpus {
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a15";
|
||||
reg = <0x0>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a15";
|
||||
reg = <0x1>;
|
||||
};
|
||||
|
||||
cpu@100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a7";
|
||||
reg = <0x100>;
|
||||
};
|
||||
|
||||
cpu@101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a7";
|
||||
reg = <0x101>;
|
||||
};
|
||||
};
|
||||
|
||||
Example 2 (Cortex-A8 uniprocessor 32-bit system):
|
||||
|
||||
cpus {
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a8";
|
||||
reg = <0x0>;
|
||||
};
|
||||
};
|
||||
|
||||
Example 3 (ARM 926EJ-S uniprocessor 32-bit system):
|
||||
|
||||
cpus {
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,arm926ej-s";
|
||||
reg = <0x0>;
|
||||
};
|
||||
};
|
||||
|
||||
Example 4 (ARM Cortex-A57 64-bit system):
|
||||
|
||||
cpus {
|
||||
#size-cells = <0>;
|
||||
#address-cells = <2>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x0>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x1>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x100>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x101>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@10000 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x10000>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@10001 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x10001>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@10100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x10100>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@10101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x10101>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100000000 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x0>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100000001 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x1>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100000100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x100>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100000101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x101>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100010000 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x10000>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100010001 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x10001>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100010100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x10100>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100010101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x10101>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
};
|
||||
|
||||
--
|
||||
[1] arm/msm/qcom,saw2.txt
|
||||
[2] arm/msm/qcom,kpss-acc.txt
|
||||
[3] ARM Linux kernel documentation - idle states bindings
|
||||
Documentation/devicetree/bindings/arm/idle-states.txt
|
||||
[4] ARM Linux kernel documentation - cpu capacity bindings
|
||||
Documentation/devicetree/bindings/arm/cpu-capacity.txt
|
||||
|
|
@ -0,0 +1,507 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/cpus.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ARM CPUs bindings
|
||||
|
||||
maintainers:
|
||||
- Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
|
||||
|
||||
description: |+
|
||||
The device tree allows to describe the layout of CPUs in a system through
|
||||
the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
|
||||
defining properties for every cpu.
|
||||
|
||||
Bindings for CPU nodes follow the Devicetree Specification, available from:
|
||||
|
||||
https://www.devicetree.org/specifications/
|
||||
|
||||
with updates for 32-bit and 64-bit ARM systems provided in this document.
|
||||
|
||||
================================
|
||||
Convention used in this document
|
||||
================================
|
||||
|
||||
This document follows the conventions described in the Devicetree
|
||||
Specification, with the addition:
|
||||
|
||||
- square brackets define bitfields, eg reg[7:0] value of the bitfield in
|
||||
the reg property contained in bits 7 down to 0
|
||||
|
||||
=====================================
|
||||
cpus and cpu node bindings definition
|
||||
=====================================
|
||||
|
||||
The ARM architecture, in accordance with the Devicetree Specification,
|
||||
requires the cpus and cpu nodes to be present and contain the properties
|
||||
described below.
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: cpus
|
||||
description: Container of cpu nodes
|
||||
|
||||
'#address-cells':
|
||||
enum: [1, 2]
|
||||
description: |
|
||||
Definition depends on ARM architecture version and configuration:
|
||||
|
||||
On uniprocessor ARM architectures previous to v7
|
||||
value must be 1, to enable a simple enumeration
|
||||
scheme for processors that do not have a HW CPU
|
||||
identification register.
|
||||
On 32-bit ARM 11 MPcore, ARM v7 or later systems
|
||||
value must be 1, that corresponds to CPUID/MPIDR
|
||||
registers sizes.
|
||||
On ARM v8 64-bit systems value should be set to 2,
|
||||
that corresponds to the MPIDR_EL1 register size.
|
||||
If MPIDR_EL1[63:32] value is equal to 0 on all CPUs
|
||||
in the system, #address-cells can be set to 1, since
|
||||
MPIDR_EL1[63:32] bits are not used for CPUs
|
||||
identification.
|
||||
|
||||
'#size-cells':
|
||||
const: 0
|
||||
|
||||
patternProperties:
|
||||
'^cpu@[0-9a-f]+$':
|
||||
properties:
|
||||
device_type:
|
||||
const: cpu
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
description: |
|
||||
Usage and definition depend on ARM architecture version and
|
||||
configuration:
|
||||
|
||||
On uniprocessor ARM architectures previous to v7
|
||||
this property is required and must be set to 0.
|
||||
|
||||
On ARM 11 MPcore based systems this property is
|
||||
required and matches the CPUID[11:0] register bits.
|
||||
|
||||
Bits [11:0] in the reg cell must be set to
|
||||
bits [11:0] in CPU ID register.
|
||||
|
||||
All other bits in the reg cell must be set to 0.
|
||||
|
||||
On 32-bit ARM v7 or later systems this property is
|
||||
required and matches the CPU MPIDR[23:0] register
|
||||
bits.
|
||||
|
||||
Bits [23:0] in the reg cell must be set to
|
||||
bits [23:0] in MPIDR.
|
||||
|
||||
All other bits in the reg cell must be set to 0.
|
||||
|
||||
On ARM v8 64-bit systems this property is required
|
||||
and matches the MPIDR_EL1 register affinity bits.
|
||||
|
||||
* If cpus node's #address-cells property is set to 2
|
||||
|
||||
The first reg cell bits [7:0] must be set to
|
||||
bits [39:32] of MPIDR_EL1.
|
||||
|
||||
The second reg cell bits [23:0] must be set to
|
||||
bits [23:0] of MPIDR_EL1.
|
||||
|
||||
* If cpus node's #address-cells property is set to 1
|
||||
|
||||
The reg cell bits [23:0] must be set to bits [23:0]
|
||||
of MPIDR_EL1.
|
||||
|
||||
All other bits in the reg cells must be set to 0.
|
||||
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- arm,arm710t
|
||||
- arm,arm720t
|
||||
- arm,arm740t
|
||||
- arm,arm7ej-s
|
||||
- arm,arm7tdmi
|
||||
- arm,arm7tdmi-s
|
||||
- arm,arm9es
|
||||
- arm,arm9ej-s
|
||||
- arm,arm920t
|
||||
- arm,arm922t
|
||||
- arm,arm925
|
||||
- arm,arm926e-s
|
||||
- arm,arm926ej-s
|
||||
- arm,arm940t
|
||||
- arm,arm946e-s
|
||||
- arm,arm966e-s
|
||||
- arm,arm968e-s
|
||||
- arm,arm9tdmi
|
||||
- arm,arm1020e
|
||||
- arm,arm1020t
|
||||
- arm,arm1022e
|
||||
- arm,arm1026ej-s
|
||||
- arm,arm1136j-s
|
||||
- arm,arm1136jf-s
|
||||
- arm,arm1156t2-s
|
||||
- arm,arm1156t2f-s
|
||||
- arm,arm1176jzf
|
||||
- arm,arm1176jz-s
|
||||
- arm,arm1176jzf-s
|
||||
- arm,arm11mpcore
|
||||
- arm,armv8 # Only for s/w models
|
||||
- arm,cortex-a5
|
||||
- arm,cortex-a7
|
||||
- arm,cortex-a8
|
||||
- arm,cortex-a9
|
||||
- arm,cortex-a12
|
||||
- arm,cortex-a15
|
||||
- arm,cortex-a17
|
||||
- arm,cortex-a53
|
||||
- arm,cortex-a57
|
||||
- arm,cortex-a72
|
||||
- arm,cortex-a73
|
||||
- arm,cortex-m0
|
||||
- arm,cortex-m0+
|
||||
- arm,cortex-m1
|
||||
- arm,cortex-m3
|
||||
- arm,cortex-m4
|
||||
- arm,cortex-r4
|
||||
- arm,cortex-r5
|
||||
- arm,cortex-r7
|
||||
- brcm,brahma-b15
|
||||
- brcm,brahma-b53
|
||||
- brcm,vulcan
|
||||
- cavium,thunder
|
||||
- cavium,thunder2
|
||||
- faraday,fa526
|
||||
- intel,sa110
|
||||
- intel,sa1100
|
||||
- marvell,feroceon
|
||||
- marvell,mohawk
|
||||
- marvell,pj4a
|
||||
- marvell,pj4b
|
||||
- marvell,sheeva-v5
|
||||
- marvell,sheeva-v7
|
||||
- nvidia,tegra132-denver
|
||||
- nvidia,tegra186-denver
|
||||
- nvidia,tegra194-carmel
|
||||
- qcom,krait
|
||||
- qcom,kryo
|
||||
- qcom,kryo385
|
||||
- qcom,scorpion
|
||||
|
||||
enable-method:
|
||||
allOf:
|
||||
- $ref: '/schemas/types.yaml#/definitions/string'
|
||||
- oneOf:
|
||||
# On ARM v8 64-bit this property is required
|
||||
- enum:
|
||||
- psci
|
||||
- spin-table
|
||||
# On ARM 32-bit systems this property is optional
|
||||
- enum:
|
||||
- actions,s500-smp
|
||||
- allwinner,sun6i-a31
|
||||
- allwinner,sun8i-a23
|
||||
- allwinner,sun9i-a80-smp
|
||||
- allwinner,sun8i-a83t-smp
|
||||
- amlogic,meson8-smp
|
||||
- amlogic,meson8b-smp
|
||||
- arm,realview-smp
|
||||
- brcm,bcm11351-cpu-method
|
||||
- brcm,bcm23550
|
||||
- brcm,bcm2836-smp
|
||||
- brcm,bcm63138
|
||||
- brcm,bcm-nsp-smp
|
||||
- brcm,brahma-b15
|
||||
- marvell,armada-375-smp
|
||||
- marvell,armada-380-smp
|
||||
- marvell,armada-390-smp
|
||||
- marvell,armada-xp-smp
|
||||
- marvell,98dx3236-smp
|
||||
- mediatek,mt6589-smp
|
||||
- mediatek,mt81xx-tz-smp
|
||||
- qcom,gcc-msm8660
|
||||
- qcom,kpss-acc-v1
|
||||
- qcom,kpss-acc-v2
|
||||
- renesas,apmu
|
||||
- renesas,r9a06g032-smp
|
||||
- rockchip,rk3036-smp
|
||||
- rockchip,rk3066-smp
|
||||
- ste,dbx500-smp
|
||||
|
||||
cpu-release-addr:
|
||||
$ref: '/schemas/types.yaml#/definitions/uint64'
|
||||
|
||||
description:
|
||||
Required for systems that have an "enable-method"
|
||||
property value of "spin-table".
|
||||
On ARM v8 64-bit systems must be a two cell
|
||||
property identifying a 64-bit zero-initialised
|
||||
memory location.
|
||||
|
||||
cpu-idle-states:
|
||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
||||
description: |
|
||||
List of phandles to idle state nodes supported
|
||||
by this cpu (see ./idle-states.txt).
|
||||
|
||||
capacity-dmips-mhz:
|
||||
$ref: '/schemas/types.yaml#/definitions/uint32'
|
||||
description:
|
||||
u32 value representing CPU capacity (see ./cpu-capacity.txt) in
|
||||
DMIPS/MHz, relative to highest capacity-dmips-mhz
|
||||
in the system.
|
||||
|
||||
dynamic-power-coefficient:
|
||||
$ref: '/schemas/types.yaml#/definitions/uint32'
|
||||
description:
|
||||
A u32 value that represents the running time dynamic
|
||||
power coefficient in units of uW/MHz/V^2. The
|
||||
coefficient can either be calculated from power
|
||||
measurements or derived by analysis.
|
||||
|
||||
The dynamic power consumption of the CPU is
|
||||
proportional to the square of the Voltage (V) and
|
||||
the clock frequency (f). The coefficient is used to
|
||||
calculate the dynamic power as below -
|
||||
|
||||
Pdyn = dynamic-power-coefficient * V^2 * f
|
||||
|
||||
where voltage is in V, frequency is in MHz.
|
||||
|
||||
qcom,saw:
|
||||
$ref: '/schemas/types.yaml#/definitions/phandle'
|
||||
description: |
|
||||
Specifies the SAW* node associated with this CPU.
|
||||
|
||||
Required for systems that have an "enable-method" property
|
||||
value of "qcom,kpss-acc-v1" or "qcom,kpss-acc-v2"
|
||||
|
||||
* arm/msm/qcom,saw2.txt
|
||||
|
||||
qcom,acc:
|
||||
$ref: '/schemas/types.yaml#/definitions/phandle'
|
||||
description: |
|
||||
Specifies the ACC* node associated with this CPU.
|
||||
|
||||
Required for systems that have an "enable-method" property
|
||||
value of "qcom,kpss-acc-v1" or "qcom,kpss-acc-v2"
|
||||
|
||||
* arm/msm/qcom,kpss-acc.txt
|
||||
|
||||
rockchip,pmu:
|
||||
$ref: '/schemas/types.yaml#/definitions/phandle'
|
||||
description: |
|
||||
Specifies the syscon node controlling the cpu core power domains.
|
||||
|
||||
Optional for systems that have an "enable-method"
|
||||
property value of "rockchip,rk3066-smp"
|
||||
While optional, it is the preferred way to get access to
|
||||
the cpu-core power-domains.
|
||||
|
||||
required:
|
||||
- device_type
|
||||
- reg
|
||||
- compatible
|
||||
|
||||
dependencies:
|
||||
cpu-release-addr: [enable-method]
|
||||
rockchip,pmu: [enable-method]
|
||||
|
||||
required:
|
||||
- '#address-cells'
|
||||
- '#size-cells'
|
||||
|
||||
examples:
|
||||
- |
|
||||
cpus {
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a15";
|
||||
reg = <0x0>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a15";
|
||||
reg = <0x1>;
|
||||
};
|
||||
|
||||
cpu@100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a7";
|
||||
reg = <0x100>;
|
||||
};
|
||||
|
||||
cpu@101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a7";
|
||||
reg = <0x101>;
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
// Example 2 (Cortex-A8 uniprocessor 32-bit system):
|
||||
cpus {
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a8";
|
||||
reg = <0x0>;
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
// Example 3 (ARM 926EJ-S uniprocessor 32-bit system):
|
||||
cpus {
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,arm926ej-s";
|
||||
reg = <0x0>;
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
// Example 4 (ARM Cortex-A57 64-bit system):
|
||||
cpus {
|
||||
#size-cells = <0>;
|
||||
#address-cells = <2>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x0>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x1>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x100>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x101>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@10000 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x10000>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@10001 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x10001>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@10100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x10100>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@10101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x0 0x10101>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100000000 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x0>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100000001 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x1>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100000100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x100>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100000101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x101>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100010000 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x10000>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100010001 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x10001>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100010100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x10100>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
|
||||
cpu@100010101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x1 0x10101>;
|
||||
enable-method = "spin-table";
|
||||
cpu-release-addr = <0 0x20000000>;
|
||||
};
|
||||
};
|
||||
...
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
Texas Instruments DaVinci Platforms Device Tree Bindings
|
||||
--------------------------------------------------------
|
||||
|
||||
DA850/OMAP-L138/AM18x Evaluation Module (EVM) board
|
||||
Required root node properties:
|
||||
- compatible = "ti,da850-evm", "ti,da850";
|
||||
|
||||
DA850/OMAP-L138/AM18x L138/C6748 Development Kit (LCDK) board
|
||||
Required root node properties:
|
||||
- compatible = "ti,da850-lcdk", "ti,da850";
|
||||
|
||||
EnBW AM1808 based CMC board
|
||||
Required root node properties:
|
||||
- compatible = "enbw,cmc", "ti,da850;
|
||||
|
||||
LEGO MINDSTORMS EV3 (AM1808 based)
|
||||
Required root node properties:
|
||||
- compatible = "lego,ev3", "ti,da850";
|
||||
|
||||
Generic DaVinci Boards
|
||||
----------------------
|
||||
|
||||
DA850/OMAP-L138/AM18x generic board
|
||||
Required root node properties:
|
||||
- compatible = "ti,da850";
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
Emtrion Devicetree Bindings
|
||||
===========================
|
||||
|
||||
emCON Series:
|
||||
-------------
|
||||
|
||||
Required root node properties
|
||||
- compatible:
|
||||
- "emtrion,emcon-mx6", "fsl,imx6q"; : emCON-MX6D or emCON-MX6Q SoM
|
||||
- "emtrion,emcon-mx6-avari", "fsl,imx6q"; : emCON-MX6D or emCON-MX6Q SoM on Avari Base
|
||||
- "emtrion,emcon-mx6", "fsl,imx6dl"; : emCON-MX6S or emCON-MX6DL SoM
|
||||
- "emtrion,emcon-mx6-avari", "fsl,imx6dl"; : emCON-MX6S or emCON-MX6DL SoM on Avari Base
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
Freescale i.MX7ULP Power Management Components
|
||||
----------------------------------------------
|
||||
|
||||
The Multi-System Mode Controller (MSMC) is responsible for sequencing
|
||||
the MCU into and out of all stop and run power modes. Specifically, it
|
||||
monitors events to trigger transitions between power modes while
|
||||
controlling the power, clocks, and memories of the MCU to achieve the
|
||||
power consumption and functionality of that mode.
|
||||
|
||||
The WFI or WFE instruction is used to invoke a Sleep, Deep Sleep or
|
||||
Standby modes for either Cortex family. Run, Wait, and Stop are the
|
||||
common terms used for the primary operating modes of Kinetis
|
||||
microcontrollers.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,imx7ulp-smc1".
|
||||
- reg: Specifies base physical address and size of the register sets.
|
||||
|
||||
Example:
|
||||
smc1: smc1@40410000 {
|
||||
compatible = "fsl,imx7ulp-smc1";
|
||||
reg = <0x40410000 0x1000>;
|
||||
};
|
||||
|
|
@ -88,13 +88,16 @@ Pinctrl bindings based on SCU Message Protocol
|
|||
This binding uses the i.MX common pinctrl binding[3].
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,imx8qxp-iomuxc".
|
||||
- compatible: Should be one of:
|
||||
"fsl,imx8qm-iomuxc",
|
||||
"fsl,imx8qxp-iomuxc".
|
||||
|
||||
Required properties for Pinctrl sub nodes:
|
||||
- fsl,pins: Each entry consists of 3 integers which represents
|
||||
the mux and config setting for one pin. The first 2
|
||||
integers <pin_id mux_mode> are specified using a
|
||||
PIN_FUNC_ID macro, which can be found in
|
||||
<dt-bindings/pinctrl/pads-imx8qm.h>,
|
||||
<dt-bindings/pinctrl/pads-imx8qxp.h>.
|
||||
The last integer CONFIG is the pad setting value like
|
||||
pull-up on this pin.
|
||||
|
|
@ -106,6 +109,12 @@ Required properties for Pinctrl sub nodes:
|
|||
[2] Documentation/devicetree/bindings/power/power_domain.txt
|
||||
[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
|
||||
|
||||
RTC bindings based on SCU Message Protocol
|
||||
------------------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "fsl,imx8qxp-sc-rtc";
|
||||
|
||||
Example (imx8qxp):
|
||||
-------------
|
||||
lsio_mu1: mailbox@5d1c0000 {
|
||||
|
|
@ -148,6 +157,10 @@ firmware {
|
|||
compatible = "fsl,imx8qxp-scu-pd";
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
rtc: rtc {
|
||||
compatible = "fsl,imx8qxp-sc-rtc";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -101,6 +101,10 @@ i.MX7 SabreSD Board
|
|||
Required root node properties:
|
||||
- compatible = "fsl,imx7d-sdb", "fsl,imx7d";
|
||||
|
||||
i.MX7ULP Evaluation Kit
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx7ulp-evk", "fsl,imx7ulp";
|
||||
|
||||
Generic i.MX boards
|
||||
-------------------
|
||||
|
||||
|
|
@ -123,6 +127,10 @@ i.MX6q generic board
|
|||
Required root node properties:
|
||||
- compatible = "fsl,imx6q";
|
||||
|
||||
i.MX7ULP generic board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx7ulp";
|
||||
|
||||
Freescale Vybrid Platform Device Tree Bindings
|
||||
----------------------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -142,7 +142,7 @@ characterised by the following graph:
|
|||
|
||||
The graph is split in two parts delimited by time 1ms on the X-axis.
|
||||
The graph curve with X-axis values = { x | 0 < x < 1ms } has a steep slope
|
||||
and denotes the energy costs incurred whilst entering and leaving the idle
|
||||
and denotes the energy costs incurred while entering and leaving the idle
|
||||
state.
|
||||
The graph curve in the area delimited by X-axis values = {x | x > 1ms } has
|
||||
shallower slope and essentially represents the energy consumption of the idle
|
||||
|
|
|
|||
|
|
@ -11,4 +11,4 @@ Required root node properties:
|
|||
|
||||
MMP2 Brownstone Board
|
||||
Required root node properties:
|
||||
- compatible = "mrvl,mmp2-brownstone";
|
||||
- compatible = "mrvl,mmp2-brownstone", "mrvl,mmp2";
|
||||
|
|
|
|||
|
|
@ -1,14 +0,0 @@
|
|||
TI-NSPIRE calculators
|
||||
|
||||
Required properties:
|
||||
- compatible: Compatible property value should contain "ti,nspire".
|
||||
CX models should have "ti,nspire-cx"
|
||||
Touchpad models should have "ti,nspire-tp"
|
||||
Clickpad models should have "ti,nspire-clp"
|
||||
|
||||
Example:
|
||||
|
||||
/ {
|
||||
model = "TI-NSPIRE CX";
|
||||
compatible = "ti,nspire-cx";
|
||||
...
|
||||
|
|
@ -1,46 +0,0 @@
|
|||
* ARM Primecell Peripherals
|
||||
|
||||
ARM, Ltd. Primecell peripherals have a standard id register that can be used to
|
||||
identify the peripheral type, vendor, and revision. This value can be used for
|
||||
driver matching.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be a specific name for the peripheral and
|
||||
"arm,primecell". The specific name will match the ARM
|
||||
engineering name for the logic block in the form: "arm,pl???"
|
||||
|
||||
Optional properties:
|
||||
|
||||
- arm,primecell-periphid : Value to override the h/w value with
|
||||
- clocks : From common clock binding. First clock is phandle to clock for apb
|
||||
pclk. Additional clocks are optional and specific to those peripherals.
|
||||
- clock-names : From common clock binding. Shall be "apb_pclk" for first clock.
|
||||
- dmas : From common DMA binding. If present, refers to one or more dma channels.
|
||||
- dma-names : From common DMA binding, needs to match the 'dmas' property.
|
||||
Devices with exactly one receive and transmit channel shall name
|
||||
these "rx" and "tx", respectively.
|
||||
- pinctrl-<n> : Pinctrl states as described in bindings/pinctrl/pinctrl-bindings.txt
|
||||
- pinctrl-names : Names corresponding to the numbered pinctrl states
|
||||
- interrupts : one or more interrupt specifiers
|
||||
- interrupt-names : names corresponding to the interrupts properties
|
||||
|
||||
Example:
|
||||
|
||||
serial@fff36000 {
|
||||
compatible = "arm,pl011", "arm,primecell";
|
||||
arm,primecell-periphid = <0x00341011>;
|
||||
|
||||
clocks = <&pclk>;
|
||||
clock-names = "apb_pclk";
|
||||
|
||||
dmas = <&dma-controller 4>, <&dma-controller 5>;
|
||||
dma-names = "rx", "tx";
|
||||
|
||||
pinctrl-0 = <&uart0_default_mux>, <&uart0_default_mode>;
|
||||
pinctrl-1 = <&uart0_sleep_mode>;
|
||||
pinctrl-names = "default","sleep";
|
||||
|
||||
interrupts = <0 11 0x4>;
|
||||
};
|
||||
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/primecell.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ARM Primecell Peripherals
|
||||
|
||||
maintainers:
|
||||
- Rob Herring <robh@kernel.org>
|
||||
|
||||
description: |+
|
||||
ARM, Ltd. Primecell peripherals have a standard id register that can be used to
|
||||
identify the peripheral type, vendor, and revision. This value can be used for
|
||||
driver matching.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: arm,primecell
|
||||
description:
|
||||
Should be a specific name for the peripheral followed by "arm,primecell".
|
||||
The specific name will match the ARM engineering name for the logic block
|
||||
in the form "arm,pl???"
|
||||
|
||||
arm,primecell-periphid:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: Value to override the h/w ID value
|
||||
clocks:
|
||||
minItems: 1
|
||||
maxItems: 32
|
||||
clock-names:
|
||||
contains:
|
||||
const: apb_pclk
|
||||
additionalItems: true
|
||||
...
|
||||
|
|
@ -1,57 +0,0 @@
|
|||
QCOM device tree bindings
|
||||
-------------------------
|
||||
|
||||
Some qcom based bootloaders identify the dtb blob based on a set of
|
||||
device properties like SoC and platform and revisions of those components.
|
||||
To support this scheme, we encode this information into the board compatible
|
||||
string.
|
||||
|
||||
Each board must specify a top-level board compatible string with the following
|
||||
format:
|
||||
|
||||
compatible = "qcom,<SoC>[-<soc_version>][-<foundry_id>]-<board>[/<subtype>][-<board_version>]"
|
||||
|
||||
The 'SoC' and 'board' elements are required. All other elements are optional.
|
||||
|
||||
The 'SoC' element must be one of the following strings:
|
||||
|
||||
apq8016
|
||||
apq8074
|
||||
apq8084
|
||||
apq8096
|
||||
msm8916
|
||||
msm8974
|
||||
msm8992
|
||||
msm8994
|
||||
msm8996
|
||||
mdm9615
|
||||
ipq8074
|
||||
sdm845
|
||||
|
||||
The 'board' element must be one of the following strings:
|
||||
|
||||
cdp
|
||||
liquid
|
||||
dragonboard
|
||||
mtp
|
||||
sbc
|
||||
hk01
|
||||
|
||||
The 'soc_version' and 'board_version' elements take the form of v<Major>.<Minor>
|
||||
where the minor number may be omitted when it's zero, i.e. v1.0 is the same
|
||||
as v1. If all versions of the 'board_version' elements match, then a
|
||||
wildcard '*' should be used, e.g. 'v*'.
|
||||
|
||||
The 'foundry_id' and 'subtype' elements are one or more digits from 0 to 9.
|
||||
|
||||
Examples:
|
||||
|
||||
"qcom,msm8916-v1-cdp-pm8916-v2.1"
|
||||
|
||||
A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of version
|
||||
2.1.
|
||||
|
||||
"qcom,apq8074-v2.0-2-dragonboard/1-v0.1"
|
||||
|
||||
A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in
|
||||
foundry 2.
|
||||
|
|
@ -0,0 +1,125 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/bindings/arm/qcom.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: QCOM device tree bindings
|
||||
|
||||
maintainers:
|
||||
- Stephen Boyd <sboyd@codeaurora.org>
|
||||
|
||||
description: |
|
||||
Some qcom based bootloaders identify the dtb blob based on a set of
|
||||
device properties like SoC and platform and revisions of those components.
|
||||
To support this scheme, we encode this information into the board compatible
|
||||
string.
|
||||
|
||||
Each board must specify a top-level board compatible string with the following
|
||||
format:
|
||||
|
||||
compatible = "qcom,<SoC>[-<soc_version>][-<foundry_id>]-<board>[/<subtype>][-<board_version>]"
|
||||
|
||||
The 'SoC' and 'board' elements are required. All other elements are optional.
|
||||
|
||||
The 'SoC' element must be one of the following strings:
|
||||
|
||||
apq8016
|
||||
apq8074
|
||||
apq8084
|
||||
apq8096
|
||||
msm8916
|
||||
msm8974
|
||||
msm8992
|
||||
msm8994
|
||||
msm8996
|
||||
mdm9615
|
||||
ipq8074
|
||||
sdm845
|
||||
|
||||
The 'board' element must be one of the following strings:
|
||||
|
||||
cdp
|
||||
liquid
|
||||
dragonboard
|
||||
mtp
|
||||
sbc
|
||||
hk01
|
||||
|
||||
The 'soc_version' and 'board_version' elements take the form of v<Major>.<Minor>
|
||||
where the minor number may be omitted when it's zero, i.e. v1.0 is the same
|
||||
as v1. If all versions of the 'board_version' elements match, then a
|
||||
wildcard '*' should be used, e.g. 'v*'.
|
||||
|
||||
The 'foundry_id' and 'subtype' elements are one or more digits from 0 to 9.
|
||||
|
||||
Examples:
|
||||
|
||||
"qcom,msm8916-v1-cdp-pm8916-v2.1"
|
||||
|
||||
A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of version
|
||||
2.1.
|
||||
|
||||
"qcom,apq8074-v2.0-2-dragonboard/1-v0.1"
|
||||
|
||||
A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in
|
||||
foundry 2.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,apq8016-sbc
|
||||
- const: qcom,apq8016
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,apq8064-cm-qs600
|
||||
- qcom,apq8064-ifc6410
|
||||
- const: qcom,apq8064
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,apq8074-dragonboard
|
||||
- const: qcom,apq8074
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,apq8060-dragonboard
|
||||
- qcom,msm8660-surf
|
||||
- const: qcom,msm8660
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,apq8084-mtp
|
||||
- qcom,apq8084-sbc
|
||||
- const: qcom,apq8084
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,msm8960-cdp
|
||||
- const: qcom,msm8960
|
||||
|
||||
- items:
|
||||
- const: qcom,msm8916-mtp/1
|
||||
- const: qcom,msm8916-mtp
|
||||
- const: qcom,msm8916
|
||||
|
||||
- items:
|
||||
- const: qcom,msm8996-mtp
|
||||
|
||||
- items:
|
||||
- const: qcom,ipq4019
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,ipq8064-ap148
|
||||
- const: qcom,ipq8064
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,ipq8074-hk01
|
||||
- const: qcom,ipq8074
|
||||
|
||||
...
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
Renesas Product Register
|
||||
|
||||
Most Renesas ARM SoCs have a Product Register or Boundary Scan ID Register that
|
||||
allows to retrieve SoC product and revision information. If present, a device
|
||||
node for this register should be added.
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be one of:
|
||||
"renesas,prr"
|
||||
"renesas,bsid"
|
||||
- reg: Base address and length of the register block.
|
||||
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
prr: chipid@ff000044 {
|
||||
compatible = "renesas,prr";
|
||||
reg = <0 0xff000044 0 4>;
|
||||
};
|
||||
|
|
@ -1,240 +0,0 @@
|
|||
Rockchip platforms device tree bindings
|
||||
---------------------------------------
|
||||
|
||||
- 96boards RK3399 Ficus (ROCK960 Enterprise Edition)
|
||||
Required root node properties:
|
||||
- compatible = "vamrs,ficus", "rockchip,rk3399";
|
||||
|
||||
- 96boards RK3399 Rock960 (ROCK960 Consumer Edition)
|
||||
Required root node properties:
|
||||
- compatible = "vamrs,rock960", "rockchip,rk3399";
|
||||
|
||||
- Amarula Vyasa RK3288 board
|
||||
Required root node properties:
|
||||
- compatible = "amarula,vyasa-rk3288", "rockchip,rk3288";
|
||||
|
||||
- Asus Tinker board
|
||||
Required root node properties:
|
||||
- compatible = "asus,rk3288-tinker", "rockchip,rk3288";
|
||||
|
||||
- Asus Tinker board S
|
||||
Required root node properties:
|
||||
- compatible = "asus,rk3288-tinker-s", "rockchip,rk3288";
|
||||
|
||||
- Kylin RK3036 board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,kylin-rk3036", "rockchip,rk3036";
|
||||
|
||||
- MarsBoard RK3066 board:
|
||||
Required root node properties:
|
||||
- compatible = "haoyu,marsboard-rk3066", "rockchip,rk3066a";
|
||||
|
||||
- bq Curie 2 tablet:
|
||||
Required root node properties:
|
||||
- compatible = "mundoreader,bq-curie2", "rockchip,rk3066a";
|
||||
|
||||
- ChipSPARK Rayeager PX2 board:
|
||||
Required root node properties:
|
||||
- compatible = "chipspark,rayeager-px2", "rockchip,rk3066a";
|
||||
|
||||
- Radxa Rock board:
|
||||
Required root node properties:
|
||||
- compatible = "radxa,rock", "rockchip,rk3188";
|
||||
|
||||
- Radxa Rock2 Square board:
|
||||
Required root node properties:
|
||||
- compatible = "radxa,rock2-square", "rockchip,rk3288";
|
||||
|
||||
- Rikomagic MK808 v1 board:
|
||||
Required root node properties:
|
||||
- compatible = "rikomagic,mk808", "rockchip,rk3066a";
|
||||
|
||||
- Firefly Firefly-RK3288 board:
|
||||
Required root node properties:
|
||||
- compatible = "firefly,firefly-rk3288", "rockchip,rk3288";
|
||||
or
|
||||
- compatible = "firefly,firefly-rk3288-beta", "rockchip,rk3288";
|
||||
|
||||
- Firefly Firefly-RK3288 Reload board:
|
||||
Required root node properties:
|
||||
- compatible = "firefly,firefly-rk3288-reload", "rockchip,rk3288";
|
||||
|
||||
- Firefly Firefly-RK3399 board:
|
||||
Required root node properties:
|
||||
- compatible = "firefly,firefly-rk3399", "rockchip,rk3399";
|
||||
|
||||
- Firefly roc-rk3328-cc board:
|
||||
Required root node properties:
|
||||
- compatible = "firefly,roc-rk3328-cc", "rockchip,rk3328";
|
||||
|
||||
- Firefly ROC-RK3399-PC board:
|
||||
Required root node properties:
|
||||
- compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
|
||||
|
||||
- ChipSPARK PopMetal-RK3288 board:
|
||||
Required root node properties:
|
||||
- compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";
|
||||
|
||||
- Netxeon R89 board:
|
||||
Required root node properties:
|
||||
- compatible = "netxeon,r89", "rockchip,rk3288";
|
||||
|
||||
- GeekBuying GeekBox:
|
||||
Required root node properties:
|
||||
- compatible = "geekbuying,geekbox", "rockchip,rk3368";
|
||||
|
||||
- Google Bob (Asus Chromebook Flip C101PA):
|
||||
Required root node properties:
|
||||
compatible = "google,bob-rev13", "google,bob-rev12",
|
||||
"google,bob-rev11", "google,bob-rev10",
|
||||
"google,bob-rev9", "google,bob-rev8",
|
||||
"google,bob-rev7", "google,bob-rev6",
|
||||
"google,bob-rev5", "google,bob-rev4",
|
||||
"google,bob", "google,gru", "rockchip,rk3399";
|
||||
|
||||
- Google Brain (dev-board):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-brain-rev0", "google,veyron-brain",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Gru (dev-board):
|
||||
Required root node properties:
|
||||
- compatible = "google,gru-rev15", "google,gru-rev14",
|
||||
"google,gru-rev13", "google,gru-rev12",
|
||||
"google,gru-rev11", "google,gru-rev10",
|
||||
"google,gru-rev9", "google,gru-rev8",
|
||||
"google,gru-rev7", "google,gru-rev6",
|
||||
"google,gru-rev5", "google,gru-rev4",
|
||||
"google,gru-rev3", "google,gru-rev2",
|
||||
"google,gru", "rockchip,rk3399";
|
||||
|
||||
- Google Jaq (Haier Chromebook 11 and more):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-jaq-rev5", "google,veyron-jaq-rev4",
|
||||
"google,veyron-jaq-rev3", "google,veyron-jaq-rev2",
|
||||
"google,veyron-jaq-rev1", "google,veyron-jaq",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Jerry (Hisense Chromebook C11 and more):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-jerry-rev7", "google,veyron-jerry-rev6",
|
||||
"google,veyron-jerry-rev5", "google,veyron-jerry-rev4",
|
||||
"google,veyron-jerry-rev3", "google,veyron-jerry",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Kevin (Samsung Chromebook Plus):
|
||||
Required root node properties:
|
||||
- compatible = "google,kevin-rev15", "google,kevin-rev14",
|
||||
"google,kevin-rev13", "google,kevin-rev12",
|
||||
"google,kevin-rev11", "google,kevin-rev10",
|
||||
"google,kevin-rev9", "google,kevin-rev8",
|
||||
"google,kevin-rev7", "google,kevin-rev6",
|
||||
"google,kevin", "google,gru", "rockchip,rk3399";
|
||||
|
||||
- Google Mickey (Asus Chromebit CS10):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-mickey-rev8", "google,veyron-mickey-rev7",
|
||||
"google,veyron-mickey-rev6", "google,veyron-mickey-rev5",
|
||||
"google,veyron-mickey-rev4", "google,veyron-mickey-rev3",
|
||||
"google,veyron-mickey-rev2", "google,veyron-mickey-rev1",
|
||||
"google,veyron-mickey-rev0", "google,veyron-mickey",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Minnie (Asus Chromebook Flip C100P):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-minnie-rev4", "google,veyron-minnie-rev3",
|
||||
"google,veyron-minnie-rev2", "google,veyron-minnie-rev1",
|
||||
"google,veyron-minnie-rev0", "google,veyron-minnie",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Pinky (dev-board):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-pinky-rev2", "google,veyron-pinky",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Speedy (Asus C201 Chromebook):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
|
||||
"google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
|
||||
"google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
|
||||
"google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
|
||||
"google,veyron-speedy", "google,veyron", "rockchip,rk3288";
|
||||
|
||||
- mqmaker MiQi:
|
||||
Required root node properties:
|
||||
- compatible = "mqmaker,miqi", "rockchip,rk3288";
|
||||
|
||||
- Phytec phyCORE-RK3288: Rapid Development Kit
|
||||
Required root node properties:
|
||||
- compatible = "phytec,rk3288-pcm-947", "phytec,rk3288-phycore-som", "rockchip,rk3288";
|
||||
|
||||
- Pine64 Rock64 board:
|
||||
Required root node properties:
|
||||
- compatible = "pine64,rock64", "rockchip,rk3328";
|
||||
|
||||
- Pine64 RockPro64 board:
|
||||
Required root node properties:
|
||||
- compatible = "pine64,rockpro64", "rockchip,rk3399";
|
||||
|
||||
- Rockchip PX3 Evaluation board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,px3-evb", "rockchip,px3", "rockchip,rk3188";
|
||||
|
||||
- Rockchip PX5 Evaluation board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,px5-evb", "rockchip,px5", "rockchip,rk3368";
|
||||
|
||||
- Rockchip PX30 Evaluation board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,px30-evb", "rockchip,px30";
|
||||
|
||||
- Rockchip RV1108 Evaluation board
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,rv1108-evb", "rockchip,rv1108";
|
||||
|
||||
- Rockchip RK3368 evb:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,rk3368-evb-act8846", "rockchip,rk3368";
|
||||
|
||||
- Rockchip R88 board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,r88", "rockchip,rk3368";
|
||||
|
||||
- Rockchip RK3228 Evaluation board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
|
||||
|
||||
- Rockchip RK3229 Evaluation board:
|
||||
- compatible = "rockchip,rk3229-evb", "rockchip,rk3229";
|
||||
|
||||
- Rockchip RK3288 Fennec board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,rk3288-fennec", "rockchip,rk3288";
|
||||
|
||||
- Rockchip RK3328 evb:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,rk3328-evb", "rockchip,rk3328";
|
||||
|
||||
- Rockchip RK3399 evb:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,rk3399-evb", "rockchip,rk3399";
|
||||
|
||||
- Rockchip RK3399 Sapphire board standalone:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,rk3399-sapphire", "rockchip,rk3399";
|
||||
|
||||
- Rockchip RK3399 Sapphire Excavator board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,rk3399-sapphire-excavator", "rockchip,rk3399";
|
||||
|
||||
- Theobroma Systems RK3368-uQ7 Haikou Baseboard:
|
||||
Required root node properties:
|
||||
- compatible = "tsd,rk3368-uq7-haikou", "rockchip,rk3368";
|
||||
|
||||
- Theobroma Systems RK3399-Q7 Haikou Baseboard:
|
||||
Required root node properties:
|
||||
- compatible = "tsd,rk3399-q7-haikou", "rockchip,rk3399";
|
||||
|
||||
- Tronsmart Orion R68 Meta
|
||||
Required root node properties:
|
||||
- compatible = "tronsmart,orion-r68-meta", "rockchip,rk3368";
|
||||
|
|
@ -0,0 +1,423 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/rockchip.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Rockchip platforms device tree bindings
|
||||
|
||||
maintainers:
|
||||
- Heiko Stuebner <heiko@sntech.de>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: '/'
|
||||
compatible:
|
||||
oneOf:
|
||||
|
||||
- description: 96boards RK3399 Ficus (ROCK960 Enterprise Edition)
|
||||
items:
|
||||
- const: vamrs,ficus
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: 96boards RK3399 Rock960 (ROCK960 Consumer Edition)
|
||||
items:
|
||||
- const: vamrs,rock960
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: Amarula Vyasa RK3288
|
||||
items:
|
||||
- const: amarula,vyasa-rk3288
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Asus Tinker board
|
||||
items:
|
||||
- const: asus,rk3288-tinker
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Asus Tinker board S
|
||||
items:
|
||||
- const: asus,rk3288-tinker-s
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: bq Curie 2 tablet
|
||||
items:
|
||||
- const: mundoreader,bq-curie2
|
||||
- const: rockchip,rk3066a
|
||||
|
||||
- description: bq Edison 2 Quad-Core tablet
|
||||
items:
|
||||
- const: mundoreader,bq-edison2qc
|
||||
- const: rockchip,rk3188
|
||||
|
||||
- description: ChipSPARK PopMetal-RK3288
|
||||
items:
|
||||
- const: chipspark,popmetal-rk3288
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: ChipSPARK Rayeager PX2
|
||||
items:
|
||||
- const: chipspark,rayeager-px2
|
||||
- const: rockchip,rk3066a
|
||||
|
||||
- description: Firefly Firefly-RK3288
|
||||
items:
|
||||
- enum:
|
||||
- firefly,firefly-rk3288
|
||||
- firefly,firefly-rk3288-beta
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Firefly Firefly-RK3288 Reload
|
||||
items:
|
||||
- const: firefly,firefly-rk3288-reload
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Firefly Firefly-RK3399
|
||||
items:
|
||||
- const: firefly,firefly-rk3399
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: Firefly roc-rk3328-cc
|
||||
items:
|
||||
- const: firefly,roc-rk3328-cc
|
||||
- const: rockchip,rk3328
|
||||
|
||||
- description: Firefly ROC-RK3399-PC
|
||||
items:
|
||||
- const: firefly,roc-rk3399-pc
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: GeekBuying GeekBox
|
||||
items:
|
||||
- const: geekbuying,geekbox
|
||||
- const: rockchip,rk3368
|
||||
|
||||
- description: Google Bob (Asus Chromebook Flip C101PA)
|
||||
items:
|
||||
- const: google,bob-rev13
|
||||
- const: google,bob-rev12
|
||||
- const: google,bob-rev11
|
||||
- const: google,bob-rev10
|
||||
- const: google,bob-rev9
|
||||
- const: google,bob-rev8
|
||||
- const: google,bob-rev7
|
||||
- const: google,bob-rev6
|
||||
- const: google,bob-rev5
|
||||
- const: google,bob-rev4
|
||||
- const: google,bob
|
||||
- const: google,gru
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: Google Brain (dev-board)
|
||||
items:
|
||||
- const: google,veyron-brain-rev0
|
||||
- const: google,veyron-brain
|
||||
- const: google,veyron
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Google Gru (dev-board)
|
||||
items:
|
||||
- const: google,gru-rev15
|
||||
- const: google,gru-rev14
|
||||
- const: google,gru-rev13
|
||||
- const: google,gru-rev12
|
||||
- const: google,gru-rev11
|
||||
- const: google,gru-rev10
|
||||
- const: google,gru-rev9
|
||||
- const: google,gru-rev8
|
||||
- const: google,gru-rev7
|
||||
- const: google,gru-rev6
|
||||
- const: google,gru-rev5
|
||||
- const: google,gru-rev4
|
||||
- const: google,gru-rev3
|
||||
- const: google,gru-rev2
|
||||
- const: google,gru
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: Google Jaq (Haier Chromebook 11 and more)
|
||||
items:
|
||||
- const: google,veyron-jaq-rev5
|
||||
- const: google,veyron-jaq-rev4
|
||||
- const: google,veyron-jaq-rev3
|
||||
- const: google,veyron-jaq-rev2
|
||||
- const: google,veyron-jaq-rev1
|
||||
- const: google,veyron-jaq
|
||||
- const: google,veyron
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Google Jerry (Hisense Chromebook C11 and more)
|
||||
items:
|
||||
- const: google,veyron-jerry-rev7
|
||||
- const: google,veyron-jerry-rev6
|
||||
- const: google,veyron-jerry-rev5
|
||||
- const: google,veyron-jerry-rev4
|
||||
- const: google,veyron-jerry-rev3
|
||||
- const: google,veyron-jerry
|
||||
- const: google,veyron
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Google Kevin (Samsung Chromebook Plus)
|
||||
items:
|
||||
- const: google,kevin-rev15
|
||||
- const: google,kevin-rev14
|
||||
- const: google,kevin-rev13
|
||||
- const: google,kevin-rev12
|
||||
- const: google,kevin-rev11
|
||||
- const: google,kevin-rev10
|
||||
- const: google,kevin-rev9
|
||||
- const: google,kevin-rev8
|
||||
- const: google,kevin-rev7
|
||||
- const: google,kevin-rev6
|
||||
- const: google,kevin
|
||||
- const: google,gru
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: Google Mickey (Asus Chromebit CS10)
|
||||
items:
|
||||
- const: google,veyron-mickey-rev8
|
||||
- const: google,veyron-mickey-rev7
|
||||
- const: google,veyron-mickey-rev6
|
||||
- const: google,veyron-mickey-rev5
|
||||
- const: google,veyron-mickey-rev4
|
||||
- const: google,veyron-mickey-rev3
|
||||
- const: google,veyron-mickey-rev2
|
||||
- const: google,veyron-mickey-rev1
|
||||
- const: google,veyron-mickey-rev0
|
||||
- const: google,veyron-mickey
|
||||
- const: google,veyron
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Google Minnie (Asus Chromebook Flip C100P)
|
||||
items:
|
||||
- const: google,veyron-minnie-rev4
|
||||
- const: google,veyron-minnie-rev3
|
||||
- const: google,veyron-minnie-rev2
|
||||
- const: google,veyron-minnie-rev1
|
||||
- const: google,veyron-minnie-rev0
|
||||
- const: google,veyron-minnie
|
||||
- const: google,veyron
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Google Pinky (dev-board)
|
||||
items:
|
||||
- const: google,veyron-pinky-rev2
|
||||
- const: google,veyron-pinky
|
||||
- const: google,veyron
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Google Scarlet - Kingdisplay (Acer Chromebook Tab 10)
|
||||
items:
|
||||
- const: google,scarlet-rev15-sku7
|
||||
- const: google,scarlet-rev15
|
||||
- const: google,scarlet-rev14-sku7
|
||||
- const: google,scarlet-rev14
|
||||
- const: google,scarlet-rev13-sku7
|
||||
- const: google,scarlet-rev13
|
||||
- const: google,scarlet-rev12-sku7
|
||||
- const: google,scarlet-rev12
|
||||
- const: google,scarlet-rev11-sku7
|
||||
- const: google,scarlet-rev11
|
||||
- const: google,scarlet-rev10-sku7
|
||||
- const: google,scarlet-rev10
|
||||
- const: google,scarlet-rev9-sku7
|
||||
- const: google,scarlet-rev9
|
||||
- const: google,scarlet-rev8-sku7
|
||||
- const: google,scarlet-rev8
|
||||
- const: google,scarlet-rev7-sku7
|
||||
- const: google,scarlet-rev7
|
||||
- const: google,scarlet-rev6-sku7
|
||||
- const: google,scarlet-rev6
|
||||
- const: google,scarlet-rev5-sku7
|
||||
- const: google,scarlet-rev5
|
||||
- const: google,scarlet-rev4-sku7
|
||||
- const: google,scarlet-rev4
|
||||
- const: google,scarlet-rev3-sku7
|
||||
- const: google,scarlet-rev3
|
||||
- const: google,scarlet
|
||||
- const: google,gru
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: Google Scarlet - Innolux display (Acer Chromebook Tab 10)
|
||||
items:
|
||||
- const: google,scarlet-rev15-sku6
|
||||
- const: google,scarlet-rev15
|
||||
- const: google,scarlet-rev14-sku6
|
||||
- const: google,scarlet-rev14
|
||||
- const: google,scarlet-rev13-sku6
|
||||
- const: google,scarlet-rev13
|
||||
- const: google,scarlet-rev12-sku6
|
||||
- const: google,scarlet-rev12
|
||||
- const: google,scarlet-rev11-sku6
|
||||
- const: google,scarlet-rev11
|
||||
- const: google,scarlet-rev10-sku6
|
||||
- const: google,scarlet-rev10
|
||||
- const: google,scarlet-rev9-sku6
|
||||
- const: google,scarlet-rev9
|
||||
- const: google,scarlet-rev8-sku6
|
||||
- const: google,scarlet-rev8
|
||||
- const: google,scarlet-rev7-sku6
|
||||
- const: google,scarlet-rev7
|
||||
- const: google,scarlet-rev6-sku6
|
||||
- const: google,scarlet-rev6
|
||||
- const: google,scarlet-rev5-sku6
|
||||
- const: google,scarlet-rev5
|
||||
- const: google,scarlet-rev4-sku6
|
||||
- const: google,scarlet-rev4
|
||||
- const: google,scarlet
|
||||
- const: google,gru
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: Google Speedy (Asus C201 Chromebook)
|
||||
items:
|
||||
- const: google,veyron-speedy-rev9
|
||||
- const: google,veyron-speedy-rev8
|
||||
- const: google,veyron-speedy-rev7
|
||||
- const: google,veyron-speedy-rev6
|
||||
- const: google,veyron-speedy-rev5
|
||||
- const: google,veyron-speedy-rev4
|
||||
- const: google,veyron-speedy-rev3
|
||||
- const: google,veyron-speedy-rev2
|
||||
- const: google,veyron-speedy
|
||||
- const: google,veyron
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Haoyu MarsBoard RK3066
|
||||
items:
|
||||
- const: haoyu,marsboard-rk3066
|
||||
- const: rockchip,rk3066a
|
||||
|
||||
- description: mqmaker MiQi
|
||||
items:
|
||||
- const: mqmaker,miqi
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Netxeon R89 board
|
||||
items:
|
||||
- const: netxeon,r89
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Phytec phyCORE-RK3288 Rapid Development Kit
|
||||
items:
|
||||
- const: phytec,rk3288-pcm-947
|
||||
- const: phytec,rk3288-phycore-som
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Pine64 Rock64
|
||||
items:
|
||||
- const: pine64,rock64
|
||||
- const: rockchip,rk3328
|
||||
|
||||
- description: Pine64 RockPro64
|
||||
items:
|
||||
- const: pine64,rockpro64
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: Radxa Rock
|
||||
items:
|
||||
- const: radxa,rock
|
||||
- const: rockchip,rk3188
|
||||
|
||||
- description: Radxa Rock2 Square
|
||||
items:
|
||||
- const: radxa,rock2-square
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Rikomagic MK808 v1
|
||||
items:
|
||||
- const: rikomagic,mk808
|
||||
- const: rockchip,rk3066a
|
||||
|
||||
- description: Rockchip Kylin
|
||||
items:
|
||||
- const: rockchip,kylin-rk3036
|
||||
- const: rockchip,rk3036
|
||||
|
||||
- description: Rockchip PX3 Evaluation board
|
||||
items:
|
||||
- const: rockchip,px3-evb
|
||||
- const: rockchip,px3
|
||||
- const: rockchip,rk3188
|
||||
|
||||
- description: Rockchip PX30 Evaluation board
|
||||
items:
|
||||
- const: rockchip,px30-evb
|
||||
- const: rockchip,px30
|
||||
|
||||
- description: Rockchip PX5 Evaluation board
|
||||
items:
|
||||
- const: rockchip,px5-evb
|
||||
- const: rockchip,px5
|
||||
- const: rockchip,rk3368
|
||||
|
||||
- description: Rockchip R88
|
||||
items:
|
||||
- const: rockchip,r88
|
||||
- const: rockchip,rk3368
|
||||
|
||||
- description: Rockchip RK3228 Evaluation board
|
||||
items:
|
||||
- const: rockchip,rk3228-evb
|
||||
- const: rockchip,rk3228
|
||||
|
||||
- description: Rockchip RK3229 Evaluation board
|
||||
items:
|
||||
- const: rockchip,rk3229-evb
|
||||
- const: rockchip,rk3229
|
||||
|
||||
- description: Rockchip RK3288 Evaluation board
|
||||
items:
|
||||
- enum:
|
||||
- rockchip,rk3288-evb-act8846
|
||||
- rockchip,rk3288-evb-rk808
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Rockchip RK3288 Fennec
|
||||
items:
|
||||
- const: rockchip,rk3288-fennec
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Rockchip RK3328 Evaluation board
|
||||
items:
|
||||
- const: rockchip,rk3328-evb
|
||||
- const: rockchip,rk3328
|
||||
|
||||
- description: Rockchip RK3368 Evaluation board (act8846 pmic)
|
||||
items:
|
||||
- const: rockchip,rk3368-evb-act8846
|
||||
- const: rockchip,rk3368
|
||||
|
||||
- description: Rockchip RK3399 Evaluation board
|
||||
items:
|
||||
- const: rockchip,rk3399-evb
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: Rockchip RK3399 Sapphire standalone
|
||||
items:
|
||||
- const: rockchip,rk3399-sapphire
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: Rockchip RK3399 Sapphire with Excavator Baseboard
|
||||
items:
|
||||
- const: rockchip,rk3399-sapphire-excavator
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: Rockchip RV1108 Evaluation board
|
||||
items:
|
||||
- const: rockchip,rv1108-evb
|
||||
- const: rockchip,rv1108
|
||||
|
||||
- description: Theobroma Systems RK3368-uQ7 with Haikou baseboard
|
||||
items:
|
||||
- const: tsd,rk3368-uq7-haikou
|
||||
- const: rockchip,rk3368
|
||||
|
||||
- description: Theobroma Systems RK3399-Q7 with Haikou baseboard
|
||||
items:
|
||||
- const: tsd,rk3399-q7-haikou
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: Tronsmart Orion R68 Meta
|
||||
items:
|
||||
- const: tronsmart,orion-r68-meta
|
||||
- const: rockchip,rk3368
|
||||
...
|
||||
|
|
@ -101,6 +101,10 @@ Boards:
|
|||
compatible = "iwave,g20d", "iwave,g20m", "renesas,r8a7743"
|
||||
- iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven)
|
||||
compatible = "iwave,g20m", "renesas,r8a7743"
|
||||
- iWave Systems RZ/G1N Qseven Development Platform (iW-RainboW-G20D-Qseven)
|
||||
compatible = "iwave,g20d", "iwave,g20m", "renesas,r8a7744"
|
||||
- iWave Systems RZ/G1N Qseven System On Module (iW-RainboW-G20M-Qseven)
|
||||
compatible = "iwave,g20m", "renesas,r8a7744"
|
||||
- Kingfisher (SBEV-RCAR-KF-M03)
|
||||
compatible = "shimafuji,kingfisher"
|
||||
- Koelsch (RTP0RC7791SEB00010S)
|
||||
|
|
@ -149,21 +153,3 @@ Boards:
|
|||
compatible = "renesas,v3msk", "renesas,r8a77970"
|
||||
- Wheat (RTP0RC7792ASKB0000JE)
|
||||
compatible = "renesas,wheat", "renesas,r8a7792"
|
||||
|
||||
|
||||
Most Renesas ARM SoCs have a Product Register or Boundary Scan ID Register that
|
||||
allows to retrieve SoC product and revision information. If present, a device
|
||||
node for this register should be added.
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "renesas,prr" or "renesas,bsid"
|
||||
- reg: Base address and length of the register block.
|
||||
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
prr: chipid@ff000044 {
|
||||
compatible = "renesas,prr";
|
||||
reg = <0 0xff000044 0 4>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,11 +0,0 @@
|
|||
CSR SiRFprimaII and SiRFmarco device tree bindings.
|
||||
========================================
|
||||
|
||||
Required root node properties:
|
||||
- compatible:
|
||||
- "sirf,atlas6-cb" : atlas6 "cb" evaluation board
|
||||
- "sirf,atlas6" : atlas6 device based board
|
||||
- "sirf,atlas7-cb" : atlas7 "cb" evaluation board
|
||||
- "sirf,atlas7" : atlas7 device based board
|
||||
- "sirf,prima2-cb" : prima2 "cb" evaluation board
|
||||
- "sirf,prima2" : prima2 device based board
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/sirf.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: CSR SiRFprimaII and SiRFmarco device tree bindings.
|
||||
|
||||
maintainers:
|
||||
- Binghua Duan <binghua.duan@csr.com>
|
||||
- Barry Song <Baohua.Song@csr.com>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: '/'
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: sirf,atlas6-cb
|
||||
- const: sirf,atlas6
|
||||
- items:
|
||||
- const: sirf,atlas7-cb
|
||||
- const: sirf,atlas7
|
||||
- items:
|
||||
- const: sirf,prima2-cb
|
||||
- const: sirf,prima2
|
||||
...
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
Socionext UniPhier SoC family
|
||||
-----------------------------
|
||||
|
||||
Required properties in the root node:
|
||||
- compatible: should contain board and SoC compatible strings
|
||||
|
||||
SoC and board compatible strings:
|
||||
(sorted chronologically)
|
||||
|
||||
- LD4 SoC: "socionext,uniphier-ld4"
|
||||
- Reference Board: "socionext,uniphier-ld4-ref"
|
||||
|
||||
- Pro4 SoC: "socionext,uniphier-pro4"
|
||||
- Reference Board: "socionext,uniphier-pro4-ref"
|
||||
- Ace Board: "socionext,uniphier-pro4-ace"
|
||||
- Sanji Board: "socionext,uniphier-pro4-sanji"
|
||||
|
||||
- sLD8 SoC: "socionext,uniphier-sld8"
|
||||
- Reference Board: "socionext,uniphier-sld8-ref"
|
||||
|
||||
- PXs2 SoC: "socionext,uniphier-pxs2"
|
||||
- Gentil Board: "socionext,uniphier-pxs2-gentil"
|
||||
- Vodka Board: "socionext,uniphier-pxs2-vodka"
|
||||
|
||||
- LD6b SoC: "socionext,uniphier-ld6b"
|
||||
- Reference Board: "socionext,uniphier-ld6b-ref"
|
||||
|
||||
- LD11 SoC: "socionext,uniphier-ld11"
|
||||
- Reference Board: "socionext,uniphier-ld11-ref"
|
||||
- Global Board: "socionext,uniphier-ld11-global"
|
||||
|
||||
- LD20 SoC: "socionext,uniphier-ld20"
|
||||
- Reference Board: "socionext,uniphier-ld20-ref"
|
||||
- Global Board: "socionext,uniphier-ld20-global"
|
||||
|
||||
- PXs3 SoC: "socionext,uniphier-pxs3"
|
||||
- Reference Board: "socionext,uniphier-pxs3-ref"
|
||||
|
||||
Example:
|
||||
|
||||
/dts-v1/;
|
||||
|
||||
/ {
|
||||
compatible = "socionext,uniphier-ld20-ref", "socionext,uniphier-ld20";
|
||||
|
||||
...
|
||||
};
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
ST SPEAr Platforms Device Tree Bindings
|
||||
---------------------------------------
|
||||
|
||||
Boards with the ST SPEAr600 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,spear600";
|
||||
|
||||
Boards with the ST SPEAr300 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,spear300";
|
||||
|
||||
Boards with the ST SPEAr310 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,spear310";
|
||||
|
||||
Boards with the ST SPEAr320 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,spear320";
|
||||
|
||||
Boards with the ST SPEAr1310 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,spear1310";
|
||||
|
||||
Boards with the ST SPEAr1340 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,spear1340";
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/spear.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ST SPEAr Platforms Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Viresh Kumar <vireshk@kernel.org>
|
||||
- Stefan Roese <sr@denx.de>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: '/'
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- st,spear600
|
||||
- st,spear300
|
||||
- st,spear310
|
||||
- st,spear320
|
||||
- st,spear1310
|
||||
- st,spear1340
|
||||
...
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
ST STi Platforms Device Tree Bindings
|
||||
---------------------------------------
|
||||
|
||||
Boards with the ST STiH415 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,stih415";
|
||||
|
||||
Boards with the ST STiH416 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,stih416";
|
||||
|
||||
Boards with the ST STiH407 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,stih407";
|
||||
|
||||
Boards with the ST STiH410 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,stih410";
|
||||
|
||||
Boards with the ST STiH418 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,stih418";
|
||||
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/sti.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ST STi Platforms Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Patrice Chotard <patrice.chotard@st.com>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: '/'
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- st,stih415
|
||||
- st,stih416
|
||||
- st,stih407
|
||||
- st,stih410
|
||||
- st,stih418
|
||||
...
|
||||
|
|
@ -14,8 +14,10 @@ using one of the following compatible strings:
|
|||
allwinner,sun8i-a83t
|
||||
allwinner,sun8i-h2-plus
|
||||
allwinner,sun8i-h3
|
||||
allwinner-sun8i-r40
|
||||
allwinner,sun8i-r40
|
||||
allwinner,sun8i-t3
|
||||
allwinner,sun8i-v3s
|
||||
allwinner,sun9i-a80
|
||||
allwinner,sun50i-a64
|
||||
allwinner,suniv-f1c100s
|
||||
nextthing,gr8
|
||||
|
|
|
|||
|
|
@ -1,65 +0,0 @@
|
|||
NVIDIA Tegra device tree bindings
|
||||
-------------------------------------------
|
||||
|
||||
SoCs
|
||||
-------------------------------------------
|
||||
|
||||
Each device tree must specify which Tegra SoC it uses, using one of the
|
||||
following compatible values:
|
||||
|
||||
nvidia,tegra20
|
||||
nvidia,tegra30
|
||||
nvidia,tegra114
|
||||
nvidia,tegra124
|
||||
nvidia,tegra132
|
||||
nvidia,tegra210
|
||||
nvidia,tegra186
|
||||
nvidia,tegra194
|
||||
|
||||
Boards
|
||||
-------------------------------------------
|
||||
|
||||
Each device tree must specify which one or more of the following
|
||||
board-specific compatible values:
|
||||
|
||||
ad,medcom-wide
|
||||
ad,plutux
|
||||
ad,tamonten
|
||||
ad,tec
|
||||
compal,paz00
|
||||
compulab,trimslice
|
||||
nvidia,beaver
|
||||
nvidia,cardhu
|
||||
nvidia,cardhu-a02
|
||||
nvidia,cardhu-a04
|
||||
nvidia,dalmore
|
||||
nvidia,harmony
|
||||
nvidia,jetson-tk1
|
||||
nvidia,norrin
|
||||
nvidia,p2371-0000
|
||||
nvidia,p2371-2180
|
||||
nvidia,p2571
|
||||
nvidia,p2771-0000
|
||||
nvidia,p2972-0000
|
||||
nvidia,roth
|
||||
nvidia,seaboard
|
||||
nvidia,tn7
|
||||
nvidia,ventana
|
||||
toradex,apalis_t30
|
||||
toradex,apalis_t30-eval
|
||||
toradex,apalis_t30-v1.1
|
||||
toradex,apalis_t30-v1.1-eval
|
||||
toradex,apalis-tk1
|
||||
toradex,apalis-tk1-eval
|
||||
toradex,apalis-tk1-v1.2
|
||||
toradex,apalis-tk1-v1.2-eval
|
||||
toradex,colibri_t20
|
||||
toradex,colibri_t20-eval-v3
|
||||
toradex,colibri_t20-iris
|
||||
toradex,colibri_t30
|
||||
toradex,colibri_t30-eval-v3
|
||||
|
||||
Trusted Foundations
|
||||
-------------------------------------------
|
||||
Tegra supports the Trusted Foundation secure monitor. See the
|
||||
"tlm,trusted-foundations" binding's documentation for more details.
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/tegra.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: NVIDIA Tegra device tree bindings
|
||||
|
||||
maintainers:
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
- Jonathan Hunter <jonathanh@nvidia.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- compal,paz00
|
||||
- compulab,trimslice
|
||||
- nvidia,harmony
|
||||
- nvidia,seaboard
|
||||
- nvidia,ventana
|
||||
- const: nvidia,tegra20
|
||||
- items:
|
||||
- enum:
|
||||
- ad,medcom-wide
|
||||
- ad,plutux
|
||||
- ad,tec
|
||||
- const: ad,tamonten
|
||||
- const: nvidia,tegra20
|
||||
- items:
|
||||
- enum:
|
||||
- toradex,colibri_t20-eval-v3
|
||||
- toradex,colibri_t20-iris
|
||||
- const: toradex,colibri_t20
|
||||
- const: nvidia,tegra20
|
||||
- items:
|
||||
- enum:
|
||||
- nvidia,beaver
|
||||
- const: nvidia,tegra30
|
||||
- items:
|
||||
- enum:
|
||||
- nvidia,cardhu-a02
|
||||
- nvidia,cardhu-a04
|
||||
- const: nvidia,cardhu
|
||||
- const: nvidia,tegra30
|
||||
- items:
|
||||
- const: toradex,apalis_t30-eval
|
||||
- const: toradex,apalis_t30
|
||||
- const: nvidia,tegra30
|
||||
- items:
|
||||
- const: toradex,apalis_t30-eval-v1.1
|
||||
- const: toradex,apalis_t30-eval
|
||||
- const: toradex,apalis_t30-v1.1
|
||||
- const: toradex,apalis_t30
|
||||
- const: nvidia,tegra30
|
||||
- items:
|
||||
- enum:
|
||||
- toradex,colibri_t30-eval-v3
|
||||
- const: toradex,colibri_t30
|
||||
- const: nvidia,tegra30
|
||||
- items:
|
||||
- enum:
|
||||
- nvidia,dalmore
|
||||
- nvidia,roth
|
||||
- nvidia,tn7
|
||||
- const: nvidia,tegra114
|
||||
- items:
|
||||
- enum:
|
||||
- nvidia,jetson-tk1
|
||||
- nvidia,venice2
|
||||
- const: nvidia,tegra124
|
||||
- items:
|
||||
- const: toradex,apalis-tk1-eval
|
||||
- const: toradex,apalis-tk1
|
||||
- const: nvidia,tegra124
|
||||
- items:
|
||||
- const: toradex,apalis-tk1-v1.2-eval
|
||||
- const: toradex,apalis-tk1-eval
|
||||
- const: toradex,apalis-tk1-v1.2
|
||||
- const: toradex,apalis-tk1
|
||||
- const: nvidia,tegra124
|
||||
- items:
|
||||
- enum:
|
||||
- nvidia,norrin
|
||||
- const: nvidia,tegra132
|
||||
- const: nvidia,tegra124
|
||||
- items:
|
||||
- enum:
|
||||
- nvidia,p2371-0000
|
||||
- nvidia,p2371-2180
|
||||
- nvidia,p2571
|
||||
- const: nvidia,tegra210
|
||||
- items:
|
||||
- enum:
|
||||
- nvidia,p2771-0000
|
||||
- const: nvidia,tegra186
|
||||
- items:
|
||||
- enum:
|
||||
- nvidia,p2972-0000
|
||||
- const: nvidia,tegra194
|
||||
|
|
@ -15,6 +15,9 @@ Required properties:
|
|||
|
||||
Optional properties:
|
||||
- nvidia,invert-interrupt: If present, inverts the PMU interrupt signal.
|
||||
- interrupt-controller: Identifies the node as an interrupt controller.
|
||||
- #interrupt-cells: Specifies the number of cells needed to encode an
|
||||
interrupt source. The value must be 2.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,24 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/ti/nspire.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: TI-NSPIRE calculators
|
||||
|
||||
maintainers:
|
||||
- Daniel Tang <dt.tangr@gmail.com>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: '/'
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
# CX models
|
||||
- ti,nspire-cx
|
||||
# Touchpad models
|
||||
- ti,nspire-tp
|
||||
# Clickpad models
|
||||
- ti,nspire-clp
|
||||
...
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/ti/davinci.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Texas Instruments DaVinci Platforms Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Sekhar Nori <nsekhar@ti.com>
|
||||
|
||||
description:
|
||||
DA850/OMAP-L138/AM18x based boards
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: '/'
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- ti,da850-evm # DA850/OMAP-L138/AM18x Evaluation Module (EVM) board
|
||||
- ti,da850-lcdk # DA850/OMAP-L138/AM18x L138/C6748 Development Kit (LCDK) board
|
||||
- enbw,cmc # EnBW AM1808 based CMC board
|
||||
- lego,ev3 # LEGO MINDSTORMS EV3 (AM1808 based)
|
||||
- const: ti,da850
|
||||
...
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
VIA/Wondermedia VT8500 Platforms Device Tree Bindings
|
||||
---------------------------------------
|
||||
|
||||
Boards with the VIA VT8500 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "via,vt8500";
|
||||
|
||||
Boards with the Wondermedia WM8505 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "wm,wm8505";
|
||||
|
||||
Boards with the Wondermedia WM8650 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "wm,wm8650";
|
||||
|
||||
Boards with the Wondermedia WM8750 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "wm,wm8750";
|
||||
|
||||
Boards with the Wondermedia WM8850 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "wm,wm8850";
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/vt8500.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: VIA/Wondermedia VT8500 Platforms Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Tony Prisk <linux@prisktech.co.nz>
|
||||
description: test
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: '/'
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- via,vt8500
|
||||
- wm,wm8505
|
||||
- wm,wm8650
|
||||
- wm,wm8750
|
||||
- wm,wm8850
|
||||
|
|
@ -1,83 +0,0 @@
|
|||
Xilinx Zynq Platforms Device Tree Bindings
|
||||
|
||||
Boards with Zynq-7000 SOC based on an ARM Cortex A9 processor
|
||||
shall have the following properties.
|
||||
|
||||
Required root node properties:
|
||||
- compatible = "xlnx,zynq-7000";
|
||||
|
||||
Additional compatible strings:
|
||||
|
||||
- Adapteva Parallella board
|
||||
"adapteva,parallella"
|
||||
|
||||
- Avnet MicroZed board
|
||||
"avnet,zynq-microzed"
|
||||
"xlnx,zynq-microzed"
|
||||
|
||||
- Avnet ZedBoard board
|
||||
"avnet,zynq-zed"
|
||||
"xlnx,zynq-zed"
|
||||
|
||||
- Digilent Zybo board
|
||||
"digilent,zynq-zybo"
|
||||
|
||||
- Digilent Zybo Z7 board
|
||||
"digilent,zynq-zybo-z7"
|
||||
|
||||
- Xilinx CC108 internal board
|
||||
"xlnx,zynq-cc108"
|
||||
|
||||
- Xilinx ZC702 internal board
|
||||
"xlnx,zynq-zc702"
|
||||
|
||||
- Xilinx ZC706 internal board
|
||||
"xlnx,zynq-zc706"
|
||||
|
||||
- Xilinx ZC770 internal board, with different FMC cards
|
||||
"xlnx,zynq-zc770-xm010"
|
||||
"xlnx,zynq-zc770-xm011"
|
||||
"xlnx,zynq-zc770-xm012"
|
||||
"xlnx,zynq-zc770-xm013"
|
||||
|
||||
---------------------------------------------------------------
|
||||
|
||||
Xilinx Zynq UltraScale+ MPSoC Platforms Device Tree Bindings
|
||||
|
||||
Boards with ZynqMP SOC based on an ARM Cortex A53 processor
|
||||
shall have the following properties.
|
||||
|
||||
Required root node properties:
|
||||
- compatible = "xlnx,zynqmp";
|
||||
|
||||
|
||||
Additional compatible strings:
|
||||
|
||||
- Xilinx internal board zc1232
|
||||
"xlnx,zynqmp-zc1232-revA", "xlnx,zynqmp-zc1232"
|
||||
|
||||
- Xilinx internal board zc1254
|
||||
"xlnx,zynqmp-zc1254-revA", "xlnx,zynqmp-zc1254"
|
||||
|
||||
- Xilinx internal board zc1275
|
||||
"xlnx,zynqmp-zc1275-revA", "xlnx,zynqmp-zc1275"
|
||||
|
||||
- Xilinx internal board zc1751
|
||||
"xlnx,zynqmp-zc1751"
|
||||
|
||||
- Xilinx 96boards compatible board zcu100
|
||||
"xlnx,zynqmp-zcu100-revC", "xlnx,zynqmp-zcu100"
|
||||
|
||||
- Xilinx evaluation board zcu102
|
||||
"xlnx,zynqmp-zcu102-revA", "xlnx,zynqmp-zcu102"
|
||||
"xlnx,zynqmp-zcu102-revB", "xlnx,zynqmp-zcu102"
|
||||
"xlnx,zynqmp-zcu102-rev1.0", "xlnx,zynqmp-zcu102"
|
||||
|
||||
- Xilinx evaluation board zcu104
|
||||
"xlnx,zynqmp-zcu104-revA", "xlnx,zynqmp-zcu104"
|
||||
|
||||
- Xilinx evaluation board zcu106
|
||||
"xlnx,zynqmp-zcu106-revA", "xlnx,zynqmp-zcu106"
|
||||
|
||||
- Xilinx evaluation board zcu111
|
||||
"xlnx,zynqmp-zcu111-revA", "xlnx,zynqmp-zcu111"
|
||||
|
|
@ -0,0 +1,114 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/xilinx.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Xilinx Zynq Platforms Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Michal Simek <michal.simek@xilinx.com>
|
||||
|
||||
description: |
|
||||
Xilinx boards with Zynq-7000 SOC or Zynq UltraScale+ MPSoC
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: '/'
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- adapteva,parallella
|
||||
- digilent,zynq-zybo
|
||||
- digilent,zynq-zybo-z7
|
||||
- xlnx,zynq-cc108
|
||||
- xlnx,zynq-zc702
|
||||
- xlnx,zynq-zc706
|
||||
- xlnx,zynq-zc770-xm010
|
||||
- xlnx,zynq-zc770-xm011
|
||||
- xlnx,zynq-zc770-xm012
|
||||
- xlnx,zynq-zc770-xm013
|
||||
- const: xlnx,zynq-7000
|
||||
|
||||
- items:
|
||||
- const: avnet,zynq-microzed
|
||||
- const: xlnx,zynq-microzed
|
||||
- const: xlnx,zynq-7000
|
||||
|
||||
- items:
|
||||
- const: avnet,zynq-zed
|
||||
- const: xlnx,zynq-zed
|
||||
- const: xlnx,zynq-7000
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- xlnx,zynqmp-zc1751
|
||||
- const: xlnx,zynqmp
|
||||
|
||||
- description: Xilinx internal board zc1232
|
||||
items:
|
||||
- const: xlnx,zynqmp-zc1232-revA
|
||||
- const: xlnx,zynqmp-zc1232
|
||||
- const: xlnx,zynqmp
|
||||
|
||||
- description: Xilinx internal board zc1254
|
||||
items:
|
||||
- const: xlnx,zynqmp-zc1254-revA
|
||||
- const: xlnx,zynqmp-zc1254
|
||||
- const: xlnx,zynqmp
|
||||
|
||||
- description: Xilinx internal board zc1275
|
||||
items:
|
||||
- const: xlnx,zynqmp-zc1275-revA
|
||||
- const: xlnx,zynqmp-zc1275
|
||||
- const: xlnx,zynqmp
|
||||
|
||||
- description: Xilinx 96boards compatible board zcu100
|
||||
items:
|
||||
- const: xlnx,zynqmp-zcu100-revC
|
||||
- const: xlnx,zynqmp-zcu100
|
||||
- const: xlnx,zynqmp
|
||||
|
||||
- description: Xilinx 96boards compatible board Ultra96
|
||||
items:
|
||||
- const: avnet,ultra96-rev1
|
||||
- const: avnet,ultra96
|
||||
- const: xlnx,zynqmp-zcu100-revC
|
||||
- const: xlnx,zynqmp-zcu100
|
||||
- const: xlnx,zynqmp
|
||||
|
||||
- description: Xilinx evaluation board zcu102
|
||||
items:
|
||||
- enum:
|
||||
- xlnx,zynqmp-zcu102-revA
|
||||
- xlnx,zynqmp-zcu102-revB
|
||||
- xlnx,zynqmp-zcu102-rev1.0
|
||||
- const: xlnx,zynqmp-zcu102
|
||||
- const: xlnx,zynqmp
|
||||
|
||||
- description: Xilinx evaluation board zcu104
|
||||
items:
|
||||
- enum:
|
||||
- xlnx,zynqmp-zcu104-revA
|
||||
- xlnx,zynqmp-zcu104-rev1.0
|
||||
- const: xlnx,zynqmp-zcu104
|
||||
- const: xlnx,zynqmp
|
||||
|
||||
- description: Xilinx evaluation board zcu106
|
||||
items:
|
||||
- enum:
|
||||
- xlnx,zynqmp-zcu106-revA
|
||||
- xlnx,zynqmp-zcu106-rev1.0
|
||||
- const: xlnx,zynqmp-zcu106
|
||||
- const: xlnx,zynqmp
|
||||
|
||||
- description: Xilinx evaluation board zcu111
|
||||
items:
|
||||
- enum:
|
||||
- xlnx,zynqmp-zcu111-revA
|
||||
- xlnx,zynqmp-zcu11-rev1.0
|
||||
- const: xlnx,zynqmp-zcu111
|
||||
- const: xlnx,zynqmp
|
||||
|
||||
...
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
ZTE platforms device tree bindings
|
||||
|
||||
---------------------------------------
|
||||
- ZX296702 board:
|
||||
Required root node properties:
|
||||
- compatible = "zte,zx296702-ad1", "zte,zx296702"
|
||||
|
||||
---------------------------------------
|
||||
- ZX296718 SoC:
|
||||
Required root node properties:
|
||||
- compatible = "zte,zx296718"
|
||||
|
||||
ZX296718 EVB board:
|
||||
- "zte,zx296718-evb"
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/zte.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ZTE platforms device tree bindings
|
||||
|
||||
maintainers:
|
||||
- Jun Nie <jun.nie@linaro.org>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: '/'
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- zte,zx296702-ad1
|
||||
- const: zte,zx296702
|
||||
- items:
|
||||
- enum:
|
||||
- zte,zx296718-evb
|
||||
- const: zte,zx296718
|
||||
|
||||
...
|
||||
|
|
@ -35,6 +35,7 @@ Required standard properties:
|
|||
"ti,sysc-omap3-sham"
|
||||
"ti,sysc-omap-aes"
|
||||
"ti,sysc-mcasp"
|
||||
"ti,sysc-dra7-mcasp"
|
||||
"ti,sysc-usb-host-fs"
|
||||
"ti,sysc-dra7-mcan"
|
||||
|
||||
|
|
|
|||
|
|
@ -11,6 +11,13 @@ Required Properties:
|
|||
- GXM (S912) : "amlogic,meson-gxm-aoclkc"
|
||||
- AXG (A113D, A113X) : "amlogic,meson-axg-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:
|
||||
* "xtal" : the platform xtal
|
||||
* "mpeg-clk" : the main clock controller mother clock (aka clk81)
|
||||
* "ext-32k-0" : external 32kHz reference #0 if any (optional)
|
||||
* "ext-32k-1" : external 32kHz reference #1 if any (optional - gx only)
|
||||
* "ext-32k-2" : external 32kHz reference #2 if any (optional - gx only)
|
||||
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
|
|
@ -40,8 +47,9 @@ ao_sysctrl: sys-ctrl@0 {
|
|||
compatible = "amlogic,meson-gxbb-aoclkc", "amlogic,meson-gx-aoclkc";
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
clocks = <&xtal>, <&clkc CLKID_CLK81>;
|
||||
clock-names = "xtal", "mpeg-clk";
|
||||
};
|
||||
};
|
||||
|
||||
Example: UART controller node that consumes the clock and reset generated
|
||||
by the clock controller:
|
||||
|
|
|
|||
|
|
@ -9,6 +9,9 @@ Required Properties:
|
|||
"amlogic,gxbb-clkc" for GXBB SoC,
|
||||
"amlogic,gxl-clkc" for GXL and GXM SoC,
|
||||
"amlogic,axg-clkc" for AXG SoC.
|
||||
- clocks : list of clock phandle, one for each entry clock-names.
|
||||
- clock-names : should contain the following:
|
||||
* "xtal": the platform xtal
|
||||
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
|
|
@ -31,6 +34,8 @@ sysctrl: system-controller@0 {
|
|||
clkc: clock-controller {
|
||||
#clock-cells = <1>;
|
||||
compatible = "amlogic,gxbb-clkc";
|
||||
clocks = <&xtal>;
|
||||
clock-names = "xtal";
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -14,6 +14,8 @@ Optional properties:
|
|||
- label: symbolic name for the connector,
|
||||
- type: size of the connector, should be specified in case of USB-A, USB-B
|
||||
non-fullsize connectors: "mini", "micro".
|
||||
- self-powered: Set this property if the usb device that has its own power
|
||||
source.
|
||||
|
||||
Optional properties for usb-c-connector:
|
||||
- power-role: should be one of "source", "sink" or "dual"(DRP) if typec
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue