Merge drm/drm-next into drm-misc-next
Start the 6.5 release cycle. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
This commit is contained in:
Maxime Ripard
commit
ff32fcca64
@ -520,7 +520,7 @@ ForEachMacros:
|
||||
- 'of_property_for_each_string'
|
||||
- 'of_property_for_each_u32'
|
||||
- 'pci_bus_for_each_resource'
|
||||
- 'pci_doe_for_each_off'
|
||||
- 'pci_dev_for_each_resource'
|
||||
- 'pcl_for_each_chunk'
|
||||
- 'pcl_for_each_segment'
|
||||
- 'pcm_for_each_format'
|
||||
|
||||
1
.gitignore
vendored
1
.gitignore
vendored
@ -103,6 +103,7 @@ modules.order
|
||||
!.get_maintainer.ignore
|
||||
!.gitattributes
|
||||
!.gitignore
|
||||
!.kunitconfig
|
||||
!.mailmap
|
||||
!.rustfmt.toml
|
||||
|
||||
|
||||
15
.mailmap
15
.mailmap
@ -213,7 +213,10 @@ Jeff Garzik <jgarzik@pretzel.yyz.us>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@poochiereds.net>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@primarydata.com>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@redhat.com>
|
||||
Jens Axboe <axboe@suse.de>
|
||||
Jens Axboe <axboe@kernel.dk> <axboe@suse.de>
|
||||
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>
|
||||
Jernej Skrabec <jernej.skrabec@gmail.com> <jernej.skrabec@siol.net>
|
||||
Jessica Zhang <quic_jesszhan@quicinc.com> <jesszhan@codeaurora.org>
|
||||
@ -232,6 +235,8 @@ Johan Hovold <johan@kernel.org> <johan@hovoldconsulting.com>
|
||||
John Crispin <john@phrozen.org> <blogic@openwrt.org>
|
||||
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
|
||||
John Stultz <johnstul@us.ibm.com>
|
||||
<jon.toppins+linux@gmail.com> <jtoppins@cumulusnetworks.com>
|
||||
<jon.toppins+linux@gmail.com> <jtoppins@redhat.com>
|
||||
Jordan Crouse <jordan@cosmicpenguin.net> <jcrouse@codeaurora.org>
|
||||
<josh@joshtriplett.org> <josh@freedesktop.org>
|
||||
<josh@joshtriplett.org> <josh@kernel.org>
|
||||
@ -265,7 +270,9 @@ Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski@samsung.com>
|
||||
Krzysztof Kozlowski <krzk@kernel.org> <krzysztof.kozlowski@canonical.com>
|
||||
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
|
||||
Kuogee Hsieh <quic_khsieh@quicinc.com> <khsieh@codeaurora.org>
|
||||
Leonard Crestez <leonard.crestez@nxp.com> Leonard Crestez <cdleonard@gmail.com>
|
||||
Leonardo Bras <leobras.c@gmail.com> <leonardo@linux.ibm.com>
|
||||
Leonard Göhrs <l.goehrs@pengutronix.de>
|
||||
Leonid I Ananiev <leonid.i.ananiev@intel.com>
|
||||
Leon Romanovsky <leon@kernel.org> <leon@leon.nu>
|
||||
Leon Romanovsky <leon@kernel.org> <leonro@mellanox.com>
|
||||
@ -295,6 +302,8 @@ Martin Kepplinger <martink@posteo.de> <martin.kepplinger@puri.sm>
|
||||
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@theobroma-systems.com>
|
||||
Martyna Szapar-Mudlaw <martyna.szapar-mudlaw@linux.intel.com> <martyna.szapar-mudlaw@intel.com>
|
||||
Mathieu Othacehe <m.othacehe@gmail.com>
|
||||
Mat Martineau <martineau@kernel.org> <mathew.j.martineau@linux.intel.com>
|
||||
Mat Martineau <martineau@kernel.org> <mathewm@codeaurora.org>
|
||||
Matthew Wilcox <willy@infradead.org> <matthew.r.wilcox@intel.com>
|
||||
Matthew Wilcox <willy@infradead.org> <matthew@wil.cx>
|
||||
Matthew Wilcox <willy@infradead.org> <mawilcox@linuxonhyperv.com>
|
||||
@ -322,6 +331,7 @@ Maxime Ripard <mripard@kernel.org> <maxime.ripard@bootlin.com>
|
||||
Maxime Ripard <mripard@kernel.org> <maxime.ripard@free-electrons.com>
|
||||
Mayuresh Janorkar <mayur@ti.com>
|
||||
Michael Buesch <m@bues.ch>
|
||||
Michal Simek <michal.simek@amd.com> <michal.simek@xilinx.com>
|
||||
Michel Dänzer <michel@tungstengraphics.com>
|
||||
Michel Lespinasse <michel@lespinasse.org>
|
||||
Michel Lespinasse <michel@lespinasse.org> <walken@google.com>
|
||||
@ -354,6 +364,7 @@ Nicolas Pitre <nico@fluxnic.net> <nico@linaro.org>
|
||||
Nicolas Saenz Julienne <nsaenz@kernel.org> <nsaenzjulienne@suse.de>
|
||||
Nicolas Saenz Julienne <nsaenz@kernel.org> <nsaenzjulienne@suse.com>
|
||||
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
|
||||
Oleksandr Natalenko <oleksandr@natalenko.name> <oleksandr@redhat.com>
|
||||
Oleksij Rempel <linux@rempel-privat.de> <bug-track@fisher-privat.net>
|
||||
Oleksij Rempel <linux@rempel-privat.de> <external.Oleksij.Rempel@de.bosch.com>
|
||||
Oleksij Rempel <linux@rempel-privat.de> <fixed-term.Oleksij.Rempel@de.bosch.com>
|
||||
@ -369,6 +380,8 @@ Paul E. McKenney <paulmck@kernel.org> <paul.mckenney@linaro.org>
|
||||
Paul E. McKenney <paulmck@kernel.org> <paulmck@linux.ibm.com>
|
||||
Paul E. McKenney <paulmck@kernel.org> <paulmck@linux.vnet.ibm.com>
|
||||
Paul E. McKenney <paulmck@kernel.org> <paulmck@us.ibm.com>
|
||||
Paul Mackerras <paulus@ozlabs.org> <paulus@samba.org>
|
||||
Paul Mackerras <paulus@ozlabs.org> <paulus@au1.ibm.com>
|
||||
Peter A Jonsson <pj@ludd.ltu.se>
|
||||
Peter Oruba <peter.oruba@amd.com>
|
||||
Peter Oruba <peter@oruba.de>
|
||||
|
||||
25
CREDITS
25
CREDITS
@ -229,6 +229,10 @@ S: University of Notre Dame
|
||||
S: Notre Dame, Indiana
|
||||
S: USA
|
||||
|
||||
N: Kai Bankett
|
||||
E: chaosman@ontika.net
|
||||
D: QNX6 filesystem
|
||||
|
||||
N: Greg Banks
|
||||
E: gnb@alphalink.com.au
|
||||
D: IDT77105 ATM network driver
|
||||
@ -886,6 +890,10 @@ W: http://jdelvare.nerim.net/
|
||||
D: Several hardware monitoring drivers
|
||||
S: France
|
||||
|
||||
N: Frank "Jedi/Sector One" Denis
|
||||
E: j@pureftpd.org
|
||||
D: QNX4 filesystem
|
||||
|
||||
N: Peter Denison
|
||||
E: peterd@pnd-pc.demon.co.uk
|
||||
W: http://www.pnd-pc.demon.co.uk/promise/
|
||||
@ -1259,6 +1267,10 @@ S: USA
|
||||
N: Adam Fritzler
|
||||
E: mid@zigamorph.net
|
||||
|
||||
N: Richard "Scuba" A. Frowijn
|
||||
E: scuba@wxs.nl
|
||||
D: QNX4 filesystem
|
||||
|
||||
N: Fernando Fuganti
|
||||
E: fuganti@conectiva.com.br
|
||||
E: fuganti@netbank.com.br
|
||||
@ -2218,6 +2230,10 @@ D: Digiboard PC/Xe and PC/Xi, Digiboard EPCA
|
||||
D: NUMA support, Slab allocators, Page migration
|
||||
D: Scalability, Time subsystem
|
||||
|
||||
N: Anders Larsen
|
||||
E: al@alarsen.net
|
||||
D: QNX4 filesystem
|
||||
|
||||
N: Paul Laufer
|
||||
E: paul@laufernet.com
|
||||
D: Soundblaster driver fixes, ISAPnP quirk
|
||||
@ -2494,8 +2510,8 @@ D: XF86_8514
|
||||
D: cfdisk (curses based disk partitioning program)
|
||||
|
||||
N: Mat Martineau
|
||||
E: mat@martineau.name
|
||||
D: MPTCP subsystem co-maintainer 2020-2023
|
||||
E: martineau@kernel.org
|
||||
D: MPTCP subsystem co-maintainer
|
||||
D: Keyctl restricted keyring and Diffie-Hellman UAPI
|
||||
D: Bluetooth L2CAP ERTM mode and AMP
|
||||
S: USA
|
||||
@ -3459,6 +3475,11 @@ D: several improvements to system programs
|
||||
S: Oldenburg
|
||||
S: Germany
|
||||
|
||||
N: Mathieu Poirier
|
||||
E: mathieu.poirier@linaro.org
|
||||
D: CoreSight kernel subsystem, Maintainer 2014-2022
|
||||
D: Perf tool support for CoreSight
|
||||
|
||||
N: Robert Schwebel
|
||||
E: robert@schwebel.de
|
||||
W: https://www.schwebel.de
|
||||
|
||||
@ -4,6 +4,9 @@ KernelVersion: 2.6.12-rc2 (predates git)
|
||||
Contact: selinux@vger.kernel.org
|
||||
Description:
|
||||
|
||||
REMOVAL UPDATE: The SELinux checkreqprot functionality was removed in
|
||||
March 2023, the original deprecation notice is shown below.
|
||||
|
||||
The selinuxfs "checkreqprot" node allows SELinux to be configured
|
||||
to check the protection requested by userspace for mmap/mprotect
|
||||
calls instead of the actual protection applied by the kernel.
|
||||
@ -4,6 +4,9 @@ KernelVersion: 2.6.12-rc2 (predates git)
|
||||
Contact: selinux@vger.kernel.org
|
||||
Description:
|
||||
|
||||
REMOVAL UPDATE: The SELinux runtime disable functionality was removed
|
||||
in March 2023, the original deprecation notice is shown below.
|
||||
|
||||
The selinuxfs "disable" node allows SELinux to be disabled at runtime
|
||||
prior to a policy being loaded into the kernel. If disabled via this
|
||||
mechanism, SELinux will remain disabled until the system is rebooted.
|
||||
@ -2,16 +2,17 @@ What: /sys/firmware/acpi/pm_profile
|
||||
Date: 03-Nov-2011
|
||||
KernelVersion: v3.2
|
||||
Contact: linux-acpi@vger.kernel.org
|
||||
Description: The ACPI pm_profile sysfs interface exports the platform
|
||||
power management (and performance) requirement expectations
|
||||
as provided by BIOS. The integer value is directly passed as
|
||||
retrieved from the FADT ACPI table.
|
||||
Description: The ACPI pm_profile sysfs interface exposes the preferred
|
||||
power management (and performance) profile of the platform
|
||||
as provided in the ACPI FADT Preferred_PM_Profile field.
|
||||
|
||||
Values: For possible values see ACPI specification:
|
||||
5.2.9 Fixed ACPI Description Table (FADT)
|
||||
Field: Preferred_PM_Profile
|
||||
The integer value is directly passed as retrieved from the FADT.
|
||||
|
||||
Currently these values are defined by spec:
|
||||
Values: For the possible values refer to the Preferred_PM_Profile field
|
||||
definition in Table 5.9 "FADT Format", Section 5.2.9 "Fixed ACPI
|
||||
Description Table (FADT)" of the ACPI specification.
|
||||
|
||||
As of ACPI 6.5, the following values are defined:
|
||||
|
||||
== =================
|
||||
0 Unspecified
|
||||
@ -22,5 +23,6 @@ Values: For possible values see ACPI specification:
|
||||
5 SOHO Server
|
||||
6 Appliance PC
|
||||
7 Performance Server
|
||||
>7 Reserved
|
||||
8 Tablet
|
||||
>8 Reserved
|
||||
== =================
|
||||
|
||||
@ -336,18 +336,11 @@ What: /sys/block/<disk>/queue/io_poll_delay
|
||||
Date: November 2016
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] If polling is enabled, this controls what kind of polling
|
||||
will be performed. It defaults to -1, which is classic polling.
|
||||
[RW] This was used to control what kind of polling will be
|
||||
performed. It is now fixed to -1, which is classic polling.
|
||||
In this mode, the CPU will repeatedly ask for completions
|
||||
without giving up any time. If set to 0, a hybrid polling mode
|
||||
is used, where the kernel will attempt to make an educated guess
|
||||
at when the IO will complete. Based on this guess, the kernel
|
||||
will put the process issuing IO to sleep for an amount of time,
|
||||
before entering a classic poll loop. This mode might be a little
|
||||
slower than pure classic polling, but it will be more efficient.
|
||||
If set to a value larger than 0, the kernel will put the process
|
||||
issuing IO to sleep for this amount of microseconds before
|
||||
entering classic polling.
|
||||
without giving up any time.
|
||||
<deprecated>
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/io_timeout
|
||||
|
||||
@ -136,6 +136,22 @@ Description: The last executed device administrative command's status/error.
|
||||
Also last configuration error overloaded.
|
||||
Writing to it will clear the status.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/iaa_cap
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.0.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: IAA (IAX) capability mask. Exported to user space for application
|
||||
consumption. This attribute should only be visible on IAA devices
|
||||
that are version 2 or later.
|
||||
|
||||
What: /sys/bus/dsa/devices/dsa<m>/event_log_size
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.4.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The event log size to be configured. Default is 64 entries and
|
||||
occupies 4k size if the evl entry is 64 bytes. It's visible
|
||||
only on platforms that support the capability.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/block_on_fault
|
||||
Date: Oct 27, 2020
|
||||
KernelVersion: 5.11.0
|
||||
@ -219,6 +235,16 @@ Contact: dmaengine@vger.kernel.org
|
||||
Description: Indicate whether ATS disable is turned on for the workqueue.
|
||||
0 indicates ATS is on, and 1 indicates ATS is off for the workqueue.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/prs_disable
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.4.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Controls whether PRS disable is turned on for the workqueue.
|
||||
0 indicates PRS is on, and 1 indicates PRS is off for the
|
||||
workqueue. This option overrides block_on_fault attribute
|
||||
if set. It's visible only on platforms that support the
|
||||
capability.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/occupancy
|
||||
Date May 25, 2021
|
||||
KernelVersion: 5.14.0
|
||||
@ -302,3 +328,28 @@ Description: Allows control of the number of batch descriptors that can be
|
||||
1 (1/2 of max value), 2 (1/4 of the max value), and 3 (1/8 of
|
||||
the max value). It's visible only on platforms that support
|
||||
the capability.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/cr_faults
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.4.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Show the number of Completion Record (CR) faults this application
|
||||
has caused.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/cr_fault_failures
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.4.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Show the number of Completion Record (CR) faults failures that this
|
||||
application has caused. The failure counter is incremented when the
|
||||
driver cannot fault in the address for the CR. Typically this is caused
|
||||
by a bad address programmed in the submitted descriptor or a malicious
|
||||
submitter is using bad CR address on purpose.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/dsa<x>\!wq<m>.<n>/file<y>/pid
|
||||
Date: Sept 14, 2022
|
||||
KernelVersion: 6.4.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Show the process id of the application that opened the file. This is
|
||||
helpful information for a monitor daemon that wants to kill the
|
||||
application that opened the file.
|
||||
|
||||
@ -76,7 +76,7 @@ Date: Dec 2014
|
||||
KernelVersion: 4.0
|
||||
Description: Default camera terminal descriptors
|
||||
|
||||
All attributes read only:
|
||||
All attributes read only except bmControls, which is read/write:
|
||||
|
||||
======================== ====================================
|
||||
bmControls bitmap specifying which controls are
|
||||
@ -101,7 +101,7 @@ Date: Dec 2014
|
||||
KernelVersion: 4.0
|
||||
Description: Default processing unit descriptors
|
||||
|
||||
All attributes read only:
|
||||
All attributes read only except bmControls, which is read/write:
|
||||
|
||||
=============== ========================================
|
||||
iProcessing index of string descriptor
|
||||
|
||||
35
Documentation/ABI/testing/debugfs-cxl
Normal file
35
Documentation/ABI/testing/debugfs-cxl
Normal file
@ -0,0 +1,35 @@
|
||||
What: /sys/kernel/debug/cxl/memX/inject_poison
|
||||
Date: April, 2023
|
||||
KernelVersion: v6.4
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(WO) When a Device Physical Address (DPA) is written to this
|
||||
attribute, the memdev driver sends an inject poison command to
|
||||
the device for the specified address. The DPA must be 64-byte
|
||||
aligned and the length of the injected poison is 64-bytes. If
|
||||
successful, the device returns poison when the address is
|
||||
accessed through the CXL.mem bus. Injecting poison adds the
|
||||
address to the device's Poison List and the error source is set
|
||||
to Injected. In addition, the device adds a poison creation
|
||||
event to its internal Informational Event log, updates the
|
||||
Event Status register, and if configured, interrupts the host.
|
||||
It is not an error to inject poison into an address that
|
||||
already has poison present and no error is returned. The
|
||||
inject_poison attribute is only visible for devices supporting
|
||||
the capability.
|
||||
|
||||
|
||||
What: /sys/kernel/debug/memX/clear_poison
|
||||
Date: April, 2023
|
||||
KernelVersion: v6.4
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(WO) When a Device Physical Address (DPA) is written to this
|
||||
attribute, the memdev driver sends a clear poison command to
|
||||
the device for the specified address. Clearing poison removes
|
||||
the address from the device's Poison List and writes 0 (zero)
|
||||
for 64 bytes starting at address. It is not an error to clear
|
||||
poison from an address that does not have poison set. If the
|
||||
device cannot clear poison from the address, -ENXIO is returned.
|
||||
The clear_poison attribute is only visible for devices
|
||||
supporting the capability.
|
||||
56
Documentation/ABI/testing/sysfs-bus-cdx
Normal file
56
Documentation/ABI/testing/sysfs-bus-cdx
Normal file
@ -0,0 +1,56 @@
|
||||
What: /sys/bus/cdx/rescan
|
||||
Date: March 2023
|
||||
Contact: nipun.gupta@amd.com
|
||||
Description:
|
||||
Writing y/1/on to this file will cause rescan of the bus
|
||||
and devices on the CDX bus. Any new devices are scanned and
|
||||
added to the list of Linux devices and any devices removed are
|
||||
also deleted from Linux.
|
||||
|
||||
For example::
|
||||
|
||||
# echo 1 > /sys/bus/cdx/rescan
|
||||
|
||||
What: /sys/bus/cdx/devices/.../vendor
|
||||
Date: March 2023
|
||||
Contact: nipun.gupta@amd.com
|
||||
Description:
|
||||
Vendor ID for this CDX device, in hexadecimal. Vendor ID is
|
||||
16 bit identifier which is specific to the device manufacturer.
|
||||
Combination of Vendor ID and Device ID identifies a device.
|
||||
|
||||
What: /sys/bus/cdx/devices/.../device
|
||||
Date: March 2023
|
||||
Contact: nipun.gupta@amd.com
|
||||
Description:
|
||||
Device ID for this CDX device, in hexadecimal. Device ID is
|
||||
16 bit identifier to identify a device type within the range
|
||||
of a device manufacturer.
|
||||
Combination of Vendor ID and Device ID identifies a device.
|
||||
|
||||
What: /sys/bus/cdx/devices/.../reset
|
||||
Date: March 2023
|
||||
Contact: nipun.gupta@amd.com
|
||||
Description:
|
||||
Writing y/1/on to this file resets the CDX device.
|
||||
On resetting the device, the corresponding driver is notified
|
||||
twice, once before the device is being reset, and again after
|
||||
the reset has been complete.
|
||||
|
||||
For example::
|
||||
|
||||
# echo 1 > /sys/bus/cdx/.../reset
|
||||
|
||||
What: /sys/bus/cdx/devices/.../remove
|
||||
Date: March 2023
|
||||
Contact: tarak.reddy@amd.com
|
||||
Description:
|
||||
Writing y/1/on to this file removes the corresponding
|
||||
device from the CDX bus. If the device is to be reconfigured
|
||||
reconfigured in the Hardware, the device can be removed, so
|
||||
that the device driver does not access the device while it is
|
||||
being reconfigured.
|
||||
|
||||
For example::
|
||||
|
||||
# echo 1 > /sys/bus/cdx/devices/.../remove
|
||||
@ -1,3 +1,33 @@
|
||||
What: /sys/bus/counter/devices/counterX/cascade_counts_enable
|
||||
KernelVersion: 6.4
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Indicates the cascading of Counts on Counter X.
|
||||
|
||||
Valid attribute values are boolean.
|
||||
|
||||
What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select
|
||||
KernelVersion: 6.4
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Selects the external clock pin for phase counting mode of
|
||||
Counter X.
|
||||
|
||||
MTCLKA-MTCLKB:
|
||||
MTCLKA and MTCLKB pins are selected for the external
|
||||
phase clock.
|
||||
|
||||
MTCLKC-MTCLKD:
|
||||
MTCLKC and MTCLKD pins are selected for the external
|
||||
phase clock.
|
||||
|
||||
What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select_available
|
||||
KernelVersion: 6.4
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Discrete set of available values for the respective device
|
||||
configuration are listed in this file.
|
||||
|
||||
What: /sys/bus/counter/devices/counterX/countY/count
|
||||
KernelVersion: 5.2
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
@ -215,6 +245,8 @@ Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
This attribute indicates the number of overflows of count Y.
|
||||
|
||||
What: /sys/bus/counter/devices/counterX/cascade_counts_enable_component_id
|
||||
What: /sys/bus/counter/devices/counterX/external_input_phase_clock_select_component_id
|
||||
What: /sys/bus/counter/devices/counterX/countY/capture_component_id
|
||||
What: /sys/bus/counter/devices/counterX/countY/ceiling_component_id
|
||||
What: /sys/bus/counter/devices/counterX/countY/floor_component_id
|
||||
|
||||
@ -415,3 +415,17 @@ Description:
|
||||
1), and checks that the hardware accepts the commit request.
|
||||
Reading this value indicates whether the region is committed or
|
||||
not.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/memX/trigger_poison_list
|
||||
Date: April, 2023
|
||||
KernelVersion: v6.4
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(WO) When a boolean 'true' is written to this attribute the
|
||||
memdev driver retrieves the poison list from the device. The
|
||||
list consists of addresses that are poisoned, or would result
|
||||
in poison if accessed, and the source of the poison. This
|
||||
attribute is only visible for devices supporting the
|
||||
capability. The retrieved errors are logged as kernel
|
||||
events when cxl_poison event tracing is enabled.
|
||||
|
||||
@ -1807,8 +1807,8 @@ What: /sys/bus/iio/devices/iio:deviceX/out_resistanceX_raw
|
||||
KernelVersion: 4.3
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Raw (unscaled no offset etc.) resistance reading that can be processed
|
||||
into an ohm value.
|
||||
Raw (unscaled no offset etc.) resistance reading.
|
||||
Units after application of scale and offset are ohms.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/heater_enable
|
||||
KernelVersion: 4.1.0
|
||||
@ -1894,8 +1894,9 @@ What: /sys/bus/iio/devices/iio:deviceX/in_electricalconductivity_raw
|
||||
KernelVersion: 4.8
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Raw (unscaled no offset etc.) electric conductivity reading that
|
||||
can be processed to siemens per meter.
|
||||
Raw (unscaled no offset etc.) electric conductivity reading.
|
||||
Units after application of scale and offset are siemens per
|
||||
meter.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_countY_raw
|
||||
KernelVersion: 4.10
|
||||
@ -1951,8 +1952,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_phaseY_raw
|
||||
KernelVersion: 4.18
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Raw (unscaled) phase difference reading from channel Y
|
||||
that can be processed to radians.
|
||||
Raw (unscaled) phase difference reading from channel Y.
|
||||
Units after application of scale and offset are radians.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm1_input
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm1_input
|
||||
|
||||
@ -23,3 +23,55 @@ Description:
|
||||
Reading this attribute gives the state of the DbC. It
|
||||
can be one of the following states: disabled, enabled,
|
||||
initialized, connected, configured and stalled.
|
||||
|
||||
What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_idVendor
|
||||
Date: March 2023
|
||||
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
|
||||
Description:
|
||||
This dbc_idVendor attribute lets us change the idVendor field
|
||||
presented in the USB device descriptor by this xhci debug
|
||||
device.
|
||||
Value can only be changed while debug capability (DbC) is in
|
||||
disabled state to prevent USB device descriptor change while
|
||||
connected to a USB host.
|
||||
The default value is 0x1d6b (Linux Foundation).
|
||||
It can be any 16-bit integer.
|
||||
|
||||
What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_idProduct
|
||||
Date: March 2023
|
||||
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
|
||||
Description:
|
||||
This dbc_idProduct attribute lets us change the idProduct field
|
||||
presented in the USB device descriptor by this xhci debug
|
||||
device.
|
||||
Value can only be changed while debug capability (DbC) is in
|
||||
disabled state to prevent USB device descriptor change while
|
||||
connected to a USB host.
|
||||
The default value is 0x0010. It can be any 16-bit integer.
|
||||
|
||||
What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_bcdDevice
|
||||
Date: March 2023
|
||||
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
|
||||
Description:
|
||||
This dbc_bcdDevice attribute lets us change the bcdDevice field
|
||||
presented in the USB device descriptor by this xhci debug
|
||||
device.
|
||||
Value can only be changed while debug capability (DbC) is in
|
||||
disabled state to prevent USB device descriptor change while
|
||||
connected to a USB host.
|
||||
The default value is 0x0010. (device rev 0.10)
|
||||
It can be any 16-bit integer.
|
||||
|
||||
What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_bInterfaceProtocol
|
||||
Date: March 2023
|
||||
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
|
||||
Description:
|
||||
This attribute lets us change the bInterfaceProtocol field
|
||||
presented in the USB Interface descriptor by the xhci debug
|
||||
device.
|
||||
Value can only be changed while debug capability (DbC) is in
|
||||
disabled state to prevent USB descriptor change while
|
||||
connected to a USB host.
|
||||
The default value is 1 (GNU Remote Debug command).
|
||||
Other permissible value is 0 which is for vendor defined debug
|
||||
target.
|
||||
|
||||
@ -234,8 +234,8 @@ Description:
|
||||
For details, see section `5.10 RAS Internal Error Register Definitions,
|
||||
Altra Family Soc BMC Interface Specification`.
|
||||
|
||||
What: /sys/bus/platform/devices/smpro-errmon.*/event_[vrd_warn_fault|vrd_hot|dimm_hot]
|
||||
KernelVersion: 6.1
|
||||
What: /sys/bus/platform/devices/smpro-errmon.*/event_[vrd_warn_fault|vrd_hot|dimm_hot|dimm_2x_refresh]
|
||||
KernelVersion: 6.1 (event_[vrd_warn_fault|vrd_hot|dimm_hot]), 6.4 (event_dimm_2x_refresh)
|
||||
Contact: Quan Nguyen <quan@os.amperecomputing.com>
|
||||
Description:
|
||||
(RO) Contains the detail information in case of VRD/DIMM warning/hot events
|
||||
@ -258,8 +258,21 @@ Description:
|
||||
+---------------+---------------------------------------------------------------+---------------------+
|
||||
| DIMM HOT | /sys/bus/platform/devices/smpro-errmon.*/event_dimm_hot | DIMM Hot |
|
||||
+---------------+---------------------------------------------------------------+---------------------+
|
||||
| DIMM 2X | /sys/bus/platform/devices/smpro-errmon.*/event_dimm_2x_refresh| DIMM 2x refresh rate|
|
||||
| REFRESH RATE | | event in high temp |
|
||||
+---------------+---------------------------------------------------------------+---------------------+
|
||||
|
||||
For more details, see section `5.7 GPI Status Registers,
|
||||
For more details, see section `5.7 GPI Status Registers and 5.9 Memory Error Register Definitions,
|
||||
Altra Family Soc BMC Interface Specification`.
|
||||
|
||||
What: /sys/bus/platform/devices/smpro-errmon.*/event_dimm[0-15]_syndrome
|
||||
KernelVersion: 6.4
|
||||
Contact: Quan Nguyen <quan@os.amperecomputing.com>
|
||||
Description:
|
||||
(RO) The sysfs returns the 2-byte DIMM failure syndrome data for slot
|
||||
0-15 if it failed to initialize.
|
||||
|
||||
For more details, see section `5.11 Boot Stage Register Definitions,
|
||||
Altra Family Soc BMC Interface Specification`.
|
||||
|
||||
What: /sys/bus/platform/devices/smpro-misc.*/boot_progress
|
||||
|
||||
@ -166,6 +166,23 @@ Description:
|
||||
The file will be present for all speeds of USB devices, and will
|
||||
always read "no" for USB 1.1 and USB 2.0 devices.
|
||||
|
||||
What: /sys/bus/usb/devices/<INTERFACE>/wireless_status
|
||||
Date: February 2023
|
||||
Contact: Bastien Nocera <hadess@hadess.net>
|
||||
Description:
|
||||
Some USB devices use a USB receiver dongle to communicate
|
||||
wirelessly with their device using proprietary protocols. This
|
||||
attribute allows user-space to know whether the device is
|
||||
connected to its receiver dongle, and, for example, consider
|
||||
the device to be absent when choosing whether to show the
|
||||
device's battery, show a headset in a list of outputs, or show
|
||||
an on-screen keyboard if the only wireless keyboard is
|
||||
turned off.
|
||||
This attribute is not to be used to replace protocol specific
|
||||
statuses available in WWAN, WLAN/Wi-Fi, Bluetooth, etc.
|
||||
If the device does not use a receiver dongle with a wireless
|
||||
device, then this attribute will not exist.
|
||||
|
||||
What: /sys/bus/usb/devices/.../<hub_interface>/port<X>
|
||||
Date: August 2012
|
||||
Contact: Lan Tianyu <tianyu.lan@intel.com>
|
||||
|
||||
@ -21,4 +21,9 @@ Description:
|
||||
at the time the kernel starts are not affected or limited in
|
||||
any way by sync_state() callbacks.
|
||||
|
||||
Writing "1" to this file will force a call to the device's
|
||||
sync_state() function if it hasn't been called already. The
|
||||
sync_state() call happens independent of the state of the
|
||||
consumer devices.
|
||||
|
||||
|
||||
|
||||
73
Documentation/ABI/testing/sysfs-driver-zynqmp-fpga
Normal file
73
Documentation/ABI/testing/sysfs-driver-zynqmp-fpga
Normal file
@ -0,0 +1,73 @@
|
||||
What: /sys/bus/platform/drivers/zynqmp_fpga_manager/firmware:zynqmp-firmware:pcap/status
|
||||
Date: February 2023
|
||||
KernelVersion: 6.4
|
||||
Contact: Nava kishore Manne <nava.kishore.manne@amd.com>
|
||||
Description: (RO) Read fpga status.
|
||||
Read returns a hexadecimal value that tells the current status
|
||||
of the FPGA device. Each bit position in the status value is
|
||||
described Below(see ug570 chapter 9).
|
||||
https://docs.xilinx.com/v/u/en-US/ug570-ultrascale-configuration
|
||||
|
||||
====================== ==============================================
|
||||
BIT(0) 0: No CRC error
|
||||
1: CRC error
|
||||
|
||||
BIT(1) 0: Decryptor security not set
|
||||
1: Decryptor security set
|
||||
|
||||
BIT(2) 0: MMCMs/PLLs are not locked
|
||||
1: MMCMs/PLLs are locked
|
||||
|
||||
BIT(3) 0: DCI not matched
|
||||
1: DCI matched
|
||||
|
||||
BIT(4) 0: Start-up sequence has not finished
|
||||
1: Start-up sequence has finished
|
||||
|
||||
BIT(5) 0: All I/Os are placed in High-Z state
|
||||
1: All I/Os behave as configured
|
||||
|
||||
BIT(6) 0: Flip-flops and block RAM are write disabled
|
||||
1: Flip-flops and block RAM are write enabled
|
||||
|
||||
BIT(7) 0: GHIGH_B_STATUS asserted
|
||||
1: GHIGH_B_STATUS deasserted
|
||||
|
||||
BIT(8) to BIT(10) Status of the mode pins
|
||||
|
||||
BIT(11) 0: Initialization has not finished
|
||||
1: Initialization finished
|
||||
|
||||
BIT(12) Value on INIT_B_PIN pin
|
||||
|
||||
BIT(13) 0: Signal not released
|
||||
1: Signal released
|
||||
|
||||
BIT(14) Value on DONE_PIN pin.
|
||||
|
||||
BIT(15) 0: No IDCODE_ERROR
|
||||
1: IDCODE_ERROR
|
||||
|
||||
BIT(16) 0: No SECURITY_ERROR
|
||||
1: SECURITY_ERROR
|
||||
|
||||
BIT(17) System Monitor over-temperature if set
|
||||
|
||||
BIT(18) to BIT(20) Start-up state machine (0 to 7)
|
||||
Phase 0 = 000
|
||||
Phase 1 = 001
|
||||
Phase 2 = 011
|
||||
Phase 3 = 010
|
||||
Phase 4 = 110
|
||||
Phase 5 = 111
|
||||
Phase 6 = 101
|
||||
Phase 7 = 100
|
||||
|
||||
BIT(25) to BIT(26) Indicates the detected bus width
|
||||
00 = x1
|
||||
01 = x8
|
||||
10 = x16
|
||||
11 = x32
|
||||
====================== ==============================================
|
||||
|
||||
The other bits are reserved.
|
||||
@ -190,12 +190,6 @@ Description: Controls the memory footprint used by free nids and cached
|
||||
nat entries. By default, 1 is set, which indicates
|
||||
10 MB / 1 GB RAM.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/batched_trim_sections
|
||||
Date: February 2015
|
||||
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
|
||||
Description: Controls the trimming rate in batch mode.
|
||||
<deprecated>
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/cp_interval
|
||||
Date: October 2015
|
||||
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
|
||||
@ -729,3 +723,20 @@ What: /sys/fs/f2fs/<disk>/last_age_weight
|
||||
Date: January 2023
|
||||
Contact: "Ping Xiong" <xiongping1@xiaomi.com>
|
||||
Description: When DATA SEPARATION is on, it controls the weight of last data block age.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/compress_watermark
|
||||
Date: February 2023
|
||||
Contact: "Yangtao Li" <frank.li@vivo.com>
|
||||
Description: When compress cache is on, it controls free memory watermark
|
||||
in order to limit caching compress page. If free memory is lower
|
||||
than watermark, then deny caching compress page. The value should be in
|
||||
range of (0, 100], by default it was initialized as 20(%).
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/compress_percent
|
||||
Date: February 2023
|
||||
Contact: "Yangtao Li" <frank.li@vivo.com>
|
||||
Description: When compress cache is on, it controls cached page
|
||||
percent(compress pages / free_ram) in order to limit caching compress page.
|
||||
If cached page percent exceed threshold, then deny caching compress page.
|
||||
The value should be in range of (0, 100], by default it was initialized
|
||||
as 20(%).
|
||||
|
||||
@ -53,7 +53,6 @@ Description: /sys/kernel/iommu_groups/<grp_id>/type shows the type of default
|
||||
|
||||
The default domain type of a group may be modified only when
|
||||
|
||||
- The group has only one device.
|
||||
- The device in the group is not bound to any device driver.
|
||||
So, the users must unbind the appropriate driver before
|
||||
changing the default domain type.
|
||||
|
||||
@ -51,3 +51,11 @@ Description: Control merging pages across different NUMA nodes.
|
||||
|
||||
When it is set to 0 only pages from the same node are merged,
|
||||
otherwise pages from all nodes can be merged together (default).
|
||||
|
||||
What: /sys/kernel/mm/ksm/general_profit
|
||||
Date: April 2023
|
||||
KernelVersion: 6.4
|
||||
Contact: Linux memory management mailing list <linux-mm@kvack.org>
|
||||
Description: Measure how effective KSM is.
|
||||
general_profit: how effective is KSM. The formula for the
|
||||
calculation is in Documentation/admin-guide/mm/ksm.rst.
|
||||
|
||||
@ -1,3 +1,7 @@
|
||||
Device instance to test mapping
|
||||
intel_ifs_0 -> Scan Test
|
||||
intel_ifs_1 -> Array BIST test
|
||||
|
||||
What: /sys/devices/virtual/misc/intel_ifs_<N>/run_test
|
||||
Date: Nov 16 2022
|
||||
KernelVersion: 6.2
|
||||
@ -8,6 +12,7 @@ Description: Write <cpu#> to trigger IFS test for one online core.
|
||||
completes the test for the core containing that thread.
|
||||
Example: to test the core containing cpu5: echo 5 >
|
||||
/sys/devices/virtual/misc/intel_ifs_<N>/run_test
|
||||
Devices: all
|
||||
|
||||
What: /sys/devices/virtual/misc/intel_ifs_<N>/status
|
||||
Date: Nov 16 2022
|
||||
@ -15,21 +20,25 @@ KernelVersion: 6.2
|
||||
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
|
||||
Description: The status of the last test. It can be one of "pass", "fail"
|
||||
or "untested".
|
||||
Devices: all
|
||||
|
||||
What: /sys/devices/virtual/misc/intel_ifs_<N>/details
|
||||
Date: Nov 16 2022
|
||||
KernelVersion: 6.2
|
||||
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
|
||||
Description: Additional information regarding the last test. The details file reports
|
||||
the hex value of the SCAN_STATUS MSR. Note that the error_code field
|
||||
the hex value of the STATUS MSR for this test. Note that the error_code field
|
||||
may contain driver defined software code not defined in the Intel SDM.
|
||||
Devices: all
|
||||
|
||||
What: /sys/devices/virtual/misc/intel_ifs_<N>/image_version
|
||||
Date: Nov 16 2022
|
||||
KernelVersion: 6.2
|
||||
Contact: "Jithu Joseph" <jithu.joseph@intel.com>
|
||||
Description: Version (hexadecimal) of loaded IFS binary image. If no scan image
|
||||
is loaded reports "none".
|
||||
Description: Version (hexadecimal) of loaded IFS test image. If no test image
|
||||
is loaded reports "none". Only present for device instances where a test image
|
||||
is applicable.
|
||||
Devices: intel_ifs_0
|
||||
|
||||
What: /sys/devices/virtual/misc/intel_ifs_<N>/current_batch
|
||||
Date: Nov 16 2022
|
||||
@ -39,3 +48,5 @@ Description: Write a number less than or equal to 0xff to load an IFS test image
|
||||
The number written treated as the 2 digit suffix in the following file name:
|
||||
/lib/firmware/intel/ifs_<N>/ff-mm-ss-02x.scan
|
||||
Reading the file will provide the suffix of the currently loaded IFS test image.
|
||||
This file is present only for device instances where a test image is applicable.
|
||||
Devices: intel_ifs_0
|
||||
|
||||
@ -68,3 +68,10 @@ Description:
|
||||
Wasted burnt and invalid
|
||||
Invalid not burnt but marked as valid (error state).
|
||||
======= ===============================================
|
||||
|
||||
What: /sys/bus/platform/devices/MLNXBF04:00/bootfifo
|
||||
Date: Apr 2023
|
||||
KernelVersion: 6.4
|
||||
Contact: "Liming Sun <limings@nvidia.com>"
|
||||
Description:
|
||||
The file used to access the BlueField boot fifo.
|
||||
|
||||
@ -413,6 +413,35 @@ Description:
|
||||
The /sys/power/suspend_stats/last_failed_step file contains
|
||||
the last failed step in the suspend/resume path.
|
||||
|
||||
What: /sys/power/suspend_stats/last_hw_sleep
|
||||
Date: June 2023
|
||||
Contact: Mario Limonciello <mario.limonciello@amd.com>
|
||||
Description:
|
||||
The /sys/power/suspend_stats/last_hw_sleep file
|
||||
contains the duration of time spent in a hardware sleep
|
||||
state in the most recent system suspend-resume cycle.
|
||||
This number is measured in microseconds.
|
||||
|
||||
What: /sys/power/suspend_stats/total_hw_sleep
|
||||
Date: June 2023
|
||||
Contact: Mario Limonciello <mario.limonciello@amd.com>
|
||||
Description:
|
||||
The /sys/power/suspend_stats/total_hw_sleep file
|
||||
contains the aggregate of time spent in a hardware sleep
|
||||
state since the kernel was booted. This number
|
||||
is measured in microseconds.
|
||||
|
||||
What: /sys/power/suspend_stats/max_hw_sleep
|
||||
Date: June 2023
|
||||
Contact: Mario Limonciello <mario.limonciello@amd.com>
|
||||
Description:
|
||||
The /sys/power/suspend_stats/max_hw_sleep file
|
||||
contains the maximum amount of time that the hardware can
|
||||
report for time spent in a hardware sleep state. When sleep
|
||||
cycles are longer than this time, the values for
|
||||
'total_hw_sleep' and 'last_hw_sleep' may not be accurate.
|
||||
This number is measured in microseconds.
|
||||
|
||||
What: /sys/power/sync_on_suspend
|
||||
Date: October 2019
|
||||
Contact: Jonas Meurer <jonas@freesources.org>
|
||||
|
||||
@ -418,7 +418,6 @@ That is, the recovery API only requires that:
|
||||
- drivers/next/e100.c
|
||||
- drivers/net/e1000
|
||||
- drivers/net/e1000e
|
||||
- drivers/net/ixgb
|
||||
- drivers/net/ixgbe
|
||||
- drivers/net/cxgb3
|
||||
- drivers/net/s2io.c
|
||||
|
||||
@ -277,7 +277,7 @@ the following access functions:
|
||||
|
||||
Again, only one request in a given batch need actually carry out a
|
||||
grace-period operation, which means there must be an efficient way to
|
||||
identify which of many concurrent reqeusts will initiate the grace
|
||||
identify which of many concurrent requests will initiate the grace
|
||||
period, and that there be an efficient way for the remaining requests to
|
||||
wait for that grace period to complete. However, that is the topic of
|
||||
the next section.
|
||||
@ -405,7 +405,7 @@ Use of Workqueues
|
||||
In earlier implementations, the task requesting the expedited grace
|
||||
period also drove it to completion. This straightforward approach had
|
||||
the disadvantage of needing to account for POSIX signals sent to user
|
||||
tasks, so more recent implemementations use the Linux kernel's
|
||||
tasks, so more recent implementations use the Linux kernel's
|
||||
workqueues (see Documentation/core-api/workqueue.rst).
|
||||
|
||||
The requesting task still does counter snapshotting and funnel-lock
|
||||
@ -465,7 +465,7 @@ corresponding disadvantage that workqueues cannot be used until they are
|
||||
initialized, which does not happen until some time after the scheduler
|
||||
spawns the first task. Given that there are parts of the kernel that
|
||||
really do want to execute grace periods during this mid-boot “dead
|
||||
zone”, expedited grace periods must do something else during thie time.
|
||||
zone”, expedited grace periods must do something else during this time.
|
||||
|
||||
What they do is to fall back to the old practice of requiring that the
|
||||
requesting task drive the expedited grace period, as was the case before
|
||||
|
||||
@ -168,7 +168,7 @@ an ``atomic_add_return()`` of zero) to detect idle CPUs.
|
||||
+-----------------------------------------------------------------------+
|
||||
|
||||
The approach must be extended to handle one final case, that of waking a
|
||||
task blocked in ``synchronize_rcu()``. This task might be affinitied to
|
||||
task blocked in ``synchronize_rcu()``. This task might be affined to
|
||||
a CPU that is not yet aware that the grace period has ended, and thus
|
||||
might not yet be subject to the grace period's memory ordering.
|
||||
Therefore, there is an ``smp_mb()`` after the return from
|
||||
|
||||
@ -201,7 +201,7 @@ work looked at debugging uses of RCU [Seyster:2011:RFA:2075416.2075425].
|
||||
In 2012, Josh Triplett received his Ph.D. with his dissertation
|
||||
covering RCU-protected resizable hash tables and the relationship
|
||||
between memory barriers and read-side traversal order: If the updater
|
||||
is making changes in the opposite direction from the read-side traveral
|
||||
is making changes in the opposite direction from the read-side traversal
|
||||
order, the updater need only execute a memory-barrier instruction,
|
||||
but if in the same direction, the updater needs to wait for a grace
|
||||
period between the individual updates [JoshTriplettPhD]. Also in 2012,
|
||||
@ -1245,7 +1245,7 @@ Oregon Health and Sciences University"
|
||||
[Viewed September 5, 2005]"
|
||||
,annotation={
|
||||
First posting showing how RCU can be safely adapted for
|
||||
preemptable RCU read side critical sections.
|
||||
preemptible RCU read side critical sections.
|
||||
}
|
||||
}
|
||||
|
||||
@ -1888,7 +1888,7 @@ Revised:
|
||||
\url{https://lore.kernel.org/r/20070910183004.GA3299@linux.vnet.ibm.com}
|
||||
[Viewed October 25, 2007]"
|
||||
,annotation={
|
||||
Final patch for preemptable RCU to -rt. (Later patches were
|
||||
Final patch for preemptible RCU to -rt. (Later patches were
|
||||
to mainline, eventually incorporated.)
|
||||
}
|
||||
}
|
||||
@ -2275,7 +2275,7 @@ lot of {Linux} into your technology!!!"
|
||||
\url{https://lore.kernel.org/r/20090724001429.GA17374@linux.vnet.ibm.com}
|
||||
[Viewed August 15, 2009]"
|
||||
,annotation={
|
||||
First posting of simple and fast preemptable RCU.
|
||||
First posting of simple and fast preemptible RCU.
|
||||
}
|
||||
}
|
||||
|
||||
@ -2639,7 +2639,7 @@ lot of {Linux} into your technology!!!"
|
||||
RCU-protected hash tables, barriers vs. read-side traversal order.
|
||||
.
|
||||
If the updater is making changes in the opposite direction from
|
||||
the read-side traveral order, the updater need only execute a
|
||||
the read-side traversal order, the updater need only execute a
|
||||
memory-barrier instruction, but if in the same direction, the
|
||||
updater needs to wait for a grace period between the individual
|
||||
updates.
|
||||
|
||||
@ -107,7 +107,7 @@ UP systems, including PREEMPT SMP builds running on UP systems.
|
||||
|
||||
Quick Quiz #3:
|
||||
Why can't synchronize_rcu() return immediately on UP systems running
|
||||
preemptable RCU?
|
||||
preemptible RCU?
|
||||
|
||||
.. _answer_quick_quiz_up:
|
||||
|
||||
@ -143,7 +143,7 @@ Answer to Quick Quiz #2:
|
||||
|
||||
Answer to Quick Quiz #3:
|
||||
Why can't synchronize_rcu() return immediately on UP systems
|
||||
running preemptable RCU?
|
||||
running preemptible RCU?
|
||||
|
||||
Because some other task might have been preempted in the middle
|
||||
of an RCU read-side critical section. If synchronize_rcu()
|
||||
|
||||
@ -70,7 +70,7 @@ over a rather long period of time, but improvements are always welcome!
|
||||
can serve as rcu_read_lock_sched(), but is less readable and
|
||||
prevents lockdep from detecting locking issues.
|
||||
|
||||
Please not that you *cannot* rely on code known to be built
|
||||
Please note that you *cannot* rely on code known to be built
|
||||
only in non-preemptible kernels. Such code can and will break,
|
||||
especially in kernels built with CONFIG_PREEMPT_COUNT=y.
|
||||
|
||||
|
||||
@ -65,7 +65,7 @@ checking of rcu_dereference() primitives:
|
||||
rcu_access_pointer(p):
|
||||
Return the value of the pointer and omit all barriers,
|
||||
but retain the compiler constraints that prevent duplicating
|
||||
or coalescsing. This is useful when testing the
|
||||
or coalescing. This is useful when testing the
|
||||
value of the pointer itself, for example, against NULL.
|
||||
|
||||
The rcu_dereference_check() check expression can be any boolean
|
||||
|
||||
@ -216,7 +216,7 @@ Kernel boot arguments can also be supplied, for example, to control
|
||||
rcutorture's module parameters. For example, to test a change to RCU's
|
||||
CPU stall-warning code, use "--bootargs 'rcutorture.stall_cpu=30'".
|
||||
This will of course result in the scripting reporting a failure, namely
|
||||
the resuling RCU CPU stall warning. As noted above, reducing memory may
|
||||
the resulting RCU CPU stall warning. As noted above, reducing memory may
|
||||
require disabling rcutorture's callback-flooding tests::
|
||||
|
||||
kvm.sh --cpus 448 --configs '56*TREE04' --memory 128M \
|
||||
@ -370,5 +370,5 @@ You can also re-run a previous remote run in a manner similar to kvm.sh:
|
||||
tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28-remote \
|
||||
--duration 24h
|
||||
|
||||
In this case, most of the kvm-again.sh parmeters may be supplied following
|
||||
In this case, most of the kvm-again.sh parameters may be supplied following
|
||||
the pathname of the old run-results directory.
|
||||
|
||||
@ -597,10 +597,10 @@ to avoid having to write your own callback::
|
||||
If the occasional sleep is permitted, the single-argument form may
|
||||
be used, omitting the rcu_head structure from struct foo.
|
||||
|
||||
kfree_rcu(old_fp);
|
||||
kfree_rcu_mightsleep(old_fp);
|
||||
|
||||
This variant of kfree_rcu() almost never blocks, but might do so by
|
||||
invoking synchronize_rcu() in response to memory-allocation failure.
|
||||
This variant almost never blocks, but might do so by invoking
|
||||
synchronize_rcu() in response to memory-allocation failure.
|
||||
|
||||
Again, see checklist.rst for additional rules governing the use of RCU.
|
||||
|
||||
|
||||
@ -16,6 +16,7 @@ d) memory reclaim
|
||||
e) thrashing
|
||||
f) direct compact
|
||||
g) write-protect copy
|
||||
h) IRQ/SOFTIRQ
|
||||
|
||||
and makes these statistics available to userspace through
|
||||
the taskstats interface.
|
||||
@ -49,7 +50,7 @@ this structure. See
|
||||
for a description of the fields pertaining to delay accounting.
|
||||
It will generally be in the form of counters returning the cumulative
|
||||
delay seen for cpu, sync block I/O, swapin, memory reclaim, thrash page
|
||||
cache, direct compact, write-protect copy etc.
|
||||
cache, direct compact, write-protect copy, IRQ/SOFTIRQ etc.
|
||||
|
||||
Taking the difference of two successive readings of a given
|
||||
counter (say cpu_delay_total) for a task will give the delay
|
||||
@ -109,17 +110,19 @@ Get sum of delays, since system boot, for all pids with tgid 5::
|
||||
CPU count real total virtual total delay total delay average
|
||||
8 7000000 6872122 3382277 0.423ms
|
||||
IO count delay total delay average
|
||||
0 0 0ms
|
||||
0 0 0.000ms
|
||||
SWAP count delay total delay average
|
||||
0 0 0ms
|
||||
0 0 0.000ms
|
||||
RECLAIM count delay total delay average
|
||||
0 0 0ms
|
||||
0 0 0.000ms
|
||||
THRASHING count delay total delay average
|
||||
0 0 0ms
|
||||
0 0 0.000ms
|
||||
COMPACT count delay total delay average
|
||||
0 0 0ms
|
||||
WPCOPY count delay total delay average
|
||||
0 0 0ms
|
||||
0 0 0.000ms
|
||||
WPCOPY count delay total delay average
|
||||
0 0 0.000ms
|
||||
IRQ count delay total delay average
|
||||
0 0 0.000ms
|
||||
|
||||
Get IO accounting for pid 1, it works only with -p::
|
||||
|
||||
|
||||
@ -105,6 +105,10 @@ prevent overly frequent polling. Max limit is chosen as a high enough number
|
||||
after which monitors are most likely not needed and psi averages can be used
|
||||
instead.
|
||||
|
||||
Unprivileged users can also create monitors, with the only limitation that the
|
||||
window size must be a multiple of 2s, in order to prevent excessive resource
|
||||
usage.
|
||||
|
||||
When activated, psi monitor stays active for at least the duration of one
|
||||
tracking window to avoid repeated activations/deactivations when system is
|
||||
bouncing in and out of the stall state.
|
||||
|
||||
@ -14,7 +14,7 @@ to borrow disk space from another computer.
|
||||
Unlike NFS, it is possible to put any filesystem on it, etc.
|
||||
|
||||
For more information, or to download the nbd-client and nbd-server
|
||||
tools, go to http://nbd.sf.net/.
|
||||
tools, go to https://github.com/NetworkBlockDevice/nbd.
|
||||
|
||||
The nbd kernel module need only be installed on the client
|
||||
system, as the nbd-server is completely in userspace. In fact,
|
||||
|
||||
@ -719,7 +719,7 @@ There are ways to query or modify cpusets:
|
||||
cat, rmdir commands from the shell, or their equivalent from C.
|
||||
- via the C library libcpuset.
|
||||
- via the C library libcgroup.
|
||||
(http://sourceforge.net/projects/libcg/)
|
||||
(https://github.com/libcgroup/libcgroup/)
|
||||
- via the python application cset.
|
||||
(http://code.google.com/p/cpuset/)
|
||||
|
||||
|
||||
@ -39,6 +39,10 @@ Optional feature parameters:
|
||||
If no feature parameters are present, during the periods of
|
||||
unreliability, all I/O returns errors.
|
||||
|
||||
error_reads:
|
||||
All read I/O is failed with an error signalled.
|
||||
Write I/O is handled correctly.
|
||||
|
||||
drop_writes:
|
||||
All write I/O is silently ignored.
|
||||
Read I/O is handled correctly.
|
||||
|
||||
@ -489,9 +489,6 @@ Files in /sys/fs/ext4/<devname>:
|
||||
multiple of this tuning parameter if the stripe size is not set in the
|
||||
ext4 superblock
|
||||
|
||||
mb_max_inode_prealloc
|
||||
The maximum length of per-inode ext4_prealloc_space list.
|
||||
|
||||
mb_max_to_scan
|
||||
The maximum number of extents the multiblock allocator will search to
|
||||
find the best extent.
|
||||
|
||||
@ -145,7 +145,7 @@ requested using gpio_request()::
|
||||
/* export the GPIO to userspace */
|
||||
int gpiod_export(struct gpio_desc *desc, bool direction_may_change);
|
||||
|
||||
/* reverse gpio_export() */
|
||||
/* reverse gpiod_export() */
|
||||
void gpiod_unexport(struct gpio_desc *desc);
|
||||
|
||||
/* create a sysfs link to an exported GPIO node */
|
||||
|
||||
@ -58,7 +58,7 @@ Because the buffers are potentially shared between Hyper-Threads cross
|
||||
Hyper-Thread attacks are possible.
|
||||
|
||||
Deeper technical information is available in the MDS specific x86
|
||||
architecture section: :ref:`Documentation/x86/mds.rst <mds>`.
|
||||
architecture section: :ref:`Documentation/arch/x86/mds.rst <mds>`.
|
||||
|
||||
|
||||
Attack scenarios
|
||||
|
||||
@ -63,7 +63,7 @@ attacker needs to begin a TSX transaction and raise an asynchronous abort
|
||||
which in turn potentially leaks data stored in the buffers.
|
||||
|
||||
More detailed technical information is available in the TAA specific x86
|
||||
architecture section: :ref:`Documentation/x86/tsx_async_abort.rst <tsx_async_abort>`.
|
||||
architecture section: :ref:`Documentation/arch/x86/tsx_async_abort.rst <tsx_async_abort>`.
|
||||
|
||||
|
||||
Attack scenarios
|
||||
|
||||
@ -36,7 +36,7 @@ problems and bugs in particular.
|
||||
|
||||
reporting-issues
|
||||
reporting-regressions
|
||||
security-bugs
|
||||
quickly-build-trimmed-linux
|
||||
bug-hunting
|
||||
bug-bisect
|
||||
tainted-kernels
|
||||
|
||||
@ -172,7 +172,7 @@ variables.
|
||||
Offset of the free_list's member. This value is used to compute the number
|
||||
of free pages.
|
||||
|
||||
Each zone has a free_area structure array called free_area[MAX_ORDER].
|
||||
Each zone has a free_area structure array called free_area[MAX_ORDER + 1].
|
||||
The free_list represents a linked list of free page blocks.
|
||||
|
||||
(list_head, next|prev)
|
||||
@ -189,8 +189,8 @@ Offsets of the vmap_area's members. They carry vmalloc-specific
|
||||
information. Makedumpfile gets the start address of the vmalloc region
|
||||
from this.
|
||||
|
||||
(zone.free_area, MAX_ORDER)
|
||||
---------------------------
|
||||
(zone.free_area, MAX_ORDER + 1)
|
||||
-------------------------------
|
||||
|
||||
Free areas descriptor. User-space tools use this value to iterate the
|
||||
free_area ranges. MAX_ORDER is used by the zone buddy allocator.
|
||||
|
||||
@ -128,10 +128,11 @@ parameter is applicable::
|
||||
KVM Kernel Virtual Machine support is enabled.
|
||||
LIBATA Libata driver is enabled
|
||||
LP Printer support is enabled.
|
||||
LOONGARCH LoongArch architecture is enabled.
|
||||
LOOP Loopback device support is enabled.
|
||||
M68k M68k architecture is enabled.
|
||||
These options have more detailed description inside of
|
||||
Documentation/m68k/kernel-options.rst.
|
||||
Documentation/arch/m68k/kernel-options.rst.
|
||||
MDA MDA console support is enabled.
|
||||
MIPS MIPS architecture is enabled.
|
||||
MOUSE Appropriate mouse support is enabled.
|
||||
@ -177,7 +178,7 @@ parameter is applicable::
|
||||
X86-32 X86-32, aka i386 architecture is enabled.
|
||||
X86-64 X86-64 architecture is enabled.
|
||||
More X86-64 boot options can be found in
|
||||
Documentation/x86/x86_64/boot-options.rst.
|
||||
Documentation/arch/x86/x86_64/boot-options.rst.
|
||||
X86 Either 32-bit or 64-bit x86 (same as X86-32+X86-64)
|
||||
X86_UV SGI UV support is enabled.
|
||||
XEN Xen support is enabled
|
||||
@ -192,10 +193,10 @@ In addition, the following text indicates that the option::
|
||||
Parameters denoted with BOOT are actually interpreted by the boot
|
||||
loader, and have no meaning to the kernel directly.
|
||||
Do not modify the syntax of boot loader parameters without extreme
|
||||
need or coordination with <Documentation/x86/boot.rst>.
|
||||
need or coordination with <Documentation/arch/x86/boot.rst>.
|
||||
|
||||
There are also arch-specific kernel-parameters not documented here.
|
||||
See for example <Documentation/x86/x86_64/boot-options.rst>.
|
||||
See for example <Documentation/arch/x86/x86_64/boot-options.rst>.
|
||||
|
||||
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that
|
||||
a trailing = on the name of any parameter states that that parameter will
|
||||
|
||||
@ -339,6 +339,29 @@
|
||||
This mode requires kvm-amd.avic=1.
|
||||
(Default when IOMMU HW support is present.)
|
||||
|
||||
amd_pstate= [X86]
|
||||
disable
|
||||
Do not enable amd_pstate as the default
|
||||
scaling driver for the supported processors
|
||||
passive
|
||||
Use amd_pstate with passive mode as a scaling driver.
|
||||
In this mode autonomous selection is disabled.
|
||||
Driver requests a desired performance level and platform
|
||||
tries to match the same performance level if it is
|
||||
satisfied by guaranteed performance level.
|
||||
active
|
||||
Use amd_pstate_epp driver instance as the scaling driver,
|
||||
driver provides a hint to the hardware if software wants
|
||||
to bias toward performance (0x0) or energy efficiency (0xff)
|
||||
to the CPPC firmware. then CPPC power algorithm will
|
||||
calculate the runtime workload and adjust the realtime cores
|
||||
frequency.
|
||||
guided
|
||||
Activate guided autonomous mode. Driver requests minimum and
|
||||
maximum performance level and the platform autonomously
|
||||
selects a performance level in this range and appropriate
|
||||
to the current workload.
|
||||
|
||||
amijoy.map= [HW,JOY] Amiga joystick support
|
||||
Map of devices attached to JOY0DAT and JOY1DAT
|
||||
Format: <a>,<b>
|
||||
@ -889,15 +912,14 @@
|
||||
cs89x0_media= [HW,NET]
|
||||
Format: { rj45 | aui | bnc }
|
||||
|
||||
csdlock_debug= [KNL] Enable debug add-ons of cross-CPU function call
|
||||
handling. When switched on, additional debug data is
|
||||
printed to the console in case a hanging CPU is
|
||||
detected, and that CPU is pinged again in order to try
|
||||
to resolve the hang situation.
|
||||
0: disable csdlock debugging (default)
|
||||
1: enable basic csdlock debugging (minor impact)
|
||||
ext: enable extended csdlock debugging (more impact,
|
||||
but more data)
|
||||
csdlock_debug= [KNL] Enable or disable debug add-ons of cross-CPU
|
||||
function call handling. When switched on,
|
||||
additional debug data is printed to the console
|
||||
in case a hanging CPU is detected, and that
|
||||
CPU is pinged again in order to try to resolve
|
||||
the hang situation. The default value of this
|
||||
option depends on the CSD_LOCK_WAIT_DEBUG_DEFAULT
|
||||
Kconfig option.
|
||||
|
||||
dasd= [HW,NET]
|
||||
See header of drivers/s390/block/dasd_devmap.c.
|
||||
@ -929,9 +951,6 @@
|
||||
|
||||
debug_objects [KNL] Enable object debugging
|
||||
|
||||
no_debug_objects
|
||||
[KNL] Disable object debugging
|
||||
|
||||
debug_guardpage_minorder=
|
||||
[KNL] When CONFIG_DEBUG_PAGEALLOC is set, this
|
||||
parameter allows control of the order of pages that will
|
||||
@ -1582,6 +1601,20 @@
|
||||
dependencies. This only applies for fw_devlink=on|rpm.
|
||||
Format: <bool>
|
||||
|
||||
fw_devlink.sync_state =
|
||||
[KNL] When all devices that could probe have finished
|
||||
probing, this parameter controls what to do with
|
||||
devices that haven't yet received their sync_state()
|
||||
calls.
|
||||
Format: { strict | timeout }
|
||||
strict -- Default. Continue waiting on consumers to
|
||||
probe successfully.
|
||||
timeout -- Give up waiting on consumers and call
|
||||
sync_state() on any devices that haven't yet
|
||||
received their sync_state() calls after
|
||||
deferred_probe_timeout has expired or by
|
||||
late_initcall() if !CONFIG_MODULES.
|
||||
|
||||
gamecon.map[2|3]=
|
||||
[HW,JOY] Multisystem joystick and NES/SNES/PSX pad
|
||||
support via parallel port (up to 5 devices per port)
|
||||
@ -2976,7 +3009,7 @@
|
||||
|
||||
mce [X86-32] Machine Check Exception
|
||||
|
||||
mce=option [X86-64] See Documentation/x86/x86_64/boot-options.rst
|
||||
mce=option [X86-64] See Documentation/arch/x86/x86_64/boot-options.rst
|
||||
|
||||
md= [HW] RAID subsystems devices and level
|
||||
See Documentation/admin-guide/md.rst.
|
||||
@ -3184,9 +3217,6 @@
|
||||
deep - Suspend-To-RAM or equivalent (if supported)
|
||||
See Documentation/admin-guide/pm/sleep-states.rst.
|
||||
|
||||
meye.*= [HW] Set MotionEye Camera parameters
|
||||
See Documentation/admin-guide/media/meye.rst.
|
||||
|
||||
mfgpt_irq= [IA-32] Specify the IRQ to use for the
|
||||
Multi-Function General Purpose Timers on AMD Geode
|
||||
platforms.
|
||||
@ -3332,6 +3362,12 @@
|
||||
specified, <module>.async_probe takes precedence for
|
||||
the specific module.
|
||||
|
||||
module.enable_dups_trace
|
||||
[KNL] When CONFIG_MODULE_DEBUG_AUTOLOAD_DUPS is set,
|
||||
this means that duplicate request_module() calls will
|
||||
trigger a WARN_ON() instead of a pr_warn(). Note that
|
||||
if MODULE_DEBUG_AUTOLOAD_DUPS_TRACE is set, WARN_ON()s
|
||||
will always be issued and this option does nothing.
|
||||
module.sig_enforce
|
||||
[KNL] When CONFIG_MODULE_SIG is set, this means that
|
||||
modules without (valid) signatures will fail to load.
|
||||
@ -3428,14 +3464,13 @@
|
||||
1 to enable accounting
|
||||
Default value is 0.
|
||||
|
||||
nfsaddrs= [NFS] Deprecated. Use ip= instead.
|
||||
See Documentation/admin-guide/nfs/nfsroot.rst.
|
||||
nfs.cache_getent=
|
||||
[NFS] sets the pathname to the program which is used
|
||||
to update the NFS client cache entries.
|
||||
|
||||
nfsroot= [NFS] nfs root filesystem for disk-less boxes.
|
||||
See Documentation/admin-guide/nfs/nfsroot.rst.
|
||||
|
||||
nfsrootdebug [NFS] enable nfsroot debugging messages.
|
||||
See Documentation/admin-guide/nfs/nfsroot.rst.
|
||||
nfs.cache_getent_timeout=
|
||||
[NFS] sets the timeout after which an attempt to
|
||||
update a cache entry is deemed to have failed.
|
||||
|
||||
nfs.callback_nr_threads=
|
||||
[NFSv4] set the total number of threads that the
|
||||
@ -3446,18 +3481,6 @@
|
||||
[NFS] set the TCP port on which the NFSv4 callback
|
||||
channel should listen.
|
||||
|
||||
nfs.cache_getent=
|
||||
[NFS] sets the pathname to the program which is used
|
||||
to update the NFS client cache entries.
|
||||
|
||||
nfs.cache_getent_timeout=
|
||||
[NFS] sets the timeout after which an attempt to
|
||||
update a cache entry is deemed to have failed.
|
||||
|
||||
nfs.idmap_cache_timeout=
|
||||
[NFS] set the maximum lifetime for idmapper cache
|
||||
entries.
|
||||
|
||||
nfs.enable_ino64=
|
||||
[NFS] enable 64-bit inode numbers.
|
||||
If zero, the NFS client will fake up a 32-bit inode
|
||||
@ -3465,6 +3488,10 @@
|
||||
of returning the full 64-bit number.
|
||||
The default is to return 64-bit inode numbers.
|
||||
|
||||
nfs.idmap_cache_timeout=
|
||||
[NFS] set the maximum lifetime for idmapper cache
|
||||
entries.
|
||||
|
||||
nfs.max_session_cb_slots=
|
||||
[NFSv4.1] Sets the maximum number of session
|
||||
slots the client will assign to the callback
|
||||
@ -3492,21 +3519,14 @@
|
||||
will be autodetected by the client, and it will fall
|
||||
back to using the idmapper.
|
||||
To turn off this behaviour, set the value to '0'.
|
||||
|
||||
nfs.nfs4_unique_id=
|
||||
[NFS4] Specify an additional fixed unique ident-
|
||||
ification string that NFSv4 clients can insert into
|
||||
their nfs_client_id4 string. This is typically a
|
||||
UUID that is generated at system install time.
|
||||
|
||||
nfs.send_implementation_id =
|
||||
[NFSv4.1] Send client implementation identification
|
||||
information in exchange_id requests.
|
||||
If zero, no implementation identification information
|
||||
will be sent.
|
||||
The default is to send the implementation identification
|
||||
information.
|
||||
|
||||
nfs.recover_lost_locks =
|
||||
nfs.recover_lost_locks=
|
||||
[NFSv4] Attempt to recover locks that were lost due
|
||||
to a lease timeout on the server. Please note that
|
||||
doing this risks data corruption, since there are
|
||||
@ -3518,7 +3538,15 @@
|
||||
The default parameter value of '0' causes the kernel
|
||||
not to attempt recovery of lost locks.
|
||||
|
||||
nfs4.layoutstats_timer =
|
||||
nfs.send_implementation_id=
|
||||
[NFSv4.1] Send client implementation identification
|
||||
information in exchange_id requests.
|
||||
If zero, no implementation identification information
|
||||
will be sent.
|
||||
The default is to send the implementation identification
|
||||
information.
|
||||
|
||||
nfs4.layoutstats_timer=
|
||||
[NFSv4.2] Change the rate at which the kernel sends
|
||||
layoutstats to the pNFS metadata server.
|
||||
|
||||
@ -3527,19 +3555,11 @@
|
||||
driver. A non-zero value sets the minimum interval
|
||||
in seconds between layoutstats transmissions.
|
||||
|
||||
nfsd.inter_copy_offload_enable =
|
||||
nfsd.inter_copy_offload_enable=
|
||||
[NFSv4.2] When set to 1, the server will support
|
||||
server-to-server copies for which this server is
|
||||
the destination of the copy.
|
||||
|
||||
nfsd.nfsd4_ssc_umount_timeout =
|
||||
[NFSv4.2] When used as the destination of a
|
||||
server-to-server copy, knfsd temporarily mounts
|
||||
the source server. It caches the mount in case
|
||||
it will be needed again, and discards it if not
|
||||
used for the number of milliseconds specified by
|
||||
this parameter.
|
||||
|
||||
nfsd.nfs4_disable_idmapping=
|
||||
[NFSv4] When set to the default of '1', the NFSv4
|
||||
server will return only numeric uids and gids to
|
||||
@ -3547,6 +3567,22 @@
|
||||
and gids from such clients. This is intended to ease
|
||||
migration from NFSv2/v3.
|
||||
|
||||
nfsd.nfsd4_ssc_umount_timeout=
|
||||
[NFSv4.2] When used as the destination of a
|
||||
server-to-server copy, knfsd temporarily mounts
|
||||
the source server. It caches the mount in case
|
||||
it will be needed again, and discards it if not
|
||||
used for the number of milliseconds specified by
|
||||
this parameter.
|
||||
|
||||
nfsaddrs= [NFS] Deprecated. Use ip= instead.
|
||||
See Documentation/admin-guide/nfs/nfsroot.rst.
|
||||
|
||||
nfsroot= [NFS] nfs root filesystem for disk-less boxes.
|
||||
See Documentation/admin-guide/nfs/nfsroot.rst.
|
||||
|
||||
nfsrootdebug [NFS] enable nfsroot debugging messages.
|
||||
See Documentation/admin-guide/nfs/nfsroot.rst.
|
||||
|
||||
nmi_backtrace.backtrace_idle [KNL]
|
||||
Dump stacks even of idle CPUs in response to an
|
||||
@ -3576,37 +3612,12 @@
|
||||
emulation library even if a 387 maths coprocessor
|
||||
is present.
|
||||
|
||||
no5lvl [X86-64] Disable 5-level paging mode. Forces
|
||||
no4lvl [RISCV] Disable 4-level and 5-level paging modes. Forces
|
||||
kernel to use 3-level paging instead.
|
||||
|
||||
no5lvl [X86-64,RISCV] Disable 5-level paging mode. Forces
|
||||
kernel to use 4-level paging instead.
|
||||
|
||||
nofsgsbase [X86] Disables FSGSBASE instructions.
|
||||
|
||||
no_console_suspend
|
||||
[HW] Never suspend the console
|
||||
Disable suspending of consoles during suspend and
|
||||
hibernate operations. Once disabled, debugging
|
||||
messages can reach various consoles while the rest
|
||||
of the system is being put to sleep (ie, while
|
||||
debugging driver suspend/resume hooks). This may
|
||||
not work reliably with all consoles, but is known
|
||||
to work with serial and VGA consoles.
|
||||
To facilitate more flexible debugging, we also add
|
||||
console_suspend, a printk module parameter to control
|
||||
it. Users could use console_suspend (usually
|
||||
/sys/module/printk/parameters/console_suspend) to
|
||||
turn on/off it dynamically.
|
||||
|
||||
novmcoredd [KNL,KDUMP]
|
||||
Disable device dump. Device dump allows drivers to
|
||||
append dump data to vmcore so you can collect driver
|
||||
specified debug info. Drivers can append the data
|
||||
without any limit and this data is stored in memory,
|
||||
so this may cause significant memory stress. Disabling
|
||||
device dump can help save memory but the driver debug
|
||||
data will be no longer available. This parameter
|
||||
is only available when CONFIG_PROC_VMCORE_DEVICE_DUMP
|
||||
is set.
|
||||
|
||||
noaliencache [MM, NUMA, SLAB] Disables the allocation of alien
|
||||
caches in the slab allocator. Saves per-node memory,
|
||||
but will impact performance.
|
||||
@ -3623,6 +3634,24 @@
|
||||
|
||||
nocache [ARM]
|
||||
|
||||
no_console_suspend
|
||||
[HW] Never suspend the console
|
||||
Disable suspending of consoles during suspend and
|
||||
hibernate operations. Once disabled, debugging
|
||||
messages can reach various consoles while the rest
|
||||
of the system is being put to sleep (ie, while
|
||||
debugging driver suspend/resume hooks). This may
|
||||
not work reliably with all consoles, but is known
|
||||
to work with serial and VGA consoles.
|
||||
To facilitate more flexible debugging, we also add
|
||||
console_suspend, a printk module parameter to control
|
||||
it. Users could use console_suspend (usually
|
||||
/sys/module/printk/parameters/console_suspend) to
|
||||
turn on/off it dynamically.
|
||||
|
||||
no_debug_objects
|
||||
[KNL] Disable object debugging
|
||||
|
||||
nodsp [SH] Disable hardware DSP at boot time.
|
||||
|
||||
noefi Disable EFI runtime services support.
|
||||
@ -3631,14 +3660,6 @@
|
||||
|
||||
noexec [IA-64]
|
||||
|
||||
nosmap [PPC]
|
||||
Disable SMAP (Supervisor Mode Access Prevention)
|
||||
even if it is supported by processor.
|
||||
|
||||
nosmep [PPC64s]
|
||||
Disable SMEP (Supervisor Mode Execution Prevention)
|
||||
even if it is supported by processor.
|
||||
|
||||
noexec32 [X86-64]
|
||||
This affects only 32-bit executables.
|
||||
noexec32=on: enable non-executable mappings (default)
|
||||
@ -3646,74 +3667,18 @@
|
||||
noexec32=off: disable non-executable mappings
|
||||
read implies executable mappings
|
||||
|
||||
no_file_caps Tells the kernel not to honor file capabilities. The
|
||||
only way then for a file to be executed with privilege
|
||||
is to be setuid root or executed by root.
|
||||
|
||||
nofpu [MIPS,SH] Disable hardware FPU at boot time.
|
||||
|
||||
nofsgsbase [X86] Disables FSGSBASE instructions.
|
||||
|
||||
nofxsr [BUGS=X86-32] Disables x86 floating point extended
|
||||
register save and restore. The kernel will only save
|
||||
legacy floating-point registers on task switch.
|
||||
|
||||
nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
|
||||
|
||||
nohugevmalloc [KNL,X86,PPC,ARM64] Disable kernel huge vmalloc mappings.
|
||||
|
||||
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
|
||||
Equivalent to smt=1.
|
||||
|
||||
[KNL,X86] Disable symmetric multithreading (SMT).
|
||||
nosmt=force: Force disable SMT, cannot be undone
|
||||
via the sysfs control file.
|
||||
|
||||
nospectre_v1 [X86,PPC] Disable mitigations for Spectre Variant 1
|
||||
(bounds check bypass). With this option data leaks are
|
||||
possible in the system.
|
||||
|
||||
nospectre_v2 [X86,PPC_E500,ARM64] Disable all mitigations for
|
||||
the Spectre variant 2 (indirect branch prediction)
|
||||
vulnerability. System may allow data leaks with this
|
||||
option.
|
||||
|
||||
nospectre_bhb [ARM64] Disable all mitigations for Spectre-BHB (branch
|
||||
history injection) vulnerability. System may allow data leaks
|
||||
with this option.
|
||||
|
||||
nospec_store_bypass_disable
|
||||
[HW] Disable all mitigations for the Speculative Store Bypass vulnerability
|
||||
|
||||
no_uaccess_flush
|
||||
[PPC] Don't flush the L1-D cache after accessing user data.
|
||||
|
||||
noxsave [BUGS=X86] Disables x86 extended register state save
|
||||
and restore using xsave. The kernel will fallback to
|
||||
enabling legacy floating-point and sse state.
|
||||
|
||||
noxsaveopt [X86] Disables xsaveopt used in saving x86 extended
|
||||
register states. The kernel will fall back to use
|
||||
xsave to save the states. By using this parameter,
|
||||
performance of saving the states is degraded because
|
||||
xsave doesn't support modified optimization while
|
||||
xsaveopt supports it on xsaveopt enabled systems.
|
||||
|
||||
noxsaves [X86] Disables xsaves and xrstors used in saving and
|
||||
restoring x86 extended register state in compacted
|
||||
form of xsave area. The kernel will fall back to use
|
||||
xsaveopt and xrstor to save and restore the states
|
||||
in standard form of xsave area. By using this
|
||||
parameter, xsave area per process might occupy more
|
||||
memory on xsaves enabled systems.
|
||||
|
||||
nohlt [ARM,ARM64,MICROBLAZE,SH] Forces the kernel to busy wait
|
||||
in do_idle() and not use the arch_cpu_idle()
|
||||
implementation; requires CONFIG_GENERIC_IDLE_POLL_SETUP
|
||||
to be effective. This is useful on platforms where the
|
||||
sleep(SH) or wfi(ARM,ARM64) instructions do not work
|
||||
correctly or when doing power measurements to evaluate
|
||||
the impact of the sleep instructions. This is also
|
||||
useful when using JTAG debugger.
|
||||
|
||||
no_file_caps Tells the kernel not to honor file capabilities. The
|
||||
only way then for a file to be executed with privilege
|
||||
is to be setuid root or executed by root.
|
||||
|
||||
nohalt [IA-64] Tells the kernel not to use the power saving
|
||||
function PAL_HALT_LIGHT when idle. This increases
|
||||
power-consumption. On the positive side, it reduces
|
||||
@ -3737,6 +3702,19 @@
|
||||
|
||||
nohibernate [HIBERNATION] Disable hibernation and resume.
|
||||
|
||||
nohlt [ARM,ARM64,MICROBLAZE,SH] Forces the kernel to busy wait
|
||||
in do_idle() and not use the arch_cpu_idle()
|
||||
implementation; requires CONFIG_GENERIC_IDLE_POLL_SETUP
|
||||
to be effective. This is useful on platforms where the
|
||||
sleep(SH) or wfi(ARM,ARM64) instructions do not work
|
||||
correctly or when doing power measurements to evaluate
|
||||
the impact of the sleep instructions. This is also
|
||||
useful when using JTAG debugger.
|
||||
|
||||
nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
|
||||
|
||||
nohugevmalloc [KNL,X86,PPC,ARM64] Disable kernel huge vmalloc mappings.
|
||||
|
||||
nohz= [KNL] Boottime enable/disable dynamic ticks
|
||||
Valid arguments: on, off
|
||||
Default: on
|
||||
@ -3754,16 +3732,6 @@
|
||||
Note that this argument takes precedence over
|
||||
the CONFIG_RCU_NOCB_CPU_DEFAULT_ALL option.
|
||||
|
||||
noiotrap [SH] Disables trapped I/O port accesses.
|
||||
|
||||
noirqdebug [X86-32] Disables the code which attempts to detect and
|
||||
disable unhandled interrupt sources.
|
||||
|
||||
no_timer_check [X86,APIC] Disables the code which tests for
|
||||
broken timer IRQ sources.
|
||||
|
||||
noisapnp [ISAPNP] Disables ISA PnP code.
|
||||
|
||||
noinitrd [RAM] Tells the kernel not to load any configured
|
||||
initial RAM disk.
|
||||
|
||||
@ -3775,6 +3743,13 @@
|
||||
|
||||
noinvpcid [X86] Disable the INVPCID cpu feature.
|
||||
|
||||
noiotrap [SH] Disables trapped I/O port accesses.
|
||||
|
||||
noirqdebug [X86-32] Disables the code which attempts to detect and
|
||||
disable unhandled interrupt sources.
|
||||
|
||||
noisapnp [ISAPNP] Disables ISA PnP code.
|
||||
|
||||
nojitter [IA-64] Disables jitter checking for ITC timers.
|
||||
|
||||
nokaslr [KNL]
|
||||
@ -3782,18 +3757,10 @@
|
||||
kernel and module base offset ASLR (Address Space
|
||||
Layout Randomization).
|
||||
|
||||
no-kvmclock [X86,KVM] Disable paravirtualized KVM clock driver
|
||||
|
||||
no-kvmapf [X86,KVM] Disable paravirtualized asynchronous page
|
||||
fault handling.
|
||||
|
||||
no-vmw-sched-clock
|
||||
[X86,PV_OPS] Disable paravirtualized VMware scheduler
|
||||
clock and use the default one.
|
||||
|
||||
no-steal-acc [X86,PV_OPS,ARM64,PPC/PSERIES] Disable paravirtualized
|
||||
steal time accounting. steal time is computed, but
|
||||
won't influence scheduler behaviour
|
||||
no-kvmclock [X86,KVM] Disable paravirtualized KVM clock driver
|
||||
|
||||
nolapic [X86-32,APIC] Do not enable or use the local APIC.
|
||||
|
||||
@ -3806,10 +3773,6 @@
|
||||
nomfgpt [X86-32] Disable Multi-Function General Purpose
|
||||
Timer usage (for AMD Geode machines).
|
||||
|
||||
nonmi_ipi [X86] Disable using NMI IPIs during panic/reboot to
|
||||
shutdown the other cpus. Instead use the REBOOT_VECTOR
|
||||
irq.
|
||||
|
||||
nomodeset Disable kernel modesetting. Most systems' firmware
|
||||
sets up a display mode and provides framebuffer memory
|
||||
for output. With nomodeset, DRM and fbdev drivers will
|
||||
@ -3822,6 +3785,10 @@
|
||||
|
||||
nomodule Disable module load
|
||||
|
||||
nonmi_ipi [X86] Disable using NMI IPIs during panic/reboot to
|
||||
shutdown the other cpus. Instead use the REBOOT_VECTOR
|
||||
irq.
|
||||
|
||||
nopat [X86] Disable PAT (page attribute table extension of
|
||||
pagetables) support.
|
||||
|
||||
@ -3830,6 +3797,9 @@
|
||||
nopku [X86] Disable Memory Protection Keys CPU feature found
|
||||
in some Intel CPUs.
|
||||
|
||||
nopti [X86-64]
|
||||
Equivalent to pti=off
|
||||
|
||||
nopv= [X86,XEN,KVM,HYPER_V,VMWARE]
|
||||
Disables the PV optimizations forcing the guest to run
|
||||
as generic guest with no PV drivers. Currently support
|
||||
@ -3849,21 +3819,77 @@
|
||||
noresume [SWSUSP] Disables resume and restores original swap
|
||||
space.
|
||||
|
||||
nosbagart [IA-64]
|
||||
|
||||
no-scroll [VGA] Disables scrollback.
|
||||
This is required for the Braillex ib80-piezo Braille
|
||||
reader made by F.H. Papenmeier (Germany).
|
||||
|
||||
nosbagart [IA-64]
|
||||
|
||||
nosgx [X86-64,SGX] Disables Intel SGX kernel support.
|
||||
|
||||
nosmap [PPC]
|
||||
Disable SMAP (Supervisor Mode Access Prevention)
|
||||
even if it is supported by processor.
|
||||
|
||||
nosmep [PPC64s]
|
||||
Disable SMEP (Supervisor Mode Execution Prevention)
|
||||
even if it is supported by processor.
|
||||
|
||||
nosmp [SMP] Tells an SMP kernel to act as a UP kernel,
|
||||
and disable the IO APIC. legacy for "maxcpus=0".
|
||||
|
||||
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
|
||||
Equivalent to smt=1.
|
||||
|
||||
[KNL,X86] Disable symmetric multithreading (SMT).
|
||||
nosmt=force: Force disable SMT, cannot be undone
|
||||
via the sysfs control file.
|
||||
|
||||
nosoftlockup [KNL] Disable the soft-lockup detector.
|
||||
|
||||
nospec_store_bypass_disable
|
||||
[HW] Disable all mitigations for the Speculative Store Bypass vulnerability
|
||||
|
||||
nospectre_bhb [ARM64] Disable all mitigations for Spectre-BHB (branch
|
||||
history injection) vulnerability. System may allow data leaks
|
||||
with this option.
|
||||
|
||||
nospectre_v1 [X86,PPC] Disable mitigations for Spectre Variant 1
|
||||
(bounds check bypass). With this option data leaks are
|
||||
possible in the system.
|
||||
|
||||
nospectre_v2 [X86,PPC_E500,ARM64] Disable all mitigations for
|
||||
the Spectre variant 2 (indirect branch prediction)
|
||||
vulnerability. System may allow data leaks with this
|
||||
option.
|
||||
|
||||
no-steal-acc [X86,PV_OPS,ARM64,PPC/PSERIES] Disable paravirtualized
|
||||
steal time accounting. steal time is computed, but
|
||||
won't influence scheduler behaviour
|
||||
|
||||
nosync [HW,M68K] Disables sync negotiation for all devices.
|
||||
|
||||
no_timer_check [X86,APIC] Disables the code which tests for
|
||||
broken timer IRQ sources.
|
||||
|
||||
no_uaccess_flush
|
||||
[PPC] Don't flush the L1-D cache after accessing user data.
|
||||
|
||||
novmcoredd [KNL,KDUMP]
|
||||
Disable device dump. Device dump allows drivers to
|
||||
append dump data to vmcore so you can collect driver
|
||||
specified debug info. Drivers can append the data
|
||||
without any limit and this data is stored in memory,
|
||||
so this may cause significant memory stress. Disabling
|
||||
device dump can help save memory but the driver debug
|
||||
data will be no longer available. This parameter
|
||||
is only available when CONFIG_PROC_VMCORE_DEVICE_DUMP
|
||||
is set.
|
||||
|
||||
no-vmw-sched-clock
|
||||
[X86,PV_OPS] Disable paravirtualized VMware scheduler
|
||||
clock and use the default one.
|
||||
|
||||
nowatchdog [KNL] Disable both lockup detectors, i.e.
|
||||
soft-lockup and NMI watchdog (hard-lockup).
|
||||
|
||||
@ -3875,6 +3901,25 @@
|
||||
LEGACY_XAPIC_DISABLED bit set in the
|
||||
IA32_XAPIC_DISABLE_STATUS MSR.
|
||||
|
||||
noxsave [BUGS=X86] Disables x86 extended register state save
|
||||
and restore using xsave. The kernel will fallback to
|
||||
enabling legacy floating-point and sse state.
|
||||
|
||||
noxsaveopt [X86] Disables xsaveopt used in saving x86 extended
|
||||
register states. The kernel will fall back to use
|
||||
xsave to save the states. By using this parameter,
|
||||
performance of saving the states is degraded because
|
||||
xsave doesn't support modified optimization while
|
||||
xsaveopt supports it on xsaveopt enabled systems.
|
||||
|
||||
noxsaves [X86] Disables xsaves and xrstors used in saving and
|
||||
restoring x86 extended register state in compacted
|
||||
form of xsave area. The kernel will fall back to use
|
||||
xsaveopt and xrstor to save and restore the states
|
||||
in standard form of xsave area. By using this
|
||||
parameter, xsave area per process might occupy more
|
||||
memory on xsaves enabled systems.
|
||||
|
||||
nps_mtm_hs_ctr= [KNL,ARC]
|
||||
This parameter sets the maximum duration, in
|
||||
cycles, each HW thread of the CTOP can run
|
||||
@ -3969,7 +4014,7 @@
|
||||
[KNL] Minimal page reporting order
|
||||
Format: <integer>
|
||||
Adjust the minimal page reporting order. The page
|
||||
reporting is disabled when it exceeds (MAX_ORDER-1).
|
||||
reporting is disabled when it exceeds MAX_ORDER.
|
||||
|
||||
panic= [KNL] Kernel behaviour on panic: delay <timeout>
|
||||
timeout > 0: seconds before rebooting
|
||||
@ -4410,7 +4455,7 @@
|
||||
and performance comparison.
|
||||
|
||||
pirq= [SMP,APIC] Manual mp-table setup
|
||||
See Documentation/x86/i386/IO-APIC.rst.
|
||||
See Documentation/arch/x86/i386/IO-APIC.rst.
|
||||
|
||||
plip= [PPT,NET] Parallel port network link
|
||||
Format: { parport<nr> | timid | 0 }
|
||||
@ -4582,9 +4627,6 @@
|
||||
|
||||
Not specifying this option is equivalent to pti=auto.
|
||||
|
||||
nopti [X86-64]
|
||||
Equivalent to pti=off
|
||||
|
||||
pty.legacy_count=
|
||||
[KNL] Number of legacy pty's. Overwrites compiled-in
|
||||
default number.
|
||||
@ -5591,7 +5633,7 @@
|
||||
|
||||
serialnumber [BUGS=X86-32]
|
||||
|
||||
sev=option[,option...] [X86-64] See Documentation/x86/x86_64/boot-options.rst
|
||||
sev=option[,option...] [X86-64] See Documentation/arch/x86/x86_64/boot-options.rst
|
||||
|
||||
shapers= [NET]
|
||||
Maximal number of shapers.
|
||||
@ -6130,15 +6172,6 @@
|
||||
later by a loaded module cannot be set this way.
|
||||
Example: sysctl.vm.swappiness=40
|
||||
|
||||
sysfs.deprecated=0|1 [KNL]
|
||||
Enable/disable old style sysfs layout for old udev
|
||||
on older distributions. When this option is enabled
|
||||
very new udev will not work anymore. When this option
|
||||
is disabled (or CONFIG_SYSFS_DEPRECATED not compiled)
|
||||
in older udev will not work anymore.
|
||||
Default depends on CONFIG_SYSFS_DEPRECATED_V2 set in
|
||||
the kernel configuration.
|
||||
|
||||
sysrq_always_enabled
|
||||
[KNL]
|
||||
Ignore sysrq setting - this boot parameter will
|
||||
@ -6770,7 +6803,7 @@
|
||||
Can be used multiple times for multiple devices.
|
||||
|
||||
vga= [BOOT,X86-32] Select a particular video mode
|
||||
See Documentation/x86/boot.rst and
|
||||
See Documentation/arch/x86/boot.rst and
|
||||
Documentation/admin-guide/svga.rst.
|
||||
Use vga=ask for menu.
|
||||
This is actually a boot loader parameter; the value is
|
||||
@ -6933,6 +6966,12 @@
|
||||
When enabled, memory and cache locality will be
|
||||
impacted.
|
||||
|
||||
writecombine= [LOONGARCH] Control the MAT (Memory Access Type) of
|
||||
ioremap_wc().
|
||||
|
||||
on - Enable writecombine, use WUC for ioremap_wc()
|
||||
off - Disable writecombine, use SUC for ioremap_wc()
|
||||
|
||||
x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of
|
||||
default x2apic cluster mode on platforms
|
||||
supporting x2apic.
|
||||
@ -7059,20 +7098,3 @@
|
||||
xmon commands.
|
||||
off xmon is disabled.
|
||||
|
||||
amd_pstate= [X86]
|
||||
disable
|
||||
Do not enable amd_pstate as the default
|
||||
scaling driver for the supported processors
|
||||
passive
|
||||
Use amd_pstate as a scaling driver, driver requests a
|
||||
desired performance on this abstract scale and the power
|
||||
management firmware translates the requests into actual
|
||||
hardware states (core frequency, data fabric and memory
|
||||
clocks etc.)
|
||||
active
|
||||
Use amd_pstate_epp driver instance as the scaling driver,
|
||||
driver provides a hint to the hardware if software wants
|
||||
to bias toward performance (0x0) or energy efficiency (0xff)
|
||||
to the CPPC firmware. then CPPC power algorithm will
|
||||
calculate the runtime workload and adjust the realtime cores
|
||||
frequency.
|
||||
|
||||
@ -55,6 +55,15 @@ Miscellaneous:
|
||||
you can control the CEC line through this driver. This supports error
|
||||
injection as well.
|
||||
|
||||
- cec-gpio and Allwinner A10 (or any other driver that uses the CEC pin
|
||||
framework to drive the CEC pin directly): the CEC pin framework uses
|
||||
high-resolution timers. These timers are affected by NTP daemons that
|
||||
speed up or slow down the clock to sync with the official time. The
|
||||
chronyd server will by default increase or decrease the clock by
|
||||
1/12th. This will cause the CEC timings to go out of spec. To fix this,
|
||||
add a 'maxslewrate 40000' line to chronyd.conf. This limits the clock
|
||||
frequency change to 1/25th, which keeps the CEC timings within spec.
|
||||
|
||||
|
||||
Utilities
|
||||
=========
|
||||
@ -296,69 +305,71 @@ broadcast messages twice to reduce the chance of them being lost. Specifically
|
||||
Making a CEC debugger
|
||||
=====================
|
||||
|
||||
By using a Raspberry Pi 2B/3/4 and some cheap components you can make
|
||||
By using a Raspberry Pi 4B and some cheap components you can make
|
||||
your own low-level CEC debugger.
|
||||
|
||||
Here is a picture of my setup:
|
||||
|
||||
https://hverkuil.home.xs4all.nl/rpi3-cec.jpg
|
||||
|
||||
It's a Raspberry Pi 3 together with a breadboard and some breadboard wires:
|
||||
|
||||
http://www.dx.com/p/diy-40p-male-to-female-male-to-male-female-to-female-dupont-line-wire-3pcs-356089#.WYLOOXWGN7I
|
||||
|
||||
Finally on of these HDMI female-female passthrough connectors (full soldering type 1):
|
||||
The critical component is one of these HDMI female-female passthrough connectors
|
||||
(full soldering type 1):
|
||||
|
||||
https://elabbay.myshopify.com/collections/camera/products/hdmi-af-af-v1a-hdmi-type-a-female-to-hdmi-type-a-female-pass-through-adapter-breakout-board?variant=45533926147
|
||||
|
||||
We've tested this and it works up to 4kp30 (297 MHz). The quality is not high
|
||||
enough to pass-through 4kp60 (594 MHz).
|
||||
The video quality is variable and certainly not enough to pass-through 4kp60
|
||||
(594 MHz) video. You might be able to support 4kp30, but more likely you will
|
||||
be limited to 1080p60 (148.5 MHz). But for CEC testing that is fine.
|
||||
|
||||
I also added an RTC and a breakout shield:
|
||||
You need a breadboard and some breadboard wires:
|
||||
|
||||
https://www.amazon.com/Makerfire%C2%AE-Raspberry-Module-DS1307-Battery/dp/B00ZOXWHK4
|
||||
http://www.dx.com/p/diy-40p-male-to-female-male-to-male-female-to-female-dupont-line-wire-3pcs-356089#.WYLOOXWGN7I
|
||||
|
||||
https://www.dx.com/p/raspberry-pi-gpio-expansion-board-breadboard-easy-multiplexing-board-one-to-three-with-screw-for-raspberry-pi-2-3-b-b-2729992.html#.YGRCG0MzZ7I
|
||||
|
||||
These two are not needed but they make life a bit easier.
|
||||
|
||||
If you want to monitor the HPD line as well, then you need one of these
|
||||
level shifters:
|
||||
If you want to monitor the HPD and/or 5V lines as well, then you need one of
|
||||
these 5V to 3.3V level shifters:
|
||||
|
||||
https://www.adafruit.com/product/757
|
||||
|
||||
(This is just where I got these components, there are many other places you
|
||||
can get similar things).
|
||||
|
||||
The CEC pin of the HDMI connector needs to be connected to these pins:
|
||||
CE0/IO8 and CE1/IO7 (pull-up GPIOs). The (optional) HPD pin of the HDMI
|
||||
connector should be connected (via a level shifter to convert the 5V
|
||||
to 3.3V) to these pins: IO17 and IO27. The (optional) 5V pin of the HDMI
|
||||
connector should be connected (via a level shifter) to these pins: IO22
|
||||
and IO24. Monitoring the HPD an 5V lines is not necessary, but it is helpful.
|
||||
The ground pin of the HDMI connector needs to be connected to a ground
|
||||
pin of the Raspberry Pi, of course.
|
||||
|
||||
This kernel patch will hook up the cec-gpio driver correctly to
|
||||
e.g. ``arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts``::
|
||||
The CEC pin of the HDMI connector needs to be connected to these pins:
|
||||
GPIO 6 and GPIO 7. The optional HPD pin of the HDMI connector should
|
||||
be connected via the level shifter to these pins: GPIO 23 and GPIO 12.
|
||||
The optional 5V pin of the HDMI connector should be connected via the
|
||||
level shifter to these pins: GPIO 25 and GPIO 22. Monitoring the HPD and
|
||||
5V lines is not necessary, but it is helpful.
|
||||
|
||||
This device tree addition in ``arch/arm/boot/dts/bcm2711-rpi-4-b.dts``
|
||||
will hook up the cec-gpio driver correctly::
|
||||
|
||||
cec@6 {
|
||||
compatible = "cec-gpio";
|
||||
cec-gpios = <&gpio 6 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
|
||||
hpd-gpios = <&gpio 23 GPIO_ACTIVE_HIGH>;
|
||||
v5-gpios = <&gpio 25 GPIO_ACTIVE_HIGH>;
|
||||
};
|
||||
|
||||
cec@7 {
|
||||
compatible = "cec-gpio";
|
||||
cec-gpios = <&gpio 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
|
||||
hpd-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
|
||||
hpd-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>;
|
||||
v5-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
|
||||
};
|
||||
|
||||
cec@8 {
|
||||
compatible = "cec-gpio";
|
||||
cec-gpios = <&gpio 8 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
|
||||
hpd-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>;
|
||||
v5-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>;
|
||||
};
|
||||
If you haven't hooked up the HPD and/or 5V lines, then just delete those
|
||||
lines.
|
||||
|
||||
This dts change will enable two cec GPIO devices: I typically use one to
|
||||
send/receive CEC commands and the other to monitor. If you monitor using
|
||||
an unconfigured CEC adapter then it will use GPIO interrupts which makes
|
||||
monitoring very accurate.
|
||||
|
||||
If you just want to monitor traffic, then a single instance is sufficient.
|
||||
The minimum configuration is one HDMI female-female passthrough connector
|
||||
and two female-female breadboard wires: one for connecting the HDMI ground
|
||||
pin to a ground pin on the Raspberry Pi, and the other to connect the HDMI
|
||||
CEC pin to GPIO 6 on the Raspberry Pi.
|
||||
|
||||
The documentation on how to use the error injection is here: :ref:`cec_pin_error_inj`.
|
||||
|
||||
``cec-ctl --monitor-pin`` will do low-level CEC bus sniffing and analysis.
|
||||
|
||||
@ -72,17 +72,13 @@ imx319 Sony IMX319 sensor
|
||||
imx334 Sony IMX334 sensor
|
||||
imx355 Sony IMX355 sensor
|
||||
imx412 Sony IMX412 sensor
|
||||
m5mols Fujitsu M-5MOLS 8MP sensor
|
||||
mt9m001 mt9m001
|
||||
mt9m032 MT9M032 camera sensor
|
||||
mt9m111 mt9m111, mt9m112 and mt9m131
|
||||
mt9p031 Aptina MT9P031
|
||||
mt9t001 Aptina MT9T001
|
||||
mt9t112 Aptina MT9T111/MT9T112
|
||||
mt9v011 Micron mt9v011 sensor
|
||||
mt9v032 Micron MT9V032 sensor
|
||||
mt9v111 Aptina MT9V111 sensor
|
||||
noon010pc30 Siliconfile NOON010PC30 sensor
|
||||
ov13858 OmniVision OV13858 sensor
|
||||
ov13b10 OmniVision OV13B10 sensor
|
||||
ov2640 OmniVision OV2640 sensor
|
||||
@ -109,9 +105,6 @@ s5c73m3 Samsung S5C73M3 sensor
|
||||
s5k4ecgx Samsung S5K4ECGX sensor
|
||||
s5k5baf Samsung S5K5BAF sensor
|
||||
s5k6a3 Samsung S5K6A3 sensor
|
||||
s5k6aa Samsung S5K6AAFX sensor
|
||||
sr030pc30 Siliconfile SR030PC30 sensor
|
||||
vs6624 ST VS6624 sensor
|
||||
============ ==========================================================
|
||||
|
||||
Flash devices
|
||||
@ -222,7 +215,6 @@ Video encoders
|
||||
============ ==========================================================
|
||||
Driver Name
|
||||
============ ==========================================================
|
||||
ad9389b Analog Devices AD9389B encoder
|
||||
adv7170 Analog Devices ADV7170 video encoder
|
||||
adv7175 Analog Devices ADV7175 video encoder
|
||||
adv7343 ADV7343 video encoder
|
||||
|
||||
@ -20,7 +20,7 @@ content which can be replaced by a single write-protected page (which
|
||||
is automatically copied if a process later wants to update its
|
||||
content). The amount of pages that KSM daemon scans in a single pass
|
||||
and the time between the passes are configured using :ref:`sysfs
|
||||
intraface <ksm_sysfs>`
|
||||
interface <ksm_sysfs>`
|
||||
|
||||
KSM only merges anonymous (private) pages, never pagecache (file) pages.
|
||||
KSM's merged pages were originally locked into kernel memory, but can now
|
||||
@ -157,6 +157,8 @@ stable_node_chains_prune_millisecs
|
||||
|
||||
The effectiveness of KSM and MADV_MERGEABLE is shown in ``/sys/kernel/mm/ksm/``:
|
||||
|
||||
general_profit
|
||||
how effective is KSM. The calculation is explained below.
|
||||
pages_shared
|
||||
how many shared pages are being used
|
||||
pages_sharing
|
||||
@ -207,7 +209,8 @@ several times, which are unprofitable memory consumed.
|
||||
ksm_rmap_items * sizeof(rmap_item).
|
||||
|
||||
where ksm_merging_pages is shown under the directory ``/proc/<pid>/``,
|
||||
and ksm_rmap_items is shown in ``/proc/<pid>/ksm_stat``.
|
||||
and ksm_rmap_items is shown in ``/proc/<pid>/ksm_stat``. The process profit
|
||||
is also shown in ``/proc/<pid>/ksm_stat`` as ksm_process_profit.
|
||||
|
||||
From the perspective of application, a high ratio of ``ksm_rmap_items`` to
|
||||
``ksm_merging_pages`` means a bad madvise-applied policy, so developers or
|
||||
|
||||
@ -91,9 +91,9 @@ Short descriptions to the page flags
|
||||
The page is being locked for exclusive access, e.g. by undergoing read/write
|
||||
IO.
|
||||
7 - SLAB
|
||||
The page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator.
|
||||
When compound page is used, SLUB/SLQB will only set this flag on the head
|
||||
page; SLOB will not flag it at all.
|
||||
The page is managed by the SLAB/SLUB kernel memory allocator.
|
||||
When compound page is used, either will only set this flag on the head
|
||||
page.
|
||||
10 - BUDDY
|
||||
A free memory block managed by the buddy system allocator.
|
||||
The buddy system organizes free memory in blocks of various orders.
|
||||
|
||||
@ -219,6 +219,31 @@ former will have ``UFFD_PAGEFAULT_FLAG_WP`` set, the latter
|
||||
you still need to supply a page when ``UFFDIO_REGISTER_MODE_MISSING`` was
|
||||
used.
|
||||
|
||||
Userfaultfd write-protect mode currently behave differently on none ptes
|
||||
(when e.g. page is missing) over different types of memories.
|
||||
|
||||
For anonymous memory, ``ioctl(UFFDIO_WRITEPROTECT)`` will ignore none ptes
|
||||
(e.g. when pages are missing and not populated). For file-backed memories
|
||||
like shmem and hugetlbfs, none ptes will be write protected just like a
|
||||
present pte. In other words, there will be a userfaultfd write fault
|
||||
message generated when writing to a missing page on file typed memories,
|
||||
as long as the page range was write-protected before. Such a message will
|
||||
not be generated on anonymous memories by default.
|
||||
|
||||
If the application wants to be able to write protect none ptes on anonymous
|
||||
memory, one can pre-populate the memory with e.g. MADV_POPULATE_READ. On
|
||||
newer kernels, one can also detect the feature UFFD_FEATURE_WP_UNPOPULATED
|
||||
and set the feature bit in advance to make sure none ptes will also be
|
||||
write protected even upon anonymous memory.
|
||||
|
||||
When using ``UFFDIO_REGISTER_MODE_WP`` in combination with either
|
||||
``UFFDIO_REGISTER_MODE_MISSING`` or ``UFFDIO_REGISTER_MODE_MINOR``, when
|
||||
resolving missing / minor faults with ``UFFDIO_COPY`` or ``UFFDIO_CONTINUE``
|
||||
respectively, it may be desirable for the new page / mapping to be
|
||||
write-protected (so future writes will also result in a WP fault). These ioctls
|
||||
support a mode flag (``UFFDIO_COPY_MODE_WP`` or ``UFFDIO_CONTINUE_MODE_WP``
|
||||
respectively) to configure the mapping this way.
|
||||
|
||||
QEMU/KVM
|
||||
========
|
||||
|
||||
|
||||
@ -303,13 +303,18 @@ efficiency frequency management method on AMD processors.
|
||||
AMD Pstate Driver Operation Modes
|
||||
=================================
|
||||
|
||||
``amd_pstate`` CPPC has two operation modes: CPPC Autonomous(active) mode and
|
||||
CPPC non-autonomous(passive) mode.
|
||||
active mode and passive mode can be chosen by different kernel parameters.
|
||||
When in Autonomous mode, CPPC ignores requests done in the Desired Performance
|
||||
Target register and takes into account only the values set to the Minimum requested
|
||||
performance, Maximum requested performance, and Energy Performance Preference
|
||||
registers. When Autonomous is disabled, it only considers the Desired Performance Target.
|
||||
``amd_pstate`` CPPC has 3 operation modes: autonomous (active) mode,
|
||||
non-autonomous (passive) mode and guided autonomous (guided) mode.
|
||||
Active/passive/guided mode can be chosen by different kernel parameters.
|
||||
|
||||
- In autonomous mode, platform ignores the desired performance level request
|
||||
and takes into account only the values set to the minimum, maximum and energy
|
||||
performance preference registers.
|
||||
- In non-autonomous mode, platform gets desired performance level
|
||||
from OS directly through Desired Performance Register.
|
||||
- In guided-autonomous mode, platform sets operating performance level
|
||||
autonomously according to the current workload and within the limits set by
|
||||
OS through min and max performance registers.
|
||||
|
||||
Active Mode
|
||||
------------
|
||||
@ -338,6 +343,15 @@ to the Performance Reduction Tolerance register. Above the nominal performance l
|
||||
processor must provide at least nominal performance requested and go higher if current
|
||||
operating conditions allow.
|
||||
|
||||
Guided Mode
|
||||
-----------
|
||||
|
||||
``amd_pstate=guided``
|
||||
|
||||
If ``amd_pstate=guided`` is passed to kernel command line option then this mode
|
||||
is activated. In this mode, driver requests minimum and maximum performance
|
||||
level and the platform autonomously selects a performance level in this range
|
||||
and appropriate to the current workload.
|
||||
|
||||
User Space Interface in ``sysfs`` - General
|
||||
===========================================
|
||||
@ -358,6 +372,9 @@ control its functionality at the system level. They are located in the
|
||||
"passive"
|
||||
The driver is functional and in the ``passive mode``
|
||||
|
||||
"guided"
|
||||
The driver is functional and in the ``guided mode``
|
||||
|
||||
"disable"
|
||||
The driver is unregistered and not functional now.
|
||||
|
||||
|
||||
1092
Documentation/admin-guide/quickly-build-trimmed-linux.rst
Normal file
1092
Documentation/admin-guide/quickly-build-trimmed-linux.rst
Normal file
File diff suppressed because it is too large
Load Diff
@ -199,7 +199,7 @@ Architecture (MCA)\ [#f3]_.
|
||||
mode).
|
||||
|
||||
.. [#f3] For more details about the Machine Check Architecture (MCA),
|
||||
please read Documentation/x86/x86_64/machinecheck.rst at the Kernel tree.
|
||||
please read Documentation/arch/x86/x86_64/machinecheck.rst at the Kernel tree.
|
||||
|
||||
EDAC - Error Detection And Correction
|
||||
*************************************
|
||||
|
||||
@ -395,7 +395,7 @@ might want to be aware of; it for example explains how to add your issue to the
|
||||
list of tracked regressions, to ensure it won't fall through the cracks.
|
||||
|
||||
What qualifies as security issue is left to your judgment. Consider reading
|
||||
Documentation/admin-guide/security-bugs.rst before proceeding, as it
|
||||
Documentation/process/security-bugs.rst before proceeding, as it
|
||||
provides additional details how to best handle security issues.
|
||||
|
||||
An issue is a 'really severe problem' when something totally unacceptably bad
|
||||
@ -1269,7 +1269,7 @@ them when sending the report by mail. If you filed it in a bug tracker, forward
|
||||
the report's text to these addresses; but on top of it put a small note where
|
||||
you mention that you filed it with a link to the ticket.
|
||||
|
||||
See Documentation/admin-guide/security-bugs.rst for more information.
|
||||
See Documentation/process/security-bugs.rst for more information.
|
||||
|
||||
|
||||
Duties after the report went out
|
||||
|
||||
@ -33,8 +33,11 @@ The format of this option is::
|
||||
9600n8. The maximum baudrate is 115200.
|
||||
|
||||
You can specify multiple console= options on the kernel command line.
|
||||
Output will appear on all of them. The last device will be used when
|
||||
you open ``/dev/console``. So, for example::
|
||||
|
||||
The behavior is well defined when each device type is mentioned only once.
|
||||
In this case, the output will appear on all requested consoles. And
|
||||
the last device will be used when you open ``/dev/console``.
|
||||
So, for example::
|
||||
|
||||
console=ttyS1,9600 console=tty0
|
||||
|
||||
@ -42,7 +45,34 @@ defines that opening ``/dev/console`` will get you the current foreground
|
||||
virtual console, and kernel messages will appear on both the VGA
|
||||
console and the 2nd serial port (ttyS1 or COM2) at 9600 baud.
|
||||
|
||||
Note that you can only define one console per device type (serial, video).
|
||||
The behavior is more complicated when the same device type is defined more
|
||||
times. In this case, there are the following two rules:
|
||||
|
||||
1. The output will appear only on the first device of each defined type.
|
||||
|
||||
2. ``/dev/console`` will be associated with the first registered device.
|
||||
Where the registration order depends on how kernel initializes various
|
||||
subsystems.
|
||||
|
||||
This rule is used also when the last console= parameter is not used
|
||||
for other reasons. For example, because of a typo or because
|
||||
the hardware is not available.
|
||||
|
||||
The result might be surprising. For example, the following two command
|
||||
lines have the same result:
|
||||
|
||||
console=ttyS1,9600 console=tty0 console=tty1
|
||||
console=tty0 console=ttyS1,9600 console=tty1
|
||||
|
||||
The kernel messages are printed only on ``tty0`` and ``ttyS1``. And
|
||||
``/dev/console`` gets associated with ``tty0``. It is because kernel
|
||||
tries to register graphical consoles before serial ones. It does it
|
||||
because of the default behavior when no console device is specified,
|
||||
see below.
|
||||
|
||||
Note that the last ``console=tty1`` parameter still makes a difference.
|
||||
The kernel command line is used also by systemd. It would use the last
|
||||
defined ``tty1`` as the login console.
|
||||
|
||||
If no console device is specified, the first device found capable of
|
||||
acting as a system console will be used. At this time, the system
|
||||
|
||||
@ -73,6 +73,10 @@ thread-wide, without the need to invoke the kernel directly. selector
|
||||
can be set to SYSCALL_DISPATCH_FILTER_ALLOW or SYSCALL_DISPATCH_FILTER_BLOCK.
|
||||
Any other value should terminate the program with a SIGSYS.
|
||||
|
||||
Additionally, a tasks syscall user dispatch configuration can be peeked
|
||||
and poked via the PTRACE_(GET|SET)_SYSCALL_USER_DISPATCH_CONFIG ptrace
|
||||
requests. This is useful for checkpoint/restart software.
|
||||
|
||||
Security Notes
|
||||
--------------
|
||||
|
||||
|
||||
@ -95,7 +95,7 @@ is 0x15 and the full version number is 0x234, this file will contain
|
||||
the value 340 = 0x154.
|
||||
|
||||
See the ``type_of_loader`` and ``ext_loader_type`` fields in
|
||||
Documentation/x86/boot.rst for additional information.
|
||||
Documentation/arch/x86/boot.rst for additional information.
|
||||
|
||||
|
||||
bootloader_version (x86 only)
|
||||
@ -105,7 +105,7 @@ The complete bootloader version number. In the example above, this
|
||||
file will contain the value 564 = 0x234.
|
||||
|
||||
See the ``type_of_loader`` and ``ext_loader_ver`` fields in
|
||||
Documentation/x86/boot.rst for additional information.
|
||||
Documentation/arch/x86/boot.rst for additional information.
|
||||
|
||||
|
||||
bpf_stats_enabled
|
||||
|
||||
@ -3,11 +3,10 @@ Unicode support
|
||||
|
||||
Last update: 2005-01-17, version 1.4
|
||||
|
||||
This file is maintained by H. Peter Anvin <unicode@lanana.org> as part
|
||||
of the Linux Assigned Names And Numbers Authority (LANANA) project.
|
||||
The current version can be found at:
|
||||
|
||||
http://www.lanana.org/docs/unicode/admin-guide/unicode.rst
|
||||
Note: The original version of this document, which was maintained at
|
||||
lanana.org as part of the Linux Assigned Names And Numbers Authority
|
||||
(LANANA) project, is no longer existent. So, this version in the
|
||||
mainline Linux kernel is now the maintained main document.
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
@ -236,13 +236,14 @@ the dates listed above.
|
||||
Deprecated Mount Options
|
||||
========================
|
||||
|
||||
=========================== ================
|
||||
============================ ================
|
||||
Name Removal Schedule
|
||||
=========================== ================
|
||||
============================ ================
|
||||
Mounting with V4 filesystem September 2030
|
||||
Mounting ascii-ci filesystem September 2030
|
||||
ikeep/noikeep September 2025
|
||||
attr2/noattr2 September 2025
|
||||
=========================== ================
|
||||
============================ ================
|
||||
|
||||
|
||||
Removed Mount Options
|
||||
|
||||
@ -10,18 +10,18 @@ implementation.
|
||||
:maxdepth: 2
|
||||
|
||||
arc/index
|
||||
arm/index
|
||||
arm64/index
|
||||
../arm/index
|
||||
../arm64/index
|
||||
ia64/index
|
||||
loongarch/index
|
||||
../loongarch/index
|
||||
m68k/index
|
||||
mips/index
|
||||
../mips/index
|
||||
nios2/index
|
||||
openrisc/index
|
||||
parisc/index
|
||||
powerpc/index
|
||||
riscv/index
|
||||
s390/index
|
||||
../powerpc/index
|
||||
../riscv/index
|
||||
../s390/index
|
||||
sh/index
|
||||
sparc/index
|
||||
x86/index
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user