Kernel/linux-next
1
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git synced 2025-01-15 21:23:23 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch 'linus' into sched/urgent, to pick up the latest before merging new patches

Browse Source 
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar 2019-12-08 14:37:10 +01:00
commit 4f797f56c3
6108 changed files with 241771 additions and 121663 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.gitignore vendored
View File

@ -32,7 +32,6 @@
*.lzo
*.mod
*.mod.c
*.ns_deps
*.o
*.o.*
*.patch
@ -61,6 +60,7 @@ modules.order
/System.map
/Module.markers
/modules.builtin.modinfo
/modules.nsdeps
#
# RPM spec file (make rpm-pkg)

1
.mailmap
View File

@ -156,6 +156,7 @@ Mark Brown <broonie@sirena.org.uk>
Mark Yao <markyao0591@gmail.com> <mark.yao@rock-chips.com>
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@theobroma-systems.com>
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@ginzinger.com>
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@puri.sm>
Mathieu Othacehe <m.othacehe@gmail.com>
Matthew Wilcox <willy@infradead.org> <matthew.r.wilcox@intel.com>
Matthew Wilcox <willy@infradead.org> <matthew@wil.cx>

3
CREDITS
View File

@ -1875,8 +1875,9 @@ S: The Netherlands
N: Martin Kepplinger
E: martink@posteo.de
E: martin.kepplinger@ginzinger.com
E: martin.kepplinger@puri.sm
W: http://www.martinkepplinger.com
P: 4096R/5AB387D3 F208 2B88 0F9E 4239 3468 6E3F 5003 98DF 5AB3 87D3
D: mma8452 accelerators iio driver
D: pegasus_notetaker input driver
D: Kernel fixes and cleanups

19
Documentation/ABI/stable/sysfs-class-infiniband
View File

@ -314,25 +314,6 @@ Description:
board_id: (RO) Manufacturing board ID
sysfs interface for Chelsio T3 RDMA Driver (cxgb3)
--------------------------------------------------
What: /sys/class/infiniband/cxgb3_X/hw_rev
What: /sys/class/infiniband/cxgb3_X/hca_type
What: /sys/class/infiniband/cxgb3_X/board_id
Date: Feb, 2007
KernelVersion: v2.6.21
Contact: linux-rdma@vger.kernel.org
Description:
hw_rev: (RO) Hardware revision number
hca_type: (RO) HCA type. Here it is a driver short name.
It should normally match the name in its bus
driver structure (e.g. pci_driver::name).
board_id: (RO) Manufacturing board id
sysfs interface for Mellanox ConnectX HCA IB driver (mlx4)
----------------------------------------------------------

11
Documentation/ABI/stable/sysfs-driver-aspeed-vuart
View File

@ -6,10 +6,19 @@ Description: Configures which IO port the host side of the UART
Users: OpenBMC. Proposed changes should be mailed to
openbmc@lists.ozlabs.org
What: /sys/bus/platform/drivers/aspeed-vuart*/sirq
What: /sys/bus/platform/drivers/aspeed-vuart/*/sirq
Date: April 2017
Contact: Jeremy Kerr <jk@ozlabs.org>
Description: Configures which interrupt number the host side of
the UART will appear on the host <-> BMC LPC bus.
Users: OpenBMC. Proposed changes should be mailed to
openbmc@lists.ozlabs.org
What: /sys/bus/platform/drivers/aspeed-vuart/*/sirq_polarity
Date: July 2019
Contact: Oskar Senft <osk@google.com>
Description: Configures the polarity of the serial interrupt to the
host via the BMC LPC bus.
Set to 0 for active-low or 1 for active-high.
Users: OpenBMC. Proposed changes should be mailed to
openbmc@lists.ozlabs.org

2
Documentation/ABI/stable/sysfs-driver-ib_srp
View File

@ -67,6 +67,8 @@ Description: Interface for making ib_srp connect to a new target.
initiator is allowed to queue per SCSI host. The default
value for this parameter is 62. The lowest supported value
is 2.
* max_it_iu_size, a decimal number specifying the maximum
initiator to target information unit length.
What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/ibdev
Date: January 2, 2006

23
Documentation/ABI/testing/debugfs-hyperv Normal file
View File

@ -0,0 +1,23 @@
What: /sys/kernel/debug/hyperv/<UUID>/fuzz_test_state
Date: October 2019
KernelVersion: 5.5
Contact: Branden Bonaby <brandonbonaby94@gmail.com>
Description: Fuzz testing status of a vmbus device, whether its in an ON
state or a OFF state
Users: Debugging tools
What: /sys/kernel/debug/hyperv/<UUID>/delay/fuzz_test_buffer_interrupt_delay
Date: October 2019
KernelVersion: 5.5
Contact: Branden Bonaby <brandonbonaby94@gmail.com>
Description: Fuzz testing buffer interrupt delay value between 0 - 1000
microseconds (inclusive).
Users: Debugging tools
What: /sys/kernel/debug/hyperv/<UUID>/delay/fuzz_test_message_delay
Date: October 2019
KernelVersion: 5.5
Contact: Branden Bonaby <brandonbonaby94@gmail.com>
Description: Fuzz testing message delay value between 0 - 1000 microseconds
(inclusive).
Users: Debugging tools

4
Documentation/ABI/testing/ima_policy
View File

@ -25,6 +25,7 @@ Description:
lsm: [[subj_user=] [subj_role=] [subj_type=]
[obj_user=] [obj_role=] [obj_type=]]
option: [[appraise_type=]] [template=] [permit_directio]
[appraise_flag=]
base: func:= [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK][MODULE_CHECK]
[FIRMWARE_CHECK]
[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
@ -38,6 +39,9 @@ Description:
fowner:= decimal value
lsm: are LSM specific
option: appraise_type:= [imasig] [imasig|modsig]
appraise_flag:= [check_blacklist]
Currently, blacklist check is only for files signed with appended
signature.
template:= name of a defined IMA template type
(eg, ima-ng). Only valid when action is "measure".
pcr:= decimal value

183
Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
View File

@ -1,4 +1,4 @@
What: /sys/bus/coresight/devices/<memory_map>.etm/enable_source
What: /sys/bus/coresight/devices/etm<N>/enable_source
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
@ -8,82 +8,82 @@ Description: (RW) Enable/disable tracing on this specific trace entiry.
of coresight components linking the source to the sink is
configured and managed automatically by the coresight framework.
What: /sys/bus/coresight/devices/<memory_map>.etm/cpu
What: /sys/bus/coresight/devices/etm<N>/cpu
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) The CPU this tracing entity is associated with.
What: /sys/bus/coresight/devices/<memory_map>.etm/nr_pe_cmp
What: /sys/bus/coresight/devices/etm<N>/nr_pe_cmp
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of PE comparator inputs that are
available for tracing.
What: /sys/bus/coresight/devices/<memory_map>.etm/nr_addr_cmp
What: /sys/bus/coresight/devices/etm<N>/nr_addr_cmp
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of address comparator pairs that are
available for tracing.
What: /sys/bus/coresight/devices/<memory_map>.etm/nr_cntr
What: /sys/bus/coresight/devices/etm<N>/nr_cntr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of counters that are available for
tracing.
What: /sys/bus/coresight/devices/<memory_map>.etm/nr_ext_inp
What: /sys/bus/coresight/devices/etm<N>/nr_ext_inp
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates how many external inputs are implemented.
What: /sys/bus/coresight/devices/<memory_map>.etm/numcidc
What: /sys/bus/coresight/devices/etm<N>/numcidc
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of Context ID comparators that are
available for tracing.
What: /sys/bus/coresight/devices/<memory_map>.etm/numvmidc
What: /sys/bus/coresight/devices/etm<N>/numvmidc
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of VMID comparators that are available
for tracing.
What: /sys/bus/coresight/devices/<memory_map>.etm/nrseqstate
What: /sys/bus/coresight/devices/etm<N>/nrseqstate
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of sequencer states that are
implemented.
What: /sys/bus/coresight/devices/<memory_map>.etm/nr_resource
What: /sys/bus/coresight/devices/etm<N>/nr_resource
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of resource selection pairs that are
available for tracing.
What: /sys/bus/coresight/devices/<memory_map>.etm/nr_ss_cmp
What: /sys/bus/coresight/devices/etm<N>/nr_ss_cmp
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of single-shot comparator controls that
are available for tracing.
What: /sys/bus/coresight/devices/<memory_map>.etm/reset
What: /sys/bus/coresight/devices/etm<N>/reset
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (W) Cancels all configuration on a trace unit and set it back
to its boot configuration.
What: /sys/bus/coresight/devices/<memory_map>.etm/mode
What: /sys/bus/coresight/devices/etm<N>/mode
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
@ -91,302 +91,349 @@ Description: (RW) Controls various modes supported by this ETM, for example
P0 instruction tracing, branch broadcast, cycle counting and
context ID tracing.
What: /sys/bus/coresight/devices/<memory_map>.etm/pe
What: /sys/bus/coresight/devices/etm<N>/pe
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls which PE to trace.
What: /sys/bus/coresight/devices/<memory_map>.etm/event
What: /sys/bus/coresight/devices/etm<N>/event
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls the tracing of arbitrary events from bank 0 to 3.
What: /sys/bus/coresight/devices/<memory_map>.etm/event_instren
What: /sys/bus/coresight/devices/etm<N>/event_instren
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls the behavior of the events in bank 0 to 3.
What: /sys/bus/coresight/devices/<memory_map>.etm/event_ts
What: /sys/bus/coresight/devices/etm<N>/event_ts
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls the insertion of global timestamps in the trace
streams.
What: /sys/bus/coresight/devices/<memory_map>.etm/syncfreq
What: /sys/bus/coresight/devices/etm<N>/syncfreq
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls how often trace synchronization requests occur.
What: /sys/bus/coresight/devices/<memory_map>.etm/cyc_threshold
What: /sys/bus/coresight/devices/etm<N>/cyc_threshold
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Sets the threshold value for cycle counting.
What: /sys/bus/coresight/devices/<memory_map>.etm/bb_ctrl
What: /sys/bus/coresight/devices/etm<N>/bb_ctrl
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls which regions in the memory map are enabled to
use branch broadcasting.
What: /sys/bus/coresight/devices/<memory_map>.etm/event_vinst
What: /sys/bus/coresight/devices/etm<N>/event_vinst
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls instruction trace filtering.
What: /sys/bus/coresight/devices/<memory_map>.etm/s_exlevel_vinst
What: /sys/bus/coresight/devices/etm<N>/s_exlevel_vinst
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) In Secure state, each bit controls whether instruction
tracing is enabled for the corresponding exception level.
What: /sys/bus/coresight/devices/<memory_map>.etm/ns_exlevel_vinst
What: /sys/bus/coresight/devices/etm<N>/ns_exlevel_vinst
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) In non-secure state, each bit controls whether instruction
tracing is enabled for the corresponding exception level.
What: /sys/bus/coresight/devices/<memory_map>.etm/addr_idx
What: /sys/bus/coresight/devices/etm<N>/addr_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which address comparator or pair (of comparators) to
work with.
What: /sys/bus/coresight/devices/<memory_map>.etm/addr_instdatatype
What: /sys/bus/coresight/devices/etm<N>/addr_instdatatype
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls what type of comparison the trace unit performs.
What: /sys/bus/coresight/devices/<memory_map>.etm/addr_single
What: /sys/bus/coresight/devices/etm<N>/addr_single
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used to setup single address comparator values.
What: /sys/bus/coresight/devices/<memory_map>.etm/addr_range
What: /sys/bus/coresight/devices/etm<N>/addr_range
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used to setup address range comparator values.
What: /sys/bus/coresight/devices/<memory_map>.etm/seq_idx
What: /sys/bus/coresight/devices/etm<N>/seq_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which sequensor.
What: /sys/bus/coresight/devices/<memory_map>.etm/seq_state
What: /sys/bus/coresight/devices/etm<N>/seq_state
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Use this to set, or read, the sequencer state.
What: /sys/bus/coresight/devices/<memory_map>.etm/seq_event
What: /sys/bus/coresight/devices/etm<N>/seq_event
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Moves the sequencer state to a specific state.
What: /sys/bus/coresight/devices/<memory_map>.etm/seq_reset_event
What: /sys/bus/coresight/devices/etm<N>/seq_reset_event
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Moves the sequencer to state 0 when a programmed event
occurs.
What: /sys/bus/coresight/devices/<memory_map>.etm/cntr_idx
What: /sys/bus/coresight/devices/etm<N>/cntr_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which counter unit to work with.
What: /sys/bus/coresight/devices/<memory_map>.etm/cntrldvr
What: /sys/bus/coresight/devices/etm<N>/cntrldvr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) This sets or returns the reload count value of the
specific counter.
What: /sys/bus/coresight/devices/<memory_map>.etm/cntr_val
What: /sys/bus/coresight/devices/etm<N>/cntr_val
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) This sets or returns the current count value of the
specific counter.
What: /sys/bus/coresight/devices/<memory_map>.etm/cntr_ctrl
What: /sys/bus/coresight/devices/etm<N>/cntr_ctrl
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls the operation of the selected counter.
What: /sys/bus/coresight/devices/<memory_map>.etm/res_idx
What: /sys/bus/coresight/devices/etm<N>/res_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which resource selection unit to work with.
What: /sys/bus/coresight/devices/<memory_map>.etm/res_ctrl
What: /sys/bus/coresight/devices/etm<N>/res_ctrl
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls the selection of the resources in the trace unit.
What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_idx
What: /sys/bus/coresight/devices/etm<N>/ctxid_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which context ID comparator to work with.
What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_pid
What: /sys/bus/coresight/devices/etm<N>/ctxid_pid
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Get/Set the context ID comparator value to trigger on.
What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_masks
What: /sys/bus/coresight/devices/etm<N>/ctxid_masks
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Mask for all 8 context ID comparator value
registers (if implemented).
What: /sys/bus/coresight/devices/<memory_map>.etm/vmid_idx
What: /sys/bus/coresight/devices/etm<N>/vmid_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which virtual machine ID comparator to work with.
What: /sys/bus/coresight/devices/<memory_map>.etm/vmid_val
What: /sys/bus/coresight/devices/etm<N>/vmid_val
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Get/Set the virtual machine ID comparator value to
trigger on.
What: /sys/bus/coresight/devices/<memory_map>.etm/vmid_masks
What: /sys/bus/coresight/devices/etm<N>/vmid_masks
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Mask for all 8 virtual machine ID comparator value
registers (if implemented).
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcoslsr
What: /sys/bus/coresight/devices/etm<N>/addr_exlevel_s_ns
Date: December 2019
KernelVersion: 5.5
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Set the Exception Level matching bits for secure and
non-secure exception levels.
What: /sys/bus/coresight/devices/etm<N>/vinst_pe_cmp_start_stop
Date: December 2019
KernelVersion: 5.5
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Access the start stop control register for PE input
comparators.
What: /sys/bus/coresight/devices/etm<N>/addr_cmp_view
Date: December 2019
KernelVersion: 5.5
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the current settings for the selected address
comparator.
What: /sys/bus/coresight/devices/etm<N>/sshot_idx
Date: December 2019
KernelVersion: 5.5
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select the single shot control register to access.
What: /sys/bus/coresight/devices/etm<N>/sshot_ctrl
Date: December 2019
KernelVersion: 5.5
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Access the selected single shot control register.
What: /sys/bus/coresight/devices/etm<N>/sshot_status
Date: December 2019
KernelVersion: 5.5
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the current value of the selected single shot
status register.
What: /sys/bus/coresight/devices/etm<N>/sshot_pe_ctrl
Date: December 2019
KernelVersion: 5.5
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Access the selected single show PE comparator control
register.
What: /sys/bus/coresight/devices/etm<N>/mgmt/trcoslsr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the OS Lock Status Register (0x304).
The value it taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpdcr
What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpdcr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Power Down Control Register
(0x310). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpdsr
What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpdsr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Power Down Status Register
(0x314). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trclsr
What: /sys/bus/coresight/devices/etm<N>/mgmt/trclsr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the SW Lock Status Register
(0xFB4). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcauthstatus
What: /sys/bus/coresight/devices/etm<N>/mgmt/trcauthstatus
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Authentication Status Register
(0xFB8). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcdevid
What: /sys/bus/coresight/devices/etm<N>/mgmt/trcdevid
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Device ID Register
(0xFC8). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcdevtype
What: /sys/bus/coresight/devices/etm<N>/mgmt/trcdevtype
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Device Type Register
(0xFCC). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr0
What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpidr0
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Peripheral ID0 Register
(0xFE0). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr1
What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpidr1
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Peripheral ID1 Register
(0xFE4). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr2
What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpidr2
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Peripheral ID2 Register
(0xFE8). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr3
What: /sys/bus/coresight/devices/etm<N>/mgmt/trcpidr3
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Peripheral ID3 Register
(0xFEC). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcconfig
What: /sys/bus/coresight/devices/etm<N>/mgmt/trcconfig
Date: February 2016
KernelVersion: 4.07
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the trace configuration register
(0x010) as currently set by SW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trctraceid
What: /sys/bus/coresight/devices/etm<N>/mgmt/trctraceid
Date: February 2016
KernelVersion: 4.07
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the trace ID register (0x040).
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr0
What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr0
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the tracing capabilities of the trace unit (0x1E0).
The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr1
What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr1
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the tracing capabilities of the trace unit (0x1E4).
The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr2
What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr2
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
@ -394,7 +441,7 @@ Description: (R) Returns the maximum size of the data value, data address,
VMID, context ID and instuction address in the trace unit
(0x1E8). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr3
What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr3
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
@ -403,42 +450,42 @@ Description: (R) Returns the value associated with various resources
architecture specification for more details (0x1E8).
The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr4
What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr4
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns how many resources the trace unit supports (0x1F0).
The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr5
What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr5
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns how many resources the trace unit supports (0x1F4).
The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr8
What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr8
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the maximum speculation depth of the instruction
trace stream. (0x180). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr9
What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr9
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the number of P0 right-hand keys that the trace unit
can use (0x184). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr10
What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr10
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the number of P1 right-hand keys that the trace unit
can use (0x188). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr11
What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr11
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
@ -446,7 +493,7 @@ Description: (R) Returns the number of special P1 right-hand keys that the
trace unit can use (0x18C). The value is taken directly from
the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr12
What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr12
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
@ -454,7 +501,7 @@ Description: (R) Returns the number of conditional P1 right-hand keys that
the trace unit can use (0x190). The value is taken directly
from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr13
What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr13
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>

16
Documentation/ABI/testing/sysfs-bus-fsi
View File

@ -1,25 +1,25 @@
What: /sys/bus/platform/devices/fsi-master/rescan
What: /sys/bus/platform/devices/../fsi-master/fsi0/rescan
Date: May 2017
KernelVersion: 4.12
Contact: cbostic@linux.vnet.ibm.com
Contact: linux-fsi@lists.ozlabs.org
Description:
Initiates a FSI master scan for all connected slave devices
on its links.
What: /sys/bus/platform/devices/fsi-master/break
What: /sys/bus/platform/devices/../fsi-master/fsi0/break
Date: May 2017
KernelVersion: 4.12
Contact: cbostic@linux.vnet.ibm.com
Contact: linux-fsi@lists.ozlabs.org
Description:
Sends an FSI BREAK command on a master's communication
link to any connnected slaves. A BREAK resets connected
device's logic and preps it to receive further commands
from the master.
What: /sys/bus/platform/devices/fsi-master/slave@00:00/term
What: /sys/bus/platform/devices/../fsi-master/fsi0/slave@00:00/term
Date: May 2017
KernelVersion: 4.12
Contact: cbostic@linux.vnet.ibm.com
Contact: linux-fsi@lists.ozlabs.org
Description:
Sends an FSI terminate command from the master to its
connected slave. A terminate resets the slave's state machines
@ -29,10 +29,10 @@ Description:
ongoing operation in case of an expired 'Master Time Out'
timer.
What: /sys/bus/platform/devices/fsi-master/slave@00:00/raw
What: /sys/bus/platform/devices/../fsi-master/fsi0/slave@00:00/raw
Date: May 2017
KernelVersion: 4.12
Contact: cbostic@linux.vnet.ibm.com
Contact: linux-fsi@lists.ozlabs.org
Description:
Provides a means of reading/writing a 32 bit value from/to a
specified FSI bus address.

11
Documentation/ABI/testing/sysfs-bus-iio
View File

@ -753,6 +753,8 @@ What: /sys/.../events/in_illuminance0_thresh_falling_value
what: /sys/.../events/in_illuminance0_thresh_rising_value
what: /sys/.../events/in_proximity0_thresh_falling_value
what: /sys/.../events/in_proximity0_thresh_rising_value
What: /sys/.../events/in_illuminance_thresh_rising_value
What: /sys/.../events/in_illuminance_thresh_falling_value
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
@ -972,6 +974,7 @@ What: /sys/.../events/in_activity_jogging_thresh_rising_period
What: /sys/.../events/in_activity_jogging_thresh_falling_period
What: /sys/.../events/in_activity_running_thresh_rising_period
What: /sys/.../events/in_activity_running_thresh_falling_period
What: /sys/.../events/in_illuminance_thresh_either_period
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
@ -1715,3 +1718,11 @@ Description:
Mass concentration reading of particulate matter in ug / m3.
pmX consists of particles with aerodynamic diameter less or
equal to X micrometers.
What: /sys/bus/iio/devices/iio:deviceX/events/in_illuminance_period_available
Date: November 2019
KernelVersion: 5.4
Contact: linux-iio@vger.kernel.org
Description:
List of valid periods (in seconds) for which the light intensity
must be above the threshold level before interrupt is asserted.

39
Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192 Normal file
View File

@ -0,0 +1,39 @@
What: /sys/bus/iio/devices/iio:deviceX/ac_excitation_en
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Reading gives the state of AC excitation.
Writing '1' enables AC excitation.
What: /sys/bus/iio/devices/iio:deviceX/bridge_switch_en
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
This bridge switch is used to disconnect it when there is a
need to minimize the system current consumption.
Reading gives the state of the bridge switch.
Writing '1' enables the bridge switch.
What: /sys/bus/iio/devices/iio:deviceX/in_voltagex_sys_calibration
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Initiates the system calibration procedure. This is done on a
single channel at a time. Write '1' to start the calibration.
What: /sys/bus/iio/devices/iio:deviceX/in_voltagex_sys_calibration_mode_available
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Reading returns a list with the possible calibration modes.
There are two available options:
"zero_scale" - calibrate to zero scale
"full_scale" - calibrate to full scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltagex_sys_calibration_mode
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Sets up the calibration mode used in the system calibration
procedure. Reading returns the current calibration mode.
Writing sets the system calibration mode.

23
Documentation/ABI/testing/sysfs-bus-mei
View File

@ -4,7 +4,7 @@ KernelVersion: 3.10
Contact: Samuel Ortiz <sameo@linux.intel.com>
linux-mei@linux.intel.com
Description: Stores the same MODALIAS value emitted by uevent
Format: mei:<mei device name>:<device uuid>:
Format: mei:<mei device name>:<device uuid>:<protocol version>
What: /sys/bus/mei/devices/.../name
Date: May 2015
@ -26,3 +26,24 @@ KernelVersion: 4.3
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description: Stores mei client protocol version
Format: %d
What: /sys/bus/mei/devices/.../max_conn
Date: Nov 2019
KernelVersion: 5.5
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description: Stores mei client maximum number of connections
Format: %d
What: /sys/bus/mei/devices/.../fixed
Date: Nov 2019
KernelVersion: 5.5
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description: Stores mei client fixed address, if any
Format: %d
What: /sys/bus/mei/devices/.../max_len
Date: Nov 2019
KernelVersion: 5.5
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description: Stores mei client maximum message length
Format: %d

13
Documentation/ABI/testing/sysfs-bus-pci
View File

@ -347,3 +347,16 @@ Description:
If the device has any Peer-to-Peer memory registered, this
file contains a '1' if the memory has been published for
use outside the driver that owns the device.
What: /sys/bus/pci/devices/.../link/clkpm
/sys/bus/pci/devices/.../link/l0s_aspm
/sys/bus/pci/devices/.../link/l1_aspm
/sys/bus/pci/devices/.../link/l1_1_aspm
/sys/bus/pci/devices/.../link/l1_2_aspm
/sys/bus/pci/devices/.../link/l1_1_pcipm
/sys/bus/pci/devices/.../link/l1_2_pcipm
Date: October 2019
Contact: Heiner Kallweit <hkallweit1@gmail.com>
Description: If ASPM is supported for an endpoint, these files can be
used to disable or enable the individual power management
states. Write y/1/on to enable, n/0/off to disable.

36
Documentation/ABI/testing/sysfs-bus-thunderbolt
View File

@ -80,6 +80,14 @@ Contact: thunderbolt-software@lists.01.org
Description: This attribute contains 1 if Thunderbolt device was already
authorized on boot and 0 otherwise.
What: /sys/bus/thunderbolt/devices/.../generation
Date: Jan 2020
KernelVersion: 5.5
Contact: Christian Kellner <christian@kellner.me>
Description: This attribute contains the generation of the Thunderbolt
controller associated with the device. It will contain 4
for USB4.
What: /sys/bus/thunderbolt/devices/.../key
Date: Sep 2017
KernelVersion: 4.13
@ -104,6 +112,34 @@ Contact: thunderbolt-software@lists.01.org
Description: This attribute contains name of this device extracted from
the device DROM.
What: /sys/bus/thunderbolt/devices/.../rx_speed
Date: Jan 2020
KernelVersion: 5.5
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute reports the device RX speed per lane.
All RX lanes run at the same speed.
What: /sys/bus/thunderbolt/devices/.../rx_lanes
Date: Jan 2020
KernelVersion: 5.5
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute reports number of RX lanes the device is
using simultaneusly through its upstream port.
What: /sys/bus/thunderbolt/devices/.../tx_speed
Date: Jan 2020
KernelVersion: 5.5
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute reports the TX speed per lane.
All TX lanes run at the same speed.
What: /sys/bus/thunderbolt/devices/.../tx_lanes
Date: Jan 2020
KernelVersion: 5.5
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: This attribute reports number of TX lanes the device is
using simultaneusly through its upstream port.
What: /sys/bus/thunderbolt/devices/.../vendor
Date: Sep 2017
KernelVersion: 4.13

139
Documentation/ABI/testing/sysfs-class-led-driver-el15203000 Normal file
View File

@ -0,0 +1,139 @@
What: /sys/class/leds/<led>/hw_pattern
Date: September 2019
KernelVersion: 5.5
Description:
Specify a hardware pattern for the EL15203000 LED.
The LEDs board supports only predefined patterns by firmware
for specific LEDs.
Breathing mode for Screen frame light tube:
"0 4000 1 4000"
^
|
Max-| ---
| / \
| / \
| / \ /
| / \ /
Min-|- ---
|
0------4------8--> time (sec)
Cascade mode for Pipe LED:
"1 800 2 800 4 800 8 800 16 800"
^
|
0 On -|----+ +----+ +---
| | | | |
Off-| +-------------------+ +-------------------+
|
1 On -| +----+ +----+
| | | | |
Off |----+ +-------------------+ +------------------
|
2 On -| +----+ +----+
| | | | |
Off-|---------+ +-------------------+ +-------------
|
3 On -| +----+ +----+
| | | | |
Off-|--------------+ +-------------------+ +--------
|
4 On -| +----+ +----+
| | | | |
Off-|-------------------+ +-------------------+ +---
|
0---0.8--1.6--2.4--3.2---4---4.8--5.6--6.4--7.2---8--> time (sec)
Inverted cascade mode for Pipe LED:
"30 800 29 800 27 800 23 800 15 800"
^
|
0 On -| +-------------------+ +-------------------+
| | | | |
Off-|----+ +----+ +---
|
1 On -|----+ +-------------------+ +------------------
| | | | |
Off | +----+ +----+
|
2 On -|---------+ +-------------------+ +-------------
| | | | |
Off-| +----+ +----+
|
3 On -|--------------+ +-------------------+ +--------
| | | | |
Off-| +----+ +----+
|
4 On -|-------------------+ +-------------------+ +---
| | | | |
Off-| +----+ +----+
|
0---0.8--1.6--2.4--3.2---4---4.8--5.6--6.4--7.2---8--> time (sec)
Bounce mode for Pipe LED:
"1 800 2 800 4 800 8 800 16 800 16 800 8 800 4 800 2 800 1 800"
^
|
0 On -|----+ +--------
| | |
Off-| +---------------------------------------+
|
1 On -| +----+ +----+
| | | | |
Off |----+ +-----------------------------+ +--------
|
2 On -| +----+ +----+
| | | | |
Off-|---------+ +-------------------+ +-------------
|
3 On -| +----+ +----+
| | | | |
Off-|--------------+ +---------+ +------------------
|
4 On -| +---------+
| | |
Off-|-------------------+ +-----------------------
|
0---0.8--1.6--2.4--3.2---4---4.8--5.6--6.4--7.2---8--> time (sec)
Inverted bounce mode for Pipe LED:
"30 800 29 800 27 800 23 800 15 800 15 800 23 800 27 800 29 800 30 800"
^
|
0 On -| +---------------------------------------+
| | |
Off-|----+ +--------
|
1 On -|----+ +-----------------------------+ +--------
| | | | |
Off | +----+ +----+
|
2 On -|---------+ +-------------------+ +-------------
| | | | |
Off-| +----+ +----+
|
3 On -|--------------+ +---------+ +------------------
| | | | |
Off-| +----+ +----+
|
4 On -|-------------------+ +-----------------------
| | |
Off-| +---------+
|
0---0.8--1.6--2.4--3.2---4---4.8--5.6--6.4--7.2---8--> time (sec)
What: /sys/class/leds/<led>/repeat
Date: September 2019
KernelVersion: 5.5
Description:
EL15203000 supports only indefinitely patterns,
so this file should always store -1.
For more info, please see:
Documentation/ABI/testing/sysfs-class-led-trigger-pattern

10
Documentation/ABI/testing/sysfs-class-mei
View File

@ -80,3 +80,13 @@ Description: Display the ME device state.
DISABLED
POWER_DOWN
POWER_UP
What: /sys/class/mei/meiN/trc
Date: Nov 2019
KernelVersion: 5.5
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description: Display trc status register content
The ME FW writes Glitch Detection HW (TRC)
status information into trc status register
for BIOS and OS to monitor fw health.

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

@ -17,8 +17,13 @@ What: /sys/class/watchdog/watchdogn/nowayout
Date: August 2015
Contact: Wim Van Sebroeck <wim@iguana.be>
Description:
It is a read only file. While reading, it gives '1' if that
device supports nowayout feature else, it gives '0'.
It is a read/write file. While reading, it gives '1'
if the device has the nowayout feature set, otherwise
it gives '0'. Writing a '1' to the file enables the
nowayout feature. Once set, the nowayout feature
cannot be disabled, so writing a '0' either has no
effect (if the feature was already disabled) or
results in a permission error.
What: /sys/class/watchdog/watchdogn/state
Date: August 2015

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

@ -31,6 +31,12 @@ Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:
Controls the issue rate of segment discard commands.
What: /sys/fs/f2fs/<disk>/max_blkaddr
Date: November 2019
Contact: "Ramon Pantin" <pantin@google.com>
Description:
Shows first block address of MAIN area.
What: /sys/fs/f2fs/<disk>/ipu_policy
Date: November 2013
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>

132
Documentation/ABI/testing/sysfs-platform-dfl-fme
View File

@ -106,3 +106,135 @@ KernelVersion: 5.4
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. Read this file to get the second error detected by
hardware.
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/name
Date: October 2019
KernelVersion: 5.5
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Only. Read this file to get the name of hwmon device, it
supports values:
'dfl_fme_thermal' - thermal hwmon device name
'dfl_fme_power' - power hwmon device name
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_input
Date: October 2019
KernelVersion: 5.5
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Only. It returns FPGA device temperature in millidegrees
Celsius.
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_max
Date: October 2019
KernelVersion: 5.5
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Only. It returns hardware threshold1 temperature in
millidegrees Celsius. If temperature rises at or above this
threshold, hardware starts 50% or 90% throttling (see
'temp1_max_policy').
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_crit
Date: October 2019
KernelVersion: 5.5
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Only. It returns hardware threshold2 temperature in
millidegrees Celsius. If temperature rises at or above this
threshold, hardware starts 100% throttling.
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_emergency
Date: October 2019
KernelVersion: 5.5
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Only. It returns hardware trip threshold temperature in
millidegrees Celsius. If temperature rises at or above this
threshold, a fatal event will be triggered to board management
controller (BMC) to shutdown FPGA.
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_max_alarm
Date: October 2019
KernelVersion: 5.5
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. It returns 1 if temperature is currently at or above
hardware threshold1 (see 'temp1_max'), otherwise 0.
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_crit_alarm
Date: October 2019
KernelVersion: 5.5
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. It returns 1 if temperature is currently at or above
hardware threshold2 (see 'temp1_crit'), otherwise 0.
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_max_policy
Date: October 2019
KernelVersion: 5.5
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Only. Read this file to get the policy of hardware threshold1
(see 'temp1_max'). It only supports two values (policies):
0 - AP2 state (90% throttling)
1 - AP1 state (50% throttling)
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_input
Date: October 2019
KernelVersion: 5.5
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Only. It returns current FPGA power consumption in uW.
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_max
Date: October 2019
KernelVersion: 5.5
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Write. Read this file to get current hardware power
threshold1 in uW. If power consumption rises at or above
this threshold, hardware starts 50% throttling.
Write this file to set current hardware power threshold1 in uW.
As hardware only accepts values in Watts, so input value will
be round down per Watts (< 1 watts part will be discarded) and
clamped within the range from 0 to 127 Watts. Write fails with
-EINVAL if input parsing fails.
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_crit
Date: October 2019
KernelVersion: 5.5
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Write. Read this file to get current hardware power
threshold2 in uW. If power consumption rises at or above
this threshold, hardware starts 90% throttling.
Write this file to set current hardware power threshold2 in uW.
As hardware only accepts values in Watts, so input value will
be round down per Watts (< 1 watts part will be discarded) and
clamped within the range from 0 to 127 Watts. Write fails with
-EINVAL if input parsing fails.
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_max_alarm
Date: October 2019
KernelVersion: 5.5
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. It returns 1 if power consumption is currently at or
above hardware threshold1 (see 'power1_max'), otherwise 0.
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_crit_alarm
Date: October 2019
KernelVersion: 5.5
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. It returns 1 if power consumption is currently at or
above hardware threshold2 (see 'power1_crit'), otherwise 0.
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_xeon_limit
Date: October 2019
KernelVersion: 5.5
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Only. It returns power limit for XEON in uW.
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_fpga_limit
Date: October 2019
KernelVersion: 5.5
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Only. It returns power limit for FPGA in uW.
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_ltr
Date: October 2019
KernelVersion: 5.5
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. Read this file to get current Latency Tolerance
Reporting (ltr) value. It returns 1 if all Accelerated
Function Units (AFUs) can tolerate latency >= 40us for memory
access or 0 if any AFU is latency sensitive (< 40us).

58
Documentation/ABI/testing/sysfs-platform-mellanox-bootctl Normal file
View File

@ -0,0 +1,58 @@
What: /sys/bus/platform/devices/MLNXBF04:00/driver/lifecycle_state
Date: Oct 2019
KernelVersion: 5.5
Contact: "Liming Sun <lsun@mellanox.com>"
Description:
The Life-cycle state of the SoC, which could be one of the
following values.
Production - Production state and can be updated to secure
GA Secured - Secure chip and not able to change state
GA Non-Secured - Non-Secure chip and not able to change state
RMA - Return Merchandise Authorization
What: /sys/bus/platform/devices/MLNXBF04:00/driver/post_reset_wdog
Date: Oct 2019
KernelVersion: 5.5
Contact: "Liming Sun <lsun@mellanox.com>"
Description:
The watchdog setting in seconds for the next booting. It's used
to reboot the chip and recover it to the old state if the new
boot partition fails.
What: /sys/bus/platform/devices/MLNXBF04:00/driver/reset_action
Date: Oct 2019
KernelVersion: 5.5
Contact: "Liming Sun <lsun@mellanox.com>"
Description:
The source of the boot stream for the next reset. It could be
one of the following values.
external - boot from external source (USB or PCIe)
emmc - boot from the onchip eMMC
emmc_legacy - boot from the onchip eMMC in legacy (slow) mode
What: /sys/bus/platform/devices/MLNXBF04:00/driver/second_reset_action
Date: Oct 2019
KernelVersion: 5.5
Contact: "Liming Sun <lsun@mellanox.com>"
Description:
Update the source of the boot stream after next reset. It could
be one of the following values and will be applied after next
reset.
external - boot from external source (USB or PCIe)
emmc - boot from the onchip eMMC
emmc_legacy - boot from the onchip eMMC in legacy (slow) mode
swap_emmc - swap the primary / secondary boot partition
none - cancel the action
What: /sys/bus/platform/devices/MLNXBF04:00/driver/secure_boot_fuse_state
Date: Oct 2019
KernelVersion: 5.5
Contact: "Liming Sun <lsun@mellanox.com>"
Description:
The state of eFuse versions with the following values.
InUse - burnt, valid and currently in use
Used - burnt and valid
Free - not burnt and free to use
Skipped - not burnt but not free (skipped)
Wasted - burnt and invalid
Invalid - not burnt but marked as valid (error state).

17
Documentation/ABI/testing/sysfs-platform-wilco-ec
View File

@ -31,6 +31,23 @@ Description:
Output will a version string be similar to the example below:
08B6
What: /sys/bus/platform/devices/GOOG000C\:00/usb_charge
Date: October 2019
KernelVersion: 5.5
Description:
Control the USB PowerShare Policy. USB PowerShare is a policy
which affects charging via the special USB PowerShare port
(marked with a small lightning bolt or battery icon) when in
low power states:
- In S0, the port will always provide power.
- In S0ix, if usb_charge is enabled, then power will be
supplied to the port when on AC or if battery is > 50%.
Else no power is supplied.
- In S5, if usb_charge is enabled, then power will be supplied
to the port when on AC. Else no power is supplied.
Input should be either "0" or "1".
What: /sys/bus/platform/devices/GOOG000C\:00/version
Date: May 2019
KernelVersion: 5.3

46
Documentation/ABI/testing/sysfs-secvar Normal file
View File

@ -0,0 +1,46 @@
What: /sys/firmware/secvar
Date: August 2019
Contact: Nayna Jain <nayna@linux.ibm.com>
Description: This directory is created if the POWER firmware supports OS
secureboot, thereby secure variables. It exposes interface
for reading/writing the secure variables
What: /sys/firmware/secvar/vars
Date: August 2019
Contact: Nayna Jain <nayna@linux.ibm.com>
Description: This directory lists all the secure variables that are supported
by the firmware.
What: /sys/firmware/secvar/format
Date: August 2019
Contact: Nayna Jain <nayna@linux.ibm.com>
Description: A string indicating which backend is in use by the firmware.
This determines the format of the variable and the accepted
format of variable updates.
What: /sys/firmware/secvar/vars/<variable name>
Date: August 2019
Contact: Nayna Jain <nayna@linux.ibm.com>
Description: Each secure variable is represented as a directory named as
<variable_name>. The variable name is unique and is in ASCII
representation. The data and size can be determined by reading
their respective attribute files.
What: /sys/firmware/secvar/vars/<variable_name>/size
Date: August 2019
Contact: Nayna Jain <nayna@linux.ibm.com>
Description: An integer representation of the size of the content of the
variable. In other words, it represents the size of the data.
What: /sys/firmware/secvar/vars/<variable_name>/data
Date: August 2019
Contact: Nayna Jain h<nayna@linux.ibm.com>
Description: A read-only file containing the value of the variable. The size
of the file represents the maximum size of the variable data.
What: /sys/firmware/secvar/vars/<variable_name>/update
Date: August 2019
Contact: Nayna Jain <nayna@linux.ibm.com>
Description: A write-only file that is used to submit the new value for the
variable. The size of the file represents the maximum size of
the variable data that can be written.

18
Documentation/DMA-attributes.txt
View File

@ -5,24 +5,6 @@ DMA attributes
This document describes the semantics of the DMA attributes that are
defined in linux/dma-mapping.h.
DMA_ATTR_WRITE_BARRIER
----------------------
DMA_ATTR_WRITE_BARRIER is a (write) barrier attribute for DMA. DMA
to a memory region with the DMA_ATTR_WRITE_BARRIER attribute forces
all pending DMA writes to complete, and thus provides a mechanism to
strictly order DMA from a device across all intervening busses and
bridges. This barrier is not specific to a particular type of
interconnect, it applies to the system as a whole, and so its
implementation must account for the idiosyncrasies of the system all
the way from the DMA device to memory.
As an example of a situation where DMA_ATTR_WRITE_BARRIER would be
useful, suppose that a device does a DMA write to indicate that data is
ready and available in memory. The DMA of the "completion indication"
could race with data DMA. Mapping the memory used for completion
indications with DMA_ATTR_WRITE_BARRIER would prevent the race.
DMA_ATTR_WEAK_ORDERING
----------------------

12
Documentation/Makefile
View File

@ -13,7 +13,7 @@ endif
SPHINXBUILD = sphinx-build
SPHINXOPTS =
SPHINXDIRS = .
_SPHINXDIRS = $(patsubst $(srctree)/Documentation/%/conf.py,%,$(wildcard $(srctree)/Documentation/*/conf.py))
_SPHINXDIRS = $(patsubst $(srctree)/Documentation/%/index.rst,%,$(wildcard $(srctree)/Documentation/*/index.rst))
SPHINX_CONF = conf.py
PAPER =
BUILDDIR = $(obj)/output
@ -33,8 +33,6 @@ ifeq ($(HAVE_SPHINX),0)
else # HAVE_SPHINX
export SPHINXOPTS = $(shell perl -e 'open IN,"sphinx-build --version 2>&1 |"; while (<IN>) { if (m/([\d\.]+)/) { print "-jauto" if ($$1 >= "1.7") } ;} close IN')
# User-friendly check for pdflatex and latexmk
HAVE_PDFLATEX := $(shell if which $(PDFLATEX) >/dev/null 2>&1; then echo 1; else echo 0; fi)
HAVE_LATEXMK := $(shell if which latexmk >/dev/null 2>&1; then echo 1; else echo 0; fi)
@ -67,6 +65,8 @@ quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4)
cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/media $2 && \
PYTHONDONTWRITEBYTECODE=1 \
BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath $(srctree)/$(src)/$5/$(SPHINX_CONF)) \
$(PYTHON) $(srctree)/scripts/jobserver-exec \
$(SHELL) $(srctree)/Documentation/sphinx/parallel-wrapper.sh \
$(SPHINXBUILD) \
-b $2 \
-c $(abspath $(srctree)/$(src)) \
@ -128,8 +128,10 @@ dochelp:
@echo ' pdfdocs - PDF'
@echo ' epubdocs - EPUB'
@echo ' xmldocs - XML'
@echo ' linkcheckdocs - check for broken external links (will connect to external hosts)'
@echo ' refcheckdocs - check for references to non-existing files under Documentation'
@echo ' linkcheckdocs - check for broken external links'
@echo ' (will connect to external hosts)'
@echo ' refcheckdocs - check for references to non-existing files under'
@echo ' Documentation'
@echo ' cleandocs - clean all generated files'
@echo
@echo ' make SPHINXDIRS="s1 s2" [target] Generate only docs of folder s1, s2'

4
Documentation/admin-guide/LSM/SafeSetID.rst
View File

@ -56,7 +56,7 @@ setid capabilities from the application completely and refactor the process
spawning semantics in the application (e.g. by using a privileged helper program
to do process spawning and UID/GID transitions). Unfortunately, there are a
number of semantics around process spawning that would be affected by this, such
as fork() calls where the program doesn???t immediately call exec() after the
as fork() calls where the program doesn't immediately call exec() after the
fork(), parent processes specifying custom environment variables or command line
args for spawned child processes, or inheritance of file handles across a
fork()/exec(). Because of this, as solution that uses a privileged helper in
@ -72,7 +72,7 @@ own user namespace, and only approved UIDs/GIDs could be mapped back to the
initial system user namespace, affectively preventing privilege escalation.
Unfortunately, it is not generally feasible to use user namespaces in isolation,
without pairing them with other namespace types, which is not always an option.
Linux checks for capabilities based off of the user namespace that ???owns??? some
Linux checks for capabilities based off of the user namespace that "owns" some
entity. For example, Linux has the notion that network namespaces are owned by
the user namespace in which they were created. A consequence of this is that
capability checks for access to a given network namespace are done by checking

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

@ -1120,8 +1120,9 @@ PAGE_SIZE multiple when read back.
Best-effort memory protection. If the memory usage of a
cgroup is within its effective low boundary, the cgroup's
memory won't be reclaimed unless memory can be reclaimed
from unprotected cgroups. Above the effective low boundary (or
memory won't be reclaimed unless there is no reclaimable
memory available in unprotected cgroups.
Above the effective low boundary (or
effective min boundary if it is higher), pages are reclaimed
proportionally to the overage, reducing reclaim pressure for
smaller overages.
@ -1288,7 +1289,12 @@ PAGE_SIZE multiple when read back.
inactive_anon, active_anon, inactive_file, active_file, unevictable
Amount of memory, swap-backed and filesystem-backed,
on the internal memory management lists used by the
page reclaim algorithm
page reclaim algorithm.
As these represent internal list state (eg. shmem pages are on anon
memory management lists), inactive_foo + active_foo may not be equal to
the value for the foo counter, since the foo counter is type-based, not
list-based.
slab_reclaimable
Part of "slab" that might be reclaimed, such as
@ -1920,7 +1926,7 @@ Cpuset Interface Files
It accepts only the following input values when written to.
"root" - a paritition root
"root" - a partition root
"member" - a non-root member of a partition
When set to be a partition root, the current cgroup is the

14
Documentation/driver-api/dell_rbu.rst → Documentation/admin-guide/dell_rbu.rst
View File

@ -1,11 +1,11 @@
=============================================================
Usage of the new open sourced rbu (Remote BIOS Update) driver
=============================================================
=========================================
Dell Remote BIOS Update driver (dell_rbu)
=========================================
Purpose
=======
Document demonstrating the use of the Dell Remote BIOS Update driver.
Document demonstrating the use of the Dell Remote BIOS Update driver
for updating BIOS images on Dell servers and desktops.
Scope
@ -37,7 +37,7 @@ maintains a link list of packets for reading them back.
If the dell_rbu driver is unloaded all the allocated memory is freed.
The rbu driver needs to have an application (as mentioned above)which will
The rbu driver needs to have an application (as mentioned above) which will
inform the BIOS to enable the update in the next system reboot.
The user should not unload the rbu driver after downloading the BIOS image
@ -71,7 +71,7 @@ be downloaded. It is done as below::
echo XXXX > /sys/devices/platform/dell_rbu/packet_size
In the packet update mechanism, the user needs to create a new file having
packets of data arranged back to back. It can be done as follows
packets of data arranged back to back. It can be done as follows:
The user creates packets header, gets the chunk of the BIOS image and
places it next to the packetheader; now, the packetheader + BIOS image chunk
added together should match the specified packet_size. This makes one
@ -114,7 +114,7 @@ The entries can be recreated by doing the following::
echo init > /sys/devices/platform/dell_rbu/image_type
.. note:: echoing init in image_type does not change it original value.
.. note:: echoing init in image_type does not change its original value.
Also the driver provides /sys/devices/platform/dell_rbu/data readonly file to
read back the image downloaded.

243
Documentation/admin-guide/device-mapper/dm-dust.txt → Documentation/admin-guide/device-mapper/dm-dust.rst
View File

@ -31,218 +31,233 @@ configured "bad blocks" will be treated as bad, or bypassed.
This allows the pre-writing of test data and metadata prior to
simulating a "failure" event where bad sectors start to appear.
Table parameters:
-----------------
Table parameters
----------------
<device_path> <offset> <blksz>
Mandatory parameters:
<device_path>: path to the block device.
<offset>: offset to data area from start of device_path
<blksz>: block size in bytes
<device_path>:
Path to the block device.
<offset>:
Offset to data area from start of device_path
<blksz>:
Block size in bytes
(minimum 512, maximum 1073741824, must be a power of 2)
Usage instructions:
-------------------
Usage instructions
------------------
First, find the size (in 512-byte sectors) of the device to be used:
First, find the size (in 512-byte sectors) of the device to be used::
$ sudo blockdev --getsz /dev/vdb1
33552384
$ sudo blockdev --getsz /dev/vdb1
33552384
Create the dm-dust device:
(For a device with a block size of 512 bytes)
$ sudo dmsetup create dust1 --table '0 33552384 dust /dev/vdb1 0 512'
::
$ sudo dmsetup create dust1 --table '0 33552384 dust /dev/vdb1 0 512'
(For a device with a block size of 4096 bytes)
$ sudo dmsetup create dust1 --table '0 33552384 dust /dev/vdb1 0 4096'
::
$ sudo dmsetup create dust1 --table '0 33552384 dust /dev/vdb1 0 4096'
Check the status of the read behavior ("bypass" indicates that all I/O
will be passed through to the underlying device):
$ sudo dmsetup status dust1
0 33552384 dust 252:17 bypass
will be passed through to the underlying device)::
$ sudo dd if=/dev/mapper/dust1 of=/dev/null bs=512 count=128 iflag=direct
128+0 records in
128+0 records out
$ sudo dmsetup status dust1
0 33552384 dust 252:17 bypass
$ sudo dd if=/dev/zero of=/dev/mapper/dust1 bs=512 count=128 oflag=direct
128+0 records in
128+0 records out
$ sudo dd if=/dev/mapper/dust1 of=/dev/null bs=512 count=128 iflag=direct
128+0 records in
128+0 records out
Adding and removing bad blocks:
-------------------------------
$ sudo dd if=/dev/zero of=/dev/mapper/dust1 bs=512 count=128 oflag=direct
128+0 records in
128+0 records out
Adding and removing bad blocks
------------------------------
At any time (i.e.: whether the device has the "bad block" emulation
enabled or disabled), bad blocks may be added or removed from the
device via the "addbadblock" and "removebadblock" messages:
device via the "addbadblock" and "removebadblock" messages::
$ sudo dmsetup message dust1 0 addbadblock 60
kernel: device-mapper: dust: badblock added at block 60
$ sudo dmsetup message dust1 0 addbadblock 60
kernel: device-mapper: dust: badblock added at block 60
$ sudo dmsetup message dust1 0 addbadblock 67
kernel: device-mapper: dust: badblock added at block 67
$ sudo dmsetup message dust1 0 addbadblock 67
kernel: device-mapper: dust: badblock added at block 67
$ sudo dmsetup message dust1 0 addbadblock 72
kernel: device-mapper: dust: badblock added at block 72
$ sudo dmsetup message dust1 0 addbadblock 72
kernel: device-mapper: dust: badblock added at block 72
These bad blocks will be stored in the "bad block list".
While the device is in "bypass" mode, reads and writes will succeed:
While the device is in "bypass" mode, reads and writes will succeed::
$ sudo dmsetup status dust1
0 33552384 dust 252:17 bypass
$ sudo dmsetup status dust1
0 33552384 dust 252:17 bypass
Enabling block read failures:
-----------------------------
Enabling block read failures
----------------------------
To enable the "fail read on bad block" behavior, send the "enable" message:
To enable the "fail read on bad block" behavior, send the "enable" message::
$ sudo dmsetup message dust1 0 enable
kernel: device-mapper: dust: enabling read failures on bad sectors
$ sudo dmsetup message dust1 0 enable
kernel: device-mapper: dust: enabling read failures on bad sectors
$ sudo dmsetup status dust1
0 33552384 dust 252:17 fail_read_on_bad_block
$ sudo dmsetup status dust1
0 33552384 dust 252:17 fail_read_on_bad_block
With the device in "fail read on bad block" mode, attempting to read a
block will encounter an "Input/output error":
block will encounter an "Input/output error"::
$ sudo dd if=/dev/mapper/dust1 of=/dev/null bs=512 count=1 skip=67 iflag=direct
dd: error reading '/dev/mapper/dust1': Input/output error
0+0 records in
0+0 records out
0 bytes copied, 0.00040651 s, 0.0 kB/s
$ sudo dd if=/dev/mapper/dust1 of=/dev/null bs=512 count=1 skip=67 iflag=direct
dd: error reading '/dev/mapper/dust1': Input/output error
0+0 records in
0+0 records out
0 bytes copied, 0.00040651 s, 0.0 kB/s
...and writing to the bad blocks will remove the blocks from the list,
therefore emulating the "remap" behavior of hard disk drives:
therefore emulating the "remap" behavior of hard disk drives::
$ sudo dd if=/dev/zero of=/dev/mapper/dust1 bs=512 count=128 oflag=direct
128+0 records in
128+0 records out
$ sudo dd if=/dev/zero of=/dev/mapper/dust1 bs=512 count=128 oflag=direct
128+0 records in
128+0 records out
kernel: device-mapper: dust: block 60 removed from badblocklist by write
kernel: device-mapper: dust: block 67 removed from badblocklist by write
kernel: device-mapper: dust: block 72 removed from badblocklist by write
kernel: device-mapper: dust: block 87 removed from badblocklist by write
kernel: device-mapper: dust: block 60 removed from badblocklist by write
kernel: device-mapper: dust: block 67 removed from badblocklist by write
kernel: device-mapper: dust: block 72 removed from badblocklist by write
kernel: device-mapper: dust: block 87 removed from badblocklist by write
Bad block add/remove error handling:
------------------------------------
Bad block add/remove error handling
-----------------------------------
Attempting to add a bad block that already exists in the list will
result in an "Invalid argument" error, as well as a helpful message:
result in an "Invalid argument" error, as well as a helpful message::
$ sudo dmsetup message dust1 0 addbadblock 88
device-mapper: message ioctl on dust1 failed: Invalid argument
kernel: device-mapper: dust: block 88 already in badblocklist
$ sudo dmsetup message dust1 0 addbadblock 88
device-mapper: message ioctl on dust1 failed: Invalid argument
kernel: device-mapper: dust: block 88 already in badblocklist
Attempting to remove a bad block that doesn't exist in the list will
result in an "Invalid argument" error, as well as a helpful message:
result in an "Invalid argument" error, as well as a helpful message::
$ sudo dmsetup message dust1 0 removebadblock 87
device-mapper: message ioctl on dust1 failed: Invalid argument
kernel: device-mapper: dust: block 87 not found in badblocklist
$ sudo dmsetup message dust1 0 removebadblock 87
device-mapper: message ioctl on dust1 failed: Invalid argument
kernel: device-mapper: dust: block 87 not found in badblocklist
Counting the number of bad blocks in the bad block list:
--------------------------------------------------------
Counting the number of bad blocks in the bad block list
-------------------------------------------------------
To count the number of bad blocks configured in the device, run the
following message command:
following message command::
$ sudo dmsetup message dust1 0 countbadblocks
$ sudo dmsetup message dust1 0 countbadblocks
A message will print with the number of bad blocks currently
configured on the device:
configured on the device::
kernel: device-mapper: dust: countbadblocks: 895 badblock(s) found
kernel: device-mapper: dust: countbadblocks: 895 badblock(s) found
Querying for specific bad blocks:
---------------------------------
Querying for specific bad blocks
--------------------------------
To find out if a specific block is in the bad block list, run the
following message command:
following message command::
$ sudo dmsetup message dust1 0 queryblock 72
$ sudo dmsetup message dust1 0 queryblock 72
The following message will print if the block is in the list:
device-mapper: dust: queryblock: block 72 found in badblocklist
The following message will print if the block is in the list::
The following message will print if the block is in the list:
device-mapper: dust: queryblock: block 72 not found in badblocklist
device-mapper: dust: queryblock: block 72 found in badblocklist
The following message will print if the block is not in the list::
device-mapper: dust: queryblock: block 72 not found in badblocklist
The "queryblock" message command will work in both the "enabled"
and "disabled" modes, allowing the verification of whether a block
will be treated as "bad" without having to issue I/O to the device,
or having to "enable" the bad block emulation.
Clearing the bad block list:
----------------------------
Clearing the bad block list
---------------------------
To clear the bad block list (without needing to individually run
a "removebadblock" message command for every block), run the
following message command:
following message command::
$ sudo dmsetup message dust1 0 clearbadblocks
$ sudo dmsetup message dust1 0 clearbadblocks
After clearing the bad block list, the following message will appear:
After clearing the bad block list, the following message will appear::
kernel: device-mapper: dust: clearbadblocks: badblocks cleared
kernel: device-mapper: dust: clearbadblocks: badblocks cleared
If there were no bad blocks to clear, the following message will
appear:
appear::
kernel: device-mapper: dust: clearbadblocks: no badblocks found
kernel: device-mapper: dust: clearbadblocks: no badblocks found
Message commands list:
----------------------
Message commands list
---------------------
Below is a list of the messages that can be sent to a dust device:
Operations on blocks (requires a <blknum> argument):
Operations on blocks (requires a <blknum> argument)::
addbadblock <blknum>
queryblock <blknum>
removebadblock <blknum>
addbadblock <blknum>
queryblock <blknum>
removebadblock <blknum>
...where <blknum> is a block number within range of the device
(corresponding to the block size of the device.)
(corresponding to the block size of the device.)
Single argument message commands:
Single argument message commands::
countbadblocks
clearbadblocks
disable
enable
quiet
countbadblocks
clearbadblocks
disable
enable
quiet
Device removal:
---------------
Device removal
--------------
When finished, remove the device via the "dmsetup remove" command:
When finished, remove the device via the "dmsetup remove" command::
$ sudo dmsetup remove dust1
$ sudo dmsetup remove dust1
Quiet mode:
-----------
Quiet mode
----------
On test runs with many bad blocks, it may be desirable to avoid
excessive logging (from bad blocks added, removed, or "remapped").
This can be done by enabling "quiet mode" via the following message:
This can be done by enabling "quiet mode" via the following message::
$ sudo dmsetup message dust1 0 quiet
$ sudo dmsetup message dust1 0 quiet
This will suppress log messages from add / remove / removed by write
operations. Log messages from "countbadblocks" or "queryblock"
message commands will still print in quiet mode.
The status of quiet mode can be seen by running "dmsetup status":
The status of quiet mode can be seen by running "dmsetup status"::
$ sudo dmsetup status dust1
0 33552384 dust 252:17 fail_read_on_bad_block quiet
$ sudo dmsetup status dust1
0 33552384 dust 252:17 fail_read_on_bad_block quiet
To disable quiet mode, send the "quiet" message again:
To disable quiet mode, send the "quiet" message again::
$ sudo dmsetup message dust1 0 quiet
$ sudo dmsetup message dust1 0 quiet
$ sudo dmsetup status dust1
0 33552384 dust 252:17 fail_read_on_bad_block verbose
$ sudo dmsetup status dust1
0 33552384 dust 252:17 fail_read_on_bad_block verbose
(The presence of "verbose" indicates normal logging.)

1
Documentation/admin-guide/device-mapper/index.rst
View File

@ -9,6 +9,7 @@ Device Mapper
cache
delay
dm-crypt
dm-dust
dm-flakey
dm-init
dm-integrity

65
Documentation/admin-guide/index.rst
View File

@ -57,60 +57,61 @@ configure specific aspects of kernel behavior to your liking.
.. toctree::
:maxdepth: 1
initrd
cgroup-v2
cgroup-v1/index
serial-console
braille-console
parport
md
module-signing
rapidio
sysrq
unicode
vga-softcursor
binfmt-misc
mono
java
ras
bcache
blockdev/index
ext4
binderfs
cifs/index
xfs
jfs
ufs
pm/index
thunderbolt
LSM/index
mm/index
namespaces/index
perf-security
acpi/index
aoe/index
auxdisplay/index
bcache
binderfs
binfmt-misc
blockdev/index
braille-console
btmrvl
cgroup-v1/index
cgroup-v2
cifs/index
clearing-warn-once
cpu-load
cputopology
dell_rbu
device-mapper/index
efi-stub
ext4
gpio/index
highuid
hw_random
initrd
iostats
java
jfs
kernel-per-CPU-kthreads
laptops/index
auxdisplay/index
lcd-panel-cgram
ldm
lockup-watchdogs
LSM/index
md
mm/index
module-signing
mono
namespaces/index
numastat
parport
perf-security
pm/index
pnp
rapidio
ras
rtc
serial-console
svga
wimax/index
sysrq
thunderbolt
ufs
unicode
vga-softcursor
video-output
wimax/index
xfs
.. only:: subproject and html

47
Documentation/admin-guide/iostats.rst
View File

@ -46,78 +46,79 @@ each snapshot of your disk statistics.
In 2.4, the statistics fields are those after the device name. In
the above example, the first field of statistics would be 446216.
By contrast, in 2.6+ if you look at ``/sys/block/hda/stat``, you'll
find just the eleven fields, beginning with 446216. If you look at
``/proc/diskstats``, the eleven fields will be preceded by the major and
find just the 15 fields, beginning with 446216. If you look at
``/proc/diskstats``, the 15 fields will be preceded by the major and
minor device numbers, and device name. Each of these formats provides
eleven fields of statistics, each meaning exactly the same things.
15 fields of statistics, each meaning exactly the same things.
All fields except field 9 are cumulative since boot. Field 9 should
go to zero as I/Os complete; all others only increase (unless they
overflow and wrap). Yes, these are (32-bit or 64-bit) unsigned long
(native word size) numbers, and on a very busy or long-lived system they
may wrap. Applications should be prepared to deal with that; unless
your observations are measured in large numbers of minutes or hours,
they should not wrap twice before you notice them.
overflow and wrap). Wrapping might eventually occur on a very busy
or long-lived system; so applications should be prepared to deal with
it. Regarding wrapping, the types of the fields are either unsigned
int (32 bit) or unsigned long (32-bit or 64-bit, depending on your
machine) as noted per-field below. Unless your observations are very
spread in time, these fields should not wrap twice before you notice it.
Each set of stats only applies to the indicated device; if you want
system-wide stats you'll have to find all the devices and sum them all up.
Field 1 -- # of reads completed
Field 1 -- # of reads completed (unsigned long)
This is the total number of reads completed successfully.
Field 2 -- # of reads merged, field 6 -- # of writes merged
Field 2 -- # of reads merged, field 6 -- # of writes merged (unsigned long)
Reads and writes which are adjacent to each other may be merged for
efficiency. Thus two 4K reads may become one 8K read before it is
ultimately handed to the disk, and so it will be counted (and queued)
as only one I/O. This field lets you know how often this was done.
Field 3 -- # of sectors read
Field 3 -- # of sectors read (unsigned long)
This is the total number of sectors read successfully.
Field 4 -- # of milliseconds spent reading
Field 4 -- # of milliseconds spent reading (unsigned int)
This is the total number of milliseconds spent by all reads (as
measured from __make_request() to end_that_request_last()).
Field 5 -- # of writes completed
Field 5 -- # of writes completed (unsigned long)
This is the total number of writes completed successfully.
Field 6 -- # of writes merged
Field 6 -- # of writes merged (unsigned long)
See the description of field 2.
Field 7 -- # of sectors written
Field 7 -- # of sectors written (unsigned long)
This is the total number of sectors written successfully.
Field 8 -- # of milliseconds spent writing
Field 8 -- # of milliseconds spent writing (unsigned int)
This is the total number of milliseconds spent by all writes (as
measured from __make_request() to end_that_request_last()).
Field 9 -- # of I/Os currently in progress
Field 9 -- # of I/Os currently in progress (unsigned int)
The only field that should go to zero. Incremented as requests are
given to appropriate struct request_queue and decremented as they finish.
Field 10 -- # of milliseconds spent doing I/Os
Field 10 -- # of milliseconds spent doing I/Os (unsigned int)
This field increases so long as field 9 is nonzero.
Since 5.0 this field counts jiffies when at least one request was
started or completed. If request runs more than 2 jiffies then some
I/O time will not be accounted unless there are other requests.
Field 11 -- weighted # of milliseconds spent doing I/Os
Field 11 -- weighted # of milliseconds spent doing I/Os (unsigned int)
This field is incremented at each I/O start, I/O completion, I/O
merge, or read of these stats by the number of I/Os in progress
(field 9) times the number of milliseconds spent doing I/O since the
last update of this field. This can provide an easy measure of both
I/O completion time and the backlog that may be accumulating.
Field 12 -- # of discards completed
Field 12 -- # of discards completed (unsigned long)
This is the total number of discards completed successfully.
Field 13 -- # of discards merged
Field 13 -- # of discards merged (unsigned long)
See the description of field 2
Field 14 -- # of sectors discarded
Field 14 -- # of sectors discarded (unsigned long)
This is the total number of sectors discarded successfully.
Field 15 -- # of milliseconds spent discarding
Field 15 -- # of milliseconds spent discarding (unsigned int)
This is the total number of milliseconds spent by all discards (as
measured from __make_request() to end_that_request_last()).

1
Documentation/admin-guide/kernel-parameters.rst
View File

@ -127,6 +127,7 @@ parameter is applicable::
NET Appropriate network support is enabled.
NUMA NUMA support is enabled.
NFS Appropriate NFS support is enabled.
OF Devicetree is enabled.
OSS OSS sound support is enabled.
PV_OPS A paravirtualized kernel is enabled.
PARIDE The ParIDE (parallel port IDE) subsystem is enabled.

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

@ -437,8 +437,6 @@
no delay (0).
Format: integer
bootmem_debug [KNL] Enable bootmem allocator debug messages.
bert_disable [ACPI]
Disable BERT OS support on buggy BIOSes.
@ -983,12 +981,10 @@
earlycon= [KNL] Output early console device and options.
[ARM64] The early console is determined by the
stdout-path property in device tree's chosen node,
or determined by the ACPI SPCR table.
[X86] When used with no options the early console is
determined by the ACPI SPCR table.
When used with no options, the early console is
determined by stdout-path property in device tree's
chosen node or the ACPI SPCR table if supported by
the platform.
cdns,<addr>[,options]
Start an early, polled-mode console on a Cadence
@ -1101,7 +1097,7 @@
mapped with the correct attributes.
linflex,<addr>
Use early console provided by Freescale LinFlex UART
Use early console provided by Freescale LINFlexD UART
serial driver for NXP S32V234 SoCs. A valid base
address must be provided, and the serial port must
already be setup and configured.
@ -1168,7 +1164,8 @@
Format: {"off" | "on" | "skip[mbr]"}
efi= [EFI]
Format: { "old_map", "nochunk", "noruntime", "debug" }
Format: { "old_map", "nochunk", "noruntime", "debug",
"nosoftreserve" }
old_map [X86-64]: switch to the old ioremap-based EFI
runtime services mapping. 32-bit still uses this one by
default.
@ -1177,6 +1174,12 @@
firmware implementations.
noruntime : disable EFI runtime services support
debug: enable misc debug output
nosoftreserve: The EFI_MEMORY_SP (Specific Purpose)
attribute may cause the kernel to reserve the
memory range for a memory mapping driver to
claim. Specify efi=nosoftreserve to disable this
reservation and treat the memory by its base type
(i.e. EFI_CONVENTIONAL_MEMORY / "System RAM").
efi_no_storage_paranoia [EFI; X86]
Using this parameter you can use more than 50% of
@ -1189,15 +1192,21 @@
updating original EFI memory map.
Region of memory which aa attribute is added to is
from ss to ss+nn.
If efi_fake_mem=2G@4G:0x10000,2G@0x10a0000000:0x10000
is specified, EFI_MEMORY_MORE_RELIABLE(0x10000)
attribute is added to range 0x100000000-0x180000000 and
0x10a0000000-0x1120000000.
If efi_fake_mem=8G@9G:0x40000 is specified, the
EFI_MEMORY_SP(0x40000) attribute is added to
range 0x240000000-0x43fffffff.
Using this parameter you can do debugging of EFI memmap
related feature. For example, you can do debugging of
related features. For example, you can do debugging of
Address Range Mirroring feature even if your box
doesn't support it.
doesn't support it, or mark specific memory as
"soft reserved".
efivar_ssdt= [EFI; X86] Name of an EFI variable that contains an SSDT
that is to be dynamically loaded by Linux. If there are
@ -3227,6 +3236,12 @@
This can be set from sysctl after boot.
See Documentation/admin-guide/sysctl/vm.rst for details.
of_devlink [OF, KNL] Create device links between consumer and
supplier devices by scanning the devictree to infer the
consumer/supplier relationships. A consumer device
will not be probed until all the supplier devices have
probed successfully.
ohci1394_dma=early [HW] enable debugging via the ohci1394 driver.
See Documentation/debugging-via-ohci1394.txt for more
info.
@ -3525,8 +3540,15 @@
hpiosize=nn[KMG] The fixed amount of bus space which is
reserved for hotplug bridge's IO window.
Default size is 256 bytes.
hpmmiosize=nn[KMG] The fixed amount of bus space which is
reserved for hotplug bridge's MMIO window.
Default size is 2 megabytes.
hpmmioprefsize=nn[KMG] The fixed amount of bus space which is
reserved for hotplug bridge's MMIO_PREF window.
Default size is 2 megabytes.
hpmemsize=nn[KMG] The fixed amount of bus space which is
reserved for hotplug bridge's memory window.
reserved for hotplug bridge's MMIO and
MMIO_PREF window.
Default size is 2 megabytes.
hpbussize=nn The minimum amount of additional bus numbers
reserved for buses below a hotplug bridge.
@ -3573,6 +3595,8 @@
even if the platform doesn't give the OS permission to
use them. This may cause conflicts if the platform
also tries to use these services.
dpc-native Use native PCIe service for DPC only. May
cause conflicts if firmware uses AER or DPC.
compat Disable native PCIe services (PME, AER, DPC, PCIe
hotplug).
@ -5101,13 +5125,13 @@
Flags is a set of characters, each corresponding
to a common usb-storage quirk flag as follows:
a = SANE_SENSE (collect more than 18 bytes
of sense data);
of sense data, not on uas);
b = BAD_SENSE (don't collect more than 18
bytes of sense data);
bytes of sense data, not on uas);
c = FIX_CAPACITY (decrease the reported
device capacity by one sector);
d = NO_READ_DISC_INFO (don't use
READ_DISC_INFO command);
READ_DISC_INFO command, not on uas);
e = NO_READ_CAPACITY_16 (don't use
READ_CAPACITY_16 command);
f = NO_REPORT_OPCODES (don't use report opcodes
@ -5122,17 +5146,18 @@
j = NO_REPORT_LUNS (don't use report luns
command, uas only);
l = NOT_LOCKABLE (don't try to lock and
unlock ejectable media);
unlock ejectable media, not on uas);
m = MAX_SECTORS_64 (don't transfer more
than 64 sectors = 32 KB at a time);
than 64 sectors = 32 KB at a time,
not on uas);
n = INITIAL_READ10 (force a retry of the
initial READ(10) command);
initial READ(10) command, not on uas);
o = CAPACITY_OK (accept the capacity
reported by the device);
reported by the device, not on uas);
p = WRITE_CACHE (the device cache is ON
by default);
by default, not on uas);
r = IGNORE_RESIDUE (the device reports
bogus residue values);
bogus residue values, not on uas);
s = SINGLE_LUN (the device has only one
Logical Unit);
t = NO_ATA_1X (don't allow ATA(12) and ATA(16)
@ -5141,7 +5166,8 @@
w = NO_WP_DETECT (don't test whether the
medium is write-protected).
y = ALWAYS_SYNC (issue a SYNCHRONIZE_CACHE
even if the device claims no cache)
even if the device claims no cache,
not on uas)
Example: quirks=0419:aaf5:rl,0421:0433:rc
user_debug= [KNL,ARM]

31
Documentation/admin-guide/perf/imx-ddr.rst
View File

@ -19,7 +19,9 @@ devices/imx8_ddr0/format/. The "events" directory describes the events types
hardware supported that can be used with perf tool, see /sys/bus/event_source/
devices/imx8_ddr0/events/. The "caps" directory describes filter features implemented
in DDR PMU, see /sys/bus/events_source/devices/imx8_ddr0/caps/.
e.g.::
.. code-block:: bash
perf stat -a -e imx8_ddr0/cycles/ cmd
perf stat -a -e imx8_ddr0/read/,imx8_ddr0/write/ cmd
@ -35,24 +37,31 @@ value 1 for supported.
Filter is defined with two configuration parts:
--AXI_ID defines AxID matching value.
--AXI_MASKING defines which bits of AxID are meaningful for the matching.
0：corresponding bit is masked.
1: corresponding bit is not masked, i.e. used to do the matching.
- 0: corresponding bit is masked.
- 1: corresponding bit is not masked, i.e. used to do the matching.
AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance counter.
When non-masked bits are matching corresponding AXI_ID bits then counter is
incremented. Perf counter is incremented if
AxID && AXI_MASKING == AXI_ID && AXI_MASKING
AxID && AXI_MASKING == AXI_ID && AXI_MASKING
This filter doesn't support filter different AXI ID for axid-read and axid-write
event at the same time as this filter is shared between counters.
e.g.::
perf stat -a -e imx8_ddr0/axid-read,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
perf stat -a -e imx8_ddr0/axid-write,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
NOTE: axi_mask is inverted in userspace(i.e. set bits are bits to mask), and
it will be reverted in driver automatically. so that the user can just specify
axi_id to monitor a specific id, rather than having to specify axi_mask.
e.g.::
.. code-block:: bash
perf stat -a -e imx8_ddr0/axid-read,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
perf stat -a -e imx8_ddr0/axid-write,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
.. note::
axi_mask is inverted in userspace(i.e. set bits are bits to mask), and
it will be reverted in driver automatically. so that the user can just specify
axi_id to monitor a specific id, rather than having to specify axi_mask.
.. code-block:: bash
perf stat -a -e imx8_ddr0/axid-read,axi_id=0x12/ cmd, which will monitor ARID=0x12
* With DDR_CAP_AXI_ID_FILTER_ENHANCED quirk(filter: 1, enhanced_filter: 1).

1
Documentation/admin-guide/perf/index.rst
View File

@ -8,6 +8,7 @@ Performance monitor support
:maxdepth: 1
hisi-pmu
imx-ddr
qcom_l2_pmu
qcom_l3_pmu
arm-ccn

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

@ -831,8 +831,8 @@ printk_ratelimit:
=================
Some warning messages are rate limited. printk_ratelimit specifies
the minimum length of time between these messages (in jiffies), by
default we allow one every 5 seconds.
the minimum length of time between these messages (in seconds).
The default value is 5 seconds.
A value of 0 will disable rate limiting.
@ -845,6 +845,8 @@ seconds, we do allow a burst of messages to pass through.
printk_ratelimit_burst specifies the number of messages we can
send before ratelimiting kicks in.
The default value is 10 messages.
printk_devkmsg:
===============
@ -1101,7 +1103,7 @@ During initialization the kernel sets this value such that even if the
maximum number of threads is created, the thread structures occupy only
a part (1/8th) of the available RAM pages.
The minimum value that can be written to threads-max is 20.
The minimum value that can be written to threads-max is 1.
The maximum value that can be written to threads-max is given by the
constant FUTEX_TID_MASK (0x3fffffff).
@ -1109,10 +1111,6 @@ constant FUTEX_TID_MASK (0x3fffffff).
If a value outside of this range is written to threads-max an error
EINVAL occurs.
The value written is checked against the available RAM pages. If the
thread structures would occupy too much (more than 1/8th) of the
available RAM pages threads-max is reduced accordingly.
unknown_nmi_panic:
==================

3
Documentation/conf.py
View File

@ -37,7 +37,8 @@ needs_sphinx = '1.3'
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain',
'kfigure', 'sphinx.ext.ifconfig', 'automarkup']
'kfigure', 'sphinx.ext.ifconfig', 'automarkup',
'maintainers_include']
# The name of the math extension changed on Sphinx 1.4
if (major == 1 and minor > 3) or (major > 1):

26
Documentation/core-api/genalloc.rst
View File

@ -23,7 +23,7 @@ begins with the creation of a pool using one of:
.. kernel-doc:: lib/genalloc.c
:functions: devm_gen_pool_create
A call to :c:func:`gen_pool_create` will create a pool. The granularity of
A call to gen_pool_create() will create a pool. The granularity of
allocations is set with min_alloc_order; it is a log-base-2 number like
those used by the page allocator, but it refers to bytes rather than pages.
So, if min_alloc_order is passed as 3, then all allocations will be a
@ -32,7 +32,7 @@ required to track the memory in the pool. The nid parameter specifies
which NUMA node should be used for the allocation of the housekeeping
structures; it can be -1 if the caller doesn't care.
The "managed" interface :c:func:`devm_gen_pool_create` ties the pool to a
The "managed" interface devm_gen_pool_create() ties the pool to a
specific device. Among other things, it will automatically clean up the
pool when the given device is destroyed.
@ -53,32 +53,32 @@ to the pool. That can be done with one of:
:functions: gen_pool_add
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_add_virt
:functions: gen_pool_add_owner
A call to :c:func:`gen_pool_add` will place the size bytes of memory
A call to gen_pool_add() will place the size bytes of memory
starting at addr (in the kernel's virtual address space) into the given
pool, once again using nid as the node ID for ancillary memory allocations.
The :c:func:`gen_pool_add_virt` variant associates an explicit physical
The gen_pool_add_virt() variant associates an explicit physical
address with the memory; this is only necessary if the pool will be used
for DMA allocations.
The functions for allocating memory from the pool (and putting it back)
are:
.. kernel-doc:: lib/genalloc.c
.. kernel-doc:: include/linux/genalloc.h
:functions: gen_pool_alloc
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_dma_alloc
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_free
:functions: gen_pool_free_owner
As one would expect, :c:func:`gen_pool_alloc` will allocate size< bytes
from the given pool. The :c:func:`gen_pool_dma_alloc` variant allocates
As one would expect, gen_pool_alloc() will allocate size< bytes
from the given pool. The gen_pool_dma_alloc() variant allocates
memory for use with DMA operations, returning the associated physical
address in the space pointed to by dma. This will only work if the memory
was added with :c:func:`gen_pool_add_virt`. Note that this function
was added with gen_pool_add_virt(). Note that this function
departs from the usual genpool pattern of using unsigned long values to
represent kernel addresses; it returns a void * instead.
@ -89,14 +89,14 @@ return. If that sort of control is needed, the following functions will be
of interest:
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_alloc_algo
:functions: gen_pool_alloc_algo_owner
.. kernel-doc:: lib/genalloc.c
:functions: gen_pool_set_algo
Allocations with :c:func:`gen_pool_alloc_algo` specify an algorithm to be
Allocations with gen_pool_alloc_algo() specify an algorithm to be
used to choose the memory to be allocated; the default algorithm can be set
with :c:func:`gen_pool_set_algo`. The data value is passed to the
with gen_pool_set_algo(). The data value is passed to the
algorithm; most ignore it, but it is occasionally needed. One can,
naturally, write a special-purpose algorithm, but there is a fair set
already available:

52
Documentation/core-api/genericirq.rst
View File

@ -26,7 +26,7 @@ Rationale
=========
The original implementation of interrupt handling in Linux uses the
:c:func:`__do_IRQ` super-handler, which is able to deal with every type of
__do_IRQ() super-handler, which is able to deal with every type of
interrupt logic.
Originally, Russell King identified different types of handlers to build
@ -43,7 +43,7 @@ During the implementation we identified another type:
- Fast EOI type
In the SMP world of the :c:func:`__do_IRQ` super-handler another type was
In the SMP world of the __do_IRQ() super-handler another type was
identified:
- Per CPU type
@ -83,7 +83,7 @@ IRQ-flow implementation for 'level type' interrupts and add a
(sub)architecture specific 'edge type' implementation.
To make the transition to the new model easier and prevent the breakage
of existing implementations, the :c:func:`__do_IRQ` super-handler is still
of existing implementations, the __do_IRQ() super-handler is still
available. This leads to a kind of duality for the time being. Over time
the new model should be used in more and more architectures, as it
enables smaller and cleaner IRQ subsystems. It's deprecated for three
@ -116,7 +116,7 @@ status information and pointers to the interrupt flow method and the
interrupt chip structure which are assigned to this interrupt.
Whenever an interrupt triggers, the low-level architecture code calls
into the generic interrupt code by calling :c:func:`desc->handle_irq`. This
into the generic interrupt code by calling desc->handle_irq(). This
high-level IRQ handling function only uses desc->irq_data.chip
primitives referenced by the assigned chip descriptor structure.
@ -125,27 +125,29 @@ High-level Driver API
The high-level Driver API consists of following functions:
- :c:func:`request_irq`
- request_irq()
- :c:func:`free_irq`
- request_threaded_irq()
- :c:func:`disable_irq`
- free_irq()
- :c:func:`enable_irq`
- disable_irq()
- :c:func:`disable_irq_nosync` (SMP only)
- enable_irq()
- :c:func:`synchronize_irq` (SMP only)
- disable_irq_nosync() (SMP only)
- :c:func:`irq_set_irq_type`
- synchronize_irq() (SMP only)
- :c:func:`irq_set_irq_wake`
- irq_set_irq_type()
- :c:func:`irq_set_handler_data`
- irq_set_irq_wake()
- :c:func:`irq_set_chip`
- irq_set_handler_data()
- :c:func:`irq_set_chip_data`
- irq_set_chip()
- irq_set_chip_data()
See the autogenerated function documentation for details.
@ -154,19 +156,19 @@ High-level IRQ flow handlers
The generic layer provides a set of pre-defined irq-flow methods:
- :c:func:`handle_level_irq`
- handle_level_irq()
- :c:func:`handle_edge_irq`
- handle_edge_irq()
- :c:func:`handle_fasteoi_irq`
- handle_fasteoi_irq()
- :c:func:`handle_simple_irq`
- handle_simple_irq()
- :c:func:`handle_percpu_irq`
- handle_percpu_irq()
- :c:func:`handle_edge_eoi_irq`
- handle_edge_eoi_irq()
- :c:func:`handle_bad_irq`
- handle_bad_irq()
The interrupt flow handlers (either pre-defined or architecture
specific) are assigned to specific interrupts by the architecture either
@ -325,14 +327,14 @@ Delayed interrupt disable
This per interrupt selectable feature, which was introduced by Russell
King in the ARM interrupt implementation, does not mask an interrupt at
the hardware level when :c:func:`disable_irq` is called. The interrupt is kept
the hardware level when disable_irq() is called. The interrupt is kept
enabled and is masked in the flow handler when an interrupt event
happens. This prevents losing edge interrupts on hardware which does not
store an edge interrupt event while the interrupt is disabled at the
hardware level. When an interrupt arrives while the IRQ_DISABLED flag
is set, then the interrupt is masked at the hardware level and the
IRQ_PENDING bit is set. When the interrupt is re-enabled by
:c:func:`enable_irq` the pending bit is checked and if it is set, the interrupt
enable_irq() the pending bit is checked and if it is set, the interrupt
is resent either via hardware or by a software resend mechanism. (It's
necessary to enable CONFIG_HARDIRQS_SW_RESEND when you want to use
the delayed interrupt disable feature and your hardware is not capable
@ -369,7 +371,7 @@ handler(s) to use these basic units of low-level functionality.
__do_IRQ entry point
====================
The original implementation :c:func:`__do_IRQ` was an alternative entry point
The original implementation __do_IRQ() was an alternative entry point
for all types of interrupts. It no longer exists.
This handler turned out to be not suitable for all interrupt hardware

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

@ -88,10 +88,11 @@ Selecting memory allocator
==========================
The most straightforward way to allocate memory is to use a function
from the :c:func:`kmalloc` family. And, to be on the safe size it's
best to use routines that set memory to zero, like
:c:func:`kzalloc`. If you need to allocate memory for an array, there
are :c:func:`kmalloc_array` and :c:func:`kcalloc` helpers.
from the kmalloc() family. And, to be on the safe side it's best to use
routines that set memory to zero, like kzalloc(). If you need to
allocate memory for an array, there are kmalloc_array() and kcalloc()
helpers. The helpers struct_size(), array_size() and array3_size() can
be used to safely calculate object sizes without overflowing.
The maximal size of a chunk that can be allocated with `kmalloc` is
limited. The actual limit depends on the hardware and the kernel
@ -102,29 +103,26 @@ The address of a chunk allocated with `kmalloc` is aligned to at least
ARCH_KMALLOC_MINALIGN bytes. For sizes which are a power of two, the
alignment is also guaranteed to be at least the respective size.
For large allocations you can use :c:func:`vmalloc` and
:c:func:`vzalloc`, or directly request pages from the page
allocator. The memory allocated by `vmalloc` and related functions is
not physically contiguous.
For large allocations you can use vmalloc() and vzalloc(), or directly
request pages from the page allocator. The memory allocated by `vmalloc`
and related functions is not physically contiguous.
If you are not sure whether the allocation size is too large for
`kmalloc`, it is possible to use :c:func:`kvmalloc` and its
derivatives. It will try to allocate memory with `kmalloc` and if the
allocation fails it will be retried with `vmalloc`. There are
restrictions on which GFP flags can be used with `kvmalloc`; please
see :c:func:`kvmalloc_node` reference documentation. Note that
`kvmalloc` may return memory that is not physically contiguous.
`kmalloc`, it is possible to use kvmalloc() and its derivatives. It will
try to allocate memory with `kmalloc` and if the allocation fails it
will be retried with `vmalloc`. There are restrictions on which GFP
flags can be used with `kvmalloc`; please see kvmalloc_node() reference
documentation. Note that `kvmalloc` may return memory that is not
physically contiguous.
If you need to allocate many identical objects you can use the slab
cache allocator. The cache should be set up with
:c:func:`kmem_cache_create` or :c:func:`kmem_cache_create_usercopy`
before it can be used. The second function should be used if a part of
the cache might be copied to the userspace. After the cache is
created :c:func:`kmem_cache_alloc` and its convenience wrappers can
allocate memory from that cache.
cache allocator. The cache should be set up with kmem_cache_create() or
kmem_cache_create_usercopy() before it can be used. The second function
should be used if a part of the cache might be copied to the userspace.
After the cache is created kmem_cache_alloc() and its convenience
wrappers can allocate memory from that cache.
When the allocated memory is no longer needed it must be freed. You
can use :c:func:`kvfree` for the memory allocated with `kmalloc`,
`vmalloc` and `kvmalloc`. The slab caches should be freed with
:c:func:`kmem_cache_free`. And don't forget to destroy the cache with
:c:func:`kmem_cache_destroy`.
When the allocated memory is no longer needed it must be freed. You can
use kvfree() for the memory allocated with `kmalloc`, `vmalloc` and
`kvmalloc`. The slab caches should be freed with kmem_cache_free(). And
don't forget to destroy the cache with kmem_cache_destroy().

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

@ -11,7 +11,7 @@ User Space Memory Access
.. kernel-doc:: arch/x86/lib/usercopy_32.c
:export:
.. kernel-doc:: mm/util.c
.. kernel-doc:: mm/gup.c
:functions: get_user_pages_fast
.. _mm-api-gfp-flags:

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

@ -98,8 +98,6 @@ Symbols/Function Pointers
%pS versatile_init+0x0/0x110
%ps versatile_init
%pF versatile_init+0x0/0x110
%pf versatile_init
%pSR versatile_init+0x9/0x110
(with __builtin_extract_return_addr() translation)
%pB prev_fn_of_versatile_init+0x88/0x88
@ -109,14 +107,6 @@ The ``S`` and ``s`` specifiers are used for printing a pointer in symbolic
format. They result in the symbol name with (S) or without (s)
offsets. If KALLSYMS are disabled then the symbol address is printed instead.
Note, that the ``F`` and ``f`` specifiers are identical to ``S`` (``s``)
and thus deprecated. We have ``F`` and ``f`` because on ia64, ppc64 and
parisc64 function pointers are indirect and, in fact, are function
descriptors, which require additional dereferencing before we can lookup
the symbol. As of now, ``S`` and ``s`` perform dereferencing on those
platforms (when needed), so ``F`` and ``f`` exist for compatibility
reasons only.
The ``B`` specifier results in the symbol name with offsets and should be
used when printing stack backtraces. The specifier takes into
consideration the effect of compiler optimisations which may occur
@ -147,6 +137,20 @@ equivalent to %lx (or %lu). %px is preferred because it is more uniquely
grep'able. If in the future we need to modify the way the kernel handles
printing pointers we will be better equipped to find the call sites.
Pointer Differences
-------------------
::
%td 2560
%tx a00
For printing the pointer differences, use the %t modifier for ptrdiff_t.
Example::
printk("test: difference between pointers: %td\n", ptr2 - ptr1);
Struct Resources
----------------
@ -440,6 +444,30 @@ Examples::
Passed by reference.
Fwnode handles
--------------
::
%pfw[fP]
For printing information on fwnode handles. The default is to print the full
node name, including the path. The modifiers are functionally equivalent to
%pOF above.
- f - full name of the node, including the path
- P - the name of the node including an address (if there is one)
Examples (ACPI)::
%pfwf \_SB.PCI0.CIO2.port@1.endpoint@0 - Full node name
%pfwP endpoint@0 - Node name
Examples (OF)::
%pfwf /ocp@68000000/i2c@48072000/camera@10/port/endpoint - Full name
%pfwP endpoint - Node name
Time and date (struct rtc_time)
-------------------------------

36
Documentation/core-api/refcount-vs-atomic.rst
View File

@ -35,7 +35,7 @@ atomics & refcounters only provide atomicity and
program order (po) relation (on the same CPU). It guarantees that
each ``atomic_*()`` and ``refcount_*()`` operation is atomic and instructions
are executed in program order on a single CPU.
This is implemented using :c:func:`READ_ONCE`/:c:func:`WRITE_ONCE` and
This is implemented using READ_ONCE()/WRITE_ONCE() and
compare-and-swap primitives.
A strong (full) memory ordering guarantees that all prior loads and
@ -44,7 +44,7 @@ before any po-later instruction is executed on the same CPU.
It also guarantees that all po-earlier stores on the same CPU
and all propagated stores from other CPUs must propagate to all
other CPUs before any po-later instruction is executed on the original
CPU (A-cumulative property). This is implemented using :c:func:`smp_mb`.
CPU (A-cumulative property). This is implemented using smp_mb().
A RELEASE memory ordering guarantees that all prior loads and
stores (all po-earlier instructions) on the same CPU are completed
@ -52,14 +52,14 @@ before the operation. It also guarantees that all po-earlier
stores on the same CPU and all propagated stores from other CPUs
must propagate to all other CPUs before the release operation
(A-cumulative property). This is implemented using
:c:func:`smp_store_release`.
smp_store_release().
An ACQUIRE memory ordering guarantees that all post loads and
stores (all po-later instructions) on the same CPU are
completed after the acquire operation. It also guarantees that all
po-later stores on the same CPU must propagate to all other CPUs
after the acquire operation executes. This is implemented using
:c:func:`smp_acquire__after_ctrl_dep`.
smp_acquire__after_ctrl_dep().
A control dependency (on success) for refcounters guarantees that
if a reference for an object was successfully obtained (reference
@ -78,8 +78,8 @@ case 1) - non-"Read/Modify/Write" (RMW) ops
Function changes:
* :c:func:`atomic_set` --> :c:func:`refcount_set`
* :c:func:`atomic_read` --> :c:func:`refcount_read`
* atomic_set() --> refcount_set()
* atomic_read() --> refcount_read()
Memory ordering guarantee changes:
@ -91,8 +91,8 @@ case 2) - increment-based ops that return no value
Function changes:
* :c:func:`atomic_inc` --> :c:func:`refcount_inc`
* :c:func:`atomic_add` --> :c:func:`refcount_add`
* atomic_inc() --> refcount_inc()
* atomic_add() --> refcount_add()
Memory ordering guarantee changes:
@ -103,7 +103,7 @@ case 3) - decrement-based RMW ops that return no value
Function changes:
* :c:func:`atomic_dec` --> :c:func:`refcount_dec`
* atomic_dec() --> refcount_dec()
Memory ordering guarantee changes:
@ -115,8 +115,8 @@ case 4) - increment-based RMW ops that return a value
Function changes:
* :c:func:`atomic_inc_not_zero` --> :c:func:`refcount_inc_not_zero`
* no atomic counterpart --> :c:func:`refcount_add_not_zero`
* atomic_inc_not_zero() --> refcount_inc_not_zero()
* no atomic counterpart --> refcount_add_not_zero()
Memory ordering guarantees changes:
@ -131,8 +131,8 @@ case 5) - generic dec/sub decrement-based RMW ops that return a value
Function changes:
* :c:func:`atomic_dec_and_test` --> :c:func:`refcount_dec_and_test`
* :c:func:`atomic_sub_and_test` --> :c:func:`refcount_sub_and_test`
* atomic_dec_and_test() --> refcount_dec_and_test()
* atomic_sub_and_test() --> refcount_sub_and_test()
Memory ordering guarantees changes:
@ -144,14 +144,14 @@ case 6) other decrement-based RMW ops that return a value
Function changes:
* no atomic counterpart --> :c:func:`refcount_dec_if_one`
* no atomic counterpart --> refcount_dec_if_one()
* ``atomic_add_unless(&var, -1, 1)`` --> ``refcount_dec_not_one(&var)``
Memory ordering guarantees changes:
* fully ordered --> RELEASE ordering + control dependency
.. note:: :c:func:`atomic_add_unless` only provides full order on success.
.. note:: atomic_add_unless() only provides full order on success.
case 7) - lock-based RMW
@ -159,10 +159,10 @@ case 7) - lock-based RMW
Function changes:
* :c:func:`atomic_dec_and_lock` --> :c:func:`refcount_dec_and_lock`
* :c:func:`atomic_dec_and_mutex_lock` --> :c:func:`refcount_dec_and_mutex_lock`
* atomic_dec_and_lock() --> refcount_dec_and_lock()
* atomic_dec_and_mutex_lock() --> refcount_dec_and_mutex_lock()
Memory ordering guarantees changes:
* fully ordered --> RELEASE ordering + control dependency + hold
:c:func:`spin_lock` on success
spin_lock() on success

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

@ -152,3 +152,6 @@ in-tree modules::
- notice the warning of modpost telling about a missing import
- run `make nsdeps` to add the import to the correct code location
You can also run nsdeps for external module builds. A typical usage is::
$ make -C <path_to_kernel_src> M=$PWD nsdeps

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

@ -218,3 +218,66 @@ 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.
What memory accesses are sanitised by KASAN?
--------------------------------------------
The kernel maps memory in a number of different parts of the address
space. This poses something of a problem for KASAN, which requires
that all addresses accessed by instrumented code have a valid shadow
region.
The range of kernel virtual addresses is large: there is not enough
real memory to support a real shadow region for every address that
could be accessed by the kernel.
By default
~~~~~~~~~~
By default, architectures only map real memory over the shadow region
for the linear mapping (and potentially other small areas). For all
other areas - such as vmalloc and vmemmap space - a single read-only
page is mapped over the shadow area. This read-only shadow page
declares all memory accesses as permitted.
This presents a problem for modules: they do not live in the linear
mapping, but in a dedicated module space. By hooking in to the module
allocator, KASAN can temporarily map real shadow memory to cover
them. This allows detection of invalid accesses to module globals, for
example.
This also creates an incompatibility with ``VMAP_STACK``: if the stack
lives in vmalloc space, it will be shadowed by the read-only page, and
the kernel will fault when trying to set up the shadow data for stack
variables.
CONFIG_KASAN_VMALLOC
~~~~~~~~~~~~~~~~~~~~
With ``CONFIG_KASAN_VMALLOC``, KASAN can cover vmalloc space at the
cost of greater memory usage. Currently this is only supported on x86.
This works by hooking into vmalloc and vmap, and dynamically
allocating real shadow memory to back the mappings.
Most mappings in vmalloc space are small, requiring less than a full
page of shadow space. Allocating a full shadow page per mapping would
therefore be wasteful. Furthermore, to ensure that different mappings
use different shadow pages, mappings would have to be aligned to
``KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE``.
Instead, we share backing space across multiple mappings. We allocate
a backing page when a mapping in vmalloc space uses a particular page
of the shadow region. This page can be shared by other vmalloc
mappings later on.
We hook in to the vmap infrastructure to lazily clean up unused shadow
memory.
To avoid the difficulties around swapping mappings around, we expect
that the part of the shadow region that covers the vmalloc space will
not be covered by the early shadow page, but will be left
unmapped. This will require changes in arch-specific code.
This allows ``VMAP_STACK`` support on x86, and can simplify support of
architectures that do not have a fixed module region.

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

@ -69,7 +69,7 @@ the kernel command line.
Memory may be allocated or freed before kmemleak is initialised and
these actions are stored in an early log buffer. The size of this buffer
is configured via the CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE option.
is configured via the CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE option.
If CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF are enabled, the kmemleak is
disabled by default. Passing ``kmemleak=on`` on the kernel command

5
Documentation/devicetree/bindings/Makefile
View File

@ -12,7 +12,6 @@ $(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 $@ $(real-prereqs)
@ -26,8 +25,12 @@ DT_DOCS = $(shell \
DT_SCHEMA_FILES ?= $(addprefix $(src)/,$(DT_DOCS))
ifeq ($(CHECK_DTBS),)
extra-y += $(patsubst $(src)/%.yaml,%.example.dts, $(DT_SCHEMA_FILES))
extra-y += $(patsubst $(src)/%.yaml,%.example.dt.yaml, $(DT_SCHEMA_FILES))
endif
$(obj)/$(DT_TMP_SCHEMA): $(DT_SCHEMA_FILES) FORCE
$(call if_changed,mk_schema)
extra-y += $(DT_TMP_SCHEMA)

32
Documentation/devicetree/bindings/arm/amlogic/smp-sram.txt
View File

@ -1,32 +0,0 @@
Amlogic Meson8 and Meson8b SRAM for smp bringup:
------------------------------------------------
Amlogic's SMP-capable SoCs use part of the sram for the bringup of the cores.
Once the core gets powered up it executes the code that is residing at a
specific location.
Therefore a reserved section sub-node has to be added to the mmio-sram
declaration.
Required sub-node properties:
- compatible : depending on the SoC this should be one of:
"amlogic,meson8-smp-sram"
"amlogic,meson8b-smp-sram"
The rest of the properties should follow the generic mmio-sram discription
found in ../../misc/sram.txt
Example:
sram: sram@d9000000 {
compatible = "mmio-sram";
reg = <0xd9000000 0x20000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0xd9000000 0x20000>;
smp-sram@1ff80 {
compatible = "amlogic,meson8b-smp-sram";
reg = <0x1ff80 0x8>;
};
};

2
Documentation/devicetree/bindings/arm/arm,scmi.txt
View File

@ -100,7 +100,7 @@ Required sub-node properties:
[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/power/power_domain.txt
[2] Documentation/devicetree/bindings/power/power-domain.yaml
[3] Documentation/devicetree/bindings/thermal/thermal.txt
[4] Documentation/devicetree/bindings/sram/sram.txt
[5] Documentation/devicetree/bindings/reset/reset.txt

2
Documentation/devicetree/bindings/arm/arm,scpi.txt
View File

@ -110,7 +110,7 @@ Required properties:
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/thermal/thermal.txt
[3] Documentation/devicetree/bindings/sram/sram.txt
[4] Documentation/devicetree/bindings/power/power_domain.txt
[4] Documentation/devicetree/bindings/power/power-domain.yaml
Example:

28
Documentation/devicetree/bindings/arm/axentia.txt
View File

@ -1,28 +0,0 @@
Device tree bindings for Axentia ARM devices
============================================
Linea CPU module
----------------
Required root node properties:
compatible = "axentia,linea",
"atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
and following the rules from atmel-at91.txt for a sama5d31 SoC.
Nattis v2 board with Natte v2 power board
-----------------------------------------
Required root node properties:
compatible = "axentia,nattis-2", "axentia,natte-2", "axentia,linea",
"atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
and following the rules from above for the axentia,linea CPU module.
TSE-850 v3 board
----------------
Required root node properties:
compatible = "axentia,tse850v3", "axentia,linea",
"atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
and following the rules from above for the axentia,linea CPU module.

9
Documentation/devicetree/bindings/arm/coresight.txt
View File

@ -87,6 +87,15 @@ its hardware characteristcs.
* port or ports: see "Graph bindings for Coresight" below.
* Optional properties for all components:
* arm,coresight-loses-context-with-cpu : boolean. Indicates that the
hardware will lose register context on CPU power down (e.g. CPUIdle).
An example of where this may be needed are systems which contain a
coresight component and CPU in the same power domain. When the CPU
powers down the coresight component also powers down and loses its
context. This property is currently only used for the ETM 4.x driver.
* Optional properties for ETM/PTMs:
* arm,cp14: must be present if the system accesses ETM/PTM management

16
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
View File

@ -124,7 +124,7 @@ Required properties for Pinctrl sub nodes:
CONFIG settings.
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/power/power_domain.txt
[2] Documentation/devicetree/bindings/power/power-domain.yaml
[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
RTC bindings based on SCU Message Protocol
@ -157,6 +157,15 @@ Required properties:
Optional properties:
- timeout-sec: contains the watchdog timeout in seconds.
SCU key bindings based on SCU Message Protocol
------------------------------------------------------------
Required properties:
- compatible: should be:
"fsl,imx8qxp-sc-key"
followed by "fsl,imx-sc-key";
- linux,keycodes: See Documentation/devicetree/bindings/input/keys.txt
Example (imx8qxp):
-------------
aliases {
@ -220,6 +229,11 @@ firmware {
compatible = "fsl,imx8qxp-sc-rtc";
};
scu_key: scu-key {
compatible = "fsl,imx8qxp-sc-key", "fsl,imx-sc-key";
linux,keycodes = <KEY_POWER>;
};
watchdog {
compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
timeout-sec = <60>;

30
Documentation/devicetree/bindings/arm/omap/omap.txt
View File

@ -43,7 +43,7 @@ SoC Families:
- OMAP2 generic - defaults to OMAP2420
compatible = "ti,omap2"
- OMAP3 generic - defaults to OMAP3430
- OMAP3 generic
compatible = "ti,omap3"
- OMAP4 generic - defaults to OMAP4430
compatible = "ti,omap4"
@ -51,6 +51,8 @@ SoC Families:
compatible = "ti,omap5"
- DRA7 generic - defaults to DRA742
compatible = "ti,dra7"
- AM33x generic
compatible = "ti,am33xx"
- AM43x generic - defaults to AM4372
compatible = "ti,am43"
@ -63,12 +65,14 @@ SoCs:
- OMAP3430
compatible = "ti,omap3430", "ti,omap3"
legacy: "ti,omap34xx" - please do not use any more
- AM3517
compatible = "ti,am3517", "ti,omap3"
- OMAP3630
compatible = "ti,omap36xx", "ti,omap3"
- AM33xx
compatible = "ti,am33xx", "ti,omap3"
compatible = "ti,omap3630", "ti,omap3"
legacy: "ti,omap36xx" - please do not use any more
- AM335x
compatible = "ti,am33xx"
- OMAP4430
compatible = "ti,omap4430", "ti,omap4"
@ -110,19 +114,19 @@ SoCs:
- AM4372
compatible = "ti,am4372", "ti,am43"
Boards:
Boards (incomplete list of examples):
- OMAP3 BeagleBoard : Low cost community board
compatible = "ti,omap3-beagle", "ti,omap3"
compatible = "ti,omap3-beagle", "ti,omap3430", "ti,omap3"
- OMAP3 Tobi with Overo : Commercial expansion board with daughter board
compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3"
compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3430", "ti,omap3"
- OMAP4 SDP : Software Development Board
compatible = "ti,omap4-sdp", "ti,omap4430"
compatible = "ti,omap4-sdp", "ti,omap4430", "ti,omap4"
- OMAP4 PandaBoard : Low cost community board
compatible = "ti,omap4-panda", "ti,omap4430"
compatible = "ti,omap4-panda", "ti,omap4430", "ti,omap4"
- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board
compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
@ -134,16 +138,16 @@ Boards:
compatible = "variscite,var-dvk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4";
- OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
compatible = "ti,omap3-evm", "ti,omap3"
compatible = "ti,omap3-evm", "ti,omap3630", "ti,omap3"
- AM335X EVM : Software Development Board for AM335x
compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3"
compatible = "ti,am335x-evm", "ti,am33xx"
- AM335X Bone : Low cost community board
compatible = "ti,am335x-bone", "ti,am33xx", "ti,omap3"
compatible = "ti,am335x-bone", "ti,am33xx"
- AM3359 ICEv2 : Low cost Industrial Communication Engine EVM.
compatible = "ti,am3359-icev2", "ti,am33xx", "ti,omap3"
compatible = "ti,am3359-icev2", "ti,am33xx"
- AM335X OrionLXm : Substation Automation Platform
compatible = "novatech,am335x-lxm", "ti,am33xx"

12
Documentation/devicetree/bindings/arm/samsung/exynos-chipid.txt
View File

@ -1,12 +0,0 @@
SAMSUNG Exynos SoCs Chipid driver.
Required properties:
- compatible : Should at least contain "samsung,exynos4210-chipid".
- reg: offset and length of the register set
Example:
chipid@10000000 {
compatible = "samsung,exynos4210-chipid";
reg = <0x10000000 0x100>;
};

39
Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml Normal file
View File

@ -0,0 +1,39 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/samsung/exynos-chipid.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos SoC series Chipid driver
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
properties:
compatible:
items:
- const: samsung,exynos4210-chipid
reg:
maxItems: 1
samsung,asv-bin:
description:
Adaptive Supply Voltage bin selection. This can be used
to determine the ASV bin of an SoC if respective information
is missing in the CHIPID registers or in the OTP memory.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 0, 1, 2, 3 ]
required:
- compatible
- reg
examples:
- |
chipid@10000000 {
compatible = "samsung,exynos4210-chipid";
reg = <0x10000000 0x100>;
samsung,asv-bin = <2>;
};

72
Documentation/devicetree/bindings/arm/samsung/pmu.txt
View File

@ -1,72 +0,0 @@
SAMSUNG Exynos SoC series PMU Registers
Properties:
- compatible : should contain two values. First value must be one from following list:
- "samsung,exynos3250-pmu" - for Exynos3250 SoC,
- "samsung,exynos4210-pmu" - for Exynos4210 SoC,
- "samsung,exynos4412-pmu" - for Exynos4412 SoC,
- "samsung,exynos5250-pmu" - for Exynos5250 SoC,
- "samsung,exynos5260-pmu" - for Exynos5260 SoC.
- "samsung,exynos5410-pmu" - for Exynos5410 SoC,
- "samsung,exynos5420-pmu" - for Exynos5420 SoC.
- "samsung,exynos5433-pmu" - for Exynos5433 SoC.
- "samsung,exynos7-pmu" - for Exynos7 SoC.
second value must be always "syscon".
- reg : offset and length of the register set.
- #clock-cells : must be <1>, since PMU requires once cell as clock specifier.
The single specifier cell is used as index to list of clocks
provided by PMU, which is currently:
0 : SoC clock output (CLKOUT pin)
- clock-names : list of clock names for particular CLKOUT mux inputs in
following format:
"clkoutN", where N is a decimal number corresponding to
CLKOUT mux control bits value for given input, e.g.
"clkout0", "clkout7", "clkout15".
- clocks : list of phandles and specifiers to all input clocks listed in
clock-names property.
Optional properties:
Some PMUs are capable of behaving as an interrupt controller (mostly
to wake up a suspended PMU). In which case, they can have the
following properties:
- interrupt-controller: indicate that said PMU is an interrupt controller
- #interrupt-cells: must be identical to the that of the parent interrupt
controller.
Optional nodes:
- nodes defining the restart and poweroff syscon children
Example :
pmu_system_controller: system-controller@10040000 {
compatible = "samsung,exynos5250-pmu", "syscon";
reg = <0x10040000 0x5000>;
interrupt-controller;
#interrupt-cells = <3>;
interrupt-parent = <&gic>;
#clock-cells = <1>;
clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
"clkout4", "clkout8", "clkout9";
clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>,
<&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>,
<&clock CLK_OUT_CPU>, <&clock CLK_XXTI>,
<&clock CLK_XUSBXTI>;
};
Example of clock consumer :
usb3503: usb3503@8 {
/* ... */
clock-names = "refclk";
clocks = <&pmu_system_controller 0>;
/* ... */
};

105
Documentation/devicetree/bindings/arm/samsung/pmu.yaml Normal file
View File

@ -0,0 +1,105 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/samsung/pmu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos SoC series Power Management Unit (PMU)
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
# Custom select to avoid matching all nodes with 'syscon'
select:
properties:
compatible:
contains:
enum:
- samsung,exynos3250-pmu
- samsung,exynos4210-pmu
- samsung,exynos4412-pmu
- samsung,exynos5250-pmu
- samsung,exynos5260-pmu
- samsung,exynos5410-pmu
- samsung,exynos5420-pmu
- samsung,exynos5433-pmu
- samsung,exynos7-pmu
required:
- compatible
properties:
compatible:
items:
- enum:
- samsung,exynos3250-pmu
- samsung,exynos4210-pmu
- samsung,exynos4412-pmu
- samsung,exynos5250-pmu
- samsung,exynos5260-pmu
- samsung,exynos5410-pmu
- samsung,exynos5420-pmu
- samsung,exynos5433-pmu
- samsung,exynos7-pmu
- const: syscon
reg:
maxItems: 1
'#clock-cells':
const: 1
clock-names:
description:
List of clock names for particular CLKOUT mux inputs
minItems: 1
maxItems: 32
items:
pattern: '^clkout([0-9]|[12][0-9]|3[0-1])$'
clocks:
minItems: 1
maxItems: 32
interrupt-controller:
description:
Some PMUs are capable of behaving as an interrupt controller (mostly
to wake up a suspended PMU).
'#interrupt-cells':
description:
Must be identical to the that of the parent interrupt controller.
const: 3
syscon-poweroff:
$ref: "../../power/reset/syscon-poweroff.yaml#"
type: object
description:
Node for power off method
syscon-reboot:
$ref: "../../power/reset/syscon-reboot.yaml#"
type: object
description:
Node for reboot method
required:
- compatible
- reg
- '#clock-cells'
- clock-names
- clocks
examples:
- |
#include <dt-bindings/clock/exynos5250.h>
pmu_system_controller: system-controller@10040000 {
compatible = "samsung,exynos5250-pmu", "syscon";
reg = <0x10040000 0x5000>;
interrupt-controller;
#interrupt-cells = <3>;
interrupt-parent = <&gic>;
#clock-cells = <1>;
clock-names = "clkout16";
clocks = <&clock CLK_FIN_PLL>;
};

83
Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
View File

@ -1,83 +0,0 @@
* Samsung's Exynos and S5P SoC based boards
Required root node properties:
- compatible = should be one or more of the following.
- "samsung,aries" - for S5PV210-based Samsung Aries board.
- "samsung,fascinate4g" - for S5PV210-based Samsung Galaxy S Fascinate 4G (SGH-T959P) board.
- "samsung,galaxys" - for S5PV210-based Samsung Galaxy S (i9000) board.
- "samsung,artik5" - for Exynos3250-based Samsung ARTIK5 module.
- "samsung,artik5-eval" - for Exynos3250-based Samsung ARTIK5 eval board.
- "samsung,monk" - for Exynos3250-based Samsung Simband board.
- "samsung,rinato" - for Exynos3250-based Samsung Gear2 board.
- "samsung,smdkv310" - for Exynos4210-based Samsung SMDKV310 eval board.
- "samsung,trats" - for Exynos4210-based Tizen Reference board.
- "samsung,universal_c210" - for Exynos4210-based Samsung board.
- "samsung,i9300" - for Exynos4412-based Samsung GT-I9300 board.
- "samsung,i9305" - for Exynos4412-based Samsung GT-I9305 board.
- "samsung,midas" - for Exynos4412-based Samsung Midas board.
- "samsung,smdk4412", - for Exynos4412-based Samsung SMDK4412 eval board.
- "samsung,n710x" - for Exynos4412-based Samsung GT-N7100/GT-N7105 board.
- "samsung,trats2" - for Exynos4412-based Tizen Reference board.
- "samsung,smdk5250" - for Exynos5250-based Samsung SMDK5250 eval board.
- "samsung,xyref5260" - for Exynos5260-based Samsung board.
- "samsung,smdk5410" - for Exynos5410-based Samsung SMDK5410 eval board.
- "samsung,smdk5420" - for Exynos5420-based Samsung SMDK5420 eval board.
- "samsung,tm2" - for Exynos5433-based Samsung TM2 board.
- "samsung,tm2e" - for Exynos5433-based Samsung TM2E board.
* Other companies Exynos SoC based
* FriendlyARM
- "friendlyarm,tiny4412" - for Exynos4412-based FriendlyARM
TINY4412 board.
* TOPEET
- "topeet,itop4412-elite" - for Exynos4412-based TOPEET
Elite base board.
* Google
- "google,pi" - for Exynos5800-based Google Peach Pi
Rev 10+ board,
also: "google,pi-rev16", "google,pi-rev15", "google,pi-rev14",
"google,pi-rev13", "google,pi-rev12", "google,pi-rev11",
"google,pi-rev10", "google,peach".
- "google,pit" - for Exynos5420-based Google Peach Pit
Rev 6+ (Exynos5420),
also: "google,pit-rev16", "google,pit-rev15", "google,pit-rev14",
"google,pit-rev13", "google,pit-rev12", "google,pit-rev11",
"google,pit-rev10", "google,pit-rev9", "google,pit-rev8",
"google,pit-rev7", "google,pit-rev6", "google,peach".
- "google,snow-rev4" - for Exynos5250-based Google Snow board,
also: "google,snow"
- "google,snow-rev5" - for Exynos5250-based Google Snow
Rev 5+ board.
- "google,spring" - for Exynos5250-based Google Spring board.
* Hardkernel
- "hardkernel,odroid-u3" - for Exynos4412-based Hardkernel Odroid U3.
- "hardkernel,odroid-x" - for Exynos4412-based Hardkernel Odroid X.
- "hardkernel,odroid-x2" - for Exynos4412-based Hardkernel Odroid X2.
- "hardkernel,odroid-xu" - for Exynos5410-based Hardkernel Odroid XU.
- "hardkernel,odroid-xu3" - for Exynos5422-based Hardkernel Odroid XU3.
- "hardkernel,odroid-xu3-lite" - for Exynos5422-based Hardkernel
Odroid XU3 Lite board.
- "hardkernel,odroid-xu4" - for Exynos5422-based Hardkernel Odroid XU4.
- "hardkernel,odroid-hc1" - for Exynos5422-based Hardkernel Odroid HC1.
* Insignal
- "insignal,arndale" - for Exynos5250-based Insignal Arndale board.
- "insignal,arndale-octa" - for Exynos5420-based Insignal Arndale
Octa board.
- "insignal,origen" - for Exynos4210-based Insignal Origen board.
- "insignal,origen4412" - for Exynos4412-based Insignal Origen board.
Optional nodes:
- firmware node, specifying presence and type of secure firmware:
- compatible: only "samsung,secure-firmware" is currently supported
- reg: address of non-secure SYSRAM used for communication with firmware
firmware@203f000 {
compatible = "samsung,secure-firmware";
reg = <0x0203F000 0x1000>;
};

181
Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml Normal file
View File

@ -0,0 +1,181 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/samsung/samsung-boards.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos and S5P SoC based boards
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: S5PV210 based boards
items:
- enum:
- aesop,torbreck # aESOP Torbreck based on S5PV210
- samsung,aquila # Samsung Aquila based on S5PC110
- samsung,goni # Samsung Goni based on S5PC110
- yic,smdkc110 # YIC System SMDKC110 based on S5PC110
- yic,smdkv210 # YIC System SMDKV210 based on S5PV210
- const: samsung,s5pv210
- description: S5PV210 based Aries boards
items:
- enum:
- samsung,fascinate4g # Samsung Galaxy S Fascinate 4G (SGH-T959P)
- samsung,galaxys # Samsung Galaxy S (i9000)
- const: samsung,aries
- const: samsung,s5pv210
- description: Exynos3250 based boards
items:
- enum:
- samsung,monk # Samsung Simband
- samsung,rinato # Samsung Gear2
- const: samsung,exynos3250
- const: samsung,exynos3
- description: Samsung ARTIK5 boards
items:
- enum:
- samsung,artik5-eval # Samsung ARTIK5 eval board
- const: samsung,artik5 # Samsung ARTIK5 module
- const: samsung,exynos3250
- const: samsung,exynos3
- description: Exynos4210 based boards
items:
- enum:
- insignal,origen # Insignal Origen
- samsung,smdkv310 # Samsung SMDKV310 eval
- samsung,trats # Samsung Tizen Reference
- samsung,universal_c210 # Samsung C210
- const: samsung,exynos4210
- const: samsung,exynos4
- description: Exynos4412 based boards
items:
- enum:
- friendlyarm,tiny4412 # FriendlyARM TINY4412
- hardkernel,odroid-u3 # Hardkernel Odroid U3
- hardkernel,odroid-x # Hardkernel Odroid X
- hardkernel,odroid-x2 # Hardkernel Odroid X2
- insignal,origen4412 # Insignal Origen
- samsung,smdk4412 # Samsung SMDK4412 eval
- topeet,itop4412-elite # TOPEET Elite base
- const: samsung,exynos4412
- const: samsung,exynos4
- description: Samsung Midas family boards
items:
- enum:
- samsung,i9300 # Samsung GT-I9300
- samsung,i9305 # Samsung GT-I9305
- samsung,n710x # Samsung GT-N7100/GT-N7105
- samsung,trats2 # Samsung Tizen Reference
- const: samsung,midas
- const: samsung,exynos4412
- const: samsung,exynos4
- description: Exynos5250 based boards
items:
- enum:
- google,snow-rev5 # Google Snow Rev 5+
- google,spring # Google Spring
- insignal,arndale # Insignal Arndale
- samsung,smdk5250 # Samsung SMDK5250 eval
- const: samsung,exynos5250
- const: samsung,exynos5
- description: Google Snow Boards (Rev 4+)
items:
- const: google,snow-rev4
- const: google,snow
- const: samsung,exynos5250
- const: samsung,exynos5
- description: Exynos5260 based boards
items:
- enum:
- samsung,xyref5260 # Samsung Xyref5260 eval
- const: samsung,exynos5260
- const: samsung,exynos5
- description: Exynos5410 based boards
items:
- enum:
- hardkernel,odroid-xu # Hardkernel Odroid XU
- samsung,smdk5410 # Samsung SMDK5410 eval
- const: samsung,exynos5410
- const: samsung,exynos5
- description: Exynos5420 based boards
items:
- enum:
- insignal,arndale-octa # Insignal Arndale Octa
- samsung,smdk5420 # Samsung SMDK5420 eval
- const: samsung,exynos5420
- const: samsung,exynos5
- description: Google Peach Pit Boards (Rev 6+)
items:
- const: google,pit-rev16
- const: google,pit-rev15
- const: google,pit-rev14
- const: google,pit-rev13
- const: google,pit-rev12
- const: google,pit-rev11
- const: google,pit-rev10
- const: google,pit-rev9
- const: google,pit-rev8
- const: google,pit-rev7
- const: google,pit-rev6
- const: google,pit
- const: google,peach
- const: samsung,exynos5420
- const: samsung,exynos5
- description: Exynos5800 based boards
items:
- enum:
- hardkernel,odroid-xu3 # Hardkernel Odroid XU3
- hardkernel,odroid-xu3-lite # Hardkernel Odroid XU3 Lite
- hardkernel,odroid-xu4 # Hardkernel Odroid XU4
- hardkernel,odroid-hc1 # Hardkernel Odroid HC1
- const: samsung,exynos5800
- const: samsung,exynos5
- description: Google Peach Pi Boards (Rev 10+)
items:
- const: google,pi-rev16
- const: google,pi-rev15
- const: google,pi-rev14
- const: google,pi-rev13
- const: google,pi-rev12
- const: google,pi-rev11
- const: google,pi-rev10
- const: google,pi
- const: google,peach
- const: samsung,exynos5800
- const: samsung,exynos5
- description: Exynos5433 based boards
items:
- enum:
- samsung,tm2 # Samsung TM2
- samsung,tm2e # Samsung TM2E
- const: samsung,exynos5433
- description: Exynos7 based boards
items:
- enum:
- samsung,exynos7-espresso # Samsung Exynos7 Espresso
- const: samsung,exynos7
required:
- compatible

31
Documentation/devicetree/bindings/arm/samsung/samsung-secure-firmware.yaml Normal file
View File

@ -0,0 +1,31 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/samsung/samsung-secure-firmware.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos Secure Firmware
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
properties:
compatible:
items:
- const: samsung,secure-firmware
reg:
description:
Address of non-secure SYSRAM used for communication with firmware.
maxItems: 1
required:
- compatible
- reg
examples:
- |
firmware@203f000 {
compatible = "samsung,secure-firmware";
reg = <0x0203f000 0x1000>;
};

19
Documentation/devicetree/bindings/arm/samsung/sysreg.txt
View File

@ -1,19 +0,0 @@
SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
Properties:
- compatible : should contain two values. First value must be one from following list:
- "samsung,exynos4-sysreg" - for Exynos4 based SoCs,
- "samsung,exynos5-sysreg" - for Exynos5 based SoCs.
second value must be always "syscon".
- reg : offset and length of the register set.
Example:
syscon@10010000 {
compatible = "samsung,exynos4-sysreg", "syscon";
reg = <0x10010000 0x400>;
};
syscon@10050000 {
compatible = "samsung,exynos5-sysreg", "syscon";
reg = <0x10050000 0x5000>;
};

45
Documentation/devicetree/bindings/arm/samsung/sysreg.yaml Normal file
View File

@ -0,0 +1,45 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/samsung/sysreg.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung S5P/Exynos SoC series System Registers (SYSREG)
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
# Custom select to avoid matching all nodes with 'syscon'
select:
properties:
compatible:
contains:
enum:
- samsung,exynos4-sysreg
- samsung,exynos5-sysreg
required:
- compatible
properties:
compatible:
allOf:
- items:
- enum:
- samsung,exynos4-sysreg
- samsung,exynos5-sysreg
- const: syscon
reg:
maxItems: 1
examples:
- |
syscon@10010000 {
compatible = "samsung,exynos4-sysreg", "syscon";
reg = <0x10010000 0x400>;
};
syscon@10050000 {
compatible = "samsung,exynos5-sysreg", "syscon";
reg = <0x10050000 0x5000>;
};

14
Documentation/devicetree/bindings/arm/sprd.txt
View File

@ -1,14 +0,0 @@
Spreadtrum SoC Platforms Device Tree Bindings
----------------------------------------------------
SC9836 openphone Board
Required root node properties:
- compatible = "sprd,sc9836-openphone", "sprd,sc9836";
SC9860 SoC
Required root node properties:
- compatible = "sprd,sc9860"
SP9860G 3GFHD Board
Required root node properties:
- compatible = "sprd,sp9860g-1h10", "sprd,sc9860";

33
Documentation/devicetree/bindings/arm/sprd.yaml Normal file
View File

@ -0,0 +1,33 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright 2019 Unisoc Inc.
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/sprd.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Unisoc platforms device tree bindings
maintainers:
- Orson Zhai <orsonzhai@gmail.com>
- Baolin Wang <baolin.wang7@gmail.com>
- Chunyan Zhang <zhang.lyra@gmail.com>
properties:
$nodename:
const: '/'
compatible:
oneOf:
- items:
- enum:
- sprd,sc9836-openphone
- const: sprd,sc9836
- items:
- enum:
- sprd,sp9860g-1h10
- const: sprd,sc9860
- items:
- enum:
- sprd,sp9863a-1h10
- const: sprd,sc9863a
...

27
Documentation/devicetree/bindings/arm/stm32/stm32.yaml
View File

@ -13,19 +13,38 @@ properties:
compatible:
oneOf:
- items:
- enum:
- st,stm32f429i-disco
- st,stm32429i-eval
- const: st,stm32f429
- items:
- enum:
- st,stm32f469i-disco
- const: st,stm32f469
- items:
- enum:
- st,stm32f746-disco
- st,stm32746g-eval
- const: st,stm32f746
- items:
- enum:
- st,stm32f769-disco
- const: st,stm32f769
- items:
- enum:
- st,stm32h743i-disco
- st,stm32h743i-eval
- const: st,stm32h743
- items:
- enum:
- arrow,stm32mp157a-avenger96 # Avenger96
- st,stm32mp157c-ed1
- st,stm32mp157a-dk1
- st,stm32mp157c-dk2
- const: st,stm32mp157
- items:
- const: st,stm32mp157c-ev1
- const: st,stm32mp157c-ed1
- const: st,stm32mp157
...

44
Documentation/devicetree/bindings/arm/sunxi/smp-sram.txt
View File

@ -1,44 +0,0 @@
Allwinner SRAM for smp bringup:
------------------------------------------------
Allwinner's A80 SoC uses part of the secure sram for hotplugging of the
primary core (cpu0). Once the core gets powered up it checks if a magic
value is set at a specific location. If it is then the BROM will jump
to the software entry address, instead of executing a standard boot.
Therefore a reserved section sub-node has to be added to the mmio-sram
declaration.
Note that this is separate from the Allwinner SRAM controller found in
../../sram/sunxi-sram.txt. This SRAM is secure only and not mappable to
any device.
Also there are no "secure-only" properties. The implementation should
check if this SRAM is usable first.
Required sub-node properties:
- compatible : depending on the SoC this should be one of:
"allwinner,sun9i-a80-smp-sram"
The rest of the properties should follow the generic mmio-sram discription
found in ../../misc/sram.txt
Example:
sram_b: sram@20000 {
/* 256 KiB secure SRAM at 0x20000 */
compatible = "mmio-sram";
reg = <0x00020000 0x40000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x00020000 0x40000>;
smp-sram@1000 {
/*
* This is checked by BROM to determine if
* cpu0 should jump to SMP entry vector
*/
compatible = "allwinner,sun9i-a80-smp-sram";
reg = <0x1000 0x8>;
};
};

7
Documentation/devicetree/bindings/ata/sata_rcar.txt
View File

@ -2,6 +2,7 @@
Required properties:
- compatible : should contain one or more of the following:
- "renesas,sata-r8a774b1" for RZ/G2N
- "renesas,sata-r8a7779" for R-Car H1
- "renesas,sata-r8a7790-es1" for R-Car H2 ES1
- "renesas,sata-r8a7790" for R-Car H2 other than ES1
@ -9,8 +10,10 @@ Required properties:
- "renesas,sata-r8a7793" for R-Car M2-N
- "renesas,sata-r8a7795" for R-Car H3
- "renesas,sata-r8a77965" for R-Car M3-N
- "renesas,rcar-gen2-sata" for a generic R-Car Gen2 compatible device
- "renesas,rcar-gen3-sata" for a generic R-Car Gen3 compatible device
- "renesas,rcar-gen2-sata" for a generic R-Car Gen2
compatible device
- "renesas,rcar-gen3-sata" for a generic R-Car Gen3 or
RZ/G2 compatible device
- "renesas,rcar-sata" is deprecated
When compatible with the generic version nodes

30
Documentation/devicetree/bindings/board/fsl-board.txt
View File

@ -47,36 +47,6 @@ Example (LS2080A-RDB):
reg = <0x3 0 0x10000>;
};
* Freescale BCSR GPIO banks
Some BCSR registers act as simple GPIO controllers, each such
register can be represented by the gpio-controller node.
Required properities:
- compatible : Should be "fsl,<board>-bcsr-gpio".
- reg : Should contain the address and the length of the GPIO bank
register.
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
- gpio-controller : Marks the port as GPIO controller.
Example:
bcsr@1,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8360mds-bcsr";
reg = <1 0 0x8000>;
ranges = <0 1 0 0x8000>;
bcsr13: gpio-controller@d {
#gpio-cells = <2>;
compatible = "fsl,mpc8360mds-bcsr-gpio";
reg = <0xd 1>;
gpio-controller;
};
};
* Freescale on-board FPGA connected on I2C bus
Some Freescale boards like BSC9132QDS have on board FPGA connected on

46
Documentation/devicetree/bindings/bus/renesas,bsc.txt
View File

@ -1,46 +0,0 @@
Renesas Bus State Controller (BSC)
==================================
The Renesas Bus State Controller (BSC, sometimes called "LBSC within Bus
Bridge", or "External Bus Interface") can be found in several Renesas ARM SoCs.
It provides an external bus for connecting multiple external devices to the
SoC, driving several chip select lines, for e.g. NOR FLASH, Ethernet and USB.
While the BSC is a fairly simple memory-mapped bus, it may be part of a PM
domain, and may have a gateable functional clock.
Before a device connected to the BSC can be accessed, the PM domain
containing the BSC must be powered on, and the functional clock
driving the BSC must be enabled.
The bindings for the BSC extend the bindings for "simple-pm-bus".
Required properties
- compatible: Must contain an SoC-specific value, and "renesas,bsc" and
"simple-pm-bus" as fallbacks.
SoC-specific values can be:
"renesas,bsc-r8a73a4" for R-Mobile APE6 (r8a73a4)
"renesas,bsc-sh73a0" for SH-Mobile AG5 (sh73a0)
- #address-cells, #size-cells, ranges: Must describe the mapping between
parent address and child address spaces.
- reg: Must contain the base address and length to access the bus controller.
Optional properties:
- interrupts: Must contain a reference to the BSC interrupt, if available.
- clocks: Must contain a reference to the functional clock, if available.
- power-domains: Must contain a reference to the PM domain, if available.
Example:
bsc: bus@fec10000 {
compatible = "renesas,bsc-sh73a0", "renesas,bsc",
"simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0x20000000>;
reg = <0xfec10000 0x400>;
interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&zb_clk>;
power-domains = <&pd_a4s>;
};

60
Documentation/devicetree/bindings/bus/renesas,bsc.yaml Normal file
View File

@ -0,0 +1,60 @@
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/renesas,bsc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas Bus State Controller (BSC)
maintainers:
- Geert Uytterhoeven <geert+renesas@glider.be>
description: |
The Renesas Bus State Controller (BSC, sometimes called "LBSC within Bus
Bridge", or "External Bus Interface") can be found in several Renesas ARM
SoCs. It provides an external bus for connecting multiple external
devices to the SoC, driving several chip select lines, for e.g. NOR
FLASH, Ethernet and USB.
While the BSC is a fairly simple memory-mapped bus, it may be part of a
PM domain, and may have a gateable functional clock. Before a device
connected to the BSC can be accessed, the PM domain containing the BSC
must be powered on, and the functional clock driving the BSC must be
enabled.
The bindings for the BSC extend the bindings for "simple-pm-bus".
allOf:
- $ref: simple-pm-bus.yaml#
properties:
compatible:
items:
- enum:
- renesas,bsc-r8a73a4 # R-Mobile APE6 (r8a73a4)
- renesas,bsc-sh73a0 # SH-Mobile AG5 (sh73a0)
- const: renesas,bsc
- {} # simple-pm-bus, but not listed here to avoid false select
reg:
maxItems: 1
interrupts:
maxItems: 1
required:
- reg
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
bsc: bus@fec10000 {
compatible = "renesas,bsc-sh73a0", "renesas,bsc", "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0x20000000>;
reg = <0xfec10000 0x400>;
interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&zb_clk>;
power-domains = <&pd_a4s>;
};

44
Documentation/devicetree/bindings/bus/simple-pm-bus.txt
View File

@ -1,44 +0,0 @@
Simple Power-Managed Bus
========================
A Simple Power-Managed Bus is a transparent bus that doesn't need a real
driver, as it's typically initialized by the boot loader.
However, its bus controller is part of a PM domain, or under the control of a
functional clock. Hence, the bus controller's PM domain and/or clock must be
enabled for child devices connected to the bus (either on-SoC or externally)
to function.
While "simple-pm-bus" follows the "simple-bus" set of properties, as specified
in the Devicetree Specification, it is not an extension of "simple-bus".
Required properties:
- compatible: Must contain at least "simple-pm-bus".
Must not contain "simple-bus".
It's recommended to let this be preceded by one or more
vendor-specific compatible values.
- #address-cells, #size-cells, ranges: Must describe the mapping between
parent address and child address spaces.
Optional platform-specific properties for clock or PM domain control (at least
one of them is required):
- clocks: Must contain a reference to the functional clock(s),
- power-domains: Must contain a reference to the PM domain.
Please refer to the binding documentation for the clock and/or PM domain
providers for more details.
Example:
bsc: bus@fec10000 {
compatible = "renesas,bsc-sh73a0", "renesas,bsc",
"simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0x20000000>;
reg = <0xfec10000 0x400>;
interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&zb_clk>;
power-domains = <&pd_a4s>;
};

75
Documentation/devicetree/bindings/bus/simple-pm-bus.yaml Normal file
View File

@ -0,0 +1,75 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/simple-pm-bus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Simple Power-Managed Bus
maintainers:
- Geert Uytterhoeven <geert+renesas@glider.be>
description: |
A Simple Power-Managed Bus is a transparent bus that doesn't need a real
driver, as it's typically initialized by the boot loader.
However, its bus controller is part of a PM domain, or under the control
of a functional clock. Hence, the bus controller's PM domain and/or
clock must be enabled for child devices connected to the bus (either
on-SoC or externally) to function.
While "simple-pm-bus" follows the "simple-bus" set of properties, as
specified in the Devicetree Specification, it is not an extension of
"simple-bus".
properties:
$nodename:
pattern: "^bus(@[0-9a-f]+)?$"
compatible:
contains:
const: simple-pm-bus
description:
Shall contain "simple-pm-bus" in addition to a optional bus-specific
compatible strings defined in individual pm-bus bindings.
'#address-cells':
enum: [ 1, 2 ]
'#size-cells':
enum: [ 1, 2 ]
ranges: true
clocks: true
# Functional clocks
# Required if power-domains is absent, optional otherwise
power-domains:
# Required if clocks is absent, optional otherwise
minItems: 1
required:
- compatible
- '#address-cells'
- '#size-cells'
- ranges
anyOf:
- required:
- clocks
- required:
- power-domains
examples:
- |
#include <dt-bindings/clock/qcom,gcc-msm8996.h>
#include <dt-bindings/interrupt-controller/irq.h>
bus {
power-domains = <&gcc AGGRE0_NOC_GDSC>;
compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
};

3
Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.txt
View File

@ -7,7 +7,8 @@ devices.
Required Properties:
- compatible : should be "amlogic,axg-audio-clkc" for the A113X and A113D,
"amlogic,g12a-audio-clkc" for G12A.
"amlogic,g12a-audio-clkc" for G12A,
"amlogic,sm1-audio-clkc" for S905X3.
- reg : physical base address of the clock controller and length of
memory mapped region.
- clocks : a list of phandle + clock-specifier pairs for the clocks listed

5
Documentation/devicetree/bindings/clock/armada3700-periph-clock.txt
View File

@ -9,7 +9,7 @@ bridge.
The peripheral clock consumer should specify the desired clock by
having the clock ID in its "clocks" phandle cell.
The following is a list of provided IDs for Armada 370 North bridge clocks:
The following is a list of provided IDs for Armada 3700 North bridge clocks:
ID Clock name Description
-----------------------------------
0 mmc MMC controller
@ -30,7 +30,7 @@ ID Clock name Description
15 eip97 EIP 97
16 cpu CPU
The following is a list of provided IDs for Armada 370 South bridge clocks:
The following is a list of provided IDs for Armada 3700 South bridge clocks:
ID Clock name Description
-----------------------------------
0 gbe-50 50 MHz parent clock for Gigabit Ethernet
@ -46,6 +46,7 @@ ID Clock name Description
10 sdio SDIO
11 usb32-sub2-sys USB 2 clock
12 usb32-ss-sys USB 3 clock
13 pcie PCIe controller
Required properties:

76
Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml Normal file
View File

@ -0,0 +1,76 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bindings/clock/bitmain,bm1880-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Bitmain BM1880 Clock Controller
maintainers:
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
description: |
The Bitmain BM1880 clock controller generates and supplies clock to
various peripherals within the SoC.
This binding uses common clock bindings
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
properties:
compatible:
const: bitmain,bm1880-clk
reg:
items:
- description: pll registers
- description: system registers
reg-names:
items:
- const: pll
- const: sys
clocks:
maxItems: 1
clock-names:
const: osc
'#clock-cells':
const: 1
required:
- compatible
- reg
- reg-names
- clocks
- clock-names
- '#clock-cells'
additionalProperties: false
examples:
# Clock controller node:
- |
clk: clock-controller@e8 {
compatible = "bitmain,bm1880-clk";
reg = <0xe8 0x0c>, <0x800 0xb0>;
reg-names = "pll", "sys";
clocks = <&osc>;
clock-names = "osc";
#clock-cells = <1>;
};
# Example UART controller node that consumes clock generated by the clock controller:
- |
uart0: serial@58018000 {
compatible = "snps,dw-apb-uart";
reg = <0x0 0x58018000 0x0 0x2000>;
clocks = <&clk 45>, <&clk 46>;
clock-names = "baudclk", "apb_pclk";
interrupts = <0 9 4>;
reg-shift = <2>;
reg-io-width = <4>;
};
...

1
Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
View File

@ -82,7 +82,6 @@ pcc2: pcc2@403f0000 {
<&scg1 IMX7ULP_CLK_APLL_PFD0>,
<&scg1 IMX7ULP_CLK_UPLL>,
<&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>,
<&scg1 IMX7ULP_CLK_MIPI_PLL>,
<&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>,
<&scg1 IMX7ULP_CLK_ROSC>,
<&scg1 IMX7ULP_CLK_SPLL_BUS_CLK>;

1
Documentation/devicetree/bindings/clock/ingenic,cgu.txt
View File

@ -11,6 +11,7 @@ Required properties:
* ingenic,jz4725b-cgu
* ingenic,jz4770-cgu
* ingenic,jz4780-cgu
* ingenic,x1000-cgu
- reg : The address & length of the CGU registers.
- clocks : List of phandle & clock specifiers for clocks external to the CGU.
Two such external clocks should be specified - first the external crystal

94
Documentation/devicetree/bindings/clock/qcom,gcc.txt
View File

@ -1,94 +0,0 @@
Qualcomm Global Clock & Reset Controller Binding
------------------------------------------------
Required properties :
- compatible : shall contain only one of the following:
"qcom,gcc-apq8064"
"qcom,gcc-apq8084"
"qcom,gcc-ipq8064"
"qcom,gcc-ipq4019"
"qcom,gcc-ipq8074"
"qcom,gcc-msm8660"
"qcom,gcc-msm8916"
"qcom,gcc-msm8960"
"qcom,gcc-msm8974"
"qcom,gcc-msm8974pro"
"qcom,gcc-msm8974pro-ac"
"qcom,gcc-msm8994"
"qcom,gcc-msm8996"
"qcom,gcc-msm8998"
"qcom,gcc-mdm9615"
"qcom,gcc-qcs404"
"qcom,gcc-sdm630"
"qcom,gcc-sdm660"
"qcom,gcc-sdm845"
"qcom,gcc-sm8150"
- reg : shall contain base register location and length
- #clock-cells : shall contain 1
- #reset-cells : shall contain 1
Optional properties :
- #power-domain-cells : shall contain 1
- Qualcomm TSENS (thermal sensor device) on some devices can
be part of GCC and hence the TSENS properties can also be
part of the GCC/clock-controller node.
For more details on the TSENS properties please refer
Documentation/devicetree/bindings/thermal/qcom-tsens.txt
- protected-clocks : Protected clock specifier list as per common clock
binding.
For SM8150 only:
- clocks: a list of phandles and clock-specifier pairs,
one for each entry in clock-names.
- clock-names: "bi_tcxo" (required)
"sleep_clk" (optional)
"aud_ref_clock" (optional)
Example:
clock-controller@900000 {
compatible = "qcom,gcc-msm8960";
reg = <0x900000 0x4000>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
Example of GCC with TSENS properties:
clock-controller@900000 {
compatible = "qcom,gcc-apq8064";
reg = <0x00900000 0x4000>;
nvmem-cells = <&tsens_calib>, <&tsens_backup>;
nvmem-cell-names = "calib", "calib_backup";
#clock-cells = <1>;
#reset-cells = <1>;
#thermal-sensor-cells = <1>;
};
Example of GCC with protected-clocks properties:
clock-controller@100000 {
compatible = "qcom,gcc-sdm845";
reg = <0x100000 0x1f0000>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
protected-clocks = <GCC_QSPI_CORE_CLK>,
<GCC_QSPI_CORE_CLK_SRC>,
<GCC_QSPI_CNOC_PERIPH_AHB_CLK>,
<GCC_LPASS_Q6_AXI_CLK>,
<GCC_LPASS_SWAY_CLK>;
};
Example of GCC with clocks
gcc: clock-controller@100000 {
compatible = "qcom,gcc-sm8150";
reg = <0x00100000 0x1f0000>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
clock-names = "bi_tcxo",
"sleep_clk";
clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
<&sleep_clk>;
};

188
Documentation/devicetree/bindings/clock/qcom,gcc.yaml Normal file
View File

@ -0,0 +1,188 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/bindings/clock/qcom,gcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller Binding
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- Taniya Das <tdas@codeaurora.org>
description: |
Qualcomm global clock control module which supports the clocks, resets and
power domains.
properties:
compatible :
enum:
- qcom,gcc-apq8064
- qcom,gcc-apq8084
- qcom,gcc-ipq8064
- qcom,gcc-ipq4019
- qcom,gcc-ipq8074
- qcom,gcc-msm8660
- qcom,gcc-msm8916
- qcom,gcc-msm8960
- qcom,gcc-msm8974
- qcom,gcc-msm8974pro
- qcom,gcc-msm8974pro-ac
- qcom,gcc-msm8994
- qcom,gcc-msm8996
- qcom,gcc-msm8998
- qcom,gcc-mdm9615
- qcom,gcc-qcs404
- qcom,gcc-sc7180
- qcom,gcc-sdm630
- qcom,gcc-sdm660
- qcom,gcc-sdm845
- qcom,gcc-sm8150
clocks:
minItems: 1
maxItems: 3
items:
- description: Board XO source
- description: Board active XO source
- description: Sleep clock source
clock-names:
minItems: 1
maxItems: 3
items:
- const: bi_tcxo
- const: bi_tcxo_ao
- const: sleep_clk
'#clock-cells':
const: 1
'#reset-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
maxItems: 1
nvmem-cells:
minItems: 1
maxItems: 2
description:
Qualcomm TSENS (thermal sensor device) on some devices can
be part of GCC and hence the TSENS properties can also be part
of the GCC/clock-controller node.
For more details on the TSENS properties please refer
Documentation/devicetree/bindings/thermal/qcom-tsens.txt
nvmem-cell-names:
minItems: 1
maxItems: 2
description:
Names for each nvmem-cells specified.
items:
- const: calib
- const: calib_backup
'thermal-sensor-cells':
const: 1
protected-clocks:
description:
Protected clock specifier list as per common clock binding
required:
- compatible
- reg
- '#clock-cells'
- '#reset-cells'
- '#power-domain-cells'
if:
properties:
compatible:
contains:
const: qcom,gcc-apq8064
then:
required:
- nvmem-cells
- nvmem-cell-names
- '#thermal-sensor-cells'
else:
if:
properties:
compatible:
contains:
enum:
- qcom,gcc-sm8150
- qcom,gcc-sc7180
then:
required:
- clocks
- clock-names
examples:
# Example for GCC for MSM8960:
- |
clock-controller@900000 {
compatible = "qcom,gcc-msm8960";
reg = <0x900000 0x4000>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
# Example of GCC with TSENS properties:
- |
clock-controller@900000 {
compatible = "qcom,gcc-apq8064";
reg = <0x00900000 0x4000>;
nvmem-cells = <&tsens_calib>, <&tsens_backup>;
nvmem-cell-names = "calib", "calib_backup";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
#thermal-sensor-cells = <1>;
};
# Example of GCC with protected-clocks properties:
- |
clock-controller@100000 {
compatible = "qcom,gcc-sdm845";
reg = <0x100000 0x1f0000>;
protected-clocks = <187>, <188>, <189>, <190>, <191>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
# Example of GCC with clock node properties for SM8150:
- |
clock-controller@100000 {
compatible = "qcom,gcc-sm8150";
reg = <0x00100000 0x1f0000>;
clocks = <&rpmhcc 0>, <&rpmhcc 1>, <&sleep_clk>;
clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
# Example of GCC with clock nodes properties for SC7180:
- |
clock-controller@100000 {
compatible = "qcom,gcc-sc7180";
reg = <0x100000 0x1f0000>;
clocks = <&rpmhcc 0>, <&rpmhcc 1>;
clock-names = "bi_tcxo", "bi_tcxo_ao";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
...

43
Documentation/devicetree/bindings/clock/qcom,q6sstopcc.yaml Normal file
View File

@ -0,0 +1,43 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,q6sstopcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Q6SSTOP clock Controller
maintainers:
- Govind Singh <govinds@codeaurora.org>
properties:
compatible:
const: "qcom,qcs404-q6sstopcc"
reg:
items:
- description: Q6SSTOP clocks register region
- description: Q6SSTOP_TCSR register region
clocks:
items:
- description: ahb clock for the q6sstopCC
'#clock-cells':
const: 1
required:
- compatible
- reg
- clocks
- '#clock-cells'
additionalProperties: false
examples:
- |
q6sstopcc: clock-controller@7500000 {
compatible = "qcom,qcs404-q6sstopcc";
reg = <0x07500000 0x4e000>, <0x07550000 0x10000>;
clocks = <&gcc 141>;
#clock-cells = <1>;
};

27
Documentation/devicetree/bindings/clock/qcom,rpmh-clk.txt
View File

@ -1,27 +0,0 @@
Qualcomm Technologies, Inc. RPMh Clocks
-------------------------------------------------------
Resource Power Manager Hardened (RPMh) manages shared resources on
some Qualcomm Technologies Inc. SoCs. It accepts clock requests from
other hardware subsystems via RSC to control clocks.
Required properties :
- compatible : must be one of:
"qcom,sdm845-rpmh-clk"
"qcom,sm8150-rpmh-clk"
- #clock-cells : must contain 1
- clocks: a list of phandles and clock-specifier pairs,
one for each entry in clock-names.
- clock-names: Parent board clock: "xo".
Example :
#include <dt-bindings/clock/qcom,rpmh.h>
&apps_rsc {
rpmhcc: clock-controller {
compatible = "qcom,sdm845-rpmh-clk";
#clock-cells = <1>;
};
};

49
Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml Normal file
View File

@ -0,0 +1,49 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/bindings/clock/qcom,rpmhcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Technologies, Inc. RPMh Clocks Bindings
maintainers:
- Taniya Das <tdas@codeaurora.org>
description: |
Resource Power Manager Hardened (RPMh) manages shared resources on
some Qualcomm Technologies Inc. SoCs. It accepts clock requests from
other hardware subsystems via RSC to control clocks.
properties:
compatible:
enum:
- qcom,sc7180-rpmh-clk
- qcom,sdm845-rpmh-clk
- qcom,sm8150-rpmh-clk
clocks:
maxItems: 1
clock-names:
items:
- const: xo
'#clock-cells':
const: 1
required:
- compatible
- '#clock-cells'
examples:
# Example for GCC for SDM845: The below node should be defined inside
# &apps_rsc node.
- |
#include <dt-bindings/clock/qcom,rpmh.h>
rpmhcc: clock-controller {
compatible = "qcom,sdm845-rpmh-clk";
clocks = <&xo_board>;
clock-names = "xo";
#clock-cells = <1>;
};
...

15
Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
View File

@ -19,6 +19,7 @@ Required Properties:
- "renesas,r8a7745-cpg-mssr" for the r8a7745 SoC (RZ/G1E)
- "renesas,r8a77470-cpg-mssr" for the r8a77470 SoC (RZ/G1C)
- "renesas,r8a774a1-cpg-mssr" for the r8a774a1 SoC (RZ/G2M)
- "renesas,r8a774b1-cpg-mssr" for the r8a774a1 SoC (RZ/G2N)
- "renesas,r8a774c0-cpg-mssr" for the r8a774c0 SoC (RZ/G2E)
- "renesas,r8a7790-cpg-mssr" for the r8a7790 SoC (R-Car H2)
- "renesas,r8a7791-cpg-mssr" for the r8a7791 SoC (R-Car M2-W)
@ -26,7 +27,8 @@ Required Properties:
- "renesas,r8a7793-cpg-mssr" for the r8a7793 SoC (R-Car M2-N)
- "renesas,r8a7794-cpg-mssr" for the r8a7794 SoC (R-Car E2)
- "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC (R-Car H3)
- "renesas,r8a7796-cpg-mssr" for the r8a7796 SoC (R-Car M3-W)
- "renesas,r8a7796-cpg-mssr" for the r8a77960 SoC (R-Car M3-W)
- "renesas,r8a77961-cpg-mssr" for the r8a77961 SoC (R-Car M3-W+)
- "renesas,r8a77965-cpg-mssr" for the r8a77965 SoC (R-Car M3-N)
- "renesas,r8a77970-cpg-mssr" for the r8a77970 SoC (R-Car V3M)
- "renesas,r8a77980-cpg-mssr" for the r8a77980 SoC (R-Car V3H)
@ -40,10 +42,11 @@ Required Properties:
clock-names
- clock-names: List of external parent clock names. Valid names are:
- "extal" (r7s9210, r8a7743, r8a7744, r8a7745, r8a77470, r8a774a1,
r8a774c0, r8a7790, r8a7791, r8a7792, r8a7793, r8a7794,
r8a7795, r8a7796, r8a77965, r8a77970, r8a77980, r8a77990,
r8a77995)
- "extalr" (r8a774a1, r8a7795, r8a7796, r8a77965, r8a77970, r8a77980)
r8a774b1, r8a774c0, r8a7790, r8a7791, r8a7792, r8a7793,
r8a7794, r8a7795, r8a77960, r8a77961, r8a77965, r8a77970,
r8a77980, r8a77990, r8a77995)
- "extalr" (r8a774a1, r8a774b1, r8a7795, r8a77960, r8a77961, r8a77965,
r8a77970, r8a77980)
- "usb_extal" (r8a7743, r8a7744, r8a7745, r8a77470, r8a7790, r8a7791,
r8a7793, r8a7794)
@ -59,7 +62,7 @@ Required Properties:
power-managed through Module Standby should refer to the CPG device
node in their "power-domains" property, as documented by the generic PM
Domain bindings in
Documentation/devicetree/bindings/power/power_domain.txt.
Documentation/devicetree/bindings/power/power-domain.yaml.
- #reset-cells: Must be 1
- The single reset specifier cell must be the module number, as defined

60
Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
View File

@ -1,60 +0,0 @@
* Renesas R-Car Gen2 Clock Pulse Generator (CPG)
The CPG generates core clocks for the R-Car Gen2 SoCs. It includes three PLLs
and several fixed ratio dividers.
The CPG also provides a Clock Domain for SoC devices, in combination with the
CPG Module Stop (MSTP) Clocks.
Required Properties:
- compatible: Must be one of
- "renesas,r8a7790-cpg-clocks" for the r8a7790 CPG
- "renesas,r8a7791-cpg-clocks" for the r8a7791 CPG
- "renesas,r8a7792-cpg-clocks" for the r8a7792 CPG
- "renesas,r8a7793-cpg-clocks" for the r8a7793 CPG
- "renesas,r8a7794-cpg-clocks" for the r8a7794 CPG
and "renesas,rcar-gen2-cpg-clocks" as a fallback.
- reg: Base address and length of the memory resource used by the CPG
- clocks: References to the parent clocks: first to the EXTAL clock, second
to the USB_EXTAL clock
- #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are "main",
"pll0", "pll1", "pll3", "lb", "qspi", "sdh", "sd0", "sd1", "z", "rcan", and
"adsp"
- #power-domain-cells: Must be 0
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
through an MSTP clock should refer to the CPG device node in their
"power-domains" property, as documented by the generic PM domain bindings in
Documentation/devicetree/bindings/power/power_domain.txt.
Examples
--------
- CPG device node:
cpg_clocks: cpg_clocks@e6150000 {
compatible = "renesas,r8a7790-cpg-clocks",
"renesas,rcar-gen2-cpg-clocks";
reg = <0 0xe6150000 0 0x1000>;
clocks = <&extal_clk &usb_extal_clk>;
#clock-cells = <1>;
clock-output-names = "main", "pll0, "pll1", "pll3",
"lb", "qspi", "sdh", "sd0", "sd1", "z",
"rcan", "adsp";
#power-domain-cells = <0>;
};
- CPG/MSTP Clock Domain member device node:
thermal@e61f0000 {
compatible = "renesas,thermal-r8a7790", "renesas,rcar-thermal";
reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp5_clks R8A7790_CLK_THERMAL>;
power-domains = <&cpg_clocks>;
};

2
Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.txt
View File

@ -46,7 +46,7 @@ Required properties:
Example (R-Car H3):
usb2_clksel: clock-controller@e6590630 {
compatible = "renesas,r8a77950-rcar-usb2-clock-sel",
compatible = "renesas,r8a7795-rcar-usb2-clock-sel",
"renesas,rcar-gen3-usb2-clock-sel";
reg = <0 0xe6590630 0 0x02>;
clocks = <&cpg CPG_MOD 703>, <&usb_extal>, <&usb_xtal>;

2
Documentation/devicetree/bindings/clock/ti/davinci/psc.txt
View File

@ -67,5 +67,5 @@ Examples:
Also see:
- Documentation/devicetree/bindings/clock/clock-bindings.txt
- Documentation/devicetree/bindings/power/power_domain.txt
- Documentation/devicetree/bindings/power/power-domain.yaml
- Documentation/devicetree/bindings/reset/reset.txt

29
Documentation/devicetree/bindings/counter/stm32-lptimer-cnt.txt
View File

@ -1,29 +0,0 @@
STMicroelectronics STM32 Low-Power Timer quadrature encoder and counter
STM32 Low-Power Timer provides several counter modes. It can be used as:
- quadrature encoder to detect angular position and direction of rotary
elements, from IN1 and IN2 input signals.
- simple counter from IN1 input signal.
Must be a sub-node of an STM32 Low-Power Timer device tree node.
See ../mfd/stm32-lptimer.txt for details about the parent node.
Required properties:
- compatible: Must be "st,stm32-lptimer-counter".
- pinctrl-names: Set to "default". An additional "sleep" state can be
defined to set pins in sleep state.
- pinctrl-n: List of phandles pointing to pin configuration nodes,
to set IN1/IN2 pins in mode of operation for Low-Power
Timer input on external pin.
Example:
timer@40002400 {
compatible = "st,stm32-lptimer";
...
counter {
compatible = "st,stm32-lptimer-counter";
pinctrl-names = "default", "sleep";
pinctrl-0 = <&lptim1_in_pins>;
pinctrl-1 = <&lptim1_sleep_in_pins>;
};
};

31
Documentation/devicetree/bindings/counter/stm32-timer-cnt.txt
View File

@ -1,31 +0,0 @@
STMicroelectronics STM32 Timer quadrature encoder
STM32 Timer provides quadrature encoder to detect
angular position and direction of rotary elements,
from IN1 and IN2 input signals.
Must be a sub-node of an STM32 Timer device tree node.
See ../mfd/stm32-timers.txt for details about the parent node.
Required properties:
- compatible: Must be "st,stm32-timer-counter".
- pinctrl-names: Set to "default".
- pinctrl-0: List of phandles pointing to pin configuration nodes,
to set CH1/CH2 pins in mode of operation for STM32
Timer input on external pin.
Example:
timers@40010000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "st,stm32-timers";
reg = <0x40010000 0x400>;
clocks = <&rcc 0 160>;
clock-names = "int";
counter {
compatible = "st,stm32-timer-counter";
pinctrl-names = "default";
pinctrl-0 = <&tim1_in_pins>;
};
};

50
Documentation/devicetree/bindings/counter/ti-eqep.yaml Normal file
View File

@ -0,0 +1,50 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/counter/ti-eqep.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments Enhanced Quadrature Encoder Pulse (eQEP) Module
maintainers:
- David Lechner <david@lechnology.com>
properties:
compatible:
const: ti,am3352-eqep
reg:
maxItems: 1
interrupts:
description: The eQEP event interrupt
maxItems: 1
clocks:
description: The clock that determines the SYSCLKOUT rate for the eQEP
peripheral.
maxItems: 1
clock-names:
const: sysclkout
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
additionalProperties: false
examples:
- |
eqep0: counter@180 {
compatible = "ti,am3352-eqep";
reg = <0x180 0x80>;
clocks = <&l4ls_gclk>;
clock-names = "sysclkout";
interrupts = <79>;
};
...

2
Documentation/devicetree/bindings/cpu/cpu-topology.txt
View File

@ -549,5 +549,5 @@ Example 3: HiFive Unleashed (RISC-V 64 bit, 4 core system)
[2] Devicetree NUMA binding description
Documentation/devicetree/bindings/numa.txt
[3] RISC-V Linux kernel documentation
Documentation/devicetree/bindings/riscv/cpus.txt
Documentation/devicetree/bindings/riscv/cpus.yaml
[4] https://www.devicetree.org/specifications/

6
Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
View File

@ -15,12 +15,16 @@ In 'cpus' nodes:
In 'operating-points-v2' table:
- compatible: Should be
- 'operating-points-v2-ti-cpu' for am335x, am43xx, and dra7xx/am57xx SoCs
- 'operating-points-v2-ti-cpu' for am335x, am43xx, and dra7xx/am57xx,
omap34xx, omap36xx and am3517 SoCs
- syscon: A phandle pointing to a syscon node representing the control module
register space of the SoC.
Optional properties:
--------------------
- "vdd-supply", "vbb-supply": to define two regulators for dra7xx
- "cpu0-supply", "vbb-supply": to define two regulators for omap36xx
For each opp entry in 'operating-points-v2' table:
- opp-supported-hw: Two bitfields indicating:
1. Which revision of the SoC the OPP is supported by

19
Documentation/devicetree/bindings/crypto/samsung-slimsss.txt
View File

@ -1,19 +0,0 @@
Samsung SoC SlimSSS (Slim Security SubSystem) module
The SlimSSS module in Exynos5433 SoC supports the following:
-- Feeder (FeedCtrl)
-- Advanced Encryption Standard (AES) with ECB,CBC,CTR,XTS and (CBC/XTS)/CTS
-- SHA-1/SHA-256 and (SHA-1/SHA-256)/HMAC
Required properties:
- compatible : Should contain entry for slimSSS version:
- "samsung,exynos5433-slim-sss" for Exynos5433 SoC.
- reg : Offset and length of the register set for the module
- interrupts : interrupt specifiers of SlimSSS module interrupts (one feed
control interrupt).
- clocks : list of clock phandle and specifier pairs for all clocks listed in
clock-names property.
- clock-names : list of device clock input names; should contain "pclk" and
"aclk" for slim-sss in Exynos5433.

47
Documentation/devicetree/bindings/crypto/samsung-slimsss.yaml Normal file
View File

@ -0,0 +1,47 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/crypto/samsung-slimsss.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos SoC SlimSSS (Slim Security SubSystem) module
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
- Kamil Konieczny <k.konieczny@partner.samsung.com>
description: |+
The SlimSSS module in Exynos5433 SoC supports the following:
-- Feeder (FeedCtrl)
-- Advanced Encryption Standard (AES) with ECB,CBC,CTR,XTS and (CBC/XTS)/CTS
-- SHA-1/SHA-256 and (SHA-1/SHA-256)/HMAC
properties:
compatible:
items:
- const: samsung,exynos5433-slim-ss
reg:
maxItems: 1
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: pclk
- const: aclk
interrupts:
description: One feed control interrupt.
maxItems: 1
required:
- compatible
- reg
- clock-names
- clocks
- interrupts
additionalProperties: false

32
Documentation/devicetree/bindings/crypto/samsung-sss.txt
View File

@ -1,32 +0,0 @@
Samsung SoC SSS (Security SubSystem) module
The SSS module in S5PV210 SoC supports the following:
-- Feeder (FeedCtrl)
-- Advanced Encryption Standard (AES)
-- Data Encryption Standard (DES)/3DES
-- Public Key Accelerator (PKA)
-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
-- PRNG: Pseudo Random Number Generator
The SSS module in Exynos4 (Exynos4210) and
Exynos5 (Exynos5420 and Exynos5250) SoCs
supports the following also:
-- ARCFOUR (ARC4)
-- True Random Number Generator (TRNG)
-- Secure Key Manager
Required properties:
- compatible : Should contain entries for this and backward compatible
SSS versions:
- "samsung,s5pv210-secss" for S5PV210 SoC.
- "samsung,exynos4210-secss" for Exynos4210, Exynos4212, Exynos4412, Exynos5250,
Exynos5260 and Exynos5420 SoCs.
- reg : Offset and length of the register set for the module
- interrupts : interrupt specifiers of SSS module interrupts (one feed
control interrupt).
- clocks : list of clock phandle and specifier pairs for all clocks listed in
clock-names property.
- clock-names : list of device clock input names; should contain one entry
"secss".

58
Documentation/devicetree/bindings/crypto/samsung-sss.yaml Normal file
View File

@ -0,0 +1,58 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/crypto/samsung-sss.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos SoC SSS (Security SubSystem) module
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
- Kamil Konieczny <k.konieczny@partner.samsung.com>
description: |+
The SSS module in S5PV210 SoC supports the following:
-- Feeder (FeedCtrl)
-- Advanced Encryption Standard (AES)
-- Data Encryption Standard (DES)/3DES
-- Public Key Accelerator (PKA)
-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
-- PRNG: Pseudo Random Number Generator
The SSS module in Exynos4 (Exynos4210) and Exynos5 (Exynos5420 and Exynos5250)
SoCs supports the following also:
-- ARCFOUR (ARC4)
-- True Random Number Generator (TRNG)
-- Secure Key Manager
properties:
compatible:
items:
- enum:
- samsung,s5pv210-secss # for S5PV210
- samsung,exynos4210-secss # for Exynos4210, Exynos4212,
# Exynos4412, Exynos5250,
# Exynos5260 and Exynos5420
reg:
maxItems: 1
clocks:
maxItems: 1
clock-names:
items:
- const: secss
interrupts:
description: One feed control interrupt.
maxItems: 1
required:
- compatible
- reg
- clock-names
- clocks
- interrupts
additionalProperties: false

16
Documentation/devicetree/bindings/crypto/st,stm32-crc.txt
View File

@ -1,16 +0,0 @@
* STMicroelectronics STM32 CRC
Required properties:
- compatible: Should be "st,stm32f7-crc".
- reg: The address and length of the peripheral registers space
- clocks: The input clock of the CRC instance
Optional properties: none
Example:
crc: crc@40023000 {
compatible = "st,stm32f7-crc";
reg = <0x40023000 0x400>;
clocks = <&rcc 0 12>;
};

38
Documentation/devicetree/bindings/crypto/st,stm32-crc.yaml Normal file
View File

@ -0,0 +1,38 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/crypto/st,stm32-crc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 CRC bindings
maintainers:
- Lionel Debieve <lionel.debieve@st.com>
properties:
compatible:
const: st,stm32f7-crc
reg:
maxItems: 1
clocks:
maxItems: 1
required:
- compatible
- reg
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/stm32mp1-clks.h>
crc@40023000 {
compatible = "st,stm32f7-crc";
reg = <0x40023000 0x400>;
clocks = <&rcc 0 12>;
};
...

19
Documentation/devicetree/bindings/crypto/st,stm32-cryp.txt
View File

@ -1,19 +0,0 @@
* STMicroelectronics STM32 CRYP
Required properties:
- compatible: Should be "st,stm32f756-cryp".
- reg: The address and length of the peripheral registers space
- clocks: The input clock of the CRYP instance
- interrupts: The CRYP interrupt
Optional properties:
- resets: The input reset of the CRYP instance
Example:
crypto@50060000 {
compatible = "st,stm32f756-cryp";
reg = <0x50060000 0x400>;
interrupts = <79>;
clocks = <&rcc 0 STM32F7_AHB2_CLOCK(CRYP)>;
resets = <&rcc STM32F7_AHB2_RESET(CRYP)>;
};

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