leandrof/linux
1
0
Fork 0
forked from Minki/linux
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

Browse Source 
No conflicts!

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This commit is contained in:
Jakub Kicinski 2021-09-16 13:58:38 -07:00
commit 561bed688b
1129 changed files with 36760 additions and 13185 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -128,6 +128,8 @@ Date: Aug 28, 2020
KernelVersion: 5.10.0
Contact: dmaengine@vger.kernel.org
Description: The last executed device administrative command's status/error.
Also last configuration error overloaded.
Writing to it will clear the status.
What: /sys/bus/dsa/devices/wq<m>.<n>/block_on_fault
Date: Oct 27, 2020
@ -211,6 +213,13 @@ Contact: dmaengine@vger.kernel.org
Description: Indicate whether ATS disable is turned on for the workqueue.
0 indicates ATS is on, and 1 indicates ATS is off for the workqueue.
What: /sys/bus/dsa/devices/wq<m>.<n>/occupancy
Date May 25, 2021
KernelVersion: 5.14.0
Contact: dmaengine@vger.kernel.org
Description: Show the current number of entries in this WQ if WQ Occupancy
Support bit WQ capabilities is 1.
What: /sys/bus/dsa/devices/engine<m>.<n>/group_id
Date: Oct 25, 2019
KernelVersion: 5.6.0

19
Documentation/ABI/testing/debugfs-driver-habanalabs
View File

@ -215,6 +215,17 @@ Description: Sets the skip reset on timeout option for the device. Value of
"0" means device will be reset in case some CS has timed out,
otherwise it will not be reset.
What: /sys/kernel/debug/habanalabs/hl<n>/state_dump
Date: Oct 2021
KernelVersion: 5.15
Contact: ynudelman@habana.ai
Description: Gets the state dump occurring on a CS timeout or failure.
State dump is used for debug and is created each time in case of
a problem in a CS execution, before reset.
Reading from the node returns the newest state dump available.
Writing an integer X discards X state dumps, so that the
next read would return X+1-st newest state dump.
What: /sys/kernel/debug/habanalabs/hl<n>/stop_on_err
Date: Mar 2020
KernelVersion: 5.6
@ -230,6 +241,14 @@ Description: Displays a list with information about the currently user
pointers (user virtual addresses) that are pinned and mapped
to DMA addresses
What: /sys/kernel/debug/habanalabs/hl<n>/userptr_lookup
Date: Aug 2021
KernelVersion: 5.15
Contact: ogabbay@kernel.org
Description: Allows to search for specific user pointers (user virtual
addresses) that are pinned and mapped to DMA addresses, and see
their resolution to the specific dma address.
What: /sys/kernel/debug/habanalabs/hl<n>/vm
Date: Jan 2019
KernelVersion: 5.1

17
Documentation/ABI/testing/sysfs-bus-pci
View File

@ -121,6 +121,23 @@ Description:
child buses, and re-discover devices removed earlier
from this part of the device tree.
What: /sys/bus/pci/devices/.../reset_method
Date: August 2021
Contact: Amey Narkhede <ameynarkhede03@gmail.com>
Description:
Some devices allow an individual function to be reset
without affecting other functions in the same slot.
For devices that have this support, a file named
reset_method is present in sysfs. Reading this file
gives names of the supported and enabled reset methods and
their ordering. Writing a space-separated list of names of
reset methods sets the reset methods and ordering to be
used when resetting the device. Writing an empty string
disables the ability to reset the device. Writing
"default" enables all supported reset methods in the
default ordering.
What: /sys/bus/pci/devices/.../reset
Date: July 2009
Contact: Michael S. Tsirkin <mst@redhat.com>

12
Documentation/PCI/endpoint/pci-endpoint-cfs.rst
View File

@ -43,6 +43,7 @@ entries corresponding to EPF driver will be created by the EPF core.
.. <EPF Driver1>/
... <EPF Device 11>/
... <EPF Device 21>/
... <EPF Device 31>/
.. <EPF Driver2>/
... <EPF Device 12>/
... <EPF Device 22>/
@ -68,6 +69,7 @@ created)
... subsys_vendor_id
... subsys_id
... interrupt_pin
... <Symlink EPF Device 31>/
... primary/
... <Symlink EPC Device1>/
... secondary/
@ -79,6 +81,13 @@ interface should be added in 'primary' directory and symlink of endpoint
controller connected to secondary interface should be added in 'secondary'
directory.
The <EPF Device> directory can have a list of symbolic links
(<Symlink EPF Device 31>) to other <EPF Device>. These symbolic links should
be created by the user to represent the virtual functions that are bound to
the physical function. In the above directory structure <EPF Device 11> is a
physical function and <EPF Device 31> is a virtual function. An EPF device once
it's linked to another EPF device, cannot be linked to a EPC device.
EPC Device
==========
@ -98,7 +107,8 @@ entries corresponding to EPC device will be created by the EPC core.
The <EPC Device> directory will have a list of symbolic links to
<EPF Device>. These symbolic links should be created by the user to
represent the functions present in the endpoint device.
represent the functions present in the endpoint device. Only <EPF Device>
that represents a physical function can be linked to a EPC device.
The <EPC Device> directory will also have a *start* field. Once
"1" is written to this field, the endpoint device will be ready to

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

@ -259,7 +259,7 @@ Configuring the kernel
Compiling the kernel
--------------------
- Make sure you have at least gcc 4.9 available.
- Make sure you have at least gcc 5.1 available.
For more information, refer to :ref:`Documentation/process/changes.rst <changes>`.
Please note that you can still run a.out user programs with this kernel.

49
Documentation/admin-guide/acpi/ssdt-overlays.rst
View File

@ -30,22 +30,21 @@ following ASL code can be used::
{
Device (STAC)
{
Name (_ADR, Zero)
Name (_HID, "BMA222E")
Name (RBUF, ResourceTemplate ()
{
I2cSerialBus (0x0018, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2C6", 0x00,
ResourceConsumer, ,)
GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x0000,
"\\_SB.GPO2", 0x00, ResourceConsumer, , )
{ // Pin list
0
}
})
Method (_CRS, 0, Serialized)
{
Name (RBUF, ResourceTemplate ()
{
I2cSerialBus (0x0018, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2C6", 0x00,
ResourceConsumer, ,)
GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x0000,
"\\_SB.GPO2", 0x00, ResourceConsumer, , )
{ // Pin list
0
}
})
Return (RBUF)
}
}
@ -75,7 +74,7 @@ This option allows loading of user defined SSDTs from initrd and it is useful
when the system does not support EFI or when there is not enough EFI storage.
It works in a similar way with initrd based ACPI tables override/upgrade: SSDT
aml code must be placed in the first, uncompressed, initrd under the
AML code must be placed in the first, uncompressed, initrd under the
"kernel/firmware/acpi" path. Multiple files can be used and this will translate
in loading multiple tables. Only SSDT and OEM tables are allowed. See
initrd_table_override.txt for more details.
@ -103,12 +102,14 @@ This is the preferred method, when EFI is supported on the platform, because it
allows a persistent, OS independent way of storing the user defined SSDTs. There
is also work underway to implement EFI support for loading user defined SSDTs
and using this method will make it easier to convert to the EFI loading
mechanism when that will arrive.
mechanism when that will arrive. To enable it, the
CONFIG_EFI_CUSTOM_SSDT_OVERLAYS shoyld be chosen to y.
In order to load SSDTs from an EFI variable the efivar_ssdt kernel command line
parameter can be used. The argument for the option is the variable name to
use. If there are multiple variables with the same name but with different
vendor GUIDs, all of them will be loaded.
In order to load SSDTs from an EFI variable the ``"efivar_ssdt=..."`` kernel
command line parameter can be used (the name has a limitation of 16 characters).
The argument for the option is the variable name to use. If there are multiple
variables with the same name but with different vendor GUIDs, all of them will
be loaded.
In order to store the AML code in an EFI variable the efivarfs filesystem can be
used. It is enabled and mounted by default in /sys/firmware/efi/efivars in all
@ -127,7 +128,7 @@ variable with the content from a given file::
#!/bin/sh -e
while ! [ -z "$1" ]; do
while [ -n "$1" ]; do
case "$1" in
"-f") filename="$2"; shift;;
"-g") guid="$2"; shift;;
@ -167,14 +168,14 @@ variable with the content from a given file::
Loading ACPI SSDTs from configfs
================================
This option allows loading of user defined SSDTs from userspace via the configfs
This option allows loading of user defined SSDTs from user space via the configfs
interface. The CONFIG_ACPI_CONFIGFS option must be select and configfs must be
mounted. In the following examples, we assume that configfs has been mounted in
/config.
/sys/kernel/config.
New tables can be loading by creating new directories in /config/acpi/table/ and
writing the SSDT aml code in the aml attribute::
New tables can be loading by creating new directories in /sys/kernel/config/acpi/table
and writing the SSDT AML code in the aml attribute::
cd /config/acpi/table
cd /sys/kernel/config/acpi/table
mkdir my_ssdt
cat ~/ssdt.aml > my_ssdt/aml

39
Documentation/admin-guide/bootconfig.rst
View File

@ -178,7 +178,7 @@ update the boot loader and the kernel image itself as long as the boot
loader passes the correct initrd file size. If by any chance, the boot
loader passes a longer size, the kernel fails to find the bootconfig data.
To do this operation, Linux kernel provides "bootconfig" command under
To do this operation, Linux kernel provides ``bootconfig`` command under
tools/bootconfig, which allows admin to apply or delete the config file
to/from initrd image. You can build it by the following command::
@ -196,6 +196,43 @@ To remove the config from the image, you can use -d option as below::
Then add "bootconfig" on the normal kernel command line to tell the
kernel to look for the bootconfig at the end of the initrd file.
Kernel parameters via Boot Config
=================================
In addition to the kernel command line, the boot config can be used for
passing the kernel parameters. All the key-value pairs under ``kernel``
key will be passed to kernel cmdline directly. Moreover, the key-value
pairs under ``init`` will be passed to init process via the cmdline.
The parameters are concatinated with user-given kernel cmdline string
as the following order, so that the command line parameter can override
bootconfig parameters (this depends on how the subsystem handles parameters
but in general, earlier parameter will be overwritten by later one.)::
[bootconfig params][cmdline params] -- [bootconfig init params][cmdline init params]
Here is an example of the bootconfig file for kernel/init parameters.::
kernel {
root = 01234567-89ab-cdef-0123-456789abcd
}
init {
splash
}
This will be copied into the kernel cmdline string as the following::
root="01234567-89ab-cdef-0123-456789abcd" -- splash
If user gives some other command line like,::
ro bootconfig -- quiet
The final kernel cmdline will be the following::
root="01234567-89ab-cdef-0123-456789abcd" ro bootconfig -- splash quiet
Config File Limitation
======================

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

@ -1758,6 +1758,11 @@
support for the idxd driver. By default it is set to
true (1).
idxd.tc_override= [HW]
Format: <bool>
Allow override of default traffic class configuration
for the device. By default it is set to false (0).
ieee754= [MIPS] Select IEEE Std 754 conformance mode
Format: { strict | legacy | 2008 | relaxed }
Default: strict

15
Documentation/admin-guide/mm/damon/index.rst Normal file
View File

@ -0,0 +1,15 @@
.. SPDX-License-Identifier: GPL-2.0
========================
Monitoring Data Accesses
========================
:doc:`DAMON </vm/damon/index>` allows light-weight data access monitoring.
Using DAMON, users can analyze the memory access patterns of their systems and
optimize those.
.. toctree::
:maxdepth: 2
start
usage

114
Documentation/admin-guide/mm/damon/start.rst Normal file
View File

@ -0,0 +1,114 @@
.. SPDX-License-Identifier: GPL-2.0
===============
Getting Started
===============
This document briefly describes how you can use DAMON by demonstrating its
default user space tool. Please note that this document describes only a part
of its features for brevity. Please refer to :doc:`usage` for more details.
TL; DR
======
Follow the commands below to monitor and visualize the memory access pattern of
your workload. ::
# # build the kernel with CONFIG_DAMON_*=y, install it, and reboot
# mount -t debugfs none /sys/kernel/debug/
# git clone https://github.com/awslabs/damo
# ./damo/damo record $(pidof <your workload>)
# ./damo/damo report heat --plot_ascii
The final command draws the access heatmap of ``<your workload>``. The heatmap
shows which memory region (x-axis) is accessed when (y-axis) and how frequently
(number; the higher the more accesses have been observed). ::
111111111111111111111111111111111111111111111111111111110000
111121111111111111111111111111211111111111111111111111110000
000000000000000000000000000000000000000000000000001555552000
000000000000000000000000000000000000000000000222223555552000
000000000000000000000000000000000000000011111677775000000000
000000000000000000000000000000000000000488888000000000000000
000000000000000000000000000000000177888400000000000000000000
000000000000000000000000000046666522222100000000000000000000
000000000000000000000014444344444300000000000000000000000000
000000000000000002222245555510000000000000000000000000000000
# access_frequency: 0 1 2 3 4 5 6 7 8 9
# x-axis: space (140286319947776-140286426374096: 101.496 MiB)
# y-axis: time (605442256436361-605479951866441: 37.695430s)
# resolution: 60x10 (1.692 MiB and 3.770s for each character)
Prerequisites
=============
Kernel
------
You should first ensure your system is running on a kernel built with
``CONFIG_DAMON_*=y``.
User Space Tool
---------------
For the demonstration, we will use the default user space tool for DAMON,
called DAMON Operator (DAMO). It is available at
https://github.com/awslabs/damo. The examples below assume that ``damo`` is on
your ``$PATH``. It's not mandatory, though.
Because DAMO is using the debugfs interface (refer to :doc:`usage` for the
detail) of DAMON, you should ensure debugfs is mounted. Mount it manually as
below::
# mount -t debugfs none /sys/kernel/debug/
or append the following line to your ``/etc/fstab`` file so that your system
can automatically mount debugfs upon booting::
debugfs /sys/kernel/debug debugfs defaults 0 0
Recording Data Access Patterns
==============================
The commands below record the memory access patterns of a program and save the
monitoring results to a file. ::
$ git clone https://github.com/sjp38/masim
$ cd masim; make; ./masim ./configs/zigzag.cfg &
$ sudo damo record -o damon.data $(pidof masim)
The first two lines of the commands download an artificial memory access
generator program and run it in the background. The generator will repeatedly
access two 100 MiB sized memory regions one by one. You can substitute this
with your real workload. The last line asks ``damo`` to record the access
pattern in the ``damon.data`` file.
Visualizing Recorded Patterns
=============================
The following three commands visualize the recorded access patterns and save
the results as separate image files. ::
$ damo report heats --heatmap access_pattern_heatmap.png
$ damo report wss --range 0 101 1 --plot wss_dist.png
$ damo report wss --range 0 101 1 --sortby time --plot wss_chron_change.png
- ``access_pattern_heatmap.png`` will visualize the data access pattern in a
heatmap, showing which memory region (y-axis) got accessed when (x-axis)
and how frequently (color).
- ``wss_dist.png`` will show the distribution of the working set size.
- ``wss_chron_change.png`` will show how the working set size has
chronologically changed.
You can view the visualizations of this example workload at [1]_.
Visualizations of other realistic workloads are available at [2]_ [3]_ [4]_.
.. [1] https://damonitor.github.io/doc/html/v17/admin-guide/mm/damon/start.html#visualizing-recorded-patterns
.. [2] https://damonitor.github.io/test/result/visual/latest/rec.heatmap.1.png.html
.. [3] https://damonitor.github.io/test/result/visual/latest/rec.wss_sz.png.html
.. [4] https://damonitor.github.io/test/result/visual/latest/rec.wss_time.png.html

112
Documentation/admin-guide/mm/damon/usage.rst Normal file
View File

@ -0,0 +1,112 @@
.. SPDX-License-Identifier: GPL-2.0
===============
Detailed Usages
===============
DAMON provides below three interfaces for different users.
- *DAMON user space tool.*
This is for privileged people such as system administrators who want a
just-working human-friendly interface. Using this, users can use the DAMON’s
major features in a human-friendly way. It may not be highly tuned for
special cases, though. It supports only virtual address spaces monitoring.
- *debugfs interface.*
This is for privileged user space programmers who want more optimized use of
DAMON. Using this, users can use DAMON’s major features by reading
from and writing to special debugfs files. Therefore, you can write and use
your personalized DAMON debugfs wrapper programs that reads/writes the
debugfs files instead of you. The DAMON user space tool is also a reference
implementation of such programs. It supports only virtual address spaces
monitoring.
- *Kernel Space Programming Interface.*
This 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.
Nevertheless, you could write your own user space tool using the debugfs
interface. A reference implementation is available at
https://github.com/awslabs/damo. If you are a kernel programmer, you could
refer to :doc:`/vm/damon/api` for the kernel space programming interface. For
the reason, this document describes only the debugfs interface
debugfs Interface
=================
DAMON exports three files, ``attrs``, ``target_ids``, and ``monitor_on`` under
its debugfs directory, ``<debugfs>/damon/``.
Attributes
----------
Users can get and set the ``sampling interval``, ``aggregation interval``,
``regions 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
example, below commands set those values to 5 ms, 100 ms, 1,000 ms, 10 and
1000, and then check it again::
# cd <debugfs>/damon
# echo 5000 100000 1000000 10 1000 > attrs
# cat attrs
5000 100000 1000000 10 1000
Target IDs
----------
Some types of address spaces supports multiple monitoring target. For example,
the virtual memory address spaces monitoring can have multiple processes as the
monitoring targets. Users can set the targets by writing relevant id values of
the targets to, and get the ids of the current targets by reading from the
``target_ids`` file. In case of the virtual address spaces monitoring, the
values should be pids of the monitoring target processes. For example, below
commands set processes having pids 42 and 4242 as the monitoring targets and
check it again::
# cd <debugfs>/damon
# echo 42 4242 > target_ids
# cat target_ids
42 4242
Note that setting the target ids doesn't start the monitoring.
Turning On/Off
--------------
Setting the files as described above doesn't incur effect unless you explicitly
start the monitoring. You can start, stop, and check the current status of the
monitoring by writing to and reading from the ``monitor_on`` file. Writing
``on`` to the file starts the monitoring of the targets with the attributes.
Writing ``off`` to the file stops those. DAMON also stops if every target
process is terminated. Below example commands turn on, off, and check the
status of DAMON::
# cd <debugfs>/damon
# echo on > monitor_on
# echo off > monitor_on
# cat monitor_on
off
Please note that you cannot write to the above-mentioned debugfs files while
the monitoring is turned on. If you write to the files while DAMON is running,
an error code such as ``-EBUSY`` will be returned.
Tracepoint for Monitoring Results
=================================
DAMON provides the monitoring results via a tracepoint,
``damon:damon_aggregated``. While the monitoring is turned on, you could
record the tracepoint events and show results using tracepoint supporting tools
like ``perf``. For example::
# echo on > monitor_on
# perf record -e damon:damon_aggregated &
# sleep 5
# kill 9 $(pidof perf)
# echo off > monitor_on
# perf script

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

@ -27,6 +27,7 @@ the Linux memory management.
concepts
cma_debugfs
damon/index
hugetlbpage
idle_page_tracking
ksm

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

@ -1,466 +1,576 @@
.. _admin_guide_memory_hotplug:
==============
Memory Hotplug
==============
==================
Memory Hot(Un)Plug
==================
:Created: Jul 28 2007
:Updated: Add some details about locking internals: Aug 20 2018
This document is about memory hotplug including how-to-use and current status.
Because Memory Hotplug is still under development, contents of this text will
be changed often.
This document describes generic Linux support for memory hot(un)plug with
a focus on System RAM, including ZONE_MOVABLE support.
.. contents:: :local:
.. note::
(1) x86_64's has special implementation for memory hotplug.
This text does not describe it.
(2) This text assumes that sysfs is mounted at ``/sys``.
Introduction
============
Purpose of memory hotplug
-------------------------
Memory hot(un)plug allows for increasing and decreasing the size of physical
memory available to a machine at runtime. In the simplest case, it consists of
physically plugging or unplugging a DIMM at runtime, coordinated with the
operating system.
Memory Hotplug allows users to increase/decrease the amount of memory.
Generally, there are two purposes.
Memory hot(un)plug is used for various purposes:
(A) For changing the amount of memory.
This is to allow a feature like capacity on demand.
(B) For installing/removing DIMMs or NUMA-nodes physically.
This is to exchange DIMMs/NUMA-nodes, reduce power consumption, etc.
- The physical memory available to a machine can be adjusted at runtime, up- or
downgrading the memory capacity. This dynamic memory resizing, sometimes
referred to as "capacity on demand", is frequently used with virtual machines
and logical partitions.
(A) is required by highly virtualized environments and (B) is required by
hardware which supports memory power management.
- Replacing hardware, such as DIMMs or whole NUMA nodes, without downtime. One
example is replacing failing memory modules.
Linux memory hotplug is designed for both purpose.
- Reducing energy consumption either by physically unplugging memory modules or
by logically unplugging (parts of) memory modules from Linux.
Phases of memory hotplug
------------------------
Further, the basic memory hot(un)plug infrastructure in Linux is nowadays also
used to expose persistent memory, other performance-differentiated memory and
reserved memory regions as ordinary system RAM to Linux.
There are 2 phases in Memory Hotplug:
Linux only supports memory hot(un)plug on selected 64 bit architectures, such as
x86_64, arm64, ppc64, s390x and ia64.
1) Physical Memory Hotplug phase
2) Logical Memory Hotplug phase.
Memory Hot(Un)Plug Granularity
------------------------------
The First phase is to communicate hardware/firmware and make/erase
environment for hotplugged memory. Basically, this phase is necessary
for the purpose (B), but this is good phase for communication between
highly virtualized environments too.
When memory is hotplugged, the kernel recognizes new memory, makes new memory
management tables, and makes sysfs files for new memory's operation.
If firmware supports notification of connection of new memory to OS,
this phase is triggered automatically. ACPI can notify this event. If not,
"probe" operation by system administration is used instead.
(see :ref:`memory_hotplug_physical_mem`).
Logical Memory Hotplug phase is to change memory state into
available/unavailable for users. Amount of memory from user's view is
changed by this phase. The kernel makes all memory in it as free pages
when a memory range is available.
In this document, this phase is described as online/offline.
Logical Memory Hotplug phase is triggered by write of sysfs file by system
administrator. For the hot-add case, it must be executed after Physical Hotplug
phase by hand.
(However, if you writes udev's hotplug scripts for memory hotplug, these
phases can be execute in seamless way.)
Unit of Memory online/offline operation
---------------------------------------
Memory hotplug uses SPARSEMEM memory model which allows memory to be divided
into chunks of the same size. These chunks are called "sections". The size of
a memory section is architecture dependent. For example, power uses 16MiB, ia64
uses 1GiB.
Memory hot(un)plug in Linux uses the SPARSEMEM memory model, which divides the
physical memory address space into chunks of the same size: memory sections. The
size of a memory section is architecture dependent. For example, x86_64 uses
128 MiB and ppc64 uses 16 MiB.
Memory sections are combined into chunks referred to as "memory blocks". The
size of a memory block is architecture dependent and represents the logical
unit upon which memory online/offline operations are to be performed. The
default size of a memory block is the same as memory section size unless an
architecture specifies otherwise. (see :ref:`memory_hotplug_sysfs_files`.)
size of a memory block is architecture dependent and corresponds to the smallest
granularity that can be hot(un)plugged. The default size of a memory block is
the same as memory section size, unless an architecture specifies otherwise.
To determine the size (in bytes) of a memory block please read this file::
All memory blocks have the same size.
/sys/devices/system/memory/block_size_bytes
Phases of Memory Hotplug
------------------------
Kernel Configuration
====================
Memory hotplug consists of two phases:
To use memory hotplug feature, kernel must be compiled with following
config options.
(1) Adding the memory to Linux
(2) Onlining memory blocks
- For all memory hotplug:
- Memory model -> Sparse Memory (``CONFIG_SPARSEMEM``)
- Allow for memory hot-add (``CONFIG_MEMORY_HOTPLUG``)
In the first phase, metadata, such as the memory map ("memmap") and page tables
for the direct mapping, is allocated and initialized, and memory blocks are
created; the latter also creates sysfs files for managing newly created memory
blocks.
- To enable memory removal, the following are also necessary:
- Allow for memory hot remove (``CONFIG_MEMORY_HOTREMOVE``)
- Page Migration (``CONFIG_MIGRATION``)
In the second phase, added memory is exposed to the page allocator. After this
phase, the memory is visible in memory statistics, such as free and total
memory, of the system.
- For ACPI memory hotplug, the following are also necessary:
- Memory hotplug (under ACPI Support menu) (``CONFIG_ACPI_HOTPLUG_MEMORY``)
- This option can be kernel module.
Phases of Memory Hotunplug
--------------------------
- As a related configuration, if your box has a feature of NUMA-node hotplug
via ACPI, then this option is necessary too.
Memory hotunplug consists of two phases:
- ACPI0004,PNP0A05 and PNP0A06 Container Driver (under ACPI Support menu)
(``CONFIG_ACPI_CONTAINER``).
(1) Offlining memory blocks
(2) Removing the memory from Linux
This option can be kernel module too.
In the fist phase, memory is "hidden" from the page allocator again, for
example, by migrating busy memory to other memory locations and removing all
relevant free pages from the page allocator After this phase, the memory is no
longer visible in memory statistics of the system.
In the second phase, the memory blocks are removed and metadata is freed.
.. _memory_hotplug_sysfs_files:
Memory Hotplug Notifications
============================
sysfs files for memory hotplug
There are various ways how Linux is notified about memory hotplug events such
that it can start adding hotplugged memory. This description is limited to
systems that support ACPI; mechanisms specific to other firmware interfaces or
virtual machines are not described.
ACPI Notifications
------------------
Platforms that support ACPI, such as x86_64, can support memory hotplug
notifications via ACPI.
In general, a firmware supporting memory hotplug defines a memory class object
HID "PNP0C80". When notified about hotplug of a new memory device, the ACPI
driver will hotplug the memory to Linux.
If the firmware supports hotplug of NUMA nodes, it defines an object _HID
"ACPI0004", "PNP0A05", or "PNP0A06". When notified about an hotplug event, all
assigned memory devices are added to Linux by the ACPI driver.
Similarly, Linux can be notified about requests to hotunplug a memory device or
a NUMA node via ACPI. The ACPI driver will try offlining all relevant memory
blocks, and, if successful, hotunplug the memory from Linux.
Manual Probing
--------------
On some architectures, the firmware may not be able to notify the operating
system about a memory hotplug event. Instead, the memory has to be manually
probed from user space.
The probe interface is located at::
/sys/devices/system/memory/probe
Only complete memory blocks can be probed. Individual memory blocks are probed
by providing the physical start address of the memory block::
% echo addr > /sys/devices/system/memory/probe
Which results in a memory block for the range [addr, addr + memory_block_size)
being created.
.. note::
Using the probe interface is discouraged as it is easy to crash the kernel,
because Linux cannot validate user input; this interface might be removed in
the future.
Onlining and Offlining Memory Blocks
====================================
After a memory block has been created, Linux has to be instructed to actually
make use of that memory: the memory block has to be "online".
Before a memory block can be removed, Linux has to stop using any memory part of
the memory block: the memory block has to be "offlined".
The Linux kernel can be configured to automatically online added memory blocks
and drivers automatically trigger offlining of memory blocks when trying
hotunplug of memory. Memory blocks can only be removed once offlining succeeded
and drivers may trigger offlining of memory blocks when attempting hotunplug of
memory.
Onlining Memory Blocks Manually
-------------------------------
If auto-onlining of memory blocks isn't enabled, user-space has to manually
trigger onlining of memory blocks. Often, udev rules are used to automate this
task in user space.
Onlining of a memory block can be triggered via::
% echo online > /sys/devices/system/memory/memoryXXX/state
Or alternatively::
% echo 1 > /sys/devices/system/memory/memoryXXX/online
The kernel will select the target zone automatically, usually defaulting to
``ZONE_NORMAL`` unless ``movablecore=1`` has been specified on the kernel
command line or if the memory block would intersect the ZONE_MOVABLE already.
One can explicitly request to associate an offline memory block with
ZONE_MOVABLE by::
% echo online_movable > /sys/devices/system/memory/memoryXXX/state
Or one can explicitly request a kernel zone (usually ZONE_NORMAL) by::
% echo online_kernel > /sys/devices/system/memory/memoryXXX/state
In any case, if onlining succeeds, the state of the memory block is changed to
be "online". If it fails, the state of the memory block will remain unchanged
and the above commands will fail.
Onlining Memory Blocks Automatically
------------------------------------
The kernel can be configured to try auto-onlining of newly added memory blocks.
If this feature is disabled, the memory blocks will stay offline until
explicitly onlined from user space.
The configured auto-online behavior can be observed via::
% cat /sys/devices/system/memory/auto_online_blocks
Auto-onlining can be enabled by writing ``online``, ``online_kernel`` or
``online_movable`` to that file, like::
% echo online > /sys/devices/system/memory/auto_online_blocks
Modifying the auto-online behavior will only affect all subsequently added
memory blocks only.
.. note::
In corner cases, auto-onlining can fail. The kernel won't retry. Note that
auto-onlining is not expected to fail in default configurations.
.. note::
DLPAR on ppc64 ignores the ``offline`` setting and will still online added
memory blocks; if onlining fails, memory blocks are removed again.
Offlining Memory Blocks
-----------------------
In the current implementation, Linux's memory offlining will try migrating all
movable pages off the affected memory block. As most kernel allocations, such as
page tables, are unmovable, page migration can fail and, therefore, inhibit
memory offlining from succeeding.
Having the memory provided by memory block managed by ZONE_MOVABLE significantly
increases memory offlining reliability; still, memory offlining can fail in
some corner cases.
Further, memory offlining might retry for a long time (or even forever), until
aborted by the user.
Offlining of a memory block can be triggered via::
% echo offline > /sys/devices/system/memory/memoryXXX/state
Or alternatively::
% echo 0 > /sys/devices/system/memory/memoryXXX/online
If offlining succeeds, the state of the memory block is changed to be "offline".
If it fails, the state of the memory block will remain unchanged and the above
commands will fail, for example, via::
bash: echo: write error: Device or resource busy
or via::
bash: echo: write error: Invalid argument
Observing the State of Memory Blocks
------------------------------------
The state (online/offline/going-offline) of a memory block can be observed
either via::
% cat /sys/device/system/memory/memoryXXX/state
Or alternatively (1/0) via::
% cat /sys/device/system/memory/memoryXXX/online
For an online memory block, the managing zone can be observed via::
% cat /sys/device/system/memory/memoryXXX/valid_zones
Configuring Memory Hot(Un)Plug
==============================
All memory blocks have their device information in sysfs. Each memory block
is described under ``/sys/devices/system/memory`` as::
There are various ways how system administrators can configure memory
hot(un)plug and interact with memory blocks, especially, to online them.
Memory Hot(Un)Plug Configuration via Sysfs
------------------------------------------
Some memory hot(un)plug properties can be configured or inspected via sysfs in::
/sys/devices/system/memory/
The following files are currently defined:
====================== =========================================================
``auto_online_blocks`` read-write: set or get the default state of new memory
blocks; configure auto-onlining.
The default value depends on the
CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE kernel configuration
option.
See the ``state`` property of memory blocks for details.
``block_size_bytes`` read-only: the size in bytes of a memory block.
``probe`` write-only: add (probe) selected memory blocks manually
from user space by supplying the physical start address.
Availability depends on the CONFIG_ARCH_MEMORY_PROBE
kernel configuration option.
``uevent`` read-write: generic udev file for device subsystems.
====================== =========================================================
.. note::
When the CONFIG_MEMORY_FAILURE kernel configuration option is enabled, two
additional files ``hard_offline_page`` and ``soft_offline_page`` are available
to trigger hwpoisoning of pages, for example, for testing purposes. Note that
this functionality is not really related to memory hot(un)plug or actual
offlining of memory blocks.
Memory Block Configuration via Sysfs
------------------------------------
Each memory block is represented as a memory block device that can be
onlined or offlined. All memory blocks have their device information located in
sysfs. Each present memory block is listed under
``/sys/devices/system/memory`` as::
/sys/devices/system/memory/memoryXXX
where XXX is the memory block id.
where XXX is the memory block id; the number of digits is variable.
For the memory block covered by the sysfs directory. It is expected that all
memory sections in this range are present and no memory holes exist in the
range. Currently there is no way to determine if there is a memory hole, but
the existence of one should not affect the hotplug capabilities of the memory
block.
A present memory block indicates that some memory in the range is present;
however, a memory block might span memory holes. A memory block spanning memory
holes cannot be offlined.
For example, assume 1GiB memory block size. A device for a memory starting at
For example, assume 1 GiB memory block size. A device for a memory starting at
0x100000000 is ``/sys/device/system/memory/memory4``::
(0x100000000 / 1Gib = 4)
This device covers address range [0x100000000 ... 0x140000000)
Under each memory block, you can see 5 files:
- ``/sys/devices/system/memory/memoryXXX/phys_index``
- ``/sys/devices/system/memory/memoryXXX/phys_device``
- ``/sys/devices/system/memory/memoryXXX/state``
- ``/sys/devices/system/memory/memoryXXX/removable``
- ``/sys/devices/system/memory/memoryXXX/valid_zones``
The following files are currently defined:
=================== ============================================================
``phys_index`` read-only and contains memory block id, same as XXX.
``state`` read-write
- at read: contains online/offline state of memory.
- at write: user can specify "online_kernel",
"online_movable", "online", "offline" command
which will be performed on all sections in the block.
``online`` read-write: simplified interface to trigger onlining /
offlining and to observe the state of a memory block.
When onlining, the zone is selected automatically.
``phys_device`` read-only: legacy interface only ever used on s390x to
expose the covered storage increment.
``phys_index`` read-only: the memory block id (XXX).
``removable`` read-only: legacy interface that indicated whether a memory
block was likely to be offlineable or not. Newer kernel
versions return "1" if and only if the kernel supports
memory offlining.
``valid_zones`` read-only: designed to show by which zone memory provided by
a memory block is managed, and to show by which zone memory
provided by an offline memory block could be managed when
onlining.
block was likely to be offlineable or not. Nowadays, the
kernel return ``1`` if and only if it supports memory
offlining.
``state`` read-write: advanced interface to trigger onlining /
offlining and to observe the state of a memory block.
The first column shows it`s default zone.
When writing, ``online``, ``offline``, ``online_kernel`` and
``online_movable`` are supported.
"memory6/valid_zones: Normal Movable" shows this memoryblock
can be onlined to ZONE_NORMAL by default and to ZONE_MOVABLE
by online_movable.
``online_movable`` specifies onlining to ZONE_MOVABLE.
``online_kernel`` specifies onlining to the default kernel
zone for the memory block, such as ZONE_NORMAL.
``online`` let's the kernel select the zone automatically.
"memory7/valid_zones: Movable Normal" shows this memoryblock
can be onlined to ZONE_MOVABLE by default and to ZONE_NORMAL
by online_kernel.
When reading, ``online``, ``offline`` and ``going-offline``
may be returned.
``uevent`` read-write: generic uevent file for devices.
``valid_zones`` read-only: when a block is online, shows the zone it
belongs to; when a block is offline, shows what zone will
manage it when the block will be onlined.
For online memory blocks, ``DMA``, ``DMA32``, ``Normal``,
``Movable`` and ``none`` may be returned. ``none`` indicates
that memory provided by a memory block is managed by
multiple zones or spans multiple nodes; such memory blocks
cannot be offlined. ``Movable`` indicates ZONE_MOVABLE.
Other values indicate a kernel zone.
For offline memory blocks, the first column shows the
zone the kernel would select when onlining the memory block
right now without further specifying a zone.
Availability depends on the CONFIG_MEMORY_HOTREMOVE
kernel configuration option.
=================== ============================================================
.. note::
These directories/files appear after physical memory hotplug phase.
If the CONFIG_NUMA kernel configuration option is enabled, the memoryXXX/
directories can also be accessed via symbolic links located in the
``/sys/devices/system/node/node*`` directories.
If CONFIG_NUMA is enabled the memoryXXX/ directories can also be accessed
via symbolic links located in the ``/sys/devices/system/node/node*`` directories.
For example::
For example::
/sys/devices/system/node/node0/memory9 -> ../../memory/memory9
A backlink will also be created::
A backlink will also be created::
/sys/devices/system/memory/memory9/node0 -> ../../node/node0
.. _memory_hotplug_physical_mem:
Command Line Parameters
-----------------------
Physical memory hot-add phase
=============================
Some command line parameters affect memory hot(un)plug handling. The following
command line parameters are relevant:
Hardware(Firmware) Support
--------------------------
======================== =======================================================
``memhp_default_state`` configure auto-onlining by essentially setting
``/sys/devices/system/memory/auto_online_blocks``.
``movablecore`` configure automatic zone selection of the kernel. When
set, the kernel will default to ZONE_MOVABLE, unless
other zones can be kept contiguous.
======================== =======================================================
On x86_64/ia64 platform, memory hotplug by ACPI is supported.
Module Parameters
------------------
In general, the firmware (ACPI) which supports memory hotplug defines
memory class object of _HID "PNP0C80". When a notify is asserted to PNP0C80,
Linux's ACPI handler does hot-add memory to the system and calls a hotplug udev
script. This will be done automatically.
Instead of additional command line parameters or sysfs files, the
``memory_hotplug`` subsystem now provides a dedicated namespace for module
parameters. Module parameters can be set via the command line by predicating
them with ``memory_hotplug.`` such as::
But scripts for memory hotplug are not contained in generic udev package(now).
You may have to write it by yourself or online/offline memory by hand.
Please see :ref:`memory_hotplug_how_to_online_memory` and
:ref:`memory_hotplug_how_to_offline_memory`.
memory_hotplug.memmap_on_memory=1
If firmware supports NUMA-node hotplug, and defines an object _HID "ACPI0004",
"PNP0A05", or "PNP0A06", notification is asserted to it, and ACPI handler
calls hotplug code for all of objects which are defined in it.
If memory device is found, memory hotplug code will be called.
and they can be observed (and some even modified at runtime) via::
Notify memory hot-add event by hand
-----------------------------------
/sys/modules/memory_hotplug/parameters/
On some architectures, the firmware may not notify the kernel of a memory
hotplug event. Therefore, the memory "probe" interface is supported to
explicitly notify the kernel. This interface depends on
CONFIG_ARCH_MEMORY_PROBE and can be configured on powerpc, sh, and x86
if hotplug is supported, although for x86 this should be handled by ACPI
notification.
The following module parameters are currently defined:
Probe interface is located at::
======================== =======================================================
``memmap_on_memory`` read-write: Allocate memory for the memmap from the
added memory block itself. Even if enabled, actual
support depends on various other system properties and
should only be regarded as a hint whether the behavior
would be desired.
/sys/devices/system/memory/probe
While allocating the memmap from the memory block
itself makes memory hotplug less likely to fail and
keeps the memmap on the same NUMA node in any case, it
can fragment physical memory in a way that huge pages
in bigger granularity cannot be formed on hotplugged
memory.
======================== =======================================================
You can tell the physical address of new memory to the kernel by::
ZONE_MOVABLE
============
% echo start_address_of_new_memory > /sys/devices/system/memory/probe
ZONE_MOVABLE is an important mechanism for more reliable memory offlining.
Further, having system RAM managed by ZONE_MOVABLE instead of one of the
kernel zones can increase the number of possible transparent huge pages and
dynamically allocated huge pages.
Then, [start_address_of_new_memory, start_address_of_new_memory +
memory_block_size] memory range is hot-added. In this case, hotplug script is
not called (in current implementation). You'll have to online memory by
yourself. Please see :ref:`memory_hotplug_how_to_online_memory`.
Most kernel allocations are unmovable. Important examples include the memory
map (usually 1/64ths of memory), page tables, and kmalloc(). Such allocations
can only be served from the kernel zones.
Logical Memory hot-add phase
============================
Most user space pages, such as anonymous memory, and page cache pages are
movable. Such allocations can be served from ZONE_MOVABLE and the kernel zones.
State of memory
Only movable allocations are served from ZONE_MOVABLE, resulting in unmovable
allocations being limited to the kernel zones. Without ZONE_MOVABLE, there is
absolutely no guarantee whether a memory block can be offlined successfully.
Zone Imbalances
---------------
To see (online/offline) state of a memory block, read 'state' file::
Having too much system RAM managed by ZONE_MOVABLE is called a zone imbalance,
which can harm the system or degrade performance. As one example, the kernel
might crash because it runs out of free memory for unmovable allocations,
although there is still plenty of free memory left in ZONE_MOVABLE.
% cat /sys/device/system/memory/memoryXXX/state
Usually, MOVABLE:KERNEL ratios of up to 3:1 or even 4:1 are fine. Ratios of 63:1
are definitely impossible due to the overhead for the memory map.
- If the memory block is online, you'll read "online".
- If the memory block is offline, you'll read "offline".
.. _memory_hotplug_how_to_online_memory:
How to online memory
--------------------
When the memory is hot-added, the kernel decides whether or not to "online"
it according to the policy which can be read from "auto_online_blocks" file::
% cat /sys/devices/system/memory/auto_online_blocks
The default depends on the CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE kernel config
option. If it is disabled the default is "offline" which means the newly added
memory is not in a ready-to-use state and you have to "online" the newly added
memory blocks manually. Automatic onlining can be requested by writing "online"
to "auto_online_blocks" file::
% echo online > /sys/devices/system/memory/auto_online_blocks
This sets a global policy and impacts all memory blocks that will subsequently
be hotplugged. Currently offline blocks keep their state. It is possible, under
certain circumstances, that some memory blocks will be added but will fail to
online. User space tools can check their "state" files
(``/sys/devices/system/memory/memoryXXX/state``) and try to online them manually.
If the automatic onlining wasn't requested, failed, or some memory block was
offlined it is possible to change the individual block's state by writing to the
"state" file::
% echo online > /sys/devices/system/memory/memoryXXX/state
This onlining will not change the ZONE type of the target memory block,
If the memory block doesn't belong to any zone an appropriate kernel zone
(usually ZONE_NORMAL) will be used unless movable_node kernel command line
option is specified when ZONE_MOVABLE will be used.
You can explicitly request to associate it with ZONE_MOVABLE by::
% echo online_movable > /sys/devices/system/memory/memoryXXX/state
.. note:: current limit: this memory block must be adjacent to ZONE_MOVABLE
Or you can explicitly request a kernel zone (usually ZONE_NORMAL) by::
% echo online_kernel > /sys/devices/system/memory/memoryXXX/state
.. note:: current limit: this memory block must be adjacent to ZONE_NORMAL
An explicit zone onlining can fail (e.g. when the range is already within
and existing and incompatible zone already).
After this, memory block XXX's state will be 'online' and the amount of
available memory will be increased.
This may be changed in future.
Logical memory remove
=====================
Memory offline and ZONE_MOVABLE
-------------------------------
Memory offlining is more complicated than memory online. Because memory offline
has to make the whole memory block be unused, memory offline can fail if
the memory block includes memory which cannot be freed.
In general, memory offline can use 2 techniques.
(1) reclaim and free all memory in the memory block.
(2) migrate all pages in the memory block.
In the current implementation, Linux's memory offline uses method (2), freeing
all pages in the memory block by page migration. But not all pages are
migratable. Under current Linux, migratable pages are anonymous pages and
page caches. For offlining a memory block by migration, the kernel has to
guarantee that the memory block contains only migratable pages.
Now, a boot option for making a memory block which consists of migratable pages
is supported. By specifying "kernelcore=" or "movablecore=" boot option, you can
create ZONE_MOVABLE...a zone which is just used for movable pages.
(See also Documentation/admin-guide/kernel-parameters.rst)
Assume the system has "TOTAL" amount of memory at boot time, this boot option
creates ZONE_MOVABLE as following.
1) When kernelcore=YYYY boot option is used,
Size of memory not for movable pages (not for offline) is YYYY.
Size of memory for movable pages (for offline) is TOTAL-YYYY.
2) When movablecore=ZZZZ boot option is used,
Size of memory not for movable pages (not for offline) is TOTAL - ZZZZ.
Size of memory for movable pages (for offline) is ZZZZ.
Actual safe zone ratios depend on the workload. Extreme cases, like excessive
long-term pinning of pages, might not be able to deal with ZONE_MOVABLE at all.
.. note::
Unfortunately, there is no information to show which memory block belongs
to ZONE_MOVABLE. This is TBD.
CMA memory part of a kernel zone essentially behaves like memory in
ZONE_MOVABLE and similar considerations apply, especially when combining
CMA with ZONE_MOVABLE.
Memory offlining can fail when dissolving a free huge page on ZONE_MOVABLE
and the feature of freeing unused vmemmap pages associated with each hugetlb
page is enabled.
ZONE_MOVABLE Sizing Considerations
----------------------------------
This can happen when we have plenty of ZONE_MOVABLE memory, but not enough
kernel memory to allocate vmemmmap pages. We may even be able to migrate
huge page contents, but will not be able to dissolve the source huge page.
This will prevent an offline operation and is unfortunate as memory offlining
is expected to succeed on movable zones. Users that depend on memory hotplug
to succeed for movable zones should carefully consider whether the memory
savings gained from this feature are worth the risk of possibly not being
able to offline memory in certain situations.
We usually expect that a large portion of available system RAM will actually
be consumed by user space, either directly or indirectly via the page cache. In
the normal case, ZONE_MOVABLE can be used when allocating such pages just fine.
.. note::
Techniques that rely on long-term pinnings of memory (especially, RDMA and
vfio) are fundamentally problematic with ZONE_MOVABLE and, therefore, memory
hot remove. Pinned pages cannot reside on ZONE_MOVABLE, to guarantee that
memory can still get hot removed - be aware that pinning can fail even if
there is plenty of free memory in ZONE_MOVABLE. In addition, using
ZONE_MOVABLE might make page pinning more expensive, because pages have to be
migrated off that zone first.
With that in mind, it makes sense that we can have a big portion of system RAM
managed by ZONE_MOVABLE. However, there are some things to consider when using
ZONE_MOVABLE, especially when fine-tuning zone ratios:
.. _memory_hotplug_how_to_offline_memory:
- Having a lot of offline memory blocks. Even offline memory blocks consume
memory for metadata and page tables in the direct map; having a lot of offline
memory blocks is not a typical case, though.
How to offline memory
---------------------
- Memory ballooning without balloon compaction is incompatible with
ZONE_MOVABLE. Only some implementations, such as virtio-balloon and
pseries CMM, fully support balloon compaction.
You can offline a memory block by using the same sysfs interface that was used
in memory onlining::
Further, the CONFIG_BALLOON_COMPACTION kernel configuration option might be
disabled. In that case, balloon inflation will only perform unmovable
allocations and silently create a zone imbalance, usually triggered by
inflation requests from the hypervisor.
% echo offline > /sys/devices/system/memory/memoryXXX/state
- Gigantic pages are unmovable, resulting in user space consuming a
lot of unmovable memory.
If offline succeeds, the state of the memory block is changed to be "offline".
If it fails, some error core (like -EBUSY) will be returned by the kernel.
Even if a memory block does not belong to ZONE_MOVABLE, you can try to offline
it. If it doesn't contain 'unmovable' memory, you'll get success.
- Huge pages are unmovable when an architectures does not support huge
page migration, resulting in a similar issue as with gigantic pages.
A memory block under ZONE_MOVABLE is considered to be able to be offlined
easily. But under some busy state, it may return -EBUSY. Even if a memory
block cannot be offlined due to -EBUSY, you can retry offlining it and may be
able to offline it (or not). (For example, a page is referred to by some kernel
internal call and released soon.)
- Page tables are unmovable. Excessive swapping, mapping extremely large
files or ZONE_DEVICE memory can be problematic, although only really relevant
in corner cases. When we manage a lot of user space memory that has been
swapped out or is served from a file/persistent memory/... we still need a lot
of page tables to manage that memory once user space accessed that memory.
Consideration:
Memory hotplug's design direction is to make the possibility of memory
offlining higher and to guarantee unplugging memory under any situation. But
it needs more work. Returning -EBUSY under some situation may be good because
the user can decide to retry more or not by himself. Currently, memory
offlining code does some amount of retry with 120 seconds timeout.
- In certain DAX configurations the memory map for the device memory will be
allocated from the kernel zones.
Physical memory remove
======================
- KASAN can have a significant memory overhead, for example, consuming 1/8th of
the total system memory size as (unmovable) tracking metadata.
Need more implementation yet....
- Notification completion of remove works by OS to firmware.
- Guard from remove if not yet.
- Long-term pinning of pages. Techniques that rely on long-term pinnings
(especially, RDMA and vfio/mdev) are fundamentally problematic with
ZONE_MOVABLE, and therefore, memory offlining. Pinned pages cannot reside
on ZONE_MOVABLE as that would turn these pages unmovable. Therefore, they
have to be migrated off that zone while pinning. Pinning a page can fail
even if there is plenty of free memory in ZONE_MOVABLE.
In addition, using ZONE_MOVABLE might make page pinning more expensive,
because of the page migration overhead.
Locking Internals
=================
By default, all the memory configured at boot time is managed by the kernel
zones and ZONE_MOVABLE is not used.
When adding/removing memory that uses memory block devices (i.e. ordinary RAM),
the device_hotplug_lock should be held to:
To enable ZONE_MOVABLE to include the memory present at boot and to control the
ratio between movable and kernel zones there are two command line options:
``kernelcore=`` and ``movablecore=``. See
Documentation/admin-guide/kernel-parameters.rst for their description.
- synchronize against online/offline requests (e.g. via sysfs). This way, memory
block devices can only be accessed (.online/.state attributes) by user
space once memory has been fully added. And when removing memory, we
know nobody is in critical sections.
- synchronize against CPU hotplug and similar (e.g. relevant for ACPI and PPC)
Memory Offlining and ZONE_MOVABLE
---------------------------------
Especially, there is a possible lock inversion that is avoided using
device_hotplug_lock when adding memory and user space tries to online that
memory faster than expected:
Even with ZONE_MOVABLE, there are some corner cases where offlining a memory
block might fail:
- device_online() will first take the device_lock(), followed by
mem_hotplug_lock
- add_memory_resource() will first take the mem_hotplug_lock, followed by
the device_lock() (while creating the devices, during bus_add_device()).
- Memory blocks with memory holes; this applies to memory blocks present during
boot and can apply to memory blocks hotplugged via the XEN balloon and the
Hyper-V balloon.
As the device is visible to user space before taking the device_lock(), this
can result in a lock inversion.
- Mixed NUMA nodes and mixed zones within a single memory block prevent memory
offlining; this applies to memory blocks present during boot only.
onlining/offlining of memory should be done via device_online()/
device_offline() - to make sure it is properly synchronized to actions
via sysfs. Holding device_hotplug_lock is advised (to e.g. protect online_type)
- Special memory blocks prevented by the system from getting offlined. Examples
include any memory available during boot on arm64 or memory blocks spanning
the crashkernel area on s390x; this usually applies to memory blocks present
during boot only.
When adding/removing/onlining/offlining memory or adding/removing
heterogeneous/device memory, we should always hold the mem_hotplug_lock in
write mode to serialise memory hotplug (e.g. access to global/zone
variables).
- Memory blocks overlapping with CMA areas cannot be offlined, this applies to
memory blocks present during boot only.
In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
mode allows for a quite efficient get_online_mems/put_online_mems
implementation, so code accessing memory can protect from that memory
vanishing.
- 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.
Future Work
===========
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
for the vmemmap, because the system might not have free memory in the kernel
zones left.
- allowing memory hot-add to ZONE_MOVABLE. maybe we need some switch like
sysctl or new control file.
- showing memory block and physical device relationship.
- test and make it better memory offlining.
- support HugeTLB page migration and offlining.
- memmap removing at memory offline.
- physical remove memory.
Users that depend on memory offlining to succeed for movable zones should
carefully consider whether the memory savings gained from this feature are
worth the risk of possibly not being able to offline memory in certain
situations.
Further, when running into out of memory situations while migrating pages, or
when still encountering permanently unmovable pages within ZONE_MOVABLE
(-> BUG), memory offlining will keep retrying until it eventually succeeds.
When offlining is triggered from user space, the offlining context can be
terminated by sending a fatal signal. A timeout based offlining can easily be
implemented via::
% timeout $TIMEOUT offline_block | failure_handling

1
Documentation/arm/marvell.rst
View File

@ -140,6 +140,7 @@ EBU Armada family
- 88F6821 Armada 382
- 88F6W21 Armada 383
- 88F6820 Armada 385
- 88F6825
- 88F6828 Armada 388
- Product infos: https://web.archive.org/web/20181006144616/http://www.marvell.com/embedded-processors/armada-38x/

2
Documentation/block/blk-mq.rst
View File

@ -54,7 +54,7 @@ layer or if we want to try to merge requests. In both cases, requests will be
sent to the software queue.
Then, after the requests are processed by software queues, they will be placed
at the hardware queue, a second stage queue were the hardware has direct access
at the hardware queue, a second stage queue where the hardware has direct access
to process those requests. However, if the hardware does not have enough
resources to accept more requests, blk-mq will places requests on a temporary
queue, to be sent in the future, when the hardware is able.

4
Documentation/conf.py
View File

@ -463,8 +463,8 @@ latex_elements['preamble'] += '''
\\newcommand{\\kerneldocEndTC}{}
\\newcommand{\\kerneldocBeginKR}{}
\\newcommand{\\kerneldocEndKR}{}
\\newcommand{\\kerneldocBeginSC}{}
\\newcommand{\\kerneldocEndKR}{}
\\newcommand{\\kerneldocBeginJP}{}
\\newcommand{\\kerneldocEndJP}{}
}
'''

537
Documentation/core-api/cpu_hotplug.rst
View File

@ -2,12 +2,13 @@
CPU hotplug in the Kernel
=========================
:Date: December, 2016
:Date: September, 2021
:Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Rusty Russell <rusty@rustcorp.com.au>,
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
Ashok Raj <ashok.raj@intel.com>,
Joel Schopp <jschopp@austin.ibm.com>
Rusty Russell <rusty@rustcorp.com.au>,
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
Ashok Raj <ashok.raj@intel.com>,
Joel Schopp <jschopp@austin.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>
Introduction
============
@ -158,100 +159,480 @@ at state ``CPUHP_OFFLINE``. This includes:
* Once all services are migrated, kernel calls an arch specific routine
``__cpu_disable()`` to perform arch specific cleanup.
Using the hotplug API
---------------------
It is possible to receive notifications once a CPU is offline or onlined. This
might be important to certain drivers which need to perform some kind of setup
or clean up functions based on the number of available CPUs::
The CPU hotplug API
===================
#include <linux/cpuhotplug.h>
CPU hotplug state machine
-------------------------
ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "X/Y:online",
Y_online, Y_prepare_down);
CPU hotplug uses a trivial state machine with a linear state space from
CPUHP_OFFLINE to CPUHP_ONLINE. Each state has a startup and a teardown
callback.
*X* is the subsystem and *Y* the particular driver. The *Y_online* callback
will be invoked during registration on all online CPUs. If an error
occurs during the online callback the *Y_prepare_down* callback will be
invoked on all CPUs on which the online callback was previously invoked.
After registration completed, the *Y_online* callback will be invoked
once a CPU is brought online and *Y_prepare_down* will be invoked when a
CPU is shutdown. All resources which were previously allocated in
*Y_online* should be released in *Y_prepare_down*.
The return value *ret* is negative if an error occurred during the
registration process. Otherwise a positive value is returned which
contains the allocated hotplug for dynamically allocated states
(*CPUHP_AP_ONLINE_DYN*). It will return zero for predefined states.
When a CPU is onlined, the startup callbacks are invoked sequentially until
the state CPUHP_ONLINE is reached. They can also be invoked when the
callbacks of a state are set up or an instance is added to a multi-instance
state.
The callback can be remove by invoking ``cpuhp_remove_state()``. In case of a
dynamically allocated state (*CPUHP_AP_ONLINE_DYN*) use the returned state.
During the removal of a hotplug state the teardown callback will be invoked.
When a CPU is offlined the teardown callbacks are invoked in the reverse
order sequentially until the state CPUHP_OFFLINE is reached. They can also
be invoked when the callbacks of a state are removed or an instance is
removed from a multi-instance state.
Multiple instances
~~~~~~~~~~~~~~~~~~
If a usage site requires only a callback in one direction of the hotplug
operations (CPU online or CPU offline) then the other not-required callback
can be set to NULL when the state is set up.
If a driver has multiple instances and each instance needs to perform the
callback independently then it is likely that a ''multi-state'' should be used.
First a multi-state state needs to be registered::
The state space is divided into three sections:
ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, "X/Y:online,
Y_online, Y_prepare_down);
Y_hp_online = ret;
* The PREPARE section
The ``cpuhp_setup_state_multi()`` behaves similar to ``cpuhp_setup_state()``
except it prepares the callbacks for a multi state and does not invoke
the callbacks. This is a one time setup.
Once a new instance is allocated, you need to register this new instance::
The PREPARE section covers the state space from CPUHP_OFFLINE to
CPUHP_BRINGUP_CPU.
ret = cpuhp_state_add_instance(Y_hp_online, &d->node);
The startup callbacks in this section are invoked before the CPU is
started during a CPU online operation. The teardown callbacks are invoked
after the CPU has become dysfunctional during a CPU offline operation.
This function will add this instance to your previously allocated
*Y_hp_online* state and invoke the previously registered callback
(*Y_online*) on all online CPUs. The *node* element is a ``struct
hlist_node`` member of your per-instance data structure.
The callbacks are invoked on a control CPU as they can't obviously run on
the hotplugged CPU which is either not yet started or has become
dysfunctional already.
On removal of the instance::
The startup callbacks are used to setup resources which are required to
bring a CPU successfully online. The teardown callbacks are used to free
resources or to move pending work to an online CPU after the hotplugged
CPU became dysfunctional.
cpuhp_state_remove_instance(Y_hp_online, &d->node)
The startup callbacks are allowed to fail. If a callback fails, the CPU
online operation is aborted and the CPU is brought down to the previous
state (usually CPUHP_OFFLINE) again.
should be invoked which will invoke the teardown callback on all online
CPUs.
The teardown callbacks in this section are not allowed to fail.
Manual setup
~~~~~~~~~~~~
* The STARTING section
Usually it is handy to invoke setup and teardown callbacks on registration or
removal of a state because usually the operation needs to performed once a CPU
goes online (offline) and during initial setup (shutdown) of the driver. However
each registration and removal function is also available with a ``_nocalls``
suffix which does not invoke the provided callbacks if the invocation of the
callbacks is not desired. During the manual setup (or teardown) the functions
``cpus_read_lock()`` and ``cpus_read_unlock()`` should be used to inhibit CPU
hotplug operations.
The STARTING section covers the state space between CPUHP_BRINGUP_CPU + 1
and CPUHP_AP_ONLINE.
The startup callbacks in this section are invoked on the hotplugged CPU
with interrupts disabled during a CPU online operation in the early CPU
setup code. The teardown callbacks are invoked with interrupts disabled
on the hotplugged CPU during a CPU offline operation shortly before the
CPU is completely shut down.
The ordering of the events
--------------------------
The callbacks in this section are not allowed to fail.
The hotplug states are defined in ``include/linux/cpuhotplug.h``:
The callbacks are used for low level hardware initialization/shutdown and
for core subsystems.
* The states *CPUHP_OFFLINE* … *CPUHP_AP_OFFLINE* are invoked before the
CPU is up.
* The states *CPUHP_AP_OFFLINE* … *CPUHP_AP_ONLINE* are invoked
just the after the CPU has been brought up. The interrupts are off and
the scheduler is not yet active on this CPU. Starting with *CPUHP_AP_OFFLINE*
the callbacks are invoked on the target CPU.
* The states between *CPUHP_AP_ONLINE_DYN* and *CPUHP_AP_ONLINE_DYN_END* are
reserved for the dynamic allocation.
* The states are invoked in the reverse order on CPU shutdown starting with
*CPUHP_ONLINE* and stopping at *CPUHP_OFFLINE*. Here the callbacks are
invoked on the CPU that will be shutdown until *CPUHP_AP_OFFLINE*.
* The ONLINE section
The ONLINE section covers the state space between CPUHP_AP_ONLINE + 1 and
CPUHP_ONLINE.
The startup callbacks in this section are invoked on the hotplugged CPU
during a CPU online operation. The teardown callbacks are invoked on the
hotplugged CPU during a CPU offline operation.
The callbacks are invoked in the context of the per CPU hotplug thread,
which is pinned on the hotplugged CPU. The callbacks are invoked with
interrupts and preemption enabled.
The callbacks are allowed to fail. When a callback fails the hotplug
operation is aborted and the CPU is brought back to the previous state.
CPU online/offline operations
-----------------------------
A successful online operation looks like this::
[CPUHP_OFFLINE]
[CPUHP_OFFLINE + 1]->startup() -> success
[CPUHP_OFFLINE + 2]->startup() -> success
[CPUHP_OFFLINE + 3] -> skipped because startup == NULL
...
[CPUHP_BRINGUP_CPU]->startup() -> success
=== End of PREPARE section
[CPUHP_BRINGUP_CPU + 1]->startup() -> success
...
[CPUHP_AP_ONLINE]->startup() -> success
=== End of STARTUP section
[CPUHP_AP_ONLINE + 1]->startup() -> success
...
[CPUHP_ONLINE - 1]->startup() -> success
[CPUHP_ONLINE]
A successful offline operation looks like this::
[CPUHP_ONLINE]
[CPUHP_ONLINE - 1]->teardown() -> success
...
[CPUHP_AP_ONLINE + 1]->teardown() -> success
=== Start of STARTUP section
[CPUHP_AP_ONLINE]->teardown() -> success
...
[CPUHP_BRINGUP_ONLINE - 1]->teardown()
...
=== Start of PREPARE section
[CPUHP_BRINGUP_CPU]->teardown()
[CPUHP_OFFLINE + 3]->teardown()
[CPUHP_OFFLINE + 2] -> skipped because teardown == NULL
[CPUHP_OFFLINE + 1]->teardown()
[CPUHP_OFFLINE]
A failed online operation looks like this::
[CPUHP_OFFLINE]
[CPUHP_OFFLINE + 1]->startup() -> success
[CPUHP_OFFLINE + 2]->startup() -> success
[CPUHP_OFFLINE + 3] -> skipped because startup == NULL
...
[CPUHP_BRINGUP_CPU]->startup() -> success
=== End of PREPARE section
[CPUHP_BRINGUP_CPU + 1]->startup() -> success
...
[CPUHP_AP_ONLINE]->startup() -> success
=== End of STARTUP section
[CPUHP_AP_ONLINE + 1]->startup() -> success
---
[CPUHP_AP_ONLINE + N]->startup() -> fail
[CPUHP_AP_ONLINE + (N - 1)]->teardown()
...
[CPUHP_AP_ONLINE + 1]->teardown()
=== Start of STARTUP section
[CPUHP_AP_ONLINE]->teardown()
...
[CPUHP_BRINGUP_ONLINE - 1]->teardown()
...
=== Start of PREPARE section
[CPUHP_BRINGUP_CPU]->teardown()
[CPUHP_OFFLINE + 3]->teardown()
[CPUHP_OFFLINE + 2] -> skipped because teardown == NULL
[CPUHP_OFFLINE + 1]->teardown()
[CPUHP_OFFLINE]
A failed offline operation looks like this::
[CPUHP_ONLINE]
[CPUHP_ONLINE - 1]->teardown() -> success
...
[CPUHP_ONLINE - N]->teardown() -> fail
[CPUHP_ONLINE - (N - 1)]->startup()
...
[CPUHP_ONLINE - 1]->startup()
[CPUHP_ONLINE]
Recursive failures cannot be handled sensibly. Look at the following
example of a recursive fail due to a failed offline operation: ::
[CPUHP_ONLINE]
[CPUHP_ONLINE - 1]->teardown() -> success
...
[CPUHP_ONLINE - N]->teardown() -> fail
[CPUHP_ONLINE - (N - 1)]->startup() -> success
[CPUHP_ONLINE - (N - 2)]->startup() -> fail
The CPU hotplug state machine stops right here and does not try to go back
down again because that would likely result in an endless loop::
[CPUHP_ONLINE - (N - 1)]->teardown() -> success
[CPUHP_ONLINE - N]->teardown() -> fail
[CPUHP_ONLINE - (N - 1)]->startup() -> success
[CPUHP_ONLINE - (N - 2)]->startup() -> fail
[CPUHP_ONLINE - (N - 1)]->teardown() -> success
[CPUHP_ONLINE - N]->teardown() -> fail
Lather, rinse and repeat. In this case the CPU left in state::
[CPUHP_ONLINE - (N - 1)]
which at least lets the system make progress and gives the user a chance to
debug or even resolve the situation.
Allocating a state
------------------
There are two ways to allocate a CPU hotplug state:
* Static allocation
Static allocation has to be used when the subsystem or driver has
ordering requirements versus other CPU hotplug states. E.g. the PERF core
startup callback has to be invoked before the PERF driver startup
callbacks during a CPU online operation. During a CPU offline operation
the driver teardown callbacks have to be invoked before the core teardown
callback. The statically allocated states are described by constants in
the cpuhp_state enum which can be found in include/linux/cpuhotplug.h.
Insert the state into the enum at the proper place so the ordering
requirements are fulfilled. The state constant has to be used for state
setup and removal.
Static allocation is also required when the state callbacks are not set
up at runtime and are part of the initializer of the CPU hotplug state
array in kernel/cpu.c.
* Dynamic allocation
When there are no ordering requirements for the state callbacks then
dynamic allocation is the preferred method. The state number is allocated
by the setup function and returned to the caller on success.
Only the PREPARE and ONLINE sections provide a dynamic allocation
range. The STARTING section does not as most of the callbacks in that
section have explicit ordering requirements.
Setup of a CPU hotplug state
----------------------------
The core code provides the following functions to setup a state:
* cpuhp_setup_state(state, name, startup, teardown)
* cpuhp_setup_state_nocalls(state, name, startup, teardown)
* cpuhp_setup_state_cpuslocked(state, name, startup, teardown)
* cpuhp_setup_state_nocalls_cpuslocked(state, name, startup, teardown)
For cases where a driver or a subsystem has multiple instances and the same
CPU hotplug state callbacks need to be invoked for each instance, the CPU
hotplug core provides multi-instance support. The advantage over driver
specific instance lists is that the instance related functions are fully
serialized against CPU hotplug operations and provide the automatic
invocations of the state callbacks on add and removal. To set up such a
multi-instance state the following function is available:
* cpuhp_setup_state_multi(state, name, startup, teardown)
The @state argument is either a statically allocated state or one of the
constants for dynamically allocated states - CPUHP_PREPARE_DYN,
CPUHP_ONLINE_DYN - depending on the state section (PREPARE, ONLINE) for
which a dynamic state should be allocated.
The @name argument is used for sysfs output and for instrumentation. The
naming convention is "subsys:mode" or "subsys/driver:mode",
e.g. "perf:mode" or "perf/x86:mode". The common mode names are:
======== =======================================================
prepare For states in the PREPARE section
dead For states in the PREPARE section which do not provide
a startup callback
starting For states in the STARTING section
dying For states in the STARTING section which do not provide
a startup callback
online For states in the ONLINE section
offline For states in the ONLINE section which do not provide
a startup callback
======== =======================================================
As the @name argument is only used for sysfs and instrumentation other mode
descriptors can be used as well if they describe the nature of the state
better than the common ones.
Examples for @name arguments: "perf/online", "perf/x86:prepare",
"RCU/tree:dying", "sched/waitempty"
The @startup argument is a function pointer to the callback which should be
invoked during a CPU online operation. If the usage site does not require a
startup callback set the pointer to NULL.
The @teardown argument is a function pointer to the callback which should
be invoked during a CPU offline operation. If the usage site does not
require a teardown callback set the pointer to NULL.
The functions differ in the way how the installed callbacks are treated:
* cpuhp_setup_state_nocalls(), cpuhp_setup_state_nocalls_cpuslocked()
and cpuhp_setup_state_multi() only install the callbacks
* cpuhp_setup_state() and cpuhp_setup_state_cpuslocked() install the
callbacks and invoke the @startup callback (if not NULL) for all online
CPUs which have currently a state greater than the newly installed
state. Depending on the state section the callback is either invoked on
the current CPU (PREPARE section) or on each online CPU (ONLINE
section) in the context of the CPU's hotplug thread.
If a callback fails for CPU N then the teardown callback for CPU
0 .. N-1 is invoked to rollback the operation. The state setup fails,
the callbacks for the state are not installed and in case of dynamic
allocation the allocated state is freed.
The state setup and the callback invocations are serialized against CPU
hotplug operations. If the setup function has to be called from a CPU
hotplug read locked region, then the _cpuslocked() variants have to be
used. These functions cannot be used from within CPU hotplug callbacks.
The function return values:
======== ===================================================================
0 Statically allocated state was successfully set up
>0 Dynamically allocated state was successfully set up.
The returned number is the state number which was allocated. If
the state callbacks have to be removed later, e.g. module
removal, then this number has to be saved by the caller and used
as @state argument for the state remove function. For
multi-instance states the dynamically allocated state number is
also required as @state argument for the instance add/remove
operations.
<0 Operation failed
======== ===================================================================
Removal of a CPU hotplug state
------------------------------
To remove a previously set up state, the following functions are provided:
* cpuhp_remove_state(state)
* cpuhp_remove_state_nocalls(state)
* cpuhp_remove_state_nocalls_cpuslocked(state)
* cpuhp_remove_multi_state(state)
The @state argument is either a statically allocated state or the state
number which was allocated in the dynamic range by cpuhp_setup_state*(). If
the state is in the dynamic range, then the state number is freed and
available for dynamic allocation again.
The functions differ in the way how the installed callbacks are treated:
* cpuhp_remove_state_nocalls(), cpuhp_remove_state_nocalls_cpuslocked()
and cpuhp_remove_multi_state() only remove the callbacks.
* cpuhp_remove_state() removes the callbacks and invokes the teardown
callback (if not NULL) for all online CPUs which have currently a state
greater than the removed state. Depending on the state section the
callback is either invoked on the current CPU (PREPARE section) or on
each online CPU (ONLINE section) in the context of the CPU's hotplug
thread.
In order to complete the removal, the teardown callback should not fail.
The state removal and the callback invocations are serialized against CPU
hotplug operations. If the remove function has to be called from a CPU
hotplug read locked region, then the _cpuslocked() variants have to be
used. These functions cannot be used from within CPU hotplug callbacks.
If a multi-instance state is removed then the caller has to remove all
instances first.
Multi-Instance state instance management
----------------------------------------
Once the multi-instance state is set up, instances can be added to the
state:
* cpuhp_state_add_instance(state, node)
* cpuhp_state_add_instance_nocalls(state, node)
The @state argument is either a statically allocated state or the state
number which was allocated in the dynamic range by cpuhp_setup_state_multi().
The @node argument is a pointer to an hlist_node which is embedded in the
instance's data structure. The pointer is handed to the multi-instance
state callbacks and can be used by the callback to retrieve the instance
via container_of().
The functions differ in the way how the installed callbacks are treated:
* cpuhp_state_add_instance_nocalls() and only adds the instance to the
multi-instance state's node list.
* cpuhp_state_add_instance() adds the instance and invokes the startup
callback (if not NULL) associated with @state for all online CPUs which
have currently a state greater than @state. The callback is only
invoked for the to be added instance. Depending on the state section
the callback is either invoked on the current CPU (PREPARE section) or
on each online CPU (ONLINE section) in the context of the CPU's hotplug
thread.
If a callback fails for CPU N then the teardown callback for CPU
0 .. N-1 is invoked to rollback the operation, the function fails and
the instance is not added to the node list of the multi-instance state.
To remove an instance from the state's node list these functions are
available:
* cpuhp_state_remove_instance(state, node)
* cpuhp_state_remove_instance_nocalls(state, node)
The arguments are the same as for the the cpuhp_state_add_instance*()
variants above.
The functions differ in the way how the installed callbacks are treated:
* cpuhp_state_remove_instance_nocalls() only removes the instance from the
state's node list.
* cpuhp_state_remove_instance() removes the instance and invokes the
teardown callback (if not NULL) associated with @state for all online
CPUs which have currently a state greater than @state. The callback is
only invoked for the to be removed instance. Depending on the state
section the callback is either invoked on the current CPU (PREPARE
section) or on each online CPU (ONLINE section) in the context of the
CPU's hotplug thread.
In order to complete the removal, the teardown callback should not fail.
The node list add/remove operations and the callback invocations are
serialized against CPU hotplug operations. These functions cannot be used
from within CPU hotplug callbacks and CPU hotplug read locked regions.
Examples
--------
Setup and teardown a statically allocated state in the STARTING section for
notifications on online and offline operations::
ret = cpuhp_setup_state(CPUHP_SUBSYS_STARTING, "subsys:starting", subsys_cpu_starting, subsys_cpu_dying);
if (ret < 0)
return ret;
....
cpuhp_remove_state(CPUHP_SUBSYS_STARTING);
Setup and teardown a dynamically allocated state in the ONLINE section
for notifications on offline operations::
state = cpuhp_setup_state(CPUHP_ONLINE_DYN, "subsys:offline", NULL, subsys_cpu_offline);
if (state < 0)
return state;
....
cpuhp_remove_state(state);
Setup and teardown a dynamically allocated state in the ONLINE section
for notifications on online operations without invoking the callbacks::
state = cpuhp_setup_state_nocalls(CPUHP_ONLINE_DYN, "subsys:online", subsys_cpu_online, NULL);
if (state < 0)
return state;
....
cpuhp_remove_state_nocalls(state);
Setup, use and teardown a dynamically allocated multi-instance state in the
ONLINE section for notifications on online and offline operation::
state = cpuhp_setup_state_multi(CPUHP_ONLINE_DYN, "subsys:online", subsys_cpu_online, subsys_cpu_offline);
if (state < 0)
return state;
....
ret = cpuhp_state_add_instance(state, &inst1->node);
if (ret)
return ret;
....
ret = cpuhp_state_add_instance(state, &inst2->node);
if (ret)
return ret;
....
cpuhp_remove_instance(state, &inst1->node);
....
cpuhp_remove_instance(state, &inst2->node);
....
remove_multi_state(state);
A dynamically allocated state via *CPUHP_AP_ONLINE_DYN* is often enough.
However if an earlier invocation during the bring up or shutdown is required
then an explicit state should be acquired. An explicit state might also be
required if the hotplug event requires specific ordering in respect to
another hotplug event.
Testing of hotplug states
=========================

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

@ -315,6 +315,9 @@ Block Devices
.. kernel-doc:: block/genhd.c
:export:
.. kernel-doc:: block/bdev.c
:export:
Char devices
============

3
Documentation/cpu-freq/cpu-drivers.rst
View File

@ -75,9 +75,6 @@ And optionally
.resume - A pointer to a per-policy resume function which is called
with interrupts disabled and _before_ the governor is started again.
.ready - A pointer to a per-policy ready function which is called after
the policy is fully initialized.
.attr - A pointer to a NULL-terminated list of "struct freq_attr" which
allow to export values to sysfs.

98
Documentation/dev-tools/kfence.rst
View File

@ -65,25 +65,27 @@ Error reports
A typical out-of-bounds access looks like this::
==================================================================
BUG: KFENCE: out-of-bounds read in test_out_of_bounds_read+0xa3/0x22b
BUG: KFENCE: out-of-bounds read in test_out_of_bounds_read+0xa6/0x234
Out-of-bounds read at 0xffffffffb672efff (1B left of kfence-#17):
test_out_of_bounds_read+0xa3/0x22b
kunit_try_run_case+0x51/0x85
Out-of-bounds read at 0xffff8c3f2e291fff (1B left of kfence-#72):
test_out_of_bounds_read+0xa6/0x234
kunit_try_run_case+0x61/0xa0
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
kthread+0x176/0x1b0
ret_from_fork+0x22/0x30
kfence-#17 [0xffffffffb672f000-0xffffffffb672f01f, size=32, cache=kmalloc-32] allocated by task 507:
test_alloc+0xf3/0x25b
test_out_of_bounds_read+0x98/0x22b
kunit_try_run_case+0x51/0x85
kfence-#72: 0xffff8c3f2e292000-0xffff8c3f2e29201f, size=32, cache=kmalloc-32
allocated by task 484 on cpu 0 at 32.919330s:
test_alloc+0xfe/0x738
test_out_of_bounds_read+0x9b/0x234
kunit_try_run_case+0x61/0xa0
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
kthread+0x176/0x1b0
ret_from_fork+0x22/0x30
CPU: 4 PID: 107 Comm: kunit_try_catch Not tainted 5.8.0-rc6+ #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
CPU: 0 PID: 484 Comm: kunit_try_catch Not tainted 5.13.0-rc3+ #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
==================================================================
The header of the report provides a short summary of the function involved in
@ -96,30 +98,32 @@ Use-after-free accesses are reported as::
==================================================================
BUG: KFENCE: use-after-free read in test_use_after_free_read+0xb3/0x143
Use-after-free read at 0xffffffffb673dfe0 (in kfence-#24):
Use-after-free read at 0xffff8c3f2e2a0000 (in kfence-#79):
test_use_after_free_read+0xb3/0x143
kunit_try_run_case+0x51/0x85
kunit_try_run_case+0x61/0xa0
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
kthread+0x176/0x1b0
ret_from_fork+0x22/0x30
kfence-#24 [0xffffffffb673dfe0-0xffffffffb673dfff, size=32, cache=kmalloc-32] allocated by task 507:
test_alloc+0xf3/0x25b
kfence-#79: 0xffff8c3f2e2a0000-0xffff8c3f2e2a001f, size=32, cache=kmalloc-32
allocated by task 488 on cpu 2 at 33.871326s:
test_alloc+0xfe/0x738
test_use_after_free_read+0x76/0x143
kunit_try_run_case+0x51/0x85
kunit_try_run_case+0x61/0xa0
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
kthread+0x176/0x1b0
ret_from_fork+0x22/0x30
freed by task 507:
freed by task 488 on cpu 2 at 33.871358s:
test_use_after_free_read+0xa8/0x143
kunit_try_run_case+0x51/0x85
kunit_try_run_case+0x61/0xa0
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
kthread+0x176/0x1b0
ret_from_fork+0x22/0x30
CPU: 4 PID: 109 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
CPU: 2 PID: 488 Comm: kunit_try_catch Tainted: G B 5.13.0-rc3+ #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
==================================================================
KFENCE also reports on invalid frees, such as double-frees::
@ -127,30 +131,32 @@ KFENCE also reports on invalid frees, such as double-frees::
==================================================================
BUG: KFENCE: invalid free in test_double_free+0xdc/0x171
Invalid free of 0xffffffffb6741000:
Invalid free of 0xffff8c3f2e2a4000 (in kfence-#81):
test_double_free+0xdc/0x171
kunit_try_run_case+0x51/0x85
kunit_try_run_case+0x61/0xa0
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
kthread+0x176/0x1b0
ret_from_fork+0x22/0x30
kfence-#26 [0xffffffffb6741000-0xffffffffb674101f, size=32, cache=kmalloc-32] allocated by task 507:
test_alloc+0xf3/0x25b
kfence-#81: 0xffff8c3f2e2a4000-0xffff8c3f2e2a401f, size=32, cache=kmalloc-32
allocated by task 490 on cpu 1 at 34.175321s:
test_alloc+0xfe/0x738
test_double_free+0x76/0x171
kunit_try_run_case+0x51/0x85
kunit_try_run_case+0x61/0xa0
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
kthread+0x176/0x1b0
ret_from_fork+0x22/0x30
freed by task 507:
freed by task 490 on cpu 1 at 34.175348s:
test_double_free+0xa8/0x171
kunit_try_run_case+0x51/0x85
kunit_try_run_case+0x61/0xa0
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
kthread+0x176/0x1b0
ret_from_fork+0x22/0x30
CPU: 4 PID: 111 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
CPU: 1 PID: 490 Comm: kunit_try_catch Tainted: G B 5.13.0-rc3+ #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
==================================================================
KFENCE also uses pattern-based redzones on the other side of an object's guard
@ -160,23 +166,25 @@ These are reported on frees::
==================================================================
BUG: KFENCE: memory corruption in test_kmalloc_aligned_oob_write+0xef/0x184
Corrupted memory at 0xffffffffb6797ff9 [ 0xac . . . . . . ] (in kfence-#69):
Corrupted memory at 0xffff8c3f2e33aff9 [ 0xac . . . . . . ] (in kfence-#156):
test_kmalloc_aligned_oob_write+0xef/0x184
kunit_try_run_case+0x51/0x85
kunit_try_run_case+0x61/0xa0
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
kthread+0x176/0x1b0
ret_from_fork+0x22/0x30
kfence-#69 [0xffffffffb6797fb0-0xffffffffb6797ff8, size=73, cache=kmalloc-96] allocated by task 507:
test_alloc+0xf3/0x25b
kfence-#156: 0xffff8c3f2e33afb0-0xffff8c3f2e33aff8, size=73, cache=kmalloc-96
allocated by task 502 on cpu 7 at 42.159302s:
test_alloc+0xfe/0x738
test_kmalloc_aligned_oob_write+0x57/0x184
kunit_try_run_case+0x51/0x85
kunit_try_run_case+0x61/0xa0
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
kthread+0x176/0x1b0
ret_from_fork+0x22/0x30
CPU: 4 PID: 120 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
CPU: 7 PID: 502 Comm: kunit_try_catch Tainted: G B 5.13.0-rc3+ #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
==================================================================
For such errors, the address where the corruption occurred as well as the

31
Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml
View File

@ -12,7 +12,10 @@ maintainers:
description:
The Hitachi HD44780 Character LCD Controller is commonly used on character
LCDs that can display one or more lines of text. It exposes an M6800 bus
interface, which can be used in either 4-bit or 8-bit mode.
interface, which can be used in either 4-bit or 8-bit mode. By using a
GPIO expander it is possible to use the driver with one of the popular I2C
expander boards based on the PCF8574 available for these displays. For
an example see below.
properties:
compatible:
@ -94,3 +97,29 @@ examples:
display-height-chars = <2>;
display-width-chars = <16>;
};
- |
#include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
pcf8574: pcf8574@27 {
compatible = "nxp,pcf8574";
reg = <0x27>;
gpio-controller;
#gpio-cells = <2>;
};
};
hd44780 {
compatible = "hit,hd44780";
display-height-chars = <2>;
display-width-chars = <16>;
data-gpios = <&pcf8574 4 0>,
<&pcf8574 5 0>,
<&pcf8574 6 0>,
<&pcf8574 7 0>;
enable-gpios = <&pcf8574 2 0>;
rs-gpios = <&pcf8574 0 0>;
rw-gpios = <&pcf8574 1 0>;
backlight-gpios = <&pcf8574 3 0>;
};

2
Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
View File

@ -11,7 +11,7 @@ Required properties:
- None
Optional properties:
- operating-points: Refer to Documentation/devicetree/bindings/opp/opp.txt for
- operating-points: Refer to Documentation/devicetree/bindings/opp/opp-v1.yaml for
details. OPPs *must* be supplied either via DT, i.e. this property, or
populated at runtime.
- clock-latency: Specify the possible maximum transition latency for clock,

70
Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml Normal file
View File

@ -0,0 +1,70 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/cpufreq/cpufreq-mediatek-hw.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek's CPUFREQ Bindings
maintainers:
- Hector Yuan <hector.yuan@mediatek.com>
description:
CPUFREQ HW is a hardware engine used by MediaTek SoCs to
manage frequency in hardware. It is capable of controlling
frequency for multiple clusters.
properties:
compatible:
const: mediatek,cpufreq-hw
reg:
minItems: 1
maxItems: 2
description:
Addresses and sizes for the memory of the HW bases in
each frequency domain. Each entry corresponds to
a register bank for each frequency domain present.
"#performance-domain-cells":
description:
Number of cells in a performance domain specifier.
Set const to 1 here for nodes providing multiple
performance domains.
const: 1
required:
- compatible
- reg
- "#performance-domain-cells"
additionalProperties: false
examples:
- |
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a55";
enable-method = "psci";
performance-domains = <&performance 0>;
reg = <0x000>;
};
};
/* ... */
soc {
#address-cells = <2>;
#size-cells = <2>;
performance: performance-controller@11bc00 {
compatible = "mediatek,cpufreq-hw";
reg = <0 0x0011bc10 0 0x120>, <0 0x0011bd30 0 0x120>;
#performance-domain-cells = <1>;
};
};

2
Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt
View File

@ -10,7 +10,7 @@ Required properties:
transition and not stable yet.
Please refer to Documentation/devicetree/bindings/clock/clock-bindings.txt for
generic clock consumer properties.
- operating-points-v2: Please refer to Documentation/devicetree/bindings/opp/opp.txt
- operating-points-v2: Please refer to Documentation/devicetree/bindings/opp/opp-v2.yaml
for detail.
- proc-supply: Regulator for Vproc of CPU cluster.

6
Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
View File

@ -6,8 +6,6 @@ from the SoC, then supplies the OPP framework with 'prop' and 'supported
hardware' information respectively. The framework is then able to read
the DT and operate in the usual way.
For more information about the expected DT format [See: ../opp/opp.txt].
Frequency Scaling only
----------------------
@ -15,7 +13,7 @@ No vendor specific driver required for this.
Located in CPU's node:
- operating-points : [See: ../power/opp.txt]
- operating-points : [See: ../power/opp-v1.yaml]
Example [safe]
--------------
@ -37,7 +35,7 @@ This requires the ST CPUFreq driver to supply 'process' and 'version' info.
Located in CPU's node:
- operating-points-v2 : [See ../power/opp.txt]
- operating-points-v2 : [See ../power/opp-v2.yaml]
Example [unsafe]
----------------

2
Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt
View File

@ -4,7 +4,7 @@ Binding for NVIDIA Tegra20 CPUFreq
Required properties:
- clocks: Must contain an entry for the CPU clock.
See ../clocks/clock-bindings.txt for details.
- operating-points-v2: See ../bindings/opp/opp.txt for details.
- operating-points-v2: See ../bindings/opp/opp-v2.yaml for details.
- #cooling-cells: Should be 2. See ../thermal/thermal-cooling-devices.yaml for details.
For each opp entry in 'operating-points-v2' table:

2
Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
View File

@ -8,7 +8,7 @@ Required properties:
- clocks: Phandles for clock specified in "clock-names" property
- clock-names : The name of clock used by the DFI, must be
"pclk_ddr_mon";
- operating-points-v2: Refer to Documentation/devicetree/bindings/opp/opp.txt
- operating-points-v2: Refer to Documentation/devicetree/bindings/opp/opp-v2.yaml
for details.
- center-supply: DMC supply node.
- status: Marks the node enabled/disabled.

8
Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
View File

@ -14,10 +14,10 @@ allOf:
properties:
compatible:
oneOf:
- const: qcom,dsi-phy-7nm
- const: qcom,dsi-phy-7nm-8150
- const: qcom,sc7280-dsi-phy-7nm
enum:
- qcom,dsi-phy-7nm
- qcom,dsi-phy-7nm-8150
- qcom,sc7280-dsi-phy-7nm
reg:
items:

4
Documentation/devicetree/bindings/dma/altr,msgdma.yaml
View File

@ -24,13 +24,15 @@ properties:
items:
- description: Control and Status Register Slave Port
- description: Descriptor Slave Port
- description: Response Slave Port
- description: Response Slave Port (Optional)
minItems: 2
reg-names:
items:
- const: csr
- const: desc
- const: resp
minItems: 2
interrupts:
maxItems: 1

130
Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml Normal file
View File

@ -0,0 +1,130 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/renesas,rz-dmac.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/G2L DMA Controller
maintainers:
- Biju Das <biju.das.jz@bp.renesas.com>
allOf:
- $ref: "dma-controller.yaml#"
properties:
compatible:
items:
- enum:
- renesas,r9a07g044-dmac # RZ/G2{L,LC}
- const: renesas,rz-dmac
reg:
items:
- description: Control and channel register block
- description: DMA extended resource selector block
interrupts:
maxItems: 17
interrupt-names:
items:
- const: error
- const: ch0
- const: ch1
- const: ch2
- const: ch3
- const: ch4
- const: ch5
- const: ch6
- const: ch7
- const: ch8
- const: ch9
- const: ch10
- const: ch11
- const: ch12
- const: ch13
- const: ch14
- const: ch15
clocks:
items:
- description: DMA main clock
- description: DMA register access clock
'#dma-cells':
const: 1
description:
The cell specifies the encoded MID/RID values of the DMAC port
connected to the DMA client and the slave channel configuration
parameters.
bits[0:9] - Specifies MID/RID value
bit[10] - Specifies DMA request high enable (HIEN)
bit[11] - Specifies DMA request detection type (LVL)
bits[12:14] - Specifies DMAACK output mode (AM)
bit[15] - Specifies Transfer Mode (TM)
dma-channels:
const: 16
power-domains:
maxItems: 1
resets:
items:
- description: Reset for DMA ARESETN reset terminal
- description: Reset for DMA RST_ASYNC reset terminal
required:
- compatible
- reg
- interrupts
- interrupt-names
- clocks
- '#dma-cells'
- dma-channels
- power-domains
- resets
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/r9a07g044-cpg.h>
dmac: dma-controller@11820000 {
compatible = "renesas,r9a07g044-dmac",
"renesas,rz-dmac";
reg = <0x11820000 0x10000>,
<0x11830000 0x10000>;
interrupts = <GIC_SPI 141 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 125 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 126 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 127 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 128 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 129 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 130 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 131 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 132 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 133 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 134 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 135 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 136 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 137 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 138 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 139 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 140 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "error",
"ch0", "ch1", "ch2", "ch3",
"ch4", "ch5", "ch6", "ch7",
"ch8", "ch9", "ch10", "ch11",
"ch12", "ch13", "ch14", "ch15";
clocks = <&cpg CPG_MOD R9A07G044_DMAC_ACLK>,
<&cpg CPG_MOD R9A07G044_DMAC_PCLK>;
power-domains = <&cpg>;
resets = <&cpg R9A07G044_DMAC_ARESETN>,
<&cpg R9A07G044_DMAC_RST_ASYNC>;
#dma-cells = <1>;
dma-channels = <16>;
};

7
Documentation/devicetree/bindings/dma/st,stm32-dma.yaml
View File

@ -40,6 +40,13 @@ description: |
0x0: FIFO mode with threshold selectable with bit 0-1
0x1: Direct mode: each DMA request immediately initiates a transfer
from/to the memory, FIFO is bypassed.
-bit 4: alternative DMA request/acknowledge protocol
0x0: Use standard DMA ACK management, where ACK signal is maintained
up to the removal of request and transfer completion
0x1: Use alternative DMA ACK management, where ACK de-assertion does
not wait for the de-assertion of the REQuest, ACK is only managed
by transfer completion. This must only be used on channels
managing transfers for STM32 USART/UART.
maintainers:

59
Documentation/devicetree/bindings/gpio/gpio-virtio.yaml Normal file
View File

@ -0,0 +1,59 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/gpio-virtio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Virtio GPIO controller
maintainers:
- Viresh Kumar <viresh.kumar@linaro.org>
allOf:
- $ref: /schemas/virtio/virtio-device.yaml#
description:
Virtio GPIO controller, see /schemas/virtio/virtio-device.yaml for more
details.
properties:
$nodename:
const: gpio
compatible:
const: virtio,device29
gpio-controller: true
"#gpio-cells":
const: 2
interrupt-controller: true
"#interrupt-cells":
const: 2
required:
- compatible
- gpio-controller
- "#gpio-cells"
unevaluatedProperties: false
examples:
- |
virtio@3000 {
compatible = "virtio,mmio";
reg = <0x3000 0x100>;
interrupts = <41>;
gpio {
compatible = "virtio,device29";
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
};
...

2
Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
View File

@ -137,7 +137,7 @@ examples:
resets = <&reset 0>, <&reset 1>;
};
gpu_opp_table: opp_table0 {
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
opp-533000000 {

2
Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
View File

@ -160,7 +160,7 @@ examples:
#cooling-cells = <2>;
};
gpu_opp_table: opp_table0 {
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
opp-533000000 {

51
Documentation/devicetree/bindings/i2c/i2c-virtio.yaml Normal file
View File

@ -0,0 +1,51 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/i2c-virtio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Virtio I2C Adapter
maintainers:
- Viresh Kumar <viresh.kumar@linaro.org>
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
- $ref: /schemas/virtio/virtio-device.yaml#
description:
Virtio I2C device, see /schemas/virtio/virtio-device.yaml for more details.
properties:
$nodename:
const: i2c
compatible:
const: virtio,device22
required:
- compatible
unevaluatedProperties: false
examples:
- |
virtio@3000 {
compatible = "virtio,mmio";
reg = <0x3000 0x100>;
interrupts = <41>;
i2c {
compatible = "virtio,device22";
#address-cells = <1>;
#size-cells = <0>;
light-sensor@20 {
compatible = "dynaimage,al3320a";
reg = <0x20>;
};
};
};
...

2
Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml
View File

@ -29,6 +29,8 @@ properties:
description:
Regulator for the LRADC reference voltage
wakeup-source: true
patternProperties:
"^button-[0-9]+$":
type: object

55
Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
View File

@ -1,55 +0,0 @@
Qualcomm PM8941 PMIC Power Key
PROPERTIES
- compatible:
Usage: required
Value type: <string>
Definition: must be one of:
"qcom,pm8941-pwrkey"
"qcom,pm8941-resin"
"qcom,pmk8350-pwrkey"
"qcom,pmk8350-resin"
- reg:
Usage: required
Value type: <prop-encoded-array>
Definition: base address of registers for block
- interrupts:
Usage: required
Value type: <prop-encoded-array>
Definition: key change interrupt; The format of the specifier is
defined by the binding document describing the node's
interrupt parent.
- debounce:
Usage: optional
Value type: <u32>
Definition: time in microseconds that key must be pressed or released
for state change interrupt to trigger.
- bias-pull-up:
Usage: optional
Value type: <empty>
Definition: presence of this property indicates that the KPDPWR_N pin
should be configured for pull up.
- linux,code:
Usage: optional
Value type: <u32>
Definition: The input key-code associated with the power key.
Use the linux event codes defined in
include/dt-bindings/input/linux-event-codes.h
When property is omitted KEY_POWER is assumed.
EXAMPLE
pwrkey@800 {
compatible = "qcom,pm8941-pwrkey";
reg = <0x800>;
interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
debounce = <15625>;
bias-pull-up;
linux,code = <KEY_POWER>;
};

51
Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml Normal file
View File

@ -0,0 +1,51 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/qcom,pm8941-pwrkey.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm PM8941 PMIC Power Key
maintainers:
- Courtney Cavin <courtney.cavin@sonymobile.com>
- Vinod Koul <vkoul@kernel.org>
allOf:
- $ref: input.yaml#
properties:
compatible:
enum:
- qcom,pm8941-pwrkey
- qcom,pm8941-resin
- qcom,pmk8350-pwrkey
- qcom,pmk8350-resin
interrupts:
maxItems: 1
debounce:
description: |
Time in microseconds that key must be pressed or
released for state change interrupt to trigger.
$ref: /schemas/types.yaml#/definitions/uint32
bias-pull-up:
description: |
Presence of this property indicates that the KPDPWR_N
pin should be configured for pull up.
$ref: /schemas/types.yaml#/definitions/flag
linux,code:
description: |
The input key-code associated with the power key.
Use the linux event codes defined in
include/dt-bindings/input/linux-event-codes.h
When property is omitted KEY_POWER is assumed.
required:
- compatible
- interrupts
unevaluatedProperties: false
...

21
Documentation/devicetree/bindings/input/regulator-haptic.txt
View File

@ -1,21 +0,0 @@
* Regulator Haptic Device Tree Bindings
Required Properties:
- compatible : Should be "regulator-haptic"
- haptic-supply : Power supply to the haptic motor.
[*] refer Documentation/devicetree/bindings/regulator/regulator.txt
- max-microvolt : The maximum voltage value supplied to the haptic motor.
[The unit of the voltage is a micro]
- min-microvolt : The minimum voltage value supplied to the haptic motor.
[The unit of the voltage is a micro]
Example:
haptics {
compatible = "regulator-haptic";
haptic-supply = <&motor_regulator>;
max-microvolt = <2700000>;
min-microvolt = <1100000>;
};

43
Documentation/devicetree/bindings/input/regulator-haptic.yaml Normal file
View File

@ -0,0 +1,43 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: "http://devicetree.org/schemas/input/regulator-haptic.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Regulator Haptic Device Tree Bindings
maintainers:
- Jaewon Kim <jaewon02.kim@samsung.com>
properties:
compatible:
const: regulator-haptic
haptic-supply:
description: >
Power supply to the haptic motor
max-microvolt:
description: >
The maximum voltage value supplied to the haptic motor
min-microvolt:
description: >
The minimum voltage value supplied to the haptic motor
required:
- compatible
- haptic-supply
- max-microvolt
- min-microvolt
additionalProperties: false
examples:
- |
haptics {
compatible = "regulator-haptic";
haptic-supply = <&motor_regulator>;
max-microvolt = <2700000>;
min-microvolt = <1100000>;
};

62
Documentation/devicetree/bindings/input/touchscreen/chipone,icn8318.yaml Normal file
View File

@ -0,0 +1,62 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/touchscreen/chipone,icn8318.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ChipOne ICN8318 Touchscreen Controller Device Tree Bindings
maintainers:
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
allOf:
- $ref: touchscreen.yaml#
properties:
compatible:
const: chipone,icn8318
reg:
maxItems: 1
interrupts:
maxItems: 1
wake-gpios:
maxItems: 1
unevaluatedProperties: false
required:
- compatible
- reg
- interrupts
- wake-gpios
- touchscreen-size-x
- touchscreen-size-y
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
touchscreen@40 {
compatible = "chipone,icn8318";
reg = <0x40>;
interrupt-parent = <&pio>;
interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
pinctrl-names = "default";
pinctrl-0 = <&ts_wake_pin_p66>;
wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
touchscreen-size-x = <800>;
touchscreen-size-y = <480>;
touchscreen-inverted-x;
touchscreen-swapped-x-y;
};
};
...

44
Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
View File

@ -1,44 +0,0 @@
* ChipOne icn8318 I2C touchscreen controller
Required properties:
- compatible : "chipone,icn8318"
- reg : I2C slave address of the chip (0x40)
- interrupts : interrupt specification for the icn8318 interrupt
- wake-gpios : GPIO specification for the WAKE input
- touchscreen-size-x : horizontal resolution of touchscreen (in pixels)
- touchscreen-size-y : vertical resolution of touchscreen (in pixels)
Optional properties:
- pinctrl-names : should be "default"
- pinctrl-0: : a phandle pointing to the pin settings for the
control gpios
- touchscreen-fuzz-x : horizontal noise value of the absolute input
device (in pixels)
- touchscreen-fuzz-y : vertical noise value of the absolute input
device (in pixels)
- touchscreen-inverted-x : X axis is inverted (boolean)
- touchscreen-inverted-y : Y axis is inverted (boolean)
- touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
Swapping is done after inverting the axis
Example:
i2c@00000000 {
/* ... */
chipone_icn8318@40 {
compatible = "chipone,icn8318";
reg = <0x40>;
interrupt-parent = <&pio>;
interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
pinctrl-names = "default";
pinctrl-0 = <&ts_wake_pin_p66>;
wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
touchscreen-size-x = <800>;
touchscreen-size-y = <480>;
touchscreen-inverted-x;
touchscreen-swapped-x-y;
};
/* ... */
};

68
Documentation/devicetree/bindings/input/touchscreen/pixcir,pixcir_ts.yaml Normal file
View File

@ -0,0 +1,68 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/touchscreen/pixcir,pixcir_ts.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Pixcir Touchscreen Controller Device Tree Bindings
maintainers:
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
allOf:
- $ref: touchscreen.yaml#
properties:
compatible:
enum:
- pixcir,pixcir_ts
- pixcir,pixcir_tangoc
reg:
maxItems: 1
interrupts:
maxItems: 1
attb-gpio:
maxItems: 1
reset-gpios:
maxItems: 1
enable-gpios:
maxItems: 1
wake-gpios:
maxItems: 1
unevaluatedProperties: false
required:
- compatible
- reg
- interrupts
- attb-gpio
- touchscreen-size-x
- touchscreen-size-y
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
touchscreen@5c {
compatible = "pixcir,pixcir_ts";
reg = <0x5c>;
interrupts = <2 0>;
attb-gpio = <&gpf 2 0 2>;
touchscreen-size-x = <800>;
touchscreen-size-y = <600>;
};
};
...

31
Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt
View File

@ -1,31 +0,0 @@
* Pixcir I2C touchscreen controllers
Required properties:
- compatible: must be "pixcir,pixcir_ts" or "pixcir,pixcir_tangoc"
- reg: I2C address of the chip
- interrupts: interrupt to which the chip is connected
- attb-gpio: GPIO connected to the ATTB line of the chip
- touchscreen-size-x: horizontal resolution of touchscreen (in pixels)
- touchscreen-size-y: vertical resolution of touchscreen (in pixels)
Optional properties:
- reset-gpios: GPIO connected to the RESET line of the chip
- enable-gpios: GPIO connected to the ENABLE line of the chip
- wake-gpios: GPIO connected to the WAKE line of the chip
Example:
i2c@00000000 {
/* ... */
pixcir_ts@5c {
compatible = "pixcir,pixcir_ts";
reg = <0x5c>;
interrupts = <2 0>;
attb-gpio = <&gpf 2 0 2>;
touchscreen-size-x = <800>;
touchscreen-size-y = <600>;
};
/* ... */
};

128
Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml Normal file
View File

@ -0,0 +1,128 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/touchscreen/ti,tsc2005.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments TSC2004 and TSC2005 touchscreen controller bindings
maintainers:
- Marek Vasut <marex@denx.de>
- Michael Welling <mwelling@ieee.org>
properties:
$nodename:
pattern: "^touchscreen(@.*)?$"
compatible:
enum:
- ti,tsc2004
- ti,tsc2005
reg:
maxItems: 1
description: |
I2C address when used on the I2C bus, or the SPI chip select index
when used on the SPI bus
interrupts:
maxItems: 1
reset-gpios:
maxItems: 1
description: GPIO specifier for the controller reset line
spi-max-frequency:
description: TSC2005 SPI bus clock frequency.
maximum: 25000000
ti,x-plate-ohms:
description: resistance of the touchscreen's X plates in ohm (defaults to 280)
ti,esd-recovery-timeout-ms:
description: |
if the touchscreen does not respond after the configured time
(in milli seconds), the driver will reset it. This is disabled
by default.
vio-supply:
description: Regulator specifier
touchscreen-fuzz-pressure: true
touchscreen-fuzz-x: true
touchscreen-fuzz-y: true
touchscreen-max-pressure: true
touchscreen-size-x: true
touchscreen-size-y: true
allOf:
- $ref: touchscreen.yaml#
- if:
properties:
compatible:
contains:
const: ti,tsc2004
then:
properties:
spi-max-frequency: false
additionalProperties: false
required:
- compatible
- reg
- interrupts
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
touchscreen@48 {
compatible = "ti,tsc2004";
reg = <0x48>;
vio-supply = <&vio>;
reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>;
interrupts-extended = <&gpio1 27 IRQ_TYPE_EDGE_RISING>;
touchscreen-fuzz-x = <4>;
touchscreen-fuzz-y = <7>;
touchscreen-fuzz-pressure = <2>;
touchscreen-size-x = <4096>;
touchscreen-size-y = <4096>;
touchscreen-max-pressure = <2048>;
ti,x-plate-ohms = <280>;
ti,esd-recovery-timeout-ms = <8000>;
};
};
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/gpio/gpio.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
touchscreen@0 {
compatible = "ti,tsc2005";
spi-max-frequency = <6000000>;
reg = <0>;
vio-supply = <&vio>;
reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>; /* 104 */
interrupts-extended = <&gpio4 4 IRQ_TYPE_EDGE_RISING>; /* 100 */
touchscreen-fuzz-x = <4>;
touchscreen-fuzz-y = <7>;
touchscreen-fuzz-pressure = <2>;
touchscreen-size-x = <4096>;
touchscreen-size-y = <4096>;
touchscreen-max-pressure = <2048>;
ti,x-plate-ohms = <280>;
ti,esd-recovery-timeout-ms = <8000>;
};
};

64
Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
View File

@ -1,64 +0,0 @@
* Texas Instruments tsc2004 and tsc2005 touchscreen controllers
Required properties:
- compatible : "ti,tsc2004" or "ti,tsc2005"
- reg : Device address
- interrupts : IRQ specifier
- spi-max-frequency : Maximum SPI clocking speed of the device
(for tsc2005)
Optional properties:
- vio-supply : Regulator specifier
- reset-gpios : GPIO specifier for the controller reset line
- ti,x-plate-ohms : integer, resistance of the touchscreen's X plates
in ohm (defaults to 280)
- ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond after
the configured time (in milli seconds), the driver
will reset it. This is disabled by default.
- properties defined in touchscreen.txt
Example:
&i2c3 {
tsc2004@48 {
compatible = "ti,tsc2004";
reg = <0x48>;
vio-supply = <&vio>;
reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>;
interrupts-extended = <&gpio1 27 IRQ_TYPE_EDGE_RISING>;
touchscreen-fuzz-x = <4>;
touchscreen-fuzz-y = <7>;
touchscreen-fuzz-pressure = <2>;
touchscreen-size-x = <4096>;
touchscreen-size-y = <4096>;
touchscreen-max-pressure = <2048>;
ti,x-plate-ohms = <280>;
ti,esd-recovery-timeout-ms = <8000>;
};
}
&mcspi1 {
tsc2005@0 {
compatible = "ti,tsc2005";
spi-max-frequency = <6000000>;
reg = <0>;
vio-supply = <&vio>;
reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>; /* 104 */
interrupts-extended = <&gpio4 4 IRQ_TYPE_EDGE_RISING>; /* 100 */
touchscreen-fuzz-x = <4>;
touchscreen-fuzz-y = <7>;
touchscreen-fuzz-pressure = <2>;
touchscreen-size-x = <4096>;
touchscreen-size-y = <4096>;
touchscreen-max-pressure = <2048>;
ti,x-plate-ohms = <280>;
ti,esd-recovery-timeout-ms = <8000>;
};
}

4
Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml
View File

@ -81,10 +81,10 @@ examples:
noc_opp_table: opp-table {
compatible = "operating-points-v2";
opp-133M {
opp-133333333 {
opp-hz = /bits/ 64 <133333333>;
};
opp-800M {
opp-800000000 {
opp-hz = /bits/ 64 <800000000>;
};
};

4
Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
View File

@ -19,7 +19,9 @@ properties:
- const: allwinner,sun8i-v3s-emac
- const: allwinner,sun50i-a64-emac
- items:
- const: allwinner,sun50i-h6-emac
- enum:
- allwinner,sun20i-d1-emac
- allwinner,sun50i-h6-emac
- const: allwinner,sun50i-a64-emac
reg:

4
Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
View File

@ -18,6 +18,9 @@ description: |
sun50i-cpufreq-nvmem driver reads the efuse value from the SoC to
provide the OPP framework with required information.
allOf:
- $ref: opp-v2-base.yaml#
properties:
compatible:
const: allwinner,sun50i-h6-operating-points
@ -43,6 +46,7 @@ patternProperties:
properties:
opp-hz: true
clock-latency-ns: true
patternProperties:
"opp-microvolt-.*": true

51
Documentation/devicetree/bindings/opp/opp-v1.yaml Normal file
View File

@ -0,0 +1,51 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/opp/opp-v1.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Generic OPP (Operating Performance Points) v1 Bindings
maintainers:
- Viresh Kumar <viresh.kumar@linaro.org>
description: |+
Devices work at voltage-current-frequency combinations and some implementations
have the liberty of choosing these. These combinations are called Operating
Performance Points aka OPPs. This document defines bindings for these OPPs
applicable across wide range of devices. For illustration purpose, this document
uses CPU as a device.
This binding only supports voltage-frequency pairs.
select: true
properties:
operating-points:
$ref: /schemas/types.yaml#/definitions/uint32-matrix
items:
items:
- description: Frequency in kHz
- description: Voltage for OPP in uV
additionalProperties: true
examples:
- |
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0>;
next-level-cache = <&L2>;
operating-points =
/* kHz uV */
<792000 1100000>,
<396000 950000>,
<198000 850000>;
};
};
...

214
Documentation/devicetree/bindings/opp/opp-v2-base.yaml Normal file
View File

@ -0,0 +1,214 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/opp/opp-v2-base.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Generic OPP (Operating Performance Points) Common Binding
maintainers:
- Viresh Kumar <viresh.kumar@linaro.org>
description: |
Devices work at voltage-current-frequency combinations and some implementations
have the liberty of choosing these. These combinations are called Operating
Performance Points aka OPPs. This document defines bindings for these OPPs
applicable across wide range of devices. For illustration purpose, this document
uses CPU as a device.
This describes the OPPs belonging to a device.
select: false
properties:
$nodename:
pattern: '^opp-table(-[a-z0-9]+)?$'
opp-shared:
description:
Indicates that device nodes using this OPP Table Node's phandle switch
their DVFS state together, i.e. they share clock/voltage/current lines.
Missing property means devices have independent clock/voltage/current
lines, but they share OPP tables.
type: boolean
patternProperties:
'^opp-?[0-9]+$':
type: object
description:
One or more OPP nodes describing voltage-current-frequency combinations.
Their name isn't significant but their phandle can be used to reference an
OPP. These are mandatory except for the case where the OPP table is
present only to indicate dependency between devices using the opp-shared
property.
properties:
opp-hz:
description:
Frequency in Hz, expressed as a 64-bit big-endian integer. This is a
required property for all device nodes, unless another "required"
property to uniquely identify the OPP nodes exists. Devices like power
domains must have another (implementation dependent) property.
opp-microvolt:
description: |
Voltage for the OPP
A single regulator's voltage is specified with an array of size one or three.
Single entry is for target voltage and three entries are for <target min max>
voltages.
Entries for multiple regulators shall be provided in the same field separated
by angular brackets <>. The OPP binding doesn't provide any provisions to
relate the values to their power supplies or the order in which the supplies
need to be configured and that is left for the implementation specific
binding.
Entries for all regulators shall be of the same size, i.e. either all use a
single value or triplets.
minItems: 1
maxItems: 8 # Should be enough regulators
items:
minItems: 1
maxItems: 3
opp-microamp:
description: |
The maximum current drawn by the device in microamperes considering
system specific parameters (such as transients, process, aging,
maximum operating temperature range etc.) as necessary. This may be
used to set the most efficient regulator operating mode.
Should only be set if opp-microvolt or opp-microvolt-<name> is set for
the OPP.
Entries for multiple regulators shall be provided in the same field
separated by angular brackets <>. If current values aren't required
for a regulator, then it shall be filled with 0. If current values
aren't required for any of the regulators, then this field is not
required. The OPP binding doesn't provide any provisions to relate the
values to their power supplies or the order in which the supplies need
to be configured and that is left for the implementation specific
binding.
minItems: 1
maxItems: 8 # Should be enough regulators
opp-level:
description:
A value representing the performance level of the device.
$ref: /schemas/types.yaml#/definitions/uint32
opp-peak-kBps:
description:
Peak bandwidth in kilobytes per second, expressed as an array of
32-bit big-endian integers. Each element of the array represents the
peak bandwidth value of each interconnect path. The number of elements
should match the number of interconnect paths.
minItems: 1
maxItems: 32 # Should be enough
opp-avg-kBps:
description:
Average bandwidth in kilobytes per second, expressed as an array
of 32-bit big-endian integers. Each element of the array represents the
average bandwidth value of each interconnect path. The number of elements
should match the number of interconnect paths. This property is only
meaningful in OPP tables where opp-peak-kBps is present.
minItems: 1
maxItems: 32 # Should be enough
clock-latency-ns:
description:
Specifies the maximum possible transition latency (in nanoseconds) for
switching to this OPP from any other OPP.
turbo-mode:
description:
Marks the OPP to be used only for turbo modes. Turbo mode is available
on some platforms, where the device can run over its operating
frequency for a short duration of time limited by the device's power,
current and thermal limits.
type: boolean
opp-suspend:
description:
Marks the OPP to be used during device suspend. If multiple OPPs in
the table have this, the OPP with highest opp-hz will be used.
type: boolean
opp-supported-hw:
description: |
This property allows a platform to enable only a subset of the OPPs
from the larger set present in the OPP table, based on the current
version of the hardware (already known to the operating system).
Each block present in the array of blocks in this property, represents
a sub-group of hardware versions supported by the OPP. i.e. <sub-group
A>, <sub-group B>, etc. The OPP will be enabled if _any_ of these
sub-groups match the hardware's version.
Each sub-group is a platform defined array representing the hierarchy
of hardware versions supported by the platform. For a platform with
three hierarchical levels of version (X.Y.Z), this field shall look
like
opp-supported-hw = <X1 Y1 Z1>, <X2 Y2 Z2>, <X3 Y3 Z3>.
Each level (eg. X1) in version hierarchy is represented by a 32 bit
value, one bit per version and so there can be maximum 32 versions per
level. Logical AND (&) operation is performed for each level with the
hardware's level version and a non-zero output for _all_ the levels in
a sub-group means the OPP is supported by hardware. A value of
0xFFFFFFFF for each level in the sub-group will enable the OPP for all
versions for the hardware.
$ref: /schemas/types.yaml#/definitions/uint32-matrix
maxItems: 32
items:
minItems: 1
maxItems: 4
required-opps:
description:
This contains phandle to an OPP node in another device's OPP table. It
may contain an array of phandles, where each phandle points to an OPP
of a different device. It should not contain multiple phandles to the
OPP nodes in the same OPP table. This specifies the minimum required
OPP of the device(s), whose OPP's phandle is present in this property,
for the functioning of the current device at the current OPP (where
this property is present).
$ref: /schemas/types.yaml#/definitions/phandle-array
patternProperties:
'^opp-microvolt-':
description:
Named opp-microvolt property. This is exactly similar to the above
opp-microvolt property, but allows multiple voltage ranges to be
provided for the same OPP. At runtime, the platform can pick a <name>
and matching opp-microvolt-<name> property will be enabled for all
OPPs. If the platform doesn't pick a specific <name> or the <name>
doesn't match with any opp-microvolt-<name> properties, then
opp-microvolt property shall be used, if present.
$ref: /schemas/types.yaml#/definitions/uint32-matrix
minItems: 1
maxItems: 8 # Should be enough regulators
items:
minItems: 1
maxItems: 3
'^opp-microamp-':
description:
Named opp-microamp property. Similar to opp-microvolt-<name> property,
but for microamp instead.
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 8 # Should be enough regulators
dependencies:
opp-avg-kBps: [ opp-peak-kBps ]
required:
- compatible
additionalProperties: true
...

475
Documentation/devicetree/bindings/opp/opp-v2.yaml Normal file
View File

@ -0,0 +1,475 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/opp/opp-v2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Generic OPP (Operating Performance Points) Bindings
maintainers:
- Viresh Kumar <viresh.kumar@linaro.org>
allOf:
- $ref: opp-v2-base.yaml#
properties:
compatible:
const: operating-points-v2
unevaluatedProperties: false
examples:
- |
/*
* Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states
* together.
*/
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
cpu-supply = <&cpu_supply0>;
operating-points-v2 = <&cpu0_opp_table0>;
};
cpu@1 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <1>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
cpu-supply = <&cpu_supply0>;
operating-points-v2 = <&cpu0_opp_table0>;
};
};
cpu0_opp_table0: opp-table {
compatible = "operating-points-v2";
opp-shared;
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
clock-latency-ns = <290000>;
turbo-mode;
};
};
- |
/*
* Example 2: Single cluster, Quad-core Qualcom-krait, switches DVFS states
* independently.
*/
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "qcom,krait";
device_type = "cpu";
reg = <0>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
cpu-supply = <&cpu_supply0>;
operating-points-v2 = <&cpu_opp_table>;
};
cpu@1 {
compatible = "qcom,krait";
device_type = "cpu";
reg = <1>;
next-level-cache = <&L2>;
clocks = <&clk_controller 1>;
clock-names = "cpu";
cpu-supply = <&cpu_supply1>;
operating-points-v2 = <&cpu_opp_table>;
};
cpu@2 {
compatible = "qcom,krait";
device_type = "cpu";
reg = <2>;
next-level-cache = <&L2>;
clocks = <&clk_controller 2>;
clock-names = "cpu";
cpu-supply = <&cpu_supply2>;
operating-points-v2 = <&cpu_opp_table>;
};
cpu@3 {
compatible = "qcom,krait";
device_type = "cpu";
reg = <3>;
next-level-cache = <&L2>;
clocks = <&clk_controller 3>;
clock-names = "cpu";
cpu-supply = <&cpu_supply3>;
operating-points-v2 = <&cpu_opp_table>;
};
};
cpu_opp_table: opp-table {
compatible = "operating-points-v2";
/*
* Missing opp-shared property means CPUs switch DVFS states
* independently.
*/
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000>;
lock-latency-ns = <290000>;
turbo-mode;
};
};
- |
/*
* Example 3: Dual-cluster, Dual-core per cluster. CPUs within a cluster switch
* DVFS state together.
*/
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
cpu-supply = <&cpu_supply0>;
operating-points-v2 = <&cluster0_opp>;
};
cpu@1 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
cpu-supply = <&cpu_supply0>;
operating-points-v2 = <&cluster0_opp>;
};
cpu@100 {
compatible = "arm,cortex-a15";
device_type = "cpu";
reg = <100>;
next-level-cache = <&L2>;
clocks = <&clk_controller 1>;
clock-names = "cpu";
cpu-supply = <&cpu_supply1>;
operating-points-v2 = <&cluster1_opp>;
};
cpu@101 {
compatible = "arm,cortex-a15";
device_type = "cpu";
reg = <101>;
next-level-cache = <&L2>;
clocks = <&clk_controller 1>;
clock-names = "cpu";
cpu-supply = <&cpu_supply1>;
operating-points-v2 = <&cluster1_opp>;
};
};
cluster0_opp: opp-table-0 {
compatible = "operating-points-v2";
opp-shared;
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000>;
clock-latency-ns = <290000>;
turbo-mode;
};
};
cluster1_opp: opp-table-1 {
compatible = "operating-points-v2";
opp-shared;
opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1050000 1045000 1055000>;
opp-microamp = <95000>;
clock-latency-ns = <400000>;
opp-suspend;
};
opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1075000>;
opp-microamp = <100000>;
clock-latency-ns = <400000>;
};
opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1100000 1010000 1110000>;
opp-microamp = <95000>;
clock-latency-ns = <400000>;
turbo-mode;
};
};
- |
/* Example 4: Handling multiple regulators */
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "foo,cpu-type";
device_type = "cpu";
reg = <0>;
vcc0-supply = <&cpu_supply0>;
vcc1-supply = <&cpu_supply1>;
vcc2-supply = <&cpu_supply2>;
operating-points-v2 = <&cpu0_opp_table4>;
};
};
cpu0_opp_table4: opp-table-0 {
compatible = "operating-points-v2";
opp-shared;
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000>, /* Supply 0 */
<960000>, /* Supply 1 */
<960000>; /* Supply 2 */
opp-microamp = <70000>, /* Supply 0 */
<70000>, /* Supply 1 */
<70000>; /* Supply 2 */
clock-latency-ns = <300000>;
};
/* OR */
opp-1000000001 {
opp-hz = /bits/ 64 <1000000001>;
opp-microvolt = <975000 970000 985000>, /* Supply 0 */
<965000 960000 975000>, /* Supply 1 */
<965000 960000 975000>; /* Supply 2 */
opp-microamp = <70000>, /* Supply 0 */
<70000>, /* Supply 1 */
<70000>; /* Supply 2 */
clock-latency-ns = <300000>;
};
/* OR */
opp-1000000002 {
opp-hz = /bits/ 64 <1000000002>;
opp-microvolt = <975000 970000 985000>, /* Supply 0 */
<965000 960000 975000>, /* Supply 1 */
<965000 960000 975000>; /* Supply 2 */
opp-microamp = <70000>, /* Supply 0 */
<0>, /* Supply 1 doesn't need this */
<70000>; /* Supply 2 */
clock-latency-ns = <300000>;
};
};
- |
/*
* Example 5: opp-supported-hw
* (example: three level hierarchy of versions: cuts, substrate and process)
*/
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0>;
cpu-supply = <&cpu_supply>;
operating-points-v2 = <&cpu0_opp_table_slow>;
};
};
cpu0_opp_table_slow: opp-table {
compatible = "operating-points-v2";
opp-shared;
opp-600000000 {
/*
* Supports all substrate and process versions for 0xF
* cuts, i.e. only first four cuts.
*/
opp-supported-hw = <0xF 0xFFFFFFFF 0xFFFFFFFF>;
opp-hz = /bits/ 64 <600000000>;
};
opp-800000000 {
/*
* Supports:
* - cuts: only one, 6th cut (represented by 6th bit).
* - substrate: supports 16 different substrate versions
* - process: supports 9 different process versions
*/
opp-supported-hw = <0x20 0xff0000ff 0x0000f4f0>;
opp-hz = /bits/ 64 <800000000>;
};
opp-900000000 {
/*
* Supports:
* - All cuts and substrate where process version is 0x2.
* - All cuts and process where substrate version is 0x2.
*/
opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0x02>,
<0xFFFFFFFF 0x01 0xFFFFFFFF>;
opp-hz = /bits/ 64 <900000000>;
};
};
- |
/*
* Example 6: opp-microvolt-<name>, opp-microamp-<name>:
* (example: device with two possible microvolt ranges: slow and fast)
*/
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0>;
operating-points-v2 = <&cpu0_opp_table6>;
};
};
cpu0_opp_table6: opp-table-0 {
compatible = "operating-points-v2";
opp-shared;
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt-slow = <915000 900000 925000>;
opp-microvolt-fast = <975000 970000 985000>;
opp-microamp-slow = <70000>;
opp-microamp-fast = <71000>;
};
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt-slow = <915000 900000 925000>, /* Supply vcc0 */
<925000 910000 935000>; /* Supply vcc1 */
opp-microvolt-fast = <975000 970000 985000>, /* Supply vcc0 */
<965000 960000 975000>; /* Supply vcc1 */
opp-microamp = <70000>; /* Will be used for both slow/fast */
};
};
- |
/*
* Example 7: Single cluster Quad-core ARM cortex A53, OPP points from firmware,
* distinct clock controls but two sets of clock/voltage/current lines.
*/
cpus {
#address-cells = <2>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <0x0 0x100>;
next-level-cache = <&A53_L2>;
clocks = <&dvfs_controller 0>;
operating-points-v2 = <&cpu_opp0_table>;
};
cpu@1 {
compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <0x0 0x101>;
next-level-cache = <&A53_L2>;
clocks = <&dvfs_controller 1>;
operating-points-v2 = <&cpu_opp0_table>;
};
cpu@2 {
compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <0x0 0x102>;
next-level-cache = <&A53_L2>;
clocks = <&dvfs_controller 2>;
operating-points-v2 = <&cpu_opp1_table>;
};
cpu@3 {
compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <0x0 0x103>;
next-level-cache = <&A53_L2>;
clocks = <&dvfs_controller 3>;
operating-points-v2 = <&cpu_opp1_table>;
};
};
cpu_opp0_table: opp-table-0 {
compatible = "operating-points-v2";
opp-shared;
};
cpu_opp1_table: opp-table-1 {
compatible = "operating-points-v2";
opp-shared;
};
...

622
Documentation/devicetree/bindings/opp/opp.txt
View File

@ -1,622 +0,0 @@
Generic OPP (Operating Performance Points) Bindings
----------------------------------------------------
Devices work at voltage-current-frequency combinations and some implementations
have the liberty of choosing these. These combinations are called Operating
Performance Points aka OPPs. This document defines bindings for these OPPs
applicable across wide range of devices. For illustration purpose, this document
uses CPU as a device.
This document contain multiple versions of OPP binding and only one of them
should be used per device.
Binding 1: operating-points
============================
This binding only supports voltage-frequency pairs.
Properties:
- operating-points: An array of 2-tuples items, and each item consists
of frequency and voltage like <freq-kHz vol-uV>.
freq: clock frequency in kHz
vol: voltage in microvolt
Examples:
cpu@0 {
compatible = "arm,cortex-a9";
reg = <0>;
next-level-cache = <&L2>;
operating-points = <
/* kHz uV */
792000 1100000
396000 950000
198000 850000
>;
};
Binding 2: operating-points-v2
============================
* Property: operating-points-v2
Devices supporting OPPs must set their "operating-points-v2" property with
phandle to a OPP table in their DT node. The OPP core will use this phandle to
find the operating points for the device.
This can contain more than one phandle for power domain providers that provide
multiple power domains. That is, one phandle for each power domain. If only one
phandle is available, then the same OPP table will be used for all power domains
provided by the power domain provider.
If required, this can be extended for SoC vendor specific bindings. Such bindings
should be documented as Documentation/devicetree/bindings/power/<vendor>-opp.txt
and should have a compatible description like: "operating-points-v2-<vendor>".
* OPP Table Node
This describes the OPPs belonging to a device. This node can have following
properties:
Required properties:
- compatible: Allow OPPs to express their compatibility. It should be:
"operating-points-v2".
- OPP nodes: One or more OPP nodes describing voltage-current-frequency
combinations. Their name isn't significant but their phandle can be used to
reference an OPP. These are mandatory except for the case where the OPP table
is present only to indicate dependency between devices using the opp-shared
property.
Optional properties:
- opp-shared: Indicates that device nodes using this OPP Table Node's phandle
switch their DVFS state together, i.e. they share clock/voltage/current lines.
Missing property means devices have independent clock/voltage/current lines,
but they share OPP tables.
- status: Marks the OPP table enabled/disabled.
* OPP Node
This defines voltage-current-frequency combinations along with other related
properties.
Required properties:
- opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer. This is a
required property for all device nodes, unless another "required" property to
uniquely identify the OPP nodes exists. Devices like power domains must have
another (implementation dependent) property.
- opp-peak-kBps: Peak bandwidth in kilobytes per second, expressed as an array
of 32-bit big-endian integers. Each element of the array represents the
peak bandwidth value of each interconnect path. The number of elements should
match the number of interconnect paths.
Optional properties:
- opp-microvolt: voltage in micro Volts.
A single regulator's voltage is specified with an array of size one or three.
Single entry is for target voltage and three entries are for <target min max>
voltages.
Entries for multiple regulators shall be provided in the same field separated
by angular brackets <>. The OPP binding doesn't provide any provisions to
relate the values to their power supplies or the order in which the supplies
need to be configured and that is left for the implementation specific
binding.
Entries for all regulators shall be of the same size, i.e. either all use a
single value or triplets.
- opp-microvolt-<name>: Named opp-microvolt property. This is exactly similar to
the above opp-microvolt property, but allows multiple voltage ranges to be
provided for the same OPP. At runtime, the platform can pick a <name> and
matching opp-microvolt-<name> property will be enabled for all OPPs. If the
platform doesn't pick a specific <name> or the <name> doesn't match with any
opp-microvolt-<name> properties, then opp-microvolt property shall be used, if
present.
- opp-microamp: The maximum current drawn by the device in microamperes
considering system specific parameters (such as transients, process, aging,
maximum operating temperature range etc.) as necessary. This may be used to
set the most efficient regulator operating mode.
Should only be set if opp-microvolt is set for the OPP.
Entries for multiple regulators shall be provided in the same field separated
by angular brackets <>. If current values aren't required for a regulator,
then it shall be filled with 0. If current values aren't required for any of
the regulators, then this field is not required. The OPP binding doesn't
provide any provisions to relate the values to their power supplies or the
order in which the supplies need to be configured and that is left for the
implementation specific binding.
- opp-microamp-<name>: Named opp-microamp property. Similar to
opp-microvolt-<name> property, but for microamp instead.
- opp-level: A value representing the performance level of the device,
expressed as a 32-bit integer.
- opp-avg-kBps: Average bandwidth in kilobytes per second, expressed as an array
of 32-bit big-endian integers. Each element of the array represents the
average bandwidth value of each interconnect path. The number of elements
should match the number of interconnect paths. This property is only
meaningful in OPP tables where opp-peak-kBps is present.
- clock-latency-ns: Specifies the maximum possible transition latency (in
nanoseconds) for switching to this OPP from any other OPP.
- turbo-mode: Marks the OPP to be used only for turbo modes. Turbo mode is
available on some platforms, where the device can run over its operating
frequency for a short duration of time limited by the device's power, current
and thermal limits.
- opp-suspend: Marks the OPP to be used during device suspend. If multiple OPPs
in the table have this, the OPP with highest opp-hz will be used.
- opp-supported-hw: This property allows a platform to enable only a subset of
the OPPs from the larger set present in the OPP table, based on the current
version of the hardware (already known to the operating system).
Each block present in the array of blocks in this property, represents a
sub-group of hardware versions supported by the OPP. i.e. <sub-group A>,
<sub-group B>, etc. The OPP will be enabled if _any_ of these sub-groups match
the hardware's version.
Each sub-group is a platform defined array representing the hierarchy of
hardware versions supported by the platform. For a platform with three
hierarchical levels of version (X.Y.Z), this field shall look like
opp-supported-hw = <X1 Y1 Z1>, <X2 Y2 Z2>, <X3 Y3 Z3>.
Each level (eg. X1) in version hierarchy is represented by a 32 bit value, one
bit per version and so there can be maximum 32 versions per level. Logical AND
(&) operation is performed for each level with the hardware's level version
and a non-zero output for _all_ the levels in a sub-group means the OPP is
supported by hardware. A value of 0xFFFFFFFF for each level in the sub-group
will enable the OPP for all versions for the hardware.
- status: Marks the node enabled/disabled.
- required-opps: This contains phandle to an OPP node in another device's OPP
table. It may contain an array of phandles, where each phandle points to an
OPP of a different device. It should not contain multiple phandles to the OPP
nodes in the same OPP table. This specifies the minimum required OPP of the
device(s), whose OPP's phandle is present in this property, for the
functioning of the current device at the current OPP (where this property is
present).
Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
/ {
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a9";
reg = <0>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
cpu-supply = <&cpu_supply0>;
operating-points-v2 = <&cpu0_opp_table>;
};
cpu@1 {
compatible = "arm,cortex-a9";
reg = <1>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
cpu-supply = <&cpu_supply0>;
operating-points-v2 = <&cpu0_opp_table>;
};
};
cpu0_opp_table: opp_table0 {
compatible = "operating-points-v2";
opp-shared;
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
clock-latency-ns = <290000>;
turbo-mode;
};
};
};
Example 2: Single cluster, Quad-core Qualcom-krait, switches DVFS states
independently.
/ {
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "qcom,krait";
reg = <0>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
cpu-supply = <&cpu_supply0>;
operating-points-v2 = <&cpu_opp_table>;
};
cpu@1 {
compatible = "qcom,krait";
reg = <1>;
next-level-cache = <&L2>;
clocks = <&clk_controller 1>;
clock-names = "cpu";
cpu-supply = <&cpu_supply1>;
operating-points-v2 = <&cpu_opp_table>;
};
cpu@2 {
compatible = "qcom,krait";
reg = <2>;
next-level-cache = <&L2>;
clocks = <&clk_controller 2>;
clock-names = "cpu";
cpu-supply = <&cpu_supply2>;
operating-points-v2 = <&cpu_opp_table>;
};
cpu@3 {
compatible = "qcom,krait";
reg = <3>;
next-level-cache = <&L2>;
clocks = <&clk_controller 3>;
clock-names = "cpu";
cpu-supply = <&cpu_supply3>;
operating-points-v2 = <&cpu_opp_table>;
};
};
cpu_opp_table: opp_table {
compatible = "operating-points-v2";
/*
* Missing opp-shared property means CPUs switch DVFS states
* independently.
*/
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000;
lock-latency-ns = <290000>;
turbo-mode;
};
};
};
Example 3: Dual-cluster, Dual-core per cluster. CPUs within a cluster switch
DVFS state together.
/ {
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a7";
reg = <0>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
cpu-supply = <&cpu_supply0>;
operating-points-v2 = <&cluster0_opp>;
};
cpu@1 {
compatible = "arm,cortex-a7";
reg = <1>;
next-level-cache = <&L2>;
clocks = <&clk_controller 0>;
clock-names = "cpu";
cpu-supply = <&cpu_supply0>;
operating-points-v2 = <&cluster0_opp>;
};
cpu@100 {
compatible = "arm,cortex-a15";
reg = <100>;
next-level-cache = <&L2>;
clocks = <&clk_controller 1>;
clock-names = "cpu";
cpu-supply = <&cpu_supply1>;
operating-points-v2 = <&cluster1_opp>;
};
cpu@101 {
compatible = "arm,cortex-a15";
reg = <101>;
next-level-cache = <&L2>;
clocks = <&clk_controller 1>;
clock-names = "cpu";
cpu-supply = <&cpu_supply1>;
operating-points-v2 = <&cluster1_opp>;
};
};
cluster0_opp: opp_table0 {
compatible = "operating-points-v2";
opp-shared;
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
opp-1100000000 {
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <1000000 980000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000>;
clock-latency-ns = <290000>;
turbo-mode;
};
};
cluster1_opp: opp_table1 {
compatible = "operating-points-v2";
opp-shared;
opp-1300000000 {
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1050000 1045000 1055000>;
opp-microamp = <95000>;
clock-latency-ns = <400000>;
opp-suspend;
};
opp-1400000000 {
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1075000>;
opp-microamp = <100000>;
clock-latency-ns = <400000>;
};
opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1100000 1010000 1110000>;
opp-microamp = <95000>;
clock-latency-ns = <400000>;
turbo-mode;
};
};
};
Example 4: Handling multiple regulators
/ {
cpus {
cpu@0 {
compatible = "vendor,cpu-type";
...
vcc0-supply = <&cpu_supply0>;
vcc1-supply = <&cpu_supply1>;
vcc2-supply = <&cpu_supply2>;
operating-points-v2 = <&cpu0_opp_table>;
};
};
cpu0_opp_table: opp_table0 {
compatible = "operating-points-v2";
opp-shared;
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000>, /* Supply 0 */
<960000>, /* Supply 1 */
<960000>; /* Supply 2 */
opp-microamp = <70000>, /* Supply 0 */
<70000>, /* Supply 1 */
<70000>; /* Supply 2 */
clock-latency-ns = <300000>;
};
/* OR */
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>, /* Supply 0 */
<965000 960000 975000>, /* Supply 1 */
<965000 960000 975000>; /* Supply 2 */
opp-microamp = <70000>, /* Supply 0 */
<70000>, /* Supply 1 */
<70000>; /* Supply 2 */
clock-latency-ns = <300000>;
};
/* OR */
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <975000 970000 985000>, /* Supply 0 */
<965000 960000 975000>, /* Supply 1 */
<965000 960000 975000>; /* Supply 2 */
opp-microamp = <70000>, /* Supply 0 */
<0>, /* Supply 1 doesn't need this */
<70000>; /* Supply 2 */
clock-latency-ns = <300000>;
};
};
};
Example 5: opp-supported-hw
(example: three level hierarchy of versions: cuts, substrate and process)
/ {
cpus {
cpu@0 {
compatible = "arm,cortex-a7";
...
cpu-supply = <&cpu_supply>
operating-points-v2 = <&cpu0_opp_table_slow>;
};
};
opp_table {
compatible = "operating-points-v2";
opp-shared;
opp-600000000 {
/*
* Supports all substrate and process versions for 0xF
* cuts, i.e. only first four cuts.
*/
opp-supported-hw = <0xF 0xFFFFFFFF 0xFFFFFFFF>
opp-hz = /bits/ 64 <600000000>;
...
};
opp-800000000 {
/*
* Supports:
* - cuts: only one, 6th cut (represented by 6th bit).
* - substrate: supports 16 different substrate versions
* - process: supports 9 different process versions
*/
opp-supported-hw = <0x20 0xff0000ff 0x0000f4f0>
opp-hz = /bits/ 64 <800000000>;
...
};
opp-900000000 {
/*
* Supports:
* - All cuts and substrate where process version is 0x2.
* - All cuts and process where substrate version is 0x2.
*/
opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0x02>, <0xFFFFFFFF 0x01 0xFFFFFFFF>
opp-hz = /bits/ 64 <900000000>;
...
};
};
};
Example 6: opp-microvolt-<name>, opp-microamp-<name>:
(example: device with two possible microvolt ranges: slow and fast)
/ {
cpus {
cpu@0 {
compatible = "arm,cortex-a7";
...
operating-points-v2 = <&cpu0_opp_table>;
};
};
cpu0_opp_table: opp_table0 {
compatible = "operating-points-v2";
opp-shared;
opp-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt-slow = <915000 900000 925000>;
opp-microvolt-fast = <975000 970000 985000>;
opp-microamp-slow = <70000>;
opp-microamp-fast = <71000>;
};
opp-1200000000 {
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt-slow = <915000 900000 925000>, /* Supply vcc0 */
<925000 910000 935000>; /* Supply vcc1 */
opp-microvolt-fast = <975000 970000 985000>, /* Supply vcc0 */
<965000 960000 975000>; /* Supply vcc1 */
opp-microamp = <70000>; /* Will be used for both slow/fast */
};
};
};
Example 7: Single cluster Quad-core ARM cortex A53, OPP points from firmware,
distinct clock controls but two sets of clock/voltage/current lines.
/ {
cpus {
#address-cells = <2>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a53";
reg = <0x0 0x100>;
next-level-cache = <&A53_L2>;
clocks = <&dvfs_controller 0>;
operating-points-v2 = <&cpu_opp0_table>;
};
cpu@1 {
compatible = "arm,cortex-a53";
reg = <0x0 0x101>;
next-level-cache = <&A53_L2>;
clocks = <&dvfs_controller 1>;
operating-points-v2 = <&cpu_opp0_table>;
};
cpu@2 {
compatible = "arm,cortex-a53";
reg = <0x0 0x102>;
next-level-cache = <&A53_L2>;
clocks = <&dvfs_controller 2>;
operating-points-v2 = <&cpu_opp1_table>;
};
cpu@3 {
compatible = "arm,cortex-a53";
reg = <0x0 0x103>;
next-level-cache = <&A53_L2>;
clocks = <&dvfs_controller 3>;
operating-points-v2 = <&cpu_opp1_table>;
};
};
cpu_opp0_table: opp0_table {
compatible = "operating-points-v2";
opp-shared;
};
cpu_opp1_table: opp1_table {
compatible = "operating-points-v2";
opp-shared;
};
};

2
Documentation/devicetree/bindings/opp/qcom-opp.txt
View File

@ -1,7 +1,7 @@
Qualcomm OPP bindings to describe OPP nodes
The bindings are based on top of the operating-points-v2 bindings
described in Documentation/devicetree/bindings/opp/opp.txt
described in Documentation/devicetree/bindings/opp/opp-v2-base.yaml
Additional properties are described below.
* OPP Table Node

2
Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
View File

@ -13,7 +13,7 @@ regulators to the device that will undergo OPP transitions we can make use
of the multi regulator binding that is part of the OPP core described here [1]
to describe both regulators needed by the platform.
[1] Documentation/devicetree/bindings/opp/opp.txt
[1] Documentation/devicetree/bindings/opp/opp-v2.yaml
Required Properties for Device Node:
- vdd-supply: phandle to regulator controlling VDD supply

69
Documentation/devicetree/bindings/pci/intel,keembay-pcie-ep.yaml Normal file
View File

@ -0,0 +1,69 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/pci/intel,keembay-pcie-ep.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Intel Keem Bay PCIe controller Endpoint mode
maintainers:
- Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com>
- Srikanth Thokala <srikanth.thokala@intel.com>
properties:
compatible:
const: intel,keembay-pcie-ep
reg:
maxItems: 5
reg-names:
items:
- const: dbi
- const: dbi2
- const: atu
- const: addr_space
- const: apb
interrupts:
maxItems: 4
interrupt-names:
items:
- const: pcie
- const: pcie_ev
- const: pcie_err
- const: pcie_mem_access
num-lanes:
description: Number of lanes to use.
enum: [ 1, 2 ]
required:
- compatible
- reg
- reg-names
- interrupts
- interrupt-names
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
pcie-ep@37000000 {
compatible = "intel,keembay-pcie-ep";
reg = <0x37000000 0x00001000>,
<0x37100000 0x00001000>,
<0x37300000 0x00001000>,
<0x36000000 0x01000000>,
<0x37800000 0x00000200>;
reg-names = "dbi", "dbi2", "atu", "addr_space", "apb";
interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 108 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "pcie", "pcie_ev", "pcie_err", "pcie_mem_access";
num-lanes = <2>;
};

97
Documentation/devicetree/bindings/pci/intel,keembay-pcie.yaml Normal file
View File

@ -0,0 +1,97 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/pci/intel,keembay-pcie.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Intel Keem Bay PCIe controller Root Complex mode
maintainers:
- Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com>
- Srikanth Thokala <srikanth.thokala@intel.com>
allOf:
- $ref: /schemas/pci/pci-bus.yaml#
properties:
compatible:
const: intel,keembay-pcie
ranges:
maxItems: 1
reset-gpios:
maxItems: 1
reg:
maxItems: 4
reg-names:
items:
- const: dbi
- const: atu
- const: config
- const: apb
clocks:
maxItems: 2
clock-names:
items:
- const: master
- const: aux
interrupts:
maxItems: 3
interrupt-names:
items:
- const: pcie
- const: pcie_ev
- const: pcie_err
num-lanes:
description: Number of lanes to use.
enum: [ 1, 2 ]
required:
- compatible
- reg
- reg-names
- ranges
- clocks
- clock-names
- interrupts
- interrupt-names
- reset-gpios
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/gpio/gpio.h>
#define KEEM_BAY_A53_PCIE
#define KEEM_BAY_A53_AUX_PCIE
pcie@37000000 {
compatible = "intel,keembay-pcie";
reg = <0x37000000 0x00001000>,
<0x37300000 0x00001000>,
<0x36e00000 0x00200000>,
<0x37800000 0x00000200>;
reg-names = "dbi", "atu", "config", "apb";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
ranges = <0x02000000 0 0x36000000 0x36000000 0 0x00e00000>;
interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "pcie", "pcie_ev", "pcie_err";
clocks = <&scmi_clk KEEM_BAY_A53_PCIE>,
<&scmi_clk KEEM_BAY_A53_AUX_PCIE>;
clock-names = "master", "aux";
reset-gpios = <&pca2 9 GPIO_ACTIVE_LOW>;
num-lanes = <2>;
};

39
Documentation/devicetree/bindings/pci/mediatek-pcie-cfg.yaml Normal file
View File

@ -0,0 +1,39 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/pci/mediatek-pcie-cfg.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek PCIECFG controller
maintainers:
- Chuanjia Liu <chuanjia.liu@mediatek.com>
- Jianjun Wang <jianjun.wang@mediatek.com>
description: |
The MediaTek PCIECFG controller controls some feature about
LTSSM, ASPM and so on.
properties:
compatible:
items:
- enum:
- mediatek,generic-pciecfg
- const: syscon
reg:
maxItems: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
pciecfg: pciecfg@1a140000 {
compatible = "mediatek,generic-pciecfg", "syscon";
reg = <0x1a140000 0x1000>;
};
...

212
Documentation/devicetree/bindings/pci/mediatek-pcie.txt
View File

@ -8,7 +8,7 @@ Required properties:
"mediatek,mt7623-pcie"
"mediatek,mt7629-pcie"
- device_type: Must be "pci"
- reg: Base addresses and lengths of the PCIe subsys and root ports.
- reg: Base addresses and lengths of the root ports.
- reg-names: Names of the above areas to use during resource lookup.
- #address-cells: Address representation for root ports (must be 3)
- #size-cells: Size representation for root ports (must be 2)
@ -47,9 +47,12 @@ Required properties for MT7623/MT2701:
- reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the
number of root ports.
Required properties for MT2712/MT7622:
Required properties for MT2712/MT7622/MT7629:
-interrupts: A list of interrupt outputs of the controller, must have one
entry for each PCIe port
- interrupt-names: Must include the following entries:
- "pcie_irq": The interrupt that is asserted when an MSI/INTX is received
- linux,pci-domain: PCI domain ID. Should be unique for each host controller
In addition, the device tree node must have sub-nodes describing each
PCIe port interface, having the following mandatory properties:
@ -143,130 +146,143 @@ Examples for MT7623:
Examples for MT2712:
pcie: pcie@11700000 {
pcie1: pcie@112ff000 {
compatible = "mediatek,mt2712-pcie";
device_type = "pci";
reg = <0 0x11700000 0 0x1000>,
<0 0x112ff000 0 0x1000>;
reg-names = "port0", "port1";
reg = <0 0x112ff000 0 0x1000>;
reg-names = "port1";
linux,pci-domain = <1>;
#address-cells = <3>;
#size-cells = <2>;
interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&topckgen CLK_TOP_PE2_MAC_P0_SEL>,
<&topckgen CLK_TOP_PE2_MAC_P1_SEL>,
<&pericfg CLK_PERI_PCIE0>,
interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "pcie_irq";
clocks = <&topckgen CLK_TOP_PE2_MAC_P1_SEL>,
<&pericfg CLK_PERI_PCIE1>;
clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1";
phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>;
phy-names = "pcie-phy0", "pcie-phy1";
clock-names = "sys_ck1", "ahb_ck1";
phys = <&u3port1 PHY_TYPE_PCIE>;
phy-names = "pcie-phy1";
bus-range = <0x00 0xff>;
ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x10000000>;
ranges = <0x82000000 0 0x11400000 0x0 0x11400000 0 0x300000>;
status = "disabled";
pcie0: pcie@0,0 {
reg = <0x0000 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie_intc1 0>,
<0 0 0 2 &pcie_intc1 1>,
<0 0 0 3 &pcie_intc1 2>,
<0 0 0 4 &pcie_intc1 3>;
pcie_intc1: interrupt-controller {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
ranges;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie_intc0 0>,
<0 0 0 2 &pcie_intc0 1>,
<0 0 0 3 &pcie_intc0 2>,
<0 0 0 4 &pcie_intc0 3>;
pcie_intc0: interrupt-controller {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
};
};
};
pcie1: pcie@1,0 {
reg = <0x0800 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
pcie0: pcie@11700000 {
compatible = "mediatek,mt2712-pcie";
device_type = "pci";
reg = <0 0x11700000 0 0x1000>;
reg-names = "port0";
linux,pci-domain = <0>;
#address-cells = <3>;
#size-cells = <2>;
interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "pcie_irq";
clocks = <&topckgen CLK_TOP_PE2_MAC_P0_SEL>,
<&pericfg CLK_PERI_PCIE0>;
clock-names = "sys_ck0", "ahb_ck0";
phys = <&u3port0 PHY_TYPE_PCIE>;
phy-names = "pcie-phy0";
bus-range = <0x00 0xff>;
ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x10000000>;
status = "disabled";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie_intc0 0>,
<0 0 0 2 &pcie_intc0 1>,
<0 0 0 3 &pcie_intc0 2>,
<0 0 0 4 &pcie_intc0 3>;
pcie_intc0: interrupt-controller {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
ranges;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie_intc1 0>,
<0 0 0 2 &pcie_intc1 1>,
<0 0 0 3 &pcie_intc1 2>,
<0 0 0 4 &pcie_intc1 3>;
pcie_intc1: interrupt-controller {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
};
};
};
Examples for MT7622:
pcie: pcie@1a140000 {
pcie0: pcie@1a143000 {
compatible = "mediatek,mt7622-pcie";
device_type = "pci";
reg = <0 0x1a140000 0 0x1000>,
<0 0x1a143000 0 0x1000>,
<0 0x1a145000 0 0x1000>;
reg-names = "subsys", "port0", "port1";
reg = <0 0x1a143000 0 0x1000>;
reg-names = "port0";
linux,pci-domain = <0>;
#address-cells = <3>;
#size-cells = <2>;
interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_LOW>,
<GIC_SPI 229 IRQ_TYPE_LEVEL_LOW>;
interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_LOW>;
interrupt-names = "pcie_irq";
clocks = <&pciesys CLK_PCIE_P0_MAC_EN>,
<&pciesys CLK_PCIE_P1_MAC_EN>,
<&pciesys CLK_PCIE_P0_AHB_EN>,
<&pciesys CLK_PCIE_P1_AHB_EN>,
<&pciesys CLK_PCIE_P0_AUX_EN>,
<&pciesys CLK_PCIE_P1_AUX_EN>,
<&pciesys CLK_PCIE_P0_AXI_EN>,
<&pciesys CLK_PCIE_P1_AXI_EN>,
<&pciesys CLK_PCIE_P0_OBFF_EN>,
<&pciesys CLK_PCIE_P1_OBFF_EN>,
<&pciesys CLK_PCIE_P0_PIPE_EN>,
<&pciesys CLK_PCIE_P1_PIPE_EN>;
clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1",
"aux_ck0", "aux_ck1", "axi_ck0", "axi_ck1",
"obff_ck0", "obff_ck1", "pipe_ck0", "pipe_ck1";
phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>;
phy-names = "pcie-phy0", "pcie-phy1";
<&pciesys CLK_PCIE_P0_PIPE_EN>;
clock-names = "sys_ck0", "ahb_ck0", "aux_ck0",
"axi_ck0", "obff_ck0", "pipe_ck0";
power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
bus-range = <0x00 0xff>;
ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x10000000>;
ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x8000000>;
status = "disabled";
pcie0: pcie@0,0 {
reg = <0x0000 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie_intc0 0>,
<0 0 0 2 &pcie_intc0 1>,
<0 0 0 3 &pcie_intc0 2>,
<0 0 0 4 &pcie_intc0 3>;
pcie_intc0: interrupt-controller {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
};
};
pcie1: pcie@1a145000 {
compatible = "mediatek,mt7622-pcie";
device_type = "pci";
reg = <0 0x1a145000 0 0x1000>;
reg-names = "port1";
linux,pci-domain = <1>;
#address-cells = <3>;
#size-cells = <2>;
interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_LOW>;
interrupt-names = "pcie_irq";
clocks = <&pciesys CLK_PCIE_P1_MAC_EN>,
/* designer has connect RC1 with p0_ahb clock */
<&pciesys CLK_PCIE_P0_AHB_EN>,
<&pciesys CLK_PCIE_P1_AUX_EN>,
<&pciesys CLK_PCIE_P1_AXI_EN>,
<&pciesys CLK_PCIE_P1_OBFF_EN>,
<&pciesys CLK_PCIE_P1_PIPE_EN>;
clock-names = "sys_ck1", "ahb_ck1", "aux_ck1",
"axi_ck1", "obff_ck1", "pipe_ck1";
power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
bus-range = <0x00 0xff>;
ranges = <0x82000000 0 0x28000000 0x0 0x28000000 0 0x8000000>;
status = "disabled";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie_intc1 0>,
<0 0 0 2 &pcie_intc1 1>,
<0 0 0 3 &pcie_intc1 2>,
<0 0 0 4 &pcie_intc1 3>;
pcie_intc1: interrupt-controller {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
ranges;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie_intc0 0>,
<0 0 0 2 &pcie_intc0 1>,
<0 0 0 3 &pcie_intc0 2>,
<0 0 0 4 &pcie_intc0 3>;
pcie_intc0: interrupt-controller {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
};
};
pcie1: pcie@1,0 {
reg = <0x0800 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
ranges;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pcie_intc1 0>,
<0 0 0 2 &pcie_intc1 1>,
<0 0 0 3 &pcie_intc1 2>,
<0 0 0 4 &pcie_intc1 3>;
pcie_intc1: interrupt-controller {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
};
};
};

7
Documentation/devicetree/bindings/pci/pci-ep.yaml
View File

@ -23,6 +23,13 @@ properties:
default: 1
maximum: 255
max-virtual-functions:
description: Array representing the number of virtual functions corresponding to each physical
function
$ref: /schemas/types.yaml#/definitions/uint8-array
minItems: 1
maxItems: 255
max-link-speed:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 1, 2, 3, 4 ]

1
Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
View File

@ -35,6 +35,7 @@ Required properties:
Optional properties:
- dma-coherent: present if DMA operations are coherent
- clocks: Input clock specifier. Refer to common clock bindings
Example:
++++++++

2
Documentation/devicetree/bindings/power/power-domain.yaml
View File

@ -46,7 +46,7 @@ properties:
Phandles to the OPP tables of power domains provided by a power domain
provider. If the provider provides a single power domain only or all
the power domains provided by the provider have identical OPP tables,
then this shall contain a single phandle. Refer to ../opp/opp.txt
then this shall contain a single phandle. Refer to ../opp/opp-v2-base.yaml
for more information.
"#power-domain-cells":

49
Documentation/devicetree/bindings/power/reset/qcom,pon.txt
View File

@ -1,49 +0,0 @@
Qualcomm PON Device
The Power On device for Qualcomm PM8xxx is MFD supporting pwrkey
and resin along with the Android reboot-mode.
This DT node has pwrkey and resin as sub nodes.
Required Properties:
-compatible: Must be one of:
"qcom,pm8916-pon"
"qcom,pms405-pon"
"qcom,pm8998-pon"
-reg: Specifies the physical address of the pon register
Optional subnode:
-pwrkey: Specifies the subnode pwrkey and should follow the
qcom,pm8941-pwrkey.txt description.
-resin: Specifies the subnode resin and should follow the
qcom,pm8xxx-pwrkey.txt description.
The rest of the properties should follow the generic reboot-mode description
found in reboot-mode.txt
Example:
pon@800 {
compatible = "qcom,pm8916-pon";
reg = <0x800>;
mode-bootloader = <0x2>;
mode-recovery = <0x1>;
pwrkey {
compatible = "qcom,pm8941-pwrkey";
interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
debounce = <15625>;
bias-pull-up;
linux,code = <KEY_POWER>;
};
resin {
compatible = "qcom,pm8941-resin";
interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
debounce = <15625>;
bias-pull-up;
linux,code = <KEY_VOLUMEDOWN>;
};
};

80
Documentation/devicetree/bindings/power/reset/qcom,pon.yaml Normal file
View File

@ -0,0 +1,80 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/reset/qcom,pon.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm PON Device
maintainers:
- Vinod Koul <vkoul@kernel.org>
description: |
The Power On device for Qualcomm PM8xxx is MFD supporting pwrkey
and resin along with the Android reboot-mode.
This DT node has pwrkey and resin as sub nodes.
allOf:
- $ref: reboot-mode.yaml#
properties:
compatible:
enum:
- qcom,pm8916-pon
- qcom,pms405-pon
- qcom,pm8998-pon
reg:
maxItems: 1
pwrkey:
type: object
$ref: "../../input/qcom,pm8941-pwrkey.yaml#"
resin:
type: object
$ref: "../../input/qcom,pm8941-pwrkey.yaml#"
required:
- compatible
- reg
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/input/linux-event-codes.h>
#include <dt-bindings/spmi/spmi.h>
spmi_bus: spmi@c440000 {
reg = <0x0c440000 0x1100>;
#address-cells = <2>;
#size-cells = <0>;
pmk8350: pmic@0 {
reg = <0x0 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
pmk8350_pon: pon_hlos@1300 {
reg = <0x1300>;
compatible = "qcom,pm8998-pon";
pwrkey {
compatible = "qcom,pm8941-pwrkey";
interrupts = < 0x0 0x8 0 IRQ_TYPE_EDGE_BOTH >;
debounce = <15625>;
bias-pull-up;
linux,code = <KEY_POWER>;
};
resin {
compatible = "qcom,pm8941-resin";
interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
debounce = <15625>;
bias-pull-up;
linux,code = <KEY_VOLUMEDOWN>;
};
};
};
};
...

2
Documentation/devicetree/bindings/power/reset/reboot-mode.yaml
View File

@ -36,7 +36,7 @@ patternProperties:
"^mode-.*$":
$ref: /schemas/types.yaml#/definitions/uint32
additionalProperties: false
additionalProperties: true
examples:
- |

1
Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
View File

@ -29,6 +29,7 @@ properties:
- enum:
- rockchip,px30-pwm
- rockchip,rk3308-pwm
- rockchip,rk3568-pwm
- const: rockchip,rk3328-pwm
reg:

3
Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
View File

@ -32,6 +32,9 @@ properties:
- dallas,ds3232
# I2C-BUS INTERFACE REAL TIME CLOCK MODULE
- epson,rx8010
# I2C-BUS INTERFACE REAL TIME CLOCK MODULE
- epson,rx8025
- epson,rx8035
# I2C-BUS INTERFACE REAL TIME CLOCK MODULE with Battery Backed RAM
- epson,rx8571
# I2C-BUS INTERFACE REAL TIME CLOCK MODULE

1
Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
View File

@ -21,6 +21,7 @@ properties:
- fsl,imx8mn-rpmsg-audio
- fsl,imx8mm-rpmsg-audio
- fsl,imx8mp-rpmsg-audio
- fsl,imx8ulp-rpmsg-audio
model:
$ref: /schemas/types.yaml#/definitions/string

40
Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml
View File

@ -130,36 +130,34 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/clock/mt8195-clk.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/power/mt8195-power.h>
afe: mt8195-afe-pcm@10890000 {
compatible = "mediatek,mt8195-audio";
reg = <0x10890000 0x10000>;
interrupts = <GIC_SPI 822 IRQ_TYPE_LEVEL_HIGH 0>;
mediatek,topckgen = <&topckgen>;
power-domains = <&spm MT8195_POWER_DOMAIN_AUDIO>;
power-domains = <&spm 7>; //MT8195_POWER_DOMAIN_AUDIO
clocks = <&clk26m>,
<&topckgen CLK_TOP_APLL1>,
<&topckgen CLK_TOP_APLL2>,
<&topckgen CLK_TOP_APLL12_DIV0>,
<&topckgen CLK_TOP_APLL12_DIV1>,
<&topckgen CLK_TOP_APLL12_DIV2>,
<&topckgen CLK_TOP_APLL12_DIV3>,
<&topckgen CLK_TOP_APLL12_DIV9>,
<&topckgen CLK_TOP_A1SYS_HP_SEL>,
<&topckgen CLK_TOP_AUD_INTBUS_SEL>,
<&topckgen CLK_TOP_AUDIO_H_SEL>,
<&topckgen CLK_TOP_AUDIO_LOCAL_BUS_SEL>,
<&topckgen CLK_TOP_DPTX_M_SEL>,
<&topckgen CLK_TOP_I2SO1_M_SEL>,
<&topckgen CLK_TOP_I2SO2_M_SEL>,
<&topckgen CLK_TOP_I2SI1_M_SEL>,
<&topckgen CLK_TOP_I2SI2_M_SEL>,
<&infracfg_ao CLK_INFRA_AO_AUDIO_26M_B>,
<&scp_adsp CLK_SCP_ADSP_AUDIODSP>;
<&topckgen 163>, //CLK_TOP_APLL1
<&topckgen 166>, //CLK_TOP_APLL2
<&topckgen 233>, //CLK_TOP_APLL12_DIV0
<&topckgen 234>, //CLK_TOP_APLL12_DIV1
<&topckgen 235>, //CLK_TOP_APLL12_DIV2
<&topckgen 236>, //CLK_TOP_APLL12_DIV3
<&topckgen 238>, //CLK_TOP_APLL12_DIV9
<&topckgen 100>, //CLK_TOP_A1SYS_HP_SEL
<&topckgen 33>, //CLK_TOP_AUD_INTBUS_SEL
<&topckgen 34>, //CLK_TOP_AUDIO_H_SEL
<&topckgen 107>, //CLK_TOP_AUDIO_LOCAL_BUS_SEL
<&topckgen 98>, //CLK_TOP_DPTX_M_SEL
<&topckgen 94>, //CLK_TOP_I2SO1_M_SEL
<&topckgen 95>, //CLK_TOP_I2SO2_M_SEL
<&topckgen 96>, //CLK_TOP_I2SI1_M_SEL
<&topckgen 97>, //CLK_TOP_I2SI2_M_SEL
<&infracfg_ao 50>, //CLK_INFRA_AO_AUDIO_26M_B
<&scp_adsp 0>; //CLK_SCP_ADSP_AUDIODSP
clock-names = "clk26m",
"apll1_ck",
"apll2_ck",

6
Documentation/devicetree/bindings/spi/omap-spi.yaml
View File

@ -84,9 +84,9 @@ unevaluatedProperties: false
if:
properties:
compatible:
oneOf:
- const: ti,omap2-mcspi
- const: ti,omap4-mcspi
enum:
- ti,omap2-mcspi
- ti,omap4-mcspi
then:
properties:

2
Documentation/devicetree/bindings/spi/spi-xilinx.yaml
View File

@ -27,13 +27,11 @@ properties:
xlnx,num-ss-bits:
description: Number of chip selects used.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 32
xlnx,num-transfer-bits:
description: Number of bits per transfer. This will be 8 if not specified.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [8, 16, 32]
default: 8

82
Documentation/devicetree/bindings/thermal/qcom-lmh.yaml Normal file
View File

@ -0,0 +1,82 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright 2021 Linaro Ltd.
%YAML 1.2
---
$id: http://devicetree.org/schemas/thermal/qcom-lmh.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Limits Management Hardware(LMh)
maintainers:
- Thara Gopinath <thara.gopinath@linaro.org>
description:
Limits Management Hardware(LMh) is a hardware infrastructure on some
Qualcomm SoCs that can enforce temperature and current limits as
programmed by software for certain IPs like CPU.
properties:
compatible:
enum:
- qcom,sdm845-lmh
reg:
items:
- description: core registers
interrupts:
maxItems: 1
'#interrupt-cells':
const: 1
interrupt-controller: true
cpus:
description:
phandle of the first cpu in the LMh cluster
$ref: /schemas/types.yaml#/definitions/phandle
qcom,lmh-temp-arm-millicelsius:
description:
An integer expressing temperature threshold at which the LMh thermal
FSM is engaged.
qcom,lmh-temp-low-millicelsius:
description:
An integer expressing temperature threshold at which the state machine
will attempt to remove frequency throttling.
qcom,lmh-temp-high-millicelsius:
description:
An integer expressing temperature threshold at which the state machine
will attempt to throttle the frequency.
required:
- compatible
- reg
- interrupts
- '#interrupt-cells'
- interrupt-controller
- cpus
- qcom,lmh-temp-arm-millicelsius
- qcom,lmh-temp-low-millicelsius
- qcom,lmh-temp-high-millicelsius
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
lmh@17d70800 {
compatible = "qcom,sdm845-lmh";
reg = <0x17d70800 0x400>;
interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
cpus = <&CPU4>;
qcom,lmh-temp-arm-millicelsius = <65000>;
qcom,lmh-temp-low-millicelsius = <94500>;
qcom,lmh-temp-high-millicelsius = <95000>;
interrupt-controller;
#interrupt-cells = <1>;
};

2
Documentation/devicetree/bindings/thermal/thermal-zones.yaml
View File

@ -215,7 +215,7 @@ patternProperties:
- polling-delay
- polling-delay-passive
- thermal-sensors
- trips
additionalProperties: false
additionalProperties: false

3
Documentation/devicetree/bindings/virtio/mmio.yaml
View File

@ -36,7 +36,8 @@ required:
- reg
- interrupts
additionalProperties: false
additionalProperties:
type: object
examples:
- |

41
Documentation/devicetree/bindings/virtio/virtio-device.yaml Normal file
View File

@ -0,0 +1,41 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/virtio/virtio-device.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Virtio device bindings
maintainers:
- Viresh Kumar <viresh.kumar@linaro.org>
description:
These bindings are applicable to virtio devices irrespective of the bus they
are bound to, like mmio or pci.
# We need a select here so we don't match all nodes with 'virtio,mmio'
properties:
compatible:
pattern: "^virtio,device[0-9a-f]{1,8}$"
description: Virtio device nodes.
"virtio,deviceID", where ID is the virtio device id. The textual
representation of ID shall be in lower case hexadecimal with leading
zeroes suppressed.
required:
- compatible
additionalProperties: true
examples:
- |
virtio@3000 {
compatible = "virtio,mmio";
reg = <0x3000 0x100>;
interrupts = <43>;
i2c {
compatible = "virtio,device22";
};
};
...

14
Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml
View File

@ -15,13 +15,13 @@ maintainers:
properties:
compatible:
oneOf:
- const: maxim,max6369
- const: maxim,max6370
- const: maxim,max6371
- const: maxim,max6372
- const: maxim,max6373
- const: maxim,max6374
enum:
- maxim,max6369
- maxim,max6370
- maxim,max6371
- maxim,max6372
- maxim,max6373
- maxim,max6374
reg:
description: This is a 1-byte memory-mapped address

8
Documentation/driver-api/cxl/memory-devices.rst
View File

@ -36,9 +36,15 @@ CXL Core
.. kernel-doc:: drivers/cxl/cxl.h
:internal:
.. kernel-doc:: drivers/cxl/core.c
.. kernel-doc:: drivers/cxl/core/bus.c
:doc: cxl core
.. kernel-doc:: drivers/cxl/core/pmem.c
:doc: cxl pmem
.. kernel-doc:: drivers/cxl/core/regs.c
:doc: cxl registers
External Interfaces
===================

2
Documentation/features/vm/ELF-ASLR/arch-support.txt
View File

@ -22,7 +22,7 @@
| openrisc: | TODO |
| parisc: | ok |
| powerpc: | ok |
| riscv: | TODO |
| riscv: | ok |
| s390: | ok |
| sh: | TODO |
| sparc: | TODO |

2
Documentation/features/vm/huge-vmap/arch-support.txt
View File

@ -1,7 +1,7 @@
#
# Feature name: huge-vmap
# Kconfig: HAVE_ARCH_HUGE_VMAP
# description: arch supports the ioremap_pud_enabled() and ioremap_pmd_enabled() VM APIs
# description: arch supports the arch_vmap_pud_supported() and arch_vmap_pmd_supported() VM APIs
#
-----------------------
| arch |status|

3
Documentation/filesystems/api-summary.rst
View File

@ -71,9 +71,6 @@ Other Functions
.. kernel-doc:: fs/fs-writeback.c
:export:
.. kernel-doc:: fs/block_dev.c
:export:
.. kernel-doc:: fs/anon_inodes.c
:export:

2
Documentation/gpu/drm-mm.rst
View File

@ -37,7 +37,7 @@ TTM initialization
This section is outdated.
Drivers wishing to support TTM must pass a filled :c:type:`ttm_bo_driver
<ttm_bo_driver>` structure to ttm_bo_device_init, together with an
<ttm_bo_driver>` structure to ttm_device_init, together with an
initialized global reference to the memory manager. The ttm_bo_driver
structure contains several fields with function pointers for
initializing the TTM, allocating and freeing memory, waiting for command

5
Documentation/kbuild/llvm.rst
View File

@ -130,9 +130,10 @@ Getting Help
------------
- `Website <https://clangbuiltlinux.github.io/>`_
- `Mailing List <https://groups.google.com/forum/#!forum/clang-built-linux>`_: <clang-built-linux@googlegroups.com>
- `Mailing List <https://lore.kernel.org/llvm/>`_: <llvm@lists.linux.dev>
- `Old Mailing List Archives <https://groups.google.com/g/clang-built-linux>`_
- `Issue Tracker <https://github.com/ClangBuiltLinux/linux/issues>`_
- IRC: #clangbuiltlinux on chat.freenode.net
- IRC: #clangbuiltlinux on irc.libera.chat
- `Telegram <https://t.me/ClangBuiltLinux>`_: @ClangBuiltLinux
- `Wiki <https://github.com/ClangBuiltLinux/linux/wiki>`_
- `Beginner Bugs <https://github.com/ClangBuiltLinux/linux/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22>`_

4
Documentation/kernel-hacking/hacking.rst
View File

@ -76,8 +76,8 @@ handler is never re-entered: if the same interrupt arrives, it is queued
fast: frequently it simply acknowledges the interrupt, marks a 'software
interrupt' for execution and exits.
You can tell you are in a hardware interrupt, because
:c:func:`in_irq()` returns true.
You can tell you are in a hardware interrupt, because in_hardirq() returns
true.
.. warning::

12
Documentation/kernel-hacking/locking.rst
View File

@ -94,16 +94,10 @@ primitives, but I'll pretend they don't exist.
Locking in the Linux Kernel
===========================
If I could give you one piece of advice: never sleep with anyone crazier
than yourself. But if I had to give you advice on locking: **keep it
simple**.
If I could give you one piece of advice on locking: **keep it simple**.
Be reluctant to introduce new locks.
Strangely enough, this last one is the exact reverse of my advice when
you **have** slept with someone crazier than yourself. And you should
think about getting a big dog.
Two Main Types of Kernel Locks: Spinlocks and Mutexes
-----------------------------------------------------
@ -1406,7 +1400,7 @@ bh
half will be running at any time.
Hardware Interrupt / Hardware IRQ
Hardware interrupt request. in_irq() returns true in a
Hardware interrupt request. in_hardirq() returns true in a
hardware interrupt handler.
Interrupt Context
@ -1418,7 +1412,7 @@ SMP
(``CONFIG_SMP=y``).
Software Interrupt / softirq
Software interrupt handler. in_irq() returns false;
Software interrupt handler. in_hardirq() returns false;
in_softirq() returns true. Tasklets and softirqs both
fall into the category of 'software interrupts'.

2
Documentation/locking/futex-requeue-pi.rst
View File

@ -5,7 +5,7 @@ Futex Requeue PI
Requeueing of tasks from a non-PI futex to a PI futex requires
special handling in order to ensure the underlying rt_mutex is never
left without an owner if it has waiters; doing so would break the PI
boosting logic [see rt-mutex-desgin.txt] For the purposes of
boosting logic [see rt-mutex-design.rst] For the purposes of
brevity, this action will be referred to as "requeue_pi" throughout
this document. Priority inheritance is abbreviated throughout as
"PI".

2
Documentation/locking/ww-mutex-design.rst
View File

@ -2,7 +2,7 @@
Wound/Wait Deadlock-Proof Mutex Design
======================================
Please read mutex-design.txt first, as it applies to wait/wound mutexes too.
Please read mutex-design.rst first, as it applies to wait/wound mutexes too.
Motivation for WW-Mutexes
-------------------------

15
Documentation/power/energy-model.rst
View File

@ -101,8 +101,7 @@ subsystems which use EM might rely on this flag to check if all EM devices use
the same scale. If there are different scales, these subsystems might decide
to: return warning/error, stop working or panic.
See Section 3. for an example of driver implementing this
callback, and kernel/power/energy_model.c for further documentation on this
API.
callback, or Section 2.4 for further documentation on this API
2.3 Accessing performance domains
@ -123,7 +122,17 @@ em_cpu_energy() API. The estimation is performed assuming that the schedutil
CPUfreq governor is in use in case of CPU device. Currently this calculation is
not provided for other type of devices.
More details about the above APIs can be found in include/linux/energy_model.h.
More details about the above APIs can be found in ``<linux/energy_model.h>``
or in Section 2.4
2.4 Description details of this API
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. kernel-doc:: include/linux/energy_model.h
:internal:
.. kernel-doc:: kernel/power/energy_model.c
:export:
3. Example driver

2
Documentation/process/applying-patches.rst
View File

@ -389,7 +389,7 @@ The -mm patches are experimental patches released by Andrew Morton.
In the past, -mm tree were used to also test subsystem patches, but this
function is now done via the
`linux-next <https://www.kernel.org/doc/man-pages/linux-next.html>`
`linux-next` (https://www.kernel.org/doc/man-pages/linux-next.html)
tree. The Subsystem maintainers push their patches first to linux-next,
and, during the merge window, sends them directly to Linus.

2
Documentation/process/changes.rst
View File

@ -29,7 +29,7 @@ you probably needn't concern yourself with pcmciautils.
====================== =============== ========================================
Program Minimal version Command to check the version
====================== =============== ========================================
GNU C 4.9 gcc --version
GNU C 5.1 gcc --version
Clang/LLVM (optional) 10.0.1 clang --version
GNU make 3.81 make --version
binutils 2.23 ld -v

14
Documentation/process/kernel-docs.rst
View File

@ -126,15 +126,17 @@ On-line docs
describes how to write user-mode utilities for communicating with
Card Services.
* Title: **Linux Kernel Module Programming Guide**
* Title: **The Linux Kernel Module Programming Guide**
:Author: Ori Pomerantz.
:URL: https://tldp.org/LDP/lkmpg/2.6/html/index.html
:Date: 2001
:Author: Peter Jay Salzman, Michael Burian, Ori Pomerantz, Bob Mottram,
Jim Huang.
:URL: https://sysprog21.github.io/lkmpg/
:Date: 2021
:Keywords: modules, GPL book, /proc, ioctls, system calls,
interrupt handlers .
:Description: Very nice 92 pages GPL book on the topic of modules
programming. Lots of examples.
:Description: A very nice GPL book on the topic of modules
programming. Lots of examples. Currently the new version is being
actively maintained at https://github.com/sysprog21/lkmpg.
* Title: **Global spinlock list and usage**

14
Documentation/process/maintainer-pgp-guide.rst
View File

@ -944,12 +944,11 @@ have on your keyring::
uid [ unknown] Linus Torvalds <torvalds@kernel.org>
sub rsa2048 2011-09-20 [E]
Next, open the `PGP pathfinder`_. In the "From" field, paste the key
fingerprint of Linus Torvalds from the output above. In the "To" field,
paste the key-id you found via ``gpg --search`` of the unknown key, and
check the results:
- `Finding paths to Linus`_
Next, find a trust path from Linus Torvalds to the key-id you found via ``gpg
--search`` of the unknown key. For this, you can use several tools including
https://github.com/mricon/wotmate,
https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/graphs, and
https://the.earth.li/~noodles/pathfind.html.
If you get a few decent trust paths, then it's a pretty good indication
that it is a valid key. You can add it to your keyring from the
@ -962,6 +961,3 @@ administrators of the PGP Pathfinder service to not be malicious (in
fact, this goes against :ref:`devs_not_infra`). However, if you
do not carefully maintain your own web of trust, then it is a marked
improvement over blindly trusting keyservers.
.. _`PGP pathfinder`: https://pgp.cs.uu.nl/
.. _`Finding paths to Linus`: https://pgp.cs.uu.nl/paths/79BE3E4300411886/to/C94035C21B4F2AEB.html

2
Documentation/translations/it_IT/kernel-hacking/hacking.rst
View File

@ -90,7 +90,7 @@ i gestori d'interruzioni devono essere veloci: spesso si limitano
esclusivamente a notificare la presa in carico dell'interruzione,
programmare una 'interruzione software' per l'esecuzione e quindi terminare.
Potete dire d'essere in una interruzione hardware perché :c:func:`in_irq()`
Potete dire d'essere in una interruzione hardware perché in_hardirq()
ritorna vero.
.. warning::

4
Documentation/translations/it_IT/kernel-hacking/locking.rst
View File

@ -1459,11 +1459,11 @@ contesto utente
che hardware.
interruzione hardware
Richiesta di interruzione hardware. in_irq() ritorna vero in un
Richiesta di interruzione hardware. in_hardirq() ritorna vero in un
gestore d'interruzioni hardware.
interruzione software / softirq
Gestore di interruzioni software: in_irq() ritorna falso;
Gestore di interruzioni software: in_hardirq() ritorna falso;
in_softirq() ritorna vero. I tasklet e le softirq sono entrambi
considerati 'interruzioni software'.

2
Documentation/translations/zh_CN/admin-guide/README.rst
View File

@ -223,7 +223,7 @@ Linux内核5.x版本 <http://kernel.org/>
编译内核
---------
- 确保您至少有gcc 4.9可用。
- 确保您至少有gcc 5.1可用。
有关更多信息，请参阅 :ref:`Documentation/process/changes.rst <changes>` 。
请注意，您仍然可以使用此内核运行a.out用户程序。

2
Documentation/translations/zh_CN/core-api/cachetlb.rst
View File

@ -80,7 +80,7 @@ cpu上对这个地址空间进行刷新。
5) ``void update_mmu_cache(struct vm_area_struct *vma,
unsigned long address, pte_t *ptep)``
在每个页面故障结束时，这个程序被调用，以告诉体系结构特定的代码，在
在每个缺页异常结束时，这个程序被调用，以告诉体系结构特定的代码，在
软件页表中，在地址空间“vma->vm_mm”的虚拟地址“地址”处，现在存在
一个翻译。

8
Documentation/translations/zh_CN/core-api/index.rst
View File

@ -1,11 +1,13 @@
.. include:: ../disclaimer-zh_CN.rst
:Original: :doc:`../../../core-api/irq/index`
:Translator: Yanteng Si <siyanteng@loongson.cn>
:Original: Documentation/core-api/index.rst
:翻译:
司延腾 Yanteng Si <siyanteng@loongson.cn>
.. _cn_core-api_index.rst:
===========
核心API文档
===========

8
Documentation/translations/zh_CN/core-api/irq/concepts.rst
View File

@ -1,11 +1,13 @@
.. include:: ../../disclaimer-zh_CN.rst
:Original: :doc:`../../../../core-api/irq/concepts`
:Translator: Yanteng Si <siyanteng@loongson.cn>
:Original: Documentation/core-api/irq/concepts.rst
:翻译:
司延腾 Yanteng Si <siyanteng@loongson.cn>
.. _cn_concepts.rst:
===========
什么是IRQ？
===========

7
Documentation/translations/zh_CN/core-api/irq/index.rst
View File

@ -1,7 +1,10 @@
.. include:: ../../disclaimer-zh_CN.rst
:Original: :doc:`../../../../core-api/irq/index`
:Translator: Yanteng Si <siyanteng@loongson.cn>
:Original: Documentation/core-api/irq/index.rst
:翻译:
司延腾 Yanteng Si <siyanteng@loongson.cn>
.. _cn_irq_index.rst:

8
Documentation/translations/zh_CN/core-api/irq/irq-affinity.rst
View File

@ -1,11 +1,13 @@
.. include:: ../../disclaimer-zh_CN.rst
:Original: :doc:`../../../../core-api/irq/irq-affinity`
:Translator: Yanteng Si <siyanteng@loongson.cn>
:Original: Documentation/core-api/irq/irq-affinity
:翻译:
司延腾 Yanteng Si <siyanteng@loongson.cn>
.. _cn_irq-affinity.rst:
==============
SMP IRQ 亲和性
==============

8
Documentation/translations/zh_CN/core-api/irq/irq-domain.rst
View File

@ -1,11 +1,13 @@
.. include:: ../../disclaimer-zh_CN.rst
:Original: :doc:`../../../../core-api/irq/irq-domain`
:Translator: Yanteng Si <siyanteng@loongson.cn>
:Original: Documentation/core-api/irq/irq-domain.rst
:翻译:
司延腾 Yanteng Si <siyanteng@loongson.cn>
.. _cn_irq-domain.rst:
=======================
irq_domain 中断号映射库
=======================

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