mirror of
https://github.com/torvalds/linux.git
synced 2026-03-13 22:36:17 +01:00
Merge branch 'for-6.20/sony' into for-linus
- Support for Rock band 4 PS4 and PS5 guitars (Rosalie Wanders)
This commit is contained in:
Jiri Kosina
commit
ec496f77b4
5835 changed files with 248913 additions and 77088 deletions
|
|
@ -140,8 +140,8 @@ ForEachMacros:
|
|||
- 'damon_for_each_scheme_safe'
|
||||
- 'damon_for_each_target'
|
||||
- 'damon_for_each_target_safe'
|
||||
- 'damos_for_each_filter'
|
||||
- 'damos_for_each_filter_safe'
|
||||
- 'damos_for_each_core_filter'
|
||||
- 'damos_for_each_core_filter_safe'
|
||||
- 'damos_for_each_ops_filter'
|
||||
- 'damos_for_each_ops_filter_safe'
|
||||
- 'damos_for_each_quota_goal'
|
||||
|
|
@ -415,6 +415,7 @@ ForEachMacros:
|
|||
- 'for_each_prop_dlc_cpus'
|
||||
- 'for_each_prop_dlc_platforms'
|
||||
- 'for_each_property_of_node'
|
||||
- 'for_each_pt_level_entry'
|
||||
- 'for_each_rdt_resource'
|
||||
- 'for_each_reg'
|
||||
- 'for_each_reg_filtered'
|
||||
|
|
@ -747,6 +748,7 @@ ForEachMacros:
|
|||
- 'ynl_attr_for_each_nested'
|
||||
- 'ynl_attr_for_each_payload'
|
||||
- 'zorro_for_each_dev'
|
||||
- 'zpci_bus_for_each'
|
||||
|
||||
IncludeBlocks: Preserve
|
||||
IncludeCategories:
|
||||
|
|
|
|||
19
.mailmap
19
.mailmap
|
|
@ -127,7 +127,8 @@ Barry Song <baohua@kernel.org> <Baohua.Song@csr.com>
|
|||
Barry Song <baohua@kernel.org> <barry.song@analog.com>
|
||||
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@sandisk.com>
|
||||
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@wdc.com>
|
||||
Bartosz Golaszewski <brgl@bgdev.pl> <bgolaszewski@baylibre.com>
|
||||
Bartosz Golaszewski <brgl@kernel.org> <bartosz.golaszewski@linaro.org>
|
||||
Bartosz Golaszewski <brgl@kernel.org> <bgolaszewski@baylibre.com>
|
||||
Ben Dooks <ben-linux@fluff.org> <ben.dooks@simtec.co.uk>
|
||||
Ben Dooks <ben-linux@fluff.org> <ben.dooks@sifive.com>
|
||||
Ben Gardner <bgardner@wabtec.com>
|
||||
|
|
@ -186,6 +187,9 @@ Christian Brauner <brauner@kernel.org> <christian@brauner.io>
|
|||
Christian Brauner <brauner@kernel.org> <christian.brauner@canonical.com>
|
||||
Christian Brauner <brauner@kernel.org> <christian.brauner@ubuntu.com>
|
||||
Christian Marangi <ansuelsmth@gmail.com>
|
||||
Christophe Leroy <chleroy@kernel.org> <christophe.leroy@c-s.fr>
|
||||
Christophe Leroy <chleroy@kernel.org> <christophe.leroy@csgroup.eu>
|
||||
Christophe Leroy <chleroy@kernel.org> <christophe.leroy2@cs-soprasteria.com>
|
||||
Christophe Ricard <christophe.ricard@gmail.com>
|
||||
Christopher Obbard <christopher.obbard@linaro.org> <chris.obbard@collabora.com>
|
||||
Christoph Hellwig <hch@lst.de>
|
||||
|
|
@ -300,6 +304,7 @@ Hans de Goede <hansg@kernel.org> <hdegoede@redhat.com>
|
|||
Hans Verkuil <hverkuil@kernel.org> <hverkuil@xs4all.nl>
|
||||
Hans Verkuil <hverkuil@kernel.org> <hverkuil-cisco@xs4all.nl>
|
||||
Hans Verkuil <hverkuil@kernel.org> <hansverk@cisco.com>
|
||||
Hao Ge <hao.ge@linux.dev> <gehao@kylinos.cn>
|
||||
Harry Yoo <harry.yoo@oracle.com> <42.hyeyoo@gmail.com>
|
||||
Heiko Carstens <hca@linux.ibm.com> <h.carstens@de.ibm.com>
|
||||
Heiko Carstens <hca@linux.ibm.com> <heiko.carstens@de.ibm.com>
|
||||
|
|
@ -345,7 +350,8 @@ Jayachandran C <c.jayachandran@gmail.com> <jayachandranc@netlogicmicro.com>
|
|||
Jayachandran C <c.jayachandran@gmail.com> <jchandra@broadcom.com>
|
||||
Jayachandran C <c.jayachandran@gmail.com> <jchandra@digeo.com>
|
||||
Jayachandran C <c.jayachandran@gmail.com> <jnair@caviumnetworks.com>
|
||||
<jean-philippe@linaro.org> <jean-philippe.brucker@arm.com>
|
||||
Jean-Philippe Brucker <jpb@kernel.org> <jean-philippe.brucker@arm.com>
|
||||
Jean-Philippe Brucker <jpb@kernel.org> <jean-philippe@linaro.org>
|
||||
Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org> <jeanmichel.hautbois@ideasonboard.com>
|
||||
Jean Tourrilhes <jt@hpl.hp.com>
|
||||
Jeevan Shriram <quic_jshriram@quicinc.com> <jshriram@codeaurora.org>
|
||||
|
|
@ -499,9 +505,7 @@ Mark Brown <broonie@sirena.org.uk>
|
|||
Mark Starovoytov <mstarovo@pm.me> <mstarovoitov@marvell.com>
|
||||
Markus Schneider-Pargmann <msp@baylibre.com> <mpa@pengutronix.de>
|
||||
Mark Yao <markyao0591@gmail.com> <mark.yao@rock-chips.com>
|
||||
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@ginzinger.com>
|
||||
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@puri.sm>
|
||||
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@theobroma-systems.com>
|
||||
Martin Kepplinger-Novakovic <martink@posteo.de> <martin.kepplinger-novakovic@ginzinger.com>
|
||||
Martyna Szapar-Mudlaw <martyna.szapar-mudlaw@linux.intel.com> <martyna.szapar-mudlaw@intel.com>
|
||||
Mathieu Othacehe <othacehe@gnu.org> <m.othacehe@gmail.com>
|
||||
Mat Martineau <martineau@kernel.org> <mathew.j.martineau@linux.intel.com>
|
||||
|
|
@ -701,6 +705,8 @@ Sankeerth Billakanti <quic_sbillaka@quicinc.com> <sbillaka@codeaurora.org>
|
|||
Santosh Shilimkar <santosh.shilimkar@oracle.org>
|
||||
Santosh Shilimkar <ssantosh@kernel.org>
|
||||
Sarangdhar Joshi <spjoshi@codeaurora.org>
|
||||
Saravana Kannan <saravanak@kernel.org> <skannan@codeaurora.org>
|
||||
Saravana Kannan <saravanak@kernel.org> <saravanak@google.com>
|
||||
Sascha Hauer <s.hauer@pengutronix.de>
|
||||
Sahitya Tummala <quic_stummala@quicinc.com> <stummala@codeaurora.org>
|
||||
Sathishkumar Muruganandam <quic_murugana@quicinc.com> <murugana@codeaurora.org>
|
||||
|
|
@ -852,6 +858,8 @@ Vivien Didelot <vivien.didelot@gmail.com> <vivien.didelot@savoirfairelinux.com>
|
|||
Vlad Dogaru <ddvlad@gmail.com> <vlad.dogaru@intel.com>
|
||||
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@parallels.com>
|
||||
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@virtuozzo.com>
|
||||
WangYuli <wangyuli@aosc.io> <wangyl5933@chinaunicom.cn>
|
||||
WangYuli <wangyuli@aosc.io> <wangyuli@deepin.org>
|
||||
Weiwen Hu <huweiwen@linux.alibaba.com> <sehuww@mail.scut.edu.cn>
|
||||
WeiXiong Liao <gmpy.liaowx@gmail.com> <liaoweixiong@allwinnertech.com>
|
||||
Wen Gong <quic_wgong@quicinc.com> <wgong@codeaurora.org>
|
||||
|
|
@ -863,6 +871,7 @@ Yakir Yang <kuankuan.y@gmail.com> <ykk@rock-chips.com>
|
|||
Yanteng Si <si.yanteng@linux.dev> <siyanteng@loongson.cn>
|
||||
Ying Huang <huang.ying.caritas@gmail.com> <ying.huang@intel.com>
|
||||
Yosry Ahmed <yosry.ahmed@linux.dev> <yosryahmed@google.com>
|
||||
Yu-Chun Lin <eleanor.lin@realtek.com> <eleanor15x@gmail.com>
|
||||
Yusuke Goda <goda.yusuke@renesas.com>
|
||||
Zack Rusin <zack.rusin@broadcom.com> <zackr@vmware.com>
|
||||
Zhu Yanjun <zyjzyj2000@gmail.com> <yanjunz@nvidia.com>
|
||||
|
|
|
|||
14
CREDITS
14
CREDITS
|
|
@ -16,6 +16,10 @@ D: One of assisting postmasters for vger.kernel.org's lists
|
|||
S: (ask for current address)
|
||||
S: Finland
|
||||
|
||||
N: Kishon Vijay Abraham I
|
||||
E: kishon@kernel.org
|
||||
D: Generic Phy Framework
|
||||
|
||||
N: Thomas Abraham
|
||||
E: thomas.ab@samsung.com
|
||||
D: Samsung pin controller driver
|
||||
|
|
@ -1983,6 +1987,7 @@ D: netfilter: TCP window tracking code
|
|||
D: netfilter: raw table
|
||||
D: netfilter: iprange match
|
||||
D: netfilter: new logging interfaces
|
||||
D: netfilter: ipset
|
||||
D: netfilter: various other hacks
|
||||
S: Tata
|
||||
S: Hungary
|
||||
|
|
@ -2056,16 +2061,15 @@ S: Korte Heul 95
|
|||
S: 1403 ND BUSSUM
|
||||
S: The Netherlands
|
||||
|
||||
N: Martin Kepplinger
|
||||
N: Martin Kepplinger-Novakovic
|
||||
E: martink@posteo.de
|
||||
E: martin.kepplinger@puri.sm
|
||||
W: http://www.martinkepplinger.com
|
||||
P: 4096R/5AB387D3 F208 2B88 0F9E 4239 3468 6E3F 5003 98DF 5AB3 87D3
|
||||
D: mma8452 accelerators iio driver
|
||||
D: pegasus_notetaker input driver
|
||||
D: imx8m media and hi846 sensor driver
|
||||
D: Kernel fixes and cleanups
|
||||
S: Garnisonstraße 26
|
||||
S: 4020 Linz
|
||||
S: Keplerstr. 6
|
||||
S: 4050 Traun
|
||||
S: Austria
|
||||
|
||||
N: Karl Keyte
|
||||
|
|
|
|||
71
Documentation/ABI/obsolete/sysfs-kernel-kexec-kdump
Normal file
71
Documentation/ABI/obsolete/sysfs-kernel-kexec-kdump
Normal file
|
|
@ -0,0 +1,71 @@
|
|||
NOTE: all the ABIs listed in this file are deprecated and will be removed after 2028.
|
||||
|
||||
Here are the alternative ABIs:
|
||||
+------------------------------------+-----------------------------------------+
|
||||
| Deprecated | Alternative |
|
||||
+------------------------------------+-----------------------------------------+
|
||||
| /sys/kernel/kexec_loaded | /sys/kernel/kexec/loaded |
|
||||
+------------------------------------+-----------------------------------------+
|
||||
| /sys/kernel/kexec_crash_loaded | /sys/kernel/kexec/crash_loaded |
|
||||
+------------------------------------+-----------------------------------------+
|
||||
| /sys/kernel/kexec_crash_size | /sys/kernel/kexec/crash_size |
|
||||
+------------------------------------+-----------------------------------------+
|
||||
| /sys/kernel/crash_elfcorehdr_size | /sys/kernel/kexec/crash_elfcorehdr_size |
|
||||
+------------------------------------+-----------------------------------------+
|
||||
| /sys/kernel/kexec_crash_cma_ranges | /sys/kernel/kexec/crash_cma_ranges |
|
||||
+------------------------------------+-----------------------------------------+
|
||||
|
||||
|
||||
What: /sys/kernel/kexec_loaded
|
||||
Date: Jun 2006
|
||||
Contact: kexec@lists.infradead.org
|
||||
Description: read only
|
||||
Indicates whether a new kernel image has been loaded
|
||||
into memory using the kexec system call. It shows 1 if
|
||||
a kexec image is present and ready to boot, or 0 if none
|
||||
is loaded.
|
||||
User: kexec tools, kdump service
|
||||
|
||||
What: /sys/kernel/kexec_crash_loaded
|
||||
Date: Jun 2006
|
||||
Contact: kexec@lists.infradead.org
|
||||
Description: read only
|
||||
Indicates whether a crash (kdump) kernel is currently
|
||||
loaded into memory. It shows 1 if a crash kernel has been
|
||||
successfully loaded for panic handling, or 0 if no crash
|
||||
kernel is present.
|
||||
User: Kexec tools, Kdump service
|
||||
|
||||
What: /sys/kernel/kexec_crash_size
|
||||
Date: Dec 2009
|
||||
Contact: kexec@lists.infradead.org
|
||||
Description: read/write
|
||||
Shows the amount of memory reserved for loading the crash
|
||||
(kdump) kernel. It reports the size, in bytes, of the
|
||||
crash kernel area defined by the crashkernel= parameter.
|
||||
This interface also allows reducing the crashkernel
|
||||
reservation by writing a smaller value, and the reclaimed
|
||||
space is added back to the system RAM.
|
||||
User: Kdump service
|
||||
|
||||
What: /sys/kernel/crash_elfcorehdr_size
|
||||
Date: Aug 2023
|
||||
Contact: kexec@lists.infradead.org
|
||||
Description: read only
|
||||
Indicates the preferred size of the memory buffer for the
|
||||
ELF core header used by the crash (kdump) kernel. It defines
|
||||
how much space is needed to hold metadata about the crashed
|
||||
system, including CPU and memory information. This information
|
||||
is used by the user space utility kexec to support updating the
|
||||
in-kernel kdump image during hotplug operations.
|
||||
User: Kexec tools
|
||||
|
||||
What: /sys/kernel/kexec_crash_cma_ranges
|
||||
Date: Nov 2025
|
||||
Contact: kexec@lists.infradead.org
|
||||
Description: read only
|
||||
Provides information about the memory ranges reserved from
|
||||
the Contiguous Memory Allocator (CMA) area that are allocated
|
||||
to the crash (kdump) kernel. It lists the start and end physical
|
||||
addresses of CMA regions assigned for crashkernel use.
|
||||
User: kdump service
|
||||
|
|
@ -14,7 +14,7 @@ Description:
|
|||
for RTCs that support alarms
|
||||
|
||||
* RTC_ALM_READ, RTC_ALM_SET: Read or set the alarm time for
|
||||
RTCs that support alarms. Can be set upto 24 hours in the
|
||||
RTCs that support alarms. Can be set up to 24 hours in the
|
||||
future. Requires a separate RTC_AIE_ON call to enable the
|
||||
alarm interrupt. (Prefer to use RTC_WKALM_*)
|
||||
|
||||
|
|
|
|||
|
|
@ -496,8 +496,17 @@ Description:
|
|||
changed, only freed by writing 0. The kernel makes no guarantees
|
||||
that data is maintained over an address space freeing event, and
|
||||
there is no guarantee that a free followed by an allocate
|
||||
results in the same address being allocated.
|
||||
results in the same address being allocated. If extended linear
|
||||
cache is present, the size indicates extended linear cache size
|
||||
plus the CXL region size.
|
||||
|
||||
What: /sys/bus/cxl/devices/regionZ/extended_linear_cache_size
|
||||
Date: October, 2025
|
||||
KernelVersion: v6.19
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) The size of extended linear cache, if there is an extended
|
||||
linear cache. Otherwise the attribute will not be visible.
|
||||
|
||||
What: /sys/bus/cxl/devices/regionZ/mode
|
||||
Date: January, 2023
|
||||
|
|
|
|||
|
|
@ -898,6 +898,7 @@ What: /sys/.../iio:deviceX/events/in_tempY_thresh_rising_en
|
|||
What: /sys/.../iio:deviceX/events/in_tempY_thresh_falling_en
|
||||
What: /sys/.../iio:deviceX/events/in_capacitanceY_thresh_rising_en
|
||||
What: /sys/.../iio:deviceX/events/in_capacitanceY_thresh_falling_en
|
||||
What: /sys/.../iio:deviceX/events/in_pressure_thresh_rising_en
|
||||
KernelVersion: 2.6.37
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
|
|
@ -926,6 +927,7 @@ What: /sys/.../iio:deviceX/events/in_accel_y_roc_rising_en
|
|||
What: /sys/.../iio:deviceX/events/in_accel_y_roc_falling_en
|
||||
What: /sys/.../iio:deviceX/events/in_accel_z_roc_rising_en
|
||||
What: /sys/.../iio:deviceX/events/in_accel_z_roc_falling_en
|
||||
What: /sys/.../iio:deviceX/events/in_accel_x&y&z_roc_rising_en
|
||||
What: /sys/.../iio:deviceX/events/in_anglvel_x_roc_rising_en
|
||||
What: /sys/.../iio:deviceX/events/in_anglvel_x_roc_falling_en
|
||||
What: /sys/.../iio:deviceX/events/in_anglvel_y_roc_rising_en
|
||||
|
|
@ -1001,6 +1003,7 @@ Description:
|
|||
to the raw signal, allowing slow tracking to resume and the
|
||||
adaptive threshold event detection to function as expected.
|
||||
|
||||
What: /sys/.../events/in_accel_mag_adaptive_rising_value
|
||||
What: /sys/.../events/in_accel_thresh_rising_value
|
||||
What: /sys/.../events/in_accel_thresh_falling_value
|
||||
What: /sys/.../events/in_accel_x_raw_thresh_rising_value
|
||||
|
|
@ -1045,6 +1048,7 @@ What: /sys/.../events/in_capacitanceY_thresh_rising_value
|
|||
What: /sys/.../events/in_capacitanceY_thresh_falling_value
|
||||
What: /sys/.../events/in_capacitanceY_thresh_adaptive_rising_value
|
||||
What: /sys/.../events/in_capacitanceY_thresh_falling_rising_value
|
||||
What: /sys/.../events/in_pressure_thresh_rising_value
|
||||
KernelVersion: 2.6.37
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
|
|
@ -1147,6 +1151,7 @@ Description:
|
|||
will get activated once in_voltage0_raw goes above 1200 and will become
|
||||
deactivated again once the value falls below 1150.
|
||||
|
||||
What: /sys/.../events/in_accel_roc_rising_value
|
||||
What: /sys/.../events/in_accel_x_raw_roc_rising_value
|
||||
What: /sys/.../events/in_accel_x_raw_roc_falling_value
|
||||
What: /sys/.../events/in_accel_y_raw_roc_rising_value
|
||||
|
|
@ -1193,6 +1198,8 @@ Description:
|
|||
value is in raw device units or in processed units (as _raw
|
||||
and _input do on sysfs direct channel read attributes).
|
||||
|
||||
What: /sys/.../events/in_accel_mag_adaptive_rising_period
|
||||
What: /sys/.../events/in_accel_roc_rising_period
|
||||
What: /sys/.../events/in_accel_x_thresh_rising_period
|
||||
What: /sys/.../events/in_accel_x_thresh_falling_period
|
||||
What: /sys/.../events/in_accel_x_roc_rising_period
|
||||
|
|
@ -1362,6 +1369,15 @@ Description:
|
|||
number or direction is not specified, applies to all channels of
|
||||
this type.
|
||||
|
||||
What: /sys/.../iio:deviceX/events/in_accel_x_mag_adaptive_rising_en
|
||||
What: /sys/.../iio:deviceX/events/in_accel_y_mag_adaptive_rising_en
|
||||
What: /sys/.../iio:deviceX/events/in_accel_z_mag_adaptive_rising_en
|
||||
KernelVersion: 2.6.37
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Similar to in_accel_x_thresh[_rising|_falling]_en, but here the
|
||||
magnitude of the channel is compared to the adaptive threshold.
|
||||
|
||||
What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_en
|
||||
What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_rising_en
|
||||
What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_falling_en
|
||||
|
|
@ -2422,3 +2438,23 @@ Description:
|
|||
Value representing the user's attention to the system expressed
|
||||
in units as percentage. This usually means if the user is
|
||||
looking at the screen or not.
|
||||
|
||||
What: /sys/.../events/in_accel_value_available
|
||||
KernelVersion: 6.18
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
List of available threshold values for acceleration event
|
||||
generation. Applies to all event types on in_accel channels.
|
||||
Units after application of scale and offset are m/s^2.
|
||||
Expressed as:
|
||||
|
||||
- a range specified as "[min step max]"
|
||||
|
||||
What: /sys/.../events/in_accel_period_available
|
||||
KernelVersion: 6.18
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
List of available periods for accelerometer event detection in
|
||||
seconds, expressed as:
|
||||
|
||||
- a range specified as "[min step max]"
|
||||
|
|
|
|||
|
|
@ -621,3 +621,84 @@ Description:
|
|||
number extended capability. The file is read only and due to
|
||||
the possible sensitivity of accessible serial numbers, admin
|
||||
only.
|
||||
|
||||
What: /sys/bus/pci/devices/.../tsm/
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description:
|
||||
This directory only appears if a physical device function
|
||||
supports authentication (PCIe CMA-SPDM), interface security
|
||||
(PCIe TDISP), and is accepted for secure operation by the
|
||||
platform TSM driver. This attribute directory appears
|
||||
dynamically after the platform TSM driver loads. So, only after
|
||||
the /sys/class/tsm/tsm0 device arrives can tools assume that
|
||||
devices without a tsm/ attribute directory will never have one;
|
||||
before that, the security capabilities of the device relative to
|
||||
the platform TSM are unknown. See
|
||||
Documentation/ABI/testing/sysfs-class-tsm.
|
||||
|
||||
What: /sys/bus/pci/devices/.../tsm/connect
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description:
|
||||
(RW) Write the name of a TSM (TEE Security Manager) device from
|
||||
/sys/class/tsm to this file to establish a connection with the
|
||||
device. This typically includes an SPDM (DMTF Security
|
||||
Protocols and Data Models) session over PCIe DOE (Data Object
|
||||
Exchange) and may also include PCIe IDE (Integrity and Data
|
||||
Encryption) establishment. Reads from this attribute return the
|
||||
name of the connected TSM or the empty string if not
|
||||
connected. A TSM device signals its readiness to accept PCI
|
||||
connection via a KOBJ_CHANGE event.
|
||||
|
||||
What: /sys/bus/pci/devices/.../tsm/disconnect
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description:
|
||||
(WO) Write the name of the TSM device that was specified
|
||||
to 'connect' to teardown the connection.
|
||||
|
||||
What: /sys/bus/pci/devices/.../tsm/dsm
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description: (RO) Return PCI device name of this device's DSM (Device
|
||||
Security Manager). When a device is in the connected state it
|
||||
indicates that the platform TSM (TEE Security Manager) has made
|
||||
a secure-session connection with a device's DSM. A DSM is always
|
||||
physical function 0 and when the device supports TDISP (TEE
|
||||
Device Interface Security Protocol) its managed functions also
|
||||
populate this tsm/dsm attribute. The managed functions of a DSM
|
||||
are SR-IOV (Single Root I/O Virtualization) virtual functions,
|
||||
non-zero functions of a multi-function device, or downstream
|
||||
endpoints depending on whether the DSM is an SR-IOV physical
|
||||
function, function0 of a multi-function device, or an upstream
|
||||
PCIe switch port. This is a "link" TSM attribute, see
|
||||
Documentation/ABI/testing/sysfs-class-tsm.
|
||||
|
||||
What: /sys/bus/pci/devices/.../tsm/bound
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description: (RO) Return the device name of the TSM when the device is in a
|
||||
TDISP (TEE Device Interface Security Protocol) operational state
|
||||
(LOCKED, RUN, or ERROR, not UNLOCKED). Bound devices consume
|
||||
platform TSM resources and depend on the device's configuration
|
||||
(e.g. BME (Bus Master Enable) and MSE (Memory Space Enable)
|
||||
among other settings) to remain stable for the duration of the
|
||||
bound state. This attribute is only visible for devices that
|
||||
support TDISP operation, and it is only populated after
|
||||
successful connect and TSM bind. The TSM bind operation is
|
||||
initiated by VFIO/IOMMUFD. This is a "link" TSM attribute, see
|
||||
Documentation/ABI/testing/sysfs-class-tsm.
|
||||
|
||||
What: /sys/bus/pci/devices/.../authenticated
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
Description:
|
||||
When the device's tsm/ directory is present device
|
||||
authentication (PCIe CMA-SPDM) and link encryption (PCIe IDE)
|
||||
are handled by the platform TSM (TEE Security Manager). When the
|
||||
tsm/ directory is not present this attribute reflects only the
|
||||
native CMA-SPDM authentication state with the kernel's
|
||||
certificate store.
|
||||
|
||||
If the attribute is not present, it indicates that
|
||||
authentication is unsupported by the device, or the TSM has no
|
||||
available authentication methods for the device.
|
||||
|
||||
When present and the tsm/ attribute directory is present, the
|
||||
authenticated attribute is an alias for the device 'connect'
|
||||
state. See the 'tsm/connect' attribute for more details.
|
||||
|
|
|
|||
|
|
@ -23,6 +23,8 @@ Description: This file contains a space-separated list of profiles supported
|
|||
power consumption with a slight bias
|
||||
towards performance
|
||||
performance High performance operation
|
||||
max-power Higher performance operation that may exceed
|
||||
internal battery draw limits when on AC power
|
||||
custom Driver defined custom profile
|
||||
==================== ========================================
|
||||
|
||||
|
|
|
|||
30
Documentation/ABI/testing/sysfs-class-power-rt9756
Normal file
30
Documentation/ABI/testing/sysfs-class-power-rt9756
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
What: /sys/class/power_supply/rt9756-*/watchdog_timer
|
||||
Date: Dec 2025
|
||||
KernelVersion: 6.19
|
||||
Contact: ChiYuan Huang <cy_huang@richtek.com>
|
||||
Description:
|
||||
This entry shows and sets the watchdog timer when rt9756 charger
|
||||
operates in charging mode. When the timer expires, the device
|
||||
will disable the charging. To prevent the timer expires, any
|
||||
host communication can make the timer restarted.
|
||||
|
||||
Access: Read, Write
|
||||
|
||||
Valid values:
|
||||
- 500, 1000, 5000, 30000, 40000, 80000, 128000 or 255000 (milliseconds),
|
||||
- 0: disabled
|
||||
|
||||
What: /sys/class/power_supply/rt9756-*/operation_mode
|
||||
Date: Dec 2025
|
||||
KernelVersion: 6.19
|
||||
Contact: ChiYuan Huang <cy_huang@richtek.com>
|
||||
Description:
|
||||
This entry shows and set the operation mode when rt9756 charger
|
||||
operates in charging phase. If 'bypass' mode is used, internal
|
||||
path will connect vbus directly to vbat. Else, default 'div2'
|
||||
mode for the switch-cap charging.
|
||||
|
||||
Access: Read, Write
|
||||
|
||||
Valid values:
|
||||
- 'bypass' or 'div2'
|
||||
19
Documentation/ABI/testing/sysfs-class-tsm
Normal file
19
Documentation/ABI/testing/sysfs-class-tsm
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
What: /sys/class/tsm/tsmN
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description:
|
||||
"tsmN" is a device that represents the generic attributes of a
|
||||
platform TEE Security Manager. It is typically a child of a
|
||||
platform enumerated TSM device. /sys/class/tsm/tsmN/uevent
|
||||
signals when the PCI layer is able to support establishment of
|
||||
link encryption and other device-security features coordinated
|
||||
through a platform tsm.
|
||||
|
||||
What: /sys/class/tsm/tsmN/streamH.R.E
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
Description:
|
||||
(RO) When a host bridge has established a secure connection via
|
||||
the platform TSM, symlink appears. The primary function of this
|
||||
is have a system global review of TSM resource consumption
|
||||
across host bridges. The link points to the endpoint PCI device
|
||||
and matches the same link published by the host bridge. See
|
||||
Documentation/ABI/testing/sysfs-devices-pci-host-bridge.
|
||||
|
|
@ -254,3 +254,31 @@ Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
|||
Description:
|
||||
The PPS Power Limited bit indicates whether or not the source
|
||||
supply will exceed the rated output power if requested.
|
||||
|
||||
Standard Power Range (SPR) Adjustable Voltage Supplies
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/<position>:spr_adjustable_voltage_supply
|
||||
Date: Oct 2025
|
||||
Contact: Badhri Jagan Sridharan <badhri@google.com>
|
||||
Description:
|
||||
Adjustable Voltage Supply (AVS) Augmented PDO (APDO).
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/<position>:spr_adjustable_voltage_supply/maximum_current_9V_to_15V
|
||||
Date: Oct 2025
|
||||
Contact: Badhri Jagan Sridharan <badhri@google.com>
|
||||
Description:
|
||||
Maximum Current for 9V to 15V range in milliamperes.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/<position>:spr_adjustable_voltage_supply/maximum_current_15V_to_20V
|
||||
Date: Oct 2025
|
||||
Contact: Badhri Jagan Sridharan <badhri@google.com>
|
||||
Description:
|
||||
Maximum Current for greater than 15V till 20V range in
|
||||
milliamperes.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../<capability>/<position>:spr_adjustable_voltage_supply/peak_current
|
||||
Date: Oct 2025
|
||||
Contact: Badhri Jagan Sridharan <badhri@google.com>
|
||||
Description:
|
||||
This file shows the value of the Adjustable Voltage Supply Peak Current
|
||||
Capability field.
|
||||
|
|
|
|||
45
Documentation/ABI/testing/sysfs-devices-pci-host-bridge
Normal file
45
Documentation/ABI/testing/sysfs-devices-pci-host-bridge
Normal file
|
|
@ -0,0 +1,45 @@
|
|||
What: /sys/devices/pciDDDD:BB
|
||||
/sys/devices/.../pciDDDD:BB
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
Description:
|
||||
A PCI host bridge device parents a PCI bus device topology. PCI
|
||||
controllers may also parent host bridges. The DDDD:BB format
|
||||
conveys the PCI domain (ACPI segment) number and root bus number
|
||||
(in hexadecimal) of the host bridge. Note that the domain number
|
||||
may be larger than the 16-bits that the "DDDD" format implies
|
||||
for emulated host-bridges.
|
||||
|
||||
What: pciDDDD:BB/firmware_node
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
Description:
|
||||
(RO) Symlink to the platform firmware device object "companion"
|
||||
of the host bridge. For example, an ACPI device with an _HID of
|
||||
PNP0A08 (/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00). See
|
||||
/sys/devices/pciDDDD:BB entry for details about the DDDD:BB
|
||||
format.
|
||||
|
||||
What: pciDDDD:BB/streamH.R.E
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
Description:
|
||||
(RO) When a platform has established a secure connection, PCIe
|
||||
IDE, between two Partner Ports, this symlink appears. A stream
|
||||
consumes a Stream ID slot in each of the Host bridge (H), Root
|
||||
Port (R) and Endpoint (E). The link points to the Endpoint PCI
|
||||
device in the Selective IDE Stream pairing. Specifically, "R"
|
||||
and "E" represent the assigned Selective IDE Stream Register
|
||||
Block in the Root Port and Endpoint, and "H" represents a
|
||||
platform specific pool of stream resources shared by the Root
|
||||
Ports in a host bridge. See /sys/devices/pciDDDD:BB entry for
|
||||
details about the DDDD:BB format.
|
||||
|
||||
What: pciDDDD:BB/available_secure_streams
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
Description:
|
||||
(RO) When a host bridge has Root Ports that support PCIe IDE
|
||||
(link encryption and integrity protection) there may be a
|
||||
limited number of Selective IDE Streams that can be used for
|
||||
establishing new end-to-end secure links. This attribute
|
||||
decrements upon secure link setup, and increments upon secure
|
||||
link teardown. The in-use stream count is determined by counting
|
||||
stream symlinks. See /sys/devices/pciDDDD:BB entry for details
|
||||
about the DDDD:BB format.
|
||||
|
|
@ -764,6 +764,17 @@ Description:
|
|||
participate in load balancing. These CPUs are set by
|
||||
boot parameter "isolcpus=".
|
||||
|
||||
What: /sys/devices/system/cpu/housekeeping
|
||||
Date: Oct 2025
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description:
|
||||
(RO) the list of logical CPUs that are designated by the kernel as
|
||||
"housekeeping". Each CPU are responsible for handling essential
|
||||
system-wide background tasks, including RCU callbacks, delayed
|
||||
timer callbacks, and unbound workqueues, minimizing scheduling
|
||||
jitter on low-latency, isolated CPUs. These CPUs are set when boot
|
||||
parameter "isolcpus=nohz" or "nohz_full=" is specified.
|
||||
|
||||
What: /sys/devices/system/cpu/crash_hotplug
|
||||
Date: Aug 2023
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
|
|
|
|||
29
Documentation/ABI/testing/sysfs-driver-uio_pci_sva-pasid
Normal file
29
Documentation/ABI/testing/sysfs-driver-uio_pci_sva-pasid
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
What: /sys/bus/pci/drivers/uio_pci_sva/<pci_dev>/pasid
|
||||
Date: September 2025
|
||||
Contact: Yaxing Guo <guoyaxing@bosc.ac.cn>
|
||||
Description:
|
||||
Process Address Space ID (PASID) assigned by IOMMU driver to
|
||||
the device for use with Shared Virtual Addressing (SVA).
|
||||
|
||||
This read-only attribute exposes the PASID (A 20-bit identifier
|
||||
used in PCIe Address Translation Services and iommu table walks)
|
||||
allocated by the IOMMU driver during sva device binding.
|
||||
|
||||
User-space UIO applications must read this attribute to obtain
|
||||
the PASID and program it into the device's configuration registers.
|
||||
This enables the device to perform DMA using user-space virtual
|
||||
address, with address translation handled by IOMMU.
|
||||
|
||||
UIO User-space applications must:
|
||||
- Opening device and Mapping the device's register space via /dev/uioX
|
||||
(This triggers the IOMMU driver to allocate the PASID)
|
||||
- Reading the PASID from sysfs
|
||||
- Writing the PASID to a device-specific register (with example offset)
|
||||
The code may be like:
|
||||
|
||||
map = mmap(..., "/dev/uio0", ...);
|
||||
|
||||
f = fopen("/sys/.../pasid", "r");
|
||||
fscanf(f, "%d", &pasid);
|
||||
|
||||
map[REG_PASID_OFFSET] = pasid;
|
||||
53
Documentation/ABI/testing/sysfs-driver-uniwill-laptop
Normal file
53
Documentation/ABI/testing/sysfs-driver-uniwill-laptop
Normal file
|
|
@ -0,0 +1,53 @@
|
|||
What: /sys/bus/platform/devices/INOU0000:XX/fn_lock_toggle_enable
|
||||
Date: November 2025
|
||||
KernelVersion: 6.19
|
||||
Contact: Armin Wolf <W_Armin@gmx.de>
|
||||
Description:
|
||||
Allows userspace applications to enable/disable the FN lock feature
|
||||
of the integrated keyboard by writing "1"/"0" into this file.
|
||||
|
||||
Reading this file returns the current enable status of the FN lock functionality.
|
||||
|
||||
What: /sys/bus/platform/devices/INOU0000:XX/super_key_toggle_enable
|
||||
Date: November 2025
|
||||
KernelVersion: 6.19
|
||||
Contact: Armin Wolf <W_Armin@gmx.de>
|
||||
Description:
|
||||
Allows userspace applications to enable/disable the super key functionality
|
||||
of the integrated keyboard by writing "1"/"0" into this file.
|
||||
|
||||
Reading this file returns the current enable status of the super key functionality.
|
||||
|
||||
What: /sys/bus/platform/devices/INOU0000:XX/touchpad_toggle_enable
|
||||
Date: November 2025
|
||||
KernelVersion: 6.19
|
||||
Contact: Armin Wolf <W_Armin@gmx.de>
|
||||
Description:
|
||||
Allows userspace applications to enable/disable the touchpad toggle functionality
|
||||
of the integrated touchpad by writing "1"/"0" into this file.
|
||||
|
||||
Reading this file returns the current enable status of the touchpad toggle
|
||||
functionality.
|
||||
|
||||
What: /sys/bus/platform/devices/INOU0000:XX/rainbow_animation
|
||||
Date: November 2025
|
||||
KernelVersion: 6.19
|
||||
Contact: Armin Wolf <W_Armin@gmx.de>
|
||||
Description:
|
||||
Forces the integrated lightbar to display a rainbow animation when the machine
|
||||
is not suspended. Writing "1"/"0" into this file enables/disables this
|
||||
functionality.
|
||||
|
||||
Reading this file returns the current status of the rainbow animation functionality.
|
||||
|
||||
What: /sys/bus/platform/devices/INOU0000:XX/breathing_in_suspend
|
||||
Date: November 2025
|
||||
KernelVersion: 6.19
|
||||
Contact: Armin Wolf <W_Armin@gmx.de>
|
||||
Description:
|
||||
Causes the integrated lightbar to display a breathing animation when the machine
|
||||
has been suspended and is running on AC power. Writing "1"/"0" into this file
|
||||
enables/disables this functionality.
|
||||
|
||||
Reading this file returns the current status of the breathing animation
|
||||
functionality.
|
||||
|
|
@ -643,6 +643,12 @@ Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
|
|||
Description: Shows the number of unusable blocks in a section which was defined by
|
||||
the zone capacity reported by underlying zoned device.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/max_open_zones
|
||||
Date: November 2025
|
||||
Contact: "Yongpeng Yang" <yangyongpeng@xiaomi.com>
|
||||
Description: Shows the max number of zones that F2FS can write concurrently when a zoned
|
||||
device is mounted.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/current_atomic_write
|
||||
Date: July 2022
|
||||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
|
|
|
|||
61
Documentation/ABI/testing/sysfs-kernel-kexec-kdump
Normal file
61
Documentation/ABI/testing/sysfs-kernel-kexec-kdump
Normal file
|
|
@ -0,0 +1,61 @@
|
|||
What: /sys/kernel/kexec/*
|
||||
Date: Nov 2025
|
||||
Contact: kexec@lists.infradead.org
|
||||
Description:
|
||||
The /sys/kernel/kexec/* directory contains sysfs files
|
||||
that provide information about the configuration status
|
||||
of kexec and kdump.
|
||||
|
||||
What: /sys/kernel/kexec/loaded
|
||||
Date: Nov 2025
|
||||
Contact: kexec@lists.infradead.org
|
||||
Description: read only
|
||||
Indicates whether a new kernel image has been loaded
|
||||
into memory using the kexec system call. It shows 1 if
|
||||
a kexec image is present and ready to boot, or 0 if none
|
||||
is loaded.
|
||||
User: kexec tools, kdump service
|
||||
|
||||
What: /sys/kernel/kexec/crash_loaded
|
||||
Date: Nov 2025
|
||||
Contact: kexec@lists.infradead.org
|
||||
Description: read only
|
||||
Indicates whether a crash (kdump) kernel is currently
|
||||
loaded into memory. It shows 1 if a crash kernel has been
|
||||
successfully loaded for panic handling, or 0 if no crash
|
||||
kernel is present.
|
||||
User: Kexec tools, Kdump service
|
||||
|
||||
What: /sys/kernel/kexec/crash_size
|
||||
Date: Nov 2025
|
||||
Contact: kexec@lists.infradead.org
|
||||
Description: read/write
|
||||
Shows the amount of memory reserved for loading the crash
|
||||
(kdump) kernel. It reports the size, in bytes, of the
|
||||
crash kernel area defined by the crashkernel= parameter.
|
||||
This interface also allows reducing the crashkernel
|
||||
reservation by writing a smaller value, and the reclaimed
|
||||
space is added back to the system RAM.
|
||||
User: Kdump service
|
||||
|
||||
What: /sys/kernel/kexec/crash_elfcorehdr_size
|
||||
Date: Nov 2025
|
||||
Contact: kexec@lists.infradead.org
|
||||
Description: read only
|
||||
Indicates the preferred size of the memory buffer for the
|
||||
ELF core header used by the crash (kdump) kernel. It defines
|
||||
how much space is needed to hold metadata about the crashed
|
||||
system, including CPU and memory information. This information
|
||||
is used by the user space utility kexec to support updating the
|
||||
in-kernel kdump image during hotplug operations.
|
||||
User: Kexec tools
|
||||
|
||||
What: /sys/kernel/kexec/crash_cma_ranges
|
||||
Date: Nov 2025
|
||||
Contact: kexec@lists.infradead.org
|
||||
Description: read only
|
||||
Provides information about the memory ranges reserved from
|
||||
the Contiguous Memory Allocator (CMA) area that are allocated
|
||||
to the crash (kdump) kernel. It lists the start and end physical
|
||||
addresses of CMA regions assigned for crashkernel use.
|
||||
User: kdump service
|
||||
|
|
@ -164,6 +164,13 @@ Description: Writing to and reading from this file sets and gets the pid of
|
|||
the target process if the context is for virtual address spaces
|
||||
monitoring, respectively.
|
||||
|
||||
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/targets/<T>/obsolete_target
|
||||
Date: Oct 2025
|
||||
Contact: SeongJae Park <sj@kernel.org>
|
||||
Description: Writing to and reading from this file sets and gets the
|
||||
obsoleteness of the matching parameters commit destination
|
||||
target.
|
||||
|
||||
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/targets/<T>/regions/nr_regions
|
||||
Date: Mar 2022
|
||||
Contact: SeongJae Park <sj@kernel.org>
|
||||
|
|
@ -303,6 +310,12 @@ Contact: SeongJae Park <sj@kernel.org>
|
|||
Description: Writing to and reading from this file sets and gets the nid
|
||||
parameter of the goal.
|
||||
|
||||
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/goals/<G>/path
|
||||
Date: Oct 2025
|
||||
Contact: SeongJae Park <sj@kernel.org>
|
||||
Description: Writing to and reading from this file sets and gets the path
|
||||
parameter of the goal.
|
||||
|
||||
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/weights/sz_permil
|
||||
Date: Mar 2022
|
||||
Contact: SeongJae Park <sj@kernel.org>
|
||||
|
|
|
|||
|
|
@ -63,6 +63,7 @@ Date: Aug 2022
|
|||
KernelVersion: 6.1
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
Switch the GPU hardware MUX mode. Laptops with this feature can
|
||||
can be toggled to boot with only the dGPU (discrete mode) or in
|
||||
standard Optimus/Hybrid mode. On switch a reboot is required:
|
||||
|
|
@ -75,6 +76,7 @@ Date: Aug 2022
|
|||
KernelVersion: 5.17
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
Disable discrete GPU:
|
||||
* 0 - Enable dGPU,
|
||||
* 1 - Disable dGPU
|
||||
|
|
@ -84,6 +86,7 @@ Date: Aug 2022
|
|||
KernelVersion: 5.17
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
Enable the external GPU paired with ROG X-Flow laptops.
|
||||
Toggling this setting will also trigger ACPI to disable the dGPU:
|
||||
|
||||
|
|
@ -95,6 +98,7 @@ Date: Aug 2022
|
|||
KernelVersion: 5.17
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
Enable an LCD response-time boost to reduce or remove ghosting:
|
||||
* 0 - Disable,
|
||||
* 1 - Enable
|
||||
|
|
@ -104,6 +108,7 @@ Date: Jun 2023
|
|||
KernelVersion: 6.5
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
Get the current charging mode being used:
|
||||
* 1 - Barrel connected charger,
|
||||
* 2 - USB-C charging
|
||||
|
|
@ -114,6 +119,7 @@ Date: Jun 2023
|
|||
KernelVersion: 6.5
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
Show if the egpu (XG Mobile) is correctly connected:
|
||||
* 0 - False,
|
||||
* 1 - True
|
||||
|
|
@ -123,6 +129,7 @@ Date: Jun 2023
|
|||
KernelVersion: 6.5
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
Change the mini-LED mode:
|
||||
* 0 - Single-zone,
|
||||
* 1 - Multi-zone
|
||||
|
|
@ -133,6 +140,7 @@ Date: Apr 2024
|
|||
KernelVersion: 6.10
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
List the available mini-led modes.
|
||||
|
||||
What: /sys/devices/platform/<platform>/ppt_pl1_spl
|
||||
|
|
@ -140,6 +148,7 @@ Date: Jun 2023
|
|||
KernelVersion: 6.5
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
Set the Package Power Target total of CPU: PL1 on Intel, SPL on AMD.
|
||||
Shown on Intel+Nvidia or AMD+Nvidia based systems:
|
||||
|
||||
|
|
@ -150,6 +159,7 @@ Date: Jun 2023
|
|||
KernelVersion: 6.5
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
Set the Slow Package Power Tracking Limit of CPU: PL2 on Intel, SPPT,
|
||||
on AMD. Shown on Intel+Nvidia or AMD+Nvidia based systems:
|
||||
|
||||
|
|
@ -160,6 +170,7 @@ Date: Jun 2023
|
|||
KernelVersion: 6.5
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
Set the Fast Package Power Tracking Limit of CPU. AMD+Nvidia only:
|
||||
* min=5, max=250
|
||||
|
||||
|
|
@ -168,6 +179,7 @@ Date: Jun 2023
|
|||
KernelVersion: 6.5
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
Set the APU SPPT limit. Shown on full AMD systems only:
|
||||
* min=5, max=130
|
||||
|
||||
|
|
@ -176,6 +188,7 @@ Date: Jun 2023
|
|||
KernelVersion: 6.5
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
Set the platform SPPT limit. Shown on full AMD systems only:
|
||||
* min=5, max=130
|
||||
|
||||
|
|
@ -184,6 +197,7 @@ Date: Jun 2023
|
|||
KernelVersion: 6.5
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
Set the dynamic boost limit of the Nvidia dGPU:
|
||||
* min=5, max=25
|
||||
|
||||
|
|
@ -192,6 +206,7 @@ Date: Jun 2023
|
|||
KernelVersion: 6.5
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
Set the target temperature limit of the Nvidia dGPU:
|
||||
* min=75, max=87
|
||||
|
||||
|
|
@ -200,6 +215,7 @@ Date: Apr 2024
|
|||
KernelVersion: 6.10
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
Set if the BIOS POST sound is played on boot.
|
||||
* 0 - False,
|
||||
* 1 - True
|
||||
|
|
@ -209,6 +225,7 @@ Date: Apr 2024
|
|||
KernelVersion: 6.10
|
||||
Contact: "Luke Jones" <luke@ljones.dev>
|
||||
Description:
|
||||
DEPRECATED, WILL BE REMOVED SOON: please use asus-armoury
|
||||
Set if the MCU can go in to low-power mode on system sleep
|
||||
* 0 - False,
|
||||
* 1 - True
|
||||
|
|
|
|||
19
Documentation/ABI/testing/sysfs-platform-ayaneo-ec
Normal file
19
Documentation/ABI/testing/sysfs-platform-ayaneo-ec
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
What: /sys/devices/platform/ayaneo-ec/controller_power
|
||||
Date: Nov 2025
|
||||
KernelVersion: 6.19
|
||||
Contact: "Antheas Kapenekakis" <lkml@antheas.dev>
|
||||
Description:
|
||||
Current controller power state. Allows turning on and off
|
||||
the controller power (e.g. for power savings). Write 1 to
|
||||
turn on, 0 to turn off. File is readable and writable.
|
||||
|
||||
What: /sys/devices/platform/ayaneo-ec/controller_modules
|
||||
Date: Nov 2025
|
||||
KernelVersion: 6.19
|
||||
Contact: "Antheas Kapenekakis" <lkml@antheas.dev>
|
||||
Description:
|
||||
Shows which controller modules are currently connected to
|
||||
the device. Possible values are "left", "right" and "both".
|
||||
File is read-only. The Windows software for this device
|
||||
will only set controller power to 1 if both module sides
|
||||
are connected (i.e. this file returns "both").
|
||||
|
|
@ -326,6 +326,21 @@ be recovered, there is nothing more that can be done; the platform
|
|||
will typically report a "permanent failure" in such a case. The
|
||||
device will be considered "dead" in this case.
|
||||
|
||||
Drivers typically need to call pci_restore_state() after reset to
|
||||
re-initialize the device's config space registers and thereby
|
||||
bring it from D0\ :sub:`uninitialized` into D0\ :sub:`active` state
|
||||
(PCIe r7.0 sec 5.3.1.1). The PCI core invokes pci_save_state()
|
||||
on enumeration after initializing config space to ensure that a
|
||||
saved state is available for subsequent error recovery.
|
||||
Drivers which modify config space on probe may need to invoke
|
||||
pci_save_state() afterwards to record those changes for later
|
||||
error recovery. When going into system suspend, pci_save_state()
|
||||
is called for every PCI device and that state will be restored
|
||||
not only on resume, but also on any subsequent error recovery.
|
||||
In the unlikely event that the saved state recorded on suspend
|
||||
is unsuitable for error recovery, drivers should call
|
||||
pci_save_state() on resume.
|
||||
|
||||
Drivers for multi-function cards will need to coordinate among
|
||||
themselves as to which driver instance will perform any "one-shot"
|
||||
or global device initialization. For example, the Symbios sym53cxx2
|
||||
|
|
|
|||
|
|
@ -134,7 +134,7 @@ MB and a zone capacity of 63 MB::
|
|||
|
||||
$ modprobe zloop
|
||||
$ mkdir -p /var/local/zloop/0
|
||||
$ echo "add capacity_mb=2048,zone_size_mb=64,zone_capacity=63MB" > /dev/zloop-control
|
||||
$ echo "add capacity_mb=2048,zone_size_mb=64,zone_capacity_mb=63" > /dev/zloop-control
|
||||
|
||||
For the device created (/dev/zloop0), the zone backing files are all created
|
||||
under the default base directory (/var/local/zloop)::
|
||||
|
|
|
|||
|
|
@ -1513,6 +1513,10 @@ The following nested keys are defined.
|
|||
oom_group_kill
|
||||
The number of times a group OOM has occurred.
|
||||
|
||||
sock_throttled
|
||||
The number of times network sockets associated with
|
||||
this cgroup are throttled.
|
||||
|
||||
memory.events.local
|
||||
Similar to memory.events but the fields in the file are local
|
||||
to the cgroup i.e. not hierarchical. The file modified event
|
||||
|
|
|
|||
|
|
@ -20,10 +20,10 @@ The target is named "raid" and it accepts the following parameters::
|
|||
raid0 RAID0 striping (no resilience)
|
||||
raid1 RAID1 mirroring
|
||||
raid4 RAID4 with dedicated last parity disk
|
||||
raid5_n RAID5 with dedicated last parity disk supporting takeover
|
||||
raid5_n RAID5 with dedicated last parity disk supporting takeover from/to raid1
|
||||
Same as raid4
|
||||
|
||||
- Transitory layout
|
||||
- Transitory layout for takeover from/to raid1
|
||||
raid5_la RAID5 left asymmetric
|
||||
|
||||
- rotating parity 0 with data continuation
|
||||
|
|
@ -48,8 +48,8 @@ The target is named "raid" and it accepts the following parameters::
|
|||
raid6_n_6 RAID6 with dedicate parity disks
|
||||
|
||||
- parity and Q-syndrome on the last 2 disks;
|
||||
layout for takeover from/to raid4/raid5_n
|
||||
raid6_la_6 Same as "raid_la" plus dedicated last Q-syndrome disk
|
||||
layout for takeover from/to raid0/raid4/raid5_n
|
||||
raid6_la_6 Same as "raid_la" plus dedicated last Q-syndrome disk supporting takeover from/to raid5
|
||||
|
||||
- layout for takeover from raid5_la from/to raid6
|
||||
raid6_ra_6 Same as "raid5_ra" dedicated last Q-syndrome disk
|
||||
|
|
@ -173,9 +173,9 @@ The target is named "raid" and it accepts the following parameters::
|
|||
The delta_disks option value (-251 < N < +251) triggers
|
||||
device removal (negative value) or device addition (positive
|
||||
value) to any reshape supporting raid levels 4/5/6 and 10.
|
||||
RAID levels 4/5/6 allow for addition of devices (metadata
|
||||
and data device tuple), raid10_near and raid10_offset only
|
||||
allow for device addition. raid10_far does not support any
|
||||
RAID levels 4/5/6 allow for addition and removal of devices
|
||||
(metadata and data device tuple), raid10_near and raid10_offset
|
||||
only allow for device addition. raid10_far does not support any
|
||||
reshaping at all.
|
||||
A minimum of devices have to be kept to enforce resilience,
|
||||
which is 3 devices for raid4/5 and 4 devices for raid6.
|
||||
|
|
@ -372,6 +372,72 @@ to safely enable discard support for RAID 4/5/6:
|
|||
'devices_handle_discards_safely'
|
||||
|
||||
|
||||
Takeover/Reshape Support
|
||||
------------------------
|
||||
The target natively supports these two types of MDRAID conversions:
|
||||
|
||||
o Takeover: Converts an array from one RAID level to another
|
||||
|
||||
o Reshape: Changes the internal layout while maintaining the current RAID level
|
||||
|
||||
Each operation is only valid under specific constraints imposed by the existing array's layout and configuration.
|
||||
|
||||
|
||||
Takeover:
|
||||
linear -> raid1 with N >= 2 mirrors
|
||||
raid0 -> raid4 (add dedicated parity device)
|
||||
raid0 -> raid5 (add dedicated parity device)
|
||||
raid0 -> raid10 with near layout and N >= 2 mirror groups (raid0 stripes have to become first member within mirror groups)
|
||||
raid1 -> linear
|
||||
raid1 -> raid5 with 2 mirrors
|
||||
raid4 -> raid5 w/ rotating parity
|
||||
raid5 with dedicated parity device -> raid4
|
||||
raid5 -> raid6 (with dedicated Q-syndrome)
|
||||
raid6 (with dedicated Q-syndrome) -> raid5
|
||||
raid10 with near layout and even number of disks -> raid0 (select any in-sync device from each mirror group)
|
||||
|
||||
Reshape:
|
||||
linear: not possible
|
||||
raid0: not possible
|
||||
raid1: change number of mirrors
|
||||
raid4: add and remove stripes (minimum 3), change stripesize
|
||||
raid5: add and remove stripes (minimum 3, special case 2 for raid1 takeover), change rotating parity algorithms, change stripesize
|
||||
raid6: add and remove stripes (minimum 4), change rotating syndrome algorithms, change stripesize
|
||||
raid10 near: add stripes (minimum 4), change stripesize, no stripe removal possible, change to offset layout
|
||||
raid10 offset: add stripes, change stripesize, no stripe removal possible, change to near layout
|
||||
raid10 far: not possible
|
||||
|
||||
Table line examples:
|
||||
|
||||
### raid1 -> raid5
|
||||
#
|
||||
# 2 devices limitation in raid1.
|
||||
# raid5 personality is able to just map 2 like raid1.
|
||||
# Reshape after takeover to change to full raid5 layout
|
||||
|
||||
0 1960886272 raid raid1 3 0 region_size 2048 2 /dev/dm-0 /dev/dm-1 /dev/dm-2 /dev/dm-3
|
||||
|
||||
# dm-0 and dm-2 are e.g. 4MiB large metadata devices, dm-1 and dm-3 have to be at least 1960886272 big.
|
||||
#
|
||||
# Table line to takeover to raid5
|
||||
|
||||
0 1960886272 raid raid5 3 0 region_size 2048 2 /dev/dm-0 /dev/dm-1 /dev/dm-2 /dev/dm-3
|
||||
|
||||
# Add required out-of-place reshape space to the beginniong of the given 2 data devices,
|
||||
# allocate another metadata/data device tuple with the same sizes for the parity space
|
||||
# and zero the first 4K of the metadata device.
|
||||
#
|
||||
# Example table of the out-of-place reshape space addition for one data device, e.g. dm-1
|
||||
|
||||
0 8192 linear 8:0 0 1960903888 # <- must be free space segment
|
||||
8192 1960886272 linear 8:0 0 2048 # previous data segment
|
||||
|
||||
# Mapping table for e.g. raid5_rs reshape causing the size of the raid device to double-fold once the reshape finishes.
|
||||
# Check the status output (e.g. "dmsetup status $RaidDev") for progess.
|
||||
|
||||
0 $((2 * 1960886272)) raid raid5 7 0 region_size 2048 data_offset 8192 delta_disk 1 2 /dev/dm-0 /dev/dm-1 /dev/dm-2 /dev/dm-3
|
||||
|
||||
|
||||
Version History
|
||||
---------------
|
||||
|
||||
|
|
|
|||
|
|
@ -236,8 +236,10 @@ is available at the cryptsetup project's wiki page
|
|||
|
||||
Status
|
||||
======
|
||||
V (for Valid) is returned if every check performed so far was valid.
|
||||
If any check failed, C (for Corruption) is returned.
|
||||
1. V (for Valid) is returned if every check performed so far was valid.
|
||||
If any check failed, C (for Corruption) is returned.
|
||||
2. Number of corrected blocks by Forward Error Correction.
|
||||
'-' if Forward Error Correction is not enabled.
|
||||
|
||||
Example
|
||||
=======
|
||||
|
|
|
|||
|
|
@ -223,12 +223,13 @@ The flags are::
|
|||
f Include the function name
|
||||
s Include the source file name
|
||||
l Include line number
|
||||
d Include call trace
|
||||
|
||||
For ``print_hex_dump_debug()`` and ``print_hex_dump_bytes()``, only
|
||||
the ``p`` flag has meaning, other flags are ignored.
|
||||
|
||||
Note the regexp ``^[-+=][fslmpt_]+$`` matches a flags specification.
|
||||
To clear all flags at once, use ``=_`` or ``-fslmpt``.
|
||||
Note the regexp ``^[-+=][fslmptd_]+$`` matches a flags specification.
|
||||
To clear all flags at once, use ``=_`` or ``-fslmptd``.
|
||||
|
||||
|
||||
Debug messages during Boot Process
|
||||
|
|
|
|||
|
|
@ -767,6 +767,14 @@ Kernel parameters
|
|||
nokmem -- Disable kernel memory accounting.
|
||||
nobpf -- Disable BPF memory accounting.
|
||||
|
||||
check_pages= [MM,EARLY] Enable sanity checking of pages after
|
||||
allocations / before freeing. This adds checks to catch
|
||||
double-frees, use-after-frees, and other sources of
|
||||
page corruption by inspecting page internals (flags,
|
||||
mapcount/refcount, memcg_data, etc.).
|
||||
Format: { "0" | "1" }
|
||||
Default: 0 (1 if CONFIG_DEBUG_VM is set)
|
||||
|
||||
checkreqprot= [SELINUX] Set initial checkreqprot flag value.
|
||||
Format: { "0" | "1" }
|
||||
See security/selinux/Kconfig help text.
|
||||
|
|
@ -1111,7 +1119,7 @@ Kernel parameters
|
|||
It will be ignored when crashkernel=X,high is not used
|
||||
or memory reserved is below 4G.
|
||||
crashkernel=size[KMG],cma
|
||||
[KNL, X86] Reserve additional crash kernel memory from
|
||||
[KNL, X86, ppc] Reserve additional crash kernel memory from
|
||||
CMA. This reservation is usable by the first system's
|
||||
userspace memory and kernel movable allocations (memory
|
||||
balloon, zswap). Pages allocated from this memory range
|
||||
|
|
@ -1211,12 +1219,8 @@ Kernel parameters
|
|||
|
||||
debugfs= [KNL,EARLY] This parameter enables what is exposed to
|
||||
userspace and debugfs internal clients.
|
||||
Format: { on, no-mount, off }
|
||||
Format: { on, off }
|
||||
on: All functions are enabled.
|
||||
no-mount:
|
||||
Filesystem is not registered but kernel clients can
|
||||
access APIs and a crashkernel can be used to read
|
||||
its content. There is nothing to mount.
|
||||
off: Filesystem is not registered and clients
|
||||
get a -EPERM as result when trying to register files
|
||||
or directories within debugfs.
|
||||
|
|
@ -2118,14 +2122,20 @@ Kernel parameters
|
|||
the added memory block itself do not be affected.
|
||||
|
||||
hung_task_panic=
|
||||
[KNL] Should the hung task detector generate panics.
|
||||
Format: 0 | 1
|
||||
[KNL] Number of hung tasks to trigger kernel panic.
|
||||
Format: <int>
|
||||
|
||||
A value of 1 instructs the kernel to panic when a
|
||||
hung task is detected. The default value is controlled
|
||||
by the CONFIG_BOOTPARAM_HUNG_TASK_PANIC build-time
|
||||
option. The value selected by this boot parameter can
|
||||
be changed later by the kernel.hung_task_panic sysctl.
|
||||
When set to a non-zero value, a kernel panic will be triggered if
|
||||
the number of detected hung tasks reaches this value.
|
||||
|
||||
0: don't panic
|
||||
1: panic immediately on first hung task
|
||||
N: panic after N hung tasks are detected in a single scan
|
||||
|
||||
The default value is controlled by the
|
||||
CONFIG_BOOTPARAM_HUNG_TASK_PANIC build-time option. The value
|
||||
selected by this boot parameter can be changed later by the
|
||||
kernel.hung_task_panic sysctl.
|
||||
|
||||
hvc_iucv= [S390] Number of z/VM IUCV hypervisor console (HVC)
|
||||
terminal devices. Valid values: 0..8
|
||||
|
|
@ -7304,6 +7314,9 @@ Kernel parameters
|
|||
them frequently to increase the rate of SLB faults
|
||||
on kernel addresses.
|
||||
|
||||
no_slb_preload [PPC,EARLY]
|
||||
Disables slb preloading for userspace.
|
||||
|
||||
sunrpc.min_resvport=
|
||||
sunrpc.max_resvport=
|
||||
[NFS,SUNRPC]
|
||||
|
|
|
|||
|
|
@ -17,3 +17,4 @@ Laptop Drivers
|
|||
sonypi
|
||||
thinkpad-acpi
|
||||
toshiba_haps
|
||||
uniwill-laptop
|
||||
|
|
|
|||
60
Documentation/admin-guide/laptops/uniwill-laptop.rst
Normal file
60
Documentation/admin-guide/laptops/uniwill-laptop.rst
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
|
||||
Uniwill laptop extra features
|
||||
=============================
|
||||
|
||||
On laptops manufactured by Uniwill (either directly or as ODM), the ``uniwill-laptop`` driver
|
||||
handles various platform-specific features.
|
||||
|
||||
Module Loading
|
||||
--------------
|
||||
|
||||
The ``uniwill-laptop`` driver relies on a DMI table to automatically load on supported devices.
|
||||
When using the ``force`` module parameter, this DMI check will be omitted, allowing the driver
|
||||
to be loaded on unsupported devices for testing purposes.
|
||||
|
||||
Hotkeys
|
||||
-------
|
||||
|
||||
Usually the FN keys work without a special driver. However as soon as the ``uniwill-laptop`` driver
|
||||
is loaded, the FN keys need to be handled manually. This is done automatically by the driver itself.
|
||||
|
||||
Keyboard settings
|
||||
-----------------
|
||||
|
||||
The ``uniwill-laptop`` driver allows the user to enable/disable:
|
||||
|
||||
- the FN and super key lock functionality of the integrated keyboard
|
||||
- the touchpad toggle functionality of the integrated touchpad
|
||||
|
||||
See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details.
|
||||
|
||||
Hwmon interface
|
||||
---------------
|
||||
|
||||
The ``uniwill-laptop`` driver supports reading of the CPU and GPU temperature and supports up to
|
||||
two fans. Userspace applications can access sensor readings over the hwmon sysfs interface.
|
||||
|
||||
Platform profile
|
||||
----------------
|
||||
|
||||
Support for changing the platform performance mode is currently not implemented.
|
||||
|
||||
Battery Charging Control
|
||||
------------------------
|
||||
|
||||
The ``uniwill-laptop`` driver supports controlling the battery charge limit. This happens over
|
||||
the standard ``charge_control_end_threshold`` power supply sysfs attribute. All values
|
||||
between 1 and 100 percent are supported.
|
||||
|
||||
Additionally the driver signals the presence of battery charging issues through the standard
|
||||
``health`` power supply sysfs attribute.
|
||||
|
||||
Lightbar
|
||||
--------
|
||||
|
||||
The ``uniwill-laptop`` driver exposes the lightbar found on some models as a standard multicolor
|
||||
LED class device. The default name of this LED class device is ``uniwill:multicolor:status``.
|
||||
|
||||
See Documentation/ABI/testing/sysfs-driver-uniwill-laptop for details on how to control the various
|
||||
animation modes of the lightbar.
|
||||
|
|
@ -211,6 +211,28 @@ End of target memory region in physical address.
|
|||
The end physical address of memory region that DAMON_LRU_SORT will do work
|
||||
against. By default, biggest System RAM is used as the region.
|
||||
|
||||
addr_unit
|
||||
---------
|
||||
|
||||
A scale factor for memory addresses and bytes.
|
||||
|
||||
This parameter is for setting and getting the :ref:`address unit
|
||||
<damon_design_addr_unit>` parameter of the DAMON instance for DAMON_RECLAIM.
|
||||
|
||||
``monitor_region_start`` and ``monitor_region_end`` should be provided in this
|
||||
unit. For example, let's suppose ``addr_unit``, ``monitor_region_start`` and
|
||||
``monitor_region_end`` are set as ``1024``, ``0`` and ``10``, respectively.
|
||||
Then DAMON_LRU_SORT will work for 10 KiB length of physical address range that
|
||||
starts from address zero (``[0 * 1024, 10 * 1024)`` in bytes).
|
||||
|
||||
Stat parameters having ``bytes_`` prefix are also in this unit. For example,
|
||||
let's suppose values of ``addr_unit``, ``bytes_lru_sort_tried_hot_regions`` and
|
||||
``bytes_lru_sorted_hot_regions`` are ``1024``, ``42``, and ``32``,
|
||||
respectively. Then it means DAMON_LRU_SORT tried to LRU-sort 42 KiB of hot
|
||||
memory and successfully LRU-sorted 32 KiB of the memory in total.
|
||||
|
||||
If unsure, use only the default value (``1``) and forget about this.
|
||||
|
||||
kdamond_pid
|
||||
-----------
|
||||
|
||||
|
|
|
|||
|
|
@ -232,6 +232,28 @@ The end physical address of memory region that DAMON_RECLAIM will do work
|
|||
against. That is, DAMON_RECLAIM will find cold memory regions in this region
|
||||
and reclaims. By default, biggest System RAM is used as the region.
|
||||
|
||||
addr_unit
|
||||
---------
|
||||
|
||||
A scale factor for memory addresses and bytes.
|
||||
|
||||
This parameter is for setting and getting the :ref:`address unit
|
||||
<damon_design_addr_unit>` parameter of the DAMON instance for DAMON_RECLAIM.
|
||||
|
||||
``monitor_region_start`` and ``monitor_region_end`` should be provided in this
|
||||
unit. For example, let's suppose ``addr_unit``, ``monitor_region_start`` and
|
||||
``monitor_region_end`` are set as ``1024``, ``0`` and ``10``, respectively.
|
||||
Then DAMON_RECLAIM will work for 10 KiB length of physical address range that
|
||||
starts from address zero (``[0 * 1024, 10 * 1024)`` in bytes).
|
||||
|
||||
``bytes_reclaim_tried_regions`` and ``bytes_reclaimed_regions`` are also in
|
||||
this unit. For example, let's suppose values of ``addr_unit``,
|
||||
``bytes_reclaim_tried_regions`` and ``bytes_reclaimed_regions`` are ``1024``,
|
||||
``42``, and ``32``, respectively. Then it means DAMON_RECLAIM tried to reclaim
|
||||
42 KiB memory and successfully reclaimed 32 KiB memory in total.
|
||||
|
||||
If unsure, use only the default value (``1``) and forget about this.
|
||||
|
||||
skip_anon
|
||||
---------
|
||||
|
||||
|
|
|
|||
|
|
@ -10,6 +10,8 @@ on the system's entire physical memory using DAMON, and provides simplified
|
|||
access monitoring results statistics, namely idle time percentiles and
|
||||
estimated memory bandwidth.
|
||||
|
||||
.. _damon_stat_monitoring_accuracy_overhead:
|
||||
|
||||
Monitoring Accuracy and Overhead
|
||||
================================
|
||||
|
||||
|
|
@ -17,9 +19,11 @@ DAMON_STAT uses monitoring intervals :ref:`auto-tuning
|
|||
<damon_design_monitoring_intervals_autotuning>` to make its accuracy high and
|
||||
overhead minimum. It auto-tunes the intervals aiming 4 % of observable access
|
||||
events to be captured in each snapshot, while limiting the resulting sampling
|
||||
events to be 5 milliseconds in minimum and 10 seconds in maximum. On a few
|
||||
interval to be 5 milliseconds in minimum and 10 seconds in maximum. On a few
|
||||
production server systems, it resulted in consuming only 0.x % single CPU time,
|
||||
while capturing reasonable quality of access patterns.
|
||||
while capturing reasonable quality of access patterns. The tuning-resulting
|
||||
intervals can be retrieved via ``aggr_interval_us`` :ref:`parameter
|
||||
<damon_stat_aggr_interval_us>`.
|
||||
|
||||
Interface: Module Parameters
|
||||
============================
|
||||
|
|
@ -41,6 +45,18 @@ You can enable DAMON_STAT by setting the value of this parameter as ``Y``.
|
|||
Setting it as ``N`` disables DAMON_STAT. The default value is set by
|
||||
``CONFIG_DAMON_STAT_ENABLED_DEFAULT`` build config option.
|
||||
|
||||
.. _damon_stat_aggr_interval_us:
|
||||
|
||||
aggr_interval_us
|
||||
----------------
|
||||
|
||||
Auto-tuned aggregation time interval in microseconds.
|
||||
|
||||
Users can read the aggregation interval of DAMON that is being used by the
|
||||
DAMON instance for DAMON_STAT. It is :ref:`auto-tuned
|
||||
<damon_stat_monitoring_accuracy_overhead>` and therefore the value is
|
||||
dynamically changed.
|
||||
|
||||
estimated_memory_bandwidth
|
||||
--------------------------
|
||||
|
||||
|
|
@ -58,12 +74,13 @@ memory_idle_ms_percentiles
|
|||
Per-byte idle time (milliseconds) percentiles of the system.
|
||||
|
||||
DAMON_STAT calculates how long each byte of the memory was not accessed until
|
||||
now (idle time), based on the current DAMON results snapshot. If DAMON found a
|
||||
region of access frequency (nr_accesses) larger than zero, every byte of the
|
||||
region gets zero idle time. If a region has zero access frequency
|
||||
(nr_accesses), how long the region was keeping the zero access frequency (age)
|
||||
becomes the idle time of every byte of the region. Then, DAMON_STAT exposes
|
||||
the percentiles of the idle time values via this read-only parameter. Reading
|
||||
the parameter returns 101 idle time values in milliseconds, separated by comma.
|
||||
now (idle time), based on the current DAMON results snapshot. For regions
|
||||
having access frequency (nr_accesses) larger than zero, how long the current
|
||||
access frequency level was kept multiplied by ``-1`` becomes the idlee time of
|
||||
every byte of the region. If a region has zero access frequency (nr_accesses),
|
||||
how long the region was keeping the zero access frequency (age) becomes the
|
||||
idle time of every byte of the region. Then, DAMON_STAT exposes the
|
||||
percentiles of the idle time values via this read-only parameter. Reading the
|
||||
parameter returns 101 idle time values in milliseconds, separated by comma.
|
||||
Each value represents 0-th, 1st, 2nd, 3rd, ..., 99th and 100th percentile idle
|
||||
times.
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ comma (",").
|
|||
│ │ │ │ │ │ │ intervals_goal/access_bp,aggrs,min_sample_us,max_sample_us
|
||||
│ │ │ │ │ │ nr_regions/min,max
|
||||
│ │ │ │ │ :ref:`targets <sysfs_targets>`/nr_targets
|
||||
│ │ │ │ │ │ :ref:`0 <sysfs_target>`/pid_target
|
||||
│ │ │ │ │ │ :ref:`0 <sysfs_target>`/pid_target,obsolete_target
|
||||
│ │ │ │ │ │ │ :ref:`regions <sysfs_regions>`/nr_regions
|
||||
│ │ │ │ │ │ │ │ :ref:`0 <sysfs_region>`/start,end
|
||||
│ │ │ │ │ │ │ │ ...
|
||||
|
|
@ -81,7 +81,7 @@ comma (",").
|
|||
│ │ │ │ │ │ │ :ref:`quotas <sysfs_quotas>`/ms,bytes,reset_interval_ms,effective_bytes
|
||||
│ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil
|
||||
│ │ │ │ │ │ │ │ :ref:`goals <sysfs_schemes_quota_goals>`/nr_goals
|
||||
│ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value,nid
|
||||
│ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value,nid,path
|
||||
│ │ │ │ │ │ │ :ref:`watermarks <sysfs_watermarks>`/metric,interval_us,high,mid,low
|
||||
│ │ │ │ │ │ │ :ref:`{core_,ops_,}filters <sysfs_filters>`/nr_filters
|
||||
│ │ │ │ │ │ │ │ 0/type,matching,allow,memcg_path,addr_start,addr_end,target_idx,min,max
|
||||
|
|
@ -134,7 +134,8 @@ Users can write below commands for the kdamond to the ``state`` file.
|
|||
- ``on``: Start running.
|
||||
- ``off``: Stop running.
|
||||
- ``commit``: Read the user inputs in the sysfs files except ``state`` file
|
||||
again.
|
||||
again. Monitoring :ref:`target region <sysfs_regions>` inputs are also be
|
||||
ignored if no target region is specified.
|
||||
- ``update_tuned_intervals``: Update the contents of ``sample_us`` and
|
||||
``aggr_us`` files of the kdamond with the auto-tuning applied ``sampling
|
||||
interval`` and ``aggregation interval`` for the files. Please refer to
|
||||
|
|
@ -264,13 +265,20 @@ to ``N-1``. Each directory represents each monitoring target.
|
|||
targets/<N>/
|
||||
------------
|
||||
|
||||
In each target directory, one file (``pid_target``) and one directory
|
||||
(``regions``) exist.
|
||||
In each target directory, two files (``pid_target`` and ``obsolete_target``)
|
||||
and one directory (``regions``) exist.
|
||||
|
||||
If you wrote ``vaddr`` to the ``contexts/<N>/operations``, each target should
|
||||
be a process. You can specify the process to DAMON by writing the pid of the
|
||||
process to the ``pid_target`` file.
|
||||
|
||||
Users can selectively remove targets in the middle of the targets array by
|
||||
writing non-zero value to ``obsolete_target`` file and committing it (writing
|
||||
``commit`` to ``state`` file). DAMON will remove the matching targets from its
|
||||
internal targets array. Users are responsible to construct target directories
|
||||
again, so that those correctly represent the changed internal targets array.
|
||||
|
||||
|
||||
.. _sysfs_regions:
|
||||
|
||||
targets/<N>/regions
|
||||
|
|
@ -289,6 +297,11 @@ In the beginning, this directory has only one file, ``nr_regions``. Writing a
|
|||
number (``N``) to the file creates the number of child directories named ``0``
|
||||
to ``N-1``. Each directory represents each initial monitoring target region.
|
||||
|
||||
If ``nr_regions`` is zero when committing new DAMON parameters online (writing
|
||||
``commit`` to ``state`` file of :ref:`kdamond <sysfs_kdamond>`), the commit
|
||||
logic ignores the target regions. In other words, the current monitoring
|
||||
results for the target are preserved.
|
||||
|
||||
.. _sysfs_region:
|
||||
|
||||
regions/<N>/
|
||||
|
|
@ -402,9 +415,9 @@ number (``N``) to the file creates the number of child directories named ``0``
|
|||
to ``N-1``. Each directory represents each goal and current achievement.
|
||||
Among the multiple feedback, the best one is used.
|
||||
|
||||
Each goal directory contains four files, namely ``target_metric``,
|
||||
``target_value``, ``current_value`` and ``nid``. Users can set and get the
|
||||
four parameters for the quota auto-tuning goals that specified on the
|
||||
Each goal directory contains five files, namely ``target_metric``,
|
||||
``target_value``, ``current_value`` ``nid`` and ``path``. Users can set and
|
||||
get the five parameters for the quota auto-tuning goals that specified on the
|
||||
:ref:`design doc <damon_design_damos_quotas_auto_tuning>` by writing to and
|
||||
reading from each of the files. Note that users should further write
|
||||
``commit_schemes_quota_goals`` to the ``state`` file of the :ref:`kdamond
|
||||
|
|
|
|||
|
|
@ -39,7 +39,6 @@ the Linux memory management.
|
|||
shrinker_debugfs
|
||||
slab
|
||||
soft-dirty
|
||||
swap_numa
|
||||
transhuge
|
||||
userfaultfd
|
||||
zswap
|
||||
|
|
|
|||
|
|
@ -115,7 +115,8 @@ Short descriptions to the page flags
|
|||
A free memory block managed by the buddy system allocator.
|
||||
The buddy system organizes free memory in blocks of various orders.
|
||||
An order N block has 2^N physically contiguous pages, with the BUDDY flag
|
||||
set for and _only_ for the first page.
|
||||
set for all pages.
|
||||
Before 4.6 only the first page of the block had the flag set.
|
||||
15 - COMPOUND_HEAD
|
||||
A compound page with order N consists of 2^N physically contiguous pages.
|
||||
A compound page with order 2 takes the form of "HTTT", where H donates its
|
||||
|
|
|
|||
|
|
@ -1,78 +0,0 @@
|
|||
===========================================
|
||||
Automatically bind swap device to numa node
|
||||
===========================================
|
||||
|
||||
If the system has more than one swap device and swap device has the node
|
||||
information, we can make use of this information to decide which swap
|
||||
device to use in get_swap_pages() to get better performance.
|
||||
|
||||
|
||||
How to use this feature
|
||||
=======================
|
||||
|
||||
Swap device has priority and that decides the order of it to be used. To make
|
||||
use of automatically binding, there is no need to manipulate priority settings
|
||||
for swap devices. e.g. on a 2 node machine, assume 2 swap devices swapA and
|
||||
swapB, with swapA attached to node 0 and swapB attached to node 1, are going
|
||||
to be swapped on. Simply swapping them on by doing::
|
||||
|
||||
# swapon /dev/swapA
|
||||
# swapon /dev/swapB
|
||||
|
||||
Then node 0 will use the two swap devices in the order of swapA then swapB and
|
||||
node 1 will use the two swap devices in the order of swapB then swapA. Note
|
||||
that the order of them being swapped on doesn't matter.
|
||||
|
||||
A more complex example on a 4 node machine. Assume 6 swap devices are going to
|
||||
be swapped on: swapA and swapB are attached to node 0, swapC is attached to
|
||||
node 1, swapD and swapE are attached to node 2 and swapF is attached to node3.
|
||||
The way to swap them on is the same as above::
|
||||
|
||||
# swapon /dev/swapA
|
||||
# swapon /dev/swapB
|
||||
# swapon /dev/swapC
|
||||
# swapon /dev/swapD
|
||||
# swapon /dev/swapE
|
||||
# swapon /dev/swapF
|
||||
|
||||
Then node 0 will use them in the order of::
|
||||
|
||||
swapA/swapB -> swapC -> swapD -> swapE -> swapF
|
||||
|
||||
swapA and swapB will be used in a round robin mode before any other swap device.
|
||||
|
||||
node 1 will use them in the order of::
|
||||
|
||||
swapC -> swapA -> swapB -> swapD -> swapE -> swapF
|
||||
|
||||
node 2 will use them in the order of::
|
||||
|
||||
swapD/swapE -> swapA -> swapB -> swapC -> swapF
|
||||
|
||||
Similaly, swapD and swapE will be used in a round robin mode before any
|
||||
other swap devices.
|
||||
|
||||
node 3 will use them in the order of::
|
||||
|
||||
swapF -> swapA -> swapB -> swapC -> swapD -> swapE
|
||||
|
||||
|
||||
Implementation details
|
||||
======================
|
||||
|
||||
The current code uses a priority based list, swap_avail_list, to decide
|
||||
which swap device to use and if multiple swap devices share the same
|
||||
priority, they are used round robin. This change here replaces the single
|
||||
global swap_avail_list with a per-numa-node list, i.e. for each numa node,
|
||||
it sees its own priority based list of available swap devices. Swap
|
||||
device's priority can be promoted on its matching node's swap_avail_list.
|
||||
|
||||
The current swap device's priority is set as: user can set a >=0 value,
|
||||
or the system will pick one starting from -1 then downwards. The priority
|
||||
value in the swap_avail_list is the negated value of the swap device's
|
||||
due to plist being sorted from low to high. The new policy doesn't change
|
||||
the semantics for priority >=0 cases, the previous starting from -1 then
|
||||
downwards now becomes starting from -2 then downwards and -1 is reserved
|
||||
as the promoted value. So if multiple swap devices are attached to the same
|
||||
node, they will all be promoted to priority -1 on that node's plist and will
|
||||
be used round robin before any other swap devices.
|
||||
|
|
@ -381,6 +381,11 @@ hugepage allocation policy for the tmpfs mount by using the kernel parameter
|
|||
four valid policies for tmpfs (``always``, ``within_size``, ``advise``,
|
||||
``never``). The tmpfs mount default policy is ``never``.
|
||||
|
||||
Additionally, Kconfig options are available to set the default hugepage
|
||||
policies for shmem (``CONFIG_TRANSPARENT_HUGEPAGE_SHMEM_HUGE_*``) and tmpfs
|
||||
(``CONFIG_TRANSPARENT_HUGEPAGE_TMPFS_HUGE_*``) at build time. Refer to the
|
||||
Kconfig help for more details.
|
||||
|
||||
In the same manner as ``thp_anon`` controls each supported anonymous THP
|
||||
size, ``thp_shmem`` controls each supported shmem THP size. ``thp_shmem``
|
||||
has the same format as ``thp_anon``, but also supports the policy
|
||||
|
|
|
|||
|
|
@ -59,11 +59,11 @@ returned by the allocation routine and that handle must be mapped before being
|
|||
accessed. The compressed memory pool grows on demand and shrinks as compressed
|
||||
pages are freed. The pool is not preallocated.
|
||||
|
||||
When a swap page is passed from swapout to zswap, zswap maintains a mapping
|
||||
of the swap entry, a combination of the swap type and swap offset, to the
|
||||
zsmalloc handle that references that compressed swap page. This mapping is
|
||||
achieved with a red-black tree per swap type. The swap offset is the search
|
||||
key for the tree nodes.
|
||||
When a swap page is passed from swapout to zswap, zswap maintains a mapping of
|
||||
the swap entry, a combination of the swap type and swap offset, to the zsmalloc
|
||||
handle that references that compressed swap page. This mapping is achieved
|
||||
with an xarray per swap type. The swap offset is the search key for the xarray
|
||||
nodes.
|
||||
|
||||
During a page fault on a PTE that is a swap entry, the swapin code calls the
|
||||
zswap load function to decompress the page into the page allocated by the page
|
||||
|
|
|
|||
|
|
@ -397,13 +397,14 @@ a hung task is detected.
|
|||
hung_task_panic
|
||||
===============
|
||||
|
||||
Controls the kernel's behavior when a hung task is detected.
|
||||
When set to a non-zero value, a kernel panic will be triggered if the
|
||||
number of hung tasks found during a single scan reaches this value.
|
||||
This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled.
|
||||
|
||||
= =================================================
|
||||
= =======================================================
|
||||
0 Continue operation. This is the default behavior.
|
||||
1 Panic immediately.
|
||||
= =================================================
|
||||
N Panic when N hung tasks are found during a single scan.
|
||||
= =======================================================
|
||||
|
||||
|
||||
hung_task_check_count
|
||||
|
|
@ -421,6 +422,11 @@ the system boot.
|
|||
|
||||
This file shows up if ``CONFIG_DETECT_HUNG_TASK`` is enabled.
|
||||
|
||||
hung_task_sys_info
|
||||
==================
|
||||
A comma separated list of extra system information to be dumped when
|
||||
hung task is detected, for example, "tasks,mem,timers,locks,...".
|
||||
Refer 'panic_sys_info' section below for more details.
|
||||
|
||||
hung_task_timeout_secs
|
||||
======================
|
||||
|
|
@ -515,6 +521,15 @@ default), only processes with the CAP_SYS_ADMIN capability may create
|
|||
io_uring instances.
|
||||
|
||||
|
||||
kernel_sys_info
|
||||
===============
|
||||
A comma separated list of extra system information to be dumped when
|
||||
soft/hard lockup is detected, for example, "tasks,mem,timers,locks,...".
|
||||
Refer 'panic_sys_info' section below for more details.
|
||||
|
||||
It serves as the default kernel control knob, which will take effect
|
||||
when a kernel module calls sys_info() with parameter==0.
|
||||
|
||||
kexec_load_disabled
|
||||
===================
|
||||
|
||||
|
|
@ -576,6 +591,11 @@ if leaking kernel pointer values to unprivileged users is a concern.
|
|||
When ``kptr_restrict`` is set to 2, kernel pointers printed using
|
||||
%pK will be replaced with 0s regardless of privileges.
|
||||
|
||||
softlockup_sys_info & hardlockup_sys_info
|
||||
=========================================
|
||||
A comma separated list of extra system information to be dumped when
|
||||
soft/hard lockup is detected, for example, "tasks,mem,timers,locks,...".
|
||||
Refer 'panic_sys_info' section below for more details.
|
||||
|
||||
modprobe
|
||||
========
|
||||
|
|
@ -910,8 +930,8 @@ to 'panic_print'. Possible values are:
|
|||
============= ===================================================
|
||||
tasks print all tasks info
|
||||
mem print system memory info
|
||||
timer print timers info
|
||||
lock print locks info if CONFIG_LOCKDEP is on
|
||||
timers print timers info
|
||||
locks print locks info if CONFIG_LOCKDEP is on
|
||||
ftrace print ftrace buffer
|
||||
all_bt print all CPUs backtrace (if available in the arch)
|
||||
blocked_tasks print only tasks in uninterruptible (blocked) state
|
||||
|
|
|
|||
|
|
@ -203,10 +203,10 @@ host controller or a device, it is important that the firmware can be
|
|||
upgraded to the latest where possible bugs in it have been fixed.
|
||||
Typically OEMs provide this firmware from their support site.
|
||||
|
||||
There is also a central site which has links where to download firmware
|
||||
for some machines:
|
||||
|
||||
`Thunderbolt Updates <https://thunderbolttechnology.net/updates>`_
|
||||
Currently, recommended method of updating firmware is through "fwupd" tool.
|
||||
It uses LVFS (Linux Vendor Firmware Service) portal by default to get the
|
||||
latest firmware from hardware vendors and updates connected devices if found
|
||||
compatible. For details refer to: https://github.com/fwupd/fwupd.
|
||||
|
||||
Before you upgrade firmware on a device, host or retimer, please make
|
||||
sure it is a suitable upgrade. Failing to do that may render the device
|
||||
|
|
@ -215,18 +215,40 @@ tools!
|
|||
|
||||
Host NVM upgrade on Apple Macs is not supported.
|
||||
|
||||
Once the NVM image has been downloaded, you need to plug in a
|
||||
Thunderbolt device so that the host controller appears. It does not
|
||||
matter which device is connected (unless you are upgrading NVM on a
|
||||
device - then you need to connect that particular device).
|
||||
Fwupd is installed by default. If you don't have it on your system, simply
|
||||
use your distro package manager to get it.
|
||||
|
||||
To see possible updates through fwupd, you need to plug in a Thunderbolt
|
||||
device so that the host controller appears. It does not matter which
|
||||
device is connected (unless you are upgrading NVM on a device - then you
|
||||
need to connect that particular device).
|
||||
|
||||
Note an OEM-specific method to power the controller up ("force power") may
|
||||
be available for your system in which case there is no need to plug in a
|
||||
Thunderbolt device.
|
||||
|
||||
After that we can write the firmware to the non-active parts of the NVM
|
||||
of the host or device. As an example here is how Intel NUC6i7KYK (Skull
|
||||
Canyon) Thunderbolt controller NVM is upgraded::
|
||||
Updating firmware using fwupd is straightforward - refer to official
|
||||
readme on fwupd github.
|
||||
|
||||
If firmware image is written successfully, the device shortly disappears.
|
||||
Once it comes back, the driver notices it and initiates a full power
|
||||
cycle. After a while device appears again and this time it should be
|
||||
fully functional.
|
||||
|
||||
Device of interest should display new version under "Current version"
|
||||
and "Update State: Success" in fwupd's interface.
|
||||
|
||||
Upgrading firmware manually
|
||||
---------------------------------------------------------------
|
||||
If possible, use fwupd to updated the firmware. However, if your device OEM
|
||||
has not uploaded the firmware to LVFS, but it is available for download
|
||||
from their side, you can use method below to directly upgrade the
|
||||
firmware.
|
||||
|
||||
Manual firmware update can be done with 'dd' tool. To update firmware
|
||||
using this method, you need to write it to the non-active parts of NVM
|
||||
of the host or device. Example on how to update Intel NUC6i7KYK
|
||||
(Skull Canyon) Thunderbolt controller NVM::
|
||||
|
||||
# dd if=KYK_TBT_FW_0018.bin of=/sys/bus/thunderbolt/devices/0-0/nvm_non_active0/nvmem
|
||||
|
||||
|
|
@ -235,10 +257,8 @@ upgrade process as follows::
|
|||
|
||||
# echo 1 > /sys/bus/thunderbolt/devices/0-0/nvm_authenticate
|
||||
|
||||
If no errors are returned, the host controller shortly disappears. Once
|
||||
it comes back the driver notices it and initiates a full power cycle.
|
||||
After a while the host controller appears again and this time it should
|
||||
be fully functional.
|
||||
If no errors are returned, device should behave as described in previous
|
||||
section.
|
||||
|
||||
We can verify that the new NVM firmware is active by running the following
|
||||
commands::
|
||||
|
|
|
|||
|
|
@ -249,6 +249,9 @@ The following keys are defined:
|
|||
defined in the in the RISC-V ISA manual starting from commit e87412e621f1
|
||||
("integrate Zaamo and Zalrsc text (#1304)").
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZALASR`: The Zalasr extension is supported as
|
||||
frozen at commit 194f0094 ("Version 0.9 for freeze") of riscv-zalasr.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZALRSC`: The Zalrsc extension is supported as
|
||||
defined in the in the RISC-V ISA manual starting from commit e87412e621f1
|
||||
("integrate Zaamo and Zalrsc text (#1304)").
|
||||
|
|
@ -275,6 +278,17 @@ The following keys are defined:
|
|||
ratified in commit 49f49c842ff9 ("Update to Rafified state") of
|
||||
riscv-zabha.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZICBOP`: The Zicbop extension is supported, as
|
||||
ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZILSD`: The Zilsd extension is supported as
|
||||
defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating
|
||||
load/store pair for RV32 with the main manual") of the riscv-isa-manual.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZCLSD`: The Zclsd extension is supported as
|
||||
defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating
|
||||
load/store pair for RV32 with the main manual") of the riscv-isa-manual.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: Deprecated. Returns similar values to
|
||||
:c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`, but the key was
|
||||
mistakenly classified as a bitmask rather than a value.
|
||||
|
|
@ -369,4 +383,7 @@ The following keys are defined:
|
|||
|
||||
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVFWMACCQQQ`: The Xsfvfwmaccqqq
|
||||
vendor extension is supported in version 1.0 of Matrix Multiply Accumulate
|
||||
Instruction Extensions Specification.
|
||||
Instruction Extensions Specification.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_ZICBOP_BLOCK_SIZE`: An unsigned int which
|
||||
represents the size of the Zicbop block in bytes.
|
||||
|
|
|
|||
|
|
@ -95,26 +95,26 @@ Memory Layout
|
|||
The traditional memory map for the kernel loader, used for Image or
|
||||
zImage kernels, typically looks like::
|
||||
|
||||
| |
|
||||
| |
|
||||
0A0000 +------------------------+
|
||||
| Reserved for BIOS | Do not use. Reserved for BIOS EBDA.
|
||||
| Reserved for BIOS | Do not use. Reserved for BIOS EBDA.
|
||||
09A000 +------------------------+
|
||||
| Command line |
|
||||
| Stack/heap | For use by the kernel real-mode code.
|
||||
| Command line |
|
||||
| Stack/heap | For use by the kernel real-mode code.
|
||||
098000 +------------------------+
|
||||
| Kernel setup | The kernel real-mode code.
|
||||
| Kernel setup | The kernel real-mode code.
|
||||
090200 +------------------------+
|
||||
| Kernel boot sector | The kernel legacy boot sector.
|
||||
| Kernel boot sector | The kernel legacy boot sector.
|
||||
090000 +------------------------+
|
||||
| Protected-mode kernel | The bulk of the kernel image.
|
||||
| Protected-mode kernel | The bulk of the kernel image.
|
||||
010000 +------------------------+
|
||||
| Boot loader | <- Boot sector entry point 0000:7C00
|
||||
| Boot loader | <- Boot sector entry point 0000:7C00
|
||||
001000 +------------------------+
|
||||
| Reserved for MBR/BIOS |
|
||||
| Reserved for MBR/BIOS |
|
||||
000800 +------------------------+
|
||||
| Typically used by MBR |
|
||||
| Typically used by MBR |
|
||||
000600 +------------------------+
|
||||
| BIOS use only |
|
||||
| BIOS use only |
|
||||
000000 +------------------------+
|
||||
|
||||
When using bzImage, the protected-mode kernel was relocated to
|
||||
|
|
@ -142,27 +142,27 @@ above the 0x9A000 point; too many BIOSes will break above that point.
|
|||
For a modern bzImage kernel with boot protocol version >= 2.02, a
|
||||
memory layout like the following is suggested::
|
||||
|
||||
~ ~
|
||||
| Protected-mode kernel |
|
||||
~ ~
|
||||
| Protected-mode kernel |
|
||||
100000 +------------------------+
|
||||
| I/O memory hole |
|
||||
| I/O memory hole |
|
||||
0A0000 +------------------------+
|
||||
| Reserved for BIOS | Leave as much as possible unused
|
||||
~ ~
|
||||
| Command line | (Can also be below the X+10000 mark)
|
||||
| Reserved for BIOS | Leave as much as possible unused
|
||||
~ ~
|
||||
| Command line | (Can also be below the X+10000 mark)
|
||||
X+10000 +------------------------+
|
||||
| Stack/heap | For use by the kernel real-mode code.
|
||||
| Stack/heap | For use by the kernel real-mode code.
|
||||
X+08000 +------------------------+
|
||||
| Kernel setup | The kernel real-mode code.
|
||||
| Kernel boot sector | The kernel legacy boot sector.
|
||||
| Kernel setup | The kernel real-mode code.
|
||||
| Kernel boot sector | The kernel legacy boot sector.
|
||||
X +------------------------+
|
||||
| Boot loader | <- Boot sector entry point 0000:7C00
|
||||
| Boot loader | <- Boot sector entry point 0000:7C00
|
||||
001000 +------------------------+
|
||||
| Reserved for MBR/BIOS |
|
||||
| Reserved for MBR/BIOS |
|
||||
000800 +------------------------+
|
||||
| Typically used by MBR |
|
||||
| Typically used by MBR |
|
||||
000600 +------------------------+
|
||||
| BIOS use only |
|
||||
| BIOS use only |
|
||||
000000 +------------------------+
|
||||
|
||||
... where the address X is as low as the design of the boot loader permits.
|
||||
|
|
@ -416,7 +416,7 @@ Offset/size: 0x210/1
|
|||
Protocol: 2.00+
|
||||
============ ==================
|
||||
|
||||
If your boot loader has an assigned id (see table below), enter
|
||||
If your boot loader has an assigned ID (see table below), enter
|
||||
0xTV here, where T is an identifier for the boot loader and V is
|
||||
a version number. Otherwise, enter 0xFF here.
|
||||
|
||||
|
|
@ -431,32 +431,32 @@ Protocol: 2.00+
|
|||
ext_loader_type <- 0x05
|
||||
ext_loader_ver <- 0x23
|
||||
|
||||
Assigned boot loader ids (hexadecimal):
|
||||
Assigned boot loader IDs:
|
||||
|
||||
== =======================================
|
||||
0 LILO
|
||||
(0x00 reserved for pre-2.00 bootloader)
|
||||
1 Loadlin
|
||||
2 bootsect-loader
|
||||
(0x20, all other values reserved)
|
||||
3 Syslinux
|
||||
4 Etherboot/gPXE/iPXE
|
||||
5 ELILO
|
||||
7 GRUB
|
||||
8 U-Boot
|
||||
9 Xen
|
||||
A Gujin
|
||||
B Qemu
|
||||
C Arcturus Networks uCbootloader
|
||||
D kexec-tools
|
||||
E Extended (see ext_loader_type)
|
||||
F Special (0xFF = undefined)
|
||||
10 Reserved
|
||||
11 Minimal Linux Bootloader
|
||||
<http://sebastian-plotz.blogspot.de>
|
||||
12 OVMF UEFI virtualization stack
|
||||
13 barebox
|
||||
== =======================================
|
||||
==== =======================================
|
||||
0x0 LILO
|
||||
(0x00 reserved for pre-2.00 bootloader)
|
||||
0x1 Loadlin
|
||||
0x2 bootsect-loader
|
||||
(0x20, all other values reserved)
|
||||
0x3 Syslinux
|
||||
0x4 Etherboot/gPXE/iPXE
|
||||
0x5 ELILO
|
||||
0x7 GRUB
|
||||
0x8 U-Boot
|
||||
0x9 Xen
|
||||
0xA Gujin
|
||||
0xB Qemu
|
||||
0xC Arcturus Networks uCbootloader
|
||||
0xD kexec-tools
|
||||
0xE Extended (see ext_loader_type)
|
||||
0xF Special (0xFF = undefined)
|
||||
0x10 Reserved
|
||||
0x11 Minimal Linux Bootloader
|
||||
<http://sebastian-plotz.blogspot.de>
|
||||
0x12 OVMF UEFI virtualization stack
|
||||
0x13 barebox
|
||||
==== =======================================
|
||||
|
||||
Please contact <hpa@zytor.com> if you need a bootloader ID value assigned.
|
||||
|
||||
|
|
@ -809,12 +809,12 @@ Protocol: 2.09+
|
|||
as follow::
|
||||
|
||||
struct setup_data {
|
||||
__u64 next;
|
||||
__u32 type;
|
||||
__u32 len;
|
||||
__u8 data[];
|
||||
__u64 next;
|
||||
__u32 type;
|
||||
__u32 len;
|
||||
__u8 data[];
|
||||
}
|
||||
|
||||
|
||||
Where, the next is a 64-bit physical pointer to the next node of
|
||||
linked list, the next field of the last node is 0; the type is used
|
||||
to identify the contents of data; the len is the length of data
|
||||
|
|
@ -835,10 +835,10 @@ Protocol: 2.09+
|
|||
protocol 2.15::
|
||||
|
||||
struct setup_indirect {
|
||||
__u32 type;
|
||||
__u32 reserved; /* Reserved, must be set to zero. */
|
||||
__u64 len;
|
||||
__u64 addr;
|
||||
__u32 type;
|
||||
__u32 reserved; /* Reserved, must be set to zero. */
|
||||
__u64 len;
|
||||
__u64 addr;
|
||||
};
|
||||
|
||||
The type member is a SETUP_INDIRECT | SETUP_* type. However, it cannot be
|
||||
|
|
@ -850,15 +850,15 @@ Protocol: 2.09+
|
|||
In this case setup_data and setup_indirect will look like this::
|
||||
|
||||
struct setup_data {
|
||||
.next = 0, /* or <addr_of_next_setup_data_struct> */
|
||||
.type = SETUP_INDIRECT,
|
||||
.len = sizeof(setup_indirect),
|
||||
.data[sizeof(setup_indirect)] = (struct setup_indirect) {
|
||||
.type = SETUP_INDIRECT | SETUP_E820_EXT,
|
||||
.reserved = 0,
|
||||
.len = <len_of_SETUP_E820_EXT_data>,
|
||||
.addr = <addr_of_SETUP_E820_EXT_data>,
|
||||
},
|
||||
.next = 0, /* or <addr_of_next_setup_data_struct> */
|
||||
.type = SETUP_INDIRECT,
|
||||
.len = sizeof(setup_indirect),
|
||||
.data[sizeof(setup_indirect)] = (struct setup_indirect) {
|
||||
.type = SETUP_INDIRECT | SETUP_E820_EXT,
|
||||
.reserved = 0,
|
||||
.len = <len_of_SETUP_E820_EXT_data>,
|
||||
.addr = <addr_of_SETUP_E820_EXT_data>,
|
||||
},
|
||||
}
|
||||
|
||||
.. note::
|
||||
|
|
@ -897,11 +897,11 @@ Offset/size: 0x260/4
|
|||
The kernel runtime start address is determined by the following algorithm::
|
||||
|
||||
if (relocatable_kernel) {
|
||||
if (load_address < pref_address)
|
||||
load_address = pref_address;
|
||||
runtime_start = align_up(load_address, kernel_alignment);
|
||||
if (load_address < pref_address)
|
||||
load_address = pref_address;
|
||||
runtime_start = align_up(load_address, kernel_alignment);
|
||||
} else {
|
||||
runtime_start = pref_address;
|
||||
runtime_start = pref_address;
|
||||
}
|
||||
|
||||
Hence the necessary memory window location and size can be estimated by
|
||||
|
|
@ -975,22 +975,22 @@ after kernel_info_var_len_data label. Each chunk of variable size data has to
|
|||
be prefixed with header/magic and its size, e.g.::
|
||||
|
||||
kernel_info:
|
||||
.ascii "LToP" /* Header, Linux top (structure). */
|
||||
.long kernel_info_var_len_data - kernel_info
|
||||
.long kernel_info_end - kernel_info
|
||||
.long 0x01234567 /* Some fixed size data for the bootloaders. */
|
||||
.ascii "LToP" /* Header, Linux top (structure). */
|
||||
.long kernel_info_var_len_data - kernel_info
|
||||
.long kernel_info_end - kernel_info
|
||||
.long 0x01234567 /* Some fixed size data for the bootloaders. */
|
||||
kernel_info_var_len_data:
|
||||
example_struct: /* Some variable size data for the bootloaders. */
|
||||
.ascii "0123" /* Header/Magic. */
|
||||
.long example_struct_end - example_struct
|
||||
.ascii "Struct"
|
||||
.long 0x89012345
|
||||
.ascii "0123" /* Header/Magic. */
|
||||
.long example_struct_end - example_struct
|
||||
.ascii "Struct"
|
||||
.long 0x89012345
|
||||
example_struct_end:
|
||||
example_strings: /* Some variable size data for the bootloaders. */
|
||||
.ascii "ABCD" /* Header/Magic. */
|
||||
.long example_strings_end - example_strings
|
||||
.asciz "String_0"
|
||||
.asciz "String_1"
|
||||
.ascii "ABCD" /* Header/Magic. */
|
||||
.long example_strings_end - example_strings
|
||||
.asciz "String_0"
|
||||
.asciz "String_1"
|
||||
example_strings_end:
|
||||
kernel_info_end:
|
||||
|
||||
|
|
@ -1132,53 +1132,53 @@ Such a boot loader should enter the following fields in the header::
|
|||
unsigned long base_ptr; /* base address for real-mode segment */
|
||||
|
||||
if (setup_sects == 0)
|
||||
setup_sects = 4;
|
||||
setup_sects = 4;
|
||||
|
||||
if (protocol >= 0x0200) {
|
||||
type_of_loader = <type code>;
|
||||
if (loading_initrd) {
|
||||
ramdisk_image = <initrd_address>;
|
||||
ramdisk_size = <initrd_size>;
|
||||
}
|
||||
type_of_loader = <type code>;
|
||||
if (loading_initrd) {
|
||||
ramdisk_image = <initrd_address>;
|
||||
ramdisk_size = <initrd_size>;
|
||||
}
|
||||
|
||||
if (protocol >= 0x0202 && loadflags & 0x01)
|
||||
heap_end = 0xe000;
|
||||
else
|
||||
heap_end = 0x9800;
|
||||
if (protocol >= 0x0202 && loadflags & 0x01)
|
||||
heap_end = 0xe000;
|
||||
else
|
||||
heap_end = 0x9800;
|
||||
|
||||
if (protocol >= 0x0201) {
|
||||
heap_end_ptr = heap_end - 0x200;
|
||||
loadflags |= 0x80; /* CAN_USE_HEAP */
|
||||
}
|
||||
if (protocol >= 0x0201) {
|
||||
heap_end_ptr = heap_end - 0x200;
|
||||
loadflags |= 0x80; /* CAN_USE_HEAP */
|
||||
}
|
||||
|
||||
if (protocol >= 0x0202) {
|
||||
cmd_line_ptr = base_ptr + heap_end;
|
||||
strcpy(cmd_line_ptr, cmdline);
|
||||
} else {
|
||||
cmd_line_magic = 0xA33F;
|
||||
cmd_line_offset = heap_end;
|
||||
setup_move_size = heap_end + strlen(cmdline) + 1;
|
||||
strcpy(base_ptr + cmd_line_offset, cmdline);
|
||||
}
|
||||
if (protocol >= 0x0202) {
|
||||
cmd_line_ptr = base_ptr + heap_end;
|
||||
strcpy(cmd_line_ptr, cmdline);
|
||||
} else {
|
||||
cmd_line_magic = 0xA33F;
|
||||
cmd_line_offset = heap_end;
|
||||
setup_move_size = heap_end + strlen(cmdline) + 1;
|
||||
strcpy(base_ptr + cmd_line_offset, cmdline);
|
||||
}
|
||||
} else {
|
||||
/* Very old kernel */
|
||||
/* Very old kernel */
|
||||
|
||||
heap_end = 0x9800;
|
||||
heap_end = 0x9800;
|
||||
|
||||
cmd_line_magic = 0xA33F;
|
||||
cmd_line_offset = heap_end;
|
||||
cmd_line_magic = 0xA33F;
|
||||
cmd_line_offset = heap_end;
|
||||
|
||||
/* A very old kernel MUST have its real-mode code loaded at 0x90000 */
|
||||
if (base_ptr != 0x90000) {
|
||||
/* Copy the real-mode kernel */
|
||||
memcpy(0x90000, base_ptr, (setup_sects + 1) * 512);
|
||||
base_ptr = 0x90000; /* Relocated */
|
||||
}
|
||||
/* A very old kernel MUST have its real-mode code loaded at 0x90000 */
|
||||
if (base_ptr != 0x90000) {
|
||||
/* Copy the real-mode kernel */
|
||||
memcpy(0x90000, base_ptr, (setup_sects + 1) * 512);
|
||||
base_ptr = 0x90000; /* Relocated */
|
||||
}
|
||||
|
||||
strcpy(0x90000 + cmd_line_offset, cmdline);
|
||||
strcpy(0x90000 + cmd_line_offset, cmdline);
|
||||
|
||||
/* It is recommended to clear memory up to the 32K mark */
|
||||
memset(0x90000 + (setup_sects + 1) * 512, 0, (64 - (setup_sects + 1)) * 512);
|
||||
/* It is recommended to clear memory up to the 32K mark */
|
||||
memset(0x90000 + (setup_sects + 1) * 512, 0, (64 - (setup_sects + 1)) * 512);
|
||||
}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -138,6 +138,7 @@ Documents that don't fit elsewhere or which have yet to be categorized.
|
|||
:maxdepth: 1
|
||||
|
||||
librs
|
||||
liveupdate
|
||||
netlink
|
||||
|
||||
.. only:: subproject and html
|
||||
|
|
|
|||
|
|
@ -70,5 +70,5 @@ in the FDT. That state is called the KHO finalization phase.
|
|||
|
||||
Public API
|
||||
==========
|
||||
.. kernel-doc:: kernel/kexec_handover.c
|
||||
.. kernel-doc:: kernel/liveupdate/kexec_handover.c
|
||||
:export:
|
||||
|
|
|
|||
61
Documentation/core-api/liveupdate.rst
Normal file
61
Documentation/core-api/liveupdate.rst
Normal file
|
|
@ -0,0 +1,61 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
========================
|
||||
Live Update Orchestrator
|
||||
========================
|
||||
:Author: Pasha Tatashin <pasha.tatashin@soleen.com>
|
||||
|
||||
.. kernel-doc:: kernel/liveupdate/luo_core.c
|
||||
:doc: Live Update Orchestrator (LUO)
|
||||
|
||||
LUO Sessions
|
||||
============
|
||||
.. kernel-doc:: kernel/liveupdate/luo_session.c
|
||||
:doc: LUO Sessions
|
||||
|
||||
LUO Preserving File Descriptors
|
||||
===============================
|
||||
.. kernel-doc:: kernel/liveupdate/luo_file.c
|
||||
:doc: LUO File Descriptors
|
||||
|
||||
Live Update Orchestrator ABI
|
||||
============================
|
||||
.. kernel-doc:: include/linux/kho/abi/luo.h
|
||||
:doc: Live Update Orchestrator ABI
|
||||
|
||||
The following types of file descriptors can be preserved
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
../mm/memfd_preservation
|
||||
|
||||
Public API
|
||||
==========
|
||||
.. kernel-doc:: include/linux/liveupdate.h
|
||||
|
||||
.. kernel-doc:: include/linux/kho/abi/luo.h
|
||||
:functions:
|
||||
|
||||
.. kernel-doc:: kernel/liveupdate/luo_core.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: kernel/liveupdate/luo_file.c
|
||||
:export:
|
||||
|
||||
Internal API
|
||||
============
|
||||
.. kernel-doc:: kernel/liveupdate/luo_core.c
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: kernel/liveupdate/luo_session.c
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: kernel/liveupdate/luo_file.c
|
||||
:internal:
|
||||
|
||||
See Also
|
||||
========
|
||||
|
||||
- :doc:`Live Update uAPI </userspace-api/liveupdate>`
|
||||
- :doc:`/core-api/kho/concepts`
|
||||
|
|
@ -1002,6 +1002,29 @@ Functions and Variables
|
|||
|
||||
return bar;
|
||||
|
||||
**UNINITIALIZED_PTR_WITH_FREE**
|
||||
Pointers with __free attribute should be declared at the place of use
|
||||
and initialized (see include/linux/cleanup.h). In this case
|
||||
declarations at the top of the function rule can be relaxed. Not doing
|
||||
so may lead to undefined behavior as the memory assigned (garbage,
|
||||
in case not initialized) to the pointer is freed automatically when
|
||||
the pointer goes out of scope.
|
||||
|
||||
Also see: https://lore.kernel.org/lkml/58fd478f408a34b578ee8d949c5c4b4da4d4f41d.camel@HansenPartnership.com/
|
||||
|
||||
Example::
|
||||
|
||||
type var __free(free_func);
|
||||
... // var not used, but, in future someone might add a return here
|
||||
var = malloc(var_size);
|
||||
...
|
||||
|
||||
should be initialized as::
|
||||
|
||||
...
|
||||
type var __free(free_func) = malloc(var_size);
|
||||
...
|
||||
|
||||
|
||||
Permissions
|
||||
-----------
|
||||
|
|
@ -1238,6 +1261,16 @@ Others
|
|||
The patch file does not appear to be in unified-diff format. Please
|
||||
regenerate the patch file before sending it to the maintainer.
|
||||
|
||||
**PLACEHOLDER_USE**
|
||||
Detects unhandled placeholder text left in cover letters or commit headers/logs.
|
||||
Common placeholders include lines like::
|
||||
|
||||
*** SUBJECT HERE ***
|
||||
*** BLURB HERE ***
|
||||
|
||||
These typically come from autogenerated templates. Replace them with a proper
|
||||
subject and description before sending.
|
||||
|
||||
**PRINTF_0XDECIMAL**
|
||||
Prefixing 0x with decimal output is defective and should be corrected.
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ rules:
|
|||
document-start:
|
||||
present: true
|
||||
empty-lines:
|
||||
max: 3
|
||||
max: 1
|
||||
max-end: 1
|
||||
empty-values:
|
||||
forbid-in-block-mappings: true
|
||||
|
|
|
|||
|
|
@ -32,7 +32,8 @@ find_cmd = $(find_all_cmd) | \
|
|||
sed 's|^$(srctree)/||' | \
|
||||
grep -F -e "$(subst :," -e ",$(DT_SCHEMA_FILES))" | \
|
||||
sed 's|^|$(srctree)/|'
|
||||
CHK_DT_EXAMPLES := $(patsubst $(srctree)/%.yaml,%.example.dtb, $(shell $(find_cmd)))
|
||||
CHK_DT_EXAMPLES := $(patsubst $(srctree)/%.yaml,%.example.dtb, \
|
||||
$(shell $(find_cmd) | xargs grep -l '^examples:'))
|
||||
|
||||
quiet_cmd_yamllint = LINT $(src)
|
||||
cmd_yamllint = ($(find_cmd) | \
|
||||
|
|
|
|||
|
|
@ -31,7 +31,9 @@ properties:
|
|||
- description: Mercury+ AA1 boards
|
||||
items:
|
||||
- enum:
|
||||
- enclustra,mercury-pe1
|
||||
- enclustra,mercury-aa1-pe1
|
||||
- enclustra,mercury-aa1-pe3
|
||||
- enclustra,mercury-aa1-st1
|
||||
- google,chameleon-v3
|
||||
- const: enclustra,mercury-aa1
|
||||
- const: altr,socfpga-arria10
|
||||
|
|
@ -52,6 +54,26 @@ properties:
|
|||
- const: altr,socfpga-cyclone5
|
||||
- const: altr,socfpga
|
||||
|
||||
- description: Mercury SA1 boards
|
||||
items:
|
||||
- enum:
|
||||
- enclustra,mercury-sa1-pe1
|
||||
- enclustra,mercury-sa1-pe3
|
||||
- enclustra,mercury-sa1-st1
|
||||
- const: enclustra,mercury-sa1
|
||||
- const: altr,socfpga-cyclone5
|
||||
- const: altr,socfpga
|
||||
|
||||
- description: Mercury+ SA2 boards
|
||||
items:
|
||||
- enum:
|
||||
- enclustra,mercury-sa2-pe1
|
||||
- enclustra,mercury-sa2-pe3
|
||||
- enclustra,mercury-sa2-st1
|
||||
- const: enclustra,mercury-sa2
|
||||
- const: altr,socfpga-cyclone5
|
||||
- const: altr,socfpga
|
||||
|
||||
- description: Stratix 10 boards
|
||||
items:
|
||||
- enum:
|
||||
|
|
|
|||
|
|
@ -27,17 +27,17 @@ properties:
|
|||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
"#address-cells":
|
||||
'#address-cells':
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
'#size-cells':
|
||||
const: 0
|
||||
|
||||
patternProperties:
|
||||
"^osc[0-9]$":
|
||||
'^osc[0-9]$':
|
||||
type: object
|
||||
|
||||
"^[a-z0-9,_]+(clk|pll|clk_gate|clk_divided)(@[a-f0-9]+)?$":
|
||||
'^[a-z0-9,_]+(clk|pll|clk_gate|clk_divided)(@[a-f0-9]+)?$':
|
||||
type: object
|
||||
$ref: '#/$defs/clock-props'
|
||||
unevaluatedProperties: false
|
||||
|
|
@ -58,14 +58,14 @@ properties:
|
|||
minItems: 1
|
||||
maxItems: 5
|
||||
|
||||
"#address-cells":
|
||||
'#address-cells':
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
'#size-cells':
|
||||
const: 0
|
||||
|
||||
patternProperties:
|
||||
"^[a-z0-9,_]+(clk|pll)(@[a-f0-9]+)?$":
|
||||
'^[a-z0-9,_]+(clk|pll)(@[a-f0-9]+)?$':
|
||||
type: object
|
||||
$ref: '#/$defs/clock-props'
|
||||
unevaluatedProperties: false
|
||||
|
|
@ -86,11 +86,11 @@ properties:
|
|||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- "#clock-cells"
|
||||
- '#clock-cells'
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- "#clock-cells"
|
||||
- '#clock-cells'
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
|
@ -104,7 +104,7 @@ $defs:
|
|||
reg:
|
||||
maxItems: 1
|
||||
|
||||
"#clock-cells":
|
||||
'#clock-cells':
|
||||
const: 0
|
||||
|
||||
clk-gate:
|
||||
|
|
|
|||
24
Documentation/devicetree/bindings/arm/amd,seattle.yaml
Normal file
24
Documentation/devicetree/bindings/arm/amd,seattle.yaml
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/amd,seattle.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: AMD Seattle SoC Platforms
|
||||
|
||||
maintainers:
|
||||
- Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
|
||||
- Tom Lendacky <thomas.lendacky@amd.com>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: "/"
|
||||
compatible:
|
||||
oneOf:
|
||||
- description: Boards with AMD Seattle SoC
|
||||
items:
|
||||
- const: amd,seattle-overdrive
|
||||
- const: amd,seattle
|
||||
|
||||
additionalProperties: true
|
||||
...
|
||||
|
|
@ -134,6 +134,7 @@ properties:
|
|||
- libretech,aml-s912-pc
|
||||
- minix,neo-u9h
|
||||
- nexbox,a1
|
||||
- oranth,tx9-pro
|
||||
- tronsmart,vega-s96
|
||||
- ugoos,am3
|
||||
- videostrong,gxm-kiii-pro
|
||||
|
|
|
|||
|
|
@ -34,6 +34,9 @@ properties:
|
|||
- amlogic,a4-ao-secure
|
||||
- amlogic,c3-ao-secure
|
||||
- amlogic,s4-ao-secure
|
||||
- amlogic,s6-ao-secure
|
||||
- amlogic,s7-ao-secure
|
||||
- amlogic,s7d-ao-secure
|
||||
- amlogic,t7-ao-secure
|
||||
- const: amlogic,meson-gx-ao-secure
|
||||
- const: syscon
|
||||
|
|
|
|||
28
Documentation/devicetree/bindings/arm/apm.yaml
Normal file
28
Documentation/devicetree/bindings/arm/apm.yaml
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/apm.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: APM X-Gene SoC Platforms
|
||||
|
||||
maintainers:
|
||||
- Khuong Dinh <khuong@os.amperecomputing.com>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: "/"
|
||||
compatible:
|
||||
oneOf:
|
||||
- description: Boards with X-Gene1 Soc
|
||||
items:
|
||||
- const: apm,mustang
|
||||
- const: apm,xgene-storm
|
||||
|
||||
- description: Boards with X-Gene2 SoC
|
||||
items:
|
||||
- const: apm,merlin
|
||||
- const: apm,xgene-shadowcat
|
||||
|
||||
additionalProperties: true
|
||||
...
|
||||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: ARM Integrator Boards
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Linus Walleij <linusw@kernel.org>
|
||||
|
||||
description: |+
|
||||
These were the first ARM platforms officially supported by ARM Ltd.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: ARM RealView Boards
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Linus Walleij <linusw@kernel.org>
|
||||
|
||||
description: |+
|
||||
The ARM RealView series of reference designs were built to explore the Arm11,
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: ARM Snoop Control Unit (SCU)
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Linus Walleij <linusw@kernel.org>
|
||||
|
||||
description: |
|
||||
As part of the MPCore complex, Cortex-A5 and Cortex-A9 are provided
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Arm Versatile system registers
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Linus Walleij <linusw@kernel.org>
|
||||
|
||||
description:
|
||||
This is a system control registers block, providing multiple low level
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: ARM Versatile Boards
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Linus Walleij <linusw@kernel.org>
|
||||
|
||||
description: |+
|
||||
The ARM Versatile boards are two variants of ARM926EJ-S evaluation boards
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ title: ARM Versatile Express and Juno Boards
|
|||
|
||||
maintainers:
|
||||
- Sudeep Holla <sudeep.holla@arm.com>
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Linus Walleij <linusw@kernel.org>
|
||||
|
||||
description: |+
|
||||
ARM's Versatile Express platform were built as reference designs for exploring
|
||||
|
|
|
|||
|
|
@ -93,7 +93,10 @@ properties:
|
|||
- facebook,minerva-cmc
|
||||
- facebook,santabarbara-bmc
|
||||
- facebook,yosemite4-bmc
|
||||
- facebook,yosemite5-bmc
|
||||
- ibm,balcones-bmc
|
||||
- ibm,blueridge-bmc
|
||||
- ibm,bonnell-bmc
|
||||
- ibm,everest-bmc
|
||||
- ibm,fuji-bmc
|
||||
- ibm,rainier-bmc
|
||||
|
|
|
|||
31
Documentation/devicetree/bindings/arm/bst.yaml
Normal file
31
Documentation/devicetree/bindings/arm/bst.yaml
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/bst.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: BST platforms
|
||||
|
||||
description:
|
||||
Black Sesame Technologies (BST) is a semiconductor company that produces
|
||||
automotive-grade system-on-chips (SoCs) for intelligent driving, focusing
|
||||
on computer vision and AI capabilities. The BST C1200 family includes SoCs
|
||||
for ADAS (Advanced Driver Assistance Systems) and autonomous driving
|
||||
applications.
|
||||
|
||||
maintainers:
|
||||
- Ge Gordon <gordon.ge@bst.ai>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: '/'
|
||||
compatible:
|
||||
oneOf:
|
||||
- description: BST C1200 CDCU1.0 ADAS 4C2G board
|
||||
items:
|
||||
- const: bst,c1200-cdcu1.0-adas-4c2g
|
||||
- const: bst,c1200
|
||||
|
||||
additionalProperties: true
|
||||
|
||||
...
|
||||
|
|
@ -1106,11 +1106,14 @@ properties:
|
|||
- gateworks,imx8mp-gw75xx-2x # i.MX8MP Gateworks Board
|
||||
- gateworks,imx8mp-gw82xx-2x # i.MX8MP Gateworks Board
|
||||
- gocontroll,moduline-display # GOcontroll Moduline Display controller
|
||||
- prt,prt8ml # Protonic PRT8ML
|
||||
- skov,imx8mp-skov-basic # SKOV i.MX8MP baseboard without frontplate
|
||||
- skov,imx8mp-skov-revb-hdmi # SKOV i.MX8MP climate control without panel
|
||||
- skov,imx8mp-skov-revb-lt6 # SKOV i.MX8MP climate control with 7” panel
|
||||
- skov,imx8mp-skov-revb-mi1010ait-1cp1 # SKOV i.MX8MP climate control with 10.1" panel
|
||||
- skov,imx8mp-skov-revc-hdmi # SKOV i.MX8MP climate control without panel
|
||||
- skov,imx8mp-skov-revc-bd500 # SKOV i.MX8MP climate control with LED frontplate
|
||||
- skov,imx8mp-skov-revc-jutouch-jt101tm023 # SKOV i.MX8MP climate control with 10" JuTouch panel
|
||||
- skov,imx8mp-skov-revc-tian-g07017 # SKOV i.MX8MP climate control with 7" panel
|
||||
- ultratronik,imx8mp-ultra-mach-sbc # Ultratronik SBC i.MX8MP based board
|
||||
- ysoft,imx8mp-iota2-lumpy # Y Soft i.MX8MP IOTA2 Lumpy Board
|
||||
|
|
@ -1430,6 +1433,7 @@ properties:
|
|||
- enum:
|
||||
- fsl,imx95-15x15-evk # i.MX95 15x15 EVK Board
|
||||
- fsl,imx95-19x19-evk # i.MX95 19x19 EVK Board
|
||||
- toradex,verdin-imx95-19x19-evk # i.MX95 Verdin Evaluation Kit (EVK)
|
||||
- const: fsl,imx95
|
||||
|
||||
- description: PHYTEC i.MX 95 FPSC based Boards
|
||||
|
|
@ -1439,6 +1443,12 @@ properties:
|
|||
- const: phytec,imx95-phycore-fpsc # phyCORE-i.MX 95 FPSC
|
||||
- const: fsl,imx95
|
||||
|
||||
- description: Toradex Boards with SMARC iMX95 Modules
|
||||
items:
|
||||
- const: toradex,smarc-imx95-dev # Toradex SMARC iMX95 on Toradex SMARC Development Board
|
||||
- const: toradex,smarc-imx95 # Toradex SMARC iMX95 Module
|
||||
- const: fsl,imx95
|
||||
|
||||
- description: i.MXRT1050 based Boards
|
||||
items:
|
||||
- enum:
|
||||
|
|
@ -1492,6 +1502,13 @@ properties:
|
|||
- const: tq,imx93-tqma9352 # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM
|
||||
- const: fsl,imx93
|
||||
|
||||
- description: PHYTEC phyCORE-i.MX91 SoM based boards
|
||||
items:
|
||||
- enum:
|
||||
- phytec,imx91-phyboard-segin # phyBOARD-Segin with i.MX91
|
||||
- const: phytec,imx91-phycore-som # phyCORE-i.MX91 SoM
|
||||
- const: fsl,imx91
|
||||
|
||||
- description: PHYTEC phyCORE-i.MX93 SoM based boards
|
||||
items:
|
||||
- enum:
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ description: |
|
|||
Many of the IP blocks used in the SoC comes from Faraday Technology.
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Linus Walleij <linusw@kernel.org>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
|
|
|
|||
|
|
@ -21,10 +21,17 @@ properties:
|
|||
- intel,socfpga-agilex-n6000
|
||||
- intel,socfpga-agilex-socdk
|
||||
- const: intel,socfpga-agilex
|
||||
- description: Agilex3 boards
|
||||
items:
|
||||
- enum:
|
||||
- intel,socfpga-agilex3-socdk
|
||||
- const: intel,socfpga-agilex3
|
||||
- const: intel,socfpga-agilex5
|
||||
- description: Agilex5 boards
|
||||
items:
|
||||
- enum:
|
||||
- intel,socfpga-agilex5-socdk
|
||||
- intel,socfpga-agilex5-socdk-013b
|
||||
- intel,socfpga-agilex5-socdk-nand
|
||||
- const: intel,socfpga-agilex5
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Intel IXP4xx
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Linus Walleij <linusw@kernel.org>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
|
|
|
|||
28
Documentation/devicetree/bindings/arm/lge.yaml
Normal file
28
Documentation/devicetree/bindings/arm/lge.yaml
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/lge.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: LG Electronics SoC Platforms
|
||||
|
||||
maintainers:
|
||||
- Chanho Min <chanho.min@lge.com>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: "/"
|
||||
compatible:
|
||||
oneOf:
|
||||
- description: Boards with LG1312 Soc
|
||||
items:
|
||||
- const: lge,lg1312-ref
|
||||
- const: lge,lg1312
|
||||
|
||||
- description: Boards with LG1313 SoC
|
||||
items:
|
||||
- const: lge,lg1313-ref
|
||||
- const: lge,lg1313
|
||||
|
||||
additionalProperties: true
|
||||
...
|
||||
|
|
@ -1,146 +0,0 @@
|
|||
Marvell Armada AP80x System Controller
|
||||
======================================
|
||||
|
||||
The AP806/AP807 is one of the two core HW blocks of the Marvell Armada
|
||||
7K/8K/931x SoCs. It contains system controllers, which provide several
|
||||
registers giving access to numerous features: clocks, pin-muxing and
|
||||
many other SoC configuration items. This DT binding allows to describe
|
||||
these system controllers.
|
||||
|
||||
For the top level node:
|
||||
- compatible: must be: "syscon", "simple-mfd";
|
||||
- reg: register area of the AP80x system controller
|
||||
|
||||
SYSTEM CONTROLLER 0
|
||||
===================
|
||||
|
||||
Clocks:
|
||||
-------
|
||||
|
||||
|
||||
The Device Tree node representing the AP806/AP807 system controller
|
||||
provides a number of clocks:
|
||||
|
||||
- 0: reference clock of CPU cluster 0
|
||||
- 1: reference clock of CPU cluster 1
|
||||
- 2: fixed PLL at 1200 Mhz
|
||||
- 3: MSS clock, derived from the fixed PLL
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: must be one of:
|
||||
* "marvell,ap806-clock"
|
||||
* "marvell,ap807-clock"
|
||||
- #clock-cells: must be set to 1
|
||||
|
||||
Pinctrl:
|
||||
--------
|
||||
|
||||
For common binding part and usage, refer to
|
||||
Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt.
|
||||
|
||||
Required properties:
|
||||
- compatible must be "marvell,ap806-pinctrl",
|
||||
|
||||
Available mpp pins/groups and functions:
|
||||
Note: brackets (x) are not part of the mpp name for marvell,function and given
|
||||
only for more detailed description in this document.
|
||||
|
||||
name pins functions
|
||||
================================================================================
|
||||
mpp0 0 gpio, sdio(clk), spi0(clk)
|
||||
mpp1 1 gpio, sdio(cmd), spi0(miso)
|
||||
mpp2 2 gpio, sdio(d0), spi0(mosi)
|
||||
mpp3 3 gpio, sdio(d1), spi0(cs0n)
|
||||
mpp4 4 gpio, sdio(d2), i2c0(sda)
|
||||
mpp5 5 gpio, sdio(d3), i2c0(sdk)
|
||||
mpp6 6 gpio, sdio(ds)
|
||||
mpp7 7 gpio, sdio(d4), uart1(rxd)
|
||||
mpp8 8 gpio, sdio(d5), uart1(txd)
|
||||
mpp9 9 gpio, sdio(d6), spi0(cs1n)
|
||||
mpp10 10 gpio, sdio(d7)
|
||||
mpp11 11 gpio, uart0(txd)
|
||||
mpp12 12 gpio, sdio(pw_off), sdio(hw_rst)
|
||||
mpp13 13 gpio
|
||||
mpp14 14 gpio
|
||||
mpp15 15 gpio
|
||||
mpp16 16 gpio
|
||||
mpp17 17 gpio
|
||||
mpp18 18 gpio
|
||||
mpp19 19 gpio, uart0(rxd), sdio(pw_off)
|
||||
|
||||
GPIO:
|
||||
-----
|
||||
For common binding part and usage, refer to
|
||||
Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: "marvell,armada-8k-gpio"
|
||||
|
||||
- offset: offset address inside the syscon block
|
||||
|
||||
Optional properties:
|
||||
|
||||
- marvell,pwm-offset: offset address of PWM duration control registers inside
|
||||
the syscon block
|
||||
|
||||
Example:
|
||||
ap_syscon: system-controller@6f4000 {
|
||||
compatible = "syscon", "simple-mfd";
|
||||
reg = <0x6f4000 0x1000>;
|
||||
|
||||
ap_clk: clock {
|
||||
compatible = "marvell,ap806-clock";
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
ap_pinctrl: pinctrl {
|
||||
compatible = "marvell,ap806-pinctrl";
|
||||
};
|
||||
|
||||
ap_gpio: gpio {
|
||||
compatible = "marvell,armada-8k-gpio";
|
||||
offset = <0x1040>;
|
||||
ngpios = <19>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
gpio-ranges = <&ap_pinctrl 0 0 19>;
|
||||
marvell,pwm-offset = <0x10c0>;
|
||||
#pwm-cells = <2>;
|
||||
clocks = <&ap_clk 3>;
|
||||
};
|
||||
};
|
||||
|
||||
SYSTEM CONTROLLER 1
|
||||
===================
|
||||
|
||||
Cluster clocks:
|
||||
---------------
|
||||
|
||||
Device Tree Clock bindings for cluster clock of Marvell
|
||||
AP806/AP807. Each cluster contain up to 2 CPUs running at the same
|
||||
frequency.
|
||||
|
||||
Required properties:
|
||||
- compatible: must be one of:
|
||||
* "marvell,ap806-cpu-clock"
|
||||
* "marvell,ap807-cpu-clock"
|
||||
- #clock-cells : should be set to 1.
|
||||
|
||||
- clocks : shall be the input parent clock(s) phandle for the clock
|
||||
(one per cluster)
|
||||
|
||||
- reg: register range associated with the cluster clocks
|
||||
|
||||
ap_syscon1: system-controller@6f8000 {
|
||||
compatible = "marvell,armada-ap806-syscon1", "syscon", "simple-mfd";
|
||||
reg = <0x6f8000 0x1000>;
|
||||
|
||||
cpu_clk: clock-cpu@278 {
|
||||
compatible = "marvell,ap806-cpu-clock";
|
||||
clocks = <&ap_clk 0>, <&ap_clk 1>;
|
||||
#clock-cells = <1>;
|
||||
reg = <0x278 0xa30>;
|
||||
};
|
||||
};
|
||||
|
|
@ -1,191 +0,0 @@
|
|||
Marvell Armada CP110 System Controller
|
||||
======================================
|
||||
|
||||
The CP110 is one of the two core HW blocks of the Marvell Armada 7K/8K
|
||||
SoCs. It contains system controllers, which provide several registers
|
||||
giving access to numerous features: clocks, pin-muxing and many other
|
||||
SoC configuration items. This DT binding allows to describe these
|
||||
system controllers.
|
||||
|
||||
For the top level node:
|
||||
- compatible: must be: "syscon", "simple-mfd";
|
||||
- reg: register area of the CP110 system controller
|
||||
|
||||
SYSTEM CONTROLLER 0
|
||||
===================
|
||||
|
||||
Clocks:
|
||||
-------
|
||||
|
||||
The Device Tree node representing this System Controller 0 provides a
|
||||
number of clocks:
|
||||
|
||||
- a set of core clocks
|
||||
- a set of gateable clocks
|
||||
|
||||
Those clocks can be referenced by other Device Tree nodes using two
|
||||
cells:
|
||||
- The first cell must be 0 or 1. 0 for the core clocks and 1 for the
|
||||
gateable clocks.
|
||||
- The second cell identifies the particular core clock or gateable
|
||||
clocks.
|
||||
|
||||
The following clocks are available:
|
||||
- Core clocks
|
||||
- 0 0 APLL
|
||||
- 0 1 PPv2 core
|
||||
- 0 2 EIP
|
||||
- 0 3 Core
|
||||
- 0 4 NAND core
|
||||
- 0 5 SDIO core
|
||||
- Gateable clocks
|
||||
- 1 0 Audio
|
||||
- 1 1 Comm Unit
|
||||
- 1 2 NAND
|
||||
- 1 3 PPv2
|
||||
- 1 4 SDIO
|
||||
- 1 5 MG Domain
|
||||
- 1 6 MG Core
|
||||
- 1 7 XOR1
|
||||
- 1 8 XOR0
|
||||
- 1 9 GOP DP
|
||||
- 1 11 PCIe x1 0
|
||||
- 1 12 PCIe x1 1
|
||||
- 1 13 PCIe x4
|
||||
- 1 14 PCIe / XOR
|
||||
- 1 15 SATA
|
||||
- 1 16 SATA USB
|
||||
- 1 17 Main
|
||||
- 1 18 SD/MMC/GOP
|
||||
- 1 21 Slow IO (SPI, NOR, BootROM, I2C, UART)
|
||||
- 1 22 USB3H0
|
||||
- 1 23 USB3H1
|
||||
- 1 24 USB3 Device
|
||||
- 1 25 EIP150
|
||||
- 1 26 EIP197
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: must be:
|
||||
"marvell,cp110-clock"
|
||||
- #clock-cells: must be set to 2
|
||||
|
||||
Pinctrl:
|
||||
--------
|
||||
|
||||
For common binding part and usage, refer to the file
|
||||
Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: "marvell,armada-7k-pinctrl", "marvell,armada-8k-cpm-pinctrl",
|
||||
"marvell,armada-8k-cps-pinctrl" or "marvell,cp115-standalone-pinctrl"
|
||||
depending on the specific variant of the SoC being used.
|
||||
|
||||
Available mpp pins/groups and functions:
|
||||
Note: brackets (x) are not part of the mpp name for marvell,function and given
|
||||
only for more detailed description in this document.
|
||||
|
||||
name pins functions
|
||||
================================================================================
|
||||
mpp0 0 gpio, dev(ale1), au(i2smclk), ge0(rxd3), tdm(pclk), ptp(pulse), mss_i2c(sda), uart0(rxd), sata0(present_act), ge(mdio)
|
||||
mpp1 1 gpio, dev(ale0), au(i2sdo_spdifo), ge0(rxd2), tdm(drx), ptp(clk), mss_i2c(sck), uart0(txd), sata1(present_act), ge(mdc)
|
||||
mpp2 2 gpio, dev(ad15), au(i2sextclk), ge0(rxd1), tdm(dtx), mss_uart(rxd), ptp(pclk_out), i2c1(sck), uart1(rxd), sata0(present_act), xg(mdc)
|
||||
mpp3 3 gpio, dev(ad14), au(i2slrclk), ge0(rxd0), tdm(fsync), mss_uart(txd), pcie(rstoutn), i2c1(sda), uart1(txd), sata1(present_act), xg(mdio)
|
||||
mpp4 4 gpio, dev(ad13), au(i2sbclk), ge0(rxctl), tdm(rstn), mss_uart(rxd), uart1(cts), pcie0(clkreq), uart3(rxd), ge(mdc)
|
||||
mpp5 5 gpio, dev(ad12), au(i2sdi), ge0(rxclk), tdm(intn), mss_uart(txd), uart1(rts), pcie1(clkreq), uart3(txd), ge(mdio)
|
||||
mpp6 6 gpio, dev(ad11), ge0(txd3), spi0(csn2), au(i2sextclk), sata1(present_act), pcie2(clkreq), uart0(rxd), ptp(pulse)
|
||||
mpp7 7 gpio, dev(ad10), ge0(txd2), spi0(csn1), spi1(csn1), sata0(present_act), led(data), uart0(txd), ptp(clk)
|
||||
mpp8 8 gpio, dev(ad9), ge0(txd1), spi0(csn0), spi1(csn0), uart0(cts), led(stb), uart2(rxd), ptp(pclk_out), synce1(clk)
|
||||
mpp9 9 gpio, dev(ad8), ge0(txd0), spi0(mosi), spi1(mosi), pcie(rstoutn), synce2(clk)
|
||||
mpp10 10 gpio, dev(readyn), ge0(txctl), spi0(miso), spi1(miso), uart0(cts), sata1(present_act)
|
||||
mpp11 11 gpio, dev(wen1), ge0(txclkout), spi0(clk), spi1(clk), uart0(rts), led(clk), uart2(txd), sata0(present_act)
|
||||
mpp12 12 gpio, dev(clk_out), nf(rbn1), spi1(csn1), ge0(rxclk)
|
||||
mpp13 13 gpio, dev(burstn), nf(rbn0), spi1(miso), ge0(rxctl), mss_spi(miso)
|
||||
mpp14 14 gpio, dev(bootcsn), dev(csn0), spi1(csn0), spi0(csn3), au(i2sextclk), spi0(miso), sata0(present_act), mss_spi(csn)
|
||||
mpp15 15 gpio, dev(ad7), spi1(mosi), spi0(mosi), mss_spi(mosi), ptp(pulse_cp2cp)
|
||||
mpp16 16 gpio, dev(ad6), spi1(clk), mss_spi(clk)
|
||||
mpp17 17 gpio, dev(ad5), ge0(txd3)
|
||||
mpp18 18 gpio, dev(ad4), ge0(txd2), ptp(clk_cp2cp)
|
||||
mpp19 19 gpio, dev(ad3), ge0(txd1), wakeup(out_cp2cp)
|
||||
mpp20 20 gpio, dev(ad2), ge0(txd0)
|
||||
mpp21 21 gpio, dev(ad1), ge0(txctl), sei(in_cp2cp)
|
||||
mpp22 22 gpio, dev(ad0), ge0(txclkout), wakeup(in_cp2cp)
|
||||
mpp23 23 gpio, dev(a1), au(i2smclk), link(rd_in_cp2cp)
|
||||
mpp24 24 gpio, dev(a0), au(i2slrclk)
|
||||
mpp25 25 gpio, dev(oen), au(i2sdo_spdifo)
|
||||
mpp26 26 gpio, dev(wen0), au(i2sbclk)
|
||||
mpp27 27 gpio, dev(csn0), spi1(miso), mss_gpio4, ge0(rxd3), spi0(csn4), ge(mdio), sata0(present_act), uart0(rts), rei(in_cp2cp)
|
||||
mpp28 28 gpio, dev(csn1), spi1(csn0), mss_gpio5, ge0(rxd2), spi0(csn5), pcie2(clkreq), ptp(pulse), ge(mdc), sata1(present_act), uart0(cts), led(data)
|
||||
mpp29 29 gpio, dev(csn2), spi1(mosi), mss_gpio6, ge0(rxd1), spi0(csn6), pcie1(clkreq), ptp(clk), mss_i2c(sda), sata0(present_act), uart0(rxd), led(stb)
|
||||
mpp30 30 gpio, dev(csn3), spi1(clk), mss_gpio7, ge0(rxd0), spi0(csn7), pcie0(clkreq), ptp(pclk_out), mss_i2c(sck), sata1(present_act), uart0(txd), led(clk)
|
||||
mpp31 31 gpio, dev(a2), mss_gpio4, pcie(rstoutn), ge(mdc)
|
||||
mpp32 32 gpio, mii(col), mii(txerr), mss_spi(miso), tdm(drx), au(i2sextclk), au(i2sdi), ge(mdio), sdio(v18_en), pcie1(clkreq), mss_gpio0
|
||||
mpp33 33 gpio, mii(txclk), sdio(pwr10), mss_spi(csn), tdm(fsync), au(i2smclk), sdio(bus_pwr), xg(mdio), pcie2(clkreq), mss_gpio1
|
||||
mpp34 34 gpio, mii(rxerr), sdio(pwr11), mss_spi(mosi), tdm(dtx), au(i2slrclk), sdio(wr_protect), ge(mdc), pcie0(clkreq), mss_gpio2
|
||||
mpp35 35 gpio, sata1(present_act), i2c1(sda), mss_spi(clk), tdm(pclk), au(i2sdo_spdifo), sdio(card_detect), xg(mdio), ge(mdio), pcie(rstoutn), mss_gpio3
|
||||
mpp36 36 gpio, synce2(clk), i2c1(sck), ptp(clk), synce1(clk), au(i2sbclk), sata0(present_act), xg(mdc), ge(mdc), pcie2(clkreq), mss_gpio5
|
||||
mpp37 37 gpio, uart2(rxd), i2c0(sck), ptp(pclk_out), tdm(intn), mss_i2c(sck), sata1(present_act), ge(mdc), xg(mdc), pcie1(clkreq), mss_gpio6, link(rd_out_cp2cp)
|
||||
mpp38 38 gpio, uart2(txd), i2c0(sda), ptp(pulse), tdm(rstn), mss_i2c(sda), sata0(present_act), ge(mdio), xg(mdio), au(i2sextclk), mss_gpio7, ptp(pulse_cp2cp)
|
||||
mpp39 39 gpio, sdio(wr_protect), au(i2sbclk), ptp(clk), spi0(csn1), sata1(present_act), mss_gpio0
|
||||
mpp40 40 gpio, sdio(pwr11), synce1(clk), mss_i2c(sda), au(i2sdo_spdifo), ptp(pclk_out), spi0(clk), uart1(txd), ge(mdio), sata0(present_act), mss_gpio1
|
||||
mpp41 41 gpio, sdio(pwr10), sdio(bus_pwr), mss_i2c(sck), au(i2slrclk), ptp(pulse), spi0(mosi), uart1(rxd), ge(mdc), sata1(present_act), mss_gpio2, rei(out_cp2cp)
|
||||
mpp42 42 gpio, sdio(v18_en), sdio(wr_protect), synce2(clk), au(i2smclk), mss_uart(txd), spi0(miso), uart1(cts), xg(mdc), sata0(present_act), mss_gpio4
|
||||
mpp43 43 gpio, sdio(card_detect), synce1(clk), au(i2sextclk), mss_uart(rxd), spi0(csn0), uart1(rts), xg(mdio), sata1(present_act), mss_gpio5, wakeup(out_cp2cp)
|
||||
mpp44 44 gpio, ge1(txd2), uart0(rts), ptp(clk_cp2cp)
|
||||
mpp45 45 gpio, ge1(txd3), uart0(txd), pcie(rstoutn)
|
||||
mpp46 46 gpio, ge1(txd1), uart1(rts)
|
||||
mpp47 47 gpio, ge1(txd0), spi1(clk), uart1(txd), ge(mdc)
|
||||
mpp48 48 gpio, ge1(txctl_txen), spi1(mosi), xg(mdc), wakeup(in_cp2cp)
|
||||
mpp49 49 gpio, ge1(txclkout), mii(crs), spi1(miso), uart1(rxd), ge(mdio), pcie0(clkreq), sdio(v18_en), sei(out_cp2cp)
|
||||
mpp50 50 gpio, ge1(rxclk), mss_i2c(sda), spi1(csn0), uart2(txd), uart0(rxd), xg(mdio), sdio(pwr11)
|
||||
mpp51 51 gpio, ge1(rxd0), mss_i2c(sck), spi1(csn1), uart2(rxd), uart0(cts), sdio(pwr10)
|
||||
mpp52 52 gpio, ge1(rxd1), synce1(clk), synce2(clk), spi1(csn2), uart1(cts), led(clk), pcie(rstoutn), pcie0(clkreq)
|
||||
mpp53 53 gpio, ge1(rxd2), ptp(clk), spi1(csn3), uart1(rxd), led(stb), sdio(led)
|
||||
mpp54 54 gpio, ge1(rxd3), synce2(clk), ptp(pclk_out), synce1(clk), led(data), sdio(hw_rst), sdio_wp(wr_protect)
|
||||
mpp55 55 gpio, ge1(rxctl_rxdv), ptp(pulse), sdio(led), sdio_cd(card_detect)
|
||||
mpp56 56 gpio, tdm(drx), au(i2sdo_spdifo), spi0(clk), uart1(rxd), sata1(present_act), sdio(clk)
|
||||
mpp57 57 gpio, mss_i2c(sda), ptp(pclk_out), tdm(intn), au(i2sbclk), spi0(mosi), uart1(txd), sata0(present_act), sdio(cmd)
|
||||
mpp58 58 gpio, mss_i2c(sck), ptp(clk), tdm(rstn), au(i2sdi), spi0(miso), uart1(cts), led(clk), sdio(d0)
|
||||
mpp59 59 gpio, mss_gpio7, synce2(clk), tdm(fsync), au(i2slrclk), spi0(csn0), uart0(cts), led(stb), uart1(txd), sdio(d1)
|
||||
mpp60 60 gpio, mss_gpio6, ptp(pulse), tdm(dtx), au(i2smclk), spi0(csn1), uart0(rts), led(data), uart1(rxd), sdio(d2)
|
||||
mpp61 61 gpio, mss_gpio5, ptp(clk), tdm(pclk), au(i2sextclk), spi0(csn2), uart0(txd), uart2(txd), sata1(present_act), ge(mdio), sdio(d3)
|
||||
mpp62 62 gpio, mss_gpio4, synce1(clk), ptp(pclk_out), sata1(present_act), spi0(csn3), uart0(rxd), uart2(rxd), sata0(present_act), ge(mdc)
|
||||
|
||||
GPIO:
|
||||
-----
|
||||
|
||||
For common binding part and usage, refer to
|
||||
Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: "marvell,armada-8k-gpio"
|
||||
|
||||
- offset: offset address inside the syscon block
|
||||
|
||||
Example:
|
||||
|
||||
CP110_LABEL(syscon0): system-controller@440000 {
|
||||
compatible = "syscon", "simple-mfd";
|
||||
reg = <0x440000 0x1000>;
|
||||
|
||||
CP110_LABEL(clk): clock {
|
||||
compatible = "marvell,cp110-clock";
|
||||
#clock-cells = <2>;
|
||||
};
|
||||
|
||||
CP110_LABEL(pinctrl): pinctrl {
|
||||
compatible = "marvell,armada-8k-cpm-pinctrl";
|
||||
};
|
||||
|
||||
CP110_LABEL(gpio1): gpio@100 {
|
||||
compatible = "marvell,armada-8k-gpio";
|
||||
offset = <0x100>;
|
||||
ngpios = <32>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
gpio-ranges = <&CP110_LABEL(pinctrl) 0 0 32>;
|
||||
};
|
||||
|
||||
};
|
||||
|
|
@ -38,6 +38,7 @@ properties:
|
|||
- const: mediatek,mt6580
|
||||
- items:
|
||||
- enum:
|
||||
- alcatel,yarisxl
|
||||
- prestigio,pmt5008-3g
|
||||
- const: mediatek,mt6582
|
||||
- items:
|
||||
|
|
@ -113,6 +114,12 @@ properties:
|
|||
- const: bananapi,bpi-r4-2g5
|
||||
- const: bananapi,bpi-r4
|
||||
- const: mediatek,mt7988a
|
||||
- items:
|
||||
- enum:
|
||||
- bananapi,bpi-r4-pro-4e
|
||||
- bananapi,bpi-r4-pro-8x
|
||||
- const: bananapi,bpi-r4-pro
|
||||
- const: mediatek,mt7988a
|
||||
- items:
|
||||
- enum:
|
||||
- mediatek,mt8127-moose
|
||||
|
|
@ -445,6 +452,7 @@ properties:
|
|||
- enum:
|
||||
- kontron,3-5-sbc-i1200
|
||||
- mediatek,mt8395-evk
|
||||
- mediatek,mt8395-evk-ufs
|
||||
- radxa,nio-12l
|
||||
- const: mediatek,mt8395
|
||||
- const: mediatek,mt8195
|
||||
|
|
|
|||
|
|
@ -163,7 +163,6 @@ examples:
|
|||
method = "smc";
|
||||
};
|
||||
|
||||
|
||||
- |+
|
||||
|
||||
// Case 3: PSCI v0.2 and PSCI v0.1.
|
||||
|
|
|
|||
|
|
@ -36,9 +36,12 @@ properties:
|
|||
$nodename:
|
||||
pattern: "^tpdm(@[0-9a-f]+)$"
|
||||
compatible:
|
||||
items:
|
||||
- const: qcom,coresight-tpdm
|
||||
- const: arm,primecell
|
||||
oneOf:
|
||||
- items:
|
||||
- const: qcom,coresight-static-tpdm
|
||||
- items:
|
||||
- const: qcom,coresight-tpdm
|
||||
- const: arm,primecell
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
@ -147,4 +150,18 @@ examples:
|
|||
};
|
||||
};
|
||||
};
|
||||
|
||||
turing-llm-tpdm {
|
||||
compatible = "qcom,coresight-static-tpdm";
|
||||
|
||||
qcom,cmb-element-bits = <32>;
|
||||
|
||||
out-ports {
|
||||
port {
|
||||
turing_llm_tpdm_out: endpoint {
|
||||
remote-endpoint = <&turing0_funnel_in1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
|
|
|
|||
|
|
@ -88,6 +88,7 @@ properties:
|
|||
|
||||
- items:
|
||||
- enum:
|
||||
- asus,z00t
|
||||
- huawei,kiwi
|
||||
- longcheer,l9100
|
||||
- samsung,a7
|
||||
|
|
@ -191,6 +192,11 @@ properties:
|
|||
- xiaomi,riva
|
||||
- const: qcom,msm8917
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- xiaomi,land
|
||||
- const: qcom,msm8937
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- flipkart,rimob
|
||||
|
|
@ -340,6 +346,7 @@ properties:
|
|||
- particle,tachyon
|
||||
- qcom,qcm6490-idp
|
||||
- qcom,qcs6490-rb3gen2
|
||||
- radxa,dragon-q6a
|
||||
- shift,otter
|
||||
- const: qcom,qcm6490
|
||||
|
||||
|
|
@ -893,6 +900,7 @@ properties:
|
|||
|
||||
- items:
|
||||
- enum:
|
||||
- huawei,planck
|
||||
- lenovo,yoga-c630
|
||||
- lg,judyln
|
||||
- lg,judyp
|
||||
|
|
@ -1083,7 +1091,13 @@ properties:
|
|||
|
||||
- items:
|
||||
- enum:
|
||||
- asus,zenbook-a14-ux3407qa
|
||||
- asus,zenbook-a14-ux3407qa-lcd
|
||||
- asus,zenbook-a14-ux3407qa-oled
|
||||
- const: asus,zenbook-a14-ux3407qa
|
||||
- const: qcom,x1p42100
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- hp,omnibook-x14-fe1
|
||||
- lenovo,thinkbook-16
|
||||
- qcom,x1p42100-crd
|
||||
|
|
@ -1167,6 +1181,7 @@ allOf:
|
|||
- qcom,apq8094
|
||||
- qcom,apq8096
|
||||
- qcom,msm8917
|
||||
- qcom,msm8937
|
||||
- qcom,msm8939
|
||||
- qcom,msm8953
|
||||
- qcom,msm8956
|
||||
|
|
|
|||
|
|
@ -15,6 +15,11 @@ properties:
|
|||
compatible:
|
||||
oneOf:
|
||||
|
||||
- description: 100ASK DshanPi A1 board
|
||||
items:
|
||||
- const: 100ask,dshanpi-a1
|
||||
- const: rockchip,rk3576
|
||||
|
||||
- description: 96boards RK3399 Ficus (ROCK960 Enterprise Edition)
|
||||
items:
|
||||
- const: vamrs,ficus
|
||||
|
|
@ -25,6 +30,12 @@ properties:
|
|||
- const: vamrs,rock960
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: 9Tripod X3568 series board
|
||||
items:
|
||||
- enum:
|
||||
- 9tripod,x3568-v4
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: Amarula Vyasa RK3288
|
||||
items:
|
||||
- const: amarula,vyasa-rk3288
|
||||
|
|
@ -78,13 +89,17 @@ properties:
|
|||
|
||||
- description: Asus Tinker board
|
||||
items:
|
||||
- const: asus,rk3288-tinker
|
||||
- enum:
|
||||
- asus,rk3288-tinker
|
||||
- asus,rk3288-tinker-s
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Asus Tinker board S
|
||||
- description: Asus Tinker Board 3/3S
|
||||
items:
|
||||
- const: asus,rk3288-tinker-s
|
||||
- const: rockchip,rk3288
|
||||
- enum:
|
||||
- asus,rk3566-tinker-board-3
|
||||
- asus,rk3566-tinker-board-3s
|
||||
- const: rockchip,rk3566
|
||||
|
||||
- description: Beelink A1
|
||||
items:
|
||||
|
|
@ -330,6 +345,11 @@ properties:
|
|||
- friendlyarm,nanopi-r6s
|
||||
- const: rockchip,rk3588s
|
||||
|
||||
- description: FriendlyElec NanoPi R76S
|
||||
items:
|
||||
- const: friendlyarm,nanopi-r76s
|
||||
- const: rockchip,rk3576
|
||||
|
||||
- description: FriendlyElec NanoPi Zero2
|
||||
items:
|
||||
- const: friendlyarm,nanopi-zero2
|
||||
|
|
@ -748,6 +768,11 @@ properties:
|
|||
- const: lckfb,tspi-rk3566
|
||||
- const: rockchip,rk3566
|
||||
|
||||
- description: LinkEase EasePi R1
|
||||
items:
|
||||
- const: linkease,easepi-r1
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: Luckfox Core3576 Module based boards
|
||||
items:
|
||||
- enum:
|
||||
|
|
@ -868,9 +893,11 @@ properties:
|
|||
- const: prt,mecsbc
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: QNAP TS-433-4G 4-Bay NAS
|
||||
- description: QNAP TS-x33 NAS devices
|
||||
items:
|
||||
- const: qnap,ts433
|
||||
- enum:
|
||||
- qnap,ts233
|
||||
- qnap,ts433
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: Radxa Compute Module 3 (CM3)
|
||||
|
|
|
|||
|
|
@ -189,6 +189,11 @@ properties:
|
|||
- nvidia,p2371-2180
|
||||
- nvidia,p2571
|
||||
- nvidia,p2894-0050-a08
|
||||
- nvidia,p3450-0000
|
||||
- const: nvidia,tegra210
|
||||
- items:
|
||||
- const: nvidia,p3541-0000
|
||||
- const: nvidia,p3450-0000
|
||||
- const: nvidia,tegra210
|
||||
- description: Jetson TX2 Developer Kit
|
||||
items:
|
||||
|
|
|
|||
|
|
@ -37,6 +37,12 @@ properties:
|
|||
- const: phytec,am62a-phycore-som
|
||||
- const: ti,am62a7
|
||||
|
||||
- description: K3 AM62L3 SoC and Boards
|
||||
items:
|
||||
- enum:
|
||||
- ti,am62l3-evm
|
||||
- const: ti,am62l3
|
||||
|
||||
- description: K3 AM62P5 SoC and Boards
|
||||
items:
|
||||
- enum:
|
||||
|
|
@ -158,6 +164,14 @@ properties:
|
|||
- ti,am654-evm
|
||||
- const: ti,am654
|
||||
|
||||
- description: K3 AM69 SoC Toradex Aquila Modules and Carrier Boards
|
||||
items:
|
||||
- enum:
|
||||
- toradex,aquila-am69-clover # Aquila AM69 Module on Clover Board
|
||||
- toradex,aquila-am69-dev # Aquila AM69 Module on Aquila Development Board
|
||||
- const: toradex,aquila-am69 # Aquila AM69 Module
|
||||
- const: ti,j784s4
|
||||
|
||||
- description: K3 J7200 SoC
|
||||
oneOf:
|
||||
- const: ti,j7200
|
||||
|
|
@ -194,6 +208,7 @@ properties:
|
|||
items:
|
||||
- enum:
|
||||
- beagle,am67a-beagley-ai
|
||||
- kontron,sa67 # Kontron SMARC-sAM67 board
|
||||
- ti,j722s-evm
|
||||
- const: ti,j722s
|
||||
|
||||
|
|
|
|||
|
|
@ -129,6 +129,13 @@ properties:
|
|||
- const: phytec,am335x-phycore-som
|
||||
- const: ti,am33xx
|
||||
|
||||
- description: TQ-Systems TQMa335x[L] SoM
|
||||
items:
|
||||
- enum:
|
||||
- tq,tqma3359-mba335x # MBa335x carrier board
|
||||
- const: tq,tqma3359
|
||||
- const: ti,am33xx
|
||||
|
||||
- description: TI OMAP4430 SoC based platforms
|
||||
items:
|
||||
- enum:
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Ux500 platforms
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Linus Walleij <linusw@kernel.org>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Generic Parallel ATA Controller
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Linus Walleij <linusw@kernel.org>
|
||||
|
||||
description:
|
||||
Generic Parallel ATA controllers supporting PIO modes only.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Cortina Systems Gemini SATA Bridge
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Linus Walleij <linusw@kernel.org>
|
||||
|
||||
description: |
|
||||
The Gemini SATA bridge in a SoC-internal PATA to SATA bridge that
|
||||
|
|
|
|||
|
|
@ -0,0 +1,79 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/ata/eswin,eic7700-ahci.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Eswin EIC7700 SoC SATA Controller
|
||||
|
||||
maintainers:
|
||||
- Yulin Lu <luyulin@eswincomputing.com>
|
||||
- Huan He <hehuan1@eswincomputing.com>
|
||||
|
||||
description:
|
||||
AHCI SATA controller embedded into the EIC7700 SoC is based on the DWC AHCI
|
||||
SATA v5.00a IP core.
|
||||
|
||||
select:
|
||||
properties:
|
||||
compatible:
|
||||
const: eswin,eic7700-ahci
|
||||
required:
|
||||
- compatible
|
||||
|
||||
allOf:
|
||||
- $ref: snps,dwc-ahci-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: eswin,eic7700-ahci
|
||||
- const: snps,dwc-ahci
|
||||
|
||||
clocks:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: pclk
|
||||
- const: aclk
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
reset-names:
|
||||
const: arst
|
||||
|
||||
ports-implemented:
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- clock-names
|
||||
- resets
|
||||
- reset-names
|
||||
- phys
|
||||
- phy-names
|
||||
- ports-implemented
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
sata@50420000 {
|
||||
compatible = "eswin,eic7700-ahci", "snps,dwc-ahci";
|
||||
reg = <0x50420000 0x10000>;
|
||||
interrupt-parent = <&plic>;
|
||||
interrupts = <58>;
|
||||
clocks = <&clock 171>, <&clock 186>;
|
||||
clock-names = "pclk", "aclk";
|
||||
phys = <&sata_phy>;
|
||||
phy-names = "sata-phy";
|
||||
ports-implemented = <0x1>;
|
||||
resets = <&reset 96>;
|
||||
reset-names = "arst";
|
||||
};
|
||||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Faraday Technology FTIDE010 PATA controller
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Linus Walleij <linusw@kernel.org>
|
||||
|
||||
description: |
|
||||
This controller is the first Faraday IDE interface block, used in the
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Intel IXP4xx CompactFlash Card Controller
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Linus Walleij <linusw@kernel.org>
|
||||
|
||||
description: |
|
||||
The IXP4xx network processors have a CompactFlash interface that presents
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Common Properties for Parallel AT attachment (PATA) controllers
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Linus Walleij <linusw@kernel.org>
|
||||
|
||||
description: |
|
||||
This document defines device tree properties common to most Parallel
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Common Properties for Serial AT attachment (SATA) controllers
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Linus Walleij <linusw@kernel.org>
|
||||
|
||||
description: |
|
||||
This document defines device tree properties common to most Serial
|
||||
|
|
|
|||
|
|
@ -33,6 +33,10 @@ properties:
|
|||
- description: SPEAr1340 AHCI SATA device
|
||||
const: snps,spear-ahci
|
||||
|
||||
iommus:
|
||||
minItems: 1
|
||||
maxItems: 3
|
||||
|
||||
patternProperties:
|
||||
"^sata-port@[0-9a-e]$":
|
||||
$ref: /schemas/ata/snps,dwc-ahci-common.yaml#/$defs/dwc-ahci-port
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: ARM Versatile Character LCD
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Linus Walleij <linusw@kernel.org>
|
||||
- Rob Herring <robh@kernel.org>
|
||||
|
||||
description:
|
||||
|
|
|
|||
|
|
@ -22,6 +22,13 @@ properties:
|
|||
- fsl,lx2160aqds-fpga
|
||||
- const: fsl,fpga-qixis-i2c
|
||||
- const: simple-mfd
|
||||
- const: fsl,lx2160ardb-fpga
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 0
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
|
@ -32,10 +39,37 @@ properties:
|
|||
mux-controller:
|
||||
$ref: /schemas/mux/reg-mux.yaml
|
||||
|
||||
patternProperties:
|
||||
"^gpio@[0-9a-f]+$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- fsl,lx2160ardb-fpga-gpio-sfp
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- fsl,lx2160ardb-fpga
|
||||
then:
|
||||
required:
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
else:
|
||||
properties:
|
||||
"#address-cells": false
|
||||
"#size-cells": false
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
|
|
@ -68,3 +102,27 @@ examples:
|
|||
};
|
||||
};
|
||||
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
board-control@66 {
|
||||
compatible = "fsl,lx2160ardb-fpga";
|
||||
reg = <0x66>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
gpio@19 {
|
||||
compatible = "fsl,lx2160ardb-fpga-gpio-sfp";
|
||||
reg = <0x19>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
gpio-line-names =
|
||||
"SFP2_TX_EN", "",
|
||||
"", "",
|
||||
"SFP2_RX_LOS", "SFP2_TX_FAULT",
|
||||
"", "SFP2_MOD_ABS";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -57,6 +57,16 @@ patternProperties:
|
|||
'^mdio-mux@[a-f0-9,]+$':
|
||||
$ref: /schemas/net/mdio-mux-mmioreg.yaml
|
||||
|
||||
'^gpio@[0-9a-f]+$':
|
||||
type: object
|
||||
additionalProperties: true
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- fsl,ls1046aqds-fpga-gpio-stat-pres2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ properties:
|
|||
maximum: 20000000
|
||||
|
||||
patternProperties:
|
||||
"^.*@[0-9a-fA-F]+$":
|
||||
"@[0-9a-f]+$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
properties:
|
||||
|
|
|
|||
94
Documentation/devicetree/bindings/bus/cznic,moxtet.yaml
Normal file
94
Documentation/devicetree/bindings/bus/cznic,moxtet.yaml
Normal file
|
|
@ -0,0 +1,94 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/bus/cznic,moxtet.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Turris Moxtet SPI bus
|
||||
|
||||
maintainers:
|
||||
- Marek Behún <kabel@kernel.org>
|
||||
|
||||
description: >
|
||||
Turris Mox module status and configuration bus (over SPI)
|
||||
|
||||
The driver finds the devices connected to the bus by itself, but it may be
|
||||
needed to reference some of them from other parts of the device tree. In that
|
||||
case the devices can be defined as subnodes of the moxtet node.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: cznic,moxtet
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 0
|
||||
|
||||
spi-cpol: true
|
||||
|
||||
spi-cpha: true
|
||||
|
||||
spi-max-frequency: true
|
||||
|
||||
interrupt-controller: true
|
||||
|
||||
"#interrupt-cells":
|
||||
const: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
reset-gpios:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
- spi-cpol
|
||||
- spi-cpha
|
||||
- interrupts
|
||||
- interrupt-controller
|
||||
- "#interrupt-cells"
|
||||
|
||||
additionalProperties:
|
||||
type: object
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
spi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
moxtet@1 {
|
||||
compatible = "cznic,moxtet";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <1>;
|
||||
spi-max-frequency = <10000000>;
|
||||
spi-cpol;
|
||||
spi-cpha;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&gpiosb>;
|
||||
interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
|
||||
|
||||
gpio@0 {
|
||||
compatible = "cznic,moxtet-gpio";
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
reg = <0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -70,7 +70,7 @@ properties:
|
|||
- const: ahb
|
||||
|
||||
patternProperties:
|
||||
"^.*@[0-9a-f]+$":
|
||||
"@[0-9a-f]+$":
|
||||
description: Devices attached to the bus
|
||||
type: object
|
||||
|
||||
|
|
|
|||
|
|
@ -1,46 +0,0 @@
|
|||
Turris Mox module status and configuration bus (over SPI)
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "cznic,moxtet"
|
||||
- #address-cells : Has to be 1
|
||||
- #size-cells : Has to be 0
|
||||
- spi-cpol : Required inverted clock polarity
|
||||
- spi-cpha : Required shifted clock phase
|
||||
- interrupts : Must contain reference to the shared interrupt line
|
||||
- interrupt-controller : Required
|
||||
- #interrupt-cells : Has to be 1
|
||||
|
||||
For other required and optional properties of SPI slave nodes please refer to
|
||||
../spi/spi-bus.txt.
|
||||
|
||||
Required properties of subnodes:
|
||||
- reg : Should be position on the Moxtet bus (how many Moxtet
|
||||
modules are between this module and CPU module, so
|
||||
either 0 or a positive integer)
|
||||
|
||||
The driver finds the devices connected to the bus by itself, but it may be
|
||||
needed to reference some of them from other parts of the device tree. In that
|
||||
case the devices can be defined as subnodes of the moxtet node.
|
||||
|
||||
Example:
|
||||
|
||||
moxtet@1 {
|
||||
compatible = "cznic,moxtet";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <1>;
|
||||
spi-max-frequency = <10000000>;
|
||||
spi-cpol;
|
||||
spi-cpha;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&gpiosb>;
|
||||
interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
|
||||
|
||||
moxtet_sfp: gpio@0 {
|
||||
compatible = "cznic,moxtet-gpio";
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
reg = <0>;
|
||||
}
|
||||
};
|
||||
|
|
@ -44,7 +44,7 @@ properties:
|
|||
Contains the firewall ID associated to the peripheral.
|
||||
|
||||
patternProperties:
|
||||
"^.*@[0-9a-f]+$":
|
||||
"@[0-9a-f]+$":
|
||||
description: Peripherals
|
||||
type: object
|
||||
|
||||
|
|
|
|||
|
|
@ -33,14 +33,18 @@ select:
|
|||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: st,stm32mp25-rifsc
|
||||
enum:
|
||||
- st,stm32mp21-rifsc
|
||||
- st,stm32mp25-rifsc
|
||||
required:
|
||||
- compatible
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: st,stm32mp25-rifsc
|
||||
- enum:
|
||||
- st,stm32mp21-rifsc
|
||||
- st,stm32mp25-rifsc
|
||||
- const: simple-bus
|
||||
|
||||
reg:
|
||||
|
|
@ -60,7 +64,7 @@ properties:
|
|||
Contains the firewall ID associated to the peripheral.
|
||||
|
||||
patternProperties:
|
||||
"^.*@[0-9a-f]+$":
|
||||
"@[0-9a-f]+$":
|
||||
description: Peripherals
|
||||
type: object
|
||||
|
||||
|
|
|
|||
|
|
@ -21,6 +21,7 @@ properties:
|
|||
compatible:
|
||||
enum:
|
||||
- qcom,ipq5424-llcc
|
||||
- qcom,kaanapali-llcc
|
||||
- qcom,qcs615-llcc
|
||||
- qcom,qcs8300-llcc
|
||||
- qcom,qdu1000-llcc
|
||||
|
|
@ -272,6 +273,7 @@ allOf:
|
|||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,kaanapali-llcc
|
||||
- qcom,sm8450-llcc
|
||||
- qcom,sm8550-llcc
|
||||
- qcom,sm8650-llcc
|
||||
|
|
|
|||
|
|
@ -48,6 +48,11 @@ properties:
|
|||
- const: microchip,mpfs-ccache
|
||||
- const: sifive,fu540-c000-ccache
|
||||
- const: cache
|
||||
- items:
|
||||
- const: microchip,pic64gx-ccache
|
||||
- const: microchip,mpfs-ccache
|
||||
- const: sifive,fu540-c000-ccache
|
||||
- const: cache
|
||||
|
||||
cache-block-size:
|
||||
const: 64
|
||||
|
|
|
|||
|
|
@ -64,8 +64,6 @@ allOf:
|
|||
reg:
|
||||
minItems: 2
|
||||
|
||||
'#reset-cells': false
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
|
|
@ -85,6 +83,7 @@ examples:
|
|||
reg = <0x1fa20000 0x400>,
|
||||
<0x1fb00000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
|
|
|
|||
|
|
@ -132,7 +132,6 @@ examples:
|
|||
"ahb_mp", "ahb_mali400";
|
||||
};
|
||||
|
||||
|
||||
- |
|
||||
clk@1c20068 {
|
||||
#clock-cells = <1>;
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue