mirrors/linux
2
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2026-08-23 08:25:58 -04:00
Code Issues Packages Projects Releases Wiki Activity

Merge drm/drm-next into drm-misc-next

Browse Source 
Backmerging to get drm-misc-next to v7.2-rc1.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
This commit is contained in:
Thomas Zimmermann
2026-06-30 10:16:00 +02:00
parent 3b3bce4a69 dc59e4fea9
commit 827b9aabd3
13026 changed files with 704703 additions and 227878 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.clang-format
View File

@@ -481,6 +481,7 @@ ForEachMacros:
- 'genradix_for_each'
- 'genradix_for_each_from'
- 'genradix_for_each_reverse'
- 'guard'
- 'hash_for_each'
- 'hash_for_each_possible'
- 'hash_for_each_possible_rcu'
@@ -674,6 +675,7 @@ ForEachMacros:
- 'rq_list_for_each'
- 'rq_list_for_each_safe'
- 'sample_read_group__for_each'
- 'scoped_guard'
- 'scsi_for_each_prot_sg'
- 'scsi_for_each_sg'
- 'sctp_for_each_hentry'

6
.gitignore vendored
View File

@@ -49,6 +49,7 @@
*.s
*.so
*.so.dbg
*.spdx.json
*.su
*.symtypes
*.tab.[ch]
@@ -57,6 +58,7 @@
*.zst
Module.symvers
dtbs-list
builtin.order
modules.order
#
@@ -68,6 +70,7 @@ modules.order
/vmlinux.32
/vmlinux.map
/vmlinux.symvers
/vmlinux.thinlto-index
/vmlinux.unstripped
/vmlinux-gdb.py
/vmlinuz
@@ -186,5 +189,8 @@ sphinx_*/
# Rust analyzer configuration
/rust-project.json
# rustc error message long types
*.long-type-*.txt
# bc language scripts (not LLVM bitcode)
!kernel/time/timeconst.bc

35
.mailmap
View File

@@ -36,13 +36,14 @@ Alexander Lobakin <alobakin@pm.me> <bloodyreaper@yandex.ru>
Alexander Mikhalitsyn <alexander@mihalicyn.com> <alexander.mikhalitsyn@virtuozzo.com>
Alexander Mikhalitsyn <alexander@mihalicyn.com> <aleksandr.mikhalitsyn@canonical.com>
Alexander Mikhalitsyn <alexander@mihalicyn.com> <aleksandr.mikhalitsyn@futurfusion.io>
Alexander Sverdlin <alexander.sverdlin@gmail.com> <alexander.sverdlin.ext@nsn.com>
Alexander Sverdlin <alexander.sverdlin@gmail.com> <alexander.sverdlin@gmx.de>
Alexander Sverdlin <alexander.sverdlin@gmail.com> <alexander.sverdlin@nokia.com>
Alexander Sverdlin <alexander.sverdlin@gmail.com> <alexander.sverdlin@nsn.com>
Alexander Sverdlin <alexander.sverdlin@gmail.com> <alexander.sverdlin@siemens.com>
Alexander Sverdlin <alexander.sverdlin@gmail.com> <alexander.sverdlin@sysgo.com>
Alexander Sverdlin <alexander.sverdlin@gmail.com> <subaparts@yandex.ru>
Alexander Sverdlin <alex@sverdlin.org> <alexander.sverdlin.ext@nsn.com>
Alexander Sverdlin <alex@sverdlin.org> <alexander.sverdlin@gmail.com>
Alexander Sverdlin <alex@sverdlin.org> <alexander.sverdlin@gmx.de>
Alexander Sverdlin <alex@sverdlin.org> <alexander.sverdlin@nokia.com>
Alexander Sverdlin <alex@sverdlin.org> <alexander.sverdlin@nsn.com>
Alexander Sverdlin <alex@sverdlin.org> <alexander.sverdlin@sysgo.com>
Alexander Sverdlin <alex@sverdlin.org> <asv@kernel.org>
Alexander Sverdlin <alex@sverdlin.org> <subaparts@yandex.ru>
Alexandre Belloni <alexandre.belloni@bootlin.com> <alexandre.belloni@free-electrons.com>
Alexandre Ghiti <alex@ghiti.fr> <alexandre.ghiti@canonical.com>
Alexei Avshalom Lazar <quic_ailizaro@quicinc.com> <ailizaro@codeaurora.org>
@@ -117,6 +118,7 @@ Asutosh Das <quic_asutoshd@quicinc.com> <asutoshd@codeaurora.org>
Atish Patra <atish.patra@linux.dev> <atishp@atishpatra.org>
Atish Patra <atish.patra@linux.dev> <atish.patra@wdc.com>
Avaneesh Kumar Dwivedi <quic_akdwived@quicinc.com> <akdwived@codeaurora.org>
Avri Altman <avri.altman@sandisk.com> <avri.altman@wdc.com>
Axel Dyks <xl@xlsigned.net>
Axel Lin <axel.lin@gmail.com>
Balakrishna Godavarthi <quic_bgodavar@quicinc.com> <bgodavar@codeaurora.org>
@@ -126,6 +128,7 @@ Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang@linaro.org>
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang@spreadtrum.com>
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang@unisoc.com>
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang7@gmail.com>
Baoquan He <baoquan.he@linux.dev> <bhe@redhat.com>
Barry Song <baohua@kernel.org> <21cnbao@gmail.com>
Barry Song <baohua@kernel.org> <v-songbaohua@oppo.com>
Barry Song <baohua@kernel.org> <song.bao.hua@hisilicon.com>
@@ -201,9 +204,9 @@ Christophe Ricard <christophe.ricard@gmail.com>
Christopher Obbard <christopher.obbard@linaro.org> <chris.obbard@collabora.com>
Christoph Hellwig <hch@lst.de>
Christoph Manszewski <c.manszewski@gmail.com> <christoph.manszewski@intel.com>
Chuck Lever <chuck.lever@oracle.com> <cel@kernel.org>
Chuck Lever <chuck.lever@oracle.com> <cel@netapp.com>
Chuck Lever <chuck.lever@oracle.com> <cel@citi.umich.edu>
Chuck Lever <cel@kernel.org> <chuck.lever@oracle.com>
Chuck Lever <cel@kernel.org> <cel@netapp.com>
Chuck Lever <cel@kernel.org> <cel@citi.umich.edu>
Claudiu Beznea <claudiu.beznea@tuxon.dev> <claudiu.beznea@microchip.com>
Colin Ian King <colin.i.king@gmail.com> <colin.king@canonical.com>
Corey Minyard <minyard@acm.org>
@@ -263,8 +266,9 @@ Enric Balletbo i Serra <eballetbo@kernel.org> <enric.balletbo@collabora.com>
Enric Balletbo i Serra <eballetbo@kernel.org> <eballetbo@iseebcn.com>
Erik Kaneda <erik.kaneda@intel.com> <erik.schmauss@intel.com>
Ethan Carter Edwards <ethan@ethancedwards.com> Ethan Edwards <ethancarteredwards@gmail.com>
Eugen Hristev <eugen.hristev@linaro.org> <eugen.hristev@microchip.com>
Eugen Hristev <eugen.hristev@linaro.org> <eugen.hristev@collabora.com>
Eugen Hristev <ehristev@kernel.org> <eugen.hristev@microchip.com>
Eugen Hristev <ehristev@kernel.org> <eugen.hristev@linaro.org>
Eugen Hristev <ehristev@kernel.org> <eugen.hristev@collabora.com>
Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> <ezequiel@collabora.com>
Faith Ekstrand <faith.ekstrand@collabora.com> <jason@jlekstrand.net>
@@ -339,6 +343,7 @@ Henrik Rydberg <rydberg@bitmath.org>
Herbert Xu <herbert@gondor.apana.org.au>
Huacai Chen <chenhuacai@kernel.org> <chenhc@lemote.com>
Huacai Chen <chenhuacai@kernel.org> <chenhuacai@loongson.cn>
Ian Ray <ian.ray@gehealthcare.com> <ian.ray@ge.com>
Ignat Korchagin <ignat@linux.win> <ignat@cloudflare.com>
Igor Korotin <igor.korotin@linux.dev> <igor.korotin.linux@gmail.com>
Ike Panhc <ikepanhc@gmail.com> <ike.pan@canonical.com>
@@ -399,6 +404,7 @@ Jesper Dangaard Brouer <hawk@kernel.org> <hawk@comx.dk>
Jesper Dangaard Brouer <hawk@kernel.org> <jbrouer@redhat.com>
Jesper Dangaard Brouer <hawk@kernel.org> <jdb@comx.dk>
Jesper Dangaard Brouer <hawk@kernel.org> <netoptimizer@brouer.com>
Jesse Brandeburg <jbrandeb@kernel.org> <jesse.brandeburg@intel.com>
Jessica Zhang <jesszhan0024@gmail.com> <jesszhan@codeaurora.org>
Jessica Zhang <jesszhan0024@gmail.com> <quic_jesszhan@quicinc.com>
Jessica Zhang <jesszhan0024@gmail.com> <jessica.zhang@oss.qualcomm.com>
@@ -433,6 +439,7 @@ John Stultz <johnstul@us.ibm.com>
Jonas Gorski <jonas.gorski@gmail.com> <jogo@openwrt.org>
Jonathan Cameron <jic23@kernel.org> <jonathan.cameron@huawei.com>
Jordan Crouse <jordan@cosmicpenguin.net> <jcrouse@codeaurora.org>
Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> <jorge.ramirez-ortiz@linaro.org>
<josh@joshtriplett.org> <josh@freedesktop.org>
<josh@joshtriplett.org> <josh@kernel.org>
<josh@joshtriplett.org> <josht@linux.vnet.ibm.com>
@@ -446,6 +453,7 @@ Juha Yrjola <juha.yrjola@nokia.com>
Juha Yrjola <juha.yrjola@solidboot.com>
Julien Thierry <julien.thierry.kdev@gmail.com> <julien.thierry@arm.com>
Justin Iurman <justin.iurman@gmail.com> <justin.iurman@uliege.be>
Ira Weiny <iweiny@kernel.org> <ira.weiny@intel.com>
Iskren Chernev <me@iskren.info> <iskren.chernev@gmail.com>
Kalle Valo <kvalo@kernel.org> <kvalo@codeaurora.org>
Kalle Valo <kvalo@kernel.org> <quic_kvalo@quicinc.com>
@@ -522,7 +530,8 @@ Luca Ceresoli <luca.ceresoli@bootlin.com> <luca@lucaceresoli.net>
Luca Weiss <luca@lucaweiss.eu> <luca@z3ntu.xyz>
Lucas De Marchi <demarchi@kernel.org> <lucas.demarchi@intel.com>
Lukasz Luba <lukasz.luba@arm.com> <l.luba@partner.samsung.com>
Luo Jie <quic_luoj@quicinc.com> <luoj@codeaurora.org>
Luo Jie <jie.luo@oss.qualcomm.com> <luoj@codeaurora.org>
Luo Jie <jie.luo@oss.qualcomm.com> <quic_luoj@quicinc.com>
Lance Yang <lance.yang@linux.dev> <ioworker0@gmail.com>
Lance Yang <lance.yang@linux.dev> <mingzhe.yang@ly.com>
Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>

19
CREDITS
View File

@@ -197,6 +197,9 @@ S: Hauptstrasse 19
S: 79837 St. Blasien
S: Germany
N: Ferenc Bakonyi
D: Hercules graphics adapter framebuffer driver
N: Krishna Balasubramanian
E: balasub@cis.ohio-state.edu
D: Wrote SYS V IPC (part of standard kernel since 0.99.10)
@@ -2241,6 +2244,7 @@ S: Canada
N: Krzysztof Kozlowski
E: krzk@kernel.org
D: NFC network subsystem and drivers maintainer
D: Samsung S2M/S5M Multifunction PMIC device drivers for Exynos platforms
N: Christian Krafft
D: PowerPC Cell support
@@ -2804,6 +2808,7 @@ D: Some of PAS 16 mixer & PCM support, inet6-apps
N: William (Bill) Metzenthen
E: billm@suburbia.net
E: billm@melbpc.org.au
D: Author of the FPU emulator.
D: Minor kernel hacker for other lost causes (Hercules mono, etc).
S: 22 Parker Street
@@ -3368,6 +3373,10 @@ N: Anil Ravindranath
E: anil_ravindranath@pmc-sierra.com
D: PMC-Sierra MaxRAID driver
N: Dwaipayan Ray
E: dwaipayanray1@gmail.com
D: checkpatch improvements
N: Eric S. Raymond
E: esr@thyrsus.com
W: http://www.tuxedo.org/~esr/
@@ -3668,7 +3677,17 @@ D: Macintosh IDE Driver
N: Peter De Schrijver
E: stud11@cc4.kuleuven.ac.be
E: p2@mind.be
E: peter.de-schrijver@nokia.com
E: pdeschrijver@nvidia.com
E: p2@psychaos.be
D: Apollo Domain workstations
D: Ariadne and Hydra Amiga Ethernet drivers
D: IBM PS/2, Microchannel, and Token Ring support
D: Mitsumi CD-ROM driver patches March version
D: TWL4030 power management and audio codec driver
D: OMAP power management
D: NVIDIA Tegra clock and BPMP drivers, among many other things
S: Molenbaan 29
S: B2240 Zandhoven
S: Belgium

8
Documentation/ABI/stable/sysfs-class-infiniband
View File

@@ -148,17 +148,17 @@ Description:
**Data info**:
port_xmit_data: (RO) Total number of data octets, divided by 4
(lanes), transmitted on all VLs. This is 64 bit counter
(lanes), transmitted on all VLs. This is a 64-bit counter
port_rcv_data: (RO) Total number of data octets, divided by 4
(lanes), received on all VLs. This is 64 bit counter.
(lanes), received on all VLs. This is a 64-bit counter.
port_xmit_packets: (RO) Total number of packets transmitted on
all VLs from this port. This may include packets with errors.
This is 64 bit counter.
This is a 64-bit counter.
port_rcv_packets: (RO) Total number of packets (this may include
packets containing Errors. This is 64 bit counter.
packets containing Errors). This is a 64-bit counter.
link_downed: (RO) Total number of times the Port Training state
machine has failed the link error recovery process and downed

83
Documentation/ABI/testing/configfs-thunderbolt_stream Normal file
View File

@@ -0,0 +1,83 @@
What: /sys/kernel/config/thunderbolt/stream/<xdomain>.<service>
Date: Sep 2026
KernelVersion: v7.2
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description:
Configuration group for a stream Thunderbolt/USB4
service. It is possible to create groups even if there
is no connection yet to the other host. Once a
connection established and there is stream service on
the remote side that matches, this configuration is
applied to it.
To find the service name you can run tblist from tbtools [1]:
# tblist -A
...
Domain 0 Route 3 Index 0: stream
[1] https://github.com/intel/tbtools
What: /sys/kernel/config/thunderbolt/stream/<xdomain>.<service>/$name
Date: Sep 2026
KernelVersion: v7.2
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description:
Creates new stream with $name and fills it with the
default values. If there is an advertised remote stream
with the same name, uses its values as the default.
What: /sys/kernel/config/thunderbolt/stream/<xdomain>.<service>/$name/index
Date: Sep 2026
KernelVersion: v7.2
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description:
This matches the X in /dev/tbstreamX and allows userspace
to map the configfs directory to the corresponding character
device.
What: /sys/kernel/config/thunderbolt/stream/<xdomain>.<service>/$name/in_hopid
Date: Sep 2026
KernelVersion: v7.2
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description:
In HopID used with the read path of the tunnel. Available HopIDs
for tunneling start from 8. You can pass also -1 for automatic
allocation. The allocated value can be read here. Writing 0 will
de-allocate if the stream is not in use.
To figure out the maximum HopID you can run tbget from
tbtools for the lane adapter. For example below we check
for lane adapter number 1 (first USB4 port):
# tbget -r 0 -a 1 -D ADP_CS_5.Max\ Input\ HopID
19
This allows to use anything between 8 and 19 inclusive.
What: /sys/kernel/config/thunderbolt/stream/<xdomain>.<service>/$name/out_hopid
Date: Sep 2026
KernelVersion: v7.2
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description:
Out HopID used with the write path of the tunnel. Available HopIDs
for tunneling start from 8. You can pass also -1 for automatic
allocation. The allocated value can be read here. Writing 0 will
de-allocate if the stream is not in use. See @in_hopid
for how to figure out the maximum HopID.
What: /sys/kernel/config/thunderbolt/stream/<xdomain>.<service>/$name/ring_size
Date: Sep 2026
KernelVersion: v7.2
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description:
Size of the TX/RX rings. Can be adjusted between 32 and
4096. The default is 256.
What: /sys/kernel/config/thunderbolt/stream/<xdomain>.<service>/$name/throttling
Date: Sep 2026
KernelVersion: v7.2
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description:
Interrupt throttling rate in ns. Lower values can give
better latency. The default is 8192 ns.

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

@@ -764,10 +764,13 @@ Contact: linux-iio@vger.kernel.org
Description:
Specifies the output powerdown mode.
DAC output stage is disconnected from the amplifier and
500ohm_to_gnd: connected to ground via a 500Ohm resistor,
1kohm_to_gnd: connected to ground via an 1kOhm resistor,
2.5kohm_to_gnd: connected to ground via a 2.5kOhm resistor,
3.85kohm_to_gnd: connected to ground via a 3.85kOhm resistor,
6kohm_to_gnd: connected to ground via a 6kOhm resistor,
7.7kohm_to_gnd: connected to ground via a 7.7kOhm resistor,
16kohm_to_gnd: connected to ground via a 16kOhm resistor,
20kohm_to_gnd: connected to ground via a 20kOhm resistor,
32kohm_to_gnd: connected to ground via a 32kOhm resistor,
42kohm_to_gnd: connected to ground via a 42kOhm resistor,
@@ -1510,21 +1513,24 @@ Contact: linux-iio@vger.kernel.org
Description:
Description of the scan element data storage within the buffer
and hence the form in which it is read from user-space.
Form is [be|le]:[s|u]bits/storagebits[>>shift].
be or le specifies big or little endian. s or u specifies if
signed (2's complement) or unsigned. bits is the number of bits
of data and storagebits is the space (after padding) that it
occupies in the buffer. shift if specified, is the shift that
needs to be applied prior to masking out unused bits. Some
devices put their data in the middle of the transferred elements
with additional information on both sides. Note that some
devices will have additional information in the unused bits
so to get a clean value, the bits value must be used to mask
the buffer output value appropriately. The storagebits value
also specifies the data alignment. So s48/64>>2 will be a
signed 48 bit integer stored in a 64 bit location aligned to
a 64 bit boundary. To obtain the clean value, shift right 2
and apply a mask to zero the top 16 bits of the result.
Form is [be|le]:[f|s|u]bits/storagebits[>>shift].
be or le specifies big or little endian. f means floating-point
(IEEE 754 binary format), s means signed (2's complement), u means
unsigned. bits is the number of bits of data and storagebits is the
space (after padding) that it occupies in the buffer; when using a
floating-point format, bits must be one of the width values defined
in the IEEE 754 standard for binary interchange formats (e.g. 16
indicates the binary16 format for half-precision numbers). shift,
if specified, is the shift that needs to be applied prior to
masking out unused bits. Some devices put their data in the middle
of the transferred elements with additional information on both
sides. Note that some devices will have additional information in
the unused bits, so to get a clean value the bits value must be
used to mask the buffer output value appropriately. The storagebits
value also specifies the data alignment. So s48/64>>2 will be a
signed 48 bit integer stored in a 64 bit location aligned to a 64
bit boundary. To obtain the clean value, shift right 2 and apply a
mask to zero the top 16 bits of the result.
For other storage combinations this attribute will be extended
appropriately.
@@ -1752,6 +1758,21 @@ Description:
measurement from channel Y. Units after application of scale and
offset are milliamps.
What: /sys/bus/iio/devices/iio:deviceX/in_rot_quaternionaxis_raw
KernelVersion: 7.1
Contact: linux-iio@vger.kernel.org
Description:
Raw value of {x, y, z} components of the quaternion vector. These
components represent the axis about which a rotation occurs, and are
subject to the following constraints:
- the quaternion vector is normalized, i.e. w^2 + x^2 + y^2 + z^2 = 1
- the rotation angle is within the [-pi, pi] range, i.e. the w
component (which represents the amount of rotation) is non-negative
These constraints allow the w value to be calculated from the other
components: w = sqrt(1 - (x^2 + y^2 + z^2)).
What: /sys/.../iio:deviceX/in_energy_en
What: /sys/.../iio:deviceX/in_distance_en
What: /sys/.../iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_en
@@ -1959,6 +1980,23 @@ Description:
Raw (unscaled no offset etc.) resistance reading.
Units after application of scale and offset are ohms.
What: /sys/bus/iio/devices/iio:deviceX/in_coverageY_raw
KernelVersion: 7.2
Contact: linux-iio@vger.kernel.org
Description:
Raw (unscaled no offset etc.) coverage reading. Used for sensors
that report fractional coverage as a percentage, such as leak
detectors where the value represents what portion of the sensing
element is wetted. Units after application of scale and offset are
percent.
What: /sys/bus/iio/devices/iio:deviceX/in_coverageY_scale
KernelVersion: 7.2
Contact: linux-iio@vger.kernel.org
Description:
Scale to be applied to in_coverageY_raw to obtain coverage
in percent.
What: /sys/bus/iio/devices/iio:deviceX/heater_enable
KernelVersion: 4.1.0
Contact: linux-iio@vger.kernel.org

2
Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
View File

@@ -22,7 +22,7 @@ Description:
Reading this attribute gives the state of the DbC. It
can be one of the following states: disabled, enabled,
initialized, connected, configured and stalled.
initialized, connected or configured.
What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_idVendor
Date: March 2023

14
Documentation/ABI/testing/sysfs-class-hwmon
View File

@@ -27,6 +27,20 @@ Description:
Some devices have a variable update rate or interval.
This attribute can be used to change it to the desired value.
What: /sys/class/hwmon/hwmonX/update_interval_us
Description:
The interval at which the chip will update readings,
expressed in microseconds.
Unit: microsecond
RW
Some devices have a variable update rate or interval and
require finer-than-millisecond control.
This attribute can be used to change it to the desired value.
Drivers implementing this attribute should also implement
update_interval for millisecond-based userspace interfaces.
What: /sys/class/hwmon/hwmonX/inY_min
Description:
Voltage min value.

24
Documentation/ABI/testing/sysfs-class-ieee80211-rtw89 Normal file
View File

@@ -0,0 +1,24 @@
What: /sys/class/ieee80211/phyX/rtw89_usb/serial_number
Date: May 2026
Contact: Johnson Tsai <wenjie.tsai@realtek.com>, linux-wireless@vger.kernel.org
Description: (Read) Serial number burned into EFUSE of the RTL8852CU-based
USB Wi-Fi adapter. Only present on devices that set the
RTW89_QUIRK_HW_INFO_SYSFS quirk (currently VID 0x28de /
PID 0x2432).
Format: %10phN (5 raw bytes printed as 10 lowercase hex
digits, no separators).
Example: 3642000123
What: /sys/class/ieee80211/phyX/rtw89_usb/uuid
Date: May 2026
Contact: Johnson Tsai <wenjie.tsai@realtek.com>, linux-wireless@vger.kernel.org
Description: (Read) UUID burned into EFUSE of the RTL8852CU-based USB Wi-Fi
adapter. Only present on devices that set the
RTW89_QUIRK_HW_INFO_SYSFS quirk (currently VID 0x28de /
PID 0x2432).
Format: %pUb (RFC 4122 UUID in lowercase with hyphens).
Example: aaec2b7c-0a55-4727-8de0-b30febccbbaa

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

@@ -22,8 +22,8 @@ Description:
For additional details please refer to
Documentation/leds/leds-class-multicolor.rst.
The value is between 0 and
/sys/class/leds/<led>/max_brightness.
The value is between 0 and /sys/class/leds/<led>/max_brightness
and is represented by as a decimal.
Writing 0 to this file clears active trigger.

19
Documentation/ABI/testing/sysfs-class-led-multicolor
View File

@@ -16,9 +16,22 @@ Date: March 2020
KernelVersion: 5.9
Contact: Dan Murphy <dmurphy@ti.com>
Description: read/write
This file contains array of integers. Order of components is
described by the multi_index array. The maximum intensity should
not exceed /sys/class/leds/<led>/max_brightness.
This file contains an array of integers. The order of components
is described by the multi_index array. The maximum intensity value
supported by each color component is described by the multi_max_intensity
file. Writing intensity values larger than the maximum value of a
given color component will result in those values being clamped.
For additional details please refer to
Documentation/leds/leds-class-multicolor.rst.
What: /sys/class/leds/<led>/multi_max_intensity
Date: May 2026
KernelVersion: 7.2
Contact: Armin Wolf <W_Armin@gmx.de>
Description: read
This file contains an array of integers describing the maximum
intensity value for each intensity component.
For additional details please refer to
Documentation/leds/leds-class-multicolor.rst.

12
Documentation/ABI/testing/sysfs-class-power-bd71828 Normal file
View File

@@ -0,0 +1,12 @@
What: /sys/class/power_supply/bd71828_ac/auto_dcin_limit
Description:
Enable/Disable automatic management of input current limit
(ILIM_DCIN_EN bit).
Possible values are:
============ ===========================================
1 automatic adjustment of input current limit
0 no adjustment of input current limit. This
helps for more unusual power sources like
solar modules.

13
Documentation/ABI/testing/sysfs-class-reboot-mode-reboot_modes
View File

@@ -2,33 +2,36 @@ What: /sys/class/reboot-mode/<driver>/reboot_modes
Date: March 2026(TBD)
KernelVersion: TBD
Contact: linux-pm@vger.kernel.org
Description:
Description:
This interface exposes the reboot-mode arguments
registered with the reboot-mode framework. It is
a read-only interface and provides a space
separated list of reboot-mode arguments supported
on the current platform.
Example:
recovery fastboot bootloader
The exact sysfs path may vary depending on the
name of the driver that registers the arguments.
Example:
Example::
/sys/class/reboot-mode/nvmem-reboot-mode/reboot_modes
/sys/class/reboot-mode/syscon-reboot-mode/reboot_modes
/sys/class/reboot-mode/qcom-pon/reboot_modes
The supported arguments can be used by userspace to
invoke device reset using the standard reboot() system
call interface, with the "argument" as string to "*arg"
parameter along with LINUX_REBOOT_CMD_RESTART2.
call interface, with the "argument" as string to ``*arg``
parameter along with ``LINUX_REBOOT_CMD_RESTART2``.
A driver can expose the supported arguments by
registering them with the reboot-mode framework
using the property names that follow the
mode-<argument> format.
Example:
mode-bootloader, mode-recovery.
mode-bootloader, mode-recovery
This attribute is useful for scripts or initramfs
logic that need to programmatically determine

26
Documentation/ABI/testing/sysfs-devices-faux-tdx-host Normal file
View File

@@ -0,0 +1,26 @@
What: /sys/devices/faux/tdx_host/version
Contact: linux-coco@lists.linux.dev
Description: (RO) Report the version of the loaded TDX module.
Formatted as "major.minor.update". Used by TDX module
update tooling. Example: "1.2.03".
What: /sys/devices/faux/tdx_host/seamldr_version
Contact: linux-coco@lists.linux.dev
Description: (RO) Report the version of the loaded P-SEAMLDR.
Formatted as a TDX module version. Used by TDX module
update tooling.
What: /sys/devices/faux/tdx_host/num_remaining_updates
Contact: linux-coco@lists.linux.dev
Description: (RO) Report the number of remaining updates. TDX maintains a
log about each TDX module that has been loaded. This log has
a finite size, which limits the number of TDX module updates
that can be performed.
After each successful update, the number reduces by one. Once it
reaches zero, further updates will fail until next reboot. The
number is always zero if the P-SEAMLDR doesn't support updates.
See Intel Trust Domain Extensions - SEAM Loader (SEAMLDR)
Interface Specification, Chapter "SEAMLDR_INFO" and Chapter
"SEAMLDR.INSTALL" for more information.

9
Documentation/ABI/testing/sysfs-driver-dell-dw5826e-reset Normal file
View File

@@ -0,0 +1,9 @@
What: /sys/bus/platform/devices/<PALC0001 device>/wwan_reset
Date: April 2026
KernelVersion: 7.2
Contact: Jackbb Wu <jackbb.wu@compal.com>
Description:
Writing to this file triggers a Platform Level Device Reset
(PLDR) of the Dell DW5826e WWAN module via an ACPI _DSM
method. This can be used to recover the modem when it is in
a frozen state and unable to respond to USB commands.

97
Documentation/ABI/testing/sysfs-driver-qat_kpt Normal file
View File

@@ -0,0 +1,97 @@
What: /sys/bus/pci/devices/<BDF>/qat_kpt/
Date: August 2026
KernelVersion: 7.2
Contact: qat-linux@intel.com
Description:
Directory containing attributes related to the QAT Key Protection
Technology (KPT) feature. KPT allows cryptographic keys to be used
by the accelerator without being exposed in plaintext to the host.
What: /sys/bus/pci/devices/<BDF>/qat_kpt/enable
Date: August 2026
KernelVersion: 7.2
Contact: qat-linux@intel.com
Description:
(RW) Enables or disables Key Protection Technology (KPT).
Write 1 to enable KPT, or 0 to disable it.
Example usage::
# cat /sys/bus/pci/devices/<BDF>/qat_kpt/enable
0
# echo 1 > /sys/bus/pci/devices/<BDF>/qat_kpt/enable
This attribute is only available on devices that support KPT.
What: /sys/bus/pci/devices/<BDF>/qat_kpt/swk_cnt_per_fn
Date: August 2026
KernelVersion: 7.2
Contact: qat-linux@intel.com
Description:
(RW) Configures the maximum number of KPT symmetric wrapping keys
(SWKs) that a Virtual Function (VF) may be associated with.
Valid values range from 0 to 128. A value of 0 indicates no limit.
Example usage::
# cat /sys/bus/pci/devices/<BDF>/qat_kpt/swk_cnt_per_fn
128
# echo 128 > /sys/bus/pci/devices/<BDF>/qat_kpt/swk_cnt_per_fn
This attribute is only available on devices that support KPT.
What: /sys/bus/pci/devices/<BDF>/qat_kpt/swk_cnt_per_pasid
Date: August 2026
KernelVersion: 7.2
Contact: qat-linux@intel.com
Description:
(RW) Configures the maximum number of KPT symmetric wrapping keys
(SWKs) per Process Address Space ID (PASID).
Valid values range from 0 to 128. A value of 0 indicates no limit.
Example usage::
# cat /sys/bus/pci/devices/<BDF>/qat_kpt/swk_cnt_per_pasid
128
# echo 128 > /sys/bus/pci/devices/<BDF>/qat_kpt/swk_cnt_per_pasid
This attribute is only available on devices that support KPT.
What: /sys/bus/pci/devices/<BDF>/qat_kpt/swk_max_ttl
Date: August 2026
KernelVersion: 7.2
Contact: qat-linux@intel.com
Description:
(RW) Configures the maximum Time To Live (TTL) for KPT symmetric
wrapping keys (SWK).
Valid values range from 0 to 31536000 seconds. A value of 0
indicates that the SWK TTL is unlimited.
Example usage::
# cat /sys/bus/pci/devices/<BDF>/qat_kpt/swk_max_ttl
1000
# echo 1000 > /sys/bus/pci/devices/<BDF>/qat_kpt/swk_max_ttl
This attribute is only available on devices that support KPT.
What: /sys/bus/pci/devices/<BDF>/qat_kpt/swk_shared
Date: August 2026
KernelVersion: 7.2
Contact: qat-linux@intel.com
Description:
(RW) Controls shared mode for KPT symmetric wrapping keys (SWK).
Write 1 to enable shared mode, or 0 to disable it (non-shared mode).
Example usage::
# cat /sys/bus/pci/devices/<BDF>/qat_kpt/swk_shared
0
# echo 1 > /sys/bus/pci/devices/<BDF>/qat_kpt/swk_shared
This attribute is only available on devices that support KPT.

2
Documentation/ABI/testing/sysfs-driver-qat_rl
View File

@@ -209,7 +209,7 @@ Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RW) This file will return the remaining capability for a
(RW) This file will return the remaining capacity for a
particular service/sla. This is the remaining value that a new
SLA can be set to or a current SLA can be increased with.

2
Documentation/ABI/testing/sysfs-driver-tegra-fuse
View File

@@ -1,6 +1,6 @@
What: /sys/devices/*/<our-device>/fuse
Date: February 2014
Contact: Peter De Schrijver <pdeschrijver@nvidia.com>
Contact: Thierry Reding <thierry.reding@kernel.org>
Description: read-only access to the efuses on Tegra20, Tegra30, Tegra114
and Tegra124 SoC's from NVIDIA. The efuses contain write once
data programmed at the factory. The data is laid out in 32bit

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

@@ -270,7 +270,8 @@ Description: Shows all enabled kernel features.
inode_checksum, flexible_inline_xattr, quota_ino,
inode_crtime, lost_found, verity, sb_checksum,
casefold, readonly, compression, test_dummy_encryption_v2,
atomic_write, pin_file, encrypted_casefold, linear_lookup.
atomic_write, pin_file, encrypted_casefold, linear_lookup,
fserror.
What: /sys/fs/f2fs/<disk>/inject_rate
Date: May 2016
@@ -1000,4 +1001,4 @@ Contact: "Chao Yu" <chao@kernel.org>
Description: It can be used to tune priority of f2fs critical task, e.g. f2fs_ckpt, f2fs_gc
threads, limitation as below:
- it requires user has CAP_SYS_NICE capability.
- the range is [100, 139], by default the value is 100.
- the range is [100, 139], by default the value is 120.

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

@@ -84,6 +84,13 @@ Description: Writing an integer to this file sets the 'address unit'
parameter of the given operations set of the context. Reading
the file returns the last-written 'address unit' value.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/pause
Date: Mar 2026
Contact: SeongJae Park <sj@kernel.org>
Description: Writing a boolean keyword to this file sets the 'pause' request
parameter for the context. Reading the file returns the
last-written 'pause' value.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/sample_us
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
@@ -322,6 +329,18 @@ Contact: SeongJae Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the
goal-based effective quota auto-tuning algorithm to use.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/fail_charge_num
Date: Mar 2026
Contact: SeongJae Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the
action-failed memory quota charging ratio numerator.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/fail_charge_denom
Date: Mar 2026
Contact: SeongJae Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the
action-failed memory quota charging ratio denominator.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/weights/sz_permil
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
@@ -377,15 +396,20 @@ Contact: SeongJae Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the low
watermark of the scheme in permil.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/nr_filters
Date: Dec 2022
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Description: Directory for DAMON core layer-handled DAMOS filters.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters/nr_filters
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Description: Writing a number 'N' to this file creates the number of
directories for setting filters of the scheme named '0' to
'N-1' under the filters/ directory.
'N-1' under the core_filters/ directory.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/type
Date: Dec 2022
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters/<F>/type
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the type of
the memory of the interest. 'anon' for anonymous pages,
@@ -393,77 +417,78 @@ Description: Writing to and reading from this file sets and gets the type of
'addr' for address range (an open-ended interval), or 'target'
for DAMON monitoring target can be written and read.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/memcg_path
Date: Dec 2022
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters/<F>/memcg_path
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Description: If 'memcg' is written to the 'type' file, writing to and
reading from this file sets and gets the path to the memory
cgroup of the interest.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/addr_start
Date: Jul 2023
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters/<F>/addr_start
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Description: If 'addr' is written to the 'type' file, writing to or reading
from this file sets or gets the start address of the address
range for the filter.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/addr_end
Date: Jul 2023
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters/<F>/addr_end
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Description: If 'addr' is written to the 'type' file, writing to or reading
from this file sets or gets the end address of the address
range for the filter.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/min
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters/<F>/min
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Description: If 'hugepage_size' is written to the 'type' file, writing to
or reading from this file sets or gets the minimum size of the
hugepage for the filter.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/max
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters/<F>/max
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Description: If 'hugepage_size' is written to the 'type' file, writing to
or reading from this file sets or gets the maximum size of the
hugepage for the filter.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/target_idx
Date: Dec 2022
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters/<F>/damon_target_idx
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Description: If 'target' is written to the 'type' file, writing to or
reading from this file sets or gets the index of the DAMON
monitoring target of the interest.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/matching
Date: Dec 2022
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters/<F>/matching
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Description: Writing 'Y' or 'N' to this file sets whether the filter is for
the memory of the 'type', or all except the 'type'.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/allow
Date: Jan 2025
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters/<F>/allow
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Description: Writing 'Y' or 'N' to this file sets whether to allow or reject
applying the scheme's action to the memory that satisfies the
'type' and the 'matching' of the directory.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Description: Directory for DAMON core layer-handled DAMOS filters. Files
under this directory works same to those of
/sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters
directory.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/ops_filters
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Description: Directory for DAMON operations set layer-handled DAMOS filters.
Files under this directory works same to those of
/sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters
/sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/core_filters
directory.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters
Date: Dec 2022
Contact: SeongJae Park <sj@kernel.org>
Description: Directory for DAMOS filters. Files under this directory works
same to those of
/sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/{core,ops}_filters
directory. This is deprecated. Use the core_filters and
ops_filters instead.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/dests/nr_dests
Date: Jul 2025
Contact: SeongJae Park <sj@kernel.org>

9
Documentation/ABI/testing/sysfs-platform-asus-wmi
View File

@@ -58,6 +58,15 @@ Description:
* 1 - overboost,
* 2 - silent
What: /sys/devices/platform/<platform>/keystone
Date: Jun 2026
KernelVersion: 7.2
Contact: "Dariusz Figzał" <dariuszfigzal@gmail.com>
Description:
Reports the Keystone dongle insert state (read-only):
* 0 - not inserted
* 1 - inserted
What: /sys/devices/platform/<platform>/gpu_mux_mode
Date: Aug 2022
KernelVersion: 6.1

2
Documentation/PCI/pci.rst
View File

@@ -338,7 +338,7 @@ the PCI_IRQ_MSI and PCI_IRQ_MSIX flags will fail, so try to always
specify PCI_IRQ_INTX as well.
Drivers that have different interrupt handlers for MSI/MSI-X and
legacy INTx should chose the right one based on the msi_enabled
legacy INTx should choose the right one based on the msi_enabled
and msix_enabled flags in the pci_dev structure after calling
pci_alloc_irq_vectors.

2
Documentation/PCI/pciebus-howto.rst
View File

@@ -97,7 +97,7 @@ register its service with the PCI Express Port Bus driver (see
section 5.2.1 & 5.2.2). It is important that a service driver
initializes the pcie_port_service_driver data structure, included in
header file /include/linux/pcieport_if.h, before calling these APIs.
Failure to do so will result an identity mismatch, which prevents
Failure to do so will result in an identity mismatch, which prevents
the PCI Express Port Bus driver from loading a service driver.
pcie_port_service_register

6
Documentation/RCU/Design/Requirements/Requirements.rst
View File

@@ -206,7 +206,7 @@ non-\ ``NULL``, locklessly accessing the ``->a`` and ``->b`` fields.
1 bool add_gp_buggy(int a, int b)
2 {
3 p = kmalloc(sizeof(*p), GFP_KERNEL);
3 p = kmalloc_obj(*p);
4 if (!p)
5 return -ENOMEM;
6 spin_lock(&gp_lock);
@@ -228,7 +228,7 @@ their rights to reorder this code as follows:
1 bool add_gp_buggy_optimized(int a, int b)
2 {
3 p = kmalloc(sizeof(*p), GFP_KERNEL);
3 p = kmalloc_obj(*p);
4 if (!p)
5 return -ENOMEM;
6 spin_lock(&gp_lock);
@@ -264,7 +264,7 @@ shows an example of insertion:
1 bool add_gp(int a, int b)
2 {
3 p = kmalloc(sizeof(*p), GFP_KERNEL);
3 p = kmalloc_obj(*p);
4 if (!p)
5 return -ENOMEM;
6 spin_lock(&gp_lock);

2
Documentation/RCU/listRCU.rst
View File

@@ -276,7 +276,7 @@ The RCU version of audit_upd_rule() is as follows::
list_for_each_entry(e, list, list) {
if (!audit_compare_rule(rule, &e->rule)) {
ne = kmalloc(sizeof(*entry), GFP_ATOMIC);
ne = kmalloc_obj(*entry, GFP_ATOMIC);
if (ne == NULL)
return -ENOMEM;
audit_copy_rule(&ne->rule, &e->rule);

4
Documentation/RCU/whatisRCU.rst
View File

@@ -468,7 +468,7 @@ uses of RCU may be found in listRCU.rst and NMI-RCU.rst.
struct foo *new_fp;
struct foo *old_fp;
new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
new_fp = kmalloc_obj(*new_fp);
spin_lock(&foo_mutex);
old_fp = rcu_dereference_protected(gbl_foo, lockdep_is_held(&foo_mutex));
*new_fp = *old_fp;
@@ -570,7 +570,7 @@ The foo_update_a() function might then be written as follows::
struct foo *new_fp;
struct foo *old_fp;
new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
new_fp = kmalloc_obj(*new_fp);
spin_lock(&foo_mutex);
old_fp = rcu_dereference_protected(gbl_foo, lockdep_is_held(&foo_mutex));
*new_fp = *old_fp;

13
Documentation/admin-guide/LSM/landlock.rst
View File

@@ -6,7 +6,7 @@ Landlock: system-wide management
================================
:Author: Mickaël Salaün
:Date: January 2026
:Date: June 2026
Landlock can leverage the audit framework to log events.
@@ -19,8 +19,10 @@ Audit
Denied access requests are logged by default for a sandboxed program if `audit`
is enabled. This default behavior can be changed with the
sys_landlock_restrict_self() flags (cf.
Documentation/userspace-api/landlock.rst). Landlock logs can also be masked
thanks to audit rules. Landlock can generate 2 audit record types.
Documentation/userspace-api/landlock.rst), or suppressed on a per-object
basis by using ``LANDLOCK_ADD_RULE_QUIET`` (ABI 10+). Landlock logs can
also be masked thanks to audit rules. Landlock can generate 2 audit
record types.
Record types
------------
@@ -54,6 +56,8 @@ AUDIT_LANDLOCK_ACCESS
**net.*** - Network access rights (ABI 4+):
- net.bind_tcp - TCP port binding was denied
- net.connect_tcp - TCP connection was denied
- net.bind_udp - UDP port binding was denied
- net.connect_send_udp - UDP connection and send was denied
**scope.*** - IPC scoping restrictions (ABI 6+):
- scope.abstract_unix_socket - Abstract UNIX socket connection denied
@@ -172,7 +176,8 @@ If you get spammed with audit logs related to Landlock, this is either an
attack attempt or a bug in the security policy. We can put in place some
filters to limit noise with two complementary ways:
- with sys_landlock_restrict_self()'s flags if we can fix the sandboxed
- with sys_landlock_restrict_self()'s flags, or
``LANDLOCK_ADD_RULE_QUIET`` (ABI 10+) if we can fix the sandboxed
programs,
- or with audit rules (see :manpage:`auditctl(8)`).

8
Documentation/admin-guide/binfmt-misc.rst
View File

@@ -68,10 +68,10 @@ Here is what the fields mean:
Legacy behavior of binfmt_misc is to pass the full path
of the binary to the interpreter as an argument. When this flag is
included, binfmt_misc will open the file for reading and pass its
descriptor as an argument, instead of the full path, thus allowing
the interpreter to execute non-readable binaries. This feature
should be used with care - the interpreter has to be trusted not to
emit the contents of the non-readable binary.
descriptor into the auxilary vector with the key "AT_EXECFD", thus
allowing the interpreter to execute non-readable binaries. This
feature should be used with care - the interpreter has to be trusted
not to emit the contents of the non-readable binary.
``C`` - credentials
Currently, the behavior of binfmt_misc is to calculate
the credentials and security token of the new process according to

4
Documentation/admin-guide/bug-hunting.rst
View File

@@ -63,8 +63,8 @@ Documentation/admin-guide/tainted-kernels.rst, "being loaded" is
annotated with "+", and "being unloaded" is annotated with "-".
Where is the Oops message is located?
-------------------------------------
Where is the Oops message located?
----------------------------------
Normally the Oops text is read from the kernel buffers by klogd and
handed to ``syslogd`` which writes it to a syslog file, typically

2
Documentation/admin-guide/cgroup-v1/cgroups.rst
View File

@@ -525,7 +525,7 @@ cgroup. It may also be taken to prevent cgroups from being
modified, but more specific locks may be more appropriate in that
situation.
See kernel/cgroup.c for more details.
See kernel/cgroup/cgroup.c for more details.
Subsystems can take/release the cgroup_mutex via the functions
cgroup_lock()/cgroup_unlock().

2
Documentation/admin-guide/cgroup-v1/memcg_test.rst
View File

@@ -321,7 +321,7 @@ Under below explanation, we assume CONFIG_SWAP=y.
----------------------
Memory controller implements memory thresholds using cgroups notification
API. You can use tools/cgroup/cgroup_event_listener.c to test it.
API. You can use samples/cgroup/cgroup_event_listener.c to test it.
(Shell-A) Create cgroup and run event listener::

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

@@ -2785,6 +2785,59 @@ RDMA Interface Files
mlx4_0 hca_handle=1 hca_object=20
ocrdma1 hca_handle=1 hca_object=23
rdma.peak
A read-only nested-keyed file that exists for all the cgroups
except root. It shows the historical high watermark of
resource usage per device since the cgroup was created.
An example for mlx4 and ocrdma device follows::
mlx4_0 hca_handle=1 hca_object=20
ocrdma1 hca_handle=0 hca_object=23
rdma.events
A read-only nested-keyed file which exists on non-root
cgroups. The following nested keys are defined.
max
The number of times a process in this cgroup or its
descendants attempted an RDMA resource allocation that
was rejected because a rdma.max limit in the subtree
was reached. This is a hierarchical counter: the event
is propagated upward to all ancestor cgroups. A value
change in this file generates a file modified event.
alloc_fail
The number of RDMA resource allocation attempts that
originated in this cgroup or its descendants and failed
due to a rdma.max limit being reached. This is a
hierarchical counter propagated upward.
An example for mlx4 device follows::
mlx4_0 hca_handle.max=5 hca_handle.alloc_fail=3 hca_object.max=0 hca_object.alloc_fail=0
rdma.events.local
Similar to rdma.events but the fields in the file are local
to the cgroup i.e. not hierarchical. The file modified event
generated on this file reflects only the local events.
The following nested keys are defined.
max
The number of times a process in this cgroup or its
descendants attempted an RDMA resource allocation that
was rejected because this cgroup's own rdma.max limit
was reached.
alloc_fail
The number of RDMA resource allocation attempts
originating from this cgroup that failed due to this
cgroup's or an ancestor's rdma.max limit.
An example for mlx4 device follows::
mlx4_0 hca_handle.max=5 hca_handle.alloc_fail=0 hca_object.max=0 hca_object.alloc_fail=0
DMEM
----

129
Documentation/admin-guide/device-mapper/dm-inlinecrypt.rst Normal file
View File

@@ -0,0 +1,129 @@
==============
dm-inlinecrypt
==============
Device-Mapper's "inlinecrypt" target provides transparent encryption of block devices
using the inline encryption hardware.
For a more detailed description of inline encryption, see:
https://docs.kernel.org/block/inline-encryption.html
Parameters::
<cipher> <key> <iv_offset> <device path> \
<offset> [<#opt_params> <opt_params>]
<cipher>
Encryption cipher type.
The cipher specifications format is::
cipher
Examples::
aes-xts-plain64
The cipher type corresponds to the encryption modes supported by
inline crypto in the block layer. Currently, only
BLK_ENCRYPTION_MODE_AES_256_XTS (i.e. aes-xts-plain64) is supported.
<key>
Key used for encryption. It is encoded either as a hexadecimal number
or it can be passed as <key_string> prefixed with single colon
character (':') for keys residing in kernel keyring service.
You can only use key sizes that are valid for the selected cipher.
Note that the size in bytes of a valid key must be in bellow range.
[BLK_CRYPTO_KEY_TYPE_RAW, BLK_CRYPTO_KEY_TYPE_HW_WRAPPED]
<key_string>
The kernel keyring key is identified by string in following format:
<key_size>:<keyring_type>:<key_description>.
<key_size>
The encryption key size in bytes. The kernel key payload size must match
the value passed in <key_size>.
<keyring_type>
The type of the key inside the kernel keyring. It can be either 'logon',
or 'trusted' kernel key type.
<key_description>
The kernel keyring key description inlinecrypt target should look for
when loading key of <keyring_type>.
<iv_offset>
The IV offset is a sector count that is added to the sector number
before creating the IV.
<device path>
This is the device that is going to be used as backend and contains the
encrypted data. You can specify it as a path like /dev/xxx or a device
number <major>:<minor>.
<offset>
Starting sector within the device where the encrypted data begins.
<#opt_params>
Number of optional parameters. If there are no optional parameters,
the optional parameters section can be skipped or #opt_params can be zero.
Otherwise #opt_params is the number of following arguments.
Example of optional parameters section:
keytype:raw allow_discards sector_size:4096 iv_large_sectors
<key_type>
The type of the key as seen by the block layer, either standard or
hardware-wrapped. The string is supplied in the table as <keytype:raw>
or <keytype:hw-wrapped>.
allow_discards
Block discard requests (a.k.a. TRIM) are passed through the inlinecrypt
device. The default is to ignore discard requests.
WARNING: Assess the specific security risks carefully before enabling this
option. For example, allowing discards on encrypted devices may lead to
the leak of information about the ciphertext device (filesystem type,
used space etc.) if the discarded blocks can be located easily on the
device later.
sector_size:<bytes>
Use <bytes> as the encryption unit instead of 512 bytes sectors.
This option can be in range 512 - 4096 bytes and must be power of two.
Virtual device will announce this size as a minimal IO and logical sector.
iv_large_sectors
Use <sector_size>-based sector numbers for IV generation instead of
512-byte sectors.
For dm-inlinecrypt, this flag must be specified when <sector_size>
is larger than 512 bytes. The legacy 512-byte-based IV behavior is
not supported.
When specified, if <sector_size> is 4096 bytes, plain64 IV for the
second sector will be 1, and <iv_offset> must be a multiple of
<sector_size> (in 512-byte units).
Example scripts
===============
Currently, dm-inlinecrypt devices must be set up directly using dmsetup.
There is no userspace support yet to integrate dm-inlinecrypt with LUKS
or cryptsetup. In particular, cryptsetup currently only supports
dm-crypt, and cannot be used to create dm-inlinecrypt mappings.
The following examples demonstrate how to create dm-inlinecrypt devices
using dmsetup
::
#!/bin/sh
# Create a inlinecrypt device using dmsetup
dmsetup create inlinecrypt1 --table "0 `blockdev --getsz $1` inlinecrypt aes-xts-plain64 babebabebabebabebabebabebabebabebabebabebabebabebabebabebabebabe 0 0 $1 0 1 keytype:raw"
::
#!/bin/sh
# Create a inlinecrypt device using dmsetup when encryption key is stored in keyring service
dmsetup create inlinecrypt2 --table "0 `blockdev --getsz $1` inlinecrypt aes-xts-plain64 :64:logon:fde:dminlinecrypt_test_key 0 0 $1 0 1 keytype:raw"

1
Documentation/admin-guide/device-mapper/index.rst
View File

@@ -15,6 +15,7 @@ Device Mapper
dm-flakey
dm-ima
dm-init
dm-inlinecrypt
dm-integrity
dm-io
dm-log

1
Documentation/admin-guide/devices.txt
View File

@@ -291,7 +291,6 @@
154 = /dev/pmu Macintosh PowerBook power manager
155 =
156 = /dev/lcd Front panel LCD display
157 = /dev/ac Applicom Intl Profibus card
158 = /dev/nwbutton Netwinder external button
159 = /dev/nwdebug Netwinder debug interface
160 = /dev/nwflash Netwinder flash memory

35
Documentation/admin-guide/dynamic-debug-howto.rst
View File

@@ -38,12 +38,12 @@ You can view the currently configured behaviour in the *prdbg* catalog::
:#> head -n7 /proc/dynamic_debug/control
# filename:lineno [module]function flags format
init/main.c:1179 [main]initcall_blacklist =_ "blacklisting initcall %s\012
init/main.c:1218 [main]initcall_blacklisted =_ "initcall %s blacklisted\012"
init/main.c:1424 [main]run_init_process =_ " with arguments:\012"
init/main.c:1426 [main]run_init_process =_ " %s\012"
init/main.c:1427 [main]run_init_process =_ " with environment:\012"
init/main.c:1429 [main]run_init_process =_ " %s\012"
init/main.c:1179 [main]initcall_blacklist =_ "blacklisting initcall %s\n"
init/main.c:1218 [main]initcall_blacklisted =_ "initcall %s blacklisted\n"
init/main.c:1424 [main]run_init_process =_ " with arguments:\n"
init/main.c:1426 [main]run_init_process =_ " %s\n"
init/main.c:1427 [main]run_init_process =_ " with environment:\n"
init/main.c:1429 [main]run_init_process =_ " %s\n"
The 3rd space-delimited column shows the current flags, preceded by
a ``=`` for easy use with grep/cut. ``=p`` shows enabled callsites.
@@ -59,10 +59,10 @@ query/commands to the control file. Example::
:#> ddcmd '-p; module main func run* +p'
:#> grep =p /proc/dynamic_debug/control
init/main.c:1424 [main]run_init_process =p " with arguments:\012"
init/main.c:1426 [main]run_init_process =p " %s\012"
init/main.c:1427 [main]run_init_process =p " with environment:\012"
init/main.c:1429 [main]run_init_process =p " %s\012"
init/main.c:1424 [main]run_init_process =p " with arguments:\n"
init/main.c:1426 [main]run_init_process =p " %s\n"
init/main.c:1427 [main]run_init_process =p " with environment:\n"
init/main.c:1429 [main]run_init_process =p " %s\n"
Error messages go to console/syslog::
@@ -109,10 +109,19 @@ The match-spec's select *prdbgs* from the catalog, upon which to apply
the flags-spec, all constraints are ANDed together. An absent keyword
is the same as keyword "*".
Note that since the match-spec can be empty, the flags are checked 1st,
then the pairs of keyword and value. Flag errs will hide keyword errs::
A match specification is a keyword, which selects the attribute of
the callsite to be compared, and a value to compare against. Possible
keywords are:::
bash-5.2# ddcmd mod bar +foo
dyndbg: read 13 bytes from userspace
dyndbg: query 0: "mod bar +foo" mod:*
dyndbg: unknown flag 'o'
dyndbg: flags parse failed
dyndbg: processed 1 queries, with 0 matches, 1 errs
So a match-spec is a keyword, which selects the attribute of the
callsite to be compared, and a value to compare against. Possible
keywords are::
match-spec ::= 'func' string |
'file' string |

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

@@ -24,7 +24,6 @@
IP_PNP IP DHCP, BOOTP, or RARP is enabled.
IPV6 IPv6 support is enabled.
ISAPNP ISA PnP code is enabled.
ISDN Appropriate ISDN support is enabled.
ISOL CPU Isolation is enabled.
JOY Appropriate joystick support is enabled.
KGDB Kernel debugger support is enabled.
@@ -36,7 +35,6 @@
M68k M68k architecture is enabled.
These options have more detailed description inside of
Documentation/arch/m68k/kernel-options.rst.
MDA MDA console support is enabled.
MIPS MIPS architecture is enabled.
MOUSE Appropriate mouse support is enabled.
MSI Message Signaled Interrupts (PCI).
@@ -558,9 +556,6 @@ Kernel parameters
1 -- enable.
Default value is set via kernel config option.
arcrimi= [HW,NET] ARCnet - "RIM I" (entirely mem-mapped) cards
Format: <io>,<irq>,<nodeID>
arm64.no32bit_el0 [ARM64] Unconditionally disable the execution of
32 bit applications.
@@ -789,24 +784,6 @@ Kernel parameters
cio_ignore= [S390]
See Documentation/arch/s390/common_io.rst for details.
clearcpuid=X[,X...] [X86]
Disable CPUID feature X for the kernel. See
arch/x86/include/asm/cpufeatures.h for the valid bit
numbers X. Note the Linux-specific bits are not necessarily
stable over kernel options, but the vendor-specific
ones should be.
X can also be a string as appearing in the flags: line
in /proc/cpuinfo which does not have the above
instability issue. However, not all features have names
in /proc/cpuinfo.
Note that using this option will taint your kernel.
Also note that user programs calling CPUID directly
or using the feature without checking anything
will still see it. This just prevents it from
being used by the kernel or shown in /proc/cpuinfo.
Also note the kernel might malfunction if you disable
some critical bits.
clk_ignore_unused
[CLK]
Prevents the clock framework from automatically gating
@@ -895,6 +872,10 @@ Kernel parameters
contiguous memory allocations. It will reserve CMA
area for the specified node.
If it is setup together with upper 'cmd_pernuma='
(unlikely), its size setting takes priority for the
specified numa nodes.
With numa CMA enabled, DMA users on node nid will
first try to allocate buffer from the numa area
which is located in node nid, if the allocation fails,
@@ -911,17 +892,6 @@ Kernel parameters
Sets the size of memory pool for coherent, atomic dma
allocations, by default set to 256K.
com20020= [HW,NET] ARCnet - COM20020 chipset
Format:
<io>[,<irq>[,<nodeID>[,<backplane>[,<ckp>[,<timeout>]]]]]
com90io= [HW,NET] ARCnet - COM90xx chipset (IO-mapped buffers)
Format: <io>[,<irq>]
com90xx= [HW,NET]
ARCnet - COM90xx chipset (memory-mapped buffers)
Format: <io>[,<irq>[,<memstart>]]
condev= [HW,S390] console device
conmode=
@@ -1246,8 +1216,9 @@ Kernel parameters
deferred probe to give up waiting on dependencies to
probe. Only specific dependencies (subsystems or
drivers) that have opted in will be ignored. A timeout
of 0 will timeout at the end of initcalls. If the time
out hasn't expired, it'll be restarted by each
of 0 will timeout at the end of initcalls; a negative
value is treated as an infinite timeout value. If the
timeout hasn't expired, it'll be restarted by each
successful driver registration. This option will also
dump out devices still on the deferred probe list after
retrying.
@@ -1669,10 +1640,6 @@ Kernel parameters
very early in the boot process. For early debugging
via a serial port see kgdboc_earlycon instead.
elanfreq= [X86-32]
See comment before function elanfreq_setup() in
arch/x86/kernel/cpu/cpufreq/elanfreq.c.
elfcorehdr=[size[KMG]@]offset[KMG] [PPC,SH,X86,S390,EARLY]
Specifies physical address of start of kernel core
image elf header and optionally the size. Generally
@@ -2100,6 +2067,10 @@ Kernel parameters
Format: nn[KMGTPE] or (node format)
<node>:nn[KMGTPE][,<node>:nn[KMGTPE]]
The size must be a multiple of the gigantic page size.
When using node format, this applies to each per-node size.
Missaligned values are dropped with a warning.
Reserve a CMA area of given size and allocate gigantic
hugepages using the CMA allocator. If enabled, the
boot-time allocation of gigantic hugepages is skipped.
@@ -2245,9 +2216,6 @@ Kernel parameters
syscalls, essentially overriding IA32_EMULATION_DEFAULT_DISABLED at
boot time. When false, unconditionally disables IA32 emulation.
icn= [HW,ISDN]
Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
idle= [X86,EARLY]
Format: idle=poll, idle=halt, idle=nomwait
@@ -2343,6 +2311,12 @@ Kernel parameters
Use the canonical format for the binary runtime
measurements, instead of host native format.
ima_flush_htable [IMA]
Flush the IMA hash table when deleting all the
staged measurement records, to achieve maximum
memory saving at the cost of having duplicate
records across the staged measurement lists.
ima_hash= [IMA]
Format: { md5 | sha1 | rmd160 | sha256 | sha384
| sha512 | ... }
@@ -2584,23 +2558,41 @@ Kernel parameters
Don't force hardware IOMMU usage when it is not
needed. (default).
biomerge
panic
nopanic
merge
Do scatter-gather (SG) merging. Implies "force"
(experimental).
nomerge
Don't do scatter-gather (SG) merging.
biomerge
Do scatter-gather (SG) merging. Implies "force"
(experimental). [same as "merge"]
panic
Always panic when IOMMU overflows.
nopanic
Don't panic on IOMMU overflows.
pt
Use passththrough mode by default
(Equivalent to iommu.passthrough=1)
nopt
Use translated mode for DMA by default
(Equivalent to iommu.passthrough=0)
soft
Use software bounce buffering (SWIOTLB) (default for
Intel machines). This can be used to prevent the usage
of an available hardware IOMMU.
pt
nopt
nobypass [PPC/POWERNV]
Disable IOMMU bypass, using IOMMU for PCI devices.
usedac
Use the DAC on VIA PCI bridge
(default: disable the VIA PCI bridge DAC)
AMD Gart HW IOMMU-specific options:
AMD Gart HW IOMMU-specific options: (CONFIG_GART_IOMMU)
<size>
Set the size of the remapping area in bytes.
@@ -2608,6 +2600,9 @@ Kernel parameters
allowed
Overwrite iommu off workarounds for specific chipsets
force
Overwrite iommu off workarounds for specific chipsets
fullflush
Flush IOMMU on each allocation (default).
@@ -2618,21 +2613,16 @@ Kernel parameters
Allocate an own aperture over RAM with size
32MB<<order. (default: order=1, i.e. 64MB)
merge
Do scatter-gather (SG) merging. Implies "force"
(experimental).
nomerge
Don't do scatter-gather (SG) merging.
noaperture
Ask the IOMMU not to touch the aperture for AGP.
noagp
Don't initialize the AGP driver and use full aperture.
panic
Always panic when IOMMU overflows.
iommu= [PPC/POWERNV]
nobypass
Disable IOMMU bypass, using IOMMU for PCI devices.
iommu.forcedac= [ARM64,X86,EARLY] Control IOVA allocation for PCI devices.
Format: { "0" | "1" }
@@ -2755,7 +2745,6 @@ Kernel parameters
Format: <RDP>,<reset>,<pci_scan>,<verbosity>
isolcpus= [KNL,SMP,ISOL] Isolate a given set of CPUs from disturbance.
[Deprecated - use cpusets instead]
Format: [flag-list,]<cpu-list>
Specify one or more CPUs to isolate from disturbances
@@ -2780,11 +2769,10 @@ Kernel parameters
Isolate from the general SMP balancing and scheduling
algorithms. Note that performing domain isolation this way
is irreversible: it's not possible to bring back a CPU to
the domains once isolated through isolcpus. It's strongly
advised to use cpusets instead to disable scheduler load
balancing through the "cpuset.sched_load_balance" file.
It offers a much more flexible interface where CPUs can
move in and out of an isolated set anytime.
the domains once isolated through this boot time
configuration. Use cpusets for a dynamic configuration
which can be altered at runtime. For details see
Documentation/admin-guide/cpu-isolation.rst.
You can move a process onto or off an "isolated" CPU via
the CPU affinity syscalls or cpuset.
@@ -3816,10 +3804,6 @@ Kernel parameters
md= [HW] RAID subsystems devices and level
See Documentation/admin-guide/md.rst.
mdacon= [MDA]
Format: <first>,<last>
Specifies range of consoles to be captured by the MDA.
mds= [X86,INTEL,EARLY]
Control mitigation for the Micro-architectural Data
Sampling (MDS) vulnerability.
@@ -4266,12 +4250,8 @@ Kernel parameters
n2= [NET] SDL Inc. RISCom/N2 synchronous serial card
netdev= [NET] Network devices parameters
netdev= [NET] NE2000 ISA network devices parameters
Format: <irq>,<io>,<mem_start>,<mem_end>,<name>
Note that mem_start is often overloaded to mean
something different and driver-specific.
This usage is only documented in each driver source
file if at all.
netpoll.carrier_timeout=
[NET] Specifies amount of time (in seconds) that
@@ -4308,13 +4288,6 @@ Kernel parameters
Only applies if the softerr mount option is enabled,
and the specified value is >= 0.
nfs.enable_ino64=
[NFS] enable 64-bit inode numbers.
If zero, the NFS client will fake up a 32-bit inode
number for the readdir() and stat() syscalls instead
of returning the full 64-bit number.
The default is to return 64-bit inode numbers.
nfs.idmap_cache_timeout=
[NFS] set the maximum lifetime for idmapper cache
entries.
@@ -4437,10 +4410,6 @@ Kernel parameters
These settings can be accessed at runtime via
the nmi_watchdog and hardlockup_panic sysctls.
no387 [BUGS=X86-32] Tells the kernel to use the 387 maths
emulation library even if a 387 maths coprocessor
is present.
no4lvl [RISCV,EARLY] Disable 4-level and 5-level paging modes.
Forces kernel to use 3-level paging instead.
@@ -4644,7 +4613,7 @@ Kernel parameters
nosmt [KNL,MIPS,PPC,EARLY] Disable symmetric multithreading (SMT).
Equivalent to smt=1.
[KNL,LOONGARCH,X86,PPC,S390] Disable symmetric multithreading (SMT).
[KNL,LOONGARCH,X86,ARM64,PPC,S390] Disable symmetric multithreading (SMT).
nosmt=force: Force disable SMT, cannot be undone
via the sysfs control file.
@@ -5037,8 +5006,6 @@ Kernel parameters
the specified number of seconds. This is to be used if
your oopses keep scrolling off the screen.
pcbit= [HW,ISDN]
pci=option[,option...] [PCI,EARLY] various PCI subsystem options.
Some options herein operate on a specific device
@@ -5862,13 +5829,13 @@ Kernel parameters
use a call_rcu[_hurry]() path. Please note, this is for a
normal grace period.
How to enable it:
How to disable it:
echo 1 > /sys/module/rcutree/parameters/rcu_normal_wake_from_gp
or pass a boot parameter "rcutree.rcu_normal_wake_from_gp=1"
echo 0 > /sys/module/rcutree/parameters/rcu_normal_wake_from_gp
or pass a boot parameter "rcutree.rcu_normal_wake_from_gp=0"
Default is 1 if num_possible_cpus() <= 16 and it is not explicitly
disabled by the boot parameter passing 0.
Default is 1 if it is not explicitly disabled by the boot parameter
passing 0.
rcuscale.gp_async= [KNL]
Measure performance of asynchronous
@@ -6778,8 +6745,6 @@ Kernel parameters
restrictions other than those given by hardware at the
cost of significant additional memory use for tables.
sa1100ir [NET]
See drivers/net/irda/sa1100_ir.c.
sched_proxy_exec= [KNL]
Enables or disables "proxy execution" style
@@ -7236,6 +7201,18 @@ Kernel parameters
Not specifying this option is equivalent to
spec_store_bypass_disable=auto.
split_llc=
[X86,EARLY] Split the LLC N-ways
When set, the LLC is split this many ways by matching
'core_id % n'. This is setup before SMP bringup and
used during SMP bringup before it knows the full
topology. If your core count doesn't nicely divide by
the number given, you get to keep the pieces.
This is mostly a debug feature to emulate multiple LLCs
on hardware that only have a single LLC.
split_lock_detect=
[X86] Enable split lock detection or bus lock detection
@@ -7414,10 +7391,10 @@ Kernel parameters
Set the STI (builtin display/keyboard on the HP-PARISC
machines) console (graphic card) which should be used
as the initial boot-console.
See also comment in drivers/video/console/sticore.c.
See also comment in drivers/video/sticore.c.
sti_font= [HW]
See comment in drivers/video/console/sticore.c.
See comment in drivers/video/sticore.c.
stifb= [HW]
Format: bpp:<bpp1>[:<bpp2>[:<bpp3>...]]
@@ -7888,6 +7865,22 @@ Kernel parameters
first trust source as a backend which is initialized
successfully during iteration.
trusted.debug= [KEYS]
Format: <bool>
Enable trusted keys debug traces at runtime when
CONFIG_TRUSTED_KEYS_DEBUG=y.
To make the traces visible after enabling the option,
use trusted.dyndbg='+p' as needed. By convention,
the subsystem uses pr_debug() for these traces.
SAFETY: The traces can leak sensitive data, so be
cautious before enabling this. They remain inactive
unless this parameter is set this option to a true
value.
Default: false
trusted.rng= [KEYS]
Format: <string>
The RNG used to generate key material for trusted keys.

2
Documentation/admin-guide/laptops/sonypi.rst
View File

@@ -89,7 +89,7 @@ statically linked into the kernel). Those options are:
set to 0xffffffff, meaning that all possible events
will be tried. You can use the following bits to
construct your own event mask (from
drivers/char/sonypi.h)::
include/linux/sonypi.h)::
SONYPI_JOGGER_MASK 0x0001
SONYPI_CAPTURE_MASK 0x0002

17
Documentation/admin-guide/laptops/uniwill-laptop.rst
View File

@@ -46,11 +46,20 @@ Battery Charging Control
.. warning:: Some devices do not properly implement the charging threshold interface. Forcing
the driver to enable access to said interface on such devices might damage the
battery [1]_. Because of this the driver will not enable said feature even when
using the ``force`` module parameter.
using the ``force`` module parameter. The charging profile interface will be
available instead.
The ``uniwill-laptop`` driver supports controlling the battery charge limit. This happens over
the standard ``charge_control_end_threshold`` power supply sysfs attribute. All values
between 1 and 100 percent are supported.
The ``uniwill-laptop`` driver supports controlling the battery charge limit. This either happens
over the standard ``charge_control_end_threshold`` or ``charge_types`` power supply sysfs attribute,
depending on the device. When using the ``charge_control_end_threshold`` sysfs attribute, all values
between 1 and 100 percent are supported. When using the ``charge_types`` sysfs attribute, the driver
supports switching between the ``Standard``, ``Trickle`` and ``Long Life`` profiles.
Keep in mind that when using the ``charge_types`` sysfs attribute, the EC firmware will hide the
true charging status of the battery from the operating system, potentially misleading users into
thinking that the charging profile does not work. Checking the ``current_now`` sysfs attribute
tells you the true charging status of the battery even when using the ``charge_types`` sysfs
attribute (0 means that the battery is currently not charging).
Additionally the driver signals the presence of battery charging issues through the standard
``health`` power supply sysfs attribute.

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

@@ -734,7 +734,7 @@ also have
They should be scaled by the bitmap_chunksize.
sync_speed_min, sync_speed_max
This are similar to ``/proc/sys/dev/raid/speed_limit_{min,max}``
These are similar to ``/proc/sys/dev/raid/speed_limit_{min,max}``
however they only apply to the particular array.
If no value has been written to these, or if the word ``system``

63
Documentation/admin-guide/media/amdisp4-1.rst Normal file
View File

@@ -0,0 +1,63 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
====================================
AMD Image Signal Processor (amdisp4)
====================================
Introduction
============
This file documents the driver for the AMD ISP4 that is part of
AMD Ryzen AI Max 300 Series.
The driver is located under drivers/media/platform/amd/isp4 and uses
the Media-Controller API.
The driver exposes one video capture device to userspace and provide
web camera like interface. Internally the video device is connected
to the isp4 sub-device responsible for communication with the CCPU FW.
Topology
========
.. _amdisp4_topology_graph:
.. kernel-figure:: amdisp4.dot
:alt: Diagram of the media pipeline topology
:align: center
The driver has 1 sub-device: Representing isp4 image signal processor.
The driver has 1 video device: Capture device for retrieving images.
- ISP4 Image Signal Processing Subdevice Node
---------------------------------------------
The isp4 is represented as a single V4L2 subdev, the sub-device does not
provide interface to the user space. The sub-device is connected to one video node
(isp4_capture) with immutable active link. The sub-device represents ISP with
connected sensor similar to smart cameras (sensors with integrated ISP).
sub-device has only one link to the video device for capturing the frames.
The sub-device communicates with CCPU FW for streaming configuration and
buffer management.
- isp4_capture - Frames Capture Video Node
------------------------------------------
Isp4_capture is a capture device to capture frames to memory.
The entity is connected to isp4 sub-device. The video device
provides web camera like interface to userspace. It supports
mmap and dma buf types of memory.
Capturing Video Frames Example
==============================
.. code-block:: bash
v4l2-ctl "-d" "/dev/video0" "--set-fmt-video=width=1920,height=1080,pixelformat=NV12" "--stream-mmap" "--stream-count=10"

6
Documentation/admin-guide/media/amdisp4.dot Normal file
View File

@@ -0,0 +1,6 @@
digraph board {
rankdir=TB
n00000001 [label="{{} | amd isp4\n | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
n00000001:port0 -> n00000003 [style=bold]
n00000003 [label="Preview\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
}

29
Documentation/admin-guide/media/rkcif-rk3588-vicap.dot Normal file
View File

@@ -0,0 +1,29 @@
digraph board {
rankdir=TB
n00000007 [label="{{<port0> 0} | rkcif-mipi2\n/dev/v4l-subdev0 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
n00000007:port1 -> n0000000a
n00000007:port1 -> n00000010 [style=dashed]
n00000007:port1 -> n00000016 [style=dashed]
n00000007:port1 -> n0000001c [style=dashed]
n0000000a [label="rkcif-mipi2-id0\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
n00000010 [label="rkcif-mipi2-id1\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
n00000016 [label="rkcif-mipi2-id2\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
n0000001c [label="rkcif-mipi2-id3\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
n00000025 [label="{{<port0> 0} | rkcif-mipi4\n/dev/v4l-subdev1 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
n00000025:port1 -> n00000028
n00000025:port1 -> n0000002e [style=dashed]
n00000025:port1 -> n00000034 [style=dashed]
n00000025:port1 -> n0000003a [style=dashed]
n00000028 [label="rkcif-mipi4-id0\n/dev/video4", shape=box, style=filled, fillcolor=yellow]
n0000002e [label="rkcif-mipi4-id1\n/dev/video5", shape=box, style=filled, fillcolor=yellow]
n00000034 [label="rkcif-mipi4-id2\n/dev/video6", shape=box, style=filled, fillcolor=yellow]
n0000003a [label="rkcif-mipi4-id3\n/dev/video7", shape=box, style=filled, fillcolor=yellow]
n00000043 [label="{{<port0> 0} | dw-mipi-csi2rx fdd30000.csi\n/dev/v4l-subdev2 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
n00000043:port1 -> n00000007:port0
n00000048 [label="{{<port0> 0} | dw-mipi-csi2rx fdd50000.csi\n/dev/v4l-subdev3 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
n00000048:port1 -> n00000025:port0
n0000004d [label="{{} | imx415 3-001a\n/dev/v4l-subdev4 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
n0000004d:port0 -> n00000043:port0
n00000051 [label="{{} | imx415 4-001a\n/dev/v4l-subdev5 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
n00000051:port0 -> n00000048:port0
}

32
Documentation/admin-guide/media/rkcif.rst
View File

@@ -77,3 +77,35 @@ and the following video devices:
.. kernel-figure:: rkcif-rk3568-vicap.dot
:alt: Topology of the RK3568 Video Capture (VICAP) unit
:align: center
Rockchip RK3588 Video Capture (VICAP)
-------------------------------------
The RK3588 Video Capture (VICAP) unit features a digital video port and six
MIPI CSI-2 capture interfaces that can receive video data independently.
The DVP accepts parallel video data, BT.656 and BT.1120.
Since the BT.1120 protocol may feature more than one stream, the RK3588 VICAP
DVP features four DMA engines that can capture different streams.
Similarly, the RK3588 VICAP MIPI CSI-2 receivers feature four DMA engines each
to handle different Virtual Channels (VCs).
The rkcif driver represents this hardware variant by exposing the following
V4L2 subdevices:
* dw-mipi-csi2rx fdd30000.csi: MIPI CSI-2 receiver connected to MIPI DPHY0
* dw-mipi-csi2rx fdd50000.csi: MIPI CSI-2 receiver connected to MIPI DPHY1
* rkcif-mipi2: INTERFACE/CROP block for the MIPI CSI-2 receiver connected to
MIPI DPHY0
* rkcif-mipi4: INTERFACE/CROP block for the MIPI CSI-2 receiver connected to
MIPI DPHY1
and the following video devices:
* rkcif-mipi2-id{0,1,2,3}: The DMA engines connected to the rkcif-mipi2
INTERFACE/CROP block.
* rkcif-mipi4-id{0,1,2,3}: The DMA engines connected to the rkcif-mipi4
INTERFACE/CROP block.
.. kernel-figure:: rkcif-rk3588-vicap.dot
:alt: Topology of the RK3588 Video Capture (VICAP) unit
:align: center

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

@@ -9,6 +9,7 @@ Video4Linux (V4L) driver-specific documentation
.. toctree::
:maxdepth: 2
amdisp4-1
bttv
c3-isp
cafe_ccic

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

@@ -75,7 +75,7 @@ Make DAMON_LRU_SORT reads the input parameters again, except ``enabled``.
Input parameters that updated while DAMON_LRU_SORT is running are not applied
by default. Once this parameter is set as ``Y``, DAMON_LRU_SORT reads values
of parametrs except ``enabled`` again. Once the re-reading is done, this
of parameters except ``enabled`` again. Once the re-reading is done, this
parameter is set as ``N``. If invalid parameters are found while the
re-reading, DAMON_LRU_SORT will be disabled.
@@ -246,7 +246,8 @@ monitor_region_start
Start of target memory region in physical address.
The start physical address of memory region that DAMON_LRU_SORT will do work
against. By default, biggest System RAM is used as the region.
against. By default, the system's entire physical memory is used as the
region.
monitor_region_end
------------------
@@ -254,7 +255,8 @@ monitor_region_end
End of target memory region in physical address.
The end physical address of memory region that DAMON_LRU_SORT will do work
against. By default, biggest System RAM is used as the region.
against. By default, the system's entire physical memory is used as the
region.
addr_unit
---------

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

@@ -67,7 +67,7 @@ Make DAMON_RECLAIM reads the input parameters again, except ``enabled``.
Input parameters that updated while DAMON_RECLAIM is running are not applied
by default. Once this parameter is set as ``Y``, DAMON_RECLAIM reads values
of parametrs except ``enabled`` again. Once the re-reading is done, this
of parameters except ``enabled`` again. Once the re-reading is done, this
parameter is set as ``N``. If invalid parameters are found while the
re-reading, DAMON_RECLAIM will be disabled.
@@ -85,6 +85,17 @@ identifies the region as cold, and reclaims it.
120 seconds by default.
autotune_monitoring_intervals
-----------------------------
If this parameter is set as ``Y``, DAMON_RECLAIM automatically tunes DAMON's
sampling and aggregation intervals. The auto-tuning aims to capture meaningful
amount of access events in each DAMON-snapshot, while keeping the sampling
interval 5 milliseconds in minimum, and 10 seconds in maximum. Setting this as
``N`` disables the auto-tuning.
Disabled by default.
quota_ms
--------
@@ -229,7 +240,8 @@ Start of target memory region in physical address.
The start physical address of memory region that DAMON_RECLAIM will do work
against. That is, DAMON_RECLAIM will find cold memory regions in this region
and reclaims. By default, biggest System RAM is used as the region.
and reclaims. By default, the system's entire physical memory is used as the
region.
monitor_region_end
------------------
@@ -238,7 +250,8 @@ End of target memory region in physical address.
The end physical address of memory region that DAMON_RECLAIM will do work
against. That is, DAMON_RECLAIM will find cold memory regions in this region
and reclaims. By default, biggest System RAM is used as the region.
and reclaims. By default, the system's entire physical memory is used as the
region.
addr_unit
---------

7
Documentation/admin-guide/mm/damon/stat.rst
View File

@@ -89,3 +89,10 @@ percentiles of the idle time values via this read-only parameter. Reading the
parameter returns 101 idle time values in milliseconds, separated by comma.
Each value represents 0-th, 1st, 2nd, 3rd, ..., 99th and 100th percentile idle
times.
kdamond_pid
-----------
PID of the DAMON thread.
If DAMON_STAT is enabled, this becomes the PID of the worker thread. Else, -1.

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

@@ -66,11 +66,17 @@ comma (",").
│ :ref:`kdamonds <sysfs_kdamonds>`/nr_kdamonds
│ │ :ref:`0 <sysfs_kdamond>`/state,pid,refresh_ms
│ │ │ :ref:`contexts <sysfs_contexts>`/nr_contexts
│ │ │ │ :ref:`0 <sysfs_context>`/avail_operations,operations,addr_unit
│ │ │ │ :ref:`0 <sysfs_context>`/avail_operations,operations,addr_unit,
│ │ │ │ pause
│ │ │ │ │ :ref:`monitoring_attrs <sysfs_monitoring_attrs>`/
│ │ │ │ │ │ intervals/sample_us,aggr_us,update_us
│ │ │ │ │ │ │ intervals_goal/access_bp,aggrs,min_sample_us,max_sample_us
│ │ │ │ │ │ nr_regions/min,max
│ │ │ │ │ │ :ref:`probes <damon_usage_sysfs_probes>`/nr_probes
│ │ │ │ │ │ │ 0/filters/nr_filters
│ │ │ │ │ │ │ │ 0/type,matching,allow,path
│ │ │ │ │ │ │ │ ...
│ │ │ │ │ │ │ ...
│ │ │ │ │ :ref:`targets <sysfs_targets>`/nr_targets
│ │ │ │ │ │ :ref:`0 <sysfs_target>`/pid_target,obsolete_target
│ │ │ │ │ │ │ :ref:`regions <sysfs_regions>`/nr_regions
@@ -83,18 +89,23 @@ comma (",").
│ │ │ │ │ │ │ │ sz/min,max
│ │ │ │ │ │ │ │ nr_accesses/min,max
│ │ │ │ │ │ │ │ age/min,max
│ │ │ │ │ │ │ :ref:`quotas <sysfs_quotas>`/ms,bytes,reset_interval_ms,effective_bytes,goal_tuner
│ │ │ │ │ │ │ :ref:`quotas <sysfs_quotas>`/ms,bytes,reset_interval_ms,
│ │ │ │ │ │ │ effective_bytes,goal_tuner,
│ │ │ │ │ │ │ fail_charge_num,fail_charge_denom
│ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil
│ │ │ │ │ │ │ │ :ref:`goals <sysfs_schemes_quota_goals>`/nr_goals
│ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value,nid,path
│ │ │ │ │ │ │ :ref:`watermarks <sysfs_watermarks>`/metric,interval_us,high,mid,low
│ │ │ │ │ │ │ :ref:`{core_,ops_,}filters <sysfs_filters>`/nr_filters
│ │ │ │ │ │ │ │ 0/type,matching,allow,memcg_path,addr_start,addr_end,target_idx,min,max
│ │ │ │ │ │ │ │ 0/type,matching,allow,memcg_path,addr_start,addr_end,damon_target_idx,min,max
│ │ │ │ │ │ │ :ref:`dests <damon_sysfs_dests>`/nr_dests
│ │ │ │ │ │ │ │ 0/id,weight
│ │ │ │ │ │ │ :ref:`stats <sysfs_schemes_stats>`/nr_tried,sz_tried,nr_applied,sz_applied,sz_ops_filter_passed,qt_exceeds,nr_snapshots,max_nr_snapshots
│ │ │ │ │ │ │ :ref:`tried_regions <sysfs_schemes_tried_regions>`/total_bytes
│ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age,sz_filter_passed
│ │ │ │ │ │ │ │ │ probes
│ │ │ │ │ │ │ │ │ │ 0/hits
│ │ │ │ │ │ │ │ │ │ ...
│ │ │ │ │ │ │ │ ...
│ │ │ │ │ │ ...
│ │ │ │ ...
@@ -194,9 +205,9 @@ details). At the moment, only one context per kdamond is supported, so only
contexts/<N>/
-------------
In each context directory, three files (``avail_operations``, ``operations``
and ``addr_unit``) and three directories (``monitoring_attrs``, ``targets``,
and ``schemes``) exist.
In each context directory, four files (``avail_operations``, ``operations``,
``addr_unit`` and ``pause``) and three directories (``monitoring_attrs``,
``targets``, and ``schemes``) exist.
DAMON supports multiple types of :ref:`monitoring operations
<damon_design_configurable_operations_set>`, including those for virtual address
@@ -214,6 +225,9 @@ reading from the ``operations`` file.
``addr_unit`` file is for setting and getting the :ref:`address unit
<damon_design_addr_unit>` parameter of the operations set.
``pause`` file is for setting and getting the :ref:`pause request
<damon_design_execution_model_and_data_structures>` parameter of the context.
.. _sysfs_monitoring_attrs:
contexts/<N>/monitoring_attrs/
@@ -221,8 +235,8 @@ contexts/<N>/monitoring_attrs/
Files for specifying attributes of the monitoring including required quality
and efficiency of the monitoring are in ``monitoring_attrs`` directory.
Specifically, two directories, ``intervals`` and ``nr_regions`` exist in this
directory.
Specifically, three directories, ``intervals``, ``nr_regions`` and ``probes``
exist in this directory.
Under ``intervals`` directory, three files for DAMON's sampling interval
(``sample_us``), aggregation interval (``aggr_us``), and update interval
@@ -256,6 +270,29 @@ tuning-applied current values of the two intervals can be read from the
``sample_us`` and ``aggr_us`` files after writing ``update_tuned_intervals`` to
the ``state`` file.
.. _damon_usage_sysfs_probes:
contexts/<N>/monitoring_attrs/probes/
-------------------------------------
A directory for registering :ref:`data attributes monitoring
<damon_design_data_attrs_monitoring>` probes.
In the beginning, this directory has only one file, ``nr_probes``. Writing a
number (``N``) to the file creates the number of child directories named ``0``
to ``N-1``. Each directory represents each monitoring probe.
In each probe directory, one directory, ``filters`` exists. The directory
contains files for installing filters for the probe, that is used to determine
the data attribute for the probe.
In the beginning, ``filters`` directory has only one file, ``nr_filters``.
Writing a number (``N``) to the file creates the number of child directories
named ``0`` to ``N-1``. Each directory represents each filter and works in a
way similar to that for :ref:`DAMOS filter <sysfs_filters>`. When the filter
``type`` is ``memcg``, ``path`` file acts as ``memcg_path`` for :ref:`DAMOS
filter <sysfs_filters>`.
.. _sysfs_targets:
contexts/<N>/targets/
@@ -337,7 +374,7 @@ to ``N-1``. Each directory represents each DAMON-based operation scheme.
schemes/<N>/
------------
In each scheme directory, eight directories (``access_pattern``, ``quotas``,
In each scheme directory, nine directories (``access_pattern``, ``quotas``,
``watermarks``, ``core_filters``, ``ops_filters``, ``filters``, ``dests``,
``stats``, and ``tried_regions``) and three files (``action``, ``target_nid``
and ``apply_interval``) exist.
@@ -377,9 +414,10 @@ schemes/<N>/quotas/
The directory for the :ref:`quotas <damon_design_damos_quotas>` of the given
DAMON-based operation scheme.
Under ``quotas`` directory, five files (``ms``, ``bytes``,
``reset_interval_ms``, ``effective_bytes`` and ``goal_tuner``) and two
directories (``weights`` and ``goals``) exist.
Under ``quotas`` directory, seven files (``ms``, ``bytes``,
``reset_interval_ms``, ``effective_bytes``, ``goal_tuner``, ``fail_charge_num``
and ``fail_charge_denom``) and two directories (``weights`` and ``goals``)
exist.
You can set the ``time quota`` in milliseconds, ``size quota`` in bytes, and
``reset interval`` in milliseconds by writing the values to the three files,
@@ -398,6 +436,13 @@ the background design of the feature and the name of the selectable algorithms.
Refer to :ref:`goals directory <sysfs_schemes_quota_goals>` for the goals
setup.
You can set the action-failed memory quota charging ratio by writing the
numerator and the denominator for the ratio to ``fail_charge_num`` and
``fail_charge_denom`` files, respectively. Reading those files will return the
current set values. Refer to :ref:`design
<damon_design_damos_quotas_failed_memory_charging_ratio>` for more details of
the ratio feature.
The time quota is internally transformed to a size quota. Between the
transformed size quota and user-specified size quota, smaller one is applied.
Based on the user-specified :ref:`goal <sysfs_schemes_quota_goals>`, the
@@ -429,10 +474,12 @@ to ``N-1``. Each directory represents each goal and current achievement.
Among the multiple feedback, the best one is used.
Each goal directory contains five files, namely ``target_metric``,
``target_value``, ``current_value`` ``nid`` and ``path``. Users can set and
``target_value``, ``current_value``, ``nid``, and ``path``. Users can set and
get the five parameters for the quota auto-tuning goals that specified on the
:ref:`design doc <damon_design_damos_quotas_auto_tuning>` by writing to and
reading from each of the files. Note that users should further write
reading from each of the files. Because the kernel does not update
``current_value``, reading it only makes sense when ``target_metric`` is
``user_input``. Note that users should further write
``commit_schemes_quota_goals`` to the ``state`` file of the :ref:`kdamond
directory <sysfs_kdamond>` to pass the feedback to DAMON.
@@ -447,7 +494,7 @@ given DAMON-based operation scheme.
Under the watermarks directory, five files (``metric``, ``interval_us``,
``high``, ``mid``, and ``low``) for setting the metric, the time interval
between check of the metric, and the three watermarks exist. You can set and
get the five values by writing to the files, respectively.
get the five values by writing to and reading from the files, respectively.
Keywords and meanings of those that can be written to the ``metric`` file are
as below.
@@ -455,7 +502,7 @@ as below.
- none: Ignore the watermarks
- free_mem_rate: System's free memory rate (per thousand)
The ``interval`` should written in microseconds unit.
The ``interval_us`` should be written in microseconds unit.
.. _sysfs_filters:
@@ -471,10 +518,10 @@ directory can be used for installing filters regardless of their handled
layers. Filters that requested by ``core_filters`` and ``ops_filters`` will be
installed before those of ``filters``. All three directories have same files.
Use of ``filters`` directory can make expecting evaluation orders of given
filters with the files under directory bit confusing. Users are hence
recommended to use ``core_filters`` and ``ops_filters`` directories. The
``filters`` directory could be deprecated in future.
Use of ``filters`` directory can make filters evaluation orders confusing to
expect. For this reason, ``filters`` directory is deprecated. It is still
functioning, but is scheduled for removal in the near future. Users should use
``core_filters`` and ``ops_filters`` directories instead.
In the beginning, the directory has only one file, ``nr_filters``. Writing a
number (``N``) to the file creates the number of child directories named ``0``
@@ -483,9 +530,9 @@ in the numeric order.
Each filter directory contains nine files, namely ``type``, ``matching``,
``allow``, ``memcg_path``, ``addr_start``, ``addr_end``, ``min``, ``max``
and ``target_idx``. To ``type`` file, you can write the type of the filter.
Refer to :ref:`the design doc <damon_design_damos_filters>` for available type
names, their meaning and on what layer those are handled.
and ``damon_target_idx``. To ``type`` file, you can write the type of the
filter. Refer to :ref:`the design doc <damon_design_damos_filters>` for
available type names, their meaning and on what layer those are handled.
For ``memcg`` type, you can specify the memory cgroup of the interest by
writing the path of the memory cgroup from the cgroups mount point to
@@ -495,7 +542,7 @@ files, respectively. For ``hugepage_size`` type, you can specify the minimum
and maximum size of the range (closed interval) to ``min`` and ``max`` files,
respectively. For ``target`` type, you can specify the index of the target
between the list of the DAMON context's monitoring targets list to
``target_idx`` file.
``damon_target_idx`` file.
You can write ``Y`` or ``N`` to ``matching`` file to specify whether the filter
is for memory that matches the ``type``. You can write ``Y`` or ``N`` to
@@ -601,10 +648,19 @@ tried_regions/<N>/
------------------
In each region directory, you will find five files (``start``, ``end``,
``nr_accesses``, ``age``, and ``sz_filter_passed``). Reading the files will
``nr_accesses``, ``age`` and ``sz_filter_passed``). Reading the files will
show the properties of the region that corresponding DAMON-based operation
scheme ``action`` has tried to be applied.
tried_regions/<N>/probes/
-------------------------
In each region directory, one directory (``probes``) also exists. In the
directory, subdirectories named ``0`` to ``N-1`` exists. ``N`` is the number
of installed probes. In each number-named directory, a file (``hits``) exist.
Reading the file shows the number of data attributes monitoring probe-hit
positive samples of the region.
Example
~~~~~~~
@@ -677,7 +733,7 @@ show results using tracepoint supporting tools like ``perf``. For example::
Each line of the perf script output represents each monitoring region. The
first five fields are as usual other tracepoint outputs. The sixth field
(``target_id=X``) shows the ide of the monitoring target of the region. The
(``target_id=X``) shows the id of the monitoring target of the region. The
seventh field (``nr_regions=X``) shows the total number of monitoring regions
for the target. The eighth field (``X-Y:``) shows the start (``X``) and end
(``Y``) addresses of the region in bytes. The ninth field (``X``) shows the

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

@@ -455,7 +455,7 @@ used to change the file attributes on hugetlbfs.
Also, it is important to note that no such mount command is required if
applications are going to use only shmat/shmget system calls or mmap with
MAP_HUGETLB. For an example of how to use mmap with MAP_HUGETLB see
:ref:`map_hugetlb <map_hugetlb>` below.
:ref:`examples <examples>` below.
Users who wish to use hugetlb memory via shared memory segment should be
members of a supplementary group and system admin needs to configure that gid
@@ -473,16 +473,13 @@ a hugetlb page and the length is smaller than the hugepage size.
Examples
========
.. _map_hugetlb:
.. _examples:
``map_hugetlb``
see tools/testing/selftests/mm/map_hugetlb.c
``hugetlb-shm``
see tools/testing/selftests/mm/hugetlb-shm.c
``hugepage-shm``
see tools/testing/selftests/mm/hugepage-shm.c
``hugepage-mmap``
see tools/testing/selftests/mm/hugepage-mmap.c
``hugetlb-mmap``
see tools/testing/selftests/mm/hugetlb-mmap.c
The `libhugetlbfs`_ library provides a wide range of userspace tools
to help with huge page usability, environment setup, and control.

75
Documentation/admin-guide/mm/transhuge.rst
View File

@@ -57,13 +57,14 @@ prominent because the size of each page isn't as huge as the PMD-sized
variant and there is less memory to clear in each page fault. Some
architectures also employ TLB compression mechanisms to squeeze more
entries in when a set of PTEs are virtually and physically contiguous
and approporiately aligned. In this case, TLB misses will occur less
and appropriately aligned. In this case, TLB misses will occur less
often.
THP can be enabled system wide or restricted to certain tasks or even
memory ranges inside task's address space. Unless THP is completely
disabled, there is ``khugepaged`` daemon that scans memory and
collapses sequences of basic pages into PMD-sized huge pages.
collapses sequences of basic pages into huge pages of either PMD size
or mTHP sizes, if the system is configured to do so.
The THP behaviour is controlled via :ref:`sysfs <thp_sysfs>`
interface and using madvise(2) and prctl(2) system calls.
@@ -210,7 +211,7 @@ PMD-mappable transparent hugepage::
cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
All THPs at fault and collapse time will be added to _deferred_list,
and will therefore be split under memory presure if they are considered
and will therefore be split under memory pressure if they are considered
"underused". A THP is underused if the number of zero-filled pages in
the THP is above max_ptes_none (see below). It is possible to disable
this behaviour by writing 0 to shrink_underused, and enable it by writing
@@ -219,10 +220,10 @@ this behaviour by writing 0 to shrink_underused, and enable it by writing
echo 0 > /sys/kernel/mm/transparent_hugepage/shrink_underused
echo 1 > /sys/kernel/mm/transparent_hugepage/shrink_underused
khugepaged will be automatically started when PMD-sized THP is enabled
khugepaged will be automatically started when any THP size is enabled
(either of the per-size anon control or the top-level control are set
to "always" or "madvise"), and it'll be automatically shutdown when
PMD-sized THP is disabled (when both the per-size anon control and the
all THP sizes are disabled (when both the per-size anon control and the
top-level control are "never")
process THP controls
@@ -265,8 +266,8 @@ Khugepaged controls
-------------------
.. note::
khugepaged currently only searches for opportunities to collapse to
PMD-sized THP and no attempt is made to collapse to other THP
khugepaged currently only searches for opportunities to collapse file/shmem
to PMD-sized THP. Only anonymous memory will attempt to collapse to other THP
sizes.
khugepaged runs usually at low frequency so while one may not want to
@@ -296,11 +297,11 @@ allocation failure to throttle the next allocation attempt::
The khugepaged progress can be seen in the number of pages collapsed (note
that this counter may not be an exact count of the number of pages
collapsed, since "collapsed" could mean multiple things: (1) A PTE mapping
being replaced by a PMD mapping, or (2) All 4K physical pages replaced by
one 2M hugepage. Each may happen independently, or together, depending on
the type of memory and the failures that occur. As such, this value should
be interpreted roughly as a sign of progress, and counters in /proc/vmstat
consulted for more accurate accounting)::
being replaced by a PMD mapping, or (2) physical pages replaced by one
hugepage of various sizes (PMD-sized or mTHP). Each may happen independently,
or together, depending on the type of memory and the failures that occur.
As such, this value should be interpreted roughly as a sign of progress,
and counters in /proc/vmstat consulted for more accurate accounting)::
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_collapsed
@@ -308,16 +309,21 @@ for each pass::
/sys/kernel/mm/transparent_hugepage/khugepaged/full_scans
``max_ptes_none`` specifies how many extra small pages (that are
not already mapped) can be allocated when collapsing a group
of small pages into one large page::
``max_ptes_none`` specifies how many empty (none/zero) pages are allowed
when collapsing a group of small pages into one large page::
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none
A higher value leads to use additional memory for programs.
A lower value leads to gain less thp performance. Value of
max_ptes_none can waste cpu time very little, you can
ignore it.
For PMD-sized THP collapse, this directly limits the number of empty pages
allowed in the 2MB region.
For mTHP collapse, only 0 or (HPAGE_PMD_NR - 1) are supported. At
HPAGE_PMD_NR - 1, we collapse to the highest possible order. Any intermediate
value will emit a warning and mTHP collapse will default to max_ptes_none=0.
A higher value allows more empty pages, potentially leading to more memory
usage but better THP performance. A lower value is more conservative and
may result in fewer THP collapses.
``max_ptes_swap`` specifies how many pages can be brought in from
swap when collapsing a group of pages into a transparent huge page::
@@ -337,6 +343,15 @@ that THP is shared. Exceeding the number would block the collapse::
A higher value may increase memory footprint for some workloads.
.. note::
For mTHP collapse, khugepaged does not support collapsing regions that
contain shared or swapped out pages, as this could lead to continuous
promotion to higher orders. The collapse will fail if any shared or
swapped PTEs are encountered during the scan.
Currently, madvise_collapse only supports collapsing to PMD-sized THPs
and does not attempt mTHP collapses.
Boot parameters
===============
@@ -639,6 +654,14 @@ anon_fault_fallback_charge
instead falls back to using huge pages with lower orders or
small pages even though the allocation was successful.
collapse_alloc
is incremented every time a huge page is successfully allocated for a
khugepaged collapse.
collapse_alloc_failed
is incremented every time a huge page allocation fails during a
khugepaged collapse.
zswpout
is incremented every time a huge page is swapped out to zswap in one
piece without splitting.
@@ -706,6 +729,20 @@ nr_anon_partially_mapped
an anonymous THP as "partially mapped" and count it here, even though it
is not actually partially mapped anymore.
collapse_exceed_none_pte
The number of collapse attempts that failed due to exceeding the
max_ptes_none threshold.
collapse_exceed_swap_pte
The number of collapse attempts that failed due to exceeding the
max_ptes_swap threshold. For non-PMD orders this occurs if a mTHP range
contains at least one swap PTE.
collapse_exceed_shared_pte
The number of collapse attempts that failed due to exceeding the
max_ptes_shared threshold. For non-PMD orders this occurs if a mTHP range
contains at least one shared PTE.
As the system ages, allocating huge pages may be expensive as the
system uses memory compaction to copy data around memory to free a
huge page for use. There are some counters in ``/proc/vmstat`` to help

6
Documentation/admin-guide/pm/cpufreq.rst
View File

@@ -516,7 +516,7 @@ This governor exposes the following tunables:
of those tasks above 0 and set this attribute to 1.
``sampling_down_factor``
Temporary multiplier, between 1 (default) and 100 inclusive, to apply to
Temporary multiplier, between 1 (default) and 100000 inclusive, to apply to
the ``sampling_rate`` value if the CPU load goes above ``up_threshold``.
This causes the next execution of the governor's worker routine (after
@@ -586,8 +586,8 @@ This governor exposes the following tunables:
100 (5 by default).
This is how much the frequency is allowed to change in one go. Setting
it to 0 will cause the default frequency step (5 percent) to be used
and setting it to 100 effectively causes the governor to periodically
it to 0 disables frequency changes by the governor entirely and setting
it to 100 effectively causes the governor to periodically
switch the frequency between the ``scaling_min_freq`` and
``scaling_max_freq`` policy limits.

7
Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst
View File

@@ -88,8 +88,15 @@ and "fabric_cluster_id" in the directory.
Attributes in each directory:
``instance_id``
This attribute is used to get die indices in userspace mapped MMIO
blocks. Indices are local to a single TPMI partition. Needed for direct
TPMI register access.
``domain_id``
This attribute is used to get the power domain id of this instance.
Indices are unique in all TPMI partitions on a given CPU package. Can be
used to map compute dies to corresponding CPUs.
``die_id``
This attribute is used to get the Linux die id of this instance.

2
Documentation/admin-guide/quickly-build-trimmed-linux.rst
View File

@@ -217,7 +217,7 @@ again.
There is a catch: 'localmodconfig' is likely to disable kernel features you
did not use since you booted your Linux -- like drivers for currently
disconnected peripherals or a virtualization software not haven't used yet.
disconnected peripherals or virtualization software not currently in use.
You can reduce or nearly eliminate that risk with tricks the reference
section outlines; but when building a kernel just for quick testing purposes
it is often negligible if such features are missing. But you should keep that

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

@@ -129,7 +129,7 @@ After these preparations you'll now enter the main part:
situations; during the merge window that actually might be even the best
approach, but in that development phase it can be an even better idea to
suspend your efforts for a few days anyway. Whatever version you choose,
ideally use a 'vanilla' build. Ignoring these advices will dramatically
ideally use a 'vanilla' build. Ignoring all of this advice will dramatically
increase the risk your report will be rejected or ignored.
* Ensure the kernel you just installed does not 'taint' itself when
@@ -795,7 +795,7 @@ Install a fresh kernel for testing
situations; during the merge window that actually might be even the best
approach, but in that development phase it can be an even better idea to
suspend your efforts for a few days anyway. Whatever version you choose,
ideally use a 'vanilla' built. Ignoring these advices will dramatically
ideally use a 'vanilla' built. Ignoring all of this advice will dramatically
increase the risk your report will be rejected or ignored.*
As mentioned in the detailed explanation for the first step already: Like most

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

@@ -36,12 +36,11 @@ Table : Subdirectories in /proc/sys/net
========= =================== = ========== ===================
802 E802 protocol mptcp Multipath TCP
appletalk Appletalk protocol netfilter Network Filter
ax25 AX25 netrom NET/ROM
bridge Bridging rose X.25 PLP layer
core General parameter tipc TIPC
ethernet Ethernet protocol unix Unix domain sockets
ipv4 IP version 4 vsock VSOCK sockets
ipv6 IP version 6 x25 X.25 protocol
bridge Bridging tipc TIPC
core General parameter unix Unix domain sockets
ethernet Ethernet protocol vsock VSOCK sockets
ipv4 IP version 4 x25 X.25 protocol
ipv6 IP version 6
========= =================== = ========== ===================
1. /proc/sys/net/core - Network core options
@@ -475,51 +474,7 @@ Please see: Documentation/networking/ip-sysctl.rst and
Documentation/admin-guide/sysctl/net.rst for descriptions of these entries.
4. Appletalk
------------
The /proc/sys/net/appletalk directory holds the Appletalk configuration data
when Appletalk is loaded. The configurable parameters are:
aarp-expiry-time
----------------
The amount of time we keep an ARP entry before expiring it. Used to age out
old hosts.
aarp-resolve-time
-----------------
The amount of time we will spend trying to resolve an Appletalk address.
aarp-retransmit-limit
---------------------
The number of times we will retransmit a query before giving up.
aarp-tick-time
--------------
Controls the rate at which expires are checked.
The directory /proc/net/appletalk holds the list of active Appletalk sockets
on a machine.
The fields indicate the DDP type, the local address (in network:node format)
the remote address, the size of the transmit pending queue, the size of the
received queue (bytes waiting for applications to read) the state and the uid
owning the socket.
/proc/net/atalk_iface lists all the interfaces configured for appletalk.It
shows the name of the interface, its Appletalk address, the network range on
that address (or network number for phase 1 networks), and the status of the
interface.
/proc/net/atalk_route lists each known network route. It lists the target
(network) that the route leads to, the router (may be directly connected), the
route flags, and the device the route is using.
5. TIPC
4. TIPC
-------
tipc_rmem

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

@@ -1034,6 +1034,8 @@ min(3% of current process size, user_reserve_kbytes) of free memory.
This is intended to prevent a user from starting a single memory hogging
process, such that they cannot recover (kill the hog).
This setting has no effect when overcommit_memory is set to 0 or 1.
user_reserve_kbytes defaults to min(3% of the current process size, 128MB).
If this is reduced to zero, then the user will be allowed to allocate

61
Documentation/admin-guide/thunderbolt.rst
View File

@@ -373,6 +373,67 @@ port which are named like ``thunderbolt0`` and so on. From this point
you can either use standard userspace tools like ``ip`` to
configure the interface or let your GUI handle it automatically.
Streaming data directly over Thunderbolt cable
----------------------------------------------
In addition to Thunderbolt networking (aka. USB4NET) Linux supports
streaming data directly over a cable as well (aka. USB4STREAM). This is
possible through ``thunderbolt-stream`` driver.
Similarly to ``thunderbolt-net`` you load the driver first on one end::
host1 # modprobe thunderbolt-stream
Then you configure it via ``ConfigFS``::
host1 # cd /sys/kernel/config/thunderbolt/stream
host1 # mkdir -p 0-1.0/data
host1 # cd 0-1.0
host1 # echo -1 > data/in_hopid
host1 # echo -1 > data/out_hopid
This information is automatically announced to the other side via
XDomain properties so if you have cable connected the other side knows
that there is a stream named ``data`` available and can configure it for
you automatically::
host2 # cd /sys/kernel/config/thunderbolt/stream
host2 # mkdir -p 0-3.0/data
Here we used auto-configuration but you can configure it manually too.
In that case you need to fill ``in_hopid`` and ``out_hopid`` accordingly.
If you set them to ``-1`` the next available HopID is used which is
typically what we want.
Once they are configured you can use ``/dev/tbstreamX`` on both sides to
transfer data::
host2 # cat /dev/tbstream0
host1 # dmesg > /dev/tbstream0
Once you are done with the stream you can remove them::
host2 # cd /sys/kernel/config/thunderbolt/stream
host2 # rmdir -p 0-1.0/data
host1 # cd /sys/kernel/config/thunderbolt/stream
host1 # rmdir -p 0-3.0/data
Since streams are essentially files you can use any existing application
that supports ``read(2)`` and ``write(2)`` in some form.
It is possible to have more than one stream and you can have both stream
and ``thunderbolt-net`` in use simultaneously. For example we can create
two streams with name ``control`` and ``data`` like this::
host1 # cd /sys/kernel/config/thunderbolt/stream
host1 # mkdir 0-1.0
host1 # cd 0-1.0
host1 # mkdir control
host1 # mkdir data
Then you have ``/dev/tbstream0`` for ``control`` and ``/dev/tbstream1``
for ``data``. Before you can use them you need to configure them as
shown above for the one stream case.
Forcing power
-------------
Many OEMs include a method that can be used to force the power of a

41
Documentation/admin-guide/workload-tracing.rst
View File

@@ -202,6 +202,15 @@ database. To get out of this mode press ctrl+d. -p option is used to
specify the number of file path components to display. -p10 is optimal
for browsing kernel sources.
Alternatively, the kernel build system can generate the cscope database::
make cscope
To exclude directories from the generated database, pass IGNORE_DIRS to
the cscope target. For example, to exclude Documentation/, run::
make IGNORE_DIRS="Documentation" cscope
What is perf and how do we use it?
==================================
@@ -243,13 +252,21 @@ which can help mitigate performance regressions. It also acts as a common
benchmarking framework, enabling developers to easily create test cases,
integrate transparently, and use performance-rich tooling.
"perf bench all" command runs the following benchmarks:
"perf bench all" runs all available benchmarks in the perf bench
framework. The exact set of benchmarks depends on the perf version and on
the features enabled when perf was built.
* sched/messaging
* sched/pipe
* syscall/basic
* mem/memcpy
* mem/memset
To list the benchmark collections available on the current system, run::
perf bench
To list benchmarks in a collection, run::
perf bench <collection>
For example, to list the benchmarks in the mem collection, run::
perf bench mem
What is stress-ng and how do we use it?
=======================================
@@ -271,17 +288,17 @@ exercised:
The following command runs the stressor::
stress-ng --netdev 1 -t 60 --metrics command.
stress-ng --netdev 1 -t 60 --metrics
We can use the perf record command to record the events and information
associated with a process. This command records the profiling data in the
perf.data file in the same directory.
Using the following commands you can record the events associated with the
netdev stressor, view the generated report perf.data and annotate the to
view the statistics of each instruction of the program::
netdev stressor, view the generated report perf.data and annotate the output
to view the statistics of each instruction of the program::
perf record stress-ng --netdev 1 -t 60 --metrics command.
perf record -- stress-ng --netdev 1 -t 60 --metrics
perf report
perf annotate
@@ -349,13 +366,13 @@ times each system call is invoked, and the corresponding Linux subsystem.
+-------------------+-----------+-----------------+-------------------------+
| geteuid | 1 | Process Mgmt. | sys_geteuid() |
+-------------------+-----------+-----------------+-------------------------+
| getegid | 1 | Process Mgmt. | sys_getegid |
| getegid | 1 | Process Mgmt. | sys_getegid() |
+-------------------+-----------+-----------------+-------------------------+
| close | 49951 | Filesystem | sys_close() |
+-------------------+-----------+-----------------+-------------------------+
| pipe | 604 | Filesystem | sys_pipe() |
+-------------------+-----------+-----------------+-------------------------+
| openat | 48560 | Filesystem | sys_opennat() |
| openat | 48560 | Filesystem | sys_openat() |
+-------------------+-----------+-----------------+-------------------------+
| fstat | 8338 | Filesystem | sys_fstat() |
+-------------------+-----------+-----------------+-------------------------+

2
Documentation/arch/arc/arc.rst
View File

@@ -36,7 +36,7 @@ Important note on ARC processors configurability
ARC processors are highly configurable and several configurable options
are supported in Linux. Some options are transparent to software
(i.e cache geometries, some can be detected at runtime and configured
(e.g., cache geometries), some can be detected at runtime and configured
and used accordingly, while some need to be explicitly selected or configured
in the kernel's configuration utility (AKA "make menuconfig").

2
Documentation/arch/arm/index.rst
View File

@@ -75,3 +75,5 @@ SoC-specific documents
sti/overview
vfp/release-notes
zte/index

4
Documentation/arch/arm/kernel_mode_neon.rst
View File

@@ -121,4 +121,6 @@ observe the following in addition to the rules above:
* Compile the unit containing the NEON intrinsics with '-ffreestanding' so GCC
uses its builtin version of <stdint.h> (this is a C99 header which the kernel
does not supply);
* Include <arm_neon.h> last, or at least after <linux/types.h>
* Do not include <arm_neon.h> directly: instead, include <asm/neon-intrinsics.h>,
which tweaks some macro definitions so that system headers can be included
safely.

2
Documentation/arch/arm/omap/dss.rst
View File

@@ -314,7 +314,7 @@ Kernel boot arguments
omapfb.mode=<display>:<mode>[,...]
- Default video mode for specified displays. For example,
"dvi:800x400MR-24@60". See drivers/video/modedb.c.
"dvi:800x400MR-24@60". See drivers/video/fbdev/core/modedb.c.
There are also two special modes: "pal" and "ntsc" that
can be used to tv out.

2
Documentation/arch/arm/samsung/clksrc-change-registers.awk
View File

@@ -163,4 +163,4 @@ BEGIN {
}
}
// && ! /clksrc_clk.*=.*{/ { print $0 }
// && ! /clksrc_clk.*=.*{/ { print $0 }}

4
Documentation/arch/arm/vlocks.rst
View File

@@ -102,10 +102,10 @@ Features and limitations
if (I_won) {
/* we won the town election, let's go for the state */
my_state = states[(this_cpu >> 8) & 0xf];
I_won = vlock_lock(my_state, this_cpu & 0xf));
I_won = vlock_lock(my_state, this_cpu & 0xf);
if (I_won) {
/* and so on */
I_won = vlock_lock(the_whole_country, this_cpu & 0xf];
I_won = vlock_lock(the_whole_country, this_cpu & 0xf);
if (I_won) {
/* ... */
}

10
Documentation/arch/arm/zte/index.rst Normal file
View File

@@ -0,0 +1,10 @@
.. SPDX-License-Identifier: GPL-2.0-only
=======
ZTE SoC
=======
.. toctree::
:maxdepth: 1
zx297520v3

166
Documentation/arch/arm/zte/zx297520v3.rst Normal file
View File

@@ -0,0 +1,166 @@
.. SPDX-License-Identifier: GPL-2.0-only
====================================
Booting Linux on ZTE zx297520v3 SoCs
====================================
Author: Stefan Dösinger
Date : 27 Jan 2026
1. Hardware description
---------------------------
Zx297520v3 SoCs use a 64-bit capable Cortex-A53 CPU and GICv3, although they
run in arm32 mode only. The CPU has support EL3, but no hypervisor (EL2) and
it seems to lack VFP and NEON.
The SoC is used in a number of cheap LTE to WiFi routers, both battery powered
MiFis and stationary CPEs. In addition to the CPU these devices usually have
64 MB Ram (although some is shared with the LTE chip), 128 MB NAND flash, an
SDIO connected RTL8192-type Wifi chip limited to 2.4 ghz operation, USB 2,
and buttons. Devices with as low as 32 MB or as high as 128 MB ram exist, as
do devices with 8 or 16 MB of NOR flash.
Some devices, especially the stationary ones, have 100 mbit Ethernet and an
Ethernet switch.
Usually the devices have LEDs for status indication, although some have SPI or
I2C connected displays.
Some have an SD card slot. If it exists, it is a better choice for the root
file system because it easily outperforms the built-in NAND.
The LTE interface runs on a separate DSP called ZSP880. It is probably derived
from LSI ZSPs and has an undocumented instruction set. The ZSP communicates
with the main CPU via SRAM and DRAM and a mailbox hardware that can generate
IRQs on either ends.
There is also a Cortex M0 CPU, which is responsible for early HW initialization
and starting the Cortex A53 CPU. It does not have any essential purpose once
U-Boot is started. An SRAM-based handover protocol exists to run custom code on
this CPU.
2. Booting via USB
---------------------------
The Boot ROM has support for booting custom code via USB. This mode can be
entered by connecting a Boot PIN to GND or by modifying the third byte on NAND
(set it to anything other than 0x5A aka 'Z'). A free software tool to start
custom U-Boot and kernels can be found here:
https://github.com/zx297520v3-mainline/zx297520v3-loader
If USB download mode is entered but no boot commands are sent through USB, the
device will proceed to boot normally after a few seconds. It is therefore
possible to enable USB boot permanently and still leave the default boot files
in place.
https://github.com/zx297520v3-mainline/u-boot-mainline
Contains an U-Boot version that can be used with the USB loader and sets up the
CPU and interrupt controller to comply with Linux's booting requirements.
3. Building for built-in U-Boot
-------------------------------
The devices come with an ancient U-Boot that loads legacy uImages from NAND and
boots them without a chance for the user to interrupt. The images are stored in
files ap_cpuap.bin and ap_recovery.bin on a jffs2 partition named imagefs,
usually mtd4. A file named "fotaflag" switches between the two modes.
In addition to the uImage header, those files have a 384-byte signature header,
which is used for authenticating the images on some devices. Most devices have
this authentication disabled and it is enough to pad the uImage files with 384
zero bytes.
Builtin U-Boot also poorly sets up the CPU. Read the next section for details
on this. It has no support for loading DTBs, so CONFIG_ARM_APPENDED_DTB is
needed.
So to build an image that boots from NAND the following steps are necessary:
1) Patch the assembly code from section 3 into arch/arm/kernel/head.S.
2) make zx29_defconfig
3) make [-j x]
4) cat arch/arm/boot/zImage arch/arm/boot/dts/zte/[device].dtb > kernel+dtb
5) mkimage -A arm -O linux -T kernel -C none -a 0x20008000 -d kernel+dtb uimg
6) dd if=/dev/zero bs=1 count=384 of=ap_recovery.bin
7) cat uimg >> ap_recovery.bin
8) Place this file onto imagefs on the device. Delete ap_cpuap.bin if the
free space is not enough.
9) Create the file fotaflag: echo -n FOTA-RECOVERY > fotaflag
For development, booting ap_recovery.bin is recommended because the normal boot
mode arms the watchdog before starting the kernel.
4. CPU and GIC Setup
---------------------------
Generally CPU and GICv3 need to be set up according to the requirements spelled
out in Documentation/arch/arm64/booting.rst. For zx297520v3 this means:
1. GICD_CTLR.DS=1 to disable GIC security
2. Enable access to ICC_SRE
3. Disable trapping IRQs into monitor mode
4. Configure EL2 and below to run in insecure mode.
5. Configure timer PPIs to active-low.
The kernel sources provided by ZTE do not boot either (interrupts do not work
at all). They are incomplete in other aspects too, so it is assumed that there
is some workaround similar to the one described in this document somewhere in
the binary blobs.
The assembly code below is given as an example of how to achieve this:
::
#include <linux/irqchip/arm-gic-v3.h>
#include <asm/assembler.h>
#include <asm/cp15.h>
@ Detect sane bootloaders and skip the hack
ldr r3, =0xf2000000
ldr r3, [r3]
ldr r4, =(GICD_CTLR_ARE_NS | GICD_CTLR_DS)
cmp r3, r4
beq skip_zx_hack
@ This allows EL1 to handle ints hat are normally handled by EL2/3.
ldr r3, =0xf2000000
str r4, [r3]
cps #MON_MODE
@ Work in non-secure physical address space: SCR_EL3.NS = 1. At least the UART
@ seems to respond only to non-secure addresses. I have taken insipiration from
@ Raspberry pi's armstub7.S here.
mov r3, #0x131 @ non-secure, Make F, A bits in CPSR writeable
@ Allow hypervisor call.
mcr p15, 0, r3, c1, c1, 0
@ AP_PPI_MODE_REG: Configure timer PPIs (10, 11, 13, 14) to active-low.
ldr r3, =0xF22020a8
ldr r4, =0x50
str r4, [r3]
ldr r3, =0xF22020ac
ldr r4, =0x14
str r4, [r3]
@ Enable EL2 access to ICC_SRE (bit 3, ICC_SRE_EL3.Enable). Enable system reg
@ access to GICv3 registers (bit 0, ICC_SRE_EL3.SRE) for EL1 and EL3.
mrc p15, 6, r3, c12, c12, 5 @ ICC_SRE_EL3
orr r3, #0x9 @ FIXME: No defines for SRE_EL3 values?
mcr p15, 6, r3, c12, c12, 5
mrc p15, 0, r3, c12, c12, 5 @ ICC_SRE_EL1
orr r3, #(ICC_SRE_EL1_SRE)
mcr p15, 0, r3, c12, c12, 5
@ Like ICC_SRE_EL3, enable EL1 access to ICC_SRE and system register access
@ for EL2.
mrc p15, 4, r3, c12, c9, 5 @ ICC_SRE_EL2 aka ICC_HSRE
orr r3, r3, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE)
mcr p15, 4, r3, c12, c9, 5
isb
@ Back to SVC mode
cps #SVC_MODE
skip_zx_hack:

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

@@ -451,6 +451,33 @@ HWCAP3_LS64
of CPU. User should only use ld64b/st64b on supported target (device)
memory location, otherwise fallback to the non-atomic alternatives.
HWCAP3_SVE_B16MM
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
ID_AA64ZFR0_EL1.B16B16 == 0b0011
HWCAP3_SVE2P3
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
ID_AA64ZFR0_EL1.SVEver == 0b0100
HWCAP3_SME_LUT6
Functionality implied by ID_AA64SMFR0_EL1.LUT6 == 0b1
HWCAP3_SME2P3
Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0100
HWCAP3_F16MM
Functionality implied by ID_AA64FPFR0_EL1.F16MM2 == 0b1
HWCAP3_F16F32DOT
Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0010
HWCAP3_F16F32MM
Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0011
HWCAP3_SVE_LUT6
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001 and
ID_AA64ISAR2_EL1.LUT == 0b0010.
4. Unused AT_HWCAP bits
-----------------------

2
Documentation/arch/arm64/memory-tagging-extension.rst
View File

@@ -222,7 +222,7 @@ programs should not retry in case of a non-zero system call return.
address ABI control and MTE configuration of a process as per the
``prctl()`` options described in
Documentation/arch/arm64/tagged-address-abi.rst and above. The corresponding
``regset`` is 1 element of 8 bytes (``sizeof(long))``).
``regset`` is 1 element of 8 bytes (``sizeof(long)``).
Core dump support
-----------------

93
Documentation/arch/arm64/silicon-errata.rst
View File

@@ -116,7 +116,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A76 | #1188873,1418040| ARM64_ERRATUM_1418040 |
| ARM | Cortex-A76 | #1188873, | ARM64_ERRATUM_1418040 |
| | | #1418040 | |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A76 | #1165522 | ARM64_ERRATUM_1165522 |
+----------------+-----------------+-----------------+-----------------------------+
@@ -128,15 +129,28 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A76 | #3324349 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A76 | #4193800 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A76AE | #4193801 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A77 | #1491015 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A77 | #3324348 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A77 | #4193798 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A78 | #3324344 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A78C | #3324346,3324347| ARM64_ERRATUM_3194386 |
| ARM | Cortex-A78 | #4193791 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A78AE | #4193793 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A78C | #3324346, | ARM64_ERRATUM_3194386 |
| | | #3324347 | |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A78C | #4193794 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
+----------------+-----------------+-----------------+-----------------------------+
@@ -146,6 +160,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A710 | #3324338 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A710 | #4193788 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A715 | #2645198 | ARM64_ERRATUM_2645198 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A715 | #3456084 | ARM64_ERRATUM_3194386 |
@@ -158,30 +174,44 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X1 | #3324344 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X1 | #4193791 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X1C | #3324346 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X1C | #4193792 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X2 | #3324338 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X2 | #4193788 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X3 | #3324335 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X3 | #4193786 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X4 | #3194386 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X4 | #4118414 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X925 | #3324334 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 |
| ARM | Cortex-X925 | #4193781 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N1 | #1349291 | N/A |
| ARM | Neoverse-N1 | #1188873, | ARM64_ERRATUM_1418040 |
| | | #1418040 | |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N1 | #1490853 | N/A |
| ARM | Neoverse-N1 | #1349291, | N/A |
| | | #1490853 | |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N1 | #3324349 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N1 | #4193800 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N2 | #2139208 | ARM64_ERRATUM_2139208 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N2 | #2067961 | ARM64_ERRATUM_2067961 |
@@ -190,24 +220,41 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N2 | #3324339 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N2 | #4193789 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N3 | #3456111 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V1 | #1619801 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V1 | #3324341 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V1 | #4193790 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V2 | #3324336 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V2 | #4193787 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V3 | #4193784 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V3AE | #3312417 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V3AE | #4193784 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | C1-Premium | #4193780 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | C1-Pro | #4193714 | ARM64_ERRATUM_4193714 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | MMU-500 | #841119,826419 | ARM_SMMU_MMU_500_CPRE_ERRATA|
| | | #562869,1047329 | |
| ARM | C1-Ultra | #4193780 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | MMU-600 | #1076982,1209401| N/A |
| ARM | MMU-500 | #562869, | ARM_SMMU_MMU_500_CPRE_ERRATA|
| | | #841119, | |
| | | #826419, | |
| | | #1047329 | |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | MMU-600 | #1076982, | N/A |
| | | #1209401 | |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | MMU-700 | #2133013, | N/A |
| | | #2268618, | |
@@ -230,11 +277,13 @@ stable kernels.
| Broadcom | Brahma-B53 | N/A | ARM64_ERRATUM_843419 |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX ITS | #22375,24313 | CAVIUM_ERRATUM_22375 |
| Cavium | ThunderX ITS | #22375, | CAVIUM_ERRATUM_22375 |
| | | #24313 | |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX GICv3 | #23154,38545 | CAVIUM_ERRATUM_23154 |
| Cavium | ThunderX GICv3 | #23154, | CAVIUM_ERRATUM_23154 |
| | | #38545 | |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX GICv3 | #38539 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
@@ -244,9 +293,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX SMMUv2 | #27704 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX2 SMMUv3| #74 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX2 SMMUv3| #126 | N/A |
| Cavium | ThunderX2 SMMUv3| #74, | N/A |
| | | #126 | |
+----------------+-----------------+-----------------+-----------------------------+
| Cavium | ThunderX2 Core | #219 | CAVIUM_TX2_ERRATUM_219 |
+----------------+-----------------+-----------------+-----------------------------+
@@ -256,13 +304,13 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| NVIDIA | Carmel Core | N/A | NVIDIA_CARMEL_CNP_ERRATUM |
+----------------+-----------------+-----------------+-----------------------------+
| NVIDIA | Olympus core | T410-OLY-1029 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+
| NVIDIA | T241 GICv3/4.x | T241-FABRIC-4 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| NVIDIA | T241 MPAM | T241-MPAM-1 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| NVIDIA | T241 MPAM | T241-MPAM-4 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| NVIDIA | T241 MPAM | T241-MPAM-6 | N/A |
| NVIDIA | T241 MPAM | T241-MPAM-1, | N/A |
| | | T241-MPAM-4, | |
| | | T241-MPAM-6 | |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
@@ -270,9 +318,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip0{5,6,7} | #161010101 | HISILICON_ERRATUM_161010101 |
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip0{6,7} | #161010701 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip0{6,7} | #161010803 | N/A |
| Hisilicon | Hip0{6,7} | #161010701, | N/A |
| | | #161010803 | |
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip07 | #161600802 | HISILICON_ERRATUM_161600802 |
+----------------+-----------------+-----------------+-----------------------------+
@@ -284,6 +331,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip09 | #162100801 | HISILICON_ERRATUM_162100801 |
+----------------+-----------------+-----------------+-----------------------------+
| Hisilicon | Hip09 | #162100125 | HISILICON_ERRATUM_162100125 |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
+----------------+-----------------+-----------------+-----------------------------+
@@ -323,3 +372,5 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| Microsoft | Azure Cobalt 100| #3324339 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| Microsoft | Azure Cobalt 100| #4193789 | ARM64_ERRATUM_4118414 |
+----------------+-----------------+-----------------+-----------------------------+

35
Documentation/arch/loongarch/irq-chip-model.rst
View File

@@ -181,6 +181,41 @@ go to PCH-PIC/PCH-LPC and gathered by EIOINTC, and then go to CPUINTC directly::
| Devices |
+---------+
Advanced Extended IRQ model (with redirection)
==============================================
In this model, IPI (Inter-Processor Interrupt) and CPU Local Timer interrupt go
to CPUINTC directly, CPU UARTS interrupts go to LIOINTC, PCH-MSI interrupts go
to REDIRECT for remapping it to AVECINTC, and then go to CPUINTC directly, while
all other devices interrupts go to PCH-PIC/PCH-LPC and gathered by EIOINTC, and
then go to CPUINTC directly::
+-----+ +-----------------------+ +-------+
| IPI | --> | CPUINTC | <-- | Timer |
+-----+ +-----------------------+ +-------+
^ ^ ^
| | |
| +----------+ |
+---------+ | AVECINTC | +---------+ +-------+
| EIOINTC | +----------+ | LIOINTC | <-- | UARTs |
+---------+ | REDIRECT | +---------+ +-------+
^ +----------+
| ^
| |
+---------+ +---------+
| PCH-PIC | | PCH-MSI |
+---------+ +---------+
^ ^ ^
| | |
+---------+ +---------+ +---------+
| Devices | | PCH-LPC | | Devices |
+---------+ +---------+ +---------+
^
|
+---------+
| Devices |
+---------+
ACPI-related definitions
========================

24
Documentation/arch/m68k/kernel-options.rst
View File

@@ -244,23 +244,7 @@ drive (with "root=").
3) General Device Options (Amiga and Atari)
===========================================
3.1) ether=
-----------
:Syntax: ether=[<irq>[,<base_addr>[,<mem_start>[,<mem_end>]]]],<dev-name>
<dev-name> is the name of a net driver, as specified in
drivers/net/Space.c in the Linux source. Most prominent are eth0, ...
eth3, sl0, ... sl3, ppp0, ..., ppp3, dummy, and lo.
The non-ethernet drivers (sl, ppp, dummy, lo) obviously ignore the
settings by this options. Also, the existing ethernet drivers for
Linux/m68k (ariadne, a2065, hydra) don't use them because Zorro boards
are really Plug-'n-Play, so the "ether=" option is useless altogether
for Linux/m68k.
3.2) hd=
3.1) hd=
--------
:Syntax: hd=<cylinders>,<heads>,<sectors>
@@ -273,7 +257,7 @@ itself. It exists just for the case that this fails for one of your
disks.
3.3) max_scsi_luns=
3.2) max_scsi_luns=
-------------------
:Syntax: max_scsi_luns=<n>
@@ -284,7 +268,7 @@ be scanned. Valid values for <n> are between 1 and 8. Default is 8 if
configuration, else 1.
3.4) st=
3.3) st=
--------
:Syntax: st=<buffer_size>,[<write_thres>,[<max_buffers>]]
@@ -297,7 +281,7 @@ total number of buffers. <max_buffer> limits the total number of
buffers allocated for all tape devices.
3.5) dmasound=
3.4) dmasound=
--------------
:Syntax: dmasound=[<buffers>,<buffer-size>[,<catch-radius>]]

2
Documentation/arch/powerpc/vas-api.rst
View File

@@ -293,7 +293,7 @@ Simple example
//Format CRB request with compression or
//uncompression
// Refer tests for vas_copy/vas_paste
vas_copy((&crb, 0, 1);
vas_copy(&crb, 0, 1);
vas_paste(addr, 0, 1);
// Poll on csb.flags with timeout
// csb address is listed in CRB

30
Documentation/arch/s390/s390dbf.rst
View File

@@ -106,6 +106,36 @@ the ``debug_stoppable`` sysctl. If you set ``debug_stoppable`` to 0 the debug
feature cannot be stopped. If the debug feature is already stopped, it
will stay deactivated.
Kernel parameters
-----------------
The size and log levels of debug logs can be configured early during boot using
the ``s390dbf`` kernel parameter. The parameter accepts a debug log name, a log
level, and a log size, separated by colon characters (``:``). To configure only
a single attribute, either the log level or the log size may be omitted.
To configure multiple debug logs, the parameter may be specified multiple times,
or multiple parameter sets may be provided in a single instance, separated by
commas.
Parameter format::
s390dbf=<name|pattern>:[<level>|-]:[<pages>][,...]
where:
- ``name`` specifies either an exact debug log name or a shell-style wildcard
pattern
- ``level`` specifies the log level, or ``-`` to completely deactivate the log
- ``pages`` specifies the debug area size in pages
Example::
s390dbf=cio*:6:128,sclp_err::2
This example sets the log level to 6 and the log size to 128 pages for all debug
logs whose names start with ``cio``. It also sets the log level of the
``sclp_err`` debug log to 2.
Kernel Interfaces:
------------------

18
Documentation/arch/sparc/oradax/dax-hv-api.txt
View File

@@ -457,7 +457,7 @@ bits set, and terminate at a CCB that has the Conditional bit set, but not the P
Offset Size Field Description
Bits Field Description
[15:14] Secondary Input Element Size (see Section 36.2.1.1.4,
“Secondary Input Element Size”
“Secondary Input Element Size”)
[13:10] Output Format (see Section 36.2.1.1.6, “Output Format”)
[9] Padding Direction selector: A value of 1 causes padding bytes
to be added to the left side of output elements. A value of 0
@@ -656,7 +656,7 @@ Offset Size Field Description
[18:16] Secondary Input Starting Offset (see Section 36.2.1.1.5, “Input
Element Offsets”)
[15:14] Secondary Input Element Size (see Section 36.2.1.1.4,
“Secondary Input Element Size”
“Secondary Input Element Size”)
[13:10] Output Format (see Section 36.2.1.1.6, “Output Format”)
[9:5] Operand size for first scan criteria value. In a scan value
operation, this is one of two potential exact match values.
@@ -793,13 +793,13 @@ Offset Size Field Description
[18:16] Secondary Input Starting Offset (see Section 36.2.1.1.5, “Input
Element Offsets”)
[15:14] Secondary Input Element Size (see Section 36.2.1.1.4,
“Secondary Input Element Size”
“Secondary Input Element Size”)
[13:10] Output Format (see Section 36.2.1.1.6, “Output Format”)
[9] Reserved
[8:0] Test value used for comparison against the most significant bits
in the input values, when using 2 or 3 byte input elements.
8 8 Completion (same fields as Section 36.2.1.2, “Extract command”
16 8 Primary Input (same fields as Section 36.2.1.2, “Extract command”
8 8 Completion (same fields as Section 36.2.1.2, “Extract command”)
16 8 Primary Input (same fields as Section 36.2.1.2, “Extract command”)
24 8 Data Access Control (same fields as Section 36.2.1.2, “Extract command”,
except Primary Input Length Format may not use the 0x0 value)
32 8 Secondary Input, if used by Primary Input Format. Same fields as Primary
@@ -880,7 +880,7 @@ Offset Size Field Description
[18:16] Secondary Input Starting Offset (see Section 36.2.1.1.5, “Input
Element Offsets”)
[15:14] Secondary Input Element Size (see Section 36.2.1.1.4,
“Secondary Input Element Size”
“Secondary Input Element Size”)
524
@@ -895,8 +895,8 @@ Offset Size Field Description
causes padding bytes to be added to the right side of output
elements.
[8:0] Reserved
8 8 Completion (same fields as Section 36.2.1.2, “Extract command”
16 8 Primary Input (same fields as Section 36.2.1.2, “Extract command”
8 8 Completion (same fields as Section 36.2.1.2, “Extract command”)
16 8 Primary Input (same fields as Section 36.2.1.2, “Extract command”)
24 8 Data Access Control (same fields as Section 36.2.1.2, “Extract command”)
32 8 Secondary Bit Vector Input. Same fields as Primary Input.
40 8 Reserved
@@ -949,7 +949,7 @@ Offset Size Field Description
[31] If set, this CCB functions as a Sync command. If clear, this
CCB functions as a No-op command.
[30:0] Reserved
8 8 Completion (same fields as Section 36.2.1.2, “Extract command”
8 8 Completion (same fields as Section 36.2.1.2, “Extract command”)
16 46 Reserved
36.2.2. CCB Completion Area

2
Documentation/arch/sparc/oradax/oracle-dax.rst
View File

@@ -438,7 +438,7 @@ that in user land::
The output bitmap is ready for consumption immediately after the
completion status indicates success.
Excer[t from UltraSPARC Virtual Machine Specification
Excerpt from UltraSPARC Virtual Machine Specification
=====================================================
.. include:: dax-hv-api.txt

4
Documentation/arch/x86/cpuinfo.rst
View File

@@ -187,6 +187,10 @@ to disable features using the feature number as defined in
Protection can be disabled using clearcpuid=514. The number 514 is calculated
from #define X86_FEATURE_UMIP (16*32 + 2).
DO NOT USE this cmdline option in production - it is meant to be used only as
a quick'n'dirty debugging aid to rule out a feature-enabling code is the
culprit. If you use it, it'll taint the kernel.
In addition, there exists a variety of custom command-line parameters that
disable specific features. The list of parameters includes, but is not limited
to, nofsgsbase, nosgx, noxsave, etc. 5-level paging can also be disabled using

134
Documentation/arch/x86/tdx.rst
View File

@@ -73,6 +73,133 @@ initialize::
[..] virt/tdx: TDX-Module initialization failed ...
TDX module Runtime Update
-------------------------
Similar to microcode, the BIOS generally has a copy of the TDX module
in flash. It loads this module image in to RAM at boot. However, just
like microcode, the BIOS-loaded TDX module might be out of date either
because the BIOS is old or the system has been up a long time. The
kernel can replace the BIOS version in RAM and load a different TDX
module. Kernel-loaded TDX modules do not affect the BIOS flash and do
not survive reboots.
The TDX module is normally the only piece of software running in SEAM
mode with which the kernel interacts. But there is a second piece of
software which is used to load or update the TDX module: a persistent
SEAM loader (P-SEAMLDR). It runs in SEAM mode separately from the TDX
module. The kernel communicates with the P-SEAMLDR to perform TDX
module runtime updates.
How to update the TDX module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Updating the TDX module is a complex process. Much of the logic and
policy is left to userspace. End users should use existing update
infrastructure provided by their distro. The Intel TDX Module Binaries
repository has a reference implementation of this logic:
https://github.com/intel/confidential-computing.tdx.tdx-module.binaries/blob/main/version_select_and_load.py
This section will now lay out roughly what is needed to implement a
userspace-driven TDX module update. Detailed documentation on the
tdx_host ABIs is available here::
Documentation/ABI/testing/sysfs-devices-faux-tdx-host
and is not duplicated in this document.
1. Check whether runtime update is supported at all
Verify that the TDX module firmware upload interface is available::
/sys/class/firmware/tdx_module
Note that this is the generic kernel firmware update ABI. It is
separate from the "tdx_host" device ABI itself.
2. Check whether additional updates are possible. Verify that::
/sys/devices/faux/tdx_host/num_remaining_updates
has a value greater than 0. If it is 0, the TDX update log might be
full. Reboot to reset this to a nonzero value.
3. Choose a compatible TDX module image
Choosing a compatible TDX module image is not trivial. There are both
hard compatibility requirements and policy choices to make.
Hard compatibility requirements:
- The update must be compatible with the kernel.
The update must not change any TDX ABIs in any non-backward-compatible
way. It can introduce new features but must not require that the kernel
use new ABIs for existing features. It must ensure that the rest of the
system is not affected in any way. Software on the system must never
notice any behavioral changes. Attestation results should be identical
except for version changes.
- The update must be compatible with the CPU.
The set of supported CPU FMS values (family, model, stepping) is
encoded in the module image itself. In practice, module version series
are platform-specific. For example, the 1.5.x series runs on Sapphire
Rapids but not Granite Rapids, which needs 2.0.x.
- The update must be compatible with the P-SEAMLDR.
This information is provided in a metadata file, typically
mapping_file.json, released with the module image. Each module image
specifies the minimum required P-SEAMLDR version, and the update is
compatible only if the running P-SEAMLDR meets that requirement.
The current version of the P-SEAMLDR can be read here::
/sys/devices/faux/tdx_host/seamldr_version
- The update must be compatible with the running TDX module.
Like P-SEAMLDR, each module image also specifies a minimum required
TDX module version. The running module must satisfy that requirement.
The update software can read the current TDX module version here::
/sys/devices/faux/tdx_host/version
Policy choices:
- The update software chooses how to optimize its update. For instance,
it can optimize for fewer updates or for smaller version steps,
for example, 1.2.3 => 1.2.5 versus 1.2.3 => 1.2.4 => 1.2.5.
4. Perform the update
Run::
echo 1 > /sys/class/firmware/tdx_module/loading
cat <path_to_module_image> > /sys/class/firmware/tdx_module/data
echo 0 > /sys/class/firmware/tdx_module/loading
The files /sys/class/firmware/tdx_module/status and
/sys/class/firmware/tdx_module/error report update progress and error
information.
After the update completes, the new module version is visible in
/sys/devices/faux/tdx_host/version.
Impact on running TDs
~~~~~~~~~~~~~~~~~~~~~
TDX module runtime updates must have virtually no visible impact on running
TDs. Any TD visible impact is a TDX module bug.
The main exception is the TEE_TCB_SVN_2 field in TD quotes, which
reflects the TCB of the currently running TDX module and therefore
changes after an update. By contrast, TEE_TCB_SVN reflects the TCB at TD
launch time and is not affected.
TDX Interaction to Other Kernel Components
------------------------------------------
@@ -138,13 +265,6 @@ If the platform has such erratum, the kernel prints additional message in
machine check handler to tell user the machine check may be caused by
kernel bug on TDX private memory.
Kexec
~~~~~~~
Currently kexec doesn't work on the TDX platforms with the aforementioned
erratum. It fails when loading the kexec kernel image. Otherwise it
works normally.
Interaction vs S3 and deeper states
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

4
Documentation/arch/x86/x86_64/fsgs.rst
View File

@@ -182,8 +182,8 @@ address spaces via an attribute based mechanism in Clang 2.6 and newer
versions:
==================================== =====================================
__attribute__((address_space(256)) Variable is addressed relative to GS
__attribute__((address_space(257)) Variable is addressed relative to FS
__attribute__(address_space(256)) Variable is addressed relative to GS
__attribute__(address_space(257)) Variable is addressed relative to FS
==================================== =====================================
FS/GS based addressing with inline assembly

2
Documentation/block/data-integrity.rst
View File

@@ -154,7 +154,7 @@ bio_free() will automatically free the bip.
----------------
Block devices can set up the integrity information in the integrity
sub-struture of the queue_limits structure.
sub-structure of the queue_limits structure.
Layered block devices will need to pick a profile that's appropriate
for all subdevices. queue_limits_stack_integrity() can help with that. DM

59
Documentation/block/error-injection.rst Normal file
View File

@@ -0,0 +1,59 @@
.. SPDX-License-Identifier: GPL-2.0
============================
Configurable Error Injection
============================
Overview
--------
Configurable error injection allows injecting specific block layer status codes
for sector ranges of a block device. Errors can be injected unconditionally, or
with a given probability.
To use configurable error injection, CONFIG_BLK_ERROR_INJECTION must be enabled.
The only interface is the error_injection debugfs file, which is created for
each registered gendisk. Writes to this file are used to create or delete rules
and reads return a list of the current error injection sites.
Options
-------
The following options specify the operations:
=================== =======================================================
add add a new rule
removeall remove all existing rules
=================== =======================================================
The following options specify the details of the rule for the add operation:
=================== =======================================================
op=<string> block layer operation this rule applies to. This uses
the XYZ for each REQ_OP_XYZ operation, e.g. READ, WRITE
or DISCARD. Mandatory.
status=<string> Status to return. This uses XYZ for each BLK_STS_XYZ
code, e.g. IOERR or MEDIUM. Mandatory.
start=<number> First block layer sector the rule applies to.
Optional, defaults to 0.
nr_sectors=<number> Number of sectors this rule applies.
Optional, defaults to the remainder of the device.
chance=<number> Only return a failure with a likelihood of 1/chance.
Optional, defaults to 1 (always).
=================== =======================================================
Example
-------
Return BLK_STS_IOERR for one in 10 reads of sector 0 of /dev/nvme0n1:
$ echo 'add,op=READ,start=0,status=IOERR,chance=10' > /sys/kernel/debug/block/nvme0n1/error_injection
Return BLK_STS_MEDIUM for every write to /dev/nvme0n1:
$ echo 'add,op=WRITE,start=0,status=MEDIUM' > /sys/kernel/debug/block/nvme0n1/error_injection
Remove all rules for /dev/nvme0n1:
$ echo 'removeall' > /sys/kernel/debug/block/nvme0n1/error_injection

1
Documentation/block/index.rst
View File

@@ -22,3 +22,4 @@ Block
switching-sched
writeback_cache_control
ublk
error-injection

6
Documentation/bpf/btf.rst
View File

@@ -97,10 +97,8 @@ Each type contains the following common data::
struct btf_type {
__u32 name_off;
/* "info" bits arrangement
* bits 0-15: vlen (e.g. # of struct's members)
* bits 16-23: unused
* bits 24-28: kind (e.g. int, ptr, array...etc)
* bits 29-30: unused
* bits 0-23: vlen (e.g. # of struct's members)
* bits 24-30: kind (e.g. int, ptr, array...etc)
* bit 31: kind_flag, currently used by
* struct, union, enum, fwd, enum64,
* decl_tag and type_tag

36
Documentation/bpf/kfuncs.rst
View File

@@ -207,8 +207,26 @@ Here, the buffer may be NULL. If the buffer is not NULL, it must be at least
buffer__szk bytes in size. The kfunc is responsible for checking if the buffer
is NULL before using it.
2.3.5 __str Annotation
----------------------------
2.3.5 __nonown_allowed Annotation
---------------------------------
This annotation is used to indicate that the parameter may be a non-owning reference.
An example is given below::
__bpf_kfunc int bpf_list_add(..., struct bpf_list_node
*prev__nonown_allowed, ...)
{
...
}
For the ``prev__nonown_allowed`` parameter (resolved as ``KF_ARG_PTR_TO_LIST_NODE``),
suffix ``__nonown_allowed`` retains the usual owning-pointer rules and also
permits a non-owning reference with no ref_obj_id (e.g. the return value of
bpf_list_front() / bpf_list_back()).
2.3.6 __str Annotation
----------------------
This annotation is used to indicate that the argument is a constant string.
An example is given below::
@@ -462,6 +480,20 @@ In order to accommodate such requirements, the verifier will enforce strict
PTR_TO_BTF_ID type matching if two types have the exact same name, with one
being suffixed with ``___init``.
2.8 Accessing arena memory through kfunc arguments
--------------------------------------------------
A read or write at any address inside an arena does not oops the kernel.
Unallocated arena pages are lazily backed by a scratch page and the
access is reported through the program's BPF stream as an error. Only
the BPF program's correctness is affected; the kernel itself remains
intact.
The arena is followed by a ``GUARD_SZ / 2`` (32 KiB) guard region that
is also covered by this recovery. A kfunc handed an arena pointer may
therefore access up to ``GUARD_SZ / 2`` past it without bounds-checking
against the arena. Larger accesses must verify the range explicitly.
.. _BPF_kfunc_lifecycle_expectations:
3. kfunc lifecycle expectations

44
Documentation/bpf/map_lru_hash_update.dot
View File

@@ -21,10 +21,18 @@ digraph {
// names that initiate the corresponding logic in kernel/bpf/bpf_lru_list.c.
// Number suffixes and errno suffixes handle subsections of the corresponding
// logic in the function as of the writing of this dot.
//
// All LRU locks are rqspinlock_t. Every acquire can fail (AA self-deadlock
// or contention timeout); on failure the corresponding helper returns NULL
// and the caller propagates -ENOMEM. The "rqspinlock acquire failed"
// terminal below is reached via the dashed arrows from each acquire site.
rqspinlock_failed [shape=rectangle,
label="Any LRU rqspinlock\nacquire fails\n(AA or timeout)"]
// cf. __local_list_pop_free() / bpf_percpu_lru_pop_free()
local_freelist_check [shape=diamond,fillcolor=1,
label="Local freelist\nnode available?"];
label="Local freelist\nnode available?\n(lockless free_llist)"];
use_local_node [shape=rectangle,
label="Use node owned\nby this CPU"]
@@ -82,6 +90,15 @@ digraph {
// fn__local_list_pop_pending()
}
// Post-steal: re-acquire local loc_l->lock to insert the stolen node into
// the local pending list. If the acquire fails, the stolen node is published
// to the lockless local free_llist so the next pop on this CPU picks it up
// instead of orphaning it.
post_steal_lock [shape=diamond,fillcolor=1,
label="Acquire local\nloc_l->lock\nto add pending"]
post_steal_to_free_llist [shape=rectangle,
label="Publish stolen node to\nlocal free_llist (lockless)"]
fn_bpf_lru_list_pop_free_to_local2 [shape=rectangle,
label="Use node that was\nnot recently referenced"]
local_freelist_check4 [shape=rectangle,
@@ -97,10 +114,19 @@ digraph {
fn_htab_lru_map_update_elem_ENOENT [shape=oval,label="return -ENOENT"]
begin -> local_freelist_check
// The initial per-CPU lock (loc_l->lock for common, l->lock for percpu) is
// acquired before the local freelist check; rqspinlock failure here exits
// directly to -ENOMEM (no recovery needed: nothing was removed yet).
local_freelist_check -> rqspinlock_failed [style=dashed,
xlabel="acquire fails"]
local_freelist_check -> use_local_node [xlabel="Y"]
local_freelist_check -> common_lru_check [xlabel="N"]
common_lru_check -> fn_bpf_lru_list_pop_free_to_local [xlabel="Y"]
common_lru_check -> fn___bpf_lru_list_shrink_inactive [xlabel="N"]
// Global lru_list lock acquire failure in pop_free_to_local: skip refill,
// fall through to the steal path. Not ENOMEM by itself.
fn_bpf_lru_list_pop_free_to_local -> common_lru_check2 [style=dashed,
xlabel="global lru_lock\nacquire fails"]
fn_bpf_lru_list_pop_free_to_local -> fn___bpf_lru_node_move_to_free
fn___bpf_lru_node_move_to_free ->
fn_bpf_lru_list_pop_free_to_local2 [xlabel="Y"]
@@ -120,13 +146,27 @@ digraph {
local_freelist_check6 -> local_freelist_check7
local_freelist_check7 -> fn_htab_lru_map_update_elem
fn_htab_lru_map_update_elem -> fn_htab_lru_map_update_elem3 [xlabel = "Y"]
// Steal-loop victim lock failure is silent: treat as "no node found here"
// and continue to next CPU; same edge as the existing "N" path.
local_freelist_check5 -> fn_htab_lru_map_update_elem2 [style=dashed,
xlabel="victim's lock\nfails: skip"]
// After a successful steal, re-acquire the local loc_l->lock. On failure
// the stolen node is published to free_llist (recovered, not orphaned)
// and the update returns -ENOMEM.
fn_htab_lru_map_update_elem -> post_steal_lock [xlabel = "Y"]
post_steal_lock -> fn_htab_lru_map_update_elem3 [xlabel = "OK"]
post_steal_lock -> post_steal_to_free_llist [style=dashed,
xlabel="loc_l->lock\nacquire fails"]
post_steal_to_free_llist -> fn_htab_lru_map_update_elem_ENOMEM
fn_htab_lru_map_update_elem -> fn_htab_lru_map_update_elem2 [xlabel = "N"]
fn_htab_lru_map_update_elem2 ->
fn_htab_lru_map_update_elem_ENOMEM [xlabel = "Y"]
fn_htab_lru_map_update_elem2 -> local_freelist_check5 [xlabel = "N"]
fn_htab_lru_map_update_elem3 -> fn_htab_lru_map_update_elem4
// Shared rqspinlock-failure terminal collapses to the same -ENOMEM exit.
rqspinlock_failed -> fn_htab_lru_map_update_elem_ENOMEM
use_local_node -> fn_htab_lru_map_update_elem4
fn_bpf_lru_list_pop_free_to_local2 -> fn_htab_lru_map_update_elem4
local_freelist_check4 -> fn_htab_lru_map_update_elem4

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

@@ -45,11 +45,6 @@ Command Line Switches
This option is limited to the X86 and S390 architecture.
``cpu0_hotplug``
Allow to shutdown CPU0.
This option is limited to the X86 architecture.
CPU maps
========

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

@@ -99,7 +99,7 @@ the same RCU read side critical section.
A typical layout example would look like this on the update side
(``housekeeping_update()``)::
rcu_assign_pointer(housekeeping_cpumasks[type], trial);
rcu_assign_pointer(housekeeping.cpumasks[type], trial);
synchronize_rcu();
flush_workqueue(example_workqueue);

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

@@ -307,6 +307,7 @@ Accounting Framework
Block Devices
=============
.. kernel-doc:: include/linux/bvec.h
.. kernel-doc:: include/linux/bio.h
.. kernel-doc:: block/blk-core.c
:export:

5
Documentation/core-api/kho/abi.rst
View File

@@ -28,6 +28,11 @@ KHO persistent memory tracker ABI
.. kernel-doc:: include/linux/kho/abi/kexec_handover.h
:doc: KHO persistent memory tracker
KHO serialization block ABI
===========================
.. kernel-doc:: include/linux/kho/abi/block.h
See Also
========

11
Documentation/core-api/kho/index.rst
View File

@@ -83,6 +83,17 @@ Public API
.. kernel-doc:: kernel/liveupdate/kexec_handover.c
:export:
KHO Serialization Blocks API
============================
.. kernel-doc:: kernel/liveupdate/kho_block.c
:doc: KHO Serialization Blocks
.. kernel-doc:: include/linux/kho_block.h
.. kernel-doc:: kernel/liveupdate/kho_block.c
:internal:
See Also
========

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

@@ -40,7 +40,7 @@ kref_init as so::
struct my_data *data;
data = kmalloc(sizeof(*data), GFP_KERNEL);
data = kmalloc_obj(*data);
if (!data)
return -ENOMEM;
kref_init(&data->refcount);
@@ -100,7 +100,7 @@ thread to process::
int rv = 0;
struct my_data *data;
struct task_struct *task;
data = kmalloc(sizeof(*data), GFP_KERNEL);
data = kmalloc_obj(*data);
if (!data)
return -ENOMEM;
kref_init(&data->refcount);

6
Documentation/core-api/list.rst
View File

@@ -112,7 +112,7 @@ list:
/* State 1 */
grock = kzalloc(sizeof(*grock), GFP_KERNEL);
grock = kzalloc_obj(*grock);
if (!grock)
return -ENOMEM;
grock->name = "Grock";
@@ -123,7 +123,7 @@ list:
/* State 2 */
dimitri = kzalloc(sizeof(*dimitri), GFP_KERNEL);
dimitri = kzalloc_obj(*dimitri);
if (!dimitri)
return -ENOMEM;
dimitri->name = "Dimitri";
@@ -752,7 +752,7 @@ This is because list_splice() did not reinitialize the list_head it took
entries from, leaving its pointer pointing into what is now a different list.
If we want to avoid this situation, list_splice_init() can be used. It does the
same thing as list_splice(), except reinitalizes the donor list_head after the
same thing as list_splice(), except reinitializes the donor list_head after the
transplant.
Concurrency considerations

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

@@ -322,6 +322,7 @@ MAC/FDDI addresses
%pMF 00-01-02-03-04-05
%pm 000102030405
%pmR 050403020100
%p[mM][FR][U]
For printing 6-byte MAC/FDDI addresses in hex notation. The ``M`` and ``m``
specifiers result in a printed address with (M) or without (m) byte
@@ -335,6 +336,8 @@ For Bluetooth addresses the ``R`` specifier shall be used after the ``M``
specifier to use reversed byte order suitable for visual interpretation
of Bluetooth addresses which are in the little endian order.
When ``U`` is passed, the result is printed in the upper case.
Passed by reference.
IPv4 addresses

2
Documentation/core-api/real-time/theory.rst
View File

@@ -25,7 +25,7 @@ Scheduling
==========
The core principles of Linux scheduling and the associated user-space API are
documented in the man page sched(7)
documented in the man page
`sched(7) <https://man7.org/linux/man-pages/man7/sched.7.html>`_.
By default, the Linux kernel uses the SCHED_OTHER scheduling policy. Under
this policy, a task is preempted when the scheduler determines that it has

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

@@ -114,8 +114,13 @@ Then, the driver must fill in the following values:
|policy->cur | The current operating frequency of |
| | this CPU (if appropriate) |
+-----------------------------------+--------------------------------------+
|policy->min, | |
|policy->max, | |
|policy->min, | The min/max scaling frequency. |
|policy->max | If set by the driver in ->init(), |
| | used as the lower/upper bound for |
| | policy frequency QoS requests; |
| | otherwise, reflects the min/max |
| | frequency the driver can set |
+-----------------------------------+--------------------------------------+
|policy->policy and, if necessary, | |
|policy->governor | must contain the "default policy" for|
| | this CPU. A few moments later, |

2
Documentation/crypto/api-samples.rst
View File

@@ -159,7 +159,7 @@ Code Example For Random Number Generator Usage
static int get_random_numbers(u8 *buf, unsigned int len)
{
struct crypto_rng *rng = NULL;
char *drbg = "drbg_nopr_sha256"; /* Hash DRBG with SHA-256, no PR */
char *drbg = "stdrng";
int ret;
if (!buf || !len) {

4
Documentation/crypto/async-tx-api.rst
View File

@@ -82,9 +82,9 @@ xor_val xor a series of source buffers and set a flag if the
pq generate the p+q (raid6 syndrome) from a series of source buffers
pq_val validate that a p and or q buffer are in sync with a given series of
sources
datap (raid6_datap_recov) recover a raid6 data block and the p block
datap (raid6_recov_datap) recover a raid6 data block and the p block
from the given sources
2data (raid6_2data_recov) recover 2 raid6 data blocks from the given
2data (raid6_recov_2data) recover 2 raid6 data blocks from the given
sources
======== ====================================================================

127
Documentation/crypto/userspace-if.rst
View File

@@ -4,26 +4,88 @@ User Space Interface
Introduction
------------
The concepts of the kernel crypto API visible to kernel space is fully
applicable to the user space interface as well. Therefore, the kernel
crypto API high level discussion for the in-kernel use cases applies
here as well.
AF_ALG provides unprivileged userspace programs access to arbitrary hash,
symmetric cipher, AEAD, and RNG algorithms that are implemented in kernel-mode
code.
The major difference, however, is that user space can only act as a
consumer and never as a provider of a transformation or cipher
algorithm.
AF_ALG is insecure and is deprecated. Originally added to the kernel in 2010,
most kernel developers now consider it to be a mistake. Support for hardware
accelerators, which was the original purpose of AF_ALG, has been removed.
The following covers the user space interface exported by the kernel
crypto API. A working example of this description is libkcapi that can
be obtained from [1]. That library can be used by user space
applications that require cryptographic services from the kernel.
AF_ALG continues to be supported only for backwards compatibility. On systems
where no programs using AF_ALG remain, the support for it should be disabled by
disabling ``CONFIG_CRYPTO_USER_API_*``.
Some details of the in-kernel kernel crypto API aspects do not apply to
user space, however. This includes the difference between synchronous
and asynchronous invocations. The user space API call is fully
synchronous.
Deprecation
-----------
[1] https://www.chronox.de/libkcapi/index.html
AF_ALG was originally intended to provide userspace programs access to crypto
accelerators that they wouldn't otherwise have access to.
However, that capability turned out to not be useful on very many systems. More
significantly, the actual implementation exposes a vastly greater amount of
functionality than that. It actually provides access to all software algorithms.
This includes arbitrary compositions of different algorithms created via a
complex template system, as well as algorithms that only make sense as internal
implementation details of other algorithms. In the past, it also included full
zero-copy support, which was difficult for the kernel to implement securely.
Ultimately, these algorithms are just math computations. They use the same
instructions that userspace programs already have access to, just accessed in a
much more convoluted and less efficient way.
Indeed, userspace code is nearly always what is being used anyway. These same
algorithms are widely implemented in userspace crypto libraries.
Even when zero-copy and off-CPU accelerators were supported, AF_ALG was usually
much slower than optimized software cryptography in userspace. This was
especially true for the small message sizes usually seen in performance-critical
workloads. While it was possible to demonstrate performance wins for hashing
large files on embedded devices, it is hard to imagine a situation where this
would be performance-critical.
Nowadays, AF_ALG no longer supports zero-copy or off-CPU accelerators.
Therefore, it is *always* slower than an optimized userspace implementation,
even for large messages. The only possible advantage left is that it avoids
duplicating code between kernel and userspace. However, userspace
implementations, especially hardware-accelerated ones, do not need to be large.
Just because OpenSSL is huge does not mean that all userspace cryptography
libraries are.
Meanwhile, AF_ALG hasn't been withstanding modern vulnerability discovery tools
such as syzbot and large language models. It receives a steady stream of CVEs.
Some of the examples include:
- CVE-2026-31677
- CVE-2026-31431 (https://copy.fail)
- CVE-2025-38079
- CVE-2025-37808
- CVE-2024-26824
- CVE-2022-48781
- CVE-2019-8912
- CVE-2018-14619
- CVE-2017-18075
- CVE-2017-17806
- CVE-2017-17805
- CVE-2016-10147
- CVE-2015-8970
- CVE-2015-3331
- CVE-2014-9644
- CVE-2013-7421
- CVE-2011-4081
Hardware accelerator drivers are frequently buggy. To reduce attack surface,
AF_ALG now only provides access to algorithms implemented in software. This
means that AF_ALG no longer fulfills its original purpose.
It is recommended that, whenever possible, userspace programs be migrated to
userspace crypto code (which again, is what is normally used anyway) and
``CONFIG_CRYPTO_USER_API_*`` be disabled. On systems that use SELinux, SELinux
can also be used to restrict the use of AF_ALG to trusted programs.
The remainder of this documentation provides the historical documentation for
the deprecated AF_ALG interface.
User Space API General Remarks
------------------------------
@@ -297,7 +359,7 @@ follows:
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "rng", /* this selects the random number generator */
.salg_name = "drbg_nopr_sha256" /* this is the RNG name */
.salg_name = "stdrng" /* this is the RNG name */
};
@@ -327,33 +389,10 @@ CRYPTO_USER_API_RNG_CAVP option:
Zero-Copy Interface
-------------------
In addition to the send/write/read/recv system call family, the AF_ALG
interface can be accessed with the zero-copy interface of
splice/vmsplice. As the name indicates, the kernel tries to avoid a copy
operation into kernel space.
The zero-copy operation requires data to be aligned at the page
boundary. Non-aligned data can be used as well, but may require more
operations of the kernel which would defeat the speed gains obtained
from the zero-copy interface.
The system-inherent limit for the size of one zero-copy operation is 16
pages. If more data is to be sent to AF_ALG, user space must slice the
input into segments with a maximum size of 16 pages.
Zero-copy can be used with the following code example (a complete
working example is provided with libkcapi):
::
int pipes[2];
pipe(pipes);
/* input data in iov */
vmsplice(pipes[1], iov, iovlen, SPLICE_F_GIFT);
/* opfd is the file descriptor returned from accept() system call */
splice(pipes[0], NULL, opfd, NULL, ret, 0);
read(opfd, out, outlen);
AF_ALG used to have zero-copy support, but it was removed due to it being a
frequent source of vulnerabilities. For backwards compatibility the splice()
and sendfile() system calls are still supported, but the kernel will make an
internal copy of the data before passing it to the crypto code.
Setsockopt Interface

41
Documentation/dev-tools/autofdo.rst
View File

@@ -61,6 +61,9 @@ process consists of the following steps:
the AutoFDO profile via offline tools.
The support requires a Clang compiler LLVM 17 or later.
Current supported architectures include x86/x86_64 (via LBR) and
arm64 (via SPE or ETM).
Preparation
===========
@@ -141,6 +144,35 @@ Here is an example workflow for AutoFDO kernel:
$ perf record --pfm-events RETIRED_TAKEN_BRANCH_INSTRUCTIONS:k -a -N -b -c <count> -o <perf_file> -- <loadtest>
- For arm64 with SPE:
There are a few kernel features that must be enabled to collect SPE profiles on Arm.
Below is a list of the required features:
- CONFIG_ARM_SPE_PMU=y
- CONFIG_PID_IN_CONTEXTIDR=y
- kpti=off
Use the following command to generate SPE perf data file::
$ perf record -e ' arm_spe_0/branch_filter=1,load_filter=0,store_filter=0/' -a -c <count> -N --no-switch-events -o <perf_file> -- <loadtest>
- For arm64 with ETM trace:
Follow the instructions in `Linaro OpenCSD document
<https://github.com/Linaro/OpenCSD/blob/master/decoder/tests/auto-fdo/autofdo.md>`_
to record ETM traces for AutoFDO::
$ perf record -e cs_etm/@tmc_etr0/k -a -o <etm_perf_file> -- <loadtest>
$ perf inject -i <etm_perf_file> -o <perf_file> --itrace=i500009il
For ARM platforms running Android, follow the instructions in `Android simpleperf
document <https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/gki/aarch64/afdo>`_
to record ETM traces for AutoFDO::
$ simpleperf record -e cs-etm:k -a -o <etm_perf_file> -- <loadtest>
$ simpleperf inject -i <etm_perf_file> -o <text_perf_file> --symdir <vmlinux_dir>
4) (Optional) Download the raw perf file to the host machine.
5) To generate an AutoFDO profile, two offline tools are available:
@@ -162,6 +194,15 @@ Here is an example workflow for AutoFDO kernel:
$ llvm-profdata merge -o <profile_file> <profile_1> <profile_2> ... <profile_n>
For arm64 SPE, use the following command::
$ create_llvm_prof --binary=<vmlinux> --profile=<perf_file> --profiler=perf_spe --format=extbinary --out=<profile_file>
For arm64 ETM, use the following command::
$ create_llvm_prof --binary=<vmlinux> --profile=<text_perf_file> --profiler=text -format=extbinary -out=<profile_file>
6) Rebuild the kernel using the AutoFDO profile file with the same config as step 1,
(Note CONFIG_AUTOFDO_CLANG needs to be enabled)::

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