UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge remote-tracking branch 'torvalds/master' into perf/core 

To pick up fixes.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This commit is contained in:
Arnaldo Carvalho de Melo 2021-06-30 15:27:32 -03:00
parent 51f382428c 007b350a58
commit 857286e4c5
2684 changed files with 80284 additions and 93922 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.mailmap
View File

@ -102,6 +102,7 @@ Felipe W Damasio <felipewd@terra.com.br>
Felix Kuhling <fxkuehl@gmx.de>
Felix Moeller <felix@derklecks.de>
Filipe Lautert <filipe@icewall.org>
Finn Thain <fthain@linux-m68k.org> <fthain@telegraphics.com.au>
Franck Bui-Huu <vagabon.xyz@gmail.com>
Frank Rowand <frowand.list@gmail.com> <frank.rowand@am.sony.com>
Frank Rowand <frowand.list@gmail.com> <frank.rowand@sonymobile.com>
@ -212,6 +213,8 @@ Manivannan Sadhasivam <mani@kernel.org> <manivannanece23@gmail.com>
Manivannan Sadhasivam <mani@kernel.org> <manivannan.sadhasivam@linaro.org>
Marcin Nowakowski <marcin.nowakowski@mips.com> <marcin.nowakowski@imgtec.com>
Marc Zyngier <maz@kernel.org> <marc.zyngier@arm.com>
Marek Behún <kabel@kernel.org> <marek.behun@nic.cz>
Marek Behún <kabel@kernel.org> Marek Behun <marek.behun@nic.cz>
Mark Brown <broonie@sirena.org.uk>
Mark Starovoytov <mstarovo@pm.me> <mstarovoitov@marvell.com>
Mark Yao <markyao0591@gmail.com> <mark.yao@rock-chips.com>

2
Documentation/ABI/obsolete/sysfs-cpuidle
View File

@ -6,4 +6,4 @@ Description:
with the update that cpuidle governor can be changed at runtime in default,
both current_governor and current_governor_ro co-exist under
/sys/devices/system/cpu/cpuidle/ file, it's duplicate so make
current_governor_ro obselete.
current_governor_ro obsolete.

2
Documentation/ABI/removed/sysfs-kernel-uids
View File

@ -5,7 +5,7 @@ Contact: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Description:
The /sys/kernel/uids/<uid>/cpu_shares tunable is used
to set the cpu bandwidth a user is allowed. This is a
propotional value. What that means is that if there
proportional value. What that means is that if there
are two users logged in, each with an equal number of
shares, then they will get equal CPU bandwidth. Another
example would be, if User A has shares = 1024 and user

2
Documentation/ABI/stable/sysfs-bus-vmbus
View File

@ -61,7 +61,7 @@ Date: September. 2017
KernelVersion: 4.14
Contact: Stephen Hemminger <sthemmin@microsoft.com>
Description: Directory for per-channel information
NN is the VMBUS relid associtated with the channel.
NN is the VMBUS relid associated with the channel.
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/cpu
Date: September. 2017

2
Documentation/ABI/stable/sysfs-bus-xen-backend
View File

@ -19,7 +19,7 @@ Date: April 2011
KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
The major:minor number (in hexidecimal) of the
The major:minor number (in hexadecimal) of the
physical device providing the storage for this backend
block device.

83
Documentation/ABI/stable/sysfs-devices-system-cpu
View File

@ -23,3 +23,86 @@ Description: Default value for the Data Stream Control Register (DSCR) on
here).
If set by a process it will be inherited by child processes.
Values: 64 bit unsigned integer (bit field)
What: /sys/devices/system/cpu/cpuX/topology/physical_package_id
Description: physical package id of cpuX. Typically corresponds to a physical
socket number, but the actual value is architecture and platform
dependent.
Values: integer
What: /sys/devices/system/cpu/cpuX/topology/die_id
Description: the CPU die ID of cpuX. Typically it is the hardware platform's
identifier (rather than the kernel's). The actual value is
architecture and platform dependent.
Values: integer
What: /sys/devices/system/cpu/cpuX/topology/core_id
Description: the CPU core ID of cpuX. Typically it is the hardware platform's
identifier (rather than the kernel's). The actual value is
architecture and platform dependent.
Values: integer
What: /sys/devices/system/cpu/cpuX/topology/book_id
Description: the book ID of cpuX. Typically it is the hardware platform's
identifier (rather than the kernel's). The actual value is
architecture and platform dependent. it's only used on s390.
Values: integer
What: /sys/devices/system/cpu/cpuX/topology/drawer_id
Description: the drawer ID of cpuX. Typically it is the hardware platform's
identifier (rather than the kernel's). The actual value is
architecture and platform dependent. it's only used on s390.
Values: integer
What: /sys/devices/system/cpu/cpuX/topology/core_cpus
Description: internal kernel map of CPUs within the same core.
(deprecated name: "thread_siblings")
Values: hexadecimal bitmask.
What: /sys/devices/system/cpu/cpuX/topology/core_cpus_list
Description: human-readable list of CPUs within the same core.
The format is like 0-3, 8-11, 14,17.
(deprecated name: "thread_siblings_list").
Values: decimal list.
What: /sys/devices/system/cpu/cpuX/topology/package_cpus
Description: internal kernel map of the CPUs sharing the same physical_package_id.
(deprecated name: "core_siblings").
Values: hexadecimal bitmask.
What: /sys/devices/system/cpu/cpuX/topology/package_cpus_list
Description: human-readable list of CPUs sharing the same physical_package_id.
The format is like 0-3, 8-11, 14,17.
(deprecated name: "core_siblings_list")
Values: decimal list.
What: /sys/devices/system/cpu/cpuX/topology/die_cpus
Description: internal kernel map of CPUs within the same die.
Values: hexadecimal bitmask.
What: /sys/devices/system/cpu/cpuX/topology/die_cpus_list
Description: human-readable list of CPUs within the same die.
The format is like 0-3, 8-11, 14,17.
Values: decimal list.
What: /sys/devices/system/cpu/cpuX/topology/book_siblings
Description: internal kernel map of cpuX's hardware threads within the same
book_id. it's only used on s390.
Values: hexadecimal bitmask.
What: /sys/devices/system/cpu/cpuX/topology/book_siblings_list
Description: human-readable list of cpuX's hardware threads within the same
book_id.
The format is like 0-3, 8-11, 14,17. it's only used on s390.
Values: decimal list.
What: /sys/devices/system/cpu/cpuX/topology/drawer_siblings
Description: internal kernel map of cpuX's hardware threads within the same
drawer_id. it's only used on s390.
Values: hexadecimal bitmask.
What: /sys/devices/system/cpu/cpuX/topology/drawer_siblings_list
Description: human-readable list of cpuX's hardware threads within the same
drawer_id.
The format is like 0-3, 8-11, 14,17. it's only used on s390.
Values: decimal list.

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

@ -173,7 +173,7 @@ What: /sys/bus/dsa/devices/wq<m>.<n>/priority
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The priority value of this work queue, it is a vlue relative to
Description: The priority value of this work queue, it is a value relative to
other work queue in the same group to control quality of service
for dispatching work from multiple workqueues in the same group.

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

@ -137,7 +137,7 @@ Contact: Vadim Pasternak <vadimpmellanox.com>
Description: These files show the system reset cause, as following:
COMEX thermal shutdown; wathchdog power off or reset was derived
by one of the next components: COMEX, switch board or by Small Form
Factor mezzanine, reset requested from ASIC, reset cuased by BIOS
Factor mezzanine, reset requested from ASIC, reset caused by BIOS
reload. Value 1 in file means this is reset cause, 0 - otherwise.
Only one of the above causes could be 1 at the same time, representing
only last reset cause.
@ -183,7 +183,7 @@ What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/vpd_wp
Date: January 2020
KernelVersion: 5.6
Contact: Vadim Pasternak <vadimpmellanox.com>
Description: This file allows to overwrite system VPD hardware wrtie
Description: This file allows to overwrite system VPD hardware write
protection when attribute is set 1.
The file is read/write.

2
Documentation/ABI/testing/configfs-iio
View File

@ -31,4 +31,4 @@ Date: April 2016
KernelVersion: 4.7
Description:
Dummy IIO devices directory. Creating a directory here will result
in creating a dummy IIO device in the IIO subystem.
in creating a dummy IIO device in the IIO subsystem.

8
Documentation/ABI/testing/configfs-most
View File

@ -20,7 +20,7 @@ Description:
subbuffer_size
configure the sub-buffer size for this channel
(needed for synchronous and isochrnous data)
(needed for synchronous and isochronous data)
num_buffers
@ -75,7 +75,7 @@ Description:
subbuffer_size
configure the sub-buffer size for this channel
(needed for synchronous and isochrnous data)
(needed for synchronous and isochronous data)
num_buffers
@ -130,7 +130,7 @@ Description:
subbuffer_size
configure the sub-buffer size for this channel
(needed for synchronous and isochrnous data)
(needed for synchronous and isochronous data)
num_buffers
@ -196,7 +196,7 @@ Description:
subbuffer_size
configure the sub-buffer size for this channel
(needed for synchronous and isochrnous data)
(needed for synchronous and isochronous data)
num_buffers

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

@ -137,7 +137,7 @@ Description:
This group contains "OS String" extension handling attributes.
============= ===============================================
use flag turning "OS Desctiptors" support on/off
use flag turning "OS Descriptors" support on/off
b_vendor_code one-byte value used for custom per-device and
per-interface requests
qw_sign an identifier to be reported as "OS String"

4
Documentation/ABI/testing/configfs-usb-gadget-uvc
View File

@ -170,7 +170,7 @@ Description: Default color matching descriptors
bMatrixCoefficients matrix used to compute luma and
chroma values from the color primaries
bTransferCharacteristics optoelectronic transfer
characteristic of the source picutre,
characteristic of the source picture,
also called the gamma function
bColorPrimaries color primaries and the reference
white
@ -311,7 +311,7 @@ Description: Specific streaming header descriptors
a hardware trigger interrupt event
bTriggerSupport flag specifying if hardware
triggering is supported
bStillCaptureMethod method of still image caputre
bStillCaptureMethod method of still image capture
supported
bTerminalLink id of the output terminal to which
the video endpoint of this interface

2
Documentation/ABI/testing/debugfs-driver-genwqe
View File

@ -31,7 +31,7 @@ What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_regs
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Dump of the error registers before the last reset of
the card occured.
the card occurred.
Only available for PF.
What: /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid0

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

@ -153,7 +153,7 @@ KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Triggers an I2C transaction that is generated by the device's
CPU. Writing to this file generates a write transaction while
reading from the file generates a read transcation
reading from the file generates a read transaction
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_reg
Date: Jan 2019

36
Documentation/ABI/testing/evm
View File

@ -24,7 +24,7 @@ Description:
1 Enable digital signature validation
2 Permit modification of EVM-protected metadata at
runtime. Not supported if HMAC validation and
creation is enabled.
creation is enabled (deprecated).
31 Disable further runtime modification of EVM policy
=== ==================================================
@ -47,10 +47,38 @@ Description:
will enable digital signature validation, permit
modification of EVM-protected metadata and
disable all further modification of policy
disable all further modification of policy. This option is now
deprecated in favor of::
Note that once a key has been loaded, it will no longer be
possible to enable metadata modification.
echo 0x80000002 ><securityfs>/evm
as the outstanding issues that prevent the usage of EVM portable
signatures have been solved.
Echoing a value is additive, the new value is added to the
existing initialization flags.
For example, after::
echo 2 ><securityfs>/evm
another echo can be performed::
echo 1 ><securityfs>/evm
and the resulting value will be 3.
Note that once an HMAC key has been loaded, it will no longer
be possible to enable metadata modification. Signaling that an
HMAC key has been loaded will clear the corresponding flag.
For example, if the current value is 6 (2 and 4 set)::
echo 1 ><securityfs>/evm
will set the new value to 3 (4 cleared).
Loading an HMAC key is the only way to disable metadata
modification.
Until key loading has been signaled EVM can not create
or validate the 'security.evm' xattr, but returns

2
Documentation/ABI/testing/sysfs-bus-fsi
View File

@ -12,7 +12,7 @@ KernelVersion: 4.12
Contact: linux-fsi@lists.ozlabs.org
Description:
Sends an FSI BREAK command on a master's communication
link to any connnected slaves. A BREAK resets connected
link to any connected slaves. A BREAK resets connected
device's logic and preps it to receive further commands
from the master.

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

@ -786,7 +786,7 @@ What: /sys/.../events/in_capacitanceY_adaptive_thresh_rising_en
What: /sys/.../events/in_capacitanceY_adaptive_thresh_falling_en
KernelVersion: 5.13
Contact: linux-iio@vger.kernel.org
Descrption:
Description:
Adaptive thresholds are similar to normal fixed thresholds
but the value is expressed as an offset from a value which
provides a low frequency approximation of the channel itself.
@ -798,10 +798,10 @@ What: /sys/.../in_capacitanceY_adaptive_thresh_rising_timeout
What: /sys/.../in_capacitanceY_adaptive_thresh_falling_timeout
KernelVersion: 5.11
Contact: linux-iio@vger.kernel.org
Descrption:
Description:
When adaptive thresholds are used, the tracking signal
may adjust too slowly to step changes in the raw signal.
*_timeout (in seconds) specifies a time for which the
Thus these specify the time in seconds for which the
difference between the slow tracking signal and the raw
signal is allowed to remain out-of-range before a reset
event occurs in which the tracking signal is made equal

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

@ -139,8 +139,8 @@ Description:
binary file containing the Vital Product Data for the
device. It should follow the VPD format defined in
PCI Specification 2.1 or 2.2, but users should consider
that some devices may have malformatted data. If the
underlying VPD has a writable section then the
that some devices may have incorrectly formatted data.
If the underlying VPD has a writable section then the
corresponding section of this file will be writable.
What: /sys/bus/pci/devices/.../virtfnN

100
Documentation/ABI/testing/sysfs-class-backlight
View File

@ -84,3 +84,103 @@ Description:
It can be enabled by writing the value stored in
/sys/class/backlight/<backlight>/max_brightness to
/sys/class/backlight/<backlight>/brightness.
What: /sys/class/backlight/<backlight>/<ambient light zone>_max
Date: Sep, 2009
KernelVersion: v2.6.32
Contact: device-drivers-devel@blackfin.uclinux.org
Description:
Control the maximum brightness for <ambient light zone>
on this <backlight>. Values are between 0 and 127. This file
will also show the brightness level stored for this
<ambient light zone>.
The <ambient light zone> is device-driver specific:
For ADP5520 and ADP5501, <ambient light zone> can be:
=========== ================================================
Ambient sysfs entry
light zone
=========== ================================================
daylight /sys/class/backlight/<backlight>/daylight_max
office /sys/class/backlight/<backlight>/office_max
dark /sys/class/backlight/<backlight>/dark_max
=========== ================================================
For ADP8860, <ambient light zone> can be:
=========== ================================================
Ambient sysfs entry
light zone
=========== ================================================
l1_daylight /sys/class/backlight/<backlight>/l1_daylight_max
l2_office /sys/class/backlight/<backlight>/l2_office_max
l3_dark /sys/class/backlight/<backlight>/l3_dark_max
=========== ================================================
For ADP8870, <ambient light zone> can be:
=========== ================================================
Ambient sysfs entry
light zone
=========== ================================================
l1_daylight /sys/class/backlight/<backlight>/l1_daylight_max
l2_bright /sys/class/backlight/<backlight>/l2_bright_max
l3_office /sys/class/backlight/<backlight>/l3_office_max
l4_indoor /sys/class/backlight/<backlight>/l4_indoor_max
l5_dark /sys/class/backlight/<backlight>/l5_dark_max
=========== ================================================
See also: /sys/class/backlight/<backlight>/ambient_light_zone.
What: /sys/class/backlight/<backlight>/<ambient light zone>_dim
Date: Sep, 2009
KernelVersion: v2.6.32
Contact: device-drivers-devel@blackfin.uclinux.org
Description:
Control the dim brightness for <ambient light zone>
on this <backlight>. Values are between 0 and 127, typically
set to 0. Full off when the backlight is disabled.
This file will also show the dim brightness level stored for
this <ambient light zone>.
The <ambient light zone> is device-driver specific:
For ADP5520 and ADP5501, <ambient light zone> can be:
=========== ================================================
Ambient sysfs entry
light zone
=========== ================================================
daylight /sys/class/backlight/<backlight>/daylight_dim
office /sys/class/backlight/<backlight>/office_dim
dark /sys/class/backlight/<backlight>/dark_dim
=========== ================================================
For ADP8860, <ambient light zone> can be:
=========== ================================================
Ambient sysfs entry
light zone
=========== ================================================
l1_daylight /sys/class/backlight/<backlight>/l1_daylight_dim
l2_office /sys/class/backlight/<backlight>/l2_office_dim
l3_dark /sys/class/backlight/<backlight>/l3_dark_dim
=========== ================================================
For ADP8870, <ambient light zone> can be:
=========== ================================================
Ambient sysfs entry
light zone
=========== ================================================
l1_daylight /sys/class/backlight/<backlight>/l1_daylight_dim
l2_bright /sys/class/backlight/<backlight>/l2_bright_dim
l3_office /sys/class/backlight/<backlight>/l3_office_dim
l4_indoor /sys/class/backlight/<backlight>/l4_indoor_dim
l5_dark /sys/class/backlight/<backlight>/l5_dark_dim
=========== ================================================
See also: /sys/class/backlight/<backlight>/ambient_light_zone.

31
Documentation/ABI/testing/sysfs-class-backlight-adp5520
View File

@ -1,31 +0,0 @@
sysfs interface for analog devices adp5520(01) backlight driver
---------------------------------------------------------------
The backlight brightness control operates at three different levels for the
adp5520 and adp5501 devices: daylight (level 1), office (level 2) and dark
(level 3). By default the brightness operates at the daylight brightness level.
What: /sys/class/backlight/<backlight>/daylight_max
What: /sys/class/backlight/<backlight>/office_max
What: /sys/class/backlight/<backlight>/dark_max
Date: Sep, 2009
KernelVersion: v2.6.32
Contact: Michael Hennerich <michael.hennerich@analog.com>
Description:
(RW) Maximum current setting for the backlight when brightness
is at one of the three levels (daylight, office or dark). This
is an input code between 0 and 127, which is transformed to a
value between 0 mA and 30 mA using linear or non-linear
algorithms.
What: /sys/class/backlight/<backlight>/daylight_dim
What: /sys/class/backlight/<backlight>/office_dim
What: /sys/class/backlight/<backlight>/dark_dim
Date: Sep, 2009
KernelVersion: v2.6.32
Contact: Michael Hennerich <michael.hennerich@analog.com>
Description:
(RW) Dim current setting for the backlight when brightness is at
one of the three levels (daylight, office or dark). This is an
input code between 0 and 127, which is transformed to a value
between 0 mA and 30 mA using linear or non-linear algorithms.

37
Documentation/ABI/testing/sysfs-class-backlight-adp8860
View File

@ -1,37 +0,0 @@
sysfs interface for analog devices adp8860 backlight driver
-----------------------------------------------------------
The backlight brightness control operates at three different levels for the
adp8860, adp8861 and adp8863 devices: daylight (level 1), office (level 2) and
dark (level 3). By default the brightness operates at the daylight brightness
level.
See also /sys/class/backlight/<backlight>/ambient_light_level and
/sys/class/backlight/<backlight>/ambient_light_zone.
What: /sys/class/backlight/<backlight>/l1_daylight_max
What: /sys/class/backlight/<backlight>/l2_office_max
What: /sys/class/backlight/<backlight>/l3_dark_max
Date: Apr, 2010
KernelVersion: v2.6.35
Contact: Michael Hennerich <michael.hennerich@analog.com>
Description:
(RW) Maximum current setting for the backlight when brightness
is at one of the three levels (daylight, office or dark). This
is an input code between 0 and 127, which is transformed to a
value between 0 mA and 30 mA using linear or non-linear
algorithms.
What: /sys/class/backlight/<backlight>/l1_daylight_dim
What: /sys/class/backlight/<backlight>/l2_office_dim
What: /sys/class/backlight/<backlight>/l3_dark_dim
Date: Apr, 2010
KernelVersion: v2.6.35
Contact: Michael Hennerich <michael.hennerich@analog.com>
Description:
(RW) Dim current setting for the backlight when brightness is at
one of the three levels (daylight, office or dark). This is an
input code between 0 and 127, which is transformed to a value
between 0 mA and 30 mA using linear or non-linear algorithms.

32
Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870
View File

@ -1,32 +0,0 @@
See also /sys/class/backlight/<backlight>/ambient_light_level and
/sys/class/backlight/<backlight>/ambient_light_zone.
What: /sys/class/backlight/<backlight>/<ambient light zone>_max
What: /sys/class/backlight/<backlight>/l1_daylight_max
What: /sys/class/backlight/<backlight>/l2_bright_max
What: /sys/class/backlight/<backlight>/l3_office_max
What: /sys/class/backlight/<backlight>/l4_indoor_max
What: /sys/class/backlight/<backlight>/l5_dark_max
Date: May 2011
KernelVersion: 3.0
Contact: device-drivers-devel@blackfin.uclinux.org
Description:
Control the maximum brightness for <ambient light zone>
on this <backlight>. Values are between 0 and 127. This file
will also show the brightness level stored for this
<ambient light zone>.
What: /sys/class/backlight/<backlight>/<ambient light zone>_dim
What: /sys/class/backlight/<backlight>/l2_bright_dim
What: /sys/class/backlight/<backlight>/l3_office_dim
What: /sys/class/backlight/<backlight>/l4_indoor_dim
What: /sys/class/backlight/<backlight>/l5_dark_dim
Date: May 2011
KernelVersion: 3.0
Contact: device-drivers-devel@blackfin.uclinux.org
Description:
Control the dim brightness for <ambient light zone>
on this <backlight>. Values are between 0 and 127, typically
set to 0. Full off when the backlight is disabled.
This file will also show the dim brightness level stored for
this <ambient light zone>.

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

@ -1,9 +0,0 @@
What: /sys/class/leds/<led>/repeat
Date: September 2019
KernelVersion: 5.5
Description:
EL15203000 supports only indefinitely patterns,
so this file should always store -1.
For more info, please see:
Documentation/ABI/testing/sysfs-class-led-trigger-pattern

3
Documentation/ABI/testing/sysfs-class-led-trigger-pattern
View File

@ -35,3 +35,6 @@ Description:
This file will always return the originally written repeat
number.
It should be noticed that some leds, like EL15203000 may
only support indefinitely patterns, so they always store -1.

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

@ -50,7 +50,7 @@ Description: Dynamic addition and removal of CPU's. This is not hotplug
architecture specific.
release: writes to this file dynamically remove a CPU from
the system. Information writtento the file to remove CPU's
the system. Information written to the file to remove CPU's
is architecture specific.
What: /sys/devices/system/cpu/cpu#/node
@ -97,7 +97,7 @@ Description: CPU topology files that describe a logical CPU's relationship
corresponds to a physical socket number, but the actual value
is architecture and platform dependent.
thread_siblings: internel kernel map of cpu#'s hardware
thread_siblings: internal kernel map of cpu#'s hardware
threads within the same core as cpu#
thread_siblings_list: human-readable list of cpu#'s hardware
@ -280,7 +280,7 @@ Description: Disable L3 cache indices
on a processor with this functionality will return the currently
disabled index for that node. There is one L3 structure per
node, or per internal node on MCM machines. Writing a valid
index to one of these files will cause the specificed cache
index to one of these files will cause the specified cache
index to be disabled.
All AMD processors with L3 caches provide this functionality.
@ -295,7 +295,7 @@ Description: Processor frequency boosting control
This switch controls the boost setting for the whole system.
Boosting allows the CPU and the firmware to run at a frequency
beyound it's nominal limit.
beyond it's nominal limit.
More details can be found in
Documentation/admin-guide/pm/cpufreq.rst
@ -532,7 +532,7 @@ What: /sys/devices/system/cpu/smt
/sys/devices/system/cpu/smt/control
Date: June 2018
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Control Symetric Multi Threading (SMT)
Description: Control Symmetric Multi Threading (SMT)
active: Tells whether SMT is active (enabled and siblings online)

4
Documentation/ABI/testing/sysfs-driver-ufs
View File

@ -168,7 +168,7 @@ Description: This file shows the manufacturing date in BCD format.
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/manufacturer_id
Date: February 2018
Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
Description: This file shows the manufacturee ID. This is one of the
Description: This file shows the manufacturer ID. This is one of the
UFS device descriptor parameters. The full information about
the descriptor could be found at UFS specifications 2.1.
@ -521,7 +521,7 @@ Description: This file shows maximum VCC, VCCQ and VCCQ2 value for
What: /sys/bus/platform/drivers/ufshcd/*/string_descriptors/manufacturer_name
Date: February 2018
Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
Description: This file contains a device manufactureer name string.
Description: This file contains a device manufacturer name string.
The full information about the descriptor could be found at
UFS specifications 2.1.

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

@ -238,7 +238,7 @@ Description: Shows current reserved blocks in system, it may be temporarily
What: /sys/fs/f2fs/<disk>/gc_urgent
Date: August 2017
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: Do background GC agressively when set. When gc_urgent = 1,
Description: Do background GC aggressively when set. When gc_urgent = 1,
background thread starts to do GC by given gc_urgent_sleep_time
interval. When gc_urgent = 2, F2FS will lower the bar of
checking idle in order to process outstanding discard commands

12
Documentation/ABI/testing/sysfs-kernel-iommu_groups
View File

@ -25,14 +25,10 @@ Description: /sys/kernel/iommu_groups/reserved_regions list IOVA
the base IOVA, the second is the end IOVA and the third
field describes the type of the region.
What: /sys/kernel/iommu_groups/reserved_regions
Date: June 2019
KernelVersion: v5.3
Contact: Eric Auger <eric.auger@redhat.com>
Description: In case an RMRR is used only by graphics or USB devices
it is now exposed as "direct-relaxable" instead of "direct".
In device assignment use case, for instance, those RMRR
are considered to be relaxable and safe.
Since kernel 5.3, in case an RMRR is used only by graphics or
USB devices it is now exposed as "direct-relaxable" instead
of "direct". In device assignment use case, for instance,
those RMRR are considered to be relaxable and safe.
What: /sys/kernel/iommu_groups/<grp_id>/type
Date: November 2020

2
Documentation/Makefile
View File

@ -76,7 +76,7 @@ quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4)
PYTHONDONTWRITEBYTECODE=1 \
BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath $(srctree)/$(src)/$5/$(SPHINX_CONF)) \
$(PYTHON3) $(srctree)/scripts/jobserver-exec \
$(SHELL) $(srctree)/Documentation/sphinx/parallel-wrapper.sh \
$(CONFIG_SHELL) $(srctree)/Documentation/sphinx/parallel-wrapper.sh \
$(SPHINXBUILD) \
-b $2 \
-c $(abspath $(srctree)/$(src)) \

18
Documentation/PCI/acpi-info.rst
View File

@ -22,9 +22,9 @@ or if the device has INTx interrupts connected by platform interrupt
controllers and a _PRT is needed to describe those connections.
ACPI resource description is done via _CRS objects of devices in the ACPI
namespace [2].   The _CRS is like a generalized PCI BAR: the OS can read
namespace [2]. The _CRS is like a generalized PCI BAR: the OS can read
_CRS and figure out what resource is being consumed even if it doesn't have
a driver for the device [3].  That's important because it means an old OS
a driver for the device [3]. That's important because it means an old OS
can work correctly even on a system with new devices unknown to the OS.
The new devices might not do anything, but the OS can at least make sure no
resources conflict with them.
@ -41,15 +41,15 @@ ACPI, that device will have a specific _HID/_CID that tells the OS what
driver to bind to it, and the _CRS tells the OS and the driver where the
device's registers are.
PCI host bridges are PNP0A03 or PNP0A08 devices.  Their _CRS should
describe all the address space they consume.  This includes all the windows
PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should
describe all the address space they consume. This includes all the windows
they forward down to the PCI bus, as well as registers of the host bridge
itself that are not forwarded to PCI.  The host bridge registers include
itself that are not forwarded to PCI. The host bridge registers include
things like secondary/subordinate bus registers that determine the bus
range below the bridge, window registers that describe the apertures, etc.
These are all device-specific, non-architected things, so the only way a
PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which contain
the device-specific details.  The host bridge registers also include ECAM
the device-specific details. The host bridge registers also include ECAM
space, since it is consumed by the host bridge.
ACPI defines a Consumer/Producer bit to distinguish the bridge registers
@ -66,7 +66,7 @@ the PNP0A03/PNP0A08 device itself. The workaround was to describe the
bridge registers (including ECAM space) in PNP0C02 catch-all devices [6].
With the exception of ECAM, the bridge register space is device-specific
anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to
know about it.  
know about it.
New architectures should be able to use "Consumer" Extended Address Space
descriptors in the PNP0A03 device for bridge registers, including ECAM,
@ -75,9 +75,9 @@ ia64 kernels assume all address space descriptors, including "Consumer"
Extended Address Space ones, are windows, so it would not be safe to
describe bridge registers this way on those architectures.
PNP0C02 "motherboard" devices are basically a catch-all.  There's no
PNP0C02 "motherboard" devices are basically a catch-all. There's no
programming model for them other than "don't use these resources for
anything else."  So a PNP0C02 _CRS should claim any address space that is
anything else." So a PNP0C02 _CRS should claim any address space that is
(1) not claimed by _CRS under any other device object in the ACPI namespace
and (2) should not be assigned by the OS to something else.

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

@ -125,4 +125,4 @@ all the EPF devices are created and linked with the EPC device.
| interrupt_pin
| function
[1] :doc:`pci-endpoint`
[1] Documentation/PCI/endpoint/pci-endpoint.rst

6
Documentation/PCI/pci.rst
View File

@ -265,7 +265,7 @@ Set the DMA mask size
---------------------
.. note::
If anything below doesn't make sense, please refer to
:doc:`/core-api/dma-api`. This section is just a reminder that
Documentation/core-api/dma-api.rst. This section is just a reminder that
drivers need to indicate DMA capabilities of the device and is not
an authoritative source for DMA interfaces.
@ -291,7 +291,7 @@ Many 64-bit "PCI" devices (before PCI-X) and some PCI-X devices are
Setup shared control data
-------------------------
Once the DMA masks are set, the driver can allocate "consistent" (a.k.a. shared)
memory. See :doc:`/core-api/dma-api` for a full description of
memory. See Documentation/core-api/dma-api.rst for a full description of
the DMA APIs. This section is just a reminder that it needs to be done
before enabling DMA on the device.
@ -421,7 +421,7 @@ owners if there is one.
Then clean up "consistent" buffers which contain the control data.
See :doc:`/core-api/dma-api` for details on unmapping interfaces.
See Documentation/core-api/dma-api.rst for details on unmapping interfaces.
Unregister from other subsystems

12
Documentation/accounting/delay-accounting.rst
View File

@ -69,13 +69,15 @@ Compile the kernel with::
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASKSTATS=y
Delay accounting is enabled by default at boot up.
To disable, add::
Delay accounting is disabled by default at boot up.
To enable, add::
nodelayacct
delayacct
to the kernel boot options. The rest of the instructions
below assume this has not been done.
to the kernel boot options. The rest of the instructions below assume this has
been done. Alternatively, use sysctl kernel.task_delayacct to switch the state
at runtime. Note however that only tasks started after enabling it will have
delayacct information.
After the system has booted up, use a utility
similar to getdelays.c to access the delays

85
Documentation/admin-guide/cputopology.rst
View File

@ -2,87 +2,10 @@
How CPU topology info is exported via sysfs
===========================================
Export CPU topology info via sysfs. Items (attributes) are similar
to /proc/cpuinfo output of some architectures. They reside in
/sys/devices/system/cpu/cpuX/topology/:
physical_package_id:
physical package id of cpuX. Typically corresponds to a physical
socket number, but the actual value is architecture and platform
dependent.
die_id:
the CPU die ID of cpuX. Typically it is the hardware platform's
identifier (rather than the kernel's). The actual value is
architecture and platform dependent.
core_id:
the CPU core ID of cpuX. Typically it is the hardware platform's
identifier (rather than the kernel's). The actual value is
architecture and platform dependent.
book_id:
the book ID of cpuX. Typically it is the hardware platform's
identifier (rather than the kernel's). The actual value is
architecture and platform dependent.
drawer_id:
the drawer ID of cpuX. Typically it is the hardware platform's
identifier (rather than the kernel's). The actual value is
architecture and platform dependent.
core_cpus:
internal kernel map of CPUs within the same core.
(deprecated name: "thread_siblings")
core_cpus_list:
human-readable list of CPUs within the same core.
(deprecated name: "thread_siblings_list");
package_cpus:
internal kernel map of the CPUs sharing the same physical_package_id.
(deprecated name: "core_siblings")
package_cpus_list:
human-readable list of CPUs sharing the same physical_package_id.
(deprecated name: "core_siblings_list")
die_cpus:
internal kernel map of CPUs within the same die.
die_cpus_list:
human-readable list of CPUs within the same die.
book_siblings:
internal kernel map of cpuX's hardware threads within the same
book_id.
book_siblings_list:
human-readable list of cpuX's hardware threads within the same
book_id.
drawer_siblings:
internal kernel map of cpuX's hardware threads within the same
drawer_id.
drawer_siblings_list:
human-readable list of cpuX's hardware threads within the same
drawer_id.
CPU topology info is exported via sysfs. Items (attributes) are similar
to /proc/cpuinfo output of some architectures. They reside in
/sys/devices/system/cpu/cpuX/topology/. Please refer to the ABI file:
Documentation/ABI/stable/sysfs-devices-system-cpu.
Architecture-neutral, drivers/base/topology.c, exports these attributes.
However, the book and drawer related sysfs files will only be created if

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

@ -392,7 +392,7 @@ When mounting an ext4 filesystem, the following option are accepted:
dax
Use direct access (no page cache). See
Documentation/filesystems/dax.txt. Note that this option is
Documentation/filesystems/dax.rst. Note that this option is
incompatible with data=journal.
inlinecrypt

223
Documentation/admin-guide/hw-vuln/core-scheduling.rst Normal file
View File

@ -0,0 +1,223 @@
.. SPDX-License-Identifier: GPL-2.0
===============
Core Scheduling
===============
Core scheduling support allows userspace to define groups of tasks that can
share a core. These groups can be specified either for security usecases (one
group of tasks don't trust another), or for performance usecases (some
workloads may benefit from running on the same core as they don't need the same
hardware resources of the shared core, or may prefer different cores if they
do share hardware resource needs). This document only describes the security
usecase.
Security usecase
----------------
A cross-HT attack involves the attacker and victim running on different Hyper
Threads of the same core. MDS and L1TF are examples of such attacks. The only
full mitigation of cross-HT attacks is to disable Hyper Threading (HT). Core
scheduling is a scheduler feature that can mitigate some (not all) cross-HT
attacks. It allows HT to be turned on safely by ensuring that only tasks in a
user-designated trusted group can share a core. This increase in core sharing
can also improve performance, however it is not guaranteed that performance
will always improve, though that is seen to be the case with a number of real
world workloads. In theory, core scheduling aims to perform at least as good as
when Hyper Threading is disabled. In practice, this is mostly the case though
not always: as synchronizing scheduling decisions across 2 or more CPUs in a
core involves additional overhead - especially when the system is lightly
loaded. When ``total_threads <= N_CPUS/2``, the extra overhead may cause core
scheduling to perform more poorly compared to SMT-disabled, where N_CPUS is the
total number of CPUs. Please measure the performance of your workloads always.
Usage
-----
Core scheduling support is enabled via the ``CONFIG_SCHED_CORE`` config option.
Using this feature, userspace defines groups of tasks that can be co-scheduled
on the same core. The core scheduler uses this information to make sure that
tasks that are not in the same group never run simultaneously on a core, while
doing its best to satisfy the system's scheduling requirements.
Core scheduling can be enabled via the ``PR_SCHED_CORE`` prctl interface.
This interface provides support for the creation of core scheduling groups, as
well as admission and removal of tasks from created groups::
#include <sys/prctl.h>
int prctl(int option, unsigned long arg2, unsigned long arg3,
unsigned long arg4, unsigned long arg5);
option:
``PR_SCHED_CORE``
arg2:
Command for operation, must be one off:
- ``PR_SCHED_CORE_GET`` -- get core_sched cookie of ``pid``.
- ``PR_SCHED_CORE_CREATE`` -- create a new unique cookie for ``pid``.
- ``PR_SCHED_CORE_SHARE_TO`` -- push core_sched cookie to ``pid``.
- ``PR_SCHED_CORE_SHARE_FROM`` -- pull core_sched cookie from ``pid``.
arg3:
``pid`` of the task for which the operation applies.
arg4:
``pid_type`` for which the operation applies. It is of type ``enum pid_type``.
For example, if arg4 is ``PIDTYPE_TGID``, then the operation of this command
will be performed for all tasks in the task group of ``pid``.
arg5:
userspace pointer to an unsigned long for storing the cookie returned by
``PR_SCHED_CORE_GET`` command. Should be 0 for all other commands.
In order for a process to push a cookie to, or pull a cookie from a process, it
is required to have the ptrace access mode: `PTRACE_MODE_READ_REALCREDS` to the
process.
Building hierarchies of tasks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The simplest way to build hierarchies of threads/processes which share a
cookie and thus a core is to rely on the fact that the core-sched cookie is
inherited across forks/clones and execs, thus setting a cookie for the
'initial' script/executable/daemon will place every spawned child in the
same core-sched group.
Cookie Transferral
~~~~~~~~~~~~~~~~~~
Transferring a cookie between the current and other tasks is possible using
PR_SCHED_CORE_SHARE_FROM and PR_SCHED_CORE_SHARE_TO to inherit a cookie from a
specified task or a share a cookie with a task. In combination this allows a
simple helper program to pull a cookie from a task in an existing core
scheduling group and share it with already running tasks.
Design/Implementation
---------------------
Each task that is tagged is assigned a cookie internally in the kernel. As
mentioned in `Usage`_, tasks with the same cookie value are assumed to trust
each other and share a core.
The basic idea is that, every schedule event tries to select tasks for all the
siblings of a core such that all the selected tasks running on a core are
trusted (same cookie) at any point in time. Kernel threads are assumed trusted.
The idle task is considered special, as it trusts everything and everything
trusts it.
During a schedule() event on any sibling of a core, the highest priority task on
the sibling's core is picked and assigned to the sibling calling schedule(), if
the sibling has the task enqueued. For rest of the siblings in the core,
highest priority task with the same cookie is selected if there is one runnable
in their individual run queues. If a task with same cookie is not available,
the idle task is selected. Idle task is globally trusted.
Once a task has been selected for all the siblings in the core, an IPI is sent to
siblings for whom a new task was selected. Siblings on receiving the IPI will
switch to the new task immediately. If an idle task is selected for a sibling,
then the sibling is considered to be in a `forced idle` state. I.e., it may
have tasks on its on runqueue to run, however it will still have to run idle.
More on this in the next section.
Forced-idling of hyperthreads
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The scheduler tries its best to find tasks that trust each other such that all
tasks selected to be scheduled are of the highest priority in a core. However,
it is possible that some runqueues had tasks that were incompatible with the
highest priority ones in the core. Favoring security over fairness, one or more
siblings could be forced to select a lower priority task if the highest
priority task is not trusted with respect to the core wide highest priority
task. If a sibling does not have a trusted task to run, it will be forced idle
by the scheduler (idle thread is scheduled to run).
When the highest priority task is selected to run, a reschedule-IPI is sent to
the sibling to force it into idle. This results in 4 cases which need to be
considered depending on whether a VM or a regular usermode process was running
on either HT::
HT1 (attack) HT2 (victim)
A idle -> user space user space -> idle
B idle -> user space guest -> idle
C idle -> guest user space -> idle
D idle -> guest guest -> idle
Note that for better performance, we do not wait for the destination CPU
(victim) to enter idle mode. This is because the sending of the IPI would bring
the destination CPU immediately into kernel mode from user space, or VMEXIT
in the case of guests. At best, this would only leak some scheduler metadata
which may not be worth protecting. It is also possible that the IPI is received
too late on some architectures, but this has not been observed in the case of
x86.
Trust model
~~~~~~~~~~~
Core scheduling maintains trust relationships amongst groups of tasks by
assigning them a tag that is the same cookie value.
When a system with core scheduling boots, all tasks are considered to trust
each other. This is because the core scheduler does not have information about
trust relationships until userspace uses the above mentioned interfaces, to
communicate them. In other words, all tasks have a default cookie value of 0.
and are considered system-wide trusted. The forced-idling of siblings running
cookie-0 tasks is also avoided.
Once userspace uses the above mentioned interfaces to group sets of tasks, tasks
within such groups are considered to trust each other, but do not trust those
outside. Tasks outside the group also don't trust tasks within.
Limitations of core-scheduling
------------------------------
Core scheduling tries to guarantee that only trusted tasks run concurrently on a
core. But there could be small window of time during which untrusted tasks run
concurrently or kernel could be running concurrently with a task not trusted by
kernel.
IPI processing delays
~~~~~~~~~~~~~~~~~~~~~
Core scheduling selects only trusted tasks to run together. IPI is used to notify
the siblings to switch to the new task. But there could be hardware delays in
receiving of the IPI on some arch (on x86, this has not been observed). This may
cause an attacker task to start running on a CPU before its siblings receive the
IPI. Even though cache is flushed on entry to user mode, victim tasks on siblings
may populate data in the cache and micro architectural buffers after the attacker
starts to run and this is a possibility for data leak.
Open cross-HT issues that core scheduling does not solve
--------------------------------------------------------
1. For MDS
~~~~~~~~~~
Core scheduling cannot protect against MDS attacks between an HT running in
user mode and another running in kernel mode. Even though both HTs run tasks
which trust each other, kernel memory is still considered untrusted. Such
attacks are possible for any combination of sibling CPU modes (host or guest mode).
2. For L1TF
~~~~~~~~~~~
Core scheduling cannot protect against an L1TF guest attacker exploiting a
guest or host victim. This is because the guest attacker can craft invalid
PTEs which are not inverted due to a vulnerable guest kernel. The only
solution is to disable EPT (Extended Page Tables).
For both MDS and L1TF, if the guest vCPU is configured to not trust each
other (by tagging separately), then the guest to guest attacks would go away.
Or it could be a system admin policy which considers guest to guest attacks as
a guest problem.
Another approach to resolve these would be to make every untrusted task on the
system to not trust every other untrusted task. While this could reduce
parallelism of the untrusted tasks, it would still solve the above issues while
allowing system processes (trusted tasks) to share a core.
3. Protecting the kernel (IRQ, syscall, VMEXIT)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Unfortunately, core scheduling does not protect kernel contexts running on
sibling hyperthreads from one another. Prototypes of mitigations have been posted
to LKML to solve this, but it is debatable whether such windows are practically
exploitable, and whether the performance overhead of the prototypes are worth
it (not to mention, the added code complexity).
Other Use cases
---------------
The main use case for Core scheduling is mitigating the cross-HT vulnerabilities
with SMT enabled. There are other use cases where this feature could be used:
- Isolating tasks that needs a whole core: Examples include realtime tasks, tasks
that uses SIMD instructions etc.
- Gang scheduling: Requirements for a group of tasks that needs to be scheduled
together could also be realized using core scheduling. One example is vCPUs of
a VM.

1
Documentation/admin-guide/hw-vuln/index.rst
View File

@ -15,3 +15,4 @@ are configurable at compile, boot or run time.
tsx_async_abort
multihit.rst
special-register-buffer-data-sampling.rst
core-scheduling.rst

3
Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst
View File

@ -3,7 +3,8 @@
SRBDS - Special Register Buffer Data Sampling
=============================================
SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to
SRBDS is a hardware vulnerability that allows MDS
Documentation/admin-guide/hw-vuln/mds.rst techniques to
infer values returned from special register accesses. Special register
accesses are accesses to off core registers. According to Intel's evaluation,
the special register reads that have a security expectation of privacy are

192
Documentation/admin-guide/kdump/kdump.rst
View File

@ -2,7 +2,7 @@
Documentation for Kdump - The kexec-based Crash Dumping Solution
================================================================
This document includes overview, setup and installation, and analysis
This document includes overview, setup, installation, and analysis
information.
Overview
@ -13,9 +13,9 @@ dump of the system kernel's memory needs to be taken (for example, when
the system panics). The system kernel's memory image is preserved across
the reboot and is accessible to the dump-capture kernel.
You can use common commands, such as cp and scp, to copy the
memory image to a dump file on the local disk, or across the network to
a remote system.
You can use common commands, such as cp, scp or makedumpfile to copy
the memory image to a dump file on the local disk, or across the network
to a remote system.
Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64,
s390x, arm and arm64 architectures.
@ -26,13 +26,15 @@ the dump-capture kernel. This ensures that ongoing Direct Memory Access
The kexec -p command loads the dump-capture kernel into this reserved
memory.
On x86 machines, the first 640 KB of physical memory is needed to boot,
regardless of where the kernel loads. Therefore, kexec backs up this
region just before rebooting into the dump-capture kernel.
On x86 machines, the first 640 KB of physical memory is needed for boot,
regardless of where the kernel loads. For simpler handling, the whole
low 1M is reserved to avoid any later kernel or device driver writing
data into this area. Like this, the low 1M can be reused as system RAM
by kdump kernel without extra handling.
Similarly on PPC64 machines first 32KB of physical memory is needed for
booting regardless of where the kernel is loaded and to support 64K page
size kexec backs up the first 64KB memory.
On PPC64 machines first 32KB of physical memory is needed for booting
regardless of where the kernel is loaded and to support 64K page size
kexec backs up the first 64KB memory.
For s390x, when kdump is triggered, the crashkernel region is exchanged
with the region [0, crashkernel region size] and then the kdump kernel
@ -46,14 +48,14 @@ passed to the dump-capture kernel through the elfcorehdr= boot
parameter. Optionally the size of the ELF header can also be passed
when using the elfcorehdr=[size[KMG]@]offset[KMG] syntax.
With the dump-capture kernel, you can access the memory image through
/proc/vmcore. This exports the dump as an ELF-format file that you can
write out using file copy commands such as cp or scp. Further, you can
use analysis tools such as the GNU Debugger (GDB) and the Crash tool to
debug the dump file. This method ensures that the dump pages are correctly
ordered.
write out using file copy commands such as cp or scp. You can also use
makedumpfile utility to analyze and write out filtered contents with
options, e.g with '-d 31' it will only write out kernel data. Further,
you can use analysis tools such as the GNU Debugger (GDB) and the Crash
tool to debug the dump file. This method ensures that the dump pages are
correctly ordered.
Setup and Installation
======================
@ -125,9 +127,18 @@ dump-capture kernels for enabling kdump support.
System kernel config options
----------------------------
1) Enable "kexec system call" in "Processor type and features."::
1) Enable "kexec system call" or "kexec file based system call" in
"Processor type and features."::
CONFIG_KEXEC=y
CONFIG_KEXEC=y or CONFIG_KEXEC_FILE=y
And both of them will select KEXEC_CORE::
CONFIG_KEXEC_CORE=y
Subsequently, CRASH_CORE is selected by KEXEC_CORE::
CONFIG_CRASH_CORE=y
2) Enable "sysfs file system support" in "Filesystem" -> "Pseudo
filesystems." This is usually enabled by default::
@ -175,17 +186,19 @@ Dump-capture kernel config options (Arch Dependent, i386 and x86_64)
CONFIG_HIGHMEM4G
2) On i386 and x86_64, disable symmetric multi-processing support
under "Processor type and features"::
2) With CONFIG_SMP=y, usually nr_cpus=1 need specified on the kernel
command line when loading the dump-capture kernel because one
CPU is enough for kdump kernel to dump vmcore on most of systems.
CONFIG_SMP=n
However, you can also specify nr_cpus=X to enable multiple processors
in kdump kernel. In this case, "disable_cpu_apicid=" is needed to
tell kdump kernel which cpu is 1st kernel's BSP. Please refer to
admin-guide/kernel-parameters.txt for more details.
(If CONFIG_SMP=y, then specify maxcpus=1 on the kernel command line
when loading the dump-capture kernel, see section "Load the Dump-capture
Kernel".)
With CONFIG_SMP=n, the above things are not related.
3) If one wants to build and use a relocatable kernel,
Enable "Build a relocatable kernel" support under "Processor type and
3) A relocatable kernel is suggested to be built by default. If not yet,
enable "Build a relocatable kernel" support under "Processor type and
features"::
CONFIG_RELOCATABLE=y
@ -232,7 +245,7 @@ Dump-capture kernel config options (Arch Dependent, ia64)
as a dump-capture kernel if desired.
The crashkernel region can be automatically placed by the system
kernel at run time. This is done by specifying the base address as 0,
kernel at runtime. This is done by specifying the base address as 0,
or omitting it all together::
crashkernel=256M@0
@ -241,10 +254,6 @@ Dump-capture kernel config options (Arch Dependent, ia64)
crashkernel=256M
If the start address is specified, note that the start address of the
kernel will be aligned to 64Mb, so if the start address is not then
any space below the alignment point will be wasted.
Dump-capture kernel config options (Arch Dependent, arm)
----------------------------------------------------------
@ -260,46 +269,82 @@ Dump-capture kernel config options (Arch Dependent, arm64)
on non-VHE systems even if it is configured. This is because the CPU
will not be reset to EL2 on panic.
Extended crashkernel syntax
crashkernel syntax
===========================
1) crashkernel=size@offset
While the "crashkernel=size[@offset]" syntax is sufficient for most
configurations, sometimes it's handy to have the reserved memory dependent
on the value of System RAM -- that's mostly for distributors that pre-setup
the kernel command line to avoid a unbootable system after some memory has
been removed from the machine.
The syntax is::
crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
range=start-[end]
For example::
crashkernel=512M-2G:64M,2G-:128M
This would mean:
1) if the RAM is smaller than 512M, then don't reserve anything
(this is the "rescue" case)
2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M
3) if the RAM size is larger than 2G, then reserve 128M
Boot into System Kernel
=======================
1) Update the boot loader (such as grub, yaboot, or lilo) configuration
files as necessary.
2) Boot the system kernel with the boot parameter "crashkernel=Y@X",
where Y specifies how much memory to reserve for the dump-capture kernel
and X specifies the beginning of this reserved memory. For example,
Here 'size' specifies how much memory to reserve for the dump-capture kernel
and 'offset' specifies the beginning of this reserved memory. For example,
"crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory
starting at physical address 0x01000000 (16MB) for the dump-capture kernel.
On x86 and x86_64, use "crashkernel=64M@16M".
The crashkernel region can be automatically placed by the system
kernel at run time. This is done by specifying the base address as 0,
or omitting it all together::
crashkernel=256M@0
or::
crashkernel=256M
If the start address is specified, note that the start address of the
kernel will be aligned to a value (which is Arch dependent), so if the
start address is not then any space below the alignment point will be
wasted.
2) range1:size1[,range2:size2,...][@offset]
While the "crashkernel=size[@offset]" syntax is sufficient for most
configurations, sometimes it's handy to have the reserved memory dependent
on the value of System RAM -- that's mostly for distributors that pre-setup
the kernel command line to avoid a unbootable system after some memory has
been removed from the machine.
The syntax is::
crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
range=start-[end]
For example::
crashkernel=512M-2G:64M,2G-:128M
This would mean:
1) if the RAM is smaller than 512M, then don't reserve anything
(this is the "rescue" case)
2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M
3) if the RAM size is larger than 2G, then reserve 128M
3) crashkernel=size,high and crashkernel=size,low
If memory above 4G is preferred, crashkernel=size,high can be used to
fulfill that. With it, physical memory is allowed to be allocated from top,
so could be above 4G if system has more than 4G RAM installed. Otherwise,
memory region will be allocated below 4G if available.
When crashkernel=X,high is passed, kernel could allocate physical memory
region above 4G, low memory under 4G is needed in this case. There are
three ways to get low memory:
1) Kernel will allocate at least 256M memory below 4G automatically
if crashkernel=Y,low is not specified.
2) Let user specify low memory size instead.
3) Specified value 0 will disable low memory allocation::
crashkernel=0,low
Boot into System Kernel
-----------------------
1) Update the boot loader (such as grub, yaboot, or lilo) configuration
files as necessary.
2) Boot the system kernel with the boot parameter "crashkernel=Y@X".
On x86 and x86_64, use "crashkernel=Y[@X]". Most of the time, the
start address 'X' is not necessary, kernel will search a suitable
area. Unless an explicit start address is expected.
On ppc64, use "crashkernel=128M@32M".
@ -331,8 +376,8 @@ of dump-capture kernel. Following is the summary.
For i386 and x86_64:
- Use vmlinux if kernel is not relocatable.
- Use bzImage/vmlinuz if kernel is relocatable.
- Use vmlinux if kernel is not relocatable.
For ppc64:
@ -392,7 +437,7 @@ loading dump-capture kernel.
For i386, x86_64 and ia64:
"1 irqpoll maxcpus=1 reset_devices"
"1 irqpoll nr_cpus=1 reset_devices"
For ppc64:
@ -400,7 +445,7 @@ For ppc64:
For s390x:
"1 maxcpus=1 cgroup_disable=memory"
"1 nr_cpus=1 cgroup_disable=memory"
For arm:
@ -408,7 +453,7 @@ For arm:
For arm64:
"1 maxcpus=1 reset_devices"
"1 nr_cpus=1 reset_devices"
Notes on loading the dump-capture kernel:
@ -488,6 +533,10 @@ the following command::
cp /proc/vmcore <dump-file>
You can also use makedumpfile utility to write out the dump file
with specified options to filter out unwanted contents, e.g::
makedumpfile -l --message-level 1 -d 31 /proc/vmcore <dump-file>
Analysis
========
@ -535,8 +584,7 @@ This will cause a kdump to occur at the add_taint()->panic() call.
Contact
=======
- Vivek Goyal (vgoyal@redhat.com)
- Maneesh Soni (maneesh@in.ibm.com)
- kexec@lists.infradead.org
GDB macros
==========

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

@ -113,7 +113,7 @@
the GPE dispatcher.
This facility can be used to prevent such uncontrolled
GPE floodings.
Format: <byte>
Format: <byte> or <bitmap-list>
acpi_no_auto_serialize [HW,ACPI]
Disable auto-serialization of AML methods
@ -581,6 +581,28 @@
loops can be debugged more effectively on production
systems.
clocksource.max_cswd_read_retries= [KNL]
Number of clocksource_watchdog() retries due to
external delays before the clock will be marked
unstable. Defaults to three retries, that is,
four attempts to read the clock under test.
clocksource.verify_n_cpus= [KNL]
Limit the number of CPUs checked for clocksources
marked with CLOCK_SOURCE_VERIFY_PERCPU that
are marked unstable due to excessive skew.
A negative value says to check all CPUs, while
zero says not to check any. Values larger than
nr_cpu_ids are silently truncated to nr_cpu_ids.
The actual CPUs are chosen randomly, with
no replacement if the same CPU is chosen twice.
clocksource-wdtest.holdoff= [KNL]
Set the time in seconds that the clocksource
watchdog test waits before commencing its tests.
Defaults to zero when built as a module and to
10 seconds when built into the kernel.
clearcpuid=BITNUM[,BITNUM...] [X86]
Disable CPUID feature X for the kernel. See
arch/x86/include/asm/cpufeatures.h for the valid bit
@ -3244,7 +3266,7 @@
noclflush [BUGS=X86] Don't use the CLFLUSH instruction
nodelayacct [KNL] Disable per-task delay accounting
delayacct [KNL] Enable per-task delay accounting
nodsp [SH] Disable hardware DSP at boot time.
@ -3513,6 +3535,9 @@
nr_uarts= [SERIAL] maximum number of UARTs to be registered.
numa=off [KNL, ARM64, PPC, RISCV, SPARC, X86] Disable NUMA, Only
set up a single NUMA node spanning all memory.
numa_balancing= [KNL,ARM64,PPC,RISCV,S390,X86] Enable or disable automatic
NUMA balancing.
Allowed values are enable and disable
@ -3566,6 +3591,12 @@
off: turn off poisoning (default)
on: turn on poisoning
page_reporting.page_reporting_order=
[KNL] Minimal page reporting order
Format: <integer>
Adjust the minimal page reporting order. The page
reporting is disabled when it exceeds (MAX_ORDER-1).
panic= [KNL] Kernel behaviour on panic: delay <timeout>
timeout > 0: seconds before rebooting
timeout = 0: wait forever
@ -4775,11 +4806,6 @@
Reserves a hole at the top of the kernel virtual
address space.
reservelow= [X86]
Format: nn[K]
Set the amount of memory to reserve for BIOS at
the bottom of the address space.
reset_devices [KNL] Force drivers to reset the underlying device
during initialization.
@ -5283,6 +5309,14 @@
exception. Default behavior is by #AC if
both features are enabled in hardware.
ratelimit:N -
Set system wide rate limit to N bus locks
per second for bus lock detection.
0 < N <= 1000.
N/A for split lock detection.
If an #AC exception is hit in the kernel or in
firmware (i.e. not while executing in user mode)
the kernel will oops in either "warn" or "fatal"

4
Documentation/admin-guide/lockup-watchdogs.rst
View File

@ -39,7 +39,7 @@ in principle, they should work in any architecture where these
subsystems are present.
A periodic hrtimer runs to generate interrupts and kick the watchdog
task. An NMI perf event is generated every "watchdog_thresh"
job. An NMI perf event is generated every "watchdog_thresh"
(compile-time initialized to 10 and configurable through sysctl of the
same name) seconds to check for hardlockups. If any CPU in the system
does not receive any hrtimer interrupt during that time the
@ -47,7 +47,7 @@ does not receive any hrtimer interrupt during that time the
generate a kernel warning or call panic, depending on the
configuration.
The watchdog task is a high priority kernel thread that updates a
The watchdog job runs in a stop scheduling thread that updates a
timestamp every time it is scheduled. If that timestamp is not updated
for 2*watchdog_thresh seconds (the softlockup threshold) the
'softlockup detector' (coded inside the hrtimer callback function)

15
Documentation/admin-guide/media/bt8xx.rst
View File

@ -15,11 +15,12 @@ Authors:
General information
-------------------
This class of cards has a bt878a as the PCI interface, and require the bttv driver
for accessing the i2c bus and the gpio pins of the bt8xx chipset.
This class of cards has a bt878a as the PCI interface, and require the bttv
driver for accessing the i2c bus and the gpio pins of the bt8xx chipset.
Please see :doc:`bttv-cardlist` for a complete list of Cards based on the
Conexant Bt8xx PCI bridge supported by the Linux Kernel.
Please see Documentation/admin-guide/media/bttv-cardlist.rst for a complete
list of Cards based on the Conexant Bt8xx PCI bridge supported by the
Linux Kernel.
In order to be able to compile the kernel, some config options should be
enabled::
@ -80,7 +81,7 @@ for dvb-bt8xx drivers by passing modprobe parameters may be necessary.
Running TwinHan and Clones
~~~~~~~~~~~~~~~~~~~~~~~~~~
As shown at :doc:`bttv-cardlist`, TwinHan and
As shown at Documentation/admin-guide/media/bttv-cardlist.rst, TwinHan and
clones use ``card=113`` modprobe parameter. So, in order to properly
detect it for devices without EEPROM, you should use::
@ -105,12 +106,12 @@ The autodetected values are determined by the cards' "response string".
In your logs see f. ex.: dst_get_device_id: Recognize [DSTMCI].
For bug reports please send in a complete log with verbose=4 activated.
Please also see :doc:`ci`.
Please also see Documentation/admin-guide/media/ci.rst.
Running multiple cards
~~~~~~~~~~~~~~~~~~~~~~
See :doc:`bttv-cardlist` for a complete list of
See Documentation/admin-guide/media/bttv-cardlist.rst for a complete list of
Card ID. Some examples:
=========================== ===

21
Documentation/admin-guide/media/bttv.rst
View File

@ -24,7 +24,8 @@ If your board has digital TV, you'll also need::
./scripts/config -m DVB_BT8XX
In this case, please see :doc:`bt8xx` for additional notes.
In this case, please see Documentation/admin-guide/media/bt8xx.rst
for additional notes.
Make bttv work with your card
-----------------------------
@ -39,7 +40,7 @@ If it doesn't bttv likely could not autodetect your card and needs some
insmod options. The most important insmod option for bttv is "card=n"
to select the correct card type. If you get video but no sound you've
very likely specified the wrong (or no) card type. A list of supported
cards is in :doc:`bttv-cardlist`.
cards is in Documentation/admin-guide/media/bttv-cardlist.rst.
If bttv takes very long to load (happens sometimes with the cheap
cards which have no tuner), try adding this to your modules configuration
@ -57,8 +58,8 @@ directory should be enough for it to be autoload during the driver's
probing mode (e. g. when the Kernel boots or when the driver is
manually loaded via ``modprobe`` command).
If your card isn't listed in :doc:`bttv-cardlist` or if you have
trouble making audio work, please read :ref:`still_doesnt_work`.
If your card isn't listed in Documentation/admin-guide/media/bttv-cardlist.rst
or if you have trouble making audio work, please read :ref:`still_doesnt_work`.
Autodetecting cards
@ -77,8 +78,8 @@ the Subsystem ID in the second line, looks like this:
only bt878-based cards can have a subsystem ID (which does not mean
that every card really has one). bt848 cards can't have a Subsystem
ID and therefore can't be autodetected. There is a list with the ID's
at :doc:`bttv-cardlist` (in case you are interested or want to mail
patches with updates).
at Documentation/admin-guide/media/bttv-cardlist.rst
(in case you are interested or want to mail patches with updates).
.. _still_doesnt_work:
@ -259,15 +260,15 @@ bug. It is very helpful if you can tell where exactly it broke
With a hard freeze you probably doesn't find anything in the logfiles.
The only way to capture any kernel messages is to hook up a serial
console and let some terminal application log the messages. /me uses
screen. See :doc:`/admin-guide/serial-console` for details on setting
up a serial console.
screen. See Documentation/admin-guide/serial-console.rst for details on
setting up a serial console.
Read :doc:`/admin-guide/bug-hunting` to learn how to get any useful
Read Documentation/admin-guide/bug-hunting.rst to learn how to get any useful
information out of a register+stack dump printed by the kernel on
protection faults (so-called "kernel oops").
If you run into some kind of deadlock, you can try to dump a call trace
for each process using sysrq-t (see :doc:`/admin-guide/sysrq`).
for each process using sysrq-t (see Documentation/admin-guide/sysrq.rst).
This way it is possible to figure where *exactly* some process in "D"
state is stuck.

12
Documentation/admin-guide/media/index.rst
View File

@ -11,12 +11,14 @@ its supported drivers.
Please see:
- :doc:`/userspace-api/media/index`
for the userspace APIs used on media devices.
Documentation/userspace-api/media/index.rst
- :doc:`/driver-api/media/index`
for driver development information and Kernel APIs used by
media devices;
- for the userspace APIs used on media devices.
Documentation/driver-api/media/index.rst
- for driver development information and Kernel APIs used by
media devices;
The media subsystem
===================

35
Documentation/admin-guide/media/ipu3.rst
View File

@ -234,22 +234,23 @@ The IPU3 ImgU pipelines can be configured using the Media Controller, defined at
Running mode and firmware binary selection
------------------------------------------
ImgU works based on firmware, currently the ImgU firmware support run 2 pipes in
time-sharing with single input frame data. Each pipe can run at certain mode -
"VIDEO" or "STILL", "VIDEO" mode is commonly used for video frames capture, and
"STILL" is used for still frame capture. However, you can also select "VIDEO" to
capture still frames if you want to capture images with less system load and
power. For "STILL" mode, ImgU will try to use smaller BDS factor and output
larger bayer frame for further YUV processing than "VIDEO" mode to get high
quality images. Besides, "STILL" mode need XNR3 to do noise reduction, hence
"STILL" mode will need more power and memory bandwidth than "VIDEO" mode. TNR
will be enabled in "VIDEO" mode and bypassed by "STILL" mode. ImgU is running at
“VIDEO” mode by default, the user can use v4l2 control V4L2_CID_INTEL_IPU3_MODE
(currently defined in drivers/staging/media/ipu3/include/intel-ipu3.h) to query
and set the running mode. For user, there is no difference for buffer queueing
between the "VIDEO" and "STILL" mode, mandatory input and main output node
should be enabled and buffers need be queued, the statistics and the view-finder
queues are optional.
ImgU works based on firmware, currently the ImgU firmware support run 2 pipes
in time-sharing with single input frame data. Each pipe can run at certain mode
- "VIDEO" or "STILL", "VIDEO" mode is commonly used for video frames capture,
and "STILL" is used for still frame capture. However, you can also select
"VIDEO" to capture still frames if you want to capture images with less system
load and power. For "STILL" mode, ImgU will try to use smaller BDS factor and
output larger bayer frame for further YUV processing than "VIDEO" mode to get
high quality images. Besides, "STILL" mode need XNR3 to do noise reduction,
hence "STILL" mode will need more power and memory bandwidth than "VIDEO" mode.
TNR will be enabled in "VIDEO" mode and bypassed by "STILL" mode. ImgU is
running at "VIDEO" mode by default, the user can use v4l2 control
V4L2_CID_INTEL_IPU3_MODE (currently defined in
drivers/staging/media/ipu3/include/uapi/intel-ipu3.h) to query and set the
running mode. For user, there is no difference for buffer queueing between the
"VIDEO" and "STILL" mode, mandatory input and main output node should be
enabled and buffers need be queued, the statistics and the view-finder queues
are optional.
The firmware binary will be selected according to current running mode, such log
"using binary if_to_osys_striped " or "using binary if_to_osys_primary_striped"
@ -586,7 +587,7 @@ preserved.
References
==========
.. [#f5] drivers/staging/media/ipu3/include/intel-ipu3.h
.. [#f5] drivers/staging/media/ipu3/include/uapi/intel-ipu3.h
.. [#f1] https://github.com/intel/nvt

3
Documentation/admin-guide/media/saa7134.rst
View File

@ -50,7 +50,8 @@ To build and install, you should run::
Once the new Kernel is booted, saa7134 driver should be loaded automatically.
Depending on the card you might have to pass ``card=<nr>`` as insmod option.
If so, please check :doc:`saa7134-cardlist` for valid choices.
If so, please check Documentation/admin-guide/media/saa7134-cardlist.rst
for valid choices.
Once you have your card type number, you can pass a modules configuration
via a file (usually, it is either ``/etc/modules.conf`` or some file at

77
Documentation/admin-guide/pm/cpuidle.rst
View File

@ -347,81 +347,8 @@ for tickless systems. It follows the same basic strategy as the ``menu`` `one
<menu-gov_>`_: it always tries to find the deepest idle state suitable for the
given conditions. However, it applies a different approach to that problem.
First, it does not use sleep length correction factors, but instead it attempts
to correlate the observed idle duration values with the available idle states
and use that information to pick up the idle state that is most likely to
"match" the upcoming CPU idle interval. Second, it does not take the tasks
that were running on the given CPU in the past and are waiting on some I/O
operations to complete now at all (there is no guarantee that they will run on
the same CPU when they become runnable again) and the pattern detection code in
it avoids taking timer wakeups into account. It also only uses idle duration
values less than the current time till the closest timer (with the scheduler
tick excluded) for that purpose.
Like in the ``menu`` governor `case <menu-gov_>`_, the first step is to obtain
the *sleep length*, which is the time until the closest timer event with the
assumption that the scheduler tick will be stopped (that also is the upper bound
on the time until the next CPU wakeup). That value is then used to preselect an
idle state on the basis of three metrics maintained for each idle state provided
by the ``CPUIdle`` driver: ``hits``, ``misses`` and ``early_hits``.
The ``hits`` and ``misses`` metrics measure the likelihood that a given idle
state will "match" the observed (post-wakeup) idle duration if it "matches" the
sleep length. They both are subject to decay (after a CPU wakeup) every time
the target residency of the idle state corresponding to them is less than or
equal to the sleep length and the target residency of the next idle state is
greater than the sleep length (that is, when the idle state corresponding to
them "matches" the sleep length). The ``hits`` metric is increased if the
former condition is satisfied and the target residency of the given idle state
is less than or equal to the observed idle duration and the target residency of
the next idle state is greater than the observed idle duration at the same time
(that is, it is increased when the given idle state "matches" both the sleep
length and the observed idle duration). In turn, the ``misses`` metric is
increased when the given idle state "matches" the sleep length only and the
observed idle duration is too short for its target residency.
The ``early_hits`` metric measures the likelihood that a given idle state will
"match" the observed (post-wakeup) idle duration if it does not "match" the
sleep length. It is subject to decay on every CPU wakeup and it is increased
when the idle state corresponding to it "matches" the observed (post-wakeup)
idle duration and the target residency of the next idle state is less than or
equal to the sleep length (i.e. the idle state "matching" the sleep length is
deeper than the given one).
The governor walks the list of idle states provided by the ``CPUIdle`` driver
and finds the last (deepest) one with the target residency less than or equal
to the sleep length. Then, the ``hits`` and ``misses`` metrics of that idle
state are compared with each other and it is preselected if the ``hits`` one is
greater (which means that that idle state is likely to "match" the observed idle
duration after CPU wakeup). If the ``misses`` one is greater, the governor
preselects the shallower idle state with the maximum ``early_hits`` metric
(or if there are multiple shallower idle states with equal ``early_hits``
metric which also is the maximum, the shallowest of them will be preselected).
[If there is a wakeup latency constraint coming from the `PM QoS framework
<cpu-pm-qos_>`_ which is hit before reaching the deepest idle state with the
target residency within the sleep length, the deepest idle state with the exit
latency within the constraint is preselected without consulting the ``hits``,
``misses`` and ``early_hits`` metrics.]
Next, the governor takes several idle duration values observed most recently
into consideration and if at least a half of them are greater than or equal to
the target residency of the preselected idle state, that idle state becomes the
final candidate to ask for. Otherwise, the average of the most recent idle
duration values below the target residency of the preselected idle state is
computed and the governor walks the idle states shallower than the preselected
one and finds the deepest of them with the target residency within that average.
That idle state is then taken as the final candidate to ask for.
Still, at this point the governor may need to refine the idle state selection if
it has not decided to `stop the scheduler tick <idle-cpus-and-tick_>`_. That
generally happens if the target residency of the idle state selected so far is
less than the tick period and the tick has not been stopped already (in a
previous iteration of the idle loop). Then, like in the ``menu`` governor
`case <menu-gov_>`_, the sleep length used in the previous computations may not
reflect the real time until the closest timer event and if it really is greater
than that time, a shallower state with a suitable target residency may need to
be selected.
.. kernel-doc:: drivers/cpuidle/governors/teo.c
:doc: teo-description
.. _idle-states-representation:

16
Documentation/admin-guide/pm/intel_idle.rst
View File

@ -20,8 +20,8 @@ Nehalem and later generations of Intel processors, but the level of support for
a particular processor model in it depends on whether or not it recognizes that
processor model and may also depend on information coming from the platform
firmware. [To understand ``intel_idle`` it is necessary to know how ``CPUIdle``
works in general, so this is the time to get familiar with :doc:`cpuidle` if you
have not done that yet.]
works in general, so this is the time to get familiar with
Documentation/admin-guide/pm/cpuidle.rst if you have not done that yet.]
``intel_idle`` uses the ``MWAIT`` instruction to inform the processor that the
logical CPU executing it is idle and so it may be possible to put some of the
@ -53,7 +53,8 @@ processor) corresponding to them depends on the processor model and it may also
depend on the configuration of the platform.
In order to create a list of available idle states required by the ``CPUIdle``
subsystem (see :ref:`idle-states-representation` in :doc:`cpuidle`),
subsystem (see :ref:`idle-states-representation` in
Documentation/admin-guide/pm/cpuidle.rst),
``intel_idle`` can use two sources of information: static tables of idle states
for different processor models included in the driver itself and the ACPI tables
of the system. The former are always used if the processor model at hand is
@ -98,7 +99,8 @@ states may not be enabled by default if there are no matching entries in the
preliminary list of idle states coming from the ACPI tables. In that case user
space still can enable them later (on a per-CPU basis) with the help of
the ``disable`` idle state attribute in ``sysfs`` (see
:ref:`idle-states-representation` in :doc:`cpuidle`). This basically means that
:ref:`idle-states-representation` in
Documentation/admin-guide/pm/cpuidle.rst). This basically means that
the idle states "known" to the driver may not be enabled by default if they have
not been exposed by the platform firmware (through the ACPI tables).
@ -186,7 +188,8 @@ be desirable. In practice, it is only really necessary to do that if the idle
states in question cannot be enabled during system startup, because in the
working state of the system the CPU power management quality of service (PM
QoS) feature can be used to prevent ``CPUIdle`` from touching those idle states
even if they have been enumerated (see :ref:`cpu-pm-qos` in :doc:`cpuidle`).
even if they have been enumerated (see :ref:`cpu-pm-qos` in
Documentation/admin-guide/pm/cpuidle.rst).
Setting ``max_cstate`` to 0 causes the ``intel_idle`` initialization to fail.
The ``no_acpi`` and ``use_acpi`` module parameters (recognized by ``intel_idle``
@ -202,7 +205,8 @@ Namely, the positions of the bits that are set in the ``states_off`` value are
the indices of idle states to be disabled by default (as reflected by the names
of the corresponding idle state directories in ``sysfs``, :file:`state0`,
:file:`state1` ... :file:`state<i>` ..., where ``<i>`` is the index of the given
idle state; see :ref:`idle-states-representation` in :doc:`cpuidle`).
idle state; see :ref:`idle-states-representation` in
Documentation/admin-guide/pm/cpuidle.rst).
For example, if ``states_off`` is equal to 3, the driver will disable idle
states 0 and 1 by default, and if it is equal to 8, idle state 3 will be

15
Documentation/admin-guide/pm/intel_pstate.rst
View File

@ -18,8 +18,8 @@ General Information
(``CPUFreq``). It is a scaling driver for the Sandy Bridge and later
generations of Intel processors. Note, however, that some of those processors
may not be supported. [To understand ``intel_pstate`` it is necessary to know
how ``CPUFreq`` works in general, so this is the time to read :doc:`cpufreq` if
you have not done that yet.]
how ``CPUFreq`` works in general, so this is the time to read
Documentation/admin-guide/pm/cpufreq.rst if you have not done that yet.]
For the processors supported by ``intel_pstate``, the P-state concept is broader
than just an operating frequency or an operating performance point (see the
@ -365,6 +365,9 @@ argument is passed to the kernel in the command line.
inclusive) including both turbo and non-turbo P-states (see
`Turbo P-states Support`_).
This attribute is present only if the value exposed by it is the same
for all of the CPUs in the system.
The value of this attribute is not affected by the ``no_turbo``
setting described `below <no_turbo_attr_>`_.
@ -374,6 +377,9 @@ argument is passed to the kernel in the command line.
Ratio of the `turbo range <turbo_>`_ size to the size of the entire
range of supported P-states, in percent.
This attribute is present only if the value exposed by it is the same
for all of the CPUs in the system.
This attribute is read-only.
.. _no_turbo_attr:
@ -445,8 +451,9 @@ Interpretation of Policy Attributes
-----------------------------------
The interpretation of some ``CPUFreq`` policy attributes described in
:doc:`cpufreq` is special with ``intel_pstate`` as the current scaling driver
and it generally depends on the driver's `operation mode <Operation Modes_>`_.
Documentation/admin-guide/pm/cpufreq.rst is special with ``intel_pstate``
as the current scaling driver and it generally depends on the driver's
`operation mode <Operation Modes_>`_.
First of all, the values of the ``cpuinfo_max_freq``, ``cpuinfo_min_freq`` and
``scaling_cur_freq`` attributes are produced by applying a processor-specific

14
Documentation/admin-guide/pstore-blk.rst
View File

@ -45,15 +45,18 @@ blkdev
The block device to use. Most of the time, it is a partition of block device.
It's required for pstore/blk. It is also used for MTD device.
It accepts the following variants for block device:
When pstore/blk is built as a module, "blkdev" accepts the following variants:
1. <hex_major><hex_minor> device number in hexadecimal represents itself; no
leading 0x, for example b302.
#. /dev/<disk_name> represents the device number of disk
1. /dev/<disk_name> represents the device number of disk
#. /dev/<disk_name><decimal> represents the device number of partition - device
number of disk plus the partition number
#. /dev/<disk_name>p<decimal> - same as the above; this form is used when disk
name of partitioned disk ends with a digit.
When pstore/blk is built into the kernel, "blkdev" accepts the following variants:
#. <hex_major><hex_minor> device number in hexadecimal representation,
with no leading 0x, for example b302.
#. PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF represents the unique id of
a partition if the partition table provides it. The UUID may be either an
EFI/GPT UUID, or refer to an MSDOS partition using the format SSSSSSSS-PP,
@ -227,8 +230,5 @@ For developer reference, here are all the important structures and APIs:
.. kernel-doc:: include/linux/pstore_zone.h
:internal:
.. kernel-doc:: fs/pstore/blk.c
:internal:
.. kernel-doc:: include/linux/pstore_blk.h
:internal:

2
Documentation/admin-guide/reporting-issues.rst
View File

@ -1248,7 +1248,7 @@ paragraph makes the severeness obvious.
In case you performed a successful bisection, use the title of the change that
introduced the regression as the second part of your subject. Make the report
also mention the commit id of the culprit. In case of an unsuccessful bisection,
also mention the commit id of the culprit. In case of an unsuccessful bisection,
make your report mention the latest tested version that's working fine (say 5.7)
and the oldest where the issue occurs (say 5.8-rc1).

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

@ -11,7 +11,7 @@ Documentation for /proc/sys/abi/
Copyright (c) 2020, Stephen Kitt
For general info, see :doc:`index`.
For general info, see Documentation/admin-guide/sysctl/index.rst.
------------------------------------------------------------------------------

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

@ -9,7 +9,8 @@ Copyright (c) 1998, 1999, Rik van Riel <riel@nl.linux.org>
Copyright (c) 2009, Shen Feng<shen@cn.fujitsu.com>
For general info and legal blurb, please look in :doc:`index`.
For general info and legal blurb, please look in
Documentation/admin-guide/sysctl/index.rst.
------------------------------------------------------------------------------
@ -54,7 +55,7 @@ free space valid for 30 seconds.
acpi_video_flags
================
See :doc:`/power/video`. This allows the video resume mode to be set,
See Documentation/power/video.rst. This allows the video resume mode to be set,
in a similar fashion to the ``acpi_sleep`` kernel parameter, by
combining the following values:
@ -89,7 +90,7 @@ is 0x15 and the full version number is 0x234, this file will contain
the value 340 = 0x154.
See the ``type_of_loader`` and ``ext_loader_type`` fields in
:doc:`/x86/boot` for additional information.
Documentation/x86/boot.rst for additional information.
bootloader_version (x86 only)
@ -99,7 +100,7 @@ The complete bootloader version number. In the example above, this
file will contain the value 564 = 0x234.
See the ``type_of_loader`` and ``ext_loader_ver`` fields in
:doc:`/x86/boot` for additional information.
Documentation/x86/boot.rst for additional information.
bpf_stats_enabled
@ -269,7 +270,7 @@ see the ``hostname(1)`` man page.
firmware_config
===============
See :doc:`/driver-api/firmware/fallback-mechanisms`.
See Documentation/driver-api/firmware/fallback-mechanisms.rst.
The entries in this directory allow the firmware loader helper
fallback to be controlled:
@ -297,7 +298,7 @@ crashes and outputting them to a serial console.
ftrace_enabled, stack_tracer_enabled
====================================
See :doc:`/trace/ftrace`.
See Documentation/trace/ftrace.rst.
hardlockup_all_cpu_backtrace
@ -325,7 +326,7 @@ when a hard lockup is detected.
1 Panic on hard lockup.
= ===========================
See :doc:`/admin-guide/lockup-watchdogs` for more information.
See Documentation/admin-guide/lockup-watchdogs.rst for more information.
This can also be set using the nmi_watchdog kernel parameter.
@ -333,7 +334,12 @@ hotplug
=======
Path for the hotplug policy agent.
Default value is "``/sbin/hotplug``".
Default value is ``CONFIG_UEVENT_HELPER_PATH``, which in turn defaults
to the empty string.
This file only exists when ``CONFIG_UEVENT_HELPER`` is enabled. Most
modern systems rely exclusively on the netlink-based uevent source and
don't need this.
hung_task_all_cpu_backtrace
@ -582,7 +588,8 @@ in a KVM virtual machine. This default can be overridden by adding::
nmi_watchdog=1
to the guest kernel command line (see :doc:`/admin-guide/kernel-parameters`).
to the guest kernel command line (see
Documentation/admin-guide/kernel-parameters.rst).
numa_balancing
@ -1067,7 +1074,7 @@ that support this feature.
real-root-dev
=============
See :doc:`/admin-guide/initrd`.
See Documentation/admin-guide/initrd.rst.
reboot-cmd (SPARC only)
@ -1088,6 +1095,13 @@ Model available). If your platform happens to meet the
requirements for EAS but you do not want to use it, change
this value to 0.
task_delayacct
===============
Enables/disables task delay accounting (see
:doc:`accounting/delay-accounting.rst`). Enabling this feature incurs
a small amount of overhead in the scheduler but is useful for debugging
and performance tuning. It is required by some tools such as iotop.
sched_schedstats
================
@ -1154,7 +1168,7 @@ will take effect.
seccomp
=======
See :doc:`/userspace-api/seccomp_filter`.
See Documentation/userspace-api/seccomp_filter.rst.
sg-big-buff
@ -1283,11 +1297,11 @@ This parameter can be used to control the soft lockup detector.
= =================================
The soft lockup detector monitors CPUs for threads that are hogging the CPUs
without rescheduling voluntarily, and thus prevent the 'watchdog/N' threads
from running. The mechanism depends on the CPUs ability to respond to timer
interrupts which are needed for the 'watchdog/N' threads to be woken up by
the watchdog timer function, otherwise the NMI watchdog — if enabled — can
detect a hard lockup condition.
without rescheduling voluntarily, and thus prevent the 'migration/N' threads
from running, causing the watchdog work fail to execute. The mechanism depends
on the CPUs ability to respond to timer interrupts which are needed for the
watchdog work to be queued by the watchdog timer function, otherwise the NMI
watchdog — if enabled — can detect a hard lockup condition.
stack_erasing
@ -1325,7 +1339,7 @@ the boot PROM.
sysrq
=====
See :doc:`/admin-guide/sysrq`.
See Documentation/admin-guide/sysrq.rst.
tainted
@ -1355,15 +1369,16 @@ ORed together. The letters are seen in "Tainted" line of Oops reports.
131072 `(T)` The kernel was built with the struct randomization plugin
====== ===== ==============================================================
See :doc:`/admin-guide/tainted-kernels` for more information.
See Documentation/admin-guide/tainted-kernels.rst for more information.
Note:
writes to this sysctl interface will fail with ``EINVAL`` if the kernel is
booted with the command line option ``panic_on_taint=<bitmask>,nousertaint``
and any of the ORed together values being written to ``tainted`` match with
the bitmask declared on panic_on_taint.
See :doc:`/admin-guide/kernel-parameters` for more details on that particular
kernel command line option and its optional ``nousertaint`` switch.
See Documentation/admin-guide/kernel-parameters.rst for more details on
that particular kernel command line option and its optional
``nousertaint`` switch.
threads-max
===========
@ -1387,7 +1402,7 @@ If a value outside of this range is written to ``threads-max`` an
traceoff_on_warning
===================
When set, disables tracing (see :doc:`/trace/ftrace`) when a
When set, disables tracing (see Documentation/trace/ftrace.rst) when a
``WARN()`` is hit.
@ -1407,8 +1422,8 @@ will send them to printk() again.
This only works if the kernel was booted with ``tp_printk`` enabled.
See :doc:`/admin-guide/kernel-parameters` and
:doc:`/trace/boottime-trace`.
See Documentation/admin-guide/kernel-parameters.rst and
Documentation/trace/boottime-trace.rst.
.. _unaligned-dump-stack:

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

@ -64,7 +64,7 @@ Currently, these files are in /proc/sys/vm:
- overcommit_ratio
- page-cluster
- panic_on_oom
- percpu_pagelist_fraction
- percpu_pagelist_high_fraction
- stat_interval
- stat_refresh
- numa_stat
@ -790,22 +790,24 @@ panic_on_oom=2+kdump gives you very strong tool to investigate
why oom happens. You can get snapshot.
percpu_pagelist_fraction
========================
percpu_pagelist_high_fraction
=============================
This is the fraction of pages at most (high mark pcp->high) in each zone that
are allocated for each per cpu page list. The min value for this is 8. It
means that we don't allow more than 1/8th of pages in each zone to be
allocated in any single per_cpu_pagelist. This entry only changes the value
of hot per cpu pagelists. User can specify a number like 100 to allocate
1/100th of each zone to each per cpu page list.
This is the fraction of pages in each zone that are can be stored to
per-cpu page lists. It is an upper boundary that is divided depending
on the number of online CPUs. The min value for this is 8 which means
that we do not allow more than 1/8th of pages in each zone to be stored
on per-cpu page lists. This entry only changes the value of hot per-cpu
page lists. A user can specify a number like 100 to allocate 1/100th of
each zone between per-cpu lists.
The batch value of each per cpu pagelist is also updated as a result. It is
set to pcp->high/4. The upper limit of batch is (PAGE_SHIFT * 8)
The batch value of each per-cpu page list remains the same regardless of
the value of the high fraction so allocation latencies are unaffected.
The initial value is zero. Kernel does not use this value at boot time to set
the high water marks for each per cpu page list. If the user writes '0' to this
sysctl, it will revert to this default behavior.
The initial value is zero. Kernel uses this value to set the high pcp->high
mark based on the low watermark for the zone and the number of local
online CPUs. If the user writes '0' to this sysctl, it will revert to
this default behavior.
stat_interval
@ -936,12 +938,12 @@ allocations, THP and hugetlbfs pages.
To make it sensible with respect to the watermark_scale_factor
parameter, the unit is in fractions of 10,000. The default value of
15,000 on !DISCONTIGMEM configurations means that up to 150% of the high
watermark will be reclaimed in the event of a pageblock being mixed due
to fragmentation. The level of reclaim is determined by the number of
fragmentation events that occurred in the recent past. If this value is
smaller than a pageblock then a pageblocks worth of pages will be reclaimed
(e.g. 2MB on 64-bit x86). A boost factor of 0 will disable the feature.
15,000 means that up to 150% of the high watermark will be reclaimed in the
event of a pageblock being mixed due to fragmentation. The level of reclaim
is determined by the number of fragmentation events that occurred in the
recent past. If this value is smaller than a pageblock then a pageblocks
worth of pages will be reclaimed (e.g. 2MB on 64-bit x86). A boost factor
of 0 will disable the feature.
watermark_scale_factor

2
Documentation/arm/marvell.rst
View File

@ -259,7 +259,7 @@ Storage family
https://web.archive.org/web/20191129073953/http://www.marvell.com/storage/armada-sp/
Core:
Sheeva ARMv7 comatible Quad-core PJ4C
Sheeva ARMv7 compatible Quad-core PJ4C
(not supported in upstream Linux kernel)

6
Documentation/arm64/booting.rst
View File

@ -277,6 +277,12 @@ Before jumping into the kernel, the following conditions must be met:
- SCR_EL3.FGTEn (bit 27) must be initialised to 0b1.
For CPUs with support for HCRX_EL2 (FEAT_HCX) present:
- If EL3 is present and the kernel is entered at EL2:
- SCR_EL3.HXEn (bit 38) must be initialised to 0b1.
For CPUs with Advanced SIMD and floating point support:
- If EL3 is present:

2
Documentation/block/biodoc.rst
View File

@ -196,7 +196,7 @@ a virtual address mapping (unlike the earlier scheme of virtual address
do not have a corresponding kernel virtual address space mapping) and
low-memory pages.
Note: Please refer to :doc:`/core-api/dma-api-howto` for a discussion
Note: Please refer to Documentation/core-api/dma-api-howto.rst for a discussion
on PCI high mem DMA aspects and mapping of scatter gather lists, and support
for 64 bit PCI.

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

@ -62,7 +62,7 @@ queue, to be sent in the future, when the hardware is able.
Software staging queues
~~~~~~~~~~~~~~~~~~~~~~~
The block IO subsystem adds requests in the software staging queues
The block IO subsystem adds requests in the software staging queues
(represented by struct blk_mq_ctx) in case that they weren't sent
directly to the driver. A request is one or more BIOs. They arrived at the
block layer through the data structure struct bio. The block layer
@ -132,7 +132,7 @@ In order to indicate which request has been completed, every request is
identified by an integer, ranging from 0 to the dispatch queue size. This tag
is generated by the block layer and later reused by the device driver, removing
the need to create a redundant identifier. When a request is completed in the
drive, the tag is sent back to the block layer to notify it of the finalization.
driver, the tag is sent back to the block layer to notify it of the finalization.
This removes the need to do a linear search to find out which IO has been
completed.

2
Documentation/block/stat.rst
View File

@ -18,7 +18,7 @@ A.
each, it would be impossible to guarantee that a set of readings
represent a single point in time.
The stat file consists of a single line of text containing 11 decimal
The stat file consists of a single line of text containing 17 decimal
values separated by whitespace. The fields are summarized in the
following table, and described in more detail below.

13
Documentation/bpf/bpf_lsm.rst
View File

@ -20,10 +20,10 @@ LSM hook:
Other LSM hooks which can be instrumented can be found in
``include/linux/lsm_hooks.h``.
eBPF programs that use :doc:`/bpf/btf` do not need to include kernel headers
for accessing information from the attached eBPF program's context. They can
simply declare the structures in the eBPF program and only specify the fields
that need to be accessed.
eBPF programs that use Documentation/bpf/btf.rst do not need to include kernel
headers for accessing information from the attached eBPF program's context.
They can simply declare the structures in the eBPF program and only specify
the fields that need to be accessed.
.. code-block:: c
@ -88,8 +88,9 @@ example:
The ``__attribute__((preserve_access_index))`` is a clang feature that allows
the BPF verifier to update the offsets for the access at runtime using the
:doc:`/bpf/btf` information. Since the BPF verifier is aware of the types, it
also validates all the accesses made to the various types in the eBPF program.
Documentation/bpf/btf.rst information. Since the BPF verifier is aware of the
types, it also validates all the accesses made to the various types in the
eBPF program.
Loading
-------

24
Documentation/conf.py
View File

@ -41,15 +41,7 @@ extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include',
'maintainers_include', 'sphinx.ext.autosectionlabel',
'kernel_abi', 'kernel_feat']
#
# cdomain is badly broken in Sphinx 3+. Leaving it out generates *most*
# of the docs correctly, but not all. Scream bloody murder but allow
# the process to proceed; hopefully somebody will fix this properly soon.
#
if major >= 3:
sys.stderr.write('''WARNING: The kernel documentation build process
support for Sphinx v3.0 and above is brand new. Be prepared for
possible issues in the generated output.\n''')
if (major > 3) or (minor > 0 or patch >= 2):
# Sphinx c function parser is more pedantic with regards to type
# checking. Due to that, having macros at c:function cause problems.
@ -353,6 +345,8 @@ latex_elements = {
# Additional stuff for the LaTeX preamble.
'preamble': '''
% Prevent column squeezing of tabulary.
\\setlength{\\tymin}{20em}
% Use some font with UTF-8 support with XeLaTeX
\\usepackage{fontspec}
\\setsansfont{DejaVu Sans}
@ -366,11 +360,23 @@ latex_elements = {
cjk_cmd = check_output(['fc-list', '--format="%{family[0]}\n"']).decode('utf-8', 'ignore')
if cjk_cmd.find("Noto Sans CJK SC") >= 0:
print ("enabling CJK for LaTeX builder")
latex_elements['preamble'] += '''
% This is needed for translations
\\usepackage{xeCJK}
\\setCJKmainfont{Noto Sans CJK SC}
% Define custom macros to on/off CJK
\\newcommand{\\kerneldocCJKon}{\\makexeCJKactive}
\\newcommand{\\kerneldocCJKoff}{\\makexeCJKinactive}
% To customize \sphinxtableofcontents
\\usepackage{etoolbox}
% Inactivate CJK after tableofcontents
\\apptocmd{\\sphinxtableofcontents}{\\kerneldocCJKoff}{}{}
'''
else:
latex_elements['preamble'] += '''
% Custom macros to on/off CJK (Dummy)
\\newcommand{\\kerneldocCJKon}{}
\\newcommand{\\kerneldocCJKoff}{}
'''
# Fix reference escape troubles with Sphinx 1.4.x

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

@ -8,7 +8,7 @@ How to access I/O mapped memory from within device drivers
The virt_to_bus() and bus_to_virt() functions have been
superseded by the functionality provided by the PCI DMA interface
(see :doc:`/core-api/dma-api-howto`). They continue
(see Documentation/core-api/dma-api-howto.rst). They continue
to be documented below for historical purposes, but new code
must not use them. --davidm 00/12/12

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

@ -5,7 +5,7 @@ Dynamic DMA mapping using the generic device
:Author: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
This document describes the DMA API. For a more gentle introduction
of the API (and actual examples), see :doc:`/core-api/dma-api-howto`.
of the API (and actual examples), see Documentation/core-api/dma-api-howto.rst.
This API is split into two pieces. Part I describes the basic API.
Part II describes extensions for supporting non-consistent memory
@ -479,7 +479,8 @@ without the _attrs suffixes, except that they pass an optional
dma_attrs.
The interpretation of DMA attributes is architecture-specific, and
each attribute should be documented in :doc:`/core-api/dma-attributes`.
each attribute should be documented in
Documentation/core-api/dma-attributes.rst.
If dma_attrs are 0, the semantics of each of these functions
is identical to those of the corresponding function

2
Documentation/core-api/dma-isa-lpc.rst
View File

@ -17,7 +17,7 @@ To do ISA style DMA you need to include two headers::
#include <asm/dma.h>
The first is the generic DMA API used to convert virtual addresses to
bus addresses (see :doc:`/core-api/dma-api` for details).
bus addresses (see Documentation/core-api/dma-api.rst for details).
The second contains the routines specific to ISA DMA transfers. Since
this is not present on all platforms make sure you construct your

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

@ -48,7 +48,7 @@ Concurrency primitives
======================
How Linux keeps everything from happening at the same time. See
:doc:`/locking/index` for more related documentation.
Documentation/locking/index.rst for more related documentation.
.. toctree::
:maxdepth: 1
@ -77,7 +77,7 @@ Memory management
=================
How to allocate and use memory in the kernel. Note that there is a lot
more memory-management documentation in :doc:`/vm/index`.
more memory-management documentation in Documentation/vm/index.rst.
.. toctree::
:maxdepth: 1

1
Documentation/core-api/irq/irq-domain.rst
View File

@ -146,7 +146,6 @@ Legacy
irq_domain_add_simple()
irq_domain_add_legacy()
irq_domain_add_legacy_isa()
irq_domain_create_simple()
irq_domain_create_legacy()

16
Documentation/core-api/printk-formats.rst
View File

@ -37,14 +37,13 @@ Integer types
u64 %llu or %llx
If <type> is dependent on a config option for its size (e.g., sector_t,
blkcnt_t) or is architecture-dependent for its size (e.g., tcflag_t), use a
format specifier of its largest possible type and explicitly cast to it.
If <type> is architecture-dependent for its size (e.g., cycles_t, tcflag_t) or
is dependent on a config option for its size (e.g., blk_status_t), use a format
specifier of its largest possible type and explicitly cast to it.
Example::
printk("test: sector number/total blocks: %llu/%llu\n",
(unsigned long long)sector, (unsigned long long)blockcount);
printk("test: latency: %llu cycles\n", (unsigned long long)time);
Reminder: sizeof() returns type size_t.
@ -514,9 +513,10 @@ Time and date
::
%pt[RT] YYYY-mm-ddTHH:MM:SS
%pt[RT]s YYYY-mm-dd HH:MM:SS
%pt[RT]d YYYY-mm-dd
%pt[RT]t HH:MM:SS
%pt[RT][dt][r]
%pt[RT][dt][r][s]
For printing date and time as represented by::
@ -528,6 +528,10 @@ in human readable format.
By default year will be incremented by 1900 and month by 1.
Use %pt[RT]r (raw) to suppress this behaviour.
The %pt[RT]s (space) will override ISO 8601 separator by using ' ' (space)
instead of 'T' (Capital T) between date and time. It won't have any effect
when date or time is omitted.
Passed by reference.
struct clk

509
Documentation/dev-tools/checkpatch.rst
View File

@ -246,6 +246,7 @@ Allocation style
The first argument for kcalloc or kmalloc_array should be the
number of elements. sizeof() as the first argument is generally
wrong.
See: https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html
**ALLOC_SIZEOF_STRUCT**
@ -264,6 +265,7 @@ Allocation style
**ALLOC_WITH_MULTIPLY**
Prefer kmalloc_array/kcalloc over kmalloc/kzalloc with a
sizeof multiply.
See: https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html
@ -284,6 +286,7 @@ API usage
BUG() or BUG_ON() should be avoided totally.
Use WARN() and WARN_ON() instead, and handle the "impossible"
error condition as gracefully as possible.
See: https://www.kernel.org/doc/html/latest/process/deprecated.html#bug-and-bug-on
**CONSIDER_KSTRTO**
@ -292,12 +295,161 @@ API usage
may lead to unexpected results in callers. The respective kstrtol(),
kstrtoll(), kstrtoul(), and kstrtoull() functions tend to be the
correct replacements.
See: https://www.kernel.org/doc/html/latest/process/deprecated.html#simple-strtol-simple-strtoll-simple-strtoul-simple-strtoull
**CONSTANT_CONVERSION**
Use of __constant_<foo> form is discouraged for the following functions::
__constant_cpu_to_be[x]
__constant_cpu_to_le[x]
__constant_be[x]_to_cpu
__constant_le[x]_to_cpu
__constant_htons
__constant_ntohs
Using any of these outside of include/uapi/ is not preferred as using the
function without __constant_ is identical when the argument is a
constant.
In big endian systems, the macros like __constant_cpu_to_be32(x) and
cpu_to_be32(x) expand to the same expression::
#define __constant_cpu_to_be32(x) ((__force __be32)(__u32)(x))
#define __cpu_to_be32(x) ((__force __be32)(__u32)(x))
In little endian systems, the macros __constant_cpu_to_be32(x) and
cpu_to_be32(x) expand to __constant_swab32 and __swab32. __swab32
has a __builtin_constant_p check::
#define __swab32(x) \
(__builtin_constant_p((__u32)(x)) ? \
___constant_swab32(x) : \
__fswab32(x))
So ultimately they have a special case for constants.
Similar is the case with all of the macros in the list. Thus
using the __constant_... forms are unnecessarily verbose and
not preferred outside of include/uapi.
See: https://lore.kernel.org/lkml/1400106425.12666.6.camel@joe-AO725/
**DEPRECATED_API**
Usage of a deprecated RCU API is detected. It is recommended to replace
old flavourful RCU APIs by their new vanilla-RCU counterparts.
The full list of available RCU APIs can be viewed from the kernel docs.
See: https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html#full-list-of-rcu-apis
**DEPRECATED_VARIABLE**
EXTRA_{A,C,CPP,LD}FLAGS are deprecated and should be replaced by the new
flags added via commit f77bf01425b1 ("kbuild: introduce ccflags-y,
asflags-y and ldflags-y").
The following conversion scheme maybe used::
EXTRA_AFLAGS -> asflags-y
EXTRA_CFLAGS -> ccflags-y
EXTRA_CPPFLAGS -> cppflags-y
EXTRA_LDFLAGS -> ldflags-y
See:
1. https://lore.kernel.org/lkml/20070930191054.GA15876@uranus.ravnborg.org/
2. https://lore.kernel.org/lkml/1313384834-24433-12-git-send-email-lacombar@gmail.com/
3. https://www.kernel.org/doc/html/latest/kbuild/makefiles.html#compilation-flags
**DEVICE_ATTR_FUNCTIONS**
The function names used in DEVICE_ATTR is unusual.
Typically, the store and show functions are used with <attr>_store and
<attr>_show, where <attr> is a named attribute variable of the device.
Consider the following examples::
static DEVICE_ATTR(type, 0444, type_show, NULL);
static DEVICE_ATTR(power, 0644, power_show, power_store);
The function names should preferably follow the above pattern.
See: https://www.kernel.org/doc/html/latest/driver-api/driver-model/device.html#attributes
**DEVICE_ATTR_RO**
The DEVICE_ATTR_RO(name) helper macro can be used instead of
DEVICE_ATTR(name, 0444, name_show, NULL);
Note that the macro automatically appends _show to the named
attribute variable of the device for the show method.
See: https://www.kernel.org/doc/html/latest/driver-api/driver-model/device.html#attributes
**DEVICE_ATTR_RW**
The DEVICE_ATTR_RW(name) helper macro can be used instead of
DEVICE_ATTR(name, 0644, name_show, name_store);
Note that the macro automatically appends _show and _store to the
named attribute variable of the device for the show and store methods.
See: https://www.kernel.org/doc/html/latest/driver-api/driver-model/device.html#attributes
**DEVICE_ATTR_WO**
The DEVICE_AATR_WO(name) helper macro can be used instead of
DEVICE_ATTR(name, 0200, NULL, name_store);
Note that the macro automatically appends _store to the
named attribute variable of the device for the store method.
See: https://www.kernel.org/doc/html/latest/driver-api/driver-model/device.html#attributes
**DUPLICATED_SYSCTL_CONST**
Commit d91bff3011cf ("proc/sysctl: add shared variables for range
check") added some shared const variables to be used instead of a local
copy in each source file.
Consider replacing the sysctl range checking value with the shared
one in include/linux/sysctl.h. The following conversion scheme may
be used::
&zero -> SYSCTL_ZERO
&one -> SYSCTL_ONE
&int_max -> SYSCTL_INT_MAX
See:
1. https://lore.kernel.org/lkml/20190430180111.10688-1-mcroce@redhat.com/
2. https://lore.kernel.org/lkml/20190531131422.14970-1-mcroce@redhat.com/
**ENOSYS**
ENOSYS means that a nonexistent system call was called.
Earlier, it was wrongly used for things like invalid operations on
otherwise valid syscalls. This should be avoided in new code.
See: https://lore.kernel.org/lkml/5eb299021dec23c1a48fa7d9f2c8b794e967766d.1408730669.git.luto@amacapital.net/
**ENOTSUPP**
ENOTSUPP is not a standard error code and should be avoided in new patches.
EOPNOTSUPP should be used instead.
See: https://lore.kernel.org/netdev/20200510182252.GA411829@lunn.ch/
**EXPORT_SYMBOL**
EXPORT_SYMBOL should immediately follow the symbol to be exported.
**IN_ATOMIC**
in_atomic() is not for driver use so any such use is reported as an ERROR.
Also in_atomic() is often used to determine if sleeping is permitted,
but it is not reliable in this use model. Therefore its use is
strongly discouraged.
However, in_atomic() is ok for core kernel use.
See: https://lore.kernel.org/lkml/20080320201723.b87b3732.akpm@linux-foundation.org/
**LOCKDEP**
The lockdep_no_validate class was added as a temporary measure to
prevent warnings on conversion of device->sem to device->mutex.
It should not be used for any other purpose.
See: https://lore.kernel.org/lkml/1268959062.9440.467.camel@laptop/
**MALFORMED_INCLUDE**
@ -308,14 +460,21 @@ API usage
**USE_LOCKDEP**
lockdep_assert_held() annotations should be preferred over
assertions based on spin_is_locked()
See: https://www.kernel.org/doc/html/latest/locking/lockdep-design.html#annotations
**UAPI_INCLUDE**
No #include statements in include/uapi should use a uapi/ path.
**USLEEP_RANGE**
usleep_range() should be preferred over udelay(). The proper way of
using usleep_range() is mentioned in the kernel docs.
Comment style
-------------
See: https://www.kernel.org/doc/html/latest/timers/timers-howto.html#delays-information-on-the-various-kernel-delay-sleep-mechanisms
Comments
--------
**BLOCK_COMMENT_STYLE**
The comment style is incorrect. The preferred style for multi-
@ -338,8 +497,24 @@ Comment style
**C99_COMMENTS**
C99 style single line comments (//) should not be used.
Prefer the block comment style instead.
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#commenting
**DATA_RACE**
Applications of data_race() should have a comment so as to document the
reasoning behind why it was deemed safe.
See: https://lore.kernel.org/lkml/20200401101714.44781-1-elver@google.com/
**FSF_MAILING_ADDRESS**
Kernel maintainers reject new instances of the GPL boilerplate paragraph
directing people to write to the FSF for a copy of the GPL, since the
FSF has moved in the past and may do so again.
So do not write paragraphs about writing to the Free Software Foundation's
mailing address.
See: https://lore.kernel.org/lkml/20131006222342.GT19510@leaf/
Commit message
--------------
@ -347,6 +522,7 @@ Commit message
**BAD_SIGN_OFF**
The signed-off-by line does not fall in line with the standards
specified by the community.
See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1
**BAD_STABLE_ADDRESS_STYLE**
@ -368,12 +544,33 @@ Commit message
**COMMIT_MESSAGE**
The patch is missing a commit description. A brief
description of the changes made by the patch should be added.
See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes
**EMAIL_SUBJECT**
Naming the tool that found the issue is not very useful in the
subject line. A good subject line summarizes the change that
the patch brings.
See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes
**FROM_SIGN_OFF_MISMATCH**
The author's email does not match with that in the Signed-off-by:
line(s). This can be sometimes caused due to an improperly configured
email client.
This message is emitted due to any of the following reasons::
- The email names do not match.
- The email addresses do not match.
- The email subaddresses do not match.
- The email comments do not match.
**MISSING_SIGN_OFF**
The patch is missing a Signed-off-by line. A signed-off-by
line should be added according to Developer's certificate of
Origin.
See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
**NO_AUTHOR_SIGN_OFF**
@ -382,6 +579,7 @@ Commit message
end of explanation of the patch to denote that the author has
written it or otherwise has the rights to pass it on as an open
source patch.
See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
**DIFF_IN_COMMIT_MSG**
@ -389,6 +587,7 @@ Commit message
This causes problems when one tries to apply a file containing both
the changelog and the diff because patch(1) tries to apply the diff
which it found in the changelog.
See: https://lore.kernel.org/lkml/20150611134006.9df79a893e3636019ad2759e@linux-foundation.org/
**GERRIT_CHANGE_ID**
@ -431,6 +630,7 @@ Comparison style
**BOOL_COMPARISON**
Comparisons of A to true and false are better written
as A and !A.
See: https://lore.kernel.org/lkml/1365563834.27174.12.camel@joe-AO722/
**COMPARISON_TO_NULL**
@ -442,6 +642,87 @@ Comparison style
side of the test should be avoided.
Indentation and Line Breaks
---------------------------
**CODE_INDENT**
Code indent should use tabs instead of spaces.
Outside of comments, documentation and Kconfig,
spaces are never used for indentation.
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#indentation
**DEEP_INDENTATION**
Indentation with 6 or more tabs usually indicate overly indented
code.
It is suggested to refactor excessive indentation of
if/else/for/do/while/switch statements.
See: https://lore.kernel.org/lkml/1328311239.21255.24.camel@joe2Laptop/
**SWITCH_CASE_INDENT_LEVEL**
switch should be at the same indent as case.
Example::
switch (suffix) {
case 'G':
case 'g':
mem <<= 30;
break;
case 'M':
case 'm':
mem <<= 20;
break;
case 'K':
case 'k':
mem <<= 10;
fallthrough;
default:
break;
}
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#indentation
**LONG_LINE**
The line has exceeded the specified maximum length.
To use a different maximum line length, the --max-line-length=n option
may be added while invoking checkpatch.
Earlier, the default line length was 80 columns. Commit bdc48fa11e46
("checkpatch/coding-style: deprecate 80-column warning") increased the
limit to 100 columns. This is not a hard limit either and it's
preferable to stay within 80 columns whenever possible.
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings
**LONG_LINE_STRING**
A string starts before but extends beyond the maximum line length.
To use a different maximum line length, the --max-line-length=n option
may be added while invoking checkpatch.
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings
**LONG_LINE_COMMENT**
A comment starts before but extends beyond the maximum line length.
To use a different maximum line length, the --max-line-length=n option
may be added while invoking checkpatch.
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings
**TRAILING_STATEMENTS**
Trailing statements (for example after any conditional) should be
on the next line.
Statements, such as::
if (x == y) break;
should be::
if (x == y)
break;
Macros, Attributes and Symbols
------------------------------
@ -472,7 +753,7 @@ Macros, Attributes and Symbols
**BIT_MACRO**
Defines like: 1 << <digit> could be BIT(digit).
The BIT() macro is defined in include/linux/bitops.h::
The BIT() macro is defined via include/linux/bits.h::
#define BIT(nr) (1UL << (nr))
@ -492,6 +773,7 @@ Macros, Attributes and Symbols
The kernel does *not* use the ``__DATE__`` and ``__TIME__`` macros,
and enables warnings if they are used as they can lead to
non-deterministic builds.
See: https://www.kernel.org/doc/html/latest/kbuild/reproducible-builds.html#timestamps
**DEFINE_ARCH_HAS**
@ -502,8 +784,12 @@ Macros, Attributes and Symbols
want architectures able to override them with optimized ones, we
should either use weak functions (appropriate for some cases), or
the symbol that protects them should be the same symbol we use.
See: https://lore.kernel.org/lkml/CA+55aFycQ9XJvEOsiM3txHL5bjUc8CeKWJNR_H+MiicaddB42Q@mail.gmail.com/
**DO_WHILE_MACRO_WITH_TRAILING_SEMICOLON**
do {} while(0) macros should not have a trailing semicolon.
**INIT_ATTRIBUTE**
Const init definitions should use __initconst instead of
__initdata.
@ -528,6 +814,20 @@ Macros, Attributes and Symbols
...
}
**MISPLACED_INIT**
It is possible to use section markers on variables in a way
which gcc doesn't understand (or at least not the way the
developer intended)::
static struct __initdata samsung_pll_clock exynos4_plls[nr_plls] = {
does not put exynos4_plls in the .initdata section. The __initdata
marker can be virtually anywhere on the line, except right after
"struct". The preferred location is before the "=" sign if there is
one, or before the trailing ";" otherwise.
See: https://lore.kernel.org/lkml/1377655732.3619.19.camel@joe-AO722/
**MULTISTATEMENT_MACRO_USE_DO_WHILE**
Macros with multiple statements should be enclosed in a
do - while block. Same should also be the case for macros
@ -541,6 +841,10 @@ Macros, Attributes and Symbols
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#macros-enums-and-rtl
**PREFER_FALLTHROUGH**
Use the `fallthrough;` pseudo keyword instead of
`/* fallthrough */` like comments.
**WEAK_DECLARATION**
Using weak declarations like __attribute__((weak)) or __weak
can have unintended link defects. Avoid using them.
@ -551,8 +855,51 @@ Functions and Variables
**CAMELCASE**
Avoid CamelCase Identifiers.
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#naming
**CONST_CONST**
Using `const <type> const *` is generally meant to be
written `const <type> * const`.
**CONST_STRUCT**
Using const is generally a good idea. Checkpatch reads
a list of frequently used structs that are always or
almost always constant.
The existing structs list can be viewed from
`scripts/const_structs.checkpatch`.
See: https://lore.kernel.org/lkml/alpine.DEB.2.10.1608281509480.3321@hadrien/
**EMBEDDED_FUNCTION_NAME**
Embedded function names are less appropriate to use as
refactoring can cause function renaming. Prefer the use of
"%s", __func__ to embedded function names.
Note that this does not work with -f (--file) checkpatch option
as it depends on patch context providing the function name.
**FUNCTION_ARGUMENTS**
This warning is emitted due to any of the following reasons:
1. Arguments for the function declaration do not follow
the identifier name. Example::
void foo
(int bar, int baz)
This should be corrected to::
void foo(int bar, int baz)
2. Some arguments for the function definition do not
have an identifier name. Example::
void foo(int)
All arguments should have identifier names.
**FUNCTION_WITHOUT_ARGS**
Function declarations without arguments like::
@ -583,6 +930,34 @@ Functions and Variables
return bar;
Permissions
-----------
**DEVICE_ATTR_PERMS**
The permissions used in DEVICE_ATTR are unusual.
Typically only three permissions are used - 0644 (RW), 0444 (RO)
and 0200 (WO).
See: https://www.kernel.org/doc/html/latest/filesystems/sysfs.html#attributes
**EXECUTE_PERMISSIONS**
There is no reason for source files to be executable. The executable
bit can be removed safely.
**EXPORTED_WORLD_WRITABLE**
Exporting world writable sysfs/debugfs files is usually a bad thing.
When done arbitrarily they can introduce serious security bugs.
In the past, some of the debugfs vulnerabilities would seemingly allow
any local user to write arbitrary values into device registers - a
situation from which little good can be expected to emerge.
See: https://lore.kernel.org/linux-arm-kernel/cover.1296818921.git.segoon@openwall.com/
**NON_OCTAL_PERMISSIONS**
Permission bits should use 4 digit octal permissions (like 0700 or 0444).
Avoid using any other base like decimal.
Spacing and Brackets
--------------------
@ -616,7 +991,7 @@ Spacing and Brackets
1. With a type on the left::
;int [] a;
int [] a;
2. At the beginning of a line for slice initialisers::
@ -626,12 +1001,6 @@ Spacing and Brackets
= { [0...10] = 5 }
**CODE_INDENT**
Code indent should use tabs instead of spaces.
Outside of comments, documentation and Kconfig,
spaces are never used for indentation.
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#indentation
**CONCATENATED_STRING**
Concatenated elements should have a space in between.
Example::
@ -644,17 +1013,20 @@ Spacing and Brackets
**ELSE_AFTER_BRACE**
`else {` should follow the closing block `}` on the same line.
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#placing-braces-and-spaces
**LINE_SPACING**
Vertical space is wasted given the limited number of lines an
editor window can display when multiple blank lines are used.
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#spaces
**OPEN_BRACE**
The opening brace should be following the function definitions on the
next line. For any non-functional block it should be on the same line
as the last construct.
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#placing-braces-and-spaces
**POINTER_LOCATION**
@ -671,37 +1043,47 @@ Spacing and Brackets
**SPACING**
Whitespace style used in the kernel sources is described in kernel docs.
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#spaces
**SWITCH_CASE_INDENT_LEVEL**
switch should be at the same indent as case.
Example::
switch (suffix) {
case 'G':
case 'g':
mem <<= 30;
break;
case 'M':
case 'm':
mem <<= 20;
break;
case 'K':
case 'k':
mem <<= 10;
/* fall through */
default:
break;
}
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#indentation
**TRAILING_WHITESPACE**
Trailing whitespace should always be removed.
Some editors highlight the trailing whitespace and cause visual
distractions when editing files.
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#spaces
**UNNECESSARY_PARENTHESES**
Parentheses are not required in the following cases:
1. Function pointer uses::
(foo->bar)();
could be::
foo->bar();
2. Comparisons in if::
if ((foo->bar) && (foo->baz))
if ((foo == bar))
could be::
if (foo->bar && foo->baz)
if (foo == bar)
3. addressof/dereference single Lvalues::
&(foo->bar)
*(foo->bar)
could be::
&foo->bar
*foo->bar
**WHILE_AFTER_BRACE**
while should follow the closing bracket on the same line::
@ -723,17 +1105,50 @@ Others
The patch seems to be corrupted or lines are wrapped.
Please regenerate the patch file before sending it to the maintainer.
**CVS_KEYWORD**
Since linux moved to git, the CVS markers are no longer used.
So, CVS style keywords ($Id$, $Revision$, $Log$) should not be
added.
**DEFAULT_NO_BREAK**
switch default case is sometimes written as "default:;". This can
cause new cases added below default to be defective.
A "break;" should be added after empty default statement to avoid
unwanted fallthrough.
**DOS_LINE_ENDINGS**
For DOS-formatted patches, there are extra ^M symbols at the end of
the line. These should be removed.
**EXECUTE_PERMISSIONS**
There is no reason for source files to be executable. The executable
bit can be removed safely.
**DT_SCHEMA_BINDING_PATCH**
DT bindings moved to a json-schema based format instead of
freeform text.
**NON_OCTAL_PERMISSIONS**
Permission bits should use 4 digit octal permissions (like 0700 or 0444).
Avoid using any other base like decimal.
See: https://www.kernel.org/doc/html/latest/devicetree/bindings/writing-schema.html
**DT_SPLIT_BINDING_PATCH**
Devicetree bindings should be their own patch. This is because
bindings are logically independent from a driver implementation,
they have a different maintainer (even though they often
are applied via the same tree), and it makes for a cleaner history in the
DT only tree created with git-filter-branch.
See: https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
**EMBEDDED_FILENAME**
Embedding the complete filename path inside the file isn't particularly
useful as often the path is moved around and becomes incorrect.
**FILE_PATH_CHANGES**
Whenever files are added, moved, or deleted, the MAINTAINERS file
patterns can be out of sync or outdated.
So MAINTAINERS might need updating in these cases.
**MEMSET**
The memset use appears to be incorrect. This may be caused due to
badly ordered parameters. Please recheck the usage.
**NOT_UNIFIED_DIFF**
The patch file does not appear to be in unified-diff format. Please
@ -742,14 +1157,12 @@ Others
**PRINTF_0XDECIMAL**
Prefixing 0x with decimal output is defective and should be corrected.
**TRAILING_STATEMENTS**
Trailing statements (for example after any conditional) should be
on the next line.
Like::
**SPDX_LICENSE_TAG**
The source file is missing or has an improper SPDX identifier tag.
The Linux kernel requires the precise SPDX identifier in all source files,
and it is thoroughly documented in the kernel docs.
if (x == y) break;
See: https://www.kernel.org/doc/html/latest/process/license-rules.html
should be::
if (x == y)
break;
**TYPO_SPELLING**
Some words may have been misspelled. Consider reviewing them.

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

@ -447,11 +447,10 @@ When a test fails due to a failed ``kmalloc``::
When a test fails due to a missing KASAN report::
# kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629
Expected kasan_data->report_expected == kasan_data->report_found, but
kasan_data->report_expected == 1
kasan_data->report_found == 0
not ok 28 - kmalloc_double_kzfree
# kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:974
KASAN failure expected in "kfree_sensitive(ptr)", but none occurred
not ok 44 - kmalloc_double_kzfree
At the end the cumulative status of all KASAN tests is printed. On success::

8
Documentation/dev-tools/kunit/api/index.rst
View File

@ -10,7 +10,7 @@ API Reference
This section documents the KUnit kernel testing API. It is divided into the
following sections:
================================= ==============================================
:doc:`test` documents all of the standard testing API
excluding mocking or mocking related features.
================================= ==============================================
Documentation/dev-tools/kunit/api/test.rst
- documents all of the standard testing API excluding mocking
or mocking related features.

2
Documentation/dev-tools/kunit/faq.rst
View File

@ -97,7 +97,7 @@ things to try.
modules will automatically execute associated tests when loaded. Test results
can be collected from ``/sys/kernel/debug/kunit/<test suite>/results``, and
can be parsed with ``kunit.py parse``. For more details, see "KUnit on
non-UML architectures" in :doc:`usage`.
non-UML architectures" in Documentation/dev-tools/kunit/usage.rst.
If none of the above tricks help, you are always welcome to email any issues to
kunit-dev@googlegroups.com.

14
Documentation/dev-tools/kunit/index.rst
View File

@ -36,7 +36,7 @@ To make running these tests (and reading the results) easier, KUnit offers
results. This provides a quick way of running KUnit tests during development,
without requiring a virtual machine or separate hardware.
Get started now: :doc:`start`
Get started now: Documentation/dev-tools/kunit/start.rst
Why KUnit?
==========
@ -88,9 +88,9 @@ it takes to read their test log?
How do I use it?
================
* :doc:`start` - for new users of KUnit
* :doc:`tips` - for short examples of best practices
* :doc:`usage` - for a more detailed explanation of KUnit features
* :doc:`api/index` - for the list of KUnit APIs used for testing
* :doc:`kunit-tool` - for more information on the kunit_tool helper script
* :doc:`faq` - for answers to some common questions about KUnit
* Documentation/dev-tools/kunit/start.rst - for new users of KUnit
* Documentation/dev-tools/kunit/tips.rst - for short examples of best practices
* Documentation/dev-tools/kunit/usage.rst - for a more detailed explanation of KUnit features
* Documentation/dev-tools/kunit/api/index.rst - for the list of KUnit APIs used for testing
* Documentation/dev-tools/kunit/kunit-tool.rst - for more information on the kunit_tool helper script
* Documentation/dev-tools/kunit/faq.rst - for answers to some common questions about KUnit

4
Documentation/dev-tools/kunit/start.rst
View File

@ -21,7 +21,7 @@ The wrapper can be run with:
./tools/testing/kunit/kunit.py run
For more information on this wrapper (also called kunit_tool) check out the
:doc:`kunit-tool` page.
Documentation/dev-tools/kunit/kunit-tool.rst page.
Creating a .kunitconfig
-----------------------
@ -234,7 +234,7 @@ Congrats! You just wrote your first KUnit test!
Next Steps
==========
* Check out the :doc:`tips` page for tips on
* Check out the Documentation/dev-tools/kunit/tips.rst page for tips on
writing idiomatic KUnit tests.
* Optional: see the :doc:`usage` page for a more
in-depth explanation of KUnit.

5
Documentation/dev-tools/kunit/tips.rst
View File

@ -125,7 +125,8 @@ Here's a slightly in-depth example of how one could implement "mocking":
Note: here we're able to get away with using ``test->priv``, but if you wanted
something more flexible you could use a named ``kunit_resource``, see :doc:`api/test`.
something more flexible you could use a named ``kunit_resource``, see
Documentation/dev-tools/kunit/api/test.rst.
Failing the current test
------------------------
@ -185,5 +186,5 @@ Alternatively, one can take full control over the error message by using ``KUNIT
Next Steps
==========
* Optional: see the :doc:`usage` page for a more
* Optional: see the Documentation/dev-tools/kunit/usage.rst page for a more
in-depth explanation of KUnit.

8
Documentation/dev-tools/kunit/usage.rst
View File

@ -10,7 +10,7 @@ understand it. This guide assumes a working knowledge of the Linux kernel and
some basic knowledge of testing.
For a high level introduction to KUnit, including setting up KUnit for your
project, see :doc:`start`.
project, see Documentation/dev-tools/kunit/start.rst.
Organization of this document
=============================
@ -99,7 +99,8 @@ violated; however, the test will continue running, potentially trying other
expectations until the test case ends or is otherwise terminated. This is as
opposed to *assertions* which are discussed later.
To learn about more expectations supported by KUnit, see :doc:`api/test`.
To learn about more expectations supported by KUnit, see
Documentation/dev-tools/kunit/api/test.rst.
.. note::
A single test case should be pretty short, pretty easy to understand,
@ -216,7 +217,8 @@ test suite in a special linker section so that it can be run by KUnit either
after late_init, or when the test module is loaded (depending on whether the
test was built in or not).
For more information on these types of things see the :doc:`api/test`.
For more information on these types of things see the
Documentation/dev-tools/kunit/api/test.rst.
Common Patterns
===============

16
Documentation/dev-tools/testing-overview.rst
View File

@ -71,15 +71,15 @@ can be used to verify that a test is executing particular functions or lines
of code. This is useful for determining how much of the kernel is being tested,
and for finding corner-cases which are not covered by the appropriate test.
:doc:`gcov` is GCC's coverage testing tool, which can be used with the kernel
to get global or per-module coverage. Unlike KCOV, it does not record per-task
coverage. Coverage data can be read from debugfs, and interpreted using the
usual gcov tooling.
Documentation/dev-tools/gcov.rst is GCC's coverage testing tool, which can be
used with the kernel to get global or per-module coverage. Unlike KCOV, it
does not record per-task coverage. Coverage data can be read from debugfs,
and interpreted using the usual gcov tooling.
:doc:`kcov` is a feature which can be built in to the kernel to allow
capturing coverage on a per-task level. It's therefore useful for fuzzing and
other situations where information about code executed during, for example, a
single syscall is useful.
Documentation/dev-tools/kcov.rst is a feature which can be built in to the
kernel to allow capturing coverage on a per-task level. It's therefore useful
for fuzzing and other situations where information about code executed during,
for example, a single syscall is useful.
Dynamic Analysis Tools

57
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt
View File

@ -1,57 +0,0 @@
NVIDIA Tegra Activity Monitor
The activity monitor block collects statistics about the behaviour of other
components in the system. This information can be used to derive the rate at
which the external memory needs to be clocked in order to serve all requests
from the monitored clients.
Required properties:
- compatible: should be "nvidia,tegra<chip>-actmon"
- reg: offset and length of the register set for the device
- interrupts: standard interrupt property
- clocks: Must contain a phandle and clock specifier pair for each entry in
clock-names. See ../../clock/clock-bindings.txt for details.
- clock-names: Must include the following entries:
- actmon
- emc
- resets: Must contain an entry for each entry in reset-names. See
../../reset/reset.txt for details.
- reset-names: Must include the following entries:
- actmon
- operating-points-v2: See ../bindings/opp/opp.txt for details.
- interconnects: Should contain entries for memory clients sitting on
MC->EMC memory interconnect path.
- interconnect-names: Should include name of the interconnect path for each
interconnect entry. Consult TRM documentation for
information about available memory clients, see MEMORY
CONTROLLER section.
For each opp entry in 'operating-points-v2' table:
- opp-supported-hw: bitfield indicating SoC speedo ID mask
- opp-peak-kBps: peak bandwidth of the memory channel
Example:
dfs_opp_table: opp-table {
compatible = "operating-points-v2";
opp@12750000 {
opp-hz = /bits/ 64 <12750000>;
opp-supported-hw = <0x000F>;
opp-peak-kBps = <51000>;
};
...
};
actmon@6000c800 {
compatible = "nvidia,tegra124-actmon";
reg = <0x0 0x6000c800 0x0 0x400>;
interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&tegra_car TEGRA124_CLK_ACTMON>,
<&tegra_car TEGRA124_CLK_EMC>;
clock-names = "actmon", "emc";
resets = <&tegra_car 119>;
reset-names = "actmon";
operating-points-v2 = <&dfs_opp_table>;
interconnects = <&mc TEGRA124_MC_MPCORER &emc>;
interconnect-names = "cpu";
};

50
Documentation/devicetree/bindings/crypto/cortina,sl3516-crypto.yaml Normal file
View File

@ -0,0 +1,50 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/crypto/cortina,sl3516-crypto.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: SL3516 cryptographic offloader driver
maintainers:
- Corentin Labbe <clabbe@baylibre.com>
properties:
compatible:
enum:
- cortina,sl3516-crypto
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
resets:
maxItems: 1
required:
- compatible
- reg
- interrupts
- clocks
- resets
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/clock/cortina,gemini-clock.h>
#include <dt-bindings/reset/cortina,gemini-reset.h>
crypto@62000000 {
compatible = "cortina,sl3516-crypto";
reg = <0x62000000 0x10000>;
interrupts = <7 IRQ_TYPE_EDGE_RISING>;
resets = <&syscon GEMINI_RESET_SECURITY>;
clocks = <&syscon GEMINI_CLK_GATE_SECURITY>;
};

47
Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml Normal file
View File

@ -0,0 +1,47 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2018 Linaro Ltd.
%YAML 1.2
---
$id: "http://devicetree.org/schemas/crypto/intel,ixp4xx-crypto.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Intel IXP4xx cryptographic engine
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |
The Intel IXP4xx cryptographic engine makes use of the IXP4xx NPE
(Network Processing Engine). Since it is not a device on its own
it is defined as a subnode of the NPE, if crypto support is
available on the platform.
properties:
compatible:
const: intel,ixp4xx-crypto
intel,npe-handle:
$ref: '/schemas/types.yaml#/definitions/phandle-array'
maxItems: 1
description: phandle to the NPE this crypto engine is using, the cell
describing the NPE instance to be used.
queue-rx:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
description: phandle to the RX queue on the NPE, the cell describing
the queue instance to be used.
queue-txready:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
description: phandle to the TX READY queue on the NPE, the cell describing
the queue instance to be used.
required:
- compatible
- intel,npe-handle
- queue-rx
- queue-txready
additionalProperties: false

126
Documentation/devicetree/bindings/devfreq/nvidia,tegra30-actmon.yaml Normal file
View File

@ -0,0 +1,126 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/devfreq/nvidia,tegra30-actmon.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra30 Activity Monitor
maintainers:
- Dmitry Osipenko <digetx@gmail.com>
- Jon Hunter <jonathanh@nvidia.com>
- Thierry Reding <thierry.reding@gmail.com>
description: |
The activity monitor block collects statistics about the behaviour of other
components in the system. This information can be used to derive the rate at
which the external memory needs to be clocked in order to serve all requests
from the monitored clients.
properties:
compatible:
enum:
- nvidia,tegra30-actmon
- nvidia,tegra114-actmon
- nvidia,tegra124-actmon
- nvidia,tegra210-actmon
reg:
maxItems: 1
clocks:
maxItems: 2
clock-names:
items:
- const: actmon
- const: emc
resets:
maxItems: 1
reset-names:
items:
- const: actmon
interrupts:
maxItems: 1
interconnects:
minItems: 1
maxItems: 12
interconnect-names:
minItems: 1
maxItems: 12
description:
Should include name of the interconnect path for each interconnect
entry. Consult TRM documentation for information about available
memory clients, see MEMORY CONTROLLER and ACTIVITY MONITOR sections.
operating-points-v2:
description:
Should contain freqs and voltages and opp-supported-hw property, which
is a bitfield indicating SoC speedo ID mask.
"#cooling-cells":
const: 2
required:
- compatible
- reg
- clocks
- clock-names
- resets
- reset-names
- interrupts
- interconnects
- interconnect-names
- operating-points-v2
- "#cooling-cells"
additionalProperties: false
examples:
- |
#include <dt-bindings/memory/tegra30-mc.h>
mc: memory-controller@7000f000 {
compatible = "nvidia,tegra30-mc";
reg = <0x7000f000 0x400>;
clocks = <&clk 32>;
clock-names = "mc";
interrupts = <0 77 4>;
#iommu-cells = <1>;
#reset-cells = <1>;
#interconnect-cells = <1>;
};
emc: external-memory-controller@7000f400 {
compatible = "nvidia,tegra30-emc";
reg = <0x7000f400 0x400>;
interrupts = <0 78 4>;
clocks = <&clk 57>;
nvidia,memory-controller = <&mc>;
operating-points-v2 = <&dvfs_opp_table>;
power-domains = <&domain>;
#interconnect-cells = <0>;
};
actmon@6000c800 {
compatible = "nvidia,tegra30-actmon";
reg = <0x6000c800 0x400>;
interrupts = <0 45 4>;
clocks = <&clk 119>, <&clk 57>;
clock-names = "actmon", "emc";
resets = <&rst 119>;
reset-names = "actmon";
operating-points-v2 = <&dvfs_opp_table>;
interconnects = <&mc TEGRA30_MC_MPCORER &emc>;
interconnect-names = "cpu-read";
#cooling-cells = <2>;
};

22
Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml
View File

@ -26,9 +26,16 @@ properties:
reg:
items:
- description: NPE0 register range
- description: NPE1 register range
- description: NPE2 register range
- description: NPE0 (NPE-A) register range
- description: NPE1 (NPE-B) register range
- description: NPE2 (NPE-C) register range
crypto:
$ref: /schemas/crypto/intel,ixp4xx-crypto.yaml#
type: object
description: Optional node for the embedded crypto engine, the node
should be named with the instance number of the NPE engine used for
the crypto engine.
required:
- compatible
@ -38,8 +45,15 @@ additionalProperties: false
examples:
- |
npe@c8006000 {
npe: npe@c8006000 {
compatible = "intel,ixp4xx-network-processing-engine";
reg = <0xc8006000 0x1000>, <0xc8007000 0x1000>, <0xc8008000 0x1000>;
crypto {
compatible = "intel,ixp4xx-crypto";
intel,npe-handle = <&npe 2>;
queue-rx = <&qmgr 30>;
queue-txready = <&qmgr 29>;
};
};
...

1
Documentation/devicetree/bindings/hwmon/lm75.yaml
View File

@ -30,6 +30,7 @@ properties:
- st,stds75
- st,stlm75
- microchip,tcn75
- ti,tmp1075
- ti,tmp100
- ti,tmp101
- ti,tmp105

13
Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
View File

@ -145,6 +145,19 @@ properties:
required:
- affinity
clocks:
maxItems: 1
clock-names:
items:
- const: aclk
power-domains:
maxItems: 1
resets:
maxItems: 1
dependencies:
mbi-ranges: [ msi-controller ]
msi-controller: [ mbi-ranges ]

1
Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml
View File

@ -29,6 +29,7 @@ properties:
- renesas,intc-ex-r8a774c0 # RZ/G2E
- renesas,intc-ex-r8a7795 # R-Car H3
- renesas,intc-ex-r8a7796 # R-Car M3-W
- renesas,intc-ex-r8a77961 # R-Car M3-W+
- renesas,intc-ex-r8a77965 # R-Car M3-N
- renesas,intc-ex-r8a77970 # R-Car V3M
- renesas,intc-ex-r8a77980 # R-Car V3H

114
Documentation/devicetree/bindings/media/atmel,isc.yaml Normal file
View File

@ -0,0 +1,114 @@
# SPDX-License-Identifier: GPL-2.0-only
# Copyright (C) 2016-2021 Microchip Technology, Inc.
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/atmel,isc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Atmel Image Sensor Controller (ISC)
maintainers:
- Eugen Hristev <eugen.hristev@microchip.com>
description: |
The Image Sensor Controller (ISC) device provides the video input capabilities for the
Atmel/Microchip AT91 SAMA family of devices.
The ISC has a single parallel input that supports RAW Bayer, RGB or YUV video,
with both external synchronization and BT.656 synchronization for the latter.
properties:
compatible:
const: atmel,sama5d2-isc
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
minItems: 3
maxItems: 3
clock-names:
items:
- const: hclock
- const: iscck
- const: gck
'#clock-cells':
const: 0
clock-output-names:
const: isc-mck
port:
$ref: /schemas/graph.yaml#/properties/port
description:
Input port node, single endpoint describing the input pad.
properties:
endpoint:
$ref: video-interfaces.yaml#
properties:
remote-endpoint: true
bus-width:
enum: [8, 9, 10, 11, 12]
default: 12
hsync-active:
enum: [0, 1]
default: 1
vsync-active:
enum: [0, 1]
default: 1
pclk-sample:
enum: [0, 1]
default: 1
required:
- remote-endpoint
additionalProperties: false
additionalProperties: false
required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
- clock-output-names
- port
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
isc: isc@f0008000 {
compatible = "atmel,sama5d2-isc";
reg = <0xf0008000 0x4000>;
interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>;
clocks = <&isc_clk>, <&iscck>, <&isc_gclk>;
clock-names = "hclock", "iscck", "gck";
#clock-cells = <0>;
clock-output-names = "isc-mck";
port {
isc_0: endpoint {
remote-endpoint = <&ov7740_0>;
hsync-active = <1>;
vsync-active = <0>;
pclk-sample = <1>;
bus-width = <8>;
};
};
};

65
Documentation/devicetree/bindings/media/atmel-isc.txt
View File

@ -1,65 +0,0 @@
Atmel Image Sensor Controller (ISC)
----------------------------------------------
Required properties for ISC:
- compatible
Must be "atmel,sama5d2-isc".
- reg
Physical base address and length of the registers set for the device.
- interrupts
Should contain IRQ line for the ISC.
- clocks
List of clock specifiers, corresponding to entries in
the clock-names property;
Please refer to clock-bindings.txt.
- clock-names
Required elements: "hclock", "iscck", "gck".
- #clock-cells
Should be 0.
- clock-output-names
Should be "isc-mck".
- pinctrl-names, pinctrl-0
Please refer to pinctrl-bindings.txt.
ISC supports a single port node with parallel bus. It should contain one
'port' child node with child 'endpoint' node. Please refer to the bindings
defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
Example:
isc: isc@f0008000 {
compatible = "atmel,sama5d2-isc";
reg = <0xf0008000 0x4000>;
interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>;
clocks = <&isc_clk>, <&iscck>, <&isc_gclk>;
clock-names = "hclock", "iscck", "gck";
#clock-cells = <0>;
clock-output-names = "isc-mck";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_isc_base &pinctrl_isc_data_8bit &pinctrl_isc_data_9_10 &pinctrl_isc_data_11_12>;
port {
isc_0: endpoint {
remote-endpoint = <&ov7740_0>;
hsync-active = <1>;
vsync-active = <0>;
pclk-sample = <1>;
};
};
};
i2c1: i2c@fc028000 {
ov7740: camera@21 {
compatible = "ovti,ov7740";
reg = <0x21>;
clocks = <&isc>;
clock-names = "xvclk";
assigned-clocks = <&isc>;
assigned-clock-rates = <24000000>;
port {
ov7740_0: endpoint {
remote-endpoint = <&isc_0>;
};
};
};
};

67
Documentation/devicetree/bindings/media/i2c/rda,rda5807.yaml Normal file
View File

@ -0,0 +1,67 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/rda,rda5807.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Unisoc Communications RDA5807 FM radio receiver
maintainers:
- Paul Cercueil <paul@crapouillou.net>
properties:
compatible:
enum:
- rda,rda5807
reg:
description: I2C address.
maxItems: 1
power-supply: true
rda,lnan:
description: Use LNAN input port.
type: boolean
rda,lnap:
description: Use LNAP input port.
type: boolean
rda,analog-out:
description: Enable analog audio output.
type: boolean
rda,i2s-out:
description: Enable I2S digital audio output.
type: boolean
rda,lna-microamp:
description: LNA working current, in micro-amperes.
default: 2500
enum: [1800, 2100, 2500, 3000]
required:
- compatible
- reg
- power-supply
additionalProperties: false
examples:
- |
i2c0 {
#address-cells = <1>;
#size-cells = <0>;
radio@11 {
compatible = "rda,rda5807";
reg = <0x11>;
power-supply = <&ldo6>;
rda,lnan;
rda,lnap;
rda,analog-out;
};
};

2
Documentation/devicetree/bindings/media/mediatek-vcodec.txt
View File

@ -9,6 +9,7 @@ Required properties:
"mediatek,mt8173-vcodec-enc" for mt8173 avc encoder.
"mediatek,mt8183-vcodec-enc" for MT8183 encoder.
"mediatek,mt8173-vcodec-dec" for MT8173 decoder.
"mediatek,mt8192-vcodec-enc" for MT8192 encoder.
- reg : Physical base address of the video codec registers and length of
memory mapped region.
- interrupts : interrupt number to the cpu.
@ -22,6 +23,7 @@ Required properties:
- iommus : should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
for details.
- dma-ranges : describes the dma address range space that the codec hw access.
One of the two following nodes:
- mediatek,vpu : the node of the video processor unit, if using VPU.
- mediatek,scp : the node of the SCP unit, if using SCP.

47
Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml Normal file
View File

@ -0,0 +1,47 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/media/microchip,sama5d4-vdec.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Hantro G1 VPU codec implemented on Microchip SAMA5D4 SoCs
maintainers:
- Emil Velikov <emil.velikov@collabora.com>
description:
Hantro G1 video decode accelerator present on Microchip SAMA5D4 SoCs.
properties:
compatible:
const: microchip,sama5d4-vdec
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
required:
- compatible
- reg
- interrupts
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/at91.h>
#include <dt-bindings/interrupt-controller/irq.h>
vdec0: vdec@300000 {
compatible = "microchip,sama5d4-vdec";
reg = <0x00300000 0x100000>;
interrupts = <19 IRQ_TYPE_LEVEL_HIGH 4>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 19>;
};

129
Documentation/devicetree/bindings/media/microchip,xisc.yaml Normal file
View File

@ -0,0 +1,129 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2021 Microchip Technology, Inc.
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/microchip,xisc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip eXtended Image Sensor Controller (XISC)
maintainers:
- Eugen Hristev <eugen.hristev@microchip.com>
description: |
The eXtended Image Sensor Controller (XISC) device provides the video input capabilities for the
Microchip AT91 SAM family of devices.
The XISC has a single internal parallel input that supports RAW Bayer, RGB or YUV video.
The source can be either a demuxer from a CSI2 type of bus, or a simple direct bridge to a
parallel sensor.
The XISC provides one clock output that is used to clock the demuxer/bridge.
properties:
compatible:
const: microchip,sama7g5-isc
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
clock-names:
items:
- const: hclock
'#clock-cells':
const: 0
clock-output-names:
const: isc-mck
microchip,mipi-mode:
type: boolean
description:
As the XISC is usually connected to a demux/bridge, the XISC receives
the same type of input, however, it should be aware of the type of
signals received. The mipi-mode enables different internal handling
of the data and clock lines.
port:
$ref: /schemas/graph.yaml#/properties/port
description:
Input port node, single endpoint describing the input pad.
properties:
endpoint:
$ref: video-interfaces.yaml#
properties:
bus-type:
enum: [5, 6]
remote-endpoint: true
bus-width:
enum: [8, 9, 10, 11, 12]
default: 12
hsync-active:
enum: [0, 1]
default: 1
vsync-active:
enum: [0, 1]
default: 1
pclk-sample:
enum: [0, 1]
default: 1
required:
- remote-endpoint
- bus-type
additionalProperties: false
additionalProperties: false
required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
- clock-output-names
- port
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/at91.h>
#include <dt-bindings/interrupt-controller/irq.h>
xisc: xisc@e1408000 {
compatible = "microchip,sama7g5-isc";
reg = <0xe1408000 0x2000>;
interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 56>;
clock-names = "hclock";
#clock-cells = <0>;
clock-output-names = "isc-mck";
port {
xisc_in: endpoint {
bus-type = <5>; /* Parallel */
remote-endpoint = <&csi2dc_out>;
hsync-active = <1>;
vsync-active = <1>;
bus-width = <12>;
};
};
};

109
Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
View File

@ -4,15 +4,17 @@
$id: http://devicetree.org/schemas/media/nxp,imx7-mipi-csi2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP i.MX7 MIPI CSI-2 receiver
title: NXP i.MX7 and i.MX8 MIPI CSI-2 receiver
maintainers:
- Rui Miguel Silva <rmfrfs@gmail.com>
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
description: |-
The NXP i.MX7 SoC family includes a MIPI CSI-2 receiver IP core, documented
as "CSIS V3.3". The IP core seems to originate from Samsung, and may be
compatible with some of the Exynos4 ad S5P SoCs.
The NXP i.MX7 and i.MX8 families contain SoCs that include a MIPI CSI-2
receiver IP core named CSIS. The IP core originates from Samsung, and may be
compatible with some of the Exynos4 and S5P SoCs. i.MX7 SoCs use CSIS version
3.3, and i.MX8 SoCs use CSIS version 3.6.3.
While the CSI-2 receiver is separate from the MIPI D-PHY IP core, the PHY is
completely wrapped by the CSIS and doesn't expose a control interface of its
@ -20,7 +22,9 @@ description: |-
properties:
compatible:
const: fsl,imx7-mipi-csi2
enum:
- fsl,imx7-mipi-csi2
- fsl,imx8mm-mipi-csi2
reg:
maxItems: 1
@ -29,16 +33,20 @@ properties:
maxItems: 1
clocks:
minItems: 3
items:
- description: The peripheral clock (a.k.a. APB clock)
- description: The external clock (optionally used as the pixel clock)
- description: The MIPI D-PHY clock
- description: The AXI clock
clock-names:
minItems: 3
items:
- const: pclk
- const: wrap
- const: phy
- const: axi
power-domains:
maxItems: 1
@ -71,16 +79,30 @@ properties:
properties:
data-lanes:
oneOf:
- items:
- const: 1
- items:
- const: 1
- const: 2
items:
minItems: 1
maxItems: 4
items:
- const: 1
- const: 2
- const: 3
- const: 4
required:
- data-lanes
allOf:
- if:
properties:
compatible:
contains:
const: fsl,imx7-mipi-csi2
then:
properties:
data-lanes:
items:
maxItems: 2
port@1:
$ref: /schemas/graph.yaml#/properties/port
description:
@ -93,12 +115,29 @@ required:
- clocks
- clock-names
- power-domains
- phy-supply
- resets
- ports
additionalProperties: false
allOf:
- if:
properties:
compatible:
contains:
const: fsl,imx7-mipi-csi2
then:
required:
- phy-supply
- resets
else:
properties:
clocks:
minItems: 4
clock-names:
minItems: 4
phy-supply: false
resets: false
examples:
- |
#include <dt-bindings/clock/imx7d-clock.h>
@ -106,7 +145,7 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/reset/imx7-reset.h>
mipi_csi: mipi-csi@30750000 {
mipi-csi@30750000 {
compatible = "fsl,imx7-mipi-csi2";
reg = <0x30750000 0x10000>;
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
@ -144,4 +183,46 @@ examples:
};
};
- |
#include <dt-bindings/clock/imx8mm-clock.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
mipi-csi@32e30000 {
compatible = "fsl,imx8mm-mipi-csi2";
reg = <0x32e30000 0x1000>;
interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <333000000>;
clocks = <&clk IMX8MM_CLK_DISP_APB_ROOT>,
<&clk IMX8MM_CLK_CSI1_ROOT>,
<&clk IMX8MM_CLK_CSI1_PHY_REF>,
<&clk IMX8MM_CLK_DISP_AXI_ROOT>;
clock-names = "pclk", "wrap", "phy", "axi";
power-domains = <&mipi_pd>;
status = "disabled";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
imx8mm_mipi_csi_in: endpoint {
remote-endpoint = <&imx477_out>;
data-lanes = <1 2 3 4>;
};
};
port@1 {
reg = <1>;
imx8mm_mipi_csi_out: endpoint {
remote-endpoint = <&csi_in>;
};
};
};
};
...

2
Documentation/devicetree/bindings/media/rc.yaml
View File

@ -45,6 +45,7 @@ properties:
- rc-cec
- rc-cinergy
- rc-cinergy-1400
- rc-ct-90405
- rc-d680-dmb
- rc-delock-61959
- rc-dib0700-nec
@ -125,7 +126,6 @@ properties:
- rc-snapstream-firefly
- rc-streamzap
- rc-su3000
- rc-tango
- rc-tanix-tx3mini
- rc-tanix-tx5max
- rc-tbs-nec

1
Documentation/devicetree/bindings/media/renesas,csi2.yaml
View File

@ -25,6 +25,7 @@ properties:
- renesas,r8a774e1-csi2 # RZ/G2H
- renesas,r8a7795-csi2 # R-Car H3
- renesas,r8a7796-csi2 # R-Car M3-W
- renesas,r8a77961-csi2 # R-Car M3-W+
- renesas,r8a77965-csi2 # R-Car M3-N
- renesas,r8a77970-csi2 # R-Car V3M
- renesas,r8a77980-csi2 # R-Car V3H

196
Documentation/devicetree/bindings/media/renesas,isp.yaml Normal file
View File

@ -0,0 +1,196 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
# Copyright (C) 2021 Renesas Electronics Corp.
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/renesas,isp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas R-Car ISP Channel Selector
maintainers:
- Niklas Söderlund <niklas.soderlund@ragnatech.se>
description:
The R-Car ISP Channel Selector provides MIPI CSI-2 VC and DT filtering
capabilities for the Renesas R-Car family of devices. It is used in
conjunction with the R-Car VIN and CSI-2 modules, which provides the video
capture capabilities.
properties:
compatible:
items:
- enum:
- renesas,r8a779a0-isp # V3U
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
power-domains:
maxItems: 1
resets:
maxItems: 1
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description:
Input port node, multiple endpoints describing the connected R-Car
CSI-2 receivers.
port@1:
$ref: /schemas/graph.yaml#/properties/port
description:
Single endpoint describing the R-Car VIN connected to output port 0.
port@2:
$ref: /schemas/graph.yaml#/properties/port
description:
Single endpoint describing the R-Car VIN connected to output port 1.
port@3:
$ref: /schemas/graph.yaml#/properties/port
description:
Single endpoint describing the R-Car VIN connected to output port 2.
port@4:
$ref: /schemas/graph.yaml#/properties/port
description:
Single endpoint describing the R-Car VIN connected to output port 3.
port@5:
$ref: /schemas/graph.yaml#/properties/port
description:
Single endpoint describing the R-Car VIN connected to output port 4.
port@6:
$ref: /schemas/graph.yaml#/properties/port
description:
Single endpoint describing the R-Car VIN connected to output port 5.
port@7:
$ref: /schemas/graph.yaml#/properties/port
description:
Single endpoint describing the R-Car VIN connected to output port 6.
port@8:
$ref: /schemas/graph.yaml#/properties/port
description:
Single endpoint describing the R-Car VIN connected to output port 7.
required:
- port@0
- port@1
- port@2
- port@3
- port@4
- port@5
- port@6
- port@7
- port@8
required:
- compatible
- reg
- interrupts
- clocks
- power-domains
- resets
- ports
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/r8a779a0-cpg-mssr.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a779a0-sysc.h>
isp1: isp@fed20000 {
compatible = "renesas,r8a779a0-isp";
reg = <0xfed20000 0x10000>;
interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 613>;
power-domains = <&sysc R8A779A0_PD_A3ISP01>;
resets = <&cpg 613>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
isp1csi41: endpoint@1 {
reg = <1>;
remote-endpoint = <&csi41isp1>;
};
};
port@1 {
reg = <1>;
isp1vin08: endpoint {
remote-endpoint = <&vin08isp1>;
};
};
port@2 {
reg = <2>;
isp1vin09: endpoint {
remote-endpoint = <&vin09isp1>;
};
};
port@3 {
reg = <3>;
isp1vin10: endpoint {
remote-endpoint = <&vin10isp1>;
};
};
port@4 {
reg = <4>;
isp1vin11: endpoint {
remote-endpoint = <&vin11isp1>;
};
};
port@5 {
reg = <5>;
isp1vin12: endpoint {
remote-endpoint = <&vin12isp1>;
};
};
port@6 {
reg = <6>;
isp1vin13: endpoint {
remote-endpoint = <&vin13isp1>;
};
};
port@7 {
reg = <7>;
isp1vin14: endpoint {
remote-endpoint = <&vin14isp1>;
};
};
port@8 {
reg = <8>;
isp1vin15: endpoint {
remote-endpoint = <&vin15isp1>;
};
};
};
};

27
Documentation/devicetree/bindings/media/renesas,vin.yaml
View File

@ -46,11 +46,13 @@ properties:
- renesas,vin-r8a7779 # R-Car H1
- renesas,vin-r8a7795 # R-Car H3
- renesas,vin-r8a7796 # R-Car M3-W
- renesas,vin-r8a77961 # R-Car M3-W+
- renesas,vin-r8a77965 # R-Car M3-N
- renesas,vin-r8a77970 # R-Car V3M
- renesas,vin-r8a77980 # R-Car V3H
- renesas,vin-r8a77990 # R-Car E3
- renesas,vin-r8a77995 # R-Car D3
- renesas,vin-r8a779a0 # R-Car V3U
reg:
maxItems: 1
@ -111,7 +113,7 @@ properties:
description: VIN channel number
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 15
maximum: 31
ports:
$ref: /schemas/graph.yaml#/properties/ports
@ -187,6 +189,29 @@ properties:
- required:
- endpoint@3
port@2:
$ref: /schemas/graph.yaml#/properties/port
description:
Input port node, multiple endpoints describing all the R-Car ISP
modules connected the VIN.
properties:
endpoint@0:
$ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to ISP0.
endpoint@1:
$ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to ISP1.
endpoint@2:
$ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to ISP2.
endpoint@3:
$ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to ISP3.
required:
- compatible
- reg

10
Documentation/devicetree/bindings/media/rockchip,vdec.yaml
View File

@ -15,7 +15,11 @@ description: |-
properties:
compatible:
const: rockchip,rk3399-vdec
oneOf:
- const: rockchip,rk3399-vdec
- items:
- const: rockchip,rk3228-vdec
- const: rockchip,rk3399-vdec
reg:
maxItems: 1
@ -37,6 +41,10 @@ properties:
- const: cabac
- const: core
assigned-clocks: true
assigned-clock-rates: true
power-domains:
maxItems: 1

33
Documentation/devicetree/bindings/media/rockchip-vpu.yaml
View File

@ -15,10 +15,19 @@ description:
properties:
compatible:
enum:
- rockchip,rk3288-vpu
- rockchip,rk3328-vpu
- rockchip,rk3399-vpu
oneOf:
- enum:
- rockchip,rk3036-vpu
- rockchip,rk3066-vpu
- rockchip,rk3288-vpu
- rockchip,rk3328-vpu
- rockchip,rk3399-vpu
- items:
- const: rockchip,rk3188-vpu
- const: rockchip,rk3066-vpu
- items:
- const: rockchip,rk3228-vpu
- const: rockchip,rk3399-vpu
reg:
maxItems: 1
@ -35,12 +44,20 @@ properties:
- const: vdpu
clocks:
maxItems: 2
oneOf:
- maxItems: 2
- maxItems: 4
clock-names:
items:
- const: aclk
- const: hclk
oneOf:
- items:
- const: aclk
- const: hclk
- items:
- const: aclk_vdpu
- const: hclk_vdpu
- const: aclk_vepu
- const: hclk_vepu
power-domains:
maxItems: 1

21
Documentation/devicetree/bindings/media/tango-ir.txt
View File

@ -1,21 +0,0 @@
Sigma Designs Tango IR NEC/RC-5/RC-6 decoder (SMP86xx and SMP87xx)
Required properties:
- compatible: "sigma,smp8642-ir"
- reg: address/size of NEC+RC5 area, address/size of RC6 area
- interrupts: spec for IR IRQ
- clocks: spec for IR clock (typically the crystal oscillator)
Optional properties:
- linux,rc-map-name: see Documentation/devicetree/bindings/media/rc.txt
Example:
ir@10518 {
compatible = "sigma,smp8642-ir";
reg = <0x10518 0x18>, <0x105e0 0x1c>;
interrupts = <21 IRQ_TYPE_EDGE_RISING>;
clocks = <&xtal>;
};

1
Documentation/devicetree/bindings/mfd/mt6397.txt
View File

@ -21,6 +21,7 @@ Required properties:
compatible:
"mediatek,mt6323" for PMIC MT6323
"mediatek,mt6358" for PMIC MT6358
"mediatek,mt6359" for PMIC MT6359
"mediatek,mt6397" for PMIC MT6397
Optional subnodes:

1
Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml
View File

@ -21,6 +21,7 @@ properties:
- brcm,bcm2711-emmc2
- brcm,sdhci-iproc-cygnus
- brcm,sdhci-iproc
- brcm,bcm7211a0-sdhci
reg:
minItems: 1

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