iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'for-6.8/amd-sfh' into for-linus

Browse Source 
- addition of new interfaces to export User presence information and
  Ambient light from amd-sfh to other drivers within the kernel (Basavaraj
  Natikar)
This commit is contained in:
Jiri Kosina 2024-01-08 20:57:04 +01:00
commit 6b93f350e5
6825 changed files with 223406 additions and 139357 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@ -74,7 +74,6 @@ modules.order
#
# RPM spec file (make rpm-pkg)
#
/kernel.spec
/rpmbuild/
#

4
.mailmap
View File

@ -95,6 +95,7 @@ Ben M Cahill <ben.m.cahill@intel.com>
Ben Widawsky <bwidawsk@kernel.org> <ben@bwidawsk.net>
Ben Widawsky <bwidawsk@kernel.org> <ben.widawsky@intel.com>
Ben Widawsky <bwidawsk@kernel.org> <benjamin.widawsky@intel.com>
Benjamin Poirier <benjamin.poirier@gmail.com> <bpoirier@suse.de>
Bjorn Andersson <andersson@kernel.org> <bjorn@kryo.se>
Bjorn Andersson <andersson@kernel.org> <bjorn.andersson@linaro.org>
Bjorn Andersson <andersson@kernel.org> <bjorn.andersson@sonymobile.com>
@ -116,6 +117,7 @@ Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
Chao Yu <chao@kernel.org> <chao2.yu@samsung.com>
Chao Yu <chao@kernel.org> <yuchao0@huawei.com>
Chester Lin <chester62515@gmail.com> <clin@suse.com>
Chris Chiu <chris.chiu@canonical.com> <chiu@endlessm.com>
Chris Chiu <chris.chiu@canonical.com> <chiu@endlessos.org>
Chris Lew <quic_clew@quicinc.com> <clew@codeaurora.org>
@ -128,6 +130,7 @@ Christian Brauner <brauner@kernel.org> <christian.brauner@ubuntu.com>
Christian Marangi <ansuelsmth@gmail.com>
Christophe Ricard <christophe.ricard@gmail.com>
Christoph Hellwig <hch@lst.de>
Claudiu Beznea <claudiu.beznea@tuxon.dev> <claudiu.beznea@microchip.com>
Colin Ian King <colin.i.king@gmail.com> <colin.king@canonical.com>
Corey Minyard <minyard@acm.org>
Damian Hobson-Garcia <dhobsong@igel.co.jp>
@ -571,6 +574,7 @@ Takashi YOSHII <takashi.yoshii.zj@renesas.com>
Tamizh Chelvam Raja <quic_tamizhr@quicinc.com> <tamizhr@codeaurora.org>
Taniya Das <quic_tdas@quicinc.com> <tdas@codeaurora.org>
Tejun Heo <htejun@gmail.com>
Tomeu Vizoso <tomeu@tomeuvizoso.net> <tomeu.vizoso@collabora.com>
Thomas Graf <tgraf@suug.ch>
Thomas Körper <socketcan@esd.eu> <thomas.koerper@esd.eu>
Thomas Pedersen <twp@codeaurora.org>

8
CREDITS
View File

@ -2944,6 +2944,14 @@ D: IPX development and support
N: Venkatesh Pallipadi (Venki)
D: x86/HPET
N: Antti Palosaari
E: crope@iki.fi
D: Various DVB drivers
W: https://palosaari.fi/linux/
S: Yliopistokatu 1 D 513
S: FI-90570 Oulu
S: FINLAND
N: Kyungmin Park
E: kyungmin.park@samsung.com
D: Samsung S5Pv210 and Exynos4210 mobile platforms

6
Documentation/ABI/stable/sysfs-driver-dma-idxd
View File

@ -270,6 +270,12 @@ Description: Shows the operation capability bits displayed in bitmap format
correlates to the operations allowed. It's visible only
on platforms that support the capability.
What: /sys/bus/dsa/devices/wq<m>.<n>/driver_name
Date: Sept 8, 2023
KernelVersion: 6.7.0
Contact: dmaengine@vger.kernel.org
Description: Name of driver to be bounded to the wq.
What: /sys/bus/dsa/devices/engine<m>.<n>/group_id
Date: Oct 25, 2019
KernelVersion: 5.6.0

82
Documentation/ABI/testing/configfs-tsm Normal file
View File

@ -0,0 +1,82 @@
What: /sys/kernel/config/tsm/report/$name/inblob
Date: September, 2023
KernelVersion: v6.7
Contact: linux-coco@lists.linux.dev
Description:
(WO) Up to 64 bytes of user specified binary data. For replay
protection this should include a nonce, but the kernel does not
place any restrictions on the content.
What: /sys/kernel/config/tsm/report/$name/outblob
Date: September, 2023
KernelVersion: v6.7
Contact: linux-coco@lists.linux.dev
Description:
(RO) Binary attestation report generated from @inblob and other
options The format of the report is implementation specific
where the implementation is conveyed via the @provider
attribute.
What: /sys/kernel/config/tsm/report/$name/auxblob
Date: October, 2023
KernelVersion: v6.7
Contact: linux-coco@lists.linux.dev
Description:
(RO) Optional supplemental data that a TSM may emit, visibility
of this attribute depends on TSM, and may be empty if no
auxiliary data is available.
When @provider is "sev_guest" this file contains the
"cert_table" from SEV-ES Guest-Hypervisor Communication Block
Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ.
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
What: /sys/kernel/config/tsm/report/$name/provider
Date: September, 2023
KernelVersion: v6.7
Contact: linux-coco@lists.linux.dev
Description:
(RO) A name for the format-specification of @outblob like
"sev_guest" [1] or "tdx_guest" [2] in the near term, or a
common standard format in the future.
[1]: SEV Secure Nested Paging Firmware ABI Specification
Revision 1.55 Table 22
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56860.pdf
[2]: Intel® Trust Domain Extensions Data Center Attestation
Primitives : Quote Generation Library and Quote Verification
Library Revision 0.8 Appendix 4,5
https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_TDX_DCAP_Quoting_Library_API.pdf
What: /sys/kernel/config/tsm/report/$name/generation
Date: September, 2023
KernelVersion: v6.7
Contact: linux-coco@lists.linux.dev
Description:
(RO) The value in this attribute increments each time @inblob or
any option is written. Userspace can detect conflicts by
checking generation before writing to any attribute and making
sure the number of writes matches expectations after reading
@outblob, or it can prevent conflicts by creating a report
instance per requesting context.
What: /sys/kernel/config/tsm/report/$name/privlevel
Date: September, 2023
KernelVersion: v6.7
Contact: linux-coco@lists.linux.dev
Description:
(WO) Attribute is visible if a TSM implementation provider
supports the concept of attestation reports for TVMs running at
different privilege levels, like SEV-SNP "VMPL", specify the
privilege level via this attribute. The minimum acceptable
value is conveyed via @privlevel_floor and the maximum
acceptable value is TSM_PRIVLEVEL_MAX (3).
What: /sys/kernel/config/tsm/report/$name/privlevel_floor
Date: September, 2023
KernelVersion: v6.7
Contact: linux-coco@lists.linux.dev
Description:
(RO) Indicates the minimum permissible value that can be written
to @privlevel.

2
Documentation/ABI/testing/configfs-usb-gadget-uac2
View File

@ -35,4 +35,6 @@ Description:
req_number the number of pre-allocated requests
for both capture and playback
function_name name of the interface
c_terminal_type code of the capture terminal type
p_terminal_type code of the playback terminal type
===================== =======================================

24
Documentation/ABI/testing/debugfs-driver-qat
View File

@ -1,4 +1,4 @@
What: /sys/kernel/debug/qat_<device>_<BDF>/qat/fw_counters
What: /sys/kernel/debug/qat_<device>_<BDF>/fw_counters
Date: November 2023
KernelVersion: 6.6
Contact: qat-linux@intel.com
@ -59,3 +59,25 @@ Description: (RO) Read returns the device health status.
The driver does not monitor for Heartbeat. It is left for a user
to poll the status periodically.
What: /sys/kernel/debug/qat_<device>_<BDF>/pm_status
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description: (RO) Read returns power management information specific to the
QAT device.
This attribute is only available for qat_4xxx devices.
What: /sys/kernel/debug/qat_<device>_<BDF>/cnv_errors
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description: (RO) Read returns, for each Acceleration Engine (AE), the number
of errors and the type of the last error detected by the device
when performing verified compression.
Reported counters::
<N>: Number of Compress and Verify (CnV) errors and type
of the last CnV error detected by Acceleration
Engine N.

66
Documentation/ABI/testing/sysfs-bus-cdx
View File

@ -28,14 +28,57 @@ Description:
of a device manufacturer.
Combination of Vendor ID and Device ID identifies a device.
What: /sys/bus/cdx/devices/.../subsystem_vendor
Date: July 2023
Contact: puneet.gupta@amd.com
Description:
Subsystem Vendor ID for this CDX device, in hexadecimal.
Subsystem Vendor ID is 16 bit identifier specific to the
card manufacturer.
What: /sys/bus/cdx/devices/.../subsystem_device
Date: July 2023
Contact: puneet.gupta@amd.com
Description:
Subsystem Device ID for this CDX device, in hexadecimal
Subsystem Device ID is 16 bit identifier specific to the
card manufacturer.
What: /sys/bus/cdx/devices/.../class
Date: July 2023
Contact: puneet.gupta@amd.com
Description:
This file contains the class of the CDX device, in hexadecimal.
Class is 24 bit identifier specifies the functionality of the device.
What: /sys/bus/cdx/devices/.../revision
Date: July 2023
Contact: puneet.gupta@amd.com
Description:
This file contains the revision field of the CDX device, in hexadecimal.
Revision is 8 bit revision identifier of the device.
What: /sys/bus/cdx/devices/.../enable
Date: October 2023
Contact: abhijit.gangurde@amd.com
Description:
CDX bus should be disabled before updating the devices in FPGA.
Writing n/0/off will attempt to disable the CDX bus and.
writing y/1/on will attempt to enable the CDX bus. Reading this file
gives the current state of the bus, 1 for enabled and 0 for disabled.
For example::
# echo 1 > /sys/bus/cdx/.../enable
What: /sys/bus/cdx/devices/.../reset
Date: March 2023
Contact: nipun.gupta@amd.com
Description:
Writing y/1/on to this file resets the CDX device.
On resetting the device, the corresponding driver is notified
twice, once before the device is being reset, and again after
the reset has been complete.
Writing y/1/on to this file resets the CDX device or all devices
on the bus. On resetting the device, the corresponding driver is
notified twice, once before the device is being reset, and again
after the reset has been complete.
For example::
@ -54,3 +97,18 @@ Description:
For example::
# echo 1 > /sys/bus/cdx/devices/.../remove
What: /sys/bus/cdx/devices/.../modalias
Date: July 2023
Contact: nipun.gupta@amd.com
Description:
This attribute indicates the CDX ID of the device.
That is in the format:
cdx:vXXXXdXXXXsvXXXXsdXXXXcXXXXXX,
where:
- vXXXX contains the vendor ID;
- dXXXX contains the device ID;
- svXXXX contains the subsystem vendor ID;
- sdXXXX contains the subsystem device ID;
- cXXXXXX contains the device class.

30
Documentation/ABI/testing/sysfs-bus-cxl
View File

@ -178,6 +178,21 @@ Description:
hardware decoder target list.
What: /sys/bus/cxl/devices/portX/decoders_committed
Date: October, 2023
KernelVersion: v6.7
Contact: linux-cxl@vger.kernel.org
Description:
(RO) A memory device is considered active when any of its
decoders are in the "committed" state (See CXL 3.0 8.2.4.19.7
CXL HDM Decoder n Control Register). Hotplug and destructive
operations like "sanitize" are blocked while device is actively
decoding a Host Physical Address range. Note that this number
may be elevated without any regionX objects active or even
enumerated, as this may be due to decoders established by
platform firwmare or a previous kernel (kexec).
What: /sys/bus/cxl/devices/decoderX.Y
Date: June, 2021
KernelVersion: v5.14
@ -369,6 +384,21 @@ Description:
provided it is currently idle / not bound to a driver.
What: /sys/bus/cxl/devices/decoderX.Y/qos_class
Date: May, 2023
KernelVersion: v6.5
Contact: linux-cxl@vger.kernel.org
Description:
(RO) For CXL host platforms that support "QoS Telemmetry" this
root-decoder-only attribute conveys a platform specific cookie
that identifies a QoS performance class for the CXL Window.
This class-id can be compared against a similar "qos_class"
published for each memory-type that an endpoint supports. While
it is not required that endpoints map their local memory-class
to a matching platform class, mismatches are not recommended and
there are platform specific side-effects that may result.
What: /sys/bus/cxl/devices/regionZ/uuid
Date: May, 2022
KernelVersion: v6.0

4
Documentation/ABI/testing/sysfs-bus-i3c
View File

@ -67,7 +67,7 @@ What: /sys/bus/i3c/devices/i3c-<bus-id>/pid
KernelVersion: 5.0
Contact: linux-i3c@vger.kernel.org
Description:
PID stands for Provisional ID and is used to uniquely identify
PID stands for Provisioned ID and is used to uniquely identify
a device on a bus. This PID contains information about the
vendor, the part and an instance ID so that several devices of
the same type can be connected on the same bus.
@ -123,7 +123,7 @@ What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/pid
KernelVersion: 5.0
Contact: linux-i3c@vger.kernel.org
Description:
PID stands for Provisional ID and is used to uniquely identify
PID stands for Provisioned ID and is used to uniquely identify
a device on a bus. This PID contains information about the
vendor, the part and an instance ID so that several devices of
the same type can be connected on the same bus.

75
Documentation/ABI/testing/sysfs-bus-iio
View File

@ -279,6 +279,35 @@ Description:
but should match other such assignments on device).
Units after application of scale and offset are m/s^2.
What: /sys/bus/iio/devices/iio:deviceX/in_deltaangl_x_raw
What: /sys/bus/iio/devices/iio:deviceX/in_deltaangl_y_raw
What: /sys/bus/iio/devices/iio:deviceX/in_deltaangl_z_raw
KernelVersion: 6.5
Contact: linux-iio@vger.kernel.org
Description:
Angular displacement between two consecutive samples on x, y or
z (may be arbitrarily assigned but should match other such
assignments on device).
In order to compute the total angular displacement during a
desired period of time, the application should sum-up the delta
angle samples acquired during that time.
Units after application of scale and offset are radians.
What: /sys/bus/iio/devices/iio:deviceX/in_deltavelocity_x_raw
What: /sys/bus/iio/devices/iio:deviceX/in_deltavelocity_y_raw
What: /sys/bus/iio/devices/iio:deviceX/in_deltavelocity_z_raw
KernelVersion: 6.5
Contact: linux-iio@vger.kernel.org
Description:
The linear velocity change between two consecutive samples on x,
y or z (may be arbitrarily assigned but should match other such
assignments on device).
In order to compute the total linear velocity change during a
desired period of time, the application should sum-up the delta
velocity samples acquired during that time.
Units after application of scale and offset are meters per
second.
What: /sys/bus/iio/devices/iio:deviceX/in_angl_raw
What: /sys/bus/iio/devices/iio:deviceX/in_anglY_raw
KernelVersion: 4.17
@ -461,6 +490,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_scale
What: /sys/bus/iio/devices/iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_scale
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_scale
What: /sys/bus/iio/devices/iio:deviceX/in_countY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_deltaangl_scale
What: /sys/bus/iio/devices/iio:deviceX/in_deltavelocity_scale
What: /sys/bus/iio/devices/iio:deviceX/in_angl_scale
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_x_scale
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_y_scale
@ -1332,6 +1363,12 @@ Description:
What: /sys/.../iio:deviceX/bufferY/in_accel_x_en
What: /sys/.../iio:deviceX/bufferY/in_accel_y_en
What: /sys/.../iio:deviceX/bufferY/in_accel_z_en
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_x_en
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_y_en
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_z_en
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_x_en
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_y_en
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_z_en
What: /sys/.../iio:deviceX/bufferY/in_anglvel_x_en
What: /sys/.../iio:deviceX/bufferY/in_anglvel_y_en
What: /sys/.../iio:deviceX/bufferY/in_anglvel_z_en
@ -1362,6 +1399,8 @@ Description:
Scan element control for triggered data capture.
What: /sys/.../iio:deviceX/bufferY/in_accel_type
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_type
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_type
What: /sys/.../iio:deviceX/bufferY/in_anglvel_type
What: /sys/.../iio:deviceX/bufferY/in_magn_type
What: /sys/.../iio:deviceX/bufferY/in_incli_type
@ -1416,6 +1455,12 @@ What: /sys/.../iio:deviceX/bufferY/in_voltage_q_index
What: /sys/.../iio:deviceX/bufferY/in_accel_x_index
What: /sys/.../iio:deviceX/bufferY/in_accel_y_index
What: /sys/.../iio:deviceX/bufferY/in_accel_z_index
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_x_index
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_y_index
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_z_index
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_x_index
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_y_index
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_z_index
What: /sys/.../iio:deviceX/bufferY/in_anglvel_x_index
What: /sys/.../iio:deviceX/bufferY/in_anglvel_y_index
What: /sys/.../iio:deviceX/bufferY/in_anglvel_z_index
@ -2179,3 +2224,33 @@ Contact: linux-iio@vger.kernel.org
Description:
Number of conditions that must occur, during a running
period, before an event is generated.
What: /sys/bus/iio/devices/iio:deviceX/in_colortemp_raw
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
Represents light color temperature, which measures light color
temperature in Kelvin.
What: /sys/bus/iio/devices/iio:deviceX/in_chromaticity_x_raw
What: /sys/bus/iio/devices/iio:deviceX/in_chromaticity_y_raw
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
The x and y light color coordinate on the CIE 1931 chromaticity
diagram.
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_mag_either_label
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_mag_rising_label
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_thresh_falling_label
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_thresh_rising_label
What: /sys/bus/iio/devices/iio:deviceX/events/in_anglvelY_mag_rising_label
What: /sys/bus/iio/devices/iio:deviceX/events/in_anglY_thresh_rising_label
What: /sys/bus/iio/devices/iio:deviceX/events/in_phaseY_mag_rising_label
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
Optional symbolic label to a device channel event.
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.

53
Documentation/ABI/testing/sysfs-bus-iio-adc-mcp3564 Normal file
View File

@ -0,0 +1,53 @@
What: /sys/bus/iio/devices/iio:deviceX/boost_current_gain
KernelVersion: 6.4
Contact: linux-iio@vger.kernel.org
Description:
This attribute is used to set the gain of the biasing current
circuit of the Delta-Sigma modulator. The different BOOST
settings are applied to the entire modulator circuit, including
the voltage reference buffers.
What: /sys/bus/iio/devices/iio:deviceX/boost_current_gain_available
KernelVersion: 6.4
Contact: linux-iio@vger.kernel.org
Description:
Reading returns a list with the possible gain values for
the current biasing circuit of the Delta-Sigma modulator.
What: /sys/bus/iio/devices/iio:deviceX/auto_zeroing_mux_enable
KernelVersion: 6.4
Contact: linux-iio@vger.kernel.org
Description:
This attribute is used to enable the analog input multiplexer
auto-zeroing algorithm (the input multiplexer and the ADC
include an offset cancellation algorithm that cancels the offset
contribution of the ADC). When the offset cancellation algorithm
is enabled, ADC takes two conversions, one with the differential
input as VIN+/VIN-, one with VIN+/VIN- inverted. In this case the
conversion time is multiplied by two compared to the default
case where the algorithm is disabled. This technique allows the
cancellation of the ADC offset error and the achievement of
ultra-low offset without any digital calibration. The resulting
offset is the residue of the difference between the two
conversions, which is on the order of magnitude of the noise
floor. This offset is effectively canceled at every conversion,
so the residual offset error temperature drift is extremely low.
Write '1' to enable it, write '0' to disable it.
What: /sys/bus/iio/devices/iio:deviceX/auto_zeroing_ref_enable
KernelVersion: 6.4
Contact: linux-iio@vger.kernel.org
Description:
This attribute is used to enable the chopping algorithm for the
internal voltage reference buffer. This setting has no effect
when external voltage reference is selected.
Internal voltage reference buffer injects a certain quantity of
1/f noise into the system that can be modulated with the
incoming input signals and can limit the SNR performance at
higher Oversampling Ratio values (over 256). To overcome this
limitation, the buffer includes an auto-zeroing algorithm that
greatly reduces (cancels out) the 1/f noise and cancels the
offset value of the reference buffer. As a result, the SNR of
the system is not affected by this 1/f noise component of the
reference buffer, even at maximum oversampling ratio values.
Write '1' to enable it, write '0' to disable it.

27
Documentation/ABI/testing/sysfs-bus-iio-resolver-ad2s1210 Normal file
View File

@ -0,0 +1,27 @@
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltage0_mag_rising_reset_max
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
Reading returns the current Degradation of Signal Reset Maximum
Threshold value in millivolts. Writing sets the value.
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltage0_mag_rising_reset_max_available
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
Reading returns the allowable voltage range for
in_altvoltage0_mag_rising_reset_max.
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltage0_mag_rising_reset_min
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
Reading returns the current Degradation of Signal Reset Minimum
Threshold value in millivolts. Writing sets the value.
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltage0_mag_rising_reset_min_available
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
Reading returns the allowable voltage range for
in_altvoltage0_mag_rising_reset_min.

9
Documentation/ABI/testing/sysfs-bus-optee-devices
View File

@ -6,3 +6,12 @@ Description:
OP-TEE bus provides reference to registered drivers under this directory. The <uuid>
matches Trusted Application (TA) driver and corresponding TA in secure OS. Drivers
are free to create needed API under optee-ta-<uuid> directory.
What: /sys/bus/tee/devices/optee-ta-<uuid>/need_supplicant
Date: November 2023
KernelVersion: 6.7
Contact: op-tee@lists.trustedfirmware.org
Description:
Allows to distinguish whether an OP-TEE based TA/device requires user-space
tee-supplicant to function properly or not. This attribute will be present for
devices which depend on tee-supplicant to be running.

9
Documentation/ABI/testing/sysfs-bus-usb
View File

@ -313,6 +313,15 @@ Description:
Inter-Chip SSIC devices support asymmetric lanes up to 4 lanes per
direction. Devices before USB 3.2 are single lane (tx_lanes = 1)
What: /sys/bus/usb/devices/.../typec
Date: November 2023
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Symlink to the USB Type-C partner device. USB Type-C partner
represents the component that communicates over the
Configuration Channel (CC signal on USB Type-C connectors and
cables) with the local port.
What: /sys/bus/usb/devices/usbX/bAlternateSetting
Description:
The current interface alternate setting number, in decimal.

4
Documentation/ABI/testing/sysfs-bus-vdpa
View File

@ -1,4 +1,4 @@
What: /sys/bus/vdpa/driver_autoprobe
What: /sys/bus/vdpa/drivers_autoprobe
Date: March 2020
Contact: virtualization@lists.linux-foundation.org
Description:
@ -17,7 +17,7 @@ Description:
Writing a device name to this file will cause the kernel binds
devices to a compatible driver.
This can be useful when /sys/bus/vdpa/driver_autoprobe is
This can be useful when /sys/bus/vdpa/drivers_autoprobe is
disabled.
What: /sys/bus/vdpa/drivers/.../bind

9
Documentation/ABI/testing/sysfs-class-led
View File

@ -59,15 +59,6 @@ Description:
brightness. Reading this file when no hw brightness change
event has happened will return an ENODATA error.
What: /sys/class/leds/<led>/color
Date: June 2023
KernelVersion: 6.5
Description:
Color of the LED.
This is a read-only file. Reading this file returns the color
of the LED as a string (e.g: "red", "green", "multicolor").
What: /sys/class/leds/<led>/trigger
Date: March 2006
KernelVersion: 2.6.17

14
Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia
View File

@ -12,3 +12,17 @@ Description: (RW) On the front panel of the Turris Omnia router there is also
able to change this setting from software.
Format: %i
What: /sys/class/leds/<led>/device/gamma_correction
Date: August 2023
KernelVersion: 6.6
Contact: Marek Behún <kabel@kernel.org>
Description: (RW) Newer versions of the microcontroller firmware of the
Turris Omnia router support gamma correction for the RGB LEDs.
This feature can be enabled/disabled by writing to this file.
If the feature is not supported because the MCU firmware is too
old, the file always reads as 0, and writing to the file results
in the EOPNOTSUPP error.
Format: %i

7
Documentation/ABI/testing/sysfs-class-usb_power_delivery
View File

@ -124,6 +124,13 @@ Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The voltage the supply supports in millivolts.
What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:fixed_supply/peak_current
Date: October 2023
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
This file shows the value of the Fixed Power Source Peak Current
Capability field.
What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:fixed_supply/maximum_current
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>

4
Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
View File

@ -17,7 +17,7 @@ Description: Read only. Returns the firmware version of Intel MAX10
What: /sys/bus/.../drivers/intel-m10-bmc/.../mac_address
Date: January 2021
KernelVersion: 5.12
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Peter Colberg <peter.colberg@intel.com>
Description: Read only. Returns the first MAC address in a block
of sequential MAC addresses assigned to the board
that is managed by the Intel MAX10 BMC. It is stored in
@ -28,7 +28,7 @@ Description: Read only. Returns the first MAC address in a block
What: /sys/bus/.../drivers/intel-m10-bmc/.../mac_count
Date: January 2021
KernelVersion: 5.12
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Peter Colberg <peter.colberg@intel.com>
Description: Read only. Returns the number of sequential MAC
addresses assigned to the board managed by the Intel
MAX10 BMC. This value is stored in FLASH and is mirrored

48
Documentation/ABI/testing/sysfs-driver-qat
View File

@ -29,6 +29,8 @@ Description: (RW) Reports the current configuration of the QAT device.
services
* asym;sym: identical to sym;asym
* dc: the device is configured for running compression services
* dcc: identical to dc but enables the dc chaining feature,
hash then compression. If this is not required chose dc
* sym: the device is configured for running symmetric crypto
services
* asym: the device is configured for running asymmetric crypto
@ -93,3 +95,49 @@ Description: (RW) This configuration option provides a way to force the device i
0
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat/rp2srv
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RW) This attribute provides a way for a user to query a
specific ring pair for the type of service that it is currently
configured for.
When written to, the value is cached and used to perform the
read operation. Allowed values are in the range 0 to N-1, where
N is the max number of ring pairs supported by a device. This
can be queried using the attribute qat/num_rps.
A read returns the service associated to the ring pair queried.
The values are:
* dc: the ring pair is configured for running compression services
* sym: the ring pair is configured for running symmetric crypto
services
* asym: the ring pair is configured for running asymmetric crypto
services
Example usage::
# echo 1 > /sys/bus/pci/devices/<BDF>/qat/rp2srv
# cat /sys/bus/pci/devices/<BDF>/qat/rp2srv
sym
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat/num_rps
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RO) Returns the number of ring pairs that a single device has.
Example usage::
# cat /sys/bus/pci/devices/<BDF>/qat/num_rps
64
This attribute is only available for qat_4xxx devices.

41
Documentation/ABI/testing/sysfs-driver-qat_ras Normal file
View File

@ -0,0 +1,41 @@
What: /sys/bus/pci/devices/<BDF>/qat_ras/errors_correctable
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description: (RO) Reports the number of correctable errors detected by the device.
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_ras/errors_nonfatal
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description: (RO) Reports the number of non fatal errors detected by the device.
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_ras/errors_fatal
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description: (RO) Reports the number of fatal errors detected by the device.
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_ras/reset_error_counters
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description: (WO) Write to resets all error counters of a device.
The following example reports how to reset the counters::
# echo 1 > /sys/bus/pci/devices/<BDF>/qat_ras/reset_error_counters
# cat /sys/bus/pci/devices/<BDF>/qat_ras/errors_correctable
0
# cat /sys/bus/pci/devices/<BDF>/qat_ras/errors_nonfatal
0
# cat /sys/bus/pci/devices/<BDF>/qat_ras/errors_fatal
0
This attribute is only available for qat_4xxx devices.

226
Documentation/ABI/testing/sysfs-driver-qat_rl Normal file
View File

@ -0,0 +1,226 @@
What: /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(WO) This attribute is used to perform an operation on an SLA.
The supported operations are: add, update, rm, rm_all, and get.
Input values must be filled through the associated attribute in
this group before a write to this file.
If the operation completes successfully, the associated
attributes will be updated.
The associated attributes are: cir, pir, srv, rp, and id.
Supported operations:
* add: Creates a new SLA with the provided inputs from user.
* Inputs: cir, pir, srv, and rp
* Output: id
* get: Returns the configuration of the specified SLA in id attribute
* Inputs: id
* Outputs: cir, pir, srv, and rp
* update: Updates the SLA with new values set in the following attributes
* Inputs: id, cir, and pir
* rm: Removes the specified SLA in the id attribute.
* Inputs: id
* rm_all: Removes all the configured SLAs.
* Inputs: None
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_rl/rp
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RW) When read, reports the current assigned ring pairs for the
queried SLA.
When wrote to, configures the ring pairs associated to a new SLA.
The value is a 64-bit bit mask and is written/displayed in hex.
Each bit of this mask represents a single ring pair i.e.,
bit 1 == ring pair id 0; bit 3 == ring pair id 2.
Selected ring pairs must to be assigned to a single service,
i.e. the one provided with the srv attribute. The service
assigned to a certain ring pair can be checked by querying
the attribute qat/rp2srv.
The maximum number of ring pairs is 4 per SLA.
Applicability in sla_op:
* WRITE: add operation
* READ: get operation
Example usage::
## Read
# echo 4 > /sys/bus/pci/devices/<BDF>/qat_rl/id
# cat /sys/bus/pci/devices/<BDF>/qat_rl/rp
0x5
## Write
# echo 0x5 > /sys/bus/pci/devices/<BDF>/qat_rl/rp
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_rl/id
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RW) If written to, the value is used to retrieve a particular
SLA and operate on it.
This is valid only for the following operations: update, rm,
and get.
A read of this attribute is only guaranteed to have correct data
after creation of an SLA.
Applicability in sla_op:
* WRITE: rm and update operations
* READ: add and get operations
Example usage::
## Read
## Set attributes e.g. cir, pir, srv, etc
# echo "add" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
# cat /sys/bus/pci/devices/<BDF>/qat_rl/id
4
## Write
# echo 7 > /sys/bus/pci/devices/<BDF>/qat_rl/id
# echo "get" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
# cat /sys/bus/pci/devices/<BDF>/qat_rl/rp
0x5 ## ring pair ID 0 and ring pair ID 2
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_rl/cir
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RW) Committed information rate (CIR). Rate guaranteed to be
achieved by a particular SLA. The value is expressed in
permille scale, i.e. 1000 refers to the maximum device
throughput for a selected service.
After sending a "get" to sla_op, this will be populated with the
CIR for that queried SLA.
Write to this file before sending an "add/update" sla_op, to set
the SLA to the specified value.
Applicability in sla_op:
* WRITE: add and update operations
* READ: get operation
Example usage::
## Write
# echo 500 > /sys/bus/pci/devices/<BDF>/qat_rl/cir
# echo "add" /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
## Read
# echo 4 > /sys/bus/pci/devices/<BDF>/qat_rl/id
# echo "get" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
# cat /sys/bus/pci/devices/<BDF>/qat_rl/cir
500
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_rl/pir
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RW) Peak information rate (PIR). The maximum rate that can be
achieved by that particular SLA. An SLA can reach a value
between CIR and PIR when the device is not fully utilized by
requests from other users (assigned to different SLAs).
After sending a "get" to sla_op, this will be populated with the
PIR for that queried SLA.
Write to this file before sending an "add/update" sla_op, to set
the SLA to the specified value.
Applicability in sla_op:
* WRITE: add and update operations
* READ: get operation
Example usage::
## Write
# echo 750 > /sys/bus/pci/devices/<BDF>/qat_rl/pir
# echo "add" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
## Read
# echo 4 > /sys/bus/pci/devices/<BDF>/qat_rl/id
# echo "get" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
# cat /sys/bus/pci/devices/<BDF>/qat_rl/pir
750
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_rl/srv
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RW) Service (SRV). Represents the service (sym, asym, dc)
associated to an SLA.
Can be written to or queried to set/show the SRV type for an SLA.
The SRV attribute is used to specify the SRV type before adding
an SLA. After an SLA is configured, reports the service
associated to that SLA.
Applicability in sla_op:
* WRITE: add and update operations
* READ: get operation
Example usage::
## Write
# echo "dc" > /sys/bus/pci/devices/<BDF>/qat_rl/srv
# echo "add" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
# cat /sys/bus/pci/devices/<BDF>/qat_rl/id
4
## Read
# echo 4 > /sys/bus/pci/devices/<BDF>/qat_rl/id
# echo "get" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
# cat /sys/bus/pci/devices/<BDF>/qat_rl/srv
dc
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_rl/cap_rem
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RW) This file will return the remaining capability for a
particular service/sla. This is the remaining value that a new
SLA can be set to or a current SLA can be increased with.
Example usage::
# echo "asym" > /sys/bus/pci/devices/<BDF>/qat_rl/cap_rem
# cat /sys/bus/pci/devices/<BDF>/qat_rl/cap_rem
250
# echo 250 > /sys/bus/pci/devices/<BDF>/qat_rl/cir
# echo "add" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
# cat /sys/bus/pci/devices/<BDF>/qat_rl/cap_rem
0
This attribute is only available for qat_4xxx devices.

7
Documentation/ABI/testing/sysfs-kernel-mm-damon
View File

@ -151,6 +151,13 @@ Contact: SeongJae Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the action
of the scheme.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/apply_interval_us
Date: Sep 2023
Contact: SeongJae Park <sj@kernel.org>
Description: Writing a value to this file sets the action apply interval of
the scheme in microseconds. Reading this file returns the
value.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/sz/min
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>

15
Documentation/ABI/testing/sysfs-tty
View File

@ -87,19 +87,22 @@ What: /sys/class/tty/ttyS<x>/close_delay
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
Show the closing delay time for this port in ms.
Show the closing delay time for this port in centiseconds.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS<x>/closing_wait
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
Show the close wait time for this port in ms.
Show the close wait time for this port in centiseconds.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
Waiting forever is represented as 0. If waiting on close is
disabled then the value is 65535.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS<x>/custom_divisor
Date: October 2012

1
Documentation/admin-guide/cgroup-v1/memory.rst
View File

@ -551,6 +551,7 @@ memory.stat file includes following statistics:
event happens each time a page is unaccounted from the
cgroup.
swap # of bytes of swap usage
swapcached # of bytes of swap cached in memory
dirty # of bytes that are waiting to get written back to the disk.
writeback # of bytes of file/anon cache that are queued for syncing to
disk.

38
Documentation/admin-guide/cgroup-v2.rst
View File

@ -210,6 +210,35 @@ cgroup v2 currently supports the following mount options.
relying on the original semantics (e.g. specifying bogusly
high 'bypass' protection values at higher tree levels).
memory_hugetlb_accounting
Count HugeTLB memory usage towards the cgroup's overall
memory usage for the memory controller (for the purpose of
statistics reporting and memory protetion). This is a new
behavior that could regress existing setups, so it must be
explicitly opted in with this mount option.
A few caveats to keep in mind:
* There is no HugeTLB pool management involved in the memory
controller. The pre-allocated pool does not belong to anyone.
Specifically, when a new HugeTLB folio is allocated to
the pool, it is not accounted for from the perspective of the
memory controller. It is only charged to a cgroup when it is
actually used (for e.g at page fault time). Host memory
overcommit management has to consider this when configuring
hard limits. In general, HugeTLB pool management should be
done via other mechanisms (such as the HugeTLB controller).
* Failure to charge a HugeTLB folio to the memory controller
results in SIGBUS. This could happen even if the HugeTLB pool
still has pages available (but the cgroup limit is hit and
reclaim attempt fails).
* Charging HugeTLB memory towards the memory controller affects
memory protection and reclaim dynamics. Any userspace tuning
(of low, min limits for e.g) needs to take this into account.
* HugeTLB pages utilized while this option is not selected
will not be tracked by the memory controller (even if cgroup
v2 is remounted later on).
Organizing Processes and Threads
--------------------------------
@ -1539,6 +1568,15 @@ PAGE_SIZE multiple when read back.
collapsing an existing range of pages. This counter is not
present when CONFIG_TRANSPARENT_HUGEPAGE is not set.
thp_swpout (npn)
Number of transparent hugepages which are swapout in one piece
without splitting.
thp_swpout_fallback (npn)
Number of transparent hugepages which were split before swapout.
Usually because failed to allocate some continuous swap space
for the huge page.
memory.numa_stat
A read-only nested-keyed file which exists on non-root cgroups.

24
Documentation/admin-guide/kernel-parameters.txt
View File

@ -1335,6 +1335,7 @@
earlyprintk=dbgp[debugController#]
earlyprintk=pciserial[,force],bus:device.function[,baudrate]
earlyprintk=xdbc[xhciController#]
earlyprintk=bios
earlyprintk is useful when the kernel crashes before
the normal console is initialized. It is not enabled by
@ -1365,6 +1366,8 @@
The sclp output can only be used on s390.
The bios output can only be used on SuperH.
The optional "force" to "pciserial" enables use of a
PCI device even when its classcode is not of the
UART class.
@ -2224,7 +2227,7 @@
forcing Dual Address Cycle for PCI cards supporting
greater than 32-bit addressing.
iommu.strict= [ARM64, X86] Configure TLB invalidation behaviour
iommu.strict= [ARM64, X86, S390] Configure TLB invalidation behaviour
Format: { "0" | "1" }
0 - Lazy mode.
Request that DMA unmap operations use deferred
@ -3330,6 +3333,11 @@
mga= [HW,DRM]
microcode.force_minrev= [X86]
Format: <bool>
Enable or disable the microcode minimal revision
enforcement for the runtime microcode loader.
min_addr=nn[KMG] [KNL,BOOT,IA-64] All physical memory below this
physical address is ignored.
@ -3588,6 +3596,13 @@
[NFS] set the TCP port on which the NFSv4 callback
channel should listen.
nfs.delay_retrans=
[NFS] specifies the number of times the NFSv4 client
retries the request before returning an EAGAIN error,
after a reply of NFS4ERR_DELAY from the server.
Only applies if the softerr mount option is enabled,
and the specified value is >= 0.
nfs.enable_ino64=
[NFS] enable 64-bit inode numbers.
If zero, the NFS client will fake up a 32-bit inode
@ -5679,9 +5694,10 @@
s390_iommu= [HW,S390]
Set s390 IOTLB flushing mode
strict
With strict flushing every unmap operation will result in
an IOTLB flush. Default is lazy flushing before reuse,
which is faster.
With strict flushing every unmap operation will result
in an IOTLB flush. Default is lazy flushing before
reuse, which is faster. Deprecated, equivalent to
iommu.strict=1.
s390_iommu_aperture= [KNL,S390]
Specifies the size of the per device DMA address space

374
Documentation/admin-guide/media/mgb4.rst Normal file
View File

@ -0,0 +1,374 @@
.. SPDX-License-Identifier: GPL-2.0
====================
mgb4 sysfs interface
====================
The mgb4 driver provides a sysfs interface, that is used to configure video
stream related parameters (some of them must be set properly before the v4l2
device can be opened) and obtain the video device/stream status.
There are two types of parameters - global / PCI card related, found under
``/sys/class/video4linux/videoX/device`` and module specific found under
``/sys/class/video4linux/videoX``.
Global (PCI card) parameters
============================
**module_type** (R):
Module type.
| 0 - No module present
| 1 - FPDL3
| 2 - GMSL
**module_version** (R):
Module version number. Zero in case of a missing module.
**fw_type** (R):
Firmware type.
| 1 - FPDL3
| 2 - GMSL
**fw_version** (R):
Firmware version number.
**serial_number** (R):
Card serial number. The format is::
PRODUCT-REVISION-SERIES-SERIAL
where each component is a 8b number.
Common FPDL3/GMSL input parameters
==================================
**input_id** (R):
Input number ID, zero based.
**oldi_lane_width** (RW):
Number of deserializer output lanes.
| 0 - single
| 1 - dual (default)
**color_mapping** (RW):
Mapping of the incoming bits in the signal to the colour bits of the pixels.
| 0 - OLDI/JEIDA
| 1 - SPWG/VESA (default)
**link_status** (R):
Video link status. If the link is locked, chips are properly connected and
communicating at the same speed and protocol. The link can be locked without
an active video stream.
A value of 0 is equivalent to the V4L2_IN_ST_NO_SYNC flag of the V4L2
VIDIOC_ENUMINPUT status bits.
| 0 - unlocked
| 1 - locked
**stream_status** (R):
Video stream status. A stream is detected if the link is locked, the input
pixel clock is running and the DE signal is moving.
A value of 0 is equivalent to the V4L2_IN_ST_NO_SIGNAL flag of the V4L2
VIDIOC_ENUMINPUT status bits.
| 0 - not detected
| 1 - detected
**video_width** (R):
Video stream width. This is the actual width as detected by the HW.
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in the width
field of the v4l2_bt_timings struct.
**video_height** (R):
Video stream height. This is the actual height as detected by the HW.
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in the height
field of the v4l2_bt_timings struct.
**vsync_status** (R):
The type of VSYNC pulses as detected by the video format detector.
The value is equivalent to the flags returned by VIDIOC_QUERY_DV_TIMINGS in
the polarities field of the v4l2_bt_timings struct.
| 0 - active low
| 1 - active high
| 2 - not available
**hsync_status** (R):
The type of HSYNC pulses as detected by the video format detector.
The value is equivalent to the flags returned by VIDIOC_QUERY_DV_TIMINGS in
the polarities field of the v4l2_bt_timings struct.
| 0 - active low
| 1 - active high
| 2 - not available
**vsync_gap_length** (RW):
If the incoming video signal does not contain synchronization VSYNC and
HSYNC pulses, these must be generated internally in the FPGA to achieve
the correct frame ordering. This value indicates, how many "empty" pixels
(pixels with deasserted Data Enable signal) are necessary to generate the
internal VSYNC pulse.
**hsync_gap_length** (RW):
If the incoming video signal does not contain synchronization VSYNC and
HSYNC pulses, these must be generated internally in the FPGA to achieve
the correct frame ordering. This value indicates, how many "empty" pixels
(pixels with deasserted Data Enable signal) are necessary to generate the
internal HSYNC pulse. The value must be greater than 1 and smaller than
vsync_gap_length.
**pclk_frequency** (R):
Input pixel clock frequency in kHz.
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
the pixelclock field of the v4l2_bt_timings struct.
*Note: The frequency_range parameter must be set properly first to get
a valid frequency here.*
**hsync_width** (R):
Width of the HSYNC signal in PCLK clock ticks.
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
the hsync field of the v4l2_bt_timings struct.
**vsync_width** (R):
Width of the VSYNC signal in PCLK clock ticks.
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
the vsync field of the v4l2_bt_timings struct.
**hback_porch** (R):
Number of PCLK pulses between deassertion of the HSYNC signal and the first
valid pixel in the video line (marked by DE=1).
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
the hbackporch field of the v4l2_bt_timings struct.
**hfront_porch** (R):
Number of PCLK pulses between the end of the last valid pixel in the video
line (marked by DE=1) and assertion of the HSYNC signal.
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
the hfrontporch field of the v4l2_bt_timings struct.
**vback_porch** (R):
Number of video lines between deassertion of the VSYNC signal and the video
line with the first valid pixel (marked by DE=1).
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
the vbackporch field of the v4l2_bt_timings struct.
**vfront_porch** (R):
Number of video lines between the end of the last valid pixel line (marked
by DE=1) and assertion of the VSYNC signal.
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
the vfrontporch field of the v4l2_bt_timings struct.
**frequency_range** (RW)
PLL frequency range of the OLDI input clock generator. The PLL frequency is
derived from the Pixel Clock Frequency (PCLK) and is equal to PCLK if
oldi_lane_width is set to "single" and PCLK/2 if oldi_lane_width is set to
"dual".
| 0 - PLL < 50MHz (default)
| 1 - PLL >= 50MHz
*Note: This parameter can not be changed while the input v4l2 device is
open.*
Common FPDL3/GMSL output parameters
===================================
**output_id** (R):
Output number ID, zero based.
**video_source** (RW):
Output video source. If set to 0 or 1, the source is the corresponding card
input and the v4l2 output devices are disabled. If set to 2 or 3, the source
is the corresponding v4l2 video output device. The default is
the corresponding v4l2 output, i.e. 2 for OUT1 and 3 for OUT2.
| 0 - input 0
| 1 - input 1
| 2 - v4l2 output 0
| 3 - v4l2 output 1
*Note: This parameter can not be changed while ANY of the input/output v4l2
devices is open.*
**display_width** (RW):
Display width. There is no autodetection of the connected display, so the
proper value must be set before the start of streaming. The default width
is 1280.
*Note: This parameter can not be changed while the output v4l2 device is
open.*
**display_height** (RW):
Display height. There is no autodetection of the connected display, so the
proper value must be set before the start of streaming. The default height
is 640.
*Note: This parameter can not be changed while the output v4l2 device is
open.*
**frame_rate** (RW):
Output video frame rate in frames per second. The default frame rate is
60Hz.
**hsync_polarity** (RW):
HSYNC signal polarity.
| 0 - active low (default)
| 1 - active high
**vsync_polarity** (RW):
VSYNC signal polarity.
| 0 - active low (default)
| 1 - active high
**de_polarity** (RW):
DE signal polarity.
| 0 - active low
| 1 - active high (default)
**pclk_frequency** (RW):
Output pixel clock frequency. Allowed values are between 25000-190000(kHz)
and there is a non-linear stepping between two consecutive allowed
frequencies. The driver finds the nearest allowed frequency to the given
value and sets it. When reading this property, you get the exact
frequency set by the driver. The default frequency is 70000kHz.
*Note: This parameter can not be changed while the output v4l2 device is
open.*
**hsync_width** (RW):
Width of the HSYNC signal in pixels. The default value is 16.
**vsync_width** (RW):
Width of the VSYNC signal in video lines. The default value is 2.
**hback_porch** (RW):
Number of PCLK pulses between deassertion of the HSYNC signal and the first
valid pixel in the video line (marked by DE=1). The default value is 32.
**hfront_porch** (RW):
Number of PCLK pulses between the end of the last valid pixel in the video
line (marked by DE=1) and assertion of the HSYNC signal. The default value
is 32.
**vback_porch** (RW):
Number of video lines between deassertion of the VSYNC signal and the video
line with the first valid pixel (marked by DE=1). The default value is 2.
**vfront_porch** (RW):
Number of video lines between the end of the last valid pixel line (marked
by DE=1) and assertion of the VSYNC signal. The default value is 2.
FPDL3 specific input parameters
===============================
**fpdl3_input_width** (RW):
Number of deserializer input lines.
| 0 - auto (default)
| 1 - single
| 2 - dual
FPDL3 specific output parameters
================================
**fpdl3_output_width** (RW):
Number of serializer output lines.
| 0 - auto (default)
| 1 - single
| 2 - dual
GMSL specific input parameters
==============================
**gmsl_mode** (RW):
GMSL speed mode.
| 0 - 12Gb/s (default)
| 1 - 6Gb/s
| 2 - 3Gb/s
| 3 - 1.5Gb/s
**gmsl_stream_id** (RW):
The GMSL multi-stream contains up to four video streams. This parameter
selects which stream is captured by the video input. The value is the
zero-based index of the stream. The default stream id is 0.
*Note: This parameter can not be changed while the input v4l2 device is
open.*
**gmsl_fec** (RW):
GMSL Forward Error Correction (FEC).
| 0 - disabled
| 1 - enabled (default)
====================
mgb4 mtd partitions
====================
The mgb4 driver creates a MTD device with two partitions:
- mgb4-fw.X - FPGA firmware.
- mgb4-data.X - Factory settings, e.g. card serial number.
The *mgb4-fw* partition is writable and is used for FW updates, *mgb4-data* is
read-only. The *X* attached to the partition name represents the card number.
Depending on the CONFIG_MTD_PARTITIONED_MASTER kernel configuration, you may
also have a third partition named *mgb4-flash* available in the system. This
partition represents the whole, unpartitioned, card's FLASH memory and one should
not fiddle with it...
====================
mgb4 iio (triggers)
====================
The mgb4 driver creates an Industrial I/O (IIO) device that provides trigger and
signal level status capability. The following scan elements are available:
**activity**:
The trigger levels and pending status.
| bit 1 - trigger 1 pending
| bit 2 - trigger 2 pending
| bit 5 - trigger 1 level
| bit 6 - trigger 2 level
**timestamp**:
The trigger event timestamp.
The iio device can operate either in "raw" mode where you can fetch the signal
levels (activity bits 5 and 6) using sysfs access or in triggered buffer mode.
In the triggered buffer mode you can follow the signal level changes (activity
bits 1 and 2) using the iio device in /dev. If you enable the timestamps, you
will also get the exact trigger event time that can be matched to a video frame
(every mgb4 video frame has a timestamp with the same clock source).
*Note: although the activity sample always contains all the status bits, it makes
no sense to get the pending bits in raw mode or the level bits in the triggered
buffer mode - the values do not represent valid data in such case.*

1
Documentation/admin-guide/media/pci-cardlist.rst
View File

@ -77,6 +77,7 @@ ipu3-cio2 Intel ipu3-cio2 driver
ivtv Conexant cx23416/cx23415 MPEG encoder/decoder
ivtvfb Conexant cx23415 framebuffer
mantis MANTIS based cards
mgb4 Digiteq Automotive MGB4 frame grabber
mxb Siemens-Nixdorf 'Multimedia eXtension Board'
netup-unidvb NetUP Universal DVB card
ngene Micronas nGene

1
Documentation/admin-guide/media/v4l-drivers.rst
View File

@ -17,6 +17,7 @@ Video4Linux (V4L) driver-specific documentation
imx7
ipu3
ivtv
mgb4
omap3isp
omap4_camera
philips

6
Documentation/admin-guide/media/visl.rst
View File

@ -78,7 +78,7 @@ The trace events are defined on a per-codec basis, e.g.:
.. code-block:: bash
$ ls /sys/kernel/debug/tracing/events/ | grep visl
$ ls /sys/kernel/tracing/events/ | grep visl
visl_fwht_controls
visl_h264_controls
visl_hevc_controls
@ -90,13 +90,13 @@ For example, in order to dump HEVC SPS data:
.. code-block:: bash
$ echo 1 > /sys/kernel/debug/tracing/events/visl_hevc_controls/v4l2_ctrl_hevc_sps/enable
$ echo 1 > /sys/kernel/tracing/events/visl_hevc_controls/v4l2_ctrl_hevc_sps/enable
The SPS data will be dumped to the trace buffer, i.e.:
.. code-block:: bash
$ cat /sys/kernel/debug/tracing/trace
$ cat /sys/kernel/tracing/trace
video_parameter_set_id 0
seq_parameter_set_id 0
pic_width_in_luma_samples 1920

124
Documentation/admin-guide/mm/damon/usage.rst
View File

@ -20,18 +20,18 @@ DAMON provides below interfaces for different users.
you can write and use your personalized DAMON sysfs wrapper programs that
reads/writes the sysfs files instead of you. The `DAMON user space tool
<https://github.com/awslabs/damo>`_ is one example of such programs.
- *debugfs interface. (DEPRECATED!)*
:ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
<sysfs_interface>`. This is deprecated, so users should move to the
:ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
move, please report your usecase to damon@lists.linux.dev and
linux-mm@kvack.org.
- *Kernel Space Programming Interface.*
:doc:`This </mm/damon/api>` is for kernel space programmers. Using this,
users can utilize every feature of DAMON most flexibly and efficiently by
writing kernel space DAMON application programs for you. You can even extend
DAMON for various address spaces. For detail, please refer to the interface
:doc:`document </mm/damon/api>`.
- *debugfs interface. (DEPRECATED!)*
:ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
<sysfs_interface>`. This is deprecated, so users should move to the
:ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
move, please report your usecase to damon@lists.linux.dev and
linux-mm@kvack.org.
.. _sysfs_interface:
@ -76,7 +76,7 @@ comma (","). ::
│ │ │ │ │ │ │ │ ...
│ │ │ │ │ │ ...
│ │ │ │ │ schemes/nr_schemes
│ │ │ │ │ │ 0/action
│ │ │ │ │ │ 0/action,apply_interval_us
│ │ │ │ │ │ │ access_pattern/
│ │ │ │ │ │ │ │ sz/min,max
│ │ │ │ │ │ │ │ nr_accesses/min,max
@ -105,14 +105,12 @@ having the root permission could use this directory.
kdamonds/
---------
The monitoring-related information including request specifications and results
are called DAMON context. DAMON executes each context with a kernel thread
called kdamond, and multiple kdamonds could run in parallel.
Under the ``admin`` directory, one directory, ``kdamonds``, which has files for
controlling the kdamonds exist. In the beginning, this directory has only one
file, ``nr_kdamonds``. Writing a number (``N``) to the file creates the number
of child directories named ``0`` to ``N-1``. Each directory represents each
controlling the kdamonds (refer to
:ref:`design <damon_design_execution_model_and_data_structures>` for more
details) exists. In the beginning, this directory has only one file,
``nr_kdamonds``. Writing a number (``N``) to the file creates the number of
child directories named ``0`` to ``N-1``. Each directory represents each
kdamond.
kdamonds/<N>/
@ -150,9 +148,10 @@ kdamonds/<N>/contexts/
In the beginning, this directory has only one file, ``nr_contexts``. Writing a
number (``N``) to the file creates the number of child directories named as
``0`` to ``N-1``. Each directory represents each monitoring context. At the
moment, only one context per kdamond is supported, so only ``0`` or ``1`` can
be written to the file.
``0`` to ``N-1``. Each directory represents each monitoring context (refer to
:ref:`design <damon_design_execution_model_and_data_structures>` for more
details). At the moment, only one context per kdamond is supported, so only
``0`` or ``1`` can be written to the file.
.. _sysfs_contexts:
@ -270,8 +269,8 @@ schemes/<N>/
------------
In each scheme directory, five directories (``access_pattern``, ``quotas``,
``watermarks``, ``filters``, ``stats``, and ``tried_regions``) and one file
(``action``) exist.
``watermarks``, ``filters``, ``stats``, and ``tried_regions``) and two files
(``action`` and ``apply_interval``) exist.
The ``action`` file is for setting and getting the scheme's :ref:`action
<damon_design_damos_action>`. The keywords that can be written to and read
@ -297,6 +296,9 @@ Note that support of each action depends on the running DAMON operations set
- ``stat``: Do nothing but count the statistics.
Supported by all operations sets.
The ``apply_interval_us`` file is for setting and getting the scheme's
:ref:`apply_interval <damon_design_damos>` in microseconds.
schemes/<N>/access_pattern/
---------------------------
@ -392,7 +394,7 @@ pages of all memory cgroups except ``/having_care_already``.::
echo N > 1/matching
Note that ``anon`` and ``memcg`` filters are currently supported only when
``paddr`` `implementation <sysfs_contexts>` is being used.
``paddr`` :ref:`implementation <sysfs_contexts>` is being used.
Also, memory regions that are filtered out by ``addr`` or ``target`` filters
are not counted as the scheme has tried to those, while regions that filtered
@ -430,9 +432,9 @@ that reading it returns the total size of the scheme tried regions, and creates
directories named integer starting from ``0`` under this directory. Each
directory contains files exposing detailed information about each of the memory
region that the corresponding scheme's ``action`` has tried to be applied under
this directory, during next :ref:`aggregation interval
<sysfs_monitoring_attrs>`. The information includes address range,
``nr_accesses``, and ``age`` of the region.
this directory, during next :ref:`apply interval <damon_design_damos>` of the
corresponding scheme. The information includes address range, ``nr_accesses``,
and ``age`` of the region.
Writing ``update_schemes_tried_bytes`` to the relevant ``kdamonds/<N>/state``
file will only update the ``total_bytes`` file, and will not create the
@ -495,6 +497,62 @@ Please note that it's highly recommended to use user space tools like `damo
<https://github.com/awslabs/damo>`_ rather than manually reading and writing
the files as above. Above is only for an example.
.. _tracepoint:
Tracepoints for Monitoring Results
==================================
Users can get the monitoring results via the :ref:`tried_regions
<sysfs_schemes_tried_regions>`. The interface is useful for getting a
snapshot, but it could be inefficient for fully recording all the monitoring
results. For the purpose, two trace points, namely ``damon:damon_aggregated``
and ``damon:damos_before_apply``, are provided. ``damon:damon_aggregated``
provides the whole monitoring results, while ``damon:damos_before_apply``
provides the monitoring results for regions that each DAMON-based Operation
Scheme (:ref:`DAMOS <damon_design_damos>`) is gonna be applied. Hence,
``damon:damos_before_apply`` is more useful for recording internal behavior of
DAMOS, or DAMOS target access
:ref:`pattern <damon_design_damos_access_pattern>` based query-like efficient
monitoring results recording.
While the monitoring is turned on, you could record the tracepoint events and
show results using tracepoint supporting tools like ``perf``. For example::
# echo on > monitor_on
# perf record -e damon:damon_aggregated &
# sleep 5
# kill 9 $(pidof perf)
# echo off > monitor_on
# perf script
kdamond.0 46568 [027] 79357.842179: damon:damon_aggregated: target_id=0 nr_regions=11 122509119488-135708762112: 0 864
[...]
Each line of the perf script output represents each monitoring region. The
first five fields are as usual other tracepoint outputs. The sixth field
(``target_id=X``) shows the ide of the monitoring target of the region. The
seventh field (``nr_regions=X``) shows the total number of monitoring regions
for the target. The eighth field (``X-Y:``) shows the start (``X``) and end
(``Y``) addresses of the region in bytes. The ninth field (``X``) shows the
``nr_accesses`` of the region (refer to
:ref:`design <damon_design_region_based_sampling>` for more details of the
counter). Finally the tenth field (``X``) shows the ``age`` of the region
(refer to :ref:`design <damon_design_age_tracking>` for more details of the
counter).
If the event was ``damon:damos_beofre_apply``, the ``perf script`` output would
be somewhat like below::
kdamond.0 47293 [000] 80801.060214: damon:damos_before_apply: ctx_idx=0 scheme_idx=0 target_idx=0 nr_regions=11 121932607488-135128711168: 0 136
[...]
Each line of the output represents each monitoring region that each DAMON-based
Operation Scheme was about to be applied at the traced time. The first five
fields are as usual. It shows the index of the DAMON context (``ctx_idx=X``)
of the scheme in the list of the contexts of the context's kdamond, the index
of the scheme (``scheme_idx=X``) in the list of the schemes of the context, in
addition to the output of ``damon_aggregated`` tracepoint.
.. _debugfs_interface:
debugfs Interface (DEPRECATED!)
@ -790,23 +848,3 @@ directory by putting the name of the context to the ``rm_contexts`` file. ::
Note that ``mk_contexts``, ``rm_contexts``, and ``monitor_on`` files are in the
root directory only.
.. _tracepoint:
Tracepoint for Monitoring Results
=================================
Users can get the monitoring results via the :ref:`tried_regions
<sysfs_schemes_tried_regions>` or a tracepoint, ``damon:damon_aggregated``.
While the tried regions directory is useful for getting a snapshot, the
tracepoint is useful for getting a full record of the results. While the
monitoring is turned on, you could record the tracepoint events and show
results using tracepoint supporting tools like ``perf``. For example::
# echo on > monitor_on
# perf record -e damon:damon_aggregated &
# sleep 5
# kill 9 $(pidof perf)
# echo off > monitor_on
# perf script

11
Documentation/admin-guide/mm/ksm.rst
View File

@ -155,6 +155,15 @@ stable_node_chains_prune_millisecs
scan. It's a noop if not a single KSM page hit the
``max_page_sharing`` yet.
smart_scan
Historically KSM checked every candidate page for each scan. It did
not take into account historic information. When smart scan is
enabled, pages that have previously not been de-duplicated get
skipped. How often these pages are skipped depends on how often
de-duplication has already been tried and failed. By default this
optimization is enabled. The ``pages_skipped`` metric shows how
effective the setting is.
The effectiveness of KSM and MADV_MERGEABLE is shown in ``/sys/kernel/mm/ksm/``:
general_profit
@ -169,6 +178,8 @@ pages_unshared
how many pages unique but repeatedly checked for merging
pages_volatile
how many pages changing too fast to be placed in a tree
pages_skipped
how many pages did the "smart" page scanning algorithm skip
full_scans
how many times all mergeable areas have been scanned
stable_node_chains

89
Documentation/admin-guide/mm/pagemap.rst
View File

@ -227,3 +227,92 @@ Before Linux 3.11 pagemap bits 55-60 were used for "page-shift" (which is
always 12 at most architectures). Since Linux 3.11 their meaning changes
after first clear of soft-dirty bits. Since Linux 4.2 they are used for
flags unconditionally.
Pagemap Scan IOCTL
==================
The ``PAGEMAP_SCAN`` IOCTL on the pagemap file can be used to get or optionally
clear the info about page table entries. The following operations are supported
in this IOCTL:
- Scan the address range and get the memory ranges matching the provided criteria.
This is performed when the output buffer is specified.
- Write-protect the pages. The ``PM_SCAN_WP_MATCHING`` is used to write-protect
the pages of interest. The ``PM_SCAN_CHECK_WPASYNC`` aborts the operation if
non-Async Write Protected pages are found. The ``PM_SCAN_WP_MATCHING`` can be
used with or without ``PM_SCAN_CHECK_WPASYNC``.
- Both of those operations can be combined into one atomic operation where we can
get and write protect the pages as well.
Following flags about pages are currently supported:
- ``PAGE_IS_WPALLOWED`` - Page has async-write-protection enabled
- ``PAGE_IS_WRITTEN`` - Page has been written to from the time it was write protected
- ``PAGE_IS_FILE`` - Page is file backed
- ``PAGE_IS_PRESENT`` - Page is present in the memory
- ``PAGE_IS_SWAPPED`` - Page is in swapped
- ``PAGE_IS_PFNZERO`` - Page has zero PFN
- ``PAGE_IS_HUGE`` - Page is THP or Hugetlb backed
The ``struct pm_scan_arg`` is used as the argument of the IOCTL.
1. The size of the ``struct pm_scan_arg`` must be specified in the ``size``
field. This field will be helpful in recognizing the structure if extensions
are done later.
2. The flags can be specified in the ``flags`` field. The ``PM_SCAN_WP_MATCHING``
and ``PM_SCAN_CHECK_WPASYNC`` are the only added flags at this time. The get
operation is optionally performed depending upon if the output buffer is
provided or not.
3. The range is specified through ``start`` and ``end``.
4. The walk can abort before visiting the complete range such as the user buffer
can get full etc. The walk ending address is specified in``end_walk``.
5. The output buffer of ``struct page_region`` array and size is specified in
``vec`` and ``vec_len``.
6. The optional maximum requested pages are specified in the ``max_pages``.
7. The masks are specified in ``category_mask``, ``category_anyof_mask``,
``category_inverted`` and ``return_mask``.
Find pages which have been written and WP them as well::
struct pm_scan_arg arg = {
.size = sizeof(arg),
.flags = PM_SCAN_CHECK_WPASYNC | PM_SCAN_CHECK_WPASYNC,
..
.category_mask = PAGE_IS_WRITTEN,
.return_mask = PAGE_IS_WRITTEN,
};
Find pages which have been written, are file backed, not swapped and either
present or huge::
struct pm_scan_arg arg = {
.size = sizeof(arg),
.flags = 0,
..
.category_mask = PAGE_IS_WRITTEN | PAGE_IS_SWAPPED,
.category_inverted = PAGE_IS_SWAPPED,
.category_anyof_mask = PAGE_IS_PRESENT | PAGE_IS_HUGE,
.return_mask = PAGE_IS_WRITTEN | PAGE_IS_SWAPPED |
PAGE_IS_PRESENT | PAGE_IS_HUGE,
};
The ``PAGE_IS_WRITTEN`` flag can be considered as a better-performing alternative
of soft-dirty flag. It doesn't get affected by VMA merging of the kernel and hence
the user can find the true soft-dirty pages in case of normal pages. (There may
still be extra dirty pages reported for THP or Hugetlb pages.)
"PAGE_IS_WRITTEN" category is used with uffd write protect-enabled ranges to
implement memory dirty tracking in userspace:
1. The userfaultfd file descriptor is created with ``userfaultfd`` syscall.
2. The ``UFFD_FEATURE_WP_UNPOPULATED`` and ``UFFD_FEATURE_WP_ASYNC`` features
are set by ``UFFDIO_API`` IOCTL.
3. The memory range is registered with ``UFFDIO_REGISTER_MODE_WP`` mode
through ``UFFDIO_REGISTER`` IOCTL.
4. Then any part of the registered memory or the whole memory region must
be write protected using ``PAGEMAP_SCAN`` IOCTL with flag ``PM_SCAN_WP_MATCHING``
or the ``UFFDIO_WRITEPROTECT`` IOCTL can be used. Both of these perform the
same operation. The former is better in terms of performance.
5. Now the ``PAGEMAP_SCAN`` IOCTL can be used to either just find pages which
have been written to since they were last marked and/or optionally write protect
the pages as well.

35
Documentation/admin-guide/mm/userfaultfd.rst
View File

@ -244,6 +244,41 @@ write-protected (so future writes will also result in a WP fault). These ioctls
support a mode flag (``UFFDIO_COPY_MODE_WP`` or ``UFFDIO_CONTINUE_MODE_WP``
respectively) to configure the mapping this way.
If the userfaultfd context has ``UFFD_FEATURE_WP_ASYNC`` feature bit set,
any vma registered with write-protection will work in async mode rather
than the default sync mode.
In async mode, there will be no message generated when a write operation
happens, meanwhile the write-protection will be resolved automatically by
the kernel. It can be seen as a more accurate version of soft-dirty
tracking and it can be different in a few ways:
- The dirty result will not be affected by vma changes (e.g. vma
merging) because the dirty is only tracked by the pte.
- It supports range operations by default, so one can enable tracking on
any range of memory as long as page aligned.
- Dirty information will not get lost if the pte was zapped due to
various reasons (e.g. during split of a shmem transparent huge page).
- Due to a reverted meaning of soft-dirty (page clean when uffd-wp bit
set; dirty when uffd-wp bit cleared), it has different semantics on
some of the memory operations. For example: ``MADV_DONTNEED`` on
anonymous (or ``MADV_REMOVE`` on a file mapping) will be treated as
dirtying of memory by dropping uffd-wp bit during the procedure.
The user app can collect the "written/dirty" status by looking up the
uffd-wp bit for the pages being interested in /proc/pagemap.
The page will not be under track of uffd-wp async mode until the page is
explicitly write-protected by ``ioctl(UFFDIO_WRITEPROTECT)`` with the mode
flag ``UFFDIO_WRITEPROTECT_MODE_WP`` set. Trying to resolve a page fault
that was tracked by async mode userfaultfd-wp is invalid.
When userfaultfd-wp async mode is used alone, it can be applied to all
kinds of memory.
Memory Poisioning Emulation
---------------------------

17
Documentation/admin-guide/module-signing.rst
View File

@ -28,10 +28,10 @@ trusted userspace bits.
This facility uses X.509 ITU-T standard certificates to encode the public keys
involved. The signatures are not themselves encoded in any industrial standard
type. The facility currently only supports the RSA public key encryption
standard (though it is pluggable and permits others to be used). The possible
hash algorithms that can be used are SHA-1, SHA-224, SHA-256, SHA-384, and
SHA-512 (the algorithm is selected by data in the signature).
type. The built-in facility currently only supports the RSA & NIST P-384 ECDSA
public key signing standard (though it is pluggable and permits others to be
used). The possible hash algorithms that can be used are SHA-2 and SHA-3 of
sizes 256, 384, and 512 (the algorithm is selected by data in the signature).
==========================
@ -81,11 +81,12 @@ This has a number of options available:
sign the modules with:
=============================== ==========================================
``CONFIG_MODULE_SIG_SHA1`` :menuselection:`Sign modules with SHA-1`
``CONFIG_MODULE_SIG_SHA224`` :menuselection:`Sign modules with SHA-224`
``CONFIG_MODULE_SIG_SHA256`` :menuselection:`Sign modules with SHA-256`
``CONFIG_MODULE_SIG_SHA384`` :menuselection:`Sign modules with SHA-384`
``CONFIG_MODULE_SIG_SHA512`` :menuselection:`Sign modules with SHA-512`
``CONFIG_MODULE_SIG_SHA3_256`` :menuselection:`Sign modules with SHA3-256`
``CONFIG_MODULE_SIG_SHA3_384`` :menuselection:`Sign modules with SHA3-384`
``CONFIG_MODULE_SIG_SHA3_512`` :menuselection:`Sign modules with SHA3-512`
=============================== ==========================================
The algorithm selected here will also be built into the kernel (rather
@ -145,6 +146,10 @@ into vmlinux) using parameters in the::
file (which is also generated if it does not already exist).
One can select between RSA (``MODULE_SIG_KEY_TYPE_RSA``) and ECDSA
(``MODULE_SIG_KEY_TYPE_ECDSA``) to generate either RSA 4k or NIST
P-384 keypair.
It is strongly recommended that you provide your own x509.genkey file.
Most notably, in the x509.genkey file, the req_distinguished_name section

6
Documentation/arch/arm64/elf_hwcaps.rst
View File

@ -174,7 +174,7 @@ HWCAP2_DCPODP
Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010.
HWCAP2_SVE2
Functionality implied by ID_AA64ZFR0_EL1.SVEVer == 0b0001.
Functionality implied by ID_AA64ZFR0_EL1.SVEver == 0b0001.
HWCAP2_SVEAES
Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0001.
@ -222,7 +222,7 @@ HWCAP2_RNG
Functionality implied by ID_AA64ISAR0_EL1.RNDR == 0b0001.
HWCAP2_BTI
Functionality implied by ID_AA64PFR0_EL1.BT == 0b0001.
Functionality implied by ID_AA64PFR1_EL1.BT == 0b0001.
HWCAP2_MTE
Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0010, as described
@ -232,7 +232,7 @@ HWCAP2_ECV
Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001.
HWCAP2_AFP
Functionality implied by ID_AA64MFR1_EL1.AFP == 0b0001.
Functionality implied by ID_AA64MMFR1_EL1.AFP == 0b0001.
HWCAP2_RPRES
Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001.

4
Documentation/arch/loongarch/introduction.rst
View File

@ -375,9 +375,9 @@ Developer web site of Loongson and LoongArch (Software and Documentation):
Documentation of LoongArch ISA:
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.02-CN.pdf (in Chinese)
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.10-CN.pdf (in Chinese)
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.02-EN.pdf (in English)
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.10-EN.pdf (in English)
Documentation of LoongArch ELF psABI:

1
Documentation/arch/powerpc/index.rst
View File

@ -26,6 +26,7 @@ powerpc
isa-versions
kaslr-booke32
mpc52xx
kvm-nested
papr_hcalls
pci_iov_resource_on_powernv
pmu-ebb

634
Documentation/arch/powerpc/kvm-nested.rst Normal file
View File

@ -0,0 +1,634 @@
.. SPDX-License-Identifier: GPL-2.0
====================================
Nested KVM on POWER
====================================
Introduction
============
This document explains how a guest operating system can act as a
hypervisor and run nested guests through the use of hypercalls, if the
hypervisor has implemented them. The terms L0, L1, and L2 are used to
refer to different software entities. L0 is the hypervisor mode entity
that would normally be called the "host" or "hypervisor". L1 is a
guest virtual machine that is directly run under L0 and is initiated
and controlled by L0. L2 is a guest virtual machine that is initiated
and controlled by L1 acting as a hypervisor.
Existing API
============
Linux/KVM has had support for Nesting as an L0 or L1 since 2018
The L0 code was added::
commit 8e3f5fc1045dc49fd175b978c5457f5f51e7a2ce
Author: Paul Mackerras <paulus@ozlabs.org>
Date: Mon Oct 8 16:31:03 2018 +1100
KVM: PPC: Book3S HV: Framework and hcall stubs for nested virtualization
The L1 code was added::
commit 360cae313702cdd0b90f82c261a8302fecef030a
Author: Paul Mackerras <paulus@ozlabs.org>
Date: Mon Oct 8 16:31:04 2018 +1100
KVM: PPC: Book3S HV: Nested guest entry via hypercall
This API works primarily using a single hcall h_enter_nested(). This
call made by the L1 to tell the L0 to start an L2 vCPU with the given
state. The L0 then starts this L2 and runs until an L2 exit condition
is reached. Once the L2 exits, the state of the L2 is given back to
the L1 by the L0. The full L2 vCPU state is always transferred from
and to L1 when the L2 is run. The L0 doesn't keep any state on the L2
vCPU (except in the short sequence in the L0 on L1 -> L2 entry and L2
-> L1 exit).
The only state kept by the L0 is the partition table. The L1 registers
it's partition table using the h_set_partition_table() hcall. All
other state held by the L0 about the L2s is cached state (such as
shadow page tables).
The L1 may run any L2 or vCPU without first informing the L0. It
simply starts the vCPU using h_enter_nested(). The creation of L2s and
vCPUs is done implicitly whenever h_enter_nested() is called.
In this document, we call this existing API the v1 API.
New PAPR API
===============
The new PAPR API changes from the v1 API such that the creating L2 and
associated vCPUs is explicit. In this document, we call this the v2
API.
h_enter_nested() is replaced with H_GUEST_VCPU_RUN(). Before this can
be called the L1 must explicitly create the L2 using h_guest_create()
and any associated vCPUs() created with h_guest_create_vCPU(). Getting
and setting vCPU state can also be performed using h_guest_{g|s}et
hcall.
The basic execution flow is for an L1 to create an L2, run it, and
delete it is:
- L1 and L0 negotiate capabilities with H_GUEST_{G,S}ET_CAPABILITIES()
(normally at L1 boot time).
- L1 requests the L0 create an L2 with H_GUEST_CREATE() and receives a token
- L1 requests the L0 create an L2 vCPU with H_GUEST_CREATE_VCPU()
- L1 and L0 communicate the vCPU state using the H_GUEST_{G,S}ET() hcall
- L1 requests the L0 runs the vCPU running H_GUEST_VCPU_RUN() hcall
- L1 deletes L2 with H_GUEST_DELETE()
More details of the individual hcalls follows:
HCALL Details
=============
This documentation is provided to give an overall understating of the
API. It doesn't aim to provide all the details required to implement
an L1 or L0. Latest version of PAPR can be referred to for more details.
All these HCALLs are made by the L1 to the L0.
H_GUEST_GET_CAPABILITIES()
--------------------------
This is called to get the capabilities of the L0 nested
hypervisor. This includes capabilities such the CPU versions (eg
POWER9, POWER10) that are supported as L2s::
H_GUEST_GET_CAPABILITIES(uint64 flags)
Parameters:
Input:
flags: Reserved
Output:
R3: Return code
R4: Hypervisor Supported Capabilities bitmap 1
H_GUEST_SET_CAPABILITIES()
--------------------------
This is called to inform the L0 of the capabilities of the L1
hypervisor. The set of flags passed here are the same as
H_GUEST_GET_CAPABILITIES()
Typically, GET will be called first and then SET will be called with a
subset of the flags returned from GET. This process allows the L0 and
L1 to negotiate an agreed set of capabilities::
H_GUEST_SET_CAPABILITIES(uint64 flags,
uint64 capabilitiesBitmap1)
Parameters:
Input:
flags: Reserved
capabilitiesBitmap1: Only capabilities advertised through
H_GUEST_GET_CAPABILITIES
Output:
R3: Return code
R4: If R3 = H_P2: The number of invalid bitmaps
R5: If R3 = H_P2: The index of first invalid bitmap
H_GUEST_CREATE()
----------------
This is called to create an L2. A unique ID of the L2 created
(similar to an LPID) is returned, which can be used on subsequent HCALLs to
identify the L2::
H_GUEST_CREATE(uint64 flags,
uint64 continueToken);
Parameters:
Input:
flags: Reserved
continueToken: Initial call set to -1. Subsequent calls,
after H_Busy or H_LongBusyOrder has been
returned, value that was returned in R4.
Output:
R3: Return code. Notable:
H_Not_Enough_Resources: Unable to create Guest VCPU due to not
enough Hypervisor memory. See H_GUEST_CREATE_GET_STATE(flags =
takeOwnershipOfVcpuState)
R4: If R3 = H_Busy or_H_LongBusyOrder -> continueToken
H_GUEST_CREATE_VCPU()
---------------------
This is called to create a vCPU associated with an L2. The L2 id
(returned from H_GUEST_CREATE()) should be passed it. Also passed in
is a unique (for this L2) vCPUid. This vCPUid is allocated by the
L1::
H_GUEST_CREATE_VCPU(uint64 flags,
uint64 guestId,
uint64 vcpuId);
Parameters:
Input:
flags: Reserved
guestId: ID obtained from H_GUEST_CREATE
vcpuId: ID of the vCPU to be created. This must be within the
range of 0 to 2047
Output:
R3: Return code. Notable:
H_Not_Enough_Resources: Unable to create Guest VCPU due to not
enough Hypervisor memory. See H_GUEST_CREATE_GET_STATE(flags =
takeOwnershipOfVcpuState)
H_GUEST_GET_STATE()
-------------------
This is called to get state associated with an L2 (Guest-wide or vCPU specific).
This info is passed via the Guest State Buffer (GSB), a standard format as
explained later in this doc, necessary details below:
This can get either L2 wide or vcpu specific information. Examples of
L2 wide is the timebase offset or process scoped page table
info. Examples of vCPU specific are GPRs or VSRs. A bit in the flags
parameter specifies if this call is L2 wide or vCPU specific and the
IDs in the GSB must match this.
The L1 provides a pointer to the GSB as a parameter to this call. Also
provided is the L2 and vCPU IDs associated with the state to set.
The L1 writes only the IDs and sizes in the GSB. L0 writes the
associated values for each ID in the GSB::
H_GUEST_GET_STATE(uint64 flags,
uint64 guestId,
uint64 vcpuId,
uint64 dataBuffer,
uint64 dataBufferSizeInBytes);
Parameters:
Input:
flags:
Bit 0: getGuestWideState: Request state of the Guest instead
of an individual VCPU.
Bit 1: takeOwnershipOfVcpuState Indicate the L1 is taking
over ownership of the VCPU state and that the L0 can free
the storage holding the state. The VCPU state will need to
be returned to the Hypervisor via H_GUEST_SET_STATE prior
to H_GUEST_RUN_VCPU being called for this VCPU. The data
returned in the dataBuffer is in a Hypervisor internal
format.
Bits 2-63: Reserved
guestId: ID obtained from H_GUEST_CREATE
vcpuId: ID of the vCPU pass to H_GUEST_CREATE_VCPU
dataBuffer: A L1 real address of the GSB.
If takeOwnershipOfVcpuState, size must be at least the size
returned by ID=0x0001
dataBufferSizeInBytes: Size of dataBuffer
Output:
R3: Return code
R4: If R3 = H_Invalid_Element_Id: The array index of the bad
element ID.
If R3 = H_Invalid_Element_Size: The array index of the bad
element size.
If R3 = H_Invalid_Element_Value: The array index of the bad
element value.
H_GUEST_SET_STATE()
-------------------
This is called to set L2 wide or vCPU specific L2 state. This info is
passed via the Guest State Buffer (GSB), necessary details below:
This can set either L2 wide or vcpu specific information. Examples of
L2 wide is the timebase offset or process scoped page table
info. Examples of vCPU specific are GPRs or VSRs. A bit in the flags
parameter specifies if this call is L2 wide or vCPU specific and the
IDs in the GSB must match this.
The L1 provides a pointer to the GSB as a parameter to this call. Also
provided is the L2 and vCPU IDs associated with the state to set.
The L1 writes all values in the GSB and the L0 only reads the GSB for
this call::
H_GUEST_SET_STATE(uint64 flags,
uint64 guestId,
uint64 vcpuId,
uint64 dataBuffer,
uint64 dataBufferSizeInBytes);
Parameters:
Input:
flags:
Bit 0: getGuestWideState: Request state of the Guest instead
of an individual VCPU.
Bit 1: returnOwnershipOfVcpuState Return Guest VCPU state. See
GET_STATE takeOwnershipOfVcpuState
Bits 2-63: Reserved
guestId: ID obtained from H_GUEST_CREATE
vcpuId: ID of the vCPU pass to H_GUEST_CREATE_VCPU
dataBuffer: A L1 real address of the GSB.
If takeOwnershipOfVcpuState, size must be at least the size
returned by ID=0x0001
dataBufferSizeInBytes: Size of dataBuffer
Output:
R3: Return code
R4: If R3 = H_Invalid_Element_Id: The array index of the bad
element ID.
If R3 = H_Invalid_Element_Size: The array index of the bad
element size.
If R3 = H_Invalid_Element_Value: The array index of the bad
element value.
H_GUEST_RUN_VCPU()
------------------
This is called to run an L2 vCPU. The L2 and vCPU IDs are passed in as
parameters. The vCPU runs with the state set previously using
H_GUEST_SET_STATE(). When the L2 exits, the L1 will resume from this
hcall.
This hcall also has associated input and output GSBs. Unlike
H_GUEST_{S,G}ET_STATE(), these GSB pointers are not passed in as
parameters to the hcall (This was done in the interest of
performance). The locations of these GSBs must be preregistered using
the H_GUEST_SET_STATE() call with ID 0x0c00 and 0x0c01 (see table
below).
The input GSB may contain only VCPU specific elements to be set. This
GSB may also contain zero elements (ie 0 in the first 4 bytes of the
GSB) if nothing needs to be set.
On exit from the hcall, the output buffer is filled with elements
determined by the L0. The reason for the exit is contained in GPR4 (ie
NIP is put in GPR4). The elements returned depend on the exit
type. For example, if the exit reason is the L2 doing a hcall (GPR4 =
0xc00), then GPR3-12 are provided in the output GSB as this is the
state likely needed to service the hcall. If additional state is
needed, H_GUEST_GET_STATE() may be called by the L1.
To synthesize interrupts in the L2, when calling H_GUEST_RUN_VCPU()
the L1 may set a flag (as a hcall parameter) and the L0 will
synthesize the interrupt in the L2. Alternatively, the L1 may
synthesize the interrupt itself using H_GUEST_SET_STATE() or the
H_GUEST_RUN_VCPU() input GSB to set the state appropriately::
H_GUEST_RUN_VCPU(uint64 flags,
uint64 guestId,
uint64 vcpuId,
uint64 dataBuffer,
uint64 dataBufferSizeInBytes);
Parameters:
Input:
flags:
Bit 0: generateExternalInterrupt: Generate an external interrupt
Bit 1: generatePrivilegedDoorbell: Generate a Privileged Doorbell
Bit 2: sendToSystemReset”: Generate a System Reset Interrupt
Bits 3-63: Reserved
guestId: ID obtained from H_GUEST_CREATE
vcpuId: ID of the vCPU pass to H_GUEST_CREATE_VCPU
Output:
R3: Return code
R4: If R3 = H_Success: The reason L1 VCPU exited (ie. NIA)
0x000: The VCPU stopped running for an unspecified reason. An
example of this is the Hypervisor stopping a VCPU running
due to an outstanding interrupt for the Host Partition.
0x980: HDEC
0xC00: HCALL
0xE00: HDSI
0xE20: HISI
0xE40: HEA
0xF80: HV Fac Unavail
If R3 = H_Invalid_Element_Id, H_Invalid_Element_Size, or
H_Invalid_Element_Value: R4 is offset of the invalid element
in the input buffer.
H_GUEST_DELETE()
----------------
This is called to delete an L2. All associated vCPUs are also
deleted. No specific vCPU delete call is provided.
A flag may be provided to delete all guests. This is used to reset the
L0 in the case of kdump/kexec::
H_GUEST_DELETE(uint64 flags,
uint64 guestId)
Parameters:
Input:
flags:
Bit 0: deleteAllGuests: deletes all guests
Bits 1-63: Reserved
guestId: ID obtained from H_GUEST_CREATE
Output:
R3: Return code
Guest State Buffer
==================
The Guest State Buffer (GSB) is the main method of communicating state
about the L2 between the L1 and L0 via H_GUEST_{G,S}ET() and
H_GUEST_VCPU_RUN() calls.
State may be associated with a whole L2 (eg timebase offset) or a
specific L2 vCPU (eg. GPR state). Only L2 VCPU state maybe be set by
H_GUEST_VCPU_RUN().
All data in the GSB is big endian (as is standard in PAPR)
The Guest state buffer has a header which gives the number of
elements, followed by the GSB elements themselves.
GSB header:
+----------+----------+-------------------------------------------+
| Offset | Size | Purpose |
| Bytes | Bytes | |
+==========+==========+===========================================+
| 0 | 4 | Number of elements |
+----------+----------+-------------------------------------------+
| 4 | | Guest state buffer elements |
+----------+----------+-------------------------------------------+
GSB element:
+----------+----------+-------------------------------------------+
| Offset | Size | Purpose |
| Bytes | Bytes | |
+==========+==========+===========================================+
| 0 | 2 | ID |
+----------+----------+-------------------------------------------+
| 2 | 2 | Size of Value |
+----------+----------+-------------------------------------------+
| 4 | As above | Value |
+----------+----------+-------------------------------------------+
The ID in the GSB element specifies what is to be set. This includes
archtected state like GPRs, VSRs, SPRs, plus also some meta data about
the partition like the timebase offset and partition scoped page
table information.
+--------+-------+----+--------+----------------------------------+
| ID | Size | RW | Thread | Details |
| | Bytes | | Guest | |
| | | | Scope | |
+========+=======+====+========+==================================+
| 0x0000 | | RW | TG | NOP element |
+--------+-------+----+--------+----------------------------------+
| 0x0001 | 0x08 | R | G | Size of L0 vCPU state. See: |
| | | | | H_GUEST_GET_STATE: |
| | | | | flags = takeOwnershipOfVcpuState |
+--------+-------+----+--------+----------------------------------+
| 0x0002 | 0x08 | R | G | Size Run vCPU out buffer |
+--------+-------+----+--------+----------------------------------+
| 0x0003 | 0x04 | RW | G | Logical PVR |
+--------+-------+----+--------+----------------------------------+
| 0x0004 | 0x08 | RW | G | TB Offset (L1 relative) |
+--------+-------+----+--------+----------------------------------+
| 0x0005 | 0x18 | RW | G |Partition scoped page tbl info: |
| | | | | |
| | | | |- 0x00 Addr part scope table |
| | | | |- 0x08 Num addr bits |
| | | | |- 0x10 Size root dir |
+--------+-------+----+--------+----------------------------------+
| 0x0006 | 0x10 | RW | G |Process Table Information: |
| | | | | |
| | | | |- 0x0 Addr proc scope table |
| | | | |- 0x8 Table size. |
+--------+-------+----+--------+----------------------------------+
| 0x0007-| | | | Reserved |
| 0x0BFF | | | | |
+--------+-------+----+--------+----------------------------------+
| 0x0C00 | 0x10 | RW | T |Run vCPU Input Buffer: |
| | | | | |
| | | | |- 0x0 Addr of buffer |
| | | | |- 0x8 Buffer Size. |
+--------+-------+----+--------+----------------------------------+
| 0x0C01 | 0x10 | RW | T |Run vCPU Output Buffer: |
| | | | | |
| | | | |- 0x0 Addr of buffer |
| | | | |- 0x8 Buffer Size. |
+--------+-------+----+--------+----------------------------------+
| 0x0C02 | 0x08 | RW | T | vCPU VPA Address |
+--------+-------+----+--------+----------------------------------+
| 0x0C03-| | | | Reserved |
| 0x0FFF | | | | |
+--------+-------+----+--------+----------------------------------+
| 0x1000-| 0x08 | RW | T | GPR 0-31 |
| 0x101F | | | | |
+--------+-------+----+--------+----------------------------------+
| 0x1020 | 0x08 | T | T | HDEC expiry TB |
+--------+-------+----+--------+----------------------------------+
| 0x1021 | 0x08 | RW | T | NIA |
+--------+-------+----+--------+----------------------------------+
| 0x1022 | 0x08 | RW | T | MSR |
+--------+-------+----+--------+----------------------------------+
| 0x1023 | 0x08 | RW | T | LR |
+--------+-------+----+--------+----------------------------------+
| 0x1024 | 0x08 | RW | T | XER |
+--------+-------+----+--------+----------------------------------+
| 0x1025 | 0x08 | RW | T | CTR |
+--------+-------+----+--------+----------------------------------+
| 0x1026 | 0x08 | RW | T | CFAR |
+--------+-------+----+--------+----------------------------------+
| 0x1027 | 0x08 | RW | T | SRR0 |
+--------+-------+----+--------+----------------------------------+
| 0x1028 | 0x08 | RW | T | SRR1 |
+--------+-------+----+--------+----------------------------------+
| 0x1029 | 0x08 | RW | T | DAR |
+--------+-------+----+--------+----------------------------------+
| 0x102A | 0x08 | RW | T | DEC expiry TB |
+--------+-------+----+--------+----------------------------------+
| 0x102B | 0x08 | RW | T | VTB |
+--------+-------+----+--------+----------------------------------+
| 0x102C | 0x08 | RW | T | LPCR |
+--------+-------+----+--------+----------------------------------+
| 0x102D | 0x08 | RW | T | HFSCR |
+--------+-------+----+--------+----------------------------------+
| 0x102E | 0x08 | RW | T | FSCR |
+--------+-------+----+--------+----------------------------------+
| 0x102F | 0x08 | RW | T | FPSCR |
+--------+-------+----+--------+----------------------------------+
| 0x1030 | 0x08 | RW | T | DAWR0 |
+--------+-------+----+--------+----------------------------------+
| 0x1031 | 0x08 | RW | T | DAWR1 |
+--------+-------+----+--------+----------------------------------+
| 0x1032 | 0x08 | RW | T | CIABR |
+--------+-------+----+--------+----------------------------------+
| 0x1033 | 0x08 | RW | T | PURR |
+--------+-------+----+--------+----------------------------------+
| 0x1034 | 0x08 | RW | T | SPURR |
+--------+-------+----+--------+----------------------------------+
| 0x1035 | 0x08 | RW | T | IC |
+--------+-------+----+--------+----------------------------------+
| 0x1036-| 0x08 | RW | T | SPRG 0-3 |
| 0x1039 | | | | |
+--------+-------+----+--------+----------------------------------+
| 0x103A | 0x08 | W | T | PPR |
+--------+-------+----+--------+----------------------------------+
| 0x103B | 0x08 | RW | T | MMCR 0-3 |
| 0x103E | | | | |
+--------+-------+----+--------+----------------------------------+
| 0x103F | 0x08 | RW | T | MMCRA |
+--------+-------+----+--------+----------------------------------+
| 0x1040 | 0x08 | RW | T | SIER |
+--------+-------+----+--------+----------------------------------+
| 0x1041 | 0x08 | RW | T | SIER 2 |
+--------+-------+----+--------+----------------------------------+
| 0x1042 | 0x08 | RW | T | SIER 3 |
+--------+-------+----+--------+----------------------------------+
| 0x1043 | 0x08 | RW | T | BESCR |
+--------+-------+----+--------+----------------------------------+
| 0x1044 | 0x08 | RW | T | EBBHR |
+--------+-------+----+--------+----------------------------------+
| 0x1045 | 0x08 | RW | T | EBBRR |
+--------+-------+----+--------+----------------------------------+
| 0x1046 | 0x08 | RW | T | AMR |
+--------+-------+----+--------+----------------------------------+
| 0x1047 | 0x08 | RW | T | IAMR |
+--------+-------+----+--------+----------------------------------+
| 0x1048 | 0x08 | RW | T | AMOR |
+--------+-------+----+--------+----------------------------------+
| 0x1049 | 0x08 | RW | T | UAMOR |
+--------+-------+----+--------+----------------------------------+
| 0x104A | 0x08 | RW | T | SDAR |
+--------+-------+----+--------+----------------------------------+
| 0x104B | 0x08 | RW | T | SIAR |
+--------+-------+----+--------+----------------------------------+
| 0x104C | 0x08 | RW | T | DSCR |
+--------+-------+----+--------+----------------------------------+
| 0x104D | 0x08 | RW | T | TAR |
+--------+-------+----+--------+----------------------------------+
| 0x104E | 0x08 | RW | T | DEXCR |
+--------+-------+----+--------+----------------------------------+
| 0x104F | 0x08 | RW | T | HDEXCR |
+--------+-------+----+--------+----------------------------------+
| 0x1050 | 0x08 | RW | T | HASHKEYR |
+--------+-------+----+--------+----------------------------------+
| 0x1051 | 0x08 | RW | T | HASHPKEYR |
+--------+-------+----+--------+----------------------------------+
| 0x1052 | 0x08 | RW | T | CTRL |
+--------+-------+----+--------+----------------------------------+
| 0x1053-| | | | Reserved |
| 0x1FFF | | | | |
+--------+-------+----+--------+----------------------------------+
| 0x2000 | 0x04 | RW | T | CR |
+--------+-------+----+--------+----------------------------------+
| 0x2001 | 0x04 | RW | T | PIDR |
+--------+-------+----+--------+----------------------------------+
| 0x2002 | 0x04 | RW | T | DSISR |
+--------+-------+----+--------+----------------------------------+
| 0x2003 | 0x04 | RW | T | VSCR |
+--------+-------+----+--------+----------------------------------+
| 0x2004 | 0x04 | RW | T | VRSAVE |
+--------+-------+----+--------+----------------------------------+
| 0x2005 | 0x04 | RW | T | DAWRX0 |
+--------+-------+----+--------+----------------------------------+
| 0x2006 | 0x04 | RW | T | DAWRX1 |
+--------+-------+----+--------+----------------------------------+
| 0x2007-| 0x04 | RW | T | PMC 1-6 |
| 0x200c | | | | |
+--------+-------+----+--------+----------------------------------+
| 0x200D | 0x04 | RW | T | WORT |
+--------+-------+----+--------+----------------------------------+
| 0x200E | 0x04 | RW | T | PSPB |
+--------+-------+----+--------+----------------------------------+
| 0x200F-| | | | Reserved |
| 0x2FFF | | | | |
+--------+-------+----+--------+----------------------------------+
| 0x3000-| 0x10 | RW | T | VSR 0-63 |
| 0x303F | | | | |
+--------+-------+----+--------+----------------------------------+
| 0x3040-| | | | Reserved |
| 0xEFFF | | | | |
+--------+-------+----+--------+----------------------------------+
| 0xF000 | 0x08 | R | T | HDAR |
+--------+-------+----+--------+----------------------------------+
| 0xF001 | 0x04 | R | T | HDSISR |
+--------+-------+----+--------+----------------------------------+
| 0xF002 | 0x04 | R | T | HEIR |
+--------+-------+----+--------+----------------------------------+
| 0xF003 | 0x08 | R | T | ASDR |
+--------+-------+----+--------+----------------------------------+
Miscellaneous info
==================
State not in ptregs/hvregs
--------------------------
In the v1 API, some state is not in the ptregs/hvstate. This includes
the vector register and some SPRs. For the L1 to set this state for
the L2, the L1 loads up these hardware registers before the
h_enter_nested() call and the L0 ensures they end up as the L2 state
(by not touching them).
The v2 API removes this and explicitly sets this state via the GSB.
L1 Implementation details: Caching state
----------------------------------------
In the v1 API, all state is sent from the L1 to the L0 and vice versa
on every h_enter_nested() hcall. If the L0 is not currently running
any L2s, the L0 has no state information about them. The only
exception to this is the location of the partition table, registered
via h_set_partition_table().
The v2 API changes this so that the L0 retains the L2 state even when
it's vCPUs are no longer running. This means that the L1 only needs to
communicate with the L0 about L2 state when it needs to modify the L2
state, or when it's value is out of date. This provides an opportunity
for performance optimisation.
When a vCPU exits from a H_GUEST_RUN_VCPU() call, the L1 internally
marks all L2 state as invalid. This means that if the L1 wants to know
the L2 state (say via a kvm_get_one_reg() call), it needs call
H_GUEST_GET_STATE() to get that state. Once it's read, it's marked as
valid in L1 until the L2 is run again.
Also, when an L1 modifies L2 vcpu state, it doesn't need to write it
to the L0 until that L2 vcpu runs again. Hence when the L1 updates
state (say via a kvm_set_one_reg() call), it writes to an internal L1
copy and only flushes this copy to the L0 when the L2 runs again via
the H_GUEST_VCPU_RUN() input buffer.
This lazy updating of state by the L1 avoids unnecessary
H_GUEST_{G|S}ET_STATE() calls.

6
Documentation/arch/riscv/hwprobe.rst
View File

@ -77,6 +77,9 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, as defined
in version 1.0 of the Bit-Manipulation ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Zicboz extension is supported, as
ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
information about the selected set of processors.
@ -96,3 +99,6 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_MISALIGNED_UNSUPPORTED`: Misaligned accesses are
not supported at all and will generate a misaligned address fault.
* :c:macro:`RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`: An unsigned int which
represents the size of the Zicboz block in bytes.

20
Documentation/arch/riscv/uabi.rst
View File

@ -42,6 +42,26 @@ An example string following the order is::
rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux
"isa" and "hart isa" lines in /proc/cpuinfo
-------------------------------------------
The "isa" line in /proc/cpuinfo describes the lowest common denominator of
RISC-V ISA extensions recognized by the kernel and implemented on all harts. The
"hart isa" line, in contrast, describes the set of extensions recognized by the
kernel on the particular hart being described, even if those extensions may not
be present on all harts in the system.
In both lines, the presence of an extension guarantees only that the hardware
has the described capability. Additional kernel support or policy changes may be
required before an extension's capability is fully usable by userspace programs.
Similarly, for S-mode extensions, presence in one of these lines does not
guarantee that the kernel is taking advantage of the extension, or that the
feature will be visible in guest VMs managed by this kernel.
Inversely, the absence of an extension in these lines does not necessarily mean
the hardware does not support that feature. The running kernel may not recognize
the extension, or may have deliberately removed it from the listing.
Misaligned accesses
-------------------

6
Documentation/arch/sh/index.rst
View File

@ -43,12 +43,6 @@ mach-x3proto
Busses
======
SuperHyway
----------
.. kernel-doc:: drivers/sh/superhyway/superhyway.c
:export:
Maple
-----

2
Documentation/arch/x86/boot.rst
View File

@ -77,7 +77,7 @@ Protocol 2.14 BURNT BY INCORRECT COMMIT
Protocol 2.15 (Kernel 5.5) Added the kernel_info and kernel_info.setup_type_max.
============= ============================================================
.. note::
.. note::
The protocol version number should be changed only if the setup header
is changed. There is no need to update the version number if boot_params
or kernel_info are changed. Additionally, it is recommended to use

6
Documentation/bpf/kfuncs.rst
View File

@ -37,16 +37,14 @@ prototype in a header for the wrapper kfunc.
An example is given below::
/* Disables missing prototype warnings */
__diag_push();
__diag_ignore_all("-Wmissing-prototypes",
"Global kfuncs as their definitions will be in BTF");
__bpf_kfunc_start_defs();
__bpf_kfunc struct task_struct *bpf_find_get_task_by_vpid(pid_t nr)
{
return find_get_task_by_vpid(nr);
}
__diag_pop();
__bpf_kfunc_end_defs();
A wrapper kfunc is often needed when we need to annotate parameters of the
kfunc. Otherwise one may directly make the kfunc visible to the BPF program by

2
Documentation/core-api/maple_tree.rst
View File

@ -175,7 +175,7 @@ will return the previous entry which occurs before the entry at index.
mas_find() will find the first entry which exists at or above index on
the first call, and the next entry from every subsequent calls.
mas_find_rev() will find the fist entry which exists at or below the last on
mas_find_rev() will find the first entry which exists at or below the last on
the first call, and the previous entry from every subsequent calls.
If the user needs to yield the lock during an operation, then the maple state

4
Documentation/crypto/devel-algos.rst
View File

@ -235,6 +235,4 @@ Specifics Of Asynchronous HASH Transformation
Some of the drivers will want to use the Generic ScatterWalk in case the
implementation needs to be fed separate chunks of the scatterlist which
contains the input data. The buffer containing the resulting hash will
always be properly aligned to .cra_alignmask so there is no need to
worry about this.
contains the input data.

7
Documentation/dev-tools/kasan.rst
View File

@ -1,5 +1,8 @@
The Kernel Address Sanitizer (KASAN)
====================================
.. SPDX-License-Identifier: GPL-2.0
.. Copyright (C) 2023, Google LLC.
Kernel Address Sanitizer (KASAN)
================================
Overview
--------

4
Documentation/dev-tools/kcsan.rst
View File

@ -1,8 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
.. Copyright (C) 2019, Google LLC.
The Kernel Concurrency Sanitizer (KCSAN)
========================================
Kernel Concurrency Sanitizer (KCSAN)
====================================
The Kernel Concurrency Sanitizer (KCSAN) is a dynamic race detector, which
relies on compile-time instrumentation, and uses a watchpoint-based sampling

6
Documentation/dev-tools/kmsan.rst
View File

@ -1,9 +1,9 @@
.. SPDX-License-Identifier: GPL-2.0
.. Copyright (C) 2022, Google LLC.
===================================
The Kernel Memory Sanitizer (KMSAN)
===================================
===============================
Kernel Memory Sanitizer (KMSAN)
===============================
KMSAN is a dynamic error detector aimed at finding uses of uninitialized
values. It is based on compiler instrumentation, and is quite similar to the

6
Documentation/dev-tools/ubsan.rst
View File

@ -1,5 +1,7 @@
The Undefined Behavior Sanitizer - UBSAN
========================================
.. SPDX-License-Identifier: GPL-2.0
Undefined Behavior Sanitizer - UBSAN
====================================
UBSAN is a runtime undefined behaviour checker.

39
Documentation/devicetree/bindings/arm/arm,integrator.yaml
View File

@ -40,45 +40,6 @@ properties:
items:
- const: arm,integrator-sp
core-module@10000000:
type: object
description: the root node in the Integrator platforms must contain
a core module child node. They are always at physical address
0x10000000 in all the Integrator variants.
properties:
compatible:
items:
- const: arm,core-module-integrator
- const: syscon
- const: simple-mfd
reg:
maxItems: 1
required:
- compatible
- reg
patternProperties:
"^syscon@[0-9a-f]+$":
description: All Integrator boards must provide a system controller as a
node in the root of the device tree.
type: object
properties:
compatible:
items:
- enum:
- arm,integrator-ap-syscon
- arm,integrator-cp-syscon
- arm,integrator-sp-syscon
- const: syscon
reg:
maxItems: 1
required:
- compatible
- reg
required:
- compatible
- core-module@10000000

37
Documentation/devicetree/bindings/arm/arm,realview.yaml
View File

@ -75,43 +75,6 @@ properties:
type: object
description: All RealView boards must provide a syscon system controller
node inside the soc node.
properties:
compatible:
oneOf:
- items:
- const: arm,realview-eb11mp-revb-syscon
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-eb11mp-revc-syscon
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pb1176-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pb11mp-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pba8-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pbx-syscon
- const: syscon
- const: simple-mfd
required:
- compatible
- reg
required:
- compatible

40
Documentation/devicetree/bindings/arm/arm,versatile.yaml
View File

@ -14,6 +14,14 @@ description: |+
with various pluggable interface boards, in essence the Versatile PB version
is a superset of the Versatile AB version.
The root node in the Versatile platforms must contain a core module child
node. They are always at physical address 0x10000000 in all the Versatile
variants.
When fitted with the IB2 Interface Board, the Versatile AB will present an
optional system controller node which controls the extra peripherals on the
interface board.
properties:
$nodename:
const: '/'
@ -32,38 +40,6 @@ properties:
items:
- const: arm,versatile-pb
core-module@10000000:
type: object
description: the root node in the Versatile platforms must contain
a core module child node. They are always at physical address
0x10000000 in all the Versatile variants.
properties:
compatible:
items:
- const: arm,core-module-versatile
- const: syscon
- const: simple-mfd
reg:
maxItems: 1
required:
- compatible
- reg
patternProperties:
"^syscon@[0-9a-f]+$":
type: object
description: When fitted with the IB2 Interface Board, the Versatile
AB will present an optional system controller node which controls the
extra peripherals on the interface board.
properties:
compatible:
contains:
const: arm,versatile-ib2-syscon
required:
- compatible
- reg
required:
- compatible
- core-module@10000000

43
Documentation/devicetree/bindings/crypto/fsl-imx-sahara.yaml
View File

@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/crypto/fsl-imx-sahara.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale SAHARA Cryptographic Accelerator included in some i.MX chips
title: Freescale SAHARA Cryptographic Accelerator
maintainers:
- Steffen Trumtrar <s.trumtrar@pengutronix.de>
@ -19,19 +19,56 @@ properties:
maxItems: 1
interrupts:
maxItems: 1
items:
- description: SAHARA Interrupt for Host 0
- description: SAHARA Interrupt for Host 1
minItems: 1
clocks:
items:
- description: Sahara IPG clock
- description: Sahara AHB clock
clock-names:
items:
- const: ipg
- const: ahb
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
allOf:
- if:
properties:
compatible:
contains:
enum:
- fsl,imx53-sahara
then:
properties:
interrupts:
minItems: 2
maxItems: 2
else:
properties:
interrupts:
maxItems: 1
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/imx27-clock.h>
crypto@10025000 {
compatible = "fsl,imx27-sahara";
reg = < 0x10025000 0x800>;
reg = <0x10025000 0x800>;
interrupts = <75>;
clocks = <&clks IMX27_CLK_SAHARA_IPG_GATE>,
<&clks IMX27_CLK_SAHARA_AHB_GATE>;
clock-names = "ipg", "ahb";
};

1
Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
View File

@ -13,6 +13,7 @@ properties:
compatible:
items:
- enum:
- qcom,sa8775p-inline-crypto-engine
- qcom,sm8450-inline-crypto-engine
- qcom,sm8550-inline-crypto-engine
- const: qcom,inline-crypto-engine

28
Documentation/devicetree/bindings/crypto/qcom,prng.yaml
View File

@ -11,9 +11,17 @@ maintainers:
properties:
compatible:
enum:
- qcom,prng # 8916 etc.
- qcom,prng-ee # 8996 and later using EE
oneOf:
- enum:
- qcom,prng # 8916 etc.
- qcom,prng-ee # 8996 and later using EE
- items:
- enum:
- qcom,sa8775p-trng
- qcom,sc7280-trng
- qcom,sm8450-trng
- qcom,sm8550-trng
- const: qcom,trng
reg:
maxItems: 1
@ -28,8 +36,18 @@ properties:
required:
- compatible
- reg
- clocks
- clock-names
allOf:
- if:
not:
properties:
compatible:
contains:
const: qcom,trng
then:
required:
- clocks
- clock-names
additionalProperties: false

6
Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
View File

@ -9,6 +9,9 @@ title: Analog Devices ADV7533/35 HDMI Encoders
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
allOf:
- $ref: /schemas/sound/dai-common.yaml#
description: |
The ADV7533 and ADV7535 are HDMI audio and video transmitters
compatible with HDMI 1.4 and DVI 1.0. They support color space
@ -89,6 +92,9 @@ properties:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 1, 2, 3, 4 ]
"#sound-dai-cells":
const: 0
ports:
description:
The ADV7533/35 has two video ports and one audio port.

20
Documentation/devicetree/bindings/display/fsl,lcdif.yaml
View File

@ -51,7 +51,10 @@ properties:
minItems: 1
interrupts:
maxItems: 1
items:
- description: LCDIF DMA interrupt
- description: LCDIF Error interrupt
minItems: 1
power-domains:
maxItems: 1
@ -131,6 +134,21 @@ allOf:
then:
required:
- power-domains
- if:
properties:
compatible:
contains:
enum:
- fsl,imx23-lcdif
then:
properties:
interrupts:
minItems: 2
maxItems: 2
else:
properties:
interrupts:
maxItems: 1
examples:
- |

1
Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
View File

@ -10,7 +10,6 @@ maintainers:
- Chun-Kuang Hu <chunkuang.hu@kernel.org>
- Philipp Zabel <p.zabel@pengutronix.de>
- Jitao Shi <jitao.shi@mediatek.com>
- Xinlei Lee <xinlei.lee@mediatek.com>
description: |
The MediaTek DSI function block is a sink of the display subsystem and can

2
Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
View File

@ -42,6 +42,8 @@ properties:
- lg,acx467akm-7
# LG Corporation 7" WXGA TFT LCD panel
- lg,ld070wx3-sl01
# LG Corporation 5" HD TFT LCD panel
- lg,lh500wx1-sd03
# One Stop Displays OSD101T2587-53TS 10.1" 1920x1200 panel
- osddisplays,osd101t2587-53ts
# Panasonic 10" WUXGA TFT LCD panel

2
Documentation/devicetree/bindings/display/panel/panel-simple.yaml
View File

@ -208,8 +208,6 @@ properties:
- lemaker,bl035-rgb-002
# LG 7" (800x480 pixels) TFT LCD panel
- lg,lb070wv8
# LG Corporation 5" HD TFT LCD panel
- lg,lh500wx1-sd03
# LG LP079QX1-SP0V 7.9" (1536x2048 pixels) TFT LCD panel
- lg,lp079qx1-sp0v
# LG 9.7" (2048x1536 pixels) TFT LCD panel

130
Documentation/devicetree/bindings/display/renesas,shmobile-lcdc.yaml Normal file
View File

@ -0,0 +1,130 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/renesas,shmobile-lcdc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas SH-Mobile LCD Controller (LCDC)
maintainers:
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
- Geert Uytterhoeven <geert+renesas@glider.be>
properties:
compatible:
enum:
- renesas,r8a7740-lcdc # R-Mobile A1
- renesas,sh73a0-lcdc # SH-Mobile AG5
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
minItems: 1
maxItems: 5
description:
Only the functional clock is mandatory.
Some of the optional clocks are model-dependent (e.g. "video" (a.k.a.
"vou" or "dv_clk") is available on R-Mobile A1 only).
clock-names:
minItems: 1
items:
- const: fck
- enum: [ media, lclk, hdmi, video ]
- enum: [ media, lclk, hdmi, video ]
- enum: [ media, lclk, hdmi, video ]
- enum: [ media, lclk, hdmi, video ]
power-domains:
maxItems: 1
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description: LCD port (R-Mobile A1 and SH-Mobile AG5)
unevaluatedProperties: false
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: HDMI port (R-Mobile A1 LCDC1 and SH-Mobile AG5)
unevaluatedProperties: false
port@2:
$ref: /schemas/graph.yaml#/properties/port
description: MIPI-DSI port (SH-Mobile AG5)
unevaluatedProperties: false
required:
- port@0
unevaluatedProperties: false
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- power-domains
- ports
additionalProperties: false
allOf:
- if:
properties:
compatible:
contains:
const: renesas,r8a7740-lcdc
then:
properties:
ports:
properties:
port@2: false
- if:
properties:
compatible:
contains:
const: renesas,sh73a0-lcdc
then:
properties:
ports:
required:
- port@1
- port@2
examples:
- |
#include <dt-bindings/clock/r8a7740-clock.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
lcd-controller@fe940000 {
compatible = "renesas,r8a7740-lcdc";
reg = <0xfe940000 0x4000>;
interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp1_clks R8A7740_CLK_LCDC0>,
<&cpg_clocks R8A7740_CLK_M3>, <&lcdlclk0_clk>,
<&vou_clk>;
clock-names = "fck", "media", "lclk", "video";
power-domains = <&pd_a4lc>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
lcdc0_rgb: endpoint {
};
};
};
};

8
Documentation/devicetree/bindings/display/solomon,ssd132x.yaml
View File

@ -11,10 +11,10 @@ maintainers:
properties:
compatible:
- enum:
- solomon,ssd1322
- solomon,ssd1325
- solomon,ssd1327
enum:
- solomon,ssd1322
- solomon,ssd1325
- solomon,ssd1327
required:
- compatible

2
Documentation/devicetree/bindings/dma/qcom,gpi.yaml
View File

@ -69,6 +69,8 @@ properties:
dma-channel-mask:
maxItems: 1
dma-coherent: true
required:
- compatible
- reg

5
Documentation/devicetree/bindings/eeprom/at24.yaml
View File

@ -12,6 +12,7 @@ maintainers:
allOf:
- $ref: /schemas/nvmem/nvmem.yaml
- $ref: /schemas/nvmem/nvmem-deprecated-cells.yaml
select:
properties:
@ -67,10 +68,14 @@ properties:
pattern: cs16$
- items:
pattern: c32$
- items:
pattern: c32d-wl$
- items:
pattern: cs32$
- items:
pattern: c64$
- items:
pattern: c64d-wl$
- items:
pattern: cs64$
- items:

135
Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt
View File

@ -1,135 +0,0 @@
Pinctrl-based I2C Bus DeMux
This binding describes an I2C bus demultiplexer that uses pin multiplexing to
route the I2C signals, and represents the pin multiplexing configuration using
the pinctrl device tree bindings. This may be used to select one I2C IP core at
runtime which may have a better feature set for a given task than another I2C
IP core on the SoC. The most simple example is to fall back to GPIO bitbanging
if your current runtime configuration hits an errata of the internal IP core.
+-------------------------------+
| SoC |
| | +-----+ +-----+
| +------------+ | | dev | | dev |
| |I2C IP Core1|--\ | +-----+ +-----+
| +------------+ \-------+ | | |
| |Pinctrl|--|------+--------+
| +------------+ +-------+ |
| |I2C IP Core2|--/ |
| +------------+ |
| |
+-------------------------------+
Required properties:
- compatible: "i2c-demux-pinctrl"
- i2c-parent: List of phandles of I2C masters available for selection. The first
one will be used as default.
- i2c-bus-name: The name of this bus. Also needed as pinctrl-name for the I2C
parents.
Furthermore, I2C mux properties and child nodes. See i2c-mux.yaml in this
directory.
Example:
Here is a snipplet for a bus to be demuxed. It contains various i2c clients for
HDMI, so the bus is named "i2c-hdmi":
i2chdmi: i2c@8 {
compatible = "i2c-demux-pinctrl";
i2c-parent = <&gpioi2c>, <&iic2>, <&i2c2>;
i2c-bus-name = "i2c-hdmi";
#address-cells = <1>;
#size-cells = <0>;
ak4643: sound-codec@12 {
compatible = "asahi-kasei,ak4643";
#sound-dai-cells = <0>;
reg = <0x12>;
};
composite-in@20 {
compatible = "adi,adv7180";
reg = <0x20>;
remote = <&vin1>;
port {
adv7180: endpoint {
bus-width = <8>;
remote-endpoint = <&vin1ep0>;
};
};
};
hdmi@39 {
compatible = "adi,adv7511w";
reg = <0x39>;
interrupt-parent = <&gpio1>;
interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
adi,input-style = <1>;
adi,input-justification = "evenly";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
adv7511_in: endpoint {
remote-endpoint = <&du_out_lvds0>;
};
};
port@1 {
reg = <1>;
adv7511_out: endpoint {
remote-endpoint = <&hdmi_con>;
};
};
};
};
};
And for clarification, here are the snipplets for the i2c-parents:
gpioi2c: i2c@9 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "i2c-gpio";
gpios = <&gpio5 6 GPIO_ACTIVE_HIGH /* sda */
&gpio5 5 GPIO_ACTIVE_HIGH /* scl */
>;
i2c-gpio,delay-us = <5>;
};
...
&i2c2 {
pinctrl-0 = <&i2c2_pins>;
pinctrl-names = "i2c-hdmi";
clock-frequency = <100000>;
};
...
&iic2 {
pinctrl-0 = <&iic2_pins>;
pinctrl-names = "i2c-hdmi";
clock-frequency = <100000>;
};
Please note:
- pinctrl properties for the parent I2C controllers need a pinctrl state
with the same name as i2c-bus-name, not "default"!
- the i2c masters must have their status "disabled". This driver will
enable them at runtime when needed.

172
Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml Normal file
View File

@ -0,0 +1,172 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/i2c-demux-pinctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Pinctrl-based I2C Bus Demultiplexer
maintainers:
- Wolfram Sang <wsa+renesas@sang-engineering.com>
description: |
This binding describes an I2C bus demultiplexer that uses pin multiplexing to
route the I2C signals, and represents the pin multiplexing configuration
using the pinctrl device tree bindings. This may be used to select one I2C
IP core at runtime which may have a better feature set for a given task than
another I2C IP core on the SoC. The most simple example is to fall back to
GPIO bitbanging if your current runtime configuration hits an errata of the
internal IP core.
+-------------------------------+
| SoC |
| | +-----+ +-----+
| +------------+ | | dev | | dev |
| |I2C IP Core1|--\ | +-----+ +-----+
| +------------+ \-------+ | | |
| |Pinctrl|--|------+--------+
| +------------+ +-------+ |
| |I2C IP Core2|--/ |
| +------------+ |
| |
+-------------------------------+
allOf:
- $ref: i2c-mux.yaml
- $ref: /schemas/i2c/i2c-controller.yaml#
properties:
compatible:
const: i2c-demux-pinctrl
i2c-parent:
$ref: /schemas/types.yaml#/definitions/phandle-array
description:
List of phandles of I2C masters available for selection. The first one
will be used as default.
i2c-bus-name:
$ref: /schemas/types.yaml#/definitions/string
description:
The name of this bus. Also needed as pinctrl-name for the I2C parents.
required:
- compatible
- i2c-parent
- i2c-bus-name
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
gpioi2c2: i2c-9 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "i2c-gpio";
scl-gpios = <&gpio5 5 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
sda-gpios = <&gpio5 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
i2c-gpio,delay-us = <5>;
// The I2C controller must have its status "disabled". The I2C bus
// demultiplexer will enable it at runtime when needed.
status = "disabled";
};
iic2: i2c@e6520000 {
reg = <0xe6520000 0x425>;
pinctrl-0 = <&iic2_pins>;
// The pinctrl property for the parent I2C controller needs a pinctrl
// state with the same name as i2c-bus-name in the I2C bus demultiplexer
// node, not "default"!
pinctrl-names = "i2c-hdmi";
clock-frequency = <100000>;
// The I2C controller must have its status "disabled". The I2C bus
// demultiplexer will enable it at runtime when needed.
status = "disabled";
};
i2c2: i2c@e6530000 {
reg = <0 0xe6530000 0 0x40>;
pinctrl-0 = <&i2c2_pins>;
// The pinctrl property for the parent I2C controller needs a pinctrl
// state with the same name as i2c-bus-name in the I2C bus demultiplexer
// node, not "default"!
pinctrl-names = "i2c-hdmi";
clock-frequency = <100000>;
// The I2C controller must have its status "disabled". The I2C bus
// demultiplexer will enable it at runtime when needed.
status = "disabled";
};
// Example for a bus to be demuxed. It contains various I2C clients for
// HDMI, so the bus is named "i2c-hdmi":
i2chdmi: i2c-mux3 {
compatible = "i2c-demux-pinctrl";
i2c-parent = <&iic2>, <&i2c2>, <&gpioi2c2>;
i2c-bus-name = "i2c-hdmi";
#address-cells = <1>;
#size-cells = <0>;
ak4643: codec@12 {
compatible = "asahi-kasei,ak4643";
#sound-dai-cells = <0>;
reg = <0x12>;
};
composite-in@20 {
compatible = "adi,adv7180";
reg = <0x20>;
port {
adv7180: endpoint {
bus-width = <8>;
remote-endpoint = <&vin1ep0>;
};
};
};
hdmi@39 {
compatible = "adi,adv7511w";
reg = <0x39>;
interrupt-parent = <&gpio1>;
interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
clocks = <&cec_clock>;
clock-names = "cec";
avdd-supply = <&fixedregulator1v8>;
dvdd-supply = <&fixedregulator1v8>;
pvdd-supply = <&fixedregulator1v8>;
dvdd-3v-supply = <&fixedregulator3v3>;
bgvdd-supply = <&fixedregulator1v8>;
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
adv7511_in: endpoint {
remote-endpoint = <&lvds0_out>;
};
};
port@1 {
reg = <1>;
adv7511_out: endpoint {
remote-endpoint = <&hdmi_con_out>;
};
};
};
};
};

2
Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
View File

@ -25,6 +25,7 @@ properties:
- items:
- enum:
- qcom,sc7280-cci
- qcom,sdm845-cci
- qcom,sm6350-cci
- qcom,sm8250-cci
@ -159,6 +160,7 @@ allOf:
compatible:
contains:
enum:
- qcom,sc7280-cci
- qcom,sm8250-cci
- qcom,sm8450-cci
then:

4
Documentation/devicetree/bindings/i3c/i3c.yaml
View File

@ -125,12 +125,12 @@ patternProperties:
minimum: 0
maximum: 0x7f
- description: |
First half of the Provisional ID (following the PID
First half of the Provisioned ID (following the PID
definition provided by the I3C specification).
Contains the manufacturer ID left-shifted by 1.
- description: |
Second half of the Provisional ID (following the PID
Second half of the Provisioned ID (following the PID
definition provided by the I3C specification).
Contains the ORing of the part ID left-shifted by 16,

14
Documentation/devicetree/bindings/iio/accel/kionix,kx022a.yaml
View File

@ -4,19 +4,23 @@
$id: http://devicetree.org/schemas/iio/accel/kionix,kx022a.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ROHM/Kionix KX022A Accelerometer
title: ROHM/Kionix KX022A, KX132-1211 and KX132ACR-LBZ Accelerometers
maintainers:
- Matti Vaittinen <mazziesaccount@gmail.com>
description: |
KX022A is a 3-axis accelerometer supporting +/- 2G, 4G, 8G and 16G ranges,
output data-rates from 0.78Hz to 1600Hz and a hardware-fifo buffering.
KX022A can be accessed either via I2C or SPI.
KX022A, KX132ACR-LBZ and KX132-1211 are 3-axis accelerometers supporting
+/- 2G, 4G, 8G and 16G ranges, variable output data-rates and a
hardware-fifo buffering. These accelerometers can be accessed either
via I2C or SPI.
properties:
compatible:
const: kionix,kx022a
enum:
- kionix,kx022a
- kionix,kx132-1211
- rohm,kx132acr-lbz
reg:
maxItems: 1

20
Documentation/devicetree/bindings/iio/adc/lltc,ltc2497.yaml
View File

@ -4,21 +4,31 @@
$id: http://devicetree.org/schemas/iio/adc/lltc,ltc2497.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Linear Technology / Analog Devices LTC2497 ADC
title: Linear Technology / Analog Devices LTC2497 and LTC2309 ADC
maintainers:
- Michael Hennerich <michael.hennerich@analog.com>
- Liam Beguin <liambeguin@gmail.com>
description: |
16bit ADC supporting up to 16 single ended or 8 differential inputs.
I2C interface.
LTC2309:
low noise, low power, 8-channel, 12-bit successive approximation ADC with an
I2C compatible serial interface.
https://www.analog.com/media/en/technical-documentation/data-sheets/2497fb.pdf
https://www.analog.com/media/en/technical-documentation/data-sheets/2499fe.pdf
https://www.analog.com/media/en/technical-documentation/data-sheets/2309fd.pdf
LTC2497:
LTC2499:
16bit ADC supporting up to 16 single ended or 8 differential inputs.
I2C interface.
https://www.analog.com/media/en/technical-documentation/data-sheets/2497fb.pdf
https://www.analog.com/media/en/technical-documentation/data-sheets/2499fe.pdf
properties:
compatible:
enum:
- lltc,ltc2309
- lltc,ltc2497
- lltc,ltc2499

205
Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml Normal file
View File

@ -0,0 +1,205 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/adc/microchip,mcp3564.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip MCP346X and MCP356X ADC Family
maintainers:
- Marius Cristea <marius.cristea@microchip.com>
description: |
Bindings for the Microchip family of 153.6 ksps, Low-Noise 16/24-Bit
Delta-Sigma ADCs with an SPI interface. Datasheet can be found here:
Datasheet for MCP3561, MCP3562, MCP3564 can be found here:
https://ww1.microchip.com/downloads/aemDocuments/documents/MSLD/ProductDocuments/DataSheets/MCP3561-2-4-Family-Data-Sheet-DS20006181C.pdf
Datasheet for MCP3561R, MCP3562R, MCP3564R can be found here:
https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/MCP3561_2_4R-Data-Sheet-DS200006391C.pdf
Datasheet for MCP3461, MCP3462, MCP3464 can be found here:
https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/MCP3461-2-4-Two-Four-Eight-Channel-153.6-ksps-Low-Noise-16-Bit-Delta-Sigma-ADC-Data-Sheet-20006180D.pdf
Datasheet for MCP3461R, MCP3462R, MCP3464R can be found here:
https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/MCP3461-2-4R-Family-Data-Sheet-DS20006404C.pdf
properties:
compatible:
enum:
- microchip,mcp3461
- microchip,mcp3462
- microchip,mcp3464
- microchip,mcp3461r
- microchip,mcp3462r
- microchip,mcp3464r
- microchip,mcp3561
- microchip,mcp3562
- microchip,mcp3564
- microchip,mcp3561r
- microchip,mcp3562r
- microchip,mcp3564r
reg:
maxItems: 1
spi-max-frequency:
maximum: 20000000
spi-cpha: true
spi-cpol: true
vdd-supply: true
avdd-supply: true
clocks:
description:
Phandle and clock identifier for external sampling clock.
If not specified, the internal crystal oscillator will be used.
maxItems: 1
interrupts:
description: IRQ line of the ADC
maxItems: 1
drive-open-drain:
description:
Whether to drive the IRQ signal as push-pull (default) or open-drain. Note
that the device requires this pin to become "high", otherwise it will stop
converting.
type: boolean
vref-supply:
description:
Some devices have a specific reference voltage supplied on a different
pin to the other supplies. Needed to be able to establish channel scaling
unless there is also an internal reference available (e.g. mcp3564r). In
case of "r" devices (e. g. mcp3564r), if it does not exists the internal
reference will be used.
microchip,hw-device-address:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 3
description:
The address is set on a per-device basis by fuses in the factory,
configured on request. If not requested, the fuses are set for 0x1.
The device address is part of the device markings to avoid
potential confusion. This address is coded on two bits, so four possible
addresses are available when multiple devices are present on the same
SPI bus with only one Chip Select line for all devices.
Each device communication starts by a CS falling edge, followed by the
clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
which is first one on the wire).
"#io-channel-cells":
const: 1
"#address-cells":
const: 1
"#size-cells":
const: 0
patternProperties:
"^channel@([0-9]|([1-7][0-9]))$":
$ref: adc.yaml
type: object
unevaluatedProperties: false
description: Represents the external channels which are connected to the ADC.
properties:
reg:
description: The channel number in single-ended and differential mode.
minimum: 0
maximum: 79
required:
- reg
dependencies:
spi-cpol: [ spi-cpha ]
spi-cpha: [ spi-cpol ]
required:
- compatible
- reg
- microchip,hw-device-address
- spi-max-frequency
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
- # External vref, no internal reference
if:
properties:
compatible:
contains:
enum:
- microchip,mcp3461
- microchip,mcp3462
- microchip,mcp3464
- microchip,mcp3561
- microchip,mcp3562
- microchip,mcp3564
then:
required:
- vref-supply
unevaluatedProperties: false
examples:
- |
spi {
#address-cells = <1>;
#size-cells = <0>;
adc@0 {
compatible = "microchip,mcp3564r";
reg = <0>;
vref-supply = <&vref_reg>;
spi-cpha;
spi-cpol;
spi-max-frequency = <10000000>;
microchip,hw-device-address = <1>;
#address-cells = <1>;
#size-cells = <0>;
channel@0 {
/* CH0 to AGND */
reg = <0>;
label = "CH0";
};
channel@1 {
/* CH1 to AGND */
reg = <1>;
label = "CH1";
};
/* diff-channels */
channel@11 {
reg = <11>;
/* CN0, CN1 */
diff-channels = <0 1>;
label = "CH0_CH1";
};
channel@22 {
reg = <0x22>;
/* CN1, CN2 */
diff-channels = <1 2>;
label = "CH1_CH3";
};
channel@23 {
reg = <0x23>;
/* CN1, CN3 */
diff-channels = <1 3>;
label = "CH1_CH3";
};
};
};
...

6
Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
View File

@ -18,7 +18,13 @@ description: |
properties:
compatible:
enum:
- microchip,mcp3910
- microchip,mcp3911
- microchip,mcp3912
- microchip,mcp3913
- microchip,mcp3914
- microchip,mcp3918
- microchip,mcp3919
reg:
maxItems: 1

3
Documentation/devicetree/bindings/iio/adc/ti,ads1015.yaml
View File

@ -23,6 +23,9 @@ properties:
reg:
maxItems: 1
interrupts:
maxItems: 1
"#address-cells":
const: 1

43
Documentation/devicetree/bindings/iio/adc/ti,twl6030-gpadc.yaml Normal file
View File

@ -0,0 +1,43 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/adc/ti,twl6030-gpadc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: GPADC subsystem in the TWL6030 power module
maintainers:
- Andreas Kemnade <andreas@kemnade.info>
description:
The GPADC subsystem in the TWL603X consists of a 10-bit ADC
combined with a 15-input analog multiplexer in the TWL6030 resp. a
19-input analog muliplexer in the TWL6032.
properties:
compatible:
enum:
- ti,twl6030-gpadc
- ti,twl6032-gpadc
interrupts:
maxItems: 1
"#io-channel-cells":
const: 1
required:
- compatible
- interrupts
- "#io-channel-cells"
additionalProperties: false
examples:
- |
gpadc {
compatible = "ti,twl6030-gpadc";
interrupts = <3>;
#io-channel-cells = <1>;
};
...

12
Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml
View File

@ -4,20 +4,26 @@
$id: http://devicetree.org/schemas/iio/amplifiers/adi,hmc425a.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: HMC425A 6-bit Digital Step Attenuator
title: Analog Devices HMC425A and similar Digital Step Attenuators
maintainers:
- Michael Hennerich <michael.hennerich@analog.com>
description: |
Digital Step Attenuator IIO device with gpio interface.
Digital Step Attenuator IIO devices with gpio interface.
Offer various frequency and attenuation ranges.
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
https://www.analog.com/media/en/technical-documentation/data-sheets/hmc425A.pdf
HMC540S 1 dB LSB Silicon MMIC 4-Bit Digital Positive Control Attenuator, 0.1 - 8 GHz
https://www.analog.com/media/en/technical-documentation/data-sheets/hmc540s.pdf
properties:
compatible:
enum:
- adi,hmc425a
- adi,hmc540s
vcc-supply: true

5
Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml
View File

@ -48,6 +48,11 @@ properties:
mount-matrix: true
invensense,level-shifter:
type: boolean
description: |
From ancient platform data struct: false: VLogic, true: VDD
i2c-gate:
$ref: /schemas/i2c/i2c-controller.yaml
unevaluatedProperties: false

3
Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml
View File

@ -93,6 +93,9 @@ properties:
wakeup-source:
$ref: /schemas/types.yaml#/definitions/flag
mount-matrix:
description: an optional 3x3 mounting rotation matrix
required:
- compatible
- reg

52
Documentation/devicetree/bindings/iio/pressure/rohm,bm1390.yaml Normal file
View File

@ -0,0 +1,52 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/pressure/rohm,bm1390.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ROHM BM1390 pressure sensor
maintainers:
- Matti Vaittinen <mazziesaccount@gmail.com>
description:
BM1390GLV-Z is a pressure sensor which performs internal temperature
compensation for the MEMS. Pressure range is from 300 hPa to 1300 hPa
and sample averaging and IIR filtering is built in. Temperature
measurement is also supported.
properties:
compatible:
const: rohm,bm1390glv-z
reg:
maxItems: 1
interrupts:
maxItems: 1
vdd-supply: true
required:
- compatible
- reg
- vdd-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
pressure-sensor@5d {
compatible = "rohm,bm1390glv-z";
reg = <0x5d>;
interrupt-parent = <&gpio1>;
interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
vdd-supply = <&vdd>;
};
};

177
Documentation/devicetree/bindings/iio/resolver/adi,ad2s1210.yaml Normal file
View File

@ -0,0 +1,177 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/resolver/adi,ad2s1210.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices AD2S1210 Resolver-to-Digital Converter
maintainers:
- Michael Hennerich <michael.hennerich@analog.com>
description: |
The AD2S1210 is a complete 10-bit to 16-bit resolution tracking
resolver-to-digital converter, integrating an on-board programmable
sinusoidal oscillator that provides sine wave excitation for
resolvers.
The AD2S1210 allows the user to read the angular position or the
angular velocity data directly from the parallel outputs or through
the serial interface.
The mode of operation of the communication channel (parallel or serial) is
selected by the A0 and A1 input pins. In normal mode, data is latched by
toggling the SAMPLE line and can then be read directly. In configuration mode,
data is read or written using a register access scheme (address byte with
read/write flag and data byte).
A1 A0 Result
0 0 Normal mode - position output
0 1 Normal mode - velocity output
1 0 Reserved
1 1 Configuration mode
In normal mode, the resolution of the digital output is selected using
the RES0 and RES1 input pins. In configuration mode, the resolution is
selected by setting the RES0 and RES1 bits in the control register.
RES1 RES0 Resolution (Bits)
0 0 10
0 1 12
1 0 14
1 1 16
Note on SPI connections: The CS line on the AD2S1210 should hard-wired to
logic low and the WR/FSYNC line on the AD2S1210 should be connected to the
SPI CSn output of the SPI controller.
Datasheet:
https://www.analog.com/media/en/technical-documentation/data-sheets/ad2s1210.pdf
properties:
compatible:
const: adi,ad2s1210
reg:
maxItems: 1
spi-max-frequency:
maximum: 25000000
spi-cpha: true
avdd-supply:
description:
A 4.75 to 5.25 V regulator that powers the Analog Supply Voltage (AVDD)
pin.
dvdd-supply:
description:
A 4.75 to 5.25 V regulator that powers the Digital Supply Voltage (DVDD)
pin.
vdrive-supply:
description:
A 2.3 to 5.25 V regulator that powers the Logic Power Supply Input
(VDrive) pin.
clocks:
maxItems: 1
description: External oscillator clock (CLKIN).
reset-gpios:
description:
GPIO connected to the /RESET pin. As the line needs to be low for the
reset to be active, it should be configured as GPIO_ACTIVE_LOW.
maxItems: 1
sample-gpios:
description:
GPIO connected to the /SAMPLE pin. As the line needs to be low to trigger
a sample, it should be configured as GPIO_ACTIVE_LOW.
maxItems: 1
mode-gpios:
description:
GPIO lines connected to the A0 and A1 pins. These pins select the data
transfer mode.
minItems: 2
maxItems: 2
resolution-gpios:
description:
GPIO lines connected to the RES0 and RES1 pins. These pins select the
resolution of the digital output. If omitted, it is assumed that the
RES0 and RES1 pins are hard-wired to match the assigned-resolution-bits
property.
minItems: 2
maxItems: 2
fault-gpios:
description:
GPIO lines connected to the LOT and DOS pins. These pins combined indicate
the type of fault present, if any. As these pins a pulled low to indicate
a fault condition, they should be configured as GPIO_ACTIVE_LOW.
minItems: 2
maxItems: 2
adi,fixed-mode:
description:
This is used to indicate the selected mode if A0 and A1 are hard-wired
instead of connected to GPIOS (i.e. mode-gpios is omitted).
$ref: /schemas/types.yaml#/definitions/string
enum: [config, velocity, position]
assigned-resolution-bits:
description:
Resolution of the digital output required by the application. This
determines the precision of the angle and/or the maximum speed that can
be measured. If resolution-gpios is omitted, it is assumed that RES0 and
RES1 are hard-wired to match this value.
enum: [10, 12, 14, 16]
required:
- compatible
- reg
- spi-cpha
- avdd-supply
- dvdd-supply
- vdrive-supply
- clocks
- sample-gpios
- assigned-resolution-bits
oneOf:
- required:
- mode-gpios
- required:
- adi,fixed-mode
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
resolver@0 {
compatible = "adi,ad2s1210";
reg = <0>;
spi-max-frequency = <20000000>;
spi-cpha;
avdd-supply = <&avdd_regulator>;
dvdd-supply = <&dvdd_regulator>;
vdrive-supply = <&vdrive_regulator>;
clocks = <&ext_osc>;
sample-gpios = <&gpio0 90 GPIO_ACTIVE_LOW>;
mode-gpios = <&gpio0 86 0>, <&gpio0 87 0>;
resolution-gpios = <&gpio0 88 0>, <&gpio0 89 0>;
assigned-resolution-bits = <16>;
};
};

2
Documentation/devicetree/bindings/input/fsl,scu-key.yaml
View File

@ -24,6 +24,8 @@ properties:
linux,keycodes:
maxItems: 1
wakeup-source: true
required:
- compatible
- linux,keycodes

3
Documentation/devicetree/bindings/input/touchscreen/cypress,tt21000.yaml
View File

@ -34,6 +34,9 @@ properties:
vdd-supply:
description: Regulator for voltage.
vddio-supply:
description: Optional Regulator for I/O voltage.
reset-gpios:
maxItems: 1

2
Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
View File

@ -1,7 +1,7 @@
Texas Instruments TWL family (twl4030) pwrbutton module
This module is part of the TWL4030. For more details about the whole
chip see Documentation/devicetree/bindings/mfd/twl-family.txt.
chip see Documentation/devicetree/bindings/mfd/ti,twl.yaml.
This module provides a simple power button event via an Interrupt.

74
Documentation/devicetree/bindings/interconnect/qcom,msm8939.yaml Normal file
View File

@ -0,0 +1,74 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interconnect/qcom,msm8939.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm MSM8939 Network-On-Chip interconnect
maintainers:
- Konrad Dybcio <konradybcio@kernel.org>
description: |
The Qualcomm MSM8939 interconnect providers support adjusting the
bandwidth requirements between the various NoC fabrics.
allOf:
- $ref: qcom,rpm-common.yaml#
properties:
compatible:
enum:
- qcom,msm8939-bimc
- qcom,msm8939-pcnoc
- qcom,msm8939-snoc
reg:
maxItems: 1
patternProperties:
'^interconnect-[a-z0-9\-]+$':
type: object
$ref: qcom,rpm-common.yaml#
description:
The interconnect providers do not have a separate QoS register space,
but share parent's space.
allOf:
- $ref: qcom,rpm-common.yaml#
properties:
compatible:
const: qcom,msm8939-snoc-mm
required:
- compatible
unevaluatedProperties: false
required:
- compatible
- reg
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmcc.h>
snoc: interconnect@580000 {
compatible = "qcom,msm8939-snoc";
reg = <0x00580000 0x14000>;
#interconnect-cells = <1>;
};
bimc: interconnect@400000 {
compatible = "qcom,msm8939-bimc";
reg = <0x00400000 0x62000>;
#interconnect-cells = <1>;
snoc_mm: interconnect-snoc {
compatible = "qcom,msm8939-snoc-mm";
#interconnect-cells = <1>;
};
};

126
Documentation/devicetree/bindings/interconnect/qcom,msm8996.yaml Normal file
View File

@ -0,0 +1,126 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interconnect/qcom,msm8996.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm MSM8996 Network-On-Chip interconnect
maintainers:
- Konrad Dybcio <konradybcio@kernel.org>
description: |
The Qualcomm MSM8996 interconnect providers support adjusting the
bandwidth requirements between the various NoC fabrics.
properties:
compatible:
enum:
- qcom,msm8996-a0noc
- qcom,msm8996-a1noc
- qcom,msm8996-a2noc
- qcom,msm8996-bimc
- qcom,msm8996-cnoc
- qcom,msm8996-mnoc
- qcom,msm8996-pnoc
- qcom,msm8996-snoc
reg:
maxItems: 1
clock-names:
minItems: 1
maxItems: 3
clocks:
minItems: 1
maxItems: 3
power-domains:
maxItems: 1
required:
- compatible
- reg
unevaluatedProperties: false
allOf:
- $ref: qcom,rpm-common.yaml#
- if:
properties:
compatible:
const: qcom,msm8996-a0noc
then:
properties:
clocks:
items:
- description: Aggregate0 System NoC AXI Clock.
- description: Aggregate0 Config NoC AHB Clock.
- description: Aggregate0 NoC MPU Clock.
clock-names:
items:
- const: aggre0_snoc_axi
- const: aggre0_cnoc_ahb
- const: aggre0_noc_mpu_cfg
required:
- power-domains
- if:
properties:
compatible:
const: qcom,msm8996-mnoc
then:
properties:
clocks:
items:
- description: CPU-NoC High-performance Bus Clock.
clock-names:
const: iface
- if:
properties:
compatible:
const: qcom,msm8996-a2noc
then:
properties:
clocks:
items:
- description: Aggregate2 NoC UFS AXI Clock
- description: UFS AXI Clock
clock-names:
items:
- const: aggre2_ufs_axi
- const: ufs_axi
examples:
- |
#include <dt-bindings/clock/qcom,gcc-msm8996.h>
#include <dt-bindings/clock/qcom,mmcc-msm8996.h>
#include <dt-bindings/clock/qcom,rpmcc.h>
bimc: interconnect@408000 {
compatible = "qcom,msm8996-bimc";
reg = <0x00408000 0x5a000>;
#interconnect-cells = <1>;
};
a0noc: interconnect@543000 {
compatible = "qcom,msm8996-a0noc";
reg = <0x00543000 0x6000>;
#interconnect-cells = <1>;
clocks = <&gcc GCC_AGGRE0_SNOC_AXI_CLK>,
<&gcc GCC_AGGRE0_CNOC_AHB_CLK>,
<&gcc GCC_AGGRE0_NOC_MPU_CFG_AHB_CLK>;
clock-names = "aggre0_snoc_axi",
"aggre0_cnoc_ahb",
"aggre0_noc_mpu_cfg";
power-domains = <&gcc AGGRE0_NOC_GDSC>;
};

60
Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml
View File

@ -13,6 +13,9 @@ description: |
The Qualcomm QCM2290 interconnect providers support adjusting the
bandwidth requirements between the various NoC fabrics.
allOf:
- $ref: qcom,rpm-common.yaml#
properties:
reg:
maxItems: 1
@ -23,19 +26,6 @@ properties:
- qcom,qcm2290-cnoc
- qcom,qcm2290-snoc
'#interconnect-cells':
const: 1
clock-names:
items:
- const: bus
- const: bus_a
clocks:
items:
- description: Bus Clock
- description: Bus A Clock
# Child node's properties
patternProperties:
'^interconnect-[a-z0-9]+$':
@ -44,6 +34,9 @@ patternProperties:
The interconnect providers do not have a separate QoS register space,
but share parent's space.
allOf:
- $ref: qcom,rpm-common.yaml#
properties:
compatible:
enum:
@ -51,35 +44,16 @@ patternProperties:
- qcom,qcm2290-mmrt-virt
- qcom,qcm2290-mmnrt-virt
'#interconnect-cells':
const: 1
clock-names:
items:
- const: bus
- const: bus_a
clocks:
items:
- description: Bus Clock
- description: Bus A Clock
required:
- compatible
- '#interconnect-cells'
- clock-names
- clocks
additionalProperties: false
unevaluatedProperties: false
required:
- compatible
- reg
- '#interconnect-cells'
- clock-names
- clocks
additionalProperties: false
unevaluatedProperties: false
examples:
- |
@ -89,32 +63,20 @@ examples:
compatible = "qcom,qcm2290-snoc";
reg = <0x01880000 0x60200>;
#interconnect-cells = <1>;
clock-names = "bus", "bus_a";
clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
<&rpmcc RPM_SMD_SNOC_A_CLK>;
qup_virt: interconnect-qup {
compatible = "qcom,qcm2290-qup-virt";
#interconnect-cells = <1>;
clock-names = "bus", "bus_a";
clocks = <&rpmcc RPM_SMD_QUP_CLK>,
<&rpmcc RPM_SMD_QUP_A_CLK>;
};
mmnrt_virt: interconnect-mmnrt {
compatible = "qcom,qcm2290-mmnrt-virt";
#interconnect-cells = <1>;
clock-names = "bus", "bus_a";
clocks = <&rpmcc RPM_SMD_MMNRT_CLK>,
<&rpmcc RPM_SMD_MMNRT_A_CLK>;
};
mmrt_virt: interconnect-mmrt {
compatible = "qcom,qcm2290-mmrt-virt";
#interconnect-cells = <1>;
clock-names = "bus", "bus_a";
clocks = <&rpmcc RPM_SMD_MMRT_CLK>,
<&rpmcc RPM_SMD_MMRT_A_CLK>;
};
};
@ -122,16 +84,10 @@ examples:
compatible = "qcom,qcm2290-cnoc";
reg = <0x01900000 0x8200>;
#interconnect-cells = <1>;
clock-names = "bus", "bus_a";
clocks = <&rpmcc RPM_SMD_CNOC_CLK>,
<&rpmcc RPM_SMD_CNOC_A_CLK>;
};
bimc: interconnect@4480000 {
compatible = "qcom,qcm2290-bimc";
reg = <0x04480000 0x80000>;
#interconnect-cells = <1>;
clock-names = "bus", "bus_a";
clocks = <&rpmcc RPM_SMD_BIMC_CLK>,
<&rpmcc RPM_SMD_BIMC_A_CLK>;
};

28
Documentation/devicetree/bindings/interconnect/qcom,rpm-common.yaml Normal file
View File

@ -0,0 +1,28 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interconnect/qcom,rpm-common.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm RPMh Network-On-Chip Interconnect
maintainers:
- Konrad Dybcio <konradybcio@kernel.org>
description:
RPM interconnect providers support for managing system bandwidth requirements
through manual requests based on either predefined values or as indicated by
the bus monitor hardware. Each provider node represents a NoC bus master,
driven by a dedicated clock source.
properties:
'#interconnect-cells':
oneOf:
- const: 2
- const: 1
deprecated: true
required:
- '#interconnect-cells'
additionalProperties: true

250
Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml
View File

@ -7,13 +7,16 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm RPM Network-On-Chip Interconnect
maintainers:
- Georgi Djakov <georgi.djakov@linaro.org>
- Georgi Djakov <djakov@kernel.org>
description: |
RPM interconnect providers support system bandwidth requirements through
RPM processor. The provider is able to communicate with the RPM through
the RPM shared memory device.
allOf:
- $ref: qcom,rpm-common.yaml#
properties:
reg:
maxItems: 1
@ -23,259 +26,22 @@ properties:
- qcom,msm8916-bimc
- qcom,msm8916-pcnoc
- qcom,msm8916-snoc
- qcom,msm8939-bimc
- qcom,msm8939-pcnoc
- qcom,msm8939-snoc
- qcom,msm8996-a0noc
- qcom,msm8996-a1noc
- qcom,msm8996-a2noc
- qcom,msm8996-bimc
- qcom,msm8996-cnoc
- qcom,msm8996-mnoc
- qcom,msm8996-pnoc
- qcom,msm8996-snoc
- qcom,qcs404-bimc
- qcom,qcs404-pcnoc
- qcom,qcs404-snoc
- qcom,sdm660-a2noc
- qcom,sdm660-bimc
- qcom,sdm660-cnoc
- qcom,sdm660-gnoc
- qcom,sdm660-mnoc
- qcom,sdm660-snoc
'#interconnect-cells':
description: |
Value: <1> is one cell in an interconnect specifier for the
interconnect node id, <2> requires the interconnect node id and an
extra path tag.
enum: [ 1, 2 ]
clocks:
minItems: 2
maxItems: 7
clock-names:
minItems: 2
maxItems: 7
power-domains:
maxItems: 1
# Child node's properties
patternProperties:
'^interconnect-[a-z0-9]+$':
type: object
additionalProperties: false
description:
snoc-mm is a child of snoc, sharing snoc's register address space.
properties:
compatible:
enum:
- qcom,msm8939-snoc-mm
'#interconnect-cells':
const: 1
clock-names:
items:
- const: bus
- const: bus_a
clocks:
items:
- description: Bus Clock
- description: Bus A Clock
required:
- compatible
- '#interconnect-cells'
- clock-names
- clocks
required:
- compatible
- reg
- '#interconnect-cells'
- clock-names
- clocks
additionalProperties: false
allOf:
- if:
properties:
compatible:
contains:
enum:
- qcom,msm8916-bimc
- qcom,msm8916-pcnoc
- qcom,msm8916-snoc
- qcom,msm8939-bimc
- qcom,msm8939-pcnoc
- qcom,msm8939-snoc
- qcom,msm8996-a1noc
- qcom,msm8996-bimc
- qcom,msm8996-cnoc
- qcom,msm8996-pnoc
- qcom,msm8996-snoc
- qcom,qcs404-bimc
- qcom,qcs404-pcnoc
- qcom,qcs404-snoc
- qcom,sdm660-bimc
- qcom,sdm660-cnoc
- qcom,sdm660-gnoc
- qcom,sdm660-snoc
then:
properties:
clock-names:
items:
- const: bus
- const: bus_a
clocks:
items:
- description: Bus Clock
- description: Bus A Clock
- if:
properties:
compatible:
contains:
enum:
- qcom,msm8996-mnoc
- qcom,sdm660-mnoc
then:
properties:
clock-names:
items:
- const: bus
- const: bus_a
- const: iface
clocks:
items:
- description: Bus Clock.
- description: Bus A Clock.
- description: CPU-NoC High-performance Bus Clock.
- if:
properties:
compatible:
contains:
enum:
- qcom,msm8996-a0noc
then:
properties:
clock-names:
items:
- const: aggre0_snoc_axi
- const: aggre0_cnoc_ahb
- const: aggre0_noc_mpu_cfg
clocks:
items:
- description: Aggregate0 System NoC AXI Clock.
- description: Aggregate0 Config NoC AHB Clock.
- description: Aggregate0 NoC MPU Clock.
required:
- power-domains
- if:
properties:
compatible:
contains:
enum:
- qcom,msm8996-a2noc
then:
properties:
clock-names:
items:
- const: bus
- const: bus_a
- const: aggre2_ufs_axi
- const: ufs_axi
clocks:
items:
- description: Bus Clock
- description: Bus A Clock
- description: Aggregate2 NoC UFS AXI Clock
- description: UFS AXI Clock
- if:
properties:
compatible:
contains:
enum:
- qcom,sdm660-a2noc
then:
properties:
clock-names:
items:
- const: bus
- const: bus_a
- const: ipa
- const: ufs_axi
- const: aggre2_ufs_axi
- const: aggre2_usb3_axi
- const: cfg_noc_usb2_axi
clocks:
items:
- description: Bus Clock.
- description: Bus A Clock.
- description: IPA Clock.
- description: UFS AXI Clock.
- description: Aggregate2 UFS AXI Clock.
- description: Aggregate2 USB3 AXI Clock.
- description: Config NoC USB2 AXI Clock.
- if:
not:
properties:
compatible:
contains:
enum:
- qcom,msm8939-snoc
then:
patternProperties:
'^interconnect-[a-z0-9]+$': false
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmcc.h>
bimc: interconnect@400000 {
compatible = "qcom,msm8916-bimc";
reg = <0x00400000 0x62000>;
#interconnect-cells = <1>;
clock-names = "bus", "bus_a";
clocks = <&rpmcc RPM_SMD_BIMC_CLK>,
<&rpmcc RPM_SMD_BIMC_A_CLK>;
};
pcnoc: interconnect@500000 {
compatible = "qcom,msm8916-pcnoc";
reg = <0x00500000 0x11000>;
#interconnect-cells = <1>;
clock-names = "bus", "bus_a";
clocks = <&rpmcc RPM_SMD_PCNOC_CLK>,
<&rpmcc RPM_SMD_PCNOC_A_CLK>;
};
snoc: interconnect@580000 {
compatible = "qcom,msm8916-snoc";
reg = <0x00580000 0x14000>;
#interconnect-cells = <1>;
clock-names = "bus", "bus_a";
clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
<&rpmcc RPM_SMD_SNOC_A_CLK>;
compatible = "qcom,msm8916-bimc";
reg = <0x00400000 0x62000>;
#interconnect-cells = <1>;
};

1
Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
View File

@ -113,6 +113,7 @@ allOf:
properties:
compatible:
enum:
- qcom,sdx65-mc-virt
- qcom,sm8250-qup-virt
then:
required:

108
Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml Normal file
View File

@ -0,0 +1,108 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interconnect/qcom,sdm660.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm SDM660 Network-On-Chip interconnect
maintainers:
- Konrad Dybcio <konradybcio@kernel.org>
description: |
The Qualcomm SDM660 interconnect providers support adjusting the
bandwidth requirements between the various NoC fabrics.
properties:
compatible:
enum:
- qcom,sdm660-a2noc
- qcom,sdm660-bimc
- qcom,sdm660-cnoc
- qcom,sdm660-gnoc
- qcom,sdm660-mnoc
- qcom,sdm660-snoc
reg:
maxItems: 1
clock-names:
minItems: 1
maxItems: 5
clocks:
minItems: 1
maxItems: 5
required:
- compatible
- reg
unevaluatedProperties: false
allOf:
- $ref: qcom,rpm-common.yaml#
- if:
properties:
compatible:
const: qcom,sdm660-mnoc
then:
properties:
clocks:
items:
- description: CPU-NoC High-performance Bus Clock.
clock-names:
const: iface
- if:
properties:
compatible:
const: qcom,sdm660-a2noc
then:
properties:
clocks:
items:
- description: IPA Clock.
- description: UFS AXI Clock.
- description: Aggregate2 UFS AXI Clock.
- description: Aggregate2 USB3 AXI Clock.
- description: Config NoC USB2 AXI Clock.
clock-names:
items:
- const: ipa
- const: ufs_axi
- const: aggre2_ufs_axi
- const: aggre2_usb3_axi
- const: cfg_noc_usb2_axi
examples:
- |
#include <dt-bindings/clock/qcom,gcc-sdm660.h>
#include <dt-bindings/clock/qcom,mmcc-sdm660.h>
#include <dt-bindings/clock/qcom,rpmcc.h>
bimc: interconnect@1008000 {
compatible = "qcom,sdm660-bimc";
reg = <0x01008000 0x78000>;
#interconnect-cells = <1>;
};
a2noc: interconnect@1704000 {
compatible = "qcom,sdm660-a2noc";
reg = <0x01704000 0xc100>;
#interconnect-cells = <1>;
clocks = <&rpmcc RPM_SMD_IPA_CLK>,
<&gcc GCC_UFS_AXI_CLK>,
<&gcc GCC_AGGRE2_UFS_AXI_CLK>,
<&gcc GCC_AGGRE2_USB3_AXI_CLK>,
<&gcc GCC_CFG_NOC_USB2_AXI_CLK>;
clock-names = "ipa",
"ufs_axi",
"aggre2_ufs_axi",
"aggre2_usb3_axi",
"cfg_noc_usb2_axi";
};

92
Documentation/devicetree/bindings/interconnect/qcom,sdx75-rpmh.yaml Normal file
View File

@ -0,0 +1,92 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interconnect/qcom,sdx75-rpmh.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm RPMh Network-On-Chip Interconnect on SDX75
maintainers:
- Rohit Agarwal <quic_rohiagar@quicinc.com>
description:
RPMh interconnect providers support system bandwidth requirements through
RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
able to communicate with the BCM through the Resource State Coordinator (RSC)
associated with each execution environment. Provider nodes must point to at
least one RPMh device child node pertaining to their RSC and each provider
can map to multiple RPMh resources.
properties:
compatible:
enum:
- qcom,sdx75-clk-virt
- qcom,sdx75-dc-noc
- qcom,sdx75-gem-noc
- qcom,sdx75-mc-virt
- qcom,sdx75-pcie-anoc
- qcom,sdx75-system-noc
'#interconnect-cells': true
reg:
maxItems: 1
clocks:
maxItems: 1
required:
- compatible
allOf:
- $ref: qcom,rpmh-common.yaml#
- if:
properties:
compatible:
contains:
enum:
- qcom,sdx75-clk-virt
- qcom,sdx75-mc-virt
then:
properties:
reg: false
else:
required:
- reg
- if:
properties:
compatible:
contains:
enum:
- qcom,sdx75-clk-virt
then:
properties:
clocks:
items:
- description: RPMH CC QPIC Clock
required:
- clocks
else:
properties:
clocks: false
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
clk_virt: interconnect-0 {
compatible = "qcom,sdx75-clk-virt";
#interconnect-cells = <2>;
qcom,bcm-voters = <&apps_bcm_voter>;
clocks = <&rpmhcc RPMH_QPIC_CLK>;
};
system_noc: interconnect@1640000 {
compatible = "qcom,sdx75-system-noc";
reg = <0x1640000 0x4b400>;
#interconnect-cells = <2>;
qcom,bcm-voters = <&apps_bcm_voter>;
};

4
Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml
View File

@ -62,6 +62,9 @@ properties:
- description: MPM pin number
- description: GIC SPI number for the MPM pin
'#power-domain-cells':
const: 0
required:
- compatible
- reg
@ -93,4 +96,5 @@ examples:
<86 183>,
<90 260>,
<91 260>;
#power-domain-cells = <0>;
};

2
Documentation/devicetree/bindings/iommu/arm,smmu.yaml
View File

@ -110,6 +110,7 @@ properties:
- qcom,sdm630-smmu-v2
- qcom,sdm845-smmu-v2
- qcom,sm6350-smmu-v2
- qcom,sm7150-smmu-v2
- const: qcom,adreno-smmu
- const: qcom,smmu-v2
- description: Qcom Adreno GPUs on Google Cheza platform
@ -409,6 +410,7 @@ allOf:
contains:
enum:
- qcom,sm6350-smmu-v2
- qcom,sm7150-smmu-v2
- qcom,sm8150-smmu-500
- qcom,sm8250-smmu-500
then:

17
Documentation/devicetree/bindings/leds/backlight/common.yaml
View File

@ -33,4 +33,21 @@ properties:
due to restrictions in a specific system, such as mounting conditions.
$ref: /schemas/types.yaml#/definitions/uint32
brightness-levels:
description:
Array of distinct brightness levels. The levels must be in the range
accepted by the underlying LED device. Typically these are in the range
from 0 to 255, but any range starting at 0 will do, as long as they are
accepted by the LED.
The 0 value means a 0% of brightness (darkest/off), while the last value
in the array represents a full 100% brightness (brightest).
If this array is not provided, the driver default mapping is used.
$ref: /schemas/types.yaml#/definitions/uint32-array
default-brightness-level:
description:
The default brightness level (index into the array defined by the
"brightness-levels" property).
$ref: /schemas/types.yaml#/definitions/uint32
additionalProperties: true

19
Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
View File

@ -16,6 +16,9 @@ description:
can also be used to describe a backlight device controlled by the output of
a LED driver.
allOf:
- $ref: common.yaml#
properties:
compatible:
const: led-backlight
@ -26,25 +29,11 @@ properties:
items:
maxItems: 1
brightness-levels:
description:
Array of distinct brightness levels. The levels must be in the range
accepted by the underlying LED devices. This is used to translate a
backlight brightness level into a LED brightness level. If it is not
provided, the identity mapping is used.
$ref: /schemas/types.yaml#/definitions/uint32-array
default-brightness-level:
description:
The default brightness level (index into the array defined by the
"brightness-levels" property).
$ref: /schemas/types.yaml#/definitions/uint32
required:
- compatible
- leds
additionalProperties: false
unevaluatedProperties: false
examples:
- |

10
Documentation/devicetree/bindings/leds/backlight/max8925-backlight.txt
View File

@ -1,10 +0,0 @@
88pm860x-backlight bindings
Optional properties:
- maxim,max8925-dual-string: whether support dual string
Example:
backlights {
maxim,max8925-dual-string = <0>;
};

73
Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml Normal file
View File

@ -0,0 +1,73 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/backlight/mps,mp3309c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MPS MP3309C backlight
maintainers:
- Flavio Suligoi <f.suligoi@asem.it>
description: |
The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a
programmable switching frequency to optimize efficiency.
It supports two different dimming modes:
- analog mode, via I2C commands (default)
- PWM controlled mode.
The datasheet is available at:
https://www.monolithicpower.com/en/mp3309c.html
allOf:
- $ref: common.yaml#
properties:
compatible:
const: mps,mp3309c
reg:
maxItems: 1
pwms:
description: if present, the backlight is controlled in PWM mode.
maxItems: 1
enable-gpios:
description: GPIO used to enable the backlight in "analog-i2c" dimming mode.
maxItems: 1
mps,overvoltage-protection-microvolt:
description: Overvoltage protection (13.5V, 24V or 35.5V).
enum: [ 13500000, 24000000, 35500000 ]
default: 35500000
mps,no-sync-mode:
description: disable synchronous rectification mode
type: boolean
required:
- compatible
- reg
- max-brightness
- default-brightness
unevaluatedProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
/* Backlight with PWM control */
backlight_pwm: backlight@17 {
compatible = "mps,mp3309c";
reg = <0x17>;
pwms = <&pwm1 0 3333333 0>; /* 300 Hz --> (1/f) * 1*10^9 */
max-brightness = <100>;
default-brightness = <80>;
mps,overvoltage-protection-microvolt = <24000000>;
};
};

20
Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
View File

@ -11,6 +11,9 @@ maintainers:
- Daniel Thompson <daniel.thompson@linaro.org>
- Jingoo Han <jingoohan1@gmail.com>
allOf:
- $ref: common.yaml#
properties:
compatible:
const: pwm-backlight
@ -39,21 +42,6 @@ properties:
Delay in ms between disabling the backlight using GPIO and setting PWM
value to 0.
brightness-levels:
description:
Array of distinct brightness levels. Typically these are in the range
from 0 to 255, but any range starting at 0 will do. The actual brightness
level (PWM duty cycle) will be interpolated from these values. 0 means a
0% duty cycle (darkest/off), while the last value in the array represents
a 100% duty cycle (brightest).
$ref: /schemas/types.yaml#/definitions/uint32-array
default-brightness-level:
description:
The default brightness level (index into the array defined by the
"brightness-levels" property).
$ref: /schemas/types.yaml#/definitions/uint32
num-interpolated-steps:
description:
Number of interpolated steps between each value of brightness-levels
@ -69,7 +57,7 @@ required:
- compatible
- pwms
additionalProperties: false
unevaluatedProperties: false
examples:
- |

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