Merge branch 'master' into mm-hotfixes-stable

This commit is contained in:
Andrew Morton 2024-01-22 19:23:56 -08:00
commit f0b7a0d1d4
2662 changed files with 93596 additions and 28275 deletions

32
.editorconfig Normal file
View File

@ -0,0 +1,32 @@
# SPDX-License-Identifier: GPL-2.0-only
root = true
[{*.{awk,c,dts,dtsi,dtso,h,mk,s,S},Kconfig,Makefile,Makefile.*}]
charset = utf-8
end_of_line = lf
trim_trailing_whitespace = true
insert_final_newline = true
indent_style = tab
indent_size = 8
[*.{json,py,rs}]
charset = utf-8
end_of_line = lf
trim_trailing_whitespace = true
insert_final_newline = true
indent_style = space
indent_size = 4
# this must be below the general *.py to overwrite it
[tools/{perf,power,rcu,testing/kunit}/**.py,]
indent_style = tab
indent_size = 8
[*.yaml]
charset = utf-8
end_of_line = lf
trim_trailing_whitespace = unset
insert_final_newline = true
indent_style = space
indent_size = 2

1
.gitignore vendored
View File

@ -96,6 +96,7 @@ modules.order
#
!.clang-format
!.cocciconfig
!.editorconfig
!.get_maintainer.ignore
!.gitattributes
!.gitignore

View File

@ -390,9 +390,10 @@ Matthias Fuchs <socketcan@esd.eu> <matthias.fuchs@esd.eu>
Matthieu Baerts <matttbe@kernel.org> <matthieu.baerts@tessares.net>
Matthieu CASTET <castet.matthieu@free.fr>
Matti Vaittinen <mazziesaccount@gmail.com> <matti.vaittinen@fi.rohmeurope.com>
Matt Ranostay <matt.ranostay@konsulko.com> <matt@ranostay.consulting>
Matt Ranostay <mranostay@gmail.com> Matthew Ranostay <mranostay@embeddedalley.com>
Matt Ranostay <mranostay@gmail.com> <matt.ranostay@intel.com>
Matt Ranostay <matt@ranostay.sg> <matt.ranostay@konsulko.com>
Matt Ranostay <matt@ranostay.sg> <matt@ranostay.consulting>
Matt Ranostay <matt@ranostay.sg> Matthew Ranostay <mranostay@embeddedalley.com>
Matt Ranostay <matt@ranostay.sg> <matt.ranostay@intel.com>
Matt Redfearn <matt.redfearn@mips.com> <matt.redfearn@imgtec.com>
Maulik Shah <quic_mkshah@quicinc.com> <mkshah@codeaurora.org>
Mauro Carvalho Chehab <mchehab@kernel.org> <maurochehab@gmail.com>

25
CREDITS
View File

@ -179,6 +179,7 @@ E: ralf@gnu.org
P: 1024/AF7B30C1 CF 97 C2 CC 6D AE A7 FE C8 BA 9C FC 88 DE 32 C3
D: Linux/MIPS port
D: Linux/68k hacker
D: AX25 maintainer
S: Hauptstrasse 19
S: 79837 St. Blasien
S: Germany
@ -677,6 +678,10 @@ D: Media subsystem (V4L/DVB) drivers and core
D: EDAC drivers and EDAC 3.0 core rework
S: Brazil
N: Landen Chao
E: Landen.Chao@mediatek.com
D: MT7531 Ethernet switch support
N: Raymond Chen
E: raymondc@microsoft.com
D: Author of Configure script
@ -814,6 +819,10 @@ D: Support for Xircom PGSDB9 (firmware and host driver)
S: Bucharest
S: Romania
N: John Crispin
E: john@phrozen.org
D: MediaTek MT7623 Gigabit ethernet support
N: Laurence Culhane
E: loz@holmes.demon.co.uk
D: Wrote the initial alpha SLIP code
@ -1538,6 +1547,10 @@ N: Andrew Haylett
E: ajh@primag.co.uk
D: Selection mechanism
N: Johan Hedberg
E: johan.hedberg@gmail.com
D: Bluetooth subsystem maintainer
N: Andre Hedrick
E: andre@linux-ide.org
E: andre@linuxdiskcert.org
@ -3052,6 +3065,10 @@ S: Demonstratsii 8-382
S: Tula 300000
S: Russia
N: Thomas Petazzoni
E: thomas.petazzoni@bootlin.com
D: Driver for the Marvell Armada 370/XP network unit.
N: Gordon Peters
E: GordPeters@smarttech.com
D: Isochronous receive for IEEE 1394 driver (OHCI module).
@ -3950,6 +3967,10 @@ S: 21513 Conradia Ct
S: Cupertino, CA 95014
S: USA
N: Manohar Vanga
E: manohar.vanga@gmail.com
D: VME subsystem maintainer
N: Thibaut Varène
E: hacks+kernel@slashdirt.org
W: http://hacks.slashdirt.org/
@ -4050,6 +4071,10 @@ D: Fixes for the NE/2-driver
D: Miscellaneous MCA-support
D: Cleanup of the Config-files
N: Martyn Welch
E: martyn@welchs.me.uk
D: VME subsystem maintainer
N: Matt Welsh
E: mdw@metalab.unc.edu
W: http://www.cs.berkeley.edu/~mdw

View File

@ -0,0 +1,25 @@
What: /sys/kernel/debug/vfio
Date: December 2023
KernelVersion: 6.8
Contact: Longfang Liu <liulongfang@huawei.com>
Description: This debugfs file directory is used for debugging
of vfio devices, it's a common directory for all vfio devices.
Vfio core will create a device subdirectory under this
directory.
What: /sys/kernel/debug/vfio/<device>/migration
Date: December 2023
KernelVersion: 6.8
Contact: Longfang Liu <liulongfang@huawei.com>
Description: This debugfs file directory is used for debugging
of vfio devices that support live migration.
The debugfs of each vfio device that supports live migration
could be created under this directory.
What: /sys/kernel/debug/vfio/<device>/migration/state
Date: December 2023
KernelVersion: 6.8
Contact: Longfang Liu <liulongfang@huawei.com>
Description: Read the live migration status of the vfio device.
The contents of the state file reflects the migration state
relative to those defined in the vfio_device_mig_state enum

View File

@ -98,6 +98,13 @@ Description:
# echo 1 > /sys/bus/cdx/devices/.../remove
What: /sys/bus/cdx/devices/.../resource<N>
Date: July 2023
Contact: puneet.gupta@amd.com
Description:
The resource binary file contains the content of the memory
regions. These files can be m'maped from userspace.
What: /sys/bus/cdx/devices/.../modalias
Date: July 2023
Contact: nipun.gupta@amd.com

View File

@ -91,3 +91,19 @@ Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Size of the trace buffer for TMC-ETR when used in SYSFS
mode. Writable only for TMC-ETR configurations. The value
should be aligned to the kernel pagesize.
What: /sys/bus/coresight/devices/<memory_map>.tmc/buf_modes_available
Date: August 2023
KernelVersion: 6.7
Contact: Anshuman Khandual <anshuman.khandual@arm.com>
Description: (Read) Shows all supported Coresight TMC-ETR buffer modes available
for the users to configure explicitly. This file is avaialble only
for TMC ETR devices.
What: /sys/bus/coresight/devices/<memory_map>.tmc/buf_mode_preferred
Date: August 2023
KernelVersion: 6.7
Contact: Anshuman Khandual <anshuman.khandual@arm.com>
Description: (RW) Current Coresight TMC-ETR buffer mode selected. But user could
only provide a mode which is supported for a given ETR device. This
file is available only for TMC ETR devices.

View File

@ -11,3 +11,162 @@ Description:
Accepts only one of the 2 values - 1 or 2.
1 : Generate 64 bits data
2 : Generate 32 bits data
What: /sys/bus/coresight/devices/<tpdm-name>/reset_dataset
Date: March 2023
KernelVersion 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(Write) Reset the dataset of the tpdm.
Accepts only one value - 1.
1 : Reset the dataset of the tpdm
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_type
Date: March 2023
KernelVersion 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the trigger type of the DSB for tpdm.
Accepts only one of the 2 values - 0 or 1.
0 : Set the DSB trigger type to false
1 : Set the DSB trigger type to true
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_ts
Date: March 2023
KernelVersion 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the trigger timestamp of the DSB for tpdm.
Accepts only one of the 2 values - 0 or 1.
0 : Set the DSB trigger type to false
1 : Set the DSB trigger type to true
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_mode
Date: March 2023
KernelVersion 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the programming mode of the DSB for tpdm.
Accepts the value needs to be greater than 0. What data
bits do is listed below.
Bit[0:1] : Test mode control bit for choosing the inputs.
Bit[3] : Set to 0 for low performance mode. Set to 1 for high
performance mode.
Bit[4:8] : Select byte lane for high performance mode.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/ctrl_idx
Date: March 2023
KernelVersion 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the index number of the edge detection for the DSB
subunit TPDM. Since there are at most 256 edge detections, this
value ranges from 0 to 255.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/ctrl_val
Date: March 2023
KernelVersion 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
Write a data to control the edge detection corresponding to
the index number. Before writing data to this sysfs file,
"ctrl_idx" should be written first to configure the index
number of the edge detection which needs to be controlled.
Accepts only one of the following values.
0 - Rising edge detection
1 - Falling edge detection
2 - Rising and falling edge detection (toggle detection)
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/ctrl_mask
Date: March 2023
KernelVersion 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
Write a data to mask the edge detection corresponding to the index
number. Before writing data to this sysfs file, "ctrl_idx" should
be written first to configure the index number of the edge detection
which needs to be masked.
Accepts only one of the 2 values - 0 or 1.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/edcr[0:15]
Date: March 2023
KernelVersion 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
Read a set of the edge control value of the DSB in TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/edcmr[0:7]
Date: March 2023
KernelVersion 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
Read a set of the edge control mask of the DSB in TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_patt/xpr[0:7]
Date: March 2023
KernelVersion 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the value of the trigger pattern for the DSB
subunit TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_patt/xpmr[0:7]
Date: March 2023
KernelVersion 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the mask of the trigger pattern for the DSB
subunit TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpr[0:7]
Date: March 2023
KernelVersion 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the value of the pattern for the DSB subunit TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpmr[0:7]
Date: March 2023
KernelVersion 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the mask of the pattern for the DSB subunit TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/enable_ts
Date: March 2023
KernelVersion 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(Write) Set the pattern timestamp of DSB tpdm. Read
the pattern timestamp of DSB tpdm.
Accepts only one of the 2 values - 0 or 1.
0 : Disable DSB pattern timestamp.
1 : Enable DSB pattern timestamp.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/set_type
Date: March 2023
KernelVersion 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(Write) Set the pattern type of DSB tpdm. Read
the pattern type of DSB tpdm.
Accepts only one of the 2 values - 0 or 1.
0 : Set the DSB pattern type to value.
1 : Set the DSB pattern type to toggle.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_msr/msr[0:31]
Date: March 2023
KernelVersion 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the MSR(mux select register) for the DSB subunit
TPDM.

View File

@ -28,6 +28,23 @@ Description:
Payload in the CXL-2.0 specification.
What: /sys/bus/cxl/devices/memX/ram/qos_class
Date: May, 2023
KernelVersion: v6.8
Contact: linux-cxl@vger.kernel.org
Description:
(RO) For CXL host platforms that support "QoS Telemmetry"
this attribute conveys a comma delimited list of platform
specific cookies that identifies a QoS performance class
for the volatile partition of the CXL mem device. These
class-ids can be compared against a similar "qos_class"
published for a root decoder. While it is not required
that the endpoints map their local memory-class to a
matching platform class, mismatches are not recommended
and there are platform specific performance related
side-effects that may result. First class-id is displayed.
What: /sys/bus/cxl/devices/memX/pmem/size
Date: December, 2020
KernelVersion: v5.12
@ -38,6 +55,23 @@ Description:
Payload in the CXL-2.0 specification.
What: /sys/bus/cxl/devices/memX/pmem/qos_class
Date: May, 2023
KernelVersion: v6.8
Contact: linux-cxl@vger.kernel.org
Description:
(RO) For CXL host platforms that support "QoS Telemmetry"
this attribute conveys a comma delimited list of platform
specific cookies that identifies a QoS performance class
for the persistent partition of the CXL mem device. These
class-ids can be compared against a similar "qos_class"
published for a root decoder. While it is not required
that the endpoints map their local memory-class to a
matching platform class, mismatches are not recommended
and there are platform specific performance related
side-effects that may result. First class-id is displayed.
What: /sys/bus/cxl/devices/memX/serial
Date: January, 2022
KernelVersion: v5.18

View File

@ -88,6 +88,21 @@ Description:
This entry describes the HDRCAP of the master controller
driving the bus.
What: /sys/bus/i3c/devices/i3c-<bus-id>/hotjoin
KernelVersion: 6.8
Contact: linux-i3c@vger.kernel.org
Description:
I3Cs Hot-Join mechanism allows an I3C Device to inform the
Active Controller that a newly-joined Target is present on the
I3C Bus and is ready to receive a Dynamic Address, in order to
become fully functional on the Bus. Hot-Join is used when the
Target is mounted on the same I3C bus and remains depowered
until needed or until the Target is physically inserted into the
I3C bus
This entry allows to enable or disable Hot-join of the Current
Controller driving the bus.
What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>
KernelVersion: 5.0
Contact: linux-i3c@vger.kernel.org

View File

@ -362,10 +362,21 @@ Description:
What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_peak_raw
What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_peak_raw
What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_peak_raw
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_peak_raw
What: /sys/bus/iio/devices/iio:deviceX/in_temp_peak_raw
KernelVersion: 2.6.36
Contact: linux-iio@vger.kernel.org
Description:
Highest value since some reset condition. These
Highest value since some reset condition. These
attributes allow access to this and are otherwise
the direct equivalent of the <type>Y[_name]_raw attributes.
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_trough_raw
What: /sys/bus/iio/devices/iio:deviceX/in_temp_trough_raw
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
Lowest value since some reset condition. These
attributes allow access to this and are otherwise
the direct equivalent of the <type>Y[_name]_raw attributes.
@ -618,7 +629,9 @@ KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
If a discrete set of scale values is available, they
are listed in this attribute.
are listed in this attribute. Unlike illumination,
multiplying intensity by intensity_scale does not
yield value with any standardized unit.
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_hardwaregain
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_hardwaregain
@ -1574,6 +1587,8 @@ What: /sys/.../iio:deviceX/in_intensityY_raw
What: /sys/.../iio:deviceX/in_intensityY_ir_raw
What: /sys/.../iio:deviceX/in_intensityY_both_raw
What: /sys/.../iio:deviceX/in_intensityY_uv_raw
What: /sys/.../iio:deviceX/in_intensityY_uva_raw
What: /sys/.../iio:deviceX/in_intensityY_uvb_raw
What: /sys/.../iio:deviceX/in_intensityY_duv_raw
KernelVersion: 3.4
Contact: linux-iio@vger.kernel.org
@ -1582,8 +1597,9 @@ Description:
that measurements contain visible and infrared light
components or just infrared light, respectively. Modifier
uv indicates that measurements contain ultraviolet light
components. Modifier duv indicates that measurements
contain deep ultraviolet light components.
components. Modifiers uva, uvb and duv indicate that
measurements contain A, B or deep (C) ultraviolet light
components respectively.
What: /sys/.../iio:deviceX/in_uvindex_input
KernelVersion: 4.6
@ -2254,3 +2270,21 @@ Description:
If a label is defined for this event add that to the event
specific attributes. This is useful for userspace to be able to
better identify an individual event.
What: /sys/.../events/in_accel_gesture_tap_wait_timeout
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
Enable tap gesture confirmation with timeout.
What: /sys/.../events/in_accel_gesture_tap_wait_dur
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
Timeout value in seconds for tap gesture confirmation.
What: /sys/.../events/in_accel_gesture_tap_wait_dur_available
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
List of available timeout value for tap gesture confirmation.

View File

@ -114,6 +114,45 @@ Description:
speed of 1000Mbps of the named network device.
Setting this value also immediately changes the LED state.
What: /sys/class/leds/<led>/link_2500
Date: Nov 2023
KernelVersion: 6.8
Contact: linux-leds@vger.kernel.org
Description:
Signal the link speed state of 2500Mbps of the named network device.
If set to 0 (default), the LED's normal state is off.
If set to 1, the LED's normal state reflects the link state
speed of 2500Mbps of the named network device.
Setting this value also immediately changes the LED state.
What: /sys/class/leds/<led>/link_5000
Date: Nov 2023
KernelVersion: 6.8
Contact: linux-leds@vger.kernel.org
Description:
Signal the link speed state of 5000Mbps of the named network device.
If set to 0 (default), the LED's normal state is off.
If set to 1, the LED's normal state reflects the link state
speed of 5000Mbps of the named network device.
Setting this value also immediately changes the LED state.
What: /sys/class/leds/<led>/link_10000
Date: Nov 2023
KernelVersion: 6.8
Contact: linux-leds@vger.kernel.org
Description:
Signal the link speed state of 10000Mbps of the named network device.
If set to 0 (default), the LED's normal state is off.
If set to 1, the LED's normal state reflects the link state
speed of 10000Mbps of the named network device.
Setting this value also immediately changes the LED state.
What: /sys/class/leds/<led>/half_duplex
Date: Jun 2023
KernelVersion: 6.5

View File

@ -4,3 +4,59 @@ KernelVersion: 5.10
Contact: linux-leds@vger.kernel.org
Description:
Specifies the tty device name of the triggering tty
What: /sys/class/leds/<led>/rx
Date: February 2024
KernelVersion: 6.8
Description:
Signal reception (rx) of data on the named tty device.
If set to 0, the LED will not blink on reception.
If set to 1 (default), the LED will blink on reception.
What: /sys/class/leds/<led>/tx
Date: February 2024
KernelVersion: 6.8
Description:
Signal transmission (tx) of data on the named tty device.
If set to 0, the LED will not blink on transmission.
If set to 1 (default), the LED will blink on transmission.
What: /sys/class/leds/<led>/cts
Date: February 2024
KernelVersion: 6.8
Description:
CTS = Clear To Send
DCE is ready to accept data from the DTE.
If the line state is detected, the LED is switched on.
If set to 0 (default), the LED will not evaluate CTS.
If set to 1, the LED will evaluate CTS.
What: /sys/class/leds/<led>/dsr
Date: February 2024
KernelVersion: 6.8
Description:
DSR = Data Set Ready
DCE is ready to receive and send data.
If the line state is detected, the LED is switched on.
If set to 0 (default), the LED will not evaluate DSR.
If set to 1, the LED will evaluate DSR.
What: /sys/class/leds/<led>/dcd
Date: February 2024
KernelVersion: 6.8
Description:
DCD = Data Carrier Detect
DTE is receiving a carrier from the DCE.
If the line state is detected, the LED is switched on.
If set to 0 (default), the LED will not evaluate CAR (DCD).
If set to 1, the LED will evaluate CAR (DCD).
What: /sys/class/leds/<led>/rng
Date: February 2024
KernelVersion: 6.8
Description:
RNG = Ring Indicator
DCE has detected an incoming ring signal on the telephone
line. If the line state is detected, the LED is switched on.
If set to 0 (default), the LED will not evaluate RNG.
If set to 1, the LED will evaluate RNG.

View File

@ -0,0 +1,8 @@
What: /sys/firmware/initrd
Date: December 2023
Contact: Alexander Graf <graf@amazon.com>
Description:
When the kernel was booted with an initrd and the
"retain_initrd" option is set on the kernel command
line, /sys/firmware/initrd contains the contents of the
initrd that the kernel was booted with.

View File

@ -0,0 +1,21 @@
What: /sys/bus/nvmem/devices/.../cells/<cell-name>
Date: May 2023
KernelVersion: 6.5
Contact: Miquel Raynal <miquel.raynal@bootlin.com>
Description:
The "cells" folder contains one file per cell exposed by the
NVMEM device. The name of the file is: <name>@<where>, with
<name> being the cell name and <where> its location in the NVMEM
device, in hexadecimal (without the '0x' prefix, to mimic device
tree node names). The length of the file is the size of the cell
(when known). The content of the file is the binary content of
the cell (may sometimes be ASCII, likely without trailing
character).
Note: This file is only present if CONFIG_NVMEM_SYSFS
is enabled.
Example::
hexdump -C /sys/bus/nvmem/devices/1-00563/cells/product-name@d
00000000 54 4e 34 38 4d 2d 50 2d 44 4e |TN48M-P-DN|
0000000a

View File

@ -61,7 +61,7 @@ Conditions
==========
The use of threaded interrupts is the most likely condition to trigger
this problem today. Threaded interrupts may not be reenabled after the IRQ
this problem today. Threaded interrupts may not be re-enabled after the IRQ
handler wakes. These "one shot" conditions mean that the threaded interrupt
needs to keep the interrupt line masked until the threaded handler has run.
Especially when dealing with high data rate interrupts, the thread needs to

View File

@ -236,7 +236,7 @@ including a full 'lspci -v' so we can add the quirks to the kernel.
Disabling MSIs below a bridge
-----------------------------
Some PCI bridges are not able to route MSIs between busses properly.
Some PCI bridges are not able to route MSIs between buses properly.
In this case, MSIs must be disabled on all devices behind the bridge.
Some bridges allow you to enable MSIs by changing some bits in their

View File

@ -75,4 +75,4 @@ taking two different snapshots of feedback counters at time T1 and T2.
delivered_counter_delta = fbc_t2[del] - fbc_t1[del]
reference_counter_delta = fbc_t2[ref] - fbc_t1[ref]
delivered_perf = (refernce_perf x delivered_counter_delta) / reference_counter_delta
delivered_perf = (reference_perf x delivered_counter_delta) / reference_counter_delta

View File

@ -2,7 +2,8 @@
TODO
====
Version 2.14 December 21, 2018
As of 6.7 kernel. See https://wiki.samba.org/index.php/LinuxCIFSKernel
for list of features added by release
A Partial List of Missing Features
==================================
@ -12,22 +13,22 @@ for visible, important contributions to this module. Here
is a partial list of the known problems and missing features:
a) SMB3 (and SMB3.1.1) missing optional features:
multichannel performance optimizations, algorithmic channel selection,
directory leases optimizations,
support for faster packet signing (GMAC),
support for compression over the network,
T10 copy offload ie "ODX" (copy chunk, and "Duplicate Extents" ioctl
are currently the only two server side copy mechanisms supported)
- multichannel (partially integrated), integration of multichannel with RDMA
- directory leases (improved metadata caching). Currently only implemented for root dir
- T10 copy offload ie "ODX" (copy chunk, and "Duplicate Extents" ioctl
currently the only two server side copy mechanisms supported)
b) Better optimized compounding and error handling for sparse file support,
perhaps addition of new optional SMB3.1.1 fsctls to make collapse range
and insert range more atomic
b) improved sparse file support (fiemap and SEEK_HOLE are implemented
but additional features would be supportable by the protocol such
as FALLOC_FL_COLLAPSE_RANGE and FALLOC_FL_INSERT_RANGE)
c) Directory entry caching relies on a 1 second timer, rather than
using Directory Leases, currently only the root file handle is cached longer
by leveraging Directory Leases
c) Support for SMB3.1.1 over QUIC (and perhaps other socket based protocols
like SCTP)
d) quota support (needs minor kernel change since quota calls otherwise
won't make it to network filesystems or deviceless filesystems).
won't make it to network filesystems or deviceless filesystems).
e) Additional use cases can be optimized to use "compounding" (e.g.
open/query/close and open/setinfo/close) to reduce the number of
@ -92,23 +93,20 @@ t) split cifs and smb3 support into separate modules so legacy (and less
v) Additional testing of POSIX Extensions for SMB3.1.1
w) Add support for additional strong encryption types, and additional spnego
authentication mechanisms (see MS-SMB2). GCM-256 is now partially implemented.
w) Support for the Mac SMB3.1.1 extensions to improve interop with Apple servers
x) Finish support for SMB3.1.1 compression
x) Support for additional authentication options (e.g. IAKERB, peer-to-peer
Kerberos, SCRAM and others supported by existing servers)
y) Improved tracing, more eBPF trace points, better scripts for performance
analysis
Known Bugs
==========
See https://bugzilla.samba.org - search on product "CifsVFS" for
current bug list. Also check http://bugzilla.kernel.org (Product = File System, Component = CIFS)
1) existing symbolic links (Windows reparse points) are recognized but
can not be created remotely. They are implemented for Samba and those that
support the CIFS Unix extensions, although earlier versions of Samba
overly restrict the pathnames.
2) follow_link and readdir code does not follow dfs junctions
but recognizes them
and xfstest results e.g. https://wiki.samba.org/index.php/Xfstest-results-smb3
Misc testing to do
==================

View File

@ -81,7 +81,7 @@ much older and less secure than the default dialect SMB3 which includes
many advanced security features such as downgrade attack detection
and encrypted shares and stronger signing and authentication algorithms.
There are additional mount options that may be helpful for SMB3 to get
improved POSIX behavior (NB: can use vers=3.0 to force only SMB3, never 2.1):
improved POSIX behavior (NB: can use vers=3 to force SMB3 or later, never 2.1):
``mfsymlinks`` and either ``cifsacl`` or ``modefromsid`` (usually with ``idsfromsid``)
@ -715,6 +715,7 @@ DebugData Displays information about active CIFS sessions and
Stats Lists summary resource usage information as well as per
share statistics.
open_files List all the open file handles on all active SMB sessions.
mount_params List of all mount parameters available for the module
======================= =======================================================
Configuration pseudo-files:
@ -864,6 +865,11 @@ i.e.::
echo "value" > /sys/module/cifs/parameters/<param>
More detailed descriptions of the available module parameters and their values
can be seen by doing:
modinfo cifs (or modinfo smb3)
================= ==========================================================
1. enable_oplocks Enable or disable oplocks. Oplocks are enabled by default.
[Y/y/1]. To disable use any of [N/n/0].

View File

@ -2704,6 +2704,9 @@
...
185 = /dev/ttyNX15 Hilscher netX serial port 15
186 = /dev/ttyJ0 JTAG1 DCC protocol based serial port emulation
If maximum number of uartlite serial ports is more than 4, then the driver
uses dynamic allocation instead of static allocation for major number.
187 = /dev/ttyUL0 Xilinx uartlite - port 0
...
190 = /dev/ttyUL3 Xilinx uartlite - port 3

View File

@ -888,9 +888,9 @@
memory region [offset, offset + size] for that kernel
image. If '@offset' is omitted, then a suitable offset
is selected automatically.
[KNL, X86-64, ARM64, RISCV] Select a region under 4G first, and
fall back to reserve region above 4G when '@offset'
hasn't been specified.
[KNL, X86-64, ARM64, RISCV, LoongArch] Select a region
under 4G first, and fall back to reserve region above
4G when '@offset' hasn't been specified.
See Documentation/admin-guide/kdump/kdump.rst for further details.
crashkernel=range1:size1[,range2:size2,...][@offset]
@ -901,25 +901,27 @@
Documentation/admin-guide/kdump/kdump.rst for an example.
crashkernel=size[KMG],high
[KNL, X86-64, ARM64, RISCV] range could be above 4G.
[KNL, X86-64, ARM64, RISCV, LoongArch] range could be
above 4G.
Allow kernel to allocate physical memory region from top,
so could be above 4G if system have more than 4G ram
installed. Otherwise memory region will be allocated
below 4G, if available.
It will be ignored if crashkernel=X is specified.
crashkernel=size[KMG],low
[KNL, X86-64, ARM64, RISCV] range under 4G. When crashkernel=X,high
is passed, kernel could allocate physical memory region
above 4G, that cause second kernel crash on system
that require some amount of low memory, e.g. swiotlb
requires at least 64M+32K low memory, also enough extra
low memory is needed to make sure DMA buffers for 32-bit
devices won't run out. Kernel would try to allocate
[KNL, X86-64, ARM64, RISCV, LoongArch] range under 4G.
When crashkernel=X,high is passed, kernel could allocate
physical memory region above 4G, that cause second kernel
crash on system that require some amount of low memory,
e.g. swiotlb requires at least 64M+32K low memory, also
enough extra low memory is needed to make sure DMA buffers
for 32-bit devices won't run out. Kernel would try to allocate
default size of memory below 4G automatically. The default
size is platform dependent.
--> x86: max(swiotlb_size_or_default() + 8MiB, 256MiB)
--> arm64: 128MiB
--> riscv: 128MiB
--> loongarch: 128MiB
This one lets the user specify own low range under 4G
for second kernel instead.
0: to disable low allocation.
@ -2449,7 +2451,7 @@
between unregistering the boot console and initializing
the real console.
keepinitrd [HW,ARM]
keepinitrd [HW,ARM] See retain_initrd.
kernelcore= [KNL,X86,IA-64,PPC]
Format: nn[KMGTPE] | nn% | "mirror"
@ -3996,9 +3998,9 @@
vulnerability. System may allow data leaks with this
option.
no-steal-acc [X86,PV_OPS,ARM64,PPC/PSERIES] Disable paravirtualized
steal time accounting. steal time is computed, but
won't influence scheduler behaviour
no-steal-acc [X86,PV_OPS,ARM64,PPC/PSERIES,RISCV] Disable
paravirtualized steal time accounting. steal time is
computed, but won't influence scheduler behaviour
nosync [HW,M68K] Disables sync negotiation for all devices.
@ -5604,7 +5606,8 @@
Useful for devices that are detected asynchronously
(e.g. USB and MMC devices).
retain_initrd [RAM] Keep initrd memory after extraction
retain_initrd [RAM] Keep initrd memory after extraction. After boot, it will
be accessible via /sys/firmware/initrd.
retbleed= [X86] Control mitigation of RETBleed (Arbitrary
Speculative Code Execution with Return Instructions)
@ -6932,6 +6935,9 @@
pause after every control message);
o = USB_QUIRK_HUB_SLOW_RESET (Hub needs extra
delay after resetting its port);
p = USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT
(Reduce timeout of the SET_ADDRESS
request from 5000 ms to 500 ms);
Example: quirks=0781:5580:bk,0a5c:5834:gij
usbhid.mousepoll=

View File

@ -361,7 +361,7 @@ Global Attributes
``amd-pstate`` exposes several global attributes (files) in ``sysfs`` to
control its functionality at the system level. They are located in the
``/sys/devices/system/cpu/amd-pstate/`` directory and affect all CPUs.
``/sys/devices/system/cpu/amd_pstate/`` directory and affect all CPUs.
``status``
Operation mode of the driver: "active", "passive" or "disable".

View File

@ -75,10 +75,19 @@ On other
submit a patch to be included in this section.
On all
Write a character to /proc/sysrq-trigger. e.g.::
Write a single character to /proc/sysrq-trigger.
Only the first character is processed, the rest of the string is
ignored. However, it is not recommended to write any extra characters
as the behavior is undefined and might change in the future versions.
E.g.::
echo t > /proc/sysrq-trigger
Alternatively, write multiple characters prepended by underscore.
This way, all characters will be processed. E.g.::
echo _reisub > /proc/sysrq-trigger
The :kbd:`<command key>` is case sensitive.
What are the 'command' keys?

View File

@ -71,6 +71,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2658417 | ARM64_ERRATUM_2658417 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #3117295 | ARM64_ERRATUM_3117295 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A520 | #2966298 | ARM64_ERRATUM_2966298 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
@ -117,6 +119,10 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A76 | #1463225 | ARM64_ERRATUM_1463225 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A76 | #1490853 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A77 | #1491015 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
@ -127,6 +133,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A715 | #2645198 | ARM64_ERRATUM_2645198 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X1 | #1502854 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 |
@ -135,6 +143,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N1 | #1349291 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N1 | #1490853 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N2 | #2139208 | ARM64_ERRATUM_2139208 |
@ -143,6 +153,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N2 | #2253138 | ARM64_ERRATUM_2253138 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V1 | #1619801 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | MMU-500 | #841119,826419 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | MMU-600 | #1076982,1209401| N/A |
@ -225,11 +237,9 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| Rockchip | RK3588 | #3588001 | ROCKCHIP_ERRATUM_3588001 |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| ASR | ASR8601 | #8601001 | N/A |
+----------------+-----------------+-----------------+-----------------------------+

View File

@ -10,6 +10,191 @@ encrypting the guest memory. In TDX, a special module running in a special
mode sits between the host and the guest and manages the guest/host
separation.
TDX Host Kernel Support
=======================
TDX introduces a new CPU mode called Secure Arbitration Mode (SEAM) and
a new isolated range pointed by the SEAM Ranger Register (SEAMRR). A
CPU-attested software module called 'the TDX module' runs inside the new
isolated range to provide the functionalities to manage and run protected
VMs.
TDX also leverages Intel Multi-Key Total Memory Encryption (MKTME) to
provide crypto-protection to the VMs. TDX reserves part of MKTME KeyIDs
as TDX private KeyIDs, which are only accessible within the SEAM mode.
BIOS is responsible for partitioning legacy MKTME KeyIDs and TDX KeyIDs.
Before the TDX module can be used to create and run protected VMs, it
must be loaded into the isolated range and properly initialized. The TDX
architecture doesn't require the BIOS to load the TDX module, but the
kernel assumes it is loaded by the BIOS.
TDX boot-time detection
-----------------------
The kernel detects TDX by detecting TDX private KeyIDs during kernel
boot. Below dmesg shows when TDX is enabled by BIOS::
[..] virt/tdx: BIOS enabled: private KeyID range: [16, 64)
TDX module initialization
---------------------------------------
The kernel talks to the TDX module via the new SEAMCALL instruction. The
TDX module implements SEAMCALL leaf functions to allow the kernel to
initialize it.
If the TDX module isn't loaded, the SEAMCALL instruction fails with a
special error. In this case the kernel fails the module initialization
and reports the module isn't loaded::
[..] virt/tdx: module not loaded
Initializing the TDX module consumes roughly ~1/256th system RAM size to
use it as 'metadata' for the TDX memory. It also takes additional CPU
time to initialize those metadata along with the TDX module itself. Both
are not trivial. The kernel initializes the TDX module at runtime on
demand.
Besides initializing the TDX module, a per-cpu initialization SEAMCALL
must be done on one cpu before any other SEAMCALLs can be made on that
cpu.
The kernel provides two functions, tdx_enable() and tdx_cpu_enable() to
allow the user of TDX to enable the TDX module and enable TDX on local
cpu respectively.
Making SEAMCALL requires VMXON has been done on that CPU. Currently only
KVM implements VMXON. For now both tdx_enable() and tdx_cpu_enable()
don't do VMXON internally (not trivial), but depends on the caller to
guarantee that.
To enable TDX, the caller of TDX should: 1) temporarily disable CPU
hotplug; 2) do VMXON and tdx_enable_cpu() on all online cpus; 3) call
tdx_enable(). For example::
cpus_read_lock();
on_each_cpu(vmxon_and_tdx_cpu_enable());
ret = tdx_enable();
cpus_read_unlock();
if (ret)
goto no_tdx;
// TDX is ready to use
And the caller of TDX must guarantee the tdx_cpu_enable() has been
successfully done on any cpu before it wants to run any other SEAMCALL.
A typical usage is do both VMXON and tdx_cpu_enable() in CPU hotplug
online callback, and refuse to online if tdx_cpu_enable() fails.
User can consult dmesg to see whether the TDX module has been initialized.
If the TDX module is initialized successfully, dmesg shows something
like below::
[..] virt/tdx: 262668 KBs allocated for PAMT
[..] virt/tdx: module initialized
If the TDX module failed to initialize, dmesg also shows it failed to
initialize::
[..] virt/tdx: module initialization failed ...
TDX Interaction to Other Kernel Components
------------------------------------------
TDX Memory Policy
~~~~~~~~~~~~~~~~~
TDX reports a list of "Convertible Memory Region" (CMR) to tell the
kernel which memory is TDX compatible. The kernel needs to build a list
of memory regions (out of CMRs) as "TDX-usable" memory and pass those
regions to the TDX module. Once this is done, those "TDX-usable" memory
regions are fixed during module's lifetime.
To keep things simple, currently the kernel simply guarantees all pages
in the page allocator are TDX memory. Specifically, the kernel uses all
system memory in the core-mm "at the time of TDX module initialization"
as TDX memory, and in the meantime, refuses to online any non-TDX-memory
in the memory hotplug.
Physical Memory Hotplug
~~~~~~~~~~~~~~~~~~~~~~~
Note TDX assumes convertible memory is always physically present during
machine's runtime. A non-buggy BIOS should never support hot-removal of
any convertible memory. This implementation doesn't handle ACPI memory
removal but depends on the BIOS to behave correctly.
CPU Hotplug
~~~~~~~~~~~
TDX module requires the per-cpu initialization SEAMCALL must be done on
one cpu before any other SEAMCALLs can be made on that cpu. The kernel
provides tdx_cpu_enable() to let the user of TDX to do it when the user
wants to use a new cpu for TDX task.
TDX doesn't support physical (ACPI) CPU hotplug. During machine boot,
TDX verifies all boot-time present logical CPUs are TDX compatible before
enabling TDX. A non-buggy BIOS should never support hot-add/removal of
physical CPU. Currently the kernel doesn't handle physical CPU hotplug,
but depends on the BIOS to behave correctly.
Note TDX works with CPU logical online/offline, thus the kernel still
allows to offline logical CPU and online it again.
Kexec()
~~~~~~~
TDX host support currently lacks the ability to handle kexec. For
simplicity only one of them can be enabled in the Kconfig. This will be
fixed in the future.
Erratum
~~~~~~~
The first few generations of TDX hardware have an erratum. A partial
write to a TDX private memory cacheline will silently "poison" the
line. Subsequent reads will consume the poison and generate a machine
check.
A partial write is a memory write where a write transaction of less than
cacheline lands at the memory controller. The CPU does these via
non-temporal write instructions (like MOVNTI), or through UC/WC memory
mappings. Devices can also do partial writes via DMA.
Theoretically, a kernel bug could do partial write to TDX private memory
and trigger unexpected machine check. What's more, the machine check
code will present these as "Hardware error" when they were, in fact, a
software-triggered issue. But in the end, this issue is hard to trigger.
If the platform has such erratum, the kernel prints additional message in
machine check handler to tell user the machine check may be caused by
kernel bug on TDX private memory.
Interaction vs S3 and deeper states
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TDX cannot survive from S3 and deeper states. The hardware resets and
disables TDX completely when platform goes to S3 and deeper. Both TDX
guests and the TDX module get destroyed permanently.
The kernel uses S3 for suspend-to-ram, and use S4 and deeper states for
hibernation. Currently, for simplicity, the kernel chooses to make TDX
mutually exclusive with S3 and hibernation.
The kernel disables TDX during early boot when hibernation support is
available::
[..] virt/tdx: initialization failed: Hibernation support is enabled
Add 'nohibernate' kernel command line to disable hibernation in order to
use TDX.
ACPI S3 is disabled during kernel early boot if TDX is enabled. The user
needs to turn off TDX in the BIOS in order to use S3.
TDX Guest Support
=================
Since the host cannot directly access guest registers or memory, much
normal functionality of a hypervisor must be moved into the guest. This is
implemented using a Virtualization Exception (#VE) that is handled by the
@ -20,7 +205,7 @@ TDX includes new hypercall-like mechanisms for communicating from the
guest to the hypervisor or the TDX module.
New TDX Exceptions
==================
------------------
TDX guests behave differently from bare-metal and traditional VMX guests.
In TDX guests, otherwise normal instructions or memory accesses can cause
@ -30,7 +215,7 @@ Instructions marked with an '*' conditionally cause exceptions. The
details for these instructions are discussed below.
Instruction-based #VE
---------------------
~~~~~~~~~~~~~~~~~~~~~
- Port I/O (INS, OUTS, IN, OUT)
- HLT
@ -41,7 +226,7 @@ Instruction-based #VE
- CPUID*
Instruction-based #GP
---------------------
~~~~~~~~~~~~~~~~~~~~~
- All VMX instructions: INVEPT, INVVPID, VMCLEAR, VMFUNC, VMLAUNCH,
VMPTRLD, VMPTRST, VMREAD, VMRESUME, VMWRITE, VMXOFF, VMXON
@ -52,7 +237,7 @@ Instruction-based #GP
- RDMSR*,WRMSR*
RDMSR/WRMSR Behavior
--------------------
~~~~~~~~~~~~~~~~~~~~
MSR access behavior falls into three categories:
@ -73,7 +258,7 @@ trapping and handling in the TDX module. Other than possibly being slow,
these MSRs appear to function just as they would on bare metal.
CPUID Behavior
--------------
~~~~~~~~~~~~~~
For some CPUID leaves and sub-leaves, the virtualized bit fields of CPUID
return values (in guest EAX/EBX/ECX/EDX) are configurable by the
@ -93,7 +278,7 @@ not know how to handle. The guest kernel may ask the hypervisor for the
value with a hypercall.
#VE on Memory Accesses
======================
----------------------
There are essentially two classes of TDX memory: private and shared.
Private memory receives full TDX protections. Its content is protected
@ -107,7 +292,7 @@ entries. This helps ensure that a guest does not place sensitive
information in shared memory, exposing it to the untrusted hypervisor.
#VE on Shared Memory
--------------------
~~~~~~~~~~~~~~~~~~~~
Access to shared mappings can cause a #VE. The hypervisor ultimately
controls whether a shared memory access causes a #VE, so the guest must be
@ -127,7 +312,7 @@ be careful not to access device MMIO regions unless it is also prepared to
handle a #VE.
#VE on Private Pages
--------------------
~~~~~~~~~~~~~~~~~~~~
An access to private mappings can also cause a #VE. Since all kernel
memory is also private memory, the kernel might theoretically need to
@ -145,7 +330,7 @@ The hypervisor is permitted to unilaterally move accepted pages to a
to handle the exception.
Linux #VE handler
=================
-----------------
Just like page faults or #GP's, #VE exceptions can be either handled or be
fatal. Typically, an unhandled userspace #VE results in a SIGSEGV.
@ -167,7 +352,7 @@ While the block is in place, any #VE is elevated to a double fault (#DF)
which is not recoverable.
MMIO handling
=============
-------------
In non-TDX VMs, MMIO is usually implemented by giving a guest access to a
mapping which will cause a VMEXIT on access, and then the hypervisor
@ -189,7 +374,7 @@ MMIO access via other means (like structure overlays) may result in an
oops.
Shared Memory Conversions
=========================
-------------------------
All TDX guest memory starts out as private at boot. This memory can not
be accessed by the hypervisor. However, some kernel users like device

View File

@ -6,17 +6,16 @@ Block io priorities
Intro
-----
With the introduction of cfq v3 (aka cfq-ts or time sliced cfq), basic io
priorities are supported for reads on files. This enables users to io nice
processes or process groups, similar to what has been possible with cpu
scheduling for ages. This document mainly details the current possibilities
with cfq; other io schedulers do not support io priorities thus far.
The io priority feature enables users to io nice processes or process groups,
similar to what has been possible with cpu scheduling for ages. Support for io
priorities is io scheduler dependent and currently supported by bfq and
mq-deadline.
Scheduling classes
------------------
CFQ implements three generic scheduling classes that determine how io is
served for a process.
Three generic scheduling classes are implemented for io priorities that
determine how io is served for a process.
IOPRIO_CLASS_RT: This is the realtime io class. This scheduling class is given
higher priority than any other in the system, processes from this class are

View File

@ -0,0 +1,477 @@
.. SPDX-License-Identifier: GPL-2.0-only
============
UAPI Checker
============
The UAPI checker (``scripts/check-uapi.sh``) is a shell script which
checks UAPI header files for userspace backwards-compatibility across
the git tree.
Options
=======
This section will describe the options with which ``check-uapi.sh``
can be run.
Usage::
check-uapi.sh [-b BASE_REF] [-p PAST_REF] [-j N] [-l ERROR_LOG] [-i] [-q] [-v]
Available options::
-b BASE_REF Base git reference to use for comparison. If unspecified or empty,
will use any dirty changes in tree to UAPI files. If there are no
dirty changes, HEAD will be used.
-p PAST_REF Compare BASE_REF to PAST_REF (e.g. -p v6.1). If unspecified or empty,
will use BASE_REF^1. Must be an ancestor of BASE_REF. Only headers
that exist on PAST_REF will be checked for compatibility.
-j JOBS Number of checks to run in parallel (default: number of CPU cores).
-l ERROR_LOG Write error log to file (default: no error log is generated).
-i Ignore ambiguous changes that may or may not break UAPI compatibility.
-q Quiet operation.
-v Verbose operation (print more information about each header being checked).
Environmental args::
ABIDIFF Custom path to abidiff binary
CC C compiler (default is "gcc")
ARCH Target architecture of C compiler (default is host arch)
Exit codes::
0) Success
1) ABI difference detected
2) Prerequisite not met
Examples
========
Basic Usage
-----------
First, let's try making a change to a UAPI header file that obviously
won't break userspace::
cat << 'EOF' | patch -l -p1
--- a/include/uapi/linux/acct.h
+++ b/include/uapi/linux/acct.h
@@ -21,7 +21,9 @@
#include <asm/param.h>
#include <asm/byteorder.h>
-/*
+#define FOO
+
+/*
* comp_t is a 16-bit "floating" point number with a 3-bit base 8
* exponent and a 13-bit fraction.
* comp2_t is 24-bit with 5-bit base 2 exponent and 20 bit fraction
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
EOF
Now, let's use the script to validate::
% ./scripts/check-uapi.sh
Installing user-facing UAPI headers from dirty tree... OK
Installing user-facing UAPI headers from HEAD... OK
Checking changes to UAPI headers between HEAD and dirty tree...
All 912 UAPI headers compatible with x86 appear to be backwards compatible
Let's add another change that *might* break userspace::
cat << 'EOF' | patch -l -p1
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -74,7 +74,7 @@ struct bpf_insn {
__u8 dst_reg:4; /* dest register */
__u8 src_reg:4; /* source register */
__s16 off; /* signed offset */
- __s32 imm; /* signed immediate constant */
+ __u32 imm; /* unsigned immediate constant */
};
/* Key of an a BPF_MAP_TYPE_LPM_TRIE entry */
EOF
The script will catch this::
% ./scripts/check-uapi.sh
Installing user-facing UAPI headers from dirty tree... OK
Installing user-facing UAPI headers from HEAD... OK
Checking changes to UAPI headers between HEAD and dirty tree...
==== ABI differences detected in include/linux/bpf.h from HEAD -> dirty tree ====
[C] 'struct bpf_insn' changed:
type size hasn't changed
1 data member change:
type of '__s32 imm' changed:
typedef name changed from __s32 to __u32 at int-ll64.h:27:1
underlying type 'int' changed:
type name changed from 'int' to 'unsigned int'
type size hasn't changed
==================================================================================
error - 1/912 UAPI headers compatible with x86 appear _not_ to be backwards compatible
In this case, the script is reporting the type change because it could
break a userspace program that passes in a negative number. Now, let's
say you know that no userspace program could possibly be using a negative
value in ``imm``, so changing to an unsigned type there shouldn't hurt
anything. You can pass the ``-i`` flag to the script to ignore changes
in which the userspace backwards compatibility is ambiguous::
% ./scripts/check-uapi.sh -i
Installing user-facing UAPI headers from dirty tree... OK
Installing user-facing UAPI headers from HEAD... OK
Checking changes to UAPI headers between HEAD and dirty tree...
All 912 UAPI headers compatible with x86 appear to be backwards compatible
Now, let's make a similar change that *will* break userspace::
cat << 'EOF' | patch -l -p1
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -71,8 +71,8 @@ enum {
struct bpf_insn {
__u8 code; /* opcode */
- __u8 dst_reg:4; /* dest register */
__u8 src_reg:4; /* source register */
+ __u8 dst_reg:4; /* dest register */
__s16 off; /* signed offset */
__s32 imm; /* signed immediate constant */
};
EOF
Since we're re-ordering an existing struct member, there's no ambiguity,
and the script will report the breakage even if you pass ``-i``::
% ./scripts/check-uapi.sh -i
Installing user-facing UAPI headers from dirty tree... OK
Installing user-facing UAPI headers from HEAD... OK
Checking changes to UAPI headers between HEAD and dirty tree...
==== ABI differences detected in include/linux/bpf.h from HEAD -> dirty tree ====
[C] 'struct bpf_insn' changed:
type size hasn't changed
2 data member changes:
'__u8 dst_reg' offset changed from 8 to 12 (in bits) (by +4 bits)
'__u8 src_reg' offset changed from 12 to 8 (in bits) (by -4 bits)
==================================================================================
error - 1/912 UAPI headers compatible with x86 appear _not_ to be backwards compatible
Let's commit the breaking change, then commit the innocuous change::
% git commit -m 'Breaking UAPI change' include/uapi/linux/bpf.h
[detached HEAD f758e574663a] Breaking UAPI change
1 file changed, 1 insertion(+), 1 deletion(-)
% git commit -m 'Innocuous UAPI change' include/uapi/linux/acct.h
[detached HEAD 2e87df769081] Innocuous UAPI change
1 file changed, 3 insertions(+), 1 deletion(-)
Now, let's run the script again with no arguments::
% ./scripts/check-uapi.sh
Installing user-facing UAPI headers from HEAD... OK
Installing user-facing UAPI headers from HEAD^1... OK
Checking changes to UAPI headers between HEAD^1 and HEAD...
All 912 UAPI headers compatible with x86 appear to be backwards compatible
It doesn't catch any breaking change because, by default, it only
compares ``HEAD`` to ``HEAD^1``. The breaking change was committed on
``HEAD~2``. If we wanted the search scope to go back further, we'd have to
use the ``-p`` option to pass a different past reference. In this case,
let's pass ``-p HEAD~2`` to the script so it checks UAPI changes between
``HEAD~2`` and ``HEAD``::
% ./scripts/check-uapi.sh -p HEAD~2
Installing user-facing UAPI headers from HEAD... OK
Installing user-facing UAPI headers from HEAD~2... OK
Checking changes to UAPI headers between HEAD~2 and HEAD...
==== ABI differences detected in include/linux/bpf.h from HEAD~2 -> HEAD ====
[C] 'struct bpf_insn' changed:
type size hasn't changed
2 data member changes:
'__u8 dst_reg' offset changed from 8 to 12 (in bits) (by +4 bits)
'__u8 src_reg' offset changed from 12 to 8 (in bits) (by -4 bits)
==============================================================================
error - 1/912 UAPI headers compatible with x86 appear _not_ to be backwards compatible
Alternatively, we could have also run with ``-b HEAD~``. This would set the
base reference to ``HEAD~`` so then the script would compare it to ``HEAD~^1``.
Architecture-specific Headers
-----------------------------
Consider this change::
cat << 'EOF' | patch -l -p1
--- a/arch/arm64/include/uapi/asm/sigcontext.h
+++ b/arch/arm64/include/uapi/asm/sigcontext.h
@@ -70,6 +70,7 @@ struct sigcontext {
struct _aarch64_ctx {
__u32 magic;
__u32 size;
+ __u32 new_var;
};
#define FPSIMD_MAGIC 0x46508001
EOF
This is a change to an arm64-specific UAPI header file. In this example, I'm
running the script from an x86 machine with an x86 compiler, so, by default,
the script only checks x86-compatible UAPI header files::
% ./scripts/check-uapi.sh
Installing user-facing UAPI headers from dirty tree... OK
Installing user-facing UAPI headers from HEAD... OK
No changes to UAPI headers were applied between HEAD and dirty tree
With an x86 compiler, we can't check header files in ``arch/arm64``, so the
script doesn't even try.
If we want to check the header file, we'll have to use an arm64 compiler and
set ``ARCH`` accordingly::
% CC=aarch64-linux-gnu-gcc ARCH=arm64 ./scripts/check-uapi.sh
Installing user-facing UAPI headers from dirty tree... OK
Installing user-facing UAPI headers from HEAD... OK
Checking changes to UAPI headers between HEAD and dirty tree...
==== ABI differences detected in include/asm/sigcontext.h from HEAD -> dirty tree ====
[C] 'struct _aarch64_ctx' changed:
type size changed from 64 to 96 (in bits)
1 data member insertion:
'__u32 new_var', at offset 64 (in bits) at sigcontext.h:73:1
-- snip --
[C] 'struct zt_context' changed:
type size changed from 128 to 160 (in bits)
2 data member changes (1 filtered):
'__u16 nregs' offset changed from 64 to 96 (in bits) (by +32 bits)
'__u16 __reserved[3]' offset changed from 80 to 112 (in bits) (by +32 bits)
=======================================================================================
error - 1/884 UAPI headers compatible with arm64 appear _not_ to be backwards compatible
We can see with ``ARCH`` and ``CC`` set properly for the file, the ABI
change is reported properly. Also notice that the total number of UAPI
header files checked by the script changes. This is because the number
of headers installed for arm64 platforms is different than x86.
Cross-Dependency Breakages
--------------------------
Consider this change::
cat << 'EOF' | patch -l -p1
--- a/include/uapi/linux/types.h
+++ b/include/uapi/linux/types.h
@@ -52,7 +52,7 @@ typedef __u32 __bitwise __wsum;
#define __aligned_be64 __be64 __attribute__((aligned(8)))
#define __aligned_le64 __le64 __attribute__((aligned(8)))
-typedef unsigned __bitwise __poll_t;
+typedef unsigned short __bitwise __poll_t;
#endif /* __ASSEMBLY__ */
#endif /* _UAPI_LINUX_TYPES_H */
EOF
Here, we're changing a ``typedef`` in ``types.h``. This doesn't break
a UAPI in ``types.h``, but other UAPIs in the tree may break due to
this change::
% ./scripts/check-uapi.sh
Installing user-facing UAPI headers from dirty tree... OK
Installing user-facing UAPI headers from HEAD... OK
Checking changes to UAPI headers between HEAD and dirty tree...
==== ABI differences detected in include/linux/eventpoll.h from HEAD -> dirty tree ====
[C] 'struct epoll_event' changed:
type size changed from 96 to 80 (in bits)
2 data member changes:
type of '__poll_t events' changed:
underlying type 'unsigned int' changed:
type name changed from 'unsigned int' to 'unsigned short int'
type size changed from 32 to 16 (in bits)
'__u64 data' offset changed from 32 to 16 (in bits) (by -16 bits)
========================================================================================
include/linux/eventpoll.h did not change between HEAD and dirty tree...
It's possible a change to one of the headers it includes caused this error:
#include <linux/fcntl.h>
#include <linux/types.h>
Note that the script noticed the failing header file did not change,
so it assumes one of its includes must have caused the breakage. Indeed,
we can see ``linux/types.h`` is used from ``eventpoll.h``.
UAPI Header Removals
--------------------
Consider this change::
cat << 'EOF' | patch -l -p1
diff --git a/include/uapi/asm-generic/Kbuild b/include/uapi/asm-generic/Kbuild
index ebb180aac74e..a9c88b0a8b3b 100644
--- a/include/uapi/asm-generic/Kbuild
+++ b/include/uapi/asm-generic/Kbuild
@@ -31,6 +31,6 @@ mandatory-y += stat.h
mandatory-y += statfs.h
mandatory-y += swab.h
mandatory-y += termbits.h
-mandatory-y += termios.h
+#mandatory-y += termios.h
mandatory-y += types.h
mandatory-y += unistd.h
EOF
This script removes a UAPI header file from the install list. Let's run
the script::
% ./scripts/check-uapi.sh
Installing user-facing UAPI headers from dirty tree... OK
Installing user-facing UAPI headers from HEAD... OK
Checking changes to UAPI headers between HEAD and dirty tree...
==== UAPI header include/asm/termios.h was removed between HEAD and dirty tree ====
error - 1/912 UAPI headers compatible with x86 appear _not_ to be backwards compatible
Removing a UAPI header is considered a breaking change, and the script
will flag it as such.
Checking Historic UAPI Compatibility
------------------------------------
You can use the ``-b`` and ``-p`` options to examine different chunks of your
git tree. For example, to check all changed UAPI header files between tags
v6.0 and v6.1, you'd run::
% ./scripts/check-uapi.sh -b v6.1 -p v6.0
Installing user-facing UAPI headers from v6.1... OK
Installing user-facing UAPI headers from v6.0... OK
Checking changes to UAPI headers between v6.0 and v6.1...
--- snip ---
error - 37/907 UAPI headers compatible with x86 appear _not_ to be backwards compatible
Note: Before v5.3, a header file needed by the script is not present,
so the script is unable to check changes before then.
You'll notice that the script detected many UAPI changes that are not
backwards compatible. Knowing that kernel UAPIs are supposed to be stable
forever, this is an alarming result. This brings us to the next section:
caveats.
Caveats
=======
The UAPI checker makes no assumptions about the author's intention, so some
types of changes may be flagged even though they intentionally break UAPI.
Removals For Refactoring or Deprecation
---------------------------------------
Sometimes drivers for very old hardware are removed, such as in this example::
% ./scripts/check-uapi.sh -b ba47652ba655
Installing user-facing UAPI headers from ba47652ba655... OK
Installing user-facing UAPI headers from ba47652ba655^1... OK
Checking changes to UAPI headers between ba47652ba655^1 and ba47652ba655...
==== UAPI header include/linux/meye.h was removed between ba47652ba655^1 and ba47652ba655 ====
error - 1/910 UAPI headers compatible with x86 appear _not_ to be backwards compatible
The script will always flag removals (even if they're intentional).
Struct Expansions
-----------------
Depending on how a structure is handled in kernelspace, a change which
expands a struct could be non-breaking.
If a struct is used as the argument to an ioctl, then the kernel driver
must be able to handle ioctl commands of any size. Beyond that, you need
to be careful when copying data from the user. Say, for example, that
``struct foo`` is changed like this::
struct foo {
__u64 a; /* added in version 1 */
+ __u32 b; /* added in version 2 */
+ __u32 c; /* added in version 2 */
}
By default, the script will flag this kind of change for further review::
[C] 'struct foo' changed:
type size changed from 64 to 128 (in bits)
2 data member insertions:
'__u32 b', at offset 64 (in bits)
'__u32 c', at offset 96 (in bits)
However, it is possible that this change was made safely.
If a userspace program was built with version 1, it will think
``sizeof(struct foo)`` is 8. That size will be encoded in the
ioctl value that gets sent to the kernel. If the kernel is built
with version 2, it will think the ``sizeof(struct foo)`` is 16.
The kernel can use the ``_IOC_SIZE`` macro to get the size encoded
in the ioctl code that the user passed in and then use
``copy_struct_from_user()`` to safely copy the value::
int handle_ioctl(unsigned long cmd, unsigned long arg)
{
switch _IOC_NR(cmd) {
0x01: {
struct foo my_cmd; /* size 16 in the kernel */
ret = copy_struct_from_user(&my_cmd, arg, sizeof(struct foo), _IOC_SIZE(cmd));
...
``copy_struct_from_user`` will zero the struct in the kernel and then copy
only the bytes passed in from the user (leaving new members zeroized).
If the user passed in a larger struct, the extra members are ignored.
If you know this situation is accounted for in the kernel code, you can
pass ``-i`` to the script, and struct expansions like this will be ignored.
Flex Array Migration
--------------------
While the script handles expansion into an existing flex array, it does
still flag initial migration to flex arrays from 1-element fake flex
arrays. For example::
struct foo {
__u32 x;
- __u32 flex[1]; /* fake flex */
+ __u32 flex[]; /* real flex */
};
This change would be flagged by the script::
[C] 'struct foo' changed:
type size changed from 64 to 32 (in bits)
1 data member change:
type of '__u32 flex[1]' changed:
type name changed from '__u32[1]' to '__u32[]'
array type size changed from 32 to 'unknown'
array type subrange 1 changed length from 1 to 'unknown'
At this time, there's no way to filter these types of changes, so be
aware of this possible false positive.
Summary
-------
While many types of false positives are filtered out by the script,
it's possible there are some cases where the script flags a change
which does not break UAPI. It's also possible a change which *does*
break userspace would not be flagged by this script. While the script
has been run on much of the kernel history, there could still be corner
cases that are not accounted for.
The intention is for this script to be used as a quick check for
maintainers or automated tooling, not as the end-all authority on
patch compatibility. It's best to remember: use your best judgment
(and ideally a unit test in userspace) to make sure your UAPI changes
are backwards-compatible!

View File

@ -31,6 +31,7 @@ Documentation/dev-tools/testing-overview.rst
kselftest
kunit/index
ktap
checkuapi
.. only:: subproject and html

View File

@ -44,6 +44,23 @@ properties:
minItems: 1
maxItems: 2
qcom,dsb-element-size:
description:
Specifies the DSB(Discrete Single Bit) element size supported by
the monitor. The associated aggregator will read this size before it
is enabled. DSB element size currently only supports 32-bit and 64-bit.
$ref: /schemas/types.yaml#/definitions/uint8
enum: [32, 64]
qcom,dsb-msrs-num:
description:
Specifies the number of DSB(Discrete Single Bit) MSR(mux select register)
registers supported by the monitor. If this property is not configured
or set to 0, it means this DSB TPDM doesn't support MSR.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 32
clocks:
maxItems: 1
@ -77,6 +94,9 @@ examples:
compatible = "qcom,coresight-tpdm", "arm,primecell";
reg = <0x0684c000 0x1000>;
qcom,dsb-element-size = /bits/ 8 <32>;
qcom,dsb-msrs-num = <16>;
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";

View File

@ -66,7 +66,6 @@ properties:
Particularly, if use an output GPIO to control a VBUS regulator, should
model it as a regulator. See bindings/regulator/fixed-regulator.yaml
# The following are optional properties for "usb-c-connector".
power-role:
description: Determines the power role that the Type C connector will
support. "dual" refers to Dual Role Port (DRP).
@ -119,30 +118,6 @@ properties:
# The following are optional properties for "usb-c-connector" with power
# delivery support.
source-pdos:
description: An array of u32 with each entry providing supported power
source data object(PDO), the detailed bit definitions of PDO can be found
in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
Source_Capabilities Message, the order of each entry(PDO) should follow
the PD spec chapter 6.4.1. Required for power source and power dual role.
User can specify the source PDO array via PDO_FIXED/BATT/VAR/PPS_APDO()
defined in dt-bindings/usb/pd.h.
minItems: 1
maxItems: 7
$ref: /schemas/types.yaml#/definitions/uint32-array
sink-pdos:
description: An array of u32 with each entry providing supported power sink
data object(PDO), the detailed bit definitions of PDO can be found in
"Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3
Sink Capabilities Message, the order of each entry(PDO) should follow the
PD spec chapter 6.4.1. Required for power sink and power dual role. User
can specify the sink PDO array via PDO_FIXED/BATT/VAR/PPS_APDO() defined
in dt-bindings/usb/pd.h.
minItems: 1
maxItems: 7
$ref: /schemas/types.yaml#/definitions/uint32-array
sink-vdos:
description: An array of u32 with each entry, a Vendor Defined Message Object (VDO),
providing additional information corresponding to the product, the detailed bit
@ -166,10 +141,43 @@ properties:
maxItems: 6
$ref: /schemas/types.yaml#/definitions/uint32-array
op-sink-microwatt:
description: Sink required operating power in microwatt, if source can't
offer the power, Capability Mismatch is set. Required for power sink and
power dual role.
accessory-mode-audio:
type: boolean
description: Whether the device supports Audio Adapter Accessory Mode. This
is only necessary if there are no other means to discover supported
alternative modes (e.g. through the UCSI firmware interface).
accessory-mode-debug:
type: boolean
description: Whether the device supports Debug Accessory Mode. This
is only necessary if there are no other means to discover supported
alternative modes (e.g. through the UCSI firmware interface).
altmodes:
type: object
description: List of Alternative Modes supported by the schematics on the
particular device. This is only necessary if there are no other means to
discover supported alternative modes (e.g. through the UCSI firmware
interface).
additionalProperties: false
patternProperties:
"^(displayport)$":
type: object
description:
A single USB-C Alternative Mode as supported by the USB-C connector logic.
additionalProperties: false
properties:
svid:
$ref: /schemas/types.yaml#/definitions/uint16
description: Unique value assigned by USB-IF to the Vendor / AltMode.
enum: [ 0xff01 ]
vdo:
$ref: /schemas/types.yaml#/definitions/uint32
description: VDO returned by Discover Modes USB PD command.
port:
$ref: /schemas/graph.yaml#/properties/port
@ -231,6 +239,20 @@ properties:
SNK_READY for non-pd link.
type: boolean
capabilities:
description: A child node to contain all the selectable USB Power Delivery capabilities.
type: object
patternProperties:
"^caps-[0-9]+$":
description: Child nodes under "capabilities" node. Each node contains a selectable USB
Power Delivery capability.
type: object
$ref: "#/$defs/capabilities"
unevaluatedProperties: false
additionalProperties: false
dependencies:
sink-vdos-v1: [ sink-vdos ]
sink-vdos: [ sink-vdos-v1 ]
@ -238,7 +260,42 @@ dependencies:
required:
- compatible
$defs:
capabilities:
type: object
properties:
source-pdos:
description: An array of u32 with each entry providing supported power
source data object(PDO), the detailed bit definitions of PDO can be found
in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
Source_Capabilities Message, the order of each entry(PDO) should follow
the PD spec chapter 6.4.1. Required for power source and power dual role.
User can specify the source PDO array via PDO_FIXED/BATT/VAR/PPS_APDO()
defined in dt-bindings/usb/pd.h.
minItems: 1
maxItems: 7
$ref: /schemas/types.yaml#/definitions/uint32-array
sink-pdos:
description: An array of u32 with each entry providing supported power sink
data object(PDO), the detailed bit definitions of PDO can be found in
"Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3
Sink Capabilities Message, the order of each entry(PDO) should follow the
PD spec chapter 6.4.1. Required for power sink and power dual role. User
can specify the sink PDO array via PDO_FIXED/BATT/VAR/PPS_APDO() defined
in dt-bindings/usb/pd.h.
minItems: 1
maxItems: 7
$ref: /schemas/types.yaml#/definitions/uint32-array
op-sink-microwatt:
description: Sink required operating power in microwatt, if source can't
offer the power, Capability Mismatch is set. Required for power sink and
power dual role.
allOf:
- $ref: "#/$defs/capabilities"
- if:
properties:
compatible:
@ -267,7 +324,7 @@ anyOf:
- typec-power-opmode
- new-source-frs-typec-current
additionalProperties: false
unevaluatedProperties: false
examples:
# Micro-USB connector with HS lines routed via controller (MUIC).
@ -289,6 +346,13 @@ examples:
compatible = "usb-c-connector";
label = "USB-C";
altmodes {
displayport {
svid = /bits/ 16 <0xff01>;
vdo = <0x00001c46>;
};
};
ports {
#address-cells = <1>;
#size-cells = <0>;

View File

@ -19,19 +19,4 @@ properties:
additionalProperties: true
examples:
- |
dma: dma-controller@48000000 {
compatible = "ti,omap-sdma";
reg = <0x48000000 0x1000>;
interrupts = <0 12 0x4>,
<0 13 0x4>,
<0 14 0x4>,
<0 15 0x4>;
#dma-cells = <1>;
dma-channels = <32>;
dma-requests = <127>;
dma-channel-mask = <0xfffe>;
};
...

View File

@ -40,15 +40,4 @@ required:
additionalProperties: true
examples:
- |
sdma_xbar: dma-router@4a002b78 {
compatible = "ti,dra7-dma-crossbar";
reg = <0x4a002b78 0xfc>;
#dma-cells = <1>;
dma-requests = <205>;
ti,dma-safe-map = <0>;
dma-masters = <&sdma>;
};
...

View File

@ -0,0 +1,62 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/loongson,ls2x-apbdma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Loongson LS2X APB DMA controller
description:
The Loongson LS2X APB DMA controller is used for transferring data
between system memory and the peripherals on the APB bus.
maintainers:
- Binbin Zhou <zhoubinbin@loongson.cn>
allOf:
- $ref: dma-controller.yaml#
properties:
compatible:
oneOf:
- const: loongson,ls2k1000-apbdma
- items:
- const: loongson,ls2k0500-apbdma
- const: loongson,ls2k1000-apbdma
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
'#dma-cells':
const: 1
required:
- compatible
- reg
- interrupts
- clocks
- '#dma-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/clock/loongson,ls2k-clk.h>
dma-controller@1fe00c00 {
compatible = "loongson,ls2k1000-apbdma";
reg = <0x1fe00c00 0x8>;
interrupt-parent = <&liointc1>;
interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk LOONGSON2_APB_CLK>;
#dma-cells = <1>;
};
...

View File

@ -53,6 +53,9 @@ properties:
ADMA_CHn_CTRL register.
const: 1
dma-channel-mask:
maxItems: 1
required:
- compatible
- reg

View File

@ -32,6 +32,8 @@ properties:
- qcom,sm8350-gpi-dma
- qcom,sm8450-gpi-dma
- qcom,sm8550-gpi-dma
- qcom,sm8650-gpi-dma
- qcom,x1e80100-gpi-dma
- const: qcom,sm6350-gpi-dma
- items:
- enum:

View File

@ -16,7 +16,7 @@ properties:
compatible:
items:
- enum:
- renesas,r9a07g043-dmac # RZ/G2UL
- renesas,r9a07g043-dmac # RZ/G2UL and RZ/Five
- renesas,r9a07g044-dmac # RZ/G2{L,LC}
- renesas,r9a07g054-dmac # RZ/V2L
- const: renesas,rz-dmac

View File

@ -29,6 +29,7 @@ properties:
compatible:
items:
- enum:
- microchip,mpfs-pdma
- sifive,fu540-c000-pdma
- const: sifive,pdma0
description:

View File

@ -37,11 +37,11 @@ properties:
reg:
minItems: 3
maxItems: 5
maxItems: 9
reg-names:
minItems: 3
maxItems: 5
maxItems: 9
"#dma-cells":
const: 3
@ -141,7 +141,10 @@ allOf:
ti,sci-rm-range-tchan: false
reg:
maxItems: 3
items:
- description: BCDMA Control /Status Registers region
- description: RX Channel Realtime Registers region
- description: Ring Realtime Registers region
reg-names:
items:
@ -161,14 +164,29 @@ allOf:
properties:
reg:
minItems: 5
items:
- description: BCDMA Control /Status Registers region
- description: Block Copy Channel Realtime Registers region
- description: RX Channel Realtime Registers region
- description: TX Channel Realtime Registers region
- description: Ring Realtime Registers region
- description: Ring Configuration Registers region
- description: TX Channel Configuration Registers region
- description: RX Channel Configuration Registers region
- description: Block Copy Channel Configuration Registers region
reg-names:
minItems: 5
items:
- const: gcfg
- const: bchanrt
- const: rchanrt
- const: tchanrt
- const: ringrt
- const: ring
- const: tchan
- const: rchan
- const: bchan
required:
- ti,sci-rm-range-bchan
@ -184,7 +202,11 @@ allOf:
ti,sci-rm-range-bchan: false
reg:
maxItems: 4
items:
- description: BCDMA Control /Status Registers region
- description: RX Channel Realtime Registers region
- description: TX Channel Realtime Registers region
- description: Ring Realtime Registers region
reg-names:
items:
@ -220,8 +242,13 @@ examples:
<0x0 0x4c000000 0x0 0x20000>,
<0x0 0x4a820000 0x0 0x20000>,
<0x0 0x4aa40000 0x0 0x20000>,
<0x0 0x4bc00000 0x0 0x100000>;
reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt";
<0x0 0x4bc00000 0x0 0x100000>,
<0x0 0x48600000 0x0 0x8000>,
<0x0 0x484a4000 0x0 0x2000>,
<0x0 0x484c2000 0x0 0x2000>,
<0x0 0x48420000 0x0 0x2000>;
reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt", "ringrt",
"ring", "tchan", "rchan", "bchan";
msi-parent = <&inta_main_dmss>;
#dma-cells = <3>;

View File

@ -45,14 +45,28 @@ properties:
The second cell is the ASEL value for the channel
reg:
maxItems: 4
minItems: 4
items:
- description: Packet DMA Control /Status Registers region
- description: RX Channel Realtime Registers region
- description: TX Channel Realtime Registers region
- description: Ring Realtime Registers region
- description: Ring Configuration Registers region
- description: TX Configuration Registers region
- description: RX Configuration Registers region
- description: RX Flow Configuration Registers region
reg-names:
minItems: 4
items:
- const: gcfg
- const: rchanrt
- const: tchanrt
- const: ringrt
- const: ring
- const: tchan
- const: rchan
- const: rflow
msi-parent: true
@ -136,8 +150,14 @@ examples:
reg = <0x0 0x485c0000 0x0 0x100>,
<0x0 0x4a800000 0x0 0x20000>,
<0x0 0x4aa00000 0x0 0x40000>,
<0x0 0x4b800000 0x0 0x400000>;
reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
<0x0 0x4b800000 0x0 0x400000>,
<0x0 0x485e0000 0x0 0x20000>,
<0x0 0x484a0000 0x0 0x4000>,
<0x0 0x484c0000 0x0 0x2000>,
<0x0 0x48430000 0x0 0x4000>;
reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt",
"ring", "tchan", "rchan", "rflow";
msi-parent = <&inta_main_dmss>;
#dma-cells = <2>;

View File

@ -69,13 +69,24 @@ properties:
- ti,j721e-navss-mcu-udmap
reg:
maxItems: 3
minItems: 3
items:
- description: UDMA-P Control /Status Registers region
- description: RX Channel Realtime Registers region
- description: TX Channel Realtime Registers region
- description: TX Configuration Registers region
- description: RX Configuration Registers region
- description: RX Flow Configuration Registers region
reg-names:
minItems: 3
items:
- const: gcfg
- const: rchanrt
- const: tchanrt
- const: tchan
- const: rchan
- const: rflow
msi-parent: true
@ -158,8 +169,11 @@ examples:
compatible = "ti,am654-navss-main-udmap";
reg = <0x0 0x31150000 0x0 0x100>,
<0x0 0x34000000 0x0 0x100000>,
<0x0 0x35000000 0x0 0x100000>;
reg-names = "gcfg", "rchanrt", "tchanrt";
<0x0 0x35000000 0x0 0x100000>,
<0x0 0x30b00000 0x0 0x20000>,
<0x0 0x30c00000 0x0 0x8000>,
<0x0 0x30d00000 0x0 0x4000>;
reg-names = "gcfg", "rchanrt", "tchanrt", "tchan", "rchan", "rflow";
#dma-cells = <1>;
ti,ringacc = <&ringacc>;

View File

@ -123,6 +123,7 @@ properties:
- enum:
- onnn,cat24c04
- onnn,cat24c05
- rohm,br24g04
- const: atmel,24c04
- items:
- const: renesas,r1ex24016

View File

@ -126,7 +126,7 @@ examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
gpio@e000a000 {
gpio@a0020000 {
compatible = "xlnx,xps-gpio-1.00.a";
reg = <0xa0020000 0x10000>;
#gpio-cells = <2>;

View File

@ -19,6 +19,7 @@ allOf:
- st,stm32f7-i2c
- st,stm32mp13-i2c
- st,stm32mp15-i2c
- st,stm32mp25-i2c
then:
properties:
i2c-scl-rising-time-ns:
@ -41,6 +42,30 @@ allOf:
clock-frequency:
enum: [100000, 400000]
- if:
properties:
compatible:
contains:
enum:
- st,stm32f4-i2c
- st,stm32f7-i2c
- st,stm32mp13-i2c
- st,stm32mp15-i2c
then:
properties:
interrupts:
minItems: 2
interrupt-names:
minItems: 2
else:
properties:
interrupts:
maxItems: 1
interrupt-names:
maxItems: 1
properties:
compatible:
enum:
@ -48,6 +73,7 @@ properties:
- st,stm32f7-i2c
- st,stm32mp13-i2c
- st,stm32mp15-i2c
- st,stm32mp25-i2c
reg:
maxItems: 1
@ -56,11 +82,13 @@ properties:
items:
- description: interrupt ID for I2C event
- description: interrupt ID for I2C error
minItems: 1
interrupt-names:
items:
- const: event
- const: error
minItems: 1
resets:
maxItems: 1

View File

@ -4,36 +4,92 @@
$id: http://devicetree.org/schemas/iio/adc/adi,ad7091r5.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices AD7091R5 4-Channel 12-Bit ADC
title: Analog Devices AD7091R-2/-4/-5/-8 Multi-Channel 12-Bit ADCs
maintainers:
- Michael Hennerich <michael.hennerich@analog.com>
- Marcelo Schmitt <marcelo.schmitt@analog.com>
description: |
Analog Devices AD7091R5 4-Channel 12-Bit ADC
Analog Devices AD7091R5 4-Channel 12-Bit ADC supporting I2C interface
https://www.analog.com/media/en/technical-documentation/data-sheets/ad7091r-5.pdf
Analog Devices AD7091R-2/AD7091R-4/AD7091R-8 2-/4-/8-Channel 12-Bit ADCs
supporting SPI interface
https://www.analog.com/media/en/technical-documentation/data-sheets/AD7091R-2_7091R-4_7091R-8.pdf
properties:
compatible:
enum:
- adi,ad7091r2
- adi,ad7091r4
- adi,ad7091r5
- adi,ad7091r8
reg:
maxItems: 1
vdd-supply:
description:
Provide VDD power to the sensor (VDD range is from 2.7V to 5.25V).
vdrive-supply:
description:
Determines the voltage level at which the interface logic will operate.
The V_drive voltage range is from 1.8V to 5.25V and must not exceed VDD by
more than 0.3V.
vref-supply:
description:
Phandle to the vref power supply
interrupts:
convst-gpios:
description:
GPIO connected to the CONVST pin.
This logic input is used to initiate conversions on the analog
input channels.
maxItems: 1
reset-gpios:
maxItems: 1
interrupts:
description:
Interrupt for signaling when conversion results exceed the high limit for
ADC readings or fall below the low limit for them. Interrupt source must
be attached to ALERT/BUSY/GPO0 pin.
maxItems: 1
required:
- compatible
- reg
additionalProperties: false
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
# AD7091R-2 does not have ALERT/BUSY/GPO pin
- if:
properties:
compatible:
contains:
enum:
- adi,ad7091r2
then:
properties:
interrupts: false
- if:
properties:
compatible:
contains:
enum:
- adi,ad7091r2
- adi,ad7091r4
- adi,ad7091r8
then:
required:
- convst-gpios
unevaluatedProperties: false
examples:
- |
@ -51,4 +107,22 @@ examples:
interrupt-parent = <&gpio>;
};
};
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
adc@0 {
compatible = "adi,ad7091r8";
reg = <0x0>;
spi-max-frequency = <1000000>;
vref-supply = <&adc_vref>;
convst-gpios = <&gpio 25 GPIO_ACTIVE_LOW>;
reset-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
interrupts = <22 IRQ_TYPE_EDGE_FALLING>;
interrupt-parent = <&gpio>;
};
};
...

View File

@ -0,0 +1,139 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/adc/maxim,max34408.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Maxim MAX34408/MAX34409 current monitors with overcurrent control
maintainers:
- Ivan Mikhaylov <fr0st61te@gmail.com>
description: |
The MAX34408/MAX34409 are two- and four-channel current monitors that are
configured and monitored with a standard I2C/SMBus serial interface. Each
unidirectional current sensor offers precision high-side operation with a
low full-scale sense voltage. The devices automatically sequence through
two or four channels and collect the current-sense samples and average them
to reduce the effect of impulse noise. The raw ADC samples are compared to
user-programmable digital thresholds to indicate overcurrent conditions.
Overcurrent conditions trigger a hardware output to provide an immediate
indication to shut down any necessary external circuitry.
Specifications about the devices can be found at:
https://www.analog.com/media/en/technical-documentation/data-sheets/MAX34408-MAX34409.pdf
properties:
compatible:
enum:
- maxim,max34408
- maxim,max34409
"#address-cells":
const: 1
"#size-cells":
const: 0
reg:
maxItems: 1
interrupts:
maxItems: 1
powerdown-gpios:
description:
Shutdown Output. Open-drain output. This output transitions to high impedance
when any of the digital comparator thresholds are exceeded as long as the ENA
pin is high.
maxItems: 1
powerdown-status-gpios:
description:
SHTDN Enable Input. CMOS digital input. Connect to GND to clear the latch and
unconditionally deassert (force low) the SHTDN output and reset the shutdown
delay. Connect to VDD to enable normal latch operation of the SHTDN output.
maxItems: 1
vdd-supply: true
patternProperties:
"^channel@[0-3]$":
$ref: adc.yaml
type: object
description:
Represents the internal channels of the ADC.
properties:
reg:
items:
- minimum: 0
maximum: 3
maxim,rsense-val-micro-ohms:
description:
Adjust the Rsense value to monitor higher or lower current levels for
input.
enum: [250, 500, 1000, 5000, 10000, 50000, 100000, 200000, 500000]
default: 1000
required:
- reg
- maxim,rsense-val-micro-ohms
unevaluatedProperties: false
required:
- compatible
- reg
allOf:
- if:
properties:
compatible:
contains:
const: maxim,max34408
then:
patternProperties:
"^channel@[2-3]$": false
"^channel@[0-1]$":
properties:
reg:
maximum: 1
else:
patternProperties:
"^channel@[0-3]$":
properties:
reg:
maximum: 3
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
adc@1e {
compatible = "maxim,max34409";
reg = <0x1e>;
powerdown-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
powerdown-status-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
channel@0 {
reg = <0x0>;
maxim,rsense-val-micro-ohms = <5000>;
};
channel@1 {
reg = <0x1>;
maxim,rsense-val-micro-ohms = <10000>;
};
};
};

View File

@ -25,7 +25,7 @@ properties:
- const: qcom,spmi-iadc
reg:
description: IADC base address and length in the SPMI PMIC register map
description: IADC base address in the SPMI PMIC register map
maxItems: 1
qcom,external-resistor-micro-ohms:
@ -50,10 +50,12 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
spmi {
pmic {
#address-cells = <1>;
#size-cells = <0>;
pmic_iadc: adc@3600 {
adc@3600 {
compatible = "qcom,pm8941-iadc", "qcom,spmi-iadc";
reg = <0x3600>;
interrupts = <0x0 0x36 0x0 IRQ_TYPE_EDGE_RISING>;

View File

@ -43,7 +43,7 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
pmic_rradc: adc@4500 {
adc@4500 {
compatible = "qcom,pmi8998-rradc";
reg = <0x4500>;
#io-channel-cells = <1>;

View File

@ -236,11 +236,11 @@ additionalProperties: false
examples:
- |
spmi {
pmic {
#address-cells = <1>;
#size-cells = <0>;
/* VADC node */
pmic_vadc: adc@3100 {
adc@3100 {
compatible = "qcom,spmi-vadc";
reg = <0x3100>;
interrupts = <0x0 0x31 0x0 0x1>;
@ -281,9 +281,10 @@ examples:
#include <dt-bindings/iio/qcom,spmi-adc7-pm8350.h>
#include <dt-bindings/interrupt-controller/irq.h>
spmi {
pmic {
#address-cells = <1>;
#size-cells = <0>;
adc@3100 {
reg = <0x3100>;
compatible = "qcom,spmi-adc7";

View File

@ -67,19 +67,4 @@ required:
- compatible
- "#io-channel-cells"
examples:
- |
#include <dt-bindings/clock/mt8183-clk.h>
pmic {
compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
adc {
compatible = "ti,palmas-gpadc";
interrupts = <18 0>,
<16 0>,
<17 0>;
#io-channel-cells = <1>;
ti,channel0-current-microamp = <5>;
ti,channel3-current-microamp = <10>;
};
};
...

View File

@ -12,6 +12,9 @@ maintainers:
description: |
Digital Step Attenuator IIO devices with gpio interface.
Offer various frequency and attenuation ranges.
ADRF5750 2 dB LSB, 4-Bit, Silicon Digital Attenuator, 10 MHz to 60 GHz
https://www.analog.com/media/en/technical-documentation/data-sheets/adrf5740.pdf
HMC425A 0.5 dB LSB GaAs MMIC 6-BIT DIGITAL POSITIVE CONTROL ATTENUATOR, 2.2 - 8.0 GHz
https://www.analog.com/media/en/technical-documentation/data-sheets/hmc425A.pdf
@ -22,6 +25,7 @@ description: |
properties:
compatible:
enum:
- adi,adrf5740
- adi,hmc425a
- adi,hmc540s

View File

@ -0,0 +1,47 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/chemical/aosong,ags02ma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Aosong AGS02MA VOC Sensor
description: |
AGS02MA is an TVOC (Total Volatile Organic Compounds) i2c sensor with default
address of 0x1a.
Datasheet:
https://asairsensors.com/wp-content/uploads/2021/09/AGS02MA.pdf
maintainers:
- Anshul Dalal <anshulusr@gmail.com>
properties:
compatible:
enum:
- aosong,ags02ma
reg:
maxItems: 1
vdd-supply: true
required:
- compatible
- reg
- vdd-supply
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
voc-sensor@1a {
compatible = "aosong,ags02ma";
reg = <0x1a>;
vdd-supply = <&vdd_regulator>;
};
};

View File

@ -26,6 +26,11 @@ properties:
vdd-supply: true
vss-supply: true
adi,rbuf-gain2-en:
description: Specify to allow an external amplifier to be connected in a
gain of two configuration.
type: boolean
required:
- compatible
- reg

View File

@ -0,0 +1,86 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/dac/microchip,mcp4821.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip MCP4821 and similar DACs
description: |
Supports MCP48x1 (single channel) and MCP48x2 (dual channel) series of DACs.
Device supports simplex communication over SPI in Mode 0 and Mode 3.
+---------+--------------+-------------+
| Device | Resolution | Channels |
|---------|--------------|-------------|
| MCP4801 | 8-bit | 1 |
| MCP4802 | 8-bit | 2 |
| MCP4811 | 10-bit | 1 |
| MCP4812 | 10-bit | 2 |
| MCP4821 | 12-bit | 1 |
| MCP4822 | 12-bit | 2 |
+---------+--------------+-------------+
Datasheet:
MCP48x1: https://ww1.microchip.com/downloads/en/DeviceDoc/22244B.pdf
MCP48x2: https://ww1.microchip.com/downloads/en/DeviceDoc/20002249B.pdf
maintainers:
- Anshul Dalal <anshulusr@gmail.com>
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
compatible:
enum:
- microchip,mcp4801
- microchip,mcp4802
- microchip,mcp4811
- microchip,mcp4812
- microchip,mcp4821
- microchip,mcp4822
reg:
maxItems: 1
vdd-supply: true
ldac-gpios:
description: |
Active Low LDAC (Latch DAC Input) pin used to update the DAC output.
maxItems: 1
powerdown-gpios:
description: |
Active Low SHDN pin used to enter the shutdown mode.
maxItems: 1
spi-cpha: true
spi-cpol: true
required:
- compatible
- reg
- vdd-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
dac@0 {
compatible = "microchip,mcp4821";
reg = <0>;
vdd-supply = <&vdd_regulator>;
ldac-gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
powerdown-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
spi-cpha;
spi-cpol;
};
};

View File

@ -0,0 +1,55 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/humidity/ti,hdc3020.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: HDC3020/HDC3021/HDC3022 humidity and temperature iio sensors
maintainers:
- Li peiyu <579lpy@gmail.com>
- Javier Carrasco <javier.carrasco.cruz@gmail.com>
description:
https://www.ti.com/lit/ds/symlink/hdc3020.pdf
The HDC302x is an integrated capacitive based relative humidity (RH)
and temperature sensor.
properties:
compatible:
oneOf:
- items:
- enum:
- ti,hdc3021
- ti,hdc3022
- const: ti,hdc3020
- const: ti,hdc3020
interrupts:
maxItems: 1
vdd-supply: true
reg:
maxItems: 1
required:
- compatible
- reg
- vdd-supply
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
humidity-sensor@47 {
compatible = "ti,hdc3021", "ti,hdc3020";
reg = <0x47>;
vdd-supply = <&vcc_3v3>;
};
};

View File

@ -25,6 +25,10 @@ properties:
spi-cpol: true
spi-cs-inactive-delay-ns:
minimum: 16000
default: 16000
interrupts:
maxItems: 1

View File

@ -47,6 +47,10 @@ properties:
spi-max-frequency:
maximum: 2000000
spi-cs-inactive-delay-ns:
minimum: 16000
default: 16000
interrupts:
maxItems: 1

View File

@ -0,0 +1,77 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/imu/bosch,bmi323.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Bosch BMI323 6-Axis IMU
maintainers:
- Jagath Jog J <jagathjog1996@gmail.com>
description:
BMI323 is a 6-axis inertial measurement unit that supports acceleration and
gyroscopic measurements with hardware fifo buffering. Sensor also provides
events information such as motion, steps, orientation, single and double
tap detection.
properties:
compatible:
const: bosch,bmi323
reg:
maxItems: 1
vdd-supply: true
vddio-supply: true
interrupts:
minItems: 1
maxItems: 2
interrupt-names:
minItems: 1
maxItems: 2
items:
enum:
- INT1
- INT2
drive-open-drain:
description:
set if the specified interrupt pin should be configured as
open drain. If not set, defaults to push-pull.
mount-matrix:
description:
an optional 3x3 mounting rotation matrix.
required:
- compatible
- reg
- vdd-supply
- vddio-supply
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
unevaluatedProperties: false
examples:
- |
// Example for I2C
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
imu@68 {
compatible = "bosch,bmi323";
reg = <0x68>;
vddio-supply = <&vddio>;
vdd-supply = <&vdd>;
interrupt-parent = <&gpio1>;
interrupts = <29 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "INT1";
};
};

View File

@ -0,0 +1,56 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/light/liteon,ltr390.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Lite-On LTR390 ALS and UV Sensor
description: |
The Lite-On LTR390 is an ALS (Ambient Light Sensor) and a UV sensor in a
single package with i2c address of 0x53.
Datasheet:
https://optoelectronics.liteon.com/upload/download/DS86-2015-0004/LTR-390UV_Final_%20DS_V1%201.pdf
maintainers:
- Anshul Dalal <anshulusr@gmail.com>
properties:
compatible:
enum:
- liteon,ltr390
reg:
maxItems: 1
interrupts:
maxItems: 1
description: |
Level interrupt pin with open drain output.
The sensor pulls this pin low when the measured reading is greater than
some configured threshold.
vdd-supply: true
required:
- compatible
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
light-sensor@53 {
compatible = "liteon,ltr390";
reg = <0x53>;
interrupts = <18 IRQ_TYPE_EDGE_FALLING>;
vdd-supply = <&vdd_regulator>;
};
};

View File

@ -0,0 +1,39 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/light/vishay,veml6075.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Vishay VEML6075 UVA and UVB sensor
maintainers:
- Javier Carrasco <javier.carrasco.cruz@gmail.com>
properties:
compatible:
const: vishay,veml6075
reg:
maxItems: 1
vdd-supply: true
required:
- compatible
- reg
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
uv-sensor@10 {
compatible = "vishay,veml6075";
reg = <0x10>;
vdd-supply = <&vdd_reg>;
};
};
...

View File

@ -0,0 +1,142 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/pressure/honeywell,hsc030pa.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Honeywell TruStability HSC and SSC pressure sensor series
description: |
support for Honeywell TruStability HSC and SSC digital pressure sensor
series.
These sensors have either an I2C, an SPI or an analog interface. Only the
digital versions are supported by this driver.
There are 118 models with different pressure ranges available in each family.
The vendor calls them "HSC series" and "SSC series". All of them have an
identical programming model but differ in pressure range, unit and transfer
function.
To support different models one needs to specify the pressure range as well
as the transfer function. Pressure range can either be provided via
pressure-triplet (directly extracted from the part number) or in case it's
a custom chip via numerical range limits converted to pascals.
The transfer function defines the ranges of raw conversion values delivered
by the sensor. pmin-pascal and pmax-pascal corespond to the minimum and
maximum pressure that can be measured.
Please note that in case of an SPI-based sensor, the clock signal should not
exceed 800kHz and the MOSI signal is not required.
Specifications about the devices can be found at:
https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/trustability-hsc-series/documents/sps-siot-trustability-hsc-series-high-accuracy-board-mount-pressure-sensors-50099148-a-en-ciid-151133.pdf
https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/trustability-ssc-series/documents/sps-siot-trustability-ssc-series-standard-accuracy-board-mount-pressure-sensors-50099533-a-en-ciid-151134.pdf
maintainers:
- Petre Rodan <petre.rodan@subdimension.ro>
properties:
compatible:
const: honeywell,hsc030pa
reg:
maxItems: 1
honeywell,transfer-function:
description: |
Transfer function which defines the range of valid values delivered by
the sensor.
0 - A, 10% to 90% of 2^14
1 - B, 5% to 95% of 2^14
2 - C, 5% to 85% of 2^14
3 - F, 4% to 94% of 2^14
enum: [0, 1, 2, 3]
$ref: /schemas/types.yaml#/definitions/uint32
honeywell,pressure-triplet:
description: |
Case-sensitive five character string that defines pressure range, unit
and type as part of the device nomenclature. In the unlikely case of a
custom chip, set to "NA" and provide pmin-pascal and pmax-pascal.
enum: [001BA, 1.6BA, 2.5BA, 004BA, 006BA, 010BA, 1.6MD, 2.5MD, 004MD,
006MD, 010MD, 016MD, 025MD, 040MD, 060MD, 100MD, 160MD, 250MD,
400MD, 600MD, 001BD, 1.6BD, 2.5BD, 004BD, 2.5MG, 004MG, 006MG,
010MG, 016MG, 025MG, 040MG, 060MG, 100MG, 160MG, 250MG, 400MG,
600MG, 001BG, 1.6BG, 2.5BG, 004BG, 006BG, 010BG, 100KA, 160KA,
250KA, 400KA, 600KA, 001GA, 160LD, 250LD, 400LD, 600LD, 001KD,
1.6KD, 2.5KD, 004KD, 006KD, 010KD, 016KD, 025KD, 040KD, 060KD,
100KD, 160KD, 250KD, 400KD, 250LG, 400LG, 600LG, 001KG, 1.6KG,
2.5KG, 004KG, 006KG, 010KG, 016KG, 025KG, 040KG, 060KG, 100KG,
160KG, 250KG, 400KG, 600KG, 001GG, 015PA, 030PA, 060PA, 100PA,
150PA, 0.5ND, 001ND, 002ND, 004ND, 005ND, 010ND, 020ND, 030ND,
001PD, 005PD, 015PD, 030PD, 060PD, 001NG, 002NG, 004NG, 005NG,
010NG, 020NG, 030NG, 001PG, 005PG, 015PG, 030PG, 060PG, 100PG,
150PG, NA]
$ref: /schemas/types.yaml#/definitions/string
honeywell,pmin-pascal:
description: |
Minimum pressure value the sensor can measure in pascal.
To be specified only if honeywell,pressure-triplet is set to "NA".
honeywell,pmax-pascal:
description: |
Maximum pressure value the sensor can measure in pascal.
To be specified only if honeywell,pressure-triplet is set to "NA".
vdd-supply:
description:
Provide VDD power to the sensor (either 3.3V or 5V depending on the chip)
spi-max-frequency:
maximum: 800000
required:
- compatible
- reg
- honeywell,transfer-function
- honeywell,pressure-triplet
additionalProperties: false
dependentSchemas:
honeywell,pmin-pascal:
properties:
honeywell,pressure-triplet:
const: NA
honeywell,pmax-pascal:
properties:
honeywell,pressure-triplet:
const: NA
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
pressure@28 {
compatible = "honeywell,hsc030pa";
reg = <0x28>;
honeywell,transfer-function = <0>;
honeywell,pressure-triplet = "030PA";
};
};
- |
spi {
#address-cells = <1>;
#size-cells = <0>;
pressure@0 {
compatible = "honeywell,hsc030pa";
reg = <0>;
spi-max-frequency = <800000>;
honeywell,transfer-function = <0>;
honeywell,pressure-triplet = "NA";
honeywell,pmin-pascal = <0>;
honeywell,pmax-pascal = <200000>;
};
};
...

View File

@ -53,12 +53,10 @@ properties:
honeywell,pmin-pascal:
description:
Minimum pressure value the sensor can measure in pascal.
$ref: /schemas/types.yaml#/definitions/uint32
honeywell,pmax-pascal:
description:
Maximum pressure value the sensor can measure in pascal.
$ref: /schemas/types.yaml#/definitions/uint32
honeywell,transfer-function:
description: |

View File

@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/iio/temperature/melexis,mlx90632.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Melexis MLX90632 contactless Infra Red temperature sensor
title: Melexis MLX90632 and MLX90635 contactless Infra Red temperature sensor
maintainers:
- Crt Mori <cmo@melexis.com>
@ -27,9 +27,24 @@ description: |
Since measured object emissivity effects Infra Red energy emitted,
emissivity should be set before requesting the object temperature.
https://www.melexis.com/en/documents/documentation/datasheets/datasheet-mlx90635
MLX90635 is most suitable for consumer applications where
measured object temperature is in range between -20 to 100 degrees
Celsius with relative error of measurement 2 degree Celsius in
object temperature range for industrial applications, while just 0.2
degree Celsius for human body measurement applications. Since it can
operate and measure ambient temperature in range of -20 to 85 degrees
Celsius it is suitable also for outdoor use.
Since measured object emissivity effects Infra Red energy emitted,
emissivity should be set before requesting the object temperature.
properties:
compatible:
const: melexis,mlx90632
enum:
- melexis,mlx90632
- melexis,mlx90635
reg:
maxItems: 1

View File

@ -0,0 +1,70 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/temperature/microchip,mcp9600.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip MCP9600 thermocouple EMF converter
maintainers:
- Andrew Hepp <andrew.hepp@ahepp.dev>
description:
https://ww1.microchip.com/downloads/en/DeviceDoc/MCP960X-Data-Sheet-20005426.pdf
properties:
compatible:
const: microchip,mcp9600
reg:
maxItems: 1
interrupts:
minItems: 1
maxItems: 6
interrupt-names:
minItems: 1
maxItems: 6
items:
enum:
- open-circuit
- short-circuit
- alert1
- alert2
- alert3
- alert4
thermocouple-type:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Type of thermocouple (THERMOCOUPLE_TYPE_K if omitted).
Use defines in dt-bindings/iio/temperature/thermocouple.h.
Supported types are B, E, J, K, N, R, S, T.
vdd-supply: true
required:
- compatible
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/iio/temperature/thermocouple.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
temperature-sensor@60 {
compatible = "microchip,mcp9600";
reg = <0x60>;
interrupt-parent = <&gpio>;
interrupts = <25 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "open-circuit";
thermocouple-type = <THERMOCOUPLE_TYPE_K>;
vdd-supply = <&vdd>;
};
};

View File

@ -0,0 +1,63 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/adafruit,seesaw-gamepad.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Adafruit Mini I2C Gamepad with seesaw
maintainers:
- Anshul Dalal <anshulusr@gmail.com>
description: |
Adafruit Mini I2C Gamepad
+-----------------------------+
| ___ |
| / \ (X) |
| | S | __ __ (Y) (A) |
| \___/ |ST| |SE| (B) |
| |
+-----------------------------+
S -> 10-bit precision bidirectional analog joystick
ST -> Start
SE -> Select
X, A, B, Y -> Digital action buttons
Datasheet: https://cdn-learn.adafruit.com/downloads/pdf/gamepad-qt.pdf
Product page: https://www.adafruit.com/product/5743
Arduino Driver: https://github.com/adafruit/Adafruit_Seesaw
properties:
compatible:
const: adafruit,seesaw-gamepad
reg:
maxItems: 1
interrupts:
maxItems: 1
description:
The gamepad's IRQ pin triggers a rising edge if interrupts are enabled.
required:
- compatible
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
joystick@50 {
compatible = "adafruit,seesaw-gamepad";
interrupts = <18 IRQ_TYPE_EDGE_RISING>;
reg = <0x50>;
};
};

View File

@ -31,7 +31,23 @@ patternProperties:
maxItems: 1
interrupts:
maxItems: 1
oneOf:
- items:
- description: Optional key interrupt or wakeup interrupt
- items:
- description: Key interrupt
- description: Wakeup interrupt
interrupt-names:
description:
Optional interrupt names, can be used to specify a separate dedicated
wake-up interrupt in addition to the gpio irq
oneOf:
- items:
- enum: [ irq, wakeup ]
- items:
- const: irq
- const: wakeup
label:
description: Descriptive name of the key.
@ -97,6 +113,20 @@ patternProperties:
- required:
- gpios
allOf:
- if:
properties:
interrupts:
minItems: 2
required:
- interrupts
then:
properties:
interrupt-names:
minItems: 2
required:
- interrupt-names
dependencies:
wakeup-event-action: [ wakeup-source ]
linux,input-value: [ gpios ]
@ -137,6 +167,15 @@ examples:
linux,code = <108>;
interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
};
key-wakeup {
label = "GPIO Key WAKEUP";
linux,code = <143>;
interrupts-extended = <&intc 2 IRQ_TYPE_EDGE_FALLING>,
<&intc_wakeup 0 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "irq", "wakeup";
wakeup-source;
};
};
...

View File

@ -1,32 +0,0 @@
Device-Tree bindings for GPIO attached mice
This simply uses standard GPIO handles to define a simple mouse connected
to 5-7 GPIO lines.
Required properties:
- compatible: must be "gpio-mouse"
- scan-interval-ms: The scanning interval in milliseconds
- up-gpios: GPIO line phandle to the line indicating "up"
- down-gpios: GPIO line phandle to the line indicating "down"
- left-gpios: GPIO line phandle to the line indicating "left"
- right-gpios: GPIO line phandle to the line indicating "right"
Optional properties:
- button-left-gpios: GPIO line handle to the left mouse button
- button-middle-gpios: GPIO line handle to the middle mouse button
- button-right-gpios: GPIO line handle to the right mouse button
Example:
#include <dt-bindings/gpio/gpio.h>
gpio-mouse {
compatible = "gpio-mouse";
scan-interval-ms = <50>;
up-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
down-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
left-gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
right-gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
button-left-gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
button-middle-gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
button-right-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
};

View File

@ -0,0 +1,68 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/gpio-mouse.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: GPIO attached mouse
description: |
This simply uses standard GPIO handles to define a simple mouse connected
to 5-7 GPIO lines.
maintainers:
- Anshul Dalal <anshulusr@gmail.com>
properties:
compatible:
const: gpio-mouse
scan-interval-ms:
maxItems: 1
up-gpios:
maxItems: 1
down-gpios:
maxItems: 1
left-gpios:
maxItems: 1
right-gpios:
maxItems: 1
button-left-gpios:
maxItems: 1
button-middle-gpios:
maxItems: 1
button-right-gpios:
maxItems: 1
required:
- compatible
- scan-interval-ms
- up-gpios
- down-gpios
- left-gpios
- right-gpios
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
gpio-mouse {
compatible = "gpio-mouse";
scan-interval-ms = <50>;
up-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
down-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
left-gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
right-gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
button-left-gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
button-middle-gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
button-right-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
};

View File

@ -9,6 +9,9 @@ title: Azoteq IQS269A Capacitive Touch Controller
maintainers:
- Jeff LaBundy <jeff@labundy.com>
allOf:
- $ref: input.yaml#
description: |
The Azoteq IQS269A is an 8-channel capacitive touch controller that features
additional Hall-effect and inductive sensing capabilities.
@ -17,7 +20,10 @@ description: |
properties:
compatible:
const: azoteq,iqs269a
enum:
- azoteq,iqs269a
- azoteq,iqs269a-00
- azoteq,iqs269a-d0
reg:
maxItems: 1
@ -204,6 +210,73 @@ properties:
default: 1
description: Specifies the slider coordinate filter strength.
azoteq,touch-hold-ms:
multipleOf: 256
minimum: 256
maximum: 65280
default: 5120
description:
Specifies the length of time (in ms) for which the channel selected by
'azoteq,gpio3-select' must be held in a state of touch in order for an
approximately 60-ms pulse to be asserted on the GPIO4 pin.
linux,keycodes:
minItems: 1
maxItems: 8
description: |
Specifies the numeric keycodes associated with each available gesture in
the following order (enter 0 for unused gestures):
0: Slider 0 tap
1: Slider 0 hold
2: Slider 0 positive flick or swipe
3: Slider 0 negative flick or swipe
4: Slider 1 tap
5: Slider 1 hold
6: Slider 1 positive flick or swipe
7: Slider 1 negative flick or swipe
azoteq,gesture-swipe:
type: boolean
description:
Directs the device to interpret axial gestures as a swipe (finger remains
on slider) instead of a flick (finger leaves slider).
azoteq,timeout-tap-ms:
multipleOf: 16
minimum: 0
maximum: 4080
default: 400
description:
Specifies the length of time (in ms) within which a slider touch must be
released in order to be interpreted as a tap. Default and maximum values
as well as step size are reduced by a factor of 4 with device version 2.
azoteq,timeout-swipe-ms:
multipleOf: 16
minimum: 0
maximum: 4080
default: 2000
description:
Specifies the length of time (in ms) within which an axial gesture must be
completed in order to be interpreted as a flick or swipe. Default and max-
imum values as well as step size are reduced by a factor of 4 with device
version 2.
azoteq,thresh-swipe:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 255
default: 128
description:
Specifies the number of points across which an axial gesture must travel
in order to be interpreted as a flick or swipe.
dependencies:
azoteq,gesture-swipe: ["linux,keycodes"]
azoteq,timeout-tap-ms: ["linux,keycodes"]
azoteq,timeout-swipe-ms: ["linux,keycodes"]
azoteq,thresh-swipe: ["linux,keycodes"]
patternProperties:
"^channel@[0-7]$":
type: object
@ -454,6 +527,21 @@ patternProperties:
additionalProperties: false
if:
properties:
compatible:
contains:
enum:
- azoteq,iqs269a-d0
then:
patternProperties:
"^channel@[0-7]$":
properties:
azoteq,slider1-select: false
else:
properties:
azoteq,touch-hold-ms: false
required:
- compatible
- reg
@ -484,6 +572,14 @@ examples:
azoteq,hall-enable;
azoteq,suspend-mode = <2>;
linux,keycodes = <KEY_PLAYPAUSE>,
<KEY_STOPCD>,
<KEY_NEXTSONG>,
<KEY_PREVIOUSSONG>;
azoteq,timeout-tap-ms = <400>;
azoteq,timeout-swipe-ms = <800>;
channel@0 {
reg = <0x0>;

View File

@ -90,26 +90,4 @@ required:
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
pmic {
compatible = "mediatek,mt6397";
keys {
compatible = "mediatek,mt6397-keys";
mediatek,long-press-mode = <1>;
power-off-time-sec = <0>;
key-power {
linux,keycodes = <KEY_POWER>;
wakeup-source;
};
key-home {
linux,keycodes = <KEY_VOLUMEDOWN>;
};
};
};
...

View File

@ -45,13 +45,13 @@ properties:
Enables the Linux input system's autorepeat feature on the input device.
linux,keycodes:
minItems: 6
maxItems: 6
minItems: 3
maxItems: 8
description: |
Specifies an array of numeric keycode values to
be used for the channels. If this property is
omitted, KEY_A, KEY_B, etc are used as defaults.
The array must have exactly six entries.
The number of entries must correspond to the number of channels.
microchip,sensor-gain:
$ref: /schemas/types.yaml#/definitions/uint32
@ -70,6 +70,59 @@ properties:
open drain. This property allows using the active
high push-pull output.
microchip,sensitivity-delta-sense:
$ref: /schemas/types.yaml#/definitions/uint32
default: 32
enum: [1, 2, 4, 8, 16, 32, 64, 128]
description:
Controls the sensitivity multiplier of a touch detection.
Higher value means more sensitive settings.
At the more sensitive settings, touches are detected for a smaller delta
capacitance corresponding to a "lighter" touch.
microchip,signal-guard:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 3
maxItems: 8
items:
enum: [0, 1]
description: |
0 - off
1 - on
The signal guard isolates the signal from virtual grounds.
If enabled then the behavior of the channel is changed to signal guard.
The number of entries must correspond to the number of channels.
microchip,input-threshold:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 3
maxItems: 8
items:
minimum: 0
maximum: 127
description:
Specifies the delta threshold that is used to determine if a touch has
been detected. A higher value means a larger difference in capacitance
is required for a touch to be registered, making the touch sensor less
sensitive.
The number of entries must correspond to the number of channels.
microchip,calib-sensitivity:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 3
maxItems: 8
items:
enum: [1, 2, 4]
description: |
Specifies an array of numeric values that controls the gain
used by the calibration routine to enable sensor inputs
to be more sensitive for proximity detection.
Gain is based on touch pad capacitance range
1 - 5-50pF
2 - 0-25pF
4 - 0-12.5pF
The number of entries must correspond to the number of channels.
patternProperties:
"^led@[0-7]$":
type: object
@ -99,10 +152,29 @@ allOf:
contains:
enum:
- microchip,cap1106
- microchip,cap1203
- microchip,cap1206
- microchip,cap1293
- microchip,cap1298
then:
patternProperties:
"^led@[0-7]$": false
- if:
properties:
compatible:
contains:
enum:
- microchip,cap1106
- microchip,cap1126
- microchip,cap1188
- microchip,cap1203
- microchip,cap1206
then:
properties:
microchip,signal-guard: false
microchip,calib-sensitivity: false
required:
- compatible
- interrupts
@ -122,6 +194,8 @@ examples:
reg = <0x28>;
autorepeat;
microchip,sensor-gain = <2>;
microchip,sensitivity-delta-sense = <16>;
microchip,input-threshold = <21>, <18>, <46>, <46>, <46>, <21>;
linux,keycodes = <103>, /* KEY_UP */
<106>, /* KEY_RIGHT */

View File

@ -28,21 +28,4 @@ required:
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
sc2731_pmic: pmic@0 {
compatible = "sprd,sc2731";
reg = <0 0>;
spi-max-frequency = <26000000>;
interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
interrupt-controller;
#interrupt-cells = <2>;
#address-cells = <1>;
#size-cells = <0>;
vibrator@eb4 {
compatible = "sprd,sc2731-vibrator";
reg = <0xeb4>;
};
};
...

View File

@ -1,17 +0,0 @@
* Texas Instruments - drv2665 Haptics driver
Required properties:
- compatible - "ti,drv2665" - DRV2665
- reg - I2C slave address
- vbat-supply - Required supply regulator
Example:
haptics: haptics@59 {
compatible = "ti,drv2665";
reg = <0x59>;
vbat-supply = <&vbat>;
};
For more product information please see the link below:
http://www.ti.com/product/drv2665

View File

@ -1,17 +0,0 @@
* Texas Instruments - drv2667 Haptics driver
Required properties:
- compatible - "ti,drv2667" - DRV2667
- reg - I2C slave address
- vbat-supply - Required supply regulator
Example:
haptics: haptics@59 {
compatible = "ti,drv2667";
reg = <0x59>;
vbat-supply = <&vbat>;
};
For more product information please see the link below:
http://www.ti.com/product/drv2667

View File

@ -0,0 +1,50 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/ti,drv266x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments - drv266x Haptics driver
description: |
Product Page:
http://www.ti.com/product/drv2665
http://www.ti.com/product/drv2667
maintainers:
- Anshul Dalal <anshulusr@gmail.com>
properties:
compatible:
enum:
- ti,drv2665
- ti,drv2667
reg:
maxItems: 1
vbat-supply:
description: Required supply regulator
required:
- compatible
- reg
- vbat-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
haptics@59 {
compatible = "ti,drv2667";
reg = <0x59>;
vbat-supply = <&vbat>;
};
};

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/input/touchscreen/neonode,zforce.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Neonode infrared touchscreen controller
maintainers:
- Heiko Stuebner <heiko@sntech.de>
allOf:
- $ref: touchscreen.yaml#
properties:
compatible:
const: neonode,zforce
reg:
maxItems: 1
interrupts:
maxItems: 1
reset-gpios:
maxItems: 1
irq-gpios:
maxItems: 1
x-size:
deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
y-size:
deprecated: true
$ref: /schemas/types.yaml#/definitions/uint32
vdd-supply: true
required:
- compatible
- reg
- interrupts
- reset-gpios
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
touchscreen@50 {
compatible = "neonode,zforce";
reg = <0x50>;
interrupts = <2 0>;
vdd-supply = <&reg_zforce_vdd>;
reset-gpios = <&gpio5 9 0>; /* RST */
irq-gpios = <&gpio5 6 0>; /* IRQ, optional */
touchscreen-min-x = <0>;
touchscreen-size-x = <800>;
touchscreen-min-y = <0>;
touchscreen-size-y = <600>;
};
};
...

View File

@ -1,32 +0,0 @@
* Samsung S6SY761 touchscreen controller
Required properties:
- compatible : must be "samsung,s6sy761"
- reg : I2C slave address, (e.g. 0x48)
- interrupts : interrupt specification
- avdd-supply : analogic power supply
- vdd-supply : power supply
Optional properties:
- touchscreen-size-x : see touchscreen.txt. This property is embedded in the
device. If defined it forces a different x resolution.
- touchscreen-size-y : see touchscreen.txt. This property is embedded in the
device. If defined it forces a different y resolution.
Example:
i2c@00000000 {
/* ... */
touchscreen@48 {
compatible = "samsung,s6sy761";
reg = <0x48>;
interrupt-parent = <&gpa1>;
interrupts = <1 IRQ_TYPE_NONE>;
avdd-supply = <&ldo30_reg>;
vdd-supply = <&ldo31_reg>;
touchscreen-size-x = <4096>;
touchscreen-size-y = <4096>;
};
};

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/input/touchscreen/samsung,s6sy761.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung S6SY761 touchscreen controller
maintainers:
- Andi Shyti <andi.shyti@kernel.org>
allOf:
- $ref: touchscreen.yaml#
properties:
compatible:
const: samsung,s6sy761
reg:
maxItems: 1
interrupts:
maxItems: 1
avdd-supply: true
vdd-supply: true
unevaluatedProperties: false
required:
- compatible
- reg
- interrupts
- avdd-supply
- vdd-supply
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
touchscreen@48 {
compatible = "samsung,s6sy761";
reg = <0x48>;
interrupt-parent = <&gpa1>;
interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
avdd-supply = <&ldo30_reg>;
vdd-supply = <&ldo31_reg>;
touchscreen-size-x = <4096>;
touchscreen-size-y = <4096>;
};
};

View File

@ -1,34 +0,0 @@
* Neonode infrared touchscreen controller
Required properties:
- compatible: must be "neonode,zforce"
- reg: I2C address of the chip
- interrupts: interrupt to which the chip is connected
- reset-gpios: reset gpio the chip is connected to
- x-size: horizontal resolution of touchscreen
- y-size: vertical resolution of touchscreen
Optional properties:
- irq-gpios : interrupt gpio the chip is connected to
- vdd-supply: Regulator controlling the controller supply
Example:
i2c@00000000 {
/* ... */
zforce_ts@50 {
compatible = "neonode,zforce";
reg = <0x50>;
interrupts = <2 0>;
vdd-supply = <&reg_zforce_vdd>;
reset-gpios = <&gpio5 9 0>; /* RST */
irq-gpios = <&gpio5 6 0>; /* IRQ, optional */
x-size = <800>;
y-size = <600>;
};
/* ... */
};

View File

@ -25,13 +25,16 @@ properties:
- const: qcom,msm8998-bwmon # BWMON v4
- items:
- enum:
- qcom,qcm2290-cpu-bwmon
- qcom,sc7180-cpu-bwmon
- qcom,sc7280-cpu-bwmon
- qcom,sc8280xp-cpu-bwmon
- qcom,sdm845-cpu-bwmon
- qcom,sm6115-cpu-bwmon
- qcom,sm6350-llcc-bwmon
- qcom,sm8250-cpu-bwmon
- qcom,sm8550-cpu-bwmon
- qcom,sm8650-cpu-bwmon
- const: qcom,sdm845-bwmon # BWMON v4, unified register space
- items:
- enum:
@ -40,6 +43,7 @@ properties:
- qcom,sm6350-cpu-bwmon
- qcom,sm8250-llcc-bwmon
- qcom,sm8550-llcc-bwmon
- qcom,sm8650-llcc-bwmon
- const: qcom,sc7280-llcc-bwmon
- const: qcom,sc7280-llcc-bwmon # BWMON v5
- const: qcom,sdm845-llcc-bwmon # BWMON v5

View File

@ -11,8 +11,13 @@ maintainers:
description: |
This interrupt controller is found in the Loongson-3 family of chips and
Loongson-2K1000 chip, as the primary package interrupt controller which
Loongson-2K series chips, as the primary package interrupt controller which
can route local I/O interrupt to interrupt lines of cores.
Be aware of the following points.
1.The Loongson-2K0500 is a single core CPU;
2.The Loongson-2K0500/2K1000 has 64 device interrupt sources as inputs, so we
need to define two nodes in dts{i} to describe the "0-31" and "32-61" interrupt
sources respectively.
allOf:
- $ref: /schemas/interrupt-controller.yaml#
@ -33,6 +38,7 @@ properties:
- const: main
- const: isr0
- const: isr1
minItems: 2
interrupt-controller: true
@ -45,11 +51,9 @@ properties:
interrupt-names:
description: List of names for the parent interrupts.
items:
- const: int0
- const: int1
- const: int2
- const: int3
pattern: int[0-3]
minItems: 1
maxItems: 4
'#interrupt-cells':
const: 2
@ -69,6 +73,7 @@ required:
- compatible
- reg
- interrupts
- interrupt-names
- interrupt-controller
- '#interrupt-cells'
- loongson,parent_int_map
@ -86,7 +91,8 @@ if:
then:
properties:
reg:
minItems: 3
minItems: 2
maxItems: 3
required:
- reg-names

View File

@ -24,6 +24,7 @@ properties:
compatible:
enum:
- apple,t8103-dart
- apple,t8103-usb4-dart
- apple,t8110-dart
- apple,t6000-dart

View File

@ -56,6 +56,8 @@ properties:
- qcom,sm8350-smmu-500
- qcom,sm8450-smmu-500
- qcom,sm8550-smmu-500
- qcom,sm8650-smmu-500
- qcom,x1e80100-smmu-500
- const: qcom,smmu-500
- const: arm,mmu-500
@ -89,6 +91,8 @@ properties:
- qcom,sm8150-smmu-500
- qcom,sm8250-smmu-500
- qcom,sm8350-smmu-500
- qcom,sm8450-smmu-500
- qcom,sm8550-smmu-500
- const: qcom,adreno-smmu
- const: qcom,smmu-500
- const: arm,mmu-500
@ -429,6 +433,30 @@ allOf:
- description: interface clock required to access smmu's registers
through the TCU's programming interface.
- if:
properties:
compatible:
items:
- enum:
- qcom,sm8350-smmu-500
- const: qcom,adreno-smmu
- const: qcom,smmu-500
- const: arm,mmu-500
then:
properties:
clock-names:
items:
- const: bus
- const: iface
- const: ahb
- const: hlos1_vote_gpu_smmu
- const: cx_gmu
- const: hub_cx_int
- const: hub_aon
clocks:
minItems: 7
maxItems: 7
- if:
properties:
compatible:
@ -453,6 +481,50 @@ allOf:
- description: Voter clock required for HLOS SMMU access
- description: Interface clock required for register access
- if:
properties:
compatible:
const: qcom,sm8450-smmu-500
then:
properties:
clock-names:
items:
- const: gmu
- const: hub
- const: hlos
- const: bus
- const: iface
- const: ahb
clocks:
items:
- description: GMU clock
- description: GPU HUB clock
- description: HLOS vote clock
- description: GPU memory bus clock
- description: GPU SNoC bus clock
- description: GPU AHB clock
- if:
properties:
compatible:
const: qcom,sm8550-smmu-500
then:
properties:
clock-names:
items:
- const: hlos
- const: bus
- const: iface
- const: ahb
clocks:
items:
- description: HLOS vote clock
- description: GPU memory bus clock
- description: GPU SNoC bus clock
- description: GPU AHB clock
# Disallow clocks for all other platforms with specific compatibles
- if:
properties:
@ -472,9 +544,8 @@ allOf:
- qcom,sdx65-smmu-500
- qcom,sm6350-smmu-500
- qcom,sm6375-smmu-500
- qcom,sm8350-smmu-500
- qcom,sm8450-smmu-500
- qcom,sm8550-smmu-500
- qcom,sm8650-smmu-500
- qcom,x1e80100-smmu-500
then:
properties:
clock-names: false

View File

@ -19,9 +19,14 @@ description: |+
properties:
compatible:
enum:
- rockchip,iommu
- rockchip,rk3568-iommu
oneOf:
- enum:
- rockchip,iommu
- rockchip,rk3568-iommu
- items:
- enum:
- rockchip,rk3588-iommu
- const: rockchip,rk3568-iommu
reg:
items:

View File

@ -0,0 +1,137 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/allwinner,sun50i-a100-ledc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A100 LED Controller
maintainers:
- Samuel Holland <samuel@sholland.org>
description:
The LED controller found in Allwinner sunxi SoCs uses a one-wire serial
interface to drive up to 1024 RGB LEDs.
properties:
compatible:
oneOf:
- const: allwinner,sun50i-a100-ledc
- items:
- enum:
- allwinner,sun20i-d1-ledc
- allwinner,sun50i-r329-ledc
- const: allwinner,sun50i-a100-ledc
reg:
maxItems: 1
"#address-cells":
const: 1
"#size-cells":
const: 0
interrupts:
maxItems: 1
clocks:
items:
- description: Bus clock
- description: Module clock
clock-names:
items:
- const: bus
- const: mod
resets:
maxItems: 1
dmas:
maxItems: 1
description: TX DMA channel
dma-names:
const: tx
allwinner,pixel-format:
description: Pixel format (subpixel transmission order), default is "grb"
enum:
- bgr
- brg
- gbr
- grb
- rbg
- rgb
allwinner,t0h-ns:
default: 336
description: Length of high pulse when transmitting a "0" bit
allwinner,t0l-ns:
default: 840
description: Length of low pulse when transmitting a "0" bit
allwinner,t1h-ns:
default: 882
description: Length of high pulse when transmitting a "1" bit
allwinner,t1l-ns:
default: 294
description: Length of low pulse when transmitting a "1" bit
allwinner,treset-ns:
default: 300000
description: Minimum delay between transmission frames
patternProperties:
"^multi-led@[0-9a-f]+$":
type: object
$ref: leds-class-multicolor.yaml#
unevaluatedProperties: false
properties:
reg:
minimum: 0
maximum: 1023
description: Index of the LED in the series (must be contiguous)
required:
- reg
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- resets
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/leds/common.h>
ledc: led-controller@2008000 {
compatible = "allwinner,sun20i-d1-ledc",
"allwinner,sun50i-a100-ledc";
reg = <0x2008000 0x400>;
interrupts = <36 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu 12>, <&ccu 34>;
clock-names = "bus", "mod";
resets = <&ccu 12>;
dmas = <&dma 42>;
dma-names = "tx";
#address-cells = <1>;
#size-cells = <0>;
multi-led@0 {
reg = <0x0>;
color = <LED_COLOR_ID_RGB>;
function = LED_FUNCTION_INDICATOR;
};
};
...

View File

@ -10,15 +10,19 @@ maintainers:
- Martin Kurbanov <mmkurbanov@sberdevices.ru>
description: |
This controller is present on AW20036/AW20054/AW20072.
It is a 3x12/6x9/6x12 matrix LED programmed via
an I2C interface, up to 36/54/72 LEDs or 12/18/24 RGBs,
3 pattern controllers for auto breathing or group dimming control.
It is a matrix LED driver programmed via an I2C interface. Devices have
a set of individually controlled leds and support 3 pattern controllers
for auto breathing or group dimming control. Supported devices:
- AW20036 (3x12) 36 LEDs
- AW20054 (6x9) 54 LEDs
- AW20072 (6x12) 72 LEDs
- AW20108 (9x12) 108 LEDs
For more product information please see the link below:
aw20036 - https://www.awinic.com/en/productDetail/AW20036QNR#tech-docs
aw20054 - https://www.awinic.com/en/productDetail/AW20054QNR#tech-docs
aw20072 - https://www.awinic.com/en/productDetail/AW20072QNR#tech-docs
aw20108 - https://www.awinic.com/en/productDetail/AW20108QNR#tech-docs
properties:
compatible:
@ -26,6 +30,7 @@ properties:
- awinic,aw20036
- awinic,aw20054
- awinic,aw20072
- awinic,aw20108
reg:
maxItems: 1
@ -36,13 +41,11 @@ properties:
"#size-cells":
const: 0
awinic,display-rows:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Leds matrix size
enable-gpios:
maxItems: 1
patternProperties:
"^led@[0-9a-f]$":
"^led@[0-9a-f]+$":
type: object
$ref: common.yaml#
unevaluatedProperties: false
@ -60,16 +63,11 @@ patternProperties:
since the chip has a single global setting.
The maximum output current of each LED is calculated by the
following formula:
IMAXled = 160000 * (592 / 600.5) * (1 / display-rows)
IMAXled = 160000 * (592 / 600.5) * (1 / max-current-switch-number)
And the minimum output current formula:
IMINled = 3300 * (592 / 600.5) * (1 / display-rows)
required:
- compatible
- reg
- "#address-cells"
- "#size-cells"
- awinic,display-rows
IMINled = 3300 * (592 / 600.5) * (1 / max-current-switch-number)
where max-current-switch-number is determinated by led configuration
and depends on how leds are physically connected to the led driver.
allOf:
- if:
@ -78,18 +76,67 @@ allOf:
contains:
const: awinic,aw20036
then:
patternProperties:
"^led@[0-9a-f]+$":
properties:
reg:
items:
minimum: 0
maximum: 36
- if:
properties:
awinic,display-rows:
enum: [1, 2, 3]
else:
compatible:
contains:
const: awinic,aw20054
then:
patternProperties:
"^led@[0-9a-f]+$":
properties:
reg:
items:
minimum: 0
maximum: 54
- if:
properties:
awinic,display-rows:
enum: [1, 2, 3, 4, 5, 6, 7]
compatible:
contains:
const: awinic,aw20072
then:
patternProperties:
"^led@[0-9a-f]+$":
properties:
reg:
items:
minimum: 0
maximum: 72
- if:
properties:
compatible:
contains:
const: awinic,aw20108
then:
patternProperties:
"^led@[0-9a-f]+$":
properties:
reg:
items:
minimum: 0
maximum: 108
required:
- compatible
- reg
- "#address-cells"
- "#size-cells"
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/leds/common.h>
i2c {
@ -101,7 +148,7 @@ examples:
reg = <0x3a>;
#address-cells = <1>;
#size-cells = <0>;
awinic,display-rows = <3>;
enable-gpios = <&gpio 3 GPIO_ACTIVE_HIGH>;
led@0 {
reg = <0x0>;

View File

@ -14,8 +14,8 @@ description: |
programmable switching frequency to optimize efficiency.
It supports two different dimming modes:
- analog mode, via I2C commands (default)
- PWM controlled mode.
- analog mode, via I2C commands, as default mode (32 dimming levels)
- PWM controlled mode (optional)
The datasheet is available at:
https://www.monolithicpower.com/en/mp3309c.html
@ -50,8 +50,6 @@ properties:
required:
- compatible
- reg
- max-brightness
- default-brightness
unevaluatedProperties: false
@ -66,8 +64,8 @@ examples:
compatible = "mps,mp3309c";
reg = <0x17>;
pwms = <&pwm1 0 3333333 0>; /* 300 Hz --> (1/f) * 1*10^9 */
max-brightness = <100>;
default-brightness = <80>;
brightness-levels = <0 4 8 16 32 64 128 255>;
default-brightness = <6>;
mps,overvoltage-protection-microvolt = <24000000>;
};
};

View File

@ -167,7 +167,7 @@ properties:
Note that this flag is mainly used for PWM-LEDs, where it is not possible
to map brightness to current. Drivers for other controllers should use
led-max-microamp.
$ref: /schemas/types.yaml#definitions/uint32
$ref: /schemas/types.yaml#/definitions/uint32
panic-indicator:
description:

View File

@ -89,9 +89,11 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/leds/common.h>
spmi {
pmic {
#address-cells = <1>;
#size-cells = <0>;
led-controller@ee00 {
compatible = "qcom,pm8350c-flash-led", "qcom,spmi-flash-led";
reg = <0xee00>;

View File

@ -0,0 +1,61 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/loongarch/cpus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: LoongArch CPUs
maintainers:
- Binbin Zhou <zhoubinbin@loongson.cn>
description:
This document describes the list of LoongArch CPU cores that support FDT,
it describe the layout of CPUs in a system through the "cpus" node.
allOf:
- $ref: /schemas/cpu.yaml#
properties:
compatible:
enum:
- loongson,la264
- loongson,la364
reg:
maxItems: 1
clocks:
maxItems: 1
required:
- compatible
- reg
- clocks
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/loongson,ls2k-clk.h>
cpus {
#size-cells = <0>;
#address-cells = <1>;
cpu@0 {
compatible = "loongson,la264";
device_type = "cpu";
reg = <0>;
clocks = <&clk LOONGSON2_NODE_CLK>;
};
cpu@1 {
compatible = "loongson,la264";
device_type = "cpu";
reg = <1>;
clocks = <&clk LOONGSON2_NODE_CLK>;
};
};
...

View File

@ -0,0 +1,34 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/loongarch/loongson.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Loongson SoC-based boards
maintainers:
- Binbin Zhou <zhoubinbin@loongson.cn>
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: Loongson-2K0500 processor based boards
items:
- const: loongson,ls2k0500-ref
- const: loongson,ls2k0500
- description: Loongson-2K1000 processor based boards
items:
- const: loongson,ls2k1000-ref
- const: loongson,ls2k1000
- description: Loongson-2K2000 processor based boards
items:
- const: loongson,ls2k2000-ref
- const: loongson,ls2k2000
additionalProperties: true
...

View File

@ -23,6 +23,24 @@ properties:
- qcom,ipq8074-apcs-apps-global
- qcom,ipq9574-apcs-apps-global
- const: qcom,ipq6018-apcs-apps-global
- items:
- enum:
- qcom,qcs404-apcs-apps-global
- const: qcom,msm8916-apcs-kpss-global
- const: syscon
- items:
- enum:
- qcom,msm8976-apcs-kpss-global
- const: qcom,msm8994-apcs-kpss-global
- const: syscon
- items:
- enum:
- qcom,msm8998-apcs-hmss-global
- qcom,sdm660-apcs-hmss-global
- qcom,sm4250-apcs-hmss-global
- qcom,sm6115-apcs-hmss-global
- qcom,sm6125-apcs-hmss-global
- const: qcom,msm8994-apcs-kpss-global
- items:
- enum:
- qcom,sc7180-apss-shared
@ -34,22 +52,14 @@ properties:
- qcom,msm8916-apcs-kpss-global
- qcom,msm8939-apcs-kpss-global
- qcom,msm8953-apcs-kpss-global
- qcom,msm8976-apcs-kpss-global
- qcom,msm8994-apcs-kpss-global
- qcom,qcs404-apcs-apps-global
- qcom,sdx55-apcs-gcc
- const: syscon
- enum:
- qcom,ipq6018-apcs-apps-global
- qcom,ipq8074-apcs-apps-global
- qcom,msm8996-apcs-hmss-global
- qcom,msm8998-apcs-hmss-global
- qcom,qcm2290-apcs-hmss-global
- qcom,sdm660-apcs-hmss-global
- qcom,sdm845-apss-shared
- qcom,sm4250-apcs-hmss-global
- qcom,sm6115-apcs-hmss-global
- qcom,sm6125-apcs-hmss-global
reg:
maxItems: 1
@ -80,10 +90,9 @@ allOf:
- if:
properties:
compatible:
enum:
- qcom,msm8916-apcs-kpss-global
- qcom,msm8939-apcs-kpss-global
- qcom,qcs404-apcs-apps-global
contains:
enum:
- qcom,msm8916-apcs-kpss-global
then:
properties:
clocks:
@ -95,6 +104,25 @@ allOf:
- const: pll
- const: aux
- if:
properties:
compatible:
contains:
enum:
- qcom,msm8939-apcs-kpss-global
then:
properties:
clocks:
items:
- description: primary pll parent of the clock driver
- description: auxiliary parent
- description: reference clock
clock-names:
items:
- const: pll
- const: aux
- const: ref
- if:
properties:
compatible:
@ -113,6 +141,7 @@ allOf:
- const: ref
- const: pll
- const: aux
- if:
properties:
compatible:
@ -137,16 +166,10 @@ allOf:
compatible:
enum:
- qcom,msm8953-apcs-kpss-global
- qcom,msm8976-apcs-kpss-global
- qcom,msm8994-apcs-kpss-global
- qcom,msm8996-apcs-hmss-global
- qcom,msm8998-apcs-hmss-global
- qcom,qcm2290-apcs-hmss-global
- qcom,sdm660-apcs-hmss-global
- qcom,sdm845-apss-shared
- qcom,sm4250-apcs-hmss-global
- qcom,sm6115-apcs-hmss-global
- qcom,sm6125-apcs-hmss-global
then:
properties:
clocks: false
@ -192,7 +215,8 @@ examples:
#define GCC_APSS_AHB_CLK_SRC 1
#define GCC_GPLL0_AO_OUT_MAIN 123
apcs: mailbox@b011000 {
compatible = "qcom,qcs404-apcs-apps-global", "syscon";
compatible = "qcom,qcs404-apcs-apps-global",
"qcom,msm8916-apcs-kpss-global", "syscon";
reg = <0x0b011000 0x1000>;
#mbox-cells = <1>;
clocks = <&apcs_hfpll>, <&gcc GCC_GPLL0_AO_OUT_MAIN>;

View File

@ -35,6 +35,7 @@ properties:
- qcom,sm8450-ipcc
- qcom,sm8550-ipcc
- qcom,sm8650-ipcc
- qcom,x1e80100-ipcc
- const: qcom,ipcc
reg:

View File

@ -37,7 +37,9 @@ maintainers:
properties:
compatible:
const: xlnx,zynqmp-ipi-mailbox
enum:
- xlnx,zynqmp-ipi-mailbox
- xlnx,versal-ipi-mailbox
method:
description: |
@ -58,6 +60,12 @@ properties:
'#size-cells':
const: 2
reg:
maxItems: 2
reg-names:
maxItems: 2
xlnx,ipi-id:
description: |
Remote Xilinx IPI agent ID of which the mailbox is connected to.
@ -76,7 +84,17 @@ patternProperties:
properties:
compatible:
const: xlnx,zynqmp-ipi-dest-mailbox
enum:
- xlnx,zynqmp-ipi-dest-mailbox
- xlnx,versal-ipi-dest-mailbox
reg:
minItems: 1
maxItems: 4
reg-names:
minItems: 1
maxItems: 4
xlnx,ipi-id:
description:
@ -88,23 +106,44 @@ patternProperties:
description:
It contains tx(0) or rx(1) channel IPI id number.
reg:
maxItems: 4
allOf:
- if:
properties:
compatible:
contains:
enum:
- xlnx,zynqmp-ipi-dest-mailbox
then:
properties:
reg:
maxItems: 4
reg-names:
items:
- const: local_request_region
- const: local_response_region
- const: remote_request_region
- const: remote_response_region
reg-names:
items:
- const: local_request_region
- const: local_response_region
- const: remote_request_region
- const: remote_response_region
else:
properties:
reg:
minItems: 1
items:
- description: Remote IPI agent control register region
- description: Remote IPI agent optional message buffers
reg-names:
minItems: 1
items:
- const: ctrl
- const: msg
required:
- compatible
- reg
- reg-names
- "#mbox-cells"
additionalProperties: false
- xlnx,ipi-id
required:
- compatible
@ -113,6 +152,36 @@ required:
- '#size-cells'
- xlnx,ipi-id
allOf:
- if:
properties:
compatible:
contains:
enum:
- xlnx,zynqmp-ipi-mailbox
then:
properties:
reg: false
reg-names: false
else:
properties:
reg:
items:
- description: Host IPI agent control register region
- description: Host IPI agent optional message buffers
reg-names:
items:
- const: ctrl
- const: msg
required:
- reg
- reg-names
additionalProperties: false
examples:
- |
#include<dt-bindings/interrupt-controller/arm-gic.h>
@ -144,4 +213,41 @@ examples:
};
};
- |
#include<dt-bindings/interrupt-controller/arm-gic.h>
bus {
#address-cells = <2>;
#size-cells = <2>;
mailbox@ff300000 {
compatible = "xlnx,versal-ipi-mailbox";
interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <2>;
#size-cells = <2>;
reg = <0x0 0xff300000 0x0 0x1000>,
<0x0 0xff990000 0x0 0x1ff>;
reg-names = "ctrl", "msg";
xlnx,ipi-id = <0>;
ranges;
/* buffered IPI */
mailbox@ff340000 {
compatible = "xlnx,versal-ipi-dest-mailbox";
reg = <0x0 0xff340000 0x0 0x1000>,
<0x0 0xff990400 0x0 0x1ff>;
reg-names = "ctrl", "msg";
#mbox-cells = <1>;
xlnx,ipi-id = <4>;
};
/* bufferless IPI */
mailbox@ff370000 {
compatible = "xlnx,versal-ipi-dest-mailbox";
reg = <0x0 0xff370000 0x0 0x1000>;
reg-names = "ctrl";
#mbox-cells = <1>;
xlnx,ipi-id = <7>;
};
};
};
...

View File

@ -0,0 +1,223 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/ams,as3711.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Austria MicroSystems AS3711 Quad Buck High Current PMIC with Charger
maintainers:
- Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
description:
AS3711 is an I2C PMIC from Austria MicroSystems with multiple DC/DC and LDO
power supplies, a battery charger and an RTC. So far only bindings for the
two step-up DC/DC converters are defined.
properties:
compatible:
const: ams,as3711
reg:
maxItems: 1
backlight:
description:
Step-up converter configuration, to be used as a backlight source
type: object
additionalProperties: false
properties:
compatible:
const: ams,as3711-bl
su1-dev:
description: Framebuffer phandle for the first step-up converter
$ref: /schemas/types.yaml#/definitions/phandle
su1-max-uA:
description: Maximum current for the first step-up converter
$ref: /schemas/types.yaml#/definitions/uint32
su2-dev:
description: Framebuffer phandle for the second step-up converter
$ref: /schemas/types.yaml#/definitions/phandle
su2-max-uA:
description: Maximum current for the second step-up converter
$ref: /schemas/types.yaml#/definitions/uint32
su2-feedback-voltage:
description: Second step-up converter uses voltage feedback
type: boolean
su2-feedback-curr1:
description:
Second step-up converter uses CURR1 input for current feedback
type: boolean
su2-feedback-curr2:
description:
Second step-up converter uses CURR2 input for current feedback
type: boolean
su2-feedback-curr3:
description:
Second step-up converter uses CURR3 input for current feedback
type: boolean
su2-feedback-curr-auto:
description:
Second step-up converter uses automatic current feedback selection
type: boolean
su2-fbprot-lx-sd4:
description:
Second step-up converter uses LX_SD4 for over-voltage protection
type: boolean
su2-fbprot-gpio2:
description:
Second step-up converter uses GPIO2 for over-voltage protection
type: boolean
su2-fbprot-gpio3:
description:
Second step-up converter uses GPIO3 for over-voltage protection
type: boolean
su2-fbprot-gpio4:
description:
Second step-up converter uses GPIO4 for over-voltage protection
type: boolean
su2-auto-curr1:
description:
Second step-up converter uses CURR1 input for automatic current
feedback
type: boolean
su2-auto-curr2:
description:
Second step-up converter uses CURR2 input for automatic current
feedback
type: boolean
su2-auto-curr3:
description:
Second step-up converter uses CURR3 input for automatic current
feedback
type: boolean
required:
- compatible
dependentRequired:
# To use the SU1 converter as a backlight source the following two
# properties must be provided:
su1-dev: [ su1-max-uA ]
su1-max-uA: [ su1-dev ]
# To use the SU2 converter as a backlight source the following two
# properties must be provided:
su2-dev: [ su2-max-uA ]
su2-max-uA: [ su2-dev ]
su2-feedback-voltage: [ su2-dev ]
su2-feedback-curr1: [ su2-dev ]
su2-feedback-curr2: [ su2-dev ]
su2-feedback-curr3: [ su2-dev ]
su2-feedback-curr-auto: [ su2-dev ]
su2-fbprot-lx-sd4: [ su2-dev ]
su2-fbprot-gpio2: [ su2-dev ]
su2-fbprot-gpio3: [ su2-dev ]
su2-fbprot-gpio4: [ su2-dev ]
su2-auto-curr1: [ su2-feedback-curr-auto ]
su2-auto-curr2: [ su2-feedback-curr-auto ]
su2-auto-curr3: [ su2-feedback-curr-auto ]
dependentSchemas:
su2-dev:
allOf:
- oneOf:
- required:
- su2-feedback-voltage
- required:
- su2-feedback-curr1
- required:
- su2-feedback-curr2
- required:
- su2-feedback-curr3
- required:
- su2-feedback-curr-auto
- oneOf:
- required:
- su2-fbprot-lx-sd4
- required:
- su2-fbprot-gpio2
- required:
- su2-fbprot-gpio3
- required:
- su2-fbprot-gpio4
su2-feedback-curr-auto:
anyOf:
- required:
- su2-auto-curr1
- required:
- su2-auto-curr2
- required:
- su2-auto-curr3
regulators:
description: Other DC/DC and LDO supplies
type: object
unevaluatedProperties: false
patternProperties:
"^(sd[1-4]|ldo[1-8])$":
type: object
$ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
required:
- compatible
- reg
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
pmic@40 {
compatible = "ams,as3711";
reg = <0x40>;
regulators {
sd4 {
regulator-name = "1.215V";
regulator-min-microvolt = <1215000>;
regulator-max-microvolt = <1235000>;
};
ldo2 {
regulator-name = "2.8V CPU";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-always-on;
regulator-boot-on;
};
};
backlight {
compatible = "ams,as3711-bl";
su2-dev = <&lcdc>;
su2-max-uA = <36000>;
su2-feedback-curr-auto;
su2-fbprot-gpio4;
su2-auto-curr1;
su2-auto-curr2;
su2-auto-curr3;
};
};
};

View File

@ -1,73 +0,0 @@
AS3711 is an I2C PMIC from Austria MicroSystems with multiple DCDC and LDO power
supplies, a battery charger and an RTC. So far only bindings for the two stepup
DCDC converters are defined. Other DCDC and LDO supplies are configured, using
standard regulator properties, they must belong to a sub-node, called
"regulators" and be called "sd1" to "sd4" and "ldo1" to "ldo8." Stepup converter
configuration should be placed in a subnode, called "backlight."
Compulsory properties:
- compatible : must be "ams,as3711"
- reg : specifies the I2C address
To use the SU1 converter as a backlight source the following two properties must
be provided:
- su1-dev : framebuffer phandle
- su1-max-uA : maximum current
To use the SU2 converter as a backlight source the following two properties must
be provided:
- su2-dev : framebuffer phandle
- su1-max-uA : maximum current
Additionally one of these properties must be provided to select the type of
feedback used:
- su2-feedback-voltage : voltage feedback is used
- su2-feedback-curr1 : CURR1 input used for current feedback
- su2-feedback-curr2 : CURR2 input used for current feedback
- su2-feedback-curr3 : CURR3 input used for current feedback
- su2-feedback-curr-auto: automatic current feedback selection
and one of these to select the over-voltage protection pin
- su2-fbprot-lx-sd4 : LX_SD4 is used for over-voltage protection
- su2-fbprot-gpio2 : GPIO2 is used for over-voltage protection
- su2-fbprot-gpio3 : GPIO3 is used for over-voltage protection
- su2-fbprot-gpio4 : GPIO4 is used for over-voltage protection
If "su2-feedback-curr-auto" is selected, one or more of the following properties
have to be specified:
- su2-auto-curr1 : use CURR1 input for current feedback
- su2-auto-curr2 : use CURR2 input for current feedback
- su2-auto-curr3 : use CURR3 input for current feedback
Example:
as3711@40 {
compatible = "ams,as3711";
reg = <0x40>;
regulators {
sd4 {
regulator-name = "1.215V";
regulator-min-microvolt = <1215000>;
regulator-max-microvolt = <1235000>;
};
ldo2 {
regulator-name = "2.8V CPU";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-always-on;
regulator-boot-on;
};
};
backlight {
compatible = "ams,as3711-bl";
su2-dev = <&lcdc>;
su2-max-uA = <36000>;
su2-feedback-curr-auto;
su2-fbprot-gpio4;
su2-auto-curr1;
su2-auto-curr2;
su2-auto-curr3;
};
};

View File

@ -17,7 +17,7 @@ description: |
node.
The SPMI controller part is provided by
Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
properties:
$nodename:
@ -42,13 +42,6 @@ properties:
additionalProperties: false
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
patternProperties:
'^ldo[0-9]+$':
type: object
@ -66,72 +59,75 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/spmi/spmi.h>
pmic: pmic@0 {
compatible = "hisilicon,hi6421v600-spmi";
reg = <0 0>;
#interrupt-cells = <2>;
interrupt-controller;
interrupt-parent = <&gpio28>;
interrupts = <0 0>;
regulators {
#address-cells = <1>;
spmi {
#address-cells = <2>;
#size-cells = <0>;
ldo3: ldo3 {
regulator-name = "ldo3";
regulator-min-microvolt = <1500000>;
regulator-max-microvolt = <2000000>;
regulator-boot-on;
};
pmic@0 {
compatible = "hisilicon,hi6421v600-spmi";
reg = <0 SPMI_USID>;
ldo4: ldo4 {
regulator-name = "ldo4";
regulator-min-microvolt = <1725000>;
regulator-max-microvolt = <1900000>;
regulator-boot-on;
};
#interrupt-cells = <2>;
interrupt-controller;
interrupt-parent = <&gpio28>;
interrupts = <0 0>;
ldo9: ldo9 {
regulator-name = "ldo9";
regulator-min-microvolt = <1750000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
};
regulators {
ldo3 {
regulator-name = "ldo3";
regulator-min-microvolt = <1500000>;
regulator-max-microvolt = <2000000>;
regulator-boot-on;
};
ldo15: ldo15 {
regulator-name = "ldo15";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3000000>;
regulator-always-on;
};
ldo4 {
regulator-name = "ldo4";
regulator-min-microvolt = <1725000>;
regulator-max-microvolt = <1900000>;
regulator-boot-on;
};
ldo16: ldo16 {
regulator-name = "ldo16";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3000000>;
regulator-boot-on;
};
ldo9 {
regulator-name = "ldo9";
regulator-min-microvolt = <1750000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
};
ldo17: ldo17 {
regulator-name = "ldo17";
regulator-min-microvolt = <2500000>;
regulator-max-microvolt = <3300000>;
};
ldo15 {
regulator-name = "ldo15";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3000000>;
regulator-always-on;
};
ldo33: ldo33 {
regulator-name = "ldo33";
regulator-min-microvolt = <2500000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
};
ldo16 {
regulator-name = "ldo16";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3000000>;
regulator-boot-on;
};
ldo34: ldo34 {
regulator-name = "ldo34";
regulator-min-microvolt = <2600000>;
regulator-max-microvolt = <3300000>;
ldo17 {
regulator-name = "ldo17";
regulator-min-microvolt = <2500000>;
regulator-max-microvolt = <3300000>;
};
ldo33 {
regulator-name = "ldo33";
regulator-min-microvolt = <2500000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
};
ldo34 {
regulator-name = "ldo34";
regulator-min-microvolt = <2600000>;
regulator-max-microvolt = <3300000>;
};
};
};
};
};

View File

@ -99,10 +99,12 @@ examples:
- |
#include <dt-bindings/mfd/qcom-pm8008.h>
#include <dt-bindings/interrupt-controller/irq.h>
qupv3_se13_i2c {
i2c {
#address-cells = <1>;
#size-cells = <0>;
pm8008i@8 {
pmic@8 {
compatible = "qcom,pm8008";
reg = <0x8>;
#address-cells = <1>;

View File

@ -66,6 +66,7 @@ properties:
- qcom,pm8841
- qcom,pm8909
- qcom,pm8916
- qcom,pm8937
- qcom,pm8941
- qcom,pm8950
- qcom,pm8953
@ -134,9 +135,15 @@ patternProperties:
type: object
$ref: /schemas/sound/qcom,pm8916-wcd-analog-codec.yaml#
"^battery@[0-9a-f]+$":
type: object
oneOf:
- $ref: /schemas/power/supply/qcom,pm8916-bms-vm.yaml#
"^charger@[0-9a-f]+$":
type: object
oneOf:
- $ref: /schemas/power/supply/qcom,pm8916-lbc.yaml#
- $ref: /schemas/power/supply/qcom,pm8941-charger.yaml#
- $ref: /schemas/power/supply/qcom,pm8941-coincell.yaml#
- $ref: /schemas/power/supply/qcom,pmi8998-charger.yaml#

View File

@ -29,6 +29,8 @@ properties:
- qcom,sdx65-tcsr
- qcom,sm4450-tcsr
- qcom,sm8150-tcsr
- qcom,sm8250-tcsr
- qcom,sm8350-tcsr
- qcom,sm8450-tcsr
- qcom,tcsr-apq8064
- qcom,tcsr-apq8084

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