Merge branch 'for-6.5/apple' into for-linus

- improved support for Keychron K8 keyboard (Lasse Brun)
This commit is contained in:
Jiri Kosina 2023-06-27 22:37:24 +02:00
commit e80b500370
5838 changed files with 339017 additions and 252383 deletions

View File

@ -521,7 +521,6 @@ ForEachMacros:
- 'of_property_for_each_u32'
- 'pci_bus_for_each_resource'
- 'pci_dev_for_each_resource'
- 'pci_doe_for_each_off'
- 'pcl_for_each_chunk'
- 'pcl_for_each_segment'
- 'pcm_for_each_format'

View File

@ -213,7 +213,10 @@ Jeff Garzik <jgarzik@pretzel.yyz.us>
Jeff Layton <jlayton@kernel.org> <jlayton@poochiereds.net>
Jeff Layton <jlayton@kernel.org> <jlayton@primarydata.com>
Jeff Layton <jlayton@kernel.org> <jlayton@redhat.com>
Jens Axboe <axboe@suse.de>
Jens Axboe <axboe@kernel.dk> <axboe@suse.de>
Jens Axboe <axboe@kernel.dk> <jens.axboe@oracle.com>
Jens Axboe <axboe@kernel.dk> <axboe@fb.com>
Jens Axboe <axboe@kernel.dk> <axboe@meta.com>
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
Jernej Skrabec <jernej.skrabec@gmail.com> <jernej.skrabec@siol.net>
Jessica Zhang <quic_jesszhan@quicinc.com> <jesszhan@codeaurora.org>
@ -328,6 +331,7 @@ Maxime Ripard <mripard@kernel.org> <maxime.ripard@bootlin.com>
Maxime Ripard <mripard@kernel.org> <maxime.ripard@free-electrons.com>
Mayuresh Janorkar <mayur@ti.com>
Michael Buesch <m@bues.ch>
Michal Simek <michal.simek@amd.com> <michal.simek@xilinx.com>
Michel Dänzer <michel@tungstengraphics.com>
Michel Lespinasse <michel@lespinasse.org>
Michel Lespinasse <michel@lespinasse.org> <walken@google.com>
@ -360,6 +364,12 @@ Nicolas Pitre <nico@fluxnic.net> <nico@linaro.org>
Nicolas Saenz Julienne <nsaenz@kernel.org> <nsaenzjulienne@suse.de>
Nicolas Saenz Julienne <nsaenz@kernel.org> <nsaenzjulienne@suse.com>
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Nikolay Aleksandrov <razor@blackwall.org> <naleksan@redhat.com>
Nikolay Aleksandrov <razor@blackwall.org> <nikolay@redhat.com>
Nikolay Aleksandrov <razor@blackwall.org> <nikolay@cumulusnetworks.com>
Nikolay Aleksandrov <razor@blackwall.org> <nikolay@nvidia.com>
Nikolay Aleksandrov <razor@blackwall.org> <nikolay@isovalent.com>
Oleksandr Natalenko <oleksandr@natalenko.name> <oleksandr@redhat.com>
Oleksij Rempel <linux@rempel-privat.de> <bug-track@fisher-privat.net>
Oleksij Rempel <linux@rempel-privat.de> <external.Oleksij.Rempel@de.bosch.com>
Oleksij Rempel <linux@rempel-privat.de> <fixed-term.Oleksij.Rempel@de.bosch.com>
@ -375,6 +385,8 @@ Paul E. McKenney <paulmck@kernel.org> <paul.mckenney@linaro.org>
Paul E. McKenney <paulmck@kernel.org> <paulmck@linux.ibm.com>
Paul E. McKenney <paulmck@kernel.org> <paulmck@linux.vnet.ibm.com>
Paul E. McKenney <paulmck@kernel.org> <paulmck@us.ibm.com>
Paul Mackerras <paulus@ozlabs.org> <paulus@samba.org>
Paul Mackerras <paulus@ozlabs.org> <paulus@au1.ibm.com>
Peter A Jonsson <pj@ludd.ltu.se>
Peter Oruba <peter.oruba@amd.com>
Peter Oruba <peter@oruba.de>

13
CREDITS
View File

@ -1706,6 +1706,10 @@ S: Panoramastrasse 18
S: D-69126 Heidelberg
S: Germany
N: Neil Horman
M: nhorman@tuxdriver.com
D: SCTP protocol maintainer.
N: Simon Horman
M: horms@verge.net.au
D: Renesas ARM/ARM64 SoC maintainer
@ -2510,8 +2514,8 @@ D: XF86_8514
D: cfdisk (curses based disk partitioning program)
N: Mat Martineau
E: mat@martineau.name
D: MPTCP subsystem co-maintainer 2020-2023
E: martineau@kernel.org
D: MPTCP subsystem co-maintainer
D: Keyctl restricted keyring and Diffie-Hellman UAPI
D: Bluetooth L2CAP ERTM mode and AMP
S: USA
@ -3475,6 +3479,11 @@ D: several improvements to system programs
S: Oldenburg
S: Germany
N: Mathieu Poirier
E: mathieu.poirier@linaro.org
D: CoreSight kernel subsystem, Maintainer 2014-2022
D: Perf tool support for CoreSight
N: Robert Schwebel
E: robert@schwebel.de
W: https://www.schwebel.de

View File

@ -136,6 +136,22 @@ Description: The last executed device administrative command's status/error.
Also last configuration error overloaded.
Writing to it will clear the status.
What: /sys/bus/dsa/devices/dsa<m>/iaa_cap
Date: Sept 14, 2022
KernelVersion: 6.0.0
Contact: dmaengine@vger.kernel.org
Description: IAA (IAX) capability mask. Exported to user space for application
consumption. This attribute should only be visible on IAA devices
that are version 2 or later.
What: /sys/bus/dsa/devices/dsa<m>/event_log_size
Date: Sept 14, 2022
KernelVersion: 6.4.0
Contact: dmaengine@vger.kernel.org
Description: The event log size to be configured. Default is 64 entries and
occupies 4k size if the evl entry is 64 bytes. It's visible
only on platforms that support the capability.
What: /sys/bus/dsa/devices/wq<m>.<n>/block_on_fault
Date: Oct 27, 2020
KernelVersion: 5.11.0
@ -219,6 +235,16 @@ Contact: dmaengine@vger.kernel.org
Description: Indicate whether ATS disable is turned on for the workqueue.
0 indicates ATS is on, and 1 indicates ATS is off for the workqueue.
What: /sys/bus/dsa/devices/wq<m>.<n>/prs_disable
Date: Sept 14, 2022
KernelVersion: 6.4.0
Contact: dmaengine@vger.kernel.org
Description: Controls whether PRS disable is turned on for the workqueue.
0 indicates PRS is on, and 1 indicates PRS is off for the
workqueue. This option overrides block_on_fault attribute
if set. It's visible only on platforms that support the
capability.
What: /sys/bus/dsa/devices/wq<m>.<n>/occupancy
Date May 25, 2021
KernelVersion: 5.14.0
@ -302,3 +328,28 @@ Description: Allows control of the number of batch descriptors that can be
1 (1/2 of max value), 2 (1/4 of the max value), and 3 (1/8 of
the max value). It's visible only on platforms that support
the capability.
What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/cr_faults
Date: Sept 14, 2022
KernelVersion: 6.4.0
Contact: dmaengine@vger.kernel.org
Description: Show the number of Completion Record (CR) faults this application
has caused.
What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/cr_fault_failures
Date: Sept 14, 2022
KernelVersion: 6.4.0
Contact: dmaengine@vger.kernel.org
Description: Show the number of Completion Record (CR) faults failures that this
application has caused. The failure counter is incremented when the
driver cannot fault in the address for the CR. Typically this is caused
by a bad address programmed in the submitted descriptor or a malicious
submitter is using bad CR address on purpose.
What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/pid
Date: Sept 14, 2022
KernelVersion: 6.4.0
Contact: dmaengine@vger.kernel.org
Description: Show the process id of the application that opened the file. This is
helpful information for a monitor daemon that wants to kill the
application that opened the file.

View File

@ -76,7 +76,7 @@ Date: Dec 2014
KernelVersion: 4.0
Description: Default camera terminal descriptors
All attributes read only:
All attributes read only except bmControls, which is read/write:
======================== ====================================
bmControls bitmap specifying which controls are
@ -101,7 +101,7 @@ Date: Dec 2014
KernelVersion: 4.0
Description: Default processing unit descriptors
All attributes read only:
All attributes read only except bmControls, which is read/write:
=============== ========================================
iProcessing index of string descriptor

View File

@ -0,0 +1,35 @@
What: /sys/kernel/debug/cxl/memX/inject_poison
Date: April, 2023
KernelVersion: v6.4
Contact: linux-cxl@vger.kernel.org
Description:
(WO) When a Device Physical Address (DPA) is written to this
attribute, the memdev driver sends an inject poison command to
the device for the specified address. The DPA must be 64-byte
aligned and the length of the injected poison is 64-bytes. If
successful, the device returns poison when the address is
accessed through the CXL.mem bus. Injecting poison adds the
address to the device's Poison List and the error source is set
to Injected. In addition, the device adds a poison creation
event to its internal Informational Event log, updates the
Event Status register, and if configured, interrupts the host.
It is not an error to inject poison into an address that
already has poison present and no error is returned. The
inject_poison attribute is only visible for devices supporting
the capability.
What: /sys/kernel/debug/memX/clear_poison
Date: April, 2023
KernelVersion: v6.4
Contact: linux-cxl@vger.kernel.org
Description:
(WO) When a Device Physical Address (DPA) is written to this
attribute, the memdev driver sends a clear poison command to
the device for the specified address. Clearing poison removes
the address from the device's Poison List and writes 0 (zero)
for 64 bytes starting at address. It is not an error to clear
poison from an address that does not have poison set. If the
device cannot clear poison from the address, -ENXIO is returned.
The clear_poison attribute is only visible for devices
supporting the capability.

View File

@ -0,0 +1,56 @@
What: /sys/bus/cdx/rescan
Date: March 2023
Contact: nipun.gupta@amd.com
Description:
Writing y/1/on to this file will cause rescan of the bus
and devices on the CDX bus. Any new devices are scanned and
added to the list of Linux devices and any devices removed are
also deleted from Linux.
For example::
# echo 1 > /sys/bus/cdx/rescan
What: /sys/bus/cdx/devices/.../vendor
Date: March 2023
Contact: nipun.gupta@amd.com
Description:
Vendor ID for this CDX device, in hexadecimal. Vendor ID is
16 bit identifier which is specific to the device manufacturer.
Combination of Vendor ID and Device ID identifies a device.
What: /sys/bus/cdx/devices/.../device
Date: March 2023
Contact: nipun.gupta@amd.com
Description:
Device ID for this CDX device, in hexadecimal. Device ID is
16 bit identifier to identify a device type within the range
of a device manufacturer.
Combination of Vendor ID and Device ID identifies a device.
What: /sys/bus/cdx/devices/.../reset
Date: March 2023
Contact: nipun.gupta@amd.com
Description:
Writing y/1/on to this file resets the CDX device.
On resetting the device, the corresponding driver is notified
twice, once before the device is being reset, and again after
the reset has been complete.
For example::
# echo 1 > /sys/bus/cdx/.../reset
What: /sys/bus/cdx/devices/.../remove
Date: March 2023
Contact: tarak.reddy@amd.com
Description:
Writing y/1/on to this file removes the corresponding
device from the CDX bus. If the device is to be reconfigured
reconfigured in the Hardware, the device can be removed, so
that the device driver does not access the device while it is
being reconfigured.
For example::
# echo 1 > /sys/bus/cdx/devices/.../remove

View File

@ -1,3 +1,33 @@
What: /sys/bus/counter/devices/counterX/cascade_counts_enable
KernelVersion: 6.4
Contact: linux-iio@vger.kernel.org
Description:
Indicates the cascading of Counts on Counter X.
Valid attribute values are boolean.
What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select
KernelVersion: 6.4
Contact: linux-iio@vger.kernel.org
Description:
Selects the external clock pin for phase counting mode of
Counter X.
MTCLKA-MTCLKB:
MTCLKA and MTCLKB pins are selected for the external
phase clock.
MTCLKC-MTCLKD:
MTCLKC and MTCLKD pins are selected for the external
phase clock.
What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select_available
KernelVersion: 6.4
Contact: linux-iio@vger.kernel.org
Description:
Discrete set of available values for the respective device
configuration are listed in this file.
What: /sys/bus/counter/devices/counterX/countY/count
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
@ -215,6 +245,8 @@ Contact: linux-iio@vger.kernel.org
Description:
This attribute indicates the number of overflows of count Y.
What: /sys/bus/counter/devices/counterX/cascade_counts_enable_component_id
What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select_component_id
What: /sys/bus/counter/devices/counterX/countY/capture_component_id
What: /sys/bus/counter/devices/counterX/countY/ceiling_component_id
What: /sys/bus/counter/devices/counterX/countY/floor_component_id

View File

@ -415,3 +415,17 @@ Description:
1), and checks that the hardware accepts the commit request.
Reading this value indicates whether the region is committed or
not.
What: /sys/bus/cxl/devices/memX/trigger_poison_list
Date: April, 2023
KernelVersion: v6.4
Contact: linux-cxl@vger.kernel.org
Description:
(WO) When a boolean 'true' is written to this attribute the
memdev driver retrieves the poison list from the device. The
list consists of addresses that are poisoned, or would result
in poison if accessed, and the source of the poison. This
attribute is only visible for devices supporting the
capability. The retrieved errors are logged as kernel
events when cxl_poison event tracing is enabled.

View File

@ -1807,8 +1807,8 @@ What: /sys/bus/iio/devices/iio:deviceX/out_resistanceX_raw
KernelVersion: 4.3
Contact: linux-iio@vger.kernel.org
Description:
Raw (unscaled no offset etc.) resistance reading that can be processed
into an ohm value.
Raw (unscaled no offset etc.) resistance reading.
Units after application of scale and offset are ohms.
What: /sys/bus/iio/devices/iio:deviceX/heater_enable
KernelVersion: 4.1.0
@ -1894,8 +1894,9 @@ What: /sys/bus/iio/devices/iio:deviceX/in_electricalconductivity_raw
KernelVersion: 4.8
Contact: linux-iio@vger.kernel.org
Description:
Raw (unscaled no offset etc.) electric conductivity reading that
can be processed to siemens per meter.
Raw (unscaled no offset etc.) electric conductivity reading.
Units after application of scale and offset are siemens per
meter.
What: /sys/bus/iio/devices/iio:deviceX/in_countY_raw
KernelVersion: 4.10
@ -1951,8 +1952,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_phaseY_raw
KernelVersion: 4.18
Contact: linux-iio@vger.kernel.org
Description:
Raw (unscaled) phase difference reading from channel Y
that can be processed to radians.
Raw (unscaled) phase difference reading from channel Y.
Units after application of scale and offset are radians.
What: /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm1_input
What: /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm1_input

View File

@ -23,3 +23,55 @@ Description:
Reading this attribute gives the state of the DbC. It
can be one of the following states: disabled, enabled,
initialized, connected, configured and stalled.
What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_idVendor
Date: March 2023
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
Description:
This dbc_idVendor attribute lets us change the idVendor field
presented in the USB device descriptor by this xhci debug
device.
Value can only be changed while debug capability (DbC) is in
disabled state to prevent USB device descriptor change while
connected to a USB host.
The default value is 0x1d6b (Linux Foundation).
It can be any 16-bit integer.
What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_idProduct
Date: March 2023
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
Description:
This dbc_idProduct attribute lets us change the idProduct field
presented in the USB device descriptor by this xhci debug
device.
Value can only be changed while debug capability (DbC) is in
disabled state to prevent USB device descriptor change while
connected to a USB host.
The default value is 0x0010. It can be any 16-bit integer.
What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_bcdDevice
Date: March 2023
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
Description:
This dbc_bcdDevice attribute lets us change the bcdDevice field
presented in the USB device descriptor by this xhci debug
device.
Value can only be changed while debug capability (DbC) is in
disabled state to prevent USB device descriptor change while
connected to a USB host.
The default value is 0x0010. (device rev 0.10)
It can be any 16-bit integer.
What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_bInterfaceProtocol
Date: March 2023
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
Description:
This attribute lets us change the bInterfaceProtocol field
presented in the USB Interface descriptor by the xhci debug
device.
Value can only be changed while debug capability (DbC) is in
disabled state to prevent USB descriptor change while
connected to a USB host.
The default value is 1 (GNU Remote Debug command).
Other permissible value is 0 which is for vendor defined debug
target.

View File

@ -234,8 +234,8 @@ Description:
For details, see section `5.10 RAS Internal Error Register Definitions,
Altra Family Soc BMC Interface Specification`.
What: /sys/bus/platform/devices/smpro-errmon.*/event_[vrd_warn_fault|vrd_hot|dimm_hot]
KernelVersion: 6.1
What: /sys/bus/platform/devices/smpro-errmon.*/event_[vrd_warn_fault|vrd_hot|dimm_hot|dimm_2x_refresh]
KernelVersion: 6.1 (event_[vrd_warn_fault|vrd_hot|dimm_hot]), 6.4 (event_dimm_2x_refresh)
Contact: Quan Nguyen <quan@os.amperecomputing.com>
Description:
(RO) Contains the detail information in case of VRD/DIMM warning/hot events
@ -258,8 +258,21 @@ Description:
+---------------+---------------------------------------------------------------+---------------------+
| DIMM HOT | /sys/bus/platform/devices/smpro-errmon.*/event_dimm_hot | DIMM Hot |
+---------------+---------------------------------------------------------------+---------------------+
| DIMM 2X | /sys/bus/platform/devices/smpro-errmon.*/event_dimm_2x_refresh| DIMM 2x refresh rate|
| REFRESH RATE | | event in high temp |
+---------------+---------------------------------------------------------------+---------------------+
For more details, see section `5.7 GPI Status Registers,
For more details, see section `5.7 GPI Status Registers and 5.9 Memory Error Register Definitions,
Altra Family Soc BMC Interface Specification`.
What: /sys/bus/platform/devices/smpro-errmon.*/event_dimm[0-15]_syndrome
KernelVersion: 6.4
Contact: Quan Nguyen <quan@os.amperecomputing.com>
Description:
(RO) The sysfs returns the 2-byte DIMM failure syndrome data for slot
0-15 if it failed to initialize.
For more details, see section `5.11 Boot Stage Register Definitions,
Altra Family Soc BMC Interface Specification`.
What: /sys/bus/platform/devices/smpro-misc.*/boot_progress

View File

@ -21,4 +21,9 @@ Description:
at the time the kernel starts are not affected or limited in
any way by sync_state() callbacks.
Writing "1" to this file will force a call to the device's
sync_state() function if it hasn't been called already. The
sync_state() call happens independent of the state of the
consumer devices.

View File

@ -0,0 +1,73 @@
What: /sys/bus/platform/drivers/zynqmp_fpga_manager/firmware:zynqmp-firmware:pcap/status
Date: February 2023
KernelVersion: 6.4
Contact: Nava kishore Manne <nava.kishore.manne@amd.com>
Description: (RO) Read fpga status.
Read returns a hexadecimal value that tells the current status
of the FPGA device. Each bit position in the status value is
described Below(see ug570 chapter 9).
https://docs.xilinx.com/v/u/en-US/ug570-ultrascale-configuration
====================== ==============================================
BIT(0) 0: No CRC error
1: CRC error
BIT(1) 0: Decryptor security not set
1: Decryptor security set
BIT(2) 0: MMCMs/PLLs are not locked
1: MMCMs/PLLs are locked
BIT(3) 0: DCI not matched
1: DCI matched
BIT(4) 0: Start-up sequence has not finished
1: Start-up sequence has finished
BIT(5) 0: All I/Os are placed in High-Z state
1: All I/Os behave as configured
BIT(6) 0: Flip-flops and block RAM are write disabled
1: Flip-flops and block RAM are write enabled
BIT(7) 0: GHIGH_B_STATUS asserted
1: GHIGH_B_STATUS deasserted
BIT(8) to BIT(10) Status of the mode pins
BIT(11) 0: Initialization has not finished
1: Initialization finished
BIT(12) Value on INIT_B_PIN pin
BIT(13) 0: Signal not released
1: Signal released
BIT(14) Value on DONE_PIN pin.
BIT(15) 0: No IDCODE_ERROR
1: IDCODE_ERROR
BIT(16) 0: No SECURITY_ERROR
1: SECURITY_ERROR
BIT(17) System Monitor over-temperature if set
BIT(18) to BIT(20) Start-up state machine (0 to 7)
Phase 0 = 000
Phase 1 = 001
Phase 2 = 011
Phase 3 = 010
Phase 4 = 110
Phase 5 = 111
Phase 6 = 101
Phase 7 = 100
BIT(25) to BIT(26) Indicates the detected bus width
00 = x1
01 = x8
10 = x16
11 = x32
====================== ==============================================
The other bits are reserved.

View File

@ -53,7 +53,6 @@ Description: /sys/kernel/iommu_groups/<grp_id>/type shows the type of default
The default domain type of a group may be modified only when
- The group has only one device.
- The device in the group is not bound to any device driver.
So, the users must unbind the appropriate driver before
changing the default domain type.

View File

@ -51,3 +51,11 @@ Description: Control merging pages across different NUMA nodes.
When it is set to 0 only pages from the same node are merged,
otherwise pages from all nodes can be merged together (default).
What: /sys/kernel/mm/ksm/general_profit
Date: April 2023
KernelVersion: 6.4
Contact: Linux memory management mailing list <linux-mm@kvack.org>
Description: Measure how effective KSM is.
general_profit: how effective is KSM. The formula for the
calculation is in Documentation/admin-guide/mm/ksm.rst.

View File

@ -16,6 +16,7 @@ d) memory reclaim
e) thrashing
f) direct compact
g) write-protect copy
h) IRQ/SOFTIRQ
and makes these statistics available to userspace through
the taskstats interface.
@ -49,7 +50,7 @@ this structure. See
for a description of the fields pertaining to delay accounting.
It will generally be in the form of counters returning the cumulative
delay seen for cpu, sync block I/O, swapin, memory reclaim, thrash page
cache, direct compact, write-protect copy etc.
cache, direct compact, write-protect copy, IRQ/SOFTIRQ etc.
Taking the difference of two successive readings of a given
counter (say cpu_delay_total) for a task will give the delay
@ -109,17 +110,19 @@ Get sum of delays, since system boot, for all pids with tgid 5::
CPU count real total virtual total delay total delay average
8 7000000 6872122 3382277 0.423ms
IO count delay total delay average
0 0 0ms
0 0 0.000ms
SWAP count delay total delay average
0 0 0ms
0 0 0.000ms
RECLAIM count delay total delay average
0 0 0ms
0 0 0.000ms
THRASHING count delay total delay average
0 0 0ms
0 0 0.000ms
COMPACT count delay total delay average
0 0 0ms
WPCOPY count delay total delay average
0 0 0ms
0 0 0.000ms
WPCOPY count delay total delay average
0 0 0.000ms
IRQ count delay total delay average
0 0 0.000ms
Get IO accounting for pid 1, it works only with -p::

View File

@ -105,6 +105,10 @@ prevent overly frequent polling. Max limit is chosen as a high enough number
after which monitors are most likely not needed and psi averages can be used
instead.
Unprivileged users can also create monitors, with the only limitation that the
window size must be a multiple of 2s, in order to prevent excessive resource
usage.
When activated, psi monitor stays active for at least the duration of one
tracking window to avoid repeated activations/deactivations when system is
bouncing in and out of the stall state.

View File

@ -14,7 +14,7 @@ to borrow disk space from another computer.
Unlike NFS, it is possible to put any filesystem on it, etc.
For more information, or to download the nbd-client and nbd-server
tools, go to http://nbd.sf.net/.
tools, go to https://github.com/NetworkBlockDevice/nbd.
The nbd kernel module need only be installed on the client
system, as the nbd-server is completely in userspace. In fact,

View File

@ -719,7 +719,7 @@ There are ways to query or modify cpusets:
cat, rmdir commands from the shell, or their equivalent from C.
- via the C library libcpuset.
- via the C library libcgroup.
(http://sourceforge.net/projects/libcg/)
(https://github.com/libcgroup/libcgroup/)
- via the python application cset.
(http://code.google.com/p/cpuset/)

View File

@ -5,5 +5,5 @@ Changes
See https://wiki.samba.org/index.php/LinuxCIFSKernel for summary
information about fixes/improvements to CIFS/SMB2/SMB3 support (changes
to cifs.ko module) by kernel version (and cifs internal module version).
This may be easier to read than parsing the output of "git log fs/cifs"
by release.
This may be easier to read than parsing the output of
"git log fs/smb/client" by release.

View File

@ -45,7 +45,7 @@ Installation instructions
If you have built the CIFS vfs as module (successfully) simply
type ``make modules_install`` (or if you prefer, manually copy the file to
the modules directory e.g. /lib/modules/2.4.10-4GB/kernel/fs/cifs/cifs.ko).
the modules directory e.g. /lib/modules/6.3.0-060300-generic/kernel/fs/smb/client/cifs.ko).
If you have built the CIFS vfs into the kernel itself, follow the instructions
for your distribution on how to install a new kernel (usually you
@ -66,15 +66,15 @@ If cifs is built as a module, then the size and number of network buffers
and maximum number of simultaneous requests to one server can be configured.
Changing these from their defaults is not recommended. By executing modinfo::
modinfo kernel/fs/cifs/cifs.ko
modinfo <path to cifs.ko>
on kernel/fs/cifs/cifs.ko the list of configuration changes that can be made
on kernel/fs/smb/client/cifs.ko the list of configuration changes that can be made
at module initialization time (by running insmod cifs.ko) can be seen.
Recommendations
===============
To improve security the SMB2.1 dialect or later (usually will get SMB3) is now
To improve security the SMB2.1 dialect or later (usually will get SMB3.1.1) is now
the new default. To use old dialects (e.g. to mount Windows XP) use "vers=1.0"
on mount (or vers=2.0 for Windows Vista). Note that the CIFS (vers=1.0) is
much older and less secure than the default dialect SMB3 which includes

View File

@ -172,7 +172,7 @@ variables.
Offset of the free_list's member. This value is used to compute the number
of free pages.
Each zone has a free_area structure array called free_area[MAX_ORDER].
Each zone has a free_area structure array called free_area[MAX_ORDER + 1].
The free_list represents a linked list of free page blocks.
(list_head, next|prev)
@ -189,8 +189,8 @@ Offsets of the vmap_area's members. They carry vmalloc-specific
information. Makedumpfile gets the start address of the vmalloc region
from this.
(zone.free_area, MAX_ORDER)
---------------------------
(zone.free_area, MAX_ORDER + 1)
-------------------------------
Free areas descriptor. User-space tools use this value to iterate the
free_area ranges. MAX_ORDER is used by the zone buddy allocator.

View File

@ -912,15 +912,14 @@
cs89x0_media= [HW,NET]
Format: { rj45 | aui | bnc }
csdlock_debug= [KNL] Enable debug add-ons of cross-CPU function call
handling. When switched on, additional debug data is
printed to the console in case a hanging CPU is
detected, and that CPU is pinged again in order to try
to resolve the hang situation.
0: disable csdlock debugging (default)
1: enable basic csdlock debugging (minor impact)
ext: enable extended csdlock debugging (more impact,
but more data)
csdlock_debug= [KNL] Enable or disable debug add-ons of cross-CPU
function call handling. When switched on,
additional debug data is printed to the console
in case a hanging CPU is detected, and that
CPU is pinged again in order to try to resolve
the hang situation. The default value of this
option depends on the CSD_LOCK_WAIT_DEBUG_DEFAULT
Kconfig option.
dasd= [HW,NET]
See header of drivers/s390/block/dasd_devmap.c.
@ -1602,6 +1601,20 @@
dependencies. This only applies for fw_devlink=on|rpm.
Format: <bool>
fw_devlink.sync_state =
[KNL] When all devices that could probe have finished
probing, this parameter controls what to do with
devices that haven't yet received their sync_state()
calls.
Format: { strict | timeout }
strict -- Default. Continue waiting on consumers to
probe successfully.
timeout -- Give up waiting on consumers and call
sync_state() on any devices that haven't yet
received their sync_state() calls after
deferred_probe_timeout has expired or by
late_initcall() if !CONFIG_MODULES.
gamecon.map[2|3]=
[HW,JOY] Multisystem joystick and NES/SNES/PSX pad
support via parallel port (up to 5 devices per port)
@ -3349,6 +3362,12 @@
specified, <module>.async_probe takes precedence for
the specific module.
module.enable_dups_trace
[KNL] When CONFIG_MODULE_DEBUG_AUTOLOAD_DUPS is set,
this means that duplicate request_module() calls will
trigger a WARN_ON() instead of a pr_warn(). Note that
if MODULE_DEBUG_AUTOLOAD_DUPS_TRACE is set, WARN_ON()s
will always be issued and this option does nothing.
module.sig_enforce
[KNL] When CONFIG_MODULE_SIG is set, this means that
modules without (valid) signatures will fail to load.
@ -3593,7 +3612,10 @@
emulation library even if a 387 maths coprocessor
is present.
no5lvl [X86-64] Disable 5-level paging mode. Forces
no4lvl [RISCV] Disable 4-level and 5-level paging modes. Forces
kernel to use 3-level paging instead.
no5lvl [X86-64,RISCV] Disable 5-level paging mode. Forces
kernel to use 4-level paging instead.
noaliencache [MM, NUMA, SLAB] Disables the allocation of alien
@ -3992,7 +4014,7 @@
[KNL] Minimal page reporting order
Format: <integer>
Adjust the minimal page reporting order. The page
reporting is disabled when it exceeds (MAX_ORDER-1).
reporting is disabled when it exceeds MAX_ORDER.
panic= [KNL] Kernel behaviour on panic: delay <timeout>
timeout > 0: seconds before rebooting
@ -6150,15 +6172,6 @@
later by a loaded module cannot be set this way.
Example: sysctl.vm.swappiness=40
sysfs.deprecated=0|1 [KNL]
Enable/disable old style sysfs layout for old udev
on older distributions. When this option is enabled
very new udev will not work anymore. When this option
is disabled (or CONFIG_SYSFS_DEPRECATED not compiled)
in older udev will not work anymore.
Default depends on CONFIG_SYSFS_DEPRECATED_V2 set in
the kernel configuration.
sysrq_always_enabled
[KNL]
Ignore sysrq setting - this boot parameter will

View File

@ -20,7 +20,7 @@ content which can be replaced by a single write-protected page (which
is automatically copied if a process later wants to update its
content). The amount of pages that KSM daemon scans in a single pass
and the time between the passes are configured using :ref:`sysfs
intraface <ksm_sysfs>`
interface <ksm_sysfs>`
KSM only merges anonymous (private) pages, never pagecache (file) pages.
KSM's merged pages were originally locked into kernel memory, but can now
@ -157,6 +157,8 @@ stable_node_chains_prune_millisecs
The effectiveness of KSM and MADV_MERGEABLE is shown in ``/sys/kernel/mm/ksm/``:
general_profit
how effective is KSM. The calculation is explained below.
pages_shared
how many shared pages are being used
pages_sharing
@ -207,7 +209,8 @@ several times, which are unprofitable memory consumed.
ksm_rmap_items * sizeof(rmap_item).
where ksm_merging_pages is shown under the directory ``/proc/<pid>/``,
and ksm_rmap_items is shown in ``/proc/<pid>/ksm_stat``.
and ksm_rmap_items is shown in ``/proc/<pid>/ksm_stat``. The process profit
is also shown in ``/proc/<pid>/ksm_stat`` as ksm_process_profit.
From the perspective of application, a high ratio of ``ksm_rmap_items`` to
``ksm_merging_pages`` means a bad madvise-applied policy, so developers or

View File

@ -219,6 +219,31 @@ former will have ``UFFD_PAGEFAULT_FLAG_WP`` set, the latter
you still need to supply a page when ``UFFDIO_REGISTER_MODE_MISSING`` was
used.
Userfaultfd write-protect mode currently behave differently on none ptes
(when e.g. page is missing) over different types of memories.
For anonymous memory, ``ioctl(UFFDIO_WRITEPROTECT)`` will ignore none ptes
(e.g. when pages are missing and not populated). For file-backed memories
like shmem and hugetlbfs, none ptes will be write protected just like a
present pte. In other words, there will be a userfaultfd write fault
message generated when writing to a missing page on file typed memories,
as long as the page range was write-protected before. Such a message will
not be generated on anonymous memories by default.
If the application wants to be able to write protect none ptes on anonymous
memory, one can pre-populate the memory with e.g. MADV_POPULATE_READ. On
newer kernels, one can also detect the feature UFFD_FEATURE_WP_UNPOPULATED
and set the feature bit in advance to make sure none ptes will also be
write protected even upon anonymous memory.
When using ``UFFDIO_REGISTER_MODE_WP`` in combination with either
``UFFDIO_REGISTER_MODE_MISSING`` or ``UFFDIO_REGISTER_MODE_MINOR``, when
resolving missing / minor faults with ``UFFDIO_COPY`` or ``UFFDIO_CONTINUE``
respectively, it may be desirable for the new page / mapping to be
write-protected (so future writes will also result in a WP fault). These ioctls
support a mode flag (``UFFDIO_COPY_MODE_WP`` or ``UFFDIO_CONTINUE_MODE_WP``
respectively) to configure the mapping this way.
QEMU/KVM
========

View File

@ -215,12 +215,14 @@ again.
reduce the compile time enormously, especially if you are running an
universal kernel from a commodity Linux distribution.
There is a catch: the make target 'localmodconfig' will disable kernel
features you have not directly or indirectly through some program utilized
since you booted the system. You can reduce or nearly eliminate that risk by
using tricks outlined in the reference section; for quick testing purposes
that risk is often negligible, but it is an aspect you want to keep in mind
in case your kernel behaves oddly.
There is a catch: 'localmodconfig' is likely to disable kernel features you
did not use since you booted your Linux -- like drivers for currently
disconnected peripherals or a virtualization software not haven't used yet.
You can reduce or nearly eliminate that risk with tricks the reference
section outlines; but when building a kernel just for quick testing purposes
it is often negligible if such features are missing. But you should keep that
aspect in mind when using a kernel built with this make target, as it might
be the reason why something you only use occasionally stopped working.
[:ref:`details<configuration>`]
@ -271,6 +273,9 @@ again.
does nothing at all; in that case you have to manually install your kernel,
as outlined in the reference section.
If you are running a immutable Linux distribution, check its documentation
and the web to find out how to install your own kernel there.
[:ref:`details<install>`]
.. _another_sbs:
@ -291,29 +296,29 @@ again.
version you care about, as git otherwise might retrieve the entire commit
history::
git fetch --shallow-exclude=v6.1 origin
git fetch --shallow-exclude=v6.0 origin
If you modified the sources (for example by applying a patch), you now need
to discard those modifications; that's because git otherwise will not be able
to switch to the sources of another version due to potential conflicting
changes::
Now switch to the version you are interested in -- but be aware the command
used here will discard any modifications you performed, as they would
conflict with the sources you want to checkout::
git reset --hard
Now checkout the version you are interested in, as explained above::
git checkout --detach origin/master
git checkout --force --detach origin/master
At this point you might want to patch the sources again or set/modify a build
tag, as explained earlier; afterwards adjust the build configuration to the
new codebase and build your next kernel::
tag, as explained earlier. Afterwards adjust the build configuration to the
new codebase using olddefconfig, which will now adjust the configuration file
you prepared earlier using localmodconfig (~/linux/.config) for your next
kernel::
# reminder: if you want to apply patches, do it at this point
# reminder: you might want to update your build tag at this point
make olddefconfig
Now build your kernel::
make -j $(nproc --all)
Install the kernel as outlined above::
Afterwards install the kernel as outlined above::
command -v installkernel && sudo make modules_install install
@ -584,11 +589,11 @@ versions and individual commits at hand at any time::
curl -L \
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/clone.bundle \
-o linux-stable.git.bundle
git clone clone.bundle ~/linux/
git clone linux-stable.git.bundle ~/linux/
rm linux-stable.git.bundle
cd ~/linux/
git remote set-url origin
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
git remote set-url origin \
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
git fetch origin
git checkout --detach origin/master

View File

@ -33,8 +33,11 @@ The format of this option is::
9600n8. The maximum baudrate is 115200.
You can specify multiple console= options on the kernel command line.
Output will appear on all of them. The last device will be used when
you open ``/dev/console``. So, for example::
The behavior is well defined when each device type is mentioned only once.
In this case, the output will appear on all requested consoles. And
the last device will be used when you open ``/dev/console``.
So, for example::
console=ttyS1,9600 console=tty0
@ -42,7 +45,34 @@ defines that opening ``/dev/console`` will get you the current foreground
virtual console, and kernel messages will appear on both the VGA
console and the 2nd serial port (ttyS1 or COM2) at 9600 baud.
Note that you can only define one console per device type (serial, video).
The behavior is more complicated when the same device type is defined more
times. In this case, there are the following two rules:
1. The output will appear only on the first device of each defined type.
2. ``/dev/console`` will be associated with the first registered device.
Where the registration order depends on how kernel initializes various
subsystems.
This rule is used also when the last console= parameter is not used
for other reasons. For example, because of a typo or because
the hardware is not available.
The result might be surprising. For example, the following two command
lines have the same result:
console=ttyS1,9600 console=tty0 console=tty1
console=tty0 console=ttyS1,9600 console=tty1
The kernel messages are printed only on ``tty0`` and ``ttyS1``. And
``/dev/console`` gets associated with ``tty0``. It is because kernel
tries to register graphical consoles before serial ones. It does it
because of the default behavior when no console device is specified,
see below.
Note that the last ``console=tty1`` parameter still makes a difference.
The kernel command line is used also by systemd. It would use the last
defined ``tty1`` as the login console.
If no console device is specified, the first device found capable of
acting as a system console will be used. At this time, the system

View File

@ -236,13 +236,14 @@ the dates listed above.
Deprecated Mount Options
========================
=========================== ================
============================ ================
Name Removal Schedule
=========================== ================
============================ ================
Mounting with V4 filesystem September 2030
Mounting ascii-ci filesystem September 2030
ikeep/noikeep September 2025
attr2/noattr2 September 2025
=========================== ================
============================ ================
Removed Mount Options

View File

@ -12,7 +12,7 @@ Most of the text from Keith Owens, hacked by AK
x86_64 page size (PAGE_SIZE) is 4K.
Like all other architectures, x86_64 has a kernel stack for every
active thread. These thread stacks are THREAD_SIZE (2*PAGE_SIZE) big.
active thread. These thread stacks are THREAD_SIZE (4*PAGE_SIZE) big.
These stacks contain useful data as long as a thread is alive or a
zombie. While the thread is in user space the kernel stack is empty
except for the thread_info structure at the bottom.

View File

@ -107,7 +107,7 @@ process share the same page tables, thus the same MSR value.
PASID Life Cycle Management
===========================
PASID is initialized as INVALID_IOASID (-1) when a process is created.
PASID is initialized as IOMMU_PASID_INVALID (-1) when a process is created.
Only processes that access SVA-capable devices need to have a PASID
allocated. This allocation happens when a process opens/binds an SVA-capable

View File

@ -11,6 +11,22 @@ are enabled by XCR0 as well, but the first use of related instruction is
trapped by the kernel because by default the required large XSTATE buffers
are not allocated automatically.
The purpose for dynamic features
--------------------------------
Legacy userspace libraries often have hard-coded, static sizes for
alternate signal stacks, often using MINSIGSTKSZ which is typically 2KB.
That stack must be able to store at *least* the signal frame that the
kernel sets up before jumping into the signal handler. That signal frame
must include an XSAVE buffer defined by the CPU.
However, that means that the size of signal stacks is dynamic, not static,
because different CPUs have differently-sized XSAVE buffers. A compiled-in
size of 2KB with existing applications is too small for new CPU features
like AMX. Instead of universally requiring larger stack, with the dynamic
enabling, the kernel can enforce userspace applications to have
properly-sized altstacks.
Using dynamically enabled XSTATE features in user space applications
--------------------------------------------------------------------
@ -64,6 +80,61 @@ the handler allocates a larger xstate buffer for the task so the large
state can be context switched. In the unlikely cases that the allocation
fails, the kernel sends SIGSEGV.
AMX TILE_DATA enabling example
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Below is the example of how userspace applications enable
TILE_DATA dynamically:
1. The application first needs to query the kernel for AMX
support::
#include <asm/prctl.h>
#include <sys/syscall.h>
#include <stdio.h>
#include <unistd.h>
#ifndef ARCH_GET_XCOMP_SUPP
#define ARCH_GET_XCOMP_SUPP 0x1021
#endif
#ifndef ARCH_XCOMP_TILECFG
#define ARCH_XCOMP_TILECFG 17
#endif
#ifndef ARCH_XCOMP_TILEDATA
#define ARCH_XCOMP_TILEDATA 18
#endif
#define MASK_XCOMP_TILE ((1 << ARCH_XCOMP_TILECFG) | \
(1 << ARCH_XCOMP_TILEDATA))
unsigned long features;
long rc;
...
rc = syscall(SYS_arch_prctl, ARCH_GET_XCOMP_SUPP, &features);
if (!rc && (features & MASK_XCOMP_TILE) == MASK_XCOMP_TILE)
printf("AMX is available.\n");
2. After that, determining support for AMX, an application must
explicitly ask permission to use it::
#ifndef ARCH_REQ_XCOMP_PERM
#define ARCH_REQ_XCOMP_PERM 0x1023
#endif
...
rc = syscall(SYS_arch_prctl, ARCH_REQ_XCOMP_PERM, ARCH_XCOMP_TILEDATA);
if (!rc)
printf("AMX is ready for use.\n");
Note this example does not include the sigaltstack preparation.
Dynamic features in signal frames
---------------------------------
@ -72,3 +143,32 @@ entry if the feature is in its initial configuration. This differs from
non-dynamic features which are always written regardless of their
configuration. Signal handlers can examine the XSAVE buffer's XSTATE_BV
field to determine if a features was written.
Dynamic features for virtual machines
-------------------------------------
The permission for the guest state component needs to be managed separately
from the host, as they are exclusive to each other. A coupled of options
are extended to control the guest permission:
-ARCH_GET_XCOMP_GUEST_PERM
arch_prctl(ARCH_GET_XCOMP_GUEST_PERM, &features);
ARCH_GET_XCOMP_GUEST_PERM is a variant of ARCH_GET_XCOMP_PERM. So it
provides the same semantics and functionality but for the guest
components.
-ARCH_REQ_XCOMP_GUEST_PERM
arch_prctl(ARCH_REQ_XCOMP_GUEST_PERM, feature_nr);
ARCH_REQ_XCOMP_GUEST_PERM is a variant of ARCH_REQ_XCOMP_PERM. It has the
same semantics for the guest permission. While providing a similar
functionality, this comes with a constraint. Permission is frozen when the
first VCPU is created. Any attempt to change permission after that point
is going to be rejected. So, the permission has to be requested before the
first VCPU creation.
Note that some VMMs may have already established a set of supported state
components. These options are not presumed to support any particular VMM.

View File

@ -18,7 +18,6 @@ Block
kyber-iosched
null_blk
pr
request
stat
switching-sched
writeback_cache_control

View File

@ -1,99 +0,0 @@
============================
struct request documentation
============================
Jens Axboe <jens.axboe@oracle.com> 27/05/02
.. FIXME:
No idea about what does mean - seems just some noise, so comment it
1.0
Index
2.0 Struct request members classification
2.1 struct request members explanation
3.0
2.0
Short explanation of request members
====================================
Classification flags:
= ====================
D driver member
B block layer member
I I/O scheduler member
= ====================
Unless an entry contains a D classification, a device driver must not access
this member. Some members may contain D classifications, but should only be
access through certain macros or functions (eg ->flags).
<linux/blkdev.h>
=============================== ======= =======================================
Member Flag Comment
=============================== ======= =======================================
struct list_head queuelist BI Organization on various internal
queues
``void *elevator_private`` I I/O scheduler private data
unsigned char cmd[16] D Driver can use this for setting up
a cdb before execution, see
blk_queue_prep_rq
unsigned long flags DBI Contains info about data direction,
request type, etc.
int rq_status D Request status bits
kdev_t rq_dev DBI Target device
int errors DB Error counts
sector_t sector DBI Target location
unsigned long hard_nr_sectors B Used to keep sector sane
unsigned long nr_sectors DBI Total number of sectors in request
unsigned long hard_nr_sectors B Used to keep nr_sectors sane
unsigned short nr_phys_segments DB Number of physical scatter gather
segments in a request
unsigned short nr_hw_segments DB Number of hardware scatter gather
segments in a request
unsigned int current_nr_sectors DB Number of sectors in first segment
of request
unsigned int hard_cur_sectors B Used to keep current_nr_sectors sane
int tag DB TCQ tag, if assigned
``void *special`` D Free to be used by driver
``char *buffer`` D Map of first segment, also see
section on bouncing SECTION
``struct completion *waiting`` D Can be used by driver to get signalled
on request completion
``struct bio *bio`` DBI First bio in request
``struct bio *biotail`` DBI Last bio in request
``struct request_queue *q`` DB Request queue this request belongs to
``struct request_list *rl`` B Request list this request came from
=============================== ======= =======================================

View File

@ -18,7 +18,7 @@ LSM hook:
.. c:function:: int file_mprotect(struct vm_area_struct *vma, unsigned long reqprot, unsigned long prot);
Other LSM hooks which can be instrumented can be found in
``include/linux/lsm_hooks.h``.
``security/security.c``.
eBPF programs that use Documentation/bpf/btf.rst do not need to include kernel
headers for accessing information from the attached eBPF program's context.

View File

@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
=====
cdrom
=====
======
CD-ROM
======
.. toctree::
:maxdepth: 1

View File

@ -220,12 +220,30 @@ relay interface
Module Support
==============
Module Loading
--------------
Kernel module auto-loading
--------------------------
.. kernel-doc:: kernel/kmod.c
.. kernel-doc:: kernel/module/kmod.c
:export:
Module debugging
----------------
.. kernel-doc:: kernel/module/stats.c
:doc: module debugging statistics overview
dup_failed_modules - tracks duplicate failed modules
****************************************************
.. kernel-doc:: kernel/module/stats.c
:doc: dup_failed_modules - tracks duplicate failed modules
module statistics debugfs counters
**********************************
.. kernel-doc:: kernel/module/stats.c
:doc: module statistics debugfs counters
Inter Module support
--------------------

View File

@ -575,20 +575,26 @@ The field width is passed by value, the bitmap is passed by reference.
Helper macros cpumask_pr_args() and nodemask_pr_args() are available to ease
printing cpumask and nodemask.
Flags bitfields such as page flags, gfp_flags
---------------------------------------------
Flags bitfields such as page flags, page_type, gfp_flags
--------------------------------------------------------
::
%pGp 0x17ffffc0002036(referenced|uptodate|lru|active|private|node=0|zone=2|lastcpupid=0x1fffff)
%pGt 0xffffff7f(buddy)
%pGg GFP_USER|GFP_DMA32|GFP_NOWARN
%pGv read|exec|mayread|maywrite|mayexec|denywrite
For printing flags bitfields as a collection of symbolic constants that
would construct the value. The type of flags is given by the third
character. Currently supported are [p]age flags, [v]ma_flags (both
expect ``unsigned long *``) and [g]fp_flags (expects ``gfp_t *``). The flag
names and print order depends on the particular type.
character. Currently supported are:
- p - [p]age flags, expects value of type (``unsigned long *``)
- t - page [t]ype, expects value of type (``unsigned int *``)
- v - [v]ma_flags, expects value of type (``unsigned long *``)
- g - [g]fp_flags, expects value of type (``gfp_t *``)
The flag names and print order depends on the particular type.
Note that this format should not be used directly in the
:c:func:`TP_printk()` part of a tracepoint. Instead, use the show_*_flags()

View File

@ -1,42 +1,50 @@
kcov: code coverage for fuzzing
KCOV: code coverage for fuzzing
===============================
kcov exposes kernel code coverage information in a form suitable for coverage-
guided fuzzing (randomized testing). Coverage data of a running kernel is
exported via the "kcov" debugfs file. Coverage collection is enabled on a task
basis, and thus it can capture precise coverage of a single system call.
KCOV collects and exposes kernel code coverage information in a form suitable
for coverage-guided fuzzing. Coverage data of a running kernel is exported via
the ``kcov`` debugfs file. Coverage collection is enabled on a task basis, and
thus KCOV can capture precise coverage of a single system call.
Note that kcov does not aim to collect as much coverage as possible. It aims
to collect more or less stable coverage that is function of syscall inputs.
To achieve this goal it does not collect coverage in soft/hard interrupts
and instrumentation of some inherently non-deterministic parts of kernel is
disabled (e.g. scheduler, locking).
Note that KCOV does not aim to collect as much coverage as possible. It aims
to collect more or less stable coverage that is a function of syscall inputs.
To achieve this goal, it does not collect coverage in soft/hard interrupts
(unless remove coverage collection is enabled, see below) and from some
inherently non-deterministic parts of the kernel (e.g. scheduler, locking).
kcov is also able to collect comparison operands from the instrumented code
(this feature currently requires that the kernel is compiled with clang).
Besides collecting code coverage, KCOV can also collect comparison operands.
See the "Comparison operands collection" section for details.
Besides collecting coverage data from syscall handlers, KCOV can also collect
coverage for annotated parts of the kernel executing in background kernel
tasks or soft interrupts. See the "Remote coverage collection" section for
details.
Prerequisites
-------------
Configure the kernel with::
KCOV relies on compiler instrumentation and requires GCC 6.1.0 or later
or any Clang version supported by the kernel.
Collecting comparison operands is supported with GCC 8+ or with Clang.
To enable KCOV, configure the kernel with::
CONFIG_KCOV=y
CONFIG_KCOV requires gcc 6.1.0 or later.
If the comparison operands need to be collected, set::
To enable comparison operands collection, set::
CONFIG_KCOV_ENABLE_COMPARISONS=y
Profiling data will only become accessible once debugfs has been mounted::
Coverage data only becomes accessible once debugfs has been mounted::
mount -t debugfs none /sys/kernel/debug
Coverage collection
-------------------
The following program demonstrates coverage collection from within a test
program using kcov:
The following program demonstrates how to use KCOV to collect coverage for a
single syscall from within a test program:
.. code-block:: c
@ -84,7 +92,7 @@ program using kcov:
perror("ioctl"), exit(1);
/* Reset coverage from the tail of the ioctl() call. */
__atomic_store_n(&cover[0], 0, __ATOMIC_RELAXED);
/* That's the target syscal call. */
/* Call the target syscall call. */
read(-1, NULL, 0);
/* Read number of PCs collected. */
n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED);
@ -103,7 +111,7 @@ program using kcov:
return 0;
}
After piping through addr2line output of the program looks as follows::
After piping through ``addr2line`` the output of the program looks as follows::
SyS_read
fs/read_write.c:562
@ -121,12 +129,13 @@ After piping through addr2line output of the program looks as follows::
fs/read_write.c:562
If a program needs to collect coverage from several threads (independently),
it needs to open /sys/kernel/debug/kcov in each thread separately.
it needs to open ``/sys/kernel/debug/kcov`` in each thread separately.
The interface is fine-grained to allow efficient forking of test processes.
That is, a parent process opens /sys/kernel/debug/kcov, enables trace mode,
mmaps coverage buffer and then forks child processes in a loop. Child processes
only need to enable coverage (disable happens automatically on thread end).
That is, a parent process opens ``/sys/kernel/debug/kcov``, enables trace mode,
mmaps coverage buffer, and then forks child processes in a loop. The child
processes only need to enable coverage (it gets disabled automatically when
a thread exits).
Comparison operands collection
------------------------------
@ -205,52 +214,78 @@ Comparison operands collection is similar to coverage collection:
return 0;
}
Note that the kcov modes (coverage collection or comparison operands) are
mutually exclusive.
Note that the KCOV modes (collection of code coverage or comparison operands)
are mutually exclusive.
Remote coverage collection
--------------------------
With KCOV_ENABLE coverage is collected only for syscalls that are issued
from the current process. With KCOV_REMOTE_ENABLE it's possible to collect
coverage for arbitrary parts of the kernel code, provided that those parts
are annotated with kcov_remote_start()/kcov_remote_stop().
Besides collecting coverage data from handlers of syscalls issued from a
userspace process, KCOV can also collect coverage for parts of the kernel
executing in other contexts - so-called "remote" coverage.
This allows to collect coverage from two types of kernel background
threads: the global ones, that are spawned during kernel boot in a limited
number of instances (e.g. one USB hub_event() worker thread is spawned per
USB HCD); and the local ones, that are spawned when a user interacts with
some kernel interface (e.g. vhost workers); as well as from soft
interrupts.
Using KCOV to collect remote coverage requires:
To enable collecting coverage from a global background thread or from a
softirq, a unique global handle must be assigned and passed to the
corresponding kcov_remote_start() call. Then a userspace process can pass
a list of such handles to the KCOV_REMOTE_ENABLE ioctl in the handles
array field of the kcov_remote_arg struct. This will attach the used kcov
device to the code sections, that are referenced by those handles.
1. Modifying kernel code to annotate the code section from where coverage
should be collected with ``kcov_remote_start`` and ``kcov_remote_stop``.
Since there might be many local background threads spawned from different
userspace processes, we can't use a single global handle per annotation.
Instead, the userspace process passes a non-zero handle through the
common_handle field of the kcov_remote_arg struct. This common handle gets
saved to the kcov_handle field in the current task_struct and needs to be
passed to the newly spawned threads via custom annotations. Those threads
should in turn be annotated with kcov_remote_start()/kcov_remote_stop().
2. Using ``KCOV_REMOTE_ENABLE`` instead of ``KCOV_ENABLE`` in the userspace
process that collects coverage.
Internally kcov stores handles as u64 integers. The top byte of a handle
is used to denote the id of a subsystem that this handle belongs to, and
the lower 4 bytes are used to denote the id of a thread instance within
that subsystem. A reserved value 0 is used as a subsystem id for common
handles as they don't belong to a particular subsystem. The bytes 4-7 are
currently reserved and must be zero. In the future the number of bytes
used for the subsystem or handle ids might be increased.
Both ``kcov_remote_start`` and ``kcov_remote_stop`` annotations and the
``KCOV_REMOTE_ENABLE`` ioctl accept handles that identify particular coverage
collection sections. The way a handle is used depends on the context where the
matching code section executes.
When a particular userspace process collects coverage via a common
handle, kcov will collect coverage for each code section that is annotated
to use the common handle obtained as kcov_handle from the current
task_struct. However non common handles allow to collect coverage
selectively from different subsystems.
KCOV supports collecting remote coverage from the following contexts:
1. Global kernel background tasks. These are the tasks that are spawned during
kernel boot in a limited number of instances (e.g. one USB ``hub_event``
worker is spawned per one USB HCD).
2. Local kernel background tasks. These are spawned when a userspace process
interacts with some kernel interface and are usually killed when the process
exits (e.g. vhost workers).
3. Soft interrupts.
For #1 and #3, a unique global handle must be chosen and passed to the
corresponding ``kcov_remote_start`` call. Then a userspace process must pass
this handle to ``KCOV_REMOTE_ENABLE`` in the ``handles`` array field of the
``kcov_remote_arg`` struct. This will attach the used KCOV device to the code
section referenced by this handle. Multiple global handles identifying
different code sections can be passed at once.
For #2, the userspace process instead must pass a non-zero handle through the
``common_handle`` field of the ``kcov_remote_arg`` struct. This common handle
gets saved to the ``kcov_handle`` field in the current ``task_struct`` and
needs to be passed to the newly spawned local tasks via custom kernel code
modifications. Those tasks should in turn use the passed handle in their
``kcov_remote_start`` and ``kcov_remote_stop`` annotations.
KCOV follows a predefined format for both global and common handles. Each
handle is a ``u64`` integer. Currently, only the one top and the lower 4 bytes
are used. Bytes 4-7 are reserved and must be zero.
For global handles, the top byte of the handle denotes the id of a subsystem
this handle belongs to. For example, KCOV uses ``1`` as the USB subsystem id.
The lower 4 bytes of a global handle denote the id of a task instance within
that subsystem. For example, each ``hub_event`` worker uses the USB bus number
as the task instance id.
For common handles, a reserved value ``0`` is used as a subsystem id, as such
handles don't belong to a particular subsystem. The lower 4 bytes of a common
handle identify a collective instance of all local tasks spawned by the
userspace process that passed a common handle to ``KCOV_REMOTE_ENABLE``.
In practice, any value can be used for common handle instance id if coverage
is only collected from a single userspace process on the system. However, if
common handles are used by multiple processes, unique instance ids must be
used for each process. One option is to use the process id as the common
handle instance id.
The following program demonstrates using KCOV to collect coverage from both
local tasks spawned by the process and the global task that handles USB bus #1:
.. code-block:: c

View File

@ -1,49 +0,0 @@
Krait Processor Sub-system (KPSS) Application Clock Controller (ACC)
The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
There is one ACC register region per CPU within the KPSS remapped region as
well as an alias register region that remaps accesses to the ACC associated
with the CPU accessing the region.
PROPERTIES
- compatible:
Usage: required
Value type: <string>
Definition: should be one of:
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
- reg:
Usage: required
Value type: <prop-encoded-array>
Definition: the first element specifies the base address and size of
the register region. An optional second element specifies
the base address and size of the alias register region.
- clocks:
Usage: required
Value type: <prop-encoded-array>
Definition: reference to the pll parents.
- clock-names:
Usage: required
Value type: <stringlist>
Definition: must be "pll8_vote", "pxo".
- clock-output-names:
Usage: optional
Value type: <string>
Definition: Name of the output clock. Typically acpuX_aux where X is a
CPU number starting at 0.
Example:
clock-controller@2088000 {
compatible = "qcom,kpss-acc-v2";
reg = <0x02088000 0x1000>,
<0x02008000 0x1000>;
clocks = <&gcc PLL8_VOTE>, <&gcc PXO_SRC>;
clock-names = "pll8_vote", "pxo";
clock-output-names = "acpu0_aux";
};

View File

@ -1,44 +0,0 @@
Krait Processor Sub-system (KPSS) Global Clock Controller (GCC)
PROPERTIES
- compatible:
Usage: required
Value type: <string>
Definition: should be one of the following. The generic compatible
"qcom,kpss-gcc" should also be included.
"qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc"
"qcom,kpss-gcc-apq8064", "qcom,kpss-gcc"
"qcom,kpss-gcc-msm8974", "qcom,kpss-gcc"
"qcom,kpss-gcc-msm8960", "qcom,kpss-gcc"
- reg:
Usage: required
Value type: <prop-encoded-array>
Definition: base address and size of the register region
- clocks:
Usage: required
Value type: <prop-encoded-array>
Definition: reference to the pll parents.
- clock-names:
Usage: required
Value type: <stringlist>
Definition: must be "pll8_vote", "pxo".
- clock-output-names:
Usage: required
Value type: <string>
Definition: Name of the output clock. Typically acpu_l2_aux indicating
an L2 cache auxiliary clock.
Example:
l2cc: clock-controller@2011000 {
compatible = "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc";
reg = <0x2011000 0x1000>;
clocks = <&gcc PLL8_VOTE>, <&gcc PXO_SRC>;
clock-names = "pll8_vote", "pxo";
clock-output-names = "acpu_l2_aux";
};

View File

@ -32,7 +32,7 @@ properties:
maxItems: 1
iommus:
maxItems: 1
maxItems: 4
power-domains:
maxItems: 1

View File

@ -0,0 +1,54 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/microsoft,vmbus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microsoft Hyper-V VMBus
maintainers:
- Saurabh Sengar <ssengar@linux.microsoft.com>
description:
VMBus is a software bus that implement the protocols for communication
between the root or host OS and guest OSs (virtual machines).
properties:
compatible:
const: microsoft,vmbus
ranges: true
'#address-cells':
const: 2
'#size-cells':
const: 1
required:
- compatible
- ranges
- '#address-cells'
- '#size-cells'
additionalProperties: false
examples:
- |
soc {
#address-cells = <2>;
#size-cells = <1>;
bus {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
ranges;
vmbus@ff0000000 {
compatible = "microsoft,vmbus";
#address-cells = <2>;
#size-cells = <1>;
ranges = <0x0f 0xf0000000 0x0f 0xf0000000 0x10000000>;
};
};
};

View File

@ -0,0 +1,82 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/xlnx,versal-net-cdx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: AMD CDX bus controller
description: |
CDX bus controller for AMD devices is implemented to dynamically
detect CDX bus and devices using the firmware.
The CDX bus manages multiple FPGA based hardware devices, which
can support network, crypto or any other specialized type of
devices. These FPGA based devices can be added/modified dynamically
on run-time.
All devices on the CDX bus will have a unique streamid (for IOMMU)
and a unique device ID (for MSI) corresponding to a requestor ID
(one to one associated with the device). The streamid and deviceid
are used to configure SMMU and GIC-ITS respectively.
iommu-map property is used to define the set of stream ids
corresponding to each device and the associated IOMMU.
The MSI writes are accompanied by sideband data (Device ID).
The msi-map property is used to associate the devices with the
device ID as well as the associated ITS controller.
rproc property (xlnx,rproc) is used to identify the remote processor
with which APU (Application Processor Unit) interacts to find out
the bus and device configuration.
maintainers:
- Nipun Gupta <nipun.gupta@amd.com>
- Nikhil Agarwal <nikhil.agarwal@amd.com>
properties:
compatible:
const: xlnx,versal-net-cdx
iommu-map: true
msi-map: true
xlnx,rproc:
$ref: /schemas/types.yaml#/definitions/phandle
description:
phandle to the remoteproc_r5 rproc node using which APU interacts
with remote processor.
ranges: true
"#address-cells":
enum: [1, 2]
"#size-cells":
enum: [1, 2]
required:
- compatible
- iommu-map
- msi-map
- xlnx,rproc
- ranges
- "#address-cells"
- "#size-cells"
additionalProperties: false
examples:
- |
cdx {
compatible = "xlnx,versal-net-cdx";
#address-cells = <1>;
#size-cells = <1>;
/* define map for RIDs 250-259 */
iommu-map = <250 &smmu 250 10>;
/* define msi map for RIDs 250-259 */
msi-map = <250 &its 250 10>;
xlnx,rproc = <&remoteproc_r5>;
ranges;
};

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/clock/brcm,bcm63268-timer-clocks.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM63268 Timer Clock and Reset Device Tree Bindings
maintainers:
- Álvaro Fernández Rojas <noltari@gmail.com>
properties:
compatible:
const: brcm,bcm63268-timer-clocks
reg:
maxItems: 1
"#clock-cells":
const: 1
"#reset-cells":
const: 1
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
- |
timer_clk: clock-controller@100000ac {
compatible = "brcm,bcm63268-timer-clocks";
reg = <0x100000ac 0x4>;
#clock-cells = <1>;
#reset-cells = <1>;
};

View File

@ -0,0 +1,79 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/imx8mp-audiomix.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP i.MX8MP AudioMIX Block Control Binding
maintainers:
- Marek Vasut <marex@denx.de>
description: |
NXP i.MX8M Plus AudioMIX is dedicated clock muxing and gating IP
used to control Audio related clock on the SoC.
properties:
compatible:
const: fsl,imx8mp-audio-blk-ctrl
reg:
maxItems: 1
power-domains:
maxItems: 1
clocks:
minItems: 7
maxItems: 7
clock-names:
items:
- const: ahb
- const: sai1
- const: sai2
- const: sai3
- const: sai5
- const: sai6
- const: sai7
'#clock-cells':
const: 1
description:
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mp-clock.h
for the full list of i.MX8MP IMX8MP_CLK_AUDIOMIX_ clock IDs.
required:
- compatible
- reg
- clocks
- clock-names
- power-domains
- '#clock-cells'
additionalProperties: false
examples:
# Clock Control Module node:
- |
#include <dt-bindings/clock/imx8mp-clock.h>
clock-controller@30e20000 {
compatible = "fsl,imx8mp-audio-blk-ctrl";
reg = <0x30e20000 0x10000>;
#clock-cells = <1>;
clocks = <&clk IMX8MP_CLK_AUDIO_ROOT>,
<&clk IMX8MP_CLK_SAI1>,
<&clk IMX8MP_CLK_SAI2>,
<&clk IMX8MP_CLK_SAI3>,
<&clk IMX8MP_CLK_SAI5>,
<&clk IMX8MP_CLK_SAI6>,
<&clk IMX8MP_CLK_SAI7>;
clock-names = "ahb",
"sai1", "sai2", "sai3",
"sai5", "sai6", "sai7";
power-domains = <&pgc_audio>;
};
...

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/clock/loongson,ls1x-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Loongson-1 Clock Controller
maintainers:
- Keguang Zhang <keguang.zhang@gmail.com>
properties:
compatible:
enum:
- loongson,ls1b-clk
- loongson,ls1c-clk
reg:
maxItems: 1
clocks:
maxItems: 1
"#clock-cells":
const: 1
required:
- compatible
- reg
- clocks
- "#clock-cells"
additionalProperties: false
examples:
- |
clkc: clock-controller@1fe78030 {
compatible = "loongson,ls1b-clk";
reg = <0x1fe78030 0x8>;
clocks = <&xtal>;
#clock-cells = <1>;
};
...

View File

@ -16,7 +16,12 @@ description: |
properties:
compatible:
const: mediatek,mt8186-fhctl
enum:
- mediatek,mt6795-fhctl
- mediatek,mt8173-fhctl
- mediatek,mt8186-fhctl
- mediatek,mt8192-fhctl
- mediatek,mt8195-fhctl
reg:
maxItems: 1

View File

@ -0,0 +1,71 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/mediatek,mt8188-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek Functional Clock Controller for MT8188
maintainers:
- Garmin Chang <garmin.chang@mediatek.com>
description: |
The clock architecture in MediaTek like below
PLLs -->
dividers -->
muxes
-->
clock gate
The devices provide clock gate control in different IP blocks.
properties:
compatible:
enum:
- mediatek,mt8188-adsp-audio26m
- mediatek,mt8188-camsys
- mediatek,mt8188-camsys-rawa
- mediatek,mt8188-camsys-rawb
- mediatek,mt8188-camsys-yuva
- mediatek,mt8188-camsys-yuvb
- mediatek,mt8188-ccusys
- mediatek,mt8188-imgsys
- mediatek,mt8188-imgsys-wpe1
- mediatek,mt8188-imgsys-wpe2
- mediatek,mt8188-imgsys-wpe3
- mediatek,mt8188-imgsys1-dip-nr
- mediatek,mt8188-imgsys1-dip-top
- mediatek,mt8188-imp-iic-wrap-c
- mediatek,mt8188-imp-iic-wrap-en
- mediatek,mt8188-imp-iic-wrap-w
- mediatek,mt8188-ipesys
- mediatek,mt8188-mfgcfg
- mediatek,mt8188-vdecsys
- mediatek,mt8188-vdecsys-soc
- mediatek,mt8188-vencsys
- mediatek,mt8188-vppsys0
- mediatek,mt8188-vppsys1
- mediatek,mt8188-wpesys
- mediatek,mt8188-wpesys-vpp0
reg:
maxItems: 1
'#clock-cells':
const: 1
required:
- compatible
- reg
- '#clock-cells'
additionalProperties: false
examples:
- |
clock-controller@11283000 {
compatible = "mediatek,mt8188-imp-iic-wrap-c";
reg = <0x11283000 0x1000>;
#clock-cells = <1>;
};

View File

@ -0,0 +1,55 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/mediatek,mt8188-sys-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek System Clock Controller for MT8188
maintainers:
- Garmin Chang <garmin.chang@mediatek.com>
description: |
The clock architecture in MediaTek like below
PLLs -->
dividers -->
muxes
-->
clock gate
The apmixedsys provides most of PLLs which generated from SoC 26m.
The topckgen provides dividers and muxes which provide the clock source to other IP blocks.
The infracfg_ao provides clock gate in peripheral and infrastructure IP blocks.
The mcusys provides mux control to select the clock source in AP MCU.
The device nodes also provide the system control capacity for configuration.
properties:
compatible:
items:
- enum:
- mediatek,mt8188-apmixedsys
- mediatek,mt8188-infracfg-ao
- mediatek,mt8188-pericfg-ao
- mediatek,mt8188-topckgen
- const: syscon
reg:
maxItems: 1
'#clock-cells':
const: 1
required:
- compatible
- reg
- '#clock-cells'
additionalProperties: false
examples:
- |
clock-controller@10000000 {
compatible = "mediatek,mt8188-topckgen", "syscon";
reg = <0x10000000 0x1000>;
#clock-cells = <1>;
};

View File

@ -16,6 +16,7 @@ description:
properties:
compatible:
enum:
- qcom,ipq5332-a53pll
- qcom,ipq6018-a53pll
- qcom,ipq8074-a53pll
- qcom,msm8916-a53pll

View File

@ -0,0 +1,53 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,gcc-ipq4019.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller on IPQ4019
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- Taniya Das <tdas@codeaurora.org>
- Robert Marko <robert.markoo@sartura.hr>
description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ4019.
See also:: include/dt-bindings/clock/qcom,gcc-ipq4019.h
allOf:
- $ref: qcom,gcc.yaml#
properties:
compatible:
const: qcom,gcc-ipq4019
clocks:
items:
- description: board XO clock
- description: sleep clock
clock-names:
items:
- const: xo
- const: sleep_clk
required:
- compatible
unevaluatedProperties: false
examples:
- |
clock-controller@1800000 {
compatible = "qcom,gcc-ipq4019";
reg = <0x1800000 0x60000>;
#clock-cells = <1>;
#power-domain-cells = <1>;
#reset-cells = <1>;
clocks = <&xo>, <&sleep_clk>;
clock-names = "xo", "sleep_clk";
};
...

View File

@ -4,20 +4,25 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-msm8909.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller on MSM8909
title: Qualcomm Global Clock & Reset Controller on MSM8909, MSM8917 and QM215
maintainers:
- Stephan Gerhold <stephan@gerhold.net>
description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8909.
domains on MSM8909, MSM8917 or QM215.
See also:: include/dt-bindings/clock/qcom,gcc-msm8909.h
See also::
include/dt-bindings/clock/qcom,gcc-msm8909.h
include/dt-bindings/clock/qcom,gcc-msm8917.h
properties:
compatible:
const: qcom,gcc-msm8909
enum:
- qcom,gcc-msm8909
- qcom,gcc-msm8917
- qcom,gcc-qm215
clocks:
items:

View File

@ -15,7 +15,6 @@ description: |
domains.
See also::
include/dt-bindings/clock/qcom,gcc-ipq4019.h
include/dt-bindings/clock/qcom,gcc-ipq6018.h
include/dt-bindings/reset/qcom,gcc-ipq6018.h
include/dt-bindings/clock/qcom,gcc-msm8953.h
@ -29,7 +28,6 @@ allOf:
properties:
compatible:
enum:
- qcom,gcc-ipq4019
- qcom,gcc-ipq6018
- qcom,gcc-mdm9607
- qcom,gcc-msm8953

View File

@ -15,6 +15,7 @@ description: |
See also::
include/dt-bindings/clock/qcom,gpucc-sdm845.h
include/dt-bindings/clock/qcom,gpucc-sa8775p.h
include/dt-bindings/clock/qcom,gpucc-sc7180.h
include/dt-bindings/clock/qcom,gpucc-sc7280.h
include/dt-bindings/clock/qcom,gpucc-sc8280xp.h
@ -27,6 +28,7 @@ properties:
compatible:
enum:
- qcom,sdm845-gpucc
- qcom,sa8775p-gpucc
- qcom,sc7180-gpucc
- qcom,sc7280-gpucc
- qcom,sc8180x-gpucc

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,kpss-acc-v1.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Krait Processor Sub-system (KPSS) Application Clock Controller (ACC) v1
maintainers:
- Christian Marangi <ansuelsmth@gmail.com>
description:
The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
There is one ACC register region per CPU within the KPSS remapped region as
well as an alias register region that remaps accesses to the ACC associated
with the CPU accessing the region. ACC v1 is currently used as a
clock-controller for enabling the cpu and hanling the aux clocks.
properties:
compatible:
const: qcom,kpss-acc-v1
reg:
items:
- description: Base address and size of the register region
- description: Optional base address and size of the alias register region
minItems: 1
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: pll8_vote
- const: pxo
clock-output-names:
description: Name of the aux clock. Krait can have at most 4 cpu.
enum:
- acpu0_aux
- acpu1_aux
- acpu2_aux
- acpu3_aux
'#clock-cells':
const: 0
required:
- compatible
- reg
- clocks
- clock-names
- clock-output-names
- '#clock-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,gcc-ipq806x.h>
clock-controller@2088000 {
compatible = "qcom,kpss-acc-v1";
reg = <0x02088000 0x1000>, <0x02008000 0x1000>;
clocks = <&gcc PLL8_VOTE>, <&pxo_board>;
clock-names = "pll8_vote", "pxo";
clock-output-names = "acpu0_aux";
#clock-cells = <0>;
};
...

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/clock/qcom,kpss-gcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Krait Processor Sub-system (KPSS) Global Clock Controller (GCC)
maintainers:
- Christian Marangi <ansuelsmth@gmail.com>
description:
Krait Processor Sub-system (KPSS) Global Clock Controller (GCC). Used
to control L2 mux (in the current implementation) and provide access
to the kpss-gcc registers.
properties:
compatible:
items:
- enum:
- qcom,kpss-gcc-ipq8064
- qcom,kpss-gcc-apq8064
- qcom,kpss-gcc-msm8974
- qcom,kpss-gcc-msm8960
- qcom,kpss-gcc-msm8660
- qcom,kpss-gcc-mdm9615
- const: qcom,kpss-gcc
- const: syscon
reg:
maxItems: 1
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: pll8_vote
- const: pxo
'#clock-cells':
const: 0
required:
- compatible
- reg
if:
properties:
compatible:
contains:
enum:
- qcom,kpss-gcc-ipq8064
- qcom,kpss-gcc-apq8064
- qcom,kpss-gcc-msm8974
- qcom,kpss-gcc-msm8960
then:
required:
- clocks
- clock-names
- '#clock-cells'
else:
properties:
clock: false
clock-names: false
'#clock-cells': false
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,gcc-ipq806x.h>
clock-controller@2011000 {
compatible = "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc", "syscon";
reg = <0x2011000 0x1000>;
clocks = <&gcc PLL8_VOTE>, <&pxo_board>;
clock-names = "pll8_vote", "pxo";
#clock-cells = <0>;
};
- |
clock-controller@2011000 {
compatible = "qcom,kpss-gcc-mdm9615", "qcom,kpss-gcc", "syscon";
reg = <0x02011000 0x1000>;
};
...

View File

@ -31,6 +31,7 @@ properties:
- qcom,rpmcc-msm8660
- qcom,rpmcc-msm8909
- qcom,rpmcc-msm8916
- qcom,rpmcc-msm8917
- qcom,rpmcc-msm8936
- qcom,rpmcc-msm8953
- qcom,rpmcc-msm8974
@ -107,6 +108,7 @@ allOf:
- qcom,rpmcc-mdm9607
- qcom,rpmcc-msm8226
- qcom,rpmcc-msm8916
- qcom,rpmcc-msm8917
- qcom,rpmcc-msm8936
- qcom,rpmcc-msm8953
- qcom,rpmcc-msm8974

View File

@ -41,6 +41,12 @@ properties:
- const: qdsp6ss
- const: top_cc
qcom,adsp-pil-mode:
description:
Indicates if the LPASS would be brought out of reset using
remoteproc peripheral loader.
type: boolean
required:
- compatible
- reg
@ -60,6 +66,7 @@ examples:
reg-names = "qdsp6ss", "top_cc";
clocks = <&gcc GCC_CFG_NOC_LPASS_CLK>;
clock-names = "iface";
qcom,adsp-pil-mode;
#clock-cells = <1>;
};
...

View File

@ -0,0 +1,52 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,sm7150-gcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller on SM7150
maintainers:
- Bjorn Andersson <andersson@kernel.org>
- Danila Tikhonov <danila@jiaxyga.com>
- David Wronek <davidwronek@gmail.com>
description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on SM7150
See also:: include/dt-bindings/clock/qcom,sm7150-gcc.h
properties:
compatible:
const: qcom,sm7150-gcc
clocks:
items:
- description: Board XO source
- description: Board XO Active-Only source
- description: Sleep clock source
required:
- compatible
- clocks
allOf:
- $ref: qcom,gcc.yaml#
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
clock-controller@100000 {
compatible = "qcom,sm7150-gcc";
reg = <0x00100000 0x001f0000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
<&rpmhcc RPMH_CXO_CLK_A>,
<&sleep_clk>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
...

View File

@ -16,6 +16,11 @@ description: |
- 9FGV0241:
0 -- DIF0
1 -- DIF1
- 9FGV0441:
0 -- DIF0
1 -- DIF1
2 -- DIF2
3 -- DIF3
maintainers:
- Marek Vasut <marex@denx.de>
@ -24,6 +29,7 @@ properties:
compatible:
enum:
- renesas,9fgv0241
- renesas,9fgv0441
reg:
description: I2C device address

View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/N1D (R9A06G032) System Controller
maintainers:
- Gareth Williams <gareth.williams.jx@renesas.com>
- Fabrizio Castro <fabrizio.castro.jz@renesas.com>
- Geert Uytterhoeven <geert+renesas@glider.be>
properties:

View File

@ -0,0 +1,59 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/skyworks,si521xx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Skyworks Si521xx I2C PCIe clock generators
description: |
The Skyworks Si521xx are I2C PCIe clock generators providing
from 4 to 9 output clocks.
maintainers:
- Marek Vasut <marex@denx.de>
properties:
compatible:
enum:
- skyworks,si52144
- skyworks,si52146
- skyworks,si52147
reg:
const: 0x6b
'#clock-cells':
const: 1
clocks:
items:
- description: XTal input clock
skyworks,out-amplitude-microvolt:
enum: [ 300000, 400000, 500000, 600000, 700000, 800000, 900000, 1000000 ]
description: Output clock signal amplitude
required:
- compatible
- reg
- clocks
- '#clock-cells'
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
clock-generator@6b {
compatible = "skyworks,si52144";
reg = <0x6b>;
#clock-cells = <1>;
clocks = <&ref25m>;
};
};
...

View File

@ -82,6 +82,18 @@ properties:
Indicates if the DSI controller is driving a panel which needs
2 DSI links.
qcom,master-dsi:
type: boolean
description: |
Indicates if the DSI controller is the master DSI controller when
qcom,dual-dsi-mode enabled.
qcom,sync-dual-dsi:
type: boolean
description: |
Indicates if the DSI controller needs to sync the other DSI controller
with MIPI DCS commands when qcom,dual-dsi-mode enabled.
assigned-clocks:
minItems: 2
maxItems: 4

View File

@ -26,6 +26,7 @@ properties:
- enum:
- apple,t6000-admac
- apple,t8103-admac
- apple,t8112-admac
- const: apple,admac
reg:

View File

@ -24,6 +24,7 @@ properties:
- qcom,sm6350-gpi-dma
- items:
- enum:
- qcom,qcm2290-gpi-dma
- qcom,qdu1000-gpi-dma
- qcom,sc7280-gpi-dma
- qcom,sm6115-gpi-dma

View File

@ -54,6 +54,11 @@ properties:
- description: DMA main clock
- description: DMA register access clock
clock-names:
items:
- const: main
- const: register
'#dma-cells':
const: 1
description:
@ -77,16 +82,23 @@ properties:
- description: Reset for DMA ARESETN reset terminal
- description: Reset for DMA RST_ASYNC reset terminal
reset-names:
items:
- const: arst
- const: rst_async
required:
- compatible
- reg
- interrupts
- interrupt-names
- clocks
- clock-names
- '#dma-cells'
- dma-channels
- power-domains
- resets
- reset-names
additionalProperties: false
@ -124,9 +136,11 @@ examples:
"ch12", "ch13", "ch14", "ch15";
clocks = <&cpg CPG_MOD R9A07G044_DMAC_ACLK>,
<&cpg CPG_MOD R9A07G044_DMAC_PCLK>;
clock-names = "main", "register";
power-domains = <&cpg>;
resets = <&cpg R9A07G044_DMAC_ARESETN>,
<&cpg R9A07G044_DMAC_RST_ASYNC>;
reset-names = "arst", "rst_async";
#dma-cells = <1>;
dma-channels = <16>;
};

View File

@ -20,6 +20,7 @@ properties:
enum:
- snps,axi-dma-1.01a
- intel,kmb-axi-dma
- starfive,jh7110-axi-dma
reg:
minItems: 1
@ -58,7 +59,8 @@ properties:
maximum: 8
resets:
maxItems: 1
minItems: 1
maxItems: 2
snps,dma-masters:
description: |
@ -109,6 +111,25 @@ required:
- snps,priority
- snps,block-size
if:
properties:
compatible:
contains:
enum:
- starfive,jh7110-axi-dma
then:
properties:
resets:
minItems: 2
items:
- description: AXI reset line
- description: AHB reset line
- description: module reset
else:
properties:
resets:
maxItems: 1
additionalProperties: false
examples:

View File

@ -43,7 +43,7 @@ description: |
configuration of the legacy peripheral.
allOf:
- $ref: "../dma-controller.yaml#"
- $ref: ../dma-controller.yaml#
- $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
properties:

View File

@ -15,7 +15,7 @@ maintainers:
- Michael Tretter <m.tretter@pengutronix.de>
allOf:
- $ref: "../dma-controller.yaml#"
- $ref: ../dma-controller.yaml#
properties:
"#dma-cells":

View File

@ -16,7 +16,7 @@ maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
allOf:
- $ref: "../dma-controller.yaml#"
- $ref: ../dma-controller.yaml#
properties:
"#dma-cells":

View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Lattice Slave SPI sysCONFIG FPGA manager
maintainers:
- Ivan Bornyakov <i.bornyakov@metrotek.ru>
- Vladimir Georgiev <v.georgiev@metrotek.ru>
description: |
Lattice sysCONFIG port, which is used for FPGA configuration, among others,

View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip Polarfire FPGA manager.
maintainers:
- Ivan Bornyakov <i.bornyakov@metrotek.ru>
- Vladimir Georgiev <v.georgiev@metrotek.ru>
description:
Device Tree Bindings for Microchip Polarfire FPGA Manager using slave SPI to

View File

@ -39,6 +39,10 @@ properties:
reg:
maxItems: 1
gpio-line-names:
minItems: 1
maxItems: 16
gpio-controller: true
'#gpio-cells':

View File

@ -1,35 +0,0 @@
Broadcom Kona Family I2C
=========================
This I2C controller is used in the following Broadcom SoCs:
BCM11130
BCM11140
BCM11351
BCM28145
BCM28155
Required Properties
-------------------
- compatible: "brcm,bcm11351-i2c", "brcm,kona-i2c"
- reg: Physical base address and length of controller registers
- interrupts: The interrupt number used by the controller
- clocks: clock specifier for the kona i2c external clock
- clock-frequency: The I2C bus frequency in Hz
- #address-cells: Should be <1>
- #size-cells: Should be <0>
Refer to clocks/clock-bindings.txt for generic clock consumer
properties.
Example:
i2c@3e016000 {
compatible = "brcm,bcm11351-i2c","brcm,kona-i2c";
reg = <0x3e016000 0x80>;
interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&bsc1_clk>;
clock-frequency = <400000>;
#address-cells = <1>;
#size-cells = <0>;
};

View File

@ -0,0 +1,59 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/brcm,kona-i2c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom Kona family I2C controller
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
properties:
compatible:
items:
- enum:
- brcm,bcm11351-i2c
- brcm,bcm21664-i2c
- brcm,bcm23550-i2c
- const: brcm,kona-i2c
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
clock-frequency:
enum: [ 100000, 400000, 1000000, 3400000 ]
required:
- compatible
- reg
- interrupts
- clocks
- clock-frequency
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c@3e016000 {
compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
reg = <0x3e016000 0x80>;
interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&bsc1_clk>;
clock-frequency = <400000>;
#address-cells = <1>;
#size-cells = <0>;
};
...

View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/V2M I2C Bus Interface
maintainers:
- Phil Edworthy <phil.edworthy@renesas.com>
- Fabrizio Castro <fabrizio.castro.jz@renesas.com>
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#

View File

@ -0,0 +1,72 @@
# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/i3c/aspeed,ast2600-i3c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ASPEED AST2600 i3c controller
maintainers:
- Jeremy Kerr <jk@codeconstruct.com.au>
allOf:
- $ref: i3c.yaml#
properties:
compatible:
const: aspeed,ast2600-i3c
reg:
maxItems: 1
clocks:
maxItems: 1
resets:
maxItems: 1
interrupts:
maxItems: 1
sda-pullup-ohms:
enum: [545, 750, 2000]
default: 2000
description: |
Value to configure SDA pullup resistor, in Ohms.
aspeed,global-regs:
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to i3c global register syscon node
- description: index of this i3c controller in the global register set
description: |
A (phandle, controller index) reference to the i3c global register set
used for this device.
required:
- compatible
- reg
- clocks
- interrupts
- aspeed,global-regs
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
i3c-master@2000 {
compatible = "aspeed,ast2600-i3c";
reg = <0x2000 0x1000>;
#address-cells = <3>;
#size-cells = <0>;
clocks = <&syscon 0>;
resets = <&syscon 0>;
aspeed,global-regs = <&i3c_global 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i3c1_default>;
interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
};
...

View File

@ -39,6 +39,12 @@ properties:
power-domains:
maxItems: 1
vref-supply:
description: |
External ADC reference voltage supply on VREFH pad. If VERID[MVI] is
set, there are additional, internal reference voltages selectable.
VREFH1 is always from VREFH pad.
"#io-channel-cells":
const: 1
@ -72,6 +78,7 @@ examples:
assigned-clocks = <&clk IMX_SC_R_ADC_0>;
assigned-clock-rates = <24000000>;
power-domains = <&pd IMX_SC_R_ADC_0>;
vref-supply = <&reg_1v8>;
#io-channel-cells = <1>;
};
};

View File

@ -34,9 +34,11 @@ properties:
clock-names:
const: fck
power-domains: true
power-domains:
maxItems: 1
resets: true
resets:
maxItems: 1
"#address-cells":
const: 1
@ -51,6 +53,8 @@ required:
- reg
- clocks
- clock-names
- power-domains
- resets
- "#address-cells"
- "#size-cells"
@ -86,7 +90,7 @@ patternProperties:
of the MAX chips to the GyroADC, while MISO line of each Maxim
ADC connects to a shared input pin of the GyroADC.
enum:
- adi,7476
- adi,ad7476
- fujitsu,mb88101a
- maxim,max1162
- maxim,max11100
@ -108,36 +112,30 @@ patternProperties:
examples:
- |
#include <dt-bindings/clock/r8a7791-clock.h>
#include <dt-bindings/clock/r8a7791-cpg-mssr.h>
#include <dt-bindings/power/r8a7791-sysc.h>
soc {
#address-cells = <2>;
#size-cells = <2>;
adc@e6e54000 {
compatible = "renesas,r8a7791-gyroadc", "renesas,rcar-gyroadc";
reg = <0 0xe6e54000 0 64>;
clocks = <&mstp9_clks R8A7791_CLK_GYROADC>;
clock-names = "fck";
power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
adc@e6e54000 {
compatible = "renesas,r8a7791-gyroadc", "renesas,rcar-gyroadc";
reg = <0xe6e54000 64>;
clocks = <&cpg CPG_MOD 901>;
clock-names = "fck";
power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
resets = <&cpg 901>;
pinctrl-0 = <&adc_pins>;
pinctrl-names = "default";
#address-cells = <1>;
#size-cells = <0>;
#address-cells = <1>;
#size-cells = <0>;
adc@0 {
reg = <0>;
compatible = "maxim,max1162";
vref-supply = <&vref_max1162>;
};
adc@0 {
reg = <0>;
compatible = "maxim,max1162";
vref-supply = <&vref_max1162>;
};
adc@1 {
reg = <1>;
compatible = "maxim,max1162";
vref-supply = <&vref_max1162>;
};
adc@1 {
reg = <1>;
compatible = "maxim,max1162";
vref-supply = <&vref_max1162>;
};
};
...

View File

@ -0,0 +1,46 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/adc/ti,ads1100.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI ADS1100/ADS1000 single channel I2C analog to digital converter
maintainers:
- Mike Looijmans <mike.looijmans@topic.nl>
description: |
Datasheet at: https://www.ti.com/lit/gpn/ads1100
properties:
compatible:
enum:
- ti,ads1100
- ti,ads1000
reg:
maxItems: 1
vdd-supply: true
"#io-channel-cells":
const: 0
required:
- compatible
- reg
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
adc@49 {
compatible = "ti,ads1100";
reg = <0x49>;
};
};
...

View File

@ -101,6 +101,15 @@ patternProperties:
When not configured as a comparator, the GPO will be treated as an
output-only GPIO.
drive-strength-microamp:
description: |
For channels configured as digital input, this configures the sink
current.
minimum: 0
maximum: 1800
default: 0
multipleOf: 120
required:
- reg

View File

@ -46,6 +46,9 @@ properties:
- items:
- const: st,ism330is
- const: st,lsm6dso16is
- items:
- const: st,asm330lhb
- const: st,asm330lhh
reg:
maxItems: 1

View File

@ -0,0 +1,46 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/light/rohm,bu27034.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ROHM BU27034 ambient light sensor
maintainers:
- Matti Vaittinen <mazziesaccount@gmail.com>
description: |
ROHM BU27034 is an ambient light sesnor with 3 channels and 3 photo diodes
capable of detecting a very wide range of illuminance. Typical application
is adjusting LCD and backlight power of TVs and mobile phones.
https://fscdn.rohm.com/en/products/databook/datasheet/ic/sensor/light/bu27034nuc-e.pdf
properties:
compatible:
const: rohm,bu27034
reg:
maxItems: 1
vdd-supply: true
required:
- compatible
- reg
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
light-sensor@38 {
compatible = "rohm,bu27034";
reg = <0x38>;
vdd-supply = <&vdd>;
};
};
...

View File

@ -17,6 +17,7 @@ description: |
https://www.bosch-sensortec.com/bst/products/all_products/bmp280
https://www.bosch-sensortec.com/bst/products/all_products/bme280
https://www.bosch-sensortec.com/bst/products/all_products/bmp380
https://www.bosch-sensortec.com/bst/products/all_products/bmp580
properties:
compatible:
@ -26,6 +27,7 @@ properties:
- bosch,bmp280
- bosch,bme280
- bosch,bmp380
- bosch,bmp580
reg:
maxItems: 1

View File

@ -11,9 +11,6 @@ description: The STMicroelectronics sensor devices are pretty straight-forward
what type of sensor it is.
Note that whilst this covers many STMicro MEMs sensors, some more complex
IMUs need their own bindings.
The STMicroelectronics sensor devices are pretty straight-forward I2C or
SPI devices, all sharing the same device tree descriptions no matter what
type of sensor it is.
maintainers:
- Denis Ciocca <denis.ciocca@st.com>
@ -48,6 +45,9 @@ properties:
- st,lsm330d-accel
- st,lsm330dl-accel
- st,lsm330dlc-accel
- items:
- const: st,iis328dq
- const: st,h3lis331dl-accel
- description: Silan Accelerometers
enum:
- silan,sc7a20

View File

@ -18,6 +18,28 @@ description: |
https://www.analog.com/media/en/technical-documentation/data-sheets/29861fa.pdf
https://www.analog.com/media/en/technical-documentation/data-sheets/ltm2985.pdf
$defs:
sensor-node:
type: object
description: Sensor node common constraints
properties:
reg:
description:
Channel number. Connects the sensor to the channel with this number
of the device.
minimum: 1
maximum: 20
adi,sensor-type:
description: Type of sensor connected to the device.
$ref: /schemas/types.yaml#/definitions/uint32
required:
- reg
- adi,sensor-type
properties:
compatible:
oneOf:
@ -64,28 +86,10 @@ properties:
const: 0
patternProperties:
"@([0-9a-f]+)$":
type: object
description: Sensor.
properties:
reg:
description:
Channel number. Connects the sensor to the channel with this number
of the device.
minimum: 1
maximum: 20
adi,sensor-type:
description: Type of sensor connected to the device.
$ref: /schemas/types.yaml#/definitions/uint32
required:
- reg
- adi,sensor-type
"^thermocouple@":
type: object
$ref: '#/$defs/sensor-node'
unevaluatedProperties: false
description: Thermocouple sensor.
properties:
@ -123,7 +127,7 @@ patternProperties:
description:
Used for digitizing custom thermocouples.
See Page 59 of the datasheet.
$ref: /schemas/types.yaml#/definitions/uint64-matrix
$ref: /schemas/types.yaml#/definitions/int64-matrix
minItems: 3
maxItems: 64
items:
@ -141,7 +145,9 @@ patternProperties:
- adi,custom-thermocouple
"^diode@":
type: object
$ref: '#/$defs/sensor-node'
unevaluatedProperties: false
description: Diode sensor.
properties:
@ -184,7 +190,8 @@ patternProperties:
default: 0
"^rtd@":
type: object
$ref: '#/$defs/sensor-node'
unevaluatedProperties: false
description: RTD sensor.
properties:
@ -282,7 +289,8 @@ patternProperties:
- adi,custom-rtd
"^thermistor@":
type: object
$ref: '#/$defs/sensor-node'
unevaluatedProperties: false
description: Thermistor sensor.
properties:
@ -383,7 +391,8 @@ patternProperties:
- adi,custom-thermistor
"^adc@":
type: object
$ref: '#/$defs/sensor-node'
unevaluatedProperties: false
description: Direct ADC sensor.
properties:
@ -397,7 +406,8 @@ patternProperties:
type: boolean
"^temp@":
type: object
$ref: '#/$defs/sensor-node'
unevaluatedProperties: false
description: Active analog temperature sensor.
properties:
@ -426,7 +436,8 @@ patternProperties:
- adi,custom-temp
"^rsense@":
type: object
$ref: '#/$defs/sensor-node'
unevaluatedProperties: false
description: Sense resistor sensor.
properties:

View File

@ -7,9 +7,10 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI TMP117 - Digital temperature sensor with integrated NV memory
description: |
TI TMP117 - Digital temperature sensor with integrated NV memory that supports
I2C interface.
https://www.ti.com/lit/gpn/tmp1
TI TMP116/117 - Digital temperature sensor with integrated NV memory that
supports I2C interface.
https://www.ti.com/lit/gpn/tmp116
https://www.ti.com/lit/gpn/tmp117
maintainers:
- Puranjay Mohan <puranjay12@gmail.com>
@ -17,6 +18,7 @@ maintainers:
properties:
compatible:
enum:
- ti,tmp116
- ti,tmp117
reg:

View File

@ -45,7 +45,7 @@ properties:
when the keyboard has a custom design for the top row keys.
dependencies:
function-row-phsymap: [ 'linux,keymap' ]
function-row-physmap: [ 'linux,keymap' ]
google,needs-ghost-filter: [ 'linux,keymap' ]
required:

View File

@ -1,24 +0,0 @@
* PWM beeper device tree bindings
Registers a PWM device as beeper.
Required properties:
- compatible: should be "pwm-beeper"
- pwms: phandle to the physical PWM device
Optional properties:
- amp-supply: phandle to a regulator that acts as an amplifier for the beeper
- beeper-hz: bell frequency in Hz
Example:
beeper_amp: amplifier {
compatible = "fixed-regulator";
gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
};
beeper {
compatible = "pwm-beeper";
pwms = <&pwm0>;
amp-supply = <&beeper_amp>;
};

View File

@ -0,0 +1,41 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/pwm-beeper.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: PWM beeper
maintainers:
- Sascha Hauer <s.hauer@pengutronix.de>
properties:
compatible:
const: pwm-beeper
pwms:
maxItems: 1
amp-supply:
description: an amplifier for the beeper
beeper-hz:
description: bell frequency in Hz
minimum: 10
maximum: 10000
required:
- compatible
- pwms
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
beeper {
compatible = "pwm-beeper";
pwms = <&pwm0>;
amp-supply = <&beeper_amp>;
beeper-hz = <1000>;
};

View File

@ -22,14 +22,14 @@ description: |
properties:
compatible:
oneOf:
- const: qcom,msm8998-bwmon # BWMON v4
- items:
- enum:
- qcom,sc7280-cpu-bwmon
- qcom,sc8280xp-cpu-bwmon
- qcom,sdm845-bwmon
- qcom,sdm845-cpu-bwmon
- qcom,sm8550-cpu-bwmon
- const: qcom,msm8998-bwmon
- const: qcom,msm8998-bwmon # BWMON v4
- const: qcom,sdm845-bwmon # BWMON v4, unified register space
- items:
- enum:
- qcom,sc8280xp-llcc-bwmon
@ -49,9 +49,13 @@ properties:
type: object
reg:
# BWMON v4 (currently described) and BWMON v5 use one register address
# space. BWMON v2 uses two register spaces - not yet described.
maxItems: 1
# BWMON v5 uses one register address space, v1-v4 use one or two.
minItems: 1
maxItems: 2
reg-names:
minItems: 1
maxItems: 2
required:
- compatible
@ -63,13 +67,36 @@ required:
additionalProperties: false
allOf:
- if:
properties:
compatible:
const: qcom,msm8998-bwmon
then:
properties:
reg:
minItems: 2
reg-names:
items:
- const: monitor
- const: global
else:
properties:
reg:
maxItems: 1
reg-names:
maxItems: 1
examples:
- |
#include <dt-bindings/interconnect/qcom,sdm845.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
pmu@1436400 {
compatible = "qcom,sdm845-bwmon", "qcom,msm8998-bwmon";
compatible = "qcom,sdm845-cpu-bwmon", "qcom,sdm845-bwmon";
reg = <0x01436400 0x600>;
interrupts = <GIC_SPI 581 IRQ_TYPE_LEVEL_HIGH>;
interconnects = <&gladiator_noc MASTER_APPSS_PROC 3 &mem_noc SLAVE_LLCC 3>;

View File

@ -29,6 +29,7 @@ properties:
- enum:
- qcom,sc7280-epss-l3
- qcom,sc8280xp-epss-l3
- qcom,sm6375-cpucp-l3
- qcom,sm8250-epss-l3
- qcom,sm8350-epss-l3
- const: qcom,epss-l3

View File

@ -166,6 +166,12 @@ properties:
resets:
maxItems: 1
mediatek,broken-save-restore-fw:
type: boolean
description:
Asserts that the firmware on this device has issues saving and restoring
GICR registers when the GIC redistributors are powered off.
dependencies:
mbi-ranges: [ msi-controller ]
msi-controller: [ mbi-ranges ]

View File

@ -53,6 +53,7 @@ properties:
- qcom,sm8250-smmu-500
- qcom,sm8350-smmu-500
- qcom,sm8450-smmu-500
- qcom,sm8550-smmu-500
- const: qcom,smmu-500
- const: arm,mmu-500
@ -75,9 +76,22 @@ properties:
- qcom,sm8350-smmu-500
- qcom,sm8450-smmu-500
- const: arm,mmu-500
- description: Qcom Adreno GPUs implementing "arm,smmu-500"
- description: Qcom Adreno GPUs implementing "qcom,smmu-500" and "arm,mmu-500"
items:
- enum:
- qcom,sc7280-smmu-500
- qcom,sm6115-smmu-500
- qcom,sm6125-smmu-500
- qcom,sm8150-smmu-500
- qcom,sm8250-smmu-500
- qcom,sm8350-smmu-500
- const: qcom,adreno-smmu
- const: qcom,smmu-500
- const: arm,mmu-500
- description: Qcom Adreno GPUs implementing "arm,mmu-500" (legacy binding)
deprecated: true
items:
# Do not add additional SoC to this list. Instead use previous list.
- enum:
- qcom,sc7280-smmu-500
- qcom,sm8150-smmu-500
@ -364,6 +378,30 @@ allOf:
- description: interface clock required to access smmu's registers
through the TCU's programming interface.
- if:
properties:
compatible:
items:
- enum:
- qcom,sm6115-smmu-500
- qcom,sm6125-smmu-500
- const: qcom,adreno-smmu
- const: qcom,smmu-500
- const: arm,mmu-500
then:
properties:
clock-names:
items:
- const: mem
- const: hlos
- const: iface
clocks:
items:
- description: GPU memory bus clock
- description: Voter clock required for HLOS SMMU access
- description: Interface clock required for register access
# Disallow clocks for all other platforms with specific compatibles
- if:
properties:
@ -383,12 +421,11 @@ allOf:
- qcom,sdm845-smmu-500
- qcom,sdx55-smmu-500
- qcom,sdx65-smmu-500
- qcom,sm6115-smmu-500
- qcom,sm6125-smmu-500
- qcom,sm6350-smmu-500
- qcom,sm6375-smmu-500
- qcom,sm8350-smmu-500
- qcom,sm8450-smmu-500
- qcom,sm8550-smmu-500
then:
properties:
clock-names: false

View File

@ -74,16 +74,16 @@ properties:
renesas,ipmmu-main:
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- minItems: 1
items:
- description: phandle to main IPMMU
- description: the interrupt bit number associated with the particular
cache IPMMU device. The interrupt bit number needs to match the main
IPMMU IMSSTR register. Only used by cache IPMMU instances.
- description:
The interrupt bit number associated with the particular cache
IPMMU device. If present, the interrupt bit number needs to match
the main IPMMU IMSSTR register. Only used by cache IPMMU
instances.
description:
Reference to the main IPMMU phandle plus 1 cell. The cell is
the interrupt bit number associated with the particular cache IPMMU
device. The interrupt bit number needs to match the main IPMMU IMSSTR
register. Only used by cache IPMMU instances.
Reference to the main IPMMU.
required:
- compatible
@ -109,6 +109,22 @@ allOf:
required:
- power-domains
- if:
properties:
compatible:
contains:
const: renesas,rcar-gen4-ipmmu-vmsa
then:
properties:
renesas,ipmmu-main:
items:
- maxItems: 1
else:
properties:
renesas,ipmmu-main:
items:
- minItems: 2
examples:
- |
#include <dt-bindings/clock/r8a7791-cpg-mssr.h>

View File

@ -90,22 +90,51 @@ properties:
- heartbeat
# LED indicates disk activity
- disk-activity
# LED indicates disk read activity
- disk-read
# LED indicates disk write activity
- disk-write
# LED flashes at a fixed, configurable rate
- timer
# LED alters the brightness for the specified duration with one software
# timer (requires "led-pattern" property)
- pattern
# LED indicates mic mute state
- audio-micmute
# LED indicates audio mute state
- audio-mute
# LED indicates bluetooth power state
- bluetooth-power
# LED indicates activity of all CPUs
- cpu
# LED indicates camera flash state
- flash
# LED indicated keyboard capslock
- kbd-capslock
# LED indicates MTD memory activity
- mtd
# LED indicates NAND memory activity (deprecated),
# in new implementations use "mtd"
- nand-disk
# No trigger assigned to the LED. This is the default mode
# if trigger is absent
- none
# LED indicates camera torch state
- torch
# LED indicates USB gadget activity
- usb-gadget
# LED indicates USB host activity
- usb-host
# LED indicates USB port state
- usbport
# LED is triggered by CPU activity
- pattern: "^cpu[0-9]*$"
- pattern: "^hci[0-9]+-power$"
# LED is triggered by Bluetooth activity
- pattern: "^mmc[0-9]+$"
- pattern: "^hci[0-9]+-power$"
# LED is triggered by SD/MMC activity
- pattern: "^phy[0-9]+tx$"
- pattern: "^mmc[0-9]+$"
# LED is triggered by WLAN activity
- pattern: "^phy[0-9]+tx$"
led-pattern:
description: |

View File

@ -1,49 +0,0 @@
*NXP - pca9532 PWM LED Driver
The PCA9532 family is SMBus I/O expander optimized for dimming LEDs.
The PWM support 256 steps.
Required properties:
- compatible:
"nxp,pca9530"
"nxp,pca9531"
"nxp,pca9532"
"nxp,pca9533"
- reg - I2C slave address
Each led is represented as a sub-node of the nxp,pca9530.
Optional sub-node properties:
- label: see Documentation/devicetree/bindings/leds/common.txt
- type: Output configuration, see dt-bindings/leds/leds-pca9532.h (default NONE)
- linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt
- default-state: see Documentation/devicetree/bindings/leds/common.txt
This property is only valid for sub-nodes of type <PCA9532_TYPE_LED>.
Example:
#include <dt-bindings/leds/leds-pca9532.h>
leds: pca9530@60 {
compatible = "nxp,pca9530";
reg = <0x60>;
red-power {
label = "pca:red:power";
type = <PCA9532_TYPE_LED>;
};
green-power {
label = "pca:green:power";
type = <PCA9532_TYPE_LED>;
};
kernel-booting {
type = <PCA9532_TYPE_LED>;
default-state = "on";
};
sys-stat {
type = <PCA9532_TYPE_LED>;
default-state = "keep"; // don't touch, was set by U-Boot
};
};
For more product information please see the link below:
http://nxp.com/documents/data_sheet/PCA9532.pdf

View File

@ -27,6 +27,7 @@ properties:
- qcom,pmc8180c-lpg
- qcom,pmi8994-lpg
- qcom,pmi8998-lpg
- qcom,pmk8550-pwm
"#pwm-cells":
const: 2

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/leds/nxp,pca953x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP PCA9532 LED Dimmer
maintainers:
- Riku Voipio <riku.voipio@iki.fi>
description: |
The PCA9532 family is SMBus I/O expander optimized for dimming LEDs.
The PWM support 256 steps.
For more product information please see the link below:
https://www.nxp.com/docs/en/data-sheet/PCA9532.pdf
properties:
compatible:
enum:
- nxp,pca9530
- nxp,pca9531
- nxp,pca9532
- nxp,pca9533
reg:
maxItems: 1
gpio-controller: true
'#gpio-cells':
const: 2
patternProperties:
"^led-[0-9a-z]+$":
type: object
$ref: common.yaml#
unevaluatedProperties: false
properties:
type:
description: |
Output configuration, see include/dt-bindings/leds/leds-pca9532.h
$ref: /schemas/types.yaml#/definitions/uint32
default: 0
minimum: 0
maximum: 4
required:
- compatible
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/leds/leds-pca9532.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
led-controller@62 {
compatible = "nxp,pca9533";
reg = <0x62>;
led-1 {
label = "pca:red:power";
type = <PCA9532_TYPE_LED>;
};
led-2 {
label = "pca:green:power";
type = <PCA9532_TYPE_LED>;
};
led-3 {
type = <PCA9532_TYPE_LED>;
default-state = "on";
};
led-4 {
type = <PCA9532_TYPE_LED>;
default-state = "keep";
};
};
};
...

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