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

Merge branch 'for-6.1/logitech' into for-linus

Browse Source 
- Add hanlding of all Bluetooth HID++ devices and fixes in hid++
  (Bastien Nocera)
This commit is contained in:
Benjamin Tissoires 2022-10-05 10:21:55 +01:00
commit edd1533d3c
5520 changed files with 371750 additions and 86014 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.clang-format
View File

@ -516,6 +516,7 @@ ForEachMacros:
- 'of_property_for_each_string'
- 'of_property_for_each_u32'
- 'pci_bus_for_each_resource'
- 'pci_doe_for_each_off'
- 'pcl_for_each_chunk'
- 'pcl_for_each_segment'
- 'pcm_for_each_format'

2
.get_maintainer.ignore
View File

@ -1,2 +1,4 @@
Alan Cox <alan@lxorguk.ukuu.org.uk>
Alan Cox <root@hraefn.swansea.linux.org.uk>
Christoph Hellwig <hch@lst.de>
Marc Gonzalez <marc.w.gonzalez@free.fr>

9
.mailmap
View File

@ -78,6 +78,7 @@ Boris Brezillon <bbrezillon@kernel.org> <b.brezillon.dev@gmail.com>
Boris Brezillon <bbrezillon@kernel.org> <b.brezillon@overkiz.com>
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@bootlin.com>
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@free-electrons.com>
Brendan Higgins <brendan.higgins@linux.dev> <brendanhiggins@google.com>
Brian Avery <b.avery@hp.com>
Brian King <brking@us.ibm.com>
Brian Silverman <bsilver16384@gmail.com> <brian.silverman@bluerivertech.com>
@ -97,8 +98,7 @@ Christian Brauner <brauner@kernel.org> <christian.brauner@ubuntu.com>
Christian Marangi <ansuelsmth@gmail.com>
Christophe Ricard <christophe.ricard@gmail.com>
Christoph Hellwig <hch@lst.de>
Colin Ian King <colin.king@intel.com> <colin.king@canonical.com>
Colin Ian King <colin.king@intel.com> <colin.i.king@gmail.com>
Colin Ian King <colin.i.king@gmail.com> <colin.king@canonical.com>
Corey Minyard <minyard@acm.org>
Damian Hobson-Garcia <dhobsong@igel.co.jp>
Daniel Borkmann <daniel@iogearbox.net> <danborkmann@googlemail.com>
@ -149,6 +149,8 @@ Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman <greg@kroah.com>
Greg Kurz <groug@kaod.org> <gkurz@linux.vnet.ibm.com>
Gregory CLEMENT <gregory.clement@bootlin.com> <gregory.clement@free-electrons.com>
Guilherme G. Piccoli <kernel@gpiccoli.net> <gpiccoli@linux.vnet.ibm.com>
Guilherme G. Piccoli <kernel@gpiccoli.net> <gpiccoli@canonical.com>
Guo Ren <guoren@kernel.org> <guoren@linux.alibaba.com>
Guo Ren <guoren@kernel.org> <ren_guo@c-sky.com>
Gustavo Padovan <gustavo@las.ic.unicamp.br>
@ -230,7 +232,7 @@ Kees Cook <keescook@chromium.org> <kees@ubuntu.com>
Keith Busch <kbusch@kernel.org> <keith.busch@intel.com>
Keith Busch <kbusch@kernel.org> <keith.busch@linux.intel.com>
Kenneth W Chen <kenneth.w.chen@intel.com>
Kirill Tkhai <kirill.tkhai@openvz.org> <ktkhai@virtuozzo.com>
Kirill Tkhai <tkhai@ya.ru> <ktkhai@virtuozzo.com>
Konstantin Khlebnikov <koct9i@gmail.com> <khlebnikov@yandex-team.ru>
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
Koushik <raghavendra.koushik@neterion.com>
@ -252,6 +254,7 @@ Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@web.de>
Li Yang <leoyang.li@nxp.com> <leoli@freescale.com>
Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
Lorenzo Pieralisi <lpieralisi@kernel.org> <lorenzo.pieralisi@arm.com>
Luca Ceresoli <luca.ceresoli@bootlin.com> <luca@lucaceresoli.net>
Lukasz Luba <lukasz.luba@arm.com> <l.luba@partner.samsung.com>
Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>
Maciej W. Rozycki <macro@orcam.me.uk> <macro@linux-mips.org>

81
Documentation/ABI/stable/sysfs-driver-mlxreg-io
View File

@ -1,7 +1,7 @@
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic_health
Date: June 2018
KernelVersion: 4.19
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: This file shows ASIC health status. The possible values are:
0 - health failed, 2 - health OK, 3 - ASIC in booting state.
@ -11,7 +11,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld1_version
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld2_version
Date: June 2018
KernelVersion: 4.19
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files show with which CPLD versions have been burned
on carrier and switch boards.
@ -20,7 +20,7 @@ Description: These files show with which CPLD versions have been burned
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/fan_dir
Date: December 2018
KernelVersion: 5.0
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: This file shows the system fans direction:
forward direction - relevant bit is set 0;
reversed direction - relevant bit is set 1.
@ -30,7 +30,7 @@ Description: This file shows the system fans direction:
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_version
Date: November 2018
KernelVersion: 5.0
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files show with which CPLD versions have been burned
on LED or Gearbox board.
@ -39,7 +39,7 @@ Description: These files show with which CPLD versions have been burned
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/jtag_enable
Date: November 2018
KernelVersion: 5.0
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files enable and disable the access to the JTAG domain.
By default access to the JTAG domain is disabled.
@ -48,7 +48,7 @@ Description: These files enable and disable the access to the JTAG domain.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/select_iio
Date: June 2018
KernelVersion: 4.19
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: This file allows iio devices selection.
Attribute select_iio can be written with 0 or with 1. It
@ -62,7 +62,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu1_on
/sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_down
Date: June 2018
KernelVersion: 4.19
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files allow asserting system power cycling, switching
power supply units on and off and system's main power domain
shutdown.
@ -89,7 +89,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_short_pb
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_sw_reset
Date: June 2018
KernelVersion: 4.19
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files show the system reset cause, as following: power
auxiliary outage or power refresh, ASIC thermal shutdown, halt,
hotswap, watchdog, firmware reset, long press power button,
@ -106,7 +106,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_system
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_voltmon_upgrade_fail
Date: November 2018
KernelVersion: 5.0
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files show the system reset cause, as following: ComEx
power fail, reset from ComEx, system platform reset, reset
due to voltage monitor devices upgrade failure,
@ -119,7 +119,7 @@ Description: These files show the system reset cause, as following: ComEx
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_version
Date: November 2018
KernelVersion: 5.0
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files show with which CPLD versions have been burned
on LED board.
@ -133,7 +133,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_sff_wd
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_swb_wd
Date: June 2019
KernelVersion: 5.3
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files show the system reset cause, as following:
COMEX thermal shutdown; wathchdog power off or reset was derived
by one of the next components: COMEX, switch board or by Small Form
@ -148,7 +148,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/config1
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/config2
Date: January 2020
KernelVersion: 5.6
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files show system static topology identification
like system's static I2C topology, number and type of FPGA
devices within the system and so on.
@ -161,7 +161,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_soc
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/reset_sw_pwr_off
Date: January 2020
KernelVersion: 5.6
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files show the system reset causes, as following: reset
due to AC power failure, reset invoked from software by
assertion reset signal through CPLD. reset caused by signal
@ -173,7 +173,7 @@ Description: These files show the system reset causes, as following: reset
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pcie_asic_reset_dis
Date: January 2020
KernelVersion: 5.6
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: This file allows to retain ASIC up during PCIe root complex
reset, when attribute is set 1.
@ -182,7 +182,7 @@ Description: This file allows to retain ASIC up during PCIe root complex
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/vpd_wp
Date: January 2020
KernelVersion: 5.6
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: This file allows to overwrite system VPD hardware write
protection when attribute is set 1.
@ -191,7 +191,7 @@ Description: This file allows to overwrite system VPD hardware write
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/voltreg_update_status
Date: January 2020
KernelVersion: 5.6
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: This file exposes the configuration update status of burnable
voltage regulator devices. The status values are as following:
0 - OK; 1 - CRC failure; 2 = I2C failure; 3 - in progress.
@ -201,7 +201,7 @@ Description: This file exposes the configuration update status of burnable
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/ufm_version
Date: January 2020
KernelVersion: 5.6
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: This file exposes the firmware version of burnable voltage
regulator devices.
@ -217,7 +217,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld3_version_min
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/cpld4_version_min
Date: July 2020
KernelVersion: 5.9
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files show with which CPLD part numbers and minor
versions have been burned CPLD devices equipped on a
system.
@ -471,7 +471,7 @@ Description: These files provide the maximum powered required for line card
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/phy_reset
Date: May 2022
KernelVersion: 5.19
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: This file allows to reset PHY 88E1548 when attribute is set 0
due to some abnormal PHY behavior.
Expected behavior:
@ -483,7 +483,7 @@ Description: This file allows to reset PHY 88E1548 when attribute is set 0
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/mac_reset
Date: May 2022
KernelVersion: 5.19
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: This file allows to reset ASIC MT52132 when attribute is set 0
due to some abnormal ASIC behavior.
Expected behavior:
@ -495,7 +495,7 @@ Description: This file allows to reset ASIC MT52132 when attribute is set 0
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/qsfp_pwr_good
Date: May 2022
KernelVersion: 5.19
Contact: Vadim Pasternak <vadimpmellanox.com>
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: This file shows QSFP ports power status. The value is set to 0
when one of any QSFP ports is plugged. The value is set to 1 when
there are no any QSFP ports are plugged.
@ -503,3 +503,42 @@ Description: This file shows QSFP ports power status. The value is set to 0
0 - Power good, 1 - Not power good.
The files are read only.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic2_health
Date: July 2022
KernelVersion: 5.20
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: This file shows 2-nd ASIC health status. The possible values are:
0 - health failed, 2 - health OK, 3 - ASIC in booting state.
The file is read only.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic_reset
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/asic2_reset
Date: July 2022
KernelVersion: 5.20
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: These files allow to each of ASICs by writing 1.
The files are write only.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/comm_chnl_ready
Date: July 2022
KernelVersion: 5.20
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: This file is used to indicate remote end (for example BMC) that system
host CPU is ready for sending telemetry data to remote end.
For indication the file should be written 1.
The file is write only.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/config3
Date: January 2020
KernelVersion: 5.6
Contact: Vadim Pasternak <vadimp@nvidia.com>
Description: The file indicates COME module hardware configuration.
The value is pushed by hardware through GPIO pins.
The purpose is to expose some minor BOM changes for the same system SKU.
The file is read only.

1
Documentation/ABI/testing/procfs-smaps_rollup
View File

@ -22,6 +22,7 @@ Description:
MMUPageSize: 4 kB
Rss: 884 kB
Pss: 385 kB
Pss_Dirty: 68 kB
Pss_Anon: 301 kB
Pss_File: 80 kB
Pss_Shmem: 4 kB

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

@ -7,6 +7,7 @@ Description:
all descendant memdevs for unbind. Writing '1' to this attribute
flushes that work.
What: /sys/bus/cxl/devices/memX/firmware_version
Date: December, 2020
KernelVersion: v5.12
@ -16,6 +17,7 @@ Description:
Memory Device Output Payload in the CXL-2.0
specification.
What: /sys/bus/cxl/devices/memX/ram/size
Date: December, 2020
KernelVersion: v5.12
@ -25,6 +27,7 @@ Description:
identically named field in the Identify Memory Device Output
Payload in the CXL-2.0 specification.
What: /sys/bus/cxl/devices/memX/pmem/size
Date: December, 2020
KernelVersion: v5.12
@ -34,6 +37,7 @@ Description:
identically named field in the Identify Memory Device Output
Payload in the CXL-2.0 specification.
What: /sys/bus/cxl/devices/memX/serial
Date: January, 2022
KernelVersion: v5.18
@ -43,6 +47,7 @@ Description:
capability. Mandatory for CXL devices, see CXL 2.0 8.1.12.2
Memory Device PCIe Capabilities and Extended Capabilities.
What: /sys/bus/cxl/devices/memX/numa_node
Date: January, 2022
KernelVersion: v5.18
@ -52,114 +57,334 @@ Description:
host PCI device for this memory device, emit the CPU node
affinity for this device.
What: /sys/bus/cxl/devices/*/devtype
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
CXL device objects export the devtype attribute which mirrors
the same value communicated in the DEVTYPE environment variable
for uevents for devices on the "cxl" bus.
(RO) CXL device objects export the devtype attribute which
mirrors the same value communicated in the DEVTYPE environment
variable for uevents for devices on the "cxl" bus.
What: /sys/bus/cxl/devices/*/modalias
Date: December, 2021
KernelVersion: v5.18
Contact: linux-cxl@vger.kernel.org
Description:
CXL device objects export the modalias attribute which mirrors
the same value communicated in the MODALIAS environment variable
for uevents for devices on the "cxl" bus.
(RO) CXL device objects export the modalias attribute which
mirrors the same value communicated in the MODALIAS environment
variable for uevents for devices on the "cxl" bus.
What: /sys/bus/cxl/devices/portX/uport
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
CXL port objects are enumerated from either a platform firmware
device (ACPI0017 and ACPI0016) or PCIe switch upstream port with
CXL component registers. The 'uport' symlink connects the CXL
portX object to the device that published the CXL port
(RO) CXL port objects are enumerated from either a platform
firmware device (ACPI0017 and ACPI0016) or PCIe switch upstream
port with CXL component registers. The 'uport' symlink connects
the CXL portX object to the device that published the CXL port
capability.
What: /sys/bus/cxl/devices/portX/dportY
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
CXL port objects are enumerated from either a platform firmware
device (ACPI0017 and ACPI0016) or PCIe switch upstream port with
CXL component registers. The 'dportY' symlink identifies one or
more downstream ports that the upstream port may target in its
decode of CXL memory resources. The 'Y' integer reflects the
hardware port unique-id used in the hardware decoder target
list.
(RO) CXL port objects are enumerated from either a platform
firmware device (ACPI0017 and ACPI0016) or PCIe switch upstream
port with CXL component registers. The 'dportY' symlink
identifies one or more downstream ports that the upstream port
may target in its decode of CXL memory resources. The 'Y'
integer reflects the hardware port unique-id used in the
hardware decoder target list.
What: /sys/bus/cxl/devices/decoderX.Y
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
CXL decoder objects are enumerated from either a platform
(RO) CXL decoder objects are enumerated from either a platform
firmware description, or a CXL HDM decoder register set in a
PCIe device (see CXL 2.0 section 8.2.5.12 CXL HDM Decoder
Capability Structure). The 'X' in decoderX.Y represents the
cxl_port container of this decoder, and 'Y' represents the
instance id of a given decoder resource.
What: /sys/bus/cxl/devices/decoderX.Y/{start,size}
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
The 'start' and 'size' attributes together convey the physical
address base and number of bytes mapped in the decoder's decode
window. For decoders of devtype "cxl_decoder_root" the address
range is fixed. For decoders of devtype "cxl_decoder_switch" the
address is bounded by the decode range of the cxl_port ancestor
of the decoder's cxl_port, and dynamically updates based on the
active memory regions in that address space.
(RO) The 'start' and 'size' attributes together convey the
physical address base and number of bytes mapped in the
decoder's decode window. For decoders of devtype
"cxl_decoder_root" the address range is fixed. For decoders of
devtype "cxl_decoder_switch" the address is bounded by the
decode range of the cxl_port ancestor of the decoder's cxl_port,
and dynamically updates based on the active memory regions in
that address space.
What: /sys/bus/cxl/devices/decoderX.Y/locked
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
CXL HDM decoders have the capability to lock the configuration
until the next device reset. For decoders of devtype
"cxl_decoder_root" there is no standard facility to unlock them.
For decoders of devtype "cxl_decoder_switch" a secondary bus
reset, of the PCIe bridge that provides the bus for this
decoders uport, unlocks / resets the decoder.
(RO) CXL HDM decoders have the capability to lock the
configuration until the next device reset. For decoders of
devtype "cxl_decoder_root" there is no standard facility to
unlock them. For decoders of devtype "cxl_decoder_switch" a
secondary bus reset, of the PCIe bridge that provides the bus
for this decoders uport, unlocks / resets the decoder.
What: /sys/bus/cxl/devices/decoderX.Y/target_list
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
Display a comma separated list of the current decoder target
configuration. The list is ordered by the current configured
interleave order of the decoder's dport instances. Each entry in
the list is a dport id.
(RO) Display a comma separated list of the current decoder
target configuration. The list is ordered by the current
configured interleave order of the decoder's dport instances.
Each entry in the list is a dport id.
What: /sys/bus/cxl/devices/decoderX.Y/cap_{pmem,ram,type2,type3}
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
When a CXL decoder is of devtype "cxl_decoder_root", it
(RO) When a CXL decoder is of devtype "cxl_decoder_root", it
represents a fixed memory window identified by platform
firmware. A fixed window may only support a subset of memory
types. The 'cap_*' attributes indicate whether persistent
memory, volatile memory, accelerator memory, and / or expander
memory may be mapped behind this decoder's memory window.
What: /sys/bus/cxl/devices/decoderX.Y/target_type
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
When a CXL decoder is of devtype "cxl_decoder_switch", it can
optionally decode either accelerator memory (type-2) or expander
memory (type-3). The 'target_type' attribute indicates the
current setting which may dynamically change based on what
(RO) When a CXL decoder is of devtype "cxl_decoder_switch", it
can optionally decode either accelerator memory (type-2) or
expander memory (type-3). The 'target_type' attribute indicates
the current setting which may dynamically change based on what
memory regions are activated in this decode hierarchy.
What: /sys/bus/cxl/devices/endpointX/CDAT
Date: July, 2022
KernelVersion: v5.20
Contact: linux-cxl@vger.kernel.org
Description:
(RO) If this sysfs entry is not present no DOE mailbox was
found to support CDAT data. If it is present and the length of
the data is 0 reading the CDAT data failed. Otherwise the CDAT
data is reported.
What: /sys/bus/cxl/devices/decoderX.Y/mode
Date: May, 2022
KernelVersion: v5.20
Contact: linux-cxl@vger.kernel.org
Description:
(RW) When a CXL decoder is of devtype "cxl_decoder_endpoint" it
translates from a host physical address range, to a device local
address range. Device-local address ranges are further split
into a 'ram' (volatile memory) range and 'pmem' (persistent
memory) range. The 'mode' attribute emits one of 'ram', 'pmem',
'mixed', or 'none'. The 'mixed' indication is for error cases
when a decoder straddles the volatile/persistent partition
boundary, and 'none' indicates the decoder is not actively
decoding, or no DPA allocation policy has been set.
'mode' can be written, when the decoder is in the 'disabled'
state, with either 'ram' or 'pmem' to set the boundaries for the
next allocation.
What: /sys/bus/cxl/devices/decoderX.Y/dpa_resource
Date: May, 2022
KernelVersion: v5.20
Contact: linux-cxl@vger.kernel.org
Description:
(RO) When a CXL decoder is of devtype "cxl_decoder_endpoint",
and its 'dpa_size' attribute is non-zero, this attribute
indicates the device physical address (DPA) base address of the
allocation.
What: /sys/bus/cxl/devices/decoderX.Y/dpa_size
Date: May, 2022
KernelVersion: v5.20
Contact: linux-cxl@vger.kernel.org
Description:
(RW) When a CXL decoder is of devtype "cxl_decoder_endpoint" it
translates from a host physical address range, to a device local
address range. The range, base address plus length in bytes, of
DPA allocated to this decoder is conveyed in these 2 attributes.
Allocations can be mutated as long as the decoder is in the
disabled state. A write to 'dpa_size' releases the previous DPA
allocation and then attempts to allocate from the free capacity
in the device partition referred to by 'decoderX.Y/mode'.
Allocate and free requests can only be performed on the highest
instance number disabled decoder with non-zero size. I.e.
allocations are enforced to occur in increasing 'decoderX.Y/id'
order and frees are enforced to occur in decreasing
'decoderX.Y/id' order.
What: /sys/bus/cxl/devices/decoderX.Y/interleave_ways
Date: May, 2022
KernelVersion: v5.20
Contact: linux-cxl@vger.kernel.org
Description:
(RO) The number of targets across which this decoder's host
physical address (HPA) memory range is interleaved. The device
maps every Nth block of HPA (of size ==
'interleave_granularity') to consecutive DPA addresses. The
decoder's position in the interleave is determined by the
device's (endpoint or switch) switch ancestry. For root
decoders their interleave is specified by platform firmware and
they only specify a downstream target order for host bridges.
What: /sys/bus/cxl/devices/decoderX.Y/interleave_granularity
Date: May, 2022
KernelVersion: v5.20
Contact: linux-cxl@vger.kernel.org
Description:
(RO) The number of consecutive bytes of host physical address
space this decoder claims at address N before the decode rotates
to the next target in the interleave at address N +
interleave_granularity (assuming N is aligned to
interleave_granularity).
What: /sys/bus/cxl/devices/decoderX.Y/create_pmem_region
Date: May, 2022
KernelVersion: v5.20
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Write a string in the form 'regionZ' to start the process
of defining a new persistent memory region (interleave-set)
within the decode range bounded by root decoder 'decoderX.Y'.
The value written must match the current value returned from
reading this attribute. An atomic compare exchange operation is
done on write to assign the requested id to a region and
allocate the region-id for the next creation attempt. EBUSY is
returned if the region name written does not match the current
cached value.
What: /sys/bus/cxl/devices/decoderX.Y/delete_region
Date: May, 2022
KernelVersion: v5.20
Contact: linux-cxl@vger.kernel.org
Description:
(WO) Write a string in the form 'regionZ' to delete that region,
provided it is currently idle / not bound to a driver.
What: /sys/bus/cxl/devices/regionZ/uuid
Date: May, 2022
KernelVersion: v5.20
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Write a unique identifier for the region. This field must
be set for persistent regions and it must not conflict with the
UUID of another region.
What: /sys/bus/cxl/devices/regionZ/interleave_granularity
Date: May, 2022
KernelVersion: v5.20
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Set the number of consecutive bytes each device in the
interleave set will claim. The possible interleave granularity
values are determined by the CXL spec and the participating
devices.
What: /sys/bus/cxl/devices/regionZ/interleave_ways
Date: May, 2022
KernelVersion: v5.20
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Configures the number of devices participating in the
region is set by writing this value. Each device will provide
1/interleave_ways of storage for the region.
What: /sys/bus/cxl/devices/regionZ/size
Date: May, 2022
KernelVersion: v5.20
Contact: linux-cxl@vger.kernel.org
Description:
(RW) System physical address space to be consumed by the region.
When written trigger the driver to allocate space out of the
parent root decoder's address space. When read the size of the
address space is reported and should match the span of the
region's resource attribute. Size shall be set after the
interleave configuration parameters. Once set it cannot be
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.
What: /sys/bus/cxl/devices/regionZ/resource
Date: May, 2022
KernelVersion: v5.20
Contact: linux-cxl@vger.kernel.org
Description:
(RO) A region is a contiguous partition of a CXL root decoder
address space. Region capacity is allocated by writing to the
size attribute, the resulting physical address space determined
by the driver is reflected here. It is therefore not useful to
read this before writing a value to the size attribute.
What: /sys/bus/cxl/devices/regionZ/target[0..N]
Date: May, 2022
KernelVersion: v5.20
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Write an endpoint decoder object name to 'targetX' where X
is the intended position of the endpoint device in the region
interleave and N is the 'interleave_ways' setting for the
region. ENXIO is returned if the write results in an impossible
to map decode scenario, like the endpoint is unreachable at that
position relative to the root decoder interleave. EBUSY is
returned if the position in the region is already occupied, or
if the region is not in a state to accept interleave
configuration changes. EINVAL is returned if the object name is
not an endpoint decoder. Once all positions have been
successfully written a final validation for decode conflicts is
performed before activating the region.
What: /sys/bus/cxl/devices/regionZ/commit
Date: May, 2022
KernelVersion: v5.20
Contact: linux-cxl@vger.kernel.org
Description:
(RW) Write a boolean 'true' string value to this attribute to
trigger the region to transition from the software programmed
state to the actively decoding in hardware state. The commit
operation in addition to validating that the region is in proper
configured state, validates that the decoders are being
committed in spec mandated order (last committed decoder id +
1), and checks that the hardware accepts the commit request.
Reading this value indicates whether the region is committed or
not.

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

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

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

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

1
Documentation/ABI/testing/sysfs-devices-system-cpu
View File

@ -523,6 +523,7 @@ What: /sys/devices/system/cpu/vulnerabilities
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
/sys/devices/system/cpu/vulnerabilities/itlb_multihit
/sys/devices/system/cpu/vulnerabilities/mmio_stale_data
/sys/devices/system/cpu/vulnerabilities/retbleed
Date: January 2018
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Information about CPU vulnerabilities

2
Documentation/ABI/testing/sysfs-driver-xen-blkback
View File

@ -42,5 +42,5 @@ KernelVersion: 5.10
Contact: Maximilian Heyne <mheyne@amazon.de>
Description:
Whether to enable the persistent grants feature or not. Note
that this option only takes effect on newly created backends.
that this option only takes effect on newly connected backends.
The default is Y (enable).

2
Documentation/ABI/testing/sysfs-driver-xen-blkfront
View File

@ -15,5 +15,5 @@ KernelVersion: 5.10
Contact: Maximilian Heyne <mheyne@amazon.de>
Description:
Whether to enable the persistent grants feature or not. Note
that this option only takes effect on newly created frontends.
that this option only takes effect on newly connected frontends.
The default is Y (enable).

30
Documentation/ABI/testing/sysfs-fs-f2fs
View File

@ -580,3 +580,33 @@ Date: January 2022
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: Controls max # of node block writes to be used for roll forward
recovery. This can limit the roll forward recovery time.
What: /sys/fs/f2fs/<disk>/unusable_blocks_per_sec
Date: June 2022
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>/current_atomic_write
Date: July 2022
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: Show the total current atomic write block count, which is not committed yet.
This is a read-only entry.
What: /sys/fs/f2fs/<disk>/peak_atomic_write
Date: July 2022
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: Show the peak value of total current atomic write block count after boot.
If you write "0" here, you can initialize to "0".
What: /sys/fs/f2fs/<disk>/committed_atomic_block
Date: July 2022
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: Show the accumulated total committed atomic write block count after boot.
If you write "0" here, you can initialize to "0".
What: /sys/fs/f2fs/<disk>/revoked_atomic_block
Date: July 2022
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: Show the accumulated total revoked atomic write block count after boot.
If you write "0" here, you can initialize to "0".

2
Documentation/ABI/testing/sysfs-kernel-mm-ksm
View File

@ -41,7 +41,7 @@ Description: Kernel Samepage Merging daemon sysfs interface
sleep_millisecs: how many milliseconds ksm should sleep between
scans.
See Documentation/vm/ksm.rst for more information.
See Documentation/mm/ksm.rst for more information.
What: /sys/kernel/mm/ksm/merge_across_nodes
Date: January 2013

4
Documentation/ABI/testing/sysfs-kernel-slab
View File

@ -37,7 +37,7 @@ Description:
The alloc_calls file is read-only and lists the kernel code
locations from which allocations for this cache were performed.
The alloc_calls file only contains information if debugging is
enabled for that cache (see Documentation/vm/slub.rst).
enabled for that cache (see Documentation/mm/slub.rst).
What: /sys/kernel/slab/<cache>/alloc_fastpath
Date: February 2008
@ -219,7 +219,7 @@ Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Description:
The free_calls file is read-only and lists the locations of
object frees if slab debugging is enabled (see
Documentation/vm/slub.rst).
Documentation/mm/slub.rst).
What: /sys/kernel/slab/<cache>/free_fastpath
Date: February 2008

2
Documentation/PCI/endpoint/index.rst
View File

@ -13,6 +13,8 @@ PCI Endpoint Framework
pci-test-howto
pci-ntb-function
pci-ntb-howto
pci-vntb-function
pci-vntb-howto
function/binding/pci-test
function/binding/pci-ntb

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

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

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

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

7
Documentation/PCI/pci-iov-howto.rst
View File

@ -125,14 +125,14 @@ Following piece of code illustrates the usage of the SR-IOV API.
...
}
static int dev_suspend(struct pci_dev *dev, pm_message_t state)
static int dev_suspend(struct device *dev)
{
...
return 0;
}
static int dev_resume(struct pci_dev *dev)
static int dev_resume(struct device *dev)
{
...
@ -165,8 +165,7 @@ Following piece of code illustrates the usage of the SR-IOV API.
.id_table = dev_id_table,
.probe = dev_probe,
.remove = dev_remove,
.suspend = dev_suspend,
.resume = dev_resume,
.driver.pm = &dev_pm_ops,
.shutdown = dev_shutdown,
.sriov_configure = dev_sriov_configure,
};

2
Documentation/PCI/sysfs-pci.rst
View File

@ -125,7 +125,7 @@ implementation of that functionality. To support the historical interface of
mmap() through files in /proc/bus/pci, platforms may also set HAVE_PCI_MMAP.
Alternatively, platforms which set HAVE_PCI_MMAP may provide their own
implementation of pci_mmap_page_range() instead of defining
implementation of pci_mmap_resource_range() instead of defining
ARCH_GENERIC_PCI_MMAP_RESOURCE.
Platforms which support write-combining maps of PCI resources must define

30
Documentation/admin-guide/README.rst
View File

@ -1,9 +1,9 @@
.. _readme:
Linux kernel release 5.x <http://kernel.org/>
Linux kernel release 6.x <http://kernel.org/>
=============================================
These are the release notes for Linux version 5. Read them carefully,
These are the release notes for Linux version 6. Read them carefully,
as they tell you what this is all about, explain how to install the
kernel, and what to do if something goes wrong.
@ -63,7 +63,7 @@ Installing the kernel source
directory where you have permissions (e.g. your home directory) and
unpack it::
xz -cd linux-5.x.tar.xz | tar xvf -
xz -cd linux-6.x.tar.xz | tar xvf -
Replace "X" with the version number of the latest kernel.
@ -72,12 +72,12 @@ Installing the kernel source
files. They should match the library, and not get messed up by
whatever the kernel-du-jour happens to be.
- You can also upgrade between 5.x releases by patching. Patches are
- You can also upgrade between 6.x releases by patching. Patches are
distributed in the xz format. To install by patching, get all the
newer patch files, enter the top level directory of the kernel source
(linux-5.x) and execute::
(linux-6.x) and execute::
xz -cd ../patch-5.x.xz | patch -p1
xz -cd ../patch-6.x.xz | patch -p1
Replace "x" for all versions bigger than the version "x" of your current
source tree, **in_order**, and you should be ok. You may want to remove
@ -85,13 +85,13 @@ Installing the kernel source
that there are no failed patches (some-file-name# or some-file-name.rej).
If there are, either you or I have made a mistake.
Unlike patches for the 5.x kernels, patches for the 5.x.y kernels
Unlike patches for the 6.x kernels, patches for the 6.x.y kernels
(also known as the -stable kernels) are not incremental but instead apply
directly to the base 5.x kernel. For example, if your base kernel is 5.0
and you want to apply the 5.0.3 patch, you must not first apply the 5.0.1
and 5.0.2 patches. Similarly, if you are running kernel version 5.0.2 and
want to jump to 5.0.3, you must first reverse the 5.0.2 patch (that is,
patch -R) **before** applying the 5.0.3 patch. You can read more on this in
directly to the base 6.x kernel. For example, if your base kernel is 6.0
and you want to apply the 6.0.3 patch, you must not first apply the 6.0.1
and 6.0.2 patches. Similarly, if you are running kernel version 6.0.2 and
want to jump to 6.0.3, you must first reverse the 6.0.2 patch (that is,
patch -R) **before** applying the 6.0.3 patch. You can read more on this in
:ref:`Documentation/process/applying-patches.rst <applying_patches>`.
Alternatively, the script patch-kernel can be used to automate this
@ -114,7 +114,7 @@ Installing the kernel source
Software requirements
---------------------
Compiling and running the 5.x kernels requires up-to-date
Compiling and running the 6.x kernels requires up-to-date
versions of various software packages. Consult
:ref:`Documentation/process/changes.rst <changes>` for the minimum version numbers
required and how to get updates for these packages. Beware that using
@ -132,12 +132,12 @@ Build directory for the kernel
place for the output files (including .config).
Example::
kernel source code: /usr/src/linux-5.x
kernel source code: /usr/src/linux-6.x
build directory: /home/name/build/kernel
To configure and build the kernel, use::
cd /usr/src/linux-5.x
cd /usr/src/linux-6.x
make O=/home/name/build/kernel menuconfig
make O=/home/name/build/kernel
sudo make O=/home/name/build/kernel modules_install install

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

@ -1237,6 +1237,13 @@ PAGE_SIZE multiple when read back.
the target cgroup. If less bytes are reclaimed than the
specified amount, -EAGAIN is returned.
Please note that the proactive reclaim (triggered by this
interface) is not meant to indicate memory pressure on the
memory cgroup. Therefore socket memory balancing triggered by
the memory reclaim normally is not exercised in this case.
This means that the networking layer will not adapt based on
reclaim induced by memory.reclaim.
memory.peak
A read-only single value file which exists on non-root
cgroups.
@ -1441,6 +1448,24 @@ PAGE_SIZE multiple when read back.
workingset_nodereclaim
Number of times a shadow node has been reclaimed
pgscan (npn)
Amount of scanned pages (in an inactive LRU list)
pgsteal (npn)
Amount of reclaimed pages
pgscan_kswapd (npn)
Amount of scanned pages by kswapd (in an inactive LRU list)
pgscan_direct (npn)
Amount of scanned pages directly (in an inactive LRU list)
pgsteal_kswapd (npn)
Amount of reclaimed pages by kswapd
pgsteal_direct (npn)
Amount of reclaimed pages directly
pgfault (npn)
Total number of page faults incurred
@ -1450,12 +1475,6 @@ PAGE_SIZE multiple when read back.
pgrefill (npn)
Amount of scanned pages (in an active LRU list)
pgscan (npn)
Amount of scanned pages (in an inactive LRU list)
pgsteal (npn)
Amount of reclaimed pages
pgactivate (npn)
Amount of pages moved to the active LRU list

14
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
View File

@ -230,6 +230,20 @@ The possible values in this file are:
* - 'Mitigation: Clear CPU buffers'
- The processor is vulnerable and the CPU buffer clearing mitigation is
enabled.
* - 'Unknown: No mitigations'
- The processor vulnerability status is unknown because it is
out of Servicing period. Mitigation is not attempted.
Definitions:
------------
Servicing period: The process of providing functional and security updates to
Intel processors or platforms, utilizing the Intel Platform Update (IPU)
process or other similar mechanisms.
End of Servicing Updates (ESU): ESU is the date at which Intel will no
longer provide Servicing, such as through IPU or other similar update
processes. ESU dates will typically be aligned to end of quarter.
If the processor is vulnerable then the following information is appended to
the above information:

8
Documentation/admin-guide/hw-vuln/spectre.rst
View File

@ -422,6 +422,14 @@ The possible values in this file are:
'RSB filling' Protection of RSB on context switch enabled
============= ===========================================
- EIBRS Post-barrier Return Stack Buffer (PBRSB) protection status:
=========================== =======================================================
'PBRSB-eIBRS: SW sequence' CPU is affected and protection of RSB on VMEXIT enabled
'PBRSB-eIBRS: Vulnerable' CPU is vulnerable
'PBRSB-eIBRS: Not affected' CPU is not affected by PBRSB
=========================== =======================================================
Full mitigation might require a microcode update from the CPU
vendor. When the necessary microcode is not available, the kernel will
report vulnerability.

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

@ -1158,8 +1158,12 @@
nopku [X86] Disable Memory Protection Keys CPU feature found
in some Intel CPUs.
<module>.async_probe [KNL]
Enable asynchronous probe on this module.
<module>.async_probe[=<bool>] [KNL]
If no <bool> value is specified or if the value
specified is not a valid <bool>, enable asynchronous
probe on this module. Otherwise, enable/disable
asynchronous probe on this module as indicated by the
<bool> value. See also: module.async_probe
early_ioremap_debug [KNL]
Enable debug messages in early_ioremap support. This
@ -1673,6 +1677,19 @@
hlt [BUGS=ARM,SH]
hostname= [KNL] Set the hostname (aka UTS nodename).
Format: <string>
This allows setting the system's hostname during early
startup. This sets the name returned by gethostname.
Using this parameter to set the hostname makes it
possible to ensure the hostname is correctly set before
any userspace processes run, avoiding the possibility
that a process may call gethostname before the hostname
has been explicitly set, resulting in the calling
process getting an incorrect result. The string must
not exceed the maximum allowed hostname length (usually
64 characters) and will be truncated otherwise.
hpet= [X86-32,HPET] option to control HPET usage
Format: { enable (default) | disable | force |
verbose }
@ -1718,19 +1735,22 @@
hugetlb_free_vmemmap=
[KNL] Reguires CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP
enabled.
Control if HugeTLB Vmemmap Optimization (HVO) is enabled.
Allows heavy hugetlb users to free up some more
memory (7 * PAGE_SIZE for each 2MB hugetlb page).
Format: { [oO][Nn]/Y/y/1 | [oO][Ff]/N/n/0 (default) }
Format: { on | off (default) }
[oO][Nn]/Y/y/1: enable the feature
[oO][Ff]/N/n/0: disable the feature
on: enable HVO
off: disable HVO
Built with CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON=y,
the default is on.
This is not compatible with memory_hotplug.memmap_on_memory.
If both parameters are enabled, hugetlb_free_vmemmap takes
precedence over memory_hotplug.memmap_on_memory.
Note that the vmemmap pages may be allocated from the added
memory block itself when memory_hotplug.memmap_on_memory is
enabled, those vmemmap pages cannot be optimized even if this
feature is enabled. Other vmemmap pages not allocated from
the added memory block itself do not be affected.
hung_task_panic=
[KNL] Should the hung task detector generate panics.
@ -2272,23 +2292,39 @@
ivrs_ioapic [HW,X86-64]
Provide an override to the IOAPIC-ID<->DEVICE-ID
mapping provided in the IVRS ACPI table. For
example, to map IOAPIC-ID decimal 10 to
PCI device 00:14.0 write the parameter as:
mapping provided in the IVRS ACPI table.
By default, PCI segment is 0, and can be omitted.
For example:
* To map IOAPIC-ID decimal 10 to PCI device 00:14.0
write the parameter as:
ivrs_ioapic[10]=00:14.0
* To map IOAPIC-ID decimal 10 to PCI segment 0x1 and
PCI device 00:14.0 write the parameter as:
ivrs_ioapic[10]=0001:00:14.0
ivrs_hpet [HW,X86-64]
Provide an override to the HPET-ID<->DEVICE-ID
mapping provided in the IVRS ACPI table. For
example, to map HPET-ID decimal 0 to
PCI device 00:14.0 write the parameter as:
mapping provided in the IVRS ACPI table.
By default, PCI segment is 0, and can be omitted.
For example:
* To map HPET-ID decimal 0 to PCI device 00:14.0
write the parameter as:
ivrs_hpet[0]=00:14.0
* To map HPET-ID decimal 10 to PCI segment 0x1 and
PCI device 00:14.0 write the parameter as:
ivrs_ioapic[10]=0001:00:14.0
ivrs_acpihid [HW,X86-64]
Provide an override to the ACPI-HID:UID<->DEVICE-ID
mapping provided in the IVRS ACPI table. For
example, to map UART-HID:UID AMD0020:0 to
PCI device 00:14.5 write the parameter as:
mapping provided in the IVRS ACPI table.
For example, to map UART-HID:UID AMD0020:0 to
PCI segment 0x1 and PCI device ID 00:14.5,
write the parameter as:
ivrs_acpihid[0001:00:14.5]=AMD0020:0
By default, PCI segment is 0, and can be omitted.
For example, PCI device 00:14.5 write the parameter as:
ivrs_acpihid[00:14.5]=AMD0020:0
js= [HW,JOY] Analog joystick
@ -3073,10 +3109,12 @@
[KNL,X86,ARM] Boolean flag to enable this feature.
Format: {on | off (default)}
When enabled, runtime hotplugged memory will
allocate its internal metadata (struct pages)
from the hotadded memory which will allow to
hotadd a lot of memory without requiring
additional memory to do so.
allocate its internal metadata (struct pages,
those vmemmap pages cannot be optimized even
if hugetlb_free_vmemmap is enabled) from the
hotadded memory which will allow to hotadd a
lot of memory without requiring additional
memory to do so.
This feature is disabled by default because it
has some implication on large (e.g. GB)
allocations in some configurations (e.g. small
@ -3086,10 +3124,6 @@
Note that even when enabled, there are a few cases where
the feature is not effective.
This is not compatible with hugetlb_free_vmemmap. If
both parameters are enabled, hugetlb_free_vmemmap takes
precedence over memory_hotplug.memmap_on_memory.
memtest= [KNL,X86,ARM,M68K,PPC,RISCV] Enable memtest
Format: <integer>
default : 0 <disable>
@ -3248,6 +3282,15 @@
For details see:
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
module.async_probe=<bool>
[KNL] When set to true, modules will use async probing
by default. To enable/disable async probing for a
specific module, use the module specific control that
is documented under <module>.async_probe. When both
module.async_probe and <module>.async_probe are
specified, <module>.async_probe takes precedence for
the specific module.
module.sig_enforce
[KNL] When CONFIG_MODULE_SIG is set, this means that
modules without (valid) signatures will fail to load.
@ -3537,9 +3580,6 @@
noautogroup Disable scheduler automatic task group creation.
nobats [PPC] Do not use BATs for mapping kernel lowmem
on "Classic" PPC cores.
nocache [ARM]
nodsp [SH] Disable hardware DSP at boot time.
@ -3709,9 +3749,6 @@
nolapic_timer [X86-32,APIC] Do not use the local APIC timer.
noltlbs [PPC] Do not use large page/tlb entries for kernel
lowmem mapping on PPC40x and PPC8xx
nomca [IA-64] Disable machine check abort handling
nomce [X86-32] Disable Machine Check Exception
@ -5237,20 +5274,33 @@
Speculative Code Execution with Return Instructions)
vulnerability.
AMD-based UNRET and IBPB mitigations alone do not stop
sibling threads from influencing the predictions of other
sibling threads. For that reason, STIBP is used on pro-
cessors that support it, and mitigate SMT on processors
that don't.
off - no mitigation
auto - automatically select a migitation
auto,nosmt - automatically select a mitigation,
disabling SMT if necessary for
the full mitigation (only on Zen1
and older without STIBP).
ibpb - mitigate short speculation windows on
basic block boundaries too. Safe, highest
perf impact.
unret - force enable untrained return thunks,
only effective on AMD f15h-f17h
based systems.
unret,nosmt - like unret, will disable SMT when STIBP
is not available.
ibpb - On AMD, mitigate short speculation
windows on basic block boundaries too.
Safe, highest perf impact. It also
enables STIBP if present. Not suitable
on Intel.
ibpb,nosmt - Like "ibpb" above but will disable SMT
when STIBP is not available. This is
the alternative for systems which do not
have STIBP.
unret - Force enable untrained return thunks,
only effective on AMD f15h-f17h based
systems.
unret,nosmt - Like unret, but will disable SMT when STIBP
is not available. This is the alternative for
systems which do not have STIBP.
Selecting 'auto' will choose a mitigation method at run
time according to the CPU.
@ -5281,6 +5331,8 @@
rodata= [KNL]
on Mark read-only kernel memory as read-only (default).
off Leave read-only kernel memory writable for debugging.
full Mark read-only kernel memory and aliases as read-only
[arm64]
rockchip.usb_uart
Enable the uart passthrough on the designated usb port
@ -5502,7 +5554,7 @@
cache (risks via metadata attacks are mostly
unchanged). Debug options disable merging on their
own.
For more information see Documentation/vm/slub.rst.
For more information see Documentation/mm/slub.rst.
slab_max_order= [MM, SLAB]
Determines the maximum allowed order for slabs.
@ -5516,13 +5568,13 @@
slub_debug can create guard zones around objects and
may poison objects when not in use. Also tracks the
last alloc / free. For more information see
Documentation/vm/slub.rst.
Documentation/mm/slub.rst.
slub_max_order= [MM, SLUB]
Determines the maximum allowed order for slabs.
A high setting may cause OOMs due to memory
fragmentation. For more information see
Documentation/vm/slub.rst.
Documentation/mm/slub.rst.
slub_min_objects= [MM, SLUB]
The minimum number of objects per slab. SLUB will
@ -5531,12 +5583,12 @@
the number of objects indicated. The higher the number
of objects the smaller the overhead of tracking slabs
and the less frequently locks need to be acquired.
For more information see Documentation/vm/slub.rst.
For more information see Documentation/mm/slub.rst.
slub_min_order= [MM, SLUB]
Determines the minimum page order for slabs. Must be
lower than slub_max_order.
For more information see Documentation/vm/slub.rst.
For more information see Documentation/mm/slub.rst.
slub_merge [MM, SLUB]
Same with slab_merge.
@ -5983,8 +6035,11 @@
it if 0 is given (See Documentation/admin-guide/cgroup-v1/memory.rst)
swiotlb= [ARM,IA-64,PPC,MIPS,X86]
Format: { <int> | force | noforce }
Format: { <int> [,<int>] | force | noforce }
<int> -- Number of I/O TLB slabs
<int> -- Second integer after comma. Number of swiotlb
areas with their own lock. Will be rounded up
to a power of 2.
force -- force using of bounce buffers even if they
wouldn't be automatically used by the kernel
noforce -- Never use bounce buffers (for debugging)

2
Documentation/admin-guide/mm/concepts.rst
View File

@ -125,7 +125,7 @@ processor. Each bank is referred to as a `node` and for each node Linux
constructs an independent memory management subsystem. A node has its
own set of zones, lists of free and used pages and various statistics
counters. You can find more details about NUMA in
:ref:`Documentation/vm/numa.rst <numa>` and in
:ref:`Documentation/mm/numa.rst <numa>` and in
:ref:`Documentation/admin-guide/mm/numa_memory_policy.rst <numa_memory_policy>`.
Page cache

3
Documentation/admin-guide/mm/damon/index.rst
View File

@ -4,7 +4,7 @@
Monitoring Data Accesses
========================
:doc:`DAMON </vm/damon/index>` allows light-weight data access monitoring.
:doc:`DAMON </mm/damon/index>` allows light-weight data access monitoring.
Using DAMON, users can analyze the memory access patterns of their systems and
optimize those.
@ -14,3 +14,4 @@ optimize those.
start
usage
reclaim
lru_sort

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

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

8
Documentation/admin-guide/mm/damon/reclaim.rst
View File

@ -48,12 +48,6 @@ DAMON_RECLAIM utilizes module parameters. That is, you can put
``damon_reclaim.<parameter>=<value>`` on the kernel boot command line or write
proper values to ``/sys/modules/damon_reclaim/parameters/<parameter>`` files.
Note that the parameter values except ``enabled`` are applied only when
DAMON_RECLAIM starts. Therefore, if you want to apply new parameter values in
runtime and DAMON_RECLAIM is already enabled, you should disable and re-enable
it via ``enabled`` parameter file. Writing of the new values to proper
parameter values should be done before the re-enablement.
Below are the description of each parameter.
enabled
@ -268,4 +262,4 @@ granularity reclamation. ::
.. [1] https://research.google/pubs/pub48551/
.. [2] https://lwn.net/Articles/787611/
.. [3] https://www.kernel.org/doc/html/latest/vm/free_page_reporting.html
.. [3] https://www.kernel.org/doc/html/latest/mm/free_page_reporting.html

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

@ -30,11 +30,11 @@ DAMON provides below interfaces for different users.
<sysfs_interface>`. This will be removed after next LTS kernel is released,
so users should move to the :ref:`sysfs interface <sysfs_interface>`.
- *Kernel Space Programming Interface.*
:doc:`This </vm/damon/api>` is for kernel space programmers. Using this,
:doc:`This </mm/damon/api>` is for kernel space programmers. Using this,
users can utilize every feature of DAMON most flexibly and efficiently by
writing kernel space DAMON application programs for you. You can even extend
DAMON for various address spaces. For detail, please refer to the interface
:doc:`document </vm/damon/api>`.
:doc:`document </mm/damon/api>`.
.. _sysfs_interface:
@ -50,10 +50,10 @@ For a short example, users can monitor the virtual address space of a given
workload as below. ::
# cd /sys/kernel/mm/damon/admin/
# echo 1 > kdamonds/nr && echo 1 > kdamonds/0/contexts/nr
# echo 1 > kdamonds/nr_kdamonds && echo 1 > kdamonds/0/contexts/nr_contexts
# echo vaddr > kdamonds/0/contexts/0/operations
# echo 1 > kdamonds/0/contexts/0/targets/nr
# echo $(pidof <workload>) > kdamonds/0/contexts/0/targets/0/pid
# echo 1 > kdamonds/0/contexts/0/targets/nr_targets
# echo $(pidof <workload>) > kdamonds/0/contexts/0/targets/0/pid_target
# echo on > kdamonds/0/state
Files Hierarchy
@ -185,7 +185,7 @@ controls the monitoring overhead, exist. You can set and get the values by
writing to and rading from the files.
For more details about the intervals and monitoring regions range, please refer
to the Design document (:doc:`/vm/damon/design`).
to the Design document (:doc:`/mm/damon/design`).
contexts/<N>/targets/
---------------------
@ -264,6 +264,8 @@ that can be written to and read from the file and their meaning are as below.
- ``pageout``: Call ``madvise()`` for the region with ``MADV_PAGEOUT``
- ``hugepage``: Call ``madvise()`` for the region with ``MADV_HUGEPAGE``
- ``nohugepage``: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE``
- ``lru_prio``: Prioritize the region on its LRU lists.
- ``lru_deprio``: Deprioritize the region on its LRU lists.
- ``stat``: Do nothing but count the statistics
schemes/<N>/access_pattern/
@ -364,12 +366,12 @@ memory rate becomes larger than 60%, or lower than 30%". ::
# echo 1 > kdamonds/0/contexts/0/schemes/nr_schemes
# cd kdamonds/0/contexts/0/schemes/0
# # set the basic access pattern and the action
# echo 4096 > access_patterns/sz/min
# echo 8192 > access_patterns/sz/max
# echo 0 > access_patterns/nr_accesses/min
# echo 5 > access_patterns/nr_accesses/max
# echo 10 > access_patterns/age/min
# echo 20 > access_patterns/age/max
# echo 4096 > access_pattern/sz/min
# echo 8192 > access_pattern/sz/max
# echo 0 > access_pattern/nr_accesses/min
# echo 5 > access_pattern/nr_accesses/max
# echo 10 > access_pattern/age/min
# echo 20 > access_pattern/age/max
# echo pageout > action
# # set quotas
# echo 10 > quotas/ms
@ -402,7 +404,7 @@ Attributes
Users can get and set the ``sampling interval``, ``aggregation interval``,
``update interval``, and min/max number of monitoring target regions by
reading from and writing to the ``attrs`` file. To know about the monitoring
attributes in detail, please refer to the :doc:`/vm/damon/design`. For
attributes in detail, please refer to the :doc:`/mm/damon/design`. For
example, below commands set those values to 5 ms, 100 ms, 1,000 ms, 10 and
1000, and then check it again::

4
Documentation/admin-guide/mm/hugetlbpage.rst
View File

@ -164,8 +164,8 @@ default_hugepagesz
will all result in 256 2M huge pages being allocated. Valid default
huge page size is architecture dependent.
hugetlb_free_vmemmap
When CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP is set, this enables optimizing
unused vmemmap pages associated with each HugeTLB page.
When CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP is set, this enables HugeTLB
Vmemmap Optimization (HVO).
When multiple huge page sizes are supported, ``/proc/sys/vm/nr_hugepages``
indicates the current number of pre-allocated huge pages of the default size.

1
Documentation/admin-guide/mm/index.rst
View File

@ -36,6 +36,7 @@ the Linux memory management.
numa_memory_policy
numaperf
pagemap
shrinker_debugfs
soft-dirty
swap_numa
transhuge

4
Documentation/admin-guide/mm/memory-hotplug.rst
View File

@ -653,8 +653,8 @@ block might fail:
- Concurrent activity that operates on the same physical memory area, such as
allocating gigantic pages, can result in temporary offlining failures.
- Out of memory when dissolving huge pages, especially when freeing unused
vmemmap pages associated with each hugetlb page is enabled.
- Out of memory when dissolving huge pages, especially when HugeTLB Vmemmap
Optimization (HVO) is enabled.
Offlining code may be able to migrate huge page contents, but may not be able
to dissolve the source huge page because it fails allocating (unmovable) pages

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

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

12
Documentation/admin-guide/sysctl/kernel.rst
View File

@ -592,6 +592,18 @@ to the guest kernel command line (see
Documentation/admin-guide/kernel-parameters.rst).
nmi_wd_lpm_factor (PPC only)
============================
Factor to apply to the NMI watchdog timeout (only when ``nmi_watchdog`` is
set to 1). This factor represents the percentage added to
``watchdog_thresh`` when calculating the NMI watchdog timeout during an
LPM. The soft lockup timeout is not impacted.
A value of 0 means no change. The default value is 200 meaning the NMI
watchdog is set to 30s (based on ``watchdog_thresh`` equal to 10).
numa_balancing
==============

2
Documentation/admin-guide/sysctl/net.rst
View File

@ -271,7 +271,7 @@ poll cycle or the number of packets processed reaches netdev_budget.
netdev_max_backlog
------------------
Maximum number of packets, queued on the INPUT side, when the interface
Maximum number of packets, queued on the INPUT side, when the interface
receives packets faster than kernel can process them.
netdev_rss_key

10
Documentation/admin-guide/sysctl/vm.rst
View File

@ -565,13 +565,11 @@ See Documentation/admin-guide/mm/hugetlbpage.rst
hugetlb_optimize_vmemmap
========================
This knob is not available when memory_hotplug.memmap_on_memory (kernel parameter)
is configured or the size of 'struct page' (a structure defined in
include/linux/mm_types.h) is not power of two (an unusual system config could
This knob is not available when the size of 'struct page' (a structure defined
in include/linux/mm_types.h) is not power of two (an unusual system config could
result in this).
Enable (set to 1) or disable (set to 0) the feature of optimizing vmemmap pages
associated with each HugeTLB page.
Enable (set to 1) or disable (set to 0) HugeTLB Vmemmap Optimization (HVO).
Once enabled, the vmemmap pages of subsequent allocation of HugeTLB pages from
buddy allocator will be optimized (7 pages per 2MB HugeTLB page and 4095 pages
@ -760,7 +758,7 @@ and don't use much of it.
The default value is 0.
See Documentation/vm/overcommit-accounting.rst and
See Documentation/mm/overcommit-accounting.rst and
mm/util.c::__vm_enough_memory() for more information.

10
Documentation/arm64/elf_hwcaps.rst
View File

@ -242,44 +242,34 @@ HWCAP2_MTE3
by Documentation/arm64/memory-tagging-extension.rst.
HWCAP2_SME
Functionality implied by ID_AA64PFR1_EL1.SME == 0b0001, as described
by Documentation/arm64/sme.rst.
HWCAP2_SME_I16I64
Functionality implied by ID_AA64SMFR0_EL1.I16I64 == 0b1111.
HWCAP2_SME_F64F64
Functionality implied by ID_AA64SMFR0_EL1.F64F64 == 0b1.
HWCAP2_SME_I8I32
Functionality implied by ID_AA64SMFR0_EL1.I8I32 == 0b1111.
HWCAP2_SME_F16F32
Functionality implied by ID_AA64SMFR0_EL1.F16F32 == 0b1.
HWCAP2_SME_B16F32
Functionality implied by ID_AA64SMFR0_EL1.B16F32 == 0b1.
HWCAP2_SME_F32F32
Functionality implied by ID_AA64SMFR0_EL1.F32F32 == 0b1.
HWCAP2_SME_FA64
Functionality implied by ID_AA64SMFR0_EL1.FA64 == 0b1.
HWCAP2_WFXT
Functionality implied by ID_AA64ISAR2_EL1.WFXT == 0b0010.
HWCAP2_EBF16
Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0010.
4. Unused AT_HWCAP bits

2
Documentation/arm64/silicon-errata.rst
View File

@ -52,6 +52,8 @@ stable kernels.
| Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2038923 | ARM64_ERRATUM_2038923 |

10
Documentation/atomic_bitops.txt
View File

@ -58,13 +58,11 @@ Like with atomic_t, the rule of thumb is:
- RMW operations that have a return value are fully ordered.
- RMW operations that are conditional are unordered on FAILURE,
otherwise the above rules apply. In the case of test_and_{}_bit() operations,
if the bit in memory is unchanged by the operation then it is deemed to have
failed.
- RMW operations that are conditional are fully ordered.
Except for a successful test_and_set_bit_lock() which has ACQUIRE semantics and
clear_bit_unlock() which has RELEASE semantics.
Except for a successful test_and_set_bit_lock() which has ACQUIRE semantics,
clear_bit_unlock() which has RELEASE semantics and test_bit_acquire which has
ACQUIRE semantics.
Since a platform only has a single means of achieving atomic operations
the same barriers as for atomic_t are used, see atomic_t.txt.

22
Documentation/block/null_blk.rst
View File

@ -72,6 +72,28 @@ submit_queues=[1..nr_cpus]: Default: 1
hw_queue_depth=[0..qdepth]: Default: 64
The hardware queue depth of the device.
memory_backed=[0/1]: Default: 0
Whether or not to use a memory buffer to respond to IO requests
= =============================================
0 Transfer no data in response to IO requests
1 Use a memory buffer to respond to IO requests
= =============================================
discard=[0/1]: Default: 0
Support discard operations (requires memory-backed null_blk device).
= =====================================
0 Do not support discard operations
1 Enable support for discard operations
= =====================================
cache_size=[Size in MB]: Default: 0
Cache size in MB for memory-backed device.
mbps=[Maximum bandwidth in MB/s]: Default: 0 (no limit)
Bandwidth limit for device performance.
Multi-queue specific parameters
-------------------------------

25
Documentation/bpf/bpf_design_QA.rst
View File

@ -214,6 +214,12 @@ A: NO. Tracepoints are tied to internal implementation details hence they are
subject to change and can break with newer kernels. BPF programs need to change
accordingly when this happens.
Q: Are places where kprobes can attach part of the stable ABI?
--------------------------------------------------------------
A: NO. The places to which kprobes can attach are internal implementation
details, which means that they are subject to change and can break with
newer kernels. BPF programs need to change accordingly when this happens.
Q: How much stack space a BPF program uses?
-------------------------------------------
A: Currently all program types are limited to 512 bytes of stack
@ -273,3 +279,22 @@ cc (congestion-control) implementations. If any of these kernel
functions has changed, both the in-tree and out-of-tree kernel tcp cc
implementations have to be changed. The same goes for the bpf
programs and they have to be adjusted accordingly.
Q: Attaching to arbitrary kernel functions is an ABI?
-----------------------------------------------------
Q: BPF programs can be attached to many kernel functions. Do these
kernel functions become part of the ABI?
A: NO.
The kernel function prototypes will change, and BPF programs attaching to
them will need to change. The BPF compile-once-run-everywhere (CO-RE)
should be used in order to make it easier to adapt your BPF programs to
different versions of the kernel.
Q: Marking a function with BTF_ID makes that function an ABI?
-------------------------------------------------------------
A: NO.
The BTF_ID macro does not cause a function to become part of the ABI
any more than does the EXPORT_SYMBOL_GPL macro.

1
Documentation/conf.py
View File

@ -86,6 +86,7 @@ if major >= 3:
"__used",
"__weak",
"noinline",
"__fix_address",
# include/linux/memblock.h:
"__init_memblock",

220
Documentation/core-api/bus-virt-phys-mapping.rst
View File

@ -1,220 +0,0 @@
==========================================================
How to access I/O mapped memory from within device drivers
==========================================================
:Author: Linus
.. warning::
The virt_to_bus() and bus_to_virt() functions have been
superseded by the functionality provided by the PCI DMA interface
(see Documentation/core-api/dma-api-howto.rst). They continue
to be documented below for historical purposes, but new code
must not use them. --davidm 00/12/12
::
[ This is a mail message in response to a query on IO mapping, thus the
strange format for a "document" ]
The AHA-1542 is a bus-master device, and your patch makes the driver give the
controller the physical address of the buffers, which is correct on x86
(because all bus master devices see the physical memory mappings directly).
However, on many setups, there are actually **three** different ways of looking
at memory addresses, and in this case we actually want the third, the
so-called "bus address".
Essentially, the three ways of addressing memory are (this is "real memory",
that is, normal RAM--see later about other details):
- CPU untranslated. This is the "physical" address. Physical address
0 is what the CPU sees when it drives zeroes on the memory bus.
- CPU translated address. This is the "virtual" address, and is
completely internal to the CPU itself with the CPU doing the appropriate
translations into "CPU untranslated".
- bus address. This is the address of memory as seen by OTHER devices,
not the CPU. Now, in theory there could be many different bus
addresses, with each device seeing memory in some device-specific way, but
happily most hardware designers aren't actually actively trying to make
things any more complex than necessary, so you can assume that all
external hardware sees the memory the same way.
Now, on normal PCs the bus address is exactly the same as the physical
address, and things are very simple indeed. However, they are that simple
because the memory and the devices share the same address space, and that is
not generally necessarily true on other PCI/ISA setups.
Now, just as an example, on the PReP (PowerPC Reference Platform), the
CPU sees a memory map something like this (this is from memory)::
0-2 GB "real memory"
2 GB-3 GB "system IO" (inb/out and similar accesses on x86)
3 GB-4 GB "IO memory" (shared memory over the IO bus)
Now, that looks simple enough. However, when you look at the same thing from
the viewpoint of the devices, you have the reverse, and the physical memory
address 0 actually shows up as address 2 GB for any IO master.
So when the CPU wants any bus master to write to physical memory 0, it
has to give the master address 0x80000000 as the memory address.
So, for example, depending on how the kernel is actually mapped on the
PPC, you can end up with a setup like this::
physical address: 0
virtual address: 0xC0000000
bus address: 0x80000000
where all the addresses actually point to the same thing. It's just seen
through different translations..
Similarly, on the Alpha, the normal translation is::
physical address: 0
virtual address: 0xfffffc0000000000
bus address: 0x40000000
(but there are also Alphas where the physical address and the bus address
are the same).
Anyway, the way to look up all these translations, you do::
#include <asm/io.h>
phys_addr = virt_to_phys(virt_addr);
virt_addr = phys_to_virt(phys_addr);
bus_addr = virt_to_bus(virt_addr);
virt_addr = bus_to_virt(bus_addr);
Now, when do you need these?
You want the **virtual** address when you are actually going to access that
pointer from the kernel. So you can have something like this::
/*
* this is the hardware "mailbox" we use to communicate with
* the controller. The controller sees this directly.
*/
struct mailbox {
__u32 status;
__u32 bufstart;
__u32 buflen;
..
} mbox;
unsigned char * retbuffer;
/* get the address from the controller */
retbuffer = bus_to_virt(mbox.bufstart);
switch (retbuffer[0]) {
case STATUS_OK:
...
on the other hand, you want the bus address when you have a buffer that
you want to give to the controller::
/* ask the controller to read the sense status into "sense_buffer" */
mbox.bufstart = virt_to_bus(&sense_buffer);
mbox.buflen = sizeof(sense_buffer);
mbox.status = 0;
notify_controller(&mbox);
And you generally **never** want to use the physical address, because you can't
use that from the CPU (the CPU only uses translated virtual addresses), and
you can't use it from the bus master.
So why do we care about the physical address at all? We do need the physical
address in some cases, it's just not very often in normal code. The physical
address is needed if you use memory mappings, for example, because the
"remap_pfn_range()" mm function wants the physical address of the memory to
be remapped as measured in units of pages, a.k.a. the pfn (the memory
management layer doesn't know about devices outside the CPU, so it
shouldn't need to know about "bus addresses" etc).
.. note::
The above is only one part of the whole equation. The above
only talks about "real memory", that is, CPU memory (RAM).
There is a completely different type of memory too, and that's the "shared
memory" on the PCI or ISA bus. That's generally not RAM (although in the case
of a video graphics card it can be normal DRAM that is just used for a frame
buffer), but can be things like a packet buffer in a network card etc.
This memory is called "PCI memory" or "shared memory" or "IO memory" or
whatever, and there is only one way to access it: the readb/writeb and
related functions. You should never take the address of such memory, because
there is really nothing you can do with such an address: it's not
conceptually in the same memory space as "real memory" at all, so you cannot
just dereference a pointer. (Sadly, on x86 it **is** in the same memory space,
so on x86 it actually works to just deference a pointer, but it's not
portable).
For such memory, you can do things like:
- reading::
/*
* read first 32 bits from ISA memory at 0xC0000, aka
* C000:0000 in DOS terms
*/
unsigned int signature = isa_readl(0xC0000);
- remapping and writing::
/*
* remap framebuffer PCI memory area at 0xFC000000,
* size 1MB, so that we can access it: We can directly
* access only the 640k-1MB area, so anything else
* has to be remapped.
*/
void __iomem *baseptr = ioremap(0xFC000000, 1024*1024);
/* write a 'A' to the offset 10 of the area */
writeb('A',baseptr+10);
/* unmap when we unload the driver */
iounmap(baseptr);
- copying and clearing::
/* get the 6-byte Ethernet address at ISA address E000:0040 */
memcpy_fromio(kernel_buffer, 0xE0040, 6);
/* write a packet to the driver */
memcpy_toio(0xE1000, skb->data, skb->len);
/* clear the frame buffer */
memset_io(0xA0000, 0, 0x10000);
OK, that just about covers the basics of accessing IO portably. Questions?
Comments? You may think that all the above is overly complex, but one day you
might find yourself with a 500 MHz Alpha in front of you, and then you'll be
happy that your driver works ;)
Note that kernel versions 2.0.x (and earlier) mistakenly called the
ioremap() function "vremap()". ioremap() is the proper name, but I
didn't think straight when I wrote it originally. People who have to
support both can do something like::
/* support old naming silliness */
#if LINUX_VERSION_CODE < 0x020100
#define ioremap vremap
#define iounmap vfree
#endif
at the top of their source files, and then they can use the right names
even on 2.0.x systems.
And the above sounds worse than it really is. Most real drivers really
don't do all that complex things (or rather: the complexity is not so
much in the actual IO accesses as in error handling and timeouts etc).
It's generally not hard to fix drivers, and in many cases the code
actually looks better afterwards::
unsigned long signature = *(unsigned int *) 0xC0000;
vs
unsigned long signature = readl(0xC0000);
I think the second version actually is more readable, no?

14
Documentation/core-api/dma-api-howto.rst
View File

@ -707,20 +707,6 @@ to use the dma_sync_*() interfaces::
}
}
Drivers converted fully to this interface should not use virt_to_bus() any
longer, nor should they use bus_to_virt(). Some drivers have to be changed a
little bit, because there is no longer an equivalent to bus_to_virt() in the
dynamic DMA mapping scheme - you have to always store the DMA addresses
returned by the dma_alloc_coherent(), dma_pool_alloc(), and dma_map_single()
calls (dma_map_sg() stores them in the scatterlist itself if the platform
supports dynamic DMA mapping in hardware) in your driver structures and/or
in the card registers.
All drivers should be using these interfaces with no exceptions. It
is planned to completely remove virt_to_bus() and bus_to_virt() as
they are entirely deprecated. Some ports already do not provide these
as it is impossible to correctly support them.
Handling Errors
===============

14
Documentation/core-api/dma-api.rst
View File

@ -204,6 +204,20 @@ Returns the maximum size of a mapping for the device. The size parameter
of the mapping functions like dma_map_single(), dma_map_page() and
others should not be larger than the returned value.
::
size_t
dma_opt_mapping_size(struct device *dev);
Returns the maximum optimal size of a mapping for the device.
Mapping larger buffers may take much longer in certain scenarios. In
addition, for high-rate short-lived streaming mappings, the upfront time
spent on the mapping may account for an appreciable part of the total
request lifetime. As such, if splitting larger requests incurs no
significant performance penalty, then device drivers are advised to
limit total DMA streaming mappings length to the returned value.
::
bool

3
Documentation/core-api/index.rst
View File

@ -41,7 +41,6 @@ Library functionality that is used throughout the kernel.
rbtree
generic-radix-tree
packing
bus-virt-phys-mapping
this_cpu_ops
timekeeping
errseq
@ -87,7 +86,7 @@ Memory management
=================
How to allocate and use memory in the kernel. Note that there is a lot
more memory-management documentation in Documentation/vm/index.rst.
more memory-management documentation in Documentation/mm/index.rst.
.. toctree::
:maxdepth: 1

8
Documentation/core-api/mm-api.rst
View File

@ -22,16 +22,16 @@ Memory Allocation Controls
.. kernel-doc:: include/linux/gfp.h
:internal:
.. kernel-doc:: include/linux/gfp.h
.. kernel-doc:: include/linux/gfp_types.h
:doc: Page mobility and placement hints
.. kernel-doc:: include/linux/gfp.h
.. kernel-doc:: include/linux/gfp_types.h
:doc: Watermark modifiers
.. kernel-doc:: include/linux/gfp.h
.. kernel-doc:: include/linux/gfp_types.h
:doc: Reclaim modifiers
.. kernel-doc:: include/linux/gfp.h
.. kernel-doc:: include/linux/gfp_types.h
:doc: Useful GFP flag combinations
The Slab Cache

1
Documentation/dev-tools/kmemleak.rst
View File

@ -174,7 +174,6 @@ mapping:
- ``kmemleak_alloc_phys``
- ``kmemleak_free_part_phys``
- ``kmemleak_not_leak_phys``
- ``kmemleak_ignore_phys``
Dealing with false positives/negatives

4
Documentation/devicetree/bindings/Makefile
View File

@ -42,9 +42,7 @@ quiet_cmd_chk_bindings = CHKDT $@
quiet_cmd_mk_schema = SCHEMA $@
cmd_mk_schema = f=$$(mktemp) ; \
$(if $(DT_MK_SCHEMA_FLAGS), \
printf '%s\n' $(real-prereqs), \
$(find_all_cmd)) > $$f ; \
$(find_all_cmd) > $$f ; \
$(DT_MK_SCHEMA) -j $(DT_MK_SCHEMA_FLAGS) @$$f > $@ ; \
rm -f $$f

15
Documentation/devicetree/bindings/arm/atmel-sysregs.txt
View File

@ -25,21 +25,6 @@ System Timer (ST) required properties:
Its subnodes can be:
- watchdog: compatible should be "atmel,at91rm9200-wdt"
RSTC Reset Controller required properties:
- compatible: Should be "atmel,<chip>-rstc".
<chip> can be "at91sam9260", "at91sam9g45", "sama5d3" or "samx7"
it also can be "microchip,sam9x60-rstc"
- reg: Should contain registers location and length
- clocks: phandle to input clock.
Example:
rstc@fffffd00 {
compatible = "atmel,at91sam9260-rstc";
reg = <0xfffffd00 0x10>;
clocks = <&clk32k>;
};
RAMC SDRAM/DDR Controller required properties:
- compatible: Should be "atmel,at91rm9200-sdramc", "syscon"
"atmel,at91sam9260-sdramc",

1
Documentation/devicetree/bindings/arm/cpus.yaml
View File

@ -138,6 +138,7 @@ properties:
- arm,cortex-a76
- arm,cortex-a77
- arm,cortex-a78
- arm,cortex-a78ae
- arm,cortex-a510
- arm,cortex-a710
- arm,cortex-m0

2
Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt
View File

@ -72,7 +72,7 @@ mpp19 19 gpio, uart0(rxd), sdio(pw_off)
GPIO:
-----
For common binding part and usage, refer to
Documentation/devicetree/bindings/gpio/gpio-mvebu.txt.
Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml.
Required properties:

2
Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt
View File

@ -156,7 +156,7 @@ GPIO:
-----
For common binding part and usage, refer to
Documentation/devicetree/bindings/gpio/gpio-mvebu.txt.
Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml.
Required properties:

3
Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml
View File

@ -39,6 +39,9 @@ properties:
'#clock-cells':
const: 1
'#reset-cells':
const: 1
required:
- compatible
- reg

8
Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-clock.yaml
View File

@ -24,7 +24,6 @@ properties:
- mediatek,mt8192-imp_iic_wrap_w
- mediatek,mt8192-imp_iic_wrap_n
- mediatek,mt8192-msdc_top
- mediatek,mt8192-msdc
- mediatek,mt8192-mfgcfg
- mediatek,mt8192-imgsys
- mediatek,mt8192-imgsys2
@ -107,13 +106,6 @@ examples:
#clock-cells = <1>;
};
- |
msdc: clock-controller@11f60000 {
compatible = "mediatek,mt8192-msdc";
reg = <0x11f60000 0x1000>;
#clock-cells = <1>;
};
- |
mfgcfg: clock-controller@13fbf000 {
compatible = "mediatek,mt8192-mfgcfg";

3
Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8192-sys-clock.yaml
View File

@ -29,6 +29,9 @@ properties:
'#clock-cells':
const: 1
'#reset-cells':
const: 1
required:
- compatible
- reg

3
Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8195-sys-clock.yaml
View File

@ -37,6 +37,9 @@ properties:
'#clock-cells':
const: 1
'#reset-cells':
const: 1
required:
- compatible
- reg

2
Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
View File

@ -10,7 +10,7 @@ system, notifying them when a low power state is entered or exited.
Multiple revisions of the SAW hardware are supported using these Device Nodes.
SAW2 revisions differ in the register offset and configuration data. Also, the
same revision of the SAW in different SoCs may have different configuration
data due the the differences in hardware capabilities. Hence the SoC name, the
data due the differences in hardware capabilities. Hence the SoC name, the
version of the SAW hardware in that SoC and the distinction between cpu (big
or Little) or cache, may be needed to uniquely identify the SAW register
configuration and initialization data. The compatible string is used to

2
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml
View File

@ -208,7 +208,7 @@ properties:
"^[a-z0-9]+$":
type: object
patternProperties:
properties:
clocks:
minItems: 1
maxItems: 8

10
Documentation/devicetree/bindings/arm/vexpress-sysreg.yaml
View File

@ -29,6 +29,13 @@ properties:
ranges: true
gpio-controller:
deprecated: true
"#gpio-cells":
deprecated: true
const: 2
additionalProperties: false
patternProperties:
@ -67,8 +74,7 @@ patternProperties:
required:
- compatible
- "#address-cells"
- "#size-cells"
- reg
examples:
- |

63
Documentation/devicetree/bindings/ata/ahci-ceva.txt
View File

@ -1,63 +0,0 @@
Binding for CEVA AHCI SATA Controller
Required properties:
- reg: Physical base address and size of the controller's register area.
- compatible: Compatibility string. Must be 'ceva,ahci-1v84'.
- clocks: Input clock specifier. Refer to common clock bindings.
- interrupts: Interrupt specifier. Refer to interrupt binding.
- ceva,p0-cominit-params: OOB timing value for COMINIT parameter for port 0.
- ceva,p1-cominit-params: OOB timing value for COMINIT parameter for port 1.
The fields for the above parameter must be as shown below:
ceva,pN-cominit-params = /bits/ 8 <CIBGMN CIBGMX CIBGN CINMP>;
CINMP : COMINIT Negate Minimum Period.
CIBGN : COMINIT Burst Gap Nominal.
CIBGMX: COMINIT Burst Gap Maximum.
CIBGMN: COMINIT Burst Gap Minimum.
- ceva,p0-comwake-params: OOB timing value for COMWAKE parameter for port 0.
- ceva,p1-comwake-params: OOB timing value for COMWAKE parameter for port 1.
The fields for the above parameter must be as shown below:
ceva,pN-comwake-params = /bits/ 8 <CWBGMN CWBGMX CWBGN CWNMP>;
CWBGMN: COMWAKE Burst Gap Minimum.
CWBGMX: COMWAKE Burst Gap Maximum.
CWBGN: COMWAKE Burst Gap Nominal.
CWNMP: COMWAKE Negate Minimum Period.
- ceva,p0-burst-params: Burst timing value for COM parameter for port 0.
- ceva,p1-burst-params: Burst timing value for COM parameter for port 1.
The fields for the above parameter must be as shown below:
ceva,pN-burst-params = /bits/ 8 <BMX BNM SFD PTST>;
BMX: COM Burst Maximum.
BNM: COM Burst Nominal.
SFD: Signal Failure Detection value.
PTST: Partial to Slumber timer value.
- ceva,p0-retry-params: Retry interval timing value for port 0.
- ceva,p1-retry-params: Retry interval timing value for port 1.
The fields for the above parameter must be as shown below:
ceva,pN-retry-params = /bits/ 16 <RIT RCT>;
RIT: Retry Interval Timer.
RCT: Rate Change Timer.
Optional properties:
- ceva,broken-gen2: limit to gen1 speed instead of gen2.
- phys: phandle for the PHY device
- resets: phandle to the reset controller for the SATA IP
Examples:
ahci@fd0c0000 {
compatible = "ceva,ahci-1v84";
reg = <0xfd0c0000 0x200>;
interrupt-parent = <&gic>;
interrupts = <0 133 4>;
clocks = <&clkc SATA_CLK_ID>;
ceva,p0-cominit-params = /bits/ 8 <0x0F 0x25 0x18 0x29>;
ceva,p0-comwake-params = /bits/ 8 <0x04 0x0B 0x08 0x0F>;
ceva,p0-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>;
ceva,p0-retry-params = /bits/ 16 <0x0216 0x7F06>;
ceva,p1-cominit-params = /bits/ 8 <0x0F 0x25 0x18 0x29>;
ceva,p1-comwake-params = /bits/ 8 <0x04 0x0B 0x08 0x0F>;
ceva,p1-burst-params = /bits/ 8 <0x0A 0x08 0x4A 0x06>;
ceva,p1-retry-params = /bits/ 16 <0x0216 0x7F06>;
ceva,broken-gen2;
phys = <&psgtr 1 PHY_TYPE_SATA 1 1>;
resets = <&zynqmp_reset ZYNQMP_RESET_SATA>;
};

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

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

25
Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml
View File

@ -28,11 +28,9 @@ properties:
- const: qcom,ssc-block-bus
reg:
description: |
Shall contain the addresses of the SSCAON_CONFIG0 and SSCAON_CONFIG1
registers
minItems: 2
maxItems: 2
items:
- description: SSCAON_CONFIG0 registers
- description: SSCAON_CONFIG1 registers
reg-names:
items:
@ -48,7 +46,6 @@ properties:
ranges: true
clocks:
minItems: 6
maxItems: 6
clock-names:
@ -61,9 +58,9 @@ properties:
- const: ssc_ahbs
power-domains:
description: Power domain phandles for the ssc_cx and ssc_mx power domains
minItems: 2
maxItems: 2
items:
- description: CX power domain
- description: MX power domain
power-domain-names:
items:
@ -71,11 +68,11 @@ properties:
- const: ssc_mx
resets:
description: |
Reset phandles for the ssc_reset and ssc_bcr resets (note: ssc_bcr is the
branch control register associated with the ssc_xo and ssc_ahbs clocks)
minItems: 2
maxItems: 2
items:
- description: Main reset
- description:
SSC Branch Control Register reset (associated with the ssc_xo and
ssc_ahbs clocks)
reset-names:
items:

137
Documentation/devicetree/bindings/chosen.txt
View File

@ -1,137 +0,0 @@
The chosen node
---------------
The chosen node does not represent a real device, but serves as a place
for passing data between firmware and the operating system, like boot
arguments. Data in the chosen node does not represent the hardware.
The following properties are recognized:
kaslr-seed
-----------
This property is used when booting with CONFIG_RANDOMIZE_BASE as the
entropy used to randomize the kernel image base address location. Since
it is used directly, this value is intended only for KASLR, and should
not be used for other purposes (as it may leak information about KASLR
offsets). It is parsed as a u64 value, e.g.
/ {
chosen {
kaslr-seed = <0xfeedbeef 0xc0def00d>;
};
};
Note that if this property is set from UEFI (or a bootloader in EFI
mode) when EFI_RNG_PROTOCOL is supported, it will be overwritten by
the Linux EFI stub (which will populate the property itself, using
EFI_RNG_PROTOCOL).
stdout-path
-----------
Device trees may specify the device to be used for boot console output
with a stdout-path property under /chosen, as described in the Devicetree
Specification, e.g.
/ {
chosen {
stdout-path = "/serial@f00:115200";
};
serial@f00 {
compatible = "vendor,some-uart";
reg = <0xf00 0x10>;
};
};
If the character ":" is present in the value, this terminates the path.
The meaning of any characters following the ":" is device-specific, and
must be specified in the relevant binding documentation.
For UART devices, the preferred binding is a string in the form:
<baud>{<parity>{<bits>{<flow>}}}
where
baud - baud rate in decimal
parity - 'n' (none), 'o', (odd) or 'e' (even)
bits - number of data bits
flow - 'r' (rts)
For example: 115200n8r
Implementation note: Linux will look for the property "linux,stdout-path" or
on PowerPC "stdout" if "stdout-path" is not found. However, the
"linux,stdout-path" and "stdout" properties are deprecated. New platforms
should only use the "stdout-path" property.
linux,booted-from-kexec
-----------------------
This property is set (currently only on PowerPC, and only needed on
book3e) by some versions of kexec-tools to tell the new kernel that it
is being booted by kexec, as the booting environment may differ (e.g.
a different secondary CPU release mechanism)
linux,usable-memory-range
-------------------------
This property holds a base address and size, describing a limited region in
which memory may be considered available for use by the kernel. Memory outside
of this range is not available for use.
This property describes a limitation: memory within this range is only
valid when also described through another mechanism that the kernel
would otherwise use to determine available memory (e.g. memory nodes
or the EFI memory map). Valid memory may be sparse within the range.
e.g.
/ {
chosen {
linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>;
};
};
The main usage is for crash dump kernel to identify its own usable
memory and exclude, at its boot time, any other memory areas that are
part of the panicked kernel's memory.
While this property does not represent a real hardware, the address
and the size are expressed in #address-cells and #size-cells,
respectively, of the root node.
linux,elfcorehdr
----------------
This property holds the memory range, the address and the size, of the elf
core header which mainly describes the panicked kernel's memory layout as
PT_LOAD segments of elf format.
e.g.
/ {
chosen {
linux,elfcorehdr = <0x9 0xfffff000 0x0 0x800>;
};
};
While this property does not represent a real hardware, the address
and the size are expressed in #address-cells and #size-cells,
respectively, of the root node.
linux,initrd-start and linux,initrd-end
---------------------------------------
These properties hold the physical start and end address of an initrd that's
loaded by the bootloader. Note that linux,initrd-start is inclusive, but
linux,initrd-end is exclusive.
e.g.
/ {
chosen {
linux,initrd-start = <0x82000000>;
linux,initrd-end = <0x82800000>;
};
};

15
Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
View File

@ -20,13 +20,24 @@ properties:
compatible:
const: google,cros-ec-typec
connector:
'#address-cells':
const: 1
'#size-cells':
const: 0
patternProperties:
'^connector@[0-9a-f]+$':
$ref: /schemas/connector/usb-connector.yaml#
unevaluatedProperties: false
properties:
reg:
maxItems: 1
required:
- compatible
additionalProperties: true #fixme
additionalProperties: false
examples:
- |+

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

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

11
Documentation/devicetree/bindings/clock/efm32-clock.txt
View File

@ -1,11 +0,0 @@
* Clock bindings for Energy Micro efm32 Giant Gecko's Clock Management Unit
Required properties:
- compatible: Should be "efm32gg,cmu"
- reg: Base address and length of the register set
- interrupts: Interrupt used by the CMU
- #clock-cells: Should be <1>
The clock consumer should specify the desired clock by having the clock ID in
its "clocks" phandle cell. The header efm32-clk.h contains a list of available
IDs.

1
Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml
View File

@ -13,7 +13,6 @@ maintainers:
properties:
compatible:
enum:
- allwinner,sun4i-a10-pll3-2x-clk
- fixed-factor-clock
"#clock-cells":

40
Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
View File

@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/qcom,gcc-apq8064.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller Binding for APQ8064
title: Qualcomm Global Clock & Reset Controller Binding for APQ8064/MSM8960
allOf:
- $ref: qcom,gcc.yaml#
@ -23,11 +23,25 @@ description: |
properties:
compatible:
const: qcom,gcc-apq8064
oneOf:
- items:
- enum:
- qcom,gcc-apq8064
- qcom,gcc-msm8960
- const: syscon
- enum:
- qcom,gcc-apq8064
- qcom,gcc-msm8960
deprecated: true
thermal-sensor:
description: child tsens device
$ref: /schemas/thermal/qcom-tsens.yaml#
nvmem-cells:
minItems: 1
maxItems: 2
deprecated: true
description:
Qualcomm TSENS (thermal sensor device) on some devices can
be part of GCC and hence the TSENS properties can also be part
@ -37,31 +51,39 @@ properties:
nvmem-cell-names:
minItems: 1
deprecated: true
items:
- const: calib
- const: calib_backup
'#thermal-sensor-cells':
const: 1
deprecated: true
required:
- compatible
- nvmem-cells
- nvmem-cell-names
- '#thermal-sensor-cells'
unevaluatedProperties: false
examples:
- |
clock-controller@900000 {
compatible = "qcom,gcc-apq8064";
compatible = "qcom,gcc-apq8064", "syscon";
reg = <0x00900000 0x4000>;
nvmem-cells = <&tsens_calib>, <&tsens_backup>;
nvmem-cell-names = "calib", "calib_backup";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
#thermal-sensor-cells = <1>;
thermal-sensor {
compatible = "qcom,msm8960-tsens";
nvmem-cells = <&tsens_calib>, <&tsens_backup>;
nvmem-cell-names = "calib", "calib_backup";
interrupts = <0 178 4>;
interrupt-names = "uplow";
#qcom,sensors = <11>;
#thermal-sensor-cells = <1>;
};
};
...

5
Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml
View File

@ -24,6 +24,9 @@ properties:
'#clock-cells':
const: 1
'#power-domain-cells':
const: 1
'#reset-cells':
const: 1
@ -38,6 +41,7 @@ required:
- compatible
- reg
- '#clock-cells'
- '#power-domain-cells'
- '#reset-cells'
additionalProperties: false
@ -48,6 +52,7 @@ examples:
compatible = "qcom,gcc-ipq8074";
reg = <0x01800000 0x80000>;
#clock-cells = <1>;
#power-domain-cells = <1>;
#reset-cells = <1>;
};
...

16
Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml
View File

@ -22,16 +22,32 @@ properties:
const: qcom,gcc-msm8996
clocks:
minItems: 3
items:
- description: XO source
- description: Second XO source
- description: Sleep clock source
- description: PCIe 0 PIPE clock (optional)
- description: PCIe 1 PIPE clock (optional)
- description: PCIe 2 PIPE clock (optional)
- description: USB3 PIPE clock (optional)
- description: UFS RX symbol 0 clock (optional)
- description: UFS RX symbol 1 clock (optional)
- description: UFS TX symbol 0 clock (optional)
clock-names:
minItems: 3
items:
- const: cxo
- const: cxo2
- const: sleep_clk
- const: pcie_0_pipe_clk_src
- const: pcie_1_pipe_clk_src
- const: pcie_2_pipe_clk_src
- const: usb3_phy_pipe_clk_src
- const: ufs_rx_symbol_0_clk_src
- const: ufs_rx_symbol_1_clk_src
- const: ufs_tx_symbol_0_clk_src
'#clock-cells':
const: 1

5
Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml
View File

@ -44,7 +44,6 @@ properties:
- qcom,gcc-msm8916
- qcom,gcc-msm8939
- qcom,gcc-msm8953
- qcom,gcc-msm8960
- qcom,gcc-msm8974
- qcom,gcc-msm8974pro
- qcom,gcc-msm8974pro-ac
@ -58,10 +57,10 @@ required:
unevaluatedProperties: false
examples:
# Example for GCC for MSM8960:
# Example for GCC for MSM8974:
- |
clock-controller@900000 {
compatible = "qcom,gcc-msm8960";
compatible = "qcom,gcc-msm8974";
reg = <0x900000 0x4000>;
#clock-cells = <1>;
#reset-cells = <1>;

3
Documentation/devicetree/bindings/clock/qcom,gcc-sdm845.yaml
View File

@ -43,6 +43,9 @@ properties:
'#reset-cells':
const: 1
power-domains:
maxItems: 1
'#power-domain-cells':
const: 1

85
Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
View File

@ -49,15 +49,86 @@ properties:
const: 1
clocks:
maxItems: 1
minItems: 1
maxItems: 2
clock-names:
const: xo
minItems: 1
maxItems: 2
required:
- compatible
- '#clock-cells'
allOf:
- if:
properties:
compatible:
contains:
enum:
- qcom,rpmcc-apq8060
- qcom,rpmcc-ipq806x
- qcom,rpmcc-msm8660
then:
properties:
clocks:
items:
- description: pxo clock
clock-names:
items:
- const: pxo
- if:
properties:
compatible:
contains:
const: qcom,rpmcc-apq8064
then:
properties:
clocks:
items:
- description: pxo clock
- description: cxo clock
clock-names:
items:
- const: pxo
- const: cxo
- if:
properties:
compatible:
contains:
enum:
- qcom,rpmcc-mdm9607
- qcom,rpmcc-msm8226
- qcom,rpmcc-msm8916
- qcom,rpmcc-msm8936
- qcom,rpmcc-msm8953
- qcom,rpmcc-msm8974
- qcom,rpmcc-msm8976
- qcom,rpmcc-msm8992
- qcom,rpmcc-msm8994
- qcom,rpmcc-msm8996
- qcom,rpmcc-msm8998
- qcom,rpmcc-qcm2290
- qcom,rpmcc-qcs404
- qcom,rpmcc-sdm660
- qcom,rpmcc-sm6115
- qcom,rpmcc-sm6125
then:
properties:
clocks:
items:
- description: xo clock
clock-names:
items:
- const: xo
additionalProperties: false
examples:
@ -73,3 +144,13 @@ examples:
};
};
};
- |
rpm {
clock-controller {
compatible = "qcom,rpmcc-ipq806x", "qcom,rpmcc";
#clock-cells = <1>;
clocks = <&pxo_board>;
clock-names = "pxo";
};
};

7
Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml
View File

@ -45,10 +45,9 @@ properties:
description: |
- For CPG core clocks, the two clock specifier cells must be "CPG_CORE"
and a core clock reference, as defined in
<dt-bindings/clock/r9a0*-cpg.h>
<dt-bindings/clock/r9a0*-cpg.h>,
- For module clocks, the two clock specifier cells must be "CPG_MOD" and
a module number, as defined in the <dt-bindings/clock/r9a07g0*-cpg.h> or
<dt-bindings/clock/r9a09g011-cpg.h>.
a module number, as defined in <dt-bindings/clock/r9a0*-cpg.h>.
const: 2
'#power-domain-cells':
@ -62,7 +61,7 @@ properties:
'#reset-cells':
description:
The single reset specifier cell must be the module number, as defined in
the <dt-bindings/clock/r9a07g0*-cpg.h> or <dt-bindings/clock/r9a09g011-cpg.h>.
<dt-bindings/clock/r9a0*-cpg.h>.
const: 1
required:

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

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

2
Documentation/devicetree/bindings/clock/st/st,flexgen.txt
View File

@ -78,7 +78,7 @@ Required properties:
- #clock-cells : from common clock binding; shall be set to 1 (multiple clock
outputs).
- clocks : must be set to the parent's phandle. it's could be output clocks of
- clocks : must be set to the parent's phandle. it could be output clocks of
a quadsfs or/and a pll or/and clk_sysin (up to 7 clocks)
- clock-output-names : List of strings used to name the clock outputs.

2
Documentation/devicetree/bindings/clock/ti/davinci/pll.txt
View File

@ -15,7 +15,7 @@ Required properties:
- for "ti,da850-pll1", shall be "clksrc"
Optional properties:
- ti,clkmode-square-wave: Indicates that the the board is supplying a square
- ti,clkmode-square-wave: Indicates that the board is supplying a square
wave input on the OSCIN pin instead of using a crystal oscillator.
This property is only valid when compatible = "ti,da850-pll0".

2
Documentation/devicetree/bindings/clock/ti/dra7-atl.txt
View File

@ -6,7 +6,7 @@ functional clock but can be configured to provide different clocks.
ATL can maintain a clock averages to some desired frequency based on the bws/aws
signals - can compensate the drift between the two ws signal.
In order to provide the support for ATL and it's output clocks (which can be used
In order to provide the support for ATL and its output clocks (which can be used
internally within the SoC or external components) two sets of bindings is needed:
Clock tree binding:

152
Documentation/devicetree/bindings/connector/usb-connector.yaml
View File

@ -263,11 +263,11 @@ examples:
# Micro-USB connector with HS lines routed via controller (MUIC).
- |
muic-max77843 {
usb_con1: connector {
compatible = "usb-b-connector";
label = "micro-USB";
type = "micro";
};
usb_con1: connector {
compatible = "usb-b-connector";
label = "micro-USB";
type = "micro";
};
};
# USB-C connector attached to CC controller (s2mm005), HS lines routed
@ -275,34 +275,34 @@ examples:
# DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
- |
ccic: s2mm005 {
usb_con2: connector {
compatible = "usb-c-connector";
label = "USB-C";
usb_con2: connector {
compatible = "usb-c-connector";
label = "USB-C";
ports {
#address-cells = <1>;
#size-cells = <0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
usb_con_hs: endpoint {
remote-endpoint = <&max77865_usbc_hs>;
port@0 {
reg = <0>;
usb_con_hs: endpoint {
remote-endpoint = <&max77865_usbc_hs>;
};
};
port@1 {
reg = <1>;
usb_con_ss: endpoint {
remote-endpoint = <&usbdrd_phy_ss>;
};
};
port@2 {
reg = <2>;
usb_con_sbu: endpoint {
remote-endpoint = <&dp_aux>;
};
};
};
};
port@1 {
reg = <1>;
usb_con_ss: endpoint {
remote-endpoint = <&usbdrd_phy_ss>;
};
};
port@2 {
reg = <2>;
usb_con_sbu: endpoint {
remote-endpoint = <&dp_aux>;
};
};
};
};
};
# USB-C connector attached to a typec port controller(ptn5110), which has
@ -310,16 +310,16 @@ examples:
- |
#include <dt-bindings/usb/pd.h>
typec: ptn5110 {
usb_con3: connector {
compatible = "usb-c-connector";
label = "USB-C";
power-role = "dual";
try-power-role = "sink";
source-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)>;
sink-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)
PDO_VAR(5000, 12000, 2000)>;
op-sink-microwatt = <10000000>;
};
usb_con3: connector {
compatible = "usb-c-connector";
label = "USB-C";
power-role = "dual";
try-power-role = "sink";
source-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)>;
sink-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)
PDO_VAR(5000, 12000, 2000)>;
op-sink-microwatt = <10000000>;
};
};
# USB-C connector attached to SoC and USB3 typec port controller(hd3ss3220)
@ -332,20 +332,20 @@ examples:
data-role = "dual";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
hs_ep: endpoint {
remote-endpoint = <&usb3_hs_ep>;
};
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
hs_ep: endpoint {
remote-endpoint = <&usb3_hs_ep>;
};
port@1 {
reg = <1>;
ss_ep: endpoint {
remote-endpoint = <&hd3ss3220_in_ep>;
};
};
port@1 {
reg = <1>;
ss_ep: endpoint {
remote-endpoint = <&hd3ss3220_in_ep>;
};
};
};
};
@ -354,12 +354,12 @@ examples:
#include <dt-bindings/gpio/gpio.h>
usb {
connector {
compatible = "gpio-usb-b-connector", "usb-b-connector";
type = "micro";
id-gpios = <&pio 12 GPIO_ACTIVE_HIGH>;
vbus-supply = <&usb_p0_vbus>;
};
connector {
compatible = "gpio-usb-b-connector", "usb-b-connector";
type = "micro";
id-gpios = <&pio 12 GPIO_ACTIVE_HIGH>;
vbus-supply = <&usb_p0_vbus>;
};
};
# Micro-USB connector with HS lines routed via controller (MUIC) and MHL
@ -367,27 +367,27 @@ examples:
# mobile phone
- |
muic-max77843 {
usb_con4: connector {
compatible = "samsung,usb-connector-11pin", "usb-b-connector";
label = "micro-USB";
type = "micro";
usb_con4: connector {
compatible = "samsung,usb-connector-11pin", "usb-b-connector";
label = "micro-USB";
type = "micro";
ports {
#address-cells = <1>;
#size-cells = <0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
muic_to_usb: endpoint {
remote-endpoint = <&usb_to_muic>;
port@0 {
reg = <0>;
muic_to_usb: endpoint {
remote-endpoint = <&usb_to_muic>;
};
};
port@3 {
reg = <3>;
usb_con_mhl: endpoint {
remote-endpoint = <&sii8620_mhl>;
};
};
};
};
port@3 {
reg = <3>;
usb_con_mhl: endpoint {
remote-endpoint = <&sii8620_mhl>;
};
};
};
};
};

1
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml
View File

@ -25,6 +25,7 @@ properties:
- description: v2 of CPUFREQ HW (EPSS)
items:
- enum:
- qcom,sm6375-cpufreq-epss
- qcom,sm8250-cpufreq-epss
- const: qcom,cpufreq-epss

7
Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
View File

@ -22,6 +22,13 @@ select:
compatible:
contains:
enum:
- qcom,apq8064
- qcom,apq8096
- qcom,ipq8064
- qcom,msm8939
- qcom,msm8960
- qcom,msm8974
- qcom,msm8996
- qcom,qcs404
required:
- compatible

4
Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
View File

@ -233,6 +233,7 @@ allOf:
- allwinner,sun8i-a83t-tcon-lcd
- allwinner,sun8i-v3s-tcon
- allwinner,sun9i-a80-tcon-lcd
- allwinner,sun20i-d1-tcon-lcd
then:
properties:
@ -252,6 +253,7 @@ allOf:
- allwinner,sun8i-a83t-tcon-tv
- allwinner,sun8i-r40-tcon-tv
- allwinner,sun9i-a80-tcon-tv
- allwinner,sun20i-d1-tcon-tv
then:
properties:
@ -278,6 +280,7 @@ allOf:
- allwinner,sun9i-a80-tcon-lcd
- allwinner,sun4i-a10-tcon
- allwinner,sun8i-a83t-tcon-lcd
- allwinner,sun20i-d1-tcon-lcd
then:
required:
@ -294,6 +297,7 @@ allOf:
- allwinner,sun8i-a23-tcon
- allwinner,sun8i-a33-tcon
- allwinner,sun8i-a83t-tcon-lcd
- allwinner,sun20i-d1-tcon-lcd
then:
properties:

15
Documentation/devicetree/bindings/display/arm,pl11x.yaml
View File

@ -159,25 +159,12 @@ examples:
};
panel {
compatible = "arm,rtsm-display", "panel-dpi";
power-supply = <&vcc_supply>;
compatible = "arm,rtsm-display";
port {
clcd_panel: endpoint {
remote-endpoint = <&clcd_pads>;
};
};
panel-timing {
clock-frequency = <25175000>;
hactive = <640>;
hback-porch = <40>;
hfront-porch = <24>;
hsync-len = <96>;
vactive = <480>;
vback-porch = <32>;
vfront-porch = <11>;
vsync-len = <2>;
};
};
...

78
Documentation/devicetree/bindings/display/bridge/sii902x.txt
View File

@ -1,78 +0,0 @@
sii902x HDMI bridge bindings
Required properties:
- compatible: "sil,sii9022"
- reg: i2c address of the bridge
Optional properties:
- interrupts: describe the interrupt line used to inform the host
about hotplug events.
- reset-gpios: OF device-tree gpio specification for RST_N pin.
- iovcc-supply: I/O Supply Voltage (1.8V or 3.3V)
- cvcc12-supply: Digital Core Supply Voltage (1.2V)
HDMI audio properties:
- #sound-dai-cells: <0> or <1>. <0> if only i2s or spdif pin
is wired, <1> if the both are wired. HDMI audio is
configured only if this property is found.
- sil,i2s-data-lanes: Array of up to 4 integers with values of 0-3
Each integer indicates which i2s pin is connected to which
audio fifo. The first integer selects i2s audio pin for the
first audio fifo#0 (HDMI channels 1&2), second for fifo#1
(HDMI channels 3&4), and so on. There is 4 fifos and 4 i2s
pins (SD0 - SD3). Any i2s pin can be connected to any fifo,
but there can be no gaps. E.g. an i2s pin must be mapped to
fifo#0 and fifo#1 before mapping a channel to fifo#2. Default
value is <0>, describing SD0 pin beiging routed to hdmi audio
fifo #0.
- clocks: phandle and clock specifier for each clock listed in
the clock-names property
- clock-names: "mclk"
Describes SII902x MCLK input. MCLK can be used to produce
HDMI audio CTS values. This property follows
Documentation/devicetree/bindings/clock/clock-bindings.txt
consumer binding.
If HDMI audio is configured the sii902x device becomes an I2S
and/or spdif audio codec component (e.g a digital audio sink),
that can be used in configuring a full audio devices with
simple-card or audio-graph-card binding. See their binding
documents on how to describe the way the sii902x device is
connected to the rest of the audio system:
Documentation/devicetree/bindings/sound/simple-card.yaml
Documentation/devicetree/bindings/sound/audio-graph-card.yaml
Note: In case of the audio-graph-card binding the used port
index should be 3.
Optional subnodes:
- video input: this subnode can contain a video input port node
to connect the bridge to a display controller output (See this
documentation [1]).
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
hdmi-bridge@39 {
compatible = "sil,sii9022";
reg = <0x39>;
reset-gpios = <&pioA 1 0>;
iovcc-supply = <&v3v3_hdmi>;
cvcc12-supply = <&v1v2_hdmi>;
#sound-dai-cells = <0>;
sil,i2s-data-lanes = < 0 1 2 >;
clocks = <&mclk>;
clock-names = "mclk";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
bridge_in: endpoint {
remote-endpoint = <&dc_out>;
};
};
};
};

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

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

27
Documentation/devicetree/bindings/display/ilitek,ili9341.txt
View File

@ -1,27 +0,0 @@
Ilitek ILI9341 display panels
This binding is for display panels using an Ilitek ILI9341 controller in SPI
mode.
Required properties:
- compatible: "adafruit,yx240qv29", "ilitek,ili9341"
- dc-gpios: D/C pin
- reset-gpios: Reset pin
The node for this driver must be a child node of a SPI controller, hence
all mandatory properties described in ../spi/spi-bus.txt must be specified.
Optional properties:
- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
- backlight: phandle of the backlight device attached to the panel
Example:
display@0{
compatible = "adafruit,yx240qv29", "ilitek,ili9341";
reg = <0>;
spi-max-frequency = <32000000>;
dc-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
rotation = <270>;
backlight = <&backlight>;
};

27
Documentation/devicetree/bindings/display/panel/arm,rtsm-display.yaml Normal file
View File

@ -0,0 +1,27 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/arm,rtsm-display.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm RTSM Virtual Platforms Display
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
const: arm,rtsm-display
port: true
required:
- compatible
- port
additionalProperties: false
...

49
Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
View File

@ -21,8 +21,10 @@ properties:
compatible:
items:
- enum:
- adafruit,yx240qv29
# ili9341 240*320 Color on stm32f429-disco board
- st,sf-tc240t-9370-t
- canaan,kd233-tft
- const: ilitek,ili9341
reg: true
@ -47,31 +49,50 @@ properties:
vddi-led-supply:
description: Voltage supply for the LED driver (1.65 .. 3.3 V)
additionalProperties: false
unevaluatedProperties: false
required:
- compatible
- reg
- dc-gpios
- port
if:
properties:
compatible:
contains:
enum:
- st,sf-tc240t-9370-t
then:
required:
- port
examples:
- |+
#include <dt-bindings/gpio/gpio.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
panel: display@0 {
compatible = "st,sf-tc240t-9370-t",
"ilitek,ili9341";
reg = <0>;
spi-3wire;
spi-max-frequency = <10000000>;
dc-gpios = <&gpiod 13 0>;
port {
panel_in: endpoint {
remote-endpoint = <&display_out>;
};
};
};
compatible = "st,sf-tc240t-9370-t",
"ilitek,ili9341";
reg = <0>;
spi-3wire;
spi-max-frequency = <10000000>;
dc-gpios = <&gpiod 13 0>;
port {
panel_in: endpoint {
remote-endpoint = <&display_out>;
};
};
};
display@1{
compatible = "adafruit,yx240qv29", "ilitek,ili9341";
reg = <1>;
spi-max-frequency = <10000000>;
dc-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
rotation = <270>;
backlight = <&backlight>;
};
};
...

2
Documentation/devicetree/bindings/display/panel/lg,lg4573.yaml
View File

@ -15,13 +15,13 @@ maintainers:
allOf:
- $ref: panel-common.yaml#
- $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
compatible:
const: lg,lg4573
reg: true
spi-max-frequency: true
required:
- compatible

1
Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml
View File

@ -38,6 +38,7 @@ properties:
0 - burst-mode
1 - non-burst with sync event
2 - non-burst with sync pulse
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2]
required:

1
Documentation/devicetree/bindings/display/simple-framebuffer.yaml
View File

@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Simple Framebuffer Device Tree Bindings
maintainers:
- Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
- Hans de Goede <hdegoede@redhat.com>
description: |+

1
Documentation/devicetree/bindings/display/sitronix,st7735r.yaml
View File

@ -15,6 +15,7 @@ description:
allOf:
- $ref: panel/panel-common.yaml#
- $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
compatible:

7
Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
View File

@ -49,9 +49,6 @@ properties:
vbat-supply:
description: The supply for VBAT
# Only required for SPI
spi-max-frequency: true
solomon,height:
$ref: /schemas/types.yaml#/definitions/uint32
default: 16
@ -153,6 +150,8 @@ required:
- reg
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
- if:
properties:
compatible:
@ -223,7 +222,7 @@ allOf:
solomon,dclk-frq:
default: 10
additionalProperties: false
unevaluatedProperties: false
examples:
- |

80
Documentation/devicetree/bindings/dma/apple,admac.yaml Normal file
View File

@ -0,0 +1,80 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/apple,admac.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Apple Audio DMA Controller (ADMAC)
description: |
Apple's Audio DMA Controller (ADMAC) is used to fetch and store audio samples
on SoCs from the "Apple Silicon" family.
The controller has been seen with up to 24 channels. Even-numbered channels
are TX-only, odd-numbered are RX-only. Individual channels are coupled to
fixed device endpoints.
maintainers:
- Martin Povišer <povik+lin@cutebit.org>
allOf:
- $ref: "dma-controller.yaml#"
properties:
compatible:
items:
- enum:
- apple,t6000-admac
- apple,t8103-admac
- const: apple,admac
reg:
maxItems: 1
'#dma-cells':
const: 1
description:
Clients specify a single cell with channel number.
dma-channels:
maximum: 24
interrupts:
minItems: 4
maxItems: 4
description:
Interrupts that correspond to the 4 IRQ outputs of the controller. Usually
only one of the controller outputs will be connected as an usable interrupt
source. The remaining interrupts will be left without a valid value, e.g.
in an interrupts-extended list the disconnected positions will contain
an empty phandle reference <0>.
required:
- compatible
- reg
- '#dma-cells'
- dma-channels
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/apple-aic.h>
#include <dt-bindings/interrupt-controller/irq.h>
aic: interrupt-controller {
interrupt-controller;
#interrupt-cells = <3>;
};
admac: dma-controller@238200000 {
compatible = "apple,t8103-admac", "apple,admac";
reg = <0x38200000 0x34000>;
dma-channels = <24>;
interrupts-extended = <0>,
<&aic AIC_IRQ 626 IRQ_TYPE_LEVEL_HIGH>,
<0>,
<0>;
#dma-cells = <1>;
};

155
Documentation/devicetree/bindings/dma/fsl,edma.yaml Normal file
View File

@ -0,0 +1,155 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale enhanced Direct Memory Access(eDMA) Controller
description: |
The eDMA channels have multiplex capability by programmable
memory-mapped registers. channels are split into two groups, called
DMAMUX0 and DMAMUX1, specific DMA request source can only be multiplexed
by any channel of certain group, DMAMUX0 or DMAMUX1, but not both.
maintainers:
- Peng Fan <peng.fan@nxp.com>
properties:
compatible:
oneOf:
- enum:
- fsl,vf610-edma
- fsl,imx7ulp-edma
- items:
- const: fsl,ls1028a-edma
- const: fsl,vf610-edma
reg:
minItems: 2
maxItems: 3
interrupts:
minItems: 2
maxItems: 17
interrupt-names:
minItems: 2
maxItems: 17
"#dma-cells":
const: 2
dma-channels:
const: 32
clocks:
maxItems: 2
clock-names:
maxItems: 2
big-endian:
description: |
If present registers and hardware scatter/gather descriptors of the
eDMA are implemented in big endian mode, otherwise in little mode.
type: boolean
required:
- "#dma-cells"
- compatible
- reg
- interrupts
- clocks
- dma-channels
allOf:
- $ref: "dma-controller.yaml#"
- if:
properties:
compatible:
contains:
const: fsl,vf610-edma
then:
properties:
clock-names:
items:
- const: dmamux0
- const: dmamux1
interrupts:
maxItems: 2
interrupt-names:
items:
- const: edma-tx
- const: edma-err
reg:
maxItems: 3
- if:
properties:
compatible:
contains:
const: fsl,imx7ulp-edma
then:
properties:
clock-names:
items:
- const: dma
- const: dmamux0
interrupts:
maxItems: 17
reg:
maxItems: 2
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/vf610-clock.h>
edma0: dma-controller@40018000 {
#dma-cells = <2>;
compatible = "fsl,vf610-edma";
reg = <0x40018000 0x2000>,
<0x40024000 0x1000>,
<0x40025000 0x1000>;
interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>,
<0 9 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "edma-tx", "edma-err";
dma-channels = <32>;
clock-names = "dmamux0", "dmamux1";
clocks = <&clks VF610_CLK_DMAMUX0>, <&clks VF610_CLK_DMAMUX1>;
};
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/imx7ulp-clock.h>
edma1: dma-controller@40080000 {
#dma-cells = <2>;
compatible = "fsl,imx7ulp-edma";
reg = <0x40080000 0x2000>,
<0x40210000 0x1000>;
dma-channels = <32>;
interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
/* last is eDMA2-ERR interrupt */
<GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "dma", "dmamux0";
clocks = <&pcc2 IMX7ULP_CLK_DMA1>, <&pcc2 IMX7ULP_CLK_DMA_MUX1>;
};

111
Documentation/devicetree/bindings/dma/fsl-edma.txt
View File

@ -1,111 +0,0 @@
* Freescale enhanced Direct Memory Access(eDMA) Controller
The eDMA channels have multiplex capability by programmble memory-mapped
registers. channels are split into two groups, called DMAMUX0 and DMAMUX1,
specific DMA request source can only be multiplexed by any channel of certain
group, DMAMUX0 or DMAMUX1, but not both.
* eDMA Controller
Required properties:
- compatible :
- "fsl,vf610-edma" for eDMA used similar to that on Vybrid vf610 SoC
- "fsl,imx7ulp-edma" for eDMA2 used similar to that on i.mx7ulp
- "fsl,ls1028a-edma" followed by "fsl,vf610-edma" for eDMA used on the
LS1028A SoC.
- reg : Specifies base physical address(s) and size of the eDMA registers.
The 1st region is eDMA control register's address and size.
The 2nd and the 3rd regions are programmable channel multiplexing
control register's address and size.
- interrupts : A list of interrupt-specifiers, one for each entry in
interrupt-names on vf610 similar SoC. But for i.mx7ulp per channel
per transmission interrupt, total 16 channel interrupt and 1
error interrupt(located in the last), no interrupt-names list on
i.mx7ulp for clean on dts.
- #dma-cells : Must be <2>.
The 1st cell specifies the DMAMUX(0 for DMAMUX0 and 1 for DMAMUX1).
Specific request source can only be multiplexed by specific channels
group called DMAMUX.
The 2nd cell specifies the request source(slot) ID.
See the SoC's reference manual for all the supported request sources.
- dma-channels : Number of channels supported by the controller
- clock-names : A list of channel group clock names. Should contain:
"dmamux0" - clock name of mux0 group
"dmamux1" - clock name of mux1 group
Note: No dmamux0 on i.mx7ulp, but another 'dma' clk added on i.mx7ulp.
- clocks : A list of phandle and clock-specifier pairs, one for each entry in
clock-names.
Optional properties:
- big-endian: If present registers and hardware scatter/gather descriptors
of the eDMA are implemented in big endian mode, otherwise in little
mode.
- interrupt-names : Should contain the below on vf610 similar SoC but not used
on i.mx7ulp similar SoC:
"edma-tx" - the transmission interrupt
"edma-err" - the error interrupt
Examples:
edma0: dma-controller@40018000 {
#dma-cells = <2>;
compatible = "fsl,vf610-edma";
reg = <0x40018000 0x2000>,
<0x40024000 0x1000>,
<0x40025000 0x1000>;
interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>,
<0 9 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "edma-tx", "edma-err";
dma-channels = <32>;
clock-names = "dmamux0", "dmamux1";
clocks = <&clks VF610_CLK_DMAMUX0>,
<&clks VF610_CLK_DMAMUX1>;
}; /* vf610 */
edma1: dma-controller@40080000 {
#dma-cells = <2>;
compatible = "fsl,imx7ulp-edma";
reg = <0x40080000 0x2000>,
<0x40210000 0x1000>;
dma-channels = <32>;
interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
/* last is eDMA2-ERR interrupt */
<GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "dma", "dmamux0";
clocks = <&pcc2 IMX7ULP_CLK_DMA1>,
<&pcc2 IMX7ULP_CLK_DMA_MUX1>;
}; /* i.mx7ulp */
* DMA clients
DMA client drivers that uses the DMA function must use the format described
in the dma.txt file, using a two-cell specifier for each channel: the 1st
specifies the channel group(DMAMUX) in which this request can be multiplexed,
and the 2nd specifies the request source.
Examples:
sai2: sai@40031000 {
compatible = "fsl,vf610-sai";
reg = <0x40031000 0x1000>;
interrupts = <0 86 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "sai";
clocks = <&clks VF610_CLK_SAI2>;
dma-names = "tx", "rx";
dmas = <&edma0 0 21>,
<&edma0 0 20>;
};

1
Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml
View File

@ -22,6 +22,7 @@ properties:
- items:
- enum:
- mediatek,mt2712-uart-dma
- mediatek,mt8365-uart-dma
- mediatek,mt8516-uart-dma
- const: mediatek,mt6577-uart-dma
- enum:

4
Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
View File

@ -23,7 +23,9 @@ properties:
oneOf:
- const: nvidia,tegra186-gpcdma
- items:
- const: nvidia,tegra194-gpcdma
- enum:
- nvidia,tegra234-gpcdma
- nvidia,tegra194-gpcdma
- const: nvidia,tegra186-gpcdma
"#dma-cells":

100
Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml Normal file
View File

@ -0,0 +1,100 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/qcom,bam-dma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Technologies Inc BAM DMA controller
maintainers:
- Andy Gross <agross@kernel.org>
- Bjorn Andersson <bjorn.andersson@linaro.org>
allOf:
- $ref: "dma-controller.yaml#"
properties:
compatible:
enum:
# APQ8064, IPQ8064 and MSM8960
- qcom,bam-v1.3.0
# MSM8974, APQ8074 and APQ8084
- qcom,bam-v1.4.0
# MSM8916
- qcom,bam-v1.7.0
clocks:
maxItems: 1
clock-names:
items:
- const: bam_clk
"#dma-cells":
const: 1
interrupts:
maxItems: 1
iommus:
minItems: 1
maxItems: 4
num-channels:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Indicates supported number of DMA channels in a remotely controlled bam.
qcom,controlled-remotely:
type: boolean
description:
Indicates that the bam is controlled by remote proccessor i.e. execution
environment.
qcom,ee:
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 7
description:
Indicates the active Execution Environment identifier (0-7) used in the
secure world.
qcom,num-ees:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Indicates supported number of Execution Environments in a remotely
controlled bam.
qcom,powered-remotely:
type: boolean
description:
Indicates that the bam is powered up by a remote processor but must be
initialized by the local processor.
reg:
maxItems: 1
required:
- compatible
- "#dma-cells"
- interrupts
- qcom,ee
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,gcc-msm8974.h>
dma-controller@f9944000 {
compatible = "qcom,bam-v1.4.0";
reg = <0xf9944000 0x15000>;
interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_BLSP2_AHB_CLK>;
clock-names = "bam_clk";
#dma-cells = <1>;
qcom,ee = <0>;
};
...

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