shinys000114/linux
1
0
Fork 0
mirror of https://github.com/hardkernel/linux.git synced 2026-06-06 10:58:48 +09:00
Code Issues Packages Projects Releases Wiki Activity

Merge 533369b145 ("Merge tag 'timers-core-2020-12-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip") into android-mailine

Browse Source 
Steps on the way to 5.11-rc1

Resolves merge conflicts in:
	include/uapi/linux/prctl.h
	kernel/sys.c

Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I85ea8cffcd22f93277b357872254fe21d68bd82c
This commit is contained in:
Greg Kroah-Hartman
2020-12-15 15:30:03 +01:00
parent 80b1c109be 533369b145
commit 482ed74e40
387 changed files with 9447 additions and 3379 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -7,7 +7,7 @@ Description:
ifname
- network device interface name associated with
this function instance
qmult
qmult
- queue length multiplier for high and
super speed
host_addr

20
Documentation/ABI/testing/procfs-attr-current Normal file
View File

@@ -0,0 +1,20 @@
What: /proc/*/attr/current
Contact: linux-security-module@vger.kernel.org,
selinux@vger.kernel.org,
apparmor@lists.ubuntu.com
Description: The current security information used by a Linux
security module (LSM) that is active on the system.
The details of permissions required to read from
this interface and hence obtain the security state
of the task identified is LSM dependent.
A process cannot write to this interface unless it
refers to itself.
The other details of permissions required to write to
this interface and hence change the security state of
the task identified are LSM dependent.
The format of the data used by this interface is LSM
dependent.
SELinux, Smack and AppArmor provide this interface.
Users: SELinux user-space
Smack user-space
AppArmor user-space

20
Documentation/ABI/testing/procfs-attr-exec Normal file
View File

@@ -0,0 +1,20 @@
What: /proc/*/attr/exec
Contact: linux-security-module@vger.kernel.org,
selinux@vger.kernel.org,
apparmor@lists.ubuntu.com
Description: The security information to be used on the process
by a Linux security module (LSM) active on the system
after a subsequent exec() call.
The details of permissions required to read from
this interface and hence obtain the security state
of the task identified is LSM dependent.
A process cannot write to this interface unless it
refers to itself.
The other details of permissions required to write to
this interface and hence change the security state of
the task identified are LSM dependent.
The format of the data used by this interface is LSM
dependent.
SELinux and AppArmor provide this interface.
Users: SELinux user-space
AppArmor user-space

19
Documentation/ABI/testing/procfs-attr-prev Normal file
View File

@@ -0,0 +1,19 @@
What: /proc/*/attr/prev
Contact: linux-security-module@vger.kernel.org,
selinux@vger.kernel.org,
apparmor@lists.ubuntu.com
Description: The security information used on the process by
a Linux security module (LSM) active on the system
prior to the most recent exec() call.
The details of permissions required to read from
this interface is LSM dependent.
A process cannot write to this interface unless it
refers to itself.
The other details of permissions required to write to
this interface are LSM dependent.
The format of the data used by this interface is LSM
dependent.
SELinux and AppArmor provide this interface.
Users: SELinux user-space
AppArmor user-space

2
Documentation/ABI/testing/sysfs-devices-memory
View File

@@ -19,7 +19,7 @@ Description:
identify removable sections of the memory before attempting
potentially expensive hot-remove memory operation
Users: hotplug memory remove tools
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
What: /sys/devices/system/memory/memoryX/phys_device
Date: September 2008

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

@@ -33,7 +33,7 @@ What: /sys/fs/ext4/<disk>/mb_order2_req
Date: March 2008
Contact: "Theodore Ts'o" <tytso@mit.edu>
Description:
Tuning parameter which controls the minimum size for
Tuning parameter which controls the minimum size for
requests (as a power of 2) where the buddy cache is
used

2
Documentation/ABI/testing/sysfs-module
View File

@@ -25,7 +25,7 @@ Description: Maximum time allowed for periodic transfers per microframe (μs)
However there are cases, when 80% max isochronous bandwidth is
too limiting. For example two video streams could require 110
microseconds of isochronous bandwidth per microframe to work
together.
together.
Through this setting it is possible to raise the limit so that
the host controller would allow allocating more than 100

2
Documentation/ABI/testing/sysfs-platform-renesas_usb3
View File

@@ -12,6 +12,6 @@ Description:
- "peripheral" - switching mode from host to peripheral.
Read the file, then it shows the following strings:
- "host" - The mode is host now.
- "peripheral" - The mode is peripheral now.

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

@@ -1929,16 +1929,46 @@ The Linux-kernel CPU-hotplug implementation has notifiers that are used
to allow the various kernel subsystems (including RCU) to respond
appropriately to a given CPU-hotplug operation. Most RCU operations may
be invoked from CPU-hotplug notifiers, including even synchronous
grace-period operations such as ``synchronize_rcu()`` and
``synchronize_rcu_expedited()``.
grace-period operations such as (``synchronize_rcu()`` and
``synchronize_rcu_expedited()``). However, these synchronous operations
do block and therefore cannot be invoked from notifiers that execute via
``stop_machine()``, specifically those between the ``CPUHP_AP_OFFLINE``
and ``CPUHP_AP_ONLINE`` states.
However, all-callback-wait operations such as ``rcu_barrier()`` are also
not supported, due to the fact that there are phases of CPU-hotplug
operations where the outgoing CPU's callbacks will not be invoked until
after the CPU-hotplug operation ends, which could also result in
deadlock. Furthermore, ``rcu_barrier()`` blocks CPU-hotplug operations
during its execution, which results in another type of deadlock when
invoked from a CPU-hotplug notifier.
In addition, all-callback-wait operations such as ``rcu_barrier()`` may
not be invoked from any CPU-hotplug notifier. This restriction is due
to the fact that there are phases of CPU-hotplug operations where the
outgoing CPU's callbacks will not be invoked until after the CPU-hotplug
operation ends, which could also result in deadlock. Furthermore,
``rcu_barrier()`` blocks CPU-hotplug operations during its execution,
which results in another type of deadlock when invoked from a CPU-hotplug
notifier.
Finally, RCU must avoid deadlocks due to interaction between hotplug,
timers and grace period processing. It does so by maintaining its own set
of books that duplicate the centrally maintained ``cpu_online_mask``,
and also by reporting quiescent states explicitly when a CPU goes
offline. This explicit reporting of quiescent states avoids any need
for the force-quiescent-state loop (FQS) to report quiescent states for
offline CPUs. However, as a debugging measure, the FQS loop does splat
if offline CPUs block an RCU grace period for too long.
An offline CPU's quiescent state will be reported either:
1. As the CPU goes offline using RCU's hotplug notifier (``rcu_report_dead()``).
2. When grace period initialization (``rcu_gp_init()``) detects a
race either with CPU offlining or with a task unblocking on a leaf
``rcu_node`` structure whose CPUs are all offline.
The CPU-online path (``rcu_cpu_starting()``) should never need to report
a quiescent state for an offline CPU. However, as a debugging measure,
it does emit a warning if a quiescent state was not already reported
for that CPU.
During the checking/modification of RCU's hotplug bookkeeping, the
corresponding CPU's leaf node lock is held. This avoids race conditions
between RCU's hotplug notifier hooks, the grace period initialization
code, and the FQS loop, all of which refer to or modify this bookkeeping.
Scheduler and RCU
~~~~~~~~~~~~~~~~~

7
Documentation/RCU/checklist.rst
View File

@@ -314,6 +314,13 @@ over a rather long period of time, but improvements are always welcome!
shared between readers and updaters. Additional primitives
are provided for this case, as discussed in lockdep.txt.
One exception to this rule is when data is only ever added to
the linked data structure, and is never removed during any
time that readers might be accessing that structure. In such
cases, READ_ONCE() may be used in place of rcu_dereference()
and the read-side markers (rcu_read_lock() and rcu_read_unlock(),
for example) may be omitted.
10. Conversely, if you are in an RCU read-side critical section,
and you don't hold the appropriate update-side lock, you -must-
use the "_rcu()" variants of the list macros. Failing to do so

6
Documentation/RCU/rcu_dereference.rst
View File

@@ -28,6 +28,12 @@ Follow these rules to keep your RCU code working properly:
for an example where the compiler can in fact deduce the exact
value of the pointer, and thus cause misordering.
- In the special case where data is added but is never removed
while readers are accessing the structure, READ_ONCE() may be used
instead of rcu_dereference(). In this case, use of READ_ONCE()
takes on the role of the lockless_dereference() primitive that
was removed in v4.15.
- You are only permitted to use rcu_dereference on pointer values.
The compiler simply knows too much about integral values to
trust it to carry dependencies through integer operations.

3
Documentation/RCU/whatisRCU.rst
View File

@@ -497,8 +497,7 @@ long -- there might be other high-priority work to be done.
In such cases, one uses call_rcu() rather than synchronize_rcu().
The call_rcu() API is as follows::
void call_rcu(struct rcu_head * head,
void (*func)(struct rcu_head *head));
void call_rcu(struct rcu_head *head, rcu_callback_t func);
This function invokes func(head) after a grace period has elapsed.
This invocation might happen from either softirq or process context,

4
Documentation/admin-guide/README.rst
View File

@@ -398,8 +398,8 @@ If something goes wrong
If you for some reason cannot do the above (you have a pre-compiled
kernel image or similar), telling me as much about your setup as
possible will help. Please read the :ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
document for details.
possible will help. Please read
'Documentation/admin-guide/reporting-issues.rst' for details.
- Alternatively, you can use gdb on a running kernel. (read-only; i.e. you
cannot change values or set break points.) To do this, first compile the

4
Documentation/admin-guide/acpi/cppc_sysfs.rst
View File

@@ -8,7 +8,7 @@ CPPC
====
CPPC defined in the ACPI spec describes a mechanism for the OS to manage the
performance of a logical processor on a contigious and abstract performance
performance of a logical processor on a contiguous and abstract performance
scale. CPPC exposes a set of registers to describe abstract performance scale,
to request performance levels and to measure per-cpu delivered performance.
@@ -45,7 +45,7 @@ for each cpu X::
* lowest_freq : CPU frequency corresponding to lowest_perf (in MHz).
* nominal_freq : CPU frequency corresponding to nominal_perf (in MHz).
The above frequencies should only be used to report processor performance in
freqency instead of abstract scale. These values should not be used for any
frequency instead of abstract scale. These values should not be used for any
functional decisions.
* feedback_ctrs : Includes both Reference and delivered performance counter.

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

@@ -70,5 +70,5 @@ Deleting binder Devices
Binderfs binder devices can be deleted via `unlink() <unlink_>`_. This means
that the `rm() <rm_>`_ tool can be used to delete them. Note that the
``binder-control`` device cannot be deleted since this would make the binderfs
instance unuseable. The ``binder-control`` device will be deleted when the
instance unusable. The ``binder-control`` device will be deleted when the
binderfs instance is unmounted and all references to it have been dropped.

2
Documentation/admin-guide/blockdev/paride.rst
View File

@@ -220,7 +220,7 @@ example::
Finally, you can load high-level drivers for each kind of device that
you have connected. By default, each driver will autoprobe for a single
device, but you can support up to four similar devices by giving their
individual co-ordinates when you load the driver.
individual coordinates when you load the driver.
For example, if you had two no-name CD-ROM drives both using the
KingByte KBIC-951A adapter, one on port 0x378 and the other on 0x3bc

2
Documentation/admin-guide/blockdev/zram.rst
View File

@@ -360,7 +360,7 @@ like below::
/sys/block/zram0/writeback_limit.
$ echo 1 > /sys/block/zram0/writeback_limit_enable
If admins want to allow further write again once the bugdet is exhausted,
If admins want to allow further write again once the budget is exhausted,
he could do it like below::
$ echo $((400<<MB_SHIFT>>4K_SHIFT)) > \

2
Documentation/admin-guide/bug-bisect.rst
View File

@@ -15,7 +15,7 @@ give up. Report as much as you have found to the relevant maintainer. See
MAINTAINERS for who that is for the subsystem you have worked on.
Before you submit a bug report read
:ref:`Documentation/admin-guide/reporting-bugs.rst <reportingbugs>`.
'Documentation/admin-guide/reporting-issues.rst'.
Devices not appearing
=====================

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

@@ -263,7 +263,7 @@ Please notice that it will point to:
- The last developers that touched the source code (if this is done inside
a git tree). On the above example, Tejun and Bhaktipriya (in this
specific case, none really envolved on the development of this file);
specific case, none really involved on the development of this file);
- The driver maintainer (Hans Verkuil);
- The subsystem maintainer (Mauro Carvalho Chehab);
- The driver and/or subsystem mailing list (linux-media@vger.kernel.org);

2
Documentation/admin-guide/cifs/introduction.rst
View File

@@ -9,7 +9,7 @@ Introduction
PC operating systems. New and improved versions of CIFS are now
called SMB2 and SMB3. Use of SMB3 (and later, including SMB3.1.1)
is strongly preferred over using older dialects like CIFS due to
security reaasons. All modern dialects, including the most recent,
security reasons. All modern dialects, including the most recent,
SMB3.1.1 are supported by the CIFS VFS module. The SMB3 protocol
is implemented and supported by all major file servers
such as all modern versions of Windows (including Windows 2016

6
Documentation/admin-guide/cifs/usage.rst
View File

@@ -115,7 +115,7 @@ later source tree in docs/manpages/mount.cifs.8
Allowing User Unmounts
======================
To permit users to ummount directories that they have user mounted (see above),
To permit users to unmount directories that they have user mounted (see above),
the utility umount.cifs may be used. It may be invoked directly, or if
umount.cifs is placed in /sbin, umount can invoke the cifs umount helper
(at least for most versions of the umount utility) for umount of cifs
@@ -197,7 +197,7 @@ that is ignored by local server applications and non-cifs clients and that will
not be traversed by the Samba server). This is opaque to the Linux client
application using the cifs vfs. Absolute symlinks will work to Samba 3.0.5 or
later, but only for remote clients using the CIFS Unix extensions, and will
be invisbile to Windows clients and typically will not affect local
be invisible to Windows clients and typically will not affect local
applications running on the same server as Samba.
Use instructions
@@ -267,7 +267,7 @@ would be forbidden for Windows/CIFS semantics) as long as the server is
configured for Unix Extensions (and the client has not disabled
/proc/fs/cifs/LinuxExtensionsEnabled). In addition the mount option
``mapposix`` can be used on CIFS (vers=1.0) to force the mapping of
illegal Windows/NTFS/SMB characters to a remap range (this mount parm
illegal Windows/NTFS/SMB characters to a remap range (this mount parameter
is the default for SMB3). This remap (``mapposix``) range is also
compatible with Mac (and "Services for Mac" on some older Windows).

4
Documentation/admin-guide/device-mapper/dm-crypt.rst
View File

@@ -46,7 +46,7 @@ Parameters::
capi:authenc(hmac(sha256),xts(aes))-random
capi:rfc7539(chacha20,poly1305)-random
The /proc/crypto contains a list of curently loaded crypto modes.
The /proc/crypto contains a list of currently loaded crypto modes.
<key>
Key used for encryption. It is encoded either as a hexadecimal number
@@ -92,7 +92,7 @@ Parameters::
<#opt_params>
Number of optional parameters. If there are no optional parameters,
the optional paramaters section can be skipped or #opt_params can be zero.
the optional parameters section can be skipped or #opt_params can be zero.
Otherwise #opt_params is the number of following arguments.
Example of optional parameters section:

4
Documentation/admin-guide/device-mapper/dm-integrity.rst
View File

@@ -117,7 +117,7 @@ journal_watermark:number
commit_time:number
Commit time in milliseconds. When this time passes, the journal is
written. The journal is also written immediatelly if the FLUSH
written. The journal is also written immediately if the FLUSH
request is received.
internal_hash:algorithm(:key) (the key is optional)
@@ -147,7 +147,7 @@ journal_crypt:algorithm(:key) (the key is optional)
"salsa20" or "ctr(aes)").
The journal contains history of last writes to the block device,
an attacker reading the journal could see the last sector nubmers
an attacker reading the journal could see the last sector numbers
that were written. From the sector numbers, the attacker can infer
the size of files that were written. To protect against this
situation, you can encrypt the journal.

2
Documentation/admin-guide/device-mapper/dm-raid.rst
View File

@@ -418,6 +418,6 @@ Version History
specific devices are requested via rebuild. Fix RAID leg
rebuild errors.
1.15.0 Fix size extensions not being synchronized in case of new MD bitmap
pages allocated; also fix those not occuring after previous reductions
pages allocated; also fix those not occurring after previous reductions
1.15.1 Fix argument count and arguments for rebuild/write_mostly/journal_(dev|mode)
on the status line.

6
Documentation/admin-guide/device-mapper/dm-zoned.rst
View File

@@ -24,7 +24,7 @@ The dm-zoned implementation is simple and minimizes system overhead (CPU
and memory usage as well as storage capacity loss). For a 10TB
host-managed disk with 256 MB zones, dm-zoned memory usage per disk
instance is at most 4.5 MB and as little as 5 zones will be used
internally for storing metadata and performaing reclaim operations.
internally for storing metadata and performing reclaim operations.
dm-zoned target devices are formatted and checked using the dmzadm
utility available at:
@@ -102,7 +102,7 @@ the buffer zone assigned. If the accessed chunk has no mapping, or the
accessed blocks are invalid, the read buffer is zeroed and the read
operation terminated.
After some time, the limited number of convnetional zones available may
After some time, the limited number of conventional zones available may
be exhausted (all used to map chunks or buffer sequential zones) and
unaligned writes to unbuffered chunks become impossible. To avoid this
situation, a reclaim process regularly scans used conventional zones and
@@ -158,7 +158,7 @@ Ex::
dmzadm --format /dev/sdxx /dev/sdyy
Fomatted device(s) can be started with the dmzadm utility, too.:
Formatted device(s) can be started with the dmzadm utility, too.:
Ex::

2
Documentation/admin-guide/device-mapper/verity.rst
View File

@@ -69,7 +69,7 @@ Construction Parameters
<#opt_params>
Number of optional parameters. If there are no optional parameters,
the optional paramaters section can be skipped or #opt_params can be zero.
the optional parameters section can be skipped or #opt_params can be zero.
Otherwise #opt_params is the number of following arguments.
Example of optional parameters section:

4
Documentation/admin-guide/device-mapper/writecache.rst
View File

@@ -37,10 +37,10 @@ Constructor parameters:
autocommit_blocks n (default: 64 for pmem, 65536 for ssd)
when the application writes this amount of blocks without
issuing the FLUSH request, the blocks are automatically
commited
committed
autocommit_time ms (default: 1000)
autocommit time in milliseconds. The data is automatically
commited if this time passes and no FLUSH request is
committed if this time passes and no FLUSH request is
received
fua (by default on)
applicable only to persistent memory - use the FUA flag

3
Documentation/admin-guide/features.rst Normal file
View File

@@ -0,0 +1,3 @@
.. SPDX-License-Identifier: GPL-2.0
.. kernel-feat:: $srctree/Documentation/features

2
Documentation/admin-guide/hw-vuln/tsx_async_abort.rst
View File

@@ -60,7 +60,7 @@ Hyper-Thread attacks are possible.
The victim of a malicious actor does not need to make use of TSX. Only the
attacker needs to begin a TSX transaction and raise an asynchronous abort
which in turn potenitally leaks data stored in the buffers.
which in turn potentially leaks data stored in the buffers.
More detailed technical information is available in the TAA specific x86
architecture section: :ref:`Documentation/x86/tsx_async_abort.rst <tsx_async_abort>`.

5
Documentation/admin-guide/index.rst
View File

@@ -19,6 +19,7 @@ etc.
sysctl/index
abi
features
This section describes CPU vulnerabilities and their mitigations.
@@ -33,7 +34,8 @@ problems and bugs in particular.
.. toctree::
:maxdepth: 1
reporting-bugs
reporting-issues
Reporting bugs (obsolete) <reporting-bugs>
security-bugs
bug-hunting
bug-bisect
@@ -111,6 +113,7 @@ configure specific aspects of kernel behavior to your liking.
rtc
serial-console
svga
syscall-user-dispatch
sysrq
thunderbolt
ufs

1
Documentation/admin-guide/kernel-parameters.rst
View File

@@ -172,6 +172,7 @@ parameter is applicable::
X86 Either 32-bit or 64-bit x86 (same as X86-32+X86-64)
X86_UV SGI UV support is enabled.
XEN Xen support is enabled
XTENSA xtensa architecture is enabled.
In addition, the following text indicates that the option::

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

@@ -2713,7 +2713,7 @@
option description.
memmap=nn[KMG]@ss[KMG]
[KNL] Force usage of a specific region of memory.
[KNL, X86, MIPS, XTENSA] Force usage of a specific region of memory.
Region of memory to be used is from ss to ss+nn.
If @ss[KMG] is omitted, it is equivalent to mem=nn[KMG],
which limits max address to nn[KMG].

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

@@ -221,7 +221,7 @@ All md devices contain:
layout
The ``layout`` for the array for the particular level. This is
simply a number that is interpretted differently by different
simply a number that is interpreted differently by different
levels. It can be written while assembling an array.
array_size

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

@@ -77,7 +77,7 @@ the Subsystem ID in the second line, looks like this:
only bt878-based cards can have a subsystem ID (which does not mean
that every card really has one). bt848 cards can't have a Subsystem
ID and therefore can't be autodetected. There is a list with the ID's
at :doc:`bttv-cardlist` (in case you are intrested or want to mail
at :doc:`bttv-cardlist` (in case you are interested or want to mail
patches with updates).

2
Documentation/admin-guide/media/dvb_references.rst
View File

@@ -10,7 +10,7 @@ The DVB mailing list linux-dvb is hosted at vger. Please see
http://vger.kernel.org/vger-lists.html#linux-media for details.
There are also some other old lists hosted at:
https://linuxtv.org/lists.php. If you're insterested on that for historic
https://linuxtv.org/lists.php. If you're interested on that for historic
reasons, please check the archive at https://linuxtv.org/pipermail/linux-dvb/.
The media subsystem Wiki is hosted at https://linuxtv.org/wiki/.

4
Documentation/admin-guide/media/frontend-cardlist.rst
View File

@@ -68,7 +68,7 @@ cx24116 Conexant CX24116 based
cx24117 Conexant CX24117 based
cx24120 Conexant CX24120 based
cx24123 Conexant CX24123 based
ds3000 Montage Tehnology DS3000 based
ds3000 Montage Technology DS3000 based
mb86a16 Fujitsu MB86A16 based
mt312 Zarlink VP310/MT312/ZL10313 based
s5h1420 Samsung S5H1420 based
@@ -83,7 +83,7 @@ tda10086 Philips TDA10086 based
tda8083 Philips TDA8083 based
tda8261 Philips TDA8261 based
tda826x Philips TDA826X silicon tuner
ts2020 Montage Tehnology TS2020 based tuners
ts2020 Montage Technology TS2020 based tuners
tua6100 Infineon TUA6100 PLL
cx24113 Conexant CX24113/CX24128 tuner for DVB-S/DSS
itd1000 Integrant ITD1000 Zero IF tuner for DVB-S/DSS

2
Documentation/admin-guide/media/gspca-cardlist.rst
View File

@@ -305,7 +305,7 @@ pac7302 093a:2625 Genius iSlim 310
pac7302 093a:2626 Labtec 2200
pac7302 093a:2627 Genius FaceCam 300
pac7302 093a:2628 Genius iLook 300
pac7302 093a:2629 Genious iSlim 300
pac7302 093a:2629 Genius iSlim 300
pac7302 093a:262a Webcam 300k
pac7302 093a:262c Philips SPC 230 NC
jl2005bcd 0979:0227 Various brands, 19 known cameras supported

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

@@ -86,7 +86,7 @@ raw Bayer format that is specific to IPU3.
Let us take the example of ov5670 sensor connected to CSI2 port 0, for a
2592x1944 image capture.
Using the media contorller APIs, the ov5670 sensor is configured to send
Using the media controller APIs, the ov5670 sensor is configured to send
frames in packed raw Bayer format to IPU3 CSI2 receiver.
.. code-block:: none
@@ -313,8 +313,8 @@ configuration steps of 0.03125 (1/32).
**Geometric Distortion Correction**
Geometric Distortion Correction is used to performe correction of distortions
and image filtering. It needs some extra filter and envelop padding pixels to
Geometric Distortion Correction is used to perform correction of distortions
and image filtering. It needs some extra filter and envelope padding pixels to
work, so the input resolution of GDC should be larger than the output
resolution.

2
Documentation/admin-guide/media/remote-controller.rst
View File

@@ -68,7 +68,7 @@ Using without lircd
Xorg recognizes several IR keycodes that have its numerical value lower
than 247. With the advent of Wayland, the input driver got updated too,
and should now accept all keycodes. Yet, you may want to just reasign
and should now accept all keycodes. Yet, you may want to just reassign
the keycodes to something that your favorite media application likes.
This can be done by setting

4
Documentation/admin-guide/mm/index.rst
View File

@@ -3,9 +3,9 @@ Memory Management
=================
Linux memory management subsystem is responsible, as the name implies,
for managing the memory in the system. This includes implemnetation of
for managing the memory in the system. This includes implementation of
virtual memory and demand paging, memory allocation both for kernel
internal structures and user space programms, mapping of files into
internal structures and user space programs, mapping of files into
processes address space and many other cool things.
Linux memory management is a complex system with many configurable

2
Documentation/admin-guide/mm/numaperf.rst
View File

@@ -74,7 +74,7 @@ memory node's access class 0 initiators as follows::
/sys/devices/system/node/nodeY/access0/initiators/
These attributes apply only when accessed from nodes that have the
are linked under the this access's inititiators.
are linked under the this access's initiators.
The performance characteristics the kernel provides for the local initiators
are exported are as follows::

2
Documentation/admin-guide/mm/userfaultfd.rst
View File

@@ -114,7 +114,7 @@ Notes:
you must provide some kind of page in your thread after reading from
the uffd. You must provide either ``UFFDIO_COPY`` or ``UFFDIO_ZEROPAGE``.
The normal behavior of the OS automatically providing a zero page on
an annonymous mmaping is not in place.
an anonymous mmaping is not in place.
- None of the page-delivering ioctls default to the range that you
registered with. You must fill in all fields for the appropriate

2
Documentation/admin-guide/module-signing.rst
View File

@@ -106,7 +106,7 @@ This has a number of options available:
certificate and a private key.
If the PEM file containing the private key is encrypted, or if the
PKCS#11 token requries a PIN, this can be provided at build time by
PKCS#11 token requires a PIN, this can be provided at build time by
means of the ``KBUILD_SIGN_PIN`` variable.

2
Documentation/admin-guide/perf/imx-ddr.rst
View File

@@ -4,7 +4,7 @@ Freescale i.MX8 DDR Performance Monitoring Unit (PMU)
There are no performance counters inside the DRAM controller, so performance
signals are brought out to the edge of the controller where a set of 4 x 32 bit
counters is implemented. This is controlled by the CSV modes programed in counter
counters is implemented. This is controlled by the CSV modes programmed in counter
control register which causes a large number of PERF signals to be generated.
Selection of the value for each counter is done via the config registers. There

4
Documentation/admin-guide/pm/intel-speed-select.rst
View File

@@ -57,7 +57,7 @@ To get help on a command, another level of help is provided. For example for the
Summary of platform capability
------------------------------
To check the current platform and driver capaibilities, execute::
To check the current platform and driver capabilities, execute::
#intel-speed-select --info
@@ -658,7 +658,7 @@ If -a option is not used, then the following steps are required before enabling
Intel(R) SST-BF:
- Discover Intel(R) SST-BF and note low and high priority base frequency
- Note the high prioity CPU list
- Note the high priority CPU list
- Enable CLOS using core-power feature set
- Configure CLOS parameters. Use CLOS.min to set to minimum performance
- Subscribe desired CPUs to CLOS groups

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

@@ -56,7 +56,7 @@ Operation Modes
``intel_pstate`` can operate in two different modes, active or passive. In the
active mode, it uses its own internal performance scaling governor algorithm or
allows the hardware to do preformance scaling by itself, while in the passive
allows the hardware to do performance scaling by itself, while in the passive
mode it responds to requests made by a generic ``CPUFreq`` governor implementing
a certain performance scaling algorithm. Which of them will be in effect
depends on what kernel command line options are used and on the capabilities of
@@ -380,13 +380,13 @@ argument is passed to the kernel in the command line.
``no_turbo``
If set (equal to 1), the driver is not allowed to set any turbo P-states
(see `Turbo P-states Support`_). If unset (equalt to 0, which is the
(see `Turbo P-states Support`_). If unset (equal to 0, which is the
default), turbo P-states can be set by the driver.
[Note that ``intel_pstate`` does not support the general ``boost``
attribute (supported by some other scaling drivers) which is replaced
by this one.]
This attrubute does not affect the maximum supported frequency value
This attribute does not affect the maximum supported frequency value
supplied to the ``CPUFreq`` core and exposed via the policy interface,
but it affects the maximum possible value of per-policy P-state limits
(see `Interpretation of Policy Attributes`_ below for details).

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

@@ -22,7 +22,7 @@ and type of the memory area are set using three variables:
* ``mem_address`` for the start
* ``mem_size`` for the size. The memory size will be rounded down to a
power of two.
* ``mem_type`` to specifiy if the memory type (default is pgprot_writecombine).
* ``mem_type`` to specify if the memory type (default is pgprot_writecombine).
Typically the default value of ``mem_type=0`` should be used as that sets the pstore
mapping to pgprot_writecombine. Setting ``mem_type=1`` attempts to use

5
Documentation/admin-guide/reporting-bugs.rst
View File

@@ -1,5 +1,10 @@
.. _reportingbugs:
.. note::
This document is obsolete, and will be replaced by
'Documentation/admin-guide/reporting-issues.rst' in the near future.
Reporting bugs
++++++++++++++

1631
Documentation/admin-guide/reporting-issues.rst Normal file
View File

File diff suppressed because it is too large Load Diff

2
Documentation/admin-guide/security-bugs.rst
View File

@@ -21,7 +21,7 @@ understand and fix the security vulnerability.
As it is with any bug, the more information provided the easier it
will be to diagnose and fix. Please review the procedure outlined in
:doc:`reporting-bugs` if you are unclear about what
'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
information is helpful. Any exploit code is very helpful and will not
be released without consent from the reporter unless it has already been
made public.

90
Documentation/admin-guide/syscall-user-dispatch.rst Normal file
View File

@@ -0,0 +1,90 @@
.. SPDX-License-Identifier: GPL-2.0
=====================
Syscall User Dispatch
=====================
Background
----------
Compatibility layers like Wine need a way to efficiently emulate system
calls of only a part of their process - the part that has the
incompatible code - while being able to execute native syscalls without
a high performance penalty on the native part of the process. Seccomp
falls short on this task, since it has limited support to efficiently
filter syscalls based on memory regions, and it doesn't support removing
filters. Therefore a new mechanism is necessary.
Syscall User Dispatch brings the filtering of the syscall dispatcher
address back to userspace. The application is in control of a flip
switch, indicating the current personality of the process. A
multiple-personality application can then flip the switch without
invoking the kernel, when crossing the compatibility layer API
boundaries, to enable/disable the syscall redirection and execute
syscalls directly (disabled) or send them to be emulated in userspace
through a SIGSYS.
The goal of this design is to provide very quick compatibility layer
boundary crosses, which is achieved by not executing a syscall to change
personality every time the compatibility layer executes. Instead, a
userspace memory region exposed to the kernel indicates the current
personality, and the application simply modifies that variable to
configure the mechanism.
There is a relatively high cost associated with handling signals on most
architectures, like x86, but at least for Wine, syscalls issued by
native Windows code are currently not known to be a performance problem,
since they are quite rare, at least for modern gaming applications.
Since this mechanism is designed to capture syscalls issued by
non-native applications, it must function on syscalls whose invocation
ABI is completely unexpected to Linux. Syscall User Dispatch, therefore
doesn't rely on any of the syscall ABI to make the filtering. It uses
only the syscall dispatcher address and the userspace key.
As the ABI of these intercepted syscalls is unknown to Linux, these
syscalls are not instrumentable via ptrace or the syscall tracepoints.
Interface
---------
A thread can setup this mechanism on supported kernels by executing the
following prctl:
prctl(PR_SET_SYSCALL_USER_DISPATCH, <op>, <offset>, <length>, [selector])
<op> is either PR_SYS_DISPATCH_ON or PR_SYS_DISPATCH_OFF, to enable and
disable the mechanism globally for that thread. When
PR_SYS_DISPATCH_OFF is used, the other fields must be zero.
[<offset>, <offset>+<length>) delimit a memory region interval
from which syscalls are always executed directly, regardless of the
userspace selector. This provides a fast path for the C library, which
includes the most common syscall dispatchers in the native code
applications, and also provides a way for the signal handler to return
without triggering a nested SIGSYS on (rt\_)sigreturn. Users of this
interface should make sure that at least the signal trampoline code is
included in this region. In addition, for syscalls that implement the
trampoline code on the vDSO, that trampoline is never intercepted.
[selector] is a pointer to a char-sized region in the process memory
region, that provides a quick way to enable disable syscall redirection
thread-wide, without the need to invoke the kernel directly. selector
can be set to PR_SYS_DISPATCH_ON or PR_SYS_DISPATCH_OFF. Any other
value should terminate the program with a SIGSYS.
Security Notes
--------------
Syscall User Dispatch provides functionality for compatibility layers to
quickly capture system calls issued by a non-native part of the
application, while not impacting the Linux native regions of the
process. It is not a mechanism for sandboxing system calls, and it
should not be seen as a security mechanism, since it is trivial for a
malicious application to subvert the mechanism by jumping to an allowed
dispatcher region prior to executing the syscall, or to discover the
address and modify the selector value. If the use case requires any
kind of security sandboxing, Seccomp should be used instead.
Any fork or exec of the existing process resets the mechanism to
PR_SYS_DISPATCH_OFF.

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

@@ -28,7 +28,7 @@ vsyscall32 (x86)
Determines whether the kernels maps a vDSO page into 32-bit processes;
can be set to 1 to enable, or 0 to disable. Defaults to enabled if
``CONFIG_COMPAT_VDSO`` is set, disabled otherwide.
``CONFIG_COMPAT_VDSO`` is set, disabled otherwise.
This controls the same setting as the ``vdso32`` kernel boot
parameter.

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

@@ -14,7 +14,7 @@ For general info and legal blurb, please look in :doc:`index`.
------------------------------------------------------------------------------
This file contains documentation for the sysctl files in
``/proc/sys/kernel/`` and is valid for Linux kernel version 2.2.
``/proc/sys/kernel/``.
The files in this directory can be used to tune and monitor
miscellaneous and general things in the operation of the Linux
@@ -879,7 +879,7 @@ The default value is 127.
perf_event_mlock_kb
===================
Control size of per-cpu ring buffer not counted agains mlock limit.
Control size of per-cpu ring buffer not counted against mlock limit.
The default value is 512 + 1 page
@@ -1095,8 +1095,8 @@ Enables/disables scheduler statistics. Enabling this feature
incurs a small amount of overhead in the scheduler but is
useful for debugging and performance tuning.
sched_util_clamp_min:
=====================
sched_util_clamp_min
====================
Max allowed *minimum* utilization.
@@ -1106,8 +1106,8 @@ It means that any requested uclamp.min value cannot be greater than
sched_util_clamp_min, i.e., it is restricted to the range
[0:sched_util_clamp_min].
sched_util_clamp_max:
=====================
sched_util_clamp_max
====================
Max allowed *maximum* utilization.
@@ -1117,8 +1117,8 @@ It means that any requested uclamp.max value cannot be greater than
sched_util_clamp_max, i.e., it is restricted to the range
[0:sched_util_clamp_max].
sched_util_clamp_min_rt_default:
================================
sched_util_clamp_min_rt_default
===============================
By default Linux is tuned for performance. Which means that RT tasks always run
at the highest frequency and most capable (highest capacity) CPU (in
@@ -1336,7 +1336,7 @@ ORed together. The letters are seen in "Tainted" line of Oops reports.
====== ===== ==============================================================
1 `(P)` proprietary module was loaded
2 `(F)` module was force loaded
4 `(S)` SMP kernel oops on an officially SMP incapable processor
4 `(S)` kernel running on an out of specification system
8 `(R)` module was force unloaded
16 `(M)` processor reported a Machine Check Exception (MCE)
32 `(B)` bad page referenced or some unexpected page flags

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

@@ -147,7 +147,7 @@ This should be used on systems where stalls for minor page faults are an
acceptable trade for large contiguous free memory. Set to 0 to prevent
compaction from moving pages that are unevictable. Default value is 1.
On CONFIG_PREEMPT_RT the default value is 0 in order to avoid a page fault, due
to compaction, which would block the task from becomming active until the fault
to compaction, which would block the task from becoming active until the fault
is resolved.

23
Documentation/admin-guide/tainted-kernels.rst
View File

@@ -84,7 +84,7 @@ Bit Log Number Reason that got the kernel tainted
=== === ====== ========================================================
0 G/P 1 proprietary module was loaded
1 _/F 2 module was force loaded
2 _/S 4 SMP kernel oops on an officially SMP incapable processor
2 _/S 4 kernel running on an out of specification system
3 _/R 8 module was force unloaded
4 _/M 16 processor reported a Machine Check Exception (MCE)
5 _/B 32 bad page referenced or some unexpected page flags
@@ -116,10 +116,23 @@ More detailed explanation for tainting
1) ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all
modules were loaded normally.
2) ``S`` if the oops occurred on an SMP kernel running on hardware that
hasn't been certified as safe to run multiprocessor.
Currently this occurs only on various Athlons that are not
SMP capable.
2) ``S`` if the kernel is running on a processor or system that is out of
specification: hardware has been put into an unsupported configuration,
therefore proper execution cannot be guaranteed.
Kernel will be tainted if, for example:
- on x86: PAE is forced through forcepae on intel CPUs (such as Pentium M)
which do not report PAE but may have a functional implementation, an SMP
kernel is running on non officially capable SMP Athlon CPUs, MSRs are
being poked at from userspace.
- on arm: kernel running on certain CPUs (such as Keystone 2) without
having certain kernel features enabled.
- on arm64: there are mismatched hardware features between CPUs, the
bootloader has booted CPUs in different modes.
- certain drivers are being used on non supported architectures (such as
scsi/snic on something else than x86_64, scsi/ips on non
x86/x86_64/itanium, have broken firmware settings for the
irqchip/irq-gic on arm64 ...).
3) ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all
modules were unloaded normally.

3
Documentation/arm/features.rst Normal file
View File

@@ -0,0 +1,3 @@
.. SPDX-License-Identifier: GPL-2.0
.. kernel-feat:: $srctree/Documentation/features arm

2
Documentation/arm/index.rst
View File

@@ -23,6 +23,8 @@ ARM Architecture
vlocks
porting
features
SoC-specific documents
======================

10
Documentation/arm/sunxi.rst
View File

@@ -158,3 +158,13 @@ SunXi family
* User Manual
https://linux-sunxi.org/images/4/46/Allwinner_H6_V200_User_Manual_V1.1.pdf
- Allwinner H616
* Datasheet
https://linux-sunxi.org/images/b/b9/H616_Datasheet_V1.0_cleaned.pdf
* User Manual
https://linux-sunxi.org/images/2/24/H616_User_Manual_V1.0_cleaned.pdf

2
Documentation/arm64/elf_hwcaps.rst
View File

@@ -1,3 +1,5 @@
.. _elf_hwcaps_index:
================
ARM64 ELF hwcaps
================

3
Documentation/arm64/features.rst Normal file
View File

@@ -0,0 +1,3 @@
.. SPDX-License-Identifier: GPL-2.0
.. kernel-feat:: $srctree/Documentation/features arm64

2
Documentation/arm64/index.rst
View File

@@ -24,6 +24,8 @@ ARM64 Architecture
tagged-address-abi
tagged-pointers
features
.. only:: subproject and html
Indices

2
Documentation/arm64/perf.rst
View File

@@ -1,5 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
.. _perf_index:
=====================
Perf Event Attributes
=====================

5
Documentation/conf.py
View File

@@ -39,7 +39,7 @@ needs_sphinx = '1.3'
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include',
'kfigure', 'sphinx.ext.ifconfig', 'automarkup',
'maintainers_include', 'sphinx.ext.autosectionlabel',
'kernel_abi']
'kernel_abi', 'kernel_feat']
#
# cdomain is badly broken in Sphinx 3+. Leaving it out generates *most*
@@ -112,6 +112,9 @@ if major >= 3:
else:
extensions.append('cdomain')
if major == 1 and minor < 7:
sys.stderr.write('WARNING: Sphinx 1.7 or greater will be required as of '
'the 5.12 release\n')
# Ensure that autosectionlabel will produce unique names
autosectionlabel_prefix_document = True

664
Documentation/core-api/atomic_ops.rst
View File

@@ -1,664 +0,0 @@
=======================================================
Semantics and Behavior of Atomic and Bitmask Operations
=======================================================
:Author: David S. Miller
This document is intended to serve as a guide to Linux port
maintainers on how to implement atomic counter, bitops, and spinlock
interfaces properly.
Atomic Type And Operations
==========================
The atomic_t type should be defined as a signed integer and
the atomic_long_t type as a signed long integer. Also, they should
be made opaque such that any kind of cast to a normal C integer type
will fail. Something like the following should suffice::
typedef struct { int counter; } atomic_t;
typedef struct { long counter; } atomic_long_t;
Historically, counter has been declared volatile. This is now discouraged.
See :ref:`Documentation/process/volatile-considered-harmful.rst
<volatile_considered_harmful>` for the complete rationale.
local_t is very similar to atomic_t. If the counter is per CPU and only
updated by one CPU, local_t is probably more appropriate. Please see
:ref:`Documentation/core-api/local_ops.rst <local_ops>` for the semantics of
local_t.
The first operations to implement for atomic_t's are the initializers and
plain writes. ::
#define ATOMIC_INIT(i) { (i) }
#define atomic_set(v, i) ((v)->counter = (i))
The first macro is used in definitions, such as::
static atomic_t my_counter = ATOMIC_INIT(1);
The initializer is atomic in that the return values of the atomic operations
are guaranteed to be correct reflecting the initialized value if the
initializer is used before runtime. If the initializer is used at runtime, a
proper implicit or explicit read memory barrier is needed before reading the
value with atomic_read from another thread.
As with all of the ``atomic_`` interfaces, replace the leading ``atomic_``
with ``atomic_long_`` to operate on atomic_long_t.
The second interface can be used at runtime, as in::
struct foo { atomic_t counter; };
...
struct foo *k;
k = kmalloc(sizeof(*k), GFP_KERNEL);
if (!k)
return -ENOMEM;
atomic_set(&k->counter, 0);
The setting is atomic in that the return values of the atomic operations by
all threads are guaranteed to be correct reflecting either the value that has
been set with this operation or set with another operation. A proper implicit
or explicit memory barrier is needed before the value set with the operation
is guaranteed to be readable with atomic_read from another thread.
Next, we have::
#define atomic_read(v) ((v)->counter)
which simply reads the counter value currently visible to the calling thread.
The read is atomic in that the return value is guaranteed to be one of the
values initialized or modified with the interface operations if a proper
implicit or explicit memory barrier is used after possible runtime
initialization by any other thread and the value is modified only with the
interface operations. atomic_read does not guarantee that the runtime
initialization by any other thread is visible yet, so the user of the
interface must take care of that with a proper implicit or explicit memory
barrier.
.. warning::
``atomic_read()`` and ``atomic_set()`` DO NOT IMPLY BARRIERS!
Some architectures may choose to use the volatile keyword, barriers, or
inline assembly to guarantee some degree of immediacy for atomic_read()
and atomic_set(). This is not uniformly guaranteed, and may change in
the future, so all users of atomic_t should treat atomic_read() and
atomic_set() as simple C statements that may be reordered or optimized
away entirely by the compiler or processor, and explicitly invoke the
appropriate compiler and/or memory barrier for each use case. Failure
to do so will result in code that may suddenly break when used with
different architectures or compiler optimizations, or even changes in
unrelated code which changes how the compiler optimizes the section
accessing atomic_t variables.
Properly aligned pointers, longs, ints, and chars (and unsigned
equivalents) may be atomically loaded from and stored to in the same
sense as described for atomic_read() and atomic_set(). The READ_ONCE()
and WRITE_ONCE() macros should be used to prevent the compiler from using
optimizations that might otherwise optimize accesses out of existence on
the one hand, or that might create unsolicited accesses on the other.
For example consider the following code::
while (a > 0)
do_something();
If the compiler can prove that do_something() does not store to the
variable a, then the compiler is within its rights transforming this to
the following::
if (a > 0)
for (;;)
do_something();
If you don't want the compiler to do this (and you probably don't), then
you should use something like the following::
while (READ_ONCE(a) > 0)
do_something();
Alternatively, you could place a barrier() call in the loop.
For another example, consider the following code::
tmp_a = a;
do_something_with(tmp_a);
do_something_else_with(tmp_a);
If the compiler can prove that do_something_with() does not store to the
variable a, then the compiler is within its rights to manufacture an
additional load as follows::
tmp_a = a;
do_something_with(tmp_a);
tmp_a = a;
do_something_else_with(tmp_a);
This could fatally confuse your code if it expected the same value
to be passed to do_something_with() and do_something_else_with().
The compiler would be likely to manufacture this additional load if
do_something_with() was an inline function that made very heavy use
of registers: reloading from variable a could save a flush to the
stack and later reload. To prevent the compiler from attacking your
code in this manner, write the following::
tmp_a = READ_ONCE(a);
do_something_with(tmp_a);
do_something_else_with(tmp_a);
For a final example, consider the following code, assuming that the
variable a is set at boot time before the second CPU is brought online
and never changed later, so that memory barriers are not needed::
if (a)
b = 9;
else
b = 42;
The compiler is within its rights to manufacture an additional store
by transforming the above code into the following::
b = 42;
if (a)
b = 9;
This could come as a fatal surprise to other code running concurrently
that expected b to never have the value 42 if a was zero. To prevent
the compiler from doing this, write something like::
if (a)
WRITE_ONCE(b, 9);
else
WRITE_ONCE(b, 42);
Don't even -think- about doing this without proper use of memory barriers,
locks, or atomic operations if variable a can change at runtime!
.. warning::
``READ_ONCE()`` OR ``WRITE_ONCE()`` DO NOT IMPLY A BARRIER!
Now, we move onto the atomic operation interfaces typically implemented with
the help of assembly code. ::
void atomic_add(int i, atomic_t *v);
void atomic_sub(int i, atomic_t *v);
void atomic_inc(atomic_t *v);
void atomic_dec(atomic_t *v);
These four routines add and subtract integral values to/from the given
atomic_t value. The first two routines pass explicit integers by
which to make the adjustment, whereas the latter two use an implicit
adjustment value of "1".
One very important aspect of these two routines is that they DO NOT
require any explicit memory barriers. They need only perform the
atomic_t counter update in an SMP safe manner.
Next, we have::
int atomic_inc_return(atomic_t *v);
int atomic_dec_return(atomic_t *v);
These routines add 1 and subtract 1, respectively, from the given
atomic_t and return the new counter value after the operation is
performed.
Unlike the above routines, it is required that these primitives
include explicit memory barriers that are performed before and after
the operation. It must be done such that all memory operations before
and after the atomic operation calls are strongly ordered with respect
to the atomic operation itself.
For example, it should behave as if a smp_mb() call existed both
before and after the atomic operation.
If the atomic instructions used in an implementation provide explicit
memory barrier semantics which satisfy the above requirements, that is
fine as well.
Let's move on::
int atomic_add_return(int i, atomic_t *v);
int atomic_sub_return(int i, atomic_t *v);
These behave just like atomic_{inc,dec}_return() except that an
explicit counter adjustment is given instead of the implicit "1".
This means that like atomic_{inc,dec}_return(), the memory barrier
semantics are required.
Next::
int atomic_inc_and_test(atomic_t *v);
int atomic_dec_and_test(atomic_t *v);
These two routines increment and decrement by 1, respectively, the
given atomic counter. They return a boolean indicating whether the
resulting counter value was zero or not.
Again, these primitives provide explicit memory barrier semantics around
the atomic operation::
int atomic_sub_and_test(int i, atomic_t *v);
This is identical to atomic_dec_and_test() except that an explicit
decrement is given instead of the implicit "1". This primitive must
provide explicit memory barrier semantics around the operation::
int atomic_add_negative(int i, atomic_t *v);
The given increment is added to the given atomic counter value. A boolean
is return which indicates whether the resulting counter value is negative.
This primitive must provide explicit memory barrier semantics around
the operation.
Then::
int atomic_xchg(atomic_t *v, int new);
This performs an atomic exchange operation on the atomic variable v, setting
the given new value. It returns the old value that the atomic variable v had
just before the operation.
atomic_xchg must provide explicit memory barriers around the operation. ::
int atomic_cmpxchg(atomic_t *v, int old, int new);
This performs an atomic compare exchange operation on the atomic value v,
with the given old and new values. Like all atomic_xxx operations,
atomic_cmpxchg will only satisfy its atomicity semantics as long as all
other accesses of \*v are performed through atomic_xxx operations.
atomic_cmpxchg must provide explicit memory barriers around the operation,
although if the comparison fails then no memory ordering guarantees are
required.
The semantics for atomic_cmpxchg are the same as those defined for 'cas'
below.
Finally::
int atomic_add_unless(atomic_t *v, int a, int u);
If the atomic value v is not equal to u, this function adds a to v, and
returns non zero. If v is equal to u then it returns zero. This is done as
an atomic operation.
atomic_add_unless must provide explicit memory barriers around the
operation unless it fails (returns 0).
atomic_inc_not_zero, equivalent to atomic_add_unless(v, 1, 0)
If a caller requires memory barrier semantics around an atomic_t
operation which does not return a value, a set of interfaces are
defined which accomplish this::
void smp_mb__before_atomic(void);
void smp_mb__after_atomic(void);
Preceding a non-value-returning read-modify-write atomic operation with
smp_mb__before_atomic() and following it with smp_mb__after_atomic()
provides the same full ordering that is provided by value-returning
read-modify-write atomic operations.
For example, smp_mb__before_atomic() can be used like so::
obj->dead = 1;
smp_mb__before_atomic();
atomic_dec(&obj->ref_count);
It makes sure that all memory operations preceding the atomic_dec()
call are strongly ordered with respect to the atomic counter
operation. In the above example, it guarantees that the assignment of
"1" to obj->dead will be globally visible to other cpus before the
atomic counter decrement.
Without the explicit smp_mb__before_atomic() call, the
implementation could legally allow the atomic counter update visible
to other cpus before the "obj->dead = 1;" assignment.
A missing memory barrier in the cases where they are required by the
atomic_t implementation above can have disastrous results. Here is
an example, which follows a pattern occurring frequently in the Linux
kernel. It is the use of atomic counters to implement reference
counting, and it works such that once the counter falls to zero it can
be guaranteed that no other entity can be accessing the object::
static void obj_list_add(struct obj *obj, struct list_head *head)
{
obj->active = 1;
list_add(&obj->list, head);
}
static void obj_list_del(struct obj *obj)
{
list_del(&obj->list);
obj->active = 0;
}
static void obj_destroy(struct obj *obj)
{
BUG_ON(obj->active);
kfree(obj);
}
struct obj *obj_list_peek(struct list_head *head)
{
if (!list_empty(head)) {
struct obj *obj;
obj = list_entry(head->next, struct obj, list);
atomic_inc(&obj->refcnt);
return obj;
}
return NULL;
}
void obj_poke(void)
{
struct obj *obj;
spin_lock(&global_list_lock);
obj = obj_list_peek(&global_list);
spin_unlock(&global_list_lock);
if (obj) {
obj->ops->poke(obj);
if (atomic_dec_and_test(&obj->refcnt))
obj_destroy(obj);
}
}
void obj_timeout(struct obj *obj)
{
spin_lock(&global_list_lock);
obj_list_del(obj);
spin_unlock(&global_list_lock);
if (atomic_dec_and_test(&obj->refcnt))
obj_destroy(obj);
}
.. note::
This is a simplification of the ARP queue management in the generic
neighbour discover code of the networking. Olaf Kirch found a bug wrt.
memory barriers in kfree_skb() that exposed the atomic_t memory barrier
requirements quite clearly.
Given the above scheme, it must be the case that the obj->active
update done by the obj list deletion be visible to other processors
before the atomic counter decrement is performed.
Otherwise, the counter could fall to zero, yet obj->active would still
be set, thus triggering the assertion in obj_destroy(). The error
sequence looks like this::
cpu 0 cpu 1
obj_poke() obj_timeout()
obj = obj_list_peek();
... gains ref to obj, refcnt=2
obj_list_del(obj);
obj->active = 0 ...
... visibility delayed ...
atomic_dec_and_test()
... refcnt drops to 1 ...
atomic_dec_and_test()
... refcount drops to 0 ...
obj_destroy()
BUG() triggers since obj->active
still seen as one
obj->active update visibility occurs
With the memory barrier semantics required of the atomic_t operations
which return values, the above sequence of memory visibility can never
happen. Specifically, in the above case the atomic_dec_and_test()
counter decrement would not become globally visible until the
obj->active update does.
As a historical note, 32-bit Sparc used to only allow usage of
24-bits of its atomic_t type. This was because it used 8 bits
as a spinlock for SMP safety. Sparc32 lacked a "compare and swap"
type instruction. However, 32-bit Sparc has since been moved over
to a "hash table of spinlocks" scheme, that allows the full 32-bit
counter to be realized. Essentially, an array of spinlocks are
indexed into based upon the address of the atomic_t being operated
on, and that lock protects the atomic operation. Parisc uses the
same scheme.
Another note is that the atomic_t operations returning values are
extremely slow on an old 386.
Atomic Bitmask
==============
We will now cover the atomic bitmask operations. You will find that
their SMP and memory barrier semantics are similar in shape and scope
to the atomic_t ops above.
Native atomic bit operations are defined to operate on objects aligned
to the size of an "unsigned long" C data type, and are least of that
size. The endianness of the bits within each "unsigned long" are the
native endianness of the cpu. ::
void set_bit(unsigned long nr, volatile unsigned long *addr);
void clear_bit(unsigned long nr, volatile unsigned long *addr);
void change_bit(unsigned long nr, volatile unsigned long *addr);
These routines set, clear, and change, respectively, the bit number
indicated by "nr" on the bit mask pointed to by "ADDR".
They must execute atomically, yet there are no implicit memory barrier
semantics required of these interfaces. ::
int test_and_set_bit(unsigned long nr, volatile unsigned long *addr);
int test_and_clear_bit(unsigned long nr, volatile unsigned long *addr);
int test_and_change_bit(unsigned long nr, volatile unsigned long *addr);
Like the above, except that these routines return a boolean which
indicates whether the changed bit was set _BEFORE_ the atomic bit
operation.
.. warning::
It is incredibly important that the value be a boolean, ie. "0" or "1".
Do not try to be fancy and save a few instructions by declaring the
above to return "long" and just returning something like "old_val &
mask" because that will not work.
For one thing, this return value gets truncated to int in many code
paths using these interfaces, so on 64-bit if the bit is set in the
upper 32-bits then testers will never see that.
One great example of where this problem crops up are the thread_info
flag operations. Routines such as test_and_set_ti_thread_flag() chop
the return value into an int. There are other places where things
like this occur as well.
These routines, like the atomic_t counter operations returning values,
must provide explicit memory barrier semantics around their execution.
All memory operations before the atomic bit operation call must be
made visible globally before the atomic bit operation is made visible.
Likewise, the atomic bit operation must be visible globally before any
subsequent memory operation is made visible. For example::
obj->dead = 1;
if (test_and_set_bit(0, &obj->flags))
/* ... */;
obj->killed = 1;
The implementation of test_and_set_bit() must guarantee that
"obj->dead = 1;" is visible to cpus before the atomic memory operation
done by test_and_set_bit() becomes visible. Likewise, the atomic
memory operation done by test_and_set_bit() must become visible before
"obj->killed = 1;" is visible.
Finally there is the basic operation::
int test_bit(unsigned long nr, __const__ volatile unsigned long *addr);
Which returns a boolean indicating if bit "nr" is set in the bitmask
pointed to by "addr".
If explicit memory barriers are required around {set,clear}_bit() (which do
not return a value, and thus does not need to provide memory barrier
semantics), two interfaces are provided::
void smp_mb__before_atomic(void);
void smp_mb__after_atomic(void);
They are used as follows, and are akin to their atomic_t operation
brothers::
/* All memory operations before this call will
* be globally visible before the clear_bit().
*/
smp_mb__before_atomic();
clear_bit( ... );
/* The clear_bit() will be visible before all
* subsequent memory operations.
*/
smp_mb__after_atomic();
There are two special bitops with lock barrier semantics (acquire/release,
same as spinlocks). These operate in the same way as their non-_lock/unlock
postfixed variants, except that they are to provide acquire/release semantics,
respectively. This means they can be used for bit_spin_trylock and
bit_spin_unlock type operations without specifying any more barriers. ::
int test_and_set_bit_lock(unsigned long nr, unsigned long *addr);
void clear_bit_unlock(unsigned long nr, unsigned long *addr);
void __clear_bit_unlock(unsigned long nr, unsigned long *addr);
The __clear_bit_unlock version is non-atomic, however it still implements
unlock barrier semantics. This can be useful if the lock itself is protecting
the other bits in the word.
Finally, there are non-atomic versions of the bitmask operations
provided. They are used in contexts where some other higher-level SMP
locking scheme is being used to protect the bitmask, and thus less
expensive non-atomic operations may be used in the implementation.
They have names similar to the above bitmask operation interfaces,
except that two underscores are prefixed to the interface name. ::
void __set_bit(unsigned long nr, volatile unsigned long *addr);
void __clear_bit(unsigned long nr, volatile unsigned long *addr);
void __change_bit(unsigned long nr, volatile unsigned long *addr);
int __test_and_set_bit(unsigned long nr, volatile unsigned long *addr);
int __test_and_clear_bit(unsigned long nr, volatile unsigned long *addr);
int __test_and_change_bit(unsigned long nr, volatile unsigned long *addr);
These non-atomic variants also do not require any special memory
barrier semantics.
The routines xchg() and cmpxchg() must provide the same exact
memory-barrier semantics as the atomic and bit operations returning
values.
.. note::
If someone wants to use xchg(), cmpxchg() and their variants,
linux/atomic.h should be included rather than asm/cmpxchg.h, unless the
code is in arch/* and can take care of itself.
Spinlocks and rwlocks have memory barrier expectations as well.
The rule to follow is simple:
1) When acquiring a lock, the implementation must make it globally
visible before any subsequent memory operation.
2) When releasing a lock, the implementation must make it such that
all previous memory operations are globally visible before the
lock release.
Which finally brings us to _atomic_dec_and_lock(). There is an
architecture-neutral version implemented in lib/dec_and_lock.c,
but most platforms will wish to optimize this in assembler. ::
int _atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock);
Atomically decrement the given counter, and if will drop to zero
atomically acquire the given spinlock and perform the decrement
of the counter to zero. If it does not drop to zero, do nothing
with the spinlock.
It is actually pretty simple to get the memory barrier correct.
Simply satisfy the spinlock grab requirements, which is make
sure the spinlock operation is globally visible before any
subsequent memory operation.
We can demonstrate this operation more clearly if we define
an abstract atomic operation::
long cas(long *mem, long old, long new);
"cas" stands for "compare and swap". It atomically:
1) Compares "old" with the value currently at "mem".
2) If they are equal, "new" is written to "mem".
3) Regardless, the current value at "mem" is returned.
As an example usage, here is what an atomic counter update
might look like::
void example_atomic_inc(long *counter)
{
long old, new, ret;
while (1) {
old = *counter;
new = old + 1;
ret = cas(counter, old, new);
if (ret == old)
break;
}
}
Let's use cas() in order to build a pseudo-C atomic_dec_and_lock()::
int _atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
{
long old, new, ret;
int went_to_zero;
went_to_zero = 0;
while (1) {
old = atomic_read(atomic);
new = old - 1;
if (new == 0) {
went_to_zero = 1;
spin_lock(lock);
}
ret = cas(atomic, old, new);
if (ret == old)
break;
if (went_to_zero) {
spin_unlock(lock);
went_to_zero = 0;
}
}
return went_to_zero;
}
Now, as far as memory barriers go, as long as spin_lock()
strictly orders all subsequent memory operations (including
the cas()) with respect to itself, things will be fine.
Said another way, _atomic_dec_and_lock() must guarantee that
a counter dropping to zero is never made visible before the
spinlock being acquired.
.. note::
Note that this also means that for the case where the counter is not
dropping to zero, there are no memory ordering requirements.

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

@@ -531,7 +531,9 @@ For printing bitmap and its derivatives such as cpumask and nodemask,
%*pb outputs the bitmap with field width as the number of bits and %*pbl
output the bitmap as range list with field width as the number of bits.
Passed by reference.
The field width is passed by value, the bitmap is passed by reference.
Helper macros cpumask_pr_args() and nodemask_pr_args() are available to ease
printing cpumask and nodemask.
Flags bitfields such as page flags, gfp_flags
---------------------------------------------

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

@@ -224,14 +224,21 @@ you may want to use::
rm -f err.log
export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci
make coccicheck DEBUG_FILE="err.log" MODE=report SPFLAGS="--profile --show-trying" M=./drivers/mfd/arizona-irq.c
make coccicheck DEBUG_FILE="err.log" MODE=report SPFLAGS="--profile --show-trying" M=./drivers/mfd
err.log will now have the profiling information, while stdout will
provide some progress information as Coccinelle moves forward with
work.
NOTE:
DEBUG_FILE support is only supported when using coccinelle >= 1.0.2.
Currently, DEBUG_FILE support is only available to check folders, and
not single files. This is because checking a single file requires spatch
to be called twice leading to DEBUG_FILE being set both times to the same value,
giving rise to an error.
.cocciconfig support
--------------------

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

@@ -330,7 +330,7 @@ using something like insmod or modprobe. The module is called ``test_kasan``.
~~~~~~~~~~~~~
With ``CONFIG_KUNIT`` built-in, ``CONFIG_KASAN_KUNIT_TEST`` can be built-in
on any architecure that supports KASAN. These and any other KUnit
on any architecture that supports KASAN. These and any other KUnit
tests enabled will run and print the results at boot as a late-init
call.
@@ -351,5 +351,5 @@ converted to KUnit. These tests can be run only as a module with
``CONFIG_KASAN`` built-in. The type of error expected and the
function being run is printed before the expression expected to give
an error. Then the error is printed, if found, and that test
should be interpretted to pass only if the error was the one expected
should be interpreted to pass only if the error was the one expected
by the test.

2
Documentation/dev-tools/kcov.rst
View File

@@ -243,7 +243,7 @@ handles as they don't belong to a particular subsystem. The bytes 4-7 are
currently reserved and must be zero. In the future the number of bytes
used for the subsystem or handle ids might be increased.
When a particular userspace proccess collects coverage via a common
When a particular userspace process collects coverage via a common
handle, kcov will collect coverage for each code section that is annotated
to use the common handle obtained as kcov_handle from the current
task_struct. However non common handles allow to collect coverage

7
Documentation/dev-tools/kgdb.rst
View File

@@ -63,10 +63,9 @@ will want to turn on ``CONFIG_DEBUG_INFO`` which is called
It is advised, but not required, that you turn on the
``CONFIG_FRAME_POINTER`` kernel option which is called :menuselection:`Compile
the kernel with frame pointers` in the config menu. This option inserts code
to into the compiled executable which saves the frame information in
registers or on the stack at different points which allows a debugger
such as gdb to more accurately construct stack back traces while
debugging the kernel.
into the compiled executable which saves the frame information in registers
or on the stack at different points which allows a debugger such as gdb to
more accurately construct stack back traces while debugging the kernel.
If the architecture that you are using supports the kernel option
``CONFIG_STRICT_KERNEL_RWX``, you should consider turning it off. This

3
Documentation/devicetree/bindings/submitting-patches.rst
View File

@@ -25,7 +25,8 @@ I. For patch submitters
make dt_binding_check
See ../writing-schema.rst for more details about schema and tools setup.
See Documentation/devicetree/writing-schema.rst for more details about
schema and tools setup.
3) DT binding files should be dual licensed. The preferred license tag is
(GPL-2.0-only OR BSD-2-Clause).

49
Documentation/devicetree/bindings/timer/renesas,tmu.txt
View File

@@ -1,49 +0,0 @@
* Renesas R-Mobile/R-Car Timer Unit (TMU)
The TMU is a 32-bit timer/counter with configurable clock inputs and
programmable compare match.
Channels share hardware resources but their counter and compare match value
are independent. The TMU hardware supports up to three channels.
Required Properties:
- compatible: must contain one or more of the following:
- "renesas,tmu-r8a7740" for the r8a7740 TMU
- "renesas,tmu-r8a774a1" for the r8a774A1 TMU
- "renesas,tmu-r8a774b1" for the r8a774B1 TMU
- "renesas,tmu-r8a774c0" for the r8a774C0 TMU
- "renesas,tmu-r8a7778" for the r8a7778 TMU
- "renesas,tmu-r8a7779" for the r8a7779 TMU
- "renesas,tmu-r8a77970" for the r8a77970 TMU
- "renesas,tmu-r8a77980" for the r8a77980 TMU
- "renesas,tmu" for any TMU.
This is a fallback for the above renesas,tmu-* entries
- reg: base address and length of the registers block for the timer module.
- interrupts: interrupt-specifier for the timer, one per channel.
- clocks: a list of phandle + clock-specifier pairs, one for each entry
in clock-names.
- clock-names: must contain "fck" for the functional clock.
Optional Properties:
- #renesas,channels: number of channels implemented by the timer, must be 2
or 3 (if not specified the value defaults to 3).
Example: R8A7779 (R-Car H1) TMU0 node
tmu0: timer@ffd80000 {
compatible = "renesas,tmu-r8a7779", "renesas,tmu";
reg = <0xffd80000 0x30>;
interrupts = <0 32 IRQ_TYPE_LEVEL_HIGH>,
<0 33 IRQ_TYPE_LEVEL_HIGH>,
<0 34 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7779_CLK_TMU0>;
clock-names = "fck";
#renesas,channels = <3>;
};

99
Documentation/devicetree/bindings/timer/renesas,tmu.yaml Normal file
View File

@@ -0,0 +1,99 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/timer/renesas,tmu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas R-Mobile/R-Car Timer Unit (TMU)
maintainers:
- Geert Uytterhoeven <geert+renesas@glider.be>
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
description:
The TMU is a 32-bit timer/counter with configurable clock inputs and
programmable compare match.
Channels share hardware resources but their counter and compare match value
are independent. The TMU hardware supports up to three channels.
properties:
compatible:
items:
- enum:
- renesas,tmu-r8a7740 # R-Mobile A1
- renesas,tmu-r8a774a1 # RZ/G2M
- renesas,tmu-r8a774b1 # RZ/G2N
- renesas,tmu-r8a774c0 # RZ/G2E
- renesas,tmu-r8a774e1 # RZ/G2H
- renesas,tmu-r8a7778 # R-Car M1A
- renesas,tmu-r8a7779 # R-Car H1
- renesas,tmu-r8a77970 # R-Car V3M
- renesas,tmu-r8a77980 # R-Car V3H
- const: renesas,tmu
reg:
maxItems: 1
interrupts:
minItems: 2
maxItems: 3
clocks:
maxItems: 1
clock-names:
const: fck
power-domains:
maxItems: 1
resets:
maxItems: 1
'#renesas,channels':
description:
Number of channels implemented by the timer.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 2, 3 ]
default: 3
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- power-domains
if:
not:
properties:
compatible:
contains:
enum:
- renesas,tmu-r8a7740
- renesas,tmu-r8a7778
- renesas,tmu-r8a7779
then:
required:
- resets
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/r8a7779-clock.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7779-sysc.h>
tmu0: timer@ffd80000 {
compatible = "renesas,tmu-r8a7779", "renesas,tmu";
reg = <0xffd80000 0x30>;
interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp0_clks R8A7779_CLK_TMU0>;
clock-names = "fck";
power-domains = <&sysc R8A7779_PD_ALWAYS_ON>;
#renesas,channels = <3>;
};

6
Documentation/doc-guide/kernel-doc.rst
View File

@@ -247,12 +247,12 @@ It is possible to document nested structs and unions, like::
struct {
int memb1;
int memb2;
}
};
struct {
void *memb3;
int memb4;
}
}
};
};
union {
struct {
int memb1;

2
Documentation/doc-guide/sphinx.rst
View File

@@ -375,7 +375,7 @@ image format use SVG (:ref:`svg_image_example`)::
SVG image example
The kernel figure (and image) directive support **DOT** formated files, see
The kernel figure (and image) directive support **DOT** formatted files, see
* DOT: http://graphviz.org/pdf/dotguide.pdf
* Graphviz: http://www.graphviz.org/content/dot-language

1
Documentation/driver-api/index.rst
View File

@@ -29,6 +29,7 @@ available subsections can be seen below.
infiniband
frame-buffer
regulator
reset
iio/index
input
usb/index

4
Documentation/driver-api/mtd/intel-spi.rst
View File

@@ -52,7 +52,7 @@ Linux.
16384+0 records out
8388608 bytes (8.4 MB) copied, 10.0269 s, 837 kB/s
6) Verify the backup:
6) Verify the backup::
# sha1sum /dev/mtd0ro bios.bak
fdbb011920572ca6c991377c4b418a0502668b73 /dev/mtd0ro
@@ -66,7 +66,7 @@ Linux.
# flash_erase /dev/mtd0 0 0
Erasing 4 Kibyte @ 7ff000 -- 100 % complete
8) Once completed without errors you can write the new BIOS image:
8) Once completed without errors you can write the new BIOS image::
# dd if=MNW2MAX1.X64.0092.R01.1605221712.bin of=/dev/mtd0

6
Documentation/driver-api/mtd/spi-nor.rst
View File

@@ -34,7 +34,8 @@ Before this framework, the layer is like::
------------------------
SPI NOR chip
After this framework, the layer is like:
After this framework, the layer is like::
MTD
------------------------
SPI NOR framework
@@ -45,7 +46,8 @@ Before this framework, the layer is like::
------------------------
SPI NOR chip
With the SPI NOR controller driver (Freescale QuadSPI), it looks like:
With the SPI NOR controller driver (Freescale QuadSPI), it looks like::
MTD
------------------------
SPI NOR framework

221
Documentation/driver-api/reset.rst Normal file
View File

@@ -0,0 +1,221 @@
.. SPDX-License-Identifier: GPL-2.0-only
====================
Reset controller API
====================
Introduction
============
Reset controllers are central units that control the reset signals to multiple
peripherals.
The reset controller API is split into two parts:
the `consumer driver interface <#consumer-driver-interface>`__ (`API reference
<#reset-consumer-api>`__), which allows peripheral drivers to request control
over their reset input signals, and the `reset controller driver interface
<#reset-controller-driver-interface>`__ (`API reference
<#reset-controller-driver-api>`__), which is used by drivers for reset
controller devices to register their reset controls to provide them to the
consumers.
While some reset controller hardware units also implement system restart
functionality, restart handlers are out of scope for the reset controller API.
Glossary
--------
The reset controller API uses these terms with a specific meaning:
Reset line
Physical reset line carrying a reset signal from a reset controller
hardware unit to a peripheral module.
Reset control
Control method that determines the state of one or multiple reset lines.
Most commonly this is a single bit in reset controller register space that
either allows direct control over the physical state of the reset line, or
is self-clearing and can be used to trigger a predetermined pulse on the
reset line.
In more complicated reset controls, a single trigger action can launch a
carefully timed sequence of pulses on multiple reset lines.
Reset controller
A hardware module that provides a number of reset controls to control a
number of reset lines.
Reset consumer
Peripheral module or external IC that is put into reset by the signal on a
reset line.
Consumer driver interface
=========================
This interface provides an API that is similar to the kernel clock framework.
Consumer drivers use get and put operations to acquire and release reset
controls.
Functions are provided to assert and deassert the controlled reset lines,
trigger reset pulses, or to query reset line status.
When requesting reset controls, consumers can use symbolic names for their
reset inputs, which are mapped to an actual reset control on an existing reset
controller device by the core.
A stub version of this API is provided when the reset controller framework is
not in use in order to minimize the need to use ifdefs.
Shared and exclusive resets
---------------------------
The reset controller API provides either reference counted deassertion and
assertion or direct, exclusive control.
The distinction between shared and exclusive reset controls is made at the time
the reset control is requested, either via devm_reset_control_get_shared() or
via devm_reset_control_get_exclusive().
This choice determines the behavior of the API calls made with the reset
control.
Shared resets behave similarly to clocks in the kernel clock framework.
They provide reference counted deassertion, where only the first deassert,
which increments the deassertion reference count to one, and the last assert
which decrements the deassertion reference count back to zero, have a physical
effect on the reset line.
Exclusive resets on the other hand guarantee direct control.
That is, an assert causes the reset line to be asserted immediately, and a
deassert causes the reset line to be deasserted immediately.
Assertion and deassertion
-------------------------
Consumer drivers use the reset_control_assert() and reset_control_deassert()
functions to assert and deassert reset lines.
For shared reset controls, calls to the two functions must be balanced.
Note that since multiple consumers may be using a shared reset control, there
is no guarantee that calling reset_control_assert() on a shared reset control
will actually cause the reset line to be asserted.
Consumer drivers using shared reset controls should assume that the reset line
may be kept deasserted at all times.
The API only guarantees that the reset line can not be asserted as long as any
consumer has requested it to be deasserted.
Triggering
----------
Consumer drivers use reset_control_reset() to trigger a reset pulse on a
self-deasserting reset control.
In general, these resets can not be shared between multiple consumers, since
requesting a pulse from any consumer driver will reset all connected
peripherals.
The reset controller API allows requesting self-deasserting reset controls as
shared, but for those only the first trigger request causes an actual pulse to
be issued on the reset line.
All further calls to this function have no effect until all consumers have
called reset_control_rearm().
For shared reset controls, calls to the two functions must be balanced.
This allows devices that only require an initial reset at any point before the
driver is probed or resumed to share a pulsed reset line.
Querying
--------
Only some reset controllers support querying the current status of a reset
line, via reset_control_status().
If supported, this function returns a positive non-zero value if the given
reset line is asserted.
The reset_control_status() function does not accept a
`reset control array <#reset-control-arrays>`__ handle as its input parameter.
Optional resets
---------------
Often peripherals require a reset line on some platforms but not on others.
For this, reset controls can be requested as optional using
devm_reset_control_get_optional_exclusive() or
devm_reset_control_get_optional_shared().
These functions return a NULL pointer instead of an error when the requested
reset control is not specified in the device tree.
Passing a NULL pointer to the reset_control functions causes them to return
quietly without an error.
Reset control arrays
--------------------
Some drivers need to assert a bunch of reset lines in no particular order.
devm_reset_control_array_get() returns an opaque reset control handle that can
be used to assert, deassert, or trigger all specified reset controls at once.
The reset control API does not guarantee the order in which the individual
controls therein are handled.
Reset controller driver interface
=================================
Drivers for reset controller modules provide the functionality necessary to
assert or deassert reset signals, to trigger a reset pulse on a reset line, or
to query its current state.
All functions are optional.
Initialization
--------------
Drivers fill a struct :c:type:`reset_controller_dev` and register it with
reset_controller_register() in their probe function.
The actual functionality is implemented in callback functions via a struct
:c:type:`reset_control_ops`.
API reference
=============
The reset controller API is documented here in two parts:
the `reset consumer API <#reset-consumer-api>`__ and the `reset controller
driver API <#reset-controller-driver-api>`__.
Reset consumer API
------------------
Reset consumers can control a reset line using an opaque reset control handle,
which can be obtained from devm_reset_control_get_exclusive() or
devm_reset_control_get_shared().
Given the reset control, consumers can call reset_control_assert() and
reset_control_deassert(), trigger a reset pulse using reset_control_reset(), or
query the reset line status using reset_control_status().
.. kernel-doc:: include/linux/reset.h
:internal:
.. kernel-doc:: drivers/reset/core.c
:functions: reset_control_reset
reset_control_assert
reset_control_deassert
reset_control_status
reset_control_acquire
reset_control_release
reset_control_rearm
reset_control_put
of_reset_control_get_count
of_reset_control_array_get
devm_reset_control_array_get
reset_control_get_count
Reset controller driver API
---------------------------
Reset controller drivers are supposed to implement the necessary functions in
a static constant structure :c:type:`reset_control_ops`, allocate and fill out
a struct :c:type:`reset_controller_dev`, and register it using
devm_reset_controller_register().
.. kernel-doc:: include/linux/reset-controller.h
:internal:
.. kernel-doc:: drivers/reset/core.c
:functions: of_reset_simple_xlate
reset_controller_register
reset_controller_unregister
devm_reset_controller_register
reset_controller_add_lookup

17
Documentation/features/list-arch.sh
View File

@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
#
# Small script that visualizes the kernel feature support status
# of an architecture.
@@ -7,18 +8,4 @@
ARCH=${1:-$(uname -m | sed 's/x86_64/x86/' | sed 's/i386/x86/')}
cd $(dirname $0)
echo "#"
echo "# Kernel feature support matrix of the '$ARCH' architecture:"
echo "#"
for F in */*/arch-support.txt; do
SUBSYS=$(echo $F | cut -d/ -f1)
N=$(grep -h "^# Feature name:" $F | cut -c25-)
C=$(grep -h "^# Kconfig:" $F | cut -c25-)
D=$(grep -h "^# description:" $F | cut -c25-)
S=$(grep -hv "^#" $F | grep -w $ARCH | cut -d\| -f3)
printf "%10s/%-22s:%s| %35s # %s\n" "$SUBSYS" "$N" "$S" "$C" "$D"
done
$(dirname $0)/../../scripts/get_feat.pl list --arch $ARCH

2
Documentation/features/locking/queued-rwlocks/arch-support.txt
View File

@@ -22,7 +22,7 @@
| nios2: | TODO |
| openrisc: | ok |
| parisc: | TODO |
| powerpc: | TODO |
| powerpc: | ok |
| riscv: | TODO |
| s390: | TODO |
| sh: | TODO |

2
Documentation/features/locking/queued-spinlocks/arch-support.txt
View File

@@ -22,7 +22,7 @@
| nios2: | TODO |
| openrisc: | ok |
| parisc: | TODO |
| powerpc: | TODO |
| powerpc: | ok |
| riscv: | TODO |
| s390: | TODO |
| sh: | TODO |

4
Documentation/features/seccomp/seccomp-filter/arch-support.txt
View File

@@ -11,7 +11,7 @@
| arm: | ok |
| arm64: | ok |
| c6x: | TODO |
| csky: | TODO |
| csky: | ok |
| h8300: | TODO |
| hexagon: | TODO |
| ia64: | TODO |
@@ -25,7 +25,7 @@
| powerpc: | ok |
| riscv: | ok |
| s390: | ok |
| sh: | TODO |
| sh: | ok |
| sparc: | TODO |
| um: | ok |
| x86: | ok |

2
Documentation/features/time/context-tracking/arch-support.txt
View File

@@ -11,7 +11,7 @@
| arm: | ok |
| arm64: | ok |
| c6x: | TODO |
| csky: | TODO |
| csky: | ok |
| h8300: | TODO |
| hexagon: | TODO |
| ia64: | TODO |

2
Documentation/features/time/virt-cpuacct/arch-support.txt
View File

@@ -11,7 +11,7 @@
| arm: | ok |
| arm64: | ok |
| c6x: | TODO |
| csky: | TODO |
| csky: | ok |
| h8300: | TODO |
| hexagon: | TODO |
| ia64: | ok |

2
Documentation/filesystems/index.rst
View File

@@ -113,7 +113,7 @@ Documentation for filesystem implementations.
sysv-fs
tmpfs
ubifs
ubifs-authentication.rst
ubifs-authentication
udf
virtiofs
vfat

4
Documentation/filesystems/mount_api.rst
View File

@@ -774,7 +774,7 @@ process the parameters it is given.
should just be set to lie inside the low-to-high range.
If all is good, true is returned. If the table is invalid, errors are
logged to dmesg and false is returned.
logged to the kernel log buffer and false is returned.
* ::
@@ -782,7 +782,7 @@ process the parameters it is given.
This performs some validation checks on a parameter description. It
returns true if the description is good and false if it is not. It will
log errors to dmesg if validation fails.
log errors to the kernel log buffer if validation fails.
* ::

1
Documentation/filesystems/proc.rst
View File

@@ -549,6 +549,7 @@ encoded manner. The codes are the following:
nh no huge page advise flag
mg mergable advise flag
bt arm64 BTI guarded page
mt arm64 MTE allocation tags are enabled
== =======================================
Note that there is no guarantee that every flag and associated mnemonic will

3
Documentation/ia64/features.rst Normal file
View File

@@ -0,0 +1,3 @@
.. SPDX-License-Identifier: GPL-2.0
.. kernel-feat:: $srctree/Documentation/features ia64

2
Documentation/ia64/index.rst
View File

@@ -15,3 +15,5 @@ IA-64 Architecture
irq-redir
mca
serial
features

2
Documentation/index.rst
View File

@@ -160,7 +160,7 @@ implementation.
ia64/index
m68k/index
mips/index
nios2/nios2
nios2/index
openrisc/index
parisc/index
powerpc/index

21
Documentation/locking/seqlock.rst
View File

@@ -89,7 +89,7 @@ Read path::
.. _seqcount_locktype_t:
Sequence counters with associated locks (``seqcount_LOCKTYPE_t``)
Sequence counters with associated locks (``seqcount_LOCKNAME_t``)
-----------------------------------------------------------------
As discussed at :ref:`seqcount_t`, sequence count write side critical
@@ -115,27 +115,26 @@ The following sequence counters with associated locks are defined:
- ``seqcount_mutex_t``
- ``seqcount_ww_mutex_t``
The plain seqcount read and write APIs branch out to the specific
seqcount_LOCKTYPE_t implementation at compile-time. This avoids kernel
API explosion per each new seqcount LOCKTYPE.
The sequence counter read and write APIs can take either a plain
seqcount_t or any of the seqcount_LOCKNAME_t variants above.
Initialization (replace "LOCKTYPE" with one of the supported locks)::
Initialization (replace "LOCKNAME" with one of the supported locks)::
/* dynamic */
seqcount_LOCKTYPE_t foo_seqcount;
seqcount_LOCKTYPE_init(&foo_seqcount, &lock);
seqcount_LOCKNAME_t foo_seqcount;
seqcount_LOCKNAME_init(&foo_seqcount, &lock);
/* static */
static seqcount_LOCKTYPE_t foo_seqcount =
SEQCNT_LOCKTYPE_ZERO(foo_seqcount, &lock);
static seqcount_LOCKNAME_t foo_seqcount =
SEQCNT_LOCKNAME_ZERO(foo_seqcount, &lock);
/* C99 struct init */
struct {
.seq = SEQCNT_LOCKTYPE_ZERO(foo.seq, &lock),
.seq = SEQCNT_LOCKNAME_ZERO(foo.seq, &lock),
} foo;
Write path: same as in :ref:`seqcount_t`, while running from a context
with the associated LOCKTYPE lock acquired.
with the associated write serialization lock acquired.
Read path: same as in :ref:`seqcount_t`.

3
Documentation/m68k/features.rst Normal file
View File

@@ -0,0 +1,3 @@
.. SPDX-License-Identifier: GPL-2.0
.. kernel-feat:: $srctree/Documentation/features m68k

2
Documentation/m68k/index.rst
View File

@@ -10,6 +10,8 @@ m68k Architecture
kernel-options
buddha-driver
features
.. only:: subproject and html
Indices

2
Documentation/memory-barriers.txt
View File

@@ -1870,7 +1870,7 @@ There are some more advanced barrier functions:
These are for use with atomic RMW functions that do not imply memory
barriers, but where the code needs a memory barrier. Examples for atomic
RMW functions that do not imply are memory barrier are e.g. add,
RMW functions that do not imply a memory barrier are e.g. add,
subtract, (failed) conditional operations, _relaxed functions,
but not atomic_read or atomic_set. A common example where a memory
barrier may be required is when atomic ops are used for reference

3
Documentation/mips/features.rst Normal file
View File

@@ -0,0 +1,3 @@
.. SPDX-License-Identifier: GPL-2.0
.. kernel-feat:: $srctree/Documentation/features mips

2
Documentation/mips/index.rst
View File

@@ -11,6 +11,8 @@ MIPS-specific Documentation
booting
ingenic-tcu
features
.. only:: subproject and html
Indices

4
Documentation/networking/device_drivers/ethernet/3com/vortex.rst
View File

@@ -374,8 +374,8 @@ steps you should take:
email address will be in the driver source or in the MAINTAINERS file.
- The contents of your report will vary a lot depending upon the
problem. If it's a kernel crash then you should refer to the
admin-guide/reporting-bugs.rst file.
problem. If it's a kernel crash then you should refer to
'Documentation/admin-guide/reporting-issues.rst'.
But for most problems it is useful to provide the following:

3
Documentation/nios2/features.rst Normal file
View File

@@ -0,0 +1,3 @@
.. SPDX-License-Identifier: GPL-2.0
.. kernel-feat:: $srctree/Documentation/features nios2

12
Documentation/nios2/index.rst Normal file
View File

@@ -0,0 +1,12 @@
.. SPDX-License-Identifier: GPL-2.0
==============================
Nios II Specific Documentation
==============================
.. toctree::
:maxdepth: 2
:numbered:
nios2
features

3
Documentation/openrisc/features.rst Normal file
View File

@@ -0,0 +1,3 @@
.. SPDX-License-Identifier: GPL-2.0
.. kernel-feat:: $srctree/Documentation/features openrisc

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