Qortal/Brooklyn
3
0
Fork 1
mirror of https://github.com/Qortal/Brooklyn.git synced 2025-01-30 14:52:17 +00:00
Code Issues Projects Releases Wiki Activity

meh

Browse Source
This commit is contained in:
Raziel K. Crowe 2022-09-09 13:55:46 +05:00
parent feadabd29b
commit 09d25b6de9
577 changed files with 79381 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
Documentation/ABI/testing/securityfs-secrets-coco Normal file
View File

@ -0,0 +1,51 @@
What: security/secrets/coco
Date: February 2022
Contact: Dov Murik <dovmurik@linux.ibm.com>
Description:
Exposes confidential computing (coco) EFI secrets to
userspace via securityfs.
EFI can declare memory area used by confidential computing
platforms (such as AMD SEV and SEV-ES) for secret injection by
the Guest Owner during VM's launch. The secrets are encrypted
by the Guest Owner and decrypted inside the trusted enclave,
and therefore are not readable by the untrusted host.
The efi_secret module exposes the secrets to userspace. Each
secret appears as a file under <securityfs>/secrets/coco,
where the filename is the GUID of the entry in the secrets
table. This module is loaded automatically by the EFI driver
if the EFI secret area is populated.
Two operations are supported for the files: read and unlink.
Reading the file returns the content of secret entry.
Unlinking the file overwrites the secret data with zeroes and
removes the entry from the filesystem. A secret cannot be read
after it has been unlinked.
For example, listing the available secrets::
# modprobe efi_secret
# ls -l /sys/kernel/security/secrets/coco
-r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec-06879ce3da0b
-r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e-d3a0b54312c6
-r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d-ff17f78864d2
-r--r----- 1 root root 0 Jun 28 11:54 e6f5a162-d67f-4750-a67c-5d065f2a9910
Reading the secret data by reading a file::
# cat /sys/kernel/security/secrets/coco/e6f5a162-d67f-4750-a67c-5d065f2a9910
the-content-of-the-secret-data
Wiping a secret by unlinking a file::
# rm /sys/kernel/security/secrets/coco/e6f5a162-d67f-4750-a67c-5d065f2a9910
# ls -l /sys/kernel/security/secrets/coco
-r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec-06879ce3da0b
-r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e-d3a0b54312c6
-r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d-ff17f78864d2
Note: The binary format of the secrets table injected by the
Guest Owner is described in
drivers/virt/coco/efi_secret/efi_secret.c under "Structure of
the EFI secret area".

18
Documentation/ABI/testing/sysfs-bus-event_source-devices-caps Normal file
View File

@ -0,0 +1,18 @@
What: /sys/bus/event_source/devices/<dev>/caps
Date: May 2022
KernelVersion: 5.19
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description:
Attribute group to describe the capabilities exposed
for a particular pmu. Each attribute of this group can
expose information specific to a PMU, say pmu_name, so that
userspace can understand some of the feature which the
platform specific PMU supports.
One of the example available capability in supported platform
like Intel is pmu_name, which exposes underlying CPU name known
to the PMU driver.
Example output in powerpc:
grep . /sys/bus/event_source/devices/cpu/caps/*
/sys/bus/event_source/devices/cpu/caps/pmu_name:POWER9

18
Documentation/ABI/testing/sysfs-bus-iio-thermocouple Normal file
View File

@ -0,0 +1,18 @@
What: /sys/bus/iio/devices/iio:deviceX/fault_ovuv
KernelVersion: 5.1
Contact: linux-iio@vger.kernel.org
Description:
Overvoltage or Undervoltage Input Fault. The internal circuitry
is protected from excessive voltages applied to the thermocouple
cables. The device can also detect if such a condition occurs.
Reading returns '1' if input voltage is negative or greater
than VDD, otherwise '0'.
What: /sys/bus/iio/devices/iio:deviceX/fault_oc
KernelVersion: 5.1
Contact: linux-iio@vger.kernel.org
Description:
Open-circuit fault. The detection of open-circuit faults,
such as those caused by broken thermocouple wires.
Reading returns '1' if fault, '0' otherwise.

8
Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub Normal file
View File

@ -0,0 +1,8 @@
What: /sys/bus/platform/devices/<dev>/always_powered_in_suspend
Date: June 2022
KernelVersion: 5.20
Contact: Matthias Kaehlcke <matthias@kaehlcke.net>
linux-usb@vger.kernel.org
Description:
(RW) Controls whether the USB hub remains always powered
during system suspend or not.

57
Documentation/ABI/testing/sysfs-bus-surface_aggregator-tabletsw Normal file
View File

@ -0,0 +1,57 @@
What: /sys/bus/surface_aggregator/devices/01:0e:01:00:01/state
Date: July 2022
KernelVersion: 5.20
Contact: Maximilian Luz <luzmaximilian@gmail.com>
Description:
This attribute returns a string with the current type-cover
or device posture, as indicated by the embedded controller.
Currently returned posture states are:
- "disconnected": The type-cover has been disconnected.
- "closed": The type-cover has been folded closed and lies on
top of the display.
- "laptop": The type-cover is open and in laptop-mode, i.e.,
ready for normal use.
- "folded-canvas": The type-cover has been folded back
part-ways, but does not lie flush with the back side of the
device. In general, this means that the kick-stand is used
and extended atop of the cover.
- "folded-back": The type cover has been fully folded back and
lies flush with the back side of the device.
- "<unknown>": The current state is unknown to the driver, for
example due to newer as-of-yet unsupported hardware.
New states may be introduced with new hardware. Users therefore
must not rely on this list of states being exhaustive and
gracefully handle unknown states.
What: /sys/bus/surface_aggregator/devices/01:26:01:00:01/state
Date: July 2022
KernelVersion: 5.20
Contact: Maximilian Luz <luzmaximilian@gmail.com>
Description:
This attribute returns a string with the current device posture, as indicated by the embedded controller. Currently
returned posture states are:
- "closed": The lid of the device is closed.
- "laptop": The lid of the device is opened and the device
operates as a normal laptop.
- "slate": The screen covers the keyboard or has been flipped
back and the device operates mainly based on touch input.
- "tablet": The device operates as tablet and exclusively
relies on touch input (or external peripherals).
- "<unknown>": The current state is unknown to the driver, for
example due to newer as-of-yet unsupported hardware.
New states may be introduced with new hardware. Users therefore
must not rely on this list of states being exhaustive and
gracefully handle unknown states.

77
Documentation/ABI/testing/sysfs-class-firmware Normal file
View File

@ -0,0 +1,77 @@
What: /sys/class/firmware/.../data
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Description: The data sysfs file is used for firmware-fallback and for
firmware uploads. Cat a firmware image to this sysfs file
after you echo 1 to the loading sysfs file. When the firmware
image write is complete, echo 0 to the loading sysfs file. This
sequence will signal the completion of the firmware write and
signal the lower-level driver that the firmware data is
available.
What: /sys/class/firmware/.../cancel
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Description: Write-only. For firmware uploads, write a "1" to this file to
request that the transfer of firmware data to the lower-level
device be canceled. This request will be rejected (EBUSY) if
the update cannot be canceled (e.g. a FLASH write is in
progress) or (ENODEV) if there is no firmware update in progress.
What: /sys/class/firmware/.../error
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Description: Read-only. Returns a string describing a failed firmware
upload. This string will be in the form of <STATUS>:<ERROR>,
where <STATUS> will be one of the status strings described
for the status sysfs file and <ERROR> will be one of the
following: "hw-error", "timeout", "user-abort", "device-busy",
"invalid-file-size", "read-write-error", "flash-wearout". The
error sysfs file is only meaningful when the current firmware
upload status is "idle". If this file is read while a firmware
transfer is in progress, then the read will fail with EBUSY.
What: /sys/class/firmware/.../loading
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Description: The loading sysfs file is used for both firmware-fallback and
for firmware uploads. Echo 1 onto the loading file to indicate
you are writing a firmware file to the data sysfs node. Echo
-1 onto this file to abort the data write or echo 0 onto this
file to indicate that the write is complete. For firmware
uploads, the zero value also triggers the transfer of the
firmware data to the lower-level device driver.
What: /sys/class/firmware/.../remaining_size
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Description: Read-only. For firmware upload, this file contains the size
of the firmware data that remains to be transferred to the
lower-level device driver. The size value is initialized to
the full size of the firmware image that was previously
written to the data sysfs file. This value is periodically
updated during the "transferring" phase of the firmware
upload.
Format: "%u".
What: /sys/class/firmware/.../status
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Description: Read-only. Returns a string describing the current status of
a firmware upload. The string will be one of the following:
idle, "receiving", "preparing", "transferring", "programming".
What: /sys/class/firmware/.../timeout
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Description: This file supports the timeout mechanism for firmware
fallback. This file has no affect on firmware uploads. For
more information on timeouts please see the documentation
for firmware fallback.

240
Documentation/ABI/testing/sysfs-class-usb_power_delivery Normal file
View File

@ -0,0 +1,240 @@
What: /sys/class/usb_power_delivery
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Directory for USB Power Delivery devices.
What: /sys/class/usb_power_delivery/.../revision
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
File showing the USB Power Delivery Specification Revision used
in communication.
What: /sys/class/usb_power_delivery/.../version
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
This is an optional attribute file showing the version of the
specific revision of the USB Power Delivery Specification. In
most cases the specification version is not known and the file
is not available.
What: /sys/class/usb_power_delivery/.../source-capabilities
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The source capabilities message "Source_Capabilities" contains a
set of Power Data Objects (PDO), each representing a type of
power supply. The order of the PDO objects is defined in the USB
Power Delivery Specification. Each PDO - power supply - will
have its own device, and the PDO device name will start with the
object position number as the first character followed by the
power supply type name (":" as delimiter).
/sys/class/usb_power_delivery/.../source_capabilities/<position>:<type>
What: /sys/class/usb_power_delivery/.../sink-capabilities
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The sink capability message "Sink_Capabilities" contains a set
of Power Data Objects (PDO) just like with source capabilities,
but instead of describing the power capabilities, these objects
describe the power requirements.
The order of the objects in the sink capability message is the
same as with the source capabilities message.
Fixed Supplies
What: /sys/class/usb_power_delivery/.../<capability>/<position>:fixed_supply
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Devices containing the attributes (the bit fields) defined for
Fixed Supplies.
The device "1:fixed_supply" is special. USB Power Delivery
Specification dictates that the first PDO (at object position
1), and the only mandatory PDO, is always the vSafe5V Fixed
Supply Object. vSafe5V Object has additional fields defined for
it that the other Fixed Supply Objects do not have and that are
related to the USB capabilities rather than power capabilities.
What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/dual_role_power
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
This file contains boolean value that tells does the device
support both source and sink power roles.
What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/usb_suspend_supported
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
This file shows the value of the USB Suspend Supported bit in
vSafe5V Fixed Supply Object. If the bit is set then the device
will follow the USB 2.0 and USB 3.2 rules for suspend and
resume.
What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/unconstrained_power
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
This file shows the value of the Unconstrained Power bit in
vSafe5V Fixed Supply Object. The bit is set when an external
source of power, powerful enough to power the entire system on
its own, is available for the device.
What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/usb_communication_capable
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
This file shows the value of the USB Communication Capable bit in
vSafe5V Fixed Supply Object.
What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/dual_role_data
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
This file shows the value of the Dual-Role Data bit in vSafe5V
Fixed Supply Object. Dual role data means ability act as both
USB host and USB device.
What: /sys/class/usb_power_delivery/.../<capability>/1:fixed_supply/unchunked_extended_messages_supported
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
This file shows the value of the Unchunked Extended Messages
Supported bit in vSafe5V Fixed Supply Object.
What: /sys/class/usb_power_delivery/.../<capability>/<position>:fixed_supply/voltage
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The voltage the supply supports in millivolts.
What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:fixed_supply/maximum_current
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Maximum current of the fixed source supply in milliamperes.
What: /sys/class/usb_power_delivery/.../sink-capabilities/<position>:fixed_supply/operational_current
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Operational current of the sink in milliamperes.
What: /sys/class/usb_power_delivery/.../sink-capabilities/<position>:fixed_supply/fast_role_swap_current
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
This file contains the value of the "Fast Role Swap USB Type-C
Current" field that tells the current level the sink requires
after a Fast Role Swap.
0 - Fast Swap not supported"
1 - Default USB Power"
2 - 1.5A@5V"
3 - 3.0A@5V"
Variable Supplies
What: /sys/class/usb_power_delivery/.../<capability>/<position>:variable_supply
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Variable Power Supply PDO.
What: /sys/class/usb_power_delivery/.../<capability>/<position>:variable_supply/maximum_voltage
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Maximum Voltage in millivolts.
What: /sys/class/usb_power_delivery/.../<capability>/<position>:variable_supply/minimum_voltage
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Minimum Voltage in millivolts.
What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:variable_supply/maximum_current
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The maximum current in milliamperes that the source can supply
at the given Voltage range.
What: /sys/class/usb_power_delivery/.../sink-capabilities/<position>:variable_supply/operational_current
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The operational current in milliamperes that the sink requires
at the given Voltage range.
Battery Supplies
What: /sys/class/usb_power_delivery/.../<capability>/<position>:battery
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Battery PDO.
What: /sys/class/usb_power_delivery/.../<capability>/<position>:battery/maximum_voltage
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Maximum Voltage in millivolts.
What: /sys/class/usb_power_delivery/.../<capability>/<position>:battery/minimum_voltage
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Minimum Voltage in millivolts.
What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:battery/maximum_power
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Maximum allowable Power in milliwatts.
What: /sys/class/usb_power_delivery/.../sink-capabilities/<position>:battery/operational_power
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The operational power that the sink requires at the given
voltage range.
Standard Power Range (SPR) Programmable Power Supplies
What: /sys/class/usb_power_delivery/.../<capability>/<position>:programmable_supply
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Programmable Power Supply (PPS) Augmented PDO (APDO).
What: /sys/class/usb_power_delivery/.../<capability>/<position>:programmable_supply/maximum_voltage
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Maximum Voltage in millivolts.
What: /sys/class/usb_power_delivery/.../<capability>/<position>:programmable_supply/minimum_voltage
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Minimum Voltage in millivolts.
What: /sys/class/usb_power_delivery/.../<capability>/<position>:programmable_supply/maximum_current
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Maximum Current in milliamperes.
What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:programmable_supply/pps_power_limited
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The PPS Power Limited bit indicates whether or not the source
supply will exceed the rated output power if requested.

33
Documentation/ABI/testing/sysfs-class-vduse Normal file
View File

@ -0,0 +1,33 @@
What: /sys/class/vduse/
Date: Oct 2021
KernelVersion: 5.15
Contact: Yongji Xie <xieyongji@bytedance.com>
Description:
The vduse/ class sub-directory belongs to the VDUSE
framework and provides a sysfs interface for configuring
VDUSE devices.
What: /sys/class/vduse/control/
Date: Oct 2021
KernelVersion: 5.15
Contact: Yongji Xie <xieyongji@bytedance.com>
Description:
This directory entry is created for the control device
of VDUSE framework.
What: /sys/class/vduse/<device-name>/
Date: Oct 2021
KernelVersion: 5.15
Contact: Yongji Xie <xieyongji@bytedance.com>
Description:
This directory entry is created when a VDUSE device is
created via the control device.
What: /sys/class/vduse/<device-name>/msg_timeout
Date: Oct 2021
KernelVersion: 5.15
Contact: Yongji Xie <xieyongji@bytedance.com>
Description:
(RW) The timeout (in seconds) for waiting for the control
message's response from userspace. Default value is 30s.
Writing a '0' to the file means to disable the timeout.

42
Documentation/ABI/testing/sysfs-devices-physical_location Normal file
View File

@ -0,0 +1,42 @@
What: /sys/devices/.../physical_location
Date: March 2022
Contact: Won Chung <wonchung@google.com>
Description:
This directory contains information on physical location of
the device connection point with respect to the system's
housing.
What: /sys/devices/.../physical_location/panel
Date: March 2022
Contact: Won Chung <wonchung@google.com>
Description:
Describes which panel surface of the system’s housing the
device connection point resides on.
What: /sys/devices/.../physical_location/vertical_position
Date: March 2022
Contact: Won Chung <wonchung@google.com>
Description:
Describes vertical position of the device connection point on
the panel surface.
What: /sys/devices/.../physical_location/horizontal_position
Date: March 2022
Contact: Won Chung <wonchung@google.com>
Description:
Describes horizontal position of the device connection point on
the panel surface.
What: /sys/devices/.../physical_location/dock
Date: March 2022
Contact: Won Chung <wonchung@google.com>
Description:
"Yes" if the device connection point resides in a docking
station or a port replicator. "No" otherwise.
What: /sys/devices/.../physical_location/lid
Date: March 2022
Contact: Won Chung <wonchung@google.com>
Description:
"Yes" if the device connection point resides on the lid of
laptop system. "No" otherwise.

87
Documentation/ABI/testing/sysfs-driver-ccp Normal file
View File

@ -0,0 +1,87 @@
What: /sys/bus/pci/devices/<BDF>/fused_part
Date: June 2022
KernelVersion: 5.19
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/fused_part file reports
whether the CPU or APU has been fused to prevent tampering.
0: Not fused
1: Fused
What: /sys/bus/pci/devices/<BDF>/debug_lock_on
Date: June 2022
KernelVersion: 5.19
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/debug_lock_on reports
whether the AMD CPU or APU has been unlocked for debugging.
Possible values:
0: Not locked
1: Locked
What: /sys/bus/pci/devices/<BDF>/tsme_status
Date: June 2022
KernelVersion: 5.19
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/tsme_status file reports
the status of transparent secure memory encryption on AMD systems.
Possible values:
0: Not active
1: Active
What: /sys/bus/pci/devices/<BDF>/anti_rollback_status
Date: June 2022
KernelVersion: 5.19
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/anti_rollback_status file reports
whether the PSP is enforcing rollback protection.
Possible values:
0: Not enforcing
1: Enforcing
What: /sys/bus/pci/devices/<BDF>/rpmc_production_enabled
Date: June 2022
KernelVersion: 5.19
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/rpmc_production_enabled file reports
whether Replay Protected Monotonic Counter support has been enabled.
Possible values:
0: Not enabled
1: Enabled
What: /sys/bus/pci/devices/<BDF>/rpmc_spirom_available
Date: June 2022
KernelVersion: 5.19
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/rpmc_spirom_available file reports
whether an Replay Protected Monotonic Counter supported SPI is installed
on the system.
Possible values:
0: Not present
1: Present
What: /sys/bus/pci/devices/<BDF>/hsp_tpm_available
Date: June 2022
KernelVersion: 5.19
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/hsp_tpm_available file reports
whether the HSP TPM has been activated.
Possible values:
0: Not activated or present
1: Activated
What: /sys/bus/pci/devices/<BDF>/rom_armor_enforced
Date: June 2022
KernelVersion: 5.19
Contact: mario.limonciello@amd.com
Description:
The /sys/bus/pci/devices/<BDF>/rom_armor_enforced file reports
whether RomArmor SPI protection is enforced.
Possible values:
0: Not enforced
1: Enforced

137
Documentation/ABI/testing/sysfs-driver-chromeos-acpi Normal file
View File

@ -0,0 +1,137 @@
What: /sys/bus/platform/devices/GGL0001:*/BINF.2
Date: May 2022
KernelVersion: 5.19
Description:
Returns active EC firmware of current boot (boolean).
== ===============================
0 Read only (recovery) firmware.
1 Rewritable firmware.
== ===============================
What: /sys/bus/platform/devices/GGL0001:*/BINF.3
Date: May 2022
KernelVersion: 5.19
Description:
Returns main firmware type for current boot (integer).
== =====================================
0 Recovery.
1 Normal.
2 Developer.
3 Netboot (factory installation only).
== =====================================
What: /sys/bus/platform/devices/GGL0001:*/CHSW
Date: May 2022
KernelVersion: 5.19
Description:
Returns switch position for Chrome OS specific hardware
switches when the firmware is booted (integer).
==== ===========================================
0 No changes.
2 Recovery button was pressed.
4 Recovery button was pressed (EC firmware).
32 Developer switch was enabled.
512 Firmware write protection was disabled.
==== ===========================================
What: /sys/bus/platform/devices/GGL0001:*/FMAP
Date: May 2022
KernelVersion: 5.19
Description:
Returns physical memory address of the start of the main
processor firmware flashmap.
What: /sys/bus/platform/devices/GGL0001:*/FRID
Date: May 2022
KernelVersion: 5.19
Description:
Returns firmware version for the read-only portion of the
main processor firmware.
What: /sys/bus/platform/devices/GGL0001:*/FWID
Date: May 2022
KernelVersion: 5.19
Description:
Returns firmware version for the rewritable portion of the
main processor firmware.
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.0
Date: May 2022
KernelVersion: 5.19
Description:
Returns type of the GPIO signal for the Chrome OS specific
GPIO assignments (integer).
=========== ==================================
1 Recovery button.
2 Developer mode switch.
3 Firmware write protection switch.
256 to 511 Debug header GPIO 0 to GPIO 255.
=========== ==================================
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.1
Date: May 2022
KernelVersion: 5.19
Description:
Returns signal attributes of the GPIO signal (integer bitfield).
== =======================
0 Signal is active low.
1 Signal is active high.
== =======================
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.2
Date: May 2022
KernelVersion: 5.19
Description:
Returns the GPIO number on the specified GPIO
controller.
What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.3
Date: May 2022
KernelVersion: 5.19
Description:
Returns name of the GPIO controller.
What: /sys/bus/platform/devices/GGL0001:*/HWID
Date: May 2022
KernelVersion: 5.19
Description:
Returns hardware ID for the Chromebook.
What: /sys/bus/platform/devices/GGL0001:*/MECK
Date: May 2022
KernelVersion: 5.19
Description:
Returns the SHA-1 or SHA-256 hash that is read out of the
Management Engine extended registers during boot. The hash
is exported via ACPI so the OS can verify that the Management
Engine firmware has not changed. If Management Engine is not
present, or if the firmware was unable to read the extended registers, this buffer size can be zero.
What: /sys/bus/platform/devices/GGL0001:*/VBNV.0
Date: May 2022
KernelVersion: 5.19
Description:
Returns offset in CMOS bank 0 of the verified boot non-volatile
storage block, counting from the first writable CMOS byte
(that is, 'offset = 0' is the byte following the 14 bytes of
clock data).
What: /sys/bus/platform/devices/GGL0001:*/VBNV.1
Date: May 2022
KernelVersion: 5.19
Description:
Return the size in bytes of the verified boot non-volatile
storage block.
What: /sys/bus/platform/devices/GGL0001:*/VDAT
Date: May 2022
KernelVersion: 5.19
Description:
Returns the verified boot data block shared between the
firmware verification step and the kernel verification step
(binary).

61
Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update Normal file
View File

@ -0,0 +1,61 @@
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/sr_root_entry_hash
Date: Sep 2022
KernelVersion: 5.20
Contact: Russ Weight <russell.h.weight@intel.com>
Description: Read only. Returns the root entry hash for the static
region if one is programmed, else it returns the
string: "hash not programmed". This file is only
visible if the underlying device supports it.
Format: string.
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/pr_root_entry_hash
Date: Sep 2022
KernelVersion: 5.20
Contact: Russ Weight <russell.h.weight@intel.com>
Description: Read only. Returns the root entry hash for the partial
reconfiguration region if one is programmed, else it
returns the string: "hash not programmed". This file
is only visible if the underlying device supports it.
Format: string.
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/bmc_root_entry_hash
Date: Sep 2022
KernelVersion: 5.20
Contact: Russ Weight <russell.h.weight@intel.com>
Description: Read only. Returns the root entry hash for the BMC image
if one is programmed, else it returns the string:
"hash not programmed". This file is only visible if the
underlying device supports it.
Format: string.
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/sr_canceled_csks
Date: Sep 2022
KernelVersion: 5.20
Contact: Russ Weight <russell.h.weight@intel.com>
Description: Read only. Returns a list of indices for canceled code
signing keys for the static region. The standard bitmap
list format is used (e.g. "1,2-6,9").
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/pr_canceled_csks
Date: Sep 2022
KernelVersion: 5.20
Contact: Russ Weight <russell.h.weight@intel.com>
Description: Read only. Returns a list of indices for canceled code
signing keys for the partial reconfiguration region. The
standard bitmap list format is used (e.g. "1,2-6,9").
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/bmc_canceled_csks
Date: Sep 2022
KernelVersion: 5.20
Contact: Russ Weight <russell.h.weight@intel.com>
Description: Read only. Returns a list of indices for canceled code
signing keys for the BMC. The standard bitmap list format
is used (e.g. "1,2-6,9").
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/flash_count
Date: Sep 2022
KernelVersion: 5.20
Contact: Russ Weight <russell.h.weight@intel.com>
Description: Read only. Returns number of times the secure update
staging area has been flashed.
Format: "%u".

49
Documentation/ABI/testing/sysfs-driver-qat Normal file
View File

@ -0,0 +1,49 @@
What: /sys/bus/pci/devices/<BDF>/qat/state
Date: June 2022
KernelVersion: 5.20
Contact: qat-linux@intel.com
Description: (RW) Reports the current state of the QAT device. Write to
the file to start or stop the device.
The values are:
* up: the device is up and running
* down: the device is down
It is possible to transition the device from up to down only
if the device is up and vice versa.
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat/cfg_services
Date: June 2022
KernelVersion: 5.20
Contact: qat-linux@intel.com
Description: (RW) Reports the current configuration of the QAT device.
Write to the file to change the configured services.
The values are:
* sym;asym: the device is configured for running crypto
services
* dc: the device is configured for running compression services
It is possible to set the configuration only if the device
is in the `down` state (see /sys/bus/pci/devices/<BDF>/qat/state)
The following example shows how to change the configuration of
a device configured for running crypto services in order to
run data compression::
# cat /sys/bus/pci/devices/<BDF>/qat/state
up
# cat /sys/bus/pci/devices/<BDF>/qat/cfg_services
sym;asym
# echo down > /sys/bus/pci/devices/<BDF>/qat/state
# echo dc > /sys/bus/pci/devices/<BDF>/qat/cfg_services
# echo up > /sys/bus/pci/devices/<BDF>/qat/state
# cat /sys/bus/pci/devices/<BDF>/qat/cfg_services
dc
This attribute is only available for qat_4xxx devices.

39
Documentation/ABI/testing/sysfs-platform-intel-ifs Normal file
View File

@ -0,0 +1,39 @@
What: /sys/devices/virtual/misc/intel_ifs_<N>/run_test
Date: April 21 2022
KernelVersion: 5.19
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
Description: Write <cpu#> to trigger IFS test for one online core.
Note that the test is per core. The cpu# can be
for any thread on the core. Running on one thread
completes the test for the core containing that thread.
Example: to test the core containing cpu5: echo 5 >
/sys/devices/platform/intel_ifs.<N>/run_test
What: /sys/devices/virtual/misc/intel_ifs_<N>/status
Date: April 21 2022
KernelVersion: 5.19
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
Description: The status of the last test. It can be one of "pass", "fail"
or "untested".
What: /sys/devices/virtual/misc/intel_ifs_<N>/details
Date: April 21 2022
KernelVersion: 5.19
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
Description: Additional information regarding the last test. The details file reports
the hex value of the SCAN_STATUS MSR. Note that the error_code field
may contain driver defined software code not defined in the Intel SDM.
What: /sys/devices/virtual/misc/intel_ifs_<N>/image_version
Date: April 21 2022
KernelVersion: 5.19
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
Description: Version (hexadecimal) of loaded IFS binary image. If no scan image
is loaded reports "none".
What: /sys/devices/virtual/misc/intel_ifs_<N>/reload
Date: April 21 2022
KernelVersion: 5.19
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
Description: Write "1" (or "y" or "Y") to reload the IFS image from
/lib/firmware/intel/ifs/ff-mm-ss.scan.

129
Documentation/PCI/endpoint/pci-vntb-function.rst Normal file
View File

@ -0,0 +1,129 @@
.. SPDX-License-Identifier: GPL-2.0
=================
PCI vNTB Function
=================
:Author: Frank Li <Frank.Li@nxp.com>
The difference between PCI NTB function and PCI vNTB function is
PCI NTB function need at two endpoint instances and connect HOST1
and HOST2.
PCI vNTB function only use one host and one endpoint(EP), use NTB
connect EP and PCI host
.. code-block:: text
+------------+ +---------------------------------------+
| | | |
+------------+ | +--------------+
| NTB | | | NTB |
| NetDev | | | NetDev |
+------------+ | +--------------+
| NTB | | | NTB |
| Transfer | | | Transfer |
+------------+ | +--------------+
| | | | |
| PCI NTB | | | |
| EPF | | | |
| Driver | | | PCI Virtual |
| | +---------------+ | NTB Driver |
| | | PCI EP NTB |<------>| |
| | | FN Driver | | |
+------------+ +---------------+ +--------------+
| | | | | |
| PCI BUS | <-----> | PCI EP BUS | | Virtual PCI |
| | PCI | | | BUS |
+------------+ +---------------+--------+--------------+
PCI RC PCI EP
Constructs used for Implementing vNTB
=====================================
1) Config Region
2) Self Scratchpad Registers
3) Peer Scratchpad Registers
4) Doorbell (DB) Registers
5) Memory Window (MW)
Config Region:
--------------
It is same as PCI NTB Function driver
Scratchpad Registers:
---------------------
It is appended after Config region.
.. code-block:: text
+--------------------------------------------------+ Base
| |
| |
| |
| Common Config Register |
| |
| |
| |
+-----------------------+--------------------------+ Base + span_offset
| | |
| Peer Span Space | Span Space |
| | |
| | |
+-----------------------+--------------------------+ Base + span_offset
| | | + span_count * 4
| | |
| Span Space | Peer Span Space |
| | |
+-----------------------+--------------------------+
Virtual PCI Pcie Endpoint
NTB Driver NTB Driver
Doorbell Registers:
-------------------
Doorbell Registers are used by the hosts to interrupt each other.
Memory Window:
--------------
Actual transfer of data between the two hosts will happen using the
memory window.
Modeling Constructs:
====================
32-bit BARs.
====== ===============
BAR NO CONSTRUCTS USED
====== ===============
BAR0 Config Region
BAR1 Doorbell
BAR2 Memory Window 1
BAR3 Memory Window 2
BAR4 Memory Window 3
BAR5 Memory Window 4
====== ===============
64-bit BARs.
====== ===============================
BAR NO CONSTRUCTS USED
====== ===============================
BAR0 Config Region + Scratchpad
BAR1
BAR2 Doorbell
BAR3
BAR4 Memory Window 1
BAR5
====== ===============================

167
Documentation/PCI/endpoint/pci-vntb-howto.rst Normal file
View File

@ -0,0 +1,167 @@
.. SPDX-License-Identifier: GPL-2.0
===================================================================
PCI Non-Transparent Bridge (NTB) Endpoint Function (EPF) User Guide
===================================================================
:Author: Frank Li <Frank.Li@nxp.com>
This document is a guide to help users use pci-epf-vntb function driver
and ntb_hw_epf host driver for NTB functionality. The list of steps to
be followed in the host side and EP side is given below. For the hardware
configuration and internals of NTB using configurable endpoints see
Documentation/PCI/endpoint/pci-vntb-function.rst
Endpoint Device
===============
Endpoint Controller Devices
---------------------------
To find the list of endpoint controller devices in the system::
# ls /sys/class/pci_epc/
5f010000.pcie_ep
If PCI_ENDPOINT_CONFIGFS is enabled::
# ls /sys/kernel/config/pci_ep/controllers
5f010000.pcie_ep
Endpoint Function Drivers
-------------------------
To find the list of endpoint function drivers in the system::
# ls /sys/bus/pci-epf/drivers
pci_epf_ntb pci_epf_test pci_epf_vntb
If PCI_ENDPOINT_CONFIGFS is enabled::
# ls /sys/kernel/config/pci_ep/functions
pci_epf_ntb pci_epf_test pci_epf_vntb
Creating pci-epf-vntb Device
----------------------------
PCI endpoint function device can be created using the configfs. To create
pci-epf-vntb device, the following commands can be used::
# mount -t configfs none /sys/kernel/config
# cd /sys/kernel/config/pci_ep/
# mkdir functions/pci_epf_vntb/func1
The "mkdir func1" above creates the pci-epf-ntb function device that will
be probed by pci_epf_vntb driver.
The PCI endpoint framework populates the directory with the following
configurable fields::
# ls functions/pci_epf_ntb/func1
baseclass_code deviceid msi_interrupts pci-epf-ntb.0
progif_code secondary subsys_id vendorid
cache_line_size interrupt_pin msix_interrupts primary
revid subclass_code subsys_vendor_id
The PCI endpoint function driver populates these entries with default values
when the device is bound to the driver. The pci-epf-vntb driver populates
vendorid with 0xffff and interrupt_pin with 0x0001::
# cat functions/pci_epf_vntb/func1/vendorid
0xffff
# cat functions/pci_epf_vntb/func1/interrupt_pin
0x0001
Configuring pci-epf-vntb Device
-------------------------------
The user can configure the pci-epf-vntb device using its configfs entry. In order
to change the vendorid and the deviceid, the following
commands can be used::
# echo 0x1957 > functions/pci_epf_vntb/func1/vendorid
# echo 0x0809 > functions/pci_epf_vntb/func1/deviceid
In order to configure NTB specific attributes, a new sub-directory to func1
should be created::
# mkdir functions/pci_epf_vntb/func1/pci_epf_vntb.0/
The NTB function driver will populate this directory with various attributes
that can be configured by the user::
# ls functions/pci_epf_vntb/func1/pci_epf_vntb.0/
db_count mw1 mw2 mw3 mw4 num_mws
spad_count
A sample configuration for NTB function is given below::
# echo 4 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/db_count
# echo 128 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/spad_count
# echo 1 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/num_mws
# echo 0x100000 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/mw1
A sample configuration for virtual NTB driver for virutal PCI bus::
# echo 0x1957 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vntb_vid
# echo 0x080A > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vntb_pid
# echo 0x10 > functions/pci_epf_vntb/func1/pci_epf_vntb.0/vbus_number
Binding pci-epf-ntb Device to EP Controller
--------------------------------------------
NTB function device should be attached to PCI endpoint controllers
connected to the host.
# ln -s controllers/5f010000.pcie_ep functions/pci-epf-ntb/func1/primary
Once the above step is completed, the PCI endpoint controllers are ready to
establish a link with the host.
Start the Link
--------------
In order for the endpoint device to establish a link with the host, the _start_
field should be populated with '1'. For NTB, both the PCI endpoint controllers
should establish link with the host (imx8 don't need this steps)::
# echo 1 > controllers/5f010000.pcie_ep/start
RootComplex Device
==================
lspci Output at Host side
-------------------------
Note that the devices listed here correspond to the values populated in
"Creating pci-epf-ntb Device" section above::
# lspci
00:00.0 PCI bridge: Freescale Semiconductor Inc Device 0000 (rev 01)
01:00.0 RAM memory: Freescale Semiconductor Inc Device 0809
Endpoint Device / Virtual PCI bus
=================================
lspci Output at EP Side / Virtual PCI bus
-----------------------------------------
Note that the devices listed here correspond to the values populated in
"Creating pci-epf-ntb Device" section above::
# lspci
10:00.0 Unassigned class [ffff]: Dawicontrol Computersysteme GmbH Device 1234 (rev ff)
Using ntb_hw_epf Device
-----------------------
The host side software follows the standard NTB software architecture in Linux.
All the existing client side NTB utilities like NTB Transport Client and NTB
Netdev, NTB Ping Pong Test Client and NTB Tool Test Client can be used with NTB
function device.
For more information on NTB see
:doc:`Non-Transparent Bridge <../../driver-api/ntb>`

260
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst Normal file
View File

@ -0,0 +1,260 @@
=========================================
Processor MMIO Stale Data Vulnerabilities
=========================================
Processor MMIO Stale Data Vulnerabilities are a class of memory-mapped I/O
(MMIO) vulnerabilities that can expose data. The sequences of operations for
exposing data range from simple to very complex. Because most of the
vulnerabilities require the attacker to have access to MMIO, many environments
are not affected. System environments using virtualization where MMIO access is
provided to untrusted guests may need mitigation. These vulnerabilities are
not transient execution attacks. However, these vulnerabilities may propagate
stale data into core fill buffers where the data can subsequently be inferred
by an unmitigated transient execution attack. Mitigation for these
vulnerabilities includes a combination of microcode update and software
changes, depending on the platform and usage model. Some of these mitigations
are similar to those used to mitigate Microarchitectural Data Sampling (MDS) or
those used to mitigate Special Register Buffer Data Sampling (SRBDS).
Data Propagators
================
Propagators are operations that result in stale data being copied or moved from
one microarchitectural buffer or register to another. Processor MMIO Stale Data
Vulnerabilities are operations that may result in stale data being directly
read into an architectural, software-visible state or sampled from a buffer or
register.
Fill Buffer Stale Data Propagator (FBSDP)
-----------------------------------------
Stale data may propagate from fill buffers (FB) into the non-coherent portion
of the uncore on some non-coherent writes. Fill buffer propagation by itself
does not make stale data architecturally visible. Stale data must be propagated
to a location where it is subject to reading or sampling.
Sideband Stale Data Propagator (SSDP)
-------------------------------------
The sideband stale data propagator (SSDP) is limited to the client (including
Intel Xeon server E3) uncore implementation. The sideband response buffer is
shared by all client cores. For non-coherent reads that go to sideband
destinations, the uncore logic returns 64 bytes of data to the core, including
both requested data and unrequested stale data, from a transaction buffer and
the sideband response buffer. As a result, stale data from the sideband
response and transaction buffers may now reside in a core fill buffer.
Primary Stale Data Propagator (PSDP)
------------------------------------
The primary stale data propagator (PSDP) is limited to the client (including
Intel Xeon server E3) uncore implementation. Similar to the sideband response
buffer, the primary response buffer is shared by all client cores. For some
processors, MMIO primary reads will return 64 bytes of data to the core fill
buffer including both requested data and unrequested stale data. This is
similar to the sideband stale data propagator.
Vulnerabilities
===============
Device Register Partial Write (DRPW) (CVE-2022-21166)
-----------------------------------------------------
Some endpoint MMIO registers incorrectly handle writes that are smaller than
the register size. Instead of aborting the write or only copying the correct
subset of bytes (for example, 2 bytes for a 2-byte write), more bytes than
specified by the write transaction may be written to the register. On
processors affected by FBSDP, this may expose stale data from the fill buffers
of the core that created the write transaction.
Shared Buffers Data Sampling (SBDS) (CVE-2022-21125)
----------------------------------------------------
After propagators may have moved data around the uncore and copied stale data
into client core fill buffers, processors affected by MFBDS can leak data from
the fill buffer. It is limited to the client (including Intel Xeon server E3)
uncore implementation.
Shared Buffers Data Read (SBDR) (CVE-2022-21123)
------------------------------------------------
It is similar to Shared Buffer Data Sampling (SBDS) except that the data is
directly read into the architectural software-visible state. It is limited to
the client (including Intel Xeon server E3) uncore implementation.
Affected Processors
===================
Not all the CPUs are affected by all the variants. For instance, most
processors for the server market (excluding Intel Xeon E3 processors) are
impacted by only Device Register Partial Write (DRPW).
Below is the list of affected Intel processors [#f1]_:
=================== ============ =========
Common name Family_Model Steppings
=================== ============ =========
HASWELL_X 06_3FH 2,4
SKYLAKE_L 06_4EH 3
BROADWELL_X 06_4FH All
SKYLAKE_X 06_55H 3,4,6,7,11
BROADWELL_D 06_56H 3,4,5
SKYLAKE 06_5EH 3
ICELAKE_X 06_6AH 4,5,6
ICELAKE_D 06_6CH 1
ICELAKE_L 06_7EH 5
ATOM_TREMONT_D 06_86H All
LAKEFIELD 06_8AH 1
KABYLAKE_L 06_8EH 9 to 12
ATOM_TREMONT 06_96H 1
ATOM_TREMONT_L 06_9CH 0
KABYLAKE 06_9EH 9 to 13
COMETLAKE 06_A5H 2,3,5
COMETLAKE_L 06_A6H 0,1
ROCKETLAKE 06_A7H 1
=================== ============ =========
If a CPU is in the affected processor list, but not affected by a variant, it
is indicated by new bits in MSR IA32_ARCH_CAPABILITIES. As described in a later
section, mitigation largely remains the same for all the variants, i.e. to
clear the CPU fill buffers via VERW instruction.
New bits in MSRs
================
Newer processors and microcode update on existing affected processors added new
bits to IA32_ARCH_CAPABILITIES MSR. These bits can be used to enumerate
specific variants of Processor MMIO Stale Data vulnerabilities and mitigation
capability.
MSR IA32_ARCH_CAPABILITIES
--------------------------
Bit 13 - SBDR_SSDP_NO - When set, processor is not affected by either the
Shared Buffers Data Read (SBDR) vulnerability or the sideband stale
data propagator (SSDP).
Bit 14 - FBSDP_NO - When set, processor is not affected by the Fill Buffer
Stale Data Propagator (FBSDP).
Bit 15 - PSDP_NO - When set, processor is not affected by Primary Stale Data
Propagator (PSDP).
Bit 17 - FB_CLEAR - When set, VERW instruction will overwrite CPU fill buffer
values as part of MD_CLEAR operations. Processors that do not
enumerate MDS_NO (meaning they are affected by MDS) but that do
enumerate support for both L1D_FLUSH and MD_CLEAR implicitly enumerate
FB_CLEAR as part of their MD_CLEAR support.
Bit 18 - FB_CLEAR_CTRL - Processor supports read and write to MSR
IA32_MCU_OPT_CTRL[FB_CLEAR_DIS]. On such processors, the FB_CLEAR_DIS
bit can be set to cause the VERW instruction to not perform the
FB_CLEAR action. Not all processors that support FB_CLEAR will support
FB_CLEAR_CTRL.
MSR IA32_MCU_OPT_CTRL
---------------------
Bit 3 - FB_CLEAR_DIS - When set, VERW instruction does not perform the FB_CLEAR
action. This may be useful to reduce the performance impact of FB_CLEAR in
cases where system software deems it warranted (for example, when performance
is more critical, or the untrusted software has no MMIO access). Note that
FB_CLEAR_DIS has no impact on enumeration (for example, it does not change
FB_CLEAR or MD_CLEAR enumeration) and it may not be supported on all processors
that enumerate FB_CLEAR.
Mitigation
==========
Like MDS, all variants of Processor MMIO Stale Data vulnerabilities have the
same mitigation strategy to force the CPU to clear the affected buffers before
an attacker can extract the secrets.
This is achieved by using the otherwise unused and obsolete VERW instruction in
combination with a microcode update. The microcode clears the affected CPU
buffers when the VERW instruction is executed.
Kernel reuses the MDS function to invoke the buffer clearing:
mds_clear_cpu_buffers()
On MDS affected CPUs, the kernel already invokes CPU buffer clear on
kernel/userspace, hypervisor/guest and C-state (idle) transitions. No
additional mitigation is needed on such CPUs.
For CPUs not affected by MDS or TAA, mitigation is needed only for the attacker
with MMIO capability. Therefore, VERW is not required for kernel/userspace. For
virtualization case, VERW is only needed at VMENTER for a guest with MMIO
capability.
Mitigation points
-----------------
Return to user space
^^^^^^^^^^^^^^^^^^^^
Same mitigation as MDS when affected by MDS/TAA, otherwise no mitigation
needed.
C-State transition
^^^^^^^^^^^^^^^^^^
Control register writes by CPU during C-state transition can propagate data
from fill buffer to uncore buffers. Execute VERW before C-state transition to
clear CPU fill buffers.
Guest entry point
^^^^^^^^^^^^^^^^^
Same mitigation as MDS when processor is also affected by MDS/TAA, otherwise
execute VERW at VMENTER only for MMIO capable guests. On CPUs not affected by
MDS/TAA, guest without MMIO access cannot extract secrets using Processor MMIO
Stale Data vulnerabilities, so there is no need to execute VERW for such guests.
Mitigation control on the kernel command line
---------------------------------------------
The kernel command line allows to control the Processor MMIO Stale Data
mitigations at boot time with the option "mmio_stale_data=". The valid
arguments for this option are:
========== =================================================================
full If the CPU is vulnerable, enable mitigation; CPU buffer clearing
on exit to userspace and when entering a VM. Idle transitions are
protected as well. It does not automatically disable SMT.
full,nosmt Same as full, with SMT disabled on vulnerable CPUs. This is the
complete mitigation.
off Disables mitigation completely.
========== =================================================================
If the CPU is affected and mmio_stale_data=off is not supplied on the kernel
command line, then the kernel selects the appropriate mitigation.
Mitigation status information
-----------------------------
The Linux kernel provides a sysfs interface to enumerate the current
vulnerability status of the system: whether the system is vulnerable, and
which mitigations are active. The relevant sysfs file is:
/sys/devices/system/cpu/vulnerabilities/mmio_stale_data
The possible values in this file are:
.. list-table::
* - 'Not affected'
- The processor is not vulnerable
* - 'Vulnerable'
- The processor is vulnerable, but no mitigation enabled
* - 'Vulnerable: Clear CPU buffers attempted, no microcode'
- The processor is vulnerable, but microcode is not updated. The
mitigation is enabled on a best effort basis.
* - 'Mitigation: Clear CPU buffers'
- The processor is vulnerable and the CPU buffer clearing mitigation is
enabled.
* - 'Unknown: No mitigations'
- The processor vulnerability status is unknown because it is
out of Servicing period. Mitigation is not attempted.
Definitions:
------------
Servicing period: The process of providing functional and security updates to
Intel processors or platforms, utilizing the Intel Platform Update (IPU)
process or other similar mechanisms.
End of Servicing Updates (ESU): ESU is the date at which Intel will no
longer provide Servicing, such as through IPU or other similar update
processes. ESU dates will typically be aligned to end of quarter.
If the processor is vulnerable then the following information is appended to
the above information:
======================== ===========================================
'SMT vulnerable' SMT is enabled
'SMT disabled' SMT is disabled
'SMT Host state unknown' Kernel runs in a VM, Host SMT state unknown
======================== ===========================================
References
----------
.. [#f1] Affected Processors
https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html

294
Documentation/admin-guide/mm/damon/lru_sort.rst Normal file
View File

@ -0,0 +1,294 @@
.. SPDX-License-Identifier: GPL-2.0
=============================
DAMON-based LRU-lists Sorting
=============================
DAMON-based LRU-lists Sorting (DAMON_LRU_SORT) is a static kernel module that
aimed to be used for proactive and lightweight data access pattern based
(de)prioritization of pages on their LRU-lists for making LRU-lists a more
trusworthy data access pattern source.
Where Proactive LRU-lists Sorting is Required?
==============================================
As page-granularity access checking overhead could be significant on huge
systems, LRU lists are normally not proactively sorted but partially and
reactively sorted for special events including specific user requests, system
calls and memory pressure. As a result, LRU lists are sometimes not so
perfectly prepared to be used as a trustworthy access pattern source for some
situations including reclamation target pages selection under sudden memory
pressure.
Because DAMON can identify access patterns of best-effort accuracy while
inducing only user-specified range of overhead, proactively running
DAMON_LRU_SORT could be helpful for making LRU lists more trustworthy access
pattern source with low and controlled overhead.
How It Works?
=============
DAMON_LRU_SORT finds hot pages (pages of memory regions that showing access
rates that higher than a user-specified threshold) and cold pages (pages of
memory regions that showing no access for a time that longer than a
user-specified threshold) using DAMON, and prioritizes hot pages while
deprioritizing cold pages on their LRU-lists. To avoid it consuming too much
CPU for the prioritizations, a CPU time usage limit can be configured. Under
the limit, it prioritizes and deprioritizes more hot and cold pages first,
respectively. System administrators can also configure under what situation
this scheme should automatically activated and deactivated with three memory
pressure watermarks.
Its default parameters for hotness/coldness thresholds and CPU quota limit are
conservatively chosen. That is, the module under its default parameters could
be widely used without harm for common situations while providing a level of
benefits for systems having clear hot/cold access patterns under memory
pressure while consuming only a limited small portion of CPU time.
Interface: Module Parameters
============================
To use this feature, you should first ensure your system is running on a kernel
that is built with ``CONFIG_DAMON_LRU_SORT=y``.
To let sysadmins enable or disable it and tune for the given system,
DAMON_LRU_SORT utilizes module parameters. That is, you can put
``damon_lru_sort.<parameter>=<value>`` on the kernel boot command line or write
proper values to ``/sys/modules/damon_lru_sort/parameters/<parameter>`` files.
Below are the description of each parameter.
enabled
-------
Enable or disable DAMON_LRU_SORT.
You can enable DAMON_LRU_SORT by setting the value of this parameter as ``Y``.
Setting it as ``N`` disables DAMON_LRU_SORT. Note that DAMON_LRU_SORT could do
no real monitoring and LRU-lists sorting due to the watermarks-based activation
condition. Refer to below descriptions for the watermarks parameter for this.
commit_inputs
-------------
Make DAMON_LRU_SORT reads the input parameters again, except ``enabled``.
Input parameters that updated while DAMON_LRU_SORT is running are not applied
by default. Once this parameter is set as ``Y``, DAMON_LRU_SORT reads values
of parametrs except ``enabled`` again. Once the re-reading is done, this
parameter is set as ``N``. If invalid parameters are found while the
re-reading, DAMON_LRU_SORT will be disabled.
hot_thres_access_freq
---------------------
Access frequency threshold for hot memory regions identification in permil.
If a memory region is accessed in frequency of this or higher, DAMON_LRU_SORT
identifies the region as hot, and mark it as accessed on the LRU list, so that
it could not be reclaimed under memory pressure. 50% by default.
cold_min_age
------------
Time threshold for cold memory regions identification in microseconds.
If a memory region is not accessed for this or longer time, DAMON_LRU_SORT
identifies the region as cold, and mark it as unaccessed on the LRU list, so
that it could be reclaimed first under memory pressure. 120 seconds by
default.
quota_ms
--------
Limit of time for trying the LRU lists sorting in milliseconds.
DAMON_LRU_SORT tries to use only up to this time within a time window
(quota_reset_interval_ms) for trying LRU lists sorting. This can be used
for limiting CPU consumption of DAMON_LRU_SORT. If the value is zero, the
limit is disabled.
10 ms by default.
quota_reset_interval_ms
-----------------------
The time quota charge reset interval in milliseconds.
The charge reset interval for the quota of time (quota_ms). That is,
DAMON_LRU_SORT does not try LRU-lists sorting for more than quota_ms
milliseconds or quota_sz bytes within quota_reset_interval_ms milliseconds.
1 second by default.
wmarks_interval
---------------
The watermarks check time interval in microseconds.
Minimal time to wait before checking the watermarks, when DAMON_LRU_SORT is
enabled but inactive due to its watermarks rule. 5 seconds by default.
wmarks_high
-----------
Free memory rate (per thousand) for the high watermark.
If free memory of the system in bytes per thousand bytes is higher than this,
DAMON_LRU_SORT becomes inactive, so it does nothing but periodically checks the
watermarks. 200 (20%) by default.
wmarks_mid
----------
Free memory rate (per thousand) for the middle watermark.
If free memory of the system in bytes per thousand bytes is between this and
the low watermark, DAMON_LRU_SORT becomes active, so starts the monitoring and
the LRU-lists sorting. 150 (15%) by default.
wmarks_low
----------
Free memory rate (per thousand) for the low watermark.
If free memory of the system in bytes per thousand bytes is lower than this,
DAMON_LRU_SORT becomes inactive, so it does nothing but periodically checks the
watermarks. 50 (5%) by default.
sample_interval
---------------
Sampling interval for the monitoring in microseconds.
The sampling interval of DAMON for the cold memory monitoring. Please refer to
the DAMON documentation (:doc:`usage`) for more detail. 5ms by default.
aggr_interval
-------------
Aggregation interval for the monitoring in microseconds.
The aggregation interval of DAMON for the cold memory monitoring. Please
refer to the DAMON documentation (:doc:`usage`) for more detail. 100ms by
default.
min_nr_regions
--------------
Minimum number of monitoring regions.
The minimal number of monitoring regions of DAMON for the cold memory
monitoring. This can be used to set lower-bound of the monitoring quality.
But, setting this too high could result in increased monitoring overhead.
Please refer to the DAMON documentation (:doc:`usage`) for more detail. 10 by
default.
max_nr_regions
--------------
Maximum number of monitoring regions.
The maximum number of monitoring regions of DAMON for the cold memory
monitoring. This can be used to set upper-bound of the monitoring overhead.
However, setting this too low could result in bad monitoring quality. Please
refer to the DAMON documentation (:doc:`usage`) for more detail. 1000 by
defaults.
monitor_region_start
--------------------
Start of target memory region in physical address.
The start physical address of memory region that DAMON_LRU_SORT will do work
against. By default, biggest System RAM is used as the region.
monitor_region_end
------------------
End of target memory region in physical address.
The end physical address of memory region that DAMON_LRU_SORT will do work
against. By default, biggest System RAM is used as the region.
kdamond_pid
-----------
PID of the DAMON thread.
If DAMON_LRU_SORT is enabled, this becomes the PID of the worker thread. Else,
-1.
nr_lru_sort_tried_hot_regions
-----------------------------
Number of hot memory regions that tried to be LRU-sorted.
bytes_lru_sort_tried_hot_regions
--------------------------------
Total bytes of hot memory regions that tried to be LRU-sorted.
nr_lru_sorted_hot_regions
-------------------------
Number of hot memory regions that successfully be LRU-sorted.
bytes_lru_sorted_hot_regions
----------------------------
Total bytes of hot memory regions that successfully be LRU-sorted.
nr_hot_quota_exceeds
--------------------
Number of times that the time quota limit for hot regions have exceeded.
nr_lru_sort_tried_cold_regions
------------------------------
Number of cold memory regions that tried to be LRU-sorted.
bytes_lru_sort_tried_cold_regions
---------------------------------
Total bytes of cold memory regions that tried to be LRU-sorted.
nr_lru_sorted_cold_regions
--------------------------
Number of cold memory regions that successfully be LRU-sorted.
bytes_lru_sorted_cold_regions
-----------------------------
Total bytes of cold memory regions that successfully be LRU-sorted.
nr_cold_quota_exceeds
---------------------
Number of times that the time quota limit for cold regions have exceeded.
Example
=======
Below runtime example commands make DAMON_LRU_SORT to find memory regions
having >=50% access frequency and LRU-prioritize while LRU-deprioritizing
memory regions that not accessed for 120 seconds. The prioritization and
deprioritization is limited to be done using only up to 1% CPU time to avoid
DAMON_LRU_SORT consuming too much CPU time for the (de)prioritization. It also
asks DAMON_LRU_SORT to do nothing if the system's free memory rate is more than
50%, but start the real works if it becomes lower than 40%. If DAMON_RECLAIM
doesn't make progress and therefore the free memory rate becomes lower than
20%, it asks DAMON_LRU_SORT to do nothing again, so that we can fall back to
the LRU-list based page granularity reclamation. ::
# cd /sys/modules/damon_lru_sort/parameters
# echo 500 > hot_thres_access_freq
# echo 120000000 > cold_min_age
# echo 10 > quota_ms
# echo 1000 > quota_reset_interval_ms
# echo 500 > wmarks_high
# echo 400 > wmarks_mid
# echo 200 > wmarks_low
# echo Y > enabled

135
Documentation/admin-guide/mm/shrinker_debugfs.rst Normal file
View File

@ -0,0 +1,135 @@
.. _shrinker_debugfs:
==========================
Shrinker Debugfs Interface
==========================
Shrinker debugfs interface provides a visibility into the kernel memory
shrinkers subsystem and allows to get information about individual shrinkers
and interact with them.
For each shrinker registered in the system a directory in **<debugfs>/shrinker/**
is created. The directory's name is composed from the shrinker's name and an
unique id: e.g. *kfree_rcu-0* or *sb-xfs:vda1-36*.
Each shrinker directory contains **count** and **scan** files, which allow to
trigger *count_objects()* and *scan_objects()* callbacks for each memcg and
numa node (if applicable).
Usage:
------
1. *List registered shrinkers*
::
$ cd /sys/kernel/debug/shrinker/
$ ls
dquota-cache-16 sb-devpts-28 sb-proc-47 sb-tmpfs-42
mm-shadow-18 sb-devtmpfs-5 sb-proc-48 sb-tmpfs-43
mm-zspool:zram0-34 sb-hugetlbfs-17 sb-pstore-31 sb-tmpfs-44
rcu-kfree-0 sb-hugetlbfs-33 sb-rootfs-2 sb-tmpfs-49
sb-aio-20 sb-iomem-12 sb-securityfs-6 sb-tracefs-13
sb-anon_inodefs-15 sb-mqueue-21 sb-selinuxfs-22 sb-xfs:vda1-36
sb-bdev-3 sb-nsfs-4 sb-sockfs-8 sb-zsmalloc-19
sb-bpf-32 sb-pipefs-14 sb-sysfs-26 thp-deferred_split-10
sb-btrfs:vda2-24 sb-proc-25 sb-tmpfs-1 thp-zero-9
sb-cgroup2-30 sb-proc-39 sb-tmpfs-27 xfs-buf:vda1-37
sb-configfs-23 sb-proc-41 sb-tmpfs-29 xfs-inodegc:vda1-38
sb-dax-11 sb-proc-45 sb-tmpfs-35
sb-debugfs-7 sb-proc-46 sb-tmpfs-40
2. *Get information about a specific shrinker*
::
$ cd sb-btrfs\:vda2-24/
$ ls
count scan
3. *Count objects*
Each line in the output has the following format::
<cgroup inode id> <nr of objects on node 0> <nr of objects on node 1> ...
<cgroup inode id> <nr of objects on node 0> <nr of objects on node 1> ...
...
If there are no objects on all numa nodes, a line is omitted. If there
are no objects at all, the output might be empty.
If the shrinker is not memcg-aware or CONFIG_MEMCG is off, 0 is printed
as cgroup inode id. If the shrinker is not numa-aware, 0's are printed
for all nodes except the first one.
::
$ cat count
1 224 2
21 98 0
55 818 10
2367 2 0
2401 30 0
225 13 0
599 35 0
939 124 0
1041 3 0
1075 1 0
1109 1 0
1279 60 0
1313 7 0
1347 39 0
1381 3 0
1449 14 0
1483 63 0
1517 53 0
1551 6 0
1585 1 0
1619 6 0
1653 40 0
1687 11 0
1721 8 0
1755 4 0
1789 52 0
1823 888 0
1857 1 0
1925 2 0
1959 32 0
2027 22 0
2061 9 0
2469 799 0
2537 861 0
2639 1 0
2707 70 0
2775 4 0
2877 84 0
293 1 0
735 8 0
4. *Scan objects*
The expected input format::
<cgroup inode id> <numa id> <number of objects to scan>
For a non-memcg-aware shrinker or on a system with no memory
cgrups **0** should be passed as cgroup id.
::
$ cd /sys/kernel/debug/shrinker/
$ cd sb-btrfs\:vda2-24/
$ cat count | head -n 5
1 212 0
21 97 0
55 802 5
2367 2 0
225 13 0
$ echo "55 0 200" > scan
$ cat count | head -n 5
1 212 0
21 96 0
55 752 5
2367 2 0
225 13 0

136
Documentation/admin-guide/perf/hns3-pmu.rst Normal file
View File

@ -0,0 +1,136 @@
======================================
HNS3 Performance Monitoring Unit (PMU)
======================================
HNS3(HiSilicon network system 3) Performance Monitoring Unit (PMU) is an
End Point device to collect performance statistics of HiSilicon SoC NIC.
On Hip09, each SICL(Super I/O cluster) has one PMU device.
HNS3 PMU supports collection of performance statistics such as bandwidth,
latency, packet rate and interrupt rate.
Each HNS3 PMU supports 8 hardware events.
HNS3 PMU driver
===============
The HNS3 PMU driver registers a perf PMU with the name of its sicl id.::
/sys/devices/hns3_pmu_sicl_<sicl_id>
PMU driver provides description of available events, filter modes, format,
identifier and cpumask in sysfs.
The "events" directory describes the event code of all supported events
shown in perf list.
The "filtermode" directory describes the supported filter modes of each
event.
The "format" directory describes all formats of the config (events) and
config1 (filter options) fields of the perf_event_attr structure.
The "identifier" file shows version of PMU hardware device.
The "bdf_min" and "bdf_max" files show the supported bdf range of each
pmu device.
The "hw_clk_freq" file shows the hardware clock frequency of each pmu
device.
Example usage of checking event code and subevent code::
$# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_time
config=0x00204
$# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_packet_num
config=0x10204
Each performance statistic has a pair of events to get two values to
calculate real performance data in userspace.
The bits 0~15 of config (here 0x0204) are the true hardware event code. If
two events have same value of bits 0~15 of config, that means they are
event pair. And the bit 16 of config indicates getting counter 0 or
counter 1 of hardware event.
After getting two values of event pair in usersapce, the formula of
computation to calculate real performance data is:::
counter 0 / counter 1
Example usage of checking supported filter mode::
$# cat /sys/devices/hns3_pmu_sicl_0/filtermode/bw_ssu_rpu_byte_num
filter mode supported: global/port/port-tc/func/func-queue/
Example usage of perf::
$# perf list
hns3_pmu_sicl_0/bw_ssu_rpu_byte_num/ [kernel PMU event]
hns3_pmu_sicl_0/bw_ssu_rpu_time/ [kernel PMU event]
------------------------------------------
$# perf stat -g -e hns3_pmu_sicl_0/bw_ssu_rpu_byte_num,global=1/ -e hns3_pmu_sicl_0/bw_ssu_rpu_time,global=1/ -I 1000
or
$# perf stat -g -e hns3_pmu_sicl_0/config=0x00002,global=1/ -e hns3_pmu_sicl_0/config=0x10002,global=1/ -I 1000
Filter modes
--------------
1. global mode
PMU collect performance statistics for all HNS3 PCIe functions of IO DIE.
Set the "global" filter option to 1 will enable this mode.
Example usage of perf::
$# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,global=1/ -I 1000
2. port mode
PMU collect performance statistic of one whole physical port. The port id
is same as mac id. The "tc" filter option must be set to 0xF in this mode,
here tc stands for traffic class.
Example usage of perf::
$# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,port=0,tc=0xF/ -I 1000
3. port-tc mode
PMU collect performance statistic of one tc of physical port. The port id
is same as mac id. The "tc" filter option must be set to 0 ~ 7 in this
mode.
Example usage of perf::
$# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,port=0,tc=0/ -I 1000
4. func mode
PMU collect performance statistic of one PF/VF. The function id is BDF of
PF/VF, its conversion formula::
func = (bus << 8) + (device << 3) + (function)
for example:
BDF func
35:00.0 0x3500
35:00.1 0x3501
35:01.0 0x3508
In this mode, the "queue" filter option must be set to 0xFFFF.
Example usage of perf::
$# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,bdf=0x3500,queue=0xFFFF/ -I 1000
5. func-queue mode
PMU collect performance statistic of one queue of PF/VF. The function id
is BDF of PF/VF, the "queue" filter option must be set to the exact queue
id of function.
Example usage of perf::
$# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,bdf=0x3500,queue=0/ -I 1000
6. func-intr mode
PMU collect performance statistic of one interrupt of PF/VF. The function
id is BDF of PF/VF, the "intr" filter option must be set to the exact
interrupt id of function.
Example usage of perf::
$# perf stat -a -e hns3_pmu_sicl_0/config=0x00301,bdf=0x3500,intr=0/ -I 1000

69
Documentation/arm/google/chromebook-boot-flow.rst Normal file
View File

@ -0,0 +1,69 @@
.. SPDX-License-Identifier: GPL-2.0
======================================
Chromebook Boot Flow
======================================
Most recent Chromebooks that use device tree are using the opensource
depthcharge_ bootloader. Depthcharge_ expects the OS to be packaged as a `FIT
Image`_ which contains an OS image as well as a collection of device trees. It
is up to depthcharge_ to pick the right device tree from the `FIT Image`_ and
provide it to the OS.
The scheme that depthcharge_ uses to pick the device tree takes into account
three variables:
- Board name, specified at depthcharge_ compile time. This is $(BOARD) below.
- Board revision number, determined at runtime (perhaps by reading GPIO
strappings, perhaps via some other method). This is $(REV) below.
- SKU number, read from GPIO strappings at boot time. This is $(SKU) below.
For recent Chromebooks, depthcharge_ creates a match list that looks like this:
- google,$(BOARD)-rev$(REV)-sku$(SKU)
- google,$(BOARD)-rev$(REV)
- google,$(BOARD)-sku$(SKU)
- google,$(BOARD)
Note that some older Chromebooks use a slightly different list that may
not include SKU matching or may prioritize SKU/rev differently.
Note that for some boards there may be extra board-specific logic to inject
extra compatibles into the list, but this is uncommon.
Depthcharge_ will look through all device trees in the `FIT Image`_ trying to
find one that matches the most specific compatible. It will then look
through all device trees in the `FIT Image`_ trying to find the one that
matches the *second most* specific compatible, etc.
When searching for a device tree, depthcharge_ doesn't care where the
compatible string falls within a device tree's root compatible string array.
As an example, if we're on board "lazor", rev 4, SKU 0 and we have two device
trees:
- "google,lazor-rev5-sku0", "google,lazor-rev4-sku0", "qcom,sc7180"
- "google,lazor", "qcom,sc7180"
Then depthcharge_ will pick the first device tree even though
"google,lazor-rev4-sku0" was the second compatible listed in that device tree.
This is because it is a more specific compatible than "google,lazor".
It should be noted that depthcharge_ does not have any smarts to try to
match board or SKU revisions that are "close by". That is to say that
if depthcharge_ knows it's on "rev4" of a board but there is no "rev4"
device tree then depthcharge_ *won't* look for a "rev3" device tree.
In general when any significant changes are made to a board the board
revision number is increased even if none of those changes need to
be reflected in the device tree. Thus it's fairly common to see device
trees with multiple revisions.
It should be noted that, taking into account the above system that
depthcharge_ has, the most flexibility is achieved if the device tree
supporting the newest revision(s) of a board omits the "-rev{REV}"
compatible strings. When this is done then if you get a new board
revision and try to run old software on it then we'll at pick the
newest device tree we know about.
.. _depthcharge: https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/depthcharge/
.. _`FIT Image`: https://doc.coreboot.org/lib/payloads/fit.html

428
Documentation/arm64/sme.rst Normal file
View File

@ -0,0 +1,428 @@
===================================================
Scalable Matrix Extension support for AArch64 Linux
===================================================
This document outlines briefly the interface provided to userspace by Linux in
order to support use of the ARM Scalable Matrix Extension (SME).
This is an outline of the most important features and issues only and not
intended to be exhaustive. It should be read in conjunction with the SVE
documentation in sve.rst which provides details on the Streaming SVE mode
included in SME.
This document does not aim to describe the SME architecture or programmer's
model. To aid understanding, a minimal description of relevant programmer's
model features for SME is included in Appendix A.
1. General
-----------
* PSTATE.SM, PSTATE.ZA, the streaming mode vector length, the ZA
register state and TPIDR2_EL0 are tracked per thread.
* The presence of SME is reported to userspace via HWCAP2_SME in the aux vector
AT_HWCAP2 entry. Presence of this flag implies the presence of the SME
instructions and registers, and the Linux-specific system interfaces
described in this document. SME is reported in /proc/cpuinfo as "sme".
* Support for the execution of SME instructions in userspace can also be
detected by reading the CPU ID register ID_AA64PFR1_EL1 using an MRS
instruction, and checking that the value of the SME field is nonzero. [3]
It does not guarantee the presence of the system interfaces described in the
following sections: software that needs to verify that those interfaces are
present must check for HWCAP2_SME instead.
* There are a number of optional SME features, presence of these is reported
through AT_HWCAP2 through:
HWCAP2_SME_I16I64
HWCAP2_SME_F64F64
HWCAP2_SME_I8I32
HWCAP2_SME_F16F32
HWCAP2_SME_B16F32
HWCAP2_SME_F32F32
HWCAP2_SME_FA64
This list may be extended over time as the SME architecture evolves.
These extensions are also reported via the CPU ID register ID_AA64SMFR0_EL1,
which userspace can read using an MRS instruction. See elf_hwcaps.txt and
cpu-feature-registers.txt for details.
* Debuggers should restrict themselves to interacting with the target via the
NT_ARM_SVE, NT_ARM_SSVE and NT_ARM_ZA regsets. The recommended way
of detecting support for these regsets is to connect to a target process
first and then attempt a
ptrace(PTRACE_GETREGSET, pid, NT_ARM_<regset>, &iov).
* Whenever ZA register values are exchanged in memory between userspace and
the kernel, the register value is encoded in memory as a series of horizontal
vectors from 0 to VL/8-1 stored in the same endianness invariant format as is
used for SVE vectors.
* On thread creation TPIDR2_EL0 is preserved unless CLONE_SETTLS is specified,
in which case it is set to 0.
2. Vector lengths
------------------
SME defines a second vector length similar to the SVE vector length which is
controls the size of the streaming mode SVE vectors and the ZA matrix array.
The ZA matrix is square with each side having as many bytes as a streaming
mode SVE vector.
3. Sharing of streaming and non-streaming mode SVE state
---------------------------------------------------------
It is implementation defined which if any parts of the SVE state are shared
between streaming and non-streaming modes. When switching between modes
via software interfaces such as ptrace if no register content is provided as
part of switching no state will be assumed to be shared and everything will
be zeroed.
4. System call behaviour
-------------------------
* On syscall PSTATE.ZA is preserved, if PSTATE.ZA==1 then the contents of the
ZA matrix are preserved.
* On syscall PSTATE.SM will be cleared and the SVE registers will be handled
as per the standard SVE ABI.
* Neither the SVE registers nor ZA are used to pass arguments to or receive
results from any syscall.
* On process creation (eg, clone()) the newly created process will have
PSTATE.SM cleared.
* All other SME state of a thread, including the currently configured vector
length, the state of the PR_SME_VL_INHERIT flag, and the deferred vector
length (if any), is preserved across all syscalls, subject to the specific
exceptions for execve() described in section 6.
5. Signal handling
-------------------
* Signal handlers are invoked with streaming mode and ZA disabled.
* A new signal frame record za_context encodes the ZA register contents on
signal delivery. [1]
* The signal frame record for ZA always contains basic metadata, in particular
the thread's vector length (in za_context.vl).
* The ZA matrix may or may not be included in the record, depending on
the value of PSTATE.ZA. The registers are present if and only if:
za_context.head.size >= ZA_SIG_CONTEXT_SIZE(sve_vq_from_vl(za_context.vl))
in which case PSTATE.ZA == 1.
* If matrix data is present, the remainder of the record has a vl-dependent
size and layout. Macros ZA_SIG_* are defined [1] to facilitate access to
them.
* The matrix is stored as a series of horizontal vectors in the same format as
is used for SVE vectors.
* If the ZA context is too big to fit in sigcontext.__reserved[], then extra
space is allocated on the stack, an extra_context record is written in
__reserved[] referencing this space. za_context is then written in the
extra space. Refer to [1] for further details about this mechanism.
5. Signal return
-----------------
When returning from a signal handler:
* If there is no za_context record in the signal frame, or if the record is
present but contains no register data as described in the previous section,
then ZA is disabled.
* If za_context is present in the signal frame and contains matrix data then
PSTATE.ZA is set to 1 and ZA is populated with the specified data.
* The vector length cannot be changed via signal return. If za_context.vl in
the signal frame does not match the current vector length, the signal return
attempt is treated as illegal, resulting in a forced SIGSEGV.
6. prctl extensions
--------------------
Some new prctl() calls are added to allow programs to manage the SME vector
length:
prctl(PR_SME_SET_VL, unsigned long arg)
Sets the vector length of the calling thread and related flags, where
arg == vl | flags. Other threads of the calling process are unaffected.
vl is the desired vector length, where sve_vl_valid(vl) must be true.
flags:
PR_SME_VL_INHERIT
Inherit the current vector length across execve(). Otherwise, the
vector length is reset to the system default at execve(). (See
Section 9.)
PR_SME_SET_VL_ONEXEC
Defer the requested vector length change until the next execve()
performed by this thread.
The effect is equivalent to implicit execution of the following
call immediately after the next execve() (if any) by the thread:
prctl(PR_SME_SET_VL, arg & ~PR_SME_SET_VL_ONEXEC)
This allows launching of a new program with a different vector
length, while avoiding runtime side effects in the caller.
Without PR_SME_SET_VL_ONEXEC, the requested change takes effect
immediately.
Return value: a nonnegative on success, or a negative value on error:
EINVAL: SME not supported, invalid vector length requested, or
invalid flags.
On success:
* Either the calling thread's vector length or the deferred vector length
to be applied at the next execve() by the thread (dependent on whether
PR_SME_SET_VL_ONEXEC is present in arg), is set to the largest value
supported by the system that is less than or equal to vl. If vl ==
SVE_VL_MAX, the value set will be the largest value supported by the
system.
* Any previously outstanding deferred vector length change in the calling
thread is cancelled.
* The returned value describes the resulting configuration, encoded as for
PR_SME_GET_VL. The vector length reported in this value is the new
current vector length for this thread if PR_SME_SET_VL_ONEXEC was not
present in arg; otherwise, the reported vector length is the deferred
vector length that will be applied at the next execve() by the calling
thread.
* Changing the vector length causes all of ZA, P0..P15, FFR and all bits of
Z0..Z31 except for Z0 bits [127:0] .. Z31 bits [127:0] to become
unspecified, including both streaming and non-streaming SVE state.
Calling PR_SME_SET_VL with vl equal to the thread's current vector
length, or calling PR_SME_SET_VL with the PR_SVE_SET_VL_ONEXEC flag,
does not constitute a change to the vector length for this purpose.
* Changing the vector length causes PSTATE.ZA and PSTATE.SM to be cleared.
Calling PR_SME_SET_VL with vl equal to the thread's current vector
length, or calling PR_SME_SET_VL with the PR_SVE_SET_VL_ONEXEC flag,
does not constitute a change to the vector length for this purpose.
prctl(PR_SME_GET_VL)
Gets the vector length of the calling thread.
The following flag may be OR-ed into the result:
PR_SME_VL_INHERIT
Vector length will be inherited across execve().
There is no way to determine whether there is an outstanding deferred
vector length change (which would only normally be the case between a
fork() or vfork() and the corresponding execve() in typical use).
To extract the vector length from the result, bitwise and it with
PR_SME_VL_LEN_MASK.
Return value: a nonnegative value on success, or a negative value on error:
EINVAL: SME not supported.
7. ptrace extensions
---------------------
* A new regset NT_ARM_SSVE is defined for access to streaming mode SVE
state via PTRACE_GETREGSET and PTRACE_SETREGSET, this is documented in
sve.rst.
* A new regset NT_ARM_ZA is defined for ZA state for access to ZA state via
PTRACE_GETREGSET and PTRACE_SETREGSET.
Refer to [2] for definitions.
The regset data starts with struct user_za_header, containing:
size
Size of the complete regset, in bytes.
This depends on vl and possibly on other things in the future.
If a call to PTRACE_GETREGSET requests less data than the value of
size, the caller can allocate a larger buffer and retry in order to
read the complete regset.
max_size
Maximum size in bytes that the regset can grow to for the target
thread. The regset won't grow bigger than this even if the target
thread changes its vector length etc.
vl
Target thread's current streaming vector length, in bytes.
max_vl
Maximum possible streaming vector length for the target thread.
flags
Zero or more of the following flags, which have the same
meaning and behaviour as the corresponding PR_SET_VL_* flags:
SME_PT_VL_INHERIT
SME_PT_VL_ONEXEC (SETREGSET only).
* The effects of changing the vector length and/or flags are equivalent to
those documented for PR_SME_SET_VL.
The caller must make a further GETREGSET call if it needs to know what VL is
actually set by SETREGSET, unless is it known in advance that the requested
VL is supported.
* The size and layout of the payload depends on the header fields. The
SME_PT_ZA_*() macros are provided to facilitate access to the data.
* In either case, for SETREGSET it is permissible to omit the payload, in which
case the vector length and flags are changed and PSTATE.ZA is set to 0
(along with any consequences of those changes). If a payload is provided
then PSTATE.ZA will be set to 1.
* For SETREGSET, if the requested VL is not supported, the effect will be the
same as if the payload were omitted, except that an EIO error is reported.
No attempt is made to translate the payload data to the correct layout
for the vector length actually set. It is up to the caller to translate the
payload layout for the actual VL and retry.
* The effect of writing a partial, incomplete payload is unspecified.
8. ELF coredump extensions
---------------------------
* NT_ARM_SSVE notes will be added to each coredump for
each thread of the dumped process. The contents will be equivalent to the
data that would have been read if a PTRACE_GETREGSET of the corresponding
type were executed for each thread when the coredump was generated.
* A NT_ARM_ZA note will be added to each coredump for each thread of the
dumped process. The contents will be equivalent to the data that would have
been read if a PTRACE_GETREGSET of NT_ARM_ZA were executed for each thread
when the coredump was generated.
9. System runtime configuration
--------------------------------
* To mitigate the ABI impact of expansion of the signal frame, a policy
mechanism is provided for administrators, distro maintainers and developers
to set the default vector length for userspace processes:
/proc/sys/abi/sme_default_vector_length
Writing the text representation of an integer to this file sets the system
default vector length to the specified value, unless the value is greater
than the maximum vector length supported by the system in which case the
default vector length is set to that maximum.
The result can be determined by reopening the file and reading its
contents.
At boot, the default vector length is initially set to 32 or the maximum
supported vector length, whichever is smaller and supported. This
determines the initial vector length of the init process (PID 1).
Reading this file returns the current system default vector length.
* At every execve() call, the new vector length of the new process is set to
the system default vector length, unless
* PR_SME_VL_INHERIT (or equivalently SME_PT_VL_INHERIT) is set for the
calling thread, or
* a deferred vector length change is pending, established via the
PR_SME_SET_VL_ONEXEC flag (or SME_PT_VL_ONEXEC).
* Modifying the system default vector length does not affect the vector length
of any existing process or thread that does not make an execve() call.
Appendix A. SME programmer's model (informative)
=================================================
This section provides a minimal description of the additions made by SME to the
ARMv8-A programmer's model that are relevant to this document.
Note: This section is for information only and not intended to be complete or
to replace any architectural specification.
A.1. Registers
---------------
In A64 state, SME adds the following:
* A new mode, streaming mode, in which a subset of the normal FPSIMD and SVE
features are available. When supported EL0 software may enter and leave
streaming mode at any time.
For best system performance it is strongly encouraged for software to enable
streaming mode only when it is actively being used.
* A new vector length controlling the size of ZA and the Z registers when in
streaming mode, separately to the vector length used for SVE when not in
streaming mode. There is no requirement that either the currently selected
vector length or the set of vector lengths supported for the two modes in
a given system have any relationship. The streaming mode vector length
is referred to as SVL.
* A new ZA matrix register. This is a square matrix of SVLxSVL bits. Most
operations on ZA require that streaming mode be enabled but ZA can be
enabled without streaming mode in order to load, save and retain data.
For best system performance it is strongly encouraged for software to enable
ZA only when it is actively being used.
* Two new 1 bit fields in PSTATE which may be controlled via the SMSTART and
SMSTOP instructions or by access to the SVCR system register:
* PSTATE.ZA, if this is 1 then the ZA matrix is accessible and has valid
data while if it is 0 then ZA can not be accessed. When PSTATE.ZA is
changed from 0 to 1 all bits in ZA are cleared.
* PSTATE.SM, if this is 1 then the PE is in streaming mode. When the value
of PSTATE.SM is changed then it is implementation defined if the subset
of the floating point register bits valid in both modes may be retained.
Any other bits will be cleared.
References
==========
[1] arch/arm64/include/uapi/asm/sigcontext.h
AArch64 Linux signal ABI definitions
[2] arch/arm64/include/uapi/asm/ptrace.h
AArch64 Linux ptrace ABI definitions
[3] Documentation/arm64/cpu-feature-registers.rst

253
Documentation/block/ublk.rst Normal file
View File

@ -0,0 +1,253 @@
.. SPDX-License-Identifier: GPL-2.0
===========================================
Userspace block device driver (ublk driver)
===========================================
Overview
========
ublk is a generic framework for implementing block device logic from userspace.
The motivation behind it is that moving virtual block drivers into userspace,
such as loop, nbd and similar can be very helpful. It can help to implement
new virtual block device such as ublk-qcow2 (there are several attempts of
implementing qcow2 driver in kernel).
Userspace block devices are attractive because:
- They can be written many programming languages.
- They can use libraries that are not available in the kernel.
- They can be debugged with tools familiar to application developers.
- Crashes do not kernel panic the machine.
- Bugs are likely to have a lower security impact than bugs in kernel
code.
- They can be installed and updated independently of the kernel.
- They can be used to simulate block device easily with user specified
parameters/setting for test/debug purpose
ublk block device (``/dev/ublkb*``) is added by ublk driver. Any IO request
on the device will be forwarded to ublk userspace program. For convenience,
in this document, ``ublk server`` refers to generic ublk userspace
program. ``ublksrv`` [#userspace]_ is one of such implementation. It
provides ``libublksrv`` [#userspace_lib]_ library for developing specific
user block device conveniently, while also generic type block device is
included, such as loop and null. Richard W.M. Jones wrote userspace nbd device
``nbdublk`` [#userspace_nbdublk]_ based on ``libublksrv`` [#userspace_lib]_.
After the IO is handled by userspace, the result is committed back to the
driver, thus completing the request cycle. This way, any specific IO handling
logic is totally done by userspace, such as loop's IO handling, NBD's IO
communication, or qcow2's IO mapping.
``/dev/ublkb*`` is driven by blk-mq request-based driver. Each request is
assigned by one queue wide unique tag. ublk server assigns unique tag to each
IO too, which is 1:1 mapped with IO of ``/dev/ublkb*``.
Both the IO request forward and IO handling result committing are done via
``io_uring`` passthrough command; that is why ublk is also one io_uring based
block driver. It has been observed that using io_uring passthrough command can
give better IOPS than block IO; which is why ublk is one of high performance
implementation of userspace block device: not only IO request communication is
done by io_uring, but also the preferred IO handling in ublk server is io_uring
based approach too.
ublk provides control interface to set/get ublk block device parameters.
The interface is extendable and kabi compatible: basically any ublk request
queue's parameter or ublk generic feature parameters can be set/get via the
interface. Thus, ublk is generic userspace block device framework.
For example, it is easy to setup a ublk device with specified block
parameters from userspace.
Using ublk
==========
ublk requires userspace ublk server to handle real block device logic.
Below is example of using ``ublksrv`` to provide ublk-based loop device.
- add a device::
ublk add -t loop -f ublk-loop.img
- format with xfs, then use it::
mkfs.xfs /dev/ublkb0
mount /dev/ublkb0 /mnt
# do anything. all IOs are handled by io_uring
...
umount /mnt
- list the devices with their info::
ublk list
- delete the device::
ublk del -a
ublk del -n $ublk_dev_id
See usage details in README of ``ublksrv`` [#userspace_readme]_.
Design
======
Control plane
-------------
ublk driver provides global misc device node (``/dev/ublk-control``) for
managing and controlling ublk devices with help of several control commands:
- ``UBLK_CMD_ADD_DEV``
Add a ublk char device (``/dev/ublkc*``) which is talked with ublk server
WRT IO command communication. Basic device info is sent together with this
command. It sets UAPI structure of ``ublksrv_ctrl_dev_info``,
such as ``nr_hw_queues``, ``queue_depth``, and max IO request buffer size,
for which the info is negotiated with the driver and sent back to the server.
When this command is completed, the basic device info is immutable.
- ``UBLK_CMD_SET_PARAMS`` / ``UBLK_CMD_GET_PARAMS``
Set or get parameters of the device, which can be either generic feature
related, or request queue limit related, but can't be IO logic specific,
because the driver does not handle any IO logic. This command has to be
sent before sending ``UBLK_CMD_START_DEV``.
- ``UBLK_CMD_START_DEV``
After the server prepares userspace resources (such as creating per-queue
pthread & io_uring for handling ublk IO), this command is sent to the
driver for allocating & exposing ``/dev/ublkb*``. Parameters set via
``UBLK_CMD_SET_PARAMS`` are applied for creating the device.
- ``UBLK_CMD_STOP_DEV``
Halt IO on ``/dev/ublkb*`` and remove the device. When this command returns,
ublk server will release resources (such as destroying per-queue pthread &
io_uring).
- ``UBLK_CMD_DEL_DEV``
Remove ``/dev/ublkc*``. When this command returns, the allocated ublk device
number can be reused.
- ``UBLK_CMD_GET_QUEUE_AFFINITY``
When ``/dev/ublkc`` is added, the driver creates block layer tagset, so
that each queue's affinity info is available. The server sends
``UBLK_CMD_GET_QUEUE_AFFINITY`` to retrieve queue affinity info. It can
set up the per-queue context efficiently, such as bind affine CPUs with IO
pthread and try to allocate buffers in IO thread context.
- ``UBLK_CMD_GET_DEV_INFO``
For retrieving device info via ``ublksrv_ctrl_dev_info``. It is the server's
responsibility to save IO target specific info in userspace.
Data plane
----------
ublk server needs to create per-queue IO pthread & io_uring for handling IO
commands via io_uring passthrough. The per-queue IO pthread
focuses on IO handling and shouldn't handle any control & management
tasks.
The's IO is assigned by a unique tag, which is 1:1 mapping with IO
request of ``/dev/ublkb*``.
UAPI structure of ``ublksrv_io_desc`` is defined for describing each IO from
the driver. A fixed mmaped area (array) on ``/dev/ublkc*`` is provided for
exporting IO info to the server; such as IO offset, length, OP/flags and
buffer address. Each ``ublksrv_io_desc`` instance can be indexed via queue id
and IO tag directly.
The following IO commands are communicated via io_uring passthrough command,
and each command is only for forwarding the IO and committing the result
with specified IO tag in the command data:
- ``UBLK_IO_FETCH_REQ``
Sent from the server IO pthread for fetching future incoming IO requests
destined to ``/dev/ublkb*``. This command is sent only once from the server
IO pthread for ublk driver to setup IO forward environment.
- ``UBLK_IO_COMMIT_AND_FETCH_REQ``
When an IO request is destined to ``/dev/ublkb*``, the driver stores
the IO's ``ublksrv_io_desc`` to the specified mapped area; then the
previous received IO command of this IO tag (either ``UBLK_IO_FETCH_REQ``
or ``UBLK_IO_COMMIT_AND_FETCH_REQ)`` is completed, so the server gets
the IO notification via io_uring.
After the server handles the IO, its result is committed back to the
driver by sending ``UBLK_IO_COMMIT_AND_FETCH_REQ`` back. Once ublkdrv
received this command, it parses the result and complete the request to
``/dev/ublkb*``. In the meantime setup environment for fetching future
requests with the same IO tag. That is, ``UBLK_IO_COMMIT_AND_FETCH_REQ``
is reused for both fetching request and committing back IO result.
- ``UBLK_IO_NEED_GET_DATA``
With ``UBLK_F_NEED_GET_DATA`` enabled, the WRITE request will be firstly
issued to ublk server without data copy. Then, IO backend of ublk server
receives the request and it can allocate data buffer and embed its addr
inside this new io command. After the kernel driver gets the command,
data copy is done from request pages to this backend's buffer. Finally,
backend receives the request again with data to be written and it can
truly handle the request.
``UBLK_IO_NEED_GET_DATA`` adds one additional round-trip and one
io_uring_enter() syscall. Any user thinks that it may lower performance
should not enable UBLK_F_NEED_GET_DATA. ublk server pre-allocates IO
buffer for each IO by default. Any new project should try to use this
buffer to communicate with ublk driver. However, existing project may
break or not able to consume the new buffer interface; that's why this
command is added for backwards compatibility so that existing projects
can still consume existing buffers.
- data copy between ublk server IO buffer and ublk block IO request
The driver needs to copy the block IO request pages into the server buffer
(pages) first for WRITE before notifying the server of the coming IO, so
that the server can handle WRITE request.
When the server handles READ request and sends
``UBLK_IO_COMMIT_AND_FETCH_REQ`` to the server, ublkdrv needs to copy
the server buffer (pages) read to the IO request pages.
Future development
==================
Container-aware ublk deivice
----------------------------
ublk driver doesn't handle any IO logic. Its function is well defined
for now and very limited userspace interfaces are needed, which is also
well defined too. It is possible to make ublk devices container-aware block
devices in future as Stefan Hajnoczi suggested [#stefan]_, by removing
ADMIN privilege.
Zero copy
---------
Zero copy is a generic requirement for nbd, fuse or similar drivers. A
problem [#xiaoguang]_ Xiaoguang mentioned is that pages mapped to userspace
can't be remapped any more in kernel with existing mm interfaces. This can
occurs when destining direct IO to ``/dev/ublkb*``. Also, he reported that
big requests (IO size >= 256 KB) may benefit a lot from zero copy.
References
==========
.. [#userspace] https://github.com/ming1/ubdsrv
.. [#userspace_lib] https://github.com/ming1/ubdsrv/tree/master/lib
.. [#userspace_nbdublk] https://gitlab.com/rwmjones/libnbd/-/tree/nbdublk
.. [#userspace_readme] https://github.com/ming1/ubdsrv/blob/master/README
.. [#stefan] https://lore.kernel.org/linux-block/YoOr6jBfgVm8GvWg@stefanha-x1.localdomain/
.. [#xiaoguang] https://lore.kernel.org/linux-block/YoOr6jBfgVm8GvWg@stefanha-x1.localdomain/

170
Documentation/bpf/kfuncs.rst Normal file
View File

@ -0,0 +1,170 @@
=============================
BPF Kernel Functions (kfuncs)
=============================
1. Introduction
===============
BPF Kernel Functions or more commonly known as kfuncs are functions in the Linux
kernel which are exposed for use by BPF programs. Unlike normal BPF helpers,
kfuncs do not have a stable interface and can change from one kernel release to
another. Hence, BPF programs need to be updated in response to changes in the
kernel.
2. Defining a kfunc
===================
There are two ways to expose a kernel function to BPF programs, either make an
existing function in the kernel visible, or add a new wrapper for BPF. In both
cases, care must be taken that BPF program can only call such function in a
valid context. To enforce this, visibility of a kfunc can be per program type.
If you are not creating a BPF wrapper for existing kernel function, skip ahead
to :ref:`BPF_kfunc_nodef`.
2.1 Creating a wrapper kfunc
----------------------------
When defining a wrapper kfunc, the wrapper function should have extern linkage.
This prevents the compiler from optimizing away dead code, as this wrapper kfunc
is not invoked anywhere in the kernel itself. It is not necessary to provide a
prototype in a header for the wrapper kfunc.
An example is given below::
/* Disables missing prototype warnings */
__diag_push();
__diag_ignore_all("-Wmissing-prototypes",
"Global kfuncs as their definitions will be in BTF");
struct task_struct *bpf_find_get_task_by_vpid(pid_t nr)
{
return find_get_task_by_vpid(nr);
}
__diag_pop();
A wrapper kfunc is often needed when we need to annotate parameters of the
kfunc. Otherwise one may directly make the kfunc visible to the BPF program by
registering it with the BPF subsystem. See :ref:`BPF_kfunc_nodef`.
2.2 Annotating kfunc parameters
-------------------------------
Similar to BPF helpers, there is sometime need for additional context required
by the verifier to make the usage of kernel functions safer and more useful.
Hence, we can annotate a parameter by suffixing the name of the argument of the
kfunc with a __tag, where tag may be one of the supported annotations.
2.2.1 __sz Annotation
---------------------
This annotation is used to indicate a memory and size pair in the argument list.
An example is given below::
void bpf_memzero(void *mem, int mem__sz)
{
...
}
Here, the verifier will treat first argument as a PTR_TO_MEM, and second
argument as its size. By default, without __sz annotation, the size of the type
of the pointer is used. Without __sz annotation, a kfunc cannot accept a void
pointer.
.. _BPF_kfunc_nodef:
2.3 Using an existing kernel function
-------------------------------------
When an existing function in the kernel is fit for consumption by BPF programs,
it can be directly registered with the BPF subsystem. However, care must still
be taken to review the context in which it will be invoked by the BPF program
and whether it is safe to do so.
2.4 Annotating kfuncs
---------------------
In addition to kfuncs' arguments, verifier may need more information about the
type of kfunc(s) being registered with the BPF subsystem. To do so, we define
flags on a set of kfuncs as follows::
BTF_SET8_START(bpf_task_set)
BTF_ID_FLAGS(func, bpf_get_task_pid, KF_ACQUIRE | KF_RET_NULL)
BTF_ID_FLAGS(func, bpf_put_pid, KF_RELEASE)
BTF_SET8_END(bpf_task_set)
This set encodes the BTF ID of each kfunc listed above, and encodes the flags
along with it. Ofcourse, it is also allowed to specify no flags.
2.4.1 KF_ACQUIRE flag
---------------------
The KF_ACQUIRE flag is used to indicate that the kfunc returns a pointer to a
refcounted object. The verifier will then ensure that the pointer to the object
is eventually released using a release kfunc, or transferred to a map using a
referenced kptr (by invoking bpf_kptr_xchg). If not, the verifier fails the
loading of the BPF program until no lingering references remain in all possible
explored states of the program.
2.4.2 KF_RET_NULL flag
----------------------
The KF_RET_NULL flag is used to indicate that the pointer returned by the kfunc
may be NULL. Hence, it forces the user to do a NULL check on the pointer
returned from the kfunc before making use of it (dereferencing or passing to
another helper). This flag is often used in pairing with KF_ACQUIRE flag, but
both are orthogonal to each other.
2.4.3 KF_RELEASE flag
---------------------
The KF_RELEASE flag is used to indicate that the kfunc releases the pointer
passed in to it. There can be only one referenced pointer that can be passed in.
All copies of the pointer being released are invalidated as a result of invoking
kfunc with this flag.
2.4.4 KF_KPTR_GET flag
----------------------
The KF_KPTR_GET flag is used to indicate that the kfunc takes the first argument
as a pointer to kptr, safely increments the refcount of the object it points to,
and returns a reference to the user. The rest of the arguments may be normal
arguments of a kfunc. The KF_KPTR_GET flag should be used in conjunction with
KF_ACQUIRE and KF_RET_NULL flags.
2.4.5 KF_TRUSTED_ARGS flag
--------------------------
The KF_TRUSTED_ARGS flag is used for kfuncs taking pointer arguments. It
indicates that the all pointer arguments will always be refcounted, and have
their offset set to 0. It can be used to enforce that a pointer to a refcounted
object acquired from a kfunc or BPF helper is passed as an argument to this
kfunc without any modifications (e.g. pointer arithmetic) such that it is
trusted and points to the original object. This flag is often used for kfuncs
that operate (change some property, perform some operation) on an object that
was obtained using an acquire kfunc. Such kfuncs need an unchanged pointer to
ensure the integrity of the operation being performed on the expected object.
2.5 Registering the kfuncs
--------------------------
Once the kfunc is prepared for use, the final step to making it visible is
registering it with the BPF subsystem. Registration is done per BPF program
type. An example is shown below::
BTF_SET8_START(bpf_task_set)
BTF_ID_FLAGS(func, bpf_get_task_pid, KF_ACQUIRE | KF_RET_NULL)
BTF_ID_FLAGS(func, bpf_put_pid, KF_RELEASE)
BTF_SET8_END(bpf_task_set)
static const struct btf_kfunc_id_set bpf_task_kfunc_set = {
.owner = THIS_MODULE,
.set = &bpf_task_set,
};
static int init_subsystem(void)
{
return register_btf_kfunc_id_set(BPF_PROG_TYPE_TRACING, &bpf_task_kfunc_set);
}
late_initcall(init_subsystem);

185
Documentation/bpf/map_hash.rst Normal file
View File

@ -0,0 +1,185 @@
.. SPDX-License-Identifier: GPL-2.0-only
.. Copyright (C) 2022 Red Hat, Inc.
===============================================
BPF_MAP_TYPE_HASH, with PERCPU and LRU Variants
===============================================
.. note::
- ``BPF_MAP_TYPE_HASH`` was introduced in kernel version 3.19
- ``BPF_MAP_TYPE_PERCPU_HASH`` was introduced in version 4.6
- Both ``BPF_MAP_TYPE_LRU_HASH`` and ``BPF_MAP_TYPE_LRU_PERCPU_HASH``
were introduced in version 4.10
``BPF_MAP_TYPE_HASH`` and ``BPF_MAP_TYPE_PERCPU_HASH`` provide general
purpose hash map storage. Both the key and the value can be structs,
allowing for composite keys and values.
The kernel is responsible for allocating and freeing key/value pairs, up
to the max_entries limit that you specify. Hash maps use pre-allocation
of hash table elements by default. The ``BPF_F_NO_PREALLOC`` flag can be
used to disable pre-allocation when it is too memory expensive.
``BPF_MAP_TYPE_PERCPU_HASH`` provides a separate value slot per
CPU. The per-cpu values are stored internally in an array.
The ``BPF_MAP_TYPE_LRU_HASH`` and ``BPF_MAP_TYPE_LRU_PERCPU_HASH``
variants add LRU semantics to their respective hash tables. An LRU hash
will automatically evict the least recently used entries when the hash
table reaches capacity. An LRU hash maintains an internal LRU list that
is used to select elements for eviction. This internal LRU list is
shared across CPUs but it is possible to request a per CPU LRU list with
the ``BPF_F_NO_COMMON_LRU`` flag when calling ``bpf_map_create``.
Usage
=====
.. c:function::
long bpf_map_update_elem(struct bpf_map *map, const void *key, const void *value, u64 flags)
Hash entries can be added or updated using the ``bpf_map_update_elem()``
helper. This helper replaces existing elements atomically. The ``flags``
parameter can be used to control the update behaviour:
- ``BPF_ANY`` will create a new element or update an existing element
- ``BPF_NOEXIST`` will create a new element only if one did not already
exist
- ``BPF_EXIST`` will update an existing element
``bpf_map_update_elem()`` returns 0 on success, or negative error in
case of failure.
.. c:function::
void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)
Hash entries can be retrieved using the ``bpf_map_lookup_elem()``
helper. This helper returns a pointer to the value associated with
``key``, or ``NULL`` if no entry was found.
.. c:function::
long bpf_map_delete_elem(struct bpf_map *map, const void *key)
Hash entries can be deleted using the ``bpf_map_delete_elem()``
helper. This helper will return 0 on success, or negative error in case
of failure.
Per CPU Hashes
--------------
For ``BPF_MAP_TYPE_PERCPU_HASH`` and ``BPF_MAP_TYPE_LRU_PERCPU_HASH``
the ``bpf_map_update_elem()`` and ``bpf_map_lookup_elem()`` helpers
automatically access the hash slot for the current CPU.
.. c:function::
void *bpf_map_lookup_percpu_elem(struct bpf_map *map, const void *key, u32 cpu)
The ``bpf_map_lookup_percpu_elem()`` helper can be used to lookup the
value in the hash slot for a specific CPU. Returns value associated with
``key`` on ``cpu`` , or ``NULL`` if no entry was found or ``cpu`` is
invalid.
Concurrency
-----------
Values stored in ``BPF_MAP_TYPE_HASH`` can be accessed concurrently by
programs running on different CPUs. Since Kernel version 5.1, the BPF
infrastructure provides ``struct bpf_spin_lock`` to synchronise access.
See ``tools/testing/selftests/bpf/progs/test_spin_lock.c``.
Userspace
---------
.. c:function::
int bpf_map_get_next_key(int fd, const void *cur_key, void *next_key)
In userspace, it is possible to iterate through the keys of a hash using
libbpf's ``bpf_map_get_next_key()`` function. The first key can be fetched by
calling ``bpf_map_get_next_key()`` with ``cur_key`` set to
``NULL``. Subsequent calls will fetch the next key that follows the
current key. ``bpf_map_get_next_key()`` returns 0 on success, -ENOENT if
cur_key is the last key in the hash, or negative error in case of
failure.
Note that if ``cur_key`` gets deleted then ``bpf_map_get_next_key()``
will instead return the *first* key in the hash table which is
undesirable. It is recommended to use batched lookup if there is going
to be key deletion intermixed with ``bpf_map_get_next_key()``.
Examples
========
Please see the ``tools/testing/selftests/bpf`` directory for functional
examples. The code snippets below demonstrates API usage.
This example shows how to declare an LRU Hash with a struct key and a
struct value.
.. code-block:: c
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
struct key {
__u32 srcip;
};
struct value {
__u64 packets;
__u64 bytes;
};
struct {
__uint(type, BPF_MAP_TYPE_LRU_HASH);
__uint(max_entries, 32);
__type(key, struct key);
__type(value, struct value);
} packet_stats SEC(".maps");
This example shows how to create or update hash values using atomic
instructions:
.. code-block:: c
static void update_stats(__u32 srcip, int bytes)
{
struct key key = {
.srcip = srcip,
};
struct value *value = bpf_map_lookup_elem(&packet_stats, &key);
if (value) {
__sync_fetch_and_add(&value->packets, 1);
__sync_fetch_and_add(&value->bytes, bytes);
} else {
struct value newval = { 1, bytes };
bpf_map_update_elem(&packet_stats, &key, &newval, BPF_NOEXIST);
}
}
Userspace walking the map elements from the map declared above:
.. code-block:: c
#include <bpf/libbpf.h>
#include <bpf/bpf.h>
static void walk_hash_elements(int map_fd)
{
struct key *cur_key = NULL;
struct key next_key;
struct value value;
int err;
for (;;) {
err = bpf_map_get_next_key(map_fd, cur_key, &next_key);
if (err)
break;
bpf_map_lookup_elem(map_fd, &next_key, &value);
// Use key and value here
cur_key = &next_key;
}
}

137
Documentation/core-api/printk-index.rst Normal file
View File

@ -0,0 +1,137 @@
.. SPDX-License-Identifier: GPL-2.0
============
Printk Index
============
There are many ways how to monitor the state of the system. One important
source of information is the system log. It provides a lot of information,
including more or less important warnings and error messages.
There are monitoring tools that filter and take action based on messages
logged.
The kernel messages are evolving together with the code. As a result,
particular kernel messages are not KABI and never will be!
It is a huge challenge for maintaining the system log monitors. It requires
knowing what messages were updated in a particular kernel version and why.
Finding these changes in the sources would require non-trivial parsers.
Also it would require matching the sources with the binary kernel which
is not always trivial. Various changes might be backported. Various kernel
versions might be used on different monitored systems.
This is where the printk index feature might become useful. It provides
a dump of printk formats used all over the source code used for the kernel
and modules on the running system. It is accessible at runtime via debugfs.
The printk index helps to find changes in the message formats. Also it helps
to track the strings back to the kernel sources and the related commit.
User Interface
==============
The index of printk formats are split in into separate files. The files are
named according to the binaries where the printk formats are built-in. There
is always "vmlinux" and optionally also modules, for example::
/sys/kernel/debug/printk/index/vmlinux
/sys/kernel/debug/printk/index/ext4
/sys/kernel/debug/printk/index/scsi_mod
Note that only loaded modules are shown. Also printk formats from a module
might appear in "vmlinux" when the module is built-in.
The content is inspired by the dynamic debug interface and looks like::
$> head -1 /sys/kernel/debug/printk/index/vmlinux; shuf -n 5 vmlinux
# <level[,flags]> filename:line function "format"
<5> block/blk-settings.c:661 disk_stack_limits "%s: Warning: Device %s is misaligned\n"
<4> kernel/trace/trace.c:8296 trace_create_file "Could not create tracefs '%s' entry\n"
<6> arch/x86/kernel/hpet.c:144 _hpet_print_config "hpet: %s(%d):\n"
<6> init/do_mounts.c:605 prepare_namespace "Waiting for root device %s...\n"
<6> drivers/acpi/osl.c:1410 acpi_no_auto_serialize_setup "ACPI: auto-serialization disabled\n"
, where the meaning is:
- :level: log level value: 0-7 for particular severity, -1 as default,
'c' as continuous line without an explicit log level
- :flags: optional flags: currently only 'c' for KERN_CONT
- :filename\:line: source filename and line number of the related
printk() call. Note that there are many wrappers, for example,
pr_warn(), pr_warn_once(), dev_warn().
- :function: function name where the printk() call is used.
- :format: format string
The extra information makes it a bit harder to find differences
between various kernels. Especially the line number might change
very often. On the other hand, it helps a lot to confirm that
it is the same string or find the commit that is responsible
for eventual changes.
printk() Is Not a Stable KABI
=============================
Several developers are afraid that exporting all these implementation
details into the user space will transform particular printk() calls
into KABI.
But it is exactly the opposite. printk() calls must _not_ be KABI.
And the printk index helps user space tools to deal with this.
Subsystem specific printk wrappers
==================================
The printk index is generated using extra metadata that are stored in
a dedicated .elf section ".printk_index". It is achieved using macro
wrappers doing __printk_index_emit() together with the real printk()
call. The same technique is used also for the metadata used by
the dynamic debug feature.
The metadata are stored for a particular message only when it is printed
using these special wrappers. It is implemented for the commonly
used printk() calls, including, for example, pr_warn(), or pr_once().
Additional changes are necessary for various subsystem specific wrappers
that call the original printk() via a common helper function. These needs
their own wrappers adding __printk_index_emit().
Only few subsystem specific wrappers have been updated so far,
for example, dev_printk(). As a result, the printk formats from
some subsystes can be missing in the printk index.
Subsystem specific prefix
=========================
The macro pr_fmt() macro allows to define a prefix that is printed
before the string generated by the related printk() calls.
Subsystem specific wrappers usually add even more complicated
prefixes.
These prefixes can be stored into the printk index metadata
by an optional parameter of __printk_index_emit(). The debugfs
interface might then show the printk formats including these prefixes.
For example, drivers/acpi/osl.c contains::
#define pr_fmt(fmt) "ACPI: OSL: " fmt
static int __init acpi_no_auto_serialize_setup(char *str)
{
acpi_gbl_auto_serialize_methods = FALSE;
pr_info("Auto-serialization disabled\n");
return 1;
}
This results in the following printk index entry::
<6> drivers/acpi/osl.c:1410 acpi_no_auto_serialize_setup "ACPI: auto-serialization disabled\n"
It helps matching messages from the real log with printk index.
Then the source file name, line number, and function name can
be used to match the string with the source code.

343
Documentation/core-api/watch_queue.rst Normal file
View File

@ -0,0 +1,343 @@
==============================
General notification mechanism
==============================
The general notification mechanism is built on top of the standard pipe driver
whereby it effectively splices notification messages from the kernel into pipes
opened by userspace. This can be used in conjunction with::
* Key/keyring notifications
The notifications buffers can be enabled by:
"General setup"/"General notification queue"
(CONFIG_WATCH_QUEUE)
This document has the following sections:
.. contents:: :local:
Overview
========
This facility appears as a pipe that is opened in a special mode. The pipe's
internal ring buffer is used to hold messages that are generated by the kernel.
These messages are then read out by read(). Splice and similar are disabled on
such pipes due to them wanting to, under some circumstances, revert their
additions to the ring - which might end up interleaved with notification
messages.
The owner of the pipe has to tell the kernel which sources it would like to
watch through that pipe. Only sources that have been connected to a pipe will
insert messages into it. Note that a source may be bound to multiple pipes and
insert messages into all of them simultaneously.
Filters may also be emplaced on a pipe so that certain source types and
subevents can be ignored if they're not of interest.
A message will be discarded if there isn't a slot available in the ring or if
no preallocated message buffer is available. In both of these cases, read()
will insert a WATCH_META_LOSS_NOTIFICATION message into the output buffer after
the last message currently in the buffer has been read.
Note that when producing a notification, the kernel does not wait for the
consumers to collect it, but rather just continues on. This means that
notifications can be generated whilst spinlocks are held and also protects the
kernel from being held up indefinitely by a userspace malfunction.
Message Structure
=================
Notification messages begin with a short header::
struct watch_notification {
__u32 type:24;
__u32 subtype:8;
__u32 info;
};
"type" indicates the source of the notification record and "subtype" indicates
the type of record from that source (see the Watch Sources section below). The
type may also be "WATCH_TYPE_META". This is a special record type generated
internally by the watch queue itself. There are two subtypes:
* WATCH_META_REMOVAL_NOTIFICATION
* WATCH_META_LOSS_NOTIFICATION
The first indicates that an object on which a watch was installed was removed
or destroyed and the second indicates that some messages have been lost.
"info" indicates a bunch of things, including:
* The length of the message in bytes, including the header (mask with
WATCH_INFO_LENGTH and shift by WATCH_INFO_LENGTH__SHIFT). This indicates
the size of the record, which may be between 8 and 127 bytes.
* The watch ID (mask with WATCH_INFO_ID and shift by WATCH_INFO_ID__SHIFT).
This indicates that caller's ID of the watch, which may be between 0
and 255. Multiple watches may share a queue, and this provides a means to
distinguish them.
* A type-specific field (WATCH_INFO_TYPE_INFO). This is set by the
notification producer to indicate some meaning specific to the type and
subtype.
Everything in info apart from the length can be used for filtering.
The header can be followed by supplementary information. The format of this is
at the discretion is defined by the type and subtype.
Watch List (Notification Source) API
====================================
A "watch list" is a list of watchers that are subscribed to a source of
notifications. A list may be attached to an object (say a key or a superblock)
or may be global (say for device events). From a userspace perspective, a
non-global watch list is typically referred to by reference to the object it
belongs to (such as using KEYCTL_NOTIFY and giving it a key serial number to
watch that specific key).
To manage a watch list, the following functions are provided:
* ::
void init_watch_list(struct watch_list *wlist,
void (*release_watch)(struct watch *wlist));
Initialise a watch list. If ``release_watch`` is not NULL, then this
indicates a function that should be called when the watch_list object is
destroyed to discard any references the watch list holds on the watched
object.
* ``void remove_watch_list(struct watch_list *wlist);``
This removes all of the watches subscribed to a watch_list and frees them
and then destroys the watch_list object itself.
Watch Queue (Notification Output) API
=====================================
A "watch queue" is the buffer allocated by an application that notification
records will be written into. The workings of this are hidden entirely inside
of the pipe device driver, but it is necessary to gain a reference to it to set
a watch. These can be managed with:
* ``struct watch_queue *get_watch_queue(int fd);``
Since watch queues are indicated to the kernel by the fd of the pipe that
implements the buffer, userspace must hand that fd through a system call.
This can be used to look up an opaque pointer to the watch queue from the
system call.
* ``void put_watch_queue(struct watch_queue *wqueue);``
This discards the reference obtained from ``get_watch_queue()``.
Watch Subscription API
======================
A "watch" is a subscription on a watch list, indicating the watch queue, and
thus the buffer, into which notification records should be written. The watch
queue object may also carry filtering rules for that object, as set by
userspace. Some parts of the watch struct can be set by the driver::
struct watch {
union {
u32 info_id; /* ID to be OR'd in to info field */
...
};
void *private; /* Private data for the watched object */
u64 id; /* Internal identifier */
...
};
The ``info_id`` value should be an 8-bit number obtained from userspace and
shifted by WATCH_INFO_ID__SHIFT. This is OR'd into the WATCH_INFO_ID field of
struct watch_notification::info when and if the notification is written into
the associated watch queue buffer.
The ``private`` field is the driver's data associated with the watch_list and
is cleaned up by the ``watch_list::release_watch()`` method.
The ``id`` field is the source's ID. Notifications that are posted with a
different ID are ignored.
The following functions are provided to manage watches:
* ``void init_watch(struct watch *watch, struct watch_queue *wqueue);``
Initialise a watch object, setting its pointer to the watch queue, using
appropriate barriering to avoid lockdep complaints.
* ``int add_watch_to_object(struct watch *watch, struct watch_list *wlist);``
Subscribe a watch to a watch list (notification source). The
driver-settable fields in the watch struct must have been set before this
is called.
* ::
int remove_watch_from_object(struct watch_list *wlist,
struct watch_queue *wqueue,
u64 id, false);
Remove a watch from a watch list, where the watch must match the specified
watch queue (``wqueue``) and object identifier (``id``). A notification
(``WATCH_META_REMOVAL_NOTIFICATION``) is sent to the watch queue to
indicate that the watch got removed.
* ``int remove_watch_from_object(struct watch_list *wlist, NULL, 0, true);``
Remove all the watches from a watch list. It is expected that this will be
called preparatory to destruction and that the watch list will be
inaccessible to new watches by this point. A notification
(``WATCH_META_REMOVAL_NOTIFICATION``) is sent to the watch queue of each
subscribed watch to indicate that the watch got removed.
Notification Posting API
========================
To post a notification to watch list so that the subscribed watches can see it,
the following function should be used::
void post_watch_notification(struct watch_list *wlist,
struct watch_notification *n,
const struct cred *cred,
u64 id);
The notification should be preformatted and a pointer to the header (``n``)
should be passed in. The notification may be larger than this and the size in
units of buffer slots is noted in ``n->info & WATCH_INFO_LENGTH``.
The ``cred`` struct indicates the credentials of the source (subject) and is
passed to the LSMs, such as SELinux, to allow or suppress the recording of the
note in each individual queue according to the credentials of that queue
(object).
The ``id`` is the ID of the source object (such as the serial number on a key).
Only watches that have the same ID set in them will see this notification.
Watch Sources
=============
Any particular buffer can be fed from multiple sources. Sources include:
* WATCH_TYPE_KEY_NOTIFY
Notifications of this type indicate changes to keys and keyrings, including
the changes of keyring contents or the attributes of keys.
See Documentation/security/keys/core.rst for more information.
Event Filtering
===============
Once a watch queue has been created, a set of filters can be applied to limit
the events that are received using::
struct watch_notification_filter filter = {
...
};
ioctl(fd, IOC_WATCH_QUEUE_SET_FILTER, &filter)
The filter description is a variable of type::
struct watch_notification_filter {
__u32 nr_filters;
__u32 __reserved;
struct watch_notification_type_filter filters[];
};
Where "nr_filters" is the number of filters in filters[] and "__reserved"
should be 0. The "filters" array has elements of the following type::
struct watch_notification_type_filter {
__u32 type;
__u32 info_filter;
__u32 info_mask;
__u32 subtype_filter[8];
};
Where:
* ``type`` is the event type to filter for and should be something like
"WATCH_TYPE_KEY_NOTIFY"
* ``info_filter`` and ``info_mask`` act as a filter on the info field of the
notification record. The notification is only written into the buffer if::
(watch.info & info_mask) == info_filter
This could be used, for example, to ignore events that are not exactly on
the watched point in a mount tree.
* ``subtype_filter`` is a bitmask indicating the subtypes that are of
interest. Bit 0 of subtype_filter[0] corresponds to subtype 0, bit 1 to
subtype 1, and so on.
If the argument to the ioctl() is NULL, then the filters will be removed and
all events from the watched sources will come through.
Userspace Code Example
======================
A buffer is created with something like the following::
pipe2(fds, O_TMPFILE);
ioctl(fds[1], IOC_WATCH_QUEUE_SET_SIZE, 256);
It can then be set to receive keyring change notifications::
keyctl(KEYCTL_WATCH_KEY, KEY_SPEC_SESSION_KEYRING, fds[1], 0x01);
The notifications can then be consumed by something like the following::
static void consumer(int rfd, struct watch_queue_buffer *buf)
{
unsigned char buffer[128];
ssize_t buf_len;
while (buf_len = read(rfd, buffer, sizeof(buffer)),
buf_len > 0
) {
void *p = buffer;
void *end = buffer + buf_len;
while (p < end) {
union {
struct watch_notification n;
unsigned char buf1[128];
} n;
size_t largest, len;
largest = end - p;
if (largest > 128)
largest = 128;
memcpy(&n, p, largest);
len = (n->info & WATCH_INFO_LENGTH) >>
WATCH_INFO_LENGTH__SHIFT;
if (len == 0 || len > largest)
return;
switch (n.n.type) {
case WATCH_TYPE_META:
got_meta(&n.n);
case WATCH_TYPE_KEY_NOTIFY:
saw_key_change(&n.n);
break;
}
p += len;
}
}
}

13
Documentation/dev-tools/kunit/api/resource.rst Normal file
View File

@ -0,0 +1,13 @@
.. SPDX-License-Identifier: GPL-2.0
============
Resource API
============
This file documents the KUnit resource API.
Most users won't need to use this API directly, power users can use it to store
state on a per-test basis, register custom cleanup actions, and more.
.. kernel-doc:: include/kunit/resource.h
:internal:

101
Documentation/devicetree/bindings/arm/arm,coresight-catu.yaml Normal file
View File

@ -0,0 +1,101 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,coresight-catu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm Coresight Address Translation Unit (CATU)
maintainers:
- Mathieu Poirier <mathieu.poirier@linaro.org>
- Mike Leach <mike.leach@linaro.org>
- Leo Yan <leo.yan@linaro.org>
- Suzuki K Poulose <suzuki.poulose@arm.com>
description: |
CoreSight components are compliant with the ARM CoreSight architecture
specification and can be connected in various topologies to suit a particular
SoCs tracing needs. These trace components can generally be classified as
sinks, links and sources. Trace data produced by one or more sources flows
through the intermediate links connecting the source to the currently selected
sink.
The CoreSight Address Translation Unit (CATU) translates addresses between an
AXI master and system memory. The CATU is normally used along with the TMC to
implement scattering of virtual trace buffers in physical memory. The CATU
translates contiguous Virtual Addresses (VAs) from an AXI master into
non-contiguous Physical Addresses (PAs) that are intended for system memory.
# Need a custom select here or 'arm,primecell' will match on lots of nodes
select:
properties:
compatible:
contains:
const: arm,coresight-catu
required:
- compatible
allOf:
- $ref: /schemas/arm/primecell.yaml#
properties:
compatible:
items:
- const: arm,coresight-catu
- const: arm,primecell
reg:
maxItems: 1
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
items:
- const: apb_pclk
- const: atclk
interrupts:
maxItems: 1
description: Address translation error interrupt
in-ports:
$ref: /schemas/graph.yaml#/properties/ports
additionalProperties: false
properties:
port:
description: AXI Slave connected to another Coresight component
$ref: /schemas/graph.yaml#/properties/port
required:
- compatible
- reg
- clocks
- clock-names
- in-ports
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
catu@207e0000 {
compatible = "arm,coresight-catu", "arm,primecell";
reg = <0x207e0000 0x1000>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
in-ports {
port {
catu_in_port: endpoint {
remote-endpoint = <&etr_out_port>;
};
};
};
};
...

81
Documentation/devicetree/bindings/arm/arm,coresight-cpu-debug.yaml Normal file
View File

@ -0,0 +1,81 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,coresight-cpu-debug.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: CoreSight CPU Debug Component
maintainers:
- Mathieu Poirier <mathieu.poirier@linaro.org>
- Mike Leach <mike.leach@linaro.org>
- Leo Yan <leo.yan@linaro.org>
- Suzuki K Poulose <suzuki.poulose@arm.com>
description: |
CoreSight CPU debug component are compliant with the ARMv8 architecture
reference manual (ARM DDI 0487A.k) Chapter 'Part H: External debug'. The
external debug module is mainly used for two modes: self-hosted debug and
external debug, and it can be accessed from mmio region from Coresight and
eventually the debug module connects with CPU for debugging. And the debug
module provides sample-based profiling extension, which can be used to sample
CPU program counter, secure state and exception level, etc; usually every CPU
has one dedicated debug module to be connected.
select:
properties:
compatible:
contains:
const: arm,coresight-cpu-debug
required:
- compatible
allOf:
- $ref: /schemas/arm/primecell.yaml#
properties:
compatible:
items:
- const: arm,coresight-cpu-debug
- const: arm,primecell
reg:
maxItems: 1
clocks:
maxItems: 1
clock-names:
maxItems: 1
cpu:
description:
A phandle to the cpu this debug component is bound to.
$ref: /schemas/types.yaml#/definitions/phandle
power-domains:
maxItems: 1
description:
A phandle to the debug power domain if the debug logic has its own
dedicated power domain. CPU idle states may also need to be separately
constrained to keep CPU cores powered.
required:
- compatible
- reg
- clocks
- clock-names
- cpu
unevaluatedProperties: false
examples:
- |
debug@f6590000 {
compatible = "arm,coresight-cpu-debug", "arm,primecell";
reg = <0xf6590000 0x1000>;
clocks = <&sys_ctrl 1>;
clock-names = "apb_pclk";
cpu = <&cpu0>;
};
...

331
Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml Normal file
View File

@ -0,0 +1,331 @@
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
# Copyright 2019 Linaro Ltd.
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,coresight-cti.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Coresight Cross Trigger Interface (CTI) device.
description: |
The CoreSight Embedded Cross Trigger (ECT) consists of CTI devices connected
to one or more CoreSight components and/or a CPU, with CTIs interconnected in
a star topology via the Cross Trigger Matrix (CTM), which is not programmable.
The ECT components are not part of the trace generation data path and are thus
not part of the CoreSight graph.
The CTI component properties define the connections between the individual
CTI and the components it is directly connected to, consisting of input and
output hardware trigger signals. CTIs can have a maximum number of input and
output hardware trigger signals (8 each for v1 CTI, 32 each for v2 CTI). The
number is defined at design time, the maximum of each defined in the DEVID
register.
CTIs are interconnected in a star topology via the CTM, using a number of
programmable channels, usually 4, but again implementation defined and
described in the DEVID register. The star topology is not required to be
described in the bindings as the actual connections are software
programmable.
In general the connections between CTI and components via the trigger signals
are implementation defined, except when the CTI is connected to an ARM v8
architecture core and optional ETM.
In this case the ARM v8 architecture defines the required signal connections
between CTI and the CPU core and ETM if present. In the case of a v8
architecturally connected CTI an additional compatible string is used to
indicate this feature (arm,coresight-cti-v8-arch).
When CTI trigger connection information is unavailable then a minimal driver
binding can be declared with no explicit trigger signals. This will result
the driver detecting the maximum available triggers and channels from the
DEVID register and make them all available for use as a single default
connection. Any user / client application will require additional information
on the connections between the CTI and other components for correct operation.
This information might be found by enabling the Integration Test registers in
the driver (set CONFIG_CORESIGHT_CTI_INTEGRATION_TEST in Kernel
configuration). These registers may be used to explore the trigger connections
between CTI and other CoreSight components.
Certain triggers between CoreSight devices and the CTI have specific types
and usages. These can be defined along with the signal indexes with the
constants defined in <dt-bindings/arm/coresight-cti-dt.h>
For example a CTI connected to a core will usually have a DBGREQ signal. This
is defined in the binding as type PE_EDBGREQ. These types will appear in an
optional array alongside the signal indexes. Omitting types will default all
signals to GEN_IO.
Note that some hardware trigger signals can be connected to non-CoreSight
components (e.g. UART etc) depending on hardware implementation.
maintainers:
- Mike Leach <mike.leach@linaro.org>
allOf:
- $ref: /schemas/arm/primecell.yaml#
# Need a custom select here or 'arm,primecell' will match on lots of nodes
select:
properties:
compatible:
contains:
enum:
- arm,coresight-cti
required:
- compatible
properties:
$nodename:
pattern: "^cti(@[0-9a-f]+)$"
compatible:
oneOf:
- items:
- const: arm,coresight-cti
- const: arm,primecell
- items:
- const: arm,coresight-cti-v8-arch
- const: arm,coresight-cti
- const: arm,primecell
reg:
maxItems: 1
cpu:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Handle to cpu this device is associated with. This must appear in the
base cti node if compatible string arm,coresight-cti-v8-arch is used,
or may appear in a trig-conns child node when appropriate.
arm,cti-ctm-id:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Defines the CTM this CTI is connected to, in large systems with multiple
separate CTI/CTM nets. Typically multi-socket systems where the CTM is
propagated between sockets.
arm,cs-dev-assoc:
$ref: /schemas/types.yaml#/definitions/phandle
description:
defines a phandle reference to an associated CoreSight trace device.
When the associated trace device is enabled, then the respective CTI
will be enabled. Use in a trig-conns node, or in CTI base node when
compatible string arm,coresight-cti-v8-arch used. If the associated
device has not been registered then the node name will be stored as
the connection name for later resolution. If the associated device is
not a CoreSight device or not registered then the node name will remain
the connection name and automatic enabling will not occur.
# size cells and address cells required if trig-conns node present.
"#size-cells":
const: 0
"#address-cells":
const: 1
patternProperties:
'^trig-conns@([0-9]+)$':
type: object
description:
A trigger connections child node which describes the trigger signals
between this CTI and another hardware device. This device may be a CPU,
CoreSight device, any other hardware device or simple external IO lines.
The connection may have both input and output triggers, or only one or the
other.
properties:
reg:
maxItems: 1
arm,trig-in-sigs:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of CTI trigger in signal numbers in use by a trig-conns node.
arm,trig-in-types:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of constants representing the types for the CTI trigger in
signals. Types in this array match to the corresponding signal in the
arm,trig-in-sigs array. If the -types array is smaller, or omitted
completely, then the types will default to GEN_IO.
arm,trig-out-sigs:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of CTI trigger out signal numbers in use by a trig-conns node.
arm,trig-out-types:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of constants representing the types for the CTI trigger out
signals. Types in this array match to the corresponding signal
in the arm,trig-out-sigs array. If the "-types" array is smaller,
or omitted completely, then the types will default to GEN_IO.
arm,trig-filters:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of CTI trigger out signals that will be blocked from becoming
active, unless filtering is disabled on the driver.
arm,trig-conn-name:
$ref: /schemas/types.yaml#/definitions/string
description:
Defines a connection name that will be displayed, if the cpu or
arm,cs-dev-assoc properties are not being used in this connection.
Principle use for CTI that are connected to non-CoreSight devices, or
external IO.
anyOf:
- required:
- arm,trig-in-sigs
- required:
- arm,trig-out-sigs
oneOf:
- required:
- arm,trig-conn-name
- required:
- cpu
- required:
- arm,cs-dev-assoc
required:
- reg
required:
- compatible
- reg
- clocks
- clock-names
if:
properties:
compatible:
contains:
const: arm,coresight-cti-v8-arch
then:
required:
- cpu
unevaluatedProperties: false
examples:
# minimum CTI definition. DEVID register used to set number of triggers.
- |
cti@20020000 {
compatible = "arm,coresight-cti", "arm,primecell";
reg = <0x20020000 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
};
# v8 architecturally defined CTI - CPU + ETM connections generated by the
# driver according to the v8 architecture specification.
- |
cti@859000 {
compatible = "arm,coresight-cti-v8-arch", "arm,coresight-cti",
"arm,primecell";
reg = <0x859000 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
cpu = <&CPU1>;
arm,cs-dev-assoc = <&etm1>;
};
# Implementation defined CTI - CPU + ETM connections explicitly defined..
# Shows use of type constants from dt-bindings/arm/coresight-cti-dt.h
# #size-cells and #address-cells are required if trig-conns@ nodes present.
- |
#include <dt-bindings/arm/coresight-cti-dt.h>
cti@858000 {
compatible = "arm,coresight-cti", "arm,primecell";
reg = <0x858000 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
arm,cti-ctm-id = <1>;
#address-cells = <1>;
#size-cells = <0>;
trig-conns@0 {
reg = <0>;
arm,trig-in-sigs = <4 5 6 7>;
arm,trig-in-types = <ETM_EXTOUT
ETM_EXTOUT
ETM_EXTOUT
ETM_EXTOUT>;
arm,trig-out-sigs = <4 5 6 7>;
arm,trig-out-types = <ETM_EXTIN
ETM_EXTIN
ETM_EXTIN
ETM_EXTIN>;
arm,cs-dev-assoc = <&etm0>;
};
trig-conns@1 {
reg = <1>;
cpu = <&CPU0>;
arm,trig-in-sigs = <0 1>;
arm,trig-in-types = <PE_DBGTRIGGER
PE_PMUIRQ>;
arm,trig-out-sigs=<0 1 2 >;
arm,trig-out-types = <PE_EDBGREQ
PE_DBGRESTART
PE_CTIIRQ>;
arm,trig-filters = <0>;
};
};
# Implementation defined CTI - non CoreSight component connections.
- |
cti@20110000 {
compatible = "arm,coresight-cti", "arm,primecell";
reg = <0x20110000 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
#address-cells = <1>;
#size-cells = <0>;
trig-conns@0 {
reg = <0>;
arm,trig-in-sigs=<0>;
arm,trig-in-types=<GEN_INTREQ>;
arm,trig-out-sigs=<0>;
arm,trig-out-types=<GEN_HALTREQ>;
arm,trig-conn-name = "sys_profiler";
};
trig-conns@1 {
reg = <1>;
arm,trig-out-sigs=<2 3>;
arm,trig-out-types=<GEN_HALTREQ GEN_RESTARTREQ>;
arm,trig-conn-name = "watchdog";
};
trig-conns@2 {
reg = <2>;
arm,trig-in-sigs=<1 6>;
arm,trig-in-types=<GEN_HALTREQ GEN_RESTARTREQ>;
arm,trig-conn-name = "g_counter";
};
};
...

126
Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml Normal file
View File

@ -0,0 +1,126 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,coresight-dynamic-funnel.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm CoreSight Programmable Trace Bus Funnel
maintainers:
- Mathieu Poirier <mathieu.poirier@linaro.org>
- Mike Leach <mike.leach@linaro.org>
- Leo Yan <leo.yan@linaro.org>
- Suzuki K Poulose <suzuki.poulose@arm.com>
description: |
CoreSight components are compliant with the ARM CoreSight architecture
specification and can be connected in various topologies to suit a particular
SoCs tracing needs. These trace components can generally be classified as
sinks, links and sources. Trace data produced by one or more sources flows
through the intermediate links connecting the source to the currently selected
sink.
The Coresight funnel merges 2-8 trace sources into a single trace
stream with programmable enable and priority of input ports.
# Need a custom select here or 'arm,primecell' will match on lots of nodes
select:
properties:
compatible:
contains:
const: arm,coresight-dynamic-funnel
required:
- compatible
allOf:
- $ref: /schemas/arm/primecell.yaml#
properties:
compatible:
items:
- const: arm,coresight-dynamic-funnel
- const: arm,primecell
reg:
maxItems: 1
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
items:
- const: apb_pclk
- const: atclk
in-ports:
$ref: /schemas/graph.yaml#/properties/ports
patternProperties:
'^port(@[0-7])?$':
description: Input connections from CoreSight Trace bus
$ref: /schemas/graph.yaml#/properties/port
out-ports:
$ref: /schemas/graph.yaml#/properties/ports
additionalProperties: false
properties:
port:
description: Output connection to CoreSight Trace bus
$ref: /schemas/graph.yaml#/properties/port
required:
- compatible
- reg
- clocks
- clock-names
- in-ports
- out-ports
unevaluatedProperties: false
examples:
- |
funnel@20040000 {
compatible = "arm,coresight-dynamic-funnel", "arm,primecell";
reg = <0x20040000 0x1000>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
out-ports {
port {
funnel_out_port0: endpoint {
remote-endpoint = <&replicator_in_port0>;
};
};
};
in-ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
funnel_in_port0: endpoint {
remote-endpoint = <&ptm0_out_port>;
};
};
port@1 {
reg = <1>;
funnel_in_port1: endpoint {
remote-endpoint = <&ptm1_out_port>;
};
};
port@2 {
reg = <2>;
funnel_in_port2: endpoint {
remote-endpoint = <&etm0_out_port>;
};
};
};
};
...

126
Documentation/devicetree/bindings/arm/arm,coresight-dynamic-replicator.yaml Normal file
View File

@ -0,0 +1,126 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,coresight-dynamic-replicator.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm Coresight Programmable Trace Bus Replicator
maintainers:
- Mathieu Poirier <mathieu.poirier@linaro.org>
- Mike Leach <mike.leach@linaro.org>
- Leo Yan <leo.yan@linaro.org>
- Suzuki K Poulose <suzuki.poulose@arm.com>
description: |
CoreSight components are compliant with the ARM CoreSight architecture
specification and can be connected in various topologies to suit a particular
SoCs tracing needs. These trace components can generally be classified as
sinks, links and sources. Trace data produced by one or more sources flows
through the intermediate links connecting the source to the currently selected
sink.
The Coresight replicator splits a single trace stream into two trace streams
for systems that have more than one trace sink component.
# Need a custom select here or 'arm,primecell' will match on lots of nodes
select:
properties:
compatible:
contains:
const: arm,coresight-dynamic-replicator
required:
- compatible
allOf:
- $ref: /schemas/arm/primecell.yaml#
properties:
compatible:
items:
- const: arm,coresight-dynamic-replicator
- const: arm,primecell
reg:
maxItems: 1
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
items:
- const: apb_pclk
- const: atclk
qcom,replicator-loses-context:
type: boolean
description:
Indicates that the replicator will lose register context when AMBA clock
is removed which is observed in some replicator designs.
in-ports:
$ref: /schemas/graph.yaml#/properties/ports
additionalProperties: false
properties:
port:
description: Input connection from CoreSight Trace bus
$ref: /schemas/graph.yaml#/properties/port
out-ports:
$ref: /schemas/graph.yaml#/properties/ports
patternProperties:
'^port(@[01])?$':
description: Output connections to CoreSight Trace bus
$ref: /schemas/graph.yaml#/properties/port
required:
- compatible
- reg
- clocks
- clock-names
- in-ports
- out-ports
unevaluatedProperties: false
examples:
- |
replicator@20120000 {
compatible = "arm,coresight-dynamic-replicator", "arm,primecell";
reg = <0x20120000 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
out-ports {
#address-cells = <1>;
#size-cells = <0>;
/* replicator output ports */
port@0 {
reg = <0>;
replicator_out_port0: endpoint {
remote-endpoint = <&tpiu_in_port>;
};
};
port@1 {
reg = <1>;
replicator_out_port1: endpoint {
remote-endpoint = <&etr_in_port>;
};
};
};
in-ports {
port {
replicator_in_port0: endpoint {
remote-endpoint = <&csys2_funnel_out_port>;
};
};
};
};
...

92
Documentation/devicetree/bindings/arm/arm,coresight-etb10.yaml Normal file
View File

@ -0,0 +1,92 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,coresight-etb10.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm CoreSight Embedded Trace Buffer
maintainers:
- Mathieu Poirier <mathieu.poirier@linaro.org>
- Mike Leach <mike.leach@linaro.org>
- Leo Yan <leo.yan@linaro.org>
- Suzuki K Poulose <suzuki.poulose@arm.com>
description: |
CoreSight components are compliant with the ARM CoreSight architecture
specification and can be connected in various topologies to suit a particular
SoCs tracing needs. These trace components can generally be classified as
sinks, links and sources. Trace data produced by one or more sources flows
through the intermediate links connecting the source to the currently selected
sink.
The CoreSight Embedded Trace Buffer stores traces in a dedicated SRAM that is
used as a circular buffer.
# Need a custom select here or 'arm,primecell' will match on lots of nodes
select:
properties:
compatible:
contains:
const: arm,coresight-etb10
required:
- compatible
allOf:
- $ref: /schemas/arm/primecell.yaml#
properties:
compatible:
items:
- const: arm,coresight-etb10
- const: arm,primecell
reg:
maxItems: 1
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
items:
- const: apb_pclk
- const: atclk
in-ports:
$ref: /schemas/graph.yaml#/properties/ports
additionalProperties: false
properties:
port:
description: Input connection from CoreSight Trace bus.
$ref: /schemas/graph.yaml#/properties/port
required:
- compatible
- reg
- clocks
- clock-names
- in-ports
unevaluatedProperties: false
examples:
- |
etb@20010000 {
compatible = "arm,coresight-etb10", "arm,primecell";
reg = <0x20010000 0x1000>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
in-ports {
port {
etb_in_port: endpoint {
remote-endpoint = <&replicator_out_port0>;
};
};
};
};
...

156
Documentation/devicetree/bindings/arm/arm,coresight-etm.yaml Normal file
View File

@ -0,0 +1,156 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,coresight-etm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm CoreSight Embedded Trace MacroCell
maintainers:
- Mathieu Poirier <mathieu.poirier@linaro.org>
- Mike Leach <mike.leach@linaro.org>
- Leo Yan <leo.yan@linaro.org>
- Suzuki K Poulose <suzuki.poulose@arm.com>
description: |
CoreSight components are compliant with the ARM CoreSight architecture
specification and can be connected in various topologies to suit a particular
SoCs tracing needs. These trace components can generally be classified as
sinks, links and sources. Trace data produced by one or more sources flows
through the intermediate links connecting the source to the currently selected
sink.
The Embedded Trace Macrocell (ETM) is a real-time trace module providing
instruction and data tracing of a processor.
select:
properties:
compatible:
contains:
enum:
- arm,coresight-etm3x
- arm,coresight-etm4x
- arm,coresight-etm4x-sysreg
required:
- compatible
allOf:
- if:
not:
properties:
compatible:
contains:
const: arm,coresight-etm4x-sysreg
then:
$ref: /schemas/arm/primecell.yaml#
required:
- reg
properties:
compatible:
oneOf:
- description:
Embedded Trace Macrocell with memory mapped access.
items:
- enum:
- arm,coresight-etm3x
- arm,coresight-etm4x
- const: arm,primecell
- description:
Embedded Trace Macrocell (version 4.x), with system register access only
const: arm,coresight-etm4x-sysreg
reg:
maxItems: 1
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
items:
- const: apb_pclk
- const: atclk
arm,coresight-loses-context-with-cpu:
type: boolean
description:
Indicates that the hardware will lose register context on CPU power down
(e.g. CPUIdle). An example of where this may be needed are systems which
contain a coresight component and CPU in the same power domain. When the
CPU powers down the coresight component also powers down and loses its
context.
arm,cp14:
type: boolean
description:
Must be present if the system accesses ETM/PTM management registers via
co-processor 14.
qcom,skip-power-up:
type: boolean
description:
Indicates that an implementation can skip powering up the trace unit.
TRCPDCR.PU does not have to be set on Qualcomm Technologies Inc. systems
since ETMs are in the same power domain as their CPU cores. This property
is required to identify such systems with hardware errata where the CPU
watchdog counter is stopped when TRCPDCR.PU is set.
cpu:
description:
phandle to the cpu this ETM is bound to.
$ref: /schemas/types.yaml#/definitions/phandle
out-ports:
$ref: /schemas/graph.yaml#/properties/ports
additionalProperties: false
properties:
port:
description: Output connection from the ETM to CoreSight Trace bus.
$ref: /schemas/graph.yaml#/properties/port
required:
- compatible
- clocks
- clock-names
- cpu
- out-ports
unevaluatedProperties: false
examples:
- |
ptm@2201c000 {
compatible = "arm,coresight-etm3x", "arm,primecell";
reg = <0x2201c000 0x1000>;
cpu = <&cpu0>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
out-ports {
port {
ptm0_out_port: endpoint {
remote-endpoint = <&funnel_in_port0>;
};
};
};
};
ptm@2201d000 {
compatible = "arm,coresight-etm3x", "arm,primecell";
reg = <0x2201d000 0x1000>;
cpu = <&cpu1>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
out-ports {
port {
ptm1_out_port: endpoint {
remote-endpoint = <&funnel_in_port1>;
};
};
};
};
...

90
Documentation/devicetree/bindings/arm/arm,coresight-static-funnel.yaml Normal file
View File

@ -0,0 +1,90 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,coresight-static-funnel.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm CoreSight Static Trace Bus Funnel
maintainers:
- Mathieu Poirier <mathieu.poirier@linaro.org>
- Mike Leach <mike.leach@linaro.org>
- Leo Yan <leo.yan@linaro.org>
- Suzuki K Poulose <suzuki.poulose@arm.com>
description: |
CoreSight components are compliant with the ARM CoreSight architecture
specification and can be connected in various topologies to suit a particular
SoCs tracing needs. These trace components can generally be classified as
sinks, links and sources. Trace data produced by one or more sources flows
through the intermediate links connecting the source to the currently selected
sink.
The Coresight static funnel merges 2-8 trace sources into a single trace
stream.
properties:
compatible:
const: arm,coresight-static-funnel
in-ports:
$ref: /schemas/graph.yaml#/properties/ports
patternProperties:
'^port@[0-7]$':
description: Input connections from CoreSight Trace bus
$ref: /schemas/graph.yaml#/properties/port
out-ports:
$ref: /schemas/graph.yaml#/properties/ports
additionalProperties: false
properties:
port:
description: Output connection to CoreSight Trace bus
$ref: /schemas/graph.yaml#/properties/port
required:
- compatible
- in-ports
- out-ports
additionalProperties: false
examples:
- |
funnel {
/*
* non-configurable replicators don't show up on the
* AMBA bus. As such no need to add "arm,primecell".
*/
compatible = "arm,coresight-static-funnel";
out-ports {
port {
combo_funnel_out: endpoint {
remote-endpoint = <&top_funnel_in>;
};
};
};
in-ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
combo_funnel_in0: endpoint {
remote-endpoint = <&cluster0_etf_out>;
};
};
port@1 {
reg = <1>;
combo_funnel_in1: endpoint {
remote-endpoint = <&cluster1_etf_out>;
};
};
};
};
...

91
Documentation/devicetree/bindings/arm/arm,coresight-static-replicator.yaml Normal file
View File

@ -0,0 +1,91 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,coresight-static-replicator.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm CoreSight Static Trace Bus Replicator
maintainers:
- Mathieu Poirier <mathieu.poirier@linaro.org>
- Mike Leach <mike.leach@linaro.org>
- Leo Yan <leo.yan@linaro.org>
- Suzuki K Poulose <suzuki.poulose@arm.com>
description: |
CoreSight components are compliant with the ARM CoreSight architecture
specification and can be connected in various topologies to suit a particular
SoCs tracing needs. These trace components can generally be classified as
sinks, links and sources. Trace data produced by one or more sources flows
through the intermediate links connecting the source to the currently selected
sink.
The Coresight replicator splits a single trace stream into two trace streams
for systems that have more than one trace sink component.
properties:
compatible:
const: arm,coresight-static-replicator
in-ports:
$ref: /schemas/graph.yaml#/properties/ports
additionalProperties: false
properties:
port:
description: Input connection from CoreSight Trace bus
$ref: /schemas/graph.yaml#/properties/port
out-ports:
$ref: /schemas/graph.yaml#/properties/ports
patternProperties:
'^port@[01]$':
description: Output connections to CoreSight Trace bus
$ref: /schemas/graph.yaml#/properties/port
required:
- compatible
- in-ports
- out-ports
additionalProperties: false
examples:
- |
replicator {
/*
* non-configurable replicators don't show up on the
* AMBA bus. As such no need to add "arm,primecell".
*/
compatible = "arm,coresight-static-replicator";
out-ports {
#address-cells = <1>;
#size-cells = <0>;
/* replicator output ports */
port@0 {
reg = <0>;
replicator_out_port0: endpoint {
remote-endpoint = <&etb_in_port>;
};
};
port@1 {
reg = <1>;
replicator_out_port1: endpoint {
remote-endpoint = <&tpiu_in_port>;
};
};
};
in-ports {
port {
replicator_in_port0: endpoint {
remote-endpoint = <&funnel_out_port0>;
};
};
};
};
...

101
Documentation/devicetree/bindings/arm/arm,coresight-stm.yaml Normal file
View File

@ -0,0 +1,101 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,coresight-stm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm CoreSight System Trace MacroCell
maintainers:
- Mathieu Poirier <mathieu.poirier@linaro.org>
- Mike Leach <mike.leach@linaro.org>
- Leo Yan <leo.yan@linaro.org>
- Suzuki K Poulose <suzuki.poulose@arm.com>
description: |
CoreSight components are compliant with the ARM CoreSight architecture
specification and can be connected in various topologies to suit a particular
SoCs tracing needs. These trace components can generally be classified as
sinks, links and sources. Trace data produced by one or more sources flows
through the intermediate links connecting the source to the currently selected
sink.
The STM is a trace source that is integrated into a CoreSight system, designed
primarily for high-bandwidth trace of instrumentation embedded into software.
This instrumentation is made up of memory-mapped writes to the STM Advanced
eXtensible Interface (AXI) slave, which carry information about the behavior
of the software.
select:
properties:
compatible:
contains:
const: arm,coresight-stm
required:
- compatible
allOf:
- $ref: /schemas/arm/primecell.yaml#
properties:
compatible:
items:
- const: arm,coresight-stm
- const: arm,primecell
reg:
maxItems: 2
reg-names:
items:
- const: stm-base
- const: stm-stimulus-base
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
items:
- const: apb_pclk
- const: atclk
out-ports:
$ref: /schemas/graph.yaml#/properties/ports
additionalProperties: false
properties:
port:
description: Output connection to the CoreSight Trace bus.
$ref: /schemas/graph.yaml#/properties/port
required:
- compatible
- reg
- reg-names
- clocks
- clock-names
- out-ports
unevaluatedProperties: false
examples:
- |
stm@20100000 {
compatible = "arm,coresight-stm", "arm,primecell";
reg = <0x20100000 0x1000>,
<0x28000000 0x180000>;
reg-names = "stm-base", "stm-stimulus-base";
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
out-ports {
port {
stm_out_port: endpoint {
remote-endpoint = <&main_funnel_in_port2>;
};
};
};
};
...

131
Documentation/devicetree/bindings/arm/arm,coresight-tmc.yaml Normal file
View File

@ -0,0 +1,131 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,coresight-tmc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm CoreSight Trace Memory Controller
maintainers:
- Mathieu Poirier <mathieu.poirier@linaro.org>
- Mike Leach <mike.leach@linaro.org>
- Leo Yan <leo.yan@linaro.org>
- Suzuki K Poulose <suzuki.poulose@arm.com>
description: |
CoreSight components are compliant with the ARM CoreSight architecture
specification and can be connected in various topologies to suit a particular
SoCs tracing needs. These trace components can generally be classified as
sinks, links and sources. Trace data produced by one or more sources flows
through the intermediate links connecting the source to the currently selected
sink.
Trace Memory Controller is used for Embedded Trace Buffer(ETB), Embedded Trace
FIFO(ETF) and Embedded Trace Router(ETR) configurations. The configuration
mode (ETB, ETF, ETR) is discovered at boot time when the device is probed.
# Need a custom select here or 'arm,primecell' will match on lots of nodes
select:
properties:
compatible:
contains:
const: arm,coresight-tmc
required:
- compatible
allOf:
- $ref: /schemas/arm/primecell.yaml#
properties:
compatible:
items:
- const: arm,coresight-tmc
- const: arm,primecell
reg:
maxItems: 1
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
items:
- const: apb_pclk
- const: atclk
arm,buffer-size:
$ref: /schemas/types.yaml#/definitions/uint32
deprecated: true
description:
Size of contiguous buffer space for TMC ETR (embedded trace router). The
buffer size can be configured dynamically via buffer_size property in
sysfs instead.
arm,scatter-gather:
type: boolean
description:
Indicates that the TMC-ETR can safely use the SG mode on this system.
arm,max-burst-size:
description:
The maximum burst size initiated by TMC on the AXI master interface. The
burst size can be in the range [0..15], the setting supports one data
transfer per burst up to a maximum of 16 data transfers per burst.
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 15
in-ports:
$ref: /schemas/graph.yaml#/properties/ports
additionalProperties: false
properties:
port:
description: Input connection from the CoreSight Trace bus.
$ref: /schemas/graph.yaml#/properties/port
out-ports:
$ref: /schemas/graph.yaml#/properties/ports
additionalProperties: false
properties:
port:
description: AXI or ATB Master output connection. Used for ETR
and ETF configurations.
$ref: /schemas/graph.yaml#/properties/port
required:
- compatible
- reg
- clocks
- clock-names
- in-ports
unevaluatedProperties: false
examples:
- |
etr@20070000 {
compatible = "arm,coresight-tmc", "arm,primecell";
reg = <0x20070000 0x1000>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
in-ports {
port {
etr_in_port: endpoint {
remote-endpoint = <&replicator2_out_port0>;
};
};
};
out-ports {
port {
etr_out_port: endpoint {
remote-endpoint = <&catu_in_port>;
};
};
};
};
...

91
Documentation/devicetree/bindings/arm/arm,coresight-tpiu.yaml Normal file
View File

@ -0,0 +1,91 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,coresight-tpiu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm CoreSight Trace Port Interface Unit
maintainers:
- Mathieu Poirier <mathieu.poirier@linaro.org>
- Mike Leach <mike.leach@linaro.org>
- Leo Yan <leo.yan@linaro.org>
- Suzuki K Poulose <suzuki.poulose@arm.com>
description: |
CoreSight components are compliant with the ARM CoreSight architecture
specification and can be connected in various topologies to suit a particular
SoCs tracing needs. These trace components can generally be classified as
sinks, links and sources. Trace data produced by one or more sources flows
through the intermediate links connecting the source to the currently selected
sink.
The CoreSight Trace Port Interface Unit captures trace data from the trace bus
and outputs it to an external trace port.
# Need a custom select here or 'arm,primecell' will match on lots of nodes
select:
properties:
compatible:
contains:
const: arm,coresight-tpiu
required:
- compatible
allOf:
- $ref: /schemas/arm/primecell.yaml#
properties:
compatible:
items:
- const: arm,coresight-tpiu
- const: arm,primecell
reg:
maxItems: 1
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
items:
- const: apb_pclk
- const: atclk
in-ports:
$ref: /schemas/graph.yaml#/properties/ports
additionalProperties: false
properties:
port:
description: Input connection from the CoreSight Trace bus.
$ref: /schemas/graph.yaml#/properties/port
required:
- compatible
- reg
- clocks
- clock-names
- in-ports
unevaluatedProperties: false
examples:
- |
tpiu@e3c05000 {
compatible = "arm,coresight-tpiu", "arm,primecell";
reg = <0xe3c05000 0x1000>;
clocks = <&clk_375m>;
clock-names = "apb_pclk";
in-ports {
port {
tpiu_in_port: endpoint {
remote-endpoint = <&funnel4_out_port0>;
};
};
};
};
...

45
Documentation/devicetree/bindings/arm/arm,corstone1000.yaml Normal file
View File

@ -0,0 +1,45 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,corstone1000.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Corstone1000 Device Tree Bindings
maintainers:
- Vishnu Banavath <vishnu.banavath@arm.com>
- Rui Miguel Silva <rui.silva@linaro.org>
description: |+
ARM's Corstone1000 includes pre-verified Corstone SSE-710 subsystem that
provides a flexible compute architecture that combines Cortex‑A and Cortex‑M
processors.
Support for Cortex‑A32, Cortex‑A35 and Cortex‑A53 processors. Two expansion
systems for M-Class (or other) processors for adding sensors, connectivity,
video, audio and machine learning at the edge System and security IPs to build
a secure SoC for a range of rich IoT applications, for example gateways, smart
cameras and embedded systems.
Integrated Secure Enclave providing hardware Root of Trust and supporting
seamless integration of the optional CryptoCell™-312 cryptographic
accelerator.
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: Corstone1000 MPS3 it has 1 Cortex-A35 CPU core in a FPGA
implementation of the Corstone1000 in the MPS3 prototyping board. See
ARM document DAI0550.
items:
- const: arm,corstone1000-mps3
- description: Corstone1000 FVP is the Fixed Virtual Platform
implementation of this system. See ARM ecosystems FVP's.
items:
- const: arm,corstone1000-fvp
additionalProperties: true
...

74
Documentation/devicetree/bindings/arm/arm,embedded-trace-extension.yaml Normal file
View File

@ -0,0 +1,74 @@
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
# Copyright 2021, Arm Ltd
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/arm,embedded-trace-extension.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: ARM Embedded Trace Extensions
maintainers:
- Suzuki K Poulose <suzuki.poulose@arm.com>
- Mathieu Poirier <mathieu.poirier@linaro.org>
description: |
Arm Embedded Trace Extension(ETE) is a per CPU trace component that
allows tracing the CPU execution. It overlaps with the CoreSight ETMv4
architecture and has extended support for future architecture changes.
The trace generated by the ETE could be stored via legacy CoreSight
components (e.g, TMC-ETR) or other means (e.g, using a per CPU buffer
Arm Trace Buffer Extension (TRBE)). Since the ETE can be connected to
legacy CoreSight components, a node must be listed per instance, along
with any optional connection graph as per the coresight bindings.
properties:
$nodename:
pattern: "^ete([0-9a-f]+)$"
compatible:
items:
- const: arm,embedded-trace-extension
cpu:
description: |
Handle to the cpu this ETE is bound to.
$ref: /schemas/types.yaml#/definitions/phandle
out-ports:
description: |
Output connections from the ETE to legacy CoreSight trace bus.
$ref: /schemas/graph.yaml#/properties/ports
properties:
port:
description: Output connection from the ETE to legacy CoreSight Trace bus.
$ref: /schemas/graph.yaml#/properties/port
required:
- compatible
- cpu
additionalProperties: false
examples:
# An ETE node without legacy CoreSight connections
- |
ete0 {
compatible = "arm,embedded-trace-extension";
cpu = <&cpu_0>;
};
# An ETE node with legacy CoreSight connections
- |
ete1 {
compatible = "arm,embedded-trace-extension";
cpu = <&cpu_1>;
out-ports { /* legacy coresight connection */
port {
ete1_out_port: endpoint {
remote-endpoint = <&funnel_in_port0>;
};
};
};
};
...

49
Documentation/devicetree/bindings/arm/arm,trace-buffer-extension.yaml Normal file
View File

@ -0,0 +1,49 @@
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
# Copyright 2021, Arm Ltd
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/arm,trace-buffer-extension.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: ARM Trace Buffer Extensions
maintainers:
- Anshuman Khandual <anshuman.khandual@arm.com>
description: |
Arm Trace Buffer Extension (TRBE) is a per CPU component
for storing trace generated on the CPU to memory. It is
accessed via CPU system registers. The software can verify
if it is permitted to use the component by checking the
TRBIDR register.
properties:
$nodename:
const: "trbe"
compatible:
items:
- const: arm,trace-buffer-extension
interrupts:
description: |
Exactly 1 PPI must be listed. For heterogeneous systems where
TRBE is only supported on a subset of the CPUs, please consult
the arm,gic-v3 binding for details on describing a PPI partition.
maxItems: 1
required:
- compatible
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
trbe {
compatible = "arm,trace-buffer-extension";
interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>;
};
...

87
Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml Normal file
View File

@ -0,0 +1,87 @@
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/aspeed/aspeed.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Aspeed SoC based boards
maintainers:
- Joel Stanley <joel@jms.id.au>
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: AST2400 based boards
items:
- enum:
- facebook,galaxy100-bmc
- facebook,wedge100-bmc
- facebook,wedge40-bmc
- microsoft,olympus-bmc
- quanta,q71l-bmc
- tyan,palmetto-bmc
- yadro,vesnin-bmc
- const: aspeed,ast2400
- description: AST2500 based boards
items:
- enum:
- amd,ethanolx-bmc
- ampere,mtjade-bmc
- aspeed,ast2500-evb
- asrock,e3c246d4i-bmc
- asrock,romed8hm3-bmc
- bytedance,g220a-bmc
- facebook,cmm-bmc
- facebook,minipack-bmc
- facebook,tiogapass-bmc
- facebook,yamp-bmc
- facebook,yosemitev2-bmc
- facebook,wedge400-bmc
- hxt,stardragon4800-rep2-bmc
- ibm,mihawk-bmc
- ibm,mowgli-bmc
- ibm,romulus-bmc
- ibm,swift-bmc
- ibm,witherspoon-bmc
- ingrasys,zaius-bmc
- inspur,fp5280g2-bmc
- inspur,nf5280m6-bmc
- inspur,on5263m5-bmc
- intel,s2600wf-bmc
- inventec,lanyang-bmc
- lenovo,hr630-bmc
- lenovo,hr855xg2-bmc
- portwell,neptune-bmc
- qcom,centriq2400-rep-bmc
- supermicro,x11spi-bmc
- tyan,s7106-bmc
- tyan,s8036-bmc
- yadro,nicole-bmc
- yadro,vegman-n110-bmc
- yadro,vegman-rx20-bmc
- yadro,vegman-sx20-bmc
- const: aspeed,ast2500
- description: AST2600 based boards
items:
- enum:
- aspeed,ast2600-evb
- aspeed,ast2600-evb-a1
- facebook,bletchley-bmc
- facebook,cloudripper-bmc
- facebook,elbert-bmc
- facebook,fuji-bmc
- ibm,everest-bmc
- ibm,rainier-bmc
- ibm,tacoma-bmc
- inventec,transformer-bmc
- jabil,rbp-bmc
- nuvia,dc-scm-bmc
- quanta,s6q-bmc
- const: aspeed,ast2600
additionalProperties: true

126
Documentation/devicetree/bindings/arm/bcm/brcm,bcmbca.yaml Normal file
View File

@ -0,0 +1,126 @@
# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,bcmbca.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom Broadband SoC device tree bindings
description:
Broadcom Broadband SoCs include family of high performance DSL/PON/Wireless
chips that can be used as home gateway, router and WLAN AP for residential,
enterprise and carrier applications.
maintainers:
- William Zhang <william.zhang@broadcom.com>
- Anand Gore <anand.gore@broadcom.com>
- Kursad Oney <kursad.oney@broadcom.com>
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: BCM47622 based boards
items:
- enum:
- brcm,bcm947622
- const: brcm,bcm47622
- const: brcm,bcmbca
- description: BCM4912 based boards
items:
- enum:
- asus,gt-ax6000
- brcm,bcm94912
- const: brcm,bcm4912
- const: brcm,bcmbca
- description: BCM63138 based boards
items:
- enum:
- brcm,bcm963138
- brcm,BCM963138DVT
- const: brcm,bcm63138
- const: brcm,bcmbca
- description: BCM63146 based boards
items:
- enum:
- brcm,bcm963146
- const: brcm,bcm63146
- const: brcm,bcmbca
- description: BCM63148 based boards
items:
- enum:
- brcm,bcm963148
- const: brcm,bcm63148
- const: brcm,bcmbca
- description: BCM63158 based boards
items:
- enum:
- brcm,bcm963158
- const: brcm,bcm63158
- const: brcm,bcmbca
- description: BCM63178 based boards
items:
- enum:
- brcm,bcm963178
- const: brcm,bcm63178
- const: brcm,bcmbca
- description: BCM6756 based boards
items:
- enum:
- brcm,bcm96756
- const: brcm,bcm6756
- const: brcm,bcmbca
- description: BCM6813 based boards
items:
- enum:
- brcm,bcm96813
- const: brcm,bcm6813
- const: brcm,bcmbca
- description: BCM6846 based boards
items:
- enum:
- brcm,bcm96846
- const: brcm,bcm6846
- const: brcm,bcmbca
- description: BCM6855 based boards
items:
- enum:
- brcm,bcm96855
- const: brcm,bcm6855
- const: brcm,bcmbca
- description: BCM6856 based boards
items:
- enum:
- brcm,bcm96856
- const: brcm,bcm6856
- const: brcm,bcmbca
- description: BCM6858 based boards
items:
- enum:
- brcm,bcm96858
- const: brcm,bcm6858
- const: brcm,bcmbca
- description: BCM6878 based boards
items:
- enum:
- brcm,bcm96878
- const: brcm,bcm6878
- const: brcm,bcmbca
additionalProperties: true
...

27
Documentation/devicetree/bindings/arm/hpe,gxp.yaml Normal file
View File

@ -0,0 +1,27 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/hpe,gxp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: HPE BMC GXP platforms
maintainers:
- Nick Hawkins <nick.hawkins@hpe.com>
- Jean-Marie Verdun <verdun@hpe.com>
properties:
compatible:
oneOf:
- description: GXP Based Boards
items:
- enum:
- hpe,gxp-dl360gen10
- const: hpe,gxp
required:
- compatible
additionalProperties: true
...

32
Documentation/devicetree/bindings/arm/marvell/marvell,ac5.yaml Normal file
View File

@ -0,0 +1,32 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/marvell/marvell,ac5.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Marvell Alleycat5/5X Platforms
maintainers:
- Chris Packham <chris.packham@alliedtelesis.co.nz>
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: Alleycat5 (98DX25xx) Reference Design
items:
- enum:
- marvell,rd-ac5
- const: marvell,ac5
- description: Alleycat5X (98DX35xx) Reference Design
items:
- enum:
- marvell,rd-ac5x
- const: marvell,ac5x
- const: marvell,ac5
additionalProperties: true
...

81
Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml Normal file
View File

@ -0,0 +1,81 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,infracfg.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: MediaTek Infrastructure System Configuration Controller
maintainers:
- Matthias Brugger <matthias.bgg@gmail.com>
description:
The Mediatek infracfg controller provides various clocks and reset outputs
to the system. The clock values can be found in <dt-bindings/clock/mt*-clk.h>,
and reset values in <dt-bindings/reset/mt*-reset.h> and
<dt-bindings/reset/mt*-resets.h>.
properties:
compatible:
oneOf:
- items:
- enum:
- mediatek,mt2701-infracfg
- mediatek,mt2712-infracfg
- mediatek,mt6765-infracfg
- mediatek,mt6779-infracfg_ao
- mediatek,mt6797-infracfg
- mediatek,mt7622-infracfg
- mediatek,mt7629-infracfg
- mediatek,mt7986-infracfg
- mediatek,mt8135-infracfg
- mediatek,mt8167-infracfg
- mediatek,mt8173-infracfg
- mediatek,mt8183-infracfg
- mediatek,mt8516-infracfg
- const: syscon
- items:
- const: mediatek,mt7623-infracfg
- const: mediatek,mt2701-infracfg
- const: syscon
reg:
maxItems: 1
'#clock-cells':
const: 1
'#reset-cells':
const: 1
required:
- compatible
- reg
- '#clock-cells'
if:
properties:
compatible:
contains:
enum:
- mediatek,mt2701-infracfg
- mediatek,mt2712-infracfg
- mediatek,mt7622-infracfg
- mediatek,mt7986-infracfg
- mediatek,mt8135-infracfg
- mediatek,mt8173-infracfg
- mediatek,mt8183-infracfg
then:
required:
- '#reset-cells'
additionalProperties: false
examples:
- |
infracfg: clock-controller@10001000 {
compatible = "mediatek,mt8173-infracfg", "syscon";
reg = <0x10001000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};

42
Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml Normal file
View File

@ -0,0 +1,42 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: MediaTek PCIE Mirror Controller for MT7622
maintainers:
- Lorenzo Bianconi <lorenzo@kernel.org>
- Felix Fietkau <nbd@nbd.name>
description:
The mediatek PCIE mirror provides a configuration interface for PCIE
controller on MT7622 soc.
properties:
compatible:
items:
- enum:
- mediatek,mt7622-pcie-mirror
- const: syscon
reg:
maxItems: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
soc {
#address-cells = <2>;
#size-cells = <2>;
pcie_mirror: pcie-mirror@10000400 {
compatible = "mediatek,mt7622-pcie-mirror", "syscon";
reg = <0 0x10000400 0 0x10>;
};
};

50
Documentation/devicetree/bindings/arm/mediatek/mediatek,mt7622-wed.yaml Normal file
View File

@ -0,0 +1,50 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-wed.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: MediaTek Wireless Ethernet Dispatch Controller for MT7622
maintainers:
- Lorenzo Bianconi <lorenzo@kernel.org>
- Felix Fietkau <nbd@nbd.name>
description:
The mediatek wireless ethernet dispatch controller can be configured to
intercept and handle access to the WLAN DMA queues and PCIe interrupts
and implement hardware flow offloading from ethernet to WLAN.
properties:
compatible:
items:
- enum:
- mediatek,mt7622-wed
- const: syscon
reg:
maxItems: 1
interrupts:
maxItems: 1
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
soc {
#address-cells = <2>;
#size-cells = <2>;
wed0: wed@1020a000 {
compatible = "mediatek,mt7622-wed","syscon";
reg = <0 0x1020a000 0 0x1000>;
interrupts = <GIC_SPI 214 IRQ_TYPE_LEVEL_LOW>;
};
};

56
Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-clock.yaml Normal file
View File

@ -0,0 +1,56 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-clock.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: MediaTek Functional Clock Controller for MT8186
maintainers:
- Chun-Jie Chen <chun-jie.chen@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:
items:
- enum:
- mediatek,mt8186-imp_iic_wrap
- mediatek,mt8186-mfgsys
- mediatek,mt8186-wpesys
- mediatek,mt8186-imgsys1
- mediatek,mt8186-imgsys2
- mediatek,mt8186-vdecsys
- mediatek,mt8186-vencsys
- mediatek,mt8186-camsys
- mediatek,mt8186-camsys_rawa
- mediatek,mt8186-camsys_rawb
- mediatek,mt8186-mdpsys
- mediatek,mt8186-ipesys
reg:
maxItems: 1
'#clock-cells':
const: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
imp_iic_wrap: clock-controller@11017000 {
compatible = "mediatek,mt8186-imp_iic_wrap";
reg = <0x11017000 0x1000>;
#clock-cells = <1>;
};

57
Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml Normal file
View File

@ -0,0 +1,57 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-sys-clock.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: MediaTek System Clock Controller for MT8186
maintainers:
- Chun-Jie Chen <chun-jie.chen@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,mt8186-mcusys
- mediatek,mt8186-topckgen
- mediatek,mt8186-infracfg_ao
- mediatek,mt8186-apmixedsys
- const: syscon
reg:
maxItems: 1
'#clock-cells':
const: 1
'#reset-cells':
const: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
topckgen: syscon@10000000 {
compatible = "mediatek,mt8186-topckgen", "syscon";
reg = <0x10000000 0x1000>;
#clock-cells = <1>;
};

40
Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml Normal file
View File

@ -0,0 +1,40 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/samsung/samsung-soc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung S3C, S5P and Exynos SoC compatibles naming convention
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
description: |
Guidelines for new compatibles for SoC blocks/components.
When adding new compatibles in new bindings, use the format::
samsung,SoC-IP
For example::
samsung,exynos5433-cmu-isp
select:
properties:
compatible:
pattern: "^samsung,.*(s3c|s5pv|exynos)[0-9a-z]+.*$"
required:
- compatible
properties:
compatible:
oneOf:
- description: Preferred naming style for compatibles of SoC components
pattern: "^samsung,(s3c|s5pv|exynos|exynosautov)[0-9]+-.*$"
# Legacy compatibles with wild-cards - list cannot grow with new bindings:
- enum:
- samsung,exynos4x12-pinctrl
- samsung,exynos4x12-usb2-phy
- samsung,s3c64xx-pinctrl
- samsung,s3c64xx-wakeup-eint
additionalProperties: true

80
Documentation/devicetree/bindings/arm/sp810.yaml Normal file
View File

@ -0,0 +1,80 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/sp810.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Versatile Express SP810 System Controller bindings
maintainers:
- Andre Przywara <andre.przywara@arm.com>
description:
The Arm SP810 system controller provides clocks, timers and a watchdog.
# We need a select here so we don't match all nodes with 'arm,primecell'
select:
properties:
compatible:
contains:
const: arm,sp810
required:
- compatible
properties:
compatible:
items:
- const: arm,sp810
- const: arm,primecell
reg:
maxItems: 1
clock-names:
items:
- const: refclk
- const: timclk
- const: apb_pclk
clocks:
items:
- description: reference clock
- description: timer clock
- description: APB register access clock
"#clock-cells":
const: 1
clock-output-names:
maxItems: 4
assigned-clocks:
maxItems: 4
assigned-clock-parents:
maxItems: 4
additionalProperties: false
required:
- compatible
- reg
- clocks
- clock-names
- "#clock-cells"
examples:
- |
sysctl@20000 {
compatible = "arm,sp810", "arm,primecell";
reg = <0x020000 0x1000>;
clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&smbclk>;
clock-names = "refclk", "timclk", "apb_pclk";
#clock-cells = <1>;
clock-output-names = "timerclken0", "timerclken1",
"timerclken2", "timerclken3";
assigned-clocks = <&v2m_sysctl 0>, <&v2m_sysctl 1>,
<&v2m_sysctl 3>, <&v2m_sysctl 3>;
assigned-clock-parents = <&v2m_refclk1mhz>, <&v2m_refclk1mhz>,
<&v2m_refclk1mhz>, <&v2m_refclk1mhz>;
};

29
Documentation/devicetree/bindings/arm/sunplus,sp7021.yaml Normal file
View File

@ -0,0 +1,29 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) Sunplus Co., Ltd. 2021
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/sunplus,sp7021.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sunplus SP7021 Boards
maintainers:
- qinjian <qinjian@cqplus1.com>
description: |
ARM platforms using Sunplus SP7021, an ARM Cortex A7 (4-cores) based SoC.
Wiki: https://sunplus-tibbo.atlassian.net/wiki/spaces/doc/overview
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- sunplus,sp7021-achip
- sunplus,sp7021-demo-v3
- const: sunplus,sp7021
additionalProperties: true
...

51
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml Normal file
View File

@ -0,0 +1,51 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra-ccplex-cluster.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: NVIDIA Tegra CPU COMPLEX CLUSTER area device tree bindings
maintainers:
- Sumit Gupta <sumitg@nvidia.com>
- Mikko Perttunen <mperttunen@nvidia.com>
- Jon Hunter <jonathanh@nvidia.com>
- Thierry Reding <thierry.reding@gmail.com>
description: |+
The Tegra CPU COMPLEX CLUSTER area contains memory-mapped
registers that initiate CPU frequency/voltage transitions.
properties:
$nodename:
pattern: "ccplex@([0-9a-f]+)$"
compatible:
enum:
- nvidia,tegra186-ccplex-cluster
- nvidia,tegra234-ccplex-cluster
reg:
maxItems: 1
nvidia,bpmp:
$ref: '/schemas/types.yaml#/definitions/phandle'
description: |
Specifies the BPMP node that needs to be queried to get
operating point data for all CPUs.
additionalProperties: false
required:
- compatible
- reg
- nvidia,bpmp
examples:
- |
ccplex@e000000 {
compatible = "nvidia,tegra234-ccplex-cluster";
reg = <0x0e000000 0x5ffff>;
nvidia,bpmp = <&bpmp>;
status = "okay";
};

40
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml Normal file
View File

@ -0,0 +1,40 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-axi2apb.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: NVIDIA Tegra194 AXI2APB bridge
maintainers:
- Sumit Gupta <sumitg@nvidia.com>
properties:
$nodename:
pattern: "^axi2apb@([0-9a-f]+)$"
compatible:
enum:
- nvidia,tegra194-axi2apb
reg:
maxItems: 6
description: Physical base address and length of registers for all bridges
additionalProperties: false
required:
- compatible
- reg
examples:
- |
axi2apb: axi2apb@2390000 {
compatible = "nvidia,tegra194-axi2apb";
reg = <0x02390000 0x1000>,
<0x023a0000 0x1000>,
<0x023b0000 0x1000>,
<0x023c0000 0x1000>,
<0x023d0000 0x1000>,
<0x023e0000 0x1000>;
};

97
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml Normal file
View File

@ -0,0 +1,97 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-cbb.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: NVIDIA Tegra194 CBB 1.0 bindings
maintainers:
- Sumit Gupta <sumitg@nvidia.com>
description: |+
The Control Backbone (CBB) is comprised of the physical path from an
initiator to a target's register configuration space. CBB 1.0 has
multiple hierarchical sub-NOCs (Network-on-Chip) and connects various
initiators and targets using different bridges like AXIP2P, AXI2APB.
This driver handles errors due to illegal register accesses reported
by the NOCs inside the CBB. NOCs reporting errors are cluster NOCs
"AON-NOC, SCE-NOC, RCE-NOC, BPMP-NOC, CV-NOC" and "CBB Central NOC"
which is the main NOC.
By default, the access issuing initiator is informed about the error
using SError or Data Abort exception unless the ERD (Error Response
Disable) is enabled/set for that initiator. If the ERD is enabled, then
SError or Data Abort is masked and the error is reported with interrupt.
- For CCPLEX (CPU Complex) initiator, the driver sets ERD bit. So, the
errors due to illegal accesses from CCPLEX are reported by interrupts.
If ERD is not set, then error is reported by SError.
- For other initiators, the ERD is disabled. So, the access issuing
initiator is informed about the illegal access by Data Abort exception.
In addition, an interrupt is also generated to CCPLEX. These initiators
include all engines using Cortex-R5 (which is ARMv7 CPU cluster) and
engines like TSEC (Security co-processor), NVDEC (NVIDIA Video Decoder
engine) etc which can initiate transactions.
The driver prints relevant debug information like Error Code, Error
Description, Master, Address, AXI ID, Cache, Protection, Security Group
etc on receiving error notification.
properties:
$nodename:
pattern: "^[a-z]+-noc@[0-9a-f]+$"
compatible:
enum:
- nvidia,tegra194-cbb-noc
- nvidia,tegra194-aon-noc
- nvidia,tegra194-bpmp-noc
- nvidia,tegra194-rce-noc
- nvidia,tegra194-sce-noc
reg:
maxItems: 1
interrupts:
description:
CCPLEX receives secure or nonsecure interrupt depending on error type.
A secure interrupt is received for SEC(firewall) & SLV errors and a
non-secure interrupt is received for TMO & DEC errors.
items:
- description: non-secure interrupt
- description: secure interrupt
nvidia,axi2apb:
$ref: '/schemas/types.yaml#/definitions/phandle'
description:
Specifies the node having all axi2apb bridges which need to be checked
for any error logged in their status register.
nvidia,apbmisc:
$ref: '/schemas/types.yaml#/definitions/phandle'
description:
Specifies the apbmisc node which need to be used for reading the ERD
register.
additionalProperties: false
required:
- compatible
- reg
- interrupts
- nvidia,apbmisc
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
cbb-noc@2300000 {
compatible = "nvidia,tegra194-cbb-noc";
reg = <0x02300000 0x1000>;
interrupts = <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>;
nvidia,axi2apb = <&axi2apb>;
nvidia,apbmisc = <&apbmisc>;
};

74
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml Normal file
View File

@ -0,0 +1,74 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra234-cbb.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: NVIDIA Tegra CBB 2.0 bindings
maintainers:
- Sumit Gupta <sumitg@nvidia.com>
description: |+
The Control Backbone (CBB) is comprised of the physical path from an
initiator to a target's register configuration space. CBB 2.0 consists
of multiple sub-blocks connected to each other to create a topology.
The Tegra234 SoC has different fabrics based on CBB 2.0 architecture
which include cluster fabrics BPMP, AON, PSC, SCE, RCE, DCE, FSI and
"CBB central fabric".
In CBB 2.0, each initiator which can issue transactions connects to a
Root Master Node (MN) before it connects to any other element of the
fabric. Each Root MN contains a Error Monitor (EM) which detects and
logs error. Interrupts from various EM blocks are collated by Error
Notifier (EN) which is per fabric and presents a single interrupt from
fabric to the SoC interrupt controller.
The driver handles errors from CBB due to illegal register accesses
and prints debug information about failed transaction on receiving
the interrupt from EN. Debug information includes Error Code, Error
Description, MasterID, Fabric, SlaveID, Address, Cache, Protection,
Security Group etc on receiving error notification.
If the Error Response Disable (ERD) is set/enabled for an initiator,
then SError or Data abort exception error response is masked and an
interrupt is used for reporting errors due to illegal accesses from
that initiator. The value returned on read failures is '0xFFFFFFFF'
for compatibility with PCIE.
properties:
$nodename:
pattern: "^[a-z]+-fabric@[0-9a-f]+$"
compatible:
enum:
- nvidia,tegra234-aon-fabric
- nvidia,tegra234-bpmp-fabric
- nvidia,tegra234-cbb-fabric
- nvidia,tegra234-dce-fabric
- nvidia,tegra234-rce-fabric
- nvidia,tegra234-sce-fabric
reg:
maxItems: 1
interrupts:
items:
- description: secure interrupt from error notifier
additionalProperties: false
required:
- compatible
- reg
- interrupts
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
cbb-fabric@1300000 {
compatible = "nvidia,tegra234-cbb-fabric";
reg = <0x13a00000 0x400000>;
interrupts = <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>;
};

285
Documentation/devicetree/bindings/arm/vexpress-config.yaml Normal file
View File

@ -0,0 +1,285 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/vexpress-config.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Versatile Express configuration bus bindings
maintainers:
- Andre Przywara <andre.przywara@arm.com>
description:
This is a system control register block, acting as a bridge to the
platform's configuration bus via "system control" interface, addressing
devices with site number, position in the board stack, config controller,
function and device numbers - see motherboard's TRM for more details.
properties:
compatible:
const: arm,vexpress,config-bus
arm,vexpress,config-bridge:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the sysreg node.
muxfpga:
type: object
properties:
compatible:
const: arm,vexpress-muxfpga
arm,vexpress-sysreg,func:
description: FPGA specifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 7
- description: device number
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
shutdown:
type: object
properties:
compatible:
const: arm,vexpress-shutdown
arm,vexpress-sysreg,func:
description: shutdown identifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 8
- description: device number
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
reboot:
type: object
properties:
compatible:
const: arm,vexpress-reboot
arm,vexpress-sysreg,func:
description: reboot identifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 9
- description: device number
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
dvimode:
type: object
properties:
compatible:
const: arm,vexpress-dvimode
arm,vexpress-sysreg,func:
description: DVI mode identifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 11
- description: device number
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
additionalProperties: false
required:
- compatible
- arm,vexpress,config-bridge
patternProperties:
'clk[0-9]*$':
type: object
description:
clocks
properties:
compatible:
const: arm,vexpress-osc
arm,vexpress-sysreg,func:
description: clock specifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 1
- description: clock number
freq-range:
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- description: minimal clock frequency
- description: maximum clock frequency
"#clock-cells":
const: 0
clock-output-names:
maxItems: 1
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
- "#clock-cells"
"^volt-.+$":
$ref: /schemas/regulator/regulator.yaml#
properties:
compatible:
const: arm,vexpress-volt
arm,vexpress-sysreg,func:
description: regulator specifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 2
- description: device number
label:
maxItems: 1
unevaluatedProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
"^amp-.+$":
type: object
properties:
compatible:
const: arm,vexpress-amp
arm,vexpress-sysreg,func:
description: current sensor identifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 3
- description: device number
label:
maxItems: 1
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
"^temp-.+$":
type: object
properties:
compatible:
const: arm,vexpress-temp
arm,vexpress-sysreg,func:
description: temperature sensor identifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 4
- description: device number
label:
maxItems: 1
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
"^reset[0-9]*$":
type: object
properties:
compatible:
const: arm,vexpress-reset
arm,vexpress-sysreg,func:
description: reset specifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 5
- description: reset device number
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
"^power-.+$":
type: object
properties:
compatible:
const: arm,vexpress-power
arm,vexpress-sysreg,func:
description: power sensor identifier
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- const: 12
- description: device number
label:
maxItems: 1
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
"^energy(-.+)?$":
type: object
properties:
compatible:
const: arm,vexpress-energy
arm,vexpress-sysreg,func:
description: energy sensor identifier
$ref: /schemas/types.yaml#/definitions/uint32-array
oneOf:
- items:
- const: 13
- description: device number
- items:
- const: 13
- description: device number
- const: 13
- description: second device number
label:
maxItems: 1
additionalProperties: false
required:
- compatible
- arm,vexpress-sysreg,func
examples:
- |
mcc {
compatible = "arm,vexpress,config-bus";
arm,vexpress,config-bridge = <&v2m_sysreg>;
clk0 {
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 0>;
#clock-cells = <0>;
};
energy {
compatible = "arm,vexpress-energy";
arm,vexpress-sysreg,func = <13 0>, <13 1>;
};
};

96
Documentation/devicetree/bindings/arm/vexpress-sysreg.yaml Normal file
View File

@ -0,0 +1,96 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/vexpress-sysreg.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Versatile Express system registers bindings
maintainers:
- Andre Przywara <andre.przywara@arm.com>
description:
This is a system control registers block, providing multiple low level
platform functions like board detection and identification, software
interrupt generation, MMC and NOR Flash control, etc.
properties:
compatible:
const: arm,vexpress-sysreg
reg:
maxItems: 1
"#address-cells":
const: 1
"#size-cells":
const: 1
ranges: true
gpio-controller:
deprecated: true
"#gpio-cells":
deprecated: true
const: 2
additionalProperties: false
patternProperties:
'^gpio@[0-9a-f]+$':
type: object
additionalProperties: false
description:
GPIO children
properties:
compatible:
enum:
- arm,vexpress-sysreg,sys_led
- arm,vexpress-sysreg,sys_mci
- arm,vexpress-sysreg,sys_flash
gpio-controller: true
"#gpio-cells":
const: 2
description: |
The first cell is the function number:
for sys_led : 0..7 = LED 0..7
for sys_mci : 0 = MMC CARDIN, 1 = MMC WPROT
for sys_flash : 0 = NOR FLASH WPn
The second cell can take standard GPIO flags.
reg:
maxItems: 1
required:
- compatible
- reg
- gpio-controller
- "#gpio-cells"
required:
- compatible
- reg
examples:
- |
sysreg@0 {
compatible = "arm,vexpress-sysreg";
reg = <0x00000 0x1000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0x1000>;
v2m_led_gpios: gpio@8 {
compatible = "arm,vexpress-sysreg,sys_led";
reg = <0x008 4>;
gpio-controller;
#gpio-cells = <2>;
};
};
...

189
Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml Normal file
View File

@ -0,0 +1,189 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/ata/ceva,ahci-1v84.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Ceva AHCI SATA Controller
maintainers:
- Piyush Mehta <piyush.mehta@xilinx.com>
description: |
The Ceva SATA controller mostly conforms to the AHCI interface with some
special extensions to add functionality, is a high-performance dual-port
SATA host controller with an AHCI compliant command layer which supports
advanced features such as native command queuing and frame information
structure (FIS) based switching for systems employing port multipliers.
properties:
compatible:
const: ceva,ahci-1v84
reg:
maxItems: 1
clocks:
maxItems: 1
dma-coherent: true
interrupts:
maxItems: 1
iommus:
maxItems: 1
power-domains:
maxItems: 1
ceva,p0-cominit-params:
$ref: /schemas/types.yaml#/definitions/uint8-array
description: |
OOB timing value for COMINIT parameter for port 0.
The fields for the above parameter must be as shown below:-
ceva,p0-cominit-params = /bits/ 8 <CIBGMN CIBGMX CIBGN CINMP>;
items:
- description: CINMP - COMINIT Negate Minimum Period.
- description: CIBGN - COMINIT Burst Gap Nominal.
- description: CIBGMX - COMINIT Burst Gap Maximum.
- description: CIBGMN - COMINIT Burst Gap Minimum.
ceva,p0-comwake-params:
$ref: /schemas/types.yaml#/definitions/uint8-array
description: |
OOB timing value for COMWAKE parameter for port 0.
The fields for the above parameter must be as shown below:-
ceva,p0-comwake-params = /bits/ 8 <CWBGMN CWBGMX CWBGN CWNMP>;
items:
- description: CWBGMN - COMWAKE Burst Gap Minimum.
- description: CWBGMX - COMWAKE Burst Gap Maximum.
- description: CWBGN - COMWAKE Burst Gap Nominal.
- description: CWNMP - COMWAKE Negate Minimum Period.
ceva,p0-burst-params:
$ref: /schemas/types.yaml#/definitions/uint8-array
description: |
Burst timing value for COM parameter for port 0.
The fields for the above parameter must be as shown below:-
ceva,p0-burst-params = /bits/ 8 <BMX BNM SFD PTST>;
items:
- description: BMX - COM Burst Maximum.
- description: BNM - COM Burst Nominal.
- description: SFD - Signal Failure Detection value.
- description: PTST - Partial to Slumber timer value.
ceva,p0-retry-params:
$ref: /schemas/types.yaml#/definitions/uint16-array
description: |
Retry interval timing value for port 0.
The fields for the above parameter must be as shown below:-
ceva,p0-retry-params = /bits/ 16 <RIT RCT>;
items:
- description: RIT - Retry Interval Timer.
- description: RCT - Rate Change Timer.
ceva,p1-cominit-params:
$ref: /schemas/types.yaml#/definitions/uint8-array
description: |
OOB timing value for COMINIT parameter for port 1.
The fields for the above parameter must be as shown below:-
ceva,p1-cominit-params = /bits/ 8 <CIBGMN CIBGMX CIBGN CINMP>;
items:
- description: CINMP - COMINIT Negate Minimum Period.
- description: CIBGN - COMINIT Burst Gap Nominal.
- description: CIBGMX - COMINIT Burst Gap Maximum.
- description: CIBGMN - COMINIT Burst Gap Minimum.
ceva,p1-comwake-params:
$ref: /schemas/types.yaml#/definitions/uint8-array
description: |
OOB timing value for COMWAKE parameter for port 1.
The fields for the above parameter must be as shown below:-
ceva,p1-comwake-params = /bits/ 8 <CWBGMN CWBGMX CWBGN CWNMP>;
items:
- description: CWBGMN - COMWAKE Burst Gap Minimum.
- description: CWBGMX - COMWAKE Burst Gap Maximum.
- description: CWBGN - COMWAKE Burst Gap Nominal.
- description: CWNMP - COMWAKE Negate Minimum Period.
ceva,p1-burst-params:
$ref: /schemas/types.yaml#/definitions/uint8-array
description: |
Burst timing value for COM parameter for port 1.
The fields for the above parameter must be as shown below:-
ceva,p1-burst-params = /bits/ 8 <BMX BNM SFD PTST>;
items:
- description: BMX - COM Burst Maximum.
- description: BNM - COM Burst Nominal.
- description: SFD - Signal Failure Detection value.
- description: PTST - Partial to Slumber timer value.
ceva,p1-retry-params:
$ref: /schemas/types.yaml#/definitions/uint16-array
description: |
Retry interval timing value for port 1.
The fields for the above parameter must be as shown below:-
ceva,pN-retry-params = /bits/ 16 <RIT RCT>;
items:
- description: RIT - Retry Interval Timer.
- description: RCT - Rate Change Timer.
ceva,broken-gen2:
$ref: /schemas/types.yaml#/definitions/flag
description: |
limit to gen1 speed instead of gen2.
phys:
maxItems: 1
phy-names:
items:
- const: sata-phy
resets:
maxItems: 1
required:
- compatible
- reg
- clocks
- interrupts
- ceva,p0-cominit-params
- ceva,p0-comwake-params
- ceva,p0-burst-params
- ceva,p0-retry-params
- ceva,p1-cominit-params
- ceva,p1-comwake-params
- ceva,p1-burst-params
- ceva,p1-retry-params
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/xlnx-zynqmp-clk.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/power/xlnx-zynqmp-power.h>
#include <dt-bindings/reset/xlnx-zynqmp-resets.h>
#include <dt-bindings/clock/xlnx-zynqmp-clk.h>
#include <dt-bindings/phy/phy.h>
sata: ahci@fd0c0000 {
compatible = "ceva,ahci-1v84";
reg = <0xfd0c0000 0x200>;
interrupt-parent = <&gic>;
interrupts = <0 133 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&zynqmp_clk SATA_REF>;
ceva,p0-cominit-params = /bits/ 8 <0x0F 0x25 0x18 0x29>;
ceva,p0-comwake-params = /bits/ 8 <0x04 0x0B 0x08 0x0F>;
ceva,p0-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>;
ceva,p0-retry-params = /bits/ 16 <0x0216 0x7F06>;
ceva,p1-cominit-params = /bits/ 8 <0x0F 0x25 0x18 0x29>;
ceva,p1-comwake-params = /bits/ 8 <0x04 0x0B 0x08 0x0F>;
ceva,p1-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>;
ceva,p1-retry-params = /bits/ 16 <0x0216 0x7F06>;
ceva,broken-gen2;
phys = <&psgtr 1 PHY_TYPE_SATA 1 1>;
resets = <&zynqmp_reset ZYNQMP_RESET_SATA>;
};

144
Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml Normal file
View File

@ -0,0 +1,144 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/qcom,ssc-block-bus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: The AHB Bus Providing a Global View of the SSC Block on (some) qcom SoCs
maintainers:
- Michael Srba <Michael.Srba@seznam.cz>
description: |
This binding describes the dependencies (clocks, resets, power domains) which
need to be turned on in a sequence before communication over the AHB bus
becomes possible.
Additionally, the reg property is used to pass to the driver the location of
two sadly undocumented registers which need to be poked as part of the sequence.
The SSC (Snapdragon Sensor Core) block contains a gpio controller, i2c/spi/uart
controllers, a hexagon core, and a clock controller which provides clocks for
the above.
properties:
compatible:
items:
- const: qcom,msm8998-ssc-block-bus
- const: qcom,ssc-block-bus
reg:
items:
- description: SSCAON_CONFIG0 registers
- description: SSCAON_CONFIG1 registers
reg-names:
items:
- const: mpm_sscaon_config0
- const: mpm_sscaon_config1
'#address-cells':
enum: [ 1, 2 ]
'#size-cells':
enum: [ 1, 2 ]
ranges: true
clocks:
maxItems: 6
clock-names:
items:
- const: xo
- const: aggre2
- const: gcc_im_sleep
- const: aggre2_north
- const: ssc_xo
- const: ssc_ahbs
power-domains:
items:
- description: CX power domain
- description: MX power domain
power-domain-names:
items:
- const: ssc_cx
- const: ssc_mx
resets:
items:
- description: Main reset
- description:
SSC Branch Control Register reset (associated with the ssc_xo and
ssc_ahbs clocks)
reset-names:
items:
- const: ssc_reset
- const: ssc_bcr
qcom,halt-regs:
$ref: /schemas/types.yaml#/definitions/phandle-array
description: describes how to locate the ssc AXI halt register
items:
- items:
- description: Phandle reference to a syscon representing TCSR
- description: offset for the ssc AXI halt register
required:
- compatible
- reg
- reg-names
- '#address-cells'
- '#size-cells'
- ranges
- clocks
- clock-names
- power-domains
- power-domain-names
- resets
- reset-names
- qcom,halt-regs
additionalProperties:
type: object
examples:
- |
#include <dt-bindings/clock/qcom,gcc-msm8998.h>
#include <dt-bindings/clock/qcom,rpmcc.h>
#include <dt-bindings/power/qcom-rpmpd.h>
soc {
#address-cells = <1>;
#size-cells = <1>;
// devices under this node are physically located in the SSC block, connected to an ssc-internal bus;
ssc_ahb_slave: bus@10ac008 {
#address-cells = <1>;
#size-cells = <1>;
ranges;
compatible = "qcom,msm8998-ssc-block-bus", "qcom,ssc-block-bus";
reg = <0x10ac008 0x4>, <0x10ac010 0x4>;
reg-names = "mpm_sscaon_config0", "mpm_sscaon_config1";
clocks = <&xo>,
<&rpmcc RPM_SMD_AGGR2_NOC_CLK>,
<&gcc GCC_IM_SLEEP>,
<&gcc AGGRE2_SNOC_NORTH_AXI>,
<&gcc SSC_XO>,
<&gcc SSC_CNOC_AHBS_CLK>;
clock-names = "xo", "aggre2", "gcc_im_sleep", "aggre2_north", "ssc_xo", "ssc_ahbs";
resets = <&gcc GCC_SSC_RESET>, <&gcc GCC_SSC_BCR>;
reset-names = "ssc_reset", "ssc_bcr";
power-domains = <&rpmpd MSM8998_SSCCX>, <&rpmpd MSM8998_SSCMX>;
power-domain-names = "ssc_cx", "ssc_mx";
qcom,halt-regs = <&tcsr_mutex_regs 0x26000>;
};
};

35
Documentation/devicetree/bindings/chrome/google,cros-kbd-led-backlight.yaml Normal file
View File

@ -0,0 +1,35 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/chrome/google,cros-kbd-led-backlight.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ChromeOS keyboard backlight LED driver.
maintainers:
- Tzung-Bi Shih <tzungbi@kernel.org>
properties:
compatible:
const: google,cros-kbd-led-backlight
required:
- compatible
additionalProperties: false
examples:
- |
spi0 {
#address-cells = <1>;
#size-cells = <0>;
cros_ec: ec@0 {
compatible = "google,cros-ec-spi";
reg = <0>;
kbd-led-backlight {
compatible = "google,cros-kbd-led-backlight";
};
};
};

58
Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml Normal file
View File

@ -0,0 +1,58 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/airoha,en7523-scu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: EN7523 Clock Device Tree Bindings
maintainers:
- Felix Fietkau <nbd@nbd.name>
- John Crispin <nbd@nbd.name>
description: |
This node defines the System Control Unit of the EN7523 SoC,
a collection of registers configuring many different aspects of the SoC.
The clock driver uses it to read and configure settings of the
PLL controller, which provides clocks for the CPU, the bus and
other SoC internal peripherals.
Each clock is assigned an identifier and client nodes use this identifier
to specify which clock they consume.
All these identifiers can be found in:
[1]: <include/dt-bindings/clock/en7523-clk.h>.
The clocks are provided inside a system controller node.
properties:
compatible:
items:
- const: airoha,en7523-scu
reg:
maxItems: 2
"#clock-cells":
description:
The first cell indicates the clock number, see [1] for available
clocks.
const: 1
required:
- compatible
- reg
- '#clock-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/en7523-clk.h>
scu: system-controller@1fa20000 {
compatible = "airoha,en7523-scu";
reg = <0x1fa20000 0x400>,
<0x1fb00000 0x1000>;
#clock-cells = <1>;
};

43
Documentation/devicetree/bindings/clock/fsl,scu-clk.yaml Normal file
View File

@ -0,0 +1,43 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/fsl,scu-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: i.MX SCU Client Device Node - Clock bindings based on SCU Message Protocol
maintainers:
- Abel Vesa <abel.vesa@nxp.com>
description: i.MX SCU Client Device Node
Client nodes are maintained as children of the relevant IMX-SCU device node.
This binding uses the common clock binding.
(Documentation/devicetree/bindings/clock/clock-bindings.txt)
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See the full list of clock IDs from
include/dt-bindings/clock/imx8qxp-clock.h
properties:
compatible:
items:
- enum:
- fsl,imx8dxl-clk
- fsl,imx8qm-clk
- fsl,imx8qxp-clk
- const: fsl,scu-clk
'#clock-cells':
const: 2
required:
- compatible
- '#clock-cells'
additionalProperties: false
examples:
- |
clock-controller {
compatible = "fsl,imx8qxp-clk", "fsl,scu-clk";
#clock-cells = <2>;
};

61
Documentation/devicetree/bindings/clock/mediatek,apmixedsys.yaml Normal file
View File

@ -0,0 +1,61 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/clock/mediatek,apmixedsys.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: MediaTek AP Mixedsys Controller
maintainers:
- Michael Turquette <mturquette@baylibre.com>
- Stephen Boyd <sboyd@kernel.org>
description:
The Mediatek apmixedsys controller provides PLLs to the system.
The clock values can be found in <dt-bindings/clock/mt*-clk.h>.
properties:
compatible:
oneOf:
- enum:
- mediatek,mt6797-apmixedsys
- mediatek,mt7622-apmixedsys
- mediatek,mt7986-apmixedsys
- mediatek,mt8135-apmixedsys
- mediatek,mt8173-apmixedsys
- mediatek,mt8516-apmixedsys
- items:
- const: mediatek,mt7623-apmixedsys
- const: mediatek,mt2701-apmixedsys
- const: syscon
- items:
- enum:
- mediatek,mt2701-apmixedsys
- mediatek,mt2712-apmixedsys
- mediatek,mt6765-apmixedsys
- mediatek,mt6779-apmixedsys
- mediatek,mt7629-apmixedsys
- mediatek,mt8167-apmixedsys
- mediatek,mt8183-apmixedsys
- const: syscon
reg:
maxItems: 1
'#clock-cells':
const: 1
required:
- compatible
- reg
- '#clock-cells'
additionalProperties: false
examples:
- |
apmixedsys: clock-controller@10209000 {
compatible = "mediatek,mt8173-apmixedsys";
reg = <0x10209000 0x1000>;
#clock-cells = <1>;
};

61
Documentation/devicetree/bindings/clock/mediatek,topckgen.yaml Normal file
View File

@ -0,0 +1,61 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/clock/mediatek,topckgen.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: MediaTek Top Clock Generator Controller
maintainers:
- Michael Turquette <mturquette@baylibre.com>
- Stephen Boyd <sboyd@kernel.org>
description:
The Mediatek topckgen controller provides various clocks to the system.
The clock values can be found in <dt-bindings/clock/mt*-clk.h>.
properties:
compatible:
oneOf:
- enum:
- mediatek,mt6797-topckgen
- mediatek,mt7622-topckgen
- mediatek,mt8135-topckgen
- mediatek,mt8173-topckgen
- mediatek,mt8516-topckgen
- items:
- const: mediatek,mt7623-topckgen
- const: mediatek,mt2701-topckgen
- const: syscon
- items:
- enum:
- mediatek,mt2701-topckgen
- mediatek,mt2712-topckgen
- mediatek,mt6765-topckgen
- mediatek,mt6779-topckgen
- mediatek,mt7629-topckgen
- mediatek,mt7986-topckgen
- mediatek,mt8167-topckgen
- mediatek,mt8183-topckgen
- const: syscon
reg:
maxItems: 1
'#clock-cells':
const: 1
required:
- compatible
- reg
- '#clock-cells'
additionalProperties: false
examples:
- |
topckgen: clock-controller@10000000 {
compatible = "mediatek,mt8173-topckgen";
reg = <0x10000000 0x1000>;
#clock-cells = <1>;
};

49
Documentation/devicetree/bindings/clock/nuvoton,npcm845-clk.yaml Normal file
View File

@ -0,0 +1,49 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/nuvoton,npcm845-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Nuvoton NPCM8XX Clock Controller Binding
maintainers:
- Tomer Maimon <tmaimon77@gmail.com>
description: |
Nuvoton Arbel BMC NPCM8XX contains an integrated clock controller, which
generates and supplies clocks to all modules within the BMC.
properties:
compatible:
enum:
- nuvoton,npcm845-clk
reg:
maxItems: 1
'#clock-cells':
const: 1
description:
See include/dt-bindings/clock/nuvoton,npcm8xx-clock.h for the full
list of NPCM8XX clock IDs.
required:
- compatible
- reg
- '#clock-cells'
additionalProperties: false
examples:
- |
ahb {
#address-cells = <2>;
#size-cells = <2>;
clock-controller@f0801000 {
compatible = "nuvoton,npcm845-clk";
reg = <0x0 0xf0801000 0x0 0x1000>;
#clock-cells = <1>;
};
};
...

42
Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml Normal file
View File

@ -0,0 +1,42 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,gcc-apq8084.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller Binding for APQ8084
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- Taniya Das <quic_tdas@quicinc.com>
description: |
Qualcomm global clock control module which supports the clocks, resets and
power domains on APQ8084.
See also::
- dt-bindings/clock/qcom,gcc-apq8084.h
- dt-bindings/reset/qcom,gcc-apq8084.h
allOf:
- $ref: qcom,gcc.yaml#
properties:
compatible:
const: qcom,gcc-apq8084
required:
- compatible
unevaluatedProperties: false
examples:
- |
clock-controller@fc400000 {
compatible = "qcom,gcc-apq8084";
reg = <0xfc400000 0x4000>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
...

128
Documentation/devicetree/bindings/clock/qcom,gcc-sc8280xp.yaml Normal file
View File

@ -0,0 +1,128 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,gcc-sc8280xp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller Binding for SC8280xp
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
description: |
Qualcomm global clock control module which supports the clocks, resets and
power domains on SC8280xp.
See also:
- include/dt-bindings/clock/qcom,gcc-sc8280xp.h
properties:
compatible:
const: qcom,gcc-sc8280xp
clocks:
items:
- description: XO reference clock
- description: Sleep clock
- description: UFS memory first RX symbol clock
- description: UFS memory second RX symbol clock
- description: UFS memory first TX symbol clock
- description: UFS card first RX symbol clock
- description: UFS card second RX symbol clock
- description: UFS card first TX symbol clock
- description: Primary USB SuperSpeed pipe clock
- description: USB4 PHY pipegmux clock source
- description: USB4 PHY DP gmux clock source
- description: USB4 PHY sys piegmux clock source
- description: USB4 PHY PCIe pipe clock
- description: USB4 PHY router max pipe clock
- description: Primary USB4 RX0 clock
- description: Primary USB4 RX1 clock
- description: Secondary USB SuperSpeed pipe clock
- description: Second USB4 PHY pipegmux clock source
- description: Second USB4 PHY DP gmux clock source
- description: Second USB4 PHY sys pipegmux clock source
- description: Second USB4 PHY PCIe pipe clock
- description: Second USB4 PHY router max pipe clock
- description: Secondary USB4 RX0 clock
- description: Secondary USB4 RX1 clock
- description: Multiport USB first SupserSpeed pipe clock
- description: Multiport USB second SuperSpeed pipe clock
- description: PCIe 2a pipe clock
- description: PCIe 2b pipe clock
- description: PCIe 3a pipe clock
- description: PCIe 3b pipe clock
- description: PCIe 4 pipe clock
- description: First EMAC controller reference clock
- description: Second EMAC controller reference clock
'#clock-cells':
const: 1
'#reset-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
maxItems: 1
protected-clocks:
maxItems: 389
required:
- compatible
- clocks
- reg
- '#clock-cells'
- '#reset-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
clock-controller@100000 {
compatible = "qcom,gcc-sc8280xp";
reg = <0x00100000 0x1f0000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
<&sleep_clk>,
<&ufs_phy_rx_symbol_0_clk>,
<&ufs_phy_rx_symbol_1_clk>,
<&ufs_phy_tx_symbol_0_clk>,
<&ufs_card_rx_symbol_0_clk>,
<&ufs_card_rx_symbol_1_clk>,
<&ufs_card_tx_symbol_0_clk>,
<&usb_0_ssphy>,
<&gcc_usb4_phy_pipegmux_clk_src>,
<&gcc_usb4_phy_dp_gmux_clk_src>,
<&gcc_usb4_phy_sys_pipegmux_clk_src>,
<&usb4_phy_gcc_usb4_pcie_pipe_clk>,
<&usb4_phy_gcc_usb4rtr_max_pipe_clk>,
<&qusb4phy_gcc_usb4_rx0_clk>,
<&qusb4phy_gcc_usb4_rx1_clk>,
<&usb_1_ssphy>,
<&gcc_usb4_1_phy_pipegmux_clk_src>,
<&gcc_usb4_1_phy_dp_gmux_clk_src>,
<&gcc_usb4_1_phy_sys_pipegmux_clk_src>,
<&usb4_1_phy_gcc_usb4_pcie_pipe_clk>,
<&usb4_1_phy_gcc_usb4rtr_max_pipe_clk>,
<&qusb4phy_1_gcc_usb4_rx0_clk>,
<&qusb4phy_1_gcc_usb4_rx1_clk>,
<&usb_2_ssphy>,
<&usb_3_ssphy>,
<&pcie2a_lane>,
<&pcie2b_lane>,
<&pcie3a_lane>,
<&pcie3b_lane>,
<&pcie4_lane>,
<&rxc0_ref_clk>,
<&rxc1_ref_clk>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
...

72
Documentation/devicetree/bindings/clock/qcom,gpucc-sm8350.yaml Normal file
View File

@ -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,gpucc-sm8350.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Graphics Clock & Reset Controller Binding
maintainers:
- Robert Foss <robert.foss@linaro.org>
description: |
Qualcomm graphics clock control module which supports the clocks, resets and
power domains on Qualcomm SoCs.
See also:
dt-bindings/clock/qcom,gpucc-sm8350.h
properties:
compatible:
enum:
- qcom,sm8350-gpucc
clocks:
items:
- description: Board XO source
- description: GPLL0 main branch source
- description: GPLL0 div branch source
'#clock-cells':
const: 1
'#reset-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
maxItems: 1
required:
- compatible
- reg
- clocks
- '#clock-cells'
- '#reset-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,gcc-sm8350.h>
#include <dt-bindings/clock/qcom,rpmh.h>
soc {
#address-cells = <2>;
#size-cells = <2>;
clock-controller@3d90000 {
compatible = "qcom,sm8350-gpucc";
reg = <0 0x03d90000 0 0x9000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
<&gcc GCC_GPU_GPLL0_CLK_SRC>,
<&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
};
...

156
Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml Normal file
View File

@ -0,0 +1,156 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,rpmcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm RPM Clock Controller
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
- Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
description: |
The clock enumerators are defined in <dt-bindings/clock/qcom,rpmcc.h> and
come in pairs:: FOO_CLK followed by FOO_A_CLK. The latter clock is
an "active" clock, which means that the consumer only care that the clock is
available when the apps CPU subsystem is active, i.e. not suspended or in
deep idle. If it is important that the clock keeps running during system
suspend, you need to specify the non-active clock, the one not containing
*_A_* in the enumerator name.
properties:
compatible:
items:
- enum:
- qcom,rpmcc-apq8060
- qcom,rpmcc-apq8064
- qcom,rpmcc-ipq806x
- qcom,rpmcc-mdm9607
- qcom,rpmcc-msm8226
- qcom,rpmcc-msm8660
- qcom,rpmcc-msm8916
- qcom,rpmcc-msm8936
- qcom,rpmcc-msm8953
- qcom,rpmcc-msm8974
- qcom,rpmcc-msm8976
- qcom,rpmcc-msm8992
- qcom,rpmcc-msm8994
- qcom,rpmcc-msm8996
- qcom,rpmcc-msm8998
- qcom,rpmcc-qcm2290
- qcom,rpmcc-qcs404
- qcom,rpmcc-sdm660
- qcom,rpmcc-sm6115
- qcom,rpmcc-sm6125
- const: qcom,rpmcc
'#clock-cells':
const: 1
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
maxItems: 2
required:
- compatible
- '#clock-cells'
allOf:
- if:
properties:
compatible:
contains:
enum:
- qcom,rpmcc-apq8060
- qcom,rpmcc-ipq806x
- qcom,rpmcc-msm8660
then:
properties:
clocks:
items:
- description: pxo clock
clock-names:
items:
- const: pxo
- if:
properties:
compatible:
contains:
const: qcom,rpmcc-apq8064
then:
properties:
clocks:
items:
- description: pxo clock
- description: cxo clock
clock-names:
items:
- const: pxo
- const: cxo
- if:
properties:
compatible:
contains:
enum:
- qcom,rpmcc-mdm9607
- qcom,rpmcc-msm8226
- qcom,rpmcc-msm8916
- qcom,rpmcc-msm8936
- qcom,rpmcc-msm8953
- qcom,rpmcc-msm8974
- qcom,rpmcc-msm8976
- qcom,rpmcc-msm8992
- qcom,rpmcc-msm8994
- qcom,rpmcc-msm8996
- qcom,rpmcc-msm8998
- qcom,rpmcc-qcm2290
- qcom,rpmcc-qcs404
- qcom,rpmcc-sdm660
- qcom,rpmcc-sm6115
- qcom,rpmcc-sm6125
then:
properties:
clocks:
items:
- description: xo clock
clock-names:
items:
- const: xo
additionalProperties: false
examples:
- |
rpm {
rpm-requests {
compatible = "qcom,rpm-msm8916";
qcom,smd-channels = "rpm_requests";
clock-controller {
compatible = "qcom,rpmcc-msm8916", "qcom,rpmcc";
#clock-cells = <1>;
};
};
};
- |
rpm {
clock-controller {
compatible = "qcom,rpmcc-ipq806x", "qcom,rpmcc";
#clock-cells = <1>;
clocks = <&pxo_board>;
clock-names = "pxo";
};
};

172
Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml Normal file
View File

@ -0,0 +1,172 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,sc7280-lpasscorecc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm LPASS Core & Audio Clock Controller Binding for SC7280
maintainers:
- Taniya Das <tdas@codeaurora.org>
description: |
Qualcomm LPASS core and audio clock control module which supports the
clocks and power domains on SC7280.
See also:
- dt-bindings/clock/qcom,lpasscorecc-sc7280.h
- dt-bindings/clock/qcom,lpassaudiocc-sc7280.h
properties:
clocks: true
clock-names: true
compatible:
enum:
- qcom,sc7280-lpassaoncc
- qcom,sc7280-lpassaudiocc
- qcom,sc7280-lpasscorecc
- qcom,sc7280-lpasshm
power-domains:
maxItems: 1
'#clock-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
maxItems: 1
required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
- '#power-domain-cells'
additionalProperties: false
allOf:
- if:
properties:
compatible:
contains:
const: qcom,sc7280-lpassaudiocc
then:
properties:
clocks:
items:
- description: Board XO source
- description: LPASS_AON_CC_MAIN_RCG_CLK_SRC
clock-names:
items:
- const: bi_tcxo
- const: lpass_aon_cc_main_rcg_clk_src
- if:
properties:
compatible:
contains:
enum:
- qcom,sc7280-lpassaoncc
then:
properties:
clocks:
items:
- description: Board XO source
- description: Board XO active only source
- description: LPASS_AON_CC_MAIN_RCG_CLK_SRC
clock-names:
items:
- const: bi_tcxo
- const: bi_tcxo_ao
- const: iface
- if:
properties:
compatible:
contains:
enum:
- qcom,sc7280-lpasshm
- qcom,sc7280-lpasscorecc
then:
properties:
clocks:
items:
- description: Board XO source
clock-names:
items:
- const: bi_tcxo
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/clock/qcom,gcc-sc7280.h>
#include <dt-bindings/clock/qcom,lpassaudiocc-sc7280.h>
#include <dt-bindings/clock/qcom,lpasscorecc-sc7280.h>
lpass_audiocc: clock-controller@3300000 {
compatible = "qcom,sc7280-lpassaudiocc";
reg = <0x3300000 0x30000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
<&lpass_aon LPASS_AON_CC_MAIN_RCG_CLK_SRC>;
clock-names = "bi_tcxo", "lpass_aon_cc_main_rcg_clk_src";
power-domains = <&lpass_aon LPASS_AON_CC_LPASS_AUDIO_HM_GDSC>;
#clock-cells = <1>;
#power-domain-cells = <1>;
};
- |
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/clock/qcom,gcc-sc7280.h>
#include <dt-bindings/clock/qcom,lpassaudiocc-sc7280.h>
#include <dt-bindings/clock/qcom,lpasscorecc-sc7280.h>
lpass_hm: clock-controller@3c00000 {
compatible = "qcom,sc7280-lpasshm";
reg = <0x3c00000 0x28>;
clocks = <&rpmhcc RPMH_CXO_CLK>;
clock-names = "bi_tcxo";
#clock-cells = <1>;
#power-domain-cells = <1>;
};
- |
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/clock/qcom,gcc-sc7280.h>
#include <dt-bindings/clock/qcom,lpassaudiocc-sc7280.h>
#include <dt-bindings/clock/qcom,lpasscorecc-sc7280.h>
lpasscore: clock-controller@3900000 {
compatible = "qcom,sc7280-lpasscorecc";
reg = <0x3900000 0x50000>;
clocks = <&rpmhcc RPMH_CXO_CLK>;
clock-names = "bi_tcxo";
power-domains = <&lpass_hm LPASS_CORE_CC_LPASS_CORE_HM_GDSC>;
#clock-cells = <1>;
#power-domain-cells = <1>;
};
- |
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/clock/qcom,gcc-sc7280.h>
#include <dt-bindings/clock/qcom,lpassaudiocc-sc7280.h>
#include <dt-bindings/clock/qcom,lpasscorecc-sc7280.h>
lpass_aon: clock-controller@3380000 {
compatible = "qcom,sc7280-lpassaoncc";
reg = <0x3380000 0x30000>;
clocks = <&rpmhcc RPMH_CXO_CLK>, <&rpmhcc RPMH_CXO_CLK_A>,
<&lpasscore LPASS_CORE_CC_CORE_CLK>;
clock-names = "bi_tcxo", "bi_tcxo_ao","iface";
#clock-cells = <1>;
#power-domain-cells = <1>;
};
...

80
Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml Normal file
View File

@ -0,0 +1,80 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Camera Clock & Reset Controller Binding for SM8450
maintainers:
- Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
description: |
Qualcomm camera clock control module which supports the clocks, resets and
power domains on SM8450.
See also include/dt-bindings/clock/qcom,sm8450-camcc.h
properties:
compatible:
const: qcom,sm8450-camcc
clocks:
items:
- description: Camera AHB clock from GCC
- description: Board XO source
- description: Board active XO source
- description: Sleep clock source
power-domains:
maxItems: 1
description:
A phandle and PM domain specifier for the MMCX power domain.
required-opps:
description:
A phandle to an OPP node describing required MMCX performance point.
'#clock-cells':
const: 1
'#reset-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
maxItems: 1
required:
- compatible
- reg
- clocks
- power-domains
- required-opps
- '#clock-cells'
- '#reset-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,gcc-sm8450.h>
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/power/qcom-rpmpd.h>
clock-controller@ade0000 {
compatible = "qcom,sm8450-camcc";
reg = <0xade0000 0x20000>;
clocks = <&gcc GCC_CAMERA_AHB_CLK>,
<&rpmhcc RPMH_CXO_CLK>,
<&rpmhcc RPMH_CXO_CLK_A>,
<&sleep_clk>;
power-domains = <&rpmhpd SM8450_MMCX>;
required-opps = <&rpmhpd_opp_low_svs>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
...

119
Documentation/devicetree/bindings/clock/rockchip,px30-cru.yaml Normal file
View File

@ -0,0 +1,119 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,px30-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip PX30 Clock and Reset Unit (CRU)
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The PX30 clock controller generates and supplies clocks to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/px30-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required
- "xin32k" - rtc clock - optional
- "i2sx_clkin" - external I2S clock - optional
- "gmac_clkin" - external GMAC clock - optional
properties:
compatible:
enum:
- rockchip,px30-cru
- rockchip,px30-pmucru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
minItems: 1
items:
- description: Clock for both PMUCRU and CRU
- description: Clock for CRU (sourced from PMUCRU)
clock-names:
minItems: 1
items:
- const: xin24m
- const: gpll
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg
- clocks
- clock-names
- "#clock-cells"
- "#reset-cells"
allOf:
- if:
properties:
compatible:
contains:
const: rockchip,px30-cru
then:
properties:
clocks:
minItems: 2
clock-names:
minItems: 2
else:
properties:
clocks:
maxItems: 1
clock-names:
maxItems: 1
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/px30-cru.h>
pmucru: clock-controller@ff2bc000 {
compatible = "rockchip,px30-pmucru";
reg = <0xff2bc000 0x1000>;
clocks = <&xin24m>;
clock-names = "xin24m";
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};
cru: clock-controller@ff2b0000 {
compatible = "rockchip,px30-cru";
reg = <0xff2b0000 0x1000>;
clocks = <&xin24m>, <&pmucru PLL_GPLL>;
clock-names = "xin24m", "gpll";
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};

72
Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.yaml Normal file
View File

@ -0,0 +1,72 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3036-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip RK3036 Clock and Reset Unit (CRU)
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The RK3036 clock controller generates and supplies clocks to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3036-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required
- "ext_i2s" - external I2S clock - optional
- "rmii_clkin" - external EMAC clock - optional
properties:
compatible:
enum:
- rockchip,rk3036-cru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
maxItems: 1
clock-names:
const: xin24m
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
- |
cru: clock-controller@20000000 {
compatible = "rockchip,rk3036-cru";
reg = <0x20000000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};

78
Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.yaml Normal file
View File

@ -0,0 +1,78 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3188-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip RK3188/RK3066 Clock and Reset Unit (CRU)
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The RK3188/RK3066 clock controller generates and supplies clocks to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3188-cru.h and
dt-bindings/clock/rk3066-cru.h headers and can be used in device tree sources.
Similar macros exist for the reset sources in these files.
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required
- "xin32k" - RTC clock - optional
- "xin27m" - 27mhz crystal input on RK3066 - optional
- "ext_hsadc" - external HSADC clock - optional
- "ext_cif0" - external camera clock - optional
- "ext_rmii" - external RMII clock - optional
- "ext_jtag" - external JTAG clock - optional
properties:
compatible:
enum:
- rockchip,rk3066a-cru
- rockchip,rk3188-cru
- rockchip,rk3188a-cru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
maxItems: 1
clock-names:
const: xin24m
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
- |
cru: clock-controller@20000000 {
compatible = "rockchip,rk3188-cru";
reg = <0x20000000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};

74
Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.yaml Normal file
View File

@ -0,0 +1,74 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3228-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip RK3228 Clock and Reset Unit (CRU)
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The RK3228 clock controller generates and supplies clocks to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3228-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required
- "ext_i2s" - external I2S clock - optional
- "ext_gmac" - external GMAC clock - optional
- "ext_hsadc" - external HSADC clock - optional
- "phy_50m_out" - output clock of the pll in the mac phy
properties:
compatible:
enum:
- rockchip,rk3228-cru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
maxItems: 1
clock-names:
const: xin24m
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
- |
cru: clock-controller@20000000 {
compatible = "rockchip,rk3228-cru";
reg = <0x20000000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};

85
Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.yaml Normal file
View File

@ -0,0 +1,85 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3288-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip RK3288 Clock and Reset Unit (CRU)
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The RK3288 clock controller generates and supplies clocks to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
A revision of this SoC is available: rk3288w. The clock tree is a bit
different so another dt-compatible is available. Noticed that it is only
setting the difference but there is no automatic revision detection. This
should be performed by boot loaders.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3288-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required,
- "xin32k" - rtc clock - optional,
- "ext_i2s" - external I2S clock - optional,
- "ext_hsadc" - external HSADC clock - optional,
- "ext_edp_24m" - external display port clock - optional,
- "ext_vip" - external VIP clock - optional,
- "ext_isp" - external ISP clock - optional,
- "ext_jtag" - external JTAG clock - optional
properties:
compatible:
enum:
- rockchip,rk3288-cru
- rockchip,rk3288w-cru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
maxItems: 1
clock-names:
const: xin24m
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
- |
cru: clock-controller@ff760000 {
compatible = "rockchip,rk3288-cru";
reg = <0xff760000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};

76
Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.yaml Normal file
View File

@ -0,0 +1,76 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3308-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip RK3308 Clock and Reset Unit (CRU)
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The RK3308 clock controller generates and supplies clocks to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3308-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required
- "xin32k" - rtc clock - optional
- "mclk_i2s0_8ch_in", "mclk_i2s1_8ch_in",
"mclk_i2s2_8ch_in", "mclk_i2s3_8ch_in",
"mclk_i2s0_2ch_in", "mclk_i2s1_2ch_in" - external I2S or
SPDIF clock - optional
- "mac_clkin" - external MAC clock - optional
properties:
compatible:
enum:
- rockchip,rk3308-cru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
maxItems: 1
clock-names:
const: xin24m
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
- |
cru: clock-controller@ff500000 {
compatible = "rockchip,rk3308-cru";
reg = <0xff500000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};

78
Documentation/devicetree/bindings/clock/rockchip,rk3368-cru.yaml Normal file
View File

@ -0,0 +1,78 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rk3368-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip RK3368 Clock and Reset Unit (CRU)
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The RK3368 clock controller generates and supplies clocks to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3368-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required
- "xin32k" - rtc clock - optional
- "ext_i2s" - external I2S clock - optional
- "ext_gmac" - external GMAC clock - optional
- "ext_hsadc" - external HSADC clock - optional
- "ext_isp" - external ISP clock - optional
- "ext_jtag" - external JTAG clock - optional
- "ext_vip" - external VIP clock - optional
- "usbotg_out" - output clock of the pll in the otg phy
properties:
compatible:
enum:
- rockchip,rk3368-cru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
maxItems: 1
clock-names:
const: xin24m
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
- |
cru: clock-controller@ff760000 {
compatible = "rockchip,rk3368-cru";
reg = <0xff760000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};

75
Documentation/devicetree/bindings/clock/rockchip,rv1108-cru.yaml Normal file
View File

@ -0,0 +1,75 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/rockchip,rv1108-cru.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rockchip RV1108 Clock and Reset Unit (CRU)
maintainers:
- Elaine Zhang <zhangqing@rock-chips.com>
- Heiko Stuebner <heiko@sntech.de>
description: |
The RV1108 clock controller generates and supplies clocks to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rv1108-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required
- "ext_vip" - external VIP clock - optional
- "ext_i2s" - external I2S clock - optional
- "ext_gmac" - external GMAC clock - optional
- "hdmiphy" - external clock input derived from HDMI PHY - optional
- "usbphy" - external clock input derived from USB PHY - optional
properties:
compatible:
enum:
- rockchip,rv1108-cru
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
clocks:
maxItems: 1
clock-names:
const: xin24m
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to the syscon managing the "general register files" (GRF),
if missing pll rates are not changeable, due to the missing pll
lock status.
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
- |
cru: clock-controller@20200000 {
compatible = "rockchip,rv1108-cru";
reg = <0x20200000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};

219
Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml Normal file
View File

@ -0,0 +1,219 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/samsung,exynosautov9-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos Auto v9 SoC clock controller
maintainers:
- Chanho Park <chanho61.park@samsung.com>
- Chanwoo Choi <cw00.choi@samsung.com>
- Krzysztof Kozlowski <krzk@kernel.org>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
- Tomasz Figa <tomasz.figa@gmail.com>
description: |
Exynos Auto v9 clock controller is comprised of several CMU units, generating
clocks for different domains. Those CMU units are modeled as separate device
tree nodes, and might depend on each other. Root clocks in that clock tree are
two external clocks:: OSCCLK/XTCXO (26 MHz) and RTCCLK/XrtcXTI (32768 Hz).
The external OSCCLK must be defined as fixed-rate clock in dts.
CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
dividers; all other clocks of function blocks (other CMUs) are usually
derived from CMU_TOP.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All clocks available for usage
in clock consumer nodes are defined as preprocessor macros in
'include/dt-bindings/clock/samsung,exynosautov9.h' header.
properties:
compatible:
enum:
- samsung,exynosautov9-cmu-top
- samsung,exynosautov9-cmu-busmc
- samsung,exynosautov9-cmu-core
- samsung,exynosautov9-cmu-fsys2
- samsung,exynosautov9-cmu-peric0
- samsung,exynosautov9-cmu-peric1
- samsung,exynosautov9-cmu-peris
clocks:
minItems: 1
maxItems: 5
clock-names:
minItems: 1
maxItems: 5
"#clock-cells":
const: 1
reg:
maxItems: 1
allOf:
- if:
properties:
compatible:
contains:
const: samsung,exynosautov9-cmu-top
then:
properties:
clocks:
items:
- description: External reference clock (26 MHz)
clock-names:
items:
- const: oscclk
- if:
properties:
compatible:
contains:
const: samsung,exynosautov9-cmu-busmc
then:
properties:
clocks:
items:
- description: External reference clock (26 MHz)
- description: CMU_BUSMC bus clock (from CMU_TOP)
clock-names:
items:
- const: oscclk
- const: dout_clkcmu_busmc_bus
- if:
properties:
compatible:
contains:
const: samsung,exynosautov9-cmu-core
then:
properties:
clocks:
items:
- description: External reference clock (26 MHz)
- description: CMU_CORE bus clock (from CMU_TOP)
clock-names:
items:
- const: oscclk
- const: dout_clkcmu_core_bus
- if:
properties:
compatible:
contains:
const: samsung,exynosautov9-cmu-fsys2
then:
properties:
clocks:
items:
- description: External reference clock (26 MHz)
- description: CMU_FSYS2 bus clock (from CMU_TOP)
- description: UFS clock (from CMU_TOP)
- description: Ethernet clock (from CMU_TOP)
clock-names:
items:
- const: oscclk
- const: dout_clkcmu_fsys2_bus
- const: dout_fsys2_clkcmu_ufs_embd
- const: dout_fsys2_clkcmu_ethernet
- if:
properties:
compatible:
contains:
const: samsung,exynosautov9-cmu-peric0
then:
properties:
clocks:
items:
- description: External reference clock (26 MHz)
- description: CMU_PERIC0 bus clock (from CMU_TOP)
- description: PERIC0 IP clock (from CMU_TOP)
clock-names:
items:
- const: oscclk
- const: dout_clkcmu_peric0_bus
- const: dout_clkcmu_peric0_ip
- if:
properties:
compatible:
contains:
const: samsung,exynosautov9-cmu-peric1
then:
properties:
clocks:
items:
- description: External reference clock (26 MHz)
- description: CMU_PERIC1 bus clock (from CMU_TOP)
- description: PERIC1 IP clock (from CMU_TOP)
clock-names:
items:
- const: oscclk
- const: dout_clkcmu_peric1_bus
- const: dout_clkcmu_peric1_ip
- if:
properties:
compatible:
contains:
const: samsung,exynosautov9-cmu-peris
then:
properties:
clocks:
items:
- description: External reference clock (26 MHz)
- description: CMU_PERIS bus clock (from CMU_TOP)
clock-names:
items:
- const: oscclk
- const: dout_clkcmu_peris_bus
required:
- compatible
- "#clock-cells"
- clocks
- clock-names
- reg
additionalProperties: false
examples:
# Clock controller node for CMU_FSYS2
- |
#include <dt-bindings/clock/samsung,exynosautov9.h>
cmu_fsys2: clock-controller@17c00000 {
compatible = "samsung,exynosautov9-cmu-fsys2";
reg = <0x17c00000 0x8000>;
#clock-cells = <1>;
clocks = <&xtcxo>,
<&cmu_top DOUT_CLKCMU_FSYS2_BUS>,
<&cmu_top DOUT_CLKCMU_FSYS2_UFS_EMBD>,
<&cmu_top DOUT_CLKCMU_FSYS2_ETHERNET>;
clock-names = "oscclk",
"dout_clkcmu_fsys2_bus",
"dout_fsys2_clkcmu_ufs_embd",
"dout_fsys2_clkcmu_ethernet";
};
...

71
Documentation/devicetree/bindings/clock/sprd,ums512-clk.yaml Normal file
View File

@ -0,0 +1,71 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright 2022 Unisoc Inc.
%YAML 1.2
---
$id: "http://devicetree.org/schemas/clock/sprd,ums512-clk.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: UMS512 Soc clock controller
maintainers:
- Orson Zhai <orsonzhai@gmail.com>
- Baolin Wang <baolin.wang7@gmail.com>
- Chunyan Zhang <zhang.lyra@gmail.com>
properties:
compatible:
enum:
- sprd,ums512-apahb-gate
- sprd,ums512-ap-clk
- sprd,ums512-aonapb-clk
- sprd,ums512-pmu-gate
- sprd,ums512-g0-pll
- sprd,ums512-g2-pll
- sprd,ums512-g3-pll
- sprd,ums512-gc-pll
- sprd,ums512-aon-gate
- sprd,ums512-audcpapb-gate
- sprd,ums512-audcpahb-gate
- sprd,ums512-gpu-clk
- sprd,ums512-mm-clk
- sprd,ums512-mm-gate-clk
- sprd,ums512-apapb-gate
"#clock-cells":
const: 1
clocks:
minItems: 1
maxItems: 4
description: |
The input parent clock(s) phandle for the clock, only list
fixed clocks which are declared in devicetree.
clock-names:
minItems: 1
items:
- const: ext-26m
- const: ext-32k
- const: ext-4m
- const: rco-100m
reg:
maxItems: 1
required:
- compatible
- '#clock-cells'
- reg
additionalProperties: false
examples:
- |
ap_clk: clock-controller@20200000 {
compatible = "sprd,ums512-ap-clk";
reg = <0x20200000 0x1000>;
clocks = <&ext_26m>;
clock-names = "ext-26m";
#clock-cells = <1>;
};
...

52
Documentation/devicetree/bindings/clock/sunplus,sp7021-clkc.yaml Normal file
View File

@ -0,0 +1,52 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) Sunplus Co., Ltd. 2021
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/sunplus,sp7021-clkc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sunplus SP7021 SoC Clock Controller
maintainers:
- Qin Jian <qinjian@cqplus1.com>
properties:
compatible:
const: sunplus,sp7021-clkc
reg:
maxItems: 3
clocks:
maxItems: 1
"#clock-cells":
const: 1
required:
- compatible
- reg
- clocks
- "#clock-cells"
additionalProperties: false
examples:
- |
extclk: osc0 {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <27000000>;
clock-output-names = "extclk";
};
clkc: clock-controller@9c000004 {
compatible = "sunplus,sp7021-clkc";
reg = <0x9c000004 0x28>,
<0x9c000200 0x44>,
<0x9c000268 0x08>;
clocks = <&extclk>;
#clock-cells = <1>;
};
...

89
Documentation/devicetree/bindings/display/arm,hdlcd.yaml Normal file
View File

@ -0,0 +1,89 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/arm,hdlcd.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm HDLCD display controller binding
maintainers:
- Liviu Dudau <Liviu.Dudau@arm.com>
- Andre Przywara <andre.przywara@arm.com>
description:
The Arm HDLCD is a display controller found on several development platforms
produced by ARM Ltd and in more modern of its Fast Models. The HDLCD is an
RGB streamer that reads the data from a framebuffer and sends it to a single
digital encoder (DVI or HDMI).
properties:
compatible:
const: arm,hdlcd
reg:
maxItems: 1
interrupts:
maxItems: 1
clock-names:
const: pxlclk
clocks:
maxItems: 1
description: The input reference for the pixel clock.
memory-region:
maxItems: 1
description:
Phandle to a node describing memory to be used for the framebuffer.
If not present, the framebuffer may be located anywhere in memory.
iommus:
maxItems: 1
port:
$ref: /schemas/graph.yaml#/properties/port
unevaluatedProperties: false
description:
Output endpoint of the controller, connecting the LCD panel signals.
additionalProperties: false
required:
- compatible
- reg
- interrupts
- clocks
- port
examples:
- |
hdlcd@2b000000 {
compatible = "arm,hdlcd";
reg = <0x2b000000 0x1000>;
interrupts = <0 85 4>;
clocks = <&oscclk5>;
clock-names = "pxlclk";
port {
hdlcd_output: endpoint {
remote-endpoint = <&hdmi_enc_input>;
};
};
};
/* HDMI encoder on I2C bus */
i2c {
#address-cells = <1>;
#size-cells = <0>;
hdmi-transmitter@70 {
compatible = "nxp,tda998x";
reg = <0x70>;
port {
hdmi_enc_input: endpoint {
remote-endpoint = <&hdlcd_output>;
};
};
};
};
...

130
Documentation/devicetree/bindings/display/arm,komeda.yaml Normal file
View File

@ -0,0 +1,130 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/arm,komeda.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm Komeda display processor
maintainers:
- Liviu Dudau <Liviu.Dudau@arm.com>
- Andre Przywara <andre.przywara@arm.com>
description:
The Arm Mali D71 display processor supports up to two displays with up
to a 4K resolution each. Each pipeline can be composed of up to four
layers. It is typically connected to a digital display connector like HDMI.
properties:
compatible:
oneOf:
- items:
- const: arm,mali-d32
- const: arm,mali-d71
- const: arm,mali-d71
reg:
maxItems: 1
interrupts:
maxItems: 1
clock-names:
const: aclk
clocks:
maxItems: 1
description: The main DPU processor clock
"#address-cells":
const: 1
"#size-cells":
const: 0
memory-region:
maxItems: 1
description:
Phandle to a node describing memory to be used for the framebuffer.
If not present, the framebuffer may be located anywhere in memory.
iommus:
description:
The stream IDs for each of the used pipelines, each four IDs for the
four layers, plus one for the write-back stream.
minItems: 5
maxItems: 10
patternProperties:
'^pipeline@[01]$':
type: object
description:
clocks
properties:
reg:
enum: [ 0, 1 ]
clock-names:
const: pxclk
clocks:
maxItems: 1
description: The input reference for the pixel clock.
port:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
additionalProperties: false
required:
- "#address-cells"
- "#size-cells"
- compatible
- reg
- interrupts
- clock-names
- clocks
- pipeline@0
examples:
- |
display@c00000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "arm,mali-d71";
reg = <0xc00000 0x20000>;
interrupts = <168>;
clocks = <&dpu_aclk>;
clock-names = "aclk";
iommus = <&smmu 0>, <&smmu 1>, <&smmu 2>, <&smmu 3>,
<&smmu 8>,
<&smmu 4>, <&smmu 5>, <&smmu 6>, <&smmu 7>,
<&smmu 9>;
dp0_pipe0: pipeline@0 {
clocks = <&fpgaosc2>;
clock-names = "pxclk";
reg = <0>;
port {
dp0_pipe0_out: endpoint {
remote-endpoint = <&db_dvi0_in>;
};
};
};
dp0_pipe1: pipeline@1 {
clocks = <&fpgaosc2>;
clock-names = "pxclk";
reg = <1>;
port {
dp0_pipe1_out: endpoint {
remote-endpoint = <&db_dvi1_in>;
};
};
};
};
...

119
Documentation/devicetree/bindings/display/arm,malidp.yaml Normal file
View File

@ -0,0 +1,119 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/arm,malidp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm Mali Display Processor (Mali-DP) binding
maintainers:
- Liviu Dudau <Liviu.Dudau@arm.com>
- Andre Przywara <andre.przywara@arm.com>
description:
The following bindings apply to a family of Display Processors sold as
licensable IP by ARM Ltd. The bindings describe the Mali DP500, DP550 and
DP650 processors that offer multiple composition layers, support for
rotation and scaling output.
properties:
compatible:
enum:
- arm,mali-dp500
- arm,mali-dp550
- arm,mali-dp650
reg:
maxItems: 1
interrupts:
items:
- description:
The interrupt used by the Display Engine (DE). Can be shared with
the interrupt for the Scaling Engine (SE), but it will have to be
listed individually.
- description:
The interrupt used by the Scaling Engine (SE). Can be shared with
the interrupt for the Display Engine (DE), but it will have to be
listed individually.
interrupt-names:
items:
- const: DE
- const: SE
clock-names:
items:
- const: pxlclk
- const: mclk
- const: aclk
- const: pclk
clocks:
items:
- description: the pixel clock feeding the output PLL of the processor
- description: the main processor clock
- description: the AXI interface clock
- description: the APB interface clock
memory-region:
maxItems: 1
description:
Phandle to a node describing memory to be used for the framebuffer.
If not present, the framebuffer may be located anywhere in memory.
arm,malidp-output-port-lines:
$ref: /schemas/types.yaml#/definitions/uint8-array
description:
Number of output lines/bits for each colour channel.
items:
- description: number of output lines for the red channel (R)
- description: number of output lines for the green channel (G)
- description: number of output lines for the blue channel (B)
arm,malidp-arqos-value:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Quality-of-Service value for the display engine FIFOs, to write
into the RQOS register of the DP500.
See the ARM Mali-DP500 TRM for details on the encoding.
If omitted, the RQOS register will not be changed.
port:
$ref: /schemas/graph.yaml#/properties/port
unevaluatedProperties: false
description:
Output endpoint of the controller, connecting the LCD panel signals.
additionalProperties: false
required:
- compatible
- reg
- interrupts
- interrupt-names
- clocks
- clock-names
- port
- arm,malidp-output-port-lines
examples:
- |
dp0: malidp@6f200000 {
compatible = "arm,mali-dp650";
reg = <0x6f200000 0x20000>;
memory-region = <&display_reserved>;
interrupts = <168>, <168>;
interrupt-names = "DE", "SE";
clocks = <&oscclk2>, <&fpgaosc0>, <&fpgaosc1>, <&fpgaosc1>;
clock-names = "pxlclk", "mclk", "aclk", "pclk";
arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
arm,malidp-arqos-value = <0xd000d000>;
port {
dp0_output: endpoint {
remote-endpoint = <&tda998x_2_input>;
};
};
};
...

170
Documentation/devicetree/bindings/display/arm,pl11x.yaml Normal file
View File

@ -0,0 +1,170 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/arm,pl11x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm PrimeCell Color LCD Controller PL110/PL111
maintainers:
- Liviu Dudau <Liviu.Dudau@arm.com>
- Andre Przywara <andre.przywara@arm.com>
description:
The Arm Primcell PL010/PL111 is an LCD controller IP, than scans out
a framebuffer region in system memory, and creates timed signals for
a variety of LCD panels.
# We need a select here so we don't match all nodes with 'arm,primecell'
select:
properties:
compatible:
contains:
enum:
- arm,pl110
- arm,pl111
required:
- compatible
properties:
compatible:
items:
- enum:
- arm,pl110
- arm,pl111
- const: arm,primecell
reg:
maxItems: 1
interrupt-names:
oneOf:
- const: combined
description:
The IP provides four individual interrupt lines, but also one
combined line. If the integration only connects this line to the
interrupt controller, this single interrupt is noted here.
- items:
- const: mbe # CLCDMBEINTR
- const: vcomp # CLCDVCOMPINTR
- const: lnbu # CLCDLNBUINTR
- const: fuf # CLCDFUFINTR
interrupts:
minItems: 1
maxItems: 4
clock-names:
items:
- const: clcdclk
- const: apb_pclk
clocks:
items:
- description: The CLCDCLK reference clock for the controller.
- description: The HCLK AHB slave clock for the register access.
memory-region:
maxItems: 1
description:
Phandle to a node describing memory to be used for the framebuffer.
If not present, the framebuffer may be located anywhere in memory.
max-memory-bandwidth:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Maximum bandwidth in bytes per second that the cell's memory interface
can handle.
If not present, the memory interface is fast enough to handle all
possible video modes.
port:
$ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
description:
Output endpoint of the controller, connecting the LCD panel signals.
properties:
endpoint:
$ref: /schemas/graph.yaml#/$defs/endpoint-base
unevaluatedProperties: false
properties:
arm,pl11x,tft-r0g0b0-pads:
$ref: /schemas/types.yaml#/definitions/uint32-array
items:
- description: index of CLD pad used for first red bit (R0)
- description: index of CLD pad used for first green bit (G0)
- description: index of CLD pad used for first blue bit (G0)
deprecated: true
description: |
DEPRECATED. An array of three 32-bit values, defining the way
CLD[23:0] pads are wired up.
The first value contains the index of the "CLD" external pin (pad)
used as R0 (first bit of the red component), the second value for
green, the third value for blue.
See also "LCD panel signal multiplexing details" paragraphs in the
PL110/PL111 Technical Reference Manuals.
This implicitly defines available color modes, for example:
- PL111 TFT 4:4:4 panel:
arm,pl11x,tft-r0g0b0-pads = <4 15 20>;
- PL110 TFT (1:)5:5:5 panel:
arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
- PL111 TFT (1:)5:5:5 panel:
arm,pl11x,tft-r0g0b0-pads = <3 11 19>;
- PL111 TFT 5:6:5 panel:
arm,pl11x,tft-r0g0b0-pads = <3 10 19>;
- PL110 and PL111 TFT 8:8:8 panel:
arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
- PL110 and PL111 TFT 8:8:8 panel, R & B components swapped:
arm,pl11x,tft-r0g0b0-pads = <16 8 0>;
additionalProperties: false
required:
- compatible
- reg
- clock-names
- clocks
- port
allOf:
- if:
properties:
interrupts:
minItems: 2
required:
- interrupts
then:
required:
- interrupt-names
examples:
- |
clcd@10020000 {
compatible = "arm,pl111", "arm,primecell";
reg = <0x10020000 0x1000>;
interrupt-names = "combined";
interrupts = <44>;
clocks = <&oscclk1>, <&oscclk2>;
clock-names = "clcdclk", "apb_pclk";
max-memory-bandwidth = <94371840>; /* Bps, 1024x768@60 16bpp */
port {
clcd_pads: endpoint {
remote-endpoint = <&clcd_panel>;
};
};
};
panel {
compatible = "arm,rtsm-display";
port {
clcd_panel: endpoint {
remote-endpoint = <&clcd_pads>;
};
};
};
...

173
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml Normal file
View File

@ -0,0 +1,173 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-ldb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale i.MX8qm/qxp LVDS Display Bridge
maintainers:
- Liu Ying <victor.liu@nxp.com>
description: |
The Freescale i.MX8qm/qxp LVDS Display Bridge(LDB) has two channels.
The i.MX8qm/qxp LDB is controlled by Control and Status Registers(CSR) module.
The CSR module, as a system controller, contains the LDB's configuration
registers.
For i.MX8qxp LDB, each channel supports up to 24bpp parallel input color
format and can map the input to VESA or JEIDA standards. The two channels
cannot be used simultaneously, that is to say, the user should pick one of
them to use. Two LDB channels from two LDB instances can work together in
LDB split mode to support a dual link LVDS display. The channel indexes
have to be different. Channel0 outputs odd pixels and channel1 outputs
even pixels.
For i.MX8qm LDB, each channel additionally supports up to 30bpp parallel
input color format. The two channels can be used simultaneously, either
in dual mode or split mode. In dual mode, the two channels output identical
data. In split mode, channel0 outputs odd pixels and channel1 outputs even
pixels.
A side note is that i.MX8qm/qxp LDB is officially called pixel mapper in
the SoC reference manuals. The pixel mapper uses logic of LDBs embedded in
i.MX6qdl/sx SoCs, i.e., it is essentially based on them. To keep the naming
consistency, this binding calls it LDB.
properties:
compatible:
enum:
- fsl,imx8qm-ldb
- fsl,imx8qxp-ldb
"#address-cells":
const: 1
"#size-cells":
const: 0
clocks:
items:
- description: pixel clock
- description: bypass clock
clock-names:
items:
- const: pixel
- const: bypass
power-domains:
maxItems: 1
fsl,companion-ldb:
$ref: /schemas/types.yaml#/definitions/phandle
description: |
A phandle which points to companion LDB which is used in LDB split mode.
patternProperties:
"^channel@[0-1]$":
type: object
description: Represents a channel of LDB.
properties:
"#address-cells":
const: 1
"#size-cells":
const: 0
reg:
description: The channel index.
enum: [ 0, 1 ]
phys:
description: A phandle to the phy module representing the LVDS PHY.
maxItems: 1
phy-names:
const: lvds_phy
port@0:
$ref: /schemas/graph.yaml#/properties/port
description: Input port of the channel.
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: Output port of the channel.
required:
- "#address-cells"
- "#size-cells"
- reg
- phys
- phy-names
additionalProperties: false
required:
- compatible
- "#address-cells"
- "#size-cells"
- clocks
- clock-names
- power-domains
- channel@0
- channel@1
allOf:
- if:
properties:
compatible:
contains:
const: fsl,imx8qm-ldb
then:
properties:
fsl,companion-ldb: false
additionalProperties: false
examples:
- |
#include <dt-bindings/firmware/imx/rsrc.h>
ldb {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx8qxp-ldb";
clocks = <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_MISC2>,
<&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_BYPASS>;
clock-names = "pixel", "bypass";
power-domains = <&pd IMX_SC_R_LVDS_0>;
channel@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
phys = <&mipi_lvds_0_phy>;
phy-names = "lvds_phy";
port@0 {
reg = <0>;
mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi: endpoint {
remote-endpoint = <&mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0>;
};
};
};
channel@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
phys = <&mipi_lvds_0_phy>;
phy-names = "lvds_phy";
port@0 {
reg = <0>;
mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi: endpoint {
remote-endpoint = <&mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1>;
};
};
};
};

144
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml Normal file
View File

@ -0,0 +1,144 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pixel-combiner.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale i.MX8qm/qxp Pixel Combiner
maintainers:
- Liu Ying <victor.liu@nxp.com>
description: |
The Freescale i.MX8qm/qxp Pixel Combiner takes two output streams from a
single display controller and manipulates the two streams to support a number
of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured as
either one screen, two screens, or virtual screens. The pixel combiner is
also responsible for generating some of the control signals for the pixel link
output channel.
properties:
compatible:
enum:
- fsl,imx8qm-pixel-combiner
- fsl,imx8qxp-pixel-combiner
"#address-cells":
const: 1
"#size-cells":
const: 0
reg:
maxItems: 1
clocks:
maxItems: 1
clock-names:
const: apb
power-domains:
maxItems: 1
patternProperties:
"^channel@[0-1]$":
type: object
description: Represents a display stream of pixel combiner.
properties:
"#address-cells":
const: 1
"#size-cells":
const: 0
reg:
description: The display stream index.
enum: [ 0, 1 ]
port@0:
$ref: /schemas/graph.yaml#/properties/port
description: Input endpoint of the display stream.
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: Output endpoint of the display stream.
required:
- "#address-cells"
- "#size-cells"
- reg
- port@0
- port@1
additionalProperties: false
required:
- compatible
- "#address-cells"
- "#size-cells"
- reg
- clocks
- clock-names
- power-domains
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/imx8-lpcg.h>
#include <dt-bindings/firmware/imx/rsrc.h>
pixel-combiner@56020000 {
compatible = "fsl,imx8qxp-pixel-combiner";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x56020000 0x10000>;
clocks = <&dc0_pixel_combiner_lpcg IMX_LPCG_CLK_4>;
clock-names = "apb";
power-domains = <&pd IMX_SC_R_DC_0>;
channel@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
port@0 {
reg = <0>;
dc0_pixel_combiner_ch0_dc0_dpu_disp0: endpoint {
remote-endpoint = <&dc0_dpu_disp0_dc0_pixel_combiner_ch0>;
};
};
port@1 {
reg = <1>;
dc0_pixel_combiner_ch0_dc0_pixel_link0: endpoint {
remote-endpoint = <&dc0_pixel_link0_dc0_pixel_combiner_ch0>;
};
};
};
channel@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
port@0 {
reg = <0>;
dc0_pixel_combiner_ch1_dc0_dpu_disp1: endpoint {
remote-endpoint = <&dc0_dpu_disp1_dc0_pixel_combiner_ch1>;
};
};
port@1 {
reg = <1>;
dc0_pixel_combiner_ch1_dc0_pixel_link1: endpoint {
remote-endpoint = <&dc0_pixel_link1_dc0_pixel_combiner_ch1>;
};
};
};
};

144
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml Normal file
View File

@ -0,0 +1,144 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pixel-link.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale i.MX8qm/qxp Display Pixel Link
maintainers:
- Liu Ying <victor.liu@nxp.com>
description: |
The Freescale i.MX8qm/qxp Display Pixel Link(DPL) forms a standard
asynchronous linkage between pixel sources(display controller or
camera module) and pixel consumers(imaging or displays).
It consists of two distinct functions, a pixel transfer function and a
control interface. Multiple pixel channels can exist per one control channel.
This binding documentation is only for pixel links whose pixel sources are
display controllers.
The i.MX8qm/qxp Display Pixel Link is accessed via System Controller Unit(SCU)
firmware.
properties:
compatible:
enum:
- fsl,imx8qm-dc-pixel-link
- fsl,imx8qxp-dc-pixel-link
fsl,dc-id:
$ref: /schemas/types.yaml#/definitions/uint8
description: |
u8 value representing the display controller index that the pixel link
connects to.
fsl,dc-stream-id:
$ref: /schemas/types.yaml#/definitions/uint8
description: |
u8 value representing the display controller stream index that the pixel
link connects to.
enum: [0, 1]
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description: The pixel link input port node from upstream video source.
patternProperties:
"^port@[1-4]$":
$ref: /schemas/graph.yaml#/properties/port
description: The pixel link output port node to downstream bridge.
required:
- port@0
- port@1
- port@2
- port@3
- port@4
allOf:
- if:
properties:
compatible:
contains:
const: fsl,imx8qxp-dc-pixel-link
then:
properties:
fsl,dc-id:
const: 0
- if:
properties:
compatible:
contains:
const: fsl,imx8qm-dc-pixel-link
then:
properties:
fsl,dc-id:
enum: [0, 1]
required:
- compatible
- fsl,dc-id
- fsl,dc-stream-id
- ports
additionalProperties: false
examples:
- |
dc0-pixel-link0 {
compatible = "fsl,imx8qxp-dc-pixel-link";
fsl,dc-id = /bits/ 8 <0>;
fsl,dc-stream-id = /bits/ 8 <0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
/* from dc0 pixel combiner channel0 */
port@0 {
reg = <0>;
dc0_pixel_link0_dc0_pixel_combiner_ch0: endpoint {
remote-endpoint = <&dc0_pixel_combiner_ch0_dc0_pixel_link0>;
};
};
/* to PXL2DPIs in MIPI/LVDS combo subsystems */
port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
dc0_pixel_link0_mipi_lvds_0_pxl2dpi: endpoint@0 {
reg = <0>;
remote-endpoint = <&mipi_lvds_0_pxl2dpi_dc0_pixel_link0>;
};
dc0_pixel_link0_mipi_lvds_1_pxl2dpi: endpoint@1 {
reg = <1>;
remote-endpoint = <&mipi_lvds_1_pxl2dpi_dc0_pixel_link0>;
};
};
/* unused */
port@2 {
reg = <2>;
};
/* unused */
port@3 {
reg = <3>;
};
/* to imaging subsystem */
port@4 {
reg = <4>;
};
};
};

108
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml Normal file
View File

@ -0,0 +1,108 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pxl2dpi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale i.MX8qxp Pixel Link to Display Pixel Interface
maintainers:
- Liu Ying <victor.liu@nxp.com>
description: |
The Freescale i.MX8qxp Pixel Link to Display Pixel Interface(PXL2DPI)
interfaces the pixel link 36-bit data output and the DSI controller’s
MIPI-DPI 24-bit data input, and inputs of LVDS Display Bridge(LDB) module
used in LVDS mode, to remap the pixel color codings between those modules.
This module is purely combinatorial.
The i.MX8qxp PXL2DPI is controlled by Control and Status Registers(CSR) module.
The CSR module, as a system controller, contains the PXL2DPI's configuration
register.
properties:
compatible:
const: fsl,imx8qxp-pxl2dpi
fsl,sc-resource:
$ref: /schemas/types.yaml#/definitions/uint32
description: The SCU resource ID associated with this PXL2DPI instance.
power-domains:
maxItems: 1
fsl,companion-pxl2dpi:
$ref: /schemas/types.yaml#/definitions/phandle
description: |
A phandle which points to companion PXL2DPI which is used by downstream
LVDS Display Bridge(LDB) in split mode.
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description: The PXL2DPI input port node from pixel link.
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: The PXL2DPI output port node to downstream bridge.
required:
- port@0
- port@1
required:
- compatible
- fsl,sc-resource
- power-domains
- ports
additionalProperties: false
examples:
- |
#include <dt-bindings/firmware/imx/rsrc.h>
pxl2dpi {
compatible = "fsl,imx8qxp-pxl2dpi";
fsl,sc-resource = <IMX_SC_R_MIPI_0>;
power-domains = <&pd IMX_SC_R_MIPI_0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
mipi_lvds_0_pxl2dpi_dc_pixel_link0: endpoint@0 {
reg = <0>;
remote-endpoint = <&dc_pixel_link0_mipi_lvds_0_pxl2dpi>;
};
mipi_lvds_0_pxl2dpi_dc_pixel_link1: endpoint@1 {
reg = <1>;
remote-endpoint = <&dc_pixel_link1_mipi_lvds_0_pxl2dpi>;
};
};
port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0: endpoint@0 {
reg = <0>;
remote-endpoint = <&mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi>;
};
mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1: endpoint@1 {
reg = <1>;
remote-endpoint = <&mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi>;
};
};
};
};

106
Documentation/devicetree/bindings/display/bridge/fsl,ldb.yaml Normal file
View File

@ -0,0 +1,106 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/fsl,ldb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale i.MX8MP DPI to LVDS bridge chip
maintainers:
- Marek Vasut <marex@denx.de>
description: |
The i.MX8MP mediamix contains two registers which are responsible
for configuring the on-SoC DPI-to-LVDS serializer. This describes
those registers as bridge within the DT.
properties:
compatible:
const: fsl,imx8mp-ldb
clocks:
maxItems: 1
clock-names:
const: ldb
reg:
minItems: 2
maxItems: 2
reg-names:
items:
- const: ldb
- const: lvds
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description: Video port for DPI input.
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: Video port for LVDS Channel-A output (panel or bridge).
port@2:
$ref: /schemas/graph.yaml#/properties/port
description: Video port for LVDS Channel-B output (panel or bridge).
required:
- port@0
- port@1
required:
- compatible
- clocks
- ports
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/imx8mp-clock.h>
blk-ctrl {
#address-cells = <1>;
#size-cells = <1>;
bridge@5c {
compatible = "fsl,imx8mp-ldb";
clocks = <&clk IMX8MP_CLK_MEDIA_LDB>;
clock-names = "ldb";
reg = <0x5c 0x4>, <0x128 0x4>;
reg-names = "ldb", "lvds";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
ldb_from_lcdif2: endpoint {
remote-endpoint = <&lcdif2_to_ldb>;
};
};
port@1 {
reg = <1>;
ldb_lvds_ch0: endpoint {
remote-endpoint = <&ldb_to_lvdsx4panel>;
};
};
port@2 {
reg = <2>;
ldb_lvds_ch1: endpoint {
};
};
};
};
};

117
Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml Normal file
View File

@ -0,0 +1,117 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/lontium,lt9211.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Lontium LT9211 DSI/LVDS/DPI to DSI/LVDS/DPI bridge.
maintainers:
- Marek Vasut <marex@denx.de>
description: |
The LT9211 are bridge devices which convert Single/Dual-Link DSI/LVDS
or Single DPI to Single/Dual-Link DSI/LVDS or Single DPI.
properties:
compatible:
enum:
- lontium,lt9211
reg:
maxItems: 1
interrupts:
maxItems: 1
reset-gpios:
maxItems: 1
description: GPIO connected to active high RESET pin.
vccio-supply:
description: Regulator for 1.8V IO power.
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description:
Primary MIPI DSI port-1 for MIPI input or
LVDS port-1 for LVDS input or DPI input.
port@1:
$ref: /schemas/graph.yaml#/properties/port
description:
Additional MIPI port-2 for MIPI input or LVDS port-2
for LVDS input. Used in combination with primary
port-1 to drive higher resolution displays
port@2:
$ref: /schemas/graph.yaml#/properties/port
description:
Primary MIPI DSI port-1 for MIPI output or
LVDS port-1 for LVDS output or DPI output.
port@3:
$ref: /schemas/graph.yaml#/properties/port
description:
Additional MIPI port-2 for MIPI output or LVDS port-2
for LVDS output. Used in combination with primary
port-1 to drive higher resolution displays.
required:
- port@0
- port@2
required:
- compatible
- reg
- vccio-supply
- ports
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
hdmi-bridge@3b {
compatible = "lontium,lt9211";
reg = <0x3b>;
reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>;
interrupts-extended = <&tlmm 84 IRQ_TYPE_EDGE_FALLING>;
vccio-supply = <&lt9211_1v8>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
endpoint {
remote-endpoint = <&dsi0_out>;
};
};
port@2 {
reg = <2>;
endpoint {
remote-endpoint = <&panel_in_lvds>;
};
};
};
};
};
...

131
Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml Normal file
View File

@ -0,0 +1,131 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/sil,sii9022.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Silicon Image sii902x HDMI bridge
maintainers:
- Boris Brezillon <bbrezillon@kernel.org>
properties:
compatible:
oneOf:
- items:
- enum:
- sil,sii9022-cpi # CEC Programming Interface
- sil,sii9022-tpi # Transmitter Programming Interface
- const: sil,sii9022
- const: sil,sii9022
reg:
maxItems: 1
interrupts:
maxItems: 1
description: Interrupt line used to inform the host about hotplug events.
reset-gpios:
maxItems: 1
iovcc-supply:
description: I/O Supply Voltage (1.8V or 3.3V)
cvcc12-supply:
description: Digital Core Supply Voltage (1.2V)
'#sound-dai-cells':
enum: [ 0, 1 ]
description: |
<0> if only I2S or S/PDIF pin is wired,
<1> if both are wired.
HDMI audio is configured only if this property is found.
If HDMI audio is configured, the sii902x device becomes an I2S and/or
S/PDIF audio codec component (e.g. a digital audio sink), that can be
used in configuring full audio devices with simple-card or
audio-graph-card bindings. See their binding documents on how to describe
the way the
sii902x device is connected to the rest of the audio system:
Documentation/devicetree/bindings/sound/simple-card.yaml
Documentation/devicetree/bindings/sound/audio-graph-card.yaml
Note: In case of the audio-graph-card binding the used port index should
be 3.
sil,i2s-data-lanes:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 4
uniqueItems: true
items:
enum: [ 0, 1, 2, 3 ]
description:
Each integer indicates which I2S pin is connected to which audio FIFO.
The first integer selects the I2S audio pin for the first audio FIFO#0
(HDMI channels 1&2), the second for FIFO#1 (HDMI channels 3&4), and so
on. There are 4 FIFOs and 4 I2S pins (SD0 - SD3). Any I2S pin can be
connected to any FIFO, but there can be no gaps. E.g. an I2S pin must be
mapped to FIFO#0 and FIFO#1 before mapping a channel to FIFO#2. The
default value is <0>, describing SD0 pin being routed to HDMI audio
FIFO#0.
clocks:
maxItems: 1
description: MCLK input. MCLK can be used to produce HDMI audio CTS values.
clock-names:
const: mclk
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description: Parallel RGB input port
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: HDMI output port
port@3:
$ref: /schemas/graph.yaml#/properties/port
description: Sound input port
required:
- compatible
- reg
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
hdmi-bridge@39 {
compatible = "sil,sii9022";
reg = <0x39>;
reset-gpios = <&pioA 1 0>;
iovcc-supply = <&v3v3_hdmi>;
cvcc12-supply = <&v1v2_hdmi>;
#sound-dai-cells = <0>;
sil,i2s-data-lanes = < 0 1 2 >;
clocks = <&mclk>;
clock-names = "mclk";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
bridge_in: endpoint {
remote-endpoint = <&dc_out>;
};
};
};
};
};

117
Documentation/devicetree/bindings/display/bridge/ti,dlpc3433.yaml Normal file
View File

@ -0,0 +1,117 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/ti,dlpc3433.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI DLPC3433 MIPI DSI to DMD bridge
maintainers:
- Jagan Teki <jagan@amarulasolutions.com>
- Christopher Vollo <chris@renewoutreach.org>
description: |
TI DLPC3433 is a MIPI DSI based display controller bridge
for processing high resolution DMD based projectors.
It has a flexible configuration of MIPI DSI and DPI signal
input that produces a DMD output in RGB565, RGB666, RGB888
formats.
It supports upto 720p resolution with 60 and 120 Hz refresh
rates.
properties:
compatible:
const: ti,dlpc3433
reg:
enum:
- 0x1b
- 0x1d
enable-gpios:
description: PROJ_ON pin, chip powers up PROJ_ON is high.
vcc_intf-supply:
description: A 1.8V/3.3V supply that power the Host I/O.
vcc_flsh-supply:
description: A 1.8V/3.3V supply that power the Flash I/O.
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description: Video port for MIPI DSI input.
properties:
endpoint:
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
data-lanes:
description: array of physical DSI data lane indexes.
minItems: 1
items:
- const: 1
- const: 2
- const: 3
- const: 4
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: Video port for DMD output.
required:
- port@0
- port@1
required:
- compatible
- reg
- enable-gpios
- ports
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
i2c1 {
#address-cells = <1>;
#size-cells = <0>;
bridge@1b {
compatible = "ti,dlpc3433";
reg = <0x1b>;
enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
bridge_in_dsi: endpoint {
remote-endpoint = <&dsi_out_bridge>;
data-lanes = <1 2 3 4>;
};
};
port@1 {
reg = <1>;
bridge_out_panel: endpoint {
remote-endpoint = <&panel_out_bridge>;
};
};
};
};
};

116
Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml Normal file
View File

@ -0,0 +1,116 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/mediatek/mediatek,dsi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek DSI Controller Device Tree Bindings
maintainers:
- Chun-Kuang Hu <chunkuang.hu@kernel.org>
- Philipp Zabel <p.zabel@pengutronix.de>
- Jitao Shi <jitao.shi@mediatek.com>
- Xinlei Lee <xinlei.lee@mediatek.com>
description: |
The MediaTek DSI function block is a sink of the display subsystem and can
drive up to 4-lane MIPI DSI output. Two DSIs can be synchronized for dual-
channel output.
allOf:
- $ref: /schemas/display/dsi-controller.yaml#
properties:
compatible:
enum:
- mediatek,mt2701-dsi
- mediatek,mt7623-dsi
- mediatek,mt8167-dsi
- mediatek,mt8173-dsi
- mediatek,mt8183-dsi
- mediatek,mt8186-dsi
reg:
maxItems: 1
interrupts:
maxItems: 1
power-domains:
maxItems: 1
clocks:
items:
- description: Engine Clock
- description: Digital Clock
- description: HS Clock
clock-names:
items:
- const: engine
- const: digital
- const: hs
resets:
maxItems: 1
phys:
maxItems: 1
phy-names:
items:
- const: dphy
port:
$ref: /schemas/graph.yaml#/properties/port
description:
Output port node. This port should be connected to the input
port of an attached DSI panel or DSI-to-eDP encoder chip.
required:
- compatible
- reg
- interrupts
- power-domains
- clocks
- clock-names
- phys
- phy-names
- port
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/mt8183-clk.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/power/mt8183-power.h>
#include <dt-bindings/phy/phy.h>
#include <dt-bindings/reset/mt8183-resets.h>
soc {
#address-cells = <2>;
#size-cells = <2>;
dsi0: dsi@14014000 {
compatible = "mediatek,mt8183-dsi";
reg = <0 0x14014000 0 0x1000>;
interrupts = <GIC_SPI 236 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DSI0_MM>,
<&mmsys CLK_MM_DSI0_IF>,
<&mipi_tx0>;
clock-names = "engine", "digital", "hs";
resets = <&mmsys MT8183_MMSYS_SW0_RST_B_DISP_DSI0>;
phys = <&mipi_tx0>;
phy-names = "dphy";
port {
dsi0_out: endpoint {
remote-endpoint = <&panel_in>;
};
};
};
};
...

88
Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml Normal file
View File

@ -0,0 +1,88 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/mediatek/mediatek,mdp-rdma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek MDP RDMA
maintainers:
- Chun-Kuang Hu <chunkuang.hu@kernel.org>
- Philipp Zabel <p.zabel@pengutronix.de>
description:
The MediaTek MDP RDMA stands for Read Direct Memory Access.
It provides real time data to the back-end panel driver, such as DSI,
DPI and DP_INTF.
It contains one line buffer to store the sufficient pixel data.
RDMA device node must be siblings to the central MMSYS_CONFIG node.
For a description of the MMSYS_CONFIG binding, see
Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml for details.
properties:
compatible:
const: mediatek,mt8195-vdo1-rdma
reg:
maxItems: 1
interrupts:
maxItems: 1
power-domains:
maxItems: 1
clocks:
items:
- description: RDMA Clock
iommus:
maxItems: 1
mediatek,gce-client-reg:
description:
The register of display function block to be set by gce. There are 4 arguments,
such as gce node, subsys id, offset and register size. The subsys id that is
mapping to the register of display function blocks is defined in the gce header
include/dt-bindings/gce/<chip>-gce.h of each chips.
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
items:
- description: phandle of GCE
- description: GCE subsys id
- description: register offset
- description: register size
maxItems: 1
required:
- compatible
- reg
- power-domains
- clocks
- iommus
- mediatek,gce-client-reg
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/mt8195-clk.h>
#include <dt-bindings/power/mt8195-power.h>
#include <dt-bindings/gce/mt8195-gce.h>
#include <dt-bindings/memory/mt8195-memory-port.h>
soc {
#address-cells = <2>;
#size-cells = <2>;
rdma@1c104000 {
compatible = "mediatek,mt8195-vdo1-rdma";
reg = <0 0x1c104000 0 0x1000>;
interrupts = <GIC_SPI 495 IRQ_TYPE_LEVEL_HIGH 0>;
clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>;
power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>;
iommus = <&iommu_vdo M4U_PORT_L2_MDP_RDMA0>;
mediatek,gce-client-reg = <&gce0 SUBSYS_1c10XXXX 0x4000 0x1000>;
};
};

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