Linux 5.5-rc1
-----BEGIN PGP SIGNATURE----- iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAl3tf/0eHHRvcnZhbGRz QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGlKwH/3fTToujuJfTx5E5 mrARAP65J1L/DxpEKvKRt2bNZo6w13mNd8g7ZPmYChz90bYGvXQSG8hYTU9iAw3O yimSTJlNXDhVAluB53XnDdUxIWC4HUZsNxWJNCeXMuiMcGNsTGX+v3f+x7oHCT0P jI1RSIsFGjgr0RWqZ8U5aJckQo2xABC1TfYw53K66Oc/JLZpSFJFwMgjf1fD5diU HGDA8E2p0u1TQIyNzr86iqMvnlSRYBQwBQn6OgEKCG4Z0NLtXfDF4mqnxsXgLmIH oQoFfxaMKXyGWds7ZxwcGWntALCF41ThfpiJWDIyxjWxFEty4bqTCbDPwwyp7ip0 iuASmTI= =YqO2 -----END PGP SIGNATURE----- Merge tag 'v5.5-rc1' into core/kprobes, to resolve conflicts Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Коммит
2040cf9f59
|
@ -1,2 +1,4 @@
|
|||
*.c diff=cpp
|
||||
*.h diff=cpp
|
||||
*.dtsi diff=dts
|
||||
*.dts diff=dts
|
||||
|
|
|
@ -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)
|
||||
|
|
4
.mailmap
4
.mailmap
|
@ -105,6 +105,9 @@ James E Wilson <wilson@specifix.com>
|
|||
James Hogan <jhogan@kernel.org> <james.hogan@imgtec.com>
|
||||
James Hogan <jhogan@kernel.org> <james@albanarts.com>
|
||||
James Ketrenos <jketreno@io.(none)>
|
||||
Jan Glauber <jan.glauber@gmail.com> <jang@de.ibm.com>
|
||||
Jan Glauber <jan.glauber@gmail.com> <jang@linux.vnet.ibm.com>
|
||||
Jan Glauber <jan.glauber@gmail.com> <jglauber@cavium.com>
|
||||
Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com>
|
||||
Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
|
||||
Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
|
||||
|
@ -156,6 +159,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
3
CREDITS
|
@ -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
|
||||
|
|
|
@ -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)
|
||||
----------------------------------------------------------
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
|
@ -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
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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).
|
|
@ -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
|
||||
|
|
|
@ -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.
|
|
@ -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
|
||||
----------------------
|
||||
|
||||
|
|
|
@ -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'
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
|
@ -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.)
|
||||
|
|
@ -9,6 +9,7 @@ Device Mapper
|
|||
cache
|
||||
delay
|
||||
dm-crypt
|
||||
dm-dust
|
||||
dm-flakey
|
||||
dm-init
|
||||
dm-integrity
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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()).
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -113,7 +113,7 @@
|
|||
the GPE dispatcher.
|
||||
This facility can be used to prevent such uncontrolled
|
||||
GPE floodings.
|
||||
Format: <int>
|
||||
Format: <byte>
|
||||
|
||||
acpi_no_auto_serialize [HW,ACPI]
|
||||
Disable auto-serialization of AML methods
|
||||
|
@ -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]
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -8,6 +8,7 @@ Performance monitor support
|
|||
:maxdepth: 1
|
||||
|
||||
hisi-pmu
|
||||
imx-ddr
|
||||
qcom_l2_pmu
|
||||
qcom_l3_pmu
|
||||
arm-ccn
|
||||
|
|
|
@ -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:
|
||||
==================
|
||||
|
|
|
@ -103,7 +103,7 @@ the Microchip website: http://www.microchip.com.
|
|||
|
||||
* Datasheet
|
||||
|
||||
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11121-32-bit-Cortex-A5-Microcontroller-SAMA5D3_Datasheet.pdf
|
||||
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11121-32-bit-Cortex-A5-Microcontroller-SAMA5D3_Datasheet_B.pdf
|
||||
|
||||
* ARM Cortex-A5 + NEON based SoCs
|
||||
- sama5d4 family
|
||||
|
@ -167,7 +167,7 @@ the Microchip website: http://www.microchip.com.
|
|||
|
||||
* Datasheet
|
||||
|
||||
http://ww1.microchip.com/downloads/en/DeviceDoc/60001527A.pdf
|
||||
http://ww1.microchip.com/downloads/en/DeviceDoc/SAM-E70-S70-V70-V71-Family-Data-Sheet-DS60001527D.pdf
|
||||
|
||||
|
||||
Linux kernel information
|
||||
|
|
|
@ -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):
|
||||
|
|
|
@ -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:
|
||||
|
@ -129,7 +129,7 @@ writing of special-purpose memory allocators in the future.
|
|||
:functions: gen_pool_for_each_chunk
|
||||
|
||||
.. kernel-doc:: lib/genalloc.c
|
||||
:functions: addr_in_gen_pool
|
||||
:functions: gen_pool_has_addr
|
||||
|
||||
.. kernel-doc:: lib/genalloc.c
|
||||
:functions: gen_pool_avail
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -57,7 +57,13 @@ The Linux kernel provides more basic utility functions.
|
|||
Bit Operations
|
||||
--------------
|
||||
|
||||
.. kernel-doc:: include/asm-generic/bitops-instrumented.h
|
||||
.. kernel-doc:: include/asm-generic/bitops/instrumented-atomic.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: include/asm-generic/bitops/instrumented-non-atomic.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: include/asm-generic/bitops/instrumented-lock.h
|
||||
:internal:
|
||||
|
||||
Bitmap Operations
|
||||
|
|
|
@ -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().
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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)
|
||||
-------------------------------
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -34,6 +34,7 @@ Profiling data will only become accessible once debugfs has been mounted::
|
|||
|
||||
Coverage collection
|
||||
-------------------
|
||||
|
||||
The following program demonstrates coverage collection from within a test
|
||||
program using kcov:
|
||||
|
||||
|
@ -128,6 +129,7 @@ only need to enable coverage (disable happens automatically on thread end).
|
|||
|
||||
Comparison operands collection
|
||||
------------------------------
|
||||
|
||||
Comparison operands collection is similar to coverage collection:
|
||||
|
||||
.. code-block:: c
|
||||
|
@ -202,3 +204,130 @@ Comparison operands collection is similar to coverage collection:
|
|||
|
||||
Note that the kcov modes (coverage collection or comparison operands) are
|
||||
mutually exclusive.
|
||||
|
||||
Remote coverage collection
|
||||
--------------------------
|
||||
|
||||
With KCOV_ENABLE coverage is collected only for syscalls that are issued
|
||||
from the current process. With KCOV_REMOTE_ENABLE it's possible to collect
|
||||
coverage for arbitrary parts of the kernel code, provided that those parts
|
||||
are annotated with kcov_remote_start()/kcov_remote_stop().
|
||||
|
||||
This allows to collect coverage from two types of kernel background
|
||||
threads: the global ones, that are spawned during kernel boot in a limited
|
||||
number of instances (e.g. one USB hub_event() worker thread is spawned per
|
||||
USB HCD); and the local ones, that are spawned when a user interacts with
|
||||
some kernel interface (e.g. vhost workers).
|
||||
|
||||
To enable collecting coverage from a global background thread, a unique
|
||||
global handle must be assigned and passed to the corresponding
|
||||
kcov_remote_start() call. Then a userspace process can pass a list of such
|
||||
handles to the KCOV_REMOTE_ENABLE ioctl in the handles array field of the
|
||||
kcov_remote_arg struct. This will attach the used kcov device to the code
|
||||
sections, that are referenced by those handles.
|
||||
|
||||
Since there might be many local background threads spawned from different
|
||||
userspace processes, we can't use a single global handle per annotation.
|
||||
Instead, the userspace process passes a non-zero handle through the
|
||||
common_handle field of the kcov_remote_arg struct. This common handle gets
|
||||
saved to the kcov_handle field in the current task_struct and needs to be
|
||||
passed to the newly spawned threads via custom annotations. Those threads
|
||||
should in turn be annotated with kcov_remote_start()/kcov_remote_stop().
|
||||
|
||||
Internally kcov stores handles as u64 integers. The top byte of a handle
|
||||
is used to denote the id of a subsystem that this handle belongs to, and
|
||||
the lower 4 bytes are used to denote the id of a thread instance within
|
||||
that subsystem. A reserved value 0 is used as a subsystem id for common
|
||||
handles as they don't belong to a particular subsystem. The bytes 4-7 are
|
||||
currently reserved and must be zero. In the future the number of bytes
|
||||
used for the subsystem or handle ids might be increased.
|
||||
|
||||
When a particular userspace proccess collects coverage by via a common
|
||||
handle, kcov will collect coverage for each code section that is annotated
|
||||
to use the common handle obtained as kcov_handle from the current
|
||||
task_struct. However non common handles allow to collect coverage
|
||||
selectively from different subsystems.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
struct kcov_remote_arg {
|
||||
unsigned trace_mode;
|
||||
unsigned area_size;
|
||||
unsigned num_handles;
|
||||
uint64_t common_handle;
|
||||
uint64_t handles[0];
|
||||
};
|
||||
|
||||
#define KCOV_INIT_TRACE _IOR('c', 1, unsigned long)
|
||||
#define KCOV_DISABLE _IO('c', 101)
|
||||
#define KCOV_REMOTE_ENABLE _IOW('c', 102, struct kcov_remote_arg)
|
||||
|
||||
#define COVER_SIZE (64 << 10)
|
||||
|
||||
#define KCOV_TRACE_PC 0
|
||||
|
||||
#define KCOV_SUBSYSTEM_COMMON (0x00ull << 56)
|
||||
#define KCOV_SUBSYSTEM_USB (0x01ull << 56)
|
||||
|
||||
#define KCOV_SUBSYSTEM_MASK (0xffull << 56)
|
||||
#define KCOV_INSTANCE_MASK (0xffffffffull)
|
||||
|
||||
static inline __u64 kcov_remote_handle(__u64 subsys, __u64 inst)
|
||||
{
|
||||
if (subsys & ~KCOV_SUBSYSTEM_MASK || inst & ~KCOV_INSTANCE_MASK)
|
||||
return 0;
|
||||
return subsys | inst;
|
||||
}
|
||||
|
||||
#define KCOV_COMMON_ID 0x42
|
||||
#define KCOV_USB_BUS_NUM 1
|
||||
|
||||
int main(int argc, char **argv)
|
||||
{
|
||||
int fd;
|
||||
unsigned long *cover, n, i;
|
||||
struct kcov_remote_arg *arg;
|
||||
|
||||
fd = open("/sys/kernel/debug/kcov", O_RDWR);
|
||||
if (fd == -1)
|
||||
perror("open"), exit(1);
|
||||
if (ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE))
|
||||
perror("ioctl"), exit(1);
|
||||
cover = (unsigned long*)mmap(NULL, COVER_SIZE * sizeof(unsigned long),
|
||||
PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
|
||||
if ((void*)cover == MAP_FAILED)
|
||||
perror("mmap"), exit(1);
|
||||
|
||||
/* Enable coverage collection via common handle and from USB bus #1. */
|
||||
arg = calloc(1, sizeof(*arg) + sizeof(uint64_t));
|
||||
if (!arg)
|
||||
perror("calloc"), exit(1);
|
||||
arg->trace_mode = KCOV_TRACE_PC;
|
||||
arg->area_size = COVER_SIZE;
|
||||
arg->num_handles = 1;
|
||||
arg->common_handle = kcov_remote_handle(KCOV_SUBSYSTEM_COMMON,
|
||||
KCOV_COMMON_ID);
|
||||
arg->handles[0] = kcov_remote_handle(KCOV_SUBSYSTEM_USB,
|
||||
KCOV_USB_BUS_NUM);
|
||||
if (ioctl(fd, KCOV_REMOTE_ENABLE, arg))
|
||||
perror("ioctl"), free(arg), exit(1);
|
||||
free(arg);
|
||||
|
||||
/*
|
||||
* Here the user needs to trigger execution of a kernel code section
|
||||
* that is either annotated with the common handle, or to trigger some
|
||||
* activity on USB bus #1.
|
||||
*/
|
||||
sleep(2);
|
||||
|
||||
n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED);
|
||||
for (i = 0; i < n; i++)
|
||||
printf("0x%lx\n", cover[i + 1]);
|
||||
if (ioctl(fd, KCOV_DISABLE, 0))
|
||||
perror("ioctl"), exit(1);
|
||||
if (munmap(cover, COVER_SIZE * sizeof(unsigned long)))
|
||||
perror("munmap"), exit(1);
|
||||
if (close(fd))
|
||||
perror("close"), exit(1);
|
||||
return 0;
|
||||
}
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -94,7 +94,7 @@ properties:
|
|||
- amlogic,p212
|
||||
- hwacom,amazetv
|
||||
- khadas,vim
|
||||
- libretech,cc
|
||||
- libretech,aml-s905x-cc
|
||||
- nexbox,a95x
|
||||
- const: amlogic,s905x
|
||||
- const: amlogic,meson-gxl
|
||||
|
@ -147,6 +147,7 @@ properties:
|
|||
- enum:
|
||||
- hardkernel,odroid-n2
|
||||
- khadas,vim3
|
||||
- ugoos,am6
|
||||
- const: amlogic,s922x
|
||||
- const: amlogic,g12b
|
||||
|
||||
|
@ -156,4 +157,10 @@ properties:
|
|||
- seirobotics,sei610
|
||||
- khadas,vim3l
|
||||
- const: amlogic,sm1
|
||||
|
||||
- description: Boards with the Amlogic Meson A1 A113L SoC
|
||||
items:
|
||||
- enum:
|
||||
- amlogic,ad401
|
||||
- const: amlogic,a1
|
||||
...
|
||||
|
|
|
@ -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>;
|
||||
};
|
||||
};
|
|
@ -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
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
|
@ -45,6 +45,13 @@ properties:
|
|||
- const: atmel,at91sam9x5
|
||||
- const: atmel,at91sam9
|
||||
|
||||
- description: Overkiz kizbox3 board
|
||||
items:
|
||||
- const: overkiz,kizbox3-hs
|
||||
- const: atmel,sama5d27
|
||||
- const: atmel,sama5d2
|
||||
- const: atmel,sama5
|
||||
|
||||
- items:
|
||||
- const: atmel,sama5d27
|
||||
- const: atmel,sama5d2
|
||||
|
@ -73,6 +80,13 @@ properties:
|
|||
- const: atmel,sama5d3
|
||||
- const: atmel,sama5
|
||||
|
||||
- description: Overkiz kizbox2 board with two heads
|
||||
items:
|
||||
- const: overkiz,kizbox2-2
|
||||
- const: atmel,sama5d31
|
||||
- const: atmel,sama5d3
|
||||
- const: atmel,sama5
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- atmel,sama5d31
|
||||
|
|
|
@ -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.
|
|
@ -0,0 +1,54 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/bcm/bcm2835.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Broadcom BCM2711/BCM2835 Platforms Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Eric Anholt <eric@anholt.net>
|
||||
- Stefan Wahren <wahrenst@gmx.net>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: '/'
|
||||
compatible:
|
||||
oneOf:
|
||||
- description: BCM2711 based Boards
|
||||
items:
|
||||
- enum:
|
||||
- raspberrypi,4-model-b
|
||||
- const: brcm,bcm2711
|
||||
|
||||
- description: BCM2835 based Boards
|
||||
items:
|
||||
- enum:
|
||||
- raspberrypi,model-a
|
||||
- raspberrypi,model-a-plus
|
||||
- raspberrypi,model-b
|
||||
- raspberrypi,model-b-i2c0 # Raspberry Pi Model B (no P5)
|
||||
- raspberrypi,model-b-rev2
|
||||
- raspberrypi,model-b-plus
|
||||
- raspberrypi,compute-module
|
||||
- raspberrypi,model-zero
|
||||
- raspberrypi,model-zero-w
|
||||
- const: brcm,bcm2835
|
||||
|
||||
- description: BCM2836 based Boards
|
||||
items:
|
||||
- enum:
|
||||
- raspberrypi,2-model-b
|
||||
- const: brcm,bcm2836
|
||||
|
||||
- description: BCM2837 based Boards
|
||||
items:
|
||||
- enum:
|
||||
- raspberrypi,3-model-a-plus
|
||||
- raspberrypi,3-model-b
|
||||
- raspberrypi,3-model-b-plus
|
||||
- raspberrypi,3-compute-module
|
||||
- raspberrypi,3-compute-module-lite
|
||||
- const: brcm,bcm2837
|
||||
|
||||
...
|
|
@ -1,67 +0,0 @@
|
|||
Broadcom BCM2835 device tree bindings
|
||||
-------------------------------------------
|
||||
|
||||
Raspberry Pi Model A
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,model-a", "brcm,bcm2835";
|
||||
|
||||
Raspberry Pi Model A+
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,model-a-plus", "brcm,bcm2835";
|
||||
|
||||
Raspberry Pi Model B
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,model-b", "brcm,bcm2835";
|
||||
|
||||
Raspberry Pi Model B (no P5)
|
||||
early model B with I2C0 rather than I2C1 routed to the expansion header
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,model-b-i2c0", "brcm,bcm2835";
|
||||
|
||||
Raspberry Pi Model B rev2
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,model-b-rev2", "brcm,bcm2835";
|
||||
|
||||
Raspberry Pi Model B+
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,model-b-plus", "brcm,bcm2835";
|
||||
|
||||
Raspberry Pi 2 Model B
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
|
||||
|
||||
Raspberry Pi 3 Model A+
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,3-model-a-plus", "brcm,bcm2837";
|
||||
|
||||
Raspberry Pi 3 Model B
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
|
||||
|
||||
Raspberry Pi 3 Model B+
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,3-model-b-plus", "brcm,bcm2837";
|
||||
|
||||
Raspberry Pi Compute Module
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,compute-module", "brcm,bcm2835";
|
||||
|
||||
Raspberry Pi Compute Module 3
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,3-compute-module", "brcm,bcm2837";
|
||||
|
||||
Raspberry Pi Compute Module 3 Lite
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,3-compute-module-lite", "brcm,bcm2837";
|
||||
|
||||
Raspberry Pi Zero
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,model-zero", "brcm,bcm2835";
|
||||
|
||||
Raspberry Pi Zero W
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,model-zero-w", "brcm,bcm2835";
|
||||
|
||||
Generic BCM2835 board
|
||||
Required root node properties:
|
||||
compatible = "brcm,bcm2835";
|
|
@ -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
|
||||
|
|
|
@ -189,6 +189,7 @@ properties:
|
|||
- marvell,armada-390-smp
|
||||
- marvell,armada-xp-smp
|
||||
- marvell,98dx3236-smp
|
||||
- marvell,mmp3-smp
|
||||
- mediatek,mt6589-smp
|
||||
- mediatek,mt81xx-tz-smp
|
||||
- qcom,gcc-msm8660
|
||||
|
|
|
@ -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>;
|
||||
|
|
|
@ -38,12 +38,16 @@ properties:
|
|||
- description: i.MX27 Product Development Kit
|
||||
items:
|
||||
- enum:
|
||||
- armadeus,imx27-apf27 # APF27 SoM
|
||||
- armadeus,imx27-apf27dev # APF27 SoM on APF27Dev board
|
||||
- fsl,imx27-pdk
|
||||
- const: fsl,imx27
|
||||
|
||||
- description: i.MX28 based Boards
|
||||
items:
|
||||
- enum:
|
||||
- armadeus,imx28-apf28 # APF28 SoM
|
||||
- armadeus,imx28-apf28dev # APF28 SoM on APF28Dev board
|
||||
- fsl,imx28-evk
|
||||
- i2se,duckbill
|
||||
- i2se,duckbill-2
|
||||
|
@ -87,7 +91,8 @@ properties:
|
|||
- description: i.MX51 Babbage Board
|
||||
items:
|
||||
- enum:
|
||||
- armadeus,imx51-apf51
|
||||
- armadeus,imx51-apf51 # APF51 SoM
|
||||
- armadeus,imx51-apf51dev # APF51 SoM on APF51Dev board
|
||||
- fsl,imx51-babbage
|
||||
- technologic,imx51-ts4800
|
||||
- const: fsl,imx51
|
||||
|
@ -106,6 +111,8 @@ properties:
|
|||
- description: i.MX6Q based Boards
|
||||
items:
|
||||
- enum:
|
||||
- armadeus,imx6q-apf6 # APF6 (Quad/Dual) SoM
|
||||
- armadeus,imx6q-apf6dev # APF6 (Quad/Dual) SoM on APF6Dev board
|
||||
- emtrion,emcon-mx6 # emCON-MX6D or emCON-MX6Q SoM
|
||||
- emtrion,emcon-mx6-avari # emCON-MX6D or emCON-MX6Q SoM on Avari Base
|
||||
- fsl,imx6q-arm2
|
||||
|
@ -114,6 +121,11 @@ properties:
|
|||
- fsl,imx6q-sabresd
|
||||
- technologic,imx6q-ts4900
|
||||
- technologic,imx6q-ts7970
|
||||
- toradex,apalis_imx6q # Apalis iMX6 Module
|
||||
- toradex,apalis_imx6q-eval # Apalis iMX6 Module on Apalis Evaluation Board
|
||||
- toradex,apalis_imx6q-ixora # Apalis iMX6 Module on Ixora
|
||||
- toradex,apalis_imx6q-ixora-v1.1 # Apalis iMX6 Module on Ixora V1.1
|
||||
- variscite,dt6customboard
|
||||
- const: fsl,imx6q
|
||||
|
||||
- description: i.MX6QP based Boards
|
||||
|
@ -126,6 +138,8 @@ properties:
|
|||
- description: i.MX6DL based Boards
|
||||
items:
|
||||
- enum:
|
||||
- armadeus,imx6dl-apf6 # APF6 (Solo) SoM
|
||||
- armadeus,imx6dl-apf6dldev # APF6 (Solo) SoM on APF6Dev board
|
||||
- eckelmann,imx6dl-ci4x10
|
||||
- emtrion,emcon-mx6 # emCON-MX6S or emCON-MX6DL SoM
|
||||
- emtrion,emcon-mx6-avari # emCON-MX6S or emCON-MX6DL SoM on Avari Base
|
||||
|
@ -133,6 +147,8 @@ properties:
|
|||
- fsl,imx6dl-sabresd # i.MX6 DualLite SABRE Smart Device Board
|
||||
- technologic,imx6dl-ts4900
|
||||
- technologic,imx6dl-ts7970
|
||||
- toradex,colibri_imx6dl # Colibri iMX6 Module
|
||||
- toradex,colibri_imx6dl-eval-v3 # Colibri iMX6 Module on Colibri Evaluation Board V3
|
||||
- ysoft,imx6dl-yapp4-draco # i.MX6 DualLite Y Soft IOTA Draco board
|
||||
- ysoft,imx6dl-yapp4-hydra # i.MX6 DualLite Y Soft IOTA Hydra board
|
||||
- ysoft,imx6dl-yapp4-ursa # i.MX6 Solo Y Soft IOTA Ursa board
|
||||
|
@ -148,6 +164,7 @@ properties:
|
|||
items:
|
||||
- enum:
|
||||
- fsl,imx6sll-evk
|
||||
- kobo,clarahd
|
||||
- const: fsl,imx6sll
|
||||
|
||||
- description: i.MX6SX based Boards
|
||||
|
@ -160,8 +177,11 @@ properties:
|
|||
- description: i.MX6UL based Boards
|
||||
items:
|
||||
- enum:
|
||||
- armadeus,imx6ul-opos6ul # OPOS6UL (i.MX6UL) SoM
|
||||
- armadeus,imx6ul-opos6uldev # OPOS6UL (i.MX6UL) SoM on OPOS6ULDev board
|
||||
- fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
|
||||
- kontron,imx6ul-n6310-som # Kontron N6310 SOM
|
||||
- kontron,imx6ul-n6311-som # Kontron N6311 SOM
|
||||
- const: fsl,imx6ul
|
||||
|
||||
- description: Kontron N6310 S Board
|
||||
|
@ -170,6 +190,12 @@ properties:
|
|||
- const: kontron,imx6ul-n6310-som
|
||||
- const: fsl,imx6ul
|
||||
|
||||
- description: Kontron N6311 S Board
|
||||
items:
|
||||
- const: kontron,imx6ul-n6311-s
|
||||
- const: kontron,imx6ul-n6311-som
|
||||
- const: fsl,imx6ul
|
||||
|
||||
- description: Kontron N6310 S 43 Board
|
||||
items:
|
||||
- const: kontron,imx6ul-n6310-s-43
|
||||
|
@ -180,7 +206,18 @@ properties:
|
|||
- description: i.MX6ULL based Boards
|
||||
items:
|
||||
- enum:
|
||||
- armadeus,imx6ull-opos6ul # OPOS6UL (i.MX6ULL) SoM
|
||||
- armadeus,imx6ull-opos6uldev # OPOS6UL (i.MX6ULL) SoM on OPOS6ULDev board
|
||||
- fsl,imx6ull-14x14-evk # i.MX6 UltraLiteLite 14x14 EVK Board
|
||||
- kontron,imx6ull-n6411-som # Kontron N6411 SOM
|
||||
- toradex,colibri-imx6ull-eval # Colibri iMX6ULL Module on Colibri Evaluation Board
|
||||
- toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / Bluetooth Module on Colibri Evaluation Board
|
||||
- const: fsl,imx6ull
|
||||
|
||||
- description: Kontron N6411 S Board
|
||||
items:
|
||||
- const: kontron,imx6ull-n6411-s
|
||||
- const: kontron,imx6ull-n6411-som
|
||||
- const: fsl,imx6ull
|
||||
|
||||
- description: i.MX6ULZ based Boards
|
||||
|
@ -193,6 +230,8 @@ properties:
|
|||
- description: i.MX7S based Boards
|
||||
items:
|
||||
- enum:
|
||||
- toradex,colibri-imx7s # Colibri iMX7 Solo Module
|
||||
- toradex,colibri-imx7s-eval-v3 # Colibri iMX7 Solo Module on Colibri Evaluation Board V3
|
||||
- tq,imx7s-mba7 # i.MX7S TQ MBa7 with TQMa7S SoM
|
||||
- const: fsl,imx7s
|
||||
|
||||
|
@ -201,6 +240,10 @@ properties:
|
|||
- enum:
|
||||
- fsl,imx7d-sdb # i.MX7 SabreSD Board
|
||||
- novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board
|
||||
- toradex,colibri-imx7d # Colibri iMX7 Dual Module
|
||||
- toradex,colibri-imx7d-emmc # Colibri iMX7 Dual 1GB (eMMC) Module
|
||||
- toradex,colibri-imx7d-emmc-eval-v3 # Colibri iMX7 Dual 1GB (eMMC) Module on Colibri Evaluation Board V3
|
||||
- toradex,colibri-imx7d-eval-v3 # Colibri iMX7 Dual Module on Colibri Evaluation Board V3
|
||||
- tq,imx7d-mba7 # i.MX7D TQ MBa7 with TQMa7D SoM
|
||||
- zii,imx7d-rmu2 # ZII RMU2 Board
|
||||
- zii,imx7d-rpu2 # ZII RPU2 Board
|
||||
|
@ -233,6 +276,7 @@ properties:
|
|||
items:
|
||||
- enum:
|
||||
- fsl,imx8mn-ddr4-evk # i.MX8MN DDR4 EVK Board
|
||||
- fsl,imx8mn-evk # i.MX8MN LPDDR4 EVK Board
|
||||
- const: fsl,imx8mn
|
||||
|
||||
- description: i.MX8MQ based Boards
|
||||
|
@ -250,6 +294,8 @@ properties:
|
|||
- enum:
|
||||
- einfochips,imx8qxp-ai_ml # i.MX8QXP AI_ML Board
|
||||
- fsl,imx8qxp-mek # i.MX8QXP MEK Board
|
||||
- toradex,colibri-imx8x # Colibri iMX8X Module
|
||||
- toradex,colibri-imx8x-eval-v3 # Colibri iMX8X Module on Colibri Evaluation Board V3
|
||||
- const: fsl,imx8qxp
|
||||
|
||||
- description:
|
||||
|
@ -267,6 +313,10 @@ properties:
|
|||
- fsl,vf600
|
||||
- fsl,vf610
|
||||
- fsl,vf610m4
|
||||
- toradex,vf500-colibri_vf50 # Colibri VF50 Module
|
||||
- toradex,vf500-colibri_vf50-on-eval # Colibri VF50 Module on Colibri Evaluation Board
|
||||
- toradex,vf610-colibri_vf61 # Colibri VF61 Module
|
||||
- toradex,vf610-colibri_vf61-on-eval # Colibri VF61 Module on Colibri Evaluation Board
|
||||
|
||||
- description: ZII's VF610 based Boards
|
||||
items:
|
||||
|
@ -335,4 +385,10 @@ properties:
|
|||
- fsl,ls2088a-rdb
|
||||
- const: fsl,ls2088a
|
||||
|
||||
- description: S32V234 based Boards
|
||||
items:
|
||||
- enum:
|
||||
- fsl,s32v234-evb # S32V234-EVB2 Customer Evaluation Board
|
||||
- const: fsl,s32v234
|
||||
|
||||
...
|
||||
|
|
|
@ -1,15 +1,15 @@
|
|||
Marvell Armada AP806 System Controller
|
||||
Marvell Armada AP80x System Controller
|
||||
======================================
|
||||
|
||||
The AP806 is one of the two core HW blocks of the Marvell Armada 7K/8K
|
||||
SoCs. It contains system controllers, which provide several registers
|
||||
giving access to numerous features: clocks, pin-muxing and many other
|
||||
SoC configuration items. This DT binding allows to describe these
|
||||
system controllers.
|
||||
The AP806/AP807 is one of the two core HW blocks of the Marvell Armada
|
||||
7K/8K/931x SoCs. It contains system controllers, which provide several
|
||||
registers giving access to numerous features: clocks, pin-muxing and
|
||||
many other SoC configuration items. This DT binding allows to describe
|
||||
these system controllers.
|
||||
|
||||
For the top level node:
|
||||
- compatible: must be: "syscon", "simple-mfd";
|
||||
- reg: register area of the AP806 system controller
|
||||
- reg: register area of the AP80x system controller
|
||||
|
||||
SYSTEM CONTROLLER 0
|
||||
===================
|
|
@ -1,24 +0,0 @@
|
|||
Marvell Armada 7K/8K Platforms Device Tree Bindings
|
||||
---------------------------------------------------
|
||||
|
||||
Boards using a SoC of the Marvell Armada 7K or 8K families must carry
|
||||
the following root node property:
|
||||
|
||||
- compatible, with one of the following values:
|
||||
|
||||
- "marvell,armada7020", "marvell,armada-ap806-dual", "marvell,armada-ap806"
|
||||
when the SoC being used is the Armada 7020
|
||||
|
||||
- "marvell,armada7040", "marvell,armada-ap806-quad", "marvell,armada-ap806"
|
||||
when the SoC being used is the Armada 7040
|
||||
|
||||
- "marvell,armada8020", "marvell,armada-ap806-dual", "marvell,armada-ap806"
|
||||
when the SoC being used is the Armada 8020
|
||||
|
||||
- "marvell,armada8040", "marvell,armada-ap806-quad", "marvell,armada-ap806"
|
||||
when the SoC being used is the Armada 8040
|
||||
|
||||
Example:
|
||||
|
||||
compatible = "marvell,armada7040-db", "marvell,armada7040",
|
||||
"marvell,armada-ap806-quad", "marvell,armada-ap806";
|
|
@ -0,0 +1,61 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0+ OR X11)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/marvell/armada-7k-8k.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Marvell Armada 7K/8K Platforms Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Gregory CLEMENT <gregory.clement@bootlin.com>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: '/'
|
||||
compatible:
|
||||
oneOf:
|
||||
|
||||
- description: Armada 7020 SoC
|
||||
items:
|
||||
- const: marvell,armada7020
|
||||
- const: marvell,armada-ap806-dual
|
||||
- const: marvell,armada-ap806
|
||||
|
||||
- description: Armada 7040 SoC
|
||||
items:
|
||||
- const: marvell,armada7040
|
||||
- const: marvell,armada-ap806-quad
|
||||
- const: marvell,armada-ap806
|
||||
|
||||
- description: Armada 8020 SoC
|
||||
items:
|
||||
- const: marvell,armada8020
|
||||
- const: marvell,armada-ap806-dual
|
||||
- const: marvell,armada-ap806
|
||||
|
||||
- description: Armada 8040 SoC
|
||||
items:
|
||||
- const: marvell,armada8040
|
||||
- const: marvell,armada-ap806-quad
|
||||
- const: marvell,armada-ap806
|
||||
|
||||
- description: Armada CN9130 SoC with no external CP
|
||||
items:
|
||||
- const: marvell,cn9130
|
||||
- const: marvell,armada-ap807-quad
|
||||
- const: marvell,armada-ap807
|
||||
|
||||
- description: Armada CN9131 SoC with one external CP
|
||||
items:
|
||||
- const: marvell,cn9131
|
||||
- const: marvell,cn9130
|
||||
- const: marvell,armada-ap807-quad
|
||||
- const: marvell,armada-ap807
|
||||
|
||||
- description: Armada CN9132 SoC with two external CPs
|
||||
items:
|
||||
- const: marvell,cn9132
|
||||
- const: marvell,cn9131
|
||||
- const: marvell,cn9130
|
||||
- const: marvell,armada-ap807-quad
|
||||
- const: marvell,armada-ap807
|
|
@ -1,14 +0,0 @@
|
|||
Marvell Platforms Device Tree Bindings
|
||||
----------------------------------------------------
|
||||
|
||||
PXA168 Aspenite Board
|
||||
Required root node properties:
|
||||
- compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";
|
||||
|
||||
PXA910 DKB Board
|
||||
Required root node properties:
|
||||
- compatible = "mrvl,pxa910-dkb";
|
||||
|
||||
MMP2 Brownstone Board
|
||||
Required root node properties:
|
||||
- compatible = "mrvl,mmp2-brownstone", "mrvl,mmp2";
|
|
@ -0,0 +1,35 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/mrvl/mrvl.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Marvell Platforms Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Lubomir Rintel <lkundrak@v3.sk>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: '/'
|
||||
compatible:
|
||||
oneOf:
|
||||
- description: PXA168 Aspenite Board
|
||||
items:
|
||||
- enum:
|
||||
- mrvl,pxa168-aspenite
|
||||
- const: mrvl,pxa168
|
||||
- description: PXA910 DKB Board
|
||||
items:
|
||||
- enum:
|
||||
- mrvl,pxa910-dkb
|
||||
- const: mrvl,pxa910
|
||||
- description: MMP2 based boards
|
||||
items:
|
||||
- enum:
|
||||
- mrvl,mmp2-brownstone
|
||||
- const: mrvl,mmp2
|
||||
- description: MMP3 based boards
|
||||
items:
|
||||
- const: mrvl,mmp3
|
||||
...
|
|
@ -1,41 +0,0 @@
|
|||
== Introduction==
|
||||
|
||||
LLCC (Last Level Cache Controller) provides last level of cache memory in SOC,
|
||||
that can be shared by multiple clients. Clients here are different cores in the
|
||||
SOC, the idea is to minimize the local caches at the clients and migrate to
|
||||
common pool of memory. Cache memory is divided into partitions called slices
|
||||
which are assigned to clients. Clients can query the slice details, activate
|
||||
and deactivate them.
|
||||
|
||||
Properties:
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: must be "qcom,sdm845-llcc"
|
||||
|
||||
- reg:
|
||||
Usage: required
|
||||
Value Type: <prop-encoded-array>
|
||||
Definition: The first element specifies the llcc base start address and
|
||||
the size of the register region. The second element specifies
|
||||
the llcc broadcast base address and size of the register region.
|
||||
|
||||
- reg-names:
|
||||
Usage: required
|
||||
Value Type: <stringlist>
|
||||
Definition: Register region names. Must be "llcc_base", "llcc_broadcast_base".
|
||||
|
||||
- interrupts:
|
||||
Usage: required
|
||||
Definition: The interrupt is associated with the llcc edac device.
|
||||
It's used for llcc cache single and double bit error detection
|
||||
and reporting.
|
||||
|
||||
Example:
|
||||
|
||||
cache-controller@1100000 {
|
||||
compatible = "qcom,sdm845-llcc";
|
||||
reg = <0x1100000 0x200000>, <0x1300000 0x50000> ;
|
||||
reg-names = "llcc_base", "llcc_broadcast_base";
|
||||
interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>;
|
||||
};
|
|
@ -0,0 +1,55 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/msm/qcom,llcc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Last Level Cache Controller
|
||||
|
||||
maintainers:
|
||||
- Rishabh Bhatnagar <rishabhb@codeaurora.org>
|
||||
- Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
|
||||
|
||||
description: |
|
||||
LLCC (Last Level Cache Controller) provides last level of cache memory in SoC,
|
||||
that can be shared by multiple clients. Clients here are different cores in the
|
||||
SoC, the idea is to minimize the local caches at the clients and migrate to
|
||||
common pool of memory. Cache memory is divided into partitions called slices
|
||||
which are assigned to clients. Clients can query the slice details, activate
|
||||
and deactivate them.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,sc7180-llcc
|
||||
- qcom,sdm845-llcc
|
||||
|
||||
reg:
|
||||
items:
|
||||
- description: LLCC base register region
|
||||
- description: LLCC broadcast base register region
|
||||
|
||||
reg-names:
|
||||
items:
|
||||
- const: llcc_base
|
||||
- const: llcc_broadcast_base
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- reg-names
|
||||
- interrupts
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
cache-controller@1100000 {
|
||||
compatible = "qcom,sdm845-llcc";
|
||||
reg = <0x1100000 0x200000>, <0x1300000 0x50000> ;
|
||||
reg-names = "llcc_base", "llcc_broadcast_base";
|
||||
interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>;
|
||||
};
|
|
@ -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"
|
||||
|
|
|
@ -0,0 +1,29 @@
|
|||
OMAP PRM instance bindings
|
||||
|
||||
Power and Reset Manager is an IP block on OMAP family of devices which
|
||||
handle the power domains and their current state, and provide reset
|
||||
handling for the domains and/or separate IP blocks under the power domain
|
||||
hierarchy.
|
||||
|
||||
Required properties:
|
||||
- compatible: Must contain one of the following:
|
||||
"ti,am3-prm-inst"
|
||||
"ti,am4-prm-inst"
|
||||
"ti,omap4-prm-inst"
|
||||
"ti,omap5-prm-inst"
|
||||
"ti,dra7-prm-inst"
|
||||
and additionally must contain:
|
||||
"ti,omap-prm-inst"
|
||||
- reg: Contains PRM instance register address range
|
||||
(base address and length)
|
||||
|
||||
Optional properties:
|
||||
- #reset-cells: Should be 1 if the PRM instance in question supports resets.
|
||||
|
||||
Example:
|
||||
|
||||
prm_dsp2: prm@1b00 {
|
||||
compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
|
||||
reg = <0x1b00 0x40>;
|
||||
#reset-cells = <1>;
|
||||
};
|
|
@ -13,11 +13,24 @@ properties:
|
|||
$nodename:
|
||||
const: '/'
|
||||
compatible:
|
||||
# RTD1295 SoC based boards
|
||||
items:
|
||||
- enum:
|
||||
- mele,v9
|
||||
- probox2,ava
|
||||
- zidoo,x9s
|
||||
- const: realtek,rtd1295
|
||||
oneOf:
|
||||
# RTD1293 SoC based boards
|
||||
- items:
|
||||
- enum:
|
||||
- synology,ds418j # Synology DiskStation DS418j
|
||||
- const: realtek,rtd1293
|
||||
|
||||
# RTD1295 SoC based boards
|
||||
- items:
|
||||
- enum:
|
||||
- mele,v9 # MeLE V9
|
||||
- probox2,ava # ProBox2 AVA
|
||||
- zidoo,x9s # Zidoo X9S
|
||||
- const: realtek,rtd1295
|
||||
|
||||
# RTD1296 SoC based boards
|
||||
- items:
|
||||
- enum:
|
||||
- synology,ds418 # Synology DiskStation DS418
|
||||
- const: realtek,rtd1296
|
||||
...
|
||||
|
|
|
@ -1,20 +0,0 @@
|
|||
Renesas Product Register
|
||||
|
||||
Most Renesas ARM SoCs have a Product Register or Boundary Scan ID Register that
|
||||
allows to retrieve SoC product and revision information. If present, a device
|
||||
node for this register should be added.
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be one of:
|
||||
"renesas,prr"
|
||||
"renesas,bsid"
|
||||
- reg: Base address and length of the register block.
|
||||
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
prr: chipid@ff000044 {
|
||||
compatible = "renesas,prr";
|
||||
reg = <0 0xff000044 0 4>;
|
||||
};
|
|
@ -0,0 +1,35 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/renesas,prr.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Renesas Product Register
|
||||
|
||||
maintainers:
|
||||
- Geert Uytterhoeven <geert+renesas@glider.be>
|
||||
- Magnus Damm <magnus.damm@gmail.com>
|
||||
|
||||
description: |
|
||||
Most Renesas ARM SoCs have a Product Register or Boundary Scan ID
|
||||
Register that allows to retrieve SoC product and revision information.
|
||||
If present, a device node for this register should be added.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- renesas,prr
|
||||
- renesas,bsid
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
examples:
|
||||
- |
|
||||
prr: chipid@ff000044 {
|
||||
compatible = "renesas,prr";
|
||||
reg = <0 0xff000044 0 4>;
|
||||
};
|
|
@ -116,6 +116,18 @@ properties:
|
|||
- const: hoperun,hihope-rzg2m
|
||||
- const: renesas,r8a774a1
|
||||
|
||||
- description: RZ/G2N (R8A774B1)
|
||||
items:
|
||||
- enum:
|
||||
- hoperun,hihope-rzg2n # HopeRun HiHope RZ/G2N platform
|
||||
- const: renesas,r8a774b1
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- hoperun,hihope-rzg2-ex # HopeRun expansion board for HiHope RZ/G2 platforms
|
||||
- const: hoperun,hihope-rzg2n
|
||||
- const: renesas,r8a774b1
|
||||
|
||||
- description: RZ/G2E (R8A774C0)
|
||||
items:
|
||||
- enum:
|
||||
|
@ -193,15 +205,23 @@ properties:
|
|||
- renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012S)
|
||||
- const: renesas,r8a7796
|
||||
|
||||
- description: R-Car M3-W+ (R8A77961)
|
||||
items:
|
||||
- enum:
|
||||
- renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012SA5A)
|
||||
- const: renesas,r8a77961
|
||||
|
||||
- description: Kingfisher (SBEV-RCAR-KF-M03)
|
||||
items:
|
||||
- const: shimafuji,kingfisher
|
||||
- enum:
|
||||
- renesas,h3ulcb
|
||||
- renesas,m3ulcb
|
||||
- renesas,m3nulcb
|
||||
- enum:
|
||||
- renesas,r8a7795
|
||||
- renesas,r8a7796
|
||||
- renesas,r8a77965
|
||||
|
||||
- description: R-Car M3-N (R8A77965)
|
||||
items:
|
||||
|
|
|
@ -40,6 +40,11 @@ properties:
|
|||
- const: asus,rk3288-tinker-s
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Beelink A1
|
||||
items:
|
||||
- const: azw,beelink-a1
|
||||
- const: rockchip,rk3328
|
||||
|
||||
- description: bq Curie 2 tablet
|
||||
items:
|
||||
- const: mundoreader,bq-curie2
|
||||
|
@ -82,6 +87,11 @@ properties:
|
|||
- const: firefly,firefly-rk3399
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: Firefly ROC-RK3308-CC
|
||||
items:
|
||||
- const: firefly,roc-rk3308-cc
|
||||
- const: rockchip,rk3308
|
||||
|
||||
- description: Firefly roc-rk3328-cc
|
||||
items:
|
||||
- const: firefly,roc-rk3328-cc
|
||||
|
@ -89,7 +99,9 @@ properties:
|
|||
|
||||
- description: Firefly ROC-RK3399-PC
|
||||
items:
|
||||
- const: firefly,roc-rk3399-pc
|
||||
- enum:
|
||||
- firefly,roc-rk3399-pc
|
||||
- firefly,roc-rk3399-pc-mezzanine
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: FriendlyElec NanoPi4 series boards
|
||||
|
@ -464,6 +476,11 @@ properties:
|
|||
- rockchip,rk3288-evb-rk808
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Rockchip RK3308 Evaluation board
|
||||
items:
|
||||
- const: rockchip,rk3308-evb
|
||||
- const: rockchip,rk3308
|
||||
|
||||
- description: Rockchip RK3328 Evaluation board
|
||||
items:
|
||||
- const: rockchip,rk3328-evb
|
||||
|
|
|
@ -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>;
|
||||
};
|
|
@ -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>;
|
||||
};
|
|
@ -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>;
|
||||
/* ... */
|
||||
};
|
|
@ -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>;
|
||||
};
|
|
@ -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>;
|
||||
};
|
|
@ -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
|
|
@ -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>;
|
||||
};
|
|
@ -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>;
|
||||
};
|
|
@ -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>;
|
||||
};
|
|
@ -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";
|
|
@ -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
|
||||
|
||||
...
|
|
@ -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
|
||||
...
|
||||
|
|
|
@ -211,6 +211,11 @@ properties:
|
|||
- const: friendlyarm,nanopi-a64
|
||||
- const: allwinner,sun50i-a64
|
||||
|
||||
- description: FriendlyARM NanoPi Duo2
|
||||
items:
|
||||
- const: friendlyarm,nanopi-duo2
|
||||
- const: allwinner,sun8i-h3
|
||||
|
||||
- description: FriendlyARM NanoPi M1
|
||||
items:
|
||||
- const: friendlyarm,nanopi-m1
|
||||
|
|
|
@ -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>;
|
||||
};
|
||||
};
|
|
@ -8,6 +8,7 @@ bus.
|
|||
Required properties:
|
||||
- compatible: Must be one of:
|
||||
- allwinner,sun5i-a13-mbus
|
||||
- allwinner,sun8i-h3-mbus
|
||||
- reg: Offset and length of the register set for the controller
|
||||
- clocks: phandle to the clock driving the controller
|
||||
- dma-ranges: See section 2.3.9 of the DeviceTree Specification
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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>;
|
||||
};
|
|
@ -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>;
|
||||
};
|
|
@ -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>;
|
||||
};
|
|
@ -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;
|
||||
};
|
|
@ -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
|
||||
|
|
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче