Merge branch 'for-6.5/apple' into for-linus
- improved support for Keychron K8 keyboard (Lasse Brun)
This commit is contained in:
commit
e80b500370
|
@ -521,7 +521,6 @@ ForEachMacros:
|
|||
- 'of_property_for_each_u32'
|
||||
- 'pci_bus_for_each_resource'
|
||||
- 'pci_dev_for_each_resource'
|
||||
- 'pci_doe_for_each_off'
|
||||
- 'pcl_for_each_chunk'
|
||||
- 'pcl_for_each_segment'
|
||||
- 'pcm_for_each_format'
|
||||
|
|
14
.mailmap
14
.mailmap
|
@ -213,7 +213,10 @@ Jeff Garzik <jgarzik@pretzel.yyz.us>
|
|||
Jeff Layton <jlayton@kernel.org> <jlayton@poochiereds.net>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@primarydata.com>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@redhat.com>
|
||||
Jens Axboe <axboe@suse.de>
|
||||
Jens Axboe <axboe@kernel.dk> <axboe@suse.de>
|
||||
Jens Axboe <axboe@kernel.dk> <jens.axboe@oracle.com>
|
||||
Jens Axboe <axboe@kernel.dk> <axboe@fb.com>
|
||||
Jens Axboe <axboe@kernel.dk> <axboe@meta.com>
|
||||
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
|
||||
Jernej Skrabec <jernej.skrabec@gmail.com> <jernej.skrabec@siol.net>
|
||||
Jessica Zhang <quic_jesszhan@quicinc.com> <jesszhan@codeaurora.org>
|
||||
|
@ -328,6 +331,7 @@ Maxime Ripard <mripard@kernel.org> <maxime.ripard@bootlin.com>
|
|||
Maxime Ripard <mripard@kernel.org> <maxime.ripard@free-electrons.com>
|
||||
Mayuresh Janorkar <mayur@ti.com>
|
||||
Michael Buesch <m@bues.ch>
|
||||
Michal Simek <michal.simek@amd.com> <michal.simek@xilinx.com>
|
||||
Michel Dänzer <michel@tungstengraphics.com>
|
||||
Michel Lespinasse <michel@lespinasse.org>
|
||||
Michel Lespinasse <michel@lespinasse.org> <walken@google.com>
|
||||
|
@ -360,6 +364,12 @@ Nicolas Pitre <nico@fluxnic.net> <nico@linaro.org>
|
|||
Nicolas Saenz Julienne <nsaenz@kernel.org> <nsaenzjulienne@suse.de>
|
||||
Nicolas Saenz Julienne <nsaenz@kernel.org> <nsaenzjulienne@suse.com>
|
||||
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
|
||||
Nikolay Aleksandrov <razor@blackwall.org> <naleksan@redhat.com>
|
||||
Nikolay Aleksandrov <razor@blackwall.org> <nikolay@redhat.com>
|
||||
Nikolay Aleksandrov <razor@blackwall.org> <nikolay@cumulusnetworks.com>
|
||||
Nikolay Aleksandrov <razor@blackwall.org> <nikolay@nvidia.com>
|
||||
Nikolay Aleksandrov <razor@blackwall.org> <nikolay@isovalent.com>
|
||||
Oleksandr Natalenko <oleksandr@natalenko.name> <oleksandr@redhat.com>
|
||||
Oleksij Rempel <linux@rempel-privat.de> <bug-track@fisher-privat.net>
|
||||
Oleksij Rempel <linux@rempel-privat.de> <external.Oleksij.Rempel@de.bosch.com>
|
||||
Oleksij Rempel <linux@rempel-privat.de> <fixed-term.Oleksij.Rempel@de.bosch.com>
|
||||
|
@ -375,6 +385,8 @@ Paul E. McKenney <paulmck@kernel.org> <paul.mckenney@linaro.org>
|
|||
Paul E. McKenney <paulmck@kernel.org> <paulmck@linux.ibm.com>
|
||||
Paul E. McKenney <paulmck@kernel.org> <paulmck@linux.vnet.ibm.com>
|
||||
Paul E. McKenney <paulmck@kernel.org> <paulmck@us.ibm.com>
|
||||
Paul Mackerras <paulus@ozlabs.org> <paulus@samba.org>
|
||||
Paul Mackerras <paulus@ozlabs.org> <paulus@au1.ibm.com>
|
||||
Peter A Jonsson <pj@ludd.ltu.se>
|
||||
Peter Oruba <peter.oruba@amd.com>
|
||||
Peter Oruba <peter@oruba.de>
|
||||
|
|
13
CREDITS
13
CREDITS
|
@ -1706,6 +1706,10 @@ S: Panoramastrasse 18
|
|||
S: D-69126 Heidelberg
|
||||
S: Germany
|
||||
|
||||
N: Neil Horman
|
||||
M: nhorman@tuxdriver.com
|
||||
D: SCTP protocol maintainer.
|
||||
|
||||
N: Simon Horman
|
||||
M: horms@verge.net.au
|
||||
D: Renesas ARM/ARM64 SoC maintainer
|
||||
|
@ -2510,8 +2514,8 @@ D: XF86_8514
|
|||
D: cfdisk (curses based disk partitioning program)
|
||||
|
||||
N: Mat Martineau
|
||||
E: mat@martineau.name
|
||||
D: MPTCP subsystem co-maintainer 2020-2023
|
||||
E: martineau@kernel.org
|
||||
D: MPTCP subsystem co-maintainer
|
||||
D: Keyctl restricted keyring and Diffie-Hellman UAPI
|
||||
D: Bluetooth L2CAP ERTM mode and AMP
|
||||
S: USA
|
||||
|
@ -3475,6 +3479,11 @@ D: several improvements to system programs
|
|||
S: Oldenburg
|
||||
S: Germany
|
||||
|
||||
N: Mathieu Poirier
|
||||
E: mathieu.poirier@linaro.org
|
||||
D: CoreSight kernel subsystem, Maintainer 2014-2022
|
||||
D: Perf tool support for CoreSight
|
||||
|
||||
N: Robert Schwebel
|
||||
E: robert@schwebel.de
|
||||
W: https://www.schwebel.de
|
||||
|
|
|
@ -136,6 +136,22 @@ Description: The last executed device administrative command's status/error.
|
|||
Also last configuration error overloaded.
|
||||
Writing to it will clear the status.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/iaa_cap
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.0.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: IAA (IAX) capability mask. Exported to user space for application
|
||||
consumption. This attribute should only be visible on IAA devices
|
||||
that are version 2 or later.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/event_log_size
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.4.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The event log size to be configured. Default is 64 entries and
|
||||
occupies 4k size if the evl entry is 64 bytes. It's visible
|
||||
only on platforms that support the capability.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/block_on_fault
|
||||
Date: Oct 27, 2020
|
||||
KernelVersion: 5.11.0
|
||||
|
@ -219,6 +235,16 @@ Contact: dmaengine@vger.kernel.org
|
|||
Description: Indicate whether ATS disable is turned on for the workqueue.
|
||||
0 indicates ATS is on, and 1 indicates ATS is off for the workqueue.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/prs_disable
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.4.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Controls whether PRS disable is turned on for the workqueue.
|
||||
0 indicates PRS is on, and 1 indicates PRS is off for the
|
||||
workqueue. This option overrides block_on_fault attribute
|
||||
if set. It's visible only on platforms that support the
|
||||
capability.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/occupancy
|
||||
Date May 25, 2021
|
||||
KernelVersion: 5.14.0
|
||||
|
@ -302,3 +328,28 @@ Description: Allows control of the number of batch descriptors that can be
|
|||
1 (1/2 of max value), 2 (1/4 of the max value), and 3 (1/8 of
|
||||
the max value). It's visible only on platforms that support
|
||||
the capability.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/cr_faults
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.4.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Show the number of Completion Record (CR) faults this application
|
||||
has caused.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/cr_fault_failures
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.4.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Show the number of Completion Record (CR) faults failures that this
|
||||
application has caused. The failure counter is incremented when the
|
||||
driver cannot fault in the address for the CR. Typically this is caused
|
||||
by a bad address programmed in the submitted descriptor or a malicious
|
||||
submitter is using bad CR address on purpose.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/pid
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.4.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Show the process id of the application that opened the file. This is
|
||||
helpful information for a monitor daemon that wants to kill the
|
||||
application that opened the file.
|
||||
|
|
|
@ -76,7 +76,7 @@ Date: Dec 2014
|
|||
KernelVersion: 4.0
|
||||
Description: Default camera terminal descriptors
|
||||
|
||||
All attributes read only:
|
||||
All attributes read only except bmControls, which is read/write:
|
||||
|
||||
======================== ====================================
|
||||
bmControls bitmap specifying which controls are
|
||||
|
@ -101,7 +101,7 @@ Date: Dec 2014
|
|||
KernelVersion: 4.0
|
||||
Description: Default processing unit descriptors
|
||||
|
||||
All attributes read only:
|
||||
All attributes read only except bmControls, which is read/write:
|
||||
|
||||
=============== ========================================
|
||||
iProcessing index of string descriptor
|
||||
|
|
|
@ -0,0 +1,35 @@
|
|||
What: /sys/kernel/debug/cxl/memX/inject_poison
|
||||
Date: April, 2023
|
||||
KernelVersion: v6.4
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(WO) When a Device Physical Address (DPA) is written to this
|
||||
attribute, the memdev driver sends an inject poison command to
|
||||
the device for the specified address. The DPA must be 64-byte
|
||||
aligned and the length of the injected poison is 64-bytes. If
|
||||
successful, the device returns poison when the address is
|
||||
accessed through the CXL.mem bus. Injecting poison adds the
|
||||
address to the device's Poison List and the error source is set
|
||||
to Injected. In addition, the device adds a poison creation
|
||||
event to its internal Informational Event log, updates the
|
||||
Event Status register, and if configured, interrupts the host.
|
||||
It is not an error to inject poison into an address that
|
||||
already has poison present and no error is returned. The
|
||||
inject_poison attribute is only visible for devices supporting
|
||||
the capability.
|
||||
|
||||
|
||||
What: /sys/kernel/debug/memX/clear_poison
|
||||
Date: April, 2023
|
||||
KernelVersion: v6.4
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(WO) When a Device Physical Address (DPA) is written to this
|
||||
attribute, the memdev driver sends a clear poison command to
|
||||
the device for the specified address. Clearing poison removes
|
||||
the address from the device's Poison List and writes 0 (zero)
|
||||
for 64 bytes starting at address. It is not an error to clear
|
||||
poison from an address that does not have poison set. If the
|
||||
device cannot clear poison from the address, -ENXIO is returned.
|
||||
The clear_poison attribute is only visible for devices
|
||||
supporting the capability.
|
|
@ -0,0 +1,56 @@
|
|||
What: /sys/bus/cdx/rescan
|
||||
Date: March 2023
|
||||
Contact: nipun.gupta@amd.com
|
||||
Description:
|
||||
Writing y/1/on to this file will cause rescan of the bus
|
||||
and devices on the CDX bus. Any new devices are scanned and
|
||||
added to the list of Linux devices and any devices removed are
|
||||
also deleted from Linux.
|
||||
|
||||
For example::
|
||||
|
||||
# echo 1 > /sys/bus/cdx/rescan
|
||||
|
||||
What: /sys/bus/cdx/devices/.../vendor
|
||||
Date: March 2023
|
||||
Contact: nipun.gupta@amd.com
|
||||
Description:
|
||||
Vendor ID for this CDX device, in hexadecimal. Vendor ID is
|
||||
16 bit identifier which is specific to the device manufacturer.
|
||||
Combination of Vendor ID and Device ID identifies a device.
|
||||
|
||||
What: /sys/bus/cdx/devices/.../device
|
||||
Date: March 2023
|
||||
Contact: nipun.gupta@amd.com
|
||||
Description:
|
||||
Device ID for this CDX device, in hexadecimal. Device ID is
|
||||
16 bit identifier to identify a device type within the range
|
||||
of a device manufacturer.
|
||||
Combination of Vendor ID and Device ID identifies a device.
|
||||
|
||||
What: /sys/bus/cdx/devices/.../reset
|
||||
Date: March 2023
|
||||
Contact: nipun.gupta@amd.com
|
||||
Description:
|
||||
Writing y/1/on to this file resets the CDX device.
|
||||
On resetting the device, the corresponding driver is notified
|
||||
twice, once before the device is being reset, and again after
|
||||
the reset has been complete.
|
||||
|
||||
For example::
|
||||
|
||||
# echo 1 > /sys/bus/cdx/.../reset
|
||||
|
||||
What: /sys/bus/cdx/devices/.../remove
|
||||
Date: March 2023
|
||||
Contact: tarak.reddy@amd.com
|
||||
Description:
|
||||
Writing y/1/on to this file removes the corresponding
|
||||
device from the CDX bus. If the device is to be reconfigured
|
||||
reconfigured in the Hardware, the device can be removed, so
|
||||
that the device driver does not access the device while it is
|
||||
being reconfigured.
|
||||
|
||||
For example::
|
||||
|
||||
# echo 1 > /sys/bus/cdx/devices/.../remove
|
|
@ -1,3 +1,33 @@
|
|||
What: /sys/bus/counter/devices/counterX/cascade_counts_enable
|
||||
KernelVersion: 6.4
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Indicates the cascading of Counts on Counter X.
|
||||
|
||||
Valid attribute values are boolean.
|
||||
|
||||
What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select
|
||||
KernelVersion: 6.4
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Selects the external clock pin for phase counting mode of
|
||||
Counter X.
|
||||
|
||||
MTCLKA-MTCLKB:
|
||||
MTCLKA and MTCLKB pins are selected for the external
|
||||
phase clock.
|
||||
|
||||
MTCLKC-MTCLKD:
|
||||
MTCLKC and MTCLKD pins are selected for the external
|
||||
phase clock.
|
||||
|
||||
What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select_available
|
||||
KernelVersion: 6.4
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Discrete set of available values for the respective device
|
||||
configuration are listed in this file.
|
||||
|
||||
What: /sys/bus/counter/devices/counterX/countY/count
|
||||
KernelVersion: 5.2
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
|
@ -215,6 +245,8 @@ Contact: linux-iio@vger.kernel.org
|
|||
Description:
|
||||
This attribute indicates the number of overflows of count Y.
|
||||
|
||||
What: /sys/bus/counter/devices/counterX/cascade_counts_enable_component_id
|
||||
What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select_component_id
|
||||
What: /sys/bus/counter/devices/counterX/countY/capture_component_id
|
||||
What: /sys/bus/counter/devices/counterX/countY/ceiling_component_id
|
||||
What: /sys/bus/counter/devices/counterX/countY/floor_component_id
|
||||
|
|
|
@ -415,3 +415,17 @@ Description:
|
|||
1), and checks that the hardware accepts the commit request.
|
||||
Reading this value indicates whether the region is committed or
|
||||
not.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/memX/trigger_poison_list
|
||||
Date: April, 2023
|
||||
KernelVersion: v6.4
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(WO) When a boolean 'true' is written to this attribute the
|
||||
memdev driver retrieves the poison list from the device. The
|
||||
list consists of addresses that are poisoned, or would result
|
||||
in poison if accessed, and the source of the poison. This
|
||||
attribute is only visible for devices supporting the
|
||||
capability. The retrieved errors are logged as kernel
|
||||
events when cxl_poison event tracing is enabled.
|
||||
|
|
|
@ -1807,8 +1807,8 @@ What: /sys/bus/iio/devices/iio:deviceX/out_resistanceX_raw
|
|||
KernelVersion: 4.3
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Raw (unscaled no offset etc.) resistance reading that can be processed
|
||||
into an ohm value.
|
||||
Raw (unscaled no offset etc.) resistance reading.
|
||||
Units after application of scale and offset are ohms.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/heater_enable
|
||||
KernelVersion: 4.1.0
|
||||
|
@ -1894,8 +1894,9 @@ What: /sys/bus/iio/devices/iio:deviceX/in_electricalconductivity_raw
|
|||
KernelVersion: 4.8
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Raw (unscaled no offset etc.) electric conductivity reading that
|
||||
can be processed to siemens per meter.
|
||||
Raw (unscaled no offset etc.) electric conductivity reading.
|
||||
Units after application of scale and offset are siemens per
|
||||
meter.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_countY_raw
|
||||
KernelVersion: 4.10
|
||||
|
@ -1951,8 +1952,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_phaseY_raw
|
|||
KernelVersion: 4.18
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Raw (unscaled) phase difference reading from channel Y
|
||||
that can be processed to radians.
|
||||
Raw (unscaled) phase difference reading from channel Y.
|
||||
Units after application of scale and offset are radians.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm1_input
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm1_input
|
||||
|
|
|
@ -23,3 +23,55 @@ Description:
|
|||
Reading this attribute gives the state of the DbC. It
|
||||
can be one of the following states: disabled, enabled,
|
||||
initialized, connected, configured and stalled.
|
||||
|
||||
What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_idVendor
|
||||
Date: March 2023
|
||||
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
|
||||
Description:
|
||||
This dbc_idVendor attribute lets us change the idVendor field
|
||||
presented in the USB device descriptor by this xhci debug
|
||||
device.
|
||||
Value can only be changed while debug capability (DbC) is in
|
||||
disabled state to prevent USB device descriptor change while
|
||||
connected to a USB host.
|
||||
The default value is 0x1d6b (Linux Foundation).
|
||||
It can be any 16-bit integer.
|
||||
|
||||
What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_idProduct
|
||||
Date: March 2023
|
||||
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
|
||||
Description:
|
||||
This dbc_idProduct attribute lets us change the idProduct field
|
||||
presented in the USB device descriptor by this xhci debug
|
||||
device.
|
||||
Value can only be changed while debug capability (DbC) is in
|
||||
disabled state to prevent USB device descriptor change while
|
||||
connected to a USB host.
|
||||
The default value is 0x0010. It can be any 16-bit integer.
|
||||
|
||||
What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_bcdDevice
|
||||
Date: March 2023
|
||||
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
|
||||
Description:
|
||||
This dbc_bcdDevice attribute lets us change the bcdDevice field
|
||||
presented in the USB device descriptor by this xhci debug
|
||||
device.
|
||||
Value can only be changed while debug capability (DbC) is in
|
||||
disabled state to prevent USB device descriptor change while
|
||||
connected to a USB host.
|
||||
The default value is 0x0010. (device rev 0.10)
|
||||
It can be any 16-bit integer.
|
||||
|
||||
What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_bInterfaceProtocol
|
||||
Date: March 2023
|
||||
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
|
||||
Description:
|
||||
This attribute lets us change the bInterfaceProtocol field
|
||||
presented in the USB Interface descriptor by the xhci debug
|
||||
device.
|
||||
Value can only be changed while debug capability (DbC) is in
|
||||
disabled state to prevent USB descriptor change while
|
||||
connected to a USB host.
|
||||
The default value is 1 (GNU Remote Debug command).
|
||||
Other permissible value is 0 which is for vendor defined debug
|
||||
target.
|
||||
|
|
|
@ -234,8 +234,8 @@ Description:
|
|||
For details, see section `5.10 RAS Internal Error Register Definitions,
|
||||
Altra Family Soc BMC Interface Specification`.
|
||||
|
||||
What: /sys/bus/platform/devices/smpro-errmon.*/event_[vrd_warn_fault|vrd_hot|dimm_hot]
|
||||
KernelVersion: 6.1
|
||||
What: /sys/bus/platform/devices/smpro-errmon.*/event_[vrd_warn_fault|vrd_hot|dimm_hot|dimm_2x_refresh]
|
||||
KernelVersion: 6.1 (event_[vrd_warn_fault|vrd_hot|dimm_hot]), 6.4 (event_dimm_2x_refresh)
|
||||
Contact: Quan Nguyen <quan@os.amperecomputing.com>
|
||||
Description:
|
||||
(RO) Contains the detail information in case of VRD/DIMM warning/hot events
|
||||
|
@ -258,8 +258,21 @@ Description:
|
|||
+---------------+---------------------------------------------------------------+---------------------+
|
||||
| DIMM HOT | /sys/bus/platform/devices/smpro-errmon.*/event_dimm_hot | DIMM Hot |
|
||||
+---------------+---------------------------------------------------------------+---------------------+
|
||||
| DIMM 2X | /sys/bus/platform/devices/smpro-errmon.*/event_dimm_2x_refresh| DIMM 2x refresh rate|
|
||||
| REFRESH RATE | | event in high temp |
|
||||
+---------------+---------------------------------------------------------------+---------------------+
|
||||
|
||||
For more details, see section `5.7 GPI Status Registers,
|
||||
For more details, see section `5.7 GPI Status Registers and 5.9 Memory Error Register Definitions,
|
||||
Altra Family Soc BMC Interface Specification`.
|
||||
|
||||
What: /sys/bus/platform/devices/smpro-errmon.*/event_dimm[0-15]_syndrome
|
||||
KernelVersion: 6.4
|
||||
Contact: Quan Nguyen <quan@os.amperecomputing.com>
|
||||
Description:
|
||||
(RO) The sysfs returns the 2-byte DIMM failure syndrome data for slot
|
||||
0-15 if it failed to initialize.
|
||||
|
||||
For more details, see section `5.11 Boot Stage Register Definitions,
|
||||
Altra Family Soc BMC Interface Specification`.
|
||||
|
||||
What: /sys/bus/platform/devices/smpro-misc.*/boot_progress
|
||||
|
|
|
@ -21,4 +21,9 @@ Description:
|
|||
at the time the kernel starts are not affected or limited in
|
||||
any way by sync_state() callbacks.
|
||||
|
||||
Writing "1" to this file will force a call to the device's
|
||||
sync_state() function if it hasn't been called already. The
|
||||
sync_state() call happens independent of the state of the
|
||||
consumer devices.
|
||||
|
||||
|
||||
|
|
|
@ -0,0 +1,73 @@
|
|||
What: /sys/bus/platform/drivers/zynqmp_fpga_manager/firmware:zynqmp-firmware:pcap/status
|
||||
Date: February 2023
|
||||
KernelVersion: 6.4
|
||||
Contact: Nava kishore Manne <nava.kishore.manne@amd.com>
|
||||
Description: (RO) Read fpga status.
|
||||
Read returns a hexadecimal value that tells the current status
|
||||
of the FPGA device. Each bit position in the status value is
|
||||
described Below(see ug570 chapter 9).
|
||||
https://docs.xilinx.com/v/u/en-US/ug570-ultrascale-configuration
|
||||
|
||||
====================== ==============================================
|
||||
BIT(0) 0: No CRC error
|
||||
1: CRC error
|
||||
|
||||
BIT(1) 0: Decryptor security not set
|
||||
1: Decryptor security set
|
||||
|
||||
BIT(2) 0: MMCMs/PLLs are not locked
|
||||
1: MMCMs/PLLs are locked
|
||||
|
||||
BIT(3) 0: DCI not matched
|
||||
1: DCI matched
|
||||
|
||||
BIT(4) 0: Start-up sequence has not finished
|
||||
1: Start-up sequence has finished
|
||||
|
||||
BIT(5) 0: All I/Os are placed in High-Z state
|
||||
1: All I/Os behave as configured
|
||||
|
||||
BIT(6) 0: Flip-flops and block RAM are write disabled
|
||||
1: Flip-flops and block RAM are write enabled
|
||||
|
||||
BIT(7) 0: GHIGH_B_STATUS asserted
|
||||
1: GHIGH_B_STATUS deasserted
|
||||
|
||||
BIT(8) to BIT(10) Status of the mode pins
|
||||
|
||||
BIT(11) 0: Initialization has not finished
|
||||
1: Initialization finished
|
||||
|
||||
BIT(12) Value on INIT_B_PIN pin
|
||||
|
||||
BIT(13) 0: Signal not released
|
||||
1: Signal released
|
||||
|
||||
BIT(14) Value on DONE_PIN pin.
|
||||
|
||||
BIT(15) 0: No IDCODE_ERROR
|
||||
1: IDCODE_ERROR
|
||||
|
||||
BIT(16) 0: No SECURITY_ERROR
|
||||
1: SECURITY_ERROR
|
||||
|
||||
BIT(17) System Monitor over-temperature if set
|
||||
|
||||
BIT(18) to BIT(20) Start-up state machine (0 to 7)
|
||||
Phase 0 = 000
|
||||
Phase 1 = 001
|
||||
Phase 2 = 011
|
||||
Phase 3 = 010
|
||||
Phase 4 = 110
|
||||
Phase 5 = 111
|
||||
Phase 6 = 101
|
||||
Phase 7 = 100
|
||||
|
||||
BIT(25) to BIT(26) Indicates the detected bus width
|
||||
00 = x1
|
||||
01 = x8
|
||||
10 = x16
|
||||
11 = x32
|
||||
====================== ==============================================
|
||||
|
||||
The other bits are reserved.
|
|
@ -53,7 +53,6 @@ Description: /sys/kernel/iommu_groups/<grp_id>/type shows the type of default
|
|||
|
||||
The default domain type of a group may be modified only when
|
||||
|
||||
- The group has only one device.
|
||||
- The device in the group is not bound to any device driver.
|
||||
So, the users must unbind the appropriate driver before
|
||||
changing the default domain type.
|
||||
|
|
|
@ -51,3 +51,11 @@ Description: Control merging pages across different NUMA nodes.
|
|||
|
||||
When it is set to 0 only pages from the same node are merged,
|
||||
otherwise pages from all nodes can be merged together (default).
|
||||
|
||||
What: /sys/kernel/mm/ksm/general_profit
|
||||
Date: April 2023
|
||||
KernelVersion: 6.4
|
||||
Contact: Linux memory management mailing list <linux-mm@kvack.org>
|
||||
Description: Measure how effective KSM is.
|
||||
general_profit: how effective is KSM. The formula for the
|
||||
calculation is in Documentation/admin-guide/mm/ksm.rst.
|
||||
|
|
|
@ -16,6 +16,7 @@ d) memory reclaim
|
|||
e) thrashing
|
||||
f) direct compact
|
||||
g) write-protect copy
|
||||
h) IRQ/SOFTIRQ
|
||||
|
||||
and makes these statistics available to userspace through
|
||||
the taskstats interface.
|
||||
|
@ -49,7 +50,7 @@ this structure. See
|
|||
for a description of the fields pertaining to delay accounting.
|
||||
It will generally be in the form of counters returning the cumulative
|
||||
delay seen for cpu, sync block I/O, swapin, memory reclaim, thrash page
|
||||
cache, direct compact, write-protect copy etc.
|
||||
cache, direct compact, write-protect copy, IRQ/SOFTIRQ etc.
|
||||
|
||||
Taking the difference of two successive readings of a given
|
||||
counter (say cpu_delay_total) for a task will give the delay
|
||||
|
@ -109,17 +110,19 @@ Get sum of delays, since system boot, for all pids with tgid 5::
|
|||
CPU count real total virtual total delay total delay average
|
||||
8 7000000 6872122 3382277 0.423ms
|
||||
IO count delay total delay average
|
||||
0 0 0ms
|
||||
0 0 0.000ms
|
||||
SWAP count delay total delay average
|
||||
0 0 0ms
|
||||
0 0 0.000ms
|
||||
RECLAIM count delay total delay average
|
||||
0 0 0ms
|
||||
0 0 0.000ms
|
||||
THRASHING count delay total delay average
|
||||
0 0 0ms
|
||||
0 0 0.000ms
|
||||
COMPACT count delay total delay average
|
||||
0 0 0ms
|
||||
WPCOPY count delay total delay average
|
||||
0 0 0ms
|
||||
0 0 0.000ms
|
||||
WPCOPY count delay total delay average
|
||||
0 0 0.000ms
|
||||
IRQ count delay total delay average
|
||||
0 0 0.000ms
|
||||
|
||||
Get IO accounting for pid 1, it works only with -p::
|
||||
|
||||
|
|
|
@ -105,6 +105,10 @@ prevent overly frequent polling. Max limit is chosen as a high enough number
|
|||
after which monitors are most likely not needed and psi averages can be used
|
||||
instead.
|
||||
|
||||
Unprivileged users can also create monitors, with the only limitation that the
|
||||
window size must be a multiple of 2s, in order to prevent excessive resource
|
||||
usage.
|
||||
|
||||
When activated, psi monitor stays active for at least the duration of one
|
||||
tracking window to avoid repeated activations/deactivations when system is
|
||||
bouncing in and out of the stall state.
|
||||
|
|
|
@ -14,7 +14,7 @@ to borrow disk space from another computer.
|
|||
Unlike NFS, it is possible to put any filesystem on it, etc.
|
||||
|
||||
For more information, or to download the nbd-client and nbd-server
|
||||
tools, go to http://nbd.sf.net/.
|
||||
tools, go to https://github.com/NetworkBlockDevice/nbd.
|
||||
|
||||
The nbd kernel module need only be installed on the client
|
||||
system, as the nbd-server is completely in userspace. In fact,
|
||||
|
|
|
@ -719,7 +719,7 @@ There are ways to query or modify cpusets:
|
|||
cat, rmdir commands from the shell, or their equivalent from C.
|
||||
- via the C library libcpuset.
|
||||
- via the C library libcgroup.
|
||||
(http://sourceforge.net/projects/libcg/)
|
||||
(https://github.com/libcgroup/libcgroup/)
|
||||
- via the python application cset.
|
||||
(http://code.google.com/p/cpuset/)
|
||||
|
||||
|
|
|
@ -5,5 +5,5 @@ Changes
|
|||
See https://wiki.samba.org/index.php/LinuxCIFSKernel for summary
|
||||
information about fixes/improvements to CIFS/SMB2/SMB3 support (changes
|
||||
to cifs.ko module) by kernel version (and cifs internal module version).
|
||||
This may be easier to read than parsing the output of "git log fs/cifs"
|
||||
by release.
|
||||
This may be easier to read than parsing the output of
|
||||
"git log fs/smb/client" by release.
|
||||
|
|
|
@ -45,7 +45,7 @@ Installation instructions
|
|||
|
||||
If you have built the CIFS vfs as module (successfully) simply
|
||||
type ``make modules_install`` (or if you prefer, manually copy the file to
|
||||
the modules directory e.g. /lib/modules/2.4.10-4GB/kernel/fs/cifs/cifs.ko).
|
||||
the modules directory e.g. /lib/modules/6.3.0-060300-generic/kernel/fs/smb/client/cifs.ko).
|
||||
|
||||
If you have built the CIFS vfs into the kernel itself, follow the instructions
|
||||
for your distribution on how to install a new kernel (usually you
|
||||
|
@ -66,15 +66,15 @@ If cifs is built as a module, then the size and number of network buffers
|
|||
and maximum number of simultaneous requests to one server can be configured.
|
||||
Changing these from their defaults is not recommended. By executing modinfo::
|
||||
|
||||
modinfo kernel/fs/cifs/cifs.ko
|
||||
modinfo <path to cifs.ko>
|
||||
|
||||
on kernel/fs/cifs/cifs.ko the list of configuration changes that can be made
|
||||
on kernel/fs/smb/client/cifs.ko the list of configuration changes that can be made
|
||||
at module initialization time (by running insmod cifs.ko) can be seen.
|
||||
|
||||
Recommendations
|
||||
===============
|
||||
|
||||
To improve security the SMB2.1 dialect or later (usually will get SMB3) is now
|
||||
To improve security the SMB2.1 dialect or later (usually will get SMB3.1.1) is now
|
||||
the new default. To use old dialects (e.g. to mount Windows XP) use "vers=1.0"
|
||||
on mount (or vers=2.0 for Windows Vista). Note that the CIFS (vers=1.0) is
|
||||
much older and less secure than the default dialect SMB3 which includes
|
||||
|
|
|
@ -172,7 +172,7 @@ variables.
|
|||
Offset of the free_list's member. This value is used to compute the number
|
||||
of free pages.
|
||||
|
||||
Each zone has a free_area structure array called free_area[MAX_ORDER].
|
||||
Each zone has a free_area structure array called free_area[MAX_ORDER + 1].
|
||||
The free_list represents a linked list of free page blocks.
|
||||
|
||||
(list_head, next|prev)
|
||||
|
@ -189,8 +189,8 @@ Offsets of the vmap_area's members. They carry vmalloc-specific
|
|||
information. Makedumpfile gets the start address of the vmalloc region
|
||||
from this.
|
||||
|
||||
(zone.free_area, MAX_ORDER)
|
||||
---------------------------
|
||||
(zone.free_area, MAX_ORDER + 1)
|
||||
-------------------------------
|
||||
|
||||
Free areas descriptor. User-space tools use this value to iterate the
|
||||
free_area ranges. MAX_ORDER is used by the zone buddy allocator.
|
||||
|
|
|
@ -912,15 +912,14 @@
|
|||
cs89x0_media= [HW,NET]
|
||||
Format: { rj45 | aui | bnc }
|
||||
|
||||
csdlock_debug= [KNL] Enable debug add-ons of cross-CPU function call
|
||||
handling. When switched on, additional debug data is
|
||||
printed to the console in case a hanging CPU is
|
||||
detected, and that CPU is pinged again in order to try
|
||||
to resolve the hang situation.
|
||||
0: disable csdlock debugging (default)
|
||||
1: enable basic csdlock debugging (minor impact)
|
||||
ext: enable extended csdlock debugging (more impact,
|
||||
but more data)
|
||||
csdlock_debug= [KNL] Enable or disable debug add-ons of cross-CPU
|
||||
function call handling. When switched on,
|
||||
additional debug data is printed to the console
|
||||
in case a hanging CPU is detected, and that
|
||||
CPU is pinged again in order to try to resolve
|
||||
the hang situation. The default value of this
|
||||
option depends on the CSD_LOCK_WAIT_DEBUG_DEFAULT
|
||||
Kconfig option.
|
||||
|
||||
dasd= [HW,NET]
|
||||
See header of drivers/s390/block/dasd_devmap.c.
|
||||
|
@ -1602,6 +1601,20 @@
|
|||
dependencies. This only applies for fw_devlink=on|rpm.
|
||||
Format: <bool>
|
||||
|
||||
fw_devlink.sync_state =
|
||||
[KNL] When all devices that could probe have finished
|
||||
probing, this parameter controls what to do with
|
||||
devices that haven't yet received their sync_state()
|
||||
calls.
|
||||
Format: { strict | timeout }
|
||||
strict -- Default. Continue waiting on consumers to
|
||||
probe successfully.
|
||||
timeout -- Give up waiting on consumers and call
|
||||
sync_state() on any devices that haven't yet
|
||||
received their sync_state() calls after
|
||||
deferred_probe_timeout has expired or by
|
||||
late_initcall() if !CONFIG_MODULES.
|
||||
|
||||
gamecon.map[2|3]=
|
||||
[HW,JOY] Multisystem joystick and NES/SNES/PSX pad
|
||||
support via parallel port (up to 5 devices per port)
|
||||
|
@ -3349,6 +3362,12 @@
|
|||
specified, <module>.async_probe takes precedence for
|
||||
the specific module.
|
||||
|
||||
module.enable_dups_trace
|
||||
[KNL] When CONFIG_MODULE_DEBUG_AUTOLOAD_DUPS is set,
|
||||
this means that duplicate request_module() calls will
|
||||
trigger a WARN_ON() instead of a pr_warn(). Note that
|
||||
if MODULE_DEBUG_AUTOLOAD_DUPS_TRACE is set, WARN_ON()s
|
||||
will always be issued and this option does nothing.
|
||||
module.sig_enforce
|
||||
[KNL] When CONFIG_MODULE_SIG is set, this means that
|
||||
modules without (valid) signatures will fail to load.
|
||||
|
@ -3593,7 +3612,10 @@
|
|||
emulation library even if a 387 maths coprocessor
|
||||
is present.
|
||||
|
||||
no5lvl [X86-64] Disable 5-level paging mode. Forces
|
||||
no4lvl [RISCV] Disable 4-level and 5-level paging modes. Forces
|
||||
kernel to use 3-level paging instead.
|
||||
|
||||
no5lvl [X86-64,RISCV] Disable 5-level paging mode. Forces
|
||||
kernel to use 4-level paging instead.
|
||||
|
||||
noaliencache [MM, NUMA, SLAB] Disables the allocation of alien
|
||||
|
@ -3992,7 +4014,7 @@
|
|||
[KNL] Minimal page reporting order
|
||||
Format: <integer>
|
||||
Adjust the minimal page reporting order. The page
|
||||
reporting is disabled when it exceeds (MAX_ORDER-1).
|
||||
reporting is disabled when it exceeds MAX_ORDER.
|
||||
|
||||
panic= [KNL] Kernel behaviour on panic: delay <timeout>
|
||||
timeout > 0: seconds before rebooting
|
||||
|
@ -6150,15 +6172,6 @@
|
|||
later by a loaded module cannot be set this way.
|
||||
Example: sysctl.vm.swappiness=40
|
||||
|
||||
sysfs.deprecated=0|1 [KNL]
|
||||
Enable/disable old style sysfs layout for old udev
|
||||
on older distributions. When this option is enabled
|
||||
very new udev will not work anymore. When this option
|
||||
is disabled (or CONFIG_SYSFS_DEPRECATED not compiled)
|
||||
in older udev will not work anymore.
|
||||
Default depends on CONFIG_SYSFS_DEPRECATED_V2 set in
|
||||
the kernel configuration.
|
||||
|
||||
sysrq_always_enabled
|
||||
[KNL]
|
||||
Ignore sysrq setting - this boot parameter will
|
||||
|
|
|
@ -20,7 +20,7 @@ content which can be replaced by a single write-protected page (which
|
|||
is automatically copied if a process later wants to update its
|
||||
content). The amount of pages that KSM daemon scans in a single pass
|
||||
and the time between the passes are configured using :ref:`sysfs
|
||||
intraface <ksm_sysfs>`
|
||||
interface <ksm_sysfs>`
|
||||
|
||||
KSM only merges anonymous (private) pages, never pagecache (file) pages.
|
||||
KSM's merged pages were originally locked into kernel memory, but can now
|
||||
|
@ -157,6 +157,8 @@ stable_node_chains_prune_millisecs
|
|||
|
||||
The effectiveness of KSM and MADV_MERGEABLE is shown in ``/sys/kernel/mm/ksm/``:
|
||||
|
||||
general_profit
|
||||
how effective is KSM. The calculation is explained below.
|
||||
pages_shared
|
||||
how many shared pages are being used
|
||||
pages_sharing
|
||||
|
@ -207,7 +209,8 @@ several times, which are unprofitable memory consumed.
|
|||
ksm_rmap_items * sizeof(rmap_item).
|
||||
|
||||
where ksm_merging_pages is shown under the directory ``/proc/<pid>/``,
|
||||
and ksm_rmap_items is shown in ``/proc/<pid>/ksm_stat``.
|
||||
and ksm_rmap_items is shown in ``/proc/<pid>/ksm_stat``. The process profit
|
||||
is also shown in ``/proc/<pid>/ksm_stat`` as ksm_process_profit.
|
||||
|
||||
From the perspective of application, a high ratio of ``ksm_rmap_items`` to
|
||||
``ksm_merging_pages`` means a bad madvise-applied policy, so developers or
|
||||
|
|
|
@ -219,6 +219,31 @@ former will have ``UFFD_PAGEFAULT_FLAG_WP`` set, the latter
|
|||
you still need to supply a page when ``UFFDIO_REGISTER_MODE_MISSING`` was
|
||||
used.
|
||||
|
||||
Userfaultfd write-protect mode currently behave differently on none ptes
|
||||
(when e.g. page is missing) over different types of memories.
|
||||
|
||||
For anonymous memory, ``ioctl(UFFDIO_WRITEPROTECT)`` will ignore none ptes
|
||||
(e.g. when pages are missing and not populated). For file-backed memories
|
||||
like shmem and hugetlbfs, none ptes will be write protected just like a
|
||||
present pte. In other words, there will be a userfaultfd write fault
|
||||
message generated when writing to a missing page on file typed memories,
|
||||
as long as the page range was write-protected before. Such a message will
|
||||
not be generated on anonymous memories by default.
|
||||
|
||||
If the application wants to be able to write protect none ptes on anonymous
|
||||
memory, one can pre-populate the memory with e.g. MADV_POPULATE_READ. On
|
||||
newer kernels, one can also detect the feature UFFD_FEATURE_WP_UNPOPULATED
|
||||
and set the feature bit in advance to make sure none ptes will also be
|
||||
write protected even upon anonymous memory.
|
||||
|
||||
When using ``UFFDIO_REGISTER_MODE_WP`` in combination with either
|
||||
``UFFDIO_REGISTER_MODE_MISSING`` or ``UFFDIO_REGISTER_MODE_MINOR``, when
|
||||
resolving missing / minor faults with ``UFFDIO_COPY`` or ``UFFDIO_CONTINUE``
|
||||
respectively, it may be desirable for the new page / mapping to be
|
||||
write-protected (so future writes will also result in a WP fault). These ioctls
|
||||
support a mode flag (``UFFDIO_COPY_MODE_WP`` or ``UFFDIO_CONTINUE_MODE_WP``
|
||||
respectively) to configure the mapping this way.
|
||||
|
||||
QEMU/KVM
|
||||
========
|
||||
|
||||
|
|
|
@ -215,12 +215,14 @@ again.
|
|||
reduce the compile time enormously, especially if you are running an
|
||||
universal kernel from a commodity Linux distribution.
|
||||
|
||||
There is a catch: the make target 'localmodconfig' will disable kernel
|
||||
features you have not directly or indirectly through some program utilized
|
||||
since you booted the system. You can reduce or nearly eliminate that risk by
|
||||
using tricks outlined in the reference section; for quick testing purposes
|
||||
that risk is often negligible, but it is an aspect you want to keep in mind
|
||||
in case your kernel behaves oddly.
|
||||
There is a catch: 'localmodconfig' is likely to disable kernel features you
|
||||
did not use since you booted your Linux -- like drivers for currently
|
||||
disconnected peripherals or a virtualization software not haven't used yet.
|
||||
You can reduce or nearly eliminate that risk with tricks the reference
|
||||
section outlines; but when building a kernel just for quick testing purposes
|
||||
it is often negligible if such features are missing. But you should keep that
|
||||
aspect in mind when using a kernel built with this make target, as it might
|
||||
be the reason why something you only use occasionally stopped working.
|
||||
|
||||
[:ref:`details<configuration>`]
|
||||
|
||||
|
@ -271,6 +273,9 @@ again.
|
|||
does nothing at all; in that case you have to manually install your kernel,
|
||||
as outlined in the reference section.
|
||||
|
||||
If you are running a immutable Linux distribution, check its documentation
|
||||
and the web to find out how to install your own kernel there.
|
||||
|
||||
[:ref:`details<install>`]
|
||||
|
||||
.. _another_sbs:
|
||||
|
@ -291,29 +296,29 @@ again.
|
|||
version you care about, as git otherwise might retrieve the entire commit
|
||||
history::
|
||||
|
||||
git fetch --shallow-exclude=v6.1 origin
|
||||
git fetch --shallow-exclude=v6.0 origin
|
||||
|
||||
If you modified the sources (for example by applying a patch), you now need
|
||||
to discard those modifications; that's because git otherwise will not be able
|
||||
to switch to the sources of another version due to potential conflicting
|
||||
changes::
|
||||
Now switch to the version you are interested in -- but be aware the command
|
||||
used here will discard any modifications you performed, as they would
|
||||
conflict with the sources you want to checkout::
|
||||
|
||||
git reset --hard
|
||||
|
||||
Now checkout the version you are interested in, as explained above::
|
||||
|
||||
git checkout --detach origin/master
|
||||
git checkout --force --detach origin/master
|
||||
|
||||
At this point you might want to patch the sources again or set/modify a build
|
||||
tag, as explained earlier; afterwards adjust the build configuration to the
|
||||
new codebase and build your next kernel::
|
||||
tag, as explained earlier. Afterwards adjust the build configuration to the
|
||||
new codebase using olddefconfig, which will now adjust the configuration file
|
||||
you prepared earlier using localmodconfig (~/linux/.config) for your next
|
||||
kernel::
|
||||
|
||||
# reminder: if you want to apply patches, do it at this point
|
||||
# reminder: you might want to update your build tag at this point
|
||||
make olddefconfig
|
||||
|
||||
Now build your kernel::
|
||||
|
||||
make -j $(nproc --all)
|
||||
|
||||
Install the kernel as outlined above::
|
||||
Afterwards install the kernel as outlined above::
|
||||
|
||||
command -v installkernel && sudo make modules_install install
|
||||
|
||||
|
@ -584,11 +589,11 @@ versions and individual commits at hand at any time::
|
|||
curl -L \
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/clone.bundle \
|
||||
-o linux-stable.git.bundle
|
||||
git clone clone.bundle ~/linux/
|
||||
git clone linux-stable.git.bundle ~/linux/
|
||||
rm linux-stable.git.bundle
|
||||
cd ~/linux/
|
||||
git remote set-url origin
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
|
||||
git remote set-url origin \
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
|
||||
git fetch origin
|
||||
git checkout --detach origin/master
|
||||
|
||||
|
|
|
@ -33,8 +33,11 @@ The format of this option is::
|
|||
9600n8. The maximum baudrate is 115200.
|
||||
|
||||
You can specify multiple console= options on the kernel command line.
|
||||
Output will appear on all of them. The last device will be used when
|
||||
you open ``/dev/console``. So, for example::
|
||||
|
||||
The behavior is well defined when each device type is mentioned only once.
|
||||
In this case, the output will appear on all requested consoles. And
|
||||
the last device will be used when you open ``/dev/console``.
|
||||
So, for example::
|
||||
|
||||
console=ttyS1,9600 console=tty0
|
||||
|
||||
|
@ -42,7 +45,34 @@ defines that opening ``/dev/console`` will get you the current foreground
|
|||
virtual console, and kernel messages will appear on both the VGA
|
||||
console and the 2nd serial port (ttyS1 or COM2) at 9600 baud.
|
||||
|
||||
Note that you can only define one console per device type (serial, video).
|
||||
The behavior is more complicated when the same device type is defined more
|
||||
times. In this case, there are the following two rules:
|
||||
|
||||
1. The output will appear only on the first device of each defined type.
|
||||
|
||||
2. ``/dev/console`` will be associated with the first registered device.
|
||||
Where the registration order depends on how kernel initializes various
|
||||
subsystems.
|
||||
|
||||
This rule is used also when the last console= parameter is not used
|
||||
for other reasons. For example, because of a typo or because
|
||||
the hardware is not available.
|
||||
|
||||
The result might be surprising. For example, the following two command
|
||||
lines have the same result:
|
||||
|
||||
console=ttyS1,9600 console=tty0 console=tty1
|
||||
console=tty0 console=ttyS1,9600 console=tty1
|
||||
|
||||
The kernel messages are printed only on ``tty0`` and ``ttyS1``. And
|
||||
``/dev/console`` gets associated with ``tty0``. It is because kernel
|
||||
tries to register graphical consoles before serial ones. It does it
|
||||
because of the default behavior when no console device is specified,
|
||||
see below.
|
||||
|
||||
Note that the last ``console=tty1`` parameter still makes a difference.
|
||||
The kernel command line is used also by systemd. It would use the last
|
||||
defined ``tty1`` as the login console.
|
||||
|
||||
If no console device is specified, the first device found capable of
|
||||
acting as a system console will be used. At this time, the system
|
||||
|
|
|
@ -236,13 +236,14 @@ the dates listed above.
|
|||
Deprecated Mount Options
|
||||
========================
|
||||
|
||||
=========================== ================
|
||||
============================ ================
|
||||
Name Removal Schedule
|
||||
=========================== ================
|
||||
============================ ================
|
||||
Mounting with V4 filesystem September 2030
|
||||
Mounting ascii-ci filesystem September 2030
|
||||
ikeep/noikeep September 2025
|
||||
attr2/noattr2 September 2025
|
||||
=========================== ================
|
||||
============================ ================
|
||||
|
||||
|
||||
Removed Mount Options
|
||||
|
|
|
@ -12,7 +12,7 @@ Most of the text from Keith Owens, hacked by AK
|
|||
x86_64 page size (PAGE_SIZE) is 4K.
|
||||
|
||||
Like all other architectures, x86_64 has a kernel stack for every
|
||||
active thread. These thread stacks are THREAD_SIZE (2*PAGE_SIZE) big.
|
||||
active thread. These thread stacks are THREAD_SIZE (4*PAGE_SIZE) big.
|
||||
These stacks contain useful data as long as a thread is alive or a
|
||||
zombie. While the thread is in user space the kernel stack is empty
|
||||
except for the thread_info structure at the bottom.
|
||||
|
|
|
@ -107,7 +107,7 @@ process share the same page tables, thus the same MSR value.
|
|||
PASID Life Cycle Management
|
||||
===========================
|
||||
|
||||
PASID is initialized as INVALID_IOASID (-1) when a process is created.
|
||||
PASID is initialized as IOMMU_PASID_INVALID (-1) when a process is created.
|
||||
|
||||
Only processes that access SVA-capable devices need to have a PASID
|
||||
allocated. This allocation happens when a process opens/binds an SVA-capable
|
||||
|
|
|
@ -11,6 +11,22 @@ are enabled by XCR0 as well, but the first use of related instruction is
|
|||
trapped by the kernel because by default the required large XSTATE buffers
|
||||
are not allocated automatically.
|
||||
|
||||
The purpose for dynamic features
|
||||
--------------------------------
|
||||
|
||||
Legacy userspace libraries often have hard-coded, static sizes for
|
||||
alternate signal stacks, often using MINSIGSTKSZ which is typically 2KB.
|
||||
That stack must be able to store at *least* the signal frame that the
|
||||
kernel sets up before jumping into the signal handler. That signal frame
|
||||
must include an XSAVE buffer defined by the CPU.
|
||||
|
||||
However, that means that the size of signal stacks is dynamic, not static,
|
||||
because different CPUs have differently-sized XSAVE buffers. A compiled-in
|
||||
size of 2KB with existing applications is too small for new CPU features
|
||||
like AMX. Instead of universally requiring larger stack, with the dynamic
|
||||
enabling, the kernel can enforce userspace applications to have
|
||||
properly-sized altstacks.
|
||||
|
||||
Using dynamically enabled XSTATE features in user space applications
|
||||
--------------------------------------------------------------------
|
||||
|
||||
|
@ -64,6 +80,61 @@ the handler allocates a larger xstate buffer for the task so the large
|
|||
state can be context switched. In the unlikely cases that the allocation
|
||||
fails, the kernel sends SIGSEGV.
|
||||
|
||||
AMX TILE_DATA enabling example
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Below is the example of how userspace applications enable
|
||||
TILE_DATA dynamically:
|
||||
|
||||
1. The application first needs to query the kernel for AMX
|
||||
support::
|
||||
|
||||
#include <asm/prctl.h>
|
||||
#include <sys/syscall.h>
|
||||
#include <stdio.h>
|
||||
#include <unistd.h>
|
||||
|
||||
#ifndef ARCH_GET_XCOMP_SUPP
|
||||
#define ARCH_GET_XCOMP_SUPP 0x1021
|
||||
#endif
|
||||
|
||||
#ifndef ARCH_XCOMP_TILECFG
|
||||
#define ARCH_XCOMP_TILECFG 17
|
||||
#endif
|
||||
|
||||
#ifndef ARCH_XCOMP_TILEDATA
|
||||
#define ARCH_XCOMP_TILEDATA 18
|
||||
#endif
|
||||
|
||||
#define MASK_XCOMP_TILE ((1 << ARCH_XCOMP_TILECFG) | \
|
||||
(1 << ARCH_XCOMP_TILEDATA))
|
||||
|
||||
unsigned long features;
|
||||
long rc;
|
||||
|
||||
...
|
||||
|
||||
rc = syscall(SYS_arch_prctl, ARCH_GET_XCOMP_SUPP, &features);
|
||||
|
||||
if (!rc && (features & MASK_XCOMP_TILE) == MASK_XCOMP_TILE)
|
||||
printf("AMX is available.\n");
|
||||
|
||||
2. After that, determining support for AMX, an application must
|
||||
explicitly ask permission to use it::
|
||||
|
||||
#ifndef ARCH_REQ_XCOMP_PERM
|
||||
#define ARCH_REQ_XCOMP_PERM 0x1023
|
||||
#endif
|
||||
|
||||
...
|
||||
|
||||
rc = syscall(SYS_arch_prctl, ARCH_REQ_XCOMP_PERM, ARCH_XCOMP_TILEDATA);
|
||||
|
||||
if (!rc)
|
||||
printf("AMX is ready for use.\n");
|
||||
|
||||
Note this example does not include the sigaltstack preparation.
|
||||
|
||||
Dynamic features in signal frames
|
||||
---------------------------------
|
||||
|
||||
|
@ -72,3 +143,32 @@ entry if the feature is in its initial configuration. This differs from
|
|||
non-dynamic features which are always written regardless of their
|
||||
configuration. Signal handlers can examine the XSAVE buffer's XSTATE_BV
|
||||
field to determine if a features was written.
|
||||
|
||||
Dynamic features for virtual machines
|
||||
-------------------------------------
|
||||
|
||||
The permission for the guest state component needs to be managed separately
|
||||
from the host, as they are exclusive to each other. A coupled of options
|
||||
are extended to control the guest permission:
|
||||
|
||||
-ARCH_GET_XCOMP_GUEST_PERM
|
||||
|
||||
arch_prctl(ARCH_GET_XCOMP_GUEST_PERM, &features);
|
||||
|
||||
ARCH_GET_XCOMP_GUEST_PERM is a variant of ARCH_GET_XCOMP_PERM. So it
|
||||
provides the same semantics and functionality but for the guest
|
||||
components.
|
||||
|
||||
-ARCH_REQ_XCOMP_GUEST_PERM
|
||||
|
||||
arch_prctl(ARCH_REQ_XCOMP_GUEST_PERM, feature_nr);
|
||||
|
||||
ARCH_REQ_XCOMP_GUEST_PERM is a variant of ARCH_REQ_XCOMP_PERM. It has the
|
||||
same semantics for the guest permission. While providing a similar
|
||||
functionality, this comes with a constraint. Permission is frozen when the
|
||||
first VCPU is created. Any attempt to change permission after that point
|
||||
is going to be rejected. So, the permission has to be requested before the
|
||||
first VCPU creation.
|
||||
|
||||
Note that some VMMs may have already established a set of supported state
|
||||
components. These options are not presumed to support any particular VMM.
|
||||
|
|
|
@ -18,7 +18,6 @@ Block
|
|||
kyber-iosched
|
||||
null_blk
|
||||
pr
|
||||
request
|
||||
stat
|
||||
switching-sched
|
||||
writeback_cache_control
|
||||
|
|
|
@ -1,99 +0,0 @@
|
|||
============================
|
||||
struct request documentation
|
||||
============================
|
||||
|
||||
Jens Axboe <jens.axboe@oracle.com> 27/05/02
|
||||
|
||||
|
||||
.. FIXME:
|
||||
No idea about what does mean - seems just some noise, so comment it
|
||||
|
||||
1.0
|
||||
Index
|
||||
|
||||
2.0 Struct request members classification
|
||||
|
||||
2.1 struct request members explanation
|
||||
|
||||
3.0
|
||||
|
||||
|
||||
2.0
|
||||
|
||||
|
||||
|
||||
Short explanation of request members
|
||||
====================================
|
||||
|
||||
Classification flags:
|
||||
|
||||
= ====================
|
||||
D driver member
|
||||
B block layer member
|
||||
I I/O scheduler member
|
||||
= ====================
|
||||
|
||||
Unless an entry contains a D classification, a device driver must not access
|
||||
this member. Some members may contain D classifications, but should only be
|
||||
access through certain macros or functions (eg ->flags).
|
||||
|
||||
<linux/blkdev.h>
|
||||
|
||||
=============================== ======= =======================================
|
||||
Member Flag Comment
|
||||
=============================== ======= =======================================
|
||||
struct list_head queuelist BI Organization on various internal
|
||||
queues
|
||||
|
||||
``void *elevator_private`` I I/O scheduler private data
|
||||
|
||||
unsigned char cmd[16] D Driver can use this for setting up
|
||||
a cdb before execution, see
|
||||
blk_queue_prep_rq
|
||||
|
||||
unsigned long flags DBI Contains info about data direction,
|
||||
request type, etc.
|
||||
|
||||
int rq_status D Request status bits
|
||||
|
||||
kdev_t rq_dev DBI Target device
|
||||
|
||||
int errors DB Error counts
|
||||
|
||||
sector_t sector DBI Target location
|
||||
|
||||
unsigned long hard_nr_sectors B Used to keep sector sane
|
||||
|
||||
unsigned long nr_sectors DBI Total number of sectors in request
|
||||
|
||||
unsigned long hard_nr_sectors B Used to keep nr_sectors sane
|
||||
|
||||
unsigned short nr_phys_segments DB Number of physical scatter gather
|
||||
segments in a request
|
||||
|
||||
unsigned short nr_hw_segments DB Number of hardware scatter gather
|
||||
segments in a request
|
||||
|
||||
unsigned int current_nr_sectors DB Number of sectors in first segment
|
||||
of request
|
||||
|
||||
unsigned int hard_cur_sectors B Used to keep current_nr_sectors sane
|
||||
|
||||
int tag DB TCQ tag, if assigned
|
||||
|
||||
``void *special`` D Free to be used by driver
|
||||
|
||||
``char *buffer`` D Map of first segment, also see
|
||||
section on bouncing SECTION
|
||||
|
||||
``struct completion *waiting`` D Can be used by driver to get signalled
|
||||
on request completion
|
||||
|
||||
``struct bio *bio`` DBI First bio in request
|
||||
|
||||
``struct bio *biotail`` DBI Last bio in request
|
||||
|
||||
``struct request_queue *q`` DB Request queue this request belongs to
|
||||
|
||||
``struct request_list *rl`` B Request list this request came from
|
||||
=============================== ======= =======================================
|
|
@ -18,7 +18,7 @@ LSM hook:
|
|||
.. c:function:: int file_mprotect(struct vm_area_struct *vma, unsigned long reqprot, unsigned long prot);
|
||||
|
||||
Other LSM hooks which can be instrumented can be found in
|
||||
``include/linux/lsm_hooks.h``.
|
||||
``security/security.c``.
|
||||
|
||||
eBPF programs that use Documentation/bpf/btf.rst do not need to include kernel
|
||||
headers for accessing information from the attached eBPF program's context.
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=====
|
||||
cdrom
|
||||
=====
|
||||
======
|
||||
CD-ROM
|
||||
======
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
|
|
@ -220,12 +220,30 @@ relay interface
|
|||
Module Support
|
||||
==============
|
||||
|
||||
Module Loading
|
||||
--------------
|
||||
Kernel module auto-loading
|
||||
--------------------------
|
||||
|
||||
.. kernel-doc:: kernel/kmod.c
|
||||
.. kernel-doc:: kernel/module/kmod.c
|
||||
:export:
|
||||
|
||||
Module debugging
|
||||
----------------
|
||||
|
||||
.. kernel-doc:: kernel/module/stats.c
|
||||
:doc: module debugging statistics overview
|
||||
|
||||
dup_failed_modules - tracks duplicate failed modules
|
||||
****************************************************
|
||||
|
||||
.. kernel-doc:: kernel/module/stats.c
|
||||
:doc: dup_failed_modules - tracks duplicate failed modules
|
||||
|
||||
module statistics debugfs counters
|
||||
**********************************
|
||||
|
||||
.. kernel-doc:: kernel/module/stats.c
|
||||
:doc: module statistics debugfs counters
|
||||
|
||||
Inter Module support
|
||||
--------------------
|
||||
|
||||
|
|
|
@ -575,20 +575,26 @@ The field width is passed by value, the bitmap is passed by reference.
|
|||
Helper macros cpumask_pr_args() and nodemask_pr_args() are available to ease
|
||||
printing cpumask and nodemask.
|
||||
|
||||
Flags bitfields such as page flags, gfp_flags
|
||||
---------------------------------------------
|
||||
Flags bitfields such as page flags, page_type, gfp_flags
|
||||
--------------------------------------------------------
|
||||
|
||||
::
|
||||
|
||||
%pGp 0x17ffffc0002036(referenced|uptodate|lru|active|private|node=0|zone=2|lastcpupid=0x1fffff)
|
||||
%pGt 0xffffff7f(buddy)
|
||||
%pGg GFP_USER|GFP_DMA32|GFP_NOWARN
|
||||
%pGv read|exec|mayread|maywrite|mayexec|denywrite
|
||||
|
||||
For printing flags bitfields as a collection of symbolic constants that
|
||||
would construct the value. The type of flags is given by the third
|
||||
character. Currently supported are [p]age flags, [v]ma_flags (both
|
||||
expect ``unsigned long *``) and [g]fp_flags (expects ``gfp_t *``). The flag
|
||||
names and print order depends on the particular type.
|
||||
character. Currently supported are:
|
||||
|
||||
- p - [p]age flags, expects value of type (``unsigned long *``)
|
||||
- t - page [t]ype, expects value of type (``unsigned int *``)
|
||||
- v - [v]ma_flags, expects value of type (``unsigned long *``)
|
||||
- g - [g]fp_flags, expects value of type (``gfp_t *``)
|
||||
|
||||
The flag names and print order depends on the particular type.
|
||||
|
||||
Note that this format should not be used directly in the
|
||||
:c:func:`TP_printk()` part of a tracepoint. Instead, use the show_*_flags()
|
||||
|
|
|
@ -1,42 +1,50 @@
|
|||
kcov: code coverage for fuzzing
|
||||
KCOV: code coverage for fuzzing
|
||||
===============================
|
||||
|
||||
kcov exposes kernel code coverage information in a form suitable for coverage-
|
||||
guided fuzzing (randomized testing). Coverage data of a running kernel is
|
||||
exported via the "kcov" debugfs file. Coverage collection is enabled on a task
|
||||
basis, and thus it can capture precise coverage of a single system call.
|
||||
KCOV collects and exposes kernel code coverage information in a form suitable
|
||||
for coverage-guided fuzzing. Coverage data of a running kernel is exported via
|
||||
the ``kcov`` debugfs file. Coverage collection is enabled on a task basis, and
|
||||
thus KCOV can capture precise coverage of a single system call.
|
||||
|
||||
Note that kcov does not aim to collect as much coverage as possible. It aims
|
||||
to collect more or less stable coverage that is function of syscall inputs.
|
||||
To achieve this goal it does not collect coverage in soft/hard interrupts
|
||||
and instrumentation of some inherently non-deterministic parts of kernel is
|
||||
disabled (e.g. scheduler, locking).
|
||||
Note that KCOV does not aim to collect as much coverage as possible. It aims
|
||||
to collect more or less stable coverage that is a function of syscall inputs.
|
||||
To achieve this goal, it does not collect coverage in soft/hard interrupts
|
||||
(unless remove coverage collection is enabled, see below) and from some
|
||||
inherently non-deterministic parts of the kernel (e.g. scheduler, locking).
|
||||
|
||||
kcov is also able to collect comparison operands from the instrumented code
|
||||
(this feature currently requires that the kernel is compiled with clang).
|
||||
Besides collecting code coverage, KCOV can also collect comparison operands.
|
||||
See the "Comparison operands collection" section for details.
|
||||
|
||||
Besides collecting coverage data from syscall handlers, KCOV can also collect
|
||||
coverage for annotated parts of the kernel executing in background kernel
|
||||
tasks or soft interrupts. See the "Remote coverage collection" section for
|
||||
details.
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
Configure the kernel with::
|
||||
KCOV relies on compiler instrumentation and requires GCC 6.1.0 or later
|
||||
or any Clang version supported by the kernel.
|
||||
|
||||
Collecting comparison operands is supported with GCC 8+ or with Clang.
|
||||
|
||||
To enable KCOV, configure the kernel with::
|
||||
|
||||
CONFIG_KCOV=y
|
||||
|
||||
CONFIG_KCOV requires gcc 6.1.0 or later.
|
||||
|
||||
If the comparison operands need to be collected, set::
|
||||
To enable comparison operands collection, set::
|
||||
|
||||
CONFIG_KCOV_ENABLE_COMPARISONS=y
|
||||
|
||||
Profiling data will only become accessible once debugfs has been mounted::
|
||||
Coverage data only becomes accessible once debugfs has been mounted::
|
||||
|
||||
mount -t debugfs none /sys/kernel/debug
|
||||
|
||||
Coverage collection
|
||||
-------------------
|
||||
|
||||
The following program demonstrates coverage collection from within a test
|
||||
program using kcov:
|
||||
The following program demonstrates how to use KCOV to collect coverage for a
|
||||
single syscall from within a test program:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
|
@ -84,7 +92,7 @@ program using kcov:
|
|||
perror("ioctl"), exit(1);
|
||||
/* Reset coverage from the tail of the ioctl() call. */
|
||||
__atomic_store_n(&cover[0], 0, __ATOMIC_RELAXED);
|
||||
/* That's the target syscal call. */
|
||||
/* Call the target syscall call. */
|
||||
read(-1, NULL, 0);
|
||||
/* Read number of PCs collected. */
|
||||
n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED);
|
||||
|
@ -103,7 +111,7 @@ program using kcov:
|
|||
return 0;
|
||||
}
|
||||
|
||||
After piping through addr2line output of the program looks as follows::
|
||||
After piping through ``addr2line`` the output of the program looks as follows::
|
||||
|
||||
SyS_read
|
||||
fs/read_write.c:562
|
||||
|
@ -121,12 +129,13 @@ After piping through addr2line output of the program looks as follows::
|
|||
fs/read_write.c:562
|
||||
|
||||
If a program needs to collect coverage from several threads (independently),
|
||||
it needs to open /sys/kernel/debug/kcov in each thread separately.
|
||||
it needs to open ``/sys/kernel/debug/kcov`` in each thread separately.
|
||||
|
||||
The interface is fine-grained to allow efficient forking of test processes.
|
||||
That is, a parent process opens /sys/kernel/debug/kcov, enables trace mode,
|
||||
mmaps coverage buffer and then forks child processes in a loop. Child processes
|
||||
only need to enable coverage (disable happens automatically on thread end).
|
||||
That is, a parent process opens ``/sys/kernel/debug/kcov``, enables trace mode,
|
||||
mmaps coverage buffer, and then forks child processes in a loop. The child
|
||||
processes only need to enable coverage (it gets disabled automatically when
|
||||
a thread exits).
|
||||
|
||||
Comparison operands collection
|
||||
------------------------------
|
||||
|
@ -205,52 +214,78 @@ Comparison operands collection is similar to coverage collection:
|
|||
return 0;
|
||||
}
|
||||
|
||||
Note that the kcov modes (coverage collection or comparison operands) are
|
||||
mutually exclusive.
|
||||
Note that the KCOV modes (collection of code coverage 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().
|
||||
Besides collecting coverage data from handlers of syscalls issued from a
|
||||
userspace process, KCOV can also collect coverage for parts of the kernel
|
||||
executing in other contexts - so-called "remote" coverage.
|
||||
|
||||
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); as well as from soft
|
||||
interrupts.
|
||||
Using KCOV to collect remote coverage requires:
|
||||
|
||||
To enable collecting coverage from a global background thread or from a
|
||||
softirq, 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.
|
||||
1. Modifying kernel code to annotate the code section from where coverage
|
||||
should be collected with ``kcov_remote_start`` and ``kcov_remote_stop``.
|
||||
|
||||
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().
|
||||
2. Using ``KCOV_REMOTE_ENABLE`` instead of ``KCOV_ENABLE`` in the userspace
|
||||
process that collects coverage.
|
||||
|
||||
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.
|
||||
Both ``kcov_remote_start`` and ``kcov_remote_stop`` annotations and the
|
||||
``KCOV_REMOTE_ENABLE`` ioctl accept handles that identify particular coverage
|
||||
collection sections. The way a handle is used depends on the context where the
|
||||
matching code section executes.
|
||||
|
||||
When a particular userspace process collects coverage 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.
|
||||
KCOV supports collecting remote coverage from the following contexts:
|
||||
|
||||
1. Global kernel background tasks. These are the tasks that are spawned during
|
||||
kernel boot in a limited number of instances (e.g. one USB ``hub_event``
|
||||
worker is spawned per one USB HCD).
|
||||
|
||||
2. Local kernel background tasks. These are spawned when a userspace process
|
||||
interacts with some kernel interface and are usually killed when the process
|
||||
exits (e.g. vhost workers).
|
||||
|
||||
3. Soft interrupts.
|
||||
|
||||
For #1 and #3, a unique global handle must be chosen and passed to the
|
||||
corresponding ``kcov_remote_start`` call. Then a userspace process must pass
|
||||
this handle to ``KCOV_REMOTE_ENABLE`` in the ``handles`` array field of the
|
||||
``kcov_remote_arg`` struct. This will attach the used KCOV device to the code
|
||||
section referenced by this handle. Multiple global handles identifying
|
||||
different code sections can be passed at once.
|
||||
|
||||
For #2, the userspace process instead must pass 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 local tasks via custom kernel code
|
||||
modifications. Those tasks should in turn use the passed handle in their
|
||||
``kcov_remote_start`` and ``kcov_remote_stop`` annotations.
|
||||
|
||||
KCOV follows a predefined format for both global and common handles. Each
|
||||
handle is a ``u64`` integer. Currently, only the one top and the lower 4 bytes
|
||||
are used. Bytes 4-7 are reserved and must be zero.
|
||||
|
||||
For global handles, the top byte of the handle denotes the id of a subsystem
|
||||
this handle belongs to. For example, KCOV uses ``1`` as the USB subsystem id.
|
||||
The lower 4 bytes of a global handle denote the id of a task instance within
|
||||
that subsystem. For example, each ``hub_event`` worker uses the USB bus number
|
||||
as the task instance id.
|
||||
|
||||
For common handles, a reserved value ``0`` is used as a subsystem id, as such
|
||||
handles don't belong to a particular subsystem. The lower 4 bytes of a common
|
||||
handle identify a collective instance of all local tasks spawned by the
|
||||
userspace process that passed a common handle to ``KCOV_REMOTE_ENABLE``.
|
||||
|
||||
In practice, any value can be used for common handle instance id if coverage
|
||||
is only collected from a single userspace process on the system. However, if
|
||||
common handles are used by multiple processes, unique instance ids must be
|
||||
used for each process. One option is to use the process id as the common
|
||||
handle instance id.
|
||||
|
||||
The following program demonstrates using KCOV to collect coverage from both
|
||||
local tasks spawned by the process and the global task that handles USB bus #1:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
|
|
|
@ -1,49 +0,0 @@
|
|||
Krait Processor Sub-system (KPSS) Application Clock Controller (ACC)
|
||||
|
||||
The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
|
||||
There is one ACC register region per CPU within the KPSS remapped region as
|
||||
well as an alias register region that remaps accesses to the ACC associated
|
||||
with the CPU accessing the region.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: should be one of:
|
||||
"qcom,kpss-acc-v1"
|
||||
"qcom,kpss-acc-v2"
|
||||
|
||||
- reg:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: the first element specifies the base address and size of
|
||||
the register region. An optional second element specifies
|
||||
the base address and size of the alias register region.
|
||||
|
||||
- clocks:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: reference to the pll parents.
|
||||
|
||||
- clock-names:
|
||||
Usage: required
|
||||
Value type: <stringlist>
|
||||
Definition: must be "pll8_vote", "pxo".
|
||||
|
||||
- clock-output-names:
|
||||
Usage: optional
|
||||
Value type: <string>
|
||||
Definition: Name of the output clock. Typically acpuX_aux where X is a
|
||||
CPU number starting at 0.
|
||||
|
||||
Example:
|
||||
|
||||
clock-controller@2088000 {
|
||||
compatible = "qcom,kpss-acc-v2";
|
||||
reg = <0x02088000 0x1000>,
|
||||
<0x02008000 0x1000>;
|
||||
clocks = <&gcc PLL8_VOTE>, <&gcc PXO_SRC>;
|
||||
clock-names = "pll8_vote", "pxo";
|
||||
clock-output-names = "acpu0_aux";
|
||||
};
|
|
@ -1,44 +0,0 @@
|
|||
Krait Processor Sub-system (KPSS) Global Clock Controller (GCC)
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: should be one of the following. The generic compatible
|
||||
"qcom,kpss-gcc" should also be included.
|
||||
"qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc"
|
||||
"qcom,kpss-gcc-apq8064", "qcom,kpss-gcc"
|
||||
"qcom,kpss-gcc-msm8974", "qcom,kpss-gcc"
|
||||
"qcom,kpss-gcc-msm8960", "qcom,kpss-gcc"
|
||||
|
||||
- reg:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: base address and size of the register region
|
||||
|
||||
- clocks:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: reference to the pll parents.
|
||||
|
||||
- clock-names:
|
||||
Usage: required
|
||||
Value type: <stringlist>
|
||||
Definition: must be "pll8_vote", "pxo".
|
||||
|
||||
- clock-output-names:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Name of the output clock. Typically acpu_l2_aux indicating
|
||||
an L2 cache auxiliary clock.
|
||||
|
||||
Example:
|
||||
|
||||
l2cc: clock-controller@2011000 {
|
||||
compatible = "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc";
|
||||
reg = <0x2011000 0x1000>;
|
||||
clocks = <&gcc PLL8_VOTE>, <&gcc PXO_SRC>;
|
||||
clock-names = "pll8_vote", "pxo";
|
||||
clock-output-names = "acpu_l2_aux";
|
||||
};
|
|
@ -32,7 +32,7 @@ properties:
|
|||
maxItems: 1
|
||||
|
||||
iommus:
|
||||
maxItems: 1
|
||||
maxItems: 4
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
|
|
@ -0,0 +1,54 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/bus/microsoft,vmbus.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Microsoft Hyper-V VMBus
|
||||
|
||||
maintainers:
|
||||
- Saurabh Sengar <ssengar@linux.microsoft.com>
|
||||
|
||||
description:
|
||||
VMBus is a software bus that implement the protocols for communication
|
||||
between the root or host OS and guest OSs (virtual machines).
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: microsoft,vmbus
|
||||
|
||||
ranges: true
|
||||
|
||||
'#address-cells':
|
||||
const: 2
|
||||
|
||||
'#size-cells':
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- ranges
|
||||
- '#address-cells'
|
||||
- '#size-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
soc {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <1>;
|
||||
bus {
|
||||
compatible = "simple-bus";
|
||||
#address-cells = <2>;
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
|
||||
vmbus@ff0000000 {
|
||||
compatible = "microsoft,vmbus";
|
||||
#address-cells = <2>;
|
||||
#size-cells = <1>;
|
||||
ranges = <0x0f 0xf0000000 0x0f 0xf0000000 0x10000000>;
|
||||
};
|
||||
};
|
||||
};
|
|
@ -0,0 +1,82 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/bus/xlnx,versal-net-cdx.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: AMD CDX bus controller
|
||||
|
||||
description: |
|
||||
CDX bus controller for AMD devices is implemented to dynamically
|
||||
detect CDX bus and devices using the firmware.
|
||||
The CDX bus manages multiple FPGA based hardware devices, which
|
||||
can support network, crypto or any other specialized type of
|
||||
devices. These FPGA based devices can be added/modified dynamically
|
||||
on run-time.
|
||||
|
||||
All devices on the CDX bus will have a unique streamid (for IOMMU)
|
||||
and a unique device ID (for MSI) corresponding to a requestor ID
|
||||
(one to one associated with the device). The streamid and deviceid
|
||||
are used to configure SMMU and GIC-ITS respectively.
|
||||
|
||||
iommu-map property is used to define the set of stream ids
|
||||
corresponding to each device and the associated IOMMU.
|
||||
|
||||
The MSI writes are accompanied by sideband data (Device ID).
|
||||
The msi-map property is used to associate the devices with the
|
||||
device ID as well as the associated ITS controller.
|
||||
|
||||
rproc property (xlnx,rproc) is used to identify the remote processor
|
||||
with which APU (Application Processor Unit) interacts to find out
|
||||
the bus and device configuration.
|
||||
|
||||
maintainers:
|
||||
- Nipun Gupta <nipun.gupta@amd.com>
|
||||
- Nikhil Agarwal <nikhil.agarwal@amd.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: xlnx,versal-net-cdx
|
||||
|
||||
iommu-map: true
|
||||
|
||||
msi-map: true
|
||||
|
||||
xlnx,rproc:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
phandle to the remoteproc_r5 rproc node using which APU interacts
|
||||
with remote processor.
|
||||
|
||||
ranges: true
|
||||
|
||||
"#address-cells":
|
||||
enum: [1, 2]
|
||||
|
||||
"#size-cells":
|
||||
enum: [1, 2]
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- iommu-map
|
||||
- msi-map
|
||||
- xlnx,rproc
|
||||
- ranges
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
cdx {
|
||||
compatible = "xlnx,versal-net-cdx";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
/* define map for RIDs 250-259 */
|
||||
iommu-map = <250 &smmu 250 10>;
|
||||
/* define msi map for RIDs 250-259 */
|
||||
msi-map = <250 &its 250 10>;
|
||||
xlnx,rproc = <&remoteproc_r5>;
|
||||
ranges;
|
||||
};
|
|
@ -0,0 +1,40 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/brcm,bcm63268-timer-clocks.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Broadcom BCM63268 Timer Clock and Reset Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Álvaro Fernández Rojas <noltari@gmail.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: brcm,bcm63268-timer-clocks
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
|
||||
"#reset-cells":
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- "#clock-cells"
|
||||
- "#reset-cells"
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
timer_clk: clock-controller@100000ac {
|
||||
compatible = "brcm,bcm63268-timer-clocks";
|
||||
reg = <0x100000ac 0x4>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
|
@ -0,0 +1,79 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/imx8mp-audiomix.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: NXP i.MX8MP AudioMIX Block Control Binding
|
||||
|
||||
maintainers:
|
||||
- Marek Vasut <marex@denx.de>
|
||||
|
||||
description: |
|
||||
NXP i.MX8M Plus AudioMIX is dedicated clock muxing and gating IP
|
||||
used to control Audio related clock on the SoC.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: fsl,imx8mp-audio-blk-ctrl
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
minItems: 7
|
||||
maxItems: 7
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: ahb
|
||||
- const: sai1
|
||||
- const: sai2
|
||||
- const: sai3
|
||||
- const: sai5
|
||||
- const: sai6
|
||||
- const: sai7
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
description:
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mp-clock.h
|
||||
for the full list of i.MX8MP IMX8MP_CLK_AUDIOMIX_ clock IDs.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- clock-names
|
||||
- power-domains
|
||||
- '#clock-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
# Clock Control Module node:
|
||||
- |
|
||||
#include <dt-bindings/clock/imx8mp-clock.h>
|
||||
|
||||
clock-controller@30e20000 {
|
||||
compatible = "fsl,imx8mp-audio-blk-ctrl";
|
||||
reg = <0x30e20000 0x10000>;
|
||||
#clock-cells = <1>;
|
||||
clocks = <&clk IMX8MP_CLK_AUDIO_ROOT>,
|
||||
<&clk IMX8MP_CLK_SAI1>,
|
||||
<&clk IMX8MP_CLK_SAI2>,
|
||||
<&clk IMX8MP_CLK_SAI3>,
|
||||
<&clk IMX8MP_CLK_SAI5>,
|
||||
<&clk IMX8MP_CLK_SAI6>,
|
||||
<&clk IMX8MP_CLK_SAI7>;
|
||||
clock-names = "ahb",
|
||||
"sai1", "sai2", "sai3",
|
||||
"sai5", "sai6", "sai7";
|
||||
power-domains = <&pgc_audio>;
|
||||
};
|
||||
|
||||
...
|
|
@ -0,0 +1,45 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/loongson,ls1x-clk.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Loongson-1 Clock Controller
|
||||
|
||||
maintainers:
|
||||
- Keguang Zhang <keguang.zhang@gmail.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- loongson,ls1b-clk
|
||||
- loongson,ls1c-clk
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- "#clock-cells"
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
clkc: clock-controller@1fe78030 {
|
||||
compatible = "loongson,ls1b-clk";
|
||||
reg = <0x1fe78030 0x8>;
|
||||
|
||||
clocks = <&xtal>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
...
|
|
@ -16,7 +16,12 @@ description: |
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
const: mediatek,mt8186-fhctl
|
||||
enum:
|
||||
- mediatek,mt6795-fhctl
|
||||
- mediatek,mt8173-fhctl
|
||||
- mediatek,mt8186-fhctl
|
||||
- mediatek,mt8192-fhctl
|
||||
- mediatek,mt8195-fhctl
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
@ -0,0 +1,71 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/mediatek,mt8188-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek Functional Clock Controller for MT8188
|
||||
|
||||
maintainers:
|
||||
- Garmin Chang <garmin.chang@mediatek.com>
|
||||
|
||||
description: |
|
||||
The clock architecture in MediaTek like below
|
||||
PLLs -->
|
||||
dividers -->
|
||||
muxes
|
||||
-->
|
||||
clock gate
|
||||
|
||||
The devices provide clock gate control in different IP blocks.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- mediatek,mt8188-adsp-audio26m
|
||||
- mediatek,mt8188-camsys
|
||||
- mediatek,mt8188-camsys-rawa
|
||||
- mediatek,mt8188-camsys-rawb
|
||||
- mediatek,mt8188-camsys-yuva
|
||||
- mediatek,mt8188-camsys-yuvb
|
||||
- mediatek,mt8188-ccusys
|
||||
- mediatek,mt8188-imgsys
|
||||
- mediatek,mt8188-imgsys-wpe1
|
||||
- mediatek,mt8188-imgsys-wpe2
|
||||
- mediatek,mt8188-imgsys-wpe3
|
||||
- mediatek,mt8188-imgsys1-dip-nr
|
||||
- mediatek,mt8188-imgsys1-dip-top
|
||||
- mediatek,mt8188-imp-iic-wrap-c
|
||||
- mediatek,mt8188-imp-iic-wrap-en
|
||||
- mediatek,mt8188-imp-iic-wrap-w
|
||||
- mediatek,mt8188-ipesys
|
||||
- mediatek,mt8188-mfgcfg
|
||||
- mediatek,mt8188-vdecsys
|
||||
- mediatek,mt8188-vdecsys-soc
|
||||
- mediatek,mt8188-vencsys
|
||||
- mediatek,mt8188-vppsys0
|
||||
- mediatek,mt8188-vppsys1
|
||||
- mediatek,mt8188-wpesys
|
||||
- mediatek,mt8188-wpesys-vpp0
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- '#clock-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
clock-controller@11283000 {
|
||||
compatible = "mediatek,mt8188-imp-iic-wrap-c";
|
||||
reg = <0x11283000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/mediatek,mt8188-sys-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek System Clock Controller for MT8188
|
||||
|
||||
maintainers:
|
||||
- Garmin Chang <garmin.chang@mediatek.com>
|
||||
|
||||
description: |
|
||||
The clock architecture in MediaTek like below
|
||||
PLLs -->
|
||||
dividers -->
|
||||
muxes
|
||||
-->
|
||||
clock gate
|
||||
|
||||
The apmixedsys provides most of PLLs which generated from SoC 26m.
|
||||
The topckgen provides dividers and muxes which provide the clock source to other IP blocks.
|
||||
The infracfg_ao provides clock gate in peripheral and infrastructure IP blocks.
|
||||
The mcusys provides mux control to select the clock source in AP MCU.
|
||||
The device nodes also provide the system control capacity for configuration.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- mediatek,mt8188-apmixedsys
|
||||
- mediatek,mt8188-infracfg-ao
|
||||
- mediatek,mt8188-pericfg-ao
|
||||
- mediatek,mt8188-topckgen
|
||||
- const: syscon
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- '#clock-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
clock-controller@10000000 {
|
||||
compatible = "mediatek,mt8188-topckgen", "syscon";
|
||||
reg = <0x10000000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
|
@ -16,6 +16,7 @@ description:
|
|||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,ipq5332-a53pll
|
||||
- qcom,ipq6018-a53pll
|
||||
- qcom,ipq8074-a53pll
|
||||
- qcom,msm8916-a53pll
|
||||
|
|
|
@ -0,0 +1,53 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,gcc-ipq4019.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Global Clock & Reset Controller on IPQ4019
|
||||
|
||||
maintainers:
|
||||
- Stephen Boyd <sboyd@kernel.org>
|
||||
- Taniya Das <tdas@codeaurora.org>
|
||||
- Robert Marko <robert.markoo@sartura.hr>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module provides the clocks, resets and power
|
||||
domains on IPQ4019.
|
||||
|
||||
See also:: include/dt-bindings/clock/qcom,gcc-ipq4019.h
|
||||
|
||||
allOf:
|
||||
- $ref: qcom,gcc.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,gcc-ipq4019
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: board XO clock
|
||||
- description: sleep clock
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: xo
|
||||
- const: sleep_clk
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
clock-controller@1800000 {
|
||||
compatible = "qcom,gcc-ipq4019";
|
||||
reg = <0x1800000 0x60000>;
|
||||
#clock-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
clocks = <&xo>, <&sleep_clk>;
|
||||
clock-names = "xo", "sleep_clk";
|
||||
};
|
||||
...
|
|
@ -4,20 +4,25 @@
|
|||
$id: http://devicetree.org/schemas/clock/qcom,gcc-msm8909.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Global Clock & Reset Controller on MSM8909
|
||||
title: Qualcomm Global Clock & Reset Controller on MSM8909, MSM8917 and QM215
|
||||
|
||||
maintainers:
|
||||
- Stephan Gerhold <stephan@gerhold.net>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module provides the clocks, resets and power
|
||||
domains on MSM8909.
|
||||
domains on MSM8909, MSM8917 or QM215.
|
||||
|
||||
See also:: include/dt-bindings/clock/qcom,gcc-msm8909.h
|
||||
See also::
|
||||
include/dt-bindings/clock/qcom,gcc-msm8909.h
|
||||
include/dt-bindings/clock/qcom,gcc-msm8917.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,gcc-msm8909
|
||||
enum:
|
||||
- qcom,gcc-msm8909
|
||||
- qcom,gcc-msm8917
|
||||
- qcom,gcc-qm215
|
||||
|
||||
clocks:
|
||||
items:
|
||||
|
|
|
@ -15,7 +15,6 @@ description: |
|
|||
domains.
|
||||
|
||||
See also::
|
||||
include/dt-bindings/clock/qcom,gcc-ipq4019.h
|
||||
include/dt-bindings/clock/qcom,gcc-ipq6018.h
|
||||
include/dt-bindings/reset/qcom,gcc-ipq6018.h
|
||||
include/dt-bindings/clock/qcom,gcc-msm8953.h
|
||||
|
@ -29,7 +28,6 @@ allOf:
|
|||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,gcc-ipq4019
|
||||
- qcom,gcc-ipq6018
|
||||
- qcom,gcc-mdm9607
|
||||
- qcom,gcc-msm8953
|
||||
|
|
|
@ -15,6 +15,7 @@ description: |
|
|||
|
||||
See also::
|
||||
include/dt-bindings/clock/qcom,gpucc-sdm845.h
|
||||
include/dt-bindings/clock/qcom,gpucc-sa8775p.h
|
||||
include/dt-bindings/clock/qcom,gpucc-sc7180.h
|
||||
include/dt-bindings/clock/qcom,gpucc-sc7280.h
|
||||
include/dt-bindings/clock/qcom,gpucc-sc8280xp.h
|
||||
|
@ -27,6 +28,7 @@ properties:
|
|||
compatible:
|
||||
enum:
|
||||
- qcom,sdm845-gpucc
|
||||
- qcom,sa8775p-gpucc
|
||||
- qcom,sc7180-gpucc
|
||||
- qcom,sc7280-gpucc
|
||||
- qcom,sc8180x-gpucc
|
||||
|
|
|
@ -0,0 +1,72 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,kpss-acc-v1.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Krait Processor Sub-system (KPSS) Application Clock Controller (ACC) v1
|
||||
|
||||
maintainers:
|
||||
- Christian Marangi <ansuelsmth@gmail.com>
|
||||
|
||||
description:
|
||||
The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
|
||||
There is one ACC register region per CPU within the KPSS remapped region as
|
||||
well as an alias register region that remaps accesses to the ACC associated
|
||||
with the CPU accessing the region. ACC v1 is currently used as a
|
||||
clock-controller for enabling the cpu and hanling the aux clocks.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,kpss-acc-v1
|
||||
|
||||
reg:
|
||||
items:
|
||||
- description: Base address and size of the register region
|
||||
- description: Optional base address and size of the alias register region
|
||||
minItems: 1
|
||||
|
||||
clocks:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: pll8_vote
|
||||
- const: pxo
|
||||
|
||||
clock-output-names:
|
||||
description: Name of the aux clock. Krait can have at most 4 cpu.
|
||||
enum:
|
||||
- acpu0_aux
|
||||
- acpu1_aux
|
||||
- acpu2_aux
|
||||
- acpu3_aux
|
||||
|
||||
'#clock-cells':
|
||||
const: 0
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- clock-names
|
||||
- clock-output-names
|
||||
- '#clock-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,gcc-ipq806x.h>
|
||||
|
||||
clock-controller@2088000 {
|
||||
compatible = "qcom,kpss-acc-v1";
|
||||
reg = <0x02088000 0x1000>, <0x02008000 0x1000>;
|
||||
clocks = <&gcc PLL8_VOTE>, <&pxo_board>;
|
||||
clock-names = "pll8_vote", "pxo";
|
||||
clock-output-names = "acpu0_aux";
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
|
||||
...
|
|
@ -0,0 +1,88 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,kpss-gcc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Krait Processor Sub-system (KPSS) Global Clock Controller (GCC)
|
||||
|
||||
maintainers:
|
||||
- Christian Marangi <ansuelsmth@gmail.com>
|
||||
|
||||
description:
|
||||
Krait Processor Sub-system (KPSS) Global Clock Controller (GCC). Used
|
||||
to control L2 mux (in the current implementation) and provide access
|
||||
to the kpss-gcc registers.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- qcom,kpss-gcc-ipq8064
|
||||
- qcom,kpss-gcc-apq8064
|
||||
- qcom,kpss-gcc-msm8974
|
||||
- qcom,kpss-gcc-msm8960
|
||||
- qcom,kpss-gcc-msm8660
|
||||
- qcom,kpss-gcc-mdm9615
|
||||
- const: qcom,kpss-gcc
|
||||
- const: syscon
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: pll8_vote
|
||||
- const: pxo
|
||||
|
||||
'#clock-cells':
|
||||
const: 0
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,kpss-gcc-ipq8064
|
||||
- qcom,kpss-gcc-apq8064
|
||||
- qcom,kpss-gcc-msm8974
|
||||
- qcom,kpss-gcc-msm8960
|
||||
then:
|
||||
required:
|
||||
- clocks
|
||||
- clock-names
|
||||
- '#clock-cells'
|
||||
else:
|
||||
properties:
|
||||
clock: false
|
||||
clock-names: false
|
||||
'#clock-cells': false
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,gcc-ipq806x.h>
|
||||
|
||||
clock-controller@2011000 {
|
||||
compatible = "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc", "syscon";
|
||||
reg = <0x2011000 0x1000>;
|
||||
clocks = <&gcc PLL8_VOTE>, <&pxo_board>;
|
||||
clock-names = "pll8_vote", "pxo";
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
|
||||
- |
|
||||
clock-controller@2011000 {
|
||||
compatible = "qcom,kpss-gcc-mdm9615", "qcom,kpss-gcc", "syscon";
|
||||
reg = <0x02011000 0x1000>;
|
||||
};
|
||||
...
|
|
@ -31,6 +31,7 @@ properties:
|
|||
- qcom,rpmcc-msm8660
|
||||
- qcom,rpmcc-msm8909
|
||||
- qcom,rpmcc-msm8916
|
||||
- qcom,rpmcc-msm8917
|
||||
- qcom,rpmcc-msm8936
|
||||
- qcom,rpmcc-msm8953
|
||||
- qcom,rpmcc-msm8974
|
||||
|
@ -107,6 +108,7 @@ allOf:
|
|||
- qcom,rpmcc-mdm9607
|
||||
- qcom,rpmcc-msm8226
|
||||
- qcom,rpmcc-msm8916
|
||||
- qcom,rpmcc-msm8917
|
||||
- qcom,rpmcc-msm8936
|
||||
- qcom,rpmcc-msm8953
|
||||
- qcom,rpmcc-msm8974
|
||||
|
|
|
@ -41,6 +41,12 @@ properties:
|
|||
- const: qdsp6ss
|
||||
- const: top_cc
|
||||
|
||||
qcom,adsp-pil-mode:
|
||||
description:
|
||||
Indicates if the LPASS would be brought out of reset using
|
||||
remoteproc peripheral loader.
|
||||
type: boolean
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
@ -60,6 +66,7 @@ examples:
|
|||
reg-names = "qdsp6ss", "top_cc";
|
||||
clocks = <&gcc GCC_CFG_NOC_LPASS_CLK>;
|
||||
clock-names = "iface";
|
||||
qcom,adsp-pil-mode;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
...
|
||||
|
|
|
@ -0,0 +1,52 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,sm7150-gcc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Global Clock & Reset Controller on SM7150
|
||||
|
||||
maintainers:
|
||||
- Bjorn Andersson <andersson@kernel.org>
|
||||
- Danila Tikhonov <danila@jiaxyga.com>
|
||||
- David Wronek <davidwronek@gmail.com>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module provides the clocks, resets and power
|
||||
domains on SM7150
|
||||
|
||||
See also:: include/dt-bindings/clock/qcom,sm7150-gcc.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,sm7150-gcc
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Board XO source
|
||||
- description: Board XO Active-Only source
|
||||
- description: Sleep clock source
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
|
||||
allOf:
|
||||
- $ref: qcom,gcc.yaml#
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
clock-controller@100000 {
|
||||
compatible = "qcom,sm7150-gcc";
|
||||
reg = <0x00100000 0x001f0000>;
|
||||
clocks = <&rpmhcc RPMH_CXO_CLK>,
|
||||
<&rpmhcc RPMH_CXO_CLK_A>,
|
||||
<&sleep_clk>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
...
|
|
@ -16,6 +16,11 @@ description: |
|
|||
- 9FGV0241:
|
||||
0 -- DIF0
|
||||
1 -- DIF1
|
||||
- 9FGV0441:
|
||||
0 -- DIF0
|
||||
1 -- DIF1
|
||||
2 -- DIF2
|
||||
3 -- DIF3
|
||||
|
||||
maintainers:
|
||||
- Marek Vasut <marex@denx.de>
|
||||
|
@ -24,6 +29,7 @@ properties:
|
|||
compatible:
|
||||
enum:
|
||||
- renesas,9fgv0241
|
||||
- renesas,9fgv0441
|
||||
|
||||
reg:
|
||||
description: I2C device address
|
||||
|
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Renesas RZ/N1D (R9A06G032) System Controller
|
||||
|
||||
maintainers:
|
||||
- Gareth Williams <gareth.williams.jx@renesas.com>
|
||||
- Fabrizio Castro <fabrizio.castro.jz@renesas.com>
|
||||
- Geert Uytterhoeven <geert+renesas@glider.be>
|
||||
|
||||
properties:
|
||||
|
|
|
@ -0,0 +1,59 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/skyworks,si521xx.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Skyworks Si521xx I2C PCIe clock generators
|
||||
|
||||
description: |
|
||||
The Skyworks Si521xx are I2C PCIe clock generators providing
|
||||
from 4 to 9 output clocks.
|
||||
|
||||
maintainers:
|
||||
- Marek Vasut <marex@denx.de>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- skyworks,si52144
|
||||
- skyworks,si52146
|
||||
- skyworks,si52147
|
||||
|
||||
reg:
|
||||
const: 0x6b
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: XTal input clock
|
||||
|
||||
skyworks,out-amplitude-microvolt:
|
||||
enum: [ 300000, 400000, 500000, 600000, 700000, 800000, 900000, 1000000 ]
|
||||
description: Output clock signal amplitude
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- '#clock-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
clock-generator@6b {
|
||||
compatible = "skyworks,si52144";
|
||||
reg = <0x6b>;
|
||||
#clock-cells = <1>;
|
||||
clocks = <&ref25m>;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
|
@ -82,6 +82,18 @@ properties:
|
|||
Indicates if the DSI controller is driving a panel which needs
|
||||
2 DSI links.
|
||||
|
||||
qcom,master-dsi:
|
||||
type: boolean
|
||||
description: |
|
||||
Indicates if the DSI controller is the master DSI controller when
|
||||
qcom,dual-dsi-mode enabled.
|
||||
|
||||
qcom,sync-dual-dsi:
|
||||
type: boolean
|
||||
description: |
|
||||
Indicates if the DSI controller needs to sync the other DSI controller
|
||||
with MIPI DCS commands when qcom,dual-dsi-mode enabled.
|
||||
|
||||
assigned-clocks:
|
||||
minItems: 2
|
||||
maxItems: 4
|
||||
|
|
|
@ -26,6 +26,7 @@ properties:
|
|||
- enum:
|
||||
- apple,t6000-admac
|
||||
- apple,t8103-admac
|
||||
- apple,t8112-admac
|
||||
- const: apple,admac
|
||||
|
||||
reg:
|
||||
|
|
|
@ -24,6 +24,7 @@ properties:
|
|||
- qcom,sm6350-gpi-dma
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,qcm2290-gpi-dma
|
||||
- qcom,qdu1000-gpi-dma
|
||||
- qcom,sc7280-gpi-dma
|
||||
- qcom,sm6115-gpi-dma
|
||||
|
|
|
@ -54,6 +54,11 @@ properties:
|
|||
- description: DMA main clock
|
||||
- description: DMA register access clock
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: main
|
||||
- const: register
|
||||
|
||||
'#dma-cells':
|
||||
const: 1
|
||||
description:
|
||||
|
@ -77,16 +82,23 @@ properties:
|
|||
- description: Reset for DMA ARESETN reset terminal
|
||||
- description: Reset for DMA RST_ASYNC reset terminal
|
||||
|
||||
reset-names:
|
||||
items:
|
||||
- const: arst
|
||||
- const: rst_async
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- interrupt-names
|
||||
- clocks
|
||||
- clock-names
|
||||
- '#dma-cells'
|
||||
- dma-channels
|
||||
- power-domains
|
||||
- resets
|
||||
- reset-names
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
|
@ -124,9 +136,11 @@ examples:
|
|||
"ch12", "ch13", "ch14", "ch15";
|
||||
clocks = <&cpg CPG_MOD R9A07G044_DMAC_ACLK>,
|
||||
<&cpg CPG_MOD R9A07G044_DMAC_PCLK>;
|
||||
clock-names = "main", "register";
|
||||
power-domains = <&cpg>;
|
||||
resets = <&cpg R9A07G044_DMAC_ARESETN>,
|
||||
<&cpg R9A07G044_DMAC_RST_ASYNC>;
|
||||
reset-names = "arst", "rst_async";
|
||||
#dma-cells = <1>;
|
||||
dma-channels = <16>;
|
||||
};
|
||||
|
|
|
@ -20,6 +20,7 @@ properties:
|
|||
enum:
|
||||
- snps,axi-dma-1.01a
|
||||
- intel,kmb-axi-dma
|
||||
- starfive,jh7110-axi-dma
|
||||
|
||||
reg:
|
||||
minItems: 1
|
||||
|
@ -58,7 +59,8 @@ properties:
|
|||
maximum: 8
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
snps,dma-masters:
|
||||
description: |
|
||||
|
@ -109,6 +111,25 @@ required:
|
|||
- snps,priority
|
||||
- snps,block-size
|
||||
|
||||
if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- starfive,jh7110-axi-dma
|
||||
then:
|
||||
properties:
|
||||
resets:
|
||||
minItems: 2
|
||||
items:
|
||||
- description: AXI reset line
|
||||
- description: AHB reset line
|
||||
- description: module reset
|
||||
else:
|
||||
properties:
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
|
|
|
@ -43,7 +43,7 @@ description: |
|
|||
configuration of the legacy peripheral.
|
||||
|
||||
allOf:
|
||||
- $ref: "../dma-controller.yaml#"
|
||||
- $ref: ../dma-controller.yaml#
|
||||
- $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
|
||||
|
||||
properties:
|
||||
|
|
|
@ -15,7 +15,7 @@ maintainers:
|
|||
- Michael Tretter <m.tretter@pengutronix.de>
|
||||
|
||||
allOf:
|
||||
- $ref: "../dma-controller.yaml#"
|
||||
- $ref: ../dma-controller.yaml#
|
||||
|
||||
properties:
|
||||
"#dma-cells":
|
||||
|
|
|
@ -16,7 +16,7 @@ maintainers:
|
|||
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
||||
|
||||
allOf:
|
||||
- $ref: "../dma-controller.yaml#"
|
||||
- $ref: ../dma-controller.yaml#
|
||||
|
||||
properties:
|
||||
"#dma-cells":
|
||||
|
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Lattice Slave SPI sysCONFIG FPGA manager
|
||||
|
||||
maintainers:
|
||||
- Ivan Bornyakov <i.bornyakov@metrotek.ru>
|
||||
- Vladimir Georgiev <v.georgiev@metrotek.ru>
|
||||
|
||||
description: |
|
||||
Lattice sysCONFIG port, which is used for FPGA configuration, among others,
|
||||
|
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Microchip Polarfire FPGA manager.
|
||||
|
||||
maintainers:
|
||||
- Ivan Bornyakov <i.bornyakov@metrotek.ru>
|
||||
- Vladimir Georgiev <v.georgiev@metrotek.ru>
|
||||
|
||||
description:
|
||||
Device Tree Bindings for Microchip Polarfire FPGA Manager using slave SPI to
|
||||
|
|
|
@ -39,6 +39,10 @@ properties:
|
|||
reg:
|
||||
maxItems: 1
|
||||
|
||||
gpio-line-names:
|
||||
minItems: 1
|
||||
maxItems: 16
|
||||
|
||||
gpio-controller: true
|
||||
|
||||
'#gpio-cells':
|
||||
|
|
|
@ -1,35 +0,0 @@
|
|||
Broadcom Kona Family I2C
|
||||
=========================
|
||||
|
||||
This I2C controller is used in the following Broadcom SoCs:
|
||||
|
||||
BCM11130
|
||||
BCM11140
|
||||
BCM11351
|
||||
BCM28145
|
||||
BCM28155
|
||||
|
||||
Required Properties
|
||||
-------------------
|
||||
- compatible: "brcm,bcm11351-i2c", "brcm,kona-i2c"
|
||||
- reg: Physical base address and length of controller registers
|
||||
- interrupts: The interrupt number used by the controller
|
||||
- clocks: clock specifier for the kona i2c external clock
|
||||
- clock-frequency: The I2C bus frequency in Hz
|
||||
- #address-cells: Should be <1>
|
||||
- #size-cells: Should be <0>
|
||||
|
||||
Refer to clocks/clock-bindings.txt for generic clock consumer
|
||||
properties.
|
||||
|
||||
Example:
|
||||
|
||||
i2c@3e016000 {
|
||||
compatible = "brcm,bcm11351-i2c","brcm,kona-i2c";
|
||||
reg = <0x3e016000 0x80>;
|
||||
interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&bsc1_clk>;
|
||||
clock-frequency = <400000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
};
|
|
@ -0,0 +1,59 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/i2c/brcm,kona-i2c.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Broadcom Kona family I2C controller
|
||||
|
||||
maintainers:
|
||||
- Florian Fainelli <f.fainelli@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/i2c/i2c-controller.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- brcm,bcm11351-i2c
|
||||
- brcm,bcm21664-i2c
|
||||
- brcm,bcm23550-i2c
|
||||
- const: brcm,kona-i2c
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
clock-frequency:
|
||||
enum: [ 100000, 400000, 1000000, 3400000 ]
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- clock-frequency
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
i2c@3e016000 {
|
||||
compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
|
||||
reg = <0x3e016000 0x80>;
|
||||
interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&bsc1_clk>;
|
||||
clock-frequency = <400000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
};
|
||||
...
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Renesas RZ/V2M I2C Bus Interface
|
||||
|
||||
maintainers:
|
||||
- Phil Edworthy <phil.edworthy@renesas.com>
|
||||
- Fabrizio Castro <fabrizio.castro.jz@renesas.com>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/i2c/i2c-controller.yaml#
|
||||
|
|
|
@ -0,0 +1,72 @@
|
|||
# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/i3c/aspeed,ast2600-i3c.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ASPEED AST2600 i3c controller
|
||||
|
||||
maintainers:
|
||||
- Jeremy Kerr <jk@codeconstruct.com.au>
|
||||
|
||||
allOf:
|
||||
- $ref: i3c.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: aspeed,ast2600-i3c
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
sda-pullup-ohms:
|
||||
enum: [545, 750, 2000]
|
||||
default: 2000
|
||||
description: |
|
||||
Value to configure SDA pullup resistor, in Ohms.
|
||||
|
||||
aspeed,global-regs:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
items:
|
||||
- items:
|
||||
- description: phandle to i3c global register syscon node
|
||||
- description: index of this i3c controller in the global register set
|
||||
description: |
|
||||
A (phandle, controller index) reference to the i3c global register set
|
||||
used for this device.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- interrupts
|
||||
- aspeed,global-regs
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
i3c-master@2000 {
|
||||
compatible = "aspeed,ast2600-i3c";
|
||||
reg = <0x2000 0x1000>;
|
||||
#address-cells = <3>;
|
||||
#size-cells = <0>;
|
||||
clocks = <&syscon 0>;
|
||||
resets = <&syscon 0>;
|
||||
aspeed,global-regs = <&i3c_global 0>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_i3c1_default>;
|
||||
interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
|
||||
};
|
||||
...
|
|
@ -39,6 +39,12 @@ properties:
|
|||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
vref-supply:
|
||||
description: |
|
||||
External ADC reference voltage supply on VREFH pad. If VERID[MVI] is
|
||||
set, there are additional, internal reference voltages selectable.
|
||||
VREFH1 is always from VREFH pad.
|
||||
|
||||
"#io-channel-cells":
|
||||
const: 1
|
||||
|
||||
|
@ -72,6 +78,7 @@ examples:
|
|||
assigned-clocks = <&clk IMX_SC_R_ADC_0>;
|
||||
assigned-clock-rates = <24000000>;
|
||||
power-domains = <&pd IMX_SC_R_ADC_0>;
|
||||
vref-supply = <®_1v8>;
|
||||
#io-channel-cells = <1>;
|
||||
};
|
||||
};
|
||||
|
|
|
@ -34,9 +34,11 @@ properties:
|
|||
clock-names:
|
||||
const: fck
|
||||
|
||||
power-domains: true
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
resets: true
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
@ -51,6 +53,8 @@ required:
|
|||
- reg
|
||||
- clocks
|
||||
- clock-names
|
||||
- power-domains
|
||||
- resets
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
|
||||
|
@ -86,7 +90,7 @@ patternProperties:
|
|||
of the MAX chips to the GyroADC, while MISO line of each Maxim
|
||||
ADC connects to a shared input pin of the GyroADC.
|
||||
enum:
|
||||
- adi,7476
|
||||
- adi,ad7476
|
||||
- fujitsu,mb88101a
|
||||
- maxim,max1162
|
||||
- maxim,max11100
|
||||
|
@ -108,36 +112,30 @@ patternProperties:
|
|||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/r8a7791-clock.h>
|
||||
#include <dt-bindings/clock/r8a7791-cpg-mssr.h>
|
||||
#include <dt-bindings/power/r8a7791-sysc.h>
|
||||
soc {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
|
||||
adc@e6e54000 {
|
||||
compatible = "renesas,r8a7791-gyroadc", "renesas,rcar-gyroadc";
|
||||
reg = <0 0xe6e54000 0 64>;
|
||||
clocks = <&mstp9_clks R8A7791_CLK_GYROADC>;
|
||||
clock-names = "fck";
|
||||
power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
|
||||
adc@e6e54000 {
|
||||
compatible = "renesas,r8a7791-gyroadc", "renesas,rcar-gyroadc";
|
||||
reg = <0xe6e54000 64>;
|
||||
clocks = <&cpg CPG_MOD 901>;
|
||||
clock-names = "fck";
|
||||
power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
|
||||
resets = <&cpg 901>;
|
||||
|
||||
pinctrl-0 = <&adc_pins>;
|
||||
pinctrl-names = "default";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
adc@0 {
|
||||
reg = <0>;
|
||||
compatible = "maxim,max1162";
|
||||
vref-supply = <&vref_max1162>;
|
||||
};
|
||||
|
||||
adc@0 {
|
||||
reg = <0>;
|
||||
compatible = "maxim,max1162";
|
||||
vref-supply = <&vref_max1162>;
|
||||
};
|
||||
|
||||
adc@1 {
|
||||
reg = <1>;
|
||||
compatible = "maxim,max1162";
|
||||
vref-supply = <&vref_max1162>;
|
||||
};
|
||||
adc@1 {
|
||||
reg = <1>;
|
||||
compatible = "maxim,max1162";
|
||||
vref-supply = <&vref_max1162>;
|
||||
};
|
||||
};
|
||||
...
|
||||
|
|
|
@ -0,0 +1,46 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/iio/adc/ti,ads1100.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: TI ADS1100/ADS1000 single channel I2C analog to digital converter
|
||||
|
||||
maintainers:
|
||||
- Mike Looijmans <mike.looijmans@topic.nl>
|
||||
|
||||
description: |
|
||||
Datasheet at: https://www.ti.com/lit/gpn/ads1100
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- ti,ads1100
|
||||
- ti,ads1000
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
vdd-supply: true
|
||||
|
||||
"#io-channel-cells":
|
||||
const: 0
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
adc@49 {
|
||||
compatible = "ti,ads1100";
|
||||
reg = <0x49>;
|
||||
};
|
||||
};
|
||||
...
|
|
@ -101,6 +101,15 @@ patternProperties:
|
|||
When not configured as a comparator, the GPO will be treated as an
|
||||
output-only GPIO.
|
||||
|
||||
drive-strength-microamp:
|
||||
description: |
|
||||
For channels configured as digital input, this configures the sink
|
||||
current.
|
||||
minimum: 0
|
||||
maximum: 1800
|
||||
default: 0
|
||||
multipleOf: 120
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
||||
|
|
|
@ -46,6 +46,9 @@ properties:
|
|||
- items:
|
||||
- const: st,ism330is
|
||||
- const: st,lsm6dso16is
|
||||
- items:
|
||||
- const: st,asm330lhb
|
||||
- const: st,asm330lhh
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
@ -0,0 +1,46 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/iio/light/rohm,bu27034.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ROHM BU27034 ambient light sensor
|
||||
|
||||
maintainers:
|
||||
- Matti Vaittinen <mazziesaccount@gmail.com>
|
||||
|
||||
description: |
|
||||
ROHM BU27034 is an ambient light sesnor with 3 channels and 3 photo diodes
|
||||
capable of detecting a very wide range of illuminance. Typical application
|
||||
is adjusting LCD and backlight power of TVs and mobile phones.
|
||||
https://fscdn.rohm.com/en/products/databook/datasheet/ic/sensor/light/bu27034nuc-e.pdf
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: rohm,bu27034
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
vdd-supply: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
light-sensor@38 {
|
||||
compatible = "rohm,bu27034";
|
||||
reg = <0x38>;
|
||||
vdd-supply = <&vdd>;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
|
@ -17,6 +17,7 @@ description: |
|
|||
https://www.bosch-sensortec.com/bst/products/all_products/bmp280
|
||||
https://www.bosch-sensortec.com/bst/products/all_products/bme280
|
||||
https://www.bosch-sensortec.com/bst/products/all_products/bmp380
|
||||
https://www.bosch-sensortec.com/bst/products/all_products/bmp580
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
@ -26,6 +27,7 @@ properties:
|
|||
- bosch,bmp280
|
||||
- bosch,bme280
|
||||
- bosch,bmp380
|
||||
- bosch,bmp580
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
@ -11,9 +11,6 @@ description: The STMicroelectronics sensor devices are pretty straight-forward
|
|||
what type of sensor it is.
|
||||
Note that whilst this covers many STMicro MEMs sensors, some more complex
|
||||
IMUs need their own bindings.
|
||||
The STMicroelectronics sensor devices are pretty straight-forward I2C or
|
||||
SPI devices, all sharing the same device tree descriptions no matter what
|
||||
type of sensor it is.
|
||||
|
||||
maintainers:
|
||||
- Denis Ciocca <denis.ciocca@st.com>
|
||||
|
@ -48,6 +45,9 @@ properties:
|
|||
- st,lsm330d-accel
|
||||
- st,lsm330dl-accel
|
||||
- st,lsm330dlc-accel
|
||||
- items:
|
||||
- const: st,iis328dq
|
||||
- const: st,h3lis331dl-accel
|
||||
- description: Silan Accelerometers
|
||||
enum:
|
||||
- silan,sc7a20
|
||||
|
|
|
@ -18,6 +18,28 @@ description: |
|
|||
https://www.analog.com/media/en/technical-documentation/data-sheets/29861fa.pdf
|
||||
https://www.analog.com/media/en/technical-documentation/data-sheets/ltm2985.pdf
|
||||
|
||||
$defs:
|
||||
sensor-node:
|
||||
type: object
|
||||
description: Sensor node common constraints
|
||||
|
||||
properties:
|
||||
reg:
|
||||
description:
|
||||
Channel number. Connects the sensor to the channel with this number
|
||||
of the device.
|
||||
minimum: 1
|
||||
maximum: 20
|
||||
|
||||
adi,sensor-type:
|
||||
description: Type of sensor connected to the device.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
required:
|
||||
- reg
|
||||
- adi,sensor-type
|
||||
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
|
@ -64,28 +86,10 @@ properties:
|
|||
const: 0
|
||||
|
||||
patternProperties:
|
||||
"@([0-9a-f]+)$":
|
||||
type: object
|
||||
description: Sensor.
|
||||
|
||||
properties:
|
||||
reg:
|
||||
description:
|
||||
Channel number. Connects the sensor to the channel with this number
|
||||
of the device.
|
||||
minimum: 1
|
||||
maximum: 20
|
||||
|
||||
adi,sensor-type:
|
||||
description: Type of sensor connected to the device.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
required:
|
||||
- reg
|
||||
- adi,sensor-type
|
||||
|
||||
"^thermocouple@":
|
||||
type: object
|
||||
$ref: '#/$defs/sensor-node'
|
||||
unevaluatedProperties: false
|
||||
|
||||
description: Thermocouple sensor.
|
||||
|
||||
properties:
|
||||
|
@ -123,7 +127,7 @@ patternProperties:
|
|||
description:
|
||||
Used for digitizing custom thermocouples.
|
||||
See Page 59 of the datasheet.
|
||||
$ref: /schemas/types.yaml#/definitions/uint64-matrix
|
||||
$ref: /schemas/types.yaml#/definitions/int64-matrix
|
||||
minItems: 3
|
||||
maxItems: 64
|
||||
items:
|
||||
|
@ -141,7 +145,9 @@ patternProperties:
|
|||
- adi,custom-thermocouple
|
||||
|
||||
"^diode@":
|
||||
type: object
|
||||
$ref: '#/$defs/sensor-node'
|
||||
unevaluatedProperties: false
|
||||
|
||||
description: Diode sensor.
|
||||
|
||||
properties:
|
||||
|
@ -184,7 +190,8 @@ patternProperties:
|
|||
default: 0
|
||||
|
||||
"^rtd@":
|
||||
type: object
|
||||
$ref: '#/$defs/sensor-node'
|
||||
unevaluatedProperties: false
|
||||
description: RTD sensor.
|
||||
|
||||
properties:
|
||||
|
@ -282,7 +289,8 @@ patternProperties:
|
|||
- adi,custom-rtd
|
||||
|
||||
"^thermistor@":
|
||||
type: object
|
||||
$ref: '#/$defs/sensor-node'
|
||||
unevaluatedProperties: false
|
||||
description: Thermistor sensor.
|
||||
|
||||
properties:
|
||||
|
@ -383,7 +391,8 @@ patternProperties:
|
|||
- adi,custom-thermistor
|
||||
|
||||
"^adc@":
|
||||
type: object
|
||||
$ref: '#/$defs/sensor-node'
|
||||
unevaluatedProperties: false
|
||||
description: Direct ADC sensor.
|
||||
|
||||
properties:
|
||||
|
@ -397,7 +406,8 @@ patternProperties:
|
|||
type: boolean
|
||||
|
||||
"^temp@":
|
||||
type: object
|
||||
$ref: '#/$defs/sensor-node'
|
||||
unevaluatedProperties: false
|
||||
description: Active analog temperature sensor.
|
||||
|
||||
properties:
|
||||
|
@ -426,7 +436,8 @@ patternProperties:
|
|||
- adi,custom-temp
|
||||
|
||||
"^rsense@":
|
||||
type: object
|
||||
$ref: '#/$defs/sensor-node'
|
||||
unevaluatedProperties: false
|
||||
description: Sense resistor sensor.
|
||||
|
||||
properties:
|
||||
|
|
|
@ -7,9 +7,10 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: TI TMP117 - Digital temperature sensor with integrated NV memory
|
||||
|
||||
description: |
|
||||
TI TMP117 - Digital temperature sensor with integrated NV memory that supports
|
||||
I2C interface.
|
||||
https://www.ti.com/lit/gpn/tmp1
|
||||
TI TMP116/117 - Digital temperature sensor with integrated NV memory that
|
||||
supports I2C interface.
|
||||
https://www.ti.com/lit/gpn/tmp116
|
||||
https://www.ti.com/lit/gpn/tmp117
|
||||
|
||||
maintainers:
|
||||
- Puranjay Mohan <puranjay12@gmail.com>
|
||||
|
@ -17,6 +18,7 @@ maintainers:
|
|||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- ti,tmp116
|
||||
- ti,tmp117
|
||||
|
||||
reg:
|
||||
|
|
|
@ -45,7 +45,7 @@ properties:
|
|||
when the keyboard has a custom design for the top row keys.
|
||||
|
||||
dependencies:
|
||||
function-row-phsymap: [ 'linux,keymap' ]
|
||||
function-row-physmap: [ 'linux,keymap' ]
|
||||
google,needs-ghost-filter: [ 'linux,keymap' ]
|
||||
|
||||
required:
|
||||
|
|
|
@ -1,24 +0,0 @@
|
|||
* PWM beeper device tree bindings
|
||||
|
||||
Registers a PWM device as beeper.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "pwm-beeper"
|
||||
- pwms: phandle to the physical PWM device
|
||||
|
||||
Optional properties:
|
||||
- amp-supply: phandle to a regulator that acts as an amplifier for the beeper
|
||||
- beeper-hz: bell frequency in Hz
|
||||
|
||||
Example:
|
||||
|
||||
beeper_amp: amplifier {
|
||||
compatible = "fixed-regulator";
|
||||
gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
|
||||
};
|
||||
|
||||
beeper {
|
||||
compatible = "pwm-beeper";
|
||||
pwms = <&pwm0>;
|
||||
amp-supply = <&beeper_amp>;
|
||||
};
|
|
@ -0,0 +1,41 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/input/pwm-beeper.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: PWM beeper
|
||||
|
||||
maintainers:
|
||||
- Sascha Hauer <s.hauer@pengutronix.de>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: pwm-beeper
|
||||
|
||||
pwms:
|
||||
maxItems: 1
|
||||
|
||||
amp-supply:
|
||||
description: an amplifier for the beeper
|
||||
|
||||
beeper-hz:
|
||||
description: bell frequency in Hz
|
||||
minimum: 10
|
||||
maximum: 10000
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- pwms
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
beeper {
|
||||
compatible = "pwm-beeper";
|
||||
pwms = <&pwm0>;
|
||||
amp-supply = <&beeper_amp>;
|
||||
beeper-hz = <1000>;
|
||||
};
|
|
@ -22,14 +22,14 @@ description: |
|
|||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- const: qcom,msm8998-bwmon # BWMON v4
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,sc7280-cpu-bwmon
|
||||
- qcom,sc8280xp-cpu-bwmon
|
||||
- qcom,sdm845-bwmon
|
||||
- qcom,sdm845-cpu-bwmon
|
||||
- qcom,sm8550-cpu-bwmon
|
||||
- const: qcom,msm8998-bwmon
|
||||
- const: qcom,msm8998-bwmon # BWMON v4
|
||||
- const: qcom,sdm845-bwmon # BWMON v4, unified register space
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,sc8280xp-llcc-bwmon
|
||||
|
@ -49,9 +49,13 @@ properties:
|
|||
type: object
|
||||
|
||||
reg:
|
||||
# BWMON v4 (currently described) and BWMON v5 use one register address
|
||||
# space. BWMON v2 uses two register spaces - not yet described.
|
||||
maxItems: 1
|
||||
# BWMON v5 uses one register address space, v1-v4 use one or two.
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
reg-names:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
@ -63,13 +67,36 @@ required:
|
|||
|
||||
additionalProperties: false
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,msm8998-bwmon
|
||||
then:
|
||||
properties:
|
||||
reg:
|
||||
minItems: 2
|
||||
|
||||
reg-names:
|
||||
items:
|
||||
- const: monitor
|
||||
- const: global
|
||||
|
||||
else:
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
reg-names:
|
||||
maxItems: 1
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interconnect/qcom,sdm845.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
pmu@1436400 {
|
||||
compatible = "qcom,sdm845-bwmon", "qcom,msm8998-bwmon";
|
||||
compatible = "qcom,sdm845-cpu-bwmon", "qcom,sdm845-bwmon";
|
||||
reg = <0x01436400 0x600>;
|
||||
interrupts = <GIC_SPI 581 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interconnects = <&gladiator_noc MASTER_APPSS_PROC 3 &mem_noc SLAVE_LLCC 3>;
|
||||
|
|
|
@ -29,6 +29,7 @@ properties:
|
|||
- enum:
|
||||
- qcom,sc7280-epss-l3
|
||||
- qcom,sc8280xp-epss-l3
|
||||
- qcom,sm6375-cpucp-l3
|
||||
- qcom,sm8250-epss-l3
|
||||
- qcom,sm8350-epss-l3
|
||||
- const: qcom,epss-l3
|
||||
|
|
|
@ -166,6 +166,12 @@ properties:
|
|||
resets:
|
||||
maxItems: 1
|
||||
|
||||
mediatek,broken-save-restore-fw:
|
||||
type: boolean
|
||||
description:
|
||||
Asserts that the firmware on this device has issues saving and restoring
|
||||
GICR registers when the GIC redistributors are powered off.
|
||||
|
||||
dependencies:
|
||||
mbi-ranges: [ msi-controller ]
|
||||
msi-controller: [ mbi-ranges ]
|
||||
|
|
|
@ -53,6 +53,7 @@ properties:
|
|||
- qcom,sm8250-smmu-500
|
||||
- qcom,sm8350-smmu-500
|
||||
- qcom,sm8450-smmu-500
|
||||
- qcom,sm8550-smmu-500
|
||||
- const: qcom,smmu-500
|
||||
- const: arm,mmu-500
|
||||
|
||||
|
@ -75,9 +76,22 @@ properties:
|
|||
- qcom,sm8350-smmu-500
|
||||
- qcom,sm8450-smmu-500
|
||||
- const: arm,mmu-500
|
||||
|
||||
- description: Qcom Adreno GPUs implementing "arm,smmu-500"
|
||||
- description: Qcom Adreno GPUs implementing "qcom,smmu-500" and "arm,mmu-500"
|
||||
items:
|
||||
- enum:
|
||||
- qcom,sc7280-smmu-500
|
||||
- qcom,sm6115-smmu-500
|
||||
- qcom,sm6125-smmu-500
|
||||
- qcom,sm8150-smmu-500
|
||||
- qcom,sm8250-smmu-500
|
||||
- qcom,sm8350-smmu-500
|
||||
- const: qcom,adreno-smmu
|
||||
- const: qcom,smmu-500
|
||||
- const: arm,mmu-500
|
||||
- description: Qcom Adreno GPUs implementing "arm,mmu-500" (legacy binding)
|
||||
deprecated: true
|
||||
items:
|
||||
# Do not add additional SoC to this list. Instead use previous list.
|
||||
- enum:
|
||||
- qcom,sc7280-smmu-500
|
||||
- qcom,sm8150-smmu-500
|
||||
|
@ -364,6 +378,30 @@ allOf:
|
|||
- description: interface clock required to access smmu's registers
|
||||
through the TCU's programming interface.
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- qcom,sm6115-smmu-500
|
||||
- qcom,sm6125-smmu-500
|
||||
- const: qcom,adreno-smmu
|
||||
- const: qcom,smmu-500
|
||||
- const: arm,mmu-500
|
||||
then:
|
||||
properties:
|
||||
clock-names:
|
||||
items:
|
||||
- const: mem
|
||||
- const: hlos
|
||||
- const: iface
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: GPU memory bus clock
|
||||
- description: Voter clock required for HLOS SMMU access
|
||||
- description: Interface clock required for register access
|
||||
|
||||
# Disallow clocks for all other platforms with specific compatibles
|
||||
- if:
|
||||
properties:
|
||||
|
@ -383,12 +421,11 @@ allOf:
|
|||
- qcom,sdm845-smmu-500
|
||||
- qcom,sdx55-smmu-500
|
||||
- qcom,sdx65-smmu-500
|
||||
- qcom,sm6115-smmu-500
|
||||
- qcom,sm6125-smmu-500
|
||||
- qcom,sm6350-smmu-500
|
||||
- qcom,sm6375-smmu-500
|
||||
- qcom,sm8350-smmu-500
|
||||
- qcom,sm8450-smmu-500
|
||||
- qcom,sm8550-smmu-500
|
||||
then:
|
||||
properties:
|
||||
clock-names: false
|
||||
|
|
|
@ -74,16 +74,16 @@ properties:
|
|||
renesas,ipmmu-main:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
items:
|
||||
- items:
|
||||
- minItems: 1
|
||||
items:
|
||||
- description: phandle to main IPMMU
|
||||
- description: the interrupt bit number associated with the particular
|
||||
cache IPMMU device. The interrupt bit number needs to match the main
|
||||
IPMMU IMSSTR register. Only used by cache IPMMU instances.
|
||||
- description:
|
||||
The interrupt bit number associated with the particular cache
|
||||
IPMMU device. If present, the interrupt bit number needs to match
|
||||
the main IPMMU IMSSTR register. Only used by cache IPMMU
|
||||
instances.
|
||||
description:
|
||||
Reference to the main IPMMU phandle plus 1 cell. The cell is
|
||||
the interrupt bit number associated with the particular cache IPMMU
|
||||
device. The interrupt bit number needs to match the main IPMMU IMSSTR
|
||||
register. Only used by cache IPMMU instances.
|
||||
Reference to the main IPMMU.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
@ -109,6 +109,22 @@ allOf:
|
|||
required:
|
||||
- power-domains
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: renesas,rcar-gen4-ipmmu-vmsa
|
||||
then:
|
||||
properties:
|
||||
renesas,ipmmu-main:
|
||||
items:
|
||||
- maxItems: 1
|
||||
else:
|
||||
properties:
|
||||
renesas,ipmmu-main:
|
||||
items:
|
||||
- minItems: 2
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/r8a7791-cpg-mssr.h>
|
||||
|
|
|
@ -90,22 +90,51 @@ properties:
|
|||
- heartbeat
|
||||
# LED indicates disk activity
|
||||
- disk-activity
|
||||
# LED indicates disk read activity
|
||||
- disk-read
|
||||
# LED indicates disk write activity
|
||||
- disk-write
|
||||
# LED flashes at a fixed, configurable rate
|
||||
- timer
|
||||
# LED alters the brightness for the specified duration with one software
|
||||
# timer (requires "led-pattern" property)
|
||||
- pattern
|
||||
# LED indicates mic mute state
|
||||
- audio-micmute
|
||||
# LED indicates audio mute state
|
||||
- audio-mute
|
||||
# LED indicates bluetooth power state
|
||||
- bluetooth-power
|
||||
# LED indicates activity of all CPUs
|
||||
- cpu
|
||||
# LED indicates camera flash state
|
||||
- flash
|
||||
# LED indicated keyboard capslock
|
||||
- kbd-capslock
|
||||
# LED indicates MTD memory activity
|
||||
- mtd
|
||||
# LED indicates NAND memory activity (deprecated),
|
||||
# in new implementations use "mtd"
|
||||
- nand-disk
|
||||
# No trigger assigned to the LED. This is the default mode
|
||||
# if trigger is absent
|
||||
- none
|
||||
# LED indicates camera torch state
|
||||
- torch
|
||||
# LED indicates USB gadget activity
|
||||
- usb-gadget
|
||||
# LED indicates USB host activity
|
||||
- usb-host
|
||||
# LED indicates USB port state
|
||||
- usbport
|
||||
# LED is triggered by CPU activity
|
||||
- pattern: "^cpu[0-9]*$"
|
||||
- pattern: "^hci[0-9]+-power$"
|
||||
# LED is triggered by Bluetooth activity
|
||||
- pattern: "^mmc[0-9]+$"
|
||||
- pattern: "^hci[0-9]+-power$"
|
||||
# LED is triggered by SD/MMC activity
|
||||
- pattern: "^phy[0-9]+tx$"
|
||||
- pattern: "^mmc[0-9]+$"
|
||||
# LED is triggered by WLAN activity
|
||||
- pattern: "^phy[0-9]+tx$"
|
||||
|
||||
led-pattern:
|
||||
description: |
|
||||
|
|
|
@ -1,49 +0,0 @@
|
|||
*NXP - pca9532 PWM LED Driver
|
||||
|
||||
The PCA9532 family is SMBus I/O expander optimized for dimming LEDs.
|
||||
The PWM support 256 steps.
|
||||
|
||||
Required properties:
|
||||
- compatible:
|
||||
"nxp,pca9530"
|
||||
"nxp,pca9531"
|
||||
"nxp,pca9532"
|
||||
"nxp,pca9533"
|
||||
- reg - I2C slave address
|
||||
|
||||
Each led is represented as a sub-node of the nxp,pca9530.
|
||||
|
||||
Optional sub-node properties:
|
||||
- label: see Documentation/devicetree/bindings/leds/common.txt
|
||||
- type: Output configuration, see dt-bindings/leds/leds-pca9532.h (default NONE)
|
||||
- linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt
|
||||
- default-state: see Documentation/devicetree/bindings/leds/common.txt
|
||||
This property is only valid for sub-nodes of type <PCA9532_TYPE_LED>.
|
||||
|
||||
Example:
|
||||
#include <dt-bindings/leds/leds-pca9532.h>
|
||||
|
||||
leds: pca9530@60 {
|
||||
compatible = "nxp,pca9530";
|
||||
reg = <0x60>;
|
||||
|
||||
red-power {
|
||||
label = "pca:red:power";
|
||||
type = <PCA9532_TYPE_LED>;
|
||||
};
|
||||
green-power {
|
||||
label = "pca:green:power";
|
||||
type = <PCA9532_TYPE_LED>;
|
||||
};
|
||||
kernel-booting {
|
||||
type = <PCA9532_TYPE_LED>;
|
||||
default-state = "on";
|
||||
};
|
||||
sys-stat {
|
||||
type = <PCA9532_TYPE_LED>;
|
||||
default-state = "keep"; // don't touch, was set by U-Boot
|
||||
};
|
||||
};
|
||||
|
||||
For more product information please see the link below:
|
||||
http://nxp.com/documents/data_sheet/PCA9532.pdf
|
|
@ -27,6 +27,7 @@ properties:
|
|||
- qcom,pmc8180c-lpg
|
||||
- qcom,pmi8994-lpg
|
||||
- qcom,pmi8998-lpg
|
||||
- qcom,pmk8550-pwm
|
||||
|
||||
"#pwm-cells":
|
||||
const: 2
|
||||
|
|
|
@ -0,0 +1,90 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/leds/nxp,pca953x.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: NXP PCA9532 LED Dimmer
|
||||
|
||||
maintainers:
|
||||
- Riku Voipio <riku.voipio@iki.fi>
|
||||
|
||||
description: |
|
||||
The PCA9532 family is SMBus I/O expander optimized for dimming LEDs.
|
||||
The PWM support 256 steps.
|
||||
|
||||
For more product information please see the link below:
|
||||
https://www.nxp.com/docs/en/data-sheet/PCA9532.pdf
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- nxp,pca9530
|
||||
- nxp,pca9531
|
||||
- nxp,pca9532
|
||||
- nxp,pca9533
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
gpio-controller: true
|
||||
|
||||
'#gpio-cells':
|
||||
const: 2
|
||||
|
||||
patternProperties:
|
||||
"^led-[0-9a-z]+$":
|
||||
type: object
|
||||
$ref: common.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
type:
|
||||
description: |
|
||||
Output configuration, see include/dt-bindings/leds/leds-pca9532.h
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
default: 0
|
||||
minimum: 0
|
||||
maximum: 4
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/leds/leds-pca9532.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
led-controller@62 {
|
||||
compatible = "nxp,pca9533";
|
||||
reg = <0x62>;
|
||||
|
||||
led-1 {
|
||||
label = "pca:red:power";
|
||||
type = <PCA9532_TYPE_LED>;
|
||||
};
|
||||
|
||||
led-2 {
|
||||
label = "pca:green:power";
|
||||
type = <PCA9532_TYPE_LED>;
|
||||
};
|
||||
|
||||
led-3 {
|
||||
type = <PCA9532_TYPE_LED>;
|
||||
default-state = "on";
|
||||
};
|
||||
|
||||
led-4 {
|
||||
type = <PCA9532_TYPE_LED>;
|
||||
default-state = "keep";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue