Skip to content

L
linux
Commit e42f6f9b authored by James Morris's avatar James Morris
Browse files
Options

Merge tag 'v4.19-rc2' into next-general 

Sync to Linux 4.19-rc2 for downstream developers.
parents 4408e300 57361846
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 29575 additions and 9810 deletions

Too many changes to show.
Plain diff Email patch

To preserve performance only 1000 of 1000+ files are displayed.

.clang-format
View file @ e42f6f9b
......@@ -382,7 +382,7 @@ IncludeIsMainRegex: '(Test)?$'
IndentCaseLabels: false
#IndentPPDirectives: None # Unknown to clang-format-5.0
IndentWidth: 8
IndentWrappedFunctionNames: true
IndentWrappedFunctionNames: false
JavaScriptQuotes: Leave
JavaScriptWrapImports: true
KeepEmptyLinesAtTheStartOfBlocks: false
......
.mailmap
View file @ e42f6f9b
......@@ -31,6 +31,8 @@ Arnaud Patard <arnaud.patard@rtp-net.org>
Arnd Bergmann <arnd@arndb.de>
Axel Dyks <xl@xlsigned.net>
Axel Lin <axel.lin@gmail.com>
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@wdc.com>
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@sandisk.com>
Ben Gardner <bgardner@wabtec.com>
Ben M Cahill <ben.m.cahill@intel.com>
Björn Steinbrink <B.Steinbrink@gmx.de>
......@@ -81,6 +83,9 @@ Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
Jean Tourrilhes <jt@hpl.hp.com>
Jeff Garzik <jgarzik@pretzel.yyz.us>
Jeff Layton <jlayton@kernel.org> <jlayton@redhat.com>
Jeff Layton <jlayton@kernel.org> <jlayton@poochiereds.net>
Jeff Layton <jlayton@kernel.org> <jlayton@primarydata.com>
Jens Axboe <axboe@suse.de>
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
Johan Hovold <johan@kernel.org> <jhovold@gmail.com>
......@@ -154,6 +159,7 @@ Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Randy Dunlap <rdunlap@infradead.org> <rdunlap@xenotime.net>
Rémi Denis-Courmont <rdenis@simphalempin.com>
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Ross Zwisler <zwisler@kernel.org> <ross.zwisler@linux.intel.com>
Rudolf Marek <R.Marek@sh.cvut.cz>
Rui Saraiva <rmps@joel.ist.utl.pt>
Sachin P Sant <ssant@in.ibm.com>
......
CREDITS
View file @ e42f6f9b
......@@ -2571,6 +2571,11 @@ S: Helstorfer Str. 7
S: D-30625 Hannover
S: Germany
N: Ron Minnich
E: rminnich@sandia.gov
E: rminnich@gmail.com
D: 9p filesystem development
N: Corey Minyard
E: minyard@wf-rch.cirr.com
E: minyard@mvista.com
......
Documentation/ABI/obsolete/sysfs-class-typec 0 → 100644
View file @ e42f6f9b
These files are deprecated and will be removed. The same files are available
under /sys/bus/typec (see Documentation/ABI/testing/sysfs-bus-typec).
What: /sys/class/typec/<port|partner|cable>/<dev>/svid
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The SVID (Standard or Vendor ID) assigned by USB-IF for this
alternate mode.
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Every supported mode will have its own directory. The name of
a mode will be "mode<index>" (for example mode1), where <index>
is the actual index to the mode VDO returned by Discover Modes
USB power delivery command.
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/description
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows description of the mode. The description is optional for
the drivers, just like with the Billboard Devices.
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/vdo
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows the VDO in hexadecimal returned by Discover Modes command
for this mode.
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/active
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows if the mode is active or not. The attribute can be used
for entering/exiting the mode with partners and cable plugs, and
with the port alternate modes it can be used for disabling
support for specific alternate modes. Entering/exiting modes is
supported as synchronous operation so write(2) to the attribute
does not return until the enter/exit mode operation has
finished. The attribute is notified when the mode is
entered/exited so poll(2) on the attribute wakes up.
Entering/exiting a mode will also generate uevent KOBJ_CHANGE.
Valid values: yes, no
Documentation/ABI/stable/sysfs-bus-vmbus
View file @ e42f6f9b
......@@ -42,6 +42,13 @@ Contact: K. Y. Srinivasan <kys@microsoft.com>
Description: The 16 bit vendor ID of the device
Users: tools/hv/lsvmbus and user level RDMA libraries
What: /sys/bus/vmbus/devices/<UUID>/numa_node
Date: Jul 2018
KernelVersion: 4.19
Contact: Stephen Hemminger <sthemmin@microsoft.com>
Description: This NUMA node to which the VMBUS device is
attached, or -1 if the node is unknown.
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>
Date: September. 2017
KernelVersion: 4.14
......
Documentation/ABI/stable/sysfs-bus-xen-backend
View file @ e42f6f9b
......@@ -73,3 +73,12 @@ KernelVersion: 3.0
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Number of sectors written by the frontend.
What: /sys/bus/xen-backend/devices/*/state
Date: August 2018
KernelVersion: 4.19
Contact: Joe Jin <joe.jin@oracle.com>
Description:
The state of the device. One of: 'Unknown',
'Initialising', 'Initialised', 'Connected', 'Closing',
'Closed', 'Reconfiguring', 'Reconfigured'.
Documentation/ABI/stable/sysfs-class-rfkill
View file @ e42f6f9b
......@@ -11,7 +11,7 @@ KernelVersion: v2.6.22
Contact: linux-wireless@vger.kernel.org,
Description: The rfkill class subsystem folder.
Each registered rfkill driver is represented by an rfkillX
subfolder (X being an integer > 0).
subfolder (X being an integer >= 0).
What: /sys/class/rfkill/rfkill[0-9]+/name
......@@ -48,8 +48,8 @@ Contact: linux-wireless@vger.kernel.org
Description: Current state of the transmitter.
This file was scheduled to be removed in 2014, but due to its
large number of users it will be sticking around for a bit
longer. Despite it being marked as stabe, the newer "hard" and
"soft" interfaces should be preffered, since it is not possible
longer. Despite it being marked as stable, the newer "hard" and
"soft" interfaces should be preferred, since it is not possible
to express the 'soft and hard block' state of the rfkill driver
through this interface. There will likely be another attempt to
remove it in the future.
......
Documentation/ABI/stable/sysfs-driver-mlxreg-io 0 → 100644
View file @ e42f6f9b
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/
asic_health
Date: June 2018
KernelVersion: 4.19
Contact: Vadim Pasternak <vadimpmellanox.com>
Description: This file shows ASIC health status. The possible values are:
0 - health failed, 2 - health OK, 3 - ASIC in booting state.
The files are read only.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/
cpld1_version
cpld2_version
Date: June 2018
KernelVersion: 4.19
Contact: Vadim Pasternak <vadimpmellanox.com>
Description: These files show with which CPLD versions have been burned
on carrier and switch boards.
The files are read only.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/select_iio
Date: June 2018
KernelVersion: 4.19
Contact: Vadim Pasternak <vadimpmellanox.com>
Description: This file allows iio devices selection.
Attribute select_iio can be written with 0 or with 1. It
selects which one of iio devices can be accessed.
The file is read/write.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu1_on
/sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu2_on
/sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_cycle
/sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_down
Date: June 2018
KernelVersion: 4.19
Contact: Vadim Pasternak <vadimpmellanox.com>
Description: These files allow asserting system power cycling, switching
power supply units on and off and system's main power domain
shutdown.
Expected behavior:
When pwr_cycle is written 1: auxiliary power domain will go
down and after short period (about 1 second) up.
When psu1_on or psu2_on is written 1, related unit will be
disconnected from the power source, when written 0 - connected.
If both are written 1 - power supplies main power domain will
go down.
When pwr_down is written 1, system's main power domain will go
down.
The files are write only.
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/
reset_aux_pwr_or_ref
reset_asic_thermal
reset_hotswap_or_halt
reset_hotswap_or_wd
reset_fw_reset
reset_long_pb
reset_main_pwr_fail
reset_short_pb
reset_sw_reset
Date: June 2018
KernelVersion: 4.19
Contact: Vadim Pasternak <vadimpmellanox.com>
Description: These files show the system reset cause, as following: power
auxiliary outage or power refresh, ASIC thermal shutdown, halt,
hotswap, watchdog, firmware reset, long press power button,
short press power button, software reset. Value 1 in file means
this is reset cause, 0 - otherwise. Only one of the above
causes could be 1 at the same time, representing only last
reset cause.
The files are read only.
Documentation/ABI/testing/configfs-usb-gadget-uvc
View file @ e42f6f9b
......@@ -263,3 +263,8 @@ Description: Specific streaming header descriptors
is connected
bmInfo - capabilities of this video streaming
interface
What: /sys/class/udc/udc.name/device/gadget/video4linux/video.name/function_name
Date: May 2018
KernelVersion: 4.19
Description: UVC configfs function instance name
Documentation/ABI/testing/ppc-memtrace
View file @ e42f6f9b
......@@ -13,10 +13,11 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: Write an integer containing the size in bytes of the memory
you want removed from each NUMA node to this file - it must be
aligned to the memblock size. This amount of RAM will be removed
from the kernel mappings and the following debugfs files will be
created. This can only be successfully done once per boot. Once
memory is successfully removed from each node, the following
files are created.
from each NUMA node in the kernel mappings and the following
debugfs files will be created. Once memory is successfully
removed from each node, the following files are created. To
re-add memory to the kernel, echo 0 into this file (it will be
automatically onlined).
What: /sys/kernel/debug/powerpc/memtrace/<node-id>
Date: Aug 2017
......
Documentation/ABI/testing/procfs-diskstats
View file @ e42f6f9b
......@@ -5,6 +5,7 @@ Description:
The /proc/diskstats file displays the I/O statistics
of block devices. Each line contains the following 14
fields:
1 - major number
2 - minor mumber
3 - device name
......@@ -19,4 +20,13 @@ Description:
12 - I/Os currently in progress
13 - time spent doing I/Os (ms)
14 - weighted time spent doing I/Os (ms)
Kernel 4.18+ appends four more fields for discard
tracking putting the total at 18:
15 - discards completed successfully
16 - discards merged
17 - sectors discarded
18 - time spent discarding
For more details refer to Documentation/iostats.txt
Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
View file @ e42f6f9b
......@@ -83,3 +83,11 @@ KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the capabilities of the Coresight TMC.
The value is read directly from the DEVID register, 0xFC8,
What: /sys/bus/coresight/devices/<memory_map>.tmc/buffer_size
Date: December 2018
KernelVersion: 4.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Size of the trace buffer for TMC-ETR when used in SYSFS
mode. Writable only for TMC-ETR configurations. The value
should be aligned to the kernel pagesize.
Documentation/ABI/testing/sysfs-bus-iio
View file @ e42f6f9b
......@@ -197,6 +197,18 @@ Description:
Angle of rotation. Units after application of scale and offset
are radians.
What: /sys/bus/iio/devices/iio:deviceX/in_positionrelative_x_raw
What: /sys/bus/iio/devices/iio:deviceX/in_positionrelative_y_raw
KernelVersion: 4.18
Contact: linux-iio@vger.kernel.org
Description:
Relative position in direction x or y on a pad (may be
arbitrarily assigned but should match other such assignments on
device).
Units after application of scale and offset are milli percents
from the pad's size in both directions. Should be calibrated by
the consumer.
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_raw
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_raw
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_raw
......@@ -1295,13 +1307,16 @@ What: /sys/.../iio:deviceX/in_intensityY_raw
What: /sys/.../iio:deviceX/in_intensityY_ir_raw
What: /sys/.../iio:deviceX/in_intensityY_both_raw
What: /sys/.../iio:deviceX/in_intensityY_uv_raw
What: /sys/.../iio:deviceX/in_intensityY_duv_raw
KernelVersion: 3.4
Contact: linux-iio@vger.kernel.org
Description:
Unit-less light intensity. Modifiers both and ir indicate
that measurements contain visible and infrared light
components or just infrared light, respectively. Modifier uv indicates
that measurements contain ultraviolet light components.
components or just infrared light, respectively. Modifier
uv indicates that measurements contain ultraviolet light
components. Modifier duv indicates that measurements
contain deep ultraviolet light components.
What: /sys/.../iio:deviceX/in_uvindex_input
KernelVersion: 4.6
......@@ -1663,3 +1678,10 @@ KernelVersion: 4.12
Contact: linux-iio@vger.kernel.org
Description:
Raw counter device counters direction for channel Y.
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.
\ No newline at end of file
Documentation/ABI/testing/sysfs-bus-iio-isl29501 0 → 100644
View file @ e42f6f9b
What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_agc_gain
What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_agc_gain_bias
KernelVersion: 4.18
Contact: linux-iio@vger.kernel.org
Description:
This sensor has an automatic gain control (agc) loop
which sets the analog signal levels at an optimum
level by controlling programmable gain amplifiers. The
criteria for optimal gain is determined by the sensor.
Return the actual gain value as an integer in [0; 65536]
range when read from.
The agc gain read when measuring crosstalk shall be
written into in_proximity0_agc_gain_bias.
What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calib_phase_temp_a
What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calib_phase_temp_b
What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calib_phase_light_a
What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calib_phase_light_b
KernelVersion: 4.18
Contact: linux-iio@vger.kernel.org
Description:
The sensor is able to perform correction of distance
measurements due to changing temperature and ambient
light conditions. It can be programmed to correct for
a second order error polynomial.
Phase data has to be collected when temperature and
ambient light are modulated independently.
Then a least squares curve fit to a second order
polynomial has to be generated from the data. The
resultant curves have the form ax^2 + bx + c.
From those two curves, a and b coefficients shall be
stored in in_proximity0_calib_phase_temp_a and
in_proximity0_calib_phase_temp_b for temperature and
in in_proximity0_calib_phase_light_a and
in_proximity0_calib_phase_light_b for ambient light.
Those values must be integer in [0; 8355840] range.
Finally, the c constant is set by the sensor
internally.
The value stored in sensor is displayed when read from.
Documentation/ABI/testing/sysfs-bus-iio-light-si1133 0 → 100644
View file @ e42f6f9b
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_ir_small_raw
KernelVersion: 4.18
Contact: linux-iio@vger.kernel.org
Description:
Unit-less infrared intensity. The intensity is measured from 1
dark photodiode. "small" indicate the surface area capturing
infrared.
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_ir_large_raw
KernelVersion: 4.18
Contact: linux-iio@vger.kernel.org
Description:
Unit-less infrared intensity. The intensity is measured from 4
dark photodiodes. "large" indicate the surface area capturing
infrared.
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_large_raw
KernelVersion: 4.18
Contact: linux-iio@vger.kernel.org
Description:
Unit-less light intensity with more diodes.
Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats 0 → 100644
View file @ e42f6f9b
==========================
PCIe Device AER statistics
==========================
These attributes show up under all the devices that are AER capable. These
statistical counters indicate the errors "as seen/reported by the device".
Note that this may mean that if an endpoint is causing problems, the AER
counters may increment at its link partner (e.g. root port) because the
errors may be "seen" / reported by the link partner and not the
problematic endpoint itself (which may report all counters as 0 as it never
saw any problems).
Where: /sys/bus/pci/devices/<dev>/aer_dev_correctable
Date: July 2018
Kernel Version: 4.19.0
Contact: linux-pci@vger.kernel.org, rajatja@google.com
Description: List of correctable errors seen and reported by this
PCI device using ERR_COR. Note that since multiple errors may
be reported using a single ERR_COR message, thus
TOTAL_ERR_COR at the end of the file may not match the actual
total of all the errors in the file. Sample output:
-------------------------------------------------------------------------
localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_correctable
Receiver Error 2
Bad TLP 0
Bad DLLP 0
RELAY_NUM Rollover 0
Replay Timer Timeout 0
Advisory Non-Fatal 0
Corrected Internal Error 0
Header Log Overflow 0
TOTAL_ERR_COR 2
-------------------------------------------------------------------------
Where: /sys/bus/pci/devices/<dev>/aer_dev_fatal
Date: July 2018
Kernel Version: 4.19.0
Contact: linux-pci@vger.kernel.org, rajatja@google.com
Description: List of uncorrectable fatal errors seen and reported by this
PCI device using ERR_FATAL. Note that since multiple errors may
be reported using a single ERR_FATAL message, thus
TOTAL_ERR_FATAL at the end of the file may not match the actual
total of all the errors in the file. Sample output:
-------------------------------------------------------------------------
localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_fatal
Undefined 0
Data Link Protocol 0
Surprise Down Error 0
Poisoned TLP 0
Flow Control Protocol 0
Completion Timeout 0
Completer Abort 0
Unexpected Completion 0
Receiver Overflow 0
Malformed TLP 0
ECRC 0
Unsupported Request 0
ACS Violation 0
Uncorrectable Internal Error 0
MC Blocked TLP 0
AtomicOp Egress Blocked 0
TLP Prefix Blocked Error 0
TOTAL_ERR_FATAL 0
-------------------------------------------------------------------------
Where: /sys/bus/pci/devices/<dev>/aer_dev_nonfatal
Date: July 2018
Kernel Version: 4.19.0
Contact: linux-pci@vger.kernel.org, rajatja@google.com
Description: List of uncorrectable nonfatal errors seen and reported by this
PCI device using ERR_NONFATAL. Note that since multiple errors
may be reported using a single ERR_FATAL message, thus
TOTAL_ERR_NONFATAL at the end of the file may not match the
actual total of all the errors in the file. Sample output:
-------------------------------------------------------------------------
localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_nonfatal
Undefined 0
Data Link Protocol 0
Surprise Down Error 0
Poisoned TLP 0
Flow Control Protocol 0
Completion Timeout 0
Completer Abort 0
Unexpected Completion 0
Receiver Overflow 0
Malformed TLP 0
ECRC 0
Unsupported Request 0
ACS Violation 0
Uncorrectable Internal Error 0
MC Blocked TLP 0
AtomicOp Egress Blocked 0
TLP Prefix Blocked Error 0
TOTAL_ERR_NONFATAL 0
-------------------------------------------------------------------------
============================
PCIe Rootport AER statistics
============================
These attributes show up under only the rootports (or root complex event
collectors) that are AER capable. These indicate the number of error messages as
"reported to" the rootport. Please note that the rootports also transmit
(internally) the ERR_* messages for errors seen by the internal rootport PCI
device, so these counters include them and are thus cumulative of all the error
messages on the PCI hierarchy originating at that root port.
Where: /sys/bus/pci/devices/<dev>/aer_stats/aer_rootport_total_err_cor
Date: July 2018
Kernel Version: 4.19.0
Contact: linux-pci@vger.kernel.org, rajatja@google.com
Description: Total number of ERR_COR messages reported to rootport.
Where: /sys/bus/pci/devices/<dev>/aer_stats/aer_rootport_total_err_fatal
Date: July 2018
Kernel Version: 4.19.0
Contact: linux-pci@vger.kernel.org, rajatja@google.com
Description: Total number of ERR_FATAL messages reported to rootport.
Where: /sys/bus/pci/devices/<dev>/aer_stats/aer_rootport_total_err_nonfatal
Date: July 2018
Kernel Version: 4.19.0
Contact: linux-pci@vger.kernel.org, rajatja@google.com
Description: Total number of ERR_NONFATAL messages reported to rootport.
Documentation/ABI/testing/sysfs-bus-typec 0 → 100644
View file @ e42f6f9b
What: /sys/bus/typec/devices/.../active
Date: July 2018
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows if the mode is active or not. The attribute can be used
for entering/exiting the mode. Entering/exiting modes is
supported as synchronous operation so write(2) to the attribute
does not return until the enter/exit mode operation has
finished. The attribute is notified when the mode is
entered/exited so poll(2) on the attribute wakes up.
Entering/exiting a mode will also generate uevent KOBJ_CHANGE.
Valid values are boolean.
What: /sys/bus/typec/devices/.../description
Date: July 2018
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows description of the mode. The description is optional for
the drivers, just like with the Billboard Devices.
What: /sys/bus/typec/devices/.../mode
Date: July 2018
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The index number of the mode returned by Discover Modes USB
Power Delivery command. Depending on the alternate mode, the
mode index may be significant.
With some alternate modes (SVIDs), the mode index is assigned
for specific functionality in the specification for that
alternate mode.
With other alternate modes, the mode index values are not
assigned, and can not be therefore used for identification. When
the mode index is not assigned, identifying the alternate mode
must be done with either mode VDO or the description.
What: /sys/bus/typec/devices/.../svid
Date: July 2018
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The Standard or Vendor ID (SVID) assigned by USB-IF for this
alternate mode.
What: /sys/bus/typec/devices/.../vdo
Date: July 2018
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows the VDO in hexadecimal returned by Discover Modes command
for this mode.
Documentation/ABI/testing/sysfs-class-fpga-manager
View file @ e42f6f9b
......@@ -35,3 +35,27 @@ Description: Read fpga manager state as a string.
* write complete = Doing post programming steps
* write complete error = Error while doing post programming
* operating = FPGA is programmed and operating
What: /sys/class/fpga_manager/<fpga>/status
Date: June 2018
KernelVersion: 4.19
Contact: Wu Hao <hao.wu@intel.com>
Description: Read fpga manager status as a string.
If FPGA programming operation fails, it could be caused by crc
error or incompatible bitstream image. The intent of this
interface is to provide more detailed information for FPGA
programming errors to userspace. This is a list of strings for
the supported status.
* reconfig operation error - invalid operations detected by
reconfiguration hardware.
e.g. start reconfiguration
with errors not cleared
* reconfig CRC error - CRC error detected by
reconfiguration hardware.
* reconfig incompatible image - reconfiguration image is
incompatible with hardware
* reconfig IP protocol error - protocol errors detected by
reconfiguration hardware
* reconfig fifo overflow error - FIFO overflow detected by
reconfiguration hardware
Documentation/ABI/testing/sysfs-class-fpga-region 0 → 100644
View file @ e42f6f9b
What: /sys/class/fpga_region/<region>/compat_id
Date: June 2018
KernelVersion: 4.19
Contact: Wu Hao <hao.wu@intel.com>
Description: FPGA region id for compatibility check, e.g. compatibility
of the FPGA reconfiguration hardware and image. This value
is defined or calculated by the layer that is creating the
FPGA region. This interface returns the compat_id value or
just error code -ENOENT in case compat_id is not used.
Documentation/ABI/testing/sysfs-class-gnss 0 → 100644
View file @ e42f6f9b
What: /sys/class/gnss/gnssN/type
Date: May 2018
KernelVersion: 4.18
Contact: Johan Hovold <johan@kernel.org>
Description:
The GNSS receiver type. The currently identified types reflect
the protocol(s) supported by the receiver:
"NMEA" NMEA 0183
"SiRF" SiRF Binary
"UBX" UBX
Note that also non-"NMEA" type receivers typically support a
subset of NMEA 0183 with vendor extensions (e.g. to allow
switching to a vendor protocol).
Documentation/ABI/testing/sysfs-class-mei
View file @ e42f6f9b
......@@ -54,3 +54,14 @@ Description: Configure tx queue limit
Set maximal number of pending writes
per opened session.
What: /sys/class/mei/meiN/fw_ver
Date: May 2018
KernelVersion: 4.18
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description: Display the ME firmware version.
The version of the platform ME firmware is in format:
<platform>:<major>.<minor>.<milestone>.<build_no>.
There can be up to three such blocks for different
FW components.
Documentation/ABI/testing/sysfs-class-net-queues
View file @ e42f6f9b
......@@ -42,6 +42,17 @@ Description:
network device transmit queue. Possible vaules depend on the
number of available CPU(s) in the system.
What: /sys/class/<iface>/queues/tx-<queue>/xps_rxqs
Date: June 2018
KernelVersion: 4.18.0
Contact: netdev@vger.kernel.org
Description:
Mask of the receive queue(s) currently enabled to participate
into the Transmit Packet Steering packet processing flow for this
network device transmit queue. Possible values depend on the
number of available receive queue(s) in the network device.
Default is disabled.
What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/hold_time
Date: November 2011
KernelVersion: 3.3
......
Documentation/ABI/testing/sysfs-class-typec
View file @ e42f6f9b
......@@ -222,70 +222,12 @@ Description:
available. The value can be polled.
Alternate Mode devices.
USB Type-C port alternate mode devices.
The alternate modes will have Standard or Vendor ID (SVID) assigned by USB-IF.
The ports, partners and cable plugs can have alternate modes. A supported SVID
will consist of a set of modes. Every SVID a port/partner/plug supports will
have a device created for it, and every supported mode for a supported SVID will
have its own directory under that device. Below <dev> refers to the device for
the alternate mode.
What: /sys/class/typec/<port|partner|cable>/<dev>/svid
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The SVID (Standard or Vendor ID) assigned by USB-IF for this
alternate mode.
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Every supported mode will have its own directory. The name of
a mode will be "mode<index>" (for example mode1), where <index>
is the actual index to the mode VDO returned by Discover Modes
USB power delivery command.
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/description
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows description of the mode. The description is optional for
the drivers, just like with the Billboard Devices.
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/vdo
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows the VDO in hexadecimal returned by Discover Modes command
for this mode.
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/active
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows if the mode is active or not. The attribute can be used
for entering/exiting the mode with partners and cable plugs, and
with the port alternate modes it can be used for disabling
support for specific alternate modes. Entering/exiting modes is
supported as synchronous operation so write(2) to the attribute
does not return until the enter/exit mode operation has
finished. The attribute is notified when the mode is
entered/exited so poll(2) on the attribute wakes up.
Entering/exiting a mode will also generate uevent KOBJ_CHANGE.
Valid values: yes, no
What: /sys/class/typec/<port>/<dev>/mode<index>/supported_roles
What: /sys/class/typec/<port>/<alt mode>/supported_roles
Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Space separated list of the supported roles.
This attribute is available for the devices describing the
alternate modes a port supports, and it will not be exposed with
the devices presenting the alternate modes the partners or cable
plugs support.
Valid values: source, sink
Documentation/ABI/testing/sysfs-devices-system-cpu
View file @ e42f6f9b
......@@ -476,6 +476,7 @@ What: /sys/devices/system/cpu/vulnerabilities
/sys/devices/system/cpu/vulnerabilities/spectre_v1
/sys/devices/system/cpu/vulnerabilities/spectre_v2
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
/sys/devices/system/cpu/vulnerabilities/l1tf
Date: January 2018
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Information about CPU vulnerabilities
......@@ -487,3 +488,26 @@ Description: Information about CPU vulnerabilities
"Not affected" CPU is not affected by the vulnerability
"Vulnerable" CPU is affected and no mitigation in effect
"Mitigation: $M" CPU is affected and mitigation $M is in effect
Details about the l1tf file can be found in
Documentation/admin-guide/l1tf.rst
What: /sys/devices/system/cpu/smt
/sys/devices/system/cpu/smt/active
/sys/devices/system/cpu/smt/control
Date: June 2018
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Control Symetric Multi Threading (SMT)
active: Tells whether SMT is active (enabled and siblings online)
control: Read/write interface to control SMT. Possible
values:
"on" SMT is enabled
"off" SMT is disabled
"forceoff" SMT is force disabled. Cannot be changed.
"notsupported" SMT is not supported by the CPU
If control status is "forceoff" or "notsupported" writes
are rejected.
Documentation/ABI/testing/sysfs-driver-bd9571mwv-regulator 0 → 100644
View file @ e42f6f9b
What: /sys/bus/i2c/devices/.../bd9571mwv-regulator.*.auto/backup_mode
Date: Jul 2018
KernelVersion: 4.19
Contact: Geert Uytterhoeven <geert+renesas@glider.be>
Description: Read/write the current state of DDR Backup Mode, which controls
if DDR power rails will be kept powered during system suspend.
("on"/"1" = enabled, "off"/"0" = disabled).
Two types of power switches (or control signals) can be used:
A. With a momentary power switch (or pulse signal), DDR
Backup Mode is enabled by default when available, as the
PMIC will be configured only during system suspend.
B. With a toggle power switch (or level signal), the
following steps must be followed exactly:
1. Configure PMIC for backup mode, to change the role of
the accessory power switch from a power switch to a
wake-up switch,
2. Switch accessory power switch off, to prepare for
system suspend, which is a manual step not controlled
by software,
3. Suspend system,
4. Switch accessory power switch on, to resume the
system.
DDR Backup Mode must be explicitly enabled by the user,
to invoke step 1.
See also Documentation/devicetree/bindings/mfd/bd9571mwv.txt.
Users: User space applications for embedded boards equipped with a
BD9571MWV PMIC.
Documentation/ABI/testing/sysfs-driver-typec-displayport 0 → 100644
View file @ e42f6f9b
What: /sys/bus/typec/devices/.../displayport/configuration
Date: July 2018
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Shows the current DisplayPort configuration for the connector.
Valid values are USB, source and sink. Source means DisplayPort
source, and sink means DisplayPort sink.
All supported configurations are listed as space separated list
with the active one wrapped in square brackets.
Source example:
USB [source] sink
The configuration can be changed by writing to the file
Note. USB configuration does not equal to Exit Mode. It is
separate configuration defined in VESA DisplayPort Alt Mode on
USB Type-C Standard. Functionally it equals to the situation
where the mode has been exited (to exit the mode, see
Documentation/ABI/testing/sysfs-bus-typec, and use file
/sys/bus/typec/devices/.../active).
What: /sys/bus/typec/devices/.../displayport/pin_assignment
Date: July 2018
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
VESA DisplayPort Alt Mode on USB Type-C Standard defines six
different pin assignments for USB Type-C connector that are
labeled A, B, C, D, E, and F. The supported pin assignments are
listed as space separated list with the active one wrapped in
square brackets.
Example:
C [D]
Pin assignment can be changed by writing to the file. It is
possible to set pin assignment before configuration has been
set, but the assignment will not be active before the
connector is actually configured.
Note. As of VESA DisplayPort Alt Mode on USB Type-C Standard
version 1.0b, pin assignments A, B, and F are deprecated. Only
pin assignment D can now carry simultaneously one channel of
USB SuperSpeed protocol. From user perspective pin assignments C
and E are equal, where all channels on the connector are used
for carrying DisplayPort protocol (allowing higher resolutions).
Documentation/ABI/testing/sysfs-driver-xen-blkback
View file @ e42f6f9b
......@@ -15,3 +15,13 @@ Description:
blkback. If the frontend tries to use more than
max_persistent_grants, the LRU kicks in and starts
removing 5% of max_persistent_grants every 100ms.
What: /sys/module/xen_blkback/parameters/persistent_grant_unused_seconds
Date: August 2018
KernelVersion: 4.19
Contact: Roger Pau Monné <roger.pau@citrix.com>
Description:
How long a persistent grant is allowed to remain
allocated without being in use. The time is in
seconds, 0 means indefinitely long.
The default is 60 seconds.
Documentation/ABI/testing/sysfs-fs-f2fs
View file @ e42f6f9b
......@@ -51,6 +51,14 @@ Description:
Controls the dirty page count condition for the in-place-update
policies.
What: /sys/fs/f2fs/<disk>/min_seq_blocks
Date: August 2018
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description:
Controls the dirty page count condition for batched sequential
writes in ->writepages.
What: /sys/fs/f2fs/<disk>/min_hot_blocks
Date: March 2017
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
......
Documentation/ABI/testing/sysfs-platform-dfl-fme 0 → 100644
View file @ e42f6f9b
What: /sys/bus/platform/devices/dfl-fme.0/ports_num
Date: June 2018
KernelVersion: 4.19
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. One DFL FPGA device may have more than 1
port/Accelerator Function Unit (AFU). It returns the
number of ports on the FPGA device when read it.
What: /sys/bus/platform/devices/dfl-fme.0/bitstream_id
Date: June 2018
KernelVersion: 4.19
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. It returns Bitstream (static FPGA region)
identifier number, which includes the detailed version
and other information of this static FPGA region.
What: /sys/bus/platform/devices/dfl-fme.0/bitstream_metadata
Date: June 2018
KernelVersion: 4.19
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. It returns Bitstream (static FPGA region) meta
data, which includes the synthesis date, seed and other
information of this static FPGA region.
Documentation/ABI/testing/sysfs-platform-dfl-port 0 → 100644
View file @ e42f6f9b
What: /sys/bus/platform/devices/dfl-port.0/id
Date: June 2018
KernelVersion: 4.19
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. It returns id of this port. One DFL FPGA device
may have more than one port. Userspace could use this id to
distinguish different ports under same FPGA device.
What: /sys/bus/platform/devices/dfl-port.0/afu_id
Date: June 2018
KernelVersion: 4.19
Contact: Wu Hao <hao.wu@intel.com>
Description: Read-only. User can program different PR bitstreams to FPGA
Accelerator Function Unit (AFU) for different functions. It
returns uuid which could be used to identify which PR bitstream
is programmed in this AFU.
Documentation/PCI/00-INDEX
View file @ e42f6f9b
00-INDEX
- this file
acpi-info.txt
- info on how PCI host bridges are represented in ACPI
MSI-HOWTO.txt
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
PCIEBUS-HOWTO.txt
......
Documentation/PCI/acpi-info.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/PCI/endpoint/function/binding/pci-test.txt
View file @ e42f6f9b
......@@ -15,3 +15,5 @@ subsys_id : don't care
interrupt_pin : Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
msi_interrupts : Should be 1 to 32 depending on the number of MSI interrupts
to test
msix_interrupts : Should be 1 to 2048 depending on the number of MSI-X
interrupts to test
Documentation/PCI/endpoint/pci-endpoint.txt
View file @ e42f6f9b
......@@ -44,7 +44,7 @@ by the PCI controller driver.
* clear_bar: ops to reset the BAR
* alloc_addr_space: ops to allocate in PCI controller address space
* free_addr_space: ops to free the allocated address space
* raise_irq: ops to raise a legacy or MSI interrupt
* raise_irq: ops to raise a legacy, MSI or MSI-X interrupt
* start: ops to start the PCI link
* stop: ops to stop the PCI link
......@@ -96,7 +96,7 @@ by the PCI endpoint function driver.
*) pci_epc_raise_irq()
The PCI endpoint function driver should use pci_epc_raise_irq() to raise
Legacy Interrupt or MSI Interrupt.
Legacy Interrupt, MSI or MSI-X Interrupt.
*) pci_epc_mem_alloc_addr()
......
Documentation/PCI/endpoint/pci-test-function.txt
View file @ e42f6f9b
......@@ -20,6 +20,8 @@ The PCI endpoint test device has the following registers:
5) PCI_ENDPOINT_TEST_DST_ADDR
6) PCI_ENDPOINT_TEST_SIZE
7) PCI_ENDPOINT_TEST_CHECKSUM
8) PCI_ENDPOINT_TEST_IRQ_TYPE
9) PCI_ENDPOINT_TEST_IRQ_NUMBER
*) PCI_ENDPOINT_TEST_MAGIC
......@@ -34,10 +36,10 @@ that the endpoint device must perform.
Bitfield Description:
Bit 0 : raise legacy IRQ
Bit 1 : raise MSI IRQ
Bit 2 - 7 : MSI interrupt number
Bit 8 : read command (read data from RC buffer)
Bit 9 : write command (write data to RC buffer)
Bit 10 : copy command (copy data from one RC buffer to another
Bit 2 : raise MSI-X IRQ
Bit 3 : read command (read data from RC buffer)
Bit 4 : write command (write data to RC buffer)
Bit 5 : copy command (copy data from one RC buffer to another
RC buffer)
*) PCI_ENDPOINT_TEST_STATUS
......@@ -64,3 +66,22 @@ COPY/READ command.
This register contains the destination address (RC buffer address) for
the COPY/WRITE command.
*) PCI_ENDPOINT_TEST_IRQ_TYPE
This register contains the interrupt type (Legacy/MSI) triggered
for the READ/WRITE/COPY and raise IRQ (Legacy/MSI) commands.
Possible types:
- Legacy : 0
- MSI : 1
- MSI-X : 2
*) PCI_ENDPOINT_TEST_IRQ_NUMBER
This register contains the triggered ID interrupt.
Admissible values:
- Legacy : 0
- MSI : [1 .. 32]
- MSI-X : [1 .. 2048]
Documentation/PCI/endpoint/pci-test-howto.txt
View file @ e42f6f9b
......@@ -45,9 +45,9 @@ The PCI endpoint framework populates the directory with the following
configurable fields.
# ls functions/pci_epf_test/func1
baseclass_code interrupt_pin revid subsys_vendor_id
cache_line_size msi_interrupts subclass_code vendorid
deviceid progif_code subsys_id
baseclass_code interrupt_pin progif_code subsys_id
cache_line_size msi_interrupts revid subsys_vendorid
deviceid msix_interrupts subclass_code vendorid
The PCI endpoint function driver populates these entries with default values
when the device is bound to the driver. The pci-epf-test driver populates
......@@ -67,6 +67,7 @@ device, the following commands can be used.
# echo 0x104c > functions/pci_epf_test/func1/vendorid
# echo 0xb500 > functions/pci_epf_test/func1/deviceid
# echo 16 > functions/pci_epf_test/func1/msi_interrupts
# echo 8 > functions/pci_epf_test/func1/msix_interrupts
1.5 Binding pci-epf-test Device to EP Controller
......@@ -120,7 +121,9 @@ following commands.
Interrupt tests
SET IRQ TYPE TO LEGACY: OKAY
LEGACY IRQ: NOT OKAY
SET IRQ TYPE TO MSI: OKAY
MSI1: OKAY
MSI2: OKAY
MSI3: OKAY
......@@ -153,9 +156,30 @@ following commands.
MSI30: NOT OKAY
MSI31: NOT OKAY
MSI32: NOT OKAY
SET IRQ TYPE TO MSI-X: OKAY
MSI-X1: OKAY
MSI-X2: OKAY
MSI-X3: OKAY
MSI-X4: OKAY
MSI-X5: OKAY
MSI-X6: OKAY
MSI-X7: OKAY
MSI-X8: OKAY
MSI-X9: NOT OKAY
MSI-X10: NOT OKAY
MSI-X11: NOT OKAY
MSI-X12: NOT OKAY
MSI-X13: NOT OKAY
MSI-X14: NOT OKAY
MSI-X15: NOT OKAY
MSI-X16: NOT OKAY
[...]
MSI-X2047: NOT OKAY
MSI-X2048: NOT OKAY
Read Tests
SET IRQ TYPE TO MSI: OKAY
READ ( 1 bytes): OKAY
READ ( 1024 bytes): OKAY
READ ( 1025 bytes): OKAY
......
Documentation/PCI/pcieaer-howto.txt
View file @ e42f6f9b
......@@ -73,6 +73,11 @@ In the example, 'Requester ID' means the ID of the device who sends
the error message to root port. Pls. refer to pci express specs for
other fields.
2.4 AER Statistics / Counters
When PCIe AER errors are captured, the counters / statistics are also exposed
in the form of sysfs attributes which are documented at
Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
3. Developer Guide
......
Documentation/RCU/Design/Data-Structures/Data-Structures.html
View file @ e42f6f9b
......@@ -380,31 +380,26 @@ and therefore need no protection.
as follows:
<pre>
1 unsigned long gpnum;
2 unsigned long completed;
1 unsigned long gp_seq;
</pre>
<p>RCU grace periods are numbered, and
the <tt>-&gt;gpnum</tt> field contains the number of the grace
period that started most recently.
The <tt>-&gt;completed</tt> field contains the number of the
grace period that completed most recently.
If the two fields are equal, the RCU grace period that most recently
started has already completed, and therefore the corresponding
flavor of RCU is idle.
If <tt>-&gt;gpnum</tt> is one greater than <tt>-&gt;completed</tt>,
then <tt>-&gt;gpnum</tt> gives the number of the current RCU
grace period, which has not yet completed.
Any other combination of values indicates that something is broken.
These two fields are protected by the root <tt>rcu_node</tt>'s
the <tt>-&gt;gp_seq</tt> field contains the current grace-period
sequence number.
The bottom two bits are the state of the current grace period,
which can be zero for not yet started or one for in progress.
In other words, if the bottom two bits of <tt>-&gt;gp_seq</tt> are
zero, the corresponding flavor of RCU is idle.
Any other value in the bottom two bits indicates that something is broken.
This field is protected by the root <tt>rcu_node</tt> structure's
<tt>-&gt;lock</tt> field.
</p><p>There are <tt>-&gt;gpnum</tt> and <tt>-&gt;completed</tt> fields
</p><p>There are <tt>-&gt;gp_seq</tt> fields
in the <tt>rcu_node</tt> and <tt>rcu_data</tt> structures
as well.
The fields in the <tt>rcu_state</tt> structure represent the
most current values, and those of the other structures are compared
in order to detect the start of a new grace period in a distributed
most current value, and those of the other structures are compared
in order to detect the beginnings and ends of grace periods in a distributed
fashion.
The values flow from <tt>rcu_state</tt> to <tt>rcu_node</tt>
(down the tree from the root to the leaves) to <tt>rcu_data</tt>.
......@@ -512,27 +507,47 @@ than to be heisenbugged out of existence.
as follows:
<pre>
1 unsigned long gpnum;
2 unsigned long completed;
1 unsigned long gp_seq;
2 unsigned long gp_seq_needed;
</pre>
<p>These fields are the counterparts of the fields of the same name in
the <tt>rcu_state</tt> structure.
They each may lag up to one behind their <tt>rcu_state</tt>
counterparts.
If a given <tt>rcu_node</tt> structure's <tt>-&gt;gpnum</tt> and
<tt>-&gt;complete</tt> fields are equal, then this <tt>rcu_node</tt>
<p>The <tt>rcu_node</tt> structures' <tt>-&gt;gp_seq</tt> fields are
the counterparts of the field of the same name in the <tt>rcu_state</tt>
structure.
They each may lag up to one step behind their <tt>rcu_state</tt>
counterpart.
If the bottom two bits of a given <tt>rcu_node</tt> structure's
<tt>-&gt;gp_seq</tt> field is zero, then this <tt>rcu_node</tt>
structure believes that RCU is idle.
Otherwise, as with the <tt>rcu_state</tt> structure,
the <tt>-&gt;gpnum</tt> field will be one greater than the
<tt>-&gt;complete</tt> fields, with <tt>-&gt;gpnum</tt>
indicating which grace period this <tt>rcu_node</tt> believes
is still being waited for.
</p><p>The <tt>&gt;gp_seq</tt> field of each <tt>rcu_node</tt>
structure is updated at the beginning and the end
of each grace period.
<p>The <tt>-&gt;gp_seq_needed</tt> fields record the
furthest-in-the-future grace period request seen by the corresponding
<tt>rcu_node</tt> structure. The request is considered fulfilled when
the value of the <tt>-&gt;gp_seq</tt> field equals or exceeds that of
the <tt>-&gt;gp_seq_needed</tt> field.
</p><p>The <tt>&gt;gpnum</tt> field of each <tt>rcu_node</tt>
structure is updated at the beginning
of each grace period, and the <tt>-&gt;completed</tt> fields are
updated at the end of each grace period.
<table>
<tr><th>&nbsp;</th></tr>
<tr><th align="left">Quick Quiz:</th></tr>
<tr><td>
Suppose that this <tt>rcu_node</tt> structure doesn't see
a request for a very long time.
Won't wrapping of the <tt>-&gt;gp_seq</tt> field cause
problems?
</td></tr>
<tr><th align="left">Answer:</th></tr>
<tr><td bgcolor="#ffffff"><font color="ffffff">
No, because if the <tt>-&gt;gp_seq_needed</tt> field lags behind the
<tt>-&gt;gp_seq</tt> field, the <tt>-&gt;gp_seq_needed</tt> field
will be updated at the end of the grace period.
Modulo-arithmetic comparisons therefore will always get the
correct answer, even with wrapping.
</font></td></tr>
<tr><td>&nbsp;</td></tr>
</table>
<h5>Quiescent-State Tracking</h5>
......@@ -626,9 +641,8 @@ normal and expedited grace periods, respectively.
</ol>
<p><font color="ffffff">So the locking is absolutely required in
order to coordinate
clearing of the bits with the grace-period numbers in
<tt>-&gt;gpnum</tt> and <tt>-&gt;completed</tt>.
order to coordinate clearing of the bits with updating of the
grace-period sequence number in <tt>-&gt;gp_seq</tt>.
</font></td></tr>
<tr><td>&nbsp;</td></tr>
</table>
......@@ -1038,15 +1052,15 @@ out any <tt>rcu_data</tt> structure for which this flag is not set.
as follows:
<pre>
1 unsigned long completed;
2 unsigned long gpnum;
1 unsigned long gp_seq;
2 unsigned long gp_seq_needed;
3 bool cpu_no_qs;
4 bool core_needs_qs;
5 bool gpwrap;
6 unsigned long rcu_qs_ctr_snap;
</pre>
<p>The <tt>completed</tt> and <tt>gpnum</tt>
<p>The <tt>-&gt;gp_seq</tt> and <tt>-&gt;gp_seq_needed</tt>
fields are the counterparts of the fields of the same name
in the <tt>rcu_state</tt> and <tt>rcu_node</tt> structures.
They may each lag up to one behind their <tt>rcu_node</tt>
......@@ -1054,15 +1068,9 @@ counterparts, but in <tt>CONFIG_NO_HZ_IDLE</tt> and
<tt>CONFIG_NO_HZ_FULL</tt> kernels can lag
arbitrarily far behind for CPUs in dyntick-idle mode (but these counters
will catch up upon exit from dyntick-idle mode).
If a given <tt>rcu_data</tt> structure's <tt>-&gt;gpnum</tt> and
<tt>-&gt;complete</tt> fields are equal, then this <tt>rcu_data</tt>
If the lower two bits of a given <tt>rcu_data</tt> structure's
<tt>-&gt;gp_seq</tt> are zero, then this <tt>rcu_data</tt>
structure believes that RCU is idle.
Otherwise, as with the <tt>rcu_state</tt> and <tt>rcu_node</tt>
structure,
the <tt>-&gt;gpnum</tt> field will be one greater than the
<tt>-&gt;complete</tt> fields, with <tt>-&gt;gpnum</tt>
indicating which grace period this <tt>rcu_data</tt> believes
is still being waited for.
<table>
<tr><th>&nbsp;</th></tr>
......@@ -1070,13 +1078,13 @@ is still being waited for.
<tr><td>
All this replication of the grace period numbers can only cause
massive confusion.
Why not just keep a global pair of counters and be done with it???
Why not just keep a global sequence number and be done with it???
</td></tr>
<tr><th align="left">Answer:</th></tr>
<tr><td bgcolor="#ffffff"><font color="ffffff">
Because if there was only a single global pair of grace-period
Because if there was only a single global sequence
numbers, there would need to be a single global lock to allow
safely accessing and updating them.
safely accessing and updating it.
And if we are not going to have a single global lock, we need
to carefully manage the numbers on a per-node basis.
Recall from the answer to a previous Quick Quiz that the consequences
......@@ -1091,8 +1099,8 @@ CPU has not yet passed through a quiescent state,
while the <tt>-&gt;core_needs_qs</tt> flag indicates that the
RCU core needs a quiescent state from the corresponding CPU.
The <tt>-&gt;gpwrap</tt> field indicates that the corresponding
CPU has remained idle for so long that the <tt>completed</tt>
and <tt>gpnum</tt> counters are in danger of overflow, which
CPU has remained idle for so long that the
<tt>gp_seq</tt> counter is in danger of overflow, which
will cause the CPU to disregard the values of its counters on
its next exit from idle.
Finally, the <tt>rcu_qs_ctr_snap</tt> field is used to detect
......@@ -1130,10 +1138,10 @@ The CPU advances the callbacks in its <tt>rcu_data</tt> structure
whenever it notices that another RCU grace period has completed.
The CPU detects the completion of an RCU grace period by noticing
that the value of its <tt>rcu_data</tt> structure's
<tt>-&gt;completed</tt> field differs from that of its leaf
<tt>-&gt;gp_seq</tt> field differs from that of its leaf
<tt>rcu_node</tt> structure.
Recall that each <tt>rcu_node</tt> structure's
<tt>-&gt;completed</tt> field is updated at the end of each
<tt>-&gt;gp_seq</tt> field is updated at the beginnings and ends of each
grace period.
<p>
......
Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.html
View file @ e42f6f9b
......@@ -357,7 +357,7 @@ parts, starting in this section with the various phases of
grace-period initialization.
<p>The first ordering-related grace-period initialization action is to
increment the <tt>rcu_state</tt> structure's <tt>-&gt;gpnum</tt>
advance the <tt>rcu_state</tt> structure's <tt>-&gt;gp_seq</tt>
grace-period-number counter, as shown below:
</p><p><img src="TreeRCU-gp-init-1.svg" alt="TreeRCU-gp-init-1.svg" width="75%">
......@@ -388,7 +388,7 @@ its last CPU and if the next <tt>rcu_node</tt> structure has no online CPUs).
<p>The final <tt>rcu_gp_init()</tt> pass through the <tt>rcu_node</tt>
tree traverses breadth-first, setting each <tt>rcu_node</tt> structure's
<tt>-&gt;gpnum</tt> field to the newly incremented value from the
<tt>-&gt;gp_seq</tt> field to the newly advanced value from the
<tt>rcu_state</tt> structure, as shown in the following diagram.
</p><p><img src="TreeRCU-gp-init-3.svg" alt="TreeRCU-gp-init-1.svg" width="75%">
......@@ -398,9 +398,9 @@ tree traverses breadth-first, setting each <tt>rcu_node</tt> structure's
to notice that a new grace period has started, as described in the next
section.
But because the grace-period kthread started the grace period at the
root (with the increment of the <tt>rcu_state</tt> structure's
<tt>-&gt;gpnum</tt> field) before setting each leaf <tt>rcu_node</tt>
structure's <tt>-&gt;gpnum</tt> field, each CPU's observation of
root (with the advancing of the <tt>rcu_state</tt> structure's
<tt>-&gt;gp_seq</tt> field) before setting each leaf <tt>rcu_node</tt>
structure's <tt>-&gt;gp_seq</tt> field, each CPU's observation of
the start of the grace period will happen after the actual start
of the grace period.
......@@ -466,7 +466,7 @@ section that the grace period must wait on.
<tr><td>
But a RCU read-side critical section might have started
after the beginning of the grace period
(the <tt>-&gt;gpnum++</tt> from earlier), so why should
(the advancing of <tt>-&gt;gp_seq</tt> from earlier), so why should
the grace period wait on such a critical section?
</td></tr>
<tr><th align="left">Answer:</th></tr>
......@@ -609,10 +609,8 @@ states outstanding from other CPUs.
<h4><a name="Grace-Period Cleanup">Grace-Period Cleanup</a></h4>
<p>Grace-period cleanup first scans the <tt>rcu_node</tt> tree
breadth-first setting all the <tt>-&gt;completed</tt> fields equal
to the number of the newly completed grace period, then it sets
the <tt>rcu_state</tt> structure's <tt>-&gt;completed</tt> field,
again to the number of the newly completed grace period.
breadth-first advancing all the <tt>-&gt;gp_seq</tt> fields, then it
advances the <tt>rcu_state</tt> structure's <tt>-&gt;gp_seq</tt> field.
The ordering effects are shown below:
</p><p><img src="TreeRCU-gp-cleanup.svg" alt="TreeRCU-gp-cleanup.svg" width="75%">
......@@ -634,7 +632,7 @@ grace-period cleanup is complete, the next grace period can begin.
CPU has reported its quiescent state, but it may be some
milliseconds before RCU becomes aware of this.
The latest reasonable candidate is once the <tt>rcu_state</tt>
structure's <tt>-&gt;completed</tt> field has been updated,
structure's <tt>-&gt;gp_seq</tt> field has been updated,
but it is quite possible that some CPUs have already completed
phase two of their updates by that time.
In short, if you are going to work with RCU, you need to
......@@ -647,7 +645,7 @@ grace-period cleanup is complete, the next grace period can begin.
<h4><a name="Callback Invocation">Callback Invocation</a></h4>
<p>Once a given CPU's leaf <tt>rcu_node</tt> structure's
<tt>-&gt;completed</tt> field has been updated, that CPU can begin
<tt>-&gt;gp_seq</tt> field has been updated, that CPU can begin
invoking its RCU callbacks that were waiting for this grace period
to end.
These callbacks are identified by <tt>rcu_advance_cbs()</tt>,
......
Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-cleanup.svg
View file @ e42f6f9b
......@@ -384,11 +384,11 @@
inkscape:window-height="1144"
id="namedview208"
showgrid="true"
inkscape:zoom="0.70710678"
inkscape:cx="617.89017"
inkscape:cy="542.52419"
inkscape:window-x="86"
inkscape:window-y="28"
inkscape:zoom="0.78716603"
inkscape:cx="513.06403"
inkscape:cy="623.1214"
inkscape:window-x="102"
inkscape:window-y="38"
inkscape:window-maximized="0"
inkscape:current-layer="g3188-3"
fit-margin-top="5"
......@@ -417,13 +417,15 @@
id="g3188">
<text
xml:space="preserve"
x="3199.1516"
x="3145.9592"
y="13255.592"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">-&gt;completed = -&gt;gpnum</text>
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier"><tspan
style="font-size:172.87567139px"
id="tspan3143">rcu_seq_end(&amp;rnp-&gt;gp_seq)</tspan></text>
<g
id="g3107"
transform="translate(947.90548,11584.029)">
......@@ -502,13 +504,15 @@
</g>
<text
xml:space="preserve"
x="5324.5371"
y="15414.598"
x="5264.4731"
y="15428.84"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-753"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;completed = -&gt;gpnum</text>
id="text202-36-7"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
style="font-size:172.87567139px"
id="tspan3166-5">rcu_seq_end(&amp;rnp-&gt;gp_seq)</tspan></text>
</g>
<g
style="fill:none;stroke-width:0.025in"
......@@ -547,15 +551,6 @@
sodipodi:linespacing="125%"><tspan
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
id="tspan3104-6-5-6-0">Leaf</tspan></text>
<text
xml:space="preserve"
x="7479.5796"
y="17699.943"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-9"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;completed = -&gt;gpnum</text>
<path
sodipodi:nodetypes="cc"
inkscape:connector-curvature="0"
......@@ -566,15 +561,6 @@
style="fill:none;stroke-width:0.025in"
transform="translate(-737.93887,7732.6672)"
id="g3188-3">
<text
xml:space="preserve"
x="3225.7478"
y="13175.802"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-60"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">rsp-&gt;completed =</text>
<g
id="g3107-62"
transform="translate(947.90548,11584.029)">
......@@ -607,15 +593,6 @@
sodipodi:linespacing="125%"><tspan
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
id="tspan3104-6-5-7">Root</tspan></text>
<text
xml:space="preserve"
x="3225.7478"
y="13390.038"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-60-3"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"> rnp-&gt;completed</text>
<flowRoot
xml:space="preserve"
id="flowRoot3356"
......@@ -627,7 +604,18 @@
height="63.63961"
x="332.34018"
y="681.87292" /></flowRegion><flowPara
id="flowPara3362" /></flowRoot> </g>
id="flowPara3362" /></flowRoot> <text
xml:space="preserve"
x="3156.6121"
y="13317.754"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-36-6"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
style="font-size:172.87567139px"
id="tspan3166-0">rcu_seq_end(&amp;rsp-&gt;gp_seq)</tspan></text>
</g>
<g
style="fill:none;stroke-width:0.025in"
transform="translate(-858.40227,7769.0342)"
......@@ -859,6 +847,17 @@
id="path3414-8-3-6-6"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<text
xml:space="preserve"
x="7418.769"
y="17646.104"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-36-70"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
style="font-size:172.87567139px"
id="tspan3166-93">rcu_seq_end(&amp;rnp-&gt;gp_seq)</tspan></text>
</g>
<g
transform="translate(-1642.5377,-11611.245)"
......@@ -887,13 +886,15 @@
</g>
<text
xml:space="preserve"
x="5327.3057"
x="5274.1133"
y="15428.84"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-36"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;completed = -&gt;gpnum</text>
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
style="font-size:172.87567139px"
id="tspan3166">rcu_seq_end(&amp;rnp-&gt;gp_seq)</tspan></text>
</g>
<g
transform="translate(-151.71746,-11647.612)"
......@@ -972,13 +973,15 @@
id="tspan3104-6-5-6-0-92">Leaf</tspan></text>
<text
xml:space="preserve"
x="7486.4907"
y="17670.119"
x="7408.5918"
y="17619.504"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-6"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;completed = -&gt;gpnum</text>
id="text202-36-2"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
style="font-size:172.87567139px"
id="tspan3166-9">rcu_seq_end(&amp;rnp-&gt;gp_seq)</tspan></text>
</g>
<g
transform="translate(-6817.1997,-11647.612)"
......@@ -1019,13 +1022,15 @@
id="tspan3104-6-5-6-0-1">Leaf</tspan></text>
<text
xml:space="preserve"
x="7474.1382"
y="17688.926"
x="7416.8003"
y="17619.504"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-5"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;completed = -&gt;gpnum</text>
id="text202-36-3"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
style="font-size:172.87567139px"
id="tspan3166-56">rcu_seq_end(&amp;rnp-&gt;gp_seq)</tspan></text>
</g>
<path
style="fill:none;stroke:#000000;stroke-width:13.29812908px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
......@@ -1059,15 +1064,6 @@
id="path3414-8-3-6"
inkscape:connector-curvature="0"
sodipodi:nodetypes="cc" />
<text
xml:space="preserve"
x="7318.9653"
y="6031.6353"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-2"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;completed = -&gt;gpnum</text>
<g
style="fill:none;stroke-width:0.025in"
id="g4504-3-9"
......@@ -1123,4 +1119,15 @@
id="path3134-9-0-3-5"
d="m 6875.6003,15833.906 1595.7755,0"
style="fill:none;stroke:#969696;stroke-width:53.19251633;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow1Send-36)" />
<text
xml:space="preserve"
x="7275.2612"
y="5971.8916"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-36-1"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
style="font-size:172.87567139px"
id="tspan3166-2">rcu_seq_end(&amp;rnp-&gt;gp_seq)</tspan></text>
</svg>
Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-1.svg
View file @ e42f6f9b
......@@ -272,13 +272,13 @@
inkscape:window-height="1144"
id="namedview208"
showgrid="true"
inkscape:zoom="0.70710678"
inkscape:cx="617.89019"
inkscape:cy="636.57143"
inkscape:window-x="697"
inkscape:zoom="2.6330492"
inkscape:cx="524.82797"
inkscape:cy="519.31194"
inkscape:window-x="79"
inkscape:window-y="28"
inkscape:window-maximized="0"
inkscape:current-layer="svg2"
inkscape:current-layer="g3188"
fit-margin-top="5"
fit-margin-right="5"
fit-margin-left="5"
......@@ -305,13 +305,15 @@
id="g3188">
<text
xml:space="preserve"
x="3305.5364"
x="3119.363"
y="13255.592"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">rsp-&gt;gpnum++</text>
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier"><tspan
style="font-size:172.87567139px"
id="tspan3071">rcu_seq_start(rsp-&gt;gp_seq)</tspan></text>
<g
id="g3107"
transform="translate(947.90548,11584.029)">
......
Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-init-3.svg
View file @ e42f6f9b
......@@ -19,7 +19,7 @@
id="svg2"
version="1.1"
inkscape:version="0.48.4 r9939"
sodipodi:docname="TreeRCU-gp-init-2.svg">
sodipodi:docname="TreeRCU-gp-init-3.svg">
<metadata
id="metadata212">
<rdf:RDF>
......@@ -257,18 +257,22 @@
inkscape:window-width="1087"
inkscape:window-height="1144"
id="namedview208"
showgrid="false"
inkscape:zoom="0.70710678"
showgrid="true"
inkscape:zoom="0.68224756"
inkscape:cx="617.89019"
inkscape:cy="625.84293"
inkscape:window-x="697"
inkscape:window-x="54"
inkscape:window-y="28"
inkscape:window-maximized="0"
inkscape:current-layer="svg2"
inkscape:current-layer="g3153"
fit-margin-top="5"
fit-margin-right="5"
fit-margin-left="5"
fit-margin-bottom="5" />
fit-margin-bottom="5">
<inkscape:grid
type="xygrid"
id="grid3090" />
</sodipodi:namedview>
<path
sodipodi:nodetypes="cccccccccccccccccccccccc"
inkscape:connector-curvature="0"
......@@ -281,13 +285,13 @@
id="g3188">
<text
xml:space="preserve"
x="3305.5364"
x="3145.9592"
y="13255.592"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">-&gt;gpnum = rsp-&gt;gpnum</text>
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">-&gt;gp_seq = rsp-&gt;gp_seq</text>
<g
id="g3107"
transform="translate(947.90548,11584.029)">
......@@ -366,13 +370,13 @@
</g>
<text
xml:space="preserve"
x="5392.3345"
y="15407.104"
x="5253.6904"
y="15407.032"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-6"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;gpnum = rsp-&gt;gpnum</text>
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;gp_seq = rsp-&gt;gp_seq</text>
</g>
<g
style="fill:none;stroke-width:0.025in"
......@@ -413,13 +417,13 @@
id="tspan3104-6-5-6-0">Leaf</tspan></text>
<text
xml:space="preserve"
x="7536.4883"
y="17640.934"
x="7415.4365"
y="17670.572"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-9"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;gpnum = rsp-&gt;gpnum</text>
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;gp_seq = rsp-&gt;gp_seq</text>
</g>
<g
transform="translate(-1642.5375,-11610.962)"
......@@ -448,13 +452,13 @@
</g>
<text
xml:space="preserve"
x="5378.4146"
y="15436.927"
x="5258.0688"
y="15412.313"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-3"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;gpnum = rsp-&gt;gpnum</text>
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;gp_seq = rsp-&gt;gp_seq</text>
</g>
<g
transform="translate(-151.71726,-11647.329)"
......@@ -533,13 +537,13 @@
id="tspan3104-6-5-6-0-92">Leaf</tspan></text>
<text
xml:space="preserve"
x="7520.1294"
y="17673.639"
x="7405.2607"
y="17670.572"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-35"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;gpnum = rsp-&gt;gpnum</text>
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;gp_seq = rsp-&gt;gp_seq</text>
</g>
<g
transform="translate(-6817.1998,-11647.329)"
......@@ -580,13 +584,13 @@
id="tspan3104-6-5-6-0-1">Leaf</tspan></text>
<text
xml:space="preserve"
x="7521.4663"
y="17666.062"
x="7413.4688"
y="17670.566"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-75"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;gpnum = rsp-&gt;gpnum</text>
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;gp_seq = rsp-&gt;gp_seq</text>
</g>
<path
style="fill:none;stroke:#000000;stroke-width:13.29812908px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
......@@ -622,11 +626,11 @@
sodipodi:nodetypes="cc" />
<text
xml:space="preserve"
x="7370.856"
y="5997.5972"
x="7271.9297"
y="6023.2412"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-62"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;gpnum = rsp-&gt;gpnum</text>
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">-&gt;gp_seq = rsp-&gt;gp_seq</text>
</svg>
Documentation/RCU/Design/Memory-Ordering/TreeRCU-qs.svg
View file @ e42f6f9b
......@@ -300,13 +300,13 @@
inkscape:window-height="1144"
id="namedview208"
showgrid="true"
inkscape:zoom="0.70710678"
inkscape:cx="616.47598"
inkscape:cy="595.41964"
inkscape:window-x="813"
inkscape:zoom="0.96484375"
inkscape:cx="507.0191"
inkscape:cy="885.62207"
inkscape:window-x="47"
inkscape:window-y="28"
inkscape:window-maximized="0"
inkscape:current-layer="g4405"
inkscape:current-layer="g3115"
fit-margin-top="5"
fit-margin-right="5"
fit-margin-left="5"
......@@ -710,7 +710,7 @@
font-weight="bold"
font-size="192"
id="text202-6-6"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rdp-&gt;gpnum</text>
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rdp-&gt;gp_seq</text>
<text
xml:space="preserve"
x="5035.4155"
......
Documentation/RCU/stallwarn.txt
View file @ e42f6f9b
......@@ -172,7 +172,7 @@ it will print a message similar to the following:
INFO: rcu_sched detected stalls on CPUs/tasks:
2-...: (3 GPs behind) idle=06c/0/0 softirq=1453/1455 fqs=0
16-...: (0 ticks this GP) idle=81c/0/0 softirq=764/764 fqs=0
(detected by 32, t=2603 jiffies, g=7073, c=7072, q=625)
(detected by 32, t=2603 jiffies, g=7075, q=625)
This message indicates that CPU 32 detected that CPUs 2 and 16 were both
causing stalls, and that the stall was affecting RCU-sched. This message
......@@ -215,11 +215,10 @@ CPU since the last time that this CPU noted the beginning of a grace
period.
The "detected by" line indicates which CPU detected the stall (in this
case, CPU 32), how many jiffies have elapsed since the start of the
grace period (in this case 2603), the number of the last grace period
to start and to complete (7073 and 7072, respectively), and an estimate
of the total number of RCU callbacks queued across all CPUs (625 in
this case).
case, CPU 32), how many jiffies have elapsed since the start of the grace
period (in this case 2603), the grace-period sequence number (7075), and
an estimate of the total number of RCU callbacks queued across all CPUs
(625 in this case).
In kernels with CONFIG_RCU_FAST_NO_HZ, more information is printed
for each CPU:
......@@ -266,15 +265,16 @@ If the relevant grace-period kthread has been unable to run prior to
the stall warning, as was the case in the "All QSes seen" line above,
the following additional line is printed:
kthread starved for 23807 jiffies! g7073 c7072 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1
kthread starved for 23807 jiffies! g7075 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1 ->cpu=5
Starving the grace-period kthreads of CPU time can of course result
in RCU CPU stall warnings even when all CPUs and tasks have passed
through the required quiescent states. The "g" and "c" numbers flag the
number of the last grace period started and completed, respectively,
the "f" precedes the ->gp_flags command to the grace-period kthread,
the "RCU_GP_WAIT_FQS" indicates that the kthread is waiting for a short
timeout, and the "state" precedes value of the task_struct ->state field.
through the required quiescent states. The "g" number shows the current
grace-period sequence number, the "f" precedes the ->gp_flags command
to the grace-period kthread, the "RCU_GP_WAIT_FQS" indicates that the
kthread is waiting for a short timeout, the "state" precedes value of the
task_struct ->state field, and the "cpu" indicates that the grace-period
kthread last ran on CPU 5.
Multiple Warnings From One Stall
......
Documentation/RCU/whatisRCU.txt
View file @ e42f6f9b
......@@ -588,6 +588,7 @@ It is extremely simple:
void synchronize_rcu(void)
{
write_lock(&rcu_gp_mutex);
smp_mb__after_spinlock();
write_unlock(&rcu_gp_mutex);
}
......@@ -609,12 +610,15 @@ don't forget about them when submitting patches making use of RCU!]
The rcu_read_lock() and rcu_read_unlock() primitive read-acquire
and release a global reader-writer lock. The synchronize_rcu()
primitive write-acquires this same lock, then immediately releases
it. This means that once synchronize_rcu() exits, all RCU read-side
critical sections that were in progress before synchronize_rcu() was
called are guaranteed to have completed -- there is no way that
synchronize_rcu() would have been able to write-acquire the lock
otherwise.
primitive write-acquires this same lock, then releases it. This means
that once synchronize_rcu() exits, all RCU read-side critical sections
that were in progress before synchronize_rcu() was called are guaranteed
to have completed -- there is no way that synchronize_rcu() would have
been able to write-acquire the lock otherwise. The smp_mb__after_spinlock()
promotes synchronize_rcu() to a full memory barrier in compliance with
the "Memory-Barrier Guarantees" listed in:
Documentation/RCU/Design/Requirements/Requirements.html.
It is possible to nest rcu_read_lock(), since reader-writer locks may
be recursively acquired. Note also that rcu_read_lock() is immune
......@@ -816,11 +820,13 @@ RCU list traversal:
list_next_rcu
list_for_each_entry_rcu
list_for_each_entry_continue_rcu
list_for_each_entry_from_rcu
hlist_first_rcu
hlist_next_rcu
hlist_pprev_rcu
hlist_for_each_entry_rcu
hlist_for_each_entry_rcu_bh
hlist_for_each_entry_from_rcu
hlist_for_each_entry_continue_rcu
hlist_for_each_entry_continue_rcu_bh
hlist_nulls_first_rcu
......
Documentation/acpi/dsd/data-node-references.txt 0 → 100644
View file @ e42f6f9b
Copyright (C) 2018 Intel Corporation
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Referencing hierarchical data nodes
-----------------------------------
ACPI in general allows referring to device objects in the tree only.
Hierarchical data extension nodes may not be referred to directly, hence this
document defines a scheme to implement such references.
A reference consist of the device object name followed by one or more
hierarchical data extension [1] keys. Specifically, the hierarchical data
extension node which is referred to by the key shall lie directly under the
parent object i.e. either the device object or another hierarchical data
extension node.
The keys in the hierarchical data nodes shall consist of the name of the node,
"@" character and the number of the node in hexadecimal notation (without pre-
or postfixes). The same ACPI object shall include the _DSD property extension
with a property "reg" that shall have the same numerical value as the number of
the node.
In case a hierarchical data extensions node has no numerical value, then the
"reg" property shall be omitted from the ACPI object's _DSD properties and the
"@" character and the number shall be omitted from the hierarchical data
extension key.
Example
-------
In the ASL snippet below, the "reference" _DSD property [2] contains a
device object reference to DEV0 and under that device object, a
hierarchical data extension key "node@1" referring to the NOD1 object
and lastly, a hierarchical data extension key "anothernode" referring to
the ANOD object which is also the final target node of the reference.
Device (DEV0)
{
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "node@0", NOD0 },
Package () { "node@1", NOD1 },
}
})
Name (NOD0, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "random-property", 3 },
}
})
Name (NOD1, Package() {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "anothernode", ANOD },
}
})
Name (ANOD, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "random-property", 0 },
}
})
}
Device (DEV1)
{
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "reference", ^DEV0, "node@1", "anothernode" },
}
})
}
Please also see a graph example in graph.txt .
References
----------
[1] Hierarchical Data Extension UUID For _DSD.
<URL:http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf>,
referenced 2018-07-17.
[2] Device Properties UUID For _DSD.
<URL:http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf>,
referenced 2016-10-04.
Documentation/acpi/dsd/graph.txt
View file @ e42f6f9b
......@@ -36,29 +36,41 @@ The port and endpoint concepts are very similar to those in Devicetree
[3]. A port represents an interface in a device, and an endpoint
represents a connection to that interface.
All port nodes are located under the device's "_DSD" node in the
hierarchical data extension tree. The property extension related to
each port node must contain the key "port" and an integer value which
is the number of the port. The object it refers to should be called "PRTX",
where "X" is the number of the port.
Further on, endpoints are located under the individual port nodes. The
first hierarchical data extension package list entry of the endpoint
nodes must begin with "endpoint" and must be followed by the number
of the endpoint. The object it refers to should be called "EPXY", where
"X" is the number of the port and "Y" is the number of the endpoint.
Each port node contains a property extension key "port", the value of
which is the number of the port node. The each endpoint is similarly numbered
with a property extension key "endpoint". Port numbers must be unique within a
device and endpoint numbers must be unique within a port.
All port nodes are located under the device's "_DSD" node in the hierarchical
data extension tree. The data extension related to each port node must begin
with "port" and must be followed by the "@" character and the number of the port
as its key. The target object it refers to should be called "PRTX", where "X" is
the number of the port. An example of such a package would be:
Package() { "port@4", PRT4 }
Further on, endpoints are located under the port nodes. The hierarchical
data extension key of the endpoint nodes must begin with
"endpoint" and must be followed by the "@" character and the number of the
endpoint. The object it refers to should be called "EPXY", where "X" is the
number of the port and "Y" is the number of the endpoint. An example of such a
package would be:
Package() { "endpoint@0", EP40 }
Each port node contains a property extension key "port", the value of which is
the number of the port. Each endpoint is similarly numbered with a property
extension key "reg", the value of which is the number of the endpoint. Port
numbers must be unique within a device and endpoint numbers must be unique
within a port. If a device object may only has a single port, then the number
of that port shall be zero. Similarly, if a port may only have a single
endpoint, the number of that endpoint shall be zero.
The endpoint reference uses property extension with "remote-endpoint" property
name followed by a reference in the same package. Such references consist of the
the remote device reference, number of the port in the device and finally the
number of the endpoint in that port. Individual references thus appear as:
the remote device reference, the first package entry of the port data extension
reference under the device and finally the first package entry of the endpoint
data extension reference under the port. Individual references thus appear as:
Package() { device, port_number, endpoint_number }
Package() { device, "port@X", "endpoint@Y" }
In the above example, "X" is the number of the port and "Y" is the number of the
endpoint.
The references to endpoints must be always done both ways, to the
remote endpoint and back from the referred remote endpoint node.
......@@ -76,24 +88,24 @@ A simple example of this is show below:
},
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "port0", "PRT0" },
Package () { "port@0", PRT0 },
}
})
Name (PRT0, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "port", 0 },
Package () { "reg", 0 },
},
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "endpoint0", "EP00" },
Package () { "endpoint@0", EP00 },
}
})
Name (EP00, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "endpoint", 0 },
Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, 4, 0 } },
Package () { "reg", 0 },
Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, "port@4", "endpoint@0" } },
}
})
}
......@@ -106,26 +118,26 @@ A simple example of this is show below:
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "port4", "PRT4" },
Package () { "port@4", PRT4 },
}
})
Name (PRT4, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "port", 4 }, /* CSI-2 port number */
Package () { "reg", 4 }, /* CSI-2 port number */
},
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "endpoint0", "EP40" },
Package () { "endpoint@0", EP40 },
}
})
Name (EP40, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "endpoint", 0 },
Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, 0, 0 } },
Package () { "reg", 0 },
Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, "port@0", "endpoint@0" } },
}
})
}
......@@ -151,7 +163,7 @@ References
referenced 2016-10-04.
[5] Hierarchical Data Extension UUID For _DSD.
<URL:http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdf>,
<URL:http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf>,
referenced 2016-10-04.
[6] Advanced Configuration and Power Interface Specification.
......
Documentation/admin-guide/README.rst
View file @ e42f6f9b
.. _readme:
Linux kernel release 4.x <http://kernel.org/>
=============================================
......
Documentation/admin-guide/cgroup-v2.rst
View file @ e42f6f9b
......@@ -51,6 +51,9 @@ v1 is available under Documentation/cgroup-v1/.
5-3. IO
5-3-1. IO Interface Files
5-3-2. Writeback
5-3-3. IO Latency
5-3-3-1. How IO Latency Throttling Works
5-3-3-2. IO Latency Interface Files
5-4. PID
5-4-1. PID Interface Files
5-5. Device
......@@ -1069,6 +1072,24 @@ PAGE_SIZE multiple when read back.
high limit is used and monitored properly, this limit's
utility is limited to providing the final safety net.
memory.oom.group
A read-write single value file which exists on non-root
cgroups. The default value is "0".
Determines whether the cgroup should be treated as
an indivisible workload by the OOM killer. If set,
all tasks belonging to the cgroup or to its descendants
(if the memory cgroup is not a leaf cgroup) are killed
together or not at all. This can be used to avoid
partial kills to guarantee workload integrity.
Tasks with the OOM protection (oom_score_adj set to -1000)
are treated as an exception and are never killed.
If the OOM killer is invoked in a cgroup, it's not going
to kill any tasks outside of this cgroup, regardless
memory.oom.group values of ancestor cgroups.
memory.events
A read-only flat-keyed file which exists on non-root cgroups.
The following entries are defined. Unless specified
......@@ -1314,17 +1335,19 @@ IO Interface Files
Lines are keyed by $MAJ:$MIN device numbers and not ordered.
The following nested keys are defined.
====== ===================
====== =====================
rbytes Bytes read
wbytes Bytes written
rios Number of read IOs
wios Number of write IOs
====== ===================
dbytes Bytes discarded
dios Number of discard IOs
====== =====================
An example read output follows:
8:16 rbytes=1459200 wbytes=314773504 rios=192 wios=353
8:0 rbytes=90430464 wbytes=299008000 rios=8950 wios=1252
8:16 rbytes=1459200 wbytes=314773504 rios=192 wios=353 dbytes=0 dios=0
8:0 rbytes=90430464 wbytes=299008000 rios=8950 wios=1252 dbytes=50331648 dios=3021
io.weight
A read-write flat-keyed file which exists on non-root cgroups.
......@@ -1446,6 +1469,85 @@ writeback as follows.
vm.dirty[_background]_ratio.
IO Latency
~~~~~~~~~~
This is a cgroup v2 controller for IO workload protection. You provide a group
with a latency target, and if the average latency exceeds that target the
controller will throttle any peers that have a lower latency target than the
protected workload.
The limits are only applied at the peer level in the hierarchy. This means that
in the diagram below, only groups A, B, and C will influence each other, and
groups D and F will influence each other. Group G will influence nobody.
[root]
/ | \
A B C
/ \ |
D F G
So the ideal way to configure this is to set io.latency in groups A, B, and C.
Generally you do not want to set a value lower than the latency your device
supports. Experiment to find the value that works best for your workload.
Start at higher than the expected latency for your device and watch the
avg_lat value in io.stat for your workload group to get an idea of the
latency you see during normal operation. Use the avg_lat value as a basis for
your real setting, setting at 10-15% higher than the value in io.stat.
How IO Latency Throttling Works
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
io.latency is work conserving; so as long as everybody is meeting their latency
target the controller doesn't do anything. Once a group starts missing its
target it begins throttling any peer group that has a higher target than itself.
This throttling takes 2 forms:
- Queue depth throttling. This is the number of outstanding IO's a group is
allowed to have. We will clamp down relatively quickly, starting at no limit
and going all the way down to 1 IO at a time.
- Artificial delay induction. There are certain types of IO that cannot be
throttled without possibly adversely affecting higher priority groups. This
includes swapping and metadata IO. These types of IO are allowed to occur
normally, however they are "charged" to the originating group. If the
originating group is being throttled you will see the use_delay and delay
fields in io.stat increase. The delay value is how many microseconds that are
being added to any process that runs in this group. Because this number can
grow quite large if there is a lot of swapping or metadata IO occurring we
limit the individual delay events to 1 second at a time.
Once the victimized group starts meeting its latency target again it will start
unthrottling any peer groups that were throttled previously. If the victimized
group simply stops doing IO the global counter will unthrottle appropriately.
IO Latency Interface Files
~~~~~~~~~~~~~~~~~~~~~~~~~~
io.latency
This takes a similar format as the other controllers.
"MAJOR:MINOR target=<target time in microseconds"
io.stat
If the controller is enabled you will see extra stats in io.stat in
addition to the normal ones.
depth
This is the current queue depth for the group.
avg_lat
This is an exponential moving average with a decay rate of 1/exp
bound by the sampling interval. The decay rate interval can be
calculated by multiplying the win value in io.stat by the
corresponding number of samples based on the win value.
win
The sampling window size in milliseconds. This is the minimum
duration of time between evaluation events. Windows only elapse
with IO activity. Idle periods extend the most recent window.
PID
---
......
Documentation/admin-guide/devices.txt
View file @ e42f6f9b
......@@ -173,14 +173,18 @@
they are redirected through the parport multiplex layer.
7 char Virtual console capture devices
0 = /dev/vcs Current vc text contents
1 = /dev/vcs1 tty1 text contents
0 = /dev/vcs Current vc text (glyph) contents
1 = /dev/vcs1 tty1 text (glyph) contents
...
63 = /dev/vcs63 tty63 text contents
128 = /dev/vcsa Current vc text/attribute contents
129 = /dev/vcsa1 tty1 text/attribute contents
63 = /dev/vcs63 tty63 text (glyph) contents
64 = /dev/vcsu Current vc text (unicode) contents
65 = /dev/vcsu1 tty1 text (unicode) contents
...
191 = /dev/vcsa63 tty63 text/attribute contents
127 = /dev/vcsu63 tty63 text (unicode) contents
128 = /dev/vcsa Current vc text/attribute (glyph) contents
129 = /dev/vcsa1 tty1 text/attribute (glyph) contents
...
191 = /dev/vcsa63 tty63 text/attribute (glyph) contents
NOTE: These devices permit both read and write access.
......
Documentation/admin-guide/index.rst
View file @ e42f6f9b
......@@ -17,6 +17,15 @@ etc.
kernel-parameters
devices
This section describes CPU vulnerabilities and provides an overview of the
possible mitigations along with guidance for selecting mitigations if they
are configurable at compile, boot or run time.
.. toctree::
:maxdepth: 1
l1tf
Here is a set of documents aimed at users who are trying to track down
problems and bugs in particular.
......
Documentation/admin-guide/kernel-parameters.txt
View file @ e42f6f9b
......@@ -748,6 +748,14 @@
debug [KNL] Enable kernel debugging (events log level).
debug_boot_weak_hash
[KNL] Enable printing [hashed] pointers early in the
boot sequence. If enabled, we use a weak hash instead
of siphash to hash pointers. Use this option if you are
seeing instances of '(___ptrval___)') and need to see a
value (hashed pointer) instead. Cryptographically
insecure, please do not use on production kernels.
debug_locks_verbose=
[KNL] verbose self-tests
Format=<0|1>
......@@ -804,6 +812,15 @@
Defaults to the default architecture's huge page size
if not specified.
deferred_probe_timeout=
[KNL] Debugging option to set a timeout in seconds for
deferred probe to give up waiting on dependencies to
probe. Only specific dependencies (subsystems or
drivers) that have opted in will be ignored. A timeout of 0
will timeout at the end of initcalls. This option will also
dump out devices still on the deferred probe list after
retrying.
dhash_entries= [KNL]
Set number of hash buckets for dentry cache.
......@@ -816,6 +833,17 @@
disable= [IPV6]
See Documentation/networking/ipv6.txt.
hardened_usercopy=
[KNL] Under CONFIG_HARDENED_USERCOPY, whether
hardening is enabled for this boot. Hardened
usercopy checking is used to protect the kernel
from reading or writing beyond known memory
allocation boundaries as a proactive defense
against bounds-checking flaws in the kernel's
copy_to_user()/copy_from_user() interface.
on Perform hardened usercopy checks (default).
off Disable hardened usercopy checks.
disable_radix [PPC]
Disable RADIX MMU mode on POWER9
......@@ -1716,7 +1744,8 @@
merge
nomerge
soft
pt [x86, IA-64]
pt [x86]
nopt [x86]
nobypass [PPC/POWERNV]
Disable IOMMU bypass, using IOMMU for PCI devices.
......@@ -1967,10 +1996,84 @@
(virtualized real and unpaged mode) on capable
Intel chips. Default is 1 (enabled)
kvm-intel.vmentry_l1d_flush=[KVM,Intel] Mitigation for L1 Terminal Fault
CVE-2018-3620.
Valid arguments: never, cond, always
always: L1D cache flush on every VMENTER.
cond: Flush L1D on VMENTER only when the code between
VMEXIT and VMENTER can leak host memory.
never: Disables the mitigation
Default is cond (do L1 cache flush in specific instances)
kvm-intel.vpid= [KVM,Intel] Disable Virtual Processor Identification
feature (tagged TLBs) on capable Intel chips.
Default is 1 (enabled)
l1tf= [X86] Control mitigation of the L1TF vulnerability on
affected CPUs
The kernel PTE inversion protection is unconditionally
enabled and cannot be disabled.
full
Provides all available mitigations for the
L1TF vulnerability. Disables SMT and
enables all mitigations in the
hypervisors, i.e. unconditional L1D flush.
SMT control and L1D flush control via the
sysfs interface is still possible after
boot. Hypervisors will issue a warning
when the first VM is started in a
potentially insecure configuration,
i.e. SMT enabled or L1D flush disabled.
full,force
Same as 'full', but disables SMT and L1D
flush runtime control. Implies the
'nosmt=force' command line option.
(i.e. sysfs control of SMT is disabled.)
flush
Leaves SMT enabled and enables the default
hypervisor mitigation, i.e. conditional
L1D flush.
SMT control and L1D flush control via the
sysfs interface is still possible after
boot. Hypervisors will issue a warning
when the first VM is started in a
potentially insecure configuration,
i.e. SMT enabled or L1D flush disabled.
flush,nosmt
Disables SMT and enables the default
hypervisor mitigation.
SMT control and L1D flush control via the
sysfs interface is still possible after
boot. Hypervisors will issue a warning
when the first VM is started in a
potentially insecure configuration,
i.e. SMT enabled or L1D flush disabled.
flush,nowarn
Same as 'flush', but hypervisors will not
warn when a VM is started in a potentially
insecure configuration.
off
Disables hypervisor mitigations and doesn't
emit any warnings.
Default is 'flush'.
For details see: Documentation/admin-guide/l1tf.rst
l2cr= [PPC]
l3cr= [PPC]
......@@ -2687,6 +2790,14 @@
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 [PPC] Disable mitigations for Spectre Variant 1 (bounds
check bypass). With this option data leaks are possible
in the system.
nospectre_v2 [X86] Disable all mitigations for the Spectre variant 2
(indirect branch prediction) vulnerability. System may
allow data leaks with this option, which is equivalent
......@@ -2835,8 +2946,6 @@
nosync [HW,M68K] Disables sync negotiation for all devices.
notsc [BUGS=X86-32] Disable Time Stamp Counter
nowatchdog [KNL] Disable both lockup detectors, i.e.
soft-lockup and NMI watchdog (hard-lockup).
......@@ -2933,8 +3042,9 @@
on: enable the feature
page_poison= [KNL] Boot-time parameter changing the state of
poisoning on the buddy allocator.
off: turn off poisoning
poisoning on the buddy allocator, available with
CONFIG_PAGE_POISONING=y.
off: turn off poisoning (default)
on: turn on poisoning
panic= [KNL] Kernel behaviour on panic: delay <timeout>
......@@ -2994,8 +3104,31 @@
See header of drivers/block/paride/pcd.c.
See also Documentation/blockdev/paride.txt.
pci=option[,option...] [PCI] various PCI subsystem options:
earlydump [X86] dump PCI config space before the kernel
pci=option[,option...] [PCI] various PCI subsystem options.
Some options herein operate on a specific device
or a set of devices (<pci_dev>). These are
specified in one of the following formats:
[<domain>:]<bus>:<dev>.<func>[/<dev>.<func>]*
pci:<vendor>:<device>[:<subvendor>:<subdevice>]
Note: the first format specifies a PCI
bus/device/function address which may change
if new hardware is inserted, if motherboard
firmware changes, or due to changes caused
by other kernel parameters. If the
domain is left unspecified, it is
taken to be zero. Optionally, a path
to a device through multiple device/function
addresses can be specified after the base
address (this is more robust against
renumbering issues). The second format
selects devices using IDs from the
configuration space which may match multiple
devices in the system.
earlydump dump PCI config space before the kernel
changes anything
off [X86] don't probe for the PCI bus
bios [X86-32] force use of PCI BIOS, don't access
......@@ -3123,11 +3256,10 @@
window. The default value is 64 megabytes.
resource_alignment=
Format:
[<order of align>@][<domain>:]<bus>:<slot>.<func>[; ...]
[<order of align>@]pci:<vendor>:<device>\
[:<subvendor>:<subdevice>][; ...]
[<order of align>@]<pci_dev>[; ...]
Specifies alignment and device to reassign
aligned memory resources.
aligned memory resources. How to
specify the device is described above.
If <order of align> is not specified,
PAGE_SIZE is used as alignment.
PCI-PCI bridge can be specified, if resource
......@@ -3170,6 +3302,15 @@
Adding the window is slightly risky (it may
conflict with unreported devices), so this
taints the kernel.
disable_acs_redir=<pci_dev>[; ...]
Specify one or more PCI devices (in the format
specified above) separated by semicolons.
Each device specified will have the PCI ACS
redirect capabilities forced off which will
allow P2P traffic between devices through
bridges without forcing it upstream. Note:
this removes isolation between devices and
may put more devices in an IOMMU group.
pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power
Management.
......@@ -3632,8 +3773,8 @@
Set time (s) after boot for CPU-hotplug testing.
rcutorture.onoff_interval= [KNL]
Set time (s) between CPU-hotplug operations, or
zero to disable CPU-hotplug testing.
Set time (jiffies) between CPU-hotplug operations,
or zero to disable CPU-hotplug testing.
rcutorture.shuffle_interval= [KNL]
Set task-shuffle interval (s). Shuffling tasks
......@@ -4060,6 +4201,8 @@
This parameter controls whether the Speculative Store
Bypass optimization is used.
On x86 the options are:
on - Unconditionally disable Speculative Store Bypass
off - Unconditionally enable Speculative Store Bypass
auto - Kernel detects whether the CPU model contains an
......@@ -4075,12 +4218,20 @@
seccomp - Same as "prctl" above, but all seccomp threads
will disable SSB unless they explicitly opt out.
Not specifying this option is equivalent to
spec_store_bypass_disable=auto.
Default mitigations:
X86: If CONFIG_SECCOMP=y "seccomp", otherwise "prctl"
On powerpc the options are:
on,auto - On Power8 and Power9 insert a store-forwarding
barrier on kernel entry and exit. On Power7
perform a software flush on kernel entry and
exit.
off - No action.
Not specifying this option is equivalent to
spec_store_bypass_disable=auto.
spia_io_base= [HW,MTD]
spia_fio_base=
spia_pedr=
......@@ -4846,3 +4997,8 @@
xirc2ps_cs= [NET,PCMCIA]
Format:
<irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]]
xhci-hcd.quirks [USB,KNL]
A hex value specifying bitmask with supplemental xhci
host controller quirks. Meaning of each bit can be
consulted in header drivers/usb/host/xhci.h.
Documentation/admin-guide/l1tf.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/admin-guide/mm/idle_page_tracking.rst
View file @ e42f6f9b
......@@ -65,6 +65,11 @@ workload one should:
are not reclaimable, he or she can filter them out using
``/proc/kpageflags``.
The page-types tool in the tools/vm directory can be used to assist in this.
If the tool is run initially with the appropriate option, it will mark all the
queried pages as idle. Subsequent runs of the tool can then show which pages have
their idle flag cleared in the interim.
See :ref:`Documentation/admin-guide/mm/pagemap.rst <pagemap>` for more
information about ``/proc/pid/pagemap``, ``/proc/kpageflags``, and
``/proc/kpagecgroup``.
......
Documentation/admin-guide/mm/pagemap.rst
View file @ e42f6f9b
......@@ -44,6 +44,9 @@ There are four components to pagemap:
* ``/proc/kpagecount``. This file contains a 64-bit count of the number of
times each page is mapped, indexed by PFN.
The page-types tool in the tools/vm directory can be used to query the
number of times a page is mapped.
* ``/proc/kpageflags``. This file contains a 64-bit set of flags for each
page, indexed by PFN.
......
Documentation/admin-guide/pm/intel_pstate.rst
View file @ e42f6f9b
......@@ -324,8 +324,7 @@ Global Attributes
``intel_pstate`` exposes several global attributes (files) in ``sysfs`` to
control its functionality at the system level. They are located in the
``/sys/devices/system/cpu/cpufreq/intel_pstate/`` directory and affect all
CPUs.
``/sys/devices/system/cpu/intel_pstate/`` directory and affect all CPUs.
Some of them are not present if the ``intel_pstate=per_cpu_perf_limits``
argument is passed to the kernel in the command line.
......@@ -379,6 +378,17 @@ argument is passed to the kernel in the command line.
but it affects the maximum possible value of per-policy P-state limits
(see `Interpretation of Policy Attributes`_ below for details).
``hwp_dynamic_boost``
This attribute is only present if ``intel_pstate`` works in the
`active mode with the HWP feature enabled <Active Mode With HWP_>`_ in
the processor. If set (equal to 1), it causes the minimum P-state limit
to be increased dynamically for a short time whenever a task previously
waiting on I/O is selected to run on a given logical CPU (the purpose
of this mechanism is to improve performance).
This setting has no effect on logical CPUs whose minimum P-state limit
is directly set to the highest non-turbo P-state or above it.
.. _status_attr:
``status``
......
Documentation/arm64/sve.txt
View file @ e42f6f9b
......@@ -200,7 +200,7 @@ prctl(PR_SVE_SET_VL, unsigned long arg)
thread.
* Changing the vector length causes all of P0..P15, FFR and all bits of
Z0..V31 except for Z0 bits [127:0] .. Z31 bits [127:0] to become
Z0..Z31 except for Z0 bits [127:0] .. Z31 bits [127:0] to become
unspecified. Calling PR_SVE_SET_VL with vl equal to the thread's current
vector length, or calling PR_SVE_SET_VL with the PR_SVE_SET_VL_ONEXEC
flag, does not constitute a change to the vector length for this purpose.
......@@ -500,7 +500,7 @@ References
[2] arch/arm64/include/uapi/asm/ptrace.h
AArch64 Linux ptrace ABI definitions
[3] linux/Documentation/arm64/cpu-feature-registers.txt
[3] Documentation/arm64/cpu-feature-registers.txt
[4] ARM IHI0055C
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055c/IHI0055C_beta_aapcs64.pdf
......
Documentation/block/null_blk.txt
View file @ e42f6f9b
......@@ -85,3 +85,10 @@ shared_tags=[0/1]: Default: 0
0: Tag set is not shared.
1: Tag set shared between devices for blk-mq. Only makes sense with
nr_devices > 1, otherwise there's no tag set to share.
zoned=[0/1]: Default: 0
0: Block device is exposed as a random-access block device.
1: Block device is exposed as a host-managed zoned block device.
zone_size=[MB]: Default: 256
Per zone size when exposed as a zoned block device. Must be a power of two.
Documentation/block/stat.txt
View file @ e42f6f9b
......@@ -31,28 +31,32 @@ write ticks milliseconds total wait time for write requests
in_flight requests number of I/Os currently in flight
io_ticks milliseconds total time this block device has been active
time_in_queue milliseconds total wait time for all requests
discard I/Os requests number of discard I/Os processed
discard merges requests number of discard I/Os merged with in-queue I/O
discard sectors sectors number of sectors discarded
discard ticks milliseconds total wait time for discard requests
read I/Os, write I/Os
=====================
read I/Os, write I/Os, discard I/0s
===================================
These values increment when an I/O request completes.
read merges, write merges
=========================
read merges, write merges, discard merges
=========================================
These values increment when an I/O request is merged with an
already-queued I/O request.
read sectors, write sectors
===========================
read sectors, write sectors, discard_sectors
============================================
These values count the number of sectors read from or written to this
block device. The "sectors" in question are the standard UNIX 512-byte
sectors, not any device- or filesystem-specific block size. The
counters are incremented when the I/O completes.
These values count the number of sectors read from, written to, or
discarded from this block device. The "sectors" in question are the
standard UNIX 512-byte sectors, not any device- or filesystem-specific
block size. The counters are incremented when the I/O completes.
read ticks, write ticks
=======================
read ticks, write ticks, discard ticks
======================================
These values count the number of milliseconds that I/O requests have
waited on this block device. If there are multiple I/O requests waiting,
......
Documentation/bpf/README.rst deleted 100644 → 0
View file @ 4408e300
=================
BPF documentation
=================
This directory contains documentation for the BPF (Berkeley Packet
Filter) facility, with a focus on the extended BPF version (eBPF).
This kernel side documentation is still work in progress. The main
textual documentation is (for historical reasons) described in
`Documentation/networking/filter.txt`_, which describe both classical
and extended BPF instruction-set.
The Cilium project also maintains a `BPF and XDP Reference Guide`_
that goes into great technical depth about the BPF Architecture.
The primary info for the bpf syscall is available in the `man-pages`_
for `bpf(2)`_.
Frequently asked questions (FAQ)
================================
Two sets of Questions and Answers (Q&A) are maintained.
* QA for common questions about BPF see: bpf_design_QA_
* QA for developers interacting with BPF subsystem: bpf_devel_QA_
.. Links:
.. _bpf_design_QA: bpf_design_QA.rst
.. _bpf_devel_QA: bpf_devel_QA.rst
.. _Documentation/networking/filter.txt: ../networking/filter.txt
.. _man-pages: https://www.kernel.org/doc/man-pages/
.. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html
.. _BPF and XDP Reference Guide: http://cilium.readthedocs.io/en/latest/bpf/
Documentation/bpf/bpf_devel_QA.rst
View file @ e42f6f9b
......@@ -106,9 +106,9 @@ into the bpf-next tree will make their way into net-next tree. net and
net-next are both run by David S. Miller. From there, they will go
into the kernel mainline tree run by Linus Torvalds. To read up on the
process of net and net-next being merged into the mainline tree, see
the `netdev FAQ`_ under:
the :ref:`netdev-FAQ`
`Documentation/networking/netdev-FAQ.txt`_
Occasionally, to prevent merge conflicts, we might send pull requests
to other trees (e.g. tracing) with a small subset of the patches, but
......@@ -125,8 +125,8 @@ request)::
Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be applied to?
---------------------------------------------------------------------------------
A: The process is the very same as described in the `netdev FAQ`_, so
please read up on it. The subject line must indicate whether the
A: The process is the very same as described in the :ref:`netdev-FAQ`,
so please read up on it. The subject line must indicate whether the
patch is a fix or rather "next-like" content in order to let the
maintainers know whether it is targeted at bpf or bpf-next.
......@@ -184,7 +184,7 @@ ii) run extensive BPF test suite and
Once the BPF pull request was accepted by David S. Miller, then
the patches end up in net or net-next tree, respectively, and
make their way from there further into mainline. Again, see the
`netdev FAQ`_ for additional information e.g. on how often they are
:ref:`netdev-FAQ` for additional information e.g. on how often they are
merged to mainline.
Q: How long do I need to wait for feedback on my BPF patches?
......@@ -208,7 +208,7 @@ Q: Are patches applied to bpf-next when the merge window is open?
-----------------------------------------------------------------
A: For the time when the merge window is open, bpf-next will not be
processed. This is roughly analogous to net-next patch processing,
so feel free to read up on the `netdev FAQ`_ about further details.
so feel free to read up on the :ref:`netdev-FAQ` about further details.
During those two weeks of merge window, we might ask you to resend
your patch series once bpf-next is open again. Once Linus released
......@@ -372,7 +372,7 @@ netdev kernel mailing list in Cc and ask for the fix to be queued up:
netdev@vger.kernel.org
The process in general is the same as on netdev itself, see also the
`netdev FAQ`_ document.
:ref:`netdev-FAQ`.
Q: Do you also backport to kernels not currently maintained as stable?
----------------------------------------------------------------------
......@@ -388,9 +388,7 @@ Q: The BPF patch I am about to submit needs to go to stable as well
What should I do?
A: The same rules apply as with netdev patch submissions in general, see
`netdev FAQ`_ under:
`Documentation/networking/netdev-FAQ.txt`_
the :ref:`netdev-FAQ`.
Never add "``Cc: stable@vger.kernel.org``" to the patch description, but
ask the BPF maintainers to queue the patches instead. This can be done
......@@ -630,8 +628,7 @@ when:
.. Links
.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
.. _MAINTAINERS: ../../MAINTAINERS
.. _Documentation/networking/netdev-FAQ.txt: ../networking/netdev-FAQ.txt
.. _netdev FAQ: ../networking/netdev-FAQ.txt
.. _netdev-FAQ: ../networking/netdev-FAQ.rst
.. _samples/bpf/: ../../samples/bpf/
.. _selftests: ../../tools/testing/selftests/bpf/
.. _Documentation/dev-tools/kselftest.rst:
......
Documentation/bpf/index.rst 0 → 100644
View file @ e42f6f9b
=================
BPF Documentation
=================
This directory contains documentation for the BPF (Berkeley Packet
Filter) facility, with a focus on the extended BPF version (eBPF).
This kernel side documentation is still work in progress. The main
textual documentation is (for historical reasons) described in
`Documentation/networking/filter.txt`_, which describe both classical
and extended BPF instruction-set.
The Cilium project also maintains a `BPF and XDP Reference Guide`_
that goes into great technical depth about the BPF Architecture.
The primary info for the bpf syscall is available in the `man-pages`_
for `bpf(2)`_.
Frequently asked questions (FAQ)
================================
Two sets of Questions and Answers (Q&A) are maintained.
.. toctree::
:maxdepth: 1
bpf_design_QA
bpf_devel_QA
.. Links:
.. _Documentation/networking/filter.txt: ../networking/filter.txt
.. _man-pages: https://www.kernel.org/doc/man-pages/
.. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html
.. _BPF and XDP Reference Guide: http://cilium.readthedocs.io/en/latest/bpf/
Documentation/conf.py
View file @ e42f6f9b
......@@ -34,7 +34,7 @@ needs_sphinx = '1.3'
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 'kfigure']
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 'kfigure', 'sphinx.ext.ifconfig']
# The name of the math extension changed on Sphinx 1.4
if major == 1 and minor > 3:
......
Documentation/console/console.txt
View file @ e42f6f9b
Console Drivers
===============
The linux kernel has 2 general types of console drivers. The first type is
The Linux kernel has 2 general types of console drivers. The first type is
assigned by the kernel to all the virtual consoles during the boot process.
This type will be called 'system driver', and only one system driver is allowed
to exist. The system driver is persistent and it can never be unloaded, though
......@@ -17,10 +17,11 @@ of driver occupying the consoles.) They can only take over the console that is
occupied by the system driver. In the same token, if the modular driver is
released by the console, the system driver will take over.
Modular drivers, from the programmer's point of view, has to call:
Modular drivers, from the programmer's point of view, have to call:
do_take_over_console() - load and bind driver to console layer
give_up_console() - unload driver, it will only work if driver is fully unbond
give_up_console() - unload driver; it will only work if driver
is fully unbound
In newer kernels, the following are also available:
......@@ -56,7 +57,7 @@ What do these files signify?
cat /sys/class/vtconsole/vtcon0/name
(S) VGA+
'(S)' stands for a (S)ystem driver, ie, it cannot be directly
'(S)' stands for a (S)ystem driver, i.e., it cannot be directly
commanded to bind or unbind
'VGA+' is the name of the driver
......@@ -89,7 +90,7 @@ driver, make changes, recompile, reload and rebind the driver without any need
for rebooting the kernel. For regular users who may want to switch from
framebuffer console to VGA console and vice versa, this feature also makes
this possible. (NOTE NOTE NOTE: Please read fbcon.txt under Documentation/fb
for more details).
for more details.)
Notes for developers:
=====================
......@@ -110,8 +111,8 @@ In order for binding to and unbinding from the console to properly work,
console drivers must follow these guidelines:
1. All drivers, except system drivers, must call either do_register_con_driver()
or do_take_over_console(). do_register_con_driver() will just add the driver to
the console's internal list. It won't take over the
or do_take_over_console(). do_register_con_driver() will just add the driver
to the console's internal list. It won't take over the
console. do_take_over_console(), as it name implies, will also take over (or
bind to) the console.
......
Documentation/core-api/atomic_ops.rst
View file @ e42f6f9b
......@@ -29,7 +29,7 @@ updated by one CPU, local_t is probably more appropriate. Please see
local_t.
The first operations to implement for atomic_t's are the initializers and
plain reads. ::
plain writes. ::
#define ATOMIC_INIT(i) { (i) }
#define atomic_set(v, i) ((v)->counter = (i))
......
Documentation/core-api/boot-time-mm.rst 0 → 100644
View file @ e42f6f9b
===========================
Boot time memory management
===========================
Early system initialization cannot use "normal" memory management
simply because it is not set up yet. But there is still need to
allocate memory for various data structures, for instance for the
physical page allocator. To address this, a specialized allocator
called the :ref:`Boot Memory Allocator <bootmem>`, or bootmem, was
introduced. Several years later PowerPC developers added a "Logical
Memory Blocks" allocator, which was later adopted by other
architectures and renamed to :ref:`memblock <memblock>`. There is also
a compatibility layer called `nobootmem` that translates bootmem
allocation interfaces to memblock calls.
The selection of the early allocator is done using
``CONFIG_NO_BOOTMEM`` and ``CONFIG_HAVE_MEMBLOCK`` kernel
configuration options. These options are enabled or disabled
statically by the architectures' Kconfig files.
* Architectures that rely only on bootmem select
``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=n``.
* The users of memblock with the nobootmem compatibility layer set
``CONFIG_NO_BOOTMEM=y && CONFIG_HAVE_MEMBLOCK=y``.
* And for those that use both memblock and bootmem the configuration
includes ``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=y``.
Whichever allocator is used, it is the responsibility of the
architecture specific initialization to set it up in
:c:func:`setup_arch` and tear it down in :c:func:`mem_init` functions.
Once the early memory management is available it offers a variety of
functions and macros for memory allocations. The allocation request
may be directed to the first (and probably the only) node or to a
particular node in a NUMA system. There are API variants that panic
when an allocation fails and those that don't. And more recent and
advanced memblock even allows controlling its own behaviour.
.. _bootmem:
Bootmem
=======
(mostly stolen from Mel Gorman's "Understanding the Linux Virtual
Memory Manager" `book`_)
.. _book: https://www.kernel.org/doc/gorman/
.. kernel-doc:: mm/bootmem.c
:doc: bootmem overview
.. _memblock:
Memblock
========
.. kernel-doc:: mm/memblock.c
:doc: memblock overview
Functions and structures
========================
Common API
----------
The functions that are described in this section are available
regardless of what early memory manager is enabled.
.. kernel-doc:: mm/nobootmem.c
Bootmem specific API
--------------------
These interfaces available only with bootmem, i.e when ``CONFIG_NO_BOOTMEM=n``
.. kernel-doc:: include/linux/bootmem.h
.. kernel-doc:: mm/bootmem.c
:nodocs:
Memblock specific API
---------------------
Here is the description of memblock data structures, functions and
macros. Some of them are actually internal, but since they are
documented it would be silly to omit them. Besides, reading the
descriptions for the internal functions can help to understand what
really happens under the hood.
.. kernel-doc:: include/linux/memblock.h
.. kernel-doc:: mm/memblock.c
:nodocs:
Documentation/core-api/idr.rst
View file @ e42f6f9b
......@@ -76,4 +76,6 @@ Functions and structures
========================
.. kernel-doc:: include/linux/idr.h
:functions:
.. kernel-doc:: lib/idr.c
:functions:
Documentation/core-api/index.rst
View file @ e42f6f9b
......@@ -27,7 +27,10 @@ Core utilities
errseq
printk-formats
circular-buffers
mm-api
gfp_mask-from-fs-io
timekeeping
boot-time-mm
Interfaces for kernel debugging
===============================
......
Documentation/core-api/kernel-api.rst
View file @ e42f6f9b
......@@ -39,6 +39,10 @@ String Manipulation
.. kernel-doc:: lib/string.c
:export:
.. kernel-doc:: mm/util.c
:functions: kstrdup kstrdup_const kstrndup kmemdup kmemdup_nul memdup_user
vmemdup_user strndup_user memdup_user_nul
Basic Kernel Library Functions
==============================
......@@ -155,60 +159,6 @@ UUID/GUID
.. kernel-doc:: lib/uuid.c
:export:
Memory Management in Linux
==========================
The Slab Cache
--------------
.. kernel-doc:: include/linux/slab.h
:internal:
.. kernel-doc:: mm/slab.c
:export:
.. kernel-doc:: mm/util.c
:export:
User Space Memory Access
------------------------
.. kernel-doc:: arch/x86/include/asm/uaccess.h
:internal:
.. kernel-doc:: arch/x86/lib/usercopy_32.c
:export:
More Memory Management Functions
--------------------------------
.. kernel-doc:: mm/readahead.c
:export:
.. kernel-doc:: mm/filemap.c
:export:
.. kernel-doc:: mm/memory.c
:export:
.. kernel-doc:: mm/vmalloc.c
:export:
.. kernel-doc:: mm/page_alloc.c
:internal:
.. kernel-doc:: mm/mempool.c
:export:
.. kernel-doc:: mm/dmapool.c
:export:
.. kernel-doc:: mm/page-writeback.c
:export:
.. kernel-doc:: mm/truncate.c
:export:
Kernel IPC facilities
=====================
......@@ -437,4 +387,3 @@ Read-Copy Update (RCU)
.. kernel-doc:: include/linux/rcu_sync.h
.. kernel-doc:: kernel/rcu/sync.c
Documentation/core-api/mm-api.rst 0 → 100644
View file @ e42f6f9b
======================
Memory Management APIs
======================
User Space Memory Access
========================
.. kernel-doc:: arch/x86/include/asm/uaccess.h
:internal:
.. kernel-doc:: arch/x86/lib/usercopy_32.c
:export:
.. kernel-doc:: mm/util.c
:functions: get_user_pages_fast
Memory Allocation Controls
==========================
Functions which need to allocate memory often use GFP flags to express
how that memory should be allocated. The GFP acronym stands for "get
free pages", the underlying memory allocation function. Not every GFP
flag is allowed to every function which may allocate memory. Most
users will want to use a plain ``GFP_KERNEL``.
.. kernel-doc:: include/linux/gfp.h
:doc: Page mobility and placement hints
.. kernel-doc:: include/linux/gfp.h
:doc: Watermark modifiers
.. kernel-doc:: include/linux/gfp.h
:doc: Reclaim modifiers
.. kernel-doc:: include/linux/gfp.h
:doc: Common combinations
The Slab Cache
==============
.. kernel-doc:: include/linux/slab.h
:internal:
.. kernel-doc:: mm/slab.c
:export:
.. kernel-doc:: mm/util.c
:functions: kfree_const kvmalloc_node kvfree
More Memory Management Functions
================================
.. kernel-doc:: mm/readahead.c
:export:
.. kernel-doc:: mm/filemap.c
:export:
.. kernel-doc:: mm/memory.c
:export:
.. kernel-doc:: mm/vmalloc.c
:export:
.. kernel-doc:: mm/page_alloc.c
:internal:
.. kernel-doc:: mm/mempool.c
:export:
.. kernel-doc:: mm/dmapool.c
:export:
.. kernel-doc:: mm/page-writeback.c
:export:
.. kernel-doc:: mm/truncate.c
:export:
Documentation/core-api/timekeeping.rst 0 → 100644
View file @ e42f6f9b
ktime accessors
===============
Device drivers can read the current time using ktime_get() and the many
related functions declared in linux/timekeeping.h. As a rule of thumb,
using an accessor with a shorter name is preferred over one with a longer
name if both are equally fit for a particular use case.
Basic ktime_t based interfaces
------------------------------
The recommended simplest form returns an opaque ktime_t, with variants
that return time for different clock references:
.. c:function:: ktime_t ktime_get( void )
CLOCK_MONOTONIC
Useful for reliable timestamps and measuring short time intervals
accurately. Starts at system boot time but stops during suspend.
.. c:function:: ktime_t ktime_get_boottime( void )
CLOCK_BOOTTIME
Like ktime_get(), but does not stop when suspended. This can be
used e.g. for key expiration times that need to be synchronized
with other machines across a suspend operation.
.. c:function:: ktime_t ktime_get_real( void )
CLOCK_REALTIME
Returns the time in relative to the UNIX epoch starting in 1970
using the Coordinated Universal Time (UTC), same as gettimeofday()
user space. This is used for all timestamps that need to
persist across a reboot, like inode times, but should be avoided
for internal uses, since it can jump backwards due to a leap
second update, NTP adjustment settimeofday() operation from user
space.
.. c:function:: ktime_t ktime_get_clocktai( void )
CLOCK_TAI
Like ktime_get_real(), but uses the International Atomic Time (TAI)
reference instead of UTC to avoid jumping on leap second updates.
This is rarely useful in the kernel.
.. c:function:: ktime_t ktime_get_raw( void )
CLOCK_MONOTONIC_RAW
Like ktime_get(), but runs at the same rate as the hardware
clocksource without (NTP) adjustments for clock drift. This is
also rarely needed in the kernel.
nanosecond, timespec64, and second output
-----------------------------------------
For all of the above, there are variants that return the time in a
different format depending on what is required by the user:
.. c:function:: u64 ktime_get_ns( void )
u64 ktime_get_boottime_ns( void )
u64 ktime_get_real_ns( void )
u64 ktime_get_tai_ns( void )
u64 ktime_get_raw_ns( void )
Same as the plain ktime_get functions, but returning a u64 number
of nanoseconds in the respective time reference, which may be
more convenient for some callers.
.. c:function:: void ktime_get_ts64( struct timespec64 * )
void ktime_get_boottime_ts64( struct timespec64 * )
void ktime_get_real_ts64( struct timespec64 * )
void ktime_get_clocktai_ts64( struct timespec64 * )
void ktime_get_raw_ts64( struct timespec64 * )
Same above, but returns the time in a 'struct timespec64', split
into seconds and nanoseconds. This can avoid an extra division
when printing the time, or when passing it into an external
interface that expects a 'timespec' or 'timeval' structure.
.. c:function:: time64_t ktime_get_seconds( void )
time64_t ktime_get_boottime_seconds( void )
time64_t ktime_get_real_seconds( void )
time64_t ktime_get_clocktai_seconds( void )
time64_t ktime_get_raw_seconds( void )
Return a coarse-grained version of the time as a scalar
time64_t. This avoids accessing the clock hardware and rounds
down the seconds to the full seconds of the last timer tick
using the respective reference.
Coarse and fast_ns access
-------------------------
Some additional variants exist for more specialized cases:
.. c:function:: ktime_t ktime_get_coarse_boottime( void )
ktime_t ktime_get_coarse_real( void )
ktime_t ktime_get_coarse_clocktai( void )
ktime_t ktime_get_coarse_raw( void )
.. c:function:: void ktime_get_coarse_ts64( struct timespec64 * )
void ktime_get_coarse_boottime_ts64( struct timespec64 * )
void ktime_get_coarse_real_ts64( struct timespec64 * )
void ktime_get_coarse_clocktai_ts64( struct timespec64 * )
void ktime_get_coarse_raw_ts64( struct timespec64 * )
These are quicker than the non-coarse versions, but less accurate,
corresponding to CLOCK_MONONOTNIC_COARSE and CLOCK_REALTIME_COARSE
in user space, along with the equivalent boottime/tai/raw
timebase not available in user space.
The time returned here corresponds to the last timer tick, which
may be as much as 10ms in the past (for CONFIG_HZ=100), same as
reading the 'jiffies' variable. These are only useful when called
in a fast path and one still expects better than second accuracy,
but can't easily use 'jiffies', e.g. for inode timestamps.
Skipping the hardware clock access saves around 100 CPU cycles
on most modern machines with a reliable cycle counter, but
up to several microseconds on older hardware with an external
clocksource.
.. c:function:: u64 ktime_get_mono_fast_ns( void )
u64 ktime_get_raw_fast_ns( void )
u64 ktime_get_boot_fast_ns( void )
u64 ktime_get_real_fast_ns( void )
These variants are safe to call from any context, including from
a non-maskable interrupt (NMI) during a timekeeper update, and
while we are entering suspend with the clocksource powered down.
This is useful in some tracing or debugging code as well as
machine check reporting, but most drivers should never call them,
since the time is allowed to jump under certain conditions.
Deprecated time interfaces
--------------------------
Older kernels used some other interfaces that are now being phased out
but may appear in third-party drivers being ported here. In particular,
all interfaces returning a 'struct timeval' or 'struct timespec' have
been replaced because the tv_sec member overflows in year 2038 on 32-bit
architectures. These are the recommended replacements:
.. c:function:: void ktime_get_ts( struct timespec * )
Use ktime_get() or ktime_get_ts64() instead.
.. c:function:: struct timeval do_gettimeofday( void )
struct timespec getnstimeofday( void )
struct timespec64 getnstimeofday64( void )
void ktime_get_real_ts( struct timespec * )
ktime_get_real_ts64() is a direct replacement, but consider using
monotonic time (ktime_get_ts64()) and/or a ktime_t based interface
(ktime_get()/ktime_get_real()).
.. c:function:: struct timespec current_kernel_time( void )
struct timespec64 current_kernel_time64( void )
struct timespec get_monotonic_coarse( void )
struct timespec64 get_monotonic_coarse64( void )
These are replaced by ktime_get_coarse_real_ts64() and
ktime_get_coarse_ts64(). However, A lot of code that wants
coarse-grained times can use the simple 'jiffies' instead, while
some drivers may actually want the higher resolution accessors
these days.
.. c:function:: struct timespec getrawmonotonic( void )
struct timespec64 getrawmonotonic64( void )
struct timespec timekeeping_clocktai( void )
struct timespec64 timekeeping_clocktai64( void )
struct timespec get_monotonic_boottime( void )
struct timespec64 get_monotonic_boottime64( void )
These are replaced by ktime_get_raw()/ktime_get_raw_ts64(),
ktime_get_clocktai()/ktime_get_clocktai_ts64() as well
as ktime_get_boottime()/ktime_get_boottime_ts64().
However, if the particular choice of clock source is not
important for the user, consider converting to
ktime_get()/ktime_get_ts64() instead for consistency.
Documentation/crypto/api-samples.rst
View file @ e42f6f9b
......@@ -162,7 +162,7 @@ Code Example For Use of Operational State Memory With SHASH
char *hash_alg_name = "sha1-padlock-nano";
int ret;
alg = crypto_alloc_shash(hash_alg_name, CRYPTO_ALG_TYPE_SHASH, 0);
alg = crypto_alloc_shash(hash_alg_name, 0, 0);
if (IS_ERR(alg)) {
pr_info("can't alloc alg %s\n", hash_alg_name);
return PTR_ERR(alg);
......
Documentation/dev-tools/kselftest.rst
View file @ e42f6f9b
......@@ -156,6 +156,11 @@ Contributing new tests (details)
installed by the distro on the system should be the primary focus to be able
to find regressions.
* If a test needs specific kernel config options enabled, add a config file in
the test directory to enable them.
e.g: tools/testing/selftests/android/ion/config
Test Harness
============
......
Documentation/device-mapper/delay.txt
View file @ e42f6f9b
......@@ -5,7 +5,8 @@ Device-Mapper's "delay" target delays reads and/or writes
and maps them to different devices.
Parameters:
<device> <offset> <delay> [<write_device> <write_offset> <write_delay>]
<device> <offset> <delay> [<write_device> <write_offset> <write_delay>
[<flush_device> <flush_offset> <flush_delay>]]
With separate write parameters, the first set is only used for reads.
Offsets are specified in sectors.
......
Documentation/device-mapper/dm-integrity.txt
View file @ e42f6f9b
......@@ -113,6 +113,10 @@ internal_hash:algorithm(:key) (the key is optional)
from an upper layer target, such as dm-crypt. The upper layer
target should check the validity of the integrity tags.
recalculate
Recalculate the integrity tags automatically. It is only valid
when using internal hash.
journal_crypt:algorithm(:key) (the key is optional)
Encrypt the journal using given algorithm to make sure that the
attacker can't read the journal. You can use a block cipher here
......
Documentation/device-mapper/thin-provisioning.txt
View file @ e42f6f9b
......@@ -28,17 +28,18 @@ administrator some freedom, for example to:
Status
======
These targets are very much still in the EXPERIMENTAL state. Please
do not yet rely on them in production. But do experiment and offer us
feedback. Different use cases will have different performance
characteristics, for example due to fragmentation of the data volume.
These targets are considered safe for production use. But different use
cases will have different performance characteristics, for example due
to fragmentation of the data volume.
If you find this software is not performing as expected please mail
dm-devel@redhat.com with details and we'll try our best to improve
things for you.
Userspace tools for checking and repairing the metadata are under
development.
Userspace tools for checking and repairing the metadata have been fully
developed and are available as 'thin_check' and 'thin_repair'. The name
of the package that provides these utilities varies by distribution (on
a Red Hat distribution it is named 'device-mapper-persistent-data').
Cookbook
========
......@@ -280,7 +281,7 @@ ii) Status
<transaction id> <used metadata blocks>/<total metadata blocks>
<used data blocks>/<total data blocks> <held metadata root>
ro|rw|out_of_data_space [no_]discard_passdown [error|queue]_if_no_space
needs_check|-
needs_check|- metadata_low_watermark
transaction id:
A 64-bit number used by userspace to help synchronise with metadata
......@@ -327,6 +328,11 @@ ii) Status
thin-pool can be made fully operational again. '-' indicates
needs_check is not set.
metadata_low_watermark:
Value of metadata low watermark in blocks. The kernel sets this
value internally but userspace needs to know this value to
determine if an event was caused by crossing this threshold.
iii) Messages
create_thin <dev id>
......
Documentation/device-mapper/writecache.txt
View file @ e42f6f9b
......@@ -15,6 +15,8 @@ Constructor parameters:
size)
5. the number of optional parameters (the parameters with an argument
count as two)
start_sector n (default: 0)
offset from the start of cache device in 512-byte sectors
high_watermark n (default: 50)
start writeback when the number of used blocks reach this
watermark
......
Documentation/devicetree/bindings/arm/adapteva.txt deleted 100644 → 0
View file @ 4408e300
Adapteva Platforms Device Tree Bindings
---------------------------------------
Parallella board
Required root node properties:
- compatible = "adapteva,parallella";
Documentation/devicetree/bindings/arm/amlogic.txt
View file @ e42f6f9b
......@@ -41,6 +41,14 @@ Boards with the Amlogic Meson GXL S905D SoC shall have the following properties:
Required root node property:
compatible: "amlogic,s905d", "amlogic,meson-gxl";
Boards with the Amlogic Meson GXL S805X SoC shall have the following properties:
Required root node property:
compatible: "amlogic,s805x", "amlogic,meson-gxl";
Boards with the Amlogic Meson GXL S905W SoC shall have the following properties:
Required root node property:
compatible: "amlogic,s905w", "amlogic,meson-gxl";
Boards with the Amlogic Meson GXM S912 SoC shall have the following properties:
Required root node property:
compatible: "amlogic,s912", "amlogic,meson-gxm";
......@@ -79,6 +87,11 @@ Board compatible values (alphabetically, grouped by SoC):
- "amlogic,p230" (Meson gxl s905d)
- "amlogic,p231" (Meson gxl s905d)
- "amlogic,p241" (Meson gxl s805x)
- "amlogic,p281" (Meson gxl s905w)
- "oranth,tx3-mini" (Meson gxl s905w)
- "amlogic,q200" (Meson gxm s912)
- "amlogic,q201" (Meson gxm s912)
- "khadas,vim2" (Meson gxm s912)
......
Documentation/devicetree/bindings/arm/atmel-pmc.txt deleted 100644 → 0
View file @ 4408e300
* Power Management Controller (PMC)
Required properties:
- compatible: Should be "atmel,<chip>-pmc".
<chip> can be: at91rm9200, at91sam9260, at91sam9g45, at91sam9n12,
at91sam9x5, sama5d3
- reg: Should contain PMC registers location and length
Examples:
pmc: pmc@fffffc00 {
compatible = "atmel,at91rm9200-pmc";
reg = <0xfffffc00 0x100>;
};
Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
View file @ e42f6f9b
......@@ -189,7 +189,11 @@ Power-Down (SRPD), among other things.
Required properties:
- compatible : should contain one of these
"brcm,brcmstb-memc-ddr-rev-b.2.1"
"brcm,brcmstb-memc-ddr-rev-b.2.2"
"brcm,brcmstb-memc-ddr-rev-b.2.3"
"brcm,brcmstb-memc-ddr-rev-b.3.0"
"brcm,brcmstb-memc-ddr-rev-b.3.1"
"brcm,brcmstb-memc-ddr"
- reg : the MEMC DDR register range
......
Documentation/devicetree/bindings/arm/coresight.txt
View file @ e42f6f9b
......@@ -39,6 +39,8 @@ its hardware characteristcs.
- System Trace Macrocell:
"arm,coresight-stm", "arm,primecell"; [1]
- Coresight Address Translation Unit (CATU)
"arm,coresight-catu", "arm,primecell";
* reg: physical base address and length of the register
set(s) of the component.
......@@ -84,8 +86,15 @@ its hardware characteristcs.
* Optional property for TMC:
* arm,buffer-size: size of contiguous buffer space for TMC ETR
(embedded trace router)
(embedded trace router). This property is obsolete. The buffer size
can be configured dynamically via buffer_size property in sysfs.
* arm,scatter-gather: boolean. Indicates that the TMC-ETR can safely
use the SG mode on this system.
* Optional property for CATU :
* interrupts : Exactly one SPI may be listed for reporting the address
error
Example:
......@@ -118,6 +127,35 @@ Example:
};
};
etr@20070000 {
compatible = "arm,coresight-tmc", "arm,primecell";
reg = <0 0x20070000 0 0x1000>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
ports {
#address-cells = <1>;
#size-cells = <0>;
/* input port */
port@0 {
reg = <0>;
etr_in_port: endpoint {
slave-mode;
remote-endpoint = <&replicator2_out_port0>;
};
};
/* CATU link represented by output port */
port@1 {
reg = <1>;
etr_out_port: endpoint {
remote-endpoint = <&catu_in_port>;
};
};
};
};
2. Links
replicator {
/* non-configurable replicators don't show up on the
......@@ -247,5 +285,23 @@ Example:
};
};
5. CATU
catu@207e0000 {
compatible = "arm,coresight-catu", "arm,primecell";
reg = <0 0x207e0000 0 0x1000>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
port {
catu_in_port: endpoint {
slave-mode;
remote-endpoint = <&etr_out_port>;
};
};
};
[1]. There is currently two version of STM: STM32 and STM500. Both
have the same HW interface and as such don't need an explicit binding name.
Documentation/devicetree/bindings/arm/cpu-capacity.txt
View file @ e42f6f9b
......@@ -94,7 +94,7 @@ cpus {
};
idle-states {
entry-method = "arm,psci";
entry-method = "psci";
CPU_SLEEP_0: cpu-sleep-0 {
compatible = "arm,idle-state";
......
Documentation/devicetree/bindings/arm/cpus.txt
View file @ e42f6f9b
......@@ -183,6 +183,7 @@ described below.
"marvell,sheeva-v5"
"nvidia,tegra132-denver"
"nvidia,tegra186-denver"
"nvidia,tegra194-carmel"
"qcom,krait"
"qcom,kryo"
"qcom,kryo385"
......@@ -219,6 +220,7 @@ described below.
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
"renesas,apmu"
"renesas,r9a06g032-smp"
"rockchip,rk3036-smp"
"rockchip,rk3066-smp"
"ste,dbx500-smp"
......
Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt
View file @ e42f6f9b
......@@ -18,9 +18,6 @@ Required properties:
assignment of the interrupt router is required.
Flags get passed only when using GIC as parent. Flags
encoding as documented by the GIC bindings.
- interrupt-parent: Should be the phandle for the interrupt controller of
the CPU the device tree is intended to be used on. This
is either the node of the GIC or NVIC controller.
Example:
mscm_ir: interrupt-controller@40001800 {
......
Documentation/devicetree/bindings/arm/freescale/m4if.txt 0 → 100644
View file @ e42f6f9b
* Freescale Multi Master Multi Memory Interface (M4IF) module
Required properties:
- compatible : Should be "fsl,imx51-m4if"
- reg : Address and length of the register set for the device
Example:
m4if: m4if@83fd8000 {
compatible = "fsl,imx51-m4if";
reg = <0x83fd8000 0x1000>;
};
Documentation/devicetree/bindings/arm/freescale/tigerp.txt 0 → 100644
View file @ e42f6f9b
* Freescale Tigerp platform module
Required properties:
- compatible : Should be "fsl,imx51-tigerp"
- reg : Address and length of the register set for the device
Example:
tigerp: tigerp@83fa0000 {
compatible = "fsl,imx51-tigerp";
reg = <0x83fa0000 0x28>;
};
Documentation/devicetree/bindings/arm/fsl.txt
View file @ e42f6f9b
......@@ -53,6 +53,10 @@ i.MX6 Quad SABRE Automotive Board
Required root node properties:
- compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";
i.MX6SLL EVK board
Required root node properties:
- compatible = "fsl,imx6sll-evk", "fsl,imx6sll";
Generic i.MX boards
-------------------
......
Documentation/devicetree/bindings/arm/idle-states.txt
View file @ e42f6f9b
......@@ -237,8 +237,8 @@ processor idle states, defined as device tree nodes, are listed.
Value type: <stringlist>
Usage and definition depend on ARM architecture version.
# On ARM v8 64-bit this property is required and must
be one of:
- "psci" (see bindings in [2])
be:
- "psci"
# On ARM 32-bit systems this property is optional
The nodes describing the idle states (state) can only be defined within the
......
Documentation/devicetree/bindings/arm/insignal-boards.txt deleted 100644 → 0
View file @ 4408e300
* Insignal's Exynos4210 based Origen evaluation board
Origen low-cost evaluation board is based on Samsung's Exynos4210 SoC.
Required root node properties:
- compatible = should be one or more of the following.
(a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
(b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.
Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt
View file @ e42f6f9b
......@@ -2,14 +2,17 @@ Marvell Armada AP806 System Controller
======================================
The AP806 is one of the two core HW blocks of the Marvell Armada 7K/8K
SoCs. It contains a system controller, which provides a number
registers giving access to numerous features: clocks, pin-muxing and
many other SoC configuration items. This DT binding allows to describe
this system controller.
SoCs. It contains system controllers, which provide several registers
giving access to numerous features: clocks, pin-muxing and many other
SoC configuration items. This DT binding allows to describe these
system controllers.
For the top level node:
- compatible: must be: "syscon", "simple-mfd";
- reg: register area of the AP806 system controller
- reg: register area of the AP806 system controller
SYSTEM CONTROLLER 0
===================
Clocks:
-------
......@@ -98,3 +101,38 @@ ap_syscon: system-controller@6f4000 {
gpio-ranges = <&ap_pinctrl 0 0 19>;
};
};
SYSTEM CONTROLLER 1
===================
Thermal:
--------
For common binding part and usage, refer to
Documentation/devicetree/bindings/thermal/thermal.txt
The thermal IP can probe the temperature all around the processor. It
may feature several channels, each of them wired to one sensor.
Required properties:
- compatible: must be one of:
* marvell,armada-ap806-thermal
- reg: register range associated with the thermal functions.
Optional properties:
- #thermal-sensor-cells: shall be <1> when thermal-zones subnodes refer
to this IP and represents the channel ID. There is one sensor per
channel. O refers to the thermal IP internal channel, while positive
IDs refer to each CPU.
Example:
ap_syscon1: system-controller@6f8000 {
compatible = "syscon", "simple-mfd";
reg = <0x6f8000 0x1000>;
ap_thermal: thermal-sensor@80 {
compatible = "marvell,armada-ap806-thermal";
reg = <0x80 0x10>;
#thermal-sensor-cells = <1>;
};
};
Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
View file @ e42f6f9b
......@@ -33,3 +33,18 @@ nb_pm: syscon@14000 {
compatible = "marvell,armada-3700-nb-pm", "syscon";
reg = <0x14000 0x60>;
}
AVS
---
For AVS an other component is needed:
Required properties:
- compatible : should contain "marvell,armada-3700-avs", "syscon";
- reg : the register start and length for the AVS
Example:
avs: avs@11500 {
compatible = "marvell,armada-3700-avs", "syscon";
reg = <0x11500 0x40>;
}
Documentation/devicetree/bindings/arm/mediatek.txt
View file @ e42f6f9b
......@@ -11,6 +11,7 @@ compatible: Must contain one of
"mediatek,mt6589"
"mediatek,mt6592"
"mediatek,mt6755"
"mediatek,mt6765"
"mediatek,mt6795"
"mediatek,mt6797"
"mediatek,mt7622"
......@@ -41,12 +42,18 @@ Supported boards:
- Evaluation phone for MT6755(Helio P10):
Required root node properties:
- compatible = "mediatek,mt6755-evb", "mediatek,mt6755";
- Evaluation board for MT6765(Helio P22):
Required root node properties:
- compatible = "mediatek,mt6765-evb", "mediatek,mt6765";
- Evaluation board for MT6795(Helio X10):
Required root node properties:
- compatible = "mediatek,mt6795-evb", "mediatek,mt6795";
- Evaluation board for MT6797(Helio X20):
Required root node properties:
- compatible = "mediatek,mt6797-evb", "mediatek,mt6797";
- Mediatek X20 Development Board:
Required root node properties:
- compatible = "archermind,mt6797-x20-dev", "mediatek,mt6797";
- Reference board variant 1 for MT7622:
Required root node properties:
- compatible = "mediatek,mt7622-rfb1", "mediatek,mt7622";
......@@ -59,9 +66,6 @@ Supported boards:
- Reference board for MT7623n with eMMC:
Required root node properties:
- compatible = "mediatek,mt7623n-rfb-emmc", "mediatek,mt7623";
- Reference board for MT7623n with NAND:
Required root node properties:
- compatible = "mediatek,mt7623n-rfb-nand", "mediatek,mt7623";
- Bananapi BPI-R2 board:
- compatible = "bananapi,bpi-r2", "mediatek,mt7623";
- MTK mt8127 tablet moose EVB:
......
Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt 0 → 100644
View file @ e42f6f9b
== Introduction==
LLCC (Last Level Cache Controller) provides last level of cache memory in SOC,
that can be shared by multiple clients. Clients here are different cores in the
SOC, the idea is to minimize the local caches at the clients and migrate to
common pool of memory. Cache memory is divided into partitions called slices
which are assigned to clients. Clients can query the slice details, activate
and deactivate them.
Properties:
- compatible:
Usage: required
Value type: <string>
Definition: must be "qcom,sdm845-llcc"
- reg:
Usage: required
Value Type: <prop-encoded-array>
Definition: Start address and the the size of the register region.
Example:
cache-controller@1100000 {
compatible = "qcom,sdm845-llcc";
reg = <0x1100000 0x250000>;
};
Documentation/devicetree/bindings/arm/omap/crossbar.txt
View file @ e42f6f9b
......@@ -10,7 +10,6 @@ Required properties:
- compatible : Should be "ti,irq-crossbar"
- reg: Base address and the size of the crossbar registers.
- interrupt-controller: indicates that this block is an interrupt controller.
- interrupt-parent: the interrupt controller this block is connected to.
- ti,max-irqs: Total number of irqs available at the parent interrupt controller.
- ti,max-crossbar-sources: Maximum number of crossbar sources that can be routed.
- ti,reg-size: Size of a individual register in bytes. Every individual
......
Documentation/devicetree/bindings/arm/omap/l4.txt
View file @ e42f6f9b
......@@ -7,6 +7,7 @@ Required properties:
Should be "ti,omap2-l4-wkup" for OMAP2 family l4 wkup bus
Should be "ti,omap3-l4-core" for OMAP3 family l4 core bus
Should be "ti,omap4-l4-cfg" for OMAP4 family l4 cfg bus
Should be "ti,omap4-l4-per" for OMAP4 family l4 per bus
Should be "ti,omap4-l4-wkup" for OMAP4 family l4 wkup bus
Should be "ti,omap5-l4-cfg" for OMAP5 family l4 cfg bus
Should be "ti,omap5-l4-wkup" for OMAP5 family l4 wkup bus
......@@ -15,11 +16,21 @@ Required properties:
Should be "ti,am3-l4-wkup" for AM33xx family l4 wkup bus
Should be "ti,am4-l4-wkup" for AM43xx family l4 wkup bus
- ranges : contains the IO map range for the bus
- reg : registers link agent and interconnect agent and access protection
- reg-names : "la" for link agent, "ia0" to "ia3" for one to three
interconnect agent instances, "ap" for access if it exists
Examples:
l4: l4@48000000 {
compatible "ti,omap2-l4", "simple-bus";
l4: interconnect@48000000 {
compatible "ti,omap4-l4-per", "simple-bus";
reg = <0x48000000 0x800>,
<0x48000800 0x800>,
<0x48001000 0x400>,
<0x48001400 0x400>,
<0x48001800 0x400>,
<0x48001c00 0x400>;
reg-names = "ap", "la", "ia0", "ia1", "ia2", "ia3";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x48000000 0x100000>;
......
Documentation/devicetree/bindings/arm/rockchip.txt
View file @ e42f6f9b
Rockchip platforms device tree bindings
---------------------------------------
- 96boards RK3399 Ficus (ROCK960 Enterprise Edition)
Required root node properties:
- compatible = "vamrs,ficus", "rockchip,rk3399";
- Amarula Vyasa RK3288 board
Required root node properties:
- compatible = "amarula,vyasa-rk3288", "rockchip,rk3288";
......@@ -66,6 +71,15 @@ Rockchip platforms device tree bindings
Required root node properties:
- compatible = "geekbuying,geekbox", "rockchip,rk3368";
- Google Bob (Asus Chromebook Flip C101PA):
Required root node properties:
compatible = "google,bob-rev13", "google,bob-rev12",
"google,bob-rev11", "google,bob-rev10",
"google,bob-rev9", "google,bob-rev8",
"google,bob-rev7", "google,bob-rev6",
"google,bob-rev5", "google,bob-rev4",
"google,bob", "google,gru", "rockchip,rk3399";
- Google Brain (dev-board):
Required root node properties:
- compatible = "google,veyron-brain-rev0", "google,veyron-brain",
......
Documentation/devicetree/bindings/arm/ti/k3.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/bus/sun50i-de2-bus.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/clock/actions,owl-cmu.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/clock/maxim,max9485.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/clock/qcom,dispcc.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/crypto/qcom,prng.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/display/ilitek,ili9341.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/display/msm/dpu.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/dma/owl-dma.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/gnss/gnss.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/gnss/sirfstar.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/gnss/u-blox.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/i2c/i2c-fsi.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/i2c/i2c-owl.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/iio/adc/sprd,sc27xx-adc.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/iio/dac/ad5758.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/iio/light/isl29501.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/input/keys.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/input/touchscreen/eeti.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/leds/leds-lt3593.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/mailbox/fsl,mu.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/mailbox/mtk-gce.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/media/i2c/ak7375.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/media/i2c/ov2680.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/mfd/madera.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/misc/aspeed,cvic.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/mmc/sdhci-of-dwcmshc.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/mtd/partitions/brcm,trx.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/mtd/spi-nand.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/mux/adi,adgs1408.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/net/dsa/realtek-smi.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/net/mediatek-bluetooth.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/nvmem/sc27xx-efuse.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/phy/brcm,sr-pcie-phy.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/power/reset/qcom,pon.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/rng/qcom,prng.txt deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/devicetree/bindings/rtc/isil,isl1219.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/serial/renesas,rzn1-uart.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/sound/ac97-bus.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/sound/amlogic,axg-fifo.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/sound/everest,es7241.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/sound/name-prefix.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/sound/qcom,sdm845.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/sound/qcom,wcd9335.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/sound/rt5682.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/sound/simple-amplifier.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/spi/spi-uniphier.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/timer/ti,davinci-timer.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/ufs/ufs-hisi.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/usb/npcm7xx-usb.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/usb/typec-tcpci.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/devicetree/bindings/w1/w1.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/doc-guide/kernel-doc.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/doc-guide/parse-headers.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/doc-guide/sphinx.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/driver-api/device_link.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/driver-api/dma-buf.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/driver-api/fpga/fpga-mgr.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/driver-api/fpga/intro.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/driver-api/libata.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/driver-api/mtdnand.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/driver-api/slimbus.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/driver-api/usb/typec_bus.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/driver-model/devres.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/early-userspace/README
View file @ e42f6f9b
This diff is collapsed.
Documentation/fb/fbcon.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/Locking
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/cifs/CHANGES
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/cifs/README
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4.txt deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/filesystems/ext4/ext4.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/index.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/about.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/allocators.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/attributes.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/bigalloc.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/bitmaps.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/blockgroup.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/blockmap.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/blocks.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/checksums.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/directory.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/dynamic.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/eainode.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/globals.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/group_descr.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/ifork.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/index.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/inlinedata.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/inodes.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/journal.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/mmp.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/overview.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/special_inodes.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/ext4/ondisk/super.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/f2fs.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/index.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/overlayfs.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/porting
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/proc.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/relay.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/seq_file.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/vfs.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/filesystems/xfs.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/fpga/dfl.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/gpu/amdgpu.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/gpu/drivers.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/gpu/drm-client.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/gpu/drm-kms-helpers.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/gpu/drm-kms.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/gpu/drm-mm.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/gpu/index.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/gpu/kms-properties.csv
View file @ e42f6f9b
This diff is collapsed.
Documentation/gpu/msm-crash-dump.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/gpu/v3d.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/hwmon/ibmpowernv
View file @ e42f6f9b
This diff is collapsed.
Documentation/hwmon/ina2xx
View file @ e42f6f9b
This diff is collapsed.
Documentation/hwmon/max34440
View file @ e42f6f9b
This diff is collapsed.
Documentation/hwmon/mlxreg-fan 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/hwmon/npcm750-pwm-fan 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/hwmon/raspberrypi-hwmon 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/hwmon/sysfs-interface
View file @ e42f6f9b
This diff is collapsed.
Documentation/i2c/DMA-considerations
View file @ e42f6f9b
This diff is collapsed.
Documentation/i2c/busses/i2c-i801
View file @ e42f6f9b
This diff is collapsed.
Documentation/i2c/busses/i2c-ocores
View file @ e42f6f9b
This diff is collapsed.
Documentation/i2c/gpio-fault-injection
View file @ e42f6f9b
This diff is collapsed.
Documentation/index.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/ioctl/ioctl-number.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/iostats.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/kbuild/kbuild.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/kbuild/kconfig-language.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/kbuild/kconfig.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/kbuild/makefiles.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/kernel-hacking/hacking.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/kernel-hacking/index.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/kernel-hacking/locking.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/kprobes.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/locking/ww-mutex-design.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/media/audio.h.rst.exceptions
View file @ e42f6f9b
This diff is collapsed.
Documentation/media/media.h.rst.exceptions
View file @ e42f6f9b
This diff is collapsed.
Documentation/media/uapi/dvb/audio-get-pts.rst deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/media/uapi/dvb/audio-set-attributes.rst deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/media/uapi/dvb/audio-set-ext-id.rst deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/media/uapi/dvb/audio-set-karaoke.rst deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/media/uapi/dvb/video-get-frame-rate.rst deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/media/uapi/dvb/video-get-navi.rst deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/media/uapi/dvb/video-set-attributes.rst deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/media/uapi/dvb/video-set-highlight.rst deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/media/uapi/dvb/video-set-id.rst deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/media/uapi/dvb/video-set-spu-palette.rst deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/media/uapi/dvb/video-set-spu.rst deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/media/uapi/dvb/video-set-system.rst deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/media/uapi/v4l/pixfmt-rgb.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/media/uapi/v4l/pixfmt-srggb14p.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/media/uapi/v4l/pixfmt-y10p.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/media/v4l-drivers/qcom_camss_8x96_graph.dot 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/media/video.h.rst.exceptions
View file @ e42f6f9b
This diff is collapsed.
Documentation/memory-barriers.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/00-INDEX
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/alias.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/alias.txt deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/networking/bonding.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/bridge.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/bridge.txt deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/networking/can_ucan_protocol.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/dpaa2/dpio-driver.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/dpaa2/index.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/dpaa2/overview.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/e100.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/e1000.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/index.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/ip-sysctl.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/net_failover.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/netdev-FAQ.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/netdev-FAQ.txt deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/networking/scaling.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/strparser.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/ti-cpsw.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/networking/tproxy.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/nommu-mmap.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/pcmcia/driver-changes.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/power/freezing-of-tasks.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/powerpc/DAWR-POWER9.txt 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/process/2.Process.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/process/changes.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/process/howto.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/process/management-style.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/rfkill.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/sound/alsa-configuration.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/sound/cards/multisound.sh 0 → 100755
View file @ e42f6f9b
This diff is collapsed.
Documentation/sound/hd-audio/models.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/sound/soc/dpcm.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/sphinx/kerneldoc.py
View file @ e42f6f9b
This diff is collapsed.
Documentation/sphinx/parse-headers.pl
View file @ e42f6f9b
This diff is collapsed.
Documentation/sysctl/fs.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/sysctl/kernel.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/sysctl/vm.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/timers/timekeeping.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/trace/events-power.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/trace/events.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/trace/ftrace.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/trace/histogram.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/trace/histogram.txt deleted 100644 → 0
View file @ 4408e300
This diff is collapsed.
Documentation/trace/index.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/trace/kprobetrace.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/trace/uprobetracer.rst
View file @ e42f6f9b
This diff is collapsed.
Documentation/translations/index.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/translations/it_IT/disclaimer-ita.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/translations/it_IT/doc-guide/index.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/translations/it_IT/doc-guide/kernel-doc.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/translations/it_IT/doc-guide/parse-headers.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/translations/it_IT/doc-guide/sphinx.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/translations/it_IT/index.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/translations/it_IT/kernel-hacking/hacking.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/translations/it_IT/kernel-hacking/index.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/translations/it_IT/kernel-hacking/locking.rst 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
Documentation/usb/gadget_configfs.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/usb/usb-serial.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/virtual/kvm/api.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/virtual/kvm/cpuid.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/virtual/kvm/hypercalls.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/w1/slaves/w1_ds2438
View file @ e42f6f9b
This diff is collapsed.
Documentation/x86/intel_rdt_ui.txt
View file @ e42f6f9b
This diff is collapsed.
Documentation/x86/x86_64/boot-options.txt
View file @ e42f6f9b
This diff is collapsed.
Kconfig
View file @ e42f6f9b
This diff is collapsed.
MAINTAINERS
View file @ e42f6f9b
This diff is collapsed.
Makefile
View file @ e42f6f9b
This diff is collapsed.
arch/Kconfig
View file @ e42f6f9b
This diff is collapsed.
arch/alpha/Kconfig
View file @ e42f6f9b
This diff is collapsed.
arch/alpha/Kconfig.debug
View file @ e42f6f9b
This diff is collapsed.
arch/alpha/boot/Makefile
View file @ e42f6f9b
This diff is collapsed.
arch/alpha/include/asm/atomic.h
View file @ e42f6f9b
This diff is collapsed.
arch/alpha/include/uapi/asm/socket.h
View file @ e42f6f9b
This diff is collapsed.
arch/alpha/kernel/osf_sys.c
View file @ e42f6f9b
This diff is collapsed.
arch/alpha/mm/fault.c
View file @ e42f6f9b
This diff is collapsed.
arch/arc/Kconfig
View file @ e42f6f9b
This diff is collapsed.
arch/arc/Kconfig.debug
View file @ e42f6f9b
This diff is collapsed.
arch/arc/Makefile
View file @ e42f6f9b
This diff is collapsed.
arch/arc/configs/axs101_defconfig
View file @ e42f6f9b
This diff is collapsed.
arch/arc/configs/axs103_defconfig
View file @ e42f6f9b
This diff is collapsed.
arch/arc/configs/axs103_smp_defconfig
View file @ e42f6f9b
This diff is collapsed.
arch/arc/configs/haps_hs_defconfig
View file @ e42f6f9b
This diff is collapsed.
arch/arc/configs/haps_hs_smp_defconfig
View file @ e42f6f9b
This diff is collapsed.
arch/arc/configs/hsdk_defconfig
View file @ e42f6f9b
This diff is collapsed.
arch/arc/configs/nsim_700_defconfig
View file @ e42f6f9b
This diff is collapsed.
arch/arc/configs/nsim_hs_defconfig
View file @ e42f6f9b
This diff is collapsed.
arch/arc/configs/nsim_hs_smp_defconfig
View file @ e42f6f9b
This diff is collapsed.
arch/arc/configs/nsimosci_defconfig
View file @ e42f6f9b
This diff is collapsed.
arch/arc/configs/nsimosci_hs_defconfig
View file @ e42f6f9b
This diff is collapsed.
arch/arc/configs/nsimosci_hs_smp_defconfig
View file @ e42f6f9b
This diff is collapsed.
arch/arc/configs/tb10x_defconfig
View file @ e42f6f9b
This diff is collapsed.
arch/arc/include/asm/atomic.h
View file @ e42f6f9b
This diff is collapsed.
arch/arc/include/asm/cache.h
View file @ e42f6f9b
This diff is collapsed.
arch/arc/include/asm/delay.h
View file @ e42f6f9b
This diff is collapsed.
arch/arc/include/asm/entry-compact.h
View file @ e42f6f9b
This diff is collapsed.
arch/arc/include/asm/entry.h
View file @ e42f6f9b
This diff is collapsed.
arch/arc/include/asm/kprobes.h
View file @ e42f6f9b
This diff is collapsed.
arch/arc/include/asm/mach_desc.h
View file @ e42f6f9b
This diff is collapsed.
arch/arc/include/asm/page.h
View file @ e42f6f9b
This diff is collapsed.
arch/arc/include/asm/pgtable.h
View file @ e42f6f9b
This diff is collapsed.
arch/arc/kernel/irq.c
View file @ e42f6f9b
This diff is collapsed.
arch/arc/kernel/kprobes.c
View file @ e42f6f9b
This diff is collapsed.
arch/arc/kernel/process.c
View file @ e42f6f9b
This diff is collapsed.
arch/arc/mm/cache.c
View file @ e42f6f9b
This diff is collapsed.
arch/arc/mm/dma.c
View file @ e42f6f9b
This diff is collapsed.
arch/arc/mm/fault.c
View file @ e42f6f9b
This diff is collapsed.
arch/arc/plat-eznps/include/plat/ctop.h
View file @ e42f6f9b
This diff is collapsed.
arch/arc/plat-eznps/mtm.c
View file @ e42f6f9b
This diff is collapsed.
arch/arc/plat-hsdk/Kconfig
View file @ e42f6f9b
This diff is collapsed.
arch/arc/plat-hsdk/platform.c
View file @ e42f6f9b
This diff is collapsed.
arch/arm/Kconfig
View file @ e42f6f9b
This diff is collapsed.
arch/arm/Kconfig.debug
View file @ e42f6f9b
This diff is collapsed.
arch/arm/Makefile
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/Makefile
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am335x-baltos.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am335x-bone-common.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am335x-evm.dts
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am335x-evmsk.dts
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am335x-osd3358-sm-red.dts 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am335x-sancloud-bbe.dts 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am335x-sl50.dts
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am33xx.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am3517-evm.dts
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am3517-som.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am3517.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am4372.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am437x-gp-evm.dts
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am437x-sk-evm.dts
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am571x-idk.dts
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am572x-idk-common.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/am57xx-idk-common.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/armada-388-clearfog.dts
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/armada-388-clearfog.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/armada-388-helios4.dts 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/armada-38x.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/aspeed-ast2500-evb.dts
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/aspeed-g4.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/aspeed-g5.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/at91-dvk_som60.dts 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/at91-dvk_su60_somc.dtsi 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/at91-dvk_su60_somc_lcm.dtsi 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/at91-gatwick.dts 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/at91-som60.dtsi 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/at91-wb45n.dts 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/at91-wb45n.dtsi 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/at91-wb50n.dts 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/at91-wb50n.dtsi 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/at91sam9261.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/at91sam9263.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/at91sam9rl.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/at91sam9x5.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/bcm-cygnus.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/bcm-hr2.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/bcm-nsp.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/bcm2835-rpi-cm1-io1.dts 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/bcm2835-rpi-cm1.dtsi 0 → 100644
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/bcm2837.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/bcm283x.dtsi
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/bcm4708-netgear-r6250.dts
View file @ e42f6f9b
This diff is collapsed.
arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
View file @ e42f6f9b
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7