github-mirror/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux.git synced 2026-09-12 12:34:02 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity Graph

sched_ext: Merge branch 'for-7.3-arena-args' into for-7.3

Browse Source 
Pull to receive the __arena argument conversion:

 67f1f4a48c ("sched_ext: Pass kernel arena pointers to ops_cid callbacks")
 a8dc810968 ("sched_ext: Convert sub-cap kfuncs to __arena cmask arguments")
 a05c5b5cb5 ("sched_ext: Convert scx_bpf_cid_override() to __arena array arguments")

along with the bpf-next branch carrying the __arena argument support they
depend on.

Conflict in kernel/sched/ext/ext.c between:

 c384ab8a0b ("sched_ext: Move the config-off sub-cap kfunc stubs into sub.c")

and:

 a8dc810968 ("sched_ext: Convert sub-cap kfuncs to __arena cmask arguments")

which updated the stubs in their old ext.c location. Resolved by keeping
ext.c without the stubs and applying the prototype conversion to the
relocated stubs in sub.c.

Signed-off-by: Tejun Heo <tj@kernel.org>
This commit is contained in:
Tejun Heo 2026-08-17 11:20:34 -10:00
commit fab183d632
4906 changed files with 78173 additions and 26465 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
.mailmap
View File

@ -66,7 +66,13 @@ Alex Hung <alexhung@gmail.com> <alex.hung@canonical.com>
Alex Shi <alexs@kernel.org> <alex.shi@intel.com>
Alex Shi <alexs@kernel.org> <alex.shi@linaro.org>
Alex Shi <alexs@kernel.org> <alex.shi@linux.alibaba.com>
Alice Mikityanska <alice.kernel@fastmail.im> <maxtram95@gmail.com>
Alice Mikityanska <alice.kernel@fastmail.im> <maximmi@mellanox.com>
Alice Mikityanska <alice.kernel@fastmail.im> <maximmi@nvidia.com>
Alice Mikityanska <alice.kernel@fastmail.im> <maxim@isovalent.com>
Alice Mikityanska <alice.kernel@fastmail.im> <alice@isovalent.com>
Aloka Dixit <quic_alokad@quicinc.com> <alokad@codeaurora.org>
Alvin Šipraga <alvin.sipraga@analog.com> <alsi@bang-olufsen.dk>
Al Viro <viro@ftp.linux.org.uk>
Al Viro <viro@zenIV.linux.org.uk>
Amit Blay <quic_ablay@quicinc.com> <ablay@codeaurora.org>
@ -165,12 +171,14 @@ Boris Brezillon <bbrezillon@kernel.org> <b.brezillon@overkiz.com>
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@bootlin.com>
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@free-electrons.com>
Brendan Higgins <brendan.higgins@linux.dev> <brendanhiggins@google.com>
Brendan Jackman <brendan.jackman@linux.dev> <jackmanb@google.com>
Brian Avery <b.avery@hp.com>
Brian Cain <bcain@kernel.org> <brian.cain@oss.qualcomm.com>
Brian Cain <bcain@kernel.org> <bcain@quicinc.com>
Brian King <brking@us.ibm.com>
Brian Silverman <bsilver16384@gmail.com> <brian.silverman@bluerivertech.com>
Bryan Tan <bryan-bt.tan@broadcom.com> <bryantan@vmware.com>
Burak Emir <burak.emir@gmail.com> <bqe@google.com>
Cai Huoqing <cai.huoqing@linux.dev> <caihuoqing@baidu.com>
Casey Connolly <casey.connolly@linaro.org> <caleb.connolly@linaro.org>
Casey Connolly <casey.connolly@linaro.org> <caleb@connolly.tech>
@ -226,6 +234,8 @@ Daniel Lezcano <daniel.lezcano@kernel.org> <daniel.lezcano@linexp.org>
Daniel Lezcano <daniel.lezcano@kernel.org> <dlezcano@fr.ibm.com>
Daniel Thompson <danielt@kernel.org> <daniel.thompson@linaro.org>
Daniele Alessandrelli <daniele.alessandrelli@gmail.com> <daniele.alessandrelli@intel.com>
Danila Tikhonov <danila@mainlining.org> <danila@jiaxyga.com>
Danila Tikhonov <danila@mainlining.org> <JIaxyga@protonmail.com>
Danilo Krummrich <dakr@kernel.org> <dakr@redhat.com>
David Brownell <david-b@pacbell.net>
David Collins <quic_collinsd@quicinc.com> <collinsd@codeaurora.org>
@ -291,6 +301,7 @@ Frank Rowand <frowand.list@gmail.com> <frank.rowand@sony.com>
Frank Rowand <frowand.list@gmail.com> <frank.rowand@sonymobile.com>
Frank Rowand <frowand.list@gmail.com> <frowand@mvista.com>
Frank Zago <fzago@systemfabricworks.com>
Fuad Tabba <fuad.tabba@linux.dev> <tabba@google.com>
Gao Xiang <xiang@kernel.org> <gaoxiang25@huawei.com>
Gao Xiang <xiang@kernel.org> <hsiangkao@aol.com>
Gao Xiang <xiang@kernel.org> <hsiangkao@linux.alibaba.com>
@ -373,6 +384,7 @@ Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@opinsys.com>
Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com>
Jason Gunthorpe <jgg@ziepe.ca> <jgg@nvidia.com>
Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
Jason Wang <jasowangio@gmail.com> <jasowang@redhat.com>
Jason Xing <kerneljasonxing@gmail.com> <kernelxing@tencent.com>
<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
@ -398,6 +410,7 @@ Jens Axboe <axboe@kernel.dk> <jens.axboe@oracle.com>
Jens Axboe <axboe@kernel.dk> <axboe@fb.com>
Jens Axboe <axboe@kernel.dk> <axboe@meta.com>
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
Jens Wiklander <jenswi@kernel.org> <jens.wiklander@linaro.org>
Jernej Skrabec <jernej.skrabec@gmail.com> <jernej.skrabec@siol.net>
Jesper Dangaard Brouer <hawk@kernel.org> <brouer@redhat.com>
Jesper Dangaard Brouer <hawk@kernel.org> <hawk@comx.dk>
@ -530,13 +543,15 @@ 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>
Maciej W. Rozycki <macro@orcam.me.uk> <macro@linux-mips.org>
Maharaja Kennadyrajan <quic_mkenna@quicinc.com> <mkenna@codeaurora.org>
Maheshwar Ajja <quic_majja@quicinc.com> <majja@codeaurora.org>
Maíra Canal <mairacanal@riseup.net> <maira.canal@usp.br>
Malathi Gottam <quic_mgottam@quicinc.com> <mgottam@codeaurora.org>
Manikanta Pubbisetty <quic_mpubbise@quicinc.com> <mpubbise@codeaurora.org>
Manivannan Sadhasivam <mani@kernel.org> <manivannanece23@gmail.com>
@ -582,8 +597,6 @@ Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@osg.samsung.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@redhat.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <m.chehab@samsung.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@s-opensource.com>
Maxim Mikityanskiy <maxtram95@gmail.com> <maximmi@mellanox.com>
Maxim Mikityanskiy <maxtram95@gmail.com> <maximmi@nvidia.com>
Maxime Ripard <mripard@kernel.org> <maxime@cerno.tech>
Maxime Ripard <mripard@kernel.org> <maxime.ripard@bootlin.com>
Maxime Ripard <mripard@kernel.org> <maxime.ripard@free-electrons.com>
@ -592,8 +605,8 @@ Mayuresh Janorkar <mayur@ti.com>
Md Sadre Alam <quic_mdalam@quicinc.com> <mdalam@codeaurora.org>
Miaoqing Pan <quic_miaoqing@quicinc.com> <miaoqing@codeaurora.org>
Michael Buesch <m@bues.ch>
Michal Grzeschik <mgr@kernel.org> <m.grzeschik@pengutronix.de>
Michal Grzeschik <mgr@kernel.org> <mgr@pengutronix.de>
Michael Grzeschik <mgr@kernel.org> <m.grzeschik@pengutronix.de>
Michael Grzeschik <mgr@kernel.org> <mgr@pengutronix.de>
Michael Riesch <michael.riesch@collabora.com> <michael.riesch@wolfvision.net>
Michal Simek <michal.simek@amd.com> <michal.simek@xilinx.com>
Michel Dänzer <michel@tungstengraphics.com>
@ -640,8 +653,8 @@ Nicholas Piggin <npiggin@gmail.com> <npiggin@kernel.dk>
Nicholas Piggin <npiggin@gmail.com> <npiggin@suse.de>
Nicholas Piggin <npiggin@gmail.com> <nickpiggin@yahoo.com.au>
Nicholas Piggin <npiggin@gmail.com> <piggin@cyberone.com.au>
Nick Desaulniers <nick.desaulniers+lkml@gmail.com> <ndesaulniers@google.com>
Nicolas Ferre <nicolas.ferre@microchip.com> <nicolas.ferre@atmel.com>
Nico Pache <nico.pache@linux.dev> <npache@redhat.com>
Nicolas Pitre <nico@fluxnic.net> <nicolas.pitre@linaro.org>
Nicolas Pitre <nico@fluxnic.net> <nico@linaro.org>
Nicolas Saenz Julienne <nsaenz@kernel.org> <nsaenzjulienne@suse.de>
@ -689,6 +702,7 @@ Paulo Alcantara <pc@manguebit.org> <palcantara@suse.com>
Paulo Alcantara <pc@manguebit.org> <pc@manguebit.com>
Pavankumar Kondeti <quic_pkondeti@quicinc.com> <pkondeti@codeaurora.org>
Peter A Jonsson <pj@ludd.ltu.se>
Peter Collingbourne <peter@pcc.me.uk> <pcc@google.com>
Peter Hilber <peter.hilber@oss.qualcomm.com> <quic_philber@quicinc.com>
Peter Oruba <peter.oruba@amd.com>
Peter Oruba <peter@oruba.de>
@ -707,6 +721,10 @@ Qi Zheng <qi.zheng@linux.dev> <zhengqi.arch@bytedance.com>
Quentin Monnet <qmo@kernel.org> <quentin.monnet@netronome.com>
Quentin Monnet <qmo@kernel.org> <quentin@isovalent.com>
Quentin Perret <qperret@qperret.net> <quentin.perret@arm.com>
Radu Rendec <radu@rendec.net> <radu.rendec@ines.ro>
Radu Rendec <radu@rendec.net> <rrendec@arista.com>
Radu Rendec <radu@rendec.net> <radu.rendec@gmail.com>
Radu Rendec <radu@rendec.net> <rrendec@redhat.com>
Rae Moar <raemoar63@gmail.com> <rmoar@google.com>
Rafael J. Wysocki <rjw@rjwysocki.net> <rjw@sisk.pl>
Rajeev Nandan <quic_rajeevny@quicinc.com> <rajeevny@codeaurora.org>
@ -811,6 +829,7 @@ Simon Wunderlich <sw@simonwunderlich.de> <simon.wunderlich@s2003.tu-chemnitz.de>
Simon Wunderlich <sw@simonwunderlich.de> <simon.wunderlich@saxnet.de>
Simon Wunderlich <sw@simonwunderlich.de> <simon@open-mesh.com>
Simon Wunderlich <sw@simonwunderlich.de> <siwu@hrz.tu-chemnitz.de>
SJ Park <sj@kernel.org>
Sricharan Ramabadhran <quic_srichara@quicinc.com> <sricharan@codeaurora.org>
Srinivas Kandagatla <srini@kernel.org> <srinivas.kandagatla@st.com>
Srinivas Kandagatla <srini@kernel.org> <srinivas.kandagatla@linaro.org>
@ -820,8 +839,8 @@ Sriram Yagnaraman <sriram.yagnaraman@ericsson.com> <sriram.yagnaraman@est.tech>
Stanislav Fomichev <sdf@fomichev.me> <sdf@google.com>
Stanislav Fomichev <sdf@fomichev.me> <stfomichev@gmail.com>
Stefan Wahren <wahrenst@gmx.net> <stefan.wahren@i2se.com>
Stéphane Grosjean <stephane.grosjean@hms-networks.com> <s.grosjean@peak-system.com>
Stéphane Grosjean <stephane.grosjean@hms-networks.com> <stephane.grosjean@free.fr>
Stéphane Grosjean <s.grosjean@peak-system.fr> <s.grosjean@peak-system.com>
Stéphane Grosjean <s.grosjean@peak-system.fr> <stephane.grosjean@free.fr>
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
Stephen Hemminger <stephen@networkplumber.org> <shemminger@linux-foundation.org>
Stephen Hemminger <stephen@networkplumber.org> <shemminger@osdl.org>

7
CREDITS
View File

@ -3626,6 +3626,13 @@ S: 69 rue Dunois
S: 75013 Paris
S: France
N: Wolfram Sang
E: wsa@kernel.org
W: sang-engineering.com
P: rsa4096/140DE4CC14A029B6 3991 B1EA B9E2 6751 A4F7 645D 140D E4CC 14A0 29B6
D: I2C Maintainer 2012 - 2026
S: Berlin, Germany
N: Aleksa Sarai
E: cyphar@cyphar.com
W: https://www.cyphar.com/

26
Documentation/ABI/testing/debugfs-vfio
View File

@ -29,3 +29,29 @@ Date: Oct 2025
KernelVersion: 6.18
Contact: Cédric Le Goater <clg@redhat.com>
Description: Read the migration features of the vfio device.
What: /sys/kernel/debug/vfio/<device>/pci
Date: June 2026
KernelVersion: 7.2
Contact: Alex Williamson <alex.williamson@nvidia.com>
Description: This debugfs file directory is used for debugging
VFIO PCI devices.
What: /sys/kernel/debug/vfio/<device>/pci/nointxmask
Date: June 2026
KernelVersion: 7.2
Contact: Alex Williamson <alex.williamson@nvidia.com>
Description: Read the nointxmask policy latched for this device. This
policy governs whether the device may use PCI 2.3 style
INTx masking when supported, reporting a value of "N", or
requires APIC level INTx masking, reporting a value of "Y".
What: /sys/kernel/debug/vfio/<device>/pci/disable_idle_d3
Date: June 2026
KernelVersion: 7.2
Contact: Alex Williamson <alex.williamson@nvidia.com>
Description: Read the disable_idle_d3 policy latched for this device. This
policy governs whether the device PM runtime usage count is
kept elevated while the device is bound to the driver and
unused, reporting a value of "Y", or decremented to allow the
device to enter a low power state, reporting a value of "N".

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 or configured.
initialized, connected, configured or suspended.
What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_idVendor
Date: March 2023

1
Documentation/ABI/testing/sysfs-class-power-bd71828
View File

@ -10,3 +10,4 @@ Description:
0 no adjustment of input current limit. This
helps for more unusual power sources like
solar modules.
============ ===========================================

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

@ -1,26 +1,26 @@
what: /sys/kernel/mm/damon/
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Interface for Data Access MONitoring (DAMON). Contains files
for controlling DAMON. For more details on DAMON itself,
please refer to Documentation/admin-guide/mm/damon/index.rst.
What: /sys/kernel/mm/damon/admin/
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Interface for privileged users of DAMON. Contains files for
controlling DAMON that aimed to be used by privileged users.
What: /sys/kernel/mm/damon/admin/kdamonds/nr_kdamonds
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a number 'N' to this file creates the number of
directories for controlling each DAMON worker thread (kdamond)
named '0' to 'N-1' under the kdamonds/ directory.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/state
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing 'on' or 'off' to this file makes the kdamond starts or
stops, respectively. Reading the file returns the keywords
based on the current status. Writing 'commit' to this file
@ -40,33 +40,33 @@ Description: Writing 'on' or 'off' to this file makes the kdamond starts or
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/pid
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Reading this file returns the pid of the kdamond if it is
running.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/refresh_ms
Date: Jul 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a value to this file sets the time interval for
automatic DAMON status file contents update. Writing '0'
disables the update. Reading this file returns the value.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/nr_contexts
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a number 'N' to this file creates the number of
directories for controlling each DAMON context named '0' to
'N-1' under the contexts/ directory.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/avail_operations
Date: Apr 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Reading this file returns the available monitoring operations
sets on the currently running kernel.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/operations
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a keyword for a monitoring operations set ('vaddr' for
virtual address spaces monitoring, 'fvaddr' for fixed virtual
address ranges monitoring, and 'paddr' for the physical address
@ -79,42 +79,42 @@ Description: Writing a keyword for a monitoring operations set ('vaddr' for
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/addr_unit
Date: Aug 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
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>
Contact: SJ 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>
Contact: SJ Park <sj@kernel.org>
Description: Writing a value to this file sets the sampling interval of the
DAMON context in microseconds as the value. Reading this file
returns the value.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/aggr_us
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a value to this file sets the aggregation interval of
the DAMON context in microseconds as the value. Reading this
file returns the value.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/update_us
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a value to this file sets the update interval of the
DAMON context in microseconds as the value. Reading this file
returns the value.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/intrvals_goal/access_bp
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a value to this file sets the monitoring intervals
auto-tuning target DAMON-observed access events ratio within
the given time interval (aggrs in same directory), in bp
@ -122,7 +122,7 @@ Description: Writing a value to this file sets the monitoring intervals
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/intrvals_goal/aggrs
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a value to this file sets the time interval to achieve
the monitoring intervals auto-tuning target DAMON-observed
access events ratio (access_bp in same directory) within.
@ -130,14 +130,14 @@ Description: Writing a value to this file sets the time interval to achieve
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/intrvals_goal/min_sample_us
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a value to this file sets the minimum value of
auto-tuned sampling interval in microseconds. Reading this
file returns the value.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/intrvals_goal/max_sample_us
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a value to this file sets the maximum value of
auto-tuned sampling interval in microseconds. Reading this
file returns the value.
@ -145,42 +145,42 @@ Description: Writing a value to this file sets the maximum value of
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/nr_regions/min
WDate: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a value to this file sets the minimum number of
monitoring regions of the DAMON context as the value. Reading
this file returns the value.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/nr_regions/max
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a value to this file sets the maximum number of
monitoring regions of the DAMON context as the value. Reading
this file returns the value.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/targets/nr_targets
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a number 'N' to this file creates the number of
directories for controlling each DAMON target of the context
named '0' to 'N-1' under the contexts/ directory.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/targets/<T>/pid_target
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the pid of
the target process if the context is for virtual address spaces
monitoring, respectively.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/targets/<T>/obsolete_target
Date: Oct 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the
obsoleteness of the matching parameters commit destination
target.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/targets/<T>/regions/nr_regions
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a number 'N' to this file creates the number of
directories for setting each DAMON target memory region of the
context named '0' to 'N-1' under the regions/ directory. In
@ -190,181 +190,181 @@ Description: Writing a number 'N' to this file creates the number of
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/targets/<T>/regions/<R>/start
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the start
address of the monitoring region.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/targets/<T>/regions/<R>/end
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the end
address of the monitoring region.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/nr_schemes
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a number 'N' to this file creates the number of
directories for controlling each DAMON-based operation scheme
of the context named '0' to 'N-1' under the schemes/ directory.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/action
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the action
of the scheme.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/target_nid
Date: Jun 2024
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Action's target NUMA node id. Supported by only relevant
actions.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/apply_interval_us
Date: Sep 2023
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a value to this file sets the action apply interval of
the scheme in microseconds. Reading this file returns the
value.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/sz/min
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the minimum
size of the scheme's target regions in bytes.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/sz/max
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the maximum
size of the scheme's target regions in bytes.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/nr_accesses/min
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the manimum
'nr_accesses' of the scheme's target regions.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/nr_accesses/max
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the maximum
'nr_accesses' of the scheme's target regions.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/age/min
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the minimum
'age' of the scheme's target regions.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/age/max
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the maximum
'age' of the scheme's target regions.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/ms
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the time
quota of the scheme in milliseconds.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/bytes
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the size
quota of the scheme in bytes.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/effective_bytes
Date: Feb 2024
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Reading from this file gets the effective size quota of the
scheme in bytes, which adjusted for the time quota and goals.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/reset_interval_ms
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the quotas
charge reset interval of the scheme in milliseconds.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/goals/nr_goals
Date: Nov 2023
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a number 'N' to this file creates the number of
directories for setting automatic tuning of the scheme's
aggressiveness named '0' to 'N-1' under the goals/ directory.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/goals/<G>/target_metric
Date: Feb 2024
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the quota
auto-tuning goal metric.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/goals/<G>/target_value
Date: Nov 2023
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the target
value of the goal metric.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/goals/<G>/current_value
Date: Nov 2023
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the current
value of the goal metric.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/goals/<G>/nid
Date: Apr 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the nid
parameter of the goal.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/goals/<G>/path
Date: Oct 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the path
parameter of the goal.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/goal_tuner
Date: Mar 2026
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ 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>
Contact: SJ 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>
Contact: SJ 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>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the
under-quota limit regions prioritization weight for 'size' in
permil.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/weights/nr_accesses_permil
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the
under-quota limit regions prioritization weight for
'nr_accesses' in permil.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/weights/age_permil
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the
under-quota limit regions prioritization weight for 'age' in
permil.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/watermarks/metric
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the metric
of the watermarks for the scheme. The writable/readable
keywords for this file are 'none' for disabling the watermarks
@ -373,44 +373,44 @@ Description: Writing to and reading from this file sets and gets the metric
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/watermarks/interval_us
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the metric
check interval of the watermarks for the scheme in
microseconds.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/watermarks/high
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the high
watermark of the scheme in permil.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/watermarks/mid
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the mid
watermark of the scheme in permil.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/watermarks/low
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ 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>/core_filters
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ 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>
Contact: SJ 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 core_filters/ directory.
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>
Contact: SJ 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,
'memcg' for specific memory cgroup, 'young' for young pages,
@ -419,62 +419,62 @@ Description: Writing to and reading from this file sets and gets the type of
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>
Contact: SJ 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>/core_filters/<F>/addr_start
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ 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>/core_filters/<F>/addr_end
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ 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>/core_filters/<F>/min
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ 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>/core_filters/<F>/max
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ 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>/core_filters/<F>/damon_target_idx
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ 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>/core_filters/<F>/matching
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ 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>/core_filters/<F>/allow
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ 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>/ops_filters
Date: Feb 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ 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>/core_filters
@ -482,7 +482,7 @@ Description: Directory for DAMON operations set layer-handled DAMOS filters.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters
Date: Dec 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ 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
@ -491,14 +491,14 @@ Description: Directory for DAMOS filters. Files under this directory works
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/dests/nr_dests
Date: Jul 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a number 'N' to this file creates the number of
directories for setting action destinations of the scheme named
'0' to 'N-1' under the dests/ directory.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/dests/<D>/id
Date: Jul 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the id of
the DAMOS action destination. For DAMOS_MIGRATE_{HOT,COLD}
actions, the destination node's node id can be written and
@ -506,98 +506,98 @@ Description: Writing to and reading from this file sets and gets the id of
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/dests/<D>/weight
Date: Jul 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the weight
of the DAMOS action destination to select as the destination of
each action among the destinations.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/nr_tried
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Reading this file returns the number of regions that the action
of the scheme has tried to be applied.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/sz_tried
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Reading this file returns the total size of regions that the
action of the scheme has tried to be applied in bytes.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/nr_applied
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Reading this file returns the number of regions that the action
of the scheme has successfully applied.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/sz_applied
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Reading this file returns the total size of regions that the
action of the scheme has successfully applied in bytes.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/sz_ops_filter_passed
Date: Dec 2024
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Reading this file returns the total size of memory that passed
DAMON operations layer-handled filters of the scheme in bytes.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/qt_exceeds
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Reading this file returns the number of the exceed events of
the scheme's quotas.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/nr_snapshots
Date: Dec 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Reading this file returns the total number of DAMON snapshots
that the scheme has tried to be applied.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/max_nr_snapshots
Date: Dec 2025
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Writing a number to this file sets the upper limit of
nr_snapshots that deactivates the scheme when the limit is
reached or exceeded.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/tried_regions/total_bytes
Date: Jul 2023
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Reading this file returns the total amount of memory that
corresponding DAMON-based Operation Scheme's action has tried
to be applied.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/tried_regions/<R>/start
Date: Oct 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Reading this file returns the start address of a memory region
that corresponding DAMON-based Operation Scheme's action has
tried to be applied.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/tried_regions/<R>/end
Date: Oct 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Reading this file returns the end address of a memory region
that corresponding DAMON-based Operation Scheme's action has
tried to be applied.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/tried_regions/<R>/nr_accesses
Date: Oct 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Reading this file returns the 'nr_accesses' of a memory region
that corresponding DAMON-based Operation Scheme's action has
tried to be applied.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/tried_regions/<R>/age
Date: Oct 2022
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Reading this file returns the 'age' of a memory region that
corresponding DAMON-based Operation Scheme's action has tried
to be applied.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/tried_regions/<R>/sz_filter_passed
Date: Dec 2024
Contact: SeongJae Park <sj@kernel.org>
Contact: SJ Park <sj@kernel.org>
Description: Reading this file returns the size of the memory in the region
that passed DAMON operations layer-handled filters of the
scheme in bytes.

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

66
Documentation/admin-guide/cgroup-v1/rdma.rst
View File

@ -9,6 +9,7 @@ RDMA Controller
1-2. Why RDMA controller needed?
1-3. How is RDMA controller implemented?
2. Usage Examples
3. RDMA Interface Files
1. Overview
===========
@ -115,3 +116,68 @@ Following resources can be accounted by rdma controller.
(d) Delete resource limit::
echo mlx4_0 hca_handle=max hca_object=max > /sys/fs/cgroup/rdma/1/rdma.max
3. RDMA Interface Files
========================
The following interface files are available in each non-root RDMA cgroup.
rdma.max
A read-write file which describes the configured resource limit
for an RDMA/IB device. See the Usage Examples above.
rdma.current
A read-only file which describes the current resource usage.
rdma.peak
A read-only nested-keyed file which 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
and contains the following keys:
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 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 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

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

@ -1570,7 +1570,7 @@ The following nested keys are defined.
sock (npn)
Amount of memory used in network transmission buffers
vmalloc (npn)
vmalloc
Amount of memory used for vmap backed memory.
shmem
@ -1735,7 +1735,7 @@ The following nested keys are defined.
Number of pages written from zswap to swap.
zswap_incomp
Number of incompressible pages currently stored in zswap
Amount of memory used by incompressible pages currently stored in zswap
without compression. These pages could not be compressed to
a size smaller than PAGE_SIZE, so they are stored as-is.
@ -2239,9 +2239,12 @@ IO Latency
~~~~~~~~~~
This is a cgroup v2 controller for IO workload protection. You provide a group
with a latency target, and if the average latency exceeds that target the
controller will throttle any peers that have a lower latency target than the
protected workload.
with a latency target, and if the group misses its target the controller will
throttle any peers that have a lower latency target than the protected
workload. How a miss is detected depends on the device: on rotational devices
the average latency over the window must exceed the target, while on
non-rotational devices a miss is counted once enough of the IOs in the window
individually exceed the target.
The limits are only applied at the peer level in the hierarchy. This means that
in the diagram below, only groups A, B, and C will influence each other, and
@ -2257,10 +2260,13 @@ groups D and F will influence each other. Group G will influence nobody::
So the ideal way to configure this is to set io.latency in groups A, B, and C.
Generally you do not want to set a value lower than the latency your device
supports. Experiment to find the value that works best for your workload.
Start at higher than the expected latency for your device and watch the
avg_lat value in io.stat for your workload group to get an idea of the
latency you see during normal operation. Use the avg_lat value as a basis for
your real setting, setting at 10-15% higher than the value in io.stat.
Start at higher than the expected latency for your device and, with
blkcg_debug_stats enabled, observe io.stat for your workload group to get an
idea of the latency you see during normal operation. On rotational devices,
use the avg_lat value as a basis for your real setting, setting it 10-15%
higher. On non-rotational devices io.stat reports no average latency; set
the target based on your device and use the missed/total fields to verify it
is being met.
How IO Latency Throttling Works
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -2298,21 +2304,40 @@ IO Latency Interface Files
io.stat
If the controller is enabled you will see extra stats in io.stat in
addition to the normal ones.
addition to the normal ones. These debug stats are only emitted when
the blkcg_debug_stats module parameter is enabled (it is disabled by
default).
The reported latency fields depend on the device. Rotational devices
report avg_lat and win; non-rotational devices report missed and total
instead. missed and total are live counters for the current window and
may change between reads.
depth
This is the current queue depth for the group.
avg_lat
This is an exponential moving average with a decay rate of 1/exp
bound by the sampling interval. The decay rate interval can be
calculated by multiplying the win value in io.stat by the
corresponding number of samples based on the win value.
(Rotational devices only.) This is an exponential moving
average with a decay rate of 1/exp bound by the sampling
interval. The decay rate interval can be calculated by
multiplying the win value in io.stat by the corresponding number
of samples based on the win value.
win
The sampling window size in milliseconds. This is the minimum
duration of time between evaluation events. Windows only elapse
with IO activity. Idle periods extend the most recent window.
(Rotational devices only.) The sampling window size in
milliseconds. This is the minimum duration of time between
evaluation events. Windows only elapse with IO activity. Idle
periods extend the most recent window.
missed
(Non-rotational devices only.) The number of IOs in the
current window whose latency exceeded the target. A group is
considered to be missing its target once missed reaches a
certain ratio of total.
total
(Non-rotational devices only.) The total number of IOs
accounted in the current window.
IO Priority
~~~~~~~~~~~
@ -2934,7 +2959,8 @@ include/linux/misc_cgroup.h.
Misc Interface Files
~~~~~~~~~~~~~~~~~~~~
Miscellaneous controller provides 3 interface files. If two misc resources (res_a and res_b) are registered then:
Miscellaneous controller provides the following interface files. If two misc
resources (res_a and res_b) are registered then:
misc.capacity
A read-only flat-keyed file shown only in the root cgroup. It shows

28
Documentation/arch/arm64/cpu-hotplug.rst
View File

@ -47,11 +47,12 @@ ever have can be described at boot. There are no power-domain considerations
as such devices are emulated.
CPU Hotplug on virtual systems is supported. It is distinct from physical
CPU Hotplug as all resources are described as ``present``, but CPUs may be
marked as disabled by firmware. Only the CPU's online/offline behaviour is
influenced by firmware. An example is where a virtual machine boots with a
single CPU, and additional CPUs are added once a cloud orchestrator deploys
the workload.
CPU Hotplug as all vCPU resources are statically described in the firmware
configuration tables (e.g. MADT), meaning their maximum possible count is
known at boot. However, vCPUs that are not enabled at boot are not marked
as ``present`` by the kernel until they are hotplugged. An example is where
a virtual machine boots with a single CPU, and additional CPUs are added
once a cloud orchestrator deploys the workload.
For a virtual machine, the VMM (e.g. Qemu) plays the part of firmware.
@ -60,16 +61,19 @@ brought online. Firmware can enforce its policy via PSCI's return codes. e.g.
``DENIED``.
The ACPI tables must describe all the resources of the virtual machine. CPUs
that firmware wishes to disable either from boot (or later) should not be
``enabled`` in the MADT GICC structures, but should have the ``online capable``
bit set, to indicate they can be enabled later. The boot CPU must be marked as
``enabled``. The 'always on' GICR structure must be used to describe the
redistributors.
that are hot-pluggable must have the ``online capable`` bit set and the
``enabled`` bit cleared in the MADT GICC structures to indicate they can be
enabled later. The boot CPU must be marked as ``enabled`` with its
``online capable`` bit cleared. The 'always on' GICR structure must be used
to describe the redistributors.
CPUs described as ``online capable`` but not ``enabled`` can be set to enabled
by the DSDT's Processor object's _STA method. On virtual systems the _STA method
must always report the CPU as ``present``. Changes to the firmware policy can
be notified to the OS via device-check or eject-request.
must always set the ``ACPI_STA_DEVICE_PRESENT`` bit, while toggling the
``ACPI_STA_DEVICE_ENABLED`` bit to reflect its plug status. The kernel will
then dynamically mark the vCPU as ``present`` within the OS when the
``ACPI_STA_DEVICE_ENABLED`` bit becomes set during hot-add. Changes to the
firmware policy can be notified to the OS via device-check or eject-request.
CPUs described as ``enabled`` in the static table, should not have their _STA
modified dynamically by firmware. Soft-restart features such as kexec will

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

@ -55,10 +55,14 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| Ampere | AmpereOne | AC03_CPU_38 | AMPERE_ERRATUM_AC03_CPU_38 |
+----------------+-----------------+-----------------+-----------------------------+
| Ampere | AmpereOne | AC03_CPU_57 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| Ampere | AmpereOne AC04 | AC04_CPU_10 | AMPERE_ERRATUM_AC03_CPU_38 |
+----------------+-----------------+-----------------+-----------------------------+
| Ampere | AmpereOne AC04 | AC04_CPU_23 | AMPERE_ERRATUM_AC04_CPU_23 |
+----------------+-----------------+-----------------+-----------------------------+
| Ampere | AmpereOne AC04 | AC04_CPU_29 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 |
+----------------+-----------------+-----------------+-----------------------------+

204
Documentation/arch/riscv/hwprobe.rst
View File

@ -82,121 +82,121 @@ The following keys are defined:
version 1.0 of the RISC-V Vector extension manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZBA`: The Zba address generation extension is
supported, as defined in version 1.0 of the Bit-Manipulation ISA
extensions.
supported, as defined in version 1.0 of the Bit-Manipulation ISA
extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZBB`: The Zbb extension is supported, as defined
in version 1.0 of the Bit-Manipulation ISA extensions.
in version 1.0 of the Bit-Manipulation ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, as defined
in version 1.0 of the Bit-Manipulation ISA extensions.
in version 1.0 of the Bit-Manipulation ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Zicboz extension is supported, as
ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
* :c:macro:`RISCV_HWPROBE_EXT_ZBC` The Zbc extension is supported, as defined
in version 1.0 of the Bit-Manipulation ISA extensions.
in version 1.0 of the Bit-Manipulation ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZBKB` The Zbkb extension is supported, as
defined in version 1.0 of the Scalar Crypto ISA extensions.
defined in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZBKC` The Zbkc extension is supported, as
defined in version 1.0 of the Scalar Crypto ISA extensions.
defined in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZBKX` The Zbkx extension is supported, as
defined in version 1.0 of the Scalar Crypto ISA extensions.
defined in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZKND` The Zknd extension is supported, as
defined in version 1.0 of the Scalar Crypto ISA extensions.
defined in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZKNE` The Zkne extension is supported, as
defined in version 1.0 of the Scalar Crypto ISA extensions.
defined in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZKNH` The Zknh extension is supported, as
defined in version 1.0 of the Scalar Crypto ISA extensions.
defined in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZKSED` The Zksed extension is supported, as
defined in version 1.0 of the Scalar Crypto ISA extensions.
defined in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZKSH` The Zksh extension is supported, as
defined in version 1.0 of the Scalar Crypto ISA extensions.
defined in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZKT` The Zkt extension is supported, as defined
in version 1.0 of the Scalar Crypto ISA extensions.
in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZVBB`: The Zvbb extension is supported as
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVBC`: The Zvbc extension is supported as
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVKB`: The Zvkb extension is supported as
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVKG`: The Zvkg extension is supported as
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVKNED`: The Zvkned extension is supported as
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVKNHA`: The Zvknha extension is supported as
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVKNHB`: The Zvknhb extension is supported as
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVKSED`: The Zvksed extension is supported as
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVKSH`: The Zvksh extension is supported as
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVKT`: The Zvkt extension is supported as
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZFH`: The Zfh extension version 1.0 is supported
as defined in the RISC-V ISA manual.
as defined in the RISC-V ISA manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZFHMIN`: The Zfhmin extension version 1.0 is
supported as defined in the RISC-V ISA manual.
supported as defined in the RISC-V ISA manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZIHINTNTL`: The Zihintntl extension version 1.0
is supported as defined in the RISC-V ISA manual.
is supported as defined in the RISC-V ISA manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZVFH`: The Zvfh extension is supported as
defined in the RISC-V Vector manual starting from commit e2ccd0548d6c
("Remove draft warnings from Zvfh[min]").
defined in the RISC-V Vector manual starting from commit e2ccd0548d6c
("Remove draft warnings from Zvfh[min]").
* :c:macro:`RISCV_HWPROBE_EXT_ZVFHMIN`: The Zvfhmin extension is supported as
defined in the RISC-V Vector manual starting from commit e2ccd0548d6c
("Remove draft warnings from Zvfh[min]").
defined in the RISC-V Vector manual starting from commit e2ccd0548d6c
("Remove draft warnings from Zvfh[min]").
* :c:macro:`RISCV_HWPROBE_EXT_ZFA`: The Zfa extension is supported as
defined in the RISC-V ISA manual starting from commit 056b6ff467c7
("Zfa is ratified").
defined in the RISC-V ISA manual starting from commit 056b6ff467c7
("Zfa is ratified").
* :c:macro:`RISCV_HWPROBE_EXT_ZTSO`: The Ztso extension is supported as
defined in the RISC-V ISA manual starting from commit 5618fb5a216b
("Ztso is now ratified.")
defined in the RISC-V ISA manual starting from commit 5618fb5a216b
("Ztso is now ratified.")
* :c:macro:`RISCV_HWPROBE_EXT_ZACAS`: The Zacas extension is supported as
defined in the Atomic Compare-and-Swap (CAS) instructions manual starting
from commit 5059e0ca641c ("update to ratified").
defined in the Atomic Compare-and-Swap (CAS) instructions manual starting
from commit 5059e0ca641c ("update to ratified").
* :c:macro:`RISCV_HWPROBE_EXT_ZICNTR`: The Zicntr extension version 2.0
is supported as defined in the RISC-V ISA manual.
is supported as defined in the RISC-V ISA manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZICOND`: The Zicond extension is supported as
defined in the RISC-V Integer Conditional (Zicond) operations extension
manual starting from commit 95cf1f9 ("Add changes requested by Ved
during signoff")
defined in the RISC-V Integer Conditional (Zicond) operations extension
manual starting from commit 95cf1f9 ("Add changes requested by Ved
during signoff")
* :c:macro:`RISCV_HWPROBE_EXT_ZIHINTPAUSE`: The Zihintpause extension is
supported as defined in the RISC-V ISA manual starting from commit
d8ab5c78c207 ("Zihintpause is ratified").
supported as defined in the RISC-V ISA manual starting from commit
d8ab5c78c207 ("Zihintpause is ratified").
* :c:macro:`RISCV_HWPROBE_EXT_ZIHPM`: The Zihpm extension version 2.0
is supported as defined in the RISC-V ISA manual.
is supported as defined in the RISC-V ISA manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZVE32X`: The Vector sub-extension Zve32x is
supported, as defined by version 1.0 of the RISC-V Vector extension manual.
@ -214,84 +214,89 @@ The following keys are defined:
supported, as defined by version 1.0 of the RISC-V Vector extension manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZIMOP`: The Zimop May-Be-Operations extension is
supported as defined in the RISC-V ISA manual starting from commit
58220614a5f ("Zimop is ratified/1.0").
supported as defined in the RISC-V ISA manual starting from commit
58220614a5f ("Zimop is ratified/1.0").
* :c:macro:`RISCV_HWPROBE_EXT_ZCA`: The Zca extension part of Zc* standard
extensions for code size reduction, as ratified in commit 8be3419c1c0
("Zcf doesn't exist on RV64 as it contains no instructions") of
riscv-code-size-reduction.
extensions for code size reduction, as ratified in commit 8be3419c1c0
("Zcf doesn't exist on RV64 as it contains no instructions") of
riscv-code-size-reduction.
* :c:macro:`RISCV_HWPROBE_EXT_ZCB`: The Zcb extension part of Zc* standard
extensions for code size reduction, as ratified in commit 8be3419c1c0
("Zcf doesn't exist on RV64 as it contains no instructions") of
riscv-code-size-reduction.
extensions for code size reduction, as ratified in commit 8be3419c1c0
("Zcf doesn't exist on RV64 as it contains no instructions") of
riscv-code-size-reduction.
* :c:macro:`RISCV_HWPROBE_EXT_ZCD`: The Zcd extension part of Zc* standard
extensions for code size reduction, as ratified in commit 8be3419c1c0
("Zcf doesn't exist on RV64 as it contains no instructions") of
riscv-code-size-reduction.
extensions for code size reduction, as ratified in commit 8be3419c1c0
("Zcf doesn't exist on RV64 as it contains no instructions") of
riscv-code-size-reduction.
* :c:macro:`RISCV_HWPROBE_EXT_ZCF`: The Zcf extension part of Zc* standard
extensions for code size reduction, as ratified in commit 8be3419c1c0
("Zcf doesn't exist on RV64 as it contains no instructions") of
riscv-code-size-reduction.
extensions for code size reduction, as ratified in commit 8be3419c1c0
("Zcf doesn't exist on RV64 as it contains no instructions") of
riscv-code-size-reduction.
* :c:macro:`RISCV_HWPROBE_EXT_ZCMOP`: The Zcmop May-Be-Operations extension is
supported as defined in the RISC-V ISA manual starting from commit
c732a4f39a4 ("Zcmop is ratified/1.0").
supported as defined in the RISC-V ISA manual starting from commit
c732a4f39a4 ("Zcmop is ratified/1.0").
* :c:macro:`RISCV_HWPROBE_EXT_ZAWRS`: The Zawrs extension is supported as
ratified in commit 98918c844281 ("Merge pull request #1217 from
riscv/zawrs") of riscv-isa-manual.
ratified in commit 98918c844281 ("Merge pull request #1217 from
riscv/zawrs") of riscv-isa-manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZAAMO`: The Zaamo extension is supported as
defined in the in the RISC-V ISA manual starting from commit e87412e621f1
("integrate Zaamo and Zalrsc text (#1304)").
defined in the in the RISC-V ISA manual starting from commit e87412e621f1
("integrate Zaamo and Zalrsc text (#1304)").
* :c:macro:`RISCV_HWPROBE_EXT_ZALASR`: The Zalasr extension is supported as
frozen at commit 194f0094 ("Version 0.9 for freeze") of riscv-zalasr.
frozen at commit 194f0094 ("Version 0.9 for freeze") of riscv-zalasr.
* :c:macro:`RISCV_HWPROBE_EXT_ZALRSC`: The Zalrsc extension is supported as
defined in the in the RISC-V ISA manual starting from commit e87412e621f1
("integrate Zaamo and Zalrsc text (#1304)").
defined in the in the RISC-V ISA manual starting from commit e87412e621f1
("integrate Zaamo and Zalrsc text (#1304)").
* :c:macro:`RISCV_HWPROBE_EXT_SUPM`: The Supm extension is supported as
defined in version 1.0 of the RISC-V Pointer Masking extensions.
defined in version 1.0 of the RISC-V Pointer Masking extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZFBFMIN`: The Zfbfmin extension is supported as
defined in the RISC-V ISA manual starting from commit 4dc23d6229de
("Added Chapter title to BF16").
defined in the RISC-V ISA manual starting from commit 4dc23d6229de
("Added Chapter title to BF16").
* :c:macro:`RISCV_HWPROBE_EXT_ZVFBFMIN`: The Zvfbfmin extension is supported as
defined in the RISC-V ISA manual starting from commit 4dc23d6229de
("Added Chapter title to BF16").
defined in the RISC-V ISA manual starting from commit 4dc23d6229de
("Added Chapter title to BF16").
* :c:macro:`RISCV_HWPROBE_EXT_ZVFBFWMA`: The Zvfbfwma extension is supported as
defined in the RISC-V ISA manual starting from commit 4dc23d6229de
("Added Chapter title to BF16").
defined in the RISC-V ISA manual starting from commit 4dc23d6229de
("Added Chapter title to BF16").
* :c:macro:`RISCV_HWPROBE_EXT_ZICBOM`: The Zicbom extension is supported, as
ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
* :c:macro:`RISCV_HWPROBE_EXT_ZABHA`: The Zabha extension is supported as
ratified in commit 49f49c842ff9 ("Update to Rafified state") of
riscv-zabha.
ratified in commit 49f49c842ff9 ("Update to Rafified state") of
riscv-zabha.
* :c:macro:`RISCV_HWPROBE_EXT_ZICBOP`: The Zicbop extension is supported, as
ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
* :c:macro:`RISCV_HWPROBE_EXT_ZILSD`: The Zilsd extension is supported as
defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating
load/store pair for RV32 with the main manual") of the riscv-isa-manual.
defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating
load/store pair for RV32 with the main manual") of the riscv-isa-manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZCLSD`: The Zclsd extension is supported as
defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating
load/store pair for RV32 with the main manual") of the riscv-isa-manual.
defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating
load/store pair for RV32 with the main manual") of the riscv-isa-manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZICFILP`: The Zicfilp extension is supported,
as defined in version 1.0 of the RISC-V Control-flow Integrity (CFI)
extensions specification, ratified in commit 302a2d45c243
("Update build-pdf.yml") of riscv-cfi.
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: Deprecated. Returns similar values to
:c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`, but the key was
mistakenly classified as a bitmask rather than a value.
:c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`, but the key was
mistakenly classified as a bitmask rather than a value.
* :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`: An enum value describing
the performance of misaligned scalar native word accesses on the selected set
@ -326,7 +331,7 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_KEY_TIME_CSR_FREQ`: Frequency (in Hz) of `time CSR`.
* :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`: An enum value describing the
performance of misaligned vector accesses on the selected set of processors.
performance of misaligned vector accesses on the selected set of processors.
* :c:macro:`RISCV_HWPROBE_MISALIGNED_VECTOR_UNKNOWN`: The performance of misaligned
vector accesses is unknown.
@ -348,7 +353,7 @@ The following keys are defined:
* MIPS
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XMIPSEXECTL`: The xmipsexectl vendor
extension is supported in the MIPS ISA extensions spec.
extension is supported in the MIPS ISA extensions spec.
* :c:macro:`RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0`: A bitmask containing the
thead vendor extensions that are compatible with the
@ -357,8 +362,8 @@ The following keys are defined:
* T-HEAD
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XTHEADVECTOR`: The xtheadvector vendor
extension is supported in the T-Head ISA extensions spec starting from
commit a18c801634 ("Add T-Head VECTOR vendor extension. ").
extension is supported in the T-Head ISA extensions spec starting from
commit a18c801634 ("Add T-Head VECTOR vendor extension. ").
* :c:macro:`RISCV_HWPROBE_KEY_ZICBOM_BLOCK_SIZE`: An unsigned int which
represents the size of the Zicbom block in bytes.
@ -370,20 +375,20 @@ The following keys are defined:
* SIFIVE
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVQMACCDOD`: The Xsfqmaccdod vendor
extension is supported in version 1.1 of SiFive Int8 Matrix Multiplication
Extensions Specification.
extension is supported in version 1.1 of SiFive Int8 Matrix Multiplication
Extensions Specification.
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVQMACCQOQ`: The Xsfqmaccqoq vendor
extension is supported in version 1.1 of SiFive Int8 Matrix Multiplication
Instruction Extensions Specification.
extension is supported in version 1.1 of SiFive Int8 Matrix Multiplication
Instruction Extensions Specification.
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVFNRCLIPXFQF`: The Xsfvfnrclipxfqf
vendor extension is supported in version 1.0 of SiFive FP32-to-int8 Ranged
Clip Instructions Extensions Specification.
vendor extension is supported in version 1.0 of SiFive FP32-to-int8 Ranged
Clip Instructions Extensions Specification.
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVFWMACCQQQ`: The Xsfvfwmaccqqq
vendor extension is supported in version 1.0 of Matrix Multiply Accumulate
Instruction Extensions Specification.
vendor extension is supported in version 1.0 of Matrix Multiply Accumulate
Instruction Extensions Specification.
* :c:macro:`RISCV_HWPROBE_KEY_ZICBOP_BLOCK_SIZE`: An unsigned int which
represents the size of the Zicbop block in bytes.
@ -391,3 +396,8 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_KEY_IMA_EXT_1`: A bitmask containing additional
extensions that are compatible with the
:c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`: base system behavior.
* :c:macro:`RISCV_HWPROBE_EXT_ZICFISS`: The Zicfiss extension is supported,
as defined in version 1.0 of the RISC-V Control-flow Integrity (CFI)
extensions specification, ratified in commit 302a2d45c243
("Update build-pdf.yml") of riscv-cfi.

5
Documentation/bpf/bpf_devel_QA.rst
View File

@ -479,7 +479,10 @@ for details.
To maximize the number of tests passing, the .config of the kernel
under test should match the config file fragment in
tools/testing/selftests/bpf as closely as possible.
tools/testing/selftests/bpf as closely as possible. If not possible,
however, you can set ``BPF_STRICT_BUILD=0`` when invoking ``make``
to tolerate individual compilation failures and continue building
the remaining tests rather than treating each failure as fatal.
Finally to ensure support for latest BPF Type Format features -
discussed in Documentation/bpf/btf.rst - pahole version 1.16

1
Documentation/bpf/index.rst
View File

@ -28,6 +28,7 @@ that goes into great technical depth about the BPF Architecture.
classic_vs_extended.rst
bpf_iterators
bpf_licensing
signing
test_debug
clang-notes
linux-notes

99
Documentation/bpf/kfuncs.rst
View File

@ -250,6 +250,71 @@ Or::
...
}
2.3.7 __const_map and __map Annotations
---------------------------------------
These annotations are used for ``struct bpf_map *`` arguments and distinguish a
verifier-known map from an opaque one.
``__const_map`` indicates a map must be known at the verification time, i.e. a
concrete map fd the BPF program references directly.
An example is given below::
__bpf_kfunc int bpf_wq_init(struct bpf_wq *wq, void *p__const_map,
unsigned int flags)
{
...
}
``__map`` indicates an opaque ``struct bpf_map *`` that may be resolved
at run time. The argument may take either a map fd or a ``PTR_TO_BTF_ID``
``struct bpf_map`` pointer.
An example is given below::
__bpf_kfunc void *bpf_arena_alloc_pages(void *p__map, ...)
{
...
}
2.3.8 __arena and __arena__nullable Annotations
-----------------------------------------------
Both annotations indicate that the pointer argument points into the
calling program's arena. The JIT rebases the value at the call site so
the kfunc receives a directly dereferenceable kernel address, subject to
the access rules described in :ref:`BPF_kfunc_arena_access` (at most
``GUARD_SZ / 2``, 32 KiB, past the pointer in a single unchecked access).
With ``__arena`` the rebase is unconditional and the argument is never
NULL: a value whose lower 32 bits are zero arrives as the arena base
address (arena offset 0). The kfunc must not check the argument for NULL.
With ``__arena__nullable`` such a value arrives as NULL instead and the
kfunc must check before dereferencing.
An example is given below::
__bpf_kfunc int bpf_process_item(struct item *item__arena)
{
...
}
Calling such a kfunc requires the program to use an arena map and a JIT with
arena argument support (currently x86-64); verification fails otherwise. The
program can pass any value without compromising the kernel. A value that does
not point into the arena is a program bug.
The suffixes have the same meaning on the arguments of struct_ops stub
functions, with the conversion running in the opposite direction. The
kernel caller passes the kernel arena address and the trampoline converts
it while saving the arguments, so the callback receives an arena pointer
it can dereference directly. With ``__arena`` the kernel caller must not
pass NULL. With ``__arena__nullable`` a NULL kernel pointer arrives as NULL.
However, there is no obligation to prove to the verifier that such a pointer is
non-NULL before use, in-line with existing semantics of arena pointers used in
a program (or obtained from any other source).
.. _BPF_kfunc_nodef:
2.4 Using an existing kernel function
@ -273,22 +338,29 @@ flags on a set of kfuncs as follows::
BTF_KFUNCS_END(bpf_task_set)
This set encodes the BTF ID of each kfunc listed above, and encodes the flags
along with it. Ofcourse, it is also allowed to specify no flags.
along with it. It is also allowed to specify no flags.
kfunc definitions should also always be annotated with the ``__bpf_kfunc``
macro. This prevents issues such as the compiler inlining the kfunc if it's a
static kernel function, or the function being elided in an LTO build as it's
not used in the rest of the kernel. Developers should not manually add
annotations to their kfunc to prevent these issues. If an annotation is
required to prevent such an issue with your kfunc, it is a bug and should be
added to the definition of the macro so that other kfuncs are similarly
protected. An example is given below::
macro. This prevents issues such as the compiler inlining the kfunc, or the
function being elided in an LTO build as it's not used in the rest of the
kernel. Developers should not manually add annotations to their kfunc to prevent
these issues. If an annotation is required to prevent such an issue with your
kfunc, it is a bug and should be added to the definition of the macro so that
other kfuncs are similarly protected. An example is given below::
__bpf_kfunc struct task_struct *bpf_get_task_pid(s32 pid)
{
...
}
Note that kfuncs must not be declared ``static``. A kfunc can be called from a
BPF program ``*.c`` file outside the compilation unit that defines it, so its
externally visible name must remain available for BTF ID lookup. ``static``
linkage allows the compiler to rename the function, which can break this
BTF-based kfunc resolution. Further note that sparse may warn that an otherwise
unreferenced kfunc should be static. Such warnings should be ignored for kfunc
definitions.
2.5.1 KF_ACQUIRE flag
---------------------
@ -404,7 +476,7 @@ Example declaration:
.. code-block:: c
__bpf_kfunc int bpf_task_work_schedule_signal(struct task_struct *task, struct bpf_task_work *tw,
void *map__map, bpf_task_work_callback_t callback,
void *map__const_map, bpf_task_work_callback_t callback,
struct bpf_prog_aux *aux) { ... }
Example usage in BPF program:
@ -437,6 +509,13 @@ type. An example is shown below::
}
late_initcall(init_subsystem);
At kernel build time the ``resolve_btfids`` tool finds all kfuncs declared with
``BTF_KFUNCS_START()`` and emits their BTF annotations into the kernel's BTF.
For each kfunc it emits a ``bpf_kfunc`` BTF decl tag, a ``bpf_fastcall`` decl
tag when the kfunc is flagged ``KF_FASTCALL``, and the ``address_space(1)`` type
attribute on the return value and/or arguments flagged ``KF_ARENA_RET``,
``KF_ARENA_ARG1`` or ``KF_ARENA_ARG2`` (see section 2.8).
2.7 Specifying no-cast aliases with ___init
--------------------------------------------
@ -480,6 +559,8 @@ 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``.
.. _BPF_kfunc_arena_access:
2.8 Accessing arena memory through kfunc arguments
--------------------------------------------------

497
Documentation/bpf/signing.rst Normal file
View File

@ -0,0 +1,497 @@
.. SPDX-License-Identifier: GPL-2.0
============
BPF signing
============
This document describes how BPF programs are cryptographically signed, how the
kernel verifies them at load time, and how Linux Security Modules (LSMs) -
including the BPF LSM - use the resulting verdict to enforce policy. It is
written for developers who want to produce signed BPF objects, understand what
the signature actually guarantees, or build a policy on top of it.
Motivation
==========
A signed BPF program lets the kernel establish that the bytecode being loaded
originates from a trusted producer and was not modified in transit. On its own
the kernel does not *require* signatures - an unsigned program loads exactly as
before - but it records a verdict (see `The verdict`_) that an LSM can gate on.
This is the building block for policies such as "only run BPF that was signed by
a key in the trusted keyring", as could in the future be enforced by an LSM
such as IPE.
Signing is orthogonal to the existing permission model: it does not replace the
capability checks or the verifier. A signed load still requires the usual
privileges (``CAP_BPF`` and any program-type-specific capability, subject to
``kernel.unprivileged_bpf_disabled``), and the loader's instructions are still
checked by the verifier like any other program. A valid signature establishes
*origin and integrity*, not safety - it lets a policy trust where the bytecode
came from, it does not let a load skip any check it would otherwise face.
The hard part is *what* gets signed. A naive scheme would sign a program's
instruction buffer at build time and verify that signature at
``BPF_PROG_LOAD``. That does not survive contact with real BPF objects, because
the bytes the kernel finally loads are not the bytes the developer built and
signed. Between the two, libbpf and the kernel rewrite the program:
- **map file descriptors** are patched into ``ld_imm64`` instructions
(``BPF_PSEUDO_MAP_FD``), and a map's fd is assigned at load time, so it
differs on every run;
- **CO-RE relocations** rewrite field offsets, sizes and existence flags against
the *running* kernel's BTF, so the result differs from one kernel to the next;
- **kfunc and ksym references** are resolved to ids/addresses in the running
kernel;
- **global data** (``.rodata``/``.data``/``.bss``) is created and seeded as maps
at load.
So a signature over the original instructions cannot match the relocated
instructions the verifier ends up checking, and the relocated form cannot be
produced ahead of time because it depends on the target kernel. There is no
fixed byte string that is both signable at build time and what the kernel
actually loads - which is why a program cannot simply be signed and loaded
directly.
The trusted loader
==================
The solution is to move that setup work *into* a small BPF program - the
**loader** - and sign the loader instead of the individual programs. libbpf's
``gen_loader`` machinery (``bpftool gen skeleton -L``, the "light skeleton")
emits a ``BPF_PROG_TYPE_SYSCALL`` program whose body performs the bpf() syscalls
that create maps, apply relocations, and load the real programs. The payload it
installs - the serialized programs, map descriptions, relocation data and
initial values - lives in a separate array map, the **metadata map**
(``__loader.map``).
So the unit of trust is the loader, and the signing contract is::
Sig(I_loader || D_meta)
where ``I_loader`` is the loader's instruction stream and ``D_meta`` is the
content of the metadata map. Verifying the loader's signature establishes that
both the loader *and* the payload it is about to install are authentic. The
loader is reproducible: ``gen_loader`` builds it from primitives so the same
object yields the same bytes on any build host.
Why the loader is signable when the program is not
--------------------------------------------------
The loader sidesteps every rewrite listed above, because the bytes that are
signed are *relocation-invariant*:
- The loader's own instructions are a fixed sequence of bpf() syscalls emitted
by ``gen_loader``; they carry no CO-RE relocations and resolve no ksyms, so
they are identical on every kernel. The metadata map is referenced by *index*
into ``fd_array`` (``BPF_PSEUDO_MAP_IDX_VALUE``), not by a baked-in file
descriptor, so even that reference does not change between build and load.
The loader instruction bytes the kernel verifies are exactly the bytes that
were signed.
- The metadata map is opaque, frozen data - the serialized target programs,
their relocation records, map descriptions and initial values. Its bytes are
identical at build time and at load time, so they are simply appended to the
instructions and covered by the same signature (there is no separate metadata
hash to compute or compare).
All the host-specific rewriting - creating maps, patching their fds into the
target programs, applying CO-RE, resolving ksyms, seeding global data - still
happens, but it happens *inside the loader at runtime*, on the verified
metadata, **after** the kernel has verified the ``insns || metadata`` signature.
The kernel never has to verify the relocated target programs: it verifies the
loader and its inputs once, and trust transfers to whatever that now-trusted,
deterministic loader installs. The relocation step is moved from "before the
signature can be checked" to "after a trusted program runs" - which is exactly
what makes it signable.
Because the metadata map is the loader's only untrusted input, two existing map
properties are reused to keep it trustworthy across the load:
Exclusive maps
A map created with ``excl_prog_hash`` (see ``BPF_MAP_CREATE``) may only be
accessed by a program whose digest matches that hash. The verifier enforces
``map->excl_prog_sha == prog->digest`` for every map a program uses, so the
metadata map is bound to exactly the signed loader and cannot be shared with
or mutated by another program.
Frozen maps
The metadata map is frozen (``BPF_MAP_FREEZE``) before the loader is loaded.
Freezing blocks further userspace writes, so the bytes folded into the
signature cannot change before the loader runs. (Freezing does not make the
map read-only to the loader program itself, which still writes created file
descriptors back into the blob's scratch area.)
Load-time verification
=======================
Rather than have the loader check its own metadata from within BPF, the kernel
verifies it directly at ``BPF_PROG_LOAD``, with no new UAPI. The mechanism
reuses the existing ``fd_array``:
#. Userspace creates the metadata map with ``excl_prog_hash`` set to the
loader's digest, populates it, and freezes it.
#. The loader is loaded with ``signature``/``signature_size``/``keyring_id``
set, the metadata map referenced through ``fd_array``, and ``fd_array_cnt``
set so the kernel knows the array's length.
#. Signature verification runs inside the verifier (``bpf_check()``), once it
has resolved the ``fd_array`` entries into the program's ``used_maps``. The
maps folded into the signature are therefore the very objects the program
binds - a single resolution of ``fd_array``, not a separate read, so the
verified bytes cannot be swapped for a different map after the check (no
time-of-check/time-of-use window). Each folded map must be exclusive (carry
``excl_prog_sha``) and a plain array map (``BPF_MAP_TYPE_ARRAY``); only an
array map exposes its value buffer through ``map_direct_value_addr()`` as a
kernel address spanning ``value_size`` bytes. A map that is not exclusive, not
frozen, or not a plain array is rejected, with a verifier log message naming
the offending map. The kernel appends each map's frozen
contents to the instruction buffer and verifies the PKCS#7 signature over the
concatenation ``insns || metadata_0 || metadata_1 || ...`` in ``used_maps``
order, before it rewrites the (signed) instructions.
A signed program therefore takes one of exactly two shapes, both fully
supported:
- **No bound maps** (``fd_array_cnt == 0``): there is nothing to append, so the
kernel verifies the signature over the instructions alone. A valid signature
yields ``BPF_SIG_VERIFIED`` and the program loads. This is the ordinary case
for a directly-loaded signed program with no separate payload; it is *not*
rejected for "missing" metadata, because it has none to cover.
- **Exclusive bound maps** (``fd_array_cnt > 0``): every entry is exclusive and
folded, so the signature covers ``insns || metadata``.
There is no third shape: a non-exclusive map in a signed program's ``fd_array``
is rejected rather than silently left out of the signature, so a signed loader
never binds a map its signature does not cover.
The digest binding (``excl_prog_sha == prog->digest``) is enforced by the
verifier as usual; because that check runs while ``fd_array`` is resolved -
before the verifier would otherwise compute the tag - ``prog->digest`` is
computed up front in the verifier, over the unmodified (signature-covered)
instructions, for any signed load.
Coverage is then enforced as the verifier resolves instructions, at the point
each object is bound rather than by a count taken afterwards. Once the signature
has been verified, binding any further map is refused: a map reached by a
directly-referenced fd, or a map swapped into an ``fd_array`` slot the loader
reads, is not among those already folded, so it is rejected the moment the
verifier tries to bind it. A BTF is refused outright for a signed program - a
ksym or a BTF fd in ``fd_array``, whether resolved up front or lazily for a
module kfunc, is rejected when it would be bound. Together with the fold rule
above this keeps the verdict binary: a signed program cannot use a map its
signature does not cover, and a different but equally digest-bound map cannot be
substituted at an ``fd_array`` slot. Non-exclusive maps are never folded, so a
signed program cannot use one at all.
The verdict
===========
A program is either unsigned or fully verified - there is no intermediate
state. The outcome is recorded in ``prog->aux->sig.verdict``:
.. code-block:: c
enum bpf_sig_verdict {
BPF_SIG_UNSIGNED = 0,
BPF_SIG_VERIFIED,
};
``BPF_SIG_VERIFIED`` means the signature is valid and covers the instructions
*and* the frozen contents of every exclusive map the program uses:
- For an ordinary, directly-loaded signed program the instructions are the whole
artifact and it uses no exclusive maps, so a valid instruction signature is
the complete verification.
- For a signed loader the metadata map is exclusive, so its contents are folded
in and the signature covers ``insns || metadata``.
There is deliberately no "instructions verified but metadata not" verdict: a
signed loader that fails to cover its metadata is *rejected* (see above), not
recorded with a weaker verdict. ``BPF_SIG_VERIFIED`` therefore always means the
program and everything the signature is responsible for are authentic, which is
what a policy can rely on.
Alongside the verdict the kernel records which keyring validated the signature;
see `Keyrings`_.
Enforcement via LSMs
====================
Signing only *records* a verdict; an LSM turns it into policy. The verdict and
keyring fields live in ``struct bpf_prog_aux``, so a BPF LSM program can read
them directly (see Documentation/bpf/prog_lsm.rst for writing and attaching BPF
LSM programs); the same fields are equally available to in-tree LSMs. Two hooks
are useful at different points of the load: the dedicated
``security_bpf_prog_load()`` gates admission before the main verification work,
and the existing ``security_bpf_prog()`` observes a program that has fully
loaded.
Admission: ``security_bpf_prog_load()``
---------------------------------------
This hook gates admission **for every load**, from a single call site inside the
verifier (``bpf_check()``), before the main verification work. It runs after the
optional signature verification, so the verdict and keyring fields are final - the
hook can see whether, and how strongly, the program was signed, which keyring
validated it, the load ``attr``, the BPF token and whether the load came from the
kernel. For a signed load the verdict is ``BPF_SIG_VERIFIED`` here (the signature
has just been checked); for an unsigned load it is ``BPF_SIG_UNSIGNED``.
This is the place for *coarse admission* that must also see unsigned and
not-yet-verified loads: require a signature at all, restrict the acceptable
keyring, restrict which token/credentials may load BPF, apply per-program-type
rules, or audit every load attempt that makes it past signature verification -
attempts failing the signature or the metadata binding abort before this hook
fires. It is the primary deny point.
One subtlety: this hook runs *before* the verifier finishes its work, so
``BPF_SIG_VERIFIED`` *here* means only "validly signed" - not "loaded". Allowing
a load at this point lets it *proceed*; it does not guarantee the program will
load. A validly signed program can still be rejected afterwards on two
independent grounds: the verifier may reject it like any other program (unsafe
memory access, bad control flow, resource limits, ...), and the kernel separately
refuses - as the verifier resolves instructions and binds each object - any map
the signature does not cover or any BTF at all, regardless of what this hook
returned. Only after the program has fully loaded, at the next hook
(``security_bpf_prog()``), does ``BPF_SIG_VERIFIED`` carry its full meaning:
validly signed *and* fully verified.
A more realistic admission policy than "is it signed at all": accept programs
signed by a system keyring, accept a user-keyring signature only if the
key/keyring it was verified against is on an explicit allowlist, and emit a
tamper-evident record of every decision so that even denied attempts are
auditable. (Illustrative - error checking elided.)
.. code-block:: c
/* Serials of user keys/keyrings we additionally trust. */
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__type(key, __s32); /* keyring_serial */
__type(value, __u8);
__uint(max_entries, 64);
} trusted_user_keys SEC(".maps");
/* Audit stream consumed by a userspace logger. */
struct {
__uint(type, BPF_MAP_TYPE_RINGBUF);
__uint(max_entries, 1 << 16);
} audit SEC(".maps");
struct decision { __u32 prog_type, verdict, ktype; __s32 serial, ret; };
SEC("lsm/bpf_prog_load")
int BPF_PROG(admit, struct bpf_prog *prog, union bpf_attr *attr,
struct bpf_token *token, bool kernel)
{
__u32 verdict = prog->aux->sig.verdict;
__u32 ktype = prog->aux->sig.keyring_type;
__s32 serial = prog->aux->sig.keyring_serial;
struct decision *d;
int ret = 0;
if (kernel)
return 0; /* trust in-kernel loads */
if (verdict != BPF_SIG_VERIFIED)
ret = -EPERM; /* must be validly signed */
else if (ktype == BPF_SIG_KEYRING_USER &&
!bpf_map_lookup_elem(&trusted_user_keys, &serial))
ret = -EPERM; /* key/keyring not allowlisted */
d = bpf_ringbuf_reserve(&audit, sizeof(*d), 0);
if (d) {
d->prog_type = attr->prog_type;
d->verdict = verdict;
d->ktype = ktype;
d->serial = serial;
d->ret = ret;
bpf_ringbuf_submit(d, 0); /* record allow *and* deny */
}
return ret;
}
Observing a verified load: ``security_bpf_prog()``
--------------------------------------------------
There is deliberately no separate "metadata attested" hook. The coverage check
above is enforced by the kernel unconditionally, so a signed loader that fails
to cover its metadata never loads and an LSM never has to re-establish that
fact. To *act on* a program that has successfully and fully loaded, use the
existing ``security_bpf_prog()`` hook (``lsm/bpf_prog``), which fires from
``bpf_prog_new_fd()`` - after the verifier, after the coverage check, and after
``bpf_prog_alloc_id()``. Relative to the admission hook this point is strictly
later and stronger:
- the program has an id (``prog->aux->id``), so it can be recorded or correlated
with later events;
- ``verdict == BPF_SIG_VERIFIED`` *here* means **fully** verified - a program
that used a map the signature does not cover was already rejected, so it cannot
reach this point;
- it observes only programs that actually loaded; a failed load never mints an
fd, so it never reaches this hook.
It takes only the ``prog`` and a non-zero return still aborts (the fd is not
handed out), so it can veto as well as observe. One wrinkle: it also fires on
other paths that mint a new program fd - notably ``bpf_prog_get_fd_by_id()`` -
not just on a fresh load. Because the program already has its id here, an LSM
can tell the two apart with a small hash map: the *first* time an id is seen is
the load; a later sighting of the same id is just another fd to a program that
already exists.
To bound the map and let a reused id read as a fresh load, this can be paired
with ``security_bpf_prog_free()`` (``lsm/bpf_prog_free``), which deletes the
entry on teardown - keyed by the same ``prog`` pointer, since
``bpf_prog_free_id()`` has already cleared ``prog->aux->id`` to ``0`` by the time
that hook runs. (Illustrative - privileged LSM, error checking elided.)
.. code-block:: c
struct rec { __u32 id, ktype; __s32 serial; };
struct {
__uint(type, BPF_MAP_TYPE_HASH);
__type(key, __u64); /* struct bpf_prog * -- stable id */
__type(value, struct rec);
__uint(max_entries, 4096);
} live SEC(".maps");
SEC("lsm/bpf_prog") /* fires after load and on every later fd */
int BPF_PROG(observe, struct bpf_prog *prog)
{
__u64 key = (__u64)(unsigned long)prog;
struct rec r;
if (prog->aux->sig.verdict != BPF_SIG_VERIFIED)
return 0;
if (bpf_map_lookup_elem(&live, &key))
return 0; /* seen before: a later fd, not a load */
/* First sighting == this program just loaded; id is valid here. */
r.id = prog->aux->id;
r.ktype = prog->aux->sig.keyring_type;
r.serial = prog->aux->sig.keyring_serial;
bpf_map_update_elem(&live, &key, &r, BPF_NOEXIST);
/* ... newly-loaded verified-program action, e.g. record r.id ... */
return 0;
}
Putting them together: to *require* verified BPF, deny at the admission hook
unless the verdict is ``BPF_SIG_VERIFIED`` (and, if desired, restrict the
keyring). The kernel then guarantees that any program which actually loads with
that verdict covered all of its exclusive maps, rejecting any that did not - so
a deny-by-default admission policy needs no second enforcement point. Use
``security_bpf_prog()`` to record or finally gate the verified programs once
they carry an id. The ``verdict``, ``keyring_type`` and ``keyring_serial`` fields
let a policy distinguish, for example, "verified and signed by a builtin key"
from "verified by a user key". A policy LSM such as IPE could consume the same
hooks to enforce system policy without writing any BPF, though none implements
this today.
Keyrings
========
``keyring_id`` selects the trusted keyring the PKCS#7 signature is verified
against. The well-known ids ``0`` (builtin), ``VERIFY_USE_SECONDARY_KEYRING``
and ``VERIFY_USE_PLATFORM_KEYRING`` select the corresponding system keyrings;
any other value is treated as the serial of a user/session key or keyring.
The keyring is looked up first, before the signature bytes are examined, so a
signature naming a non-existent keyring is rejected up front, and a failed
verification aborts the load - so a program that loads successfully with a
signature always has consistent keyring fields recorded.
Two fields are recorded in ``prog->aux->sig`` for an LSM to inspect:
``keyring_type`` (``enum bpf_sig_keyring``)
Classified purely from ``keyring_id`` whenever the program is signed:
``BPF_SIG_KEYRING_BUILTIN``, ``_SECONDARY``, ``_PLATFORM`` for the system
keyrings, or ``_USER`` for a user/session keyring. It is
``BPF_SIG_KEYRING_NONE`` for an unsigned program.
``keyring_serial`` (``s32``)
Set **only** on a successful verification, to the serial of the
**user/session key or keyring** that ``keyring_id`` resolved to - the
object the signature was verified against, not the individual asymmetric
key inside it that matched the signer. Passing
``KEY_SPEC_SESSION_KEYRING``, for example, records the session keyring's
serial. The system keyrings are trusted as a whole and expose no serial
here, so the serial is ``0`` for builtin, secondary and platform
signatures, and ``0`` for unsigned programs. In other words, a non-zero
``keyring_serial`` is exactly "verified against the user key/keyring with
this serial".
.. list-table::
:header-rows: 1
* - ``keyring_id``
- ``keyring_type``
- ``keyring_serial``
* - (no signature)
- ``BPF_SIG_KEYRING_NONE``
- ``0``
* - ``0``
- ``BPF_SIG_KEYRING_BUILTIN``
- ``0``
* - ``VERIFY_USE_SECONDARY_KEYRING``
- ``BPF_SIG_KEYRING_SECONDARY``
- ``0``
* - ``VERIFY_USE_PLATFORM_KEYRING``
- ``BPF_SIG_KEYRING_PLATFORM``
- ``0``
* - other (a user/session key serial)
- ``BPF_SIG_KEYRING_USER``
- serial of the resolved key/keyring
Producing a signed object
==========================
``bpftool`` generates and signs a light skeleton in one step::
bpftool gen skeleton -L -S -k <private_key.pem> -i <certificate.x509> \
obj.bpf.o > obj.lskel.h
``-L`` selects the light-skeleton (``gen_loader``) backend and ``-S`` enables
signing; ``-k`` and ``-i`` supply the signing key and its X.509 certificate.
``bpftool`` signs ``insns || metadata`` - the exact bytes the kernel
reconstructs - and also computes ``excl_prog_hash`` as the digest of the loader
instructions so the metadata map can be bound to the loader. The signature and
hash are embedded in the generated header; the certificate is used only for
signing and is not included. Loading the skeleton performs the
create/populate/freeze/load sequence described above.
At runtime the trusted public key must be present in the chosen keyring (for
example added to the session keyring, or built into the kernel's builtin trusted
keyring) for verification to succeed.
UAPI reference
==============
``BPF_PROG_LOAD`` (``union bpf_attr``):
``signature``, ``signature_size``
Pointer to and length of the PKCS#7 signature blob.
``keyring_id``
Trusted keyring selector (see `Keyrings`_).
``fd_array``, ``fd_array_cnt``
Array of map (and module BTF) file descriptors bound to the program.
``fd_array_cnt`` must be set for the kernel to scan the array. When a
signature is present, a BTF entry is rejected outright, and every map must
be exclusive; its frozen contents are folded into the verified buffer, and
a non-exclusive entry is rejected.
``BPF_MAP_CREATE`` (``union bpf_attr``):
``excl_prog_hash``, ``excl_prog_hash_size``
SHA-256 digest of the program permitted to access this (exclusive) map. This
binds the metadata map to the loader; it is not a hash of the map *content*.
The map content is not hashed separately at all - it is covered, as bytes,
by the program signature.
Notes and limitations
======================
- The instructions plus folded metadata are verified as one ``bpf_dynptr``,
which bounds the combined size (currently ~16 MiB); very large objects can
exceed it.
- The metadata container is a single-element array map, accessed through
``map_direct_value_addr``.

6
Documentation/crypto/libcrypto-blockcipher.rst
View File

@ -6,14 +6,14 @@ Block ciphers
AES
---
Support for the AES block cipher.
This API provides support for the AES block cipher.
.. kernel-doc:: include/crypto/aes.h
DES
---
Support for the DES block cipher. This algorithm is obsolete and is supported
only for backwards compatibility.
This API provides support for the DES block cipher. This algorithm is obsolete
and is supported only for backwards compatibility.
.. kernel-doc:: include/crypto/des.h

38
Documentation/crypto/libcrypto-hash.rst
View File

@ -6,81 +6,83 @@ Hash functions, MACs, and XOFs
AES-CMAC and AES-XCBC-MAC
-------------------------
Support for the AES-CMAC and AES-XCBC-MAC message authentication codes.
This API provides support for the AES-CMAC and AES-XCBC-MAC message
authentication codes.
.. kernel-doc:: include/crypto/aes-cbc-macs.h
BLAKE2b
-------
Support for the BLAKE2b cryptographic hash function.
This API provides support for the BLAKE2b cryptographic hash function.
.. kernel-doc:: include/crypto/blake2b.h
BLAKE2s
-------
Support for the BLAKE2s cryptographic hash function.
This API provides support for the BLAKE2s cryptographic hash function.
.. kernel-doc:: include/crypto/blake2s.h
GHASH and POLYVAL
-----------------
Support for the GHASH and POLYVAL universal hash functions. These algorithms
are used only as internal components of other algorithms.
This API provides support for the GHASH and POLYVAL universal hash functions.
These algorithms are used only as internal components of other algorithms.
.. kernel-doc:: include/crypto/gf128hash.h
MD5
---
Support for the MD5 cryptographic hash function and HMAC-MD5. This algorithm is
obsolete and is supported only for backwards compatibility.
This API provides support for the MD5 cryptographic hash function and HMAC-MD5.
This algorithm is obsolete and is supported only for backwards compatibility.
.. kernel-doc:: include/crypto/md5.h
NH
--
Support for the NH universal hash function. This algorithm is used only as an
internal component of other algorithms.
This API provides support for the NH universal hash function. This algorithm is
used only as an internal component of other algorithms.
.. kernel-doc:: include/crypto/nh.h
Poly1305
--------
Support for the Poly1305 universal hash function. This algorithm is used only
as an internal component of other algorithms.
This API provides support for the Poly1305 universal hash function. This
algorithm is used only as an internal component of other algorithms.
.. kernel-doc:: include/crypto/poly1305.h
SHA-1
-----
Support for the SHA-1 cryptographic hash function and HMAC-SHA1. This algorithm
is obsolete and is supported only for backwards compatibility.
This API provides support for the SHA-1 cryptographic hash function and
HMAC-SHA1. This algorithm is obsolete and is supported only for backwards
compatibility.
.. kernel-doc:: include/crypto/sha1.h
SHA-2
-----
Support for the SHA-2 family of cryptographic hash functions, including SHA-224,
SHA-256, SHA-384, and SHA-512. This also includes their corresponding HMACs:
HMAC-SHA224, HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512.
This API provides support for the SHA-2 family of cryptographic hash functions,
including SHA-224, SHA-256, SHA-384, and SHA-512. This also includes their
corresponding HMACs: HMAC-SHA224, HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512.
.. kernel-doc:: include/crypto/sha2.h
SHA-3
-----
The SHA-3 functions are documented in :ref:`sha3`.
The SHA-3 API is documented in :ref:`sha3`.
SM3
---
Support for the SM3 cryptographic hash function.
This API provides support for the SM3 cryptographic hash function.
.. kernel-doc:: include/crypto/sm3.h

2
Documentation/crypto/libcrypto-signature.rst
View File

@ -6,6 +6,6 @@ Digital signature algorithms
ML-DSA
------
Support for the ML-DSA digital signature algorithm.
This API provides support for the ML-DSA digital signature algorithm.
.. kernel-doc:: include/crypto/mldsa.h

5
Documentation/crypto/libcrypto.rst
View File

@ -4,8 +4,9 @@
Crypto library
==============
``lib/crypto/`` provides faster and easier access to cryptographic algorithms
than the traditional crypto API.
The Linux kernel's crypto library (``lib/crypto/``) provides kernel-internal
users of cryptographic algorithms with faster and easier access to those
algorithms than the traditional kernel crypto API.
Each cryptographic algorithm is supported via a set of dedicated functions.
"Crypto agility", where needed, is left to calling code.

12
Documentation/devicetree/bindings/clock/amlogic,t7-peripherals-clkc.yaml
View File

@ -24,7 +24,7 @@ properties:
const: 1
clocks:
minItems: 14
minItems: 15
items:
- description: input oscillator
- description: input sys clk
@ -40,12 +40,13 @@ properties:
- description: input gp1 pll
- description: input mpll1
- description: input mpll2
- description: input mpll3
- description: external input rmii oscillator (optional)
- description: input video pll0 (optional)
- description: external pad input for rtc (optional)
clock-names:
minItems: 14
minItems: 15
items:
- const: xtal
- const: sys
@ -61,6 +62,7 @@ properties:
- const: gp1
- const: mpll1
- const: mpll2
- const: mpll3
- const: ext_rmii
- const: vid_pll0
- const: ext_rtc
@ -97,7 +99,8 @@ examples:
<&gp0 1>,
<&gp1 1>,
<&mpll 4>,
<&mpll 6>;
<&mpll 6>,
<&mpll 8>;
clock-names = "xtal",
"sys",
"fix",
@ -111,6 +114,7 @@ examples:
"gp0",
"gp1",
"mpll1",
"mpll2";
"mpll2",
"mpll3";
};
};

2
Documentation/devicetree/bindings/clock/amlogic,t7-pll-clkc.yaml
View File

@ -72,7 +72,7 @@ allOf:
contains:
enum:
- amlogic,t7-gp0-pll
- amlogic,t7-gp1--pll
- amlogic,t7-gp1-pll
- amlogic,t7-hifi-pll
- amlogic,t7-pcie-pll
- amlogic,t7-mpll

59
Documentation/devicetree/bindings/clock/canaan,k230-clk.yaml Normal file
View File

@ -0,0 +1,59 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/canaan,k230-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Canaan Kendryte K230 Clock
maintainers:
- Xukai Wang <kingxukai@zohomail.com>
description:
The Canaan K230 clock controller generates various clocks for SoC
peripherals. See include/dt-bindings/clock/canaan,k230-clk.h for
valid clock IDs.
properties:
compatible:
const: canaan,k230-clk
reg:
items:
- description: PLL control registers
- description: Sysclk control registers
clocks:
items:
- description: Main external reference clock
- description:
External clock which used as the pulse input
for the timer to provide timing signals.
clock-names:
items:
- const: osc24m
- const: timer-pulse-in
'#clock-cells':
const: 1
required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
additionalProperties: false
examples:
- |
clock-controller@91102000 {
compatible = "canaan,k230-clk";
reg = <0x91102000 0x40>,
<0x91100000 0x108>;
clocks = <&osc24m>, <&timerx_pulse_in>;
clock-names = "osc24m", "timer-pulse-in";
#clock-cells = <1>;
};

34
Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml
View File

@ -37,6 +37,9 @@ properties:
'#power-domain-cells':
const: 1
'#reset-cells':
const: 1
required:
- compatible
- reg
@ -44,16 +47,27 @@ required:
additionalProperties: false
if:
not:
properties:
compatible:
contains:
const: marvell,pxa1908-apmu
then:
properties:
'#power-domain-cells': false
allOf:
- if:
not:
properties:
compatible:
contains:
const: marvell,pxa1908-apmu
then:
properties:
'#power-domain-cells': false
- if:
not:
properties:
compatible:
contains:
enum:
- marvell,pxa1908-apbc
- marvell,pxa1908-apbcp
then:
properties:
'#reset-cells': false
examples:
# APMU block:

17
Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml
View File

@ -42,12 +42,6 @@ properties:
- const: cfg_ahb_clk
- const: gcc_disp_gpll0_div_clk_src
'#clock-cells':
const: 1
'#power-domain-cells':
const: 1
power-domains:
description:
A phandle and PM domain specifier for the CX power domain.
@ -58,18 +52,16 @@ properties:
A phandle to an OPP node describing the power domain's performance point.
maxItems: 1
reg:
maxItems: 1
required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
- '#power-domain-cells'
additionalProperties: false
allOf:
- $ref: qcom,gcc.yaml#
unevaluatedProperties: false
examples:
- |
@ -101,6 +93,7 @@ examples:
power-domains = <&rpmpd SM6125_VDDCX>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
...

63
Documentation/devicetree/bindings/clock/qcom,hawi-gcc.yaml Normal file
View File

@ -0,0 +1,63 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,hawi-gcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller on Hawi
maintainers:
- Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on Hawi.
See also: include/dt-bindings/clock/qcom,hawi-gcc.h
properties:
compatible:
const: qcom,hawi-gcc
clocks:
items:
- description: Board XO source
- description: Board Always On XO source
- description: Sleep clock source
- description: PCIE 0 Pipe clock source
- description: PCIE 1 Pipe clock source
- description: UFS PHY RX symbol 0 clock
- description: UFS PHY RX symbol 1 clock
- description: UFS PHY TX symbol 0 clock
- description: USB3 PHY wrapper pipe clock
required:
- compatible
- clocks
- '#power-domain-cells'
allOf:
- $ref: qcom,gcc.yaml#
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
clock-controller@100000 {
compatible = "qcom,hawi-gcc";
reg = <0x00100000 0x1f4200>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
<&rpmhcc RPMH_CXO_CLK_A>,
<&sleep_clk>,
<&pcie0_phy>,
<&pcie1_phy>,
<&ufs_mem_phy 0>,
<&ufs_mem_phy 1>,
<&ufs_mem_phy 2>,
<&usb_1_qmpphy>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
...

3
Documentation/devicetree/bindings/clock/qcom,ipq9574-cmn-pll.yaml
View File

@ -8,7 +8,7 @@ title: Qualcomm CMN PLL Clock Controller on IPQ SoC
maintainers:
- Bjorn Andersson <andersson@kernel.org>
- Luo Jie <quic_luoj@quicinc.com>
- Luo Jie <jie.luo@oss.qualcomm.com>
description:
The CMN (or common) PLL clock controller expects a reference
@ -25,6 +25,7 @@ properties:
compatible:
enum:
- qcom,ipq5018-cmn-pll
- qcom,ipq5332-cmn-pll
- qcom,ipq5424-cmn-pll
- qcom,ipq6018-cmn-pll
- qcom,ipq8074-cmn-pll

2
Documentation/devicetree/bindings/clock/qcom,kaanapali-gxclkctl.yaml
View File

@ -44,7 +44,7 @@ required:
- power-domains
- '#power-domain-cells'
unevaluatedProperties: false
additionalProperties: false
examples:
- |

8
Documentation/devicetree/bindings/clock/qcom,milos-camcc.yaml
View File

@ -25,6 +25,10 @@ properties:
- description: Sleep clock source
- description: Camera AHB clock from GCC
interconnects:
items:
- description: Interconnect path to enable the MultiMedia NoC
required:
- compatible
- clocks
@ -37,12 +41,16 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,milos-gcc.h>
#include <dt-bindings/interconnect/qcom,icc.h>
#include <dt-bindings/interconnect/qcom,milos-rpmh.h>
clock-controller@adb0000 {
compatible = "qcom,milos-camcc";
reg = <0x0adb0000 0x40000>;
clocks = <&bi_tcxo_div2>,
<&sleep_clk>,
<&gcc GCC_CAMERA_AHB_CLK>;
interconnects = <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
&mmss_noc SLAVE_MNOC_HF_MEM_NOC QCOM_ICC_TAG_ALWAYS>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;

61
Documentation/devicetree/bindings/clock/qcom,milos-gxclkctl.yaml Normal file
View File

@ -0,0 +1,61 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,milos-gxclkctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Graphics Power Domain Controller on Milos
maintainers:
- Luca Weiss <luca.weiss@fairphone.com>
description: |
Qualcomm GX(graphics) is a clock controller which has PLLs, clocks and
Power domains (GDSC). This module provides the power domains control
of gxclkctl on Qualcomm SoCs which helps the recovery of Graphics subsystem.
See also:
include/dt-bindings/clock/qcom,kaanapali-gxclkctl.h
properties:
compatible:
enum:
- qcom,milos-gxclkctl
reg:
maxItems: 1
power-domains:
description:
Power domains required for the clock controller to operate
items:
- description: GFX power domain
- description: GPUCC(CX) power domain
'#power-domain-cells':
const: 1
required:
- compatible
- reg
- power-domains
- '#power-domain-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/power/qcom,rpmhpd.h>
soc {
#address-cells = <2>;
#size-cells = <2>;
clock-controller@3d64000 {
compatible = "qcom,milos-gxclkctl";
reg = <0x0 0x03d64000 0x0 0x6000>;
power-domains = <&rpmhpd RPMHPD_GFX>,
<&gpucc 0>;
#power-domain-cells = <1>;
};
};
...

2
Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
View File

@ -8,7 +8,7 @@ title: Qualcomm NSS Clock & Reset Controller on QCA8386/QCA8084
maintainers:
- Bjorn Andersson <andersson@kernel.org>
- Luo Jie <quic_luoj@quicinc.com>
- Luo Jie <jie.luo@oss.qualcomm.com>
description: |
Qualcomm NSS clock control module provides the clocks and resets

1
Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
View File

@ -19,6 +19,7 @@ properties:
enum:
- qcom,eliza-rpmh-clk
- qcom,glymur-rpmh-clk
- qcom,hawi-rpmh-clk
- qcom,kaanapali-rpmh-clk
- qcom,milos-rpmh-clk
- qcom,nord-rpmh-clk

3
Documentation/devicetree/bindings/clock/qcom,sm8450-videocc.yaml
View File

@ -20,6 +20,7 @@ description: |
include/dt-bindings/clock/qcom,sm8450-videocc.h
include/dt-bindings/clock/qcom,sm8650-videocc.h
include/dt-bindings/clock/qcom,sm8750-videocc.h
include/dt-bindings/clock/qcom,x1p42100-videocc.h
properties:
compatible:
@ -32,6 +33,7 @@ properties:
- qcom,sm8650-videocc
- qcom,sm8750-videocc
- qcom,x1e80100-videocc
- qcom,x1p42100-videocc
clocks:
items:
@ -70,6 +72,7 @@ allOf:
- qcom,sm8450-videocc
- qcom,sm8550-videocc
- qcom,sm8750-videocc
- qcom,x1p42100-videocc
then:
required:
- required-opps

2
Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
View File

@ -17,6 +17,7 @@ description: |
See also:
- include/dt-bindings/clock/qcom,eliza-tcsr.h
- include/dt-bindings/clock/qcom,glymur-tcsr.h
- include/dt-bindings/clock/qcom,hawi-tcsrcc.h
- include/dt-bindings/clock/qcom,nord-tcsrcc.h
- include/dt-bindings/clock/qcom,sm8550-tcsr.h
- include/dt-bindings/clock/qcom,sm8650-tcsr.h
@ -28,6 +29,7 @@ properties:
- enum:
- qcom,eliza-tcsr
- qcom,glymur-tcsr
- qcom,hawi-tcsrcc
- qcom,kaanapali-tcsr
- qcom,milos-tcsr
- qcom,nord-tcsrcc

1
Documentation/devicetree/bindings/clock/qcom,x1e80100-camcc.yaml
View File

@ -23,6 +23,7 @@ properties:
compatible:
enum:
- qcom,x1e80100-camcc
- qcom,x1p42100-camcc
reg:
maxItems: 1

2
Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml
View File

@ -60,7 +60,7 @@ examples:
clock-output-names = "main", "pll0", "pll1", "pll2",
"pll2s", "pll2h", "z", "z2",
"i", "m3", "b", "m1", "m2",
"zx", "zs", "hp";
"zx", "zs", "hp", "ztr", "zt";
};
sdhi2_clk: sdhi2_clk@e615007c {

4
Documentation/devicetree/bindings/input/touchscreen/st,stmfts.yaml
View File

@ -40,6 +40,10 @@ properties:
vdd-supply:
description: Power supply
reset-gpios:
description: Reset GPIO (active-low)
maxItems: 1
required:
- compatible
- reg

73
Documentation/devicetree/bindings/input/touchscreen/wacom,w9007a-lt03.yaml Normal file
View File

@ -0,0 +1,73 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/touchscreen/wacom,w9007a-lt03.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Wacom W9000-series penabled I2C touchscreen
maintainers:
- Hendrik Noack <hendrik-noack@gmx.de>
description: |
The W9000-series are penabled touchscreen controllers by Wacom.
The firmware of controllers in different devices may differ. This can also
affect the controller's behavior.
allOf:
- $ref: touchscreen.yaml#
properties:
compatible:
enum:
- wacom,w9002
- wacom,w9007a-lt03
- wacom,w9007a-v1
reg:
maxItems: 1
interrupts:
maxItems: 1
vdd-supply: true
flash-mode-gpios:
maxItems: 1
reset-gpios:
maxItems: 1
required:
- compatible
- reg
- interrupts
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
digitizer@56 {
compatible = "wacom,w9007a-lt03";
reg = <0x56>;
interrupt-parent = <&gpd1>;
interrupts = <1 IRQ_TYPE_EDGE_RISING>;
vdd-supply = <&stylus_reg>;
flash-mode-gpios = <&gpd1 3 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpx0 1 GPIO_ACTIVE_LOW>;
touchscreen-x-mm = <216>;
touchscreen-y-mm = <135>;
touchscreen-inverted-x;
};
};

1
Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
View File

@ -28,7 +28,6 @@ properties:
fan-supply:
description: Phandle to the regulator that powers the fan.
$ref: /schemas/types.yaml#/definitions/phandle
required:
- compatible

29
Documentation/devicetree/bindings/mmc/mtk-sd.yaml
View File

@ -193,7 +193,6 @@ allOf:
- mediatek,mt8183-mmc
- mediatek,mt8186-mmc
- mediatek,mt8188-mmc
- mediatek,mt8189-mmc
- mediatek,mt8195-mmc
- mediatek,mt8196-mmc
- mediatek,mt8516-mmc
@ -348,6 +347,34 @@ allOf:
- const: axi_cg
- const: ahb_cg
- if:
properties:
compatible:
contains:
const: mediatek,mt8189-mmc
then:
properties:
clocks:
minItems: 6
items:
- description: source clock
- description: HCLK which used for host
- description: independent source clock gate
- description: bus clock used for internal register access
- description: peripheral bus clock gate
- description: AXI bus clock gate
- description: crypto clock used for data encrypt/decrypt (optional)
clock-names:
minItems: 6
items:
- const: source
- const: hclk
- const: source_cg
- const: bus_clk
- const: pclk_cg
- const: axi_cg
- const: crypto
unevaluatedProperties: false
examples:

2
Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml
View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm IPQ packet process engine (PPE)
maintainers:
- Luo Jie <quic_luoj@quicinc.com>
- Luo Jie <jie.luo@oss.qualcomm.com>
- Lei Wei <quic_leiwei@quicinc.com>
- Suruchi Agarwal <quic_suruchia@quicinc.com>
- Pavithra R <quic_pavir@quicinc.com>

3
Documentation/devicetree/bindings/net/renesas,ether.yaml
View File

@ -121,8 +121,7 @@ examples:
#size-cells = <0>;
phy1: ethernet-phy@1 {
compatible = "ethernet-phy-id0022.1537",
"ethernet-phy-ieee802.3-c22";
compatible = "ethernet-phy-id0022.1537";
reg = <1>;
interrupt-parent = <&irqc0>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;

32
Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
View File

@ -66,16 +66,34 @@ properties:
- const: dma
reset-gpio:
deprecated: true
description: Should specify the GPIO for controlling the PCI bus device
reset signal. It's not polarity aware and defaults to active-low reset
sequence (L=reset state, H=operation state) (optional required).
This property is deprecated, instead of referencing this property from the
host bridge node, use the reset-gpios property from the root port node.
reset-gpio-active-high:
deprecated: true
description: If present then the reset sequence using the GPIO
specified in the "reset-gpio" property is reversed (H=reset state,
L=operation state) (optional required).
This property is deprecated along with the reset-gpio property above, use
the reset-gpios property from the root port node.
type: boolean
pcie@0:
description:
Describe the i.MX6 PCIe Root Port.
type: object
$ref: /schemas/pci/pci-pci-bridge.yaml#
properties:
reg:
maxItems: 1
unevaluatedProperties: false
required:
- compatible
- reg
@ -236,6 +254,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/imx6qdl-clock.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
pcie: pcie@1ffc000 {
@ -262,5 +281,18 @@ examples:
<&clks IMX6QDL_CLK_LVDS1_GATE>,
<&clks IMX6QDL_CLK_PCIE_REF_125M>;
clock-names = "pcie", "pcie_bus", "pcie_phy";
pcie_port0: pcie@0 {
compatible = "pciclass,0604";
device_type = "pci";
reg = <0x0 0x0 0x0 0x0 0x0>;
bus-range = <0x01 0xff>;
#address-cells = <3>;
#size-cells = <2>;
ranges;
reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
};
};
...

9
Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
View File

@ -27,16 +27,20 @@ properties:
- const: snps,dw-pcie
reg:
minItems: 3
items:
- description: Controller control and status registers.
- description: PCIe configuration registers.
- description: Controller application registers.
- description: Internal Address Translation Unit (iATU) registers.
reg-names:
minItems: 3
items:
- const: dbi
- const: config
- const: app
- const: atu
ranges:
maxItems: 1
@ -95,8 +99,9 @@ examples:
#size-cells = <2>;
reg = <0xd0e00000 0x1000>,
<0xd2000000 0x800000>,
<0xd0a41000 0x1000>;
reg-names = "dbi", "config", "app";
<0xd0a41000 0x1000>,
<0xd0ec0000 0x1000>;
reg-names = "dbi", "config", "app", "atu";
linux,pci-domain = <0>;
max-link-speed = <4>;
bus-range = <0x00 0x08>;

26
Documentation/devicetree/bindings/pci/mediatek-pcie.yaml
View File

@ -14,6 +14,7 @@ properties:
oneOf:
- enum:
- airoha,an7583-pcie
- econet,en7528-pcie
- mediatek,mt2712-pcie
- mediatek,mt7622-pcie
- mediatek,mt7629-pcie
@ -226,6 +227,31 @@ allOf:
mediatek,pbus-csr: false
- if:
properties:
compatible:
contains:
const: econet,en7528-pcie
then:
properties:
clocks:
maxItems: 1
clock-names:
maxItems: 1
resets: false
reset-names: false
power-domains: false
mediatek,pbus-csr: false
required:
- phys
- phy-names
unevaluatedProperties: false
examples:

50
Documentation/devicetree/bindings/pci/qcom,pcie-sm8550.yaml
View File

@ -20,6 +20,7 @@ properties:
- const: qcom,pcie-sm8550
- items:
- enum:
- qcom,eliza-pcie
- qcom,kaanapali-pcie
- qcom,sar2130p-pcie
- qcom,pcie-sm8650
@ -91,6 +92,55 @@ required:
allOf:
- $ref: qcom,pcie-common.yaml#
- if:
properties:
compatible:
contains:
const: qcom,eliza-pcie
then:
properties:
reg:
minItems: 6
reg-names:
minItems: 6
- if:
properties:
compatible:
contains:
const: qcom,eliza-pcie
then:
properties:
clocks:
minItems: 8
maxItems: 8
clock-names:
minItems: 8
maxItems: 8
- if:
properties:
compatible:
contains:
const: qcom,eliza-pcie
then:
properties:
interrupts:
minItems: 9
interrupt-names:
minItems: 9
- if:
properties:
compatible:
contains:
const: qcom,eliza-pcie
then:
properties:
resets:
minItems: 2
reset-names:
minItems: 2
unevaluatedProperties: false

23
Documentation/devicetree/bindings/pci/renesas,r9a08g045-pcie.yaml
View File

@ -4,21 +4,27 @@
$id: http://devicetree.org/schemas/pci/renesas,r9a08g045-pcie.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/G3S PCIe host controller
title: Renesas RZ/G3S PCIe host controller (and similar SoCs)
maintainers:
- Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
description:
Renesas RZ/G3{E,S} PCIe host controllers comply with PCIe
Base Specification 4.0 and support up to 5 GT/s (Gen2) for RZ/G3S and
up to 8 GT/s (Gen3) for RZ/G3E.
description: |
PCIe host controller found in Renesas RZ/G3S and similar SoCs complies
with PCIe Base Specification 4.0 and supports different link speeds
depending on the SoC variant:
- Gen2 (5 GT/s): RZ/G3S
- Gen3 (8 GT/s): RZ/G3E, RZ/V2N
properties:
compatible:
enum:
- renesas,r9a08g045-pcie # RZ/G3S
- renesas,r9a09g047-pcie # RZ/G3E
oneOf:
- enum:
- renesas,r9a08g045-pcie # RZ/G3S
- renesas,r9a09g047-pcie # RZ/G3E
- items:
- const: renesas,r9a09g056-pcie # RZ/V2N
- const: renesas,r9a09g047-pcie
reg:
maxItems: 1
@ -152,6 +158,7 @@ patternProperties:
enum:
- 0x0033
- 0x0039
- 0x003b
clocks:
items:

3
Documentation/devicetree/bindings/pci/sophgo,sg2042-pcie-host.yaml
View File

@ -30,6 +30,8 @@ properties:
device-id:
const: 0x2042
dma-coherent: true
msi-parent: true
allOf:
@ -60,5 +62,6 @@ examples:
vendor-id = <0x1f1c>;
device-id = <0x2042>;
cdns,no-bar-match-nbits = <48>;
dma-coherent;
msi-parent = <&msi>;
};

93
Documentation/devicetree/bindings/pci/ultrarisc,dp1000-pcie.yaml Normal file
View File

@ -0,0 +1,93 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/pci/ultrarisc,dp1000-pcie.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: UltraRISC DP1000 PCIe Host Controller
description:
UltraRISC DP1000 SoC PCIe host controller is based on the DesignWare PCIe IP.
maintainers:
- Xincheng Zhang <zhangxincheng@ultrarisc.com>
- Jia Wang <wangjia@ultrarisc.com>
allOf:
- $ref: /schemas/pci/snps,dw-pcie.yaml#
properties:
compatible:
const: ultrarisc,dp1000-pcie
reg:
items:
- description: Data Bus Interface (DBI) registers.
- description: PCIe configuration space region.
reg-names:
items:
- const: dbi
- const: config
num-lanes:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [4, 16]
description: Number of lanes to use.
interrupts:
items:
- description: MSI interrupt
- description: Legacy INTA interrupt
- description: Legacy INTB interrupt
- description: Legacy INTC interrupt
- description: Legacy INTD interrupt
interrupt-names:
items:
- const: msi
- const: inta
- const: intb
- const: intc
- const: intd
required:
- compatible
- reg
- reg-names
- interrupts
- interrupt-names
unevaluatedProperties: false
examples:
- |
soc {
#address-cells = <2>;
#size-cells = <2>;
pcie@21000000 {
compatible = "ultrarisc,dp1000-pcie";
reg = <0x0 0x21000000 0x0 0x01000000>,
<0x0 0x4fff0000 0x0 0x00010000>;
reg-names = "dbi", "config";
ranges = <0x81000000 0x0 0x4fbf0000 0x0 0x4fbf0000 0x0 0x00400000>,
<0x82000000 0x0 0x40000000 0x0 0x40000000 0x0 0x0fbf0000>,
<0xc3000000 0x40 0x00000000 0x40 0x00000000 0xd 0x00000000>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
device_type = "pci";
dma-coherent;
bus-range = <0x0 0xff>;
num-lanes = <16>;
interrupt-parent = <&plic>;
interrupts = <43>, <44>, <45>, <46>, <47>;
interrupt-names = "msi", "inta", "intb", "intc", "intd";
interrupt-map-mask = <0x0 0x0 0x0 0x7>;
interrupt-map = <0x0 0x0 0x0 0x1 &plic 44>,
<0x0 0x0 0x0 0x2 &plic 45>,
<0x0 0x0 0x0 0x3 &plic 46>,
<0x0 0x0 0x0 0x4 &plic 47>;
};
};

44
Documentation/devicetree/bindings/regulator/sprd,sc2730-regulator.yaml Normal file
View File

@ -0,0 +1,44 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/regulator/sprd,sc2730-regulator.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Unisoc SC2730 Power Management IC regulators
maintainers:
- Otto Pflüger <otto.pflueger@abscue.de>
patternProperties:
"^dcdc-(core|cpu|gen[0-1]|gpu|mem|memq|modem|sram)$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
"^ldo-avdd(12|18)$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
"^ldo-vdd(18-dcxo|28)$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
"^ldo-vdd(emmccore|kpled|ldo[0-2]|sd(core|io)|sim[0-2]|usb33|wcn|wifipa)$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
"^ldo-vddcam(a0|a1|d0|d1|io|mot)$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
"^ldo-vddrf(1v25|18)$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
additionalProperties: false
...

184
Documentation/devicetree/bindings/riscv/extensions.yaml
View File

@ -457,6 +457,13 @@ properties:
merged in the riscv-isa-manual by commit dbc79cf28a2 ("Initial seed
of zc.adoc to src tree.").
- const: zclsd
description:
The Zclsd extension implements the compressed (16-bit) version of the
Load/Store Pair for RV32. As with Zilsd, this extension was ratified
in commit f88abf1 ("Integrating load/store pair for RV32 with the
main manual") of riscv-isa-manual.
- const: zcmop
description:
The standard Zcmop extension version 1.0, as ratified in commit
@ -487,6 +494,22 @@ properties:
in commit 64074bc ("Update version numbers for Zfh/Zfinx") of
riscv-isa-manual.
- const: zicbom
description:
The standard Zicbom extension for base cache management operations as
ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
- const: zicbop
description:
The standard Zicbop extension for cache-block prefetch instructions
as ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of
riscv-CMOs.
- const: zicboz
description:
The standard Zicboz extension for cache-block zeroing as ratified
in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
- const: ziccamoa
description:
The standard Ziccamoa extension for main memory (cacheability and
@ -514,6 +537,66 @@ properties:
guarantee on LR/SC sequences, as ratified in commit b1d806605f87
("Updated to ratified state.") of the riscv profiles specification.
- const: zicfilp
description: |
The standard Zicfilp extension for enforcing forward edge
control-flow integrity as ratified in commit 3f8e450 ("merge
pull request #227 from ved-rivos/0709") of riscv-cfi
github repo.
- const: zicfiss
description: |
The standard Zicfiss extension for enforcing backward edge
control-flow integrity as ratified in commit 3f8e450 ("merge
pull request #227 from ved-rivos/0709") of riscv-cfi
github repo.
- const: zicntr
description:
The standard Zicntr extension for base counters and timers, as
ratified in the 20191213 version of the unprivileged ISA
specification.
- const: zicond
description:
The standard Zicond extension for conditional arithmetic and
conditional-select/move operations as ratified in commit 95cf1f9
("Add changes requested by Ved during signoff") of riscv-zicond.
- const: zicsr
description: |
The standard Zicsr extension for control and status register
instructions, as ratified in the 20191213 version of the
unprivileged ISA specification.
This does not include Chapter 10, "Counters", which documents
special case read-only CSRs, that were moved into the Zicntr and
Zihpm extensions after the ratification of the 20191213 version of
the unprivileged specification.
- const: zifencei
description:
The standard Zifencei extension for instruction-fetch fence, as
ratified in the 20191213 version of the unprivileged ISA
specification.
- const: zihintntl
description:
The standard Zihintntl extension for non-temporal locality hints, as
ratified in commit 0dc91f5 ("Zihintntl is ratified") of the
riscv-isa-manual.
- const: zihintpause
description:
The standard Zihintpause extension for pause hints, as ratified in
commit d8ab5c7 ("Zihintpause is ratified") of the riscv-isa-manual.
- const: zihpm
description:
The standard Zihpm extension for hardware performance counters, as
ratified in the 20191213 version of the unprivileged ISA
specification.
- const: zilsd
description:
The standard Zilsd extension which provides support for aligned
@ -521,12 +604,10 @@ properties:
encodings, as ratified in commit f88abf1 ("Integrating
load/store pair for RV32 with the main manual") of riscv-isa-manual.
- const: zclsd
- const: zimop
description:
The Zclsd extension implements the compressed (16-bit) version of the
Load/Store Pair for RV32. As with Zilsd, this extension was ratified
in commit f88abf1 ("Integrating load/store pair for RV32 with the
main manual") of riscv-isa-manual.
The standard Zimop extension version 1.0, as ratified in commit
58220614a5f ("Zimop is ratified/1.0") of the riscv-isa-manual.
- const: zk
description:
@ -590,87 +671,6 @@ properties:
in version 1.0 of RISC-V Cryptography Extensions Volume I
specification.
- const: zicbom
description:
The standard Zicbom extension for base cache management operations as
ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
- const: zicbop
description:
The standard Zicbop extension for cache-block prefetch instructions
as ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of
riscv-CMOs.
- const: zicboz
description:
The standard Zicboz extension for cache-block zeroing as ratified
in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
- const: zicfilp
description: |
The standard Zicfilp extension for enforcing forward edge
control-flow integrity as ratified in commit 3f8e450 ("merge
pull request #227 from ved-rivos/0709") of riscv-cfi
github repo.
- const: zicfiss
description: |
The standard Zicfiss extension for enforcing backward edge
control-flow integrity as ratified in commit 3f8e450 ("merge
pull request #227 from ved-rivos/0709") of riscv-cfi
github repo.
- const: zicntr
description:
The standard Zicntr extension for base counters and timers, as
ratified in the 20191213 version of the unprivileged ISA
specification.
- const: zicond
description:
The standard Zicond extension for conditional arithmetic and
conditional-select/move operations as ratified in commit 95cf1f9
("Add changes requested by Ved during signoff") of riscv-zicond.
- const: zicsr
description: |
The standard Zicsr extension for control and status register
instructions, as ratified in the 20191213 version of the
unprivileged ISA specification.
This does not include Chapter 10, "Counters", which documents
special case read-only CSRs, that were moved into the Zicntr and
Zihpm extensions after the ratification of the 20191213 version of
the unprivileged specification.
- const: zifencei
description:
The standard Zifencei extension for instruction-fetch fence, as
ratified in the 20191213 version of the unprivileged ISA
specification.
- const: zihintpause
description:
The standard Zihintpause extension for pause hints, as ratified in
commit d8ab5c7 ("Zihintpause is ratified") of the riscv-isa-manual.
- const: zihintntl
description:
The standard Zihintntl extension for non-temporal locality hints, as
ratified in commit 0dc91f5 ("Zihintntl is ratified") of the
riscv-isa-manual.
- const: zihpm
description:
The standard Zihpm extension for hardware performance counters, as
ratified in the 20191213 version of the unprivileged ISA
specification.
- const: zimop
description:
The standard Zimop extension version 1.0, as ratified in commit
58220614a5f ("Zimop is ratified/1.0") of the riscv-isa-manual.
- const: ztso
description:
The standard Ztso extension for total store ordering, as ratified
@ -809,18 +809,18 @@ properties:
instructions, as ratified in commit 56ed795 ("Update
riscv-crypto-spec-vector.adoc") of riscv-crypto.
- const: zvksh
description: |
The standard Zvksh extension for ShangMi suite: SM3 secure hash
instructions, as ratified in commit 56ed795 ("Update
riscv-crypto-spec-vector.adoc") of riscv-crypto.
- const: zvksg
description:
The standard Zvksg extension for ShangMi algorithm suite with GCM
instructions, as ratified in commit 56ed795 ("Update
riscv-crypto-spec-vector.adoc") of riscv-crypto.
- const: zvksh
description: |
The standard Zvksh extension for ShangMi suite: SM3 secure hash
instructions, as ratified in commit 56ed795 ("Update
riscv-crypto-spec-vector.adoc") of riscv-crypto.
- const: zvkt
description:
The standard Zvkt extension for vector data-independent execution

39
Documentation/devicetree/bindings/rtc/epson,rx6110.txt
View File

@ -1,39 +0,0 @@
Epson RX6110 Real Time Clock
============================
The Epson RX6110 can be used with SPI or I2C busses. The kind of
bus depends on the SPISEL pin and can not be configured via software.
I2C mode
--------
Required properties:
- compatible: should be: "epson,rx6110"
- reg : the I2C address of the device for I2C
Example:
rtc: rtc@32 {
compatible = "epson,rx6110"
reg = <0x32>;
};
SPI mode
--------
Required properties:
- compatible: should be: "epson,rx6110"
- reg: chip select number
- spi-cs-high: RX6110 needs chipselect high
- spi-cpha: RX6110 works with SPI shifted clock phase
- spi-cpol: RX6110 works with SPI inverse clock polarity
Example:
rtc: rtc@3 {
compatible = "epson,rx6110"
reg = <3>
spi-cs-high;
spi-cpha;
spi-cpol;
};

68
Documentation/devicetree/bindings/rtc/epson,rx6110.yaml Normal file
View File

@ -0,0 +1,68 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/rtc/epson,rx6110.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Epson RX6110 Real Time Clock
description:
The Epson RX6110 can be used with SPI or I2C busses. The kind of bus depends
on the SPISEL pin and cannot be configured via software.
maintainers:
- Alexandre Belloni <alexandre.belloni@bootlin.com>
allOf:
- $ref: rtc.yaml#
- $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
compatible:
const: epson,rx6110
reg:
maxItems: 1
spi-cs-high: true
spi-cpha: true
spi-cpol: true
required:
- compatible
- reg
dependencies:
spi-cs-high: [ spi-cpha, spi-cpol ]
spi-cpha: [ spi-cs-high, spi-cpol ]
spi-cpol: [ spi-cs-high, spi-cpha ]
unevaluatedProperties: false
examples:
# I2C mode
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
rtc@32 {
compatible = "epson,rx6110";
reg = <0x32>;
};
};
# SPI mode
- |
spi {
#address-cells = <1>;
#size-cells = <0>;
rtc@3 {
compatible = "epson,rx6110";
reg = <3>;
spi-cs-high;
spi-cpha;
spi-cpol;
};
};

1
Documentation/devicetree/bindings/rtc/rtc-ds1307.yaml
View File

@ -31,6 +31,7 @@ properties:
- epson,rx8025
- isil,isl12057
- epson,rx8130
- epson,rx8901
- items:
- enum:

50
Documentation/devicetree/bindings/rtc/st,m41t93.yaml Normal file
View File

@ -0,0 +1,50 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/rtc/st,m41t93.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ST M41T93 RTC and compatible
maintainers:
- Akhilesh Patil <akhilesh@ee.iitb.ac.in>
description:
ST M41T93 is spi based Real Time Clock (RTC) with time, date,
alarm, watchdog, square wave clock output, 8 bit timer and
7 bytes of user SRAM.
properties:
compatible:
enum:
- st,m41t93
reg:
maxItems: 1
"#clock-cells":
const: 0
required:
- compatible
- reg
allOf:
- $ref: rtc.yaml
- $ref: /schemas/spi/spi-peripheral-props.yaml#
unevaluatedProperties: false
examples:
- |
spi {
#address-cells = <1>;
#size-cells = <0>;
rtc@0 {
compatible = "st,m41t93";
reg = <0>;
#clock-cells = <0>;
spi-max-frequency = <2000000>;
};
};

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

@ -30,6 +30,8 @@ properties:
- aspeed,ast2500-rtc
# ASPEED BMC ast2600 Real-time Clock
- aspeed,ast2600-rtc
# ASPEED BMC ast2700 Real-time Clock
- aspeed,ast2700-rtc
# Conexant Digicolor Real Time Clock Controller
- cnxt,cx92755-rtc
# I2C, 32-Bit Binary Counter Watchdog RTC with Trickle Charger and Reset Input/Output

1
Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml
View File

@ -21,6 +21,7 @@ properties:
- qcom,sc8280xp-lpass-rx-macro
- items:
- enum:
- qcom,eliza-lpass-rx-macro
- qcom,kaanapali-lpass-rx-macro
- qcom,sm8650-lpass-rx-macro
- qcom,sm8750-lpass-rx-macro

1
Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml
View File

@ -21,6 +21,7 @@ properties:
- qcom,sc8280xp-lpass-tx-macro
- items:
- enum:
- qcom,eliza-lpass-tx-macro
- qcom,kaanapali-lpass-tx-macro
- qcom,sm8650-lpass-tx-macro
- qcom,sm8750-lpass-tx-macro

1
Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml
View File

@ -21,6 +21,7 @@ properties:
- qcom,sc8280xp-lpass-va-macro
- items:
- enum:
- qcom,eliza-lpass-va-macro
- qcom,glymur-lpass-va-macro
- qcom,kaanapali-lpass-va-macro
- qcom,sm8650-lpass-va-macro

1
Documentation/devicetree/bindings/sound/qcom,lpass-wsa-macro.yaml
View File

@ -20,6 +20,7 @@ properties:
- qcom,sc8280xp-lpass-wsa-macro
- items:
- enum:
- qcom,eliza-lpass-wsa-macro
- qcom,glymur-lpass-wsa-macro
- qcom,kaanapali-lpass-wsa-macro
- qcom,sm8650-lpass-wsa-macro

1
Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
View File

@ -23,6 +23,7 @@ properties:
- const: qcom,sdm845-sndcard
- items:
- enum:
- qcom,eliza-sndcard
- qcom,kaanapali-sndcard
- qcom,sm8550-sndcard
- qcom,sm8650-sndcard

1
Documentation/devicetree/bindings/sound/realtek,rt5640.yaml
View File

@ -135,7 +135,6 @@ properties:
required:
- compatible
- reg
- interrupts
unevaluatedProperties: false

10
Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
View File

@ -50,10 +50,15 @@ properties:
- enum:
- mscc,ocelot-spi
- mscc,jaguar2-spi
- renesas,rzn1-spi
- sophgo,sg2042-spi
- thead,th1520-spi
- const: snps,dw-apb-ssi
- description: Vendor controllers which use snps,dwc-ssi-2.00a as fallback
items:
- enum:
- starfive,jhb100-spi
- const: snps,dwc-ssi-2.00a
- const: snps,dwc-ssi-1.01a
- description: Intel Keem Bay SPI Controller
const: intel,keembay-ssi
- description: Intel Mount Evans Integrated Management Complex SPI Controller
@ -88,6 +93,9 @@ properties:
- const: ssi_clk
- const: pclk
power-domains:
maxItems: 1
resets:
maxItems: 1

6
Documentation/devicetree/bindings/spi/spacemit,k1-spi.yaml
View File

@ -24,7 +24,11 @@ allOf:
properties:
compatible:
const: spacemit,k1-spi
oneOf:
- const: spacemit,k1-spi
- items:
- const: spacemit,k3-spi
- const: spacemit,k1-spi
reg:
maxItems: 1

1
Documentation/devicetree/bindings/spmi/qcom,glymur-spmi-pmic-arb.yaml
View File

@ -25,6 +25,7 @@ properties:
oneOf:
- items:
- enum:
- qcom,hawi-spmi-pmic-arb
- qcom,kaanapali-spmi-pmic-arb
- const: qcom,glymur-spmi-pmic-arb
- enum:

5
Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
View File

@ -87,9 +87,12 @@ examples:
amlogic,ao-secure = <&sec_AO>;
};
- |
#include <dt-bindings/clock/amlogic,t7-peripherals-clkc.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
temperature-sensor@20000 {
compatible = "amlogic,t7-thermal";
reg = <0x0 0x20000 0x0 0x50>;
reg = <0x20000 0x50>;
interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clkc_periphs CLKID_TS>;
#thermal-sensor-cells = <0>;

9
Documentation/devicetree/bindings/ufs/qcom,sa8255p-ufshc.yaml
View File

@ -18,7 +18,14 @@ properties:
- const: qcom,sa8255p-ufshc
reg:
maxItems: 1
minItems: 1
maxItems: 2
reg-names:
minItems: 1
items:
- const: std
- const: mcq
interrupts:
maxItems: 1

2
Documentation/driver-api/ipmi.rst
View File

@ -495,7 +495,7 @@ tuned to the user's desired performance.
The driver supports a hot add and remove of interfaces. This way,
interfaces can be added or removed after the kernel is up and running.
This is done using /sys/modules/ipmi_si/parameters/hotmod, which is a
This is done using /sys/module/ipmi_si/parameters/hotmod, which is a
write-only parameter. You write a string to this interface. The string
has the format::

4
Documentation/driver-api/uio-howto.rst
View File

@ -246,10 +246,10 @@ the members are required, others are optional.
hardware interrupt number. The flags given here will be used in the
call to :c:func:`request_irq()`.
- ``int (*mmap)(struct uio_info *info, struct vm_area_struct *vma)``:
- ``int (*mmap_prepare)(struct uio_info *info, struct vm_area_desc *desc)``:
Optional. If you need a special :c:func:`mmap()`
function, you can set it here. If this pointer is not NULL, your
:c:func:`mmap()` will be called instead of the built-in one.
``mmap_prepare`` will be called instead of the built-in one.
- ``int (*open)(struct uio_info *info, struct inode *inode)``:
Optional. You might want to have your own :c:func:`open()`,

2
Documentation/features/core/thread-info-in-task/arch-support.txt
View File

@ -12,7 +12,7 @@
| arm64: | ok |
| csky: | TODO |
| hexagon: | TODO |
| loongarch: | TODO |
| loongarch: | ok |
| m68k: | TODO |
| microblaze: | TODO |
| mips: | TODO |

4
Documentation/filesystems/smb/ksmbd.rst
View File

@ -97,7 +97,7 @@ ACLs Partially Supported. only DACLs available, SACLs
to allow future support for running as a domain
member.
Kerberos Supported.
Durable handle v1,v2 Planned for future.
Durable handle v1,v2 Supported.
Persistent handle Planned for future.
SMB2 notify Planned for future.
Sparse file support Supported.
@ -111,7 +111,7 @@ DCE/RPC support Partially Supported. a few calls(NetShareEnumAll,
for Witness protocol e.g.)
ksmbd/nfsd interoperability Planned for future. The features that ksmbd
support are Leases, Notify, ACLs and Share modes.
SMB3.1.1 Compression Planned for future.
SMB3.1.1 Compression Supported.
SMB3.1.1 over QUIC Planned for future.
Signing/Encryption over RDMA Planned for future.
SMB3.1.1 GMAC signing support Planned for future.

4
Documentation/hwmon/ltc4283.rst
View File

@ -256,7 +256,7 @@ these logs can be cleared by writing in the proper reset_history attribute.
``/sys/kernel/debug/i2c/i2c-[X]/[X]-addr/``
contains the following attributes:
======================= ==========================================
============================== ==========================================================
power1_failed_fault_log Set to 1 by a power1 fault occurring.
power1_good_input_fault_log Set to 1 by a power1 good input fault occurring at PGIO3.
in11_fet_short_fault_log Set to 1 when a FET-short fault occurs.
@ -264,4 +264,4 @@ in11_fet_bad_fault_log Set to 1 when a FET-BAD fault occurs.
in0_lcrit_fault_log Set to 1 by a VIN undervoltage fault occurring.
in0_crit_fault_log Set to 1 by a VIN overvoltage fault occurring.
curr1_crit_fault_log Set to 1 by an overcurrent fault occurring.
======================= ==========================================
============================== ==========================================================

25
Documentation/input/userio.rst
View File

@ -5,7 +5,7 @@ The userio Protocol
===================
:Copyright: |copy| 2015 Stephen Chandler Paul <thatslyude@gmail.com>
:Copyright: |copy| 2015 Lyude Paul <thatslyude@gmail.com>
Sponsored by Red Hat
@ -66,8 +66,27 @@ USERIO_CMD_SET_PORT_TYPE
~~~~~~~~~~~~~~~~~~~~~~~~
Sets the type of port we're emulating, where ``data`` is the port type being
set. Can be any of the macros from <linux/serio.h>. For example: SERIO_8042
would set the port type to be a normal PS/2 port.
set. Can be any of the serio type macros from <linux/serio.h>. For example:
SERIO_8042 would set the port type to be a normal PS/2 port.
USERIO_CMD_SET_PORT_PROTO
~~~~~~~~~~~~~~~~~~~~~~~~~
Sets the protocol of port we're emulating, where ``data`` is the protocol being
set. Can be any of the serio proto macros from <linux/serio.h>. For example:
SERIO_IFORCE would set the port type to be an I-Force serial joystick.
USERIO_CMD_SET_PORT_ID
~~~~~~~~~~~~~~~~~~~~~~
Sets the ``id`` value on the identification of port we're emulating, where
``data`` is the value being set.
USERIO_CMD_SET_PORT_EXTRA
~~~~~~~~~~~~~~~~~~~~~~~~~
Sets the ``extra`` value on the identification of port we're emulating, where
``data`` is the value being set.
USERIO_CMD_SEND_INTERRUPT
~~~~~~~~~~~~~~~~~~~~~~~~~

5
Documentation/kbuild/kconfig.rst
View File

@ -59,6 +59,11 @@ Environment variables for ``*config``:
This environment variable makes Kconfig warn about all unrecognized
symbols in the config input.
``KCONFIG_WARN_CHANGED_INPUT``
If set to a non-blank value, Kconfig prints optional warnings for
user-provided values that change after Kconfig resolves dependencies
or applies other constraints such as ranges.
``KCONFIG_WERROR``
If set, Kconfig treats warnings as errors.

13
Documentation/mm/index.rst
View File

@ -7,6 +7,19 @@ of Linux. If you are looking for advice on simply allocating memory,
see the :ref:`memory_allocation`. For controlling and tuning guides,
see the :doc:`admin guide <../admin-guide/mm/index>`.
.. note::
Unfortunately, parts of this guide are still incomplete or missing.
While we appreciate contributions, documentation in this area is hard
to get right and requires a lot of attention to detail. New contributors
should reach out to the relevant maintainers early.
This guide is expected to reflect reality, which requires contributors
to have a detailed understanding. Documentation generated with LLMs
by contributors unfamiliar with these details shifts the real work onto
reviewers, which is why such contributions will be rejected without
further comment.
.. toctree::
:maxdepth: 1

4
Documentation/netlink/specs/ovpn.yaml
View File

@ -118,12 +118,16 @@ attribute-sets:
doc: >-
The number of seconds after which a keep alive message is sent to the
peer
checks:
max: 86400
-
name: keepalive-timeout
type: u32
doc: >-
The number of seconds from the last activity after which the peer is
assumed dead
checks:
max: 86400
-
name: del-reason
type: u32

40
Documentation/netlink/specs/rt-link.yaml
View File

@ -1585,31 +1585,31 @@ attribute-sets:
type: u32
-
name: mode
type: flag
type: u8
-
name: guard
type: flag
type: u8
-
name: protect
type: flag
type: u8
-
name: fast-leave
type: flag
type: u8
-
name: learning
type: flag
type: u8
-
name: unicast-flood
type: flag
type: u8
-
name: proxyarp
type: flag
type: u8
-
name: learning-sync
type: flag
type: u8
-
name: proxyarp-wifi
type: flag
type: u8
-
name: root-id
type: binary
@ -1656,34 +1656,34 @@ attribute-sets:
type: pad
-
name: mcast-flood
type: flag
type: u8
-
name: mcast-to-ucast
type: flag
type: u8
-
name: vlan-tunnel
type: flag
type: u8
-
name: bcast-flood
type: flag
type: u8
-
name: group-fwd-mask
type: u16
-
name: neigh-suppress
type: flag
type: u8
-
name: isolated
type: flag
type: u8
-
name: backup-port
type: u32
-
name: mrp-ring-open
type: flag
type: u8
-
name: mrp-in-open
type: flag
type: u8
-
name: mcast-eht-hosts-limit
type: u32
@ -1692,10 +1692,10 @@ attribute-sets:
type: u32
-
name: locked
type: flag
type: u8
-
name: mab
type: flag
type: u8
-
name: mcast-n-groups
type: u32
@ -1704,7 +1704,7 @@ attribute-sets:
type: u32
-
name: neigh-vlan-suppress
type: flag
type: u8
-
name: backup-nhid
type: u32

54
Documentation/networking/af_xdp.rst
View File

@ -43,12 +43,13 @@ UMEM also has two rings: the FILL ring and the COMPLETION ring. The
FILL ring is used by the application to send down addr for the kernel
to fill in with RX packet data. References to these frames will then
appear in the RX ring once each packet has been received. The
COMPLETION ring, on the other hand, contains frame addr that the
kernel has transmitted completely and can now be used again by user
space, for either TX or RX. Thus, the frame addrs appearing in the
COMPLETION ring are addrs that were previously transmitted using the
TX ring. In summary, the RX and FILL rings are used for the RX path
and the TX and COMPLETION rings are used for the TX path.
COMPLETION ring, on the other hand, contains frame addresses from Tx
descriptors that the kernel has finished processing and that can now be
used again by user space, for either Tx or Rx. This includes frames whose
transmission has completed as well as frames referenced by invalid Tx
descriptors rejected by the kernel. A completion therefore returns
ownership of a frame to user space, but does not by itself guarantee that
the packet was successfully transmitted.
The socket is then finally bound with a bind() call to a device and a
specific queue id on that device, and it is not until bind is
@ -169,14 +170,15 @@ chunks mode, then the incoming addr will be left untouched.
UMEM Completion Ring
~~~~~~~~~~~~~~~~~~~~
The COMPLETION Ring is used transfer ownership of UMEM frames from
The COMPLETION Ring is used to transfer ownership of UMEM frames from
kernel-space to user-space. Just like the FILL ring, UMEM indices are
used.
Frames passed from the kernel to user-space are frames that has been
sent (TX ring) and can be used by user-space again.
The user application consumes UMEM addrs from this ring.
used. Frames passed from the kernel to user-space are frames referenced
by Tx descriptors that the kernel has finished processing and can be
used by user-space again. This includes both frames whose transmission
has completed and frames referenced by invalid Tx descriptors that were
rejected and reclaimed by the kernel. A completion entry does not
guarantee successful packet transmission. The user application consumes
UMEM addrs from this ring.
RX Ring
@ -504,21 +506,25 @@ will be treated as an invalid descriptor.
These are the semantics for producing packets onto AF_XDP Tx ring
consisting of multiple frames:
* When an invalid descriptor is found, all the other
descriptors/frames of this packet are marked as invalid and not
completed. The next descriptor is treated as the start of a new
packet, even if this was not the intent (because we cannot guess
the intent). As before, if your program is producing invalid
descriptors you have a bug that must be fixed.
* When an invalid descriptor is found, the complete packet is treated as
invalid. The kernel consumes descriptors through the descriptor marking
the end of the packet and returns all their frame addresses through the
COMPLETION ring. A standalone invalid descriptor is treated as a
one-descriptor invalid packet. The descriptor following the end of the
invalid packet is treated as the start of a new packet. As before, if
your program is producing invalid descriptors you have a bug that must
be fixed. Rejected descriptors are reported in the ``tx_invalid_descs``
statistic.
* Zero length descriptors are treated as invalid descriptors.
* For copy mode, the maximum supported number of frames in a packet is
equal to CONFIG_MAX_SKB_FRAGS + 1. If it is exceeded, all
descriptors accumulated so far are dropped and treated as
invalid. To produce an application that will work on any system
regardless of this config setting, limit the number of frags to 18,
as the minimum value of the config is 17.
equal to CONFIG_MAX_SKB_FRAGS + 1. If it is exceeded, all descriptors
through the end of the oversized packet are consumed, treated as invalid,
and their frame addresses are returned through the COMPLETION ring. To
produce an application that will work on any system regardless of this
config setting, limit the number of frags to 18, as the minimum value of
the config is 17.
* For zero-copy mode, the limit is up to what the NIC HW
supports. Usually at least five on the NICs we have checked. We

2
Documentation/networking/netdevices.rst
View File

@ -433,6 +433,8 @@ exceptions) notifiers run under the instance lock. Please extend this
documentation whenever you make explicit assumption about lock being held
from a notifier.
Drivers **must not** generate nested notifications of the ops-locked types.
NETDEV_INTERNAL symbol namespace
================================

5
Documentation/process/changes.rst
View File

@ -147,11 +147,6 @@ Since Linux 5.2, if CONFIG_DEBUG_INFO_BTF is selected, the build system
generates BTF (BPF Type Format) from DWARF in vmlinux, a bit later from kernel
modules as well. This requires pahole v1.22 or later.
Since Linux 7.0, kfuncs annotated with KF_IMPLICIT_ARGS require pahole v1.26
or later. Without it, such kfuncs will have incorrect BTF prototypes in
vmlinux, causing BPF programs to fail to load with a "func_proto incompatible
with vmlinux" error. Many sched_ext kfuncs are affected.
It is found in the 'dwarves' or 'pahole' distro packages or from
https://fedorapeople.org/~acme/dwarves/.

2
Documentation/process/debugging/kgdb.rst
View File

@ -513,7 +513,7 @@ unregister all the kernel hook points.
All kgdb I/O drivers can be reconfigured at run time, if
``CONFIG_SYSFS`` and ``CONFIG_MODULES`` are enabled, by echo'ing a new
config string to ``/sys/module/<driver>/parameter/<option>``. The driver
config string to ``/sys/module/<driver>/parameters/<option>``. The driver
can be unconfigured by passing an empty string. You cannot change the
configuration while the debugger is attached. Make sure to detach the
debugger with the ``detach`` command prior to trying to unconfigure a

2
Documentation/process/embargoed-hardware-issues.rst
View File

@ -308,7 +308,7 @@ an involved disclosed party. The current ambassadors list:
Google Kees Cook <keescook@chromium.org>
LLVM Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
LLVM Nick Desaulniers <ndesaulniers@google.com>
============= ========================================================
If you want your organization to be added to the ambassadors list, please

11
Documentation/sound/codecs/tas675x.rst
View File

@ -281,7 +281,7 @@ Global Temperature
:Description: Global die temperature sense register.
:Type: Integer (read-only)
:Range: 0 to 255
:Conversion: (value × 0.5 °C) − 50 °C
:Conversion: value × 2.19 K; subtract 273.15 for °C
:Register: 0x75
CHx Temperature Range
@ -289,10 +289,11 @@ CHx Temperature Range
:Description: Per-channel coarse temperature range indicator (x = 1, 2, 3, 4).
:Type: Integer (read-only)
:Range: 0 to 3
:Mapping: 0 = <80 °C, 1 = 80–100 °C, 2 = 100–120 °C, 3 = >120 °C
:Register: 0xBB bits [7:6] (CH1), bits [5:4] (CH2),
0xBC bits [3:2] (CH3), bits [1:0] (CH4)
:Range: 0 to 7
:Mapping: 0 = <95 °C, 1 = 95–110 °C, 2 = 110–125 °C, 3 = 125–135 °C,
4 = 135–145 °C, 5 = 145–155 °C, 6 = 155–165 °C, 7 = >165 °C
:Register: 0xBB bits [2:0] (CH1), bits [5:3] (CH2),
0xBC bits [2:0] (CH3), bits [5:3] (CH4)
Load Diagnostics
================

2
Documentation/tools/unittest.rst
View File

@ -11,7 +11,7 @@ While the actual test implementation is usecase dependent, Python already
provides a standard way to add unit tests by using ``import unittest``.
Using such class, requires setting up a test suite. Also, the default format
is a little bit ackward. To improve it and provide a more uniform way to
is a little bit awkward. To improve it and provide a more uniform way to
report errors, some unittest classes and functions are defined.

2
Documentation/trace/events.rst
View File

@ -1064,7 +1064,7 @@ correct command type, and a pointer to an event-specific run_command()
callback that will be called to actually execute the event-specific
command function.
Once that's done, the command string can by built up by successive
Once that's done, the command string can be built up by successive
calls to argument-adding functions.
To add a single argument, define and initialize a struct dynevent_arg

2
Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst
View File

@ -287,7 +287,7 @@ revelada involucrada. La lista de embajadores actuales:
Google Kees Cook <keescook@chromium.org>
LLVM Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
LLVM Nick Desaulniers <ndesaulniers@google.com>
============= ========================================================
Si quiere que su organización se añada a la lista de embajadores, por

8
Documentation/virt/kvm/api.rst
View File

@ -6840,7 +6840,7 @@ s390 specific.
} s390_ucontrol;
s390 specific. A page fault has occurred for a user controlled virtual
machine (KVM_VM_S390_UNCONTROL) on its host page table that cannot be
machine (KVM_VM_S390_UCONTROL) on its host page table that cannot be
resolved by the kernel.
The program code and the translation exception code that were placed
in the cpu's lowcore are presented here as defined by the z Architecture
@ -8414,6 +8414,12 @@ When this capability is enabled all memory in memslots must be mapped as
attempts to create a memslot with an invalid mmap will result in an
-EINVAL return.
``guest_memfd``, even though it is an anonymous file, is not supported with MTE.
Attempting to create a memslot backed by ``guest_memfd`` when the MTE capability
is enabled, or attempting to enable the MTE capability after
``guest_memfd``-backed memslots have been created, will result in an -EINVAL
return.
When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to
perform a bulk copy of tags to/from the guest.

15
Documentation/virt/kvm/devices/s390_flic.rst
View File

@ -112,9 +112,20 @@ Groups:
mask or unmask the adapter, as specified in mask
KVM_S390_IO_ADAPTER_MAP
This is now a no-op. The mapping is purely done by the irq route.
Map an adapter indicator or summary page for long-term pinning so that
interrupt injection can be performed in atomic context. If long-term
pinning is not possible (e.g. file-backed memory), the page is verified
via a short-term pin and the ioctl returns success; interrupt injection
will use the non-atomic irqfd path with short-term pinning on each
interrupt. In Secure Execution mode this is a no-op and the ioctl
returns success.
KVM_S390_IO_ADAPTER_UNMAP
This is now a no-op. The mapping is purely done by the irq route.
Unmap a previously mapped adapter indicator or summary page and release
the long-term pin. If the page was not long-term pinned (e.g. file-backed
memory), the map entry is removed and success is returned; if no prior
map entry exists, -ENOENT is returned. In Secure Execution mode this is
a no-op and the ioctl returns success.
KVM_DEV_FLIC_AISM
modify the adapter-interruption-suppression mode for a given isc if the

4
Documentation/watchdog/watchdog-parameters.rst
View File

@ -59,7 +59,7 @@ advantechwdt:
alim1535_wdt:
timeout:
Watchdog timeout in seconds. (0 < timeout < 18000, default=60
Watchdog timeout in seconds. (0 < timeout < 18000, default=60)
nowayout:
Watchdog cannot be stopped once started
(default=kernel config parameter)
@ -68,7 +68,7 @@ alim1535_wdt:
alim7101_wdt:
timeout:
Watchdog timeout in seconds. (1<=timeout<=3600, default=30
Watchdog timeout in seconds. (1<=timeout<=3600, default=30)
use_gpio:
Use the gpio watchdog (required by old cobalt boards).
default=0/off/no

127
MAINTAINERS
View File

@ -1987,6 +1987,7 @@ F: include/uapi/linux/apm_bios.h
APPARMOR SECURITY MODULE
M: John Johansen <john.johansen@canonical.com>
M: John Johansen <john@apparmor.net>
M: Georgia Garcia <georgia.garcia@canonical.com>
L: apparmor@lists.ubuntu.com (moderated for non-subscribers)
S: Supported
W: apparmor.net
@ -2675,6 +2676,8 @@ F: drivers/irqchip/irq-aspeed-i2c-ic.c
ARM/ASPEED MACHINE SUPPORT
M: Joel Stanley <joel@jms.id.au>
M: Andrew Jeffery <andrew@codeconstruct.com.au>
R: Ryan Chen <ryan_chen@aspeedtech.com>
R: Billy Tsai <billy_tsai@aspeedtech.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-aspeed@lists.ozlabs.org (moderated for non-subscribers)
S: Supported
@ -2766,12 +2769,12 @@ F: arch/arm/mach-ep93xx/
F: drivers/iio/adc/ep93xx_adc.c
ARM/CIX SOC SUPPORT
M: Peter Chen <peter.chen@cixtech.com>
M: Gary Yang <gary.yang@cixtech.com>
M: Fugang Duan <fugang.duan@cixtech.com>
R: CIX Linux Kernel Upstream Group <cix-kernel-upstream@cixtech.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/cix.git
T: git https://github.com/cixtech/linux-mainline.git
F: Documentation/devicetree/bindings/arm/cix.yaml
F: Documentation/devicetree/bindings/mailbox/cix,sky1-mbox.yaml
F: arch/arm64/boot/dts/cix/
@ -2880,7 +2883,7 @@ W: http://www.armlinux.org.uk/
F: arch/arm/include/asm/hardware/dec21285.h
F: arch/arm/mach-footbridge/
ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
ARM/FREESCALE IMX / MXC / LAYERSCAPE ARM ARCHITECTURE
M: Frank Li <Frank.Li@nxp.com>
M: Sascha Hauer <s.hauer@pengutronix.de>
R: Pengutronix Kernel Team <kernel@pengutronix.de>
@ -2894,22 +2897,11 @@ F: Documentation/devicetree/bindings/firmware/nxp*
F: arch/arm/boot/dts/nxp/
F: arch/arm64/boot/dts/freescale/
X: Documentation/devicetree/bindings/media/i2c/
X: arch/arm64/boot/dts/freescale/fsl-*
X: arch/arm64/boot/dts/freescale/qoriq-*
X: drivers/media/i2c/
N: imx
N: mxs
N: \bmxc[^\d]
ARM/FREESCALE LAYERSCAPE ARM ARCHITECTURE
M: Frank Li <Frank.Li@nxp.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git
F: arch/arm/boot/dts/nxp/ls/
F: arch/arm64/boot/dts/freescale/fsl-*
F: arch/arm64/boot/dts/freescale/qoriq-*
ARM/FREESCALE VYBRID ARM ARCHITECTURE
M: Frank Li <Frank.Li@nxp.com>
M: Sascha Hauer <s.hauer@pengutronix.de>
@ -4633,7 +4625,7 @@ F: rust/helpers/cpumask.c
BITMAP API [RUST]
M: Alice Ryhl <aliceryhl@google.com>
M: Burak Emir <bqe@google.com>
M: Burak Emir <burak.emir@gmail.com>
R: Yury Norov <yury.norov@gmail.com>
S: Maintained
F: lib/find_bit_benchmark_rust.rs
@ -4915,6 +4907,7 @@ R: Song Liu <song@kernel.org>
R: Yonghong Song <yonghong.song@linux.dev>
R: Jiri Olsa <jolsa@kernel.org>
R: Emil Tsalapatis <emil@etsalapatis.com>
R: Ihor Solodrai <ihor.solodrai@linux.dev>
L: bpf@vger.kernel.org
S: Supported
W: https://bpf.io/
@ -4975,6 +4968,7 @@ F: net/unix/unix_bpf.c
BPF [LIBRARY] (libbpf)
M: Andrii Nakryiko <andrii@kernel.org>
M: Eduard Zingerman <eddyz87@gmail.com>
R: Ihor Solodrai <ihor.solodrai@linux.dev>
L: bpf@vger.kernel.org
S: Maintained
F: tools/lib/bpf/
@ -5027,7 +5021,7 @@ F: kernel/bpf/ringbuf.c
BPF [SECURITY & LSM] (Security Audit and Enforcement using BPF)
M: KP Singh <kpsingh@kernel.org>
M: Matt Bobrowski <mattbobrowski@google.com>
M: Matt Bobrowski <matt@bobrowski.net>
L: bpf@vger.kernel.org
S: Maintained
F: Documentation/bpf/prog_lsm.rst
@ -5040,6 +5034,7 @@ F: security/bpf/
BPF [SELFTESTS] (Test Runners & Infrastructure)
M: Andrii Nakryiko <andrii@kernel.org>
M: Eduard Zingerman <eddyz87@gmail.com>
R: Ihor Solodrai <ihor.solodrai@linux.dev>
L: bpf@vger.kernel.org
S: Maintained
F: tools/testing/selftests/bpf/
@ -5054,6 +5049,7 @@ F: tools/bpf/bpftool/
BPF [TRACING]
M: Song Liu <song@kernel.org>
R: Jiri Olsa <jolsa@kernel.org>
R: Ihor Solodrai <ihor.solodrai@linux.dev>
L: bpf@vger.kernel.org
S: Maintained
F: kernel/bpf/stackmap.c
@ -6208,6 +6204,7 @@ F: include/dt-bindings/sound/cs*
F: include/linux/mfd/cs42l43*
F: include/sound/cs*
F: sound/hda/codecs/cirrus*
F: sound/hda/codecs/side-codecs/cirrus*
F: sound/hda/codecs/side-codecs/cs*
F: sound/hda/codecs/side-codecs/hda_component*
F: sound/soc/codecs/cs*
@ -6341,7 +6338,7 @@ F: .clang-format
CLANG/LLVM BUILD SUPPORT
M: Nathan Chancellor <nathan@kernel.org>
R: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
R: Nick Desaulniers <ndesaulniers@google.com>
R: Bill Wendling <morbo@google.com>
R: Justin Stitt <justinstitt@google.com>
L: llvm@lists.linux.dev
@ -6476,7 +6473,7 @@ L: linux-cifs@vger.kernel.org
L: samba-technical@lists.samba.org (moderated for non-subscribers)
S: Supported
W: https://wiki.samba.org/index.php/LinuxCIFS
T: git https://git.samba.org/sfrench/cifs-2.6.git
T: git https://git.samba.org/sfrench/cifs-2.6.git for-next
F: Documentation/admin-guide/cifs/
F: fs/smb/client/
F: fs/smb/common/
@ -7123,7 +7120,7 @@ W: https://docs.dasharo.com/
F: drivers/platform/x86/dasharo-acpi.c
DAMON
M: SeongJae Park <sj@kernel.org>
M: SJ Park <sj@kernel.org>
L: damon@lists.linux.dev
L: linux-mm@kvack.org
S: Maintained
@ -7738,7 +7735,7 @@ S: Maintained
P: Documentation/doc-guide/maintainer-profile.rst
T: git git://git.lwn.net/linux.git docs-next
F: Documentation/
F: tools/lib/python/*
F: tools/lib/python/
F: tools/docs/
F: tools/net/ynl/pyynl/lib/doc_generator.py
X: Documentation/ABI/
@ -9615,7 +9612,7 @@ M: Chao Yu <chao@kernel.org>
R: Yue Hu <zbestahu@gmail.com>
R: Jeffle Xu <jefflexu@linux.alibaba.com>
R: Sandeep Dhavale <dhavale@google.com>
R: Hongbo Li <lihongbo22@huawei.com>
R: Hongbo Li <hongbohbli@tencent.com>
R: Chunhai Guo <guochunhai@vivo.com>
L: linux-erofs@lists.ozlabs.org
S: Maintained
@ -11106,6 +11103,7 @@ F: drivers/platform/x86/gpd-pocket-fan.c
GPIB DRIVERS
M: Dave Penkler <dpenkler@gmail.com>
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
S: Maintained
F: drivers/gpib/
F: include/uapi/linux/gpib.h
@ -11740,6 +11738,7 @@ F: drivers/net/ethernet/hisilicon/hibmcge/
HISILICON NETWORK SUBSYSTEM DRIVER
M: Jian Shen <shenjian15@huawei.com>
M: Jijie Shao <shaojijie@huawei.com>
L: netdev@vger.kernel.org
S: Maintained
W: http://www.hisilicon.com
@ -14140,7 +14139,7 @@ R: Sergey Senozhatsky <senozhatsky@chromium.org>
R: Tom Talpey <tom@talpey.com>
L: linux-cifs@vger.kernel.org
S: Maintained
T: git https://git.samba.org/ksmbd.git
T: git https://git.samba.org/ksmbd.git ksmbd-for-next
F: Documentation/filesystems/smb/ksmbd.rst
F: fs/smb/common/
F: fs/smb/server/
@ -14190,6 +14189,7 @@ F: virt/kvm/*
KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
M: Marc Zyngier <maz@kernel.org>
M: Oliver Upton <oupton@kernel.org>
R: Fuad Tabba <fuad.tabba@linux.dev>
R: Joey Gouly <joey.gouly@arm.com>
R: Steffen Eiden <seiden@linux.ibm.com>
R: Suzuki K Poulose <suzuki.poulose@arm.com>
@ -14883,7 +14883,7 @@ X: drivers/macintosh/via-macii.c
LINUX FOR POWERPC (32-BIT AND 64-BIT)
M: Madhavan Srinivasan <maddy@linux.ibm.com>
M: Michael Ellerman <mpe@ellerman.id.au>
R: Michael Ellerman <mpe@ellerman.id.au>
R: Nicholas Piggin <npiggin@gmail.com>
R: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
L: linuxppc-dev@lists.ozlabs.org
@ -15737,8 +15737,8 @@ F: drivers/net/ethernet/marvell/octeon_ep_vf
MARVELL OCTEONTX2 PHYSICAL FUNCTION DRIVER
M: Sunil Goutham <sgoutham@marvell.com>
M: Geetha sowjanya <gakula@marvell.com>
M: Ratheesh Kannoth <rkannoth@marvell.com>
M: Subbaraya Sundeep <sbhatta@marvell.com>
M: hariprasad <hkelam@marvell.com>
M: Bharat Bhushan <bbhushan2@marvell.com>
L: netdev@vger.kernel.org
S: Maintained
@ -15747,9 +15747,8 @@ F: include/linux/soc/marvell/octeontx2/
MARVELL OCTEONTX2 RVU ADMIN FUNCTION DRIVER
M: Sunil Goutham <sgoutham@marvell.com>
M: Linu Cherian <lcherian@marvell.com>
M: Ratheesh Kannoth <rkannoth@marvell.com>
M: Geetha sowjanya <gakula@marvell.com>
M: hariprasad <hkelam@marvell.com>
M: Subbaraya Sundeep <sbhatta@marvell.com>
L: netdev@vger.kernel.org
S: Maintained
@ -15757,8 +15756,8 @@ F: Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst
F: drivers/net/ethernet/marvell/octeontx2/af/
MARVELL PEM PMU DRIVER
M: Linu Cherian <lcherian@marvell.com>
M: Gowthami Thiagarajan <gthiagarajan@marvell.com>
M: Geetha sowjanya <gakula@marvell.com>
S: Supported
F: drivers/perf/marvell_pem_pmu.c
@ -17157,7 +17156,7 @@ M: Andrew Morton <akpm@linux-foundation.org>
M: Vlastimil Babka <vbabka@kernel.org>
R: Suren Baghdasaryan <surenb@google.com>
R: Michal Hocko <mhocko@suse.com>
R: Brendan Jackman <jackmanb@google.com>
R: Brendan Jackman <brendan.jackman@linux.dev>
R: Johannes Weiner <hannes@cmpxchg.org>
R: Zi Yan <ziy@nvidia.com>
L: linux-mm@kvack.org
@ -17204,6 +17203,7 @@ R: Liam R. Howlett <liam@infradead.org>
R: Vlastimil Babka <vbabka@kernel.org>
R: Harry Yoo <harry@kernel.org>
R: Jann Horn <jannh@google.com>
R: Lance Yang <lance.yang@linux.dev>
L: linux-mm@kvack.org
S: Maintained
F: include/linux/rmap.h
@ -17249,11 +17249,12 @@ M: Lorenzo Stoakes <ljs@kernel.org>
R: Zi Yan <ziy@nvidia.com>
R: Baolin Wang <baolin.wang@linux.alibaba.com>
R: Liam R. Howlett <liam@infradead.org>
R: Nico Pache <npache@redhat.com>
R: Nico Pache <nico.pache@linux.dev>
R: Ryan Roberts <ryan.roberts@arm.com>
R: Dev Jain <dev.jain@arm.com>
R: Barry Song <baohua@kernel.org>
R: Lance Yang <lance.yang@linux.dev>
R: Usama Arif <usama.arif@linux.dev>
L: linux-mm@kvack.org
S: Maintained
W: http://www.linux-mm.org
@ -17841,7 +17842,7 @@ F: drivers/net/wireless/microchip/
MICROCHIP ZL3073X DRIVER
M: Ivan Vecera <ivecera@redhat.com>
M: Prathosh Satish <Prathosh.Satish@microchip.com>
M: Min Li <min.li@microchip.com>
L: netdev@vger.kernel.org
S: Supported
F: Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml
@ -18441,6 +18442,7 @@ F: drivers/net/ethernet/mucse/
MULTIFUNCTION DEVICES (MFD)
M: Lee Jones <lee@kernel.org>
L: mfd@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git
F: Documentation/devicetree/bindings/mfd/
@ -19104,6 +19106,7 @@ F: drivers/nfc/
F: include/net/nfc/
F: include/uapi/linux/nfc.h
F: net/nfc/
F: tools/testing/selftests/nci/
NFC VIRTUAL NCI DEVICE DRIVER
M: Bongsu Jeon <bongsu.jeon@samsung.com>
@ -19295,7 +19298,7 @@ F: fs/ntfs3/
NTSYNC SYNCHRONIZATION PRIMITIVE DRIVER
M: Elizabeth Figura <zfigura@codeweavers.com>
L: wine-devel@winehq.org
L: wine-devel@list.winehq.org
S: Supported
F: Documentation/userspace-api/ntsync.rst
F: drivers/misc/ntsync.c
@ -20193,7 +20196,7 @@ W: http://www.onsemi.com
F: drivers/net/phy/ncn*
OP-TEE DRIVER
M: Jens Wiklander <jens.wiklander@linaro.org>
M: Jens Wiklander <jenswi@kernel.org>
L: op-tee@lists.trustedfirmware.org (moderated for non-subscribers)
S: Maintained
F: Documentation/ABI/testing/sysfs-bus-optee-devices
@ -20404,7 +20407,7 @@ F: kernel/padata.c
PAGE CACHE
M: Matthew Wilcox (Oracle) <willy@infradead.org>
R: Jan Kara <jack@suse.cz>
M: Jan Kara <jack@suse.cz>
L: linux-fsdevel@vger.kernel.org
L: linux-mm@kvack.org
S: Supported
@ -20685,7 +20688,6 @@ F: include/linux/switchtec.h
F: include/uapi/linux/switchtec_ioctl.h
PCI DRIVER FOR MOBIVEIL PCIE IP
M: Karthikeyan Mitran <m.karthikeyan@mobiveil.co.in>
M: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
L: linux-pci@vger.kernel.org
S: Supported
@ -21049,6 +21051,14 @@ S: Maintained
F: Documentation/devicetree/bindings/pci/starfive,jh7110-pcie.yaml
F: drivers/pci/controller/plda/pcie-starfive.c
PCIE DRIVER FOR ULTRARISC DP1000
M: Xincheng Zhang <zhangxincheng@ultrarisc.com>
M: Jia Wang <wangjia@ultrarisc.com>
L: linux-pci@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/pci/ultrarisc,dp1000-pcie.yaml
F: drivers/pci/controller/dwc/pcie-ultrarisc.c
PCIE ENDPOINT DRIVER FOR QUALCOMM
M: Manivannan Sadhasivam <mani@kernel.org>
L: linux-pci@vger.kernel.org
@ -22314,9 +22324,9 @@ F: Documentation/devicetree/bindings/power/supply/qcom,pmi8998-charger.yaml
F: drivers/power/supply/qcom_smbx.c
QUALCOMM PPE DRIVER
M: Luo Jie <quic_luoj@quicinc.com>
M: Luo Jie <jie.luo@oss.qualcomm.com>
L: netdev@vger.kernel.org
S: Supported
S: Maintained
F: Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml
F: Documentation/networking/device_drivers/ethernet/qualcomm/ppe/ppe.rst
F: drivers/net/ethernet/qualcomm/ppe/
@ -22721,7 +22731,8 @@ F: drivers/watchdog/realtek_otto_wdt.c
REALTEK RTL83xx SMI DSA ROUTER CHIPS
M: Linus Walleij <linusw@kernel.org>
M: Alvin Šipraga <alsi@bang-olufsen.dk>
M: Luiz Angelo Daros de Luca <luizluca@gmail.com>
R: Alvin Šipraga <alvin.sipraga@analog.com>
S: Maintained
F: Documentation/devicetree/bindings/net/dsa/realtek.yaml
F: drivers/net/dsa/realtek/*
@ -23303,7 +23314,7 @@ L: spacemit@lists.linux.dev
S: Maintained
W: https://github.com/spacemit-com/linux/wiki
C: irc://irc.libera.chat/spacemit
T: git https://github.com/spacemit-com/linux
T: https://git.kernel.org/pub/scm/linux/kernel/git/spacemit/linux.git
F: arch/riscv/boot/dts/spacemit/
N: spacemit
K: spacemit
@ -23562,7 +23573,7 @@ F: Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-de2-rotate.yaml
F: drivers/media/platform/sunxi/sun8i-rotate/
RPMB SUBSYSTEM
M: Jens Wiklander <jens.wiklander@linaro.org>
M: Jens Wiklander <jenswi@kernel.org>
L: linux-kernel@vger.kernel.org
S: Supported
F: drivers/misc/rpmb-core.c
@ -24618,8 +24629,7 @@ SHARED MEMORY COMMUNICATIONS (SMC) SOCKETS
M: D. Wythe <alibuda@linux.alibaba.com>
M: Dust Li <dust.li@linux.alibaba.com>
M: Sidraya Jayagond <sidraya@linux.ibm.com>
M: Wenjia Zhang <wenjia@linux.ibm.com>
R: Mahanta Jambigi <mjambigi@linux.ibm.com>
M: Mahanta Jambigi <mjambigi@linux.ibm.com>
R: Tony Lu <tonylu@linux.alibaba.com>
R: Wen Gu <guwen@linux.alibaba.com>
L: linux-rdma@vger.kernel.org
@ -25368,6 +25378,7 @@ M: Bard Liao <yung-chuan.liao@linux.intel.com>
M: Daniel Baluta <daniel.baluta@nxp.com>
R: Kai Vehmanen <kai.vehmanen@linux.intel.com>
R: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
R: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
L: sound-open-firmware@alsa-project.org (moderated for non-subscribers)
S: Supported
W: https://github.com/thesofproject/linux/
@ -25414,6 +25425,12 @@ S: Maintained
F: Documentation/devicetree/bindings/i2c/spacemit,k1-i2c.yaml
F: drivers/i2c/busses/i2c-k1.c
SPACEMIT K1/K3 I2S DRIVER
M: Troy Mitchell <troy.mitchell@linux.spacemit.com>
S: Maintained
F: Documentation/devicetree/bindings/sound/spacemit,k1-i2s.yaml
F: sound/soc/spacemit/k1_i2s.c
SPANISH DOCUMENTATION
M: Carlos Bilbao <carlos.bilbao@kernel.org>
R: Avadhut Naik <avadhut.naik@amd.com>
@ -25959,8 +25976,9 @@ F: Documentation/devicetree/bindings/phy/st,stm32mp25-combophy.yaml
F: drivers/phy/st/phy-stm32-combophy.c
STMMAC ETHERNET DRIVER
M: Maxime Chevallier <maxime.chevallier@bootlin.com>
L: netdev@vger.kernel.org
S: Orphan
S: Maintained
F: Documentation/networking/device_drivers/ethernet/stmicro/
F: drivers/net/ethernet/stmicro/stmmac/
@ -25992,9 +26010,8 @@ S: Maintained
F: drivers/net/ethernet/dlink/sundance.c
SUNPLUS ETHERNET DRIVER
M: Wells Lu <wellslutw@gmail.com>
L: netdev@vger.kernel.org
S: Maintained
S: Orphan
W: https://sunplus.atlassian.net/wiki/spaces/doc/overview
F: Documentation/devicetree/bindings/net/sunplus,sp7021-emac.yaml
F: drivers/net/ethernet/sunplus/
@ -26516,7 +26533,7 @@ F: drivers/media/i2c/tw9910.c
F: include/media/i2c/tw9910.h
TEE SUBSYSTEM
M: Jens Wiklander <jens.wiklander@linaro.org>
M: Jens Wiklander <jenswi@kernel.org>
R: Sumit Garg <sumit.garg@kernel.org>
L: op-tee@lists.trustedfirmware.org (moderated for non-subscribers)
S: Maintained
@ -27512,7 +27529,7 @@ F: drivers/net/ethernet/dec/tulip/
TUN/TAP DRIVER
M: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
M: Jason Wang <jasowang@redhat.com>
M: Jason Wang <jasowangio@gmail.com>
S: Maintained
W: http://vtun.sourceforge.net/tun
F: Documentation/networking/tuntap.rst
@ -27917,7 +27934,6 @@ F: drivers/usb/isp1760/*
USB LAN78XX ETHERNET DRIVER
M: Thangaraj Samynathan <Thangaraj.S@microchip.com>
M: Rengarajan Sundararajan <Rengarajan.S@microchip.com>
M: UNGLinuxDriver@microchip.com
L: netdev@vger.kernel.org
S: Maintained
@ -28045,6 +28061,7 @@ F: include/dt-bindings/usb/
F: include/linux/usb.h
F: include/linux/usb/
F: include/uapi/linux/usb/
F: rust/kernel/usb.rs
USB TYPEC BUS FOR ALTERNATE MODES
M: Heikki Krogerus <heikki.krogerus@linux.intel.com>
@ -28504,7 +28521,7 @@ F: include/uapi/linux/virtio_balloon.h
VIRTIO BLOCK AND SCSI DRIVERS
M: "Michael S. Tsirkin" <mst@redhat.com>
M: Jason Wang <jasowang@redhat.com>
M: Jason Wang <jasowangio@gmail.com>
R: Paolo Bonzini <pbonzini@redhat.com>
R: Stefan Hajnoczi <stefanha@redhat.com>
R: Eugenio Pérez <eperezma@redhat.com>
@ -28533,7 +28550,7 @@ F: include/uapi/linux/virtio_console.h
VIRTIO CORE
M: "Michael S. Tsirkin" <mst@redhat.com>
M: Jason Wang <jasowang@redhat.com>
M: Jason Wang <jasowangio@gmail.com>
R: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
R: Eugenio Pérez <eperezma@redhat.com>
L: virtualization@lists.linux.dev
@ -28611,7 +28628,7 @@ F: include/uapi/linux/virtio_gpu.h
VIRTIO HOST (VHOST)
M: "Michael S. Tsirkin" <mst@redhat.com>
M: Jason Wang <jasowang@redhat.com>
M: Jason Wang <jasowangio@gmail.com>
R: Eugenio Pérez <eperezma@redhat.com>
L: kvm@vger.kernel.org
L: virtualization@lists.linux.dev
@ -28626,7 +28643,7 @@ F: kernel/vhost_task.c
VIRTIO HOST (VHOST-SCSI)
M: "Michael S. Tsirkin" <mst@redhat.com>
M: Jason Wang <jasowang@redhat.com>
M: Jason Wang <jasowangio@gmail.com>
M: Mike Christie <michael.christie@oracle.com>
R: Paolo Bonzini <pbonzini@redhat.com>
R: Stefan Hajnoczi <stefanha@redhat.com>
@ -28666,7 +28683,7 @@ F: include/uapi/linux/virtio_mem.h
VIRTIO NET DRIVER
M: "Michael S. Tsirkin" <mst@redhat.com>
M: Jason Wang <jasowang@redhat.com>
M: Jason Wang <jasowangio@gmail.com>
R: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
R: Eugenio Pérez <eperezma@redhat.com>
L: netdev@vger.kernel.org
@ -28717,7 +28734,7 @@ F: include/linux/vbox_utils.h
F: include/uapi/linux/vbox*.h
VIRTUAL BOX SHARED FOLDER VFS DRIVER
M: Hans de Goede <hansg@kernel.org>
M: Jori Koolstra <jkoolstra@xs4all.nl>
L: linux-fsdevel@vger.kernel.org
S: Maintained
F: fs/vboxsf/*
@ -28731,7 +28748,7 @@ F: sound/drivers/pcmtest.c
F: tools/testing/selftests/alsa/test-pcmtest-driver.c
VIRTUAL SERIO DEVICE DRIVER
M: Stephen Chandler Paul <thatslyude@gmail.com>
M: Lyude Paul <thatslyude@gmail.com>
S: Maintained
F: drivers/input/serio/userio.c
F: include/uapi/linux/userio.h
@ -29385,7 +29402,7 @@ F: net/xdp/
F: tools/testing/selftests/bpf/*xsk*
XEN BLOCK SUBSYSTEM
M: Roger Pau Monné <roger.pau@citrix.com>
M: Roger Pau Monné <roger@xenproject.org>
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
S: Supported
F: drivers/block/xen*

23
Makefile
View File

@ -1,8 +1,8 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 7
PATCHLEVEL = 1
PATCHLEVEL = 2
SUBLEVEL = 0
EXTRAVERSION =
EXTRAVERSION = -rc6
NAME = Baby Opossum Posse
# *DOCUMENTATION*
@ -475,6 +475,10 @@ KBUILD_USERLDFLAGS := $(USERLDFLAGS)
# These flags apply to all Rust code in the tree, including the kernel and
# host programs.
#
# `-Aclippy::unwrap_or_default`: the lint is buggy [1] and ignores our
# MSRV. It can trigger depending on the optimization level.
# [1] https://github.com/rust-lang/rust-clippy/issues/17379
export rust_common_flags := --edition=2021 \
-Zbinary_dep_depinfo=y \
-Astable_features \
@ -503,6 +507,7 @@ export rust_common_flags := --edition=2021 \
-Aclippy::uninlined_format_args \
-Wclippy::unnecessary_safety_comment \
-Wclippy::unnecessary_safety_doc \
-Aclippy::unwrap_or_default \
-Wrustdoc::missing_crate_level_docs \
-Wrustdoc::unescaped_backticks
@ -528,6 +533,9 @@ OBJCOPY = $(LLVM_PREFIX)llvm-objcopy$(LLVM_SUFFIX)
OBJDUMP = $(LLVM_PREFIX)llvm-objdump$(LLVM_SUFFIX)
READELF = $(LLVM_PREFIX)llvm-readelf$(LLVM_SUFFIX)
STRIP = $(LLVM_PREFIX)llvm-strip$(LLVM_SUFFIX)
ifeq ($(filter -fuse-ld=% --ld-path=%,$(KBUILD_HOSTLDFLAGS)),)
KBUILD_HOSTLDFLAGS += -fuse-ld=lld
endif
else
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)ld
@ -692,13 +700,11 @@ filechk_makefile = { \
echo "include $(abs_srctree)/Makefile"; \
}
$(objtree)/Makefile: FORCE
PHONY += $(CURDIR)/Makefile
$(CURDIR)/Makefile: FORCE
$(call filechk,makefile)
# Prevent $(srcroot)/Makefile from inhibiting the rule to run.
PHONY += $(objtree)/Makefile
outputmakefile: $(objtree)/Makefile
outputmakefile: $(CURDIR)/Makefile
ifeq ($(KBUILD_EXTMOD),)
@if [ -f $(srctree)/.config -o \
-d $(srctree)/include/config -o \
@ -961,6 +967,9 @@ KBUILD_CFLAGS += $(stackp-flags-y)
ifdef CONFIG_FRAME_POINTER
KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls
KBUILD_RUSTFLAGS += -Cforce-frame-pointers=y
# Work around rustc bug on compilers without
# https://github.com/rust-lang/rust/pull/156980.
KBUILD_RUSTFLAGS += $(if $(call rustc-min-version,109800),,-Zllvm_module_flag=frame-pointer:u32:2:max)
else
# Some targets (ARM with Thumb2, for example), can't be built with frame
# pointers. For those, we don't have FUNCTION_TRACER automatically

13
arch/alpha/include/asm/pci.h
View File

@ -84,8 +84,17 @@ extern int pci_legacy_write(struct pci_bus *bus, loff_t port, u32 val,
extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
struct vm_area_struct *vma,
enum pci_mmap_state mmap_state);
extern void pci_adjust_legacy_attr(struct pci_bus *bus,
enum pci_mmap_state mmap_type);
extern bool pci_legacy_has_sparse(struct pci_bus *bus,
enum pci_mmap_state type);
#define HAVE_PCI_LEGACY 1
extern const struct attribute_group pci_dev_resource_attr_group;
extern const struct attribute_group pci_dev_resource_sparse_attr_group;
extern const struct attribute_group pci_dev_resource_dense_attr_group;
#define ARCH_PCI_DEV_GROUPS \
&pci_dev_resource_attr_group, \
&pci_dev_resource_sparse_attr_group, \
&pci_dev_resource_dense_attr_group,
#endif /* __ALPHA_PCI_H */

388
arch/alpha/kernel/pci-sysfs.c
View File

@ -11,8 +11,7 @@
*/
#include <linux/sched.h>
#include <linux/stat.h>
#include <linux/slab.h>
#include <linux/security.h>
#include <linux/pci.h>
static int hose_mmap_page_range(struct pci_controller *hose,
@ -36,20 +35,18 @@ static int hose_mmap_page_range(struct pci_controller *hose,
static int __pci_mmap_fits(struct pci_dev *pdev, int num,
struct vm_area_struct *vma, int sparse)
{
resource_size_t len = pci_resource_len(pdev, num);
unsigned long nr, start, size;
int shift = sparse ? 5 : 0;
if (!len)
return 0;
nr = vma_pages(vma);
start = vma->vm_pgoff;
size = ((pci_resource_len(pdev, num) - 1) >> (PAGE_SHIFT - shift)) + 1;
size = ((len - 1) >> (PAGE_SHIFT - shift)) + 1;
if (start < size && size - start >= nr)
return 1;
WARN(1, "process \"%s\" tried to map%s 0x%08lx-0x%08lx on %s BAR %d "
"(size 0x%08lx)\n",
current->comm, sparse ? " sparse" : "", start, start + nr,
pci_name(pdev), num, size);
return 0;
return start < size && size - start >= nr;
}
/**
@ -68,26 +65,25 @@ static int pci_mmap_resource(struct kobject *kobj,
struct vm_area_struct *vma, int sparse)
{
struct pci_dev *pdev = to_pci_dev(kobj_to_dev(kobj));
struct resource *res = attr->private;
int barno = (unsigned long)attr->private;
enum pci_mmap_state mmap_type;
struct pci_bus_region bar;
int i;
int ret;
for (i = 0; i < PCI_STD_NUM_BARS; i++)
if (res == &pdev->resource[i])
break;
if (i >= PCI_STD_NUM_BARS)
return -ENODEV;
ret = security_locked_down(LOCKDOWN_PCI_ACCESS);
if (ret)
return ret;
if (res->flags & IORESOURCE_MEM && iomem_is_exclusive(res->start))
if (pci_resource_is_mem(pdev, barno) &&
iomem_is_exclusive(pci_resource_start(pdev, barno)))
return -EINVAL;
if (!__pci_mmap_fits(pdev, i, vma, sparse))
if (!__pci_mmap_fits(pdev, barno, vma, sparse))
return -EINVAL;
pcibios_resource_to_bus(pdev->bus, &bar, res);
pcibios_resource_to_bus(pdev->bus, &bar, pci_resource_n(pdev, barno));
vma->vm_pgoff += bar.start >> (PAGE_SHIFT - (sparse ? 5 : 0));
mmap_type = res->flags & IORESOURCE_MEM ? pci_mmap_mem : pci_mmap_io;
mmap_type = pci_resource_is_mem(pdev, barno) ? pci_mmap_mem : pci_mmap_io;
return hose_mmap_page_range(pdev->sysdata, vma, mmap_type, sparse);
}
@ -106,34 +102,26 @@ static int pci_mmap_resource_dense(struct file *filp, struct kobject *kobj,
return pci_mmap_resource(kobj, attr, vma, 0);
}
/**
* pci_remove_resource_files - cleanup resource files
* @pdev: pci_dev to cleanup
*
* If we created resource files for @dev, remove them from sysfs and
* free their resources.
*/
void pci_remove_resource_files(struct pci_dev *pdev)
{
int i;
for (i = 0; i < PCI_STD_NUM_BARS; i++) {
struct bin_attribute *res_attr;
res_attr = pdev->res_attr[i];
if (res_attr) {
sysfs_remove_bin_file(&pdev->dev.kobj, res_attr);
kfree(res_attr);
}
res_attr = pdev->res_attr_wc[i];
if (res_attr) {
sysfs_remove_bin_file(&pdev->dev.kobj, res_attr);
kfree(res_attr);
}
}
#define __pci_dev_resource_attr(_bar, _name, _suffix, _mmap) \
static const struct bin_attribute \
pci_dev_resource##_bar##_suffix##_attr = { \
.attr = { .name = __stringify(_name), .mode = 0600 }, \
.private = (void *)(unsigned long)(_bar), \
.mmap = (_mmap), \
}
#define pci_dev_resource_attr(_bar) \
__pci_dev_resource_attr(_bar, resource##_bar,, \
pci_mmap_resource_dense)
#define pci_dev_resource_sparse_attr(_bar) \
__pci_dev_resource_attr(_bar, resource##_bar##_sparse, _sparse, \
pci_mmap_resource_sparse)
#define pci_dev_resource_dense_attr(_bar) \
__pci_dev_resource_attr(_bar, resource##_bar##_dense, _dense, \
pci_mmap_resource_dense)
static int sparse_mem_mmap_fits(struct pci_dev *pdev, int num)
{
struct pci_bus_region bar;
@ -141,7 +129,7 @@ static int sparse_mem_mmap_fits(struct pci_dev *pdev, int num)
long dense_offset;
unsigned long sparse_size;
pcibios_resource_to_bus(pdev->bus, &bar, &pdev->resource[num]);
pcibios_resource_to_bus(pdev->bus, &bar, pci_resource_n(pdev, num));
/* All core logic chips have 4G sparse address space, except
CIA which has 16G (see xxx_SPARSE_MEM and xxx_DENSE_MEM
@ -153,109 +141,10 @@ static int sparse_mem_mmap_fits(struct pci_dev *pdev, int num)
return bar.end < sparse_size;
}
static int pci_create_one_attr(struct pci_dev *pdev, int num, char *name,
char *suffix, struct bin_attribute *res_attr,
unsigned long sparse)
{
size_t size = pci_resource_len(pdev, num);
sprintf(name, "resource%d%s", num, suffix);
res_attr->mmap = sparse ? pci_mmap_resource_sparse :
pci_mmap_resource_dense;
res_attr->attr.name = name;
res_attr->attr.mode = S_IRUSR | S_IWUSR;
res_attr->size = sparse ? size << 5 : size;
res_attr->private = &pdev->resource[num];
return sysfs_create_bin_file(&pdev->dev.kobj, res_attr);
}
static int pci_create_attr(struct pci_dev *pdev, int num)
{
/* allocate attribute structure, piggyback attribute name */
int retval, nlen1, nlen2 = 0, res_count = 1;
unsigned long sparse_base, dense_base;
struct bin_attribute *attr;
struct pci_controller *hose = pdev->sysdata;
char *suffix, *attr_name;
suffix = ""; /* Assume bwx machine, normal resourceN files. */
nlen1 = 10;
if (pdev->resource[num].flags & IORESOURCE_MEM) {
sparse_base = hose->sparse_mem_base;
dense_base = hose->dense_mem_base;
if (sparse_base && !sparse_mem_mmap_fits(pdev, num)) {
sparse_base = 0;
suffix = "_dense";
nlen1 = 16; /* resourceN_dense */
}
} else {
sparse_base = hose->sparse_io_base;
dense_base = hose->dense_io_base;
}
if (sparse_base) {
suffix = "_sparse";
nlen1 = 17;
if (dense_base) {
nlen2 = 16; /* resourceN_dense */
res_count = 2;
}
}
attr = kzalloc(sizeof(*attr) * res_count + nlen1 + nlen2, GFP_ATOMIC);
if (!attr)
return -ENOMEM;
/* Create bwx, sparse or single dense file */
attr_name = (char *)(attr + res_count);
pdev->res_attr[num] = attr;
retval = pci_create_one_attr(pdev, num, attr_name, suffix, attr,
sparse_base);
if (retval || res_count == 1)
return retval;
/* Create dense file */
attr_name += nlen1;
attr++;
pdev->res_attr_wc[num] = attr;
return pci_create_one_attr(pdev, num, attr_name, "_dense", attr, 0);
}
/**
* pci_create_resource_files - create resource files in sysfs for @pdev
* @pdev: pci_dev in question
*
* Walk the resources in @dev creating files for each resource available.
*
* Return: %0 on success, or negative error code
*/
int pci_create_resource_files(struct pci_dev *pdev)
{
int i;
int retval;
/* Expose the PCI resources from this device as files */
for (i = 0; i < PCI_STD_NUM_BARS; i++) {
/* skip empty resources */
if (!pci_resource_len(pdev, i))
continue;
retval = pci_create_attr(pdev, i);
if (retval) {
pci_remove_resource_files(pdev);
return retval;
}
}
return 0;
}
/* Legacy I/O bus mapping stuff. */
static int __legacy_mmap_fits(struct pci_controller *hose,
struct vm_area_struct *vma,
unsigned long res_size, int sparse)
static int __legacy_mmap_fits(struct vm_area_struct *vma,
unsigned long res_size)
{
unsigned long nr, start, size;
@ -263,13 +152,7 @@ static int __legacy_mmap_fits(struct pci_controller *hose,
start = vma->vm_pgoff;
size = ((res_size - 1) >> PAGE_SHIFT) + 1;
if (start < size && size - start >= nr)
return 1;
WARN(1, "process \"%s\" tried to map%s 0x%08lx-0x%08lx on hose %d "
"(size 0x%08lx)\n",
current->comm, sparse ? " sparse" : "", start, start + nr,
hose->index, size);
return 0;
return start < size && size - start >= nr;
}
static inline int has_sparse(struct pci_controller *hose,
@ -290,36 +173,22 @@ int pci_mmap_legacy_page_range(struct pci_bus *bus, struct vm_area_struct *vma,
int sparse = has_sparse(hose, mmap_type);
unsigned long res_size;
res_size = (mmap_type == pci_mmap_mem) ? bus->legacy_mem->size :
bus->legacy_io->size;
if (!__legacy_mmap_fits(hose, vma, res_size, sparse))
res_size = (mmap_type == pci_mmap_mem) ? PCI_LEGACY_MEM_SIZE :
PCI_LEGACY_IO_SIZE;
if (sparse)
res_size <<= 5;
if (!__legacy_mmap_fits(vma, res_size))
return -EINVAL;
return hose_mmap_page_range(hose, vma, mmap_type, sparse);
}
/**
* pci_adjust_legacy_attr - adjustment of legacy file attributes
* @bus: bus to create files under
* @mmap_type: I/O port or memory
*
* Adjust file name and size for sparse mappings.
*/
void pci_adjust_legacy_attr(struct pci_bus *bus, enum pci_mmap_state mmap_type)
bool pci_legacy_has_sparse(struct pci_bus *bus, enum pci_mmap_state type)
{
struct pci_controller *hose = bus->sysdata;
if (!has_sparse(hose, mmap_type))
return;
if (mmap_type == pci_mmap_mem) {
bus->legacy_mem->attr.name = "legacy_mem_sparse";
bus->legacy_mem->size <<= 5;
} else {
bus->legacy_io->attr.name = "legacy_io_sparse";
bus->legacy_io->size <<= 5;
}
return;
return has_sparse(hose, type);
}
/* Legacy I/O bus read/write functions */
@ -370,3 +239,166 @@ int pci_legacy_write(struct pci_bus *bus, loff_t port, u32 val, size_t size)
}
return -EINVAL;
}
pci_dev_resource_attr(0);
pci_dev_resource_attr(1);
pci_dev_resource_attr(2);
pci_dev_resource_attr(3);
pci_dev_resource_attr(4);
pci_dev_resource_attr(5);
pci_dev_resource_sparse_attr(0);
pci_dev_resource_sparse_attr(1);
pci_dev_resource_sparse_attr(2);
pci_dev_resource_sparse_attr(3);
pci_dev_resource_sparse_attr(4);
pci_dev_resource_sparse_attr(5);
pci_dev_resource_dense_attr(0);
pci_dev_resource_dense_attr(1);
pci_dev_resource_dense_attr(2);
pci_dev_resource_dense_attr(3);
pci_dev_resource_dense_attr(4);
pci_dev_resource_dense_attr(5);
static inline enum pci_mmap_state pci_bar_mmap_type(struct pci_dev *pdev,
int bar)
{
return pci_resource_is_mem(pdev, bar) ? pci_mmap_mem : pci_mmap_io;
}
static inline umode_t __pci_resource_attr_is_visible(struct kobject *kobj,
const struct bin_attribute *a,
int bar)
{
struct pci_dev *pdev = to_pci_dev(kobj_to_dev(kobj));
if (!pci_resource_len(pdev, bar))
return 0;
return a->attr.mode;
}
static umode_t pci_dev_resource_is_visible(struct kobject *kobj,
const struct bin_attribute *a,
int bar)
{
struct pci_dev *pdev = to_pci_dev(kobj_to_dev(kobj));
struct pci_controller *hose = pdev->sysdata;
if (has_sparse(hose, pci_bar_mmap_type(pdev, bar)))
return 0;
return __pci_resource_attr_is_visible(kobj, a, bar);
}
static umode_t pci_dev_resource_sparse_is_visible(struct kobject *kobj,
const struct bin_attribute *a,
int bar)
{
struct pci_dev *pdev = to_pci_dev(kobj_to_dev(kobj));
struct pci_controller *hose = pdev->sysdata;
enum pci_mmap_state type = pci_bar_mmap_type(pdev, bar);
if (!has_sparse(hose, type))
return 0;
if (type == pci_mmap_mem && !sparse_mem_mmap_fits(pdev, bar))
return 0;
return __pci_resource_attr_is_visible(kobj, a, bar);
}
static umode_t pci_dev_resource_dense_is_visible(struct kobject *kobj,
const struct bin_attribute *a,
int bar)
{
struct pci_dev *pdev = to_pci_dev(kobj_to_dev(kobj));
struct pci_controller *hose = pdev->sysdata;
enum pci_mmap_state type = pci_bar_mmap_type(pdev, bar);
unsigned long dense_base;
if (!has_sparse(hose, type))
return 0;
if (type == pci_mmap_mem && !sparse_mem_mmap_fits(pdev, bar))
return __pci_resource_attr_is_visible(kobj, a, bar);
dense_base = (type == pci_mmap_mem) ? hose->dense_mem_base :
hose->dense_io_base;
if (!dense_base)
return 0;
return __pci_resource_attr_is_visible(kobj, a, bar);
}
static inline size_t __pci_dev_resource_bin_size(struct kobject *kobj,
int bar, bool sparse)
{
struct pci_dev *pdev = to_pci_dev(kobj_to_dev(kobj));
size_t size = pci_resource_len(pdev, bar);
return sparse ? size << 5 : size;
}
static size_t pci_dev_resource_bin_size(struct kobject *kobj,
const struct bin_attribute *a,
int bar)
{
return __pci_dev_resource_bin_size(kobj, bar, false);
}
static size_t pci_dev_resource_sparse_bin_size(struct kobject *kobj,
const struct bin_attribute *a,
int bar)
{
return __pci_dev_resource_bin_size(kobj, bar, true);
}
static const struct bin_attribute *const pci_dev_resource_attrs[] = {
&pci_dev_resource0_attr,
&pci_dev_resource1_attr,
&pci_dev_resource2_attr,
&pci_dev_resource3_attr,
&pci_dev_resource4_attr,
&pci_dev_resource5_attr,
NULL,
};
static const struct bin_attribute *const pci_dev_resource_sparse_attrs[] = {
&pci_dev_resource0_sparse_attr,
&pci_dev_resource1_sparse_attr,
&pci_dev_resource2_sparse_attr,
&pci_dev_resource3_sparse_attr,
&pci_dev_resource4_sparse_attr,
&pci_dev_resource5_sparse_attr,
NULL,
};
static const struct bin_attribute *const pci_dev_resource_dense_attrs[] = {
&pci_dev_resource0_dense_attr,
&pci_dev_resource1_dense_attr,
&pci_dev_resource2_dense_attr,
&pci_dev_resource3_dense_attr,
&pci_dev_resource4_dense_attr,
&pci_dev_resource5_dense_attr,
NULL,
};
const struct attribute_group pci_dev_resource_attr_group = {
.bin_attrs = pci_dev_resource_attrs,
.is_bin_visible = pci_dev_resource_is_visible,
.bin_size = pci_dev_resource_bin_size,
};
const struct attribute_group pci_dev_resource_sparse_attr_group = {
.bin_attrs = pci_dev_resource_sparse_attrs,
.is_bin_visible = pci_dev_resource_sparse_is_visible,
.bin_size = pci_dev_resource_sparse_bin_size,
};
const struct attribute_group pci_dev_resource_dense_attr_group = {
.bin_attrs = pci_dev_resource_dense_attrs,
.is_bin_visible = pci_dev_resource_dense_is_visible,
.bin_size = pci_dev_resource_bin_size,
};

1
arch/arc/configs/axs101_defconfig
View File

@ -67,7 +67,6 @@ CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_DESIGNWARE_CORE=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
# CONFIG_HWMON is not set
CONFIG_DRM=m
CONFIG_DRM_I2C_ADV7511=m

1
arch/arc/configs/axs103_defconfig
View File

@ -67,7 +67,6 @@ CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_DESIGNWARE_CORE=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
# CONFIG_HWMON is not set
CONFIG_FB=y
CONFIG_FRAMEBUFFER_CONSOLE=y

1
arch/arc/configs/axs103_smp_defconfig
View File

@ -67,7 +67,6 @@ CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_DESIGNWARE_CORE=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
# CONFIG_HWMON is not set
CONFIG_DRM=m
CONFIG_DRM_I2C_ADV7511=m

1
arch/arc/configs/tb10x_defconfig
View File

@ -61,7 +61,6 @@ CONFIG_SERIAL_8250_DW=y
CONFIG_I2C=y
# CONFIG_I2C_COMPAT is not set
CONFIG_I2C_DESIGNWARE_CORE=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
CONFIG_GPIO_SYSFS=y
# CONFIG_HWMON is not set
# CONFIG_USB_SUPPORT is not set

6
arch/arc/kernel/smp.c
View File

@ -22,6 +22,7 @@
#include <linux/irqdomain.h>
#include <linux/export.h>
#include <linux/of_fdt.h>
#include <linux/string.h>
#include <asm/mach_desc.h>
#include <asm/setup.h>
@ -43,9 +44,10 @@ static int __init arc_get_cpu_map(const char *name, struct cpumask *cpumask)
{
unsigned long dt_root = of_get_flat_dt_root();
const char *buf;
int len;
buf = of_get_flat_dt_prop(dt_root, name, NULL);
if (!buf)
buf = of_get_flat_dt_prop(dt_root, name, &len);
if (!buf || !memchr(buf, '\0', len))
return -EINVAL;
if (cpulist_parse(buf, cpumask))

2
arch/arm/boot/dts/broadcom/bcm-ns.dtsi
View File

@ -141,7 +141,7 @@ axi@18000000 {
/* PCIe Controller 2 */
<0x00014000 0 &gic GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
<0x00014000 1 &gic GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
<0x00014000 1 &gic GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>,
<0x00014000 2 &gic GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
<0x00014000 3 &gic GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
<0x00014000 4 &gic GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,

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