mirrors
/
linux-stable
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
1
0
Fork 0
Code Issues Releases Wiki Activity

Linux 5.11 

-----BEGIN PGP SIGNATURE-----
 
 iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmAppPgeHHRvcnZhbGRz
 QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGeXYH/imZPBd4A1jIMehN
 5HV2A53Z+MXmmaMuGj9X1KV6vsf55/xB+IhOoFdtRAIsO8c2yYSCO8i4+4R0XfYA
 +/YFJeq672rojQnmh6XbpR8dugaAV7CUHy6n7KDsyvtT6EOCpwFSwkOb4X3tBRX6
 TlYgm2d/xgV/wRHSgLVugK0MdFCLMAnyb7mkPfar9QrMgG1BiDKLq07xmwnS23On
 TkqpJ9yZ/rJpUrrUqQYPShSO/FmA+fSfWs0CDv7EIrJ40LUScD6PZxSHWTIHtjLk
 E4jFda6wuqLRVWsBwaBzUIdD0zk7X5quHRzEpbC5ga16SK6yrWvE5YJJXCguIEuZ
 f3FMRYs=
 =CAjn
 -----END PGP SIGNATURE-----

Merge tag 'v5.11' into sched/core, to pick up fixes & refresh the branch

Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar 2021-02-17 14:04:39 +01:00
parent bae4ec1364 f40ddce885
commit ed3cd45f8c
1642 changed files with 19379 additions and 9654 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
.clang-format
View File

@ -122,6 +122,7 @@ ForEachMacros:
- 'drm_for_each_bridge_in_chain'
- 'drm_for_each_connector_iter'
- 'drm_for_each_crtc'
- 'drm_for_each_crtc_reverse'
- 'drm_for_each_encoder'
- 'drm_for_each_encoder_mask'
- 'drm_for_each_fb'
@ -203,14 +204,13 @@ ForEachMacros:
- 'for_each_matching_node'
- 'for_each_matching_node_and_match'
- 'for_each_member'
- 'for_each_mem_region'
- 'for_each_memblock_type'
- 'for_each_memcg_cache_index'
- 'for_each_mem_pfn_range'
- '__for_each_mem_range'
- 'for_each_mem_range'
- '__for_each_mem_range_rev'
- 'for_each_mem_range_rev'
- 'for_each_mem_region'
- 'for_each_migratetype_order'
- 'for_each_msi_entry'
- 'for_each_msi_entry_safe'
@ -276,10 +276,8 @@ ForEachMacros:
- 'for_each_reserved_mem_range'
- 'for_each_reserved_mem_region'
- 'for_each_rtd_codec_dais'
- 'for_each_rtd_codec_dais_rollback'
- 'for_each_rtd_components'
- 'for_each_rtd_cpu_dais'
- 'for_each_rtd_cpu_dais_rollback'
- 'for_each_rtd_dais'
- 'for_each_set_bit'
- 'for_each_set_bit_from'
@ -298,6 +296,7 @@ ForEachMacros:
- '__for_each_thread'
- 'for_each_thread'
- 'for_each_unicast_dest_pgid'
- 'for_each_vsi'
- 'for_each_wakeup_source'
- 'for_each_zone'
- 'for_each_zone_zonelist'
@ -330,6 +329,7 @@ ForEachMacros:
- 'hlist_for_each_entry_rcu_bh'
- 'hlist_for_each_entry_rcu_notrace'
- 'hlist_for_each_entry_safe'
- 'hlist_for_each_entry_srcu'
- '__hlist_for_each_rcu'
- 'hlist_for_each_safe'
- 'hlist_nulls_for_each_entry'
@ -378,6 +378,7 @@ ForEachMacros:
- 'list_for_each_entry_safe_continue'
- 'list_for_each_entry_safe_from'
- 'list_for_each_entry_safe_reverse'
- 'list_for_each_entry_srcu'
- 'list_for_each_prev'
- 'list_for_each_prev_safe'
- 'list_for_each_safe'
@ -411,6 +412,8 @@ ForEachMacros:
- 'of_property_for_each_string'
- 'of_property_for_each_u32'
- 'pci_bus_for_each_resource'
- 'pcl_for_each_chunk'
- 'pcl_for_each_segment'
- 'pcm_for_each_format'
- 'ping_portaddr_for_each_entry'
- 'plist_for_each'

13
.mailmap
View File

@ -9,9 +9,6 @@
#
# Please keep this list dictionary sorted.
#
# This comment is parsed by git-shortlog:
# repo-abbrev: /pub/scm/linux/kernel/git/
#
Aaron Durbin <adurbin@google.com>
Adam Oldham <oldhamca@gmail.com>
Adam Radford <aradford@gmail.com>
@ -40,6 +37,7 @@ Andrew Murray <amurray@thegoodpenguin.co.uk> <amurray@embedded-bits.co.uk>
Andrew Murray <amurray@thegoodpenguin.co.uk> <andrew.murray@arm.com>
Andrew Vasquez <andrew.vasquez@qlogic.com>
Andrey Ryabinin <ryabinin.a.a@gmail.com> <a.ryabinin@samsung.com>
Andrey Ryabinin <ryabinin.a.a@gmail.com> <aryabinin@virtuozzo.com>
Andy Adamson <andros@citi.umich.edu>
Antoine Tenart <atenart@kernel.org> <antoine.tenart@bootlin.com>
Antoine Tenart <atenart@kernel.org> <antoine.tenart@free-electrons.com>
@ -55,6 +53,8 @@ Bart Van Assche <bvanassche@acm.org> <bart.vanassche@wdc.com>
Ben Gardner <bgardner@wabtec.com>
Ben M Cahill <ben.m.cahill@intel.com>
Björn Steinbrink <B.Steinbrink@gmx.de>
Björn Töpel <bjorn@kernel.org> <bjorn.topel@gmail.com>
Björn Töpel <bjorn@kernel.org> <bjorn.topel@intel.com>
Boris Brezillon <bbrezillon@kernel.org> <b.brezillon.dev@gmail.com>
Boris Brezillon <bbrezillon@kernel.org> <b.brezillon@overkiz.com>
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@bootlin.com>
@ -180,6 +180,8 @@ Kees Cook <keescook@chromium.org> <kees.cook@canonical.com>
Kees Cook <keescook@chromium.org> <keescook@google.com>
Kees Cook <keescook@chromium.org> <kees@outflux.net>
Kees Cook <keescook@chromium.org> <kees@ubuntu.com>
Keith Busch <kbusch@kernel.org> <keith.busch@intel.com>
Keith Busch <kbusch@kernel.org> <keith.busch@linux.intel.com>
Kenneth W Chen <kenneth.w.chen@intel.com>
Konstantin Khlebnikov <koct9i@gmail.com> <khlebnikov@yandex-team.ru>
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
@ -200,6 +202,8 @@ Li Yang <leoyang.li@nxp.com> <leoli@freescale.com>
Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
Lukasz Luba <lukasz.luba@arm.com> <l.luba@partner.samsung.com>
Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>
Manivannan Sadhasivam <mani@kernel.org> <manivannanece23@gmail.com>
Manivannan Sadhasivam <mani@kernel.org> <manivannan.sadhasivam@linaro.org>
Marcin Nowakowski <marcin.nowakowski@mips.com> <marcin.nowakowski@imgtec.com>
Marc Zyngier <maz@kernel.org> <marc.zyngier@arm.com>
Mark Brown <broonie@sirena.org.uk>
@ -245,6 +249,7 @@ Morten Welinder <welinder@anemone.rentec.com>
Morten Welinder <welinder@darter.rentec.com>
Morten Welinder <welinder@troll.com>
Mythri P K <mythripk@ti.com>
Nathan Chancellor <nathan@kernel.org> <natechancellor@gmail.com>
Nguyen Anh Quynh <aquynh@gmail.com>
Nicolas Ferre <nicolas.ferre@microchip.com> <nicolas.ferre@atmel.com>
Nicolas Pitre <nico@fluxnic.net> <nicolas.pitre@linaro.org>
@ -335,6 +340,8 @@ Vinod Koul <vkoul@kernel.org> <vkoul@infradead.org>
Viresh Kumar <vireshk@kernel.org> <viresh.kumar2@arm.com>
Viresh Kumar <vireshk@kernel.org> <viresh.kumar@st.com>
Viresh Kumar <vireshk@kernel.org> <viresh.linux@gmail.com>
Viresh Kumar <viresh.kumar@linaro.org> <viresh.kumar@linaro.org>
Viresh Kumar <viresh.kumar@linaro.org> <viresh.kumar@linaro.com>
Vivien Didelot <vivien.didelot@gmail.com> <vivien.didelot@savoirfairelinux.com>
Vlad Dogaru <ddvlad@gmail.com> <vlad.dogaru@intel.com>
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@parallels.com>

24
CREDITS
View File

@ -710,6 +710,10 @@ S: Las Cuevas 2385 - Bo Guemes
S: Las Heras, Mendoza CP 5539
S: Argentina
N: Jay Cliburn
E: jcliburn@gmail.com
D: ATLX Ethernet drivers
N: Steven P. Cole
E: scole@lanl.gov
E: elenstev@mesatop.com
@ -1284,6 +1288,10 @@ D: Major kbuild rework during the 2.5 cycle
D: ISDN Maintainer
S: USA
N: Gerrit Renker
E: gerrit@erg.abdn.ac.uk
D: DCCP protocol support.
N: Philip Gladstone
E: philip@gladstonefamily.net
D: Kernel / timekeeping stuff
@ -2138,6 +2146,10 @@ E: seasons@falcon.sch.bme.hu
E: seasons@makosteszta.sote.hu
D: Original author of software suspend
N: Alexey Kuznetsov
E: kuznet@ms2.inr.ac.ru
D: Author and maintainer of large parts of the networking stack
N: Jaroslav Kysela
E: perex@perex.cz
W: https://www.perex.cz
@ -2696,6 +2708,10 @@ N: Wolfgang Muees
E: wolfgang@iksw-muees.de
D: Auerswald USB driver
N: Shrijeet Mukherjee
E: shrijeet@gmail.com
D: Network routing domains (VRF).
N: Paul Mundt
E: paul.mundt@gmail.com
D: SuperH maintainer
@ -4110,6 +4126,10 @@ S: B-1206 Jingmao Guojigongyu
S: 16 Baliqiao Nanjie, Beijing 101100
S: People's Repulic of China
N: Aviad Yehezkel
E: aviadye@nvidia.com
D: Kernel TLS implementation and offload support.
N: Victor Yodaiken
E: yodaiken@fsmlabs.com
D: RTLinux (RealTime Linux)
@ -4167,6 +4187,10 @@ S: 1507 145th Place SE #B5
S: Bellevue, Washington 98007
S: USA
N: Wensong Zhang
E: wensong@linux-vs.org
D: IP virtual server (IPVS).
N: Haojian Zhuang
E: haojian.zhuang@gmail.com
D: MMP support

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

@ -5,8 +5,8 @@ Description:
Provide a place in sysfs for the device link objects in the
kernel at any given time. The name of a device link directory,
denoted as ... above, is of the form <supplier>--<consumer>
where <supplier> is the supplier device name and <consumer> is
the consumer device name.
where <supplier> is the supplier bus:device name and <consumer>
is the consumer bus:device name.
What: /sys/class/devlink/.../auto_remove_on
Date: May 2020

5
Documentation/ABI/testing/sysfs-devices-consumer
View File

@ -4,5 +4,6 @@ Contact: Saravana Kannan <saravanak@google.com>
Description:
The /sys/devices/.../consumer:<consumer> are symlinks to device
links where this device is the supplier. <consumer> denotes the
name of the consumer in that device link. There can be zero or
more of these symlinks for a given device.
name of the consumer in that device link and is of the form
bus:device name. There can be zero or more of these symlinks
for a given device.

5
Documentation/ABI/testing/sysfs-devices-supplier
View File

@ -4,5 +4,6 @@ Contact: Saravana Kannan <saravanak@google.com>
Description:
The /sys/devices/.../supplier:<supplier> are symlinks to device
links where this device is the consumer. <supplier> denotes the
name of the supplier in that device link. There can be zero or
more of these symlinks for a given device.
name of the supplier in that device link and is of the form
bus:device name. There can be zero or more of these symlinks
for a given device.

36
Documentation/ABI/testing/sysfs-driver-ufs
View File

@ -916,21 +916,25 @@ Date: September 2014
Contact: Subhash Jadavani <subhashj@codeaurora.org>
Description: This entry could be used to set or show the UFS device
runtime power management level. The current driver
implementation supports 6 levels with next target states:
implementation supports 7 levels with next target states:
== ====================================================
0 an UFS device will stay active, an UIC link will
0 UFS device will stay active, UIC link will
stay active
1 an UFS device will stay active, an UIC link will
1 UFS device will stay active, UIC link will
hibernate
2 an UFS device will moved to sleep, an UIC link will
2 UFS device will be moved to sleep, UIC link will
stay active
3 an UFS device will moved to sleep, an UIC link will
3 UFS device will be moved to sleep, UIC link will
hibernate
4 an UFS device will be powered off, an UIC link will
4 UFS device will be powered off, UIC link will
hibernate
5 an UFS device will be powered off, an UIC link will
5 UFS device will be powered off, UIC link will
be powered off
6 UFS device will be moved to deep sleep, UIC link
will be powered off. Note, deep sleep might not be
supported in which case this value will not be
accepted
== ====================================================
What: /sys/bus/platform/drivers/ufshcd/*/rpm_target_dev_state
@ -954,21 +958,25 @@ Date: September 2014
Contact: Subhash Jadavani <subhashj@codeaurora.org>
Description: This entry could be used to set or show the UFS device
system power management level. The current driver
implementation supports 6 levels with next target states:
implementation supports 7 levels with next target states:
== ====================================================
0 an UFS device will stay active, an UIC link will
0 UFS device will stay active, UIC link will
stay active
1 an UFS device will stay active, an UIC link will
1 UFS device will stay active, UIC link will
hibernate
2 an UFS device will moved to sleep, an UIC link will
2 UFS device will be moved to sleep, UIC link will
stay active
3 an UFS device will moved to sleep, an UIC link will
3 UFS device will be moved to sleep, UIC link will
hibernate
4 an UFS device will be powered off, an UIC link will
4 UFS device will be powered off, UIC link will
hibernate
5 an UFS device will be powered off, an UIC link will
5 UFS device will be powered off, UIC link will
be powered off
6 UFS device will be moved to deep sleep, UIC link
will be powered off. Note, deep sleep might not be
supported in which case this value will not be
accepted
== ====================================================
What: /sys/bus/platform/drivers/ufshcd/*/spm_target_dev_state

2
Documentation/Makefile
View File

@ -75,7 +75,7 @@ quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4)
cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/userspace-api/media $2 && \
PYTHONDONTWRITEBYTECODE=1 \
BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath $(srctree)/$(src)/$5/$(SPHINX_CONF)) \
$(PYTHON) $(srctree)/scripts/jobserver-exec \
$(PYTHON3) $(srctree)/scripts/jobserver-exec \
$(SHELL) $(srctree)/Documentation/sphinx/parallel-wrapper.sh \
$(SPHINXBUILD) \
-b $2 \

8
Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
View File

@ -473,7 +473,7 @@ read-side critical sections that follow the idle period (the oval near
the bottom of the diagram above).
Plumbing this into the full grace-period execution is described
`below <#Forcing%20Quiescent%20States>`__.
`below <Forcing Quiescent States_>`__.
CPU-Hotplug Interface
^^^^^^^^^^^^^^^^^^^^^
@ -494,7 +494,7 @@ mask to detect CPUs having gone offline since the beginning of this
grace period.
Plumbing this into the full grace-period execution is described
`below <#Forcing%20Quiescent%20States>`__.
`below <Forcing Quiescent States_>`__.
Forcing Quiescent States
^^^^^^^^^^^^^^^^^^^^^^^^
@ -532,7 +532,7 @@ from other CPUs.
| RCU. But this diagram is complex enough as it is, so simplicity |
| overrode accuracy. You can think of it as poetic license, or you can |
| think of it as misdirection that is resolved in the |
| `stitched-together diagram <#Putting%20It%20All%20Together>`__. |
| `stitched-together diagram <Putting It All Together_>`__. |
+-----------------------------------------------------------------------+
Grace-Period Cleanup
@ -596,7 +596,7 @@ maintain ordering. For example, if the callback function wakes up a task
that runs on some other CPU, proper ordering must in place in both the
callback function and the task being awakened. To see why this is
important, consider the top half of the `grace-period
cleanup <#Grace-Period%20Cleanup>`__ diagram. The callback might be
cleanup`_ diagram. The callback might be
running on a CPU corresponding to the leftmost leaf ``rcu_node``
structure, and awaken a task that is to run on a CPU corresponding to
the rightmost leaf ``rcu_node`` structure, and the grace-period kernel

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

@ -45,7 +45,7 @@ requirements:
#. `Other RCU Flavors`_
#. `Possible Future Changes`_
This is followed by a `summary <#Summary>`__, however, the answers to
This is followed by a summary_, however, the answers to
each quick quiz immediately follows the quiz. Select the big white space
with your mouse to see the answer.
@ -1096,7 +1096,7 @@ memory barriers.
| case, voluntary context switch) within an RCU read-side critical |
| section. However, sleeping locks may be used within userspace RCU |
| read-side critical sections, and also within Linux-kernel sleepable |
| RCU `(SRCU) <#Sleepable%20RCU>`__ read-side critical sections. In |
| RCU `(SRCU) <Sleepable RCU_>`__ read-side critical sections. In |
| addition, the -rt patchset turns spinlocks into a sleeping locks so |
| that the corresponding critical sections can be preempted, which also |
| means that these sleeplockified spinlocks (but not other sleeping |
@ -1186,7 +1186,7 @@ non-preemptible (``CONFIG_PREEMPT=n``) kernels, and thus `tiny
RCU <https://lkml.kernel.org/g/20090113221724.GA15307@linux.vnet.ibm.com>`__
was born. Josh Triplett has since taken over the small-memory banner
with his `Linux kernel tinification <https://tiny.wiki.kernel.org/>`__
project, which resulted in `SRCU <#Sleepable%20RCU>`__ becoming optional
project, which resulted in `SRCU <Sleepable RCU_>`__ becoming optional
for those kernels not needing it.
The remaining performance requirements are, for the most part,
@ -1457,8 +1457,8 @@ will vary as the value of ``HZ`` varies, and can also be changed using
the relevant Kconfig options and kernel boot parameters. RCU currently
does not do much sanity checking of these parameters, so please use
caution when changing them. Note that these forward-progress measures
are provided only for RCU, not for `SRCU <#Sleepable%20RCU>`__ or `Tasks
RCU <#Tasks%20RCU>`__.
are provided only for RCU, not for `SRCU <Sleepable RCU_>`__ or `Tasks
RCU`_.
RCU takes the following steps in ``call_rcu()`` to encourage timely
invocation of callbacks when any given non-\ ``rcu_nocbs`` CPU has
@ -1477,8 +1477,8 @@ encouragement was provided:
Again, these are default values when running at ``HZ=1000``, and can be
overridden. Again, these forward-progress measures are provided only for
RCU, not for `SRCU <#Sleepable%20RCU>`__ or `Tasks
RCU <#Tasks%20RCU>`__. Even for RCU, callback-invocation forward
RCU, not for `SRCU <Sleepable RCU_>`__ or `Tasks
RCU`_. Even for RCU, callback-invocation forward
progress for ``rcu_nocbs`` CPUs is much less well-developed, in part
because workloads benefiting from ``rcu_nocbs`` CPUs tend to invoke
``call_rcu()`` relatively infrequently. If workloads emerge that need
@ -1920,7 +1920,7 @@ Hotplug CPU
The Linux kernel supports CPU hotplug, which means that CPUs can come
and go. It is of course illegal to use any RCU API member from an
offline CPU, with the exception of `SRCU <#Sleepable%20RCU>`__ read-side
offline CPU, with the exception of `SRCU <Sleepable RCU_>`__ read-side
critical sections. This requirement was present from day one in
DYNIX/ptx, but on the other hand, the Linux kernel's CPU-hotplug
implementation is “interesting.”
@ -2177,7 +2177,7 @@ handles these states differently:
However, RCU must be reliably informed as to whether any given CPU is
currently in the idle loop, and, for ``NO_HZ_FULL``, also whether that
CPU is executing in usermode, as discussed
`earlier <#Energy%20Efficiency>`__. It also requires that the
`earlier <Energy Efficiency_>`__. It also requires that the
scheduling-clock interrupt be enabled when RCU needs it to be:
#. If a CPU is either idle or executing in usermode, and RCU believes it
@ -2294,7 +2294,7 @@ Performance, Scalability, Response Time, and Reliability
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Expanding on the `earlier
discussion <#Performance%20and%20Scalability>`__, RCU is used heavily by
discussion <Performance and Scalability_>`__, RCU is used heavily by
hot code paths in performance-critical portions of the Linux kernel's
networking, security, virtualization, and scheduling code paths. RCU
must therefore use efficient implementations, especially in its

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

@ -23,7 +23,7 @@ Here is what the fields mean:
- ``name``
is an identifier string. A new /proc file will be created with this
``name below /proc/sys/fs/binfmt_misc``; cannot contain slashes ``/`` for
name below ``/proc/sys/fs/binfmt_misc``; cannot contain slashes ``/`` for
obvious reasons.
- ``type``
is the type of recognition. Give ``M`` for magic and ``E`` for extension.
@ -83,7 +83,7 @@ Here is what the fields mean:
``F`` - fix binary
The usual behaviour of binfmt_misc is to spawn the
binary lazily when the misc format file is invoked. However,
this doesn``t work very well in the face of mount namespaces and
this doesn't work very well in the face of mount namespaces and
changeroots, so the ``F`` mode opens the binary as soon as the
emulation is installed and uses the opened image to spawn the
emulator, meaning it is always available once installed,

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

@ -154,7 +154,7 @@ get the boot configuration data.
Because of this "piggyback" method, there is no need to change or
update the boot loader and the kernel image itself as long as the boot
loader passes the correct initrd file size. If by any chance, the boot
loader passes a longer size, the kernel feils to find the bootconfig data.
loader passes a longer size, the kernel fails to find the bootconfig data.
To do this operation, Linux kernel provides "bootconfig" command under
tools/bootconfig, which allows admin to apply or delete the config file

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

@ -1029,7 +1029,7 @@ All time durations are in microseconds.
one number is written, $MAX is updated.
cpu.pressure
A read-only nested-key file which exists on non-root cgroups.
A read-write nested-keyed file.
Shows pressure stall information for CPU. See
:ref:`Documentation/accounting/psi.rst <psi>` for details.
@ -1475,7 +1475,7 @@ PAGE_SIZE multiple when read back.
reduces the impact on the workload and memory management.
memory.pressure
A read-only nested-key file which exists on non-root cgroups.
A read-only nested-keyed file.
Shows pressure stall information for memory. See
:ref:`Documentation/accounting/psi.rst <psi>` for details.
@ -1714,7 +1714,7 @@ IO Interface Files
8:16 rbps=2097152 wbps=max riops=max wiops=max
io.pressure
A read-only nested-key file which exists on non-root cgroups.
A read-only nested-keyed file.
Shows pressure stall information for IO. See
:ref:`Documentation/accounting/psi.rst <psi>` for details.

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

@ -177,14 +177,20 @@ bitmap_flush_interval:number
The bitmap flush interval in milliseconds. The metadata buffers
are synchronized when this interval expires.
allow_discards
Allow block discard requests (a.k.a. TRIM) for the integrity device.
Discards are only allowed to devices using internal hash.
fix_padding
Use a smaller padding of the tag area that is more
space-efficient. If this option is not present, large padding is
used - that is for compatibility with older kernels.
allow_discards
Allow block discard requests (a.k.a. TRIM) for the integrity device.
Discards are only allowed to devices using internal hash.
legacy_recalculate
Allow recalculating of volumes with HMAC keys. This is disabled by
default for security reasons - an attacker could modify the volume,
set recalc_sector to zero, and the kernel would not detect the
modification.
The journal mode (D/J), buffer_sectors, journal_watermark, commit_time and
allow_discards can be changed when reloading the target (load an inactive

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

@ -3,8 +3,8 @@
The kernel's command-line parameters
====================================
The following is a consolidated list of the kernel parameters as
implemented by the __setup(), core_param() and module_param() macros
The following is a consolidated list of the kernel parameters as implemented
by the __setup(), early_param(), core_param() and module_param() macros
and sorted into English Dictionary order (defined as ignoring all
punctuation and sorting digits before letters in a case insensitive
manner), and with descriptions where known.

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

@ -1385,7 +1385,7 @@
ftrace_filter=[function-list]
[FTRACE] Limit the functions traced by the function
tracer at boot up. function-list is a comma separated
tracer at boot up. function-list is a comma-separated
list of functions. This list can be changed at run
time by the set_ftrace_filter file in the debugfs
tracing directory.
@ -1399,13 +1399,13 @@
ftrace_graph_filter=[function-list]
[FTRACE] Limit the top level callers functions traced
by the function graph tracer at boot up.
function-list is a comma separated list of functions
function-list is a comma-separated list of functions
that can be changed at run time by the
set_graph_function file in the debugfs tracing directory.
ftrace_graph_notrace=[function-list]
[FTRACE] Do not trace from the functions specified in
function-list. This list is a comma separated list of
function-list. This list is a comma-separated list of
functions that can be changed at run time by the
set_graph_notrace file in the debugfs tracing directory.
@ -2421,7 +2421,7 @@
when set.
Format: <int>
libata.force= [LIBATA] Force configurations. The format is comma
libata.force= [LIBATA] Force configurations. The format is comma-
separated list of "[ID:]VAL" where ID is
PORT[.DEVICE]. PORT and DEVICE are decimal numbers
matching port, link or device. Basically, it matches
@ -5145,7 +5145,7 @@
stacktrace_filter=[function-list]
[FTRACE] Limit the functions that the stack tracer
will trace at boot up. function-list is a comma separated
will trace at boot up. function-list is a comma-separated
list of functions. This list can be changed at run
time by the stack_trace_filter file in the debugfs
tracing directory. Note, this enables stack tracing
@ -5348,7 +5348,7 @@
trace_event=[event-list]
[FTRACE] Set and start specified trace events in order
to facilitate early boot debugging. The event-list is a
comma separated list of trace events to enable. See
comma-separated list of trace events to enable. See
also Documentation/trace/events.rst
trace_options=[option-list]
@ -5972,6 +5972,10 @@
This option is obsoleted by the "nopv" option, which
has equivalent effect for XEN platform.
xen_no_vector_callback
[KNL,X86,XEN] Disable the vector callback for Xen
event channel interrupts.
xen_scrub_pages= [XEN]
Boolean option to control scrubbing pages before giving them back
to Xen, for use by other domains. Can be also changed at runtime

16
Documentation/admin-guide/media/rkisp1.rst
View File

@ -13,6 +13,22 @@ This file documents the driver for the Rockchip ISP1 that is part of RK3288
and RK3399 SoCs. The driver is located under drivers/staging/media/rkisp1
and uses the Media-Controller API.
Revisions
=========
There exist multiple smaller revisions to this ISP that got introduced in
later SoCs. Revisions can be found in the enum :c:type:`rkisp1_cif_isp_version`
in the UAPI and the revision of the ISP inside the running SoC can be read
in the field hw_revision of struct media_device_info as returned by
ioctl MEDIA_IOC_DEVICE_INFO.
Versions in use are:
- RKISP1_V10: used at least in rk3288 and rk3399
- RKISP1_V11: declared in the original vendor code, but not used
- RKISP1_V12: used at least in rk3326 and px30
- RKISP1_V13: used at least in rk1808
Topology
========
.. _rkisp1_topology_graph:

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

@ -184,7 +184,7 @@ pages either asynchronously or synchronously, depending on the state
of the system. When the system is not loaded, most of the memory is free
and allocation requests will be satisfied immediately from the free
pages supply. As the load increases, the amount of the free pages goes
down and when it reaches a certain threshold (high watermark), an
down and when it reaches a certain threshold (low watermark), an
allocation request will awaken the ``kswapd`` daemon. It will
asynchronously scan memory pages and either just free them if the data
they contain is available elsewhere, or evict to the backing storage

4
Documentation/admin-guide/syscall-user-dispatch.rst
View File

@ -70,8 +70,8 @@ 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.
can be set to SYSCALL_DISPATCH_FILTER_ALLOW or SYSCALL_DISPATCH_FILTER_BLOCK.
Any other value should terminate the program with a SIGSYS.
Security Notes
--------------

5
Documentation/asm-annotations.rst
View File

@ -100,6 +100,11 @@ Instruction Macros
~~~~~~~~~~~~~~~~~~
This section covers ``SYM_FUNC_*`` and ``SYM_CODE_*`` enumerated above.
``objtool`` requires that all code must be contained in an ELF symbol. Symbol
names that have a ``.L`` prefix do not emit symbol table entries. ``.L``
prefixed symbols can be used within a code region, but should be avoided for
denoting a range of code via ``SYM_*_START/END`` annotations.
* ``SYM_FUNC_START`` and ``SYM_FUNC_START_LOCAL`` are supposed to be **the
most frequent markings**. They are used for functions with standard calling
conventions -- global and local. Like in C, they both align the functions to

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

@ -53,7 +53,6 @@ How Linux keeps everything from happening at the same time. See
.. toctree::
:maxdepth: 1
atomic_ops
refcount-vs-atomic
irq/index
local_ops

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

@ -160,29 +160,13 @@ intended for use in production as a security mitigation. Therefore it supports
boot parameters that allow to disable KASAN competely or otherwise control
particular KASAN features.
The things that can be controlled are:
- ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``).
1. Whether KASAN is enabled at all.
2. Whether KASAN collects and saves alloc/free stacks.
3. Whether KASAN panics on a detected bug or not.
- ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack
traces collection (default: ``on``).
The ``kasan.mode`` boot parameter allows to choose one of three main modes:
- ``kasan.mode=off`` - KASAN is disabled, no tag checks are performed
- ``kasan.mode=prod`` - only essential production features are enabled
- ``kasan.mode=full`` - all KASAN features are enabled
The chosen mode provides default control values for the features mentioned
above. However it's also possible to override the default values by providing:
- ``kasan.stacktrace=off`` or ``=on`` - enable alloc/free stack collection
(default: ``on`` for ``mode=full``,
otherwise ``off``)
- ``kasan.fault=report`` or ``=panic`` - only print KASAN report or also panic
(default: ``report``)
If ``kasan.mode`` parameter is not provided, it defaults to ``full`` when
``CONFIG_DEBUG_KERNEL`` is enabled, and to ``prod`` otherwise.
- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN
report or also panic the kernel (default: ``report``).
For developers
~~~~~~~~~~~~~~

57
Documentation/dev-tools/kunit/usage.rst
View File

@ -522,6 +522,63 @@ There's more boilerplate involved, but it can:
* E.g. if we wanted to also test ``sha256sum``, we could add a ``sha256``
field and reuse ``cases``.
* be converted to a "parameterized test", see below.
Parameterized Testing
~~~~~~~~~~~~~~~~~~~~~
The table-driven testing pattern is common enough that KUnit has special
support for it.
Reusing the same ``cases`` array from above, we can write the test as a
"parameterized test" with the following.
.. code-block:: c
// This is copy-pasted from above.
struct sha1_test_case {
const char *str;
const char *sha1;
};
struct sha1_test_case cases[] = {
{
.str = "hello world",
.sha1 = "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed",
},
{
.str = "hello world!",
.sha1 = "430ce34d020724ed75a196dfc2ad67c77772d169",
},
};
// Need a helper function to generate a name for each test case.
static void case_to_desc(const struct sha1_test_case *t, char *desc)
{
strcpy(desc, t->str);
}
// Creates `sha1_gen_params()` to iterate over `cases`.
KUNIT_ARRAY_PARAM(sha1, cases, case_to_desc);
// Looks no different from a normal test.
static void sha1_test(struct kunit *test)
{
// This function can just contain the body of the for-loop.
// The former `cases[i]` is accessible under test->param_value.
char out[40];
struct sha1_test_case *test_param = (struct sha1_test_case *)(test->param_value);
sha1sum(test_param->str, out);
KUNIT_EXPECT_STREQ_MSG(test, (char *)out, test_param->sha1,
"sha1sum(%s)", test_param->str);
}
// Instead of KUNIT_CASE, we use KUNIT_CASE_PARAM and pass in the
// function declared by KUNIT_ARRAY_PARAM.
static struct kunit_case sha1_test_cases[] = {
KUNIT_CASE_PARAM(sha1_test, sha1_gen_params),
{}
};
.. _kunit-on-non-uml:
KUnit on non-UML architectures

1
Documentation/devicetree/bindings/arm/cpus.yaml
View File

@ -232,7 +232,6 @@ properties:
by this cpu (see ./idle-states.yaml).
capacity-dmips-mhz:
$ref: '/schemas/types.yaml#/definitions/uint32'
description:
u32 value representing CPU capacity (see ./cpu-capacity.txt) in
DMIPS/MHz, relative to highest capacity-dmips-mhz

2
Documentation/devicetree/bindings/display/bridge/sii902x.txt
View File

@ -40,7 +40,7 @@ Optional properties:
documents on how to describe the way the sii902x device is
connected to the rest of the audio system:
Documentation/devicetree/bindings/sound/simple-card.yaml
Documentation/devicetree/bindings/sound/audio-graph-card.txt
Documentation/devicetree/bindings/sound/audio-graph-card.yaml
Note: In case of the audio-graph-card binding the used port
index should be 3.

4
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
View File

@ -23,7 +23,7 @@ connected to.
For a description of the display interface sink function blocks, see
Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt and
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt.
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml.
Required properties (all function blocks):
- compatible: "mediatek,<chip>-disp-<function>", one of
@ -61,7 +61,7 @@ Required properties (DMA function blocks):
"mediatek,<chip>-disp-wdma"
the supported chips are mt2701, mt8167 and mt8173.
- larb: Should contain a phandle pointing to the local arbiter device as defined
in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
- iommus: Should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
for details.

4
Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
View File

@ -1,4 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 Texas Instruments Incorporated
# Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/ti/k3-bcdma.yaml#
@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments K3 DMSS BCDMA Device Tree Bindings
maintainers:
- Peter Ujfalusi <peter.ujfalusi@ti.com>
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
description: |
The Block Copy DMA (BCDMA) is intended to perform similar functions as the TR

4
Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
View File

@ -1,4 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 Texas Instruments Incorporated
# Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/ti/k3-pktdma.yaml#
@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments K3 DMSS PKTDMA Device Tree Bindings
maintainers:
- Peter Ujfalusi <peter.ujfalusi@ti.com>
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
description: |
The Packet DMA (PKTDMA) is intended to perform similar functions as the packet

4
Documentation/devicetree/bindings/dma/ti/k3-udma.yaml
View File

@ -1,4 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2019 Texas Instruments Incorporated
# Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/ti/k3-udma.yaml#
@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments K3 NAVSS Unified DMA Device Tree Bindings
maintainers:
- Peter Ujfalusi <peter.ujfalusi@ti.com>
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
description: |
The UDMA-P is intended to perform similar (but significantly upgraded)

1
Documentation/devicetree/bindings/extcon/wlf,arizona.yaml
View File

@ -85,7 +85,6 @@ properties:
wlf,micd-timeout-ms:
description:
Timeout for microphone detection, specified in milliseconds.
$ref: "/schemas/types.yaml#/definitions/uint32"
wlf,micd-force-micbias:
description:

1
Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml
View File

@ -49,7 +49,6 @@ properties:
description:
This property controls the Accumulation Dead band which allows to set the
level of current below which no accumulation takes place.
$ref: /schemas/types.yaml#/definitions/uint32
maximum: 255
default: 0

8
Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml
View File

@ -73,11 +73,9 @@ properties:
description: |
Temperature sensor trimming factor. It can be used to manually adjust the
temperature measurements within 7.130 degrees Celsius.
maxItems: 1
items:
default: 0
minimum: 0
maximum: 7130
default: 0
minimum: 0
maximum: 7130
additionalProperties: false

1
Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml
View File

@ -52,7 +52,6 @@ properties:
ti,bus-range-microvolt:
description: |
This is the operating range of the bus voltage in microvolt
$ref: /schemas/types.yaml#/definitions/uint32
enum: [16000000, 32000000]
default: 32000000

2
Documentation/devicetree/bindings/i2c/i2c-gpio.yaml
View File

@ -39,11 +39,9 @@ properties:
i2c-gpio,delay-us:
description: delay between GPIO operations (may depend on each platform)
$ref: /schemas/types.yaml#/definitions/uint32
i2c-gpio,timeout-ms:
description: timeout to get data
$ref: /schemas/types.yaml#/definitions/uint32
# Deprecated properties, do not use in new device tree sources:
gpios:

3
Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
View File

@ -66,21 +66,18 @@ properties:
default: 400000
i2c-sda-hold-time-ns:
maxItems: 1
description: |
The property should contain the SDA hold time in nanoseconds. This option
is only supported in hardware blocks version 1.11a or newer or on
Microsemi SoCs.
i2c-scl-falling-time-ns:
maxItems: 1
description: |
The property should contain the SCL falling time in nanoseconds.
This value is used to compute the tLOW period.
default: 300
i2c-sda-falling-time-ns:
maxItems: 1
description: |
The property should contain the SDA falling time in nanoseconds.
This value is used to compute the tHIGH period.

4
Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml
View File

@ -16,8 +16,8 @@ description:
properties:
compatible:
enum:
- bosch,bmc150
- bosch,bmi055
- bosch,bmc150_accel
- bosch,bmi055_accel
- bosch,bma255
- bosch,bma250e
- bosch,bma222

2
Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
View File

@ -80,7 +80,7 @@ properties:
type: boolean
bipolar:
description: see Documentation/devicetree/bindings/iio/adc/adc.txt
description: see Documentation/devicetree/bindings/iio/adc/adc.yaml
type: boolean
required:

1
Documentation/devicetree/bindings/iio/adc/maxim,max9611.yaml
View File

@ -23,7 +23,6 @@ properties:
maxItems: 1
shunt-resistor-micro-ohms:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
Value in micro Ohms of the shunt resistor connected between the RS+ and
RS- inputs, across which the current is measured. Value needed to compute

1
Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
View File

@ -246,7 +246,6 @@ patternProperties:
Resolution (bits) to use for conversions:
- can be 6, 8, 10 or 12 on stm32f4
- can be 8, 10, 12, 14 or 16 on stm32h7 and stm32mp1
$ref: /schemas/types.yaml#/definitions/uint32
st,adc-channels:
description: |

2
Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml
View File

@ -42,7 +42,6 @@ properties:
const: 1
ti,channel0-current-microamp:
$ref: /schemas/types.yaml#/definitions/uint32
description: Channel 0 current in uA.
enum:
- 0
@ -51,7 +50,6 @@ properties:
- 20
ti,channel3-current-microamp:
$ref: /schemas/types.yaml#/definitions/uint32
description: Channel 3 current in uA.
enum:
- 0

41
Documentation/devicetree/bindings/iio/dac/adi,ad5758.yaml
View File

@ -46,31 +46,42 @@ properties:
two properties must be present:
adi,range-microvolt:
$ref: /schemas/types.yaml#/definitions/int32-array
description: |
Voltage output range specified as <minimum, maximum>
enum:
- [[0, 5000000]]
- [[0, 10000000]]
- [[-5000000, 5000000]]
- [[-10000000, 10000000]]
oneOf:
- items:
- const: 0
- enum: [5000000, 10000000]
- items:
- const: -5000000
- const: 5000000
- items:
- const: -10000000
- const: 10000000
adi,range-microamp:
$ref: /schemas/types.yaml#/definitions/int32-array
description: |
Current output range specified as <minimum, maximum>
enum:
- [[0, 20000]]
- [[0, 24000]]
- [[4, 24000]]
- [[-20000, 20000]]
- [[-24000, 24000]]
- [[-1000, 22000]]
oneOf:
- items:
- const: 0
- enum: [20000, 24000]
- items:
- const: 4
- const: 24000
- items:
- const: -20000
- const: 20000
- items:
- const: -24000
- const: 24000
- items:
- const: -1000
- const: 22000
reset-gpios: true
adi,dc-dc-ilim-microamp:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [150000, 200000, 250000, 300000, 350000, 400000]
description: |
The dc-to-dc converter current limit.

1
Documentation/devicetree/bindings/iio/health/maxim,max30100.yaml
View File

@ -21,7 +21,6 @@ properties:
description: Connected to ADC_RDY pin.
maxim,led-current-microamp:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 2
maxItems: 2
description: |

22
Documentation/devicetree/bindings/input/adc-keys.txt
View File

@ -5,7 +5,8 @@ Required properties:
- compatible: "adc-keys"
- io-channels: Phandle to an ADC channel
- io-channel-names = "buttons";
- keyup-threshold-microvolt: Voltage at which all the keys are considered up.
- keyup-threshold-microvolt: Voltage above or equal to which all the keys are
considered up.
Optional properties:
- poll-interval: Poll interval time in milliseconds
@ -17,7 +18,12 @@ Each button (key) is represented as a sub-node of "adc-keys":
Required subnode-properties:
- label: Descriptive name of the key.
- linux,code: Keycode to emit.
- press-threshold-microvolt: Voltage ADC input when this key is pressed.
- press-threshold-microvolt: voltage above or equal to which this key is
considered pressed.
No two values of press-threshold-microvolt may be the same.
All values of press-threshold-microvolt must be less than
keyup-threshold-microvolt.
Example:
@ -47,3 +53,15 @@ Example:
press-threshold-microvolt = <500000>;
};
};
+--------------------------------+------------------------+
| 2.000.000 <= value | no key pressed |
+--------------------------------+------------------------+
| 1.500.000 <= value < 2.000.000 | KEY_VOLUMEUP pressed |
+--------------------------------+------------------------+
| 1.000.000 <= value < 1.500.000 | KEY_VOLUMEDOWN pressed |
+--------------------------------+------------------------+
| 500.000 <= value < 1.000.000 | KEY_ENTER pressed |
+--------------------------------+------------------------+
| value < 500.000 | no key pressed |
+--------------------------------+------------------------+

1
Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
View File

@ -26,6 +26,7 @@ properties:
- goodix,gt927
- goodix,gt9271
- goodix,gt928
- goodix,gt9286
- goodix,gt967
reg:

2
Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
View File

@ -70,11 +70,9 @@ properties:
touchscreen-x-mm:
description: horizontal length in mm of the touchscreen
$ref: /schemas/types.yaml#/definitions/uint32
touchscreen-y-mm:
description: vertical length in mm of the touchscreen
$ref: /schemas/types.yaml#/definitions/uint32
dependencies:
touchscreen-size-x: [ touchscreen-size-y ]

111
Documentation/devicetree/bindings/leds/richtek,rt8515.yaml Normal file
View File

@ -0,0 +1,111 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/richtek,rt8515.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Richtek RT8515 1.5A dual channel LED driver
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |
The Richtek RT8515 is a dual channel (two mode) LED driver that
supports driving a white LED in flash or torch mode. The maximum
current for each mode is defined in hardware using two resistors
RFS and RTS.
properties:
compatible:
const: richtek,rt8515
enf-gpios:
maxItems: 1
description: A connection to the 'ENF' (enable flash) pin.
ent-gpios:
maxItems: 1
description: A connection to the 'ENT' (enable torch) pin.
richtek,rfs-ohms:
minimum: 7680
maximum: 367000
description: The resistance value of the RFS resistor. This
resistors limits the maximum flash current. This must be set
for the property flash-max-microamp to work, the RFS resistor
defines the range of the dimmer setting (brightness) of the
flash LED.
richtek,rts-ohms:
minimum: 7680
maximum: 367000
description: The resistance value of the RTS resistor. This
resistors limits the maximum torch current. This must be set
for the property torch-max-microamp to work, the RTS resistor
defines the range of the dimmer setting (brightness) of the
torch LED.
led:
type: object
$ref: common.yaml#
properties:
function: true
color: true
flash-max-timeout-us: true
flash-max-microamp:
maximum: 700000
description: The maximum current for flash mode
is hardwired to the component using the RFS resistor to
ground. The maximum hardware current setting is calculated
according to the formula Imax = 5500 / RFS. The lowest
allowed resistance value is 7.86 kOhm giving an absolute
maximum current of 700mA. By setting this attribute in
the device tree, you can further restrict the maximum
current below the hardware limit. This requires the RFS
to be defined as it defines the maximum range.
led-max-microamp:
maximum: 700000
description: The maximum current for torch mode
is hardwired to the component using the RTS resistor to
ground. The maximum hardware current setting is calculated
according to the formula Imax = 5500 / RTS. The lowest
allowed resistance value is 7.86 kOhm giving an absolute
maximum current of 700mA. By setting this attribute in
the device tree, you can further restrict the maximum
current below the hardware limit. This requires the RTS
to be defined as it defines the maximum range.
additionalProperties: false
required:
- compatible
- ent-gpios
- enf-gpios
- led
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/leds/common.h>
led-controller {
compatible = "richtek,rt8515";
enf-gpios = <&gpio4 12 GPIO_ACTIVE_HIGH>;
ent-gpios = <&gpio4 13 GPIO_ACTIVE_HIGH>;
richtek,rfs-ohms = <16000>;
richtek,rts-ohms = <100000>;
led {
function = LED_FUNCTION_FLASH;
color = <LED_COLOR_ID_WHITE>;
flash-max-timeout-us = <250000>;
flash-max-microamp = <150000>;
led-max-microamp = <25000>;
};
};
...

2
Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
View File

@ -16,7 +16,7 @@ Required properties:
- power-domains: a phandle to the power domain, see
Documentation/devicetree/bindings/power/power_domain.txt for details.
- mediatek,larb: must contain the local arbiters in the current Socs, see
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
for details.
- iommus: should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt

2
Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
View File

@ -14,7 +14,7 @@ Required properties:
- power-domains: a phandle to the power domain, see
Documentation/devicetree/bindings/power/power_domain.txt for details.
- mediatek,larb: must contain the local arbiters in the current SoCs, see
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
for details.
- iommus: should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt

2
Documentation/devicetree/bindings/media/mediatek-mdp.txt
View File

@ -28,7 +28,7 @@ Required properties (DMA function blocks, child node):
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
for details.
- mediatek,larb: must contain the local arbiters in the current Socs, see
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
for details.
Example:

1
Documentation/devicetree/bindings/mmc/mmc-controller.yaml
View File

@ -259,7 +259,6 @@ properties:
waiting for I/O signalling and card power supply to be stable,
regardless of whether pwrseq-simple is used. Default to 10ms if
no available.
$ref: /schemas/types.yaml#/definitions/uint32
default: 10
supports-cqe:

2
Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml
View File

@ -41,13 +41,11 @@ properties:
description:
Delay in ms after powering the card and de-asserting the
reset-gpios (if any).
$ref: /schemas/types.yaml#/definitions/uint32
power-off-delay-us:
description:
Delay in us after asserting the reset-gpios (if any)
during power off of the card.
$ref: /schemas/types.yaml#/definitions/uint32
required:
- compatible

2
Documentation/devicetree/bindings/net/ethernet-controller.yaml
View File

@ -122,7 +122,6 @@ properties:
such as flow control thresholds.
rx-internal-delay-ps:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
RGMII Receive Clock Delay defined in pico seconds.
This is used for controllers that have configurable RX internal delays.
@ -140,7 +139,6 @@ properties:
is used for components that can have configurable fifo sizes.
tx-internal-delay-ps:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
RGMII Transmit Clock Delay defined in pico seconds.
This is used for controllers that have configurable TX internal delays.

1
Documentation/devicetree/bindings/net/renesas,etheravb.yaml
View File

@ -163,6 +163,7 @@ allOf:
enum:
- renesas,etheravb-r8a774a1
- renesas,etheravb-r8a774b1
- renesas,etheravb-r8a774e1
- renesas,etheravb-r8a7795
- renesas,etheravb-r8a7796
- renesas,etheravb-r8a77961

9
Documentation/devicetree/bindings/net/snps,dwmac.yaml
View File

@ -161,7 +161,8 @@ properties:
* snps,route-dcbcp, DCB Control Packets
* snps,route-up, Untagged Packets
* snps,route-multi-broad, Multicast & Broadcast Packets
* snps,priority, RX queue priority (Range 0x0 to 0xF)
* snps,priority, bitmask of the tagged frames priorities assigned to
the queue
snps,mtl-tx-config:
$ref: /schemas/types.yaml#/definitions/phandle
@ -188,7 +189,10 @@ properties:
* snps,idle_slope, unlock on WoL
* snps,high_credit, max write outstanding req. limit
* snps,low_credit, max read outstanding req. limit
* snps,priority, TX queue priority (Range 0x0 to 0xF)
* snps,priority, bitmask of the priorities assigned to the queue.
When a PFC frame is received with priorities matching the bitmask,
the queue is blocked from transmitting for the pause time specified
in the PFC frame.
snps,reset-gpio:
deprecated: true
@ -208,7 +212,6 @@ properties:
Triplet of delays. The 1st cell is reset pre-delay in micro
seconds. The 2nd cell is reset pulse in micro seconds. The 3rd
cell is reset post-delay in micro seconds.
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 3
maxItems: 3

3
Documentation/devicetree/bindings/power/supply/battery.yaml
View File

@ -83,21 +83,18 @@ properties:
for each of the battery capacity lookup table.
operating-range-celsius:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: operating temperature range of a battery
items:
- description: minimum temperature at which battery can operate
- description: maximum temperature at which battery can operate
ambient-celsius:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: safe range of ambient temperature
items:
- description: alert when ambient temperature is lower than this value
- description: alert when ambient temperature is higher than this value
alert-celsius:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: safe range of battery temperature
items:
- description: alert when battery temperature is lower than this value

1
Documentation/devicetree/bindings/power/supply/bq2515x.yaml
View File

@ -50,7 +50,6 @@ properties:
maxItems: 1
input-current-limit-microamp:
$ref: /schemas/types.yaml#/definitions/uint32
description: Maximum input current in micro Amps.
minimum: 50000
maximum: 500000

1
Documentation/devicetree/bindings/regulator/dlg,da9121.yaml
View File

@ -62,7 +62,6 @@ properties:
description: IRQ line information.
dlg,irq-polling-delay-passive-ms:
$ref: "/schemas/types.yaml#/definitions/uint32"
minimum: 1000
maximum: 10000
description: |

2
Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
View File

@ -72,11 +72,9 @@ properties:
startup-delay-us:
description: startup time in microseconds
$ref: /schemas/types.yaml#/definitions/uint32
off-on-delay-us:
description: off delay time in microseconds
$ref: /schemas/types.yaml#/definitions/uint32
enable-active-high:
description:

6
Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml
View File

@ -19,7 +19,9 @@ description: |
properties:
compatible:
enum:
- nxp,pf8x00
- nxp,pf8100
- nxp,pf8121a
- nxp,pf8200
reg:
maxItems: 1
@ -118,7 +120,7 @@ examples:
#size-cells = <0>;
pmic@8 {
compatible = "nxp,pf8x00";
compatible = "nxp,pf8100";
reg = <0x08>;
regulators {

1
Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
View File

@ -44,6 +44,7 @@ First Level Nodes - PMIC
Definition: Must be one of below:
"qcom,pm8005-rpmh-regulators"
"qcom,pm8009-rpmh-regulators"
"qcom,pm8009-1-rpmh-regulators"
"qcom,pm8150-rpmh-regulators"
"qcom,pm8150l-rpmh-regulators"
"qcom,pm8350-rpmh-regulators"

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

@ -27,7 +27,6 @@ properties:
1: chargeable
quartz-load-femtofarads:
$ref: /schemas/types.yaml#/definitions/uint32
description:
The capacitive load of the quartz(x-tal), expressed in femto
Farad (fF). The default value shall be listed (if optional),
@ -47,7 +46,6 @@ properties:
deprecated: true
trickle-resistor-ohms:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Selected resistor for trickle charger. Should be given
if trickle charger should be enabled.

2
Documentation/devicetree/bindings/serial/pl011.yaml
View File

@ -88,14 +88,12 @@ properties:
description:
Rate at which poll occurs when auto-poll is set.
default 100ms.
$ref: /schemas/types.yaml#/definitions/uint32
default: 100
poll-timeout-ms:
description:
Poll timeout when auto-poll is set, default
3000ms.
$ref: /schemas/types.yaml#/definitions/uint32
default: 3000
required:

4
Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml
View File

@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Mediatek MT8192 with MT6359, RT1015 and RT5682 ASoC sound card driver
maintainers:
- Jiaxin Yu <jiaxin.yu@mediatek.com>
- Shane Chien <shane.chien@mediatek.com>
- Jiaxin Yu <jiaxin.yu@mediatek.com>
- Shane Chien <shane.chien@mediatek.com>
description:
This binding describes the MT8192 sound card.

2
Documentation/devicetree/bindings/sound/sgtl5000.yaml
View File

@ -41,14 +41,12 @@ properties:
values of 2k, 4k or 8k. If set to 0 it will be off. If this node is not
mentioned or if the value is unknown, then micbias resistor is set to
4k.
$ref: "/schemas/types.yaml#/definitions/uint32"
enum: [ 0, 2, 4, 8 ]
micbias-voltage-m-volts:
description: The bias voltage to be used in mVolts. The voltage can take
values from 1.25V to 3V by 250mV steps. If this node is not mentioned
or the value is unknown, then the value is set to 1.25V.
$ref: "/schemas/types.yaml#/definitions/uint32"
enum: [ 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000 ]
lrclk-strength:

4
Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml
View File

@ -1,4 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 Texas Instruments Incorporated
# Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
%YAML 1.2
---
$id: http://devicetree.org/schemas/sound/ti,j721e-cpb-audio.yaml#
@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments J721e Common Processor Board Audio Support
maintainers:
- Peter Ujfalusi <peter.ujfalusi@ti.com>
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
description: |
The audio support on the board is using pcm3168a codec connected to McASP10

4
Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml
View File

@ -1,4 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2020 Texas Instruments Incorporated
# Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
%YAML 1.2
---
$id: http://devicetree.org/schemas/sound/ti,j721e-cpb-ivi-audio.yaml#
@ -7,7 +9,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments J721e Common Processor Board Audio Support
maintainers:
- Peter Ujfalusi <peter.ujfalusi@ti.com>
- Peter Ujfalusi <peter.ujfalusi@gmail.com>
description: |
The Infotainment board plugs into the Common Processor Board, the support of the

10
Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml
View File

@ -11,12 +11,18 @@ maintainers:
properties:
compatible:
items:
oneOf:
- const: ti,j721e-usb
- const: ti,am64-usb
- items:
- const: ti,j721e-usb
- const: ti,am64-usb
reg:
description: module registers
ranges: true
power-domains:
description:
PM domain provider node and an args specifier containing
@ -58,6 +64,8 @@ properties:
'#size-cells':
const: 2
dma-coherent: true
patternProperties:
"^usb@":
type: object

1
Documentation/devicetree/bindings/watchdog/watchdog.yaml
View File

@ -19,7 +19,6 @@ properties:
pattern: "^watchdog(@.*|-[0-9a-f])?$"
timeout-sec:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Contains the watchdog timeout in seconds.

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

@ -48,12 +48,12 @@ or ``virtualenv``, depending on how your distribution packaged Python 3.
those versions, you should run ``pip install 'docutils==0.12'``.
#) It is recommended to use the RTD theme for html output. Depending
on the Sphinx version, it should be installed in separate,
on the Sphinx version, it should be installed separately,
with ``pip install sphinx_rtd_theme``.
#) Some ReST pages contain math expressions. Due to the way Sphinx work,
#) Some ReST pages contain math expressions. Due to the way Sphinx works,
those expressions are written using LaTeX notation. It needs texlive
installed with amdfonts and amsmath in order to evaluate them.
installed with amsfonts and amsmath in order to evaluate them.
In summary, if you want to install Sphinx version 1.7.9, you should do::
@ -128,7 +128,7 @@ Sphinx Build
============
The usual way to generate the documentation is to run ``make htmldocs`` or
``make pdfdocs``. There are also other formats available, see the documentation
``make pdfdocs``. There are also other formats available: see the documentation
section of ``make help``. The generated documentation is placed in
format-specific subdirectories under ``Documentation/output``.
@ -303,17 +303,17 @@ and *targets* (e.g. a ref to ``:ref:`last row <last row>``` / :ref:`last row
- head col 3
- head col 4
* - column 1
* - row 1
- field 1.1
- field 1.2 with autospan
* - column 2
* - row 2
- field 2.1
- :rspan:`1` :cspan:`1` field 2.2 - 3.3
* .. _`last row`:
- column 3
- row 3
Rendered as:
@ -325,17 +325,17 @@ Rendered as:
- head col 3
- head col 4
* - column 1
* - row 1
- field 1.1
- field 1.2 with autospan
* - column 2
* - row 2
- field 2.1
- :rspan:`1` :cspan:`1` field 2.2 - 3.3
* .. _`last row`:
- column 3
- row 3
Cross-referencing
-----------------
@ -361,7 +361,7 @@ Figures & Images
If you want to add an image, you should use the ``kernel-figure`` and
``kernel-image`` directives. E.g. to insert a figure with a scalable
image format use SVG (:ref:`svg_image_example`)::
image format, use SVG (:ref:`svg_image_example`)::
.. kernel-figure:: svg_image.svg
:alt: simple SVG image
@ -375,7 +375,7 @@ image format use SVG (:ref:`svg_image_example`)::
SVG image example
The kernel figure (and image) directive support **DOT** formatted files, see
The kernel figure (and image) directive supports **DOT** formatted files, see
* DOT: http://graphviz.org/pdf/dotguide.pdf
* Graphviz: http://www.graphviz.org/content/dot-language
@ -394,7 +394,7 @@ A simple example (:ref:`hello_dot_file`)::
DOT's hello world example
Embed *render* markups (or languages) like Graphviz's **DOT** is provided by the
Embedded *render* markups (or languages) like Graphviz's **DOT** are provided by the
``kernel-render`` directives.::
.. kernel-render:: DOT
@ -406,7 +406,7 @@ Embed *render* markups (or languages) like Graphviz's **DOT** is provided by the
}
How this will be rendered depends on the installed tools. If Graphviz is
installed, you will see an vector image. If not the raw markup is inserted as
installed, you will see a vector image. If not, the raw markup is inserted as
*literal-block* (:ref:`hello_dot_render`).
.. _hello_dot_render:
@ -421,8 +421,8 @@ installed, you will see an vector image. If not the raw markup is inserted as
The *render* directive has all the options known from the *figure* directive,
plus option ``caption``. If ``caption`` has a value, a *figure* node is
inserted. If not, a *image* node is inserted. A ``caption`` is also needed, if
you want to refer it (:ref:`hello_svg_render`).
inserted. If not, an *image* node is inserted. A ``caption`` is also needed, if
you want to refer to it (:ref:`hello_svg_render`).
Embedded **SVG**::

8
Documentation/filesystems/overlayfs.rst
View File

@ -586,6 +586,14 @@ without significant effort.
The advantage of mounting with the "volatile" option is that all forms of
sync calls to the upper filesystem are omitted.
In order to avoid a giving a false sense of safety, the syncfs (and fsync)
semantics of volatile mounts are slightly different than that of the rest of
VFS. If any writeback error occurs on the upperdir's filesystem after a
volatile mount takes place, all sync functions will return an error. Once this
condition is reached, the filesystem will not recover, and every subsequent sync
call will return an error, even if the upperdir has not experience a new error
since the last sync call.
When overlay is mounted with "volatile" option, the directory
"$workdir/work/incompat/volatile" is created. During next mount, overlay
checks for this directory and refuses to mount if present. This is a strong

4
Documentation/firmware-guide/acpi/apei/einj.rst
View File

@ -50,8 +50,8 @@ The following files belong to it:
0x00000010 Memory Uncorrectable non-fatal
0x00000020 Memory Uncorrectable fatal
0x00000040 PCI Express Correctable
0x00000080 PCI Express Uncorrectable fatal
0x00000100 PCI Express Uncorrectable non-fatal
0x00000080 PCI Express Uncorrectable non-fatal
0x00000100 PCI Express Uncorrectable fatal
0x00000200 Platform Correctable
0x00000400 Platform Uncorrectable non-fatal
0x00000800 Platform Uncorrectable fatal

2
Documentation/hwmon/sbtsi_temp.rst
View File

@ -1,7 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0-or-later
Kernel driver sbtsi_temp
==================
========================
Supported hardware:

47
Documentation/kbuild/gcc-plugins.rst
View File

@ -11,16 +11,13 @@ compiler [1]_. They are useful for runtime instrumentation and static analysis.
We can analyse, change and add further code during compilation via
callbacks [2]_, GIMPLE [3]_, IPA [4]_ and RTL passes [5]_.
The GCC plugin infrastructure of the kernel supports all gcc versions from
4.5 to 6.0, building out-of-tree modules, cross-compilation and building in a
separate directory.
Plugin source files have to be compilable by both a C and a C++ compiler as well
because gcc versions 4.5 and 4.6 are compiled by a C compiler,
gcc-4.7 can be compiled by a C or a C++ compiler,
and versions 4.8+ can only be compiled by a C++ compiler.
The GCC plugin infrastructure of the kernel supports building out-of-tree
modules, cross-compilation and building in a separate directory.
Plugin source files have to be compilable by a C++ compiler.
Currently the GCC plugin infrastructure supports only the x86, arm, arm64 and
powerpc architectures.
Currently the GCC plugin infrastructure supports only some architectures.
Grep "select HAVE_GCC_PLUGINS" to find out which architectures support
GCC plugins.
This infrastructure was ported from grsecurity [6]_ and PaX [7]_.
@ -47,20 +44,13 @@ Files
This is a compatibility header for GCC plugins.
It should be always included instead of individual gcc headers.
**$(src)/scripts/gcc-plugin.sh**
This script checks the availability of the included headers in
gcc-common.h and chooses the proper host compiler to build the plugins
(gcc-4.7 can be built by either gcc or g++).
**$(src)/scripts/gcc-plugins/gcc-generate-gimple-pass.h,
$(src)/scripts/gcc-plugins/gcc-generate-ipa-pass.h,
$(src)/scripts/gcc-plugins/gcc-generate-simple_ipa-pass.h,
$(src)/scripts/gcc-plugins/gcc-generate-rtl-pass.h**
These headers automatically generate the registration structures for
GIMPLE, SIMPLE_IPA, IPA and RTL passes. They support all gcc versions
from 4.5 to 6.0.
GIMPLE, SIMPLE_IPA, IPA and RTL passes.
They should be preferred to creating the structures by hand.
@ -68,21 +58,25 @@ Usage
=====
You must install the gcc plugin headers for your gcc version,
e.g., on Ubuntu for gcc-4.9::
e.g., on Ubuntu for gcc-10::
apt-get install gcc-4.9-plugin-dev
apt-get install gcc-10-plugin-dev
Or on Fedora::
dnf install gcc-plugin-devel
Enable a GCC plugin based feature in the kernel config::
Enable the GCC plugin infrastructure and some plugin(s) you want to use
in the kernel config::
CONFIG_GCC_PLUGIN_CYC_COMPLEXITY = y
CONFIG_GCC_PLUGINS=y
CONFIG_GCC_PLUGIN_CYC_COMPLEXITY=y
CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y
...
To compile only the plugin(s)::
To compile the minimum tool set including the plugin(s)::
make gcc-plugins
make scripts
or just run the kernel make and compile the whole kernel with
the cyclomatic complexity GCC plugin.
@ -91,7 +85,8 @@ the cyclomatic complexity GCC plugin.
4. How to add a new GCC plugin
==============================
The GCC plugins are in $(src)/scripts/gcc-plugins/. You can use a file or a directory
here. It must be added to $(src)/scripts/gcc-plugins/Makefile,
$(src)/scripts/Makefile.gcc-plugins and $(src)/arch/Kconfig.
The GCC plugins are in scripts/gcc-plugins/. You need to put plugin source files
right under scripts/gcc-plugins/. Creating subdirectories is not supported.
It must be added to scripts/gcc-plugins/Makefile, scripts/Makefile.gcc-plugins
and a relevant Kconfig file.
See the cyc_complexity_plugin.c (CONFIG_GCC_PLUGIN_CYC_COMPLEXITY) GCC plugin.

44
Documentation/kbuild/llvm.rst
View File

@ -63,6 +63,50 @@ They can be enabled individually. The full list of the parameters: ::
Currently, the integrated assembler is disabled by default. You can pass
``LLVM_IAS=1`` to enable it.
Supported Architectures
-----------------------
LLVM does not target all of the architectures that Linux supports and
just because a target is supported in LLVM does not mean that the kernel
will build or work without any issues. Below is a general summary of
architectures that currently work with ``CC=clang`` or ``LLVM=1``. Level
of support corresponds to "S" values in the MAINTAINERS files. If an
architecture is not present, it either means that LLVM does not target
it or there are known issues. Using the latest stable version of LLVM or
even the development tree will generally yield the best results.
An architecture's ``defconfig`` is generally expected to work well,
certain configurations may have problems that have not been uncovered
yet. Bug reports are always welcome at the issue tracker below!
.. list-table::
:widths: 10 10 10
:header-rows: 1
* - Architecture
- Level of support
- ``make`` command
* - arm
- Supported
- ``LLVM=1``
* - arm64
- Supported
- ``LLVM=1``
* - mips
- Maintained
- ``CC=clang``
* - powerpc
- Maintained
- ``CC=clang``
* - riscv
- Maintained
- ``CC=clang``
* - s390
- Maintained
- ``CC=clang``
* - x86
- Supported
- ``LLVM=1``
Getting Help
------------

4
Documentation/kbuild/makefiles.rst
View File

@ -598,7 +598,7 @@ more details, with real examples.
explicitly added to $(targets).
Assignments to $(targets) are without $(obj)/ prefix. if_changed may be
used in conjunction with custom rules as defined in "3.9 Custom Rules".
used in conjunction with custom rules as defined in "3.11 Custom Rules".
Note: It is a typical mistake to forget the FORCE prerequisite.
Another common pitfall is that whitespace is sometimes significant; for
@ -755,7 +755,7 @@ more details, with real examples.
bits on the scripts nonetheless.
Kbuild provides variables $(CONFIG_SHELL), $(AWK), $(PERL),
$(PYTHON) and $(PYTHON3) to refer to interpreters for the respective
and $(PYTHON3) to refer to interpreters for the respective
scripts.
Example::

8
Documentation/kernel-hacking/locking.rst
View File

@ -118,11 +118,11 @@ spinlock, but you may block holding a mutex. If you can't lock a mutex,
your task will suspend itself, and be woken up when the mutex is
released. This means the CPU can do something else while you are
waiting. There are many cases when you simply can't sleep (see
`What Functions Are Safe To Call From Interrupts? <#sleeping-things>`__),
`What Functions Are Safe To Call From Interrupts?`_),
and so have to use a spinlock instead.
Neither type of lock is recursive: see
`Deadlock: Simple and Advanced <#deadlock>`__.
`Deadlock: Simple and Advanced`_.
Locks and Uniprocessor Kernels
------------------------------
@ -179,7 +179,7 @@ perfect world).
Note that you can also use spin_lock_irq() or
spin_lock_irqsave() here, which stop hardware interrupts
as well: see `Hard IRQ Context <#hard-irq-context>`__.
as well: see `Hard IRQ Context`_.
This works perfectly for UP as well: the spin lock vanishes, and this
macro simply becomes local_bh_disable()
@ -230,7 +230,7 @@ The Same Softirq
~~~~~~~~~~~~~~~~
The same softirq can run on the other CPUs: you can use a per-CPU array
(see `Per-CPU Data <#per-cpu-data>`__) for better performance. If you're
(see `Per-CPU Data`_) for better performance. If you're
going so far as to use a softirq, you probably care about scalable
performance enough to justify the extra complexity.

62
Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst
View File

@ -164,46 +164,56 @@ Devlink health reporters
NPA Reporters
-------------
The NPA reporters are responsible for reporting and recovering the following group of errors
The NPA reporters are responsible for reporting and recovering the following group of errors:
1. GENERAL events
- Error due to operation of unmapped PF.
- Error due to disabled alloc/free for other HW blocks (NIX, SSO, TIM, DPI and AURA).
2. ERROR events
- Fault due to NPA_AQ_INST_S read or NPA_AQ_RES_S write.
- AQ Doorbell Error.
3. RAS events
- RAS Error Reporting for NPA_AQ_INST_S/NPA_AQ_RES_S.
4. RVU events
- Error due to unmapped slot.
Sample Output
-------------
~# devlink health
pci/0002:01:00.0:
reporter hw_npa_intr
state healthy error 2872 recover 2872 last_dump_date 2020-12-10 last_dump_time 09:39:09 grace_period 0 auto_recover true auto_dump true
reporter hw_npa_gen
state healthy error 2872 recover 2872 last_dump_date 2020-12-11 last_dump_time 04:43:04 grace_period 0 auto_recover true auto_dump true
reporter hw_npa_err
state healthy error 2871 recover 2871 last_dump_date 2020-12-10 last_dump_time 09:39:17 grace_period 0 auto_recover true auto_dump true
reporter hw_npa_ras
state healthy error 0 recover 0 last_dump_date 2020-12-10 last_dump_time 09:32:40 grace_period 0 auto_recover true auto_dump true
Sample Output::
~# devlink health
pci/0002:01:00.0:
reporter hw_npa_intr
state healthy error 2872 recover 2872 last_dump_date 2020-12-10 last_dump_time 09:39:09 grace_period 0 auto_recover true auto_dump true
reporter hw_npa_gen
state healthy error 2872 recover 2872 last_dump_date 2020-12-11 last_dump_time 04:43:04 grace_period 0 auto_recover true auto_dump true
reporter hw_npa_err
state healthy error 2871 recover 2871 last_dump_date 2020-12-10 last_dump_time 09:39:17 grace_period 0 auto_recover true auto_dump true
reporter hw_npa_ras
state healthy error 0 recover 0 last_dump_date 2020-12-10 last_dump_time 09:32:40 grace_period 0 auto_recover true auto_dump true
Each reporter dumps the
- Error Type
- Error Register value
- Reason in words
For eg:
~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_gen
NPA_AF_GENERAL:
NPA General Interrupt Reg : 1
NIX0: free disabled RX
~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_intr
NPA_AF_RVU:
NPA RVU Interrupt Reg : 1
Unmap Slot Error
~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_err
NPA_AF_ERR:
NPA Error Interrupt Reg : 4096
AQ Doorbell Error
For example::
~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_gen
NPA_AF_GENERAL:
NPA General Interrupt Reg : 1
NIX0: free disabled RX
~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_intr
NPA_AF_RVU:
NPA RVU Interrupt Reg : 1
Unmap Slot Error
~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_err
NPA_AF_ERR:
NPA Error Interrupt Reg : 4096
AQ Doorbell Error

14
Documentation/networking/ip-sysctl.rst
View File

@ -1196,7 +1196,7 @@ icmp_errors_use_inbound_ifaddr - BOOLEAN
If non-zero, the message will be sent with the primary address of
the interface that received the packet that caused the icmp error.
This is the behaviour network many administrators will expect from
This is the behaviour many network administrators will expect from
a router. And it can make debugging complicated network layouts
much easier.
@ -1807,12 +1807,24 @@ seg6_flowlabel - INTEGER
``conf/default/*``:
Change the interface-specific default settings.
These settings would be used during creating new interfaces.
``conf/all/*``:
Change all the interface-specific settings.
[XXX: Other special features than forwarding?]
conf/all/disable_ipv6 - BOOLEAN
Changing this value is same as changing ``conf/default/disable_ipv6``
setting and also all per-interface ``disable_ipv6`` settings to the same
value.
Reading this value does not have any particular meaning. It does not say
whether IPv6 support is enabled or disabled. Returned value can be 1
also in the case when some interface has ``disable_ipv6`` set to 0 and
has configured IPv6 addresses.
conf/all/forwarding - BOOLEAN
Enable global IPv6 forwarding between all interfaces.

126
Documentation/networking/netdev-FAQ.rst
View File

@ -6,9 +6,9 @@
netdev FAQ
==========
Q: What is netdev?
------------------
A: It is a mailing list for all network-related Linux stuff. This
What is netdev?
---------------
It is a mailing list for all network-related Linux stuff. This
includes anything found under net/ (i.e. core code like IPv6) and
drivers/net (i.e. hardware specific drivers) in the Linux source tree.
@ -25,9 +25,9 @@ Aside from subsystems like that mentioned above, all network-related
Linux development (i.e. RFC, review, comments, etc.) takes place on
netdev.
Q: How do the changes posted to netdev make their way into Linux?
-----------------------------------------------------------------
A: There are always two trees (git repositories) in play. Both are
How do the changes posted to netdev make their way into Linux?
--------------------------------------------------------------
There are always two trees (git repositories) in play. Both are
driven by David Miller, the main network maintainer. There is the
``net`` tree, and the ``net-next`` tree. As you can probably guess from
the names, the ``net`` tree is for fixes to existing code already in the
@ -37,9 +37,9 @@ for the future release. You can find the trees here:
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
Q: How often do changes from these trees make it to the mainline Linus tree?
----------------------------------------------------------------------------
A: To understand this, you need to know a bit of background information on
How often do changes from these trees make it to the mainline Linus tree?
-------------------------------------------------------------------------
To understand this, you need to know a bit of background information on
the cadence of Linux development. Each new release starts off with a
two week "merge window" where the main maintainers feed their new stuff
to Linus for merging into the mainline tree. After the two weeks, the
@ -81,7 +81,8 @@ focus for ``net`` is on stabilization and bug fixes.
Finally, the vX.Y gets released, and the whole cycle starts over.
Q: So where are we now in this cycle?
So where are we now in this cycle?
----------------------------------
Load the mainline (Linus) page here:
@ -91,9 +92,9 @@ and note the top of the "tags" section. If it is rc1, it is early in
the dev cycle. If it was tagged rc7 a week ago, then a release is
probably imminent.
Q: How do I indicate which tree (net vs. net-next) my patch should be in?
-------------------------------------------------------------------------
A: Firstly, think whether you have a bug fix or new "next-like" content.
How do I indicate which tree (net vs. net-next) my patch should be in?
----------------------------------------------------------------------
Firstly, think whether you have a bug fix or new "next-like" content.
Then once decided, assuming that you use git, use the prefix flag, i.e.
::
@ -105,48 +106,45 @@ in the above is just the subject text of the outgoing e-mail, and you
can manually change it yourself with whatever MUA you are comfortable
with.
Q: I sent a patch and I'm wondering what happened to it?
--------------------------------------------------------
Q: How can I tell whether it got merged?
A: Start by looking at the main patchworks queue for netdev:
I sent a patch and I'm wondering what happened to it - how can I tell whether it got merged?
--------------------------------------------------------------------------------------------
Start by looking at the main patchworks queue for netdev:
https://patchwork.kernel.org/project/netdevbpf/list/
The "State" field will tell you exactly where things are at with your
patch.
Q: The above only says "Under Review". How can I find out more?
----------------------------------------------------------------
A: Generally speaking, the patches get triaged quickly (in less than
The above only says "Under Review". How can I find out more?
-------------------------------------------------------------
Generally speaking, the patches get triaged quickly (in less than
48h). So be patient. Asking the maintainer for status updates on your
patch is a good way to ensure your patch is ignored or pushed to the
bottom of the priority list.
Q: I submitted multiple versions of the patch series
----------------------------------------------------
Q: should I directly update patchwork for the previous versions of these
patch series?
A: No, please don't interfere with the patch status on patchwork, leave
I submitted multiple versions of the patch series. Should I directly update patchwork for the previous versions of these patch series?
--------------------------------------------------------------------------------------------------------------------------------------
No, please don't interfere with the patch status on patchwork, leave
it to the maintainer to figure out what is the most recent and current
version that should be applied. If there is any doubt, the maintainer
will reply and ask what should be done.
Q: I made changes to only a few patches in a patch series should I resend only those changed?
---------------------------------------------------------------------------------------------
A: No, please resend the entire patch series and make sure you do number your
I made changes to only a few patches in a patch series should I resend only those changed?
------------------------------------------------------------------------------------------
No, please resend the entire patch series and make sure you do number your
patches such that it is clear this is the latest and greatest set of patches
that can be applied.
Q: I submitted multiple versions of a patch series and it looks like a version other than the last one has been accepted, what should I do?
-------------------------------------------------------------------------------------------------------------------------------------------
A: There is no revert possible, once it is pushed out, it stays like that.
I submitted multiple versions of a patch series and it looks like a version other than the last one has been accepted, what should I do?
----------------------------------------------------------------------------------------------------------------------------------------
There is no revert possible, once it is pushed out, it stays like that.
Please send incremental versions on top of what has been merged in order to fix
the patches the way they would look like if your latest patch series was to be
merged.
Q: How can I tell what patches are queued up for backporting to the various stable releases?
--------------------------------------------------------------------------------------------
A: Normally Greg Kroah-Hartman collects stable commits himself, but for
How can I tell what patches are queued up for backporting to the various stable releases?
-----------------------------------------------------------------------------------------
Normally Greg Kroah-Hartman collects stable commits himself, but for
networking, Dave collects up patches he deems critical for the
networking subsystem, and then hands them off to Greg.
@ -169,11 +167,9 @@ simply clone the repo, and then git grep the mainline commit ID, e.g.
releases/3.9.8/ipv6-fix-possible-crashes-in-ip6_cork_release.patch
stable/stable-queue$
Q: I see a network patch and I think it should be backported to stable.
-----------------------------------------------------------------------
Q: Should I request it via stable@vger.kernel.org like the references in
the kernel's Documentation/process/stable-kernel-rules.rst file say?
A: No, not for networking. Check the stable queues as per above first
I see a network patch and I think it should be backported to stable. Should I request it via stable@vger.kernel.org like the references in the kernel's Documentation/process/stable-kernel-rules.rst file say?
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
No, not for networking. Check the stable queues as per above first
to see if it is already queued. If not, then send a mail to netdev,
listing the upstream commit ID and why you think it should be a stable
candidate.
@ -190,11 +186,9 @@ mainline, the better the odds that it is an OK candidate for stable. So
scrambling to request a commit be added the day after it appears should
be avoided.
Q: I have created a network patch and I think it should be backported to stable.
--------------------------------------------------------------------------------
Q: Should I add a Cc: stable@vger.kernel.org like the references in the
kernel's Documentation/ directory say?
A: No. See above answer. In short, if you think it really belongs in
I have created a network patch and I think it should be backported to stable. Should I add a Cc: stable@vger.kernel.org like the references in the kernel's Documentation/ directory say?
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
No. See above answer. In short, if you think it really belongs in
stable, then ensure you write a decent commit log that describes who
gets impacted by the bug fix and how it manifests itself, and when the
bug was introduced. If you do that properly, then the commit will get
@ -207,18 +201,18 @@ marker line as described in
:ref:`Documentation/process/submitting-patches.rst <the_canonical_patch_format>`
to temporarily embed that information into the patch that you send.
Q: Are all networking bug fixes backported to all stable releases?
------------------------------------------------------------------
A: Due to capacity, Dave could only take care of the backports for the
Are all networking bug fixes backported to all stable releases?
---------------------------------------------------------------
Due to capacity, Dave could only take care of the backports for the
last two stable releases. For earlier stable releases, each stable
branch maintainer is supposed to take care of them. If you find any
patch is missing from an earlier stable branch, please notify
stable@vger.kernel.org with either a commit ID or a formal patch
backported, and CC Dave and other relevant networking developers.
Q: Is the comment style convention different for the networking content?
------------------------------------------------------------------------
A: Yes, in a largely trivial way. Instead of this::
Is the comment style convention different for the networking content?
---------------------------------------------------------------------
Yes, in a largely trivial way. Instead of this::
/*
* foobar blah blah blah
@ -231,32 +225,30 @@ it is requested that you make it look like this::
* another line of text
*/
Q: I am working in existing code that has the former comment style and not the latter.
--------------------------------------------------------------------------------------
Q: Should I submit new code in the former style or the latter?
A: Make it the latter style, so that eventually all code in the domain
I am working in existing code that has the former comment style and not the latter. Should I submit new code in the former style or the latter?
-----------------------------------------------------------------------------------------------------------------------------------------------
Make it the latter style, so that eventually all code in the domain
of netdev is of this format.
Q: I found a bug that might have possible security implications or similar.
---------------------------------------------------------------------------
Q: Should I mail the main netdev maintainer off-list?**
A: No. The current netdev maintainer has consistently requested that
I found a bug that might have possible security implications or similar. Should I mail the main netdev maintainer off-list?
---------------------------------------------------------------------------------------------------------------------------
No. The current netdev maintainer has consistently requested that
people use the mailing lists and not reach out directly. If you aren't
OK with that, then perhaps consider mailing security@kernel.org or
reading about http://oss-security.openwall.org/wiki/mailing-lists/distros
as possible alternative mechanisms.
Q: What level of testing is expected before I submit my change?
---------------------------------------------------------------
A: If your changes are against ``net-next``, the expectation is that you
What level of testing is expected before I submit my change?
------------------------------------------------------------
If your changes are against ``net-next``, the expectation is that you
have tested by layering your changes on top of ``net-next``. Ideally
you will have done run-time testing specific to your change, but at a
minimum, your changes should survive an ``allyesconfig`` and an
``allmodconfig`` build without new warnings or failures.
Q: How do I post corresponding changes to user space components?
----------------------------------------------------------------
A: User space code exercising kernel features should be posted
How do I post corresponding changes to user space components?
-------------------------------------------------------------
User space code exercising kernel features should be posted
alongside kernel patches. This gives reviewers a chance to see
how any new interface is used and how well it works.
@ -280,9 +272,9 @@ to the mailing list, e.g.::
Posting as one thread is discouraged because it confuses patchwork
(as of patchwork 2.2.2).
Q: Any other tips to help ensure my net/net-next patch gets OK'd?
-----------------------------------------------------------------
A: Attention to detail. Re-read your own work as if you were the
Any other tips to help ensure my net/net-next patch gets OK'd?
--------------------------------------------------------------
Attention to detail. Re-read your own work as if you were the
reviewer. You can start with using ``checkpatch.pl``, perhaps even with
the ``--strict`` flag. But do not be mindlessly robotic in doing so.
If your change is a bug fix, make sure your commit log indicates the

175
Documentation/networking/netdevices.rst
View File

@ -10,18 +10,177 @@ Introduction
The following is a random collection of documentation regarding
network devices.
struct net_device allocation rules
==================================
struct net_device lifetime rules
================================
Network device structures need to persist even after module is unloaded and
must be allocated with alloc_netdev_mqs() and friends.
If device has registered successfully, it will be freed on last use
by free_netdev(). This is required to handle the pathologic case cleanly
(example: rmmod mydriver </sys/class/net/myeth/mtu )
by free_netdev(). This is required to handle the pathological case cleanly
(example: ``rmmod mydriver </sys/class/net/myeth/mtu``)
alloc_netdev_mqs()/alloc_netdev() reserve extra space for driver
alloc_netdev_mqs() / alloc_netdev() reserve extra space for driver
private data which gets freed when the network device is freed. If
separately allocated data is attached to the network device
(netdev_priv(dev)) then it is up to the module exit handler to free that.
(netdev_priv()) then it is up to the module exit handler to free that.
There are two groups of APIs for registering struct net_device.
First group can be used in normal contexts where ``rtnl_lock`` is not already
held: register_netdev(), unregister_netdev().
Second group can be used when ``rtnl_lock`` is already held:
register_netdevice(), unregister_netdevice(), free_netdevice().
Simple drivers
--------------
Most drivers (especially device drivers) handle lifetime of struct net_device
in context where ``rtnl_lock`` is not held (e.g. driver probe and remove paths).
In that case the struct net_device registration is done using
the register_netdev(), and unregister_netdev() functions:
.. code-block:: c
int probe()
{
struct my_device_priv *priv;
int err;
dev = alloc_netdev_mqs(...);
if (!dev)
return -ENOMEM;
priv = netdev_priv(dev);
/* ... do all device setup before calling register_netdev() ...
*/
err = register_netdev(dev);
if (err)
goto err_undo;
/* net_device is visible to the user! */
err_undo:
/* ... undo the device setup ... */
free_netdev(dev);
return err;
}
void remove()
{
unregister_netdev(dev);
free_netdev(dev);
}
Note that after calling register_netdev() the device is visible in the system.
Users can open it and start sending / receiving traffic immediately,
or run any other callback, so all initialization must be done prior to
registration.
unregister_netdev() closes the device and waits for all users to be done
with it. The memory of struct net_device itself may still be referenced
by sysfs but all operations on that device will fail.
free_netdev() can be called after unregister_netdev() returns on when
register_netdev() failed.
Device management under RTNL
----------------------------
Registering struct net_device while in context which already holds
the ``rtnl_lock`` requires extra care. In those scenarios most drivers
will want to make use of struct net_device's ``needs_free_netdev``
and ``priv_destructor`` members for freeing of state.
Example flow of netdev handling under ``rtnl_lock``:
.. code-block:: c
static void my_setup(struct net_device *dev)
{
dev->needs_free_netdev = true;
}
static void my_destructor(struct net_device *dev)
{
some_obj_destroy(priv->obj);
some_uninit(priv);
}
int create_link()
{
struct my_device_priv *priv;
int err;
ASSERT_RTNL();
dev = alloc_netdev(sizeof(*priv), "net%d", NET_NAME_UNKNOWN, my_setup);
if (!dev)
return -ENOMEM;
priv = netdev_priv(dev);
/* Implicit constructor */
err = some_init(priv);
if (err)
goto err_free_dev;
priv->obj = some_obj_create();
if (!priv->obj) {
err = -ENOMEM;
goto err_some_uninit;
}
/* End of constructor, set the destructor: */
dev->priv_destructor = my_destructor;
err = register_netdevice(dev);
if (err)
/* register_netdevice() calls destructor on failure */
goto err_free_dev;
/* If anything fails now unregister_netdevice() (or unregister_netdev())
* will take care of calling my_destructor and free_netdev().
*/
return 0;
err_some_uninit:
some_uninit(priv);
err_free_dev:
free_netdev(dev);
return err;
}
If struct net_device.priv_destructor is set it will be called by the core
some time after unregister_netdevice(), it will also be called if
register_netdevice() fails. The callback may be invoked with or without
``rtnl_lock`` held.
There is no explicit constructor callback, driver "constructs" the private
netdev state after allocating it and before registration.
Setting struct net_device.needs_free_netdev makes core call free_netdevice()
automatically after unregister_netdevice() when all references to the device
are gone. It only takes effect after a successful call to register_netdevice()
so if register_netdevice() fails driver is responsible for calling
free_netdev().
free_netdev() is safe to call on error paths right after unregister_netdevice()
or when register_netdevice() fails. Parts of netdev (de)registration process
happen after ``rtnl_lock`` is released, therefore in those cases free_netdev()
will defer some of the processing until ``rtnl_lock`` is released.
Devices spawned from struct rtnl_link_ops should never free the
struct net_device directly.
.ndo_init and .ndo_uninit
~~~~~~~~~~~~~~~~~~~~~~~~~
``.ndo_init`` and ``.ndo_uninit`` callbacks are called during net_device
registration and de-registration, under ``rtnl_lock``. Drivers can use
those e.g. when parts of their init process need to run under ``rtnl_lock``.
``.ndo_init`` runs before device is visible in the system, ``.ndo_uninit``
runs during de-registering after device is closed but other subsystems
may still have outstanding references to the netdevice.
MTU
===
@ -64,8 +223,8 @@ ndo_do_ioctl:
Context: process
ndo_get_stats:
Synchronization: dev_base_lock rwlock.
Context: nominally process, but don't sleep inside an rwlock
Synchronization: rtnl_lock() semaphore, dev_base_lock rwlock, or RCU.
Context: atomic (can't sleep under rwlock or RCU)
ndo_start_xmit:
Synchronization: __netif_tx_lock spinlock.

11
Documentation/networking/packet_mmap.rst
View File

@ -8,7 +8,7 @@ Abstract
========
This file documents the mmap() facility available with the PACKET
socket interface on 2.4/2.6/3.x kernels. This type of sockets is used for
socket interface. This type of sockets is used for
i) capture network traffic with utilities like tcpdump,
ii) transmit network traffic, or any other that needs raw
@ -25,12 +25,12 @@ Please send your comments to
Why use PACKET_MMAP
===================
In Linux 2.4/2.6/3.x if PACKET_MMAP is not enabled, the capture process is very
Non PACKET_MMAP capture process (plain AF_PACKET) is very
inefficient. It uses very limited buffers and requires one system call to
capture each packet, it requires two if you want to get packet's timestamp
(like libpcap always does).
In the other hand PACKET_MMAP is very efficient. PACKET_MMAP provides a size
On the other hand PACKET_MMAP is very efficient. PACKET_MMAP provides a size
configurable circular buffer mapped in user space that can be used to either
send or receive packets. This way reading packets just needs to wait for them,
most of the time there is no need to issue a single system call. Concerning
@ -252,8 +252,7 @@ PACKET_MMAP setting constraints
In kernel versions prior to 2.4.26 (for the 2.4 branch) and 2.6.5 (2.6 branch),
the PACKET_MMAP buffer could hold only 32768 frames in a 32 bit architecture or
16384 in a 64 bit architecture. For information on these kernel versions
see http://pusa.uv.es/~ulisses/packet_mmap/packet_mmap.pre-2.4.26_2.6.5.txt
16384 in a 64 bit architecture.
Block size limit
----------------
@ -437,7 +436,7 @@ and the following flags apply:
Capture process
^^^^^^^^^^^^^^^
from include/linux/if_packet.h
From include/linux/if_packet.h::
#define TP_STATUS_COPY (1 << 1)
#define TP_STATUS_LOSING (1 << 2)

5
Documentation/networking/tls-offload.rst
View File

@ -530,7 +530,10 @@ TLS device feature flags only control adding of new TLS connection
offloads, old connections will remain active after flags are cleared.
TLS encryption cannot be offloaded to devices without checksum calculation
offload. Hence, TLS TX device feature flag requires NETIF_F_HW_CSUM being set.
offload. Hence, TLS TX device feature flag requires TX csum offload being set.
Disabling the latter implies clearing the former. Disabling TX checksum offload
should not affect old connections, and drivers should make sure checksum
calculation does not break for them.
Similarly, device-offloaded TLS decryption implies doing RXCSUM. If the user
does not want to enable RX csum offload, TLS RX device feature is disabled
as well.

6
Documentation/process/4.Coding.rst
View File

@ -249,10 +249,8 @@ features; most of these are found in the "kernel hacking" submenu. Several
of these options should be turned on for any kernel used for development or
testing purposes. In particular, you should turn on:
- ENABLE_MUST_CHECK and FRAME_WARN to get an
extra set of warnings for problems like the use of deprecated interfaces
or ignoring an important return value from a function. The output
generated by these warnings can be verbose, but one need not worry about
- FRAME_WARN to get warnings for stack frames larger than a given amount.
The output generated can be verbose, but one need not worry about
warnings from other parts of the kernel.
- DEBUG_OBJECTS will add code to track the lifetime of various objects

2
Documentation/sound/alsa-configuration.rst
View File

@ -1501,7 +1501,7 @@ Module for Digigram miXart8 sound cards.
This module supports multiple cards.
Note: One miXart8 board will be represented as 4 alsa cards.
See MIXART.txt for details.
See Documentation/sound/cards/mixart.rst for details.
When the driver is compiled as a module and the hotplug firmware
is supported, the firmware data is loaded via hotplug automatically.

16
Documentation/sound/kernel-api/writing-an-alsa-driver.rst
View File

@ -71,7 +71,7 @@ core/oss
The codes for PCM and mixer OSS emulation modules are stored in this
directory. The rawmidi OSS emulation is included in the ALSA rawmidi
code since it's quite small. The sequencer code is stored in
``core/seq/oss`` directory (see `below <#core-seq-oss>`__).
``core/seq/oss`` directory (see `below <core/seq/oss_>`__).
core/seq
~~~~~~~~
@ -382,7 +382,7 @@ where ``enable[dev]`` is the module option.
Each time the ``probe`` callback is called, check the availability of
the device. If not available, simply increment the device index and
returns. dev will be incremented also later (`step 7
<#set-the-pci-driver-data-and-return-zero>`__).
<7) Set the PCI driver data and return zero._>`__).
2) Create a card instance
~~~~~~~~~~~~~~~~~~~~~~~~~
@ -450,10 +450,10 @@ field contains the information shown in ``/proc/asound/cards``.
5) Create other components, such as mixer, MIDI, etc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Here you define the basic components such as `PCM <#PCM-Interface>`__,
mixer (e.g. `AC97 <#API-for-AC97-Codec>`__), MIDI (e.g.
`MPU-401 <#MIDI-MPU401-UART-Interface>`__), and other interfaces.
Also, if you want a `proc file <#Proc-Interface>`__, define it here,
Here you define the basic components such as `PCM <PCM Interface_>`__,
mixer (e.g. `AC97 <API for AC97 Codec_>`__), MIDI (e.g.
`MPU-401 <MIDI (MPU401-UART) Interface_>`__), and other interfaces.
Also, if you want a `proc file <Proc Interface_>`__, define it here,
too.
6) Register the card instance.
@ -941,7 +941,7 @@ The allocation of an interrupt source is done like this:
chip->irq = pci->irq;
where :c:func:`snd_mychip_interrupt()` is the interrupt handler
defined `later <#pcm-interface-interrupt-handler>`__. Note that
defined `later <PCM Interrupt Handler_>`__. Note that
``chip->irq`` should be defined only when :c:func:`request_irq()`
succeeded.
@ -3104,7 +3104,7 @@ processing the output stream in the irq handler.
If the MPU-401 interface shares its interrupt with the other logical
devices on the card, set ``MPU401_INFO_IRQ_HOOK`` (see
`below <#MIDI-Interrupt-Handler>`__).
`below <MIDI Interrupt Handler_>`__).
Usually, the port address corresponds to the command port and port + 1
corresponds to the data port. If not, you may change the ``cport``

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

@ -360,10 +360,9 @@ since the last call to this ioctl. Bit 0 is the first page in the
memory slot. Ensure the entire structure is cleared to avoid padding
issues.
If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 specifies
the address space for which you want to return the dirty bitmap.
They must be less than the value that KVM_CHECK_EXTENSION returns for
the KVM_CAP_MULTI_ADDRESS_SPACE capability.
If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 of slot field specifies
the address space for which you want to return the dirty bitmap. See
KVM_SET_USER_MEMORY_REGION for details on the usage of slot field.
The bits in the dirty bitmap are cleared before the ioctl returns, unless
KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 is enabled. For more information,
@ -392,9 +391,14 @@ This ioctl is obsolete and has been removed.
Errors:
===== =============================
======= ==============================================================
EINTR an unmasked signal is pending
===== =============================
ENOEXEC the vcpu hasn't been initialized or the guest tried to execute
instructions from device memory (arm64)
ENOSYS data abort outside memslots with no syndrome info and
KVM_CAP_ARM_NISV_TO_USER not enabled (arm64)
EPERM SVE feature set but not finalized (arm64)
======= ==============================================================
This ioctl is used to run a guest virtual cpu. While there are no
explicit parameters, there is an implicit parameter block that can be
@ -1276,6 +1280,9 @@ field userspace_addr, which must point at user addressable memory for
the entire memory slot size. Any object may back this memory, including
anonymous memory, ordinary files, and hugetlbfs.
On architectures that support a form of address tagging, userspace_addr must
be an untagged address.
It is recommended that the lower 21 bits of guest_phys_addr and userspace_addr
be identical. This allows large pages in the guest to be backed by large
pages in the host.
@ -1328,7 +1335,7 @@ documentation when it pops into existence).
:Capability: KVM_CAP_ENABLE_CAP_VM
:Architectures: all
:Type: vcpu ioctl
:Type: vm ioctl
:Parameters: struct kvm_enable_cap (in)
:Returns: 0 on success; -1 on error
@ -4427,7 +4434,7 @@ to I/O ports.
:Capability: KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2
:Architectures: x86, arm, arm64, mips
:Type: vm ioctl
:Parameters: struct kvm_dirty_log (in)
:Parameters: struct kvm_clear_dirty_log (in)
:Returns: 0 on success, -1 on error
::
@ -4454,10 +4461,9 @@ in KVM's dirty bitmap, and dirty tracking is re-enabled for that page
(for example via write-protection, or by clearing the dirty bit in
a page table entry).
If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 specifies
the address space for which you want to return the dirty bitmap.
They must be less than the value that KVM_CHECK_EXTENSION returns for
the KVM_CAP_MULTI_ADDRESS_SPACE capability.
If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 of slot field specifies
the address space for which you want to clear the dirty status. See
KVM_SET_USER_MEMORY_REGION for details on the usage of slot field.
This ioctl is mostly useful when KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2
is enabled; for more information, see the description of the capability.

6
Documentation/virt/kvm/nested-vmx.rst
View File

@ -37,8 +37,10 @@ call L2.
Running nested VMX
------------------
The nested VMX feature is disabled by default. It can be enabled by giving
the "nested=1" option to the kvm-intel module.
The nested VMX feature is enabled by default since Linux kernel v4.20. For
older Linux kernel, it can be enabled by giving the "nested=1" option to the
kvm-intel module.
No modifications are required to user space (qemu). However, qemu's default
emulated CPU type (qemu64) does not list the "VMX" CPU feature, so it must be

2
Documentation/virt/kvm/running-nested-guests.rst
View File

@ -74,7 +74,7 @@ few:
Enabling "nested" (x86)
-----------------------
From Linux kernel v4.19 onwards, the ``nested`` KVM parameter is enabled
From Linux kernel v4.20 onwards, the ``nested`` KVM parameter is enabled
by default for Intel and AMD. (Though your Linux distribution might
override this default.)

138
MAINTAINERS
View File

@ -203,8 +203,8 @@ F: include/uapi/linux/nl80211.h
F: net/wireless/
8169 10/100/1000 GIGABIT ETHERNET DRIVER
M: Realtek linux nic maintainers <nic_swsd@realtek.com>
M: Heiner Kallweit <hkallweit1@gmail.com>
M: nic_swsd@realtek.com
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/realtek/r8169*
@ -820,7 +820,6 @@ M: Netanel Belgazal <netanel@amazon.com>
M: Arthur Kiyanovski <akiyano@amazon.com>
R: Guy Tzalik <gtzalik@amazon.com>
R: Saeed Bishara <saeedb@amazon.com>
R: Zorik Machulsky <zorik@amazon.com>
L: netdev@vger.kernel.org
S: Supported
F: Documentation/networking/device_drivers/ethernet/amazon/ena.rst
@ -907,7 +906,7 @@ AMD KFD
M: Felix Kuehling <Felix.Kuehling@amd.com>
L: amd-gfx@lists.freedesktop.org
S: Supported
T: git git://people.freedesktop.org/~agd5f/linux
T: git https://gitlab.freedesktop.org/agd5f/linux.git
F: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd*.[ch]
F: drivers/gpu/drm/amd/amdkfd/
F: drivers/gpu/drm/amd/include/cik_structs.h
@ -2119,7 +2118,7 @@ N: atmel
ARM/Microchip Sparx5 SoC support
M: Lars Povlsen <lars.povlsen@microchip.com>
M: Steen Hegelund <Steen.Hegelund@microchip.com>
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
M: UNGLinuxDriver@microchip.com
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
T: git git://github.com/microchip-ung/linux-upstream.git
@ -2617,8 +2616,8 @@ S: Maintained
F: drivers/power/reset/keystone-reset.c
ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE
M: Tero Kristo <t-kristo@ti.com>
M: Nishanth Menon <nm@ti.com>
M: Tero Kristo <kristo@kernel.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/arm/ti/k3.yaml
@ -2942,7 +2941,6 @@ S: Maintained
F: drivers/hwmon/asus_atk0110.c
ATLX ETHERNET DRIVERS
M: Jay Cliburn <jcliburn@gmail.com>
M: Chris Snook <chris.snook@gmail.com>
L: netdev@vger.kernel.org
S: Maintained
@ -3241,6 +3239,7 @@ L: netdev@vger.kernel.org
S: Supported
W: http://sourceforge.net/projects/bonding/
F: drivers/net/bonding/
F: include/net/bonding.h
F: include/uapi/linux/if_bonding.h
BOSCH SENSORTEC BMA400 ACCELEROMETER IIO DRIVER
@ -3336,7 +3335,7 @@ F: arch/riscv/net/
X: arch/riscv/net/bpf_jit_comp64.c
BPF JIT for RISC-V (64-bit)
M: Björn Töpel <bjorn.topel@gmail.com>
M: Björn Töpel <bjorn@kernel.org>
L: netdev@vger.kernel.org
L: bpf@vger.kernel.org
S: Maintained
@ -3413,7 +3412,7 @@ F: Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
F: drivers/pci/controller/pcie-brcmstb.c
F: drivers/staging/vc04_services
N: bcm2711
N: bcm2835
N: bcm283*
BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITECTURE
M: Florian Fainelli <f.fainelli@gmail.com>
@ -3556,7 +3555,7 @@ S: Supported
F: drivers/net/ethernet/broadcom/bnxt/
BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
M: Arend van Spriel <arend.vanspriel@broadcom.com>
M: Arend van Spriel <aspriel@gmail.com>
M: Franky Lin <franky.lin@broadcom.com>
M: Hante Meuleman <hante.meuleman@broadcom.com>
M: Chi-hsien Lin <chi-hsien.lin@infineon.com>
@ -3881,9 +3880,9 @@ F: Documentation/devicetree/bindings/mtd/cadence-nand-controller.txt
F: drivers/mtd/nand/raw/cadence-nand-controller.c
CADENCE USB3 DRD IP DRIVER
M: Peter Chen <peter.chen@nxp.com>
M: Peter Chen <peter.chen@kernel.org>
M: Pawel Laszczak <pawell@cadence.com>
M: Roger Quadros <rogerq@ti.com>
R: Roger Quadros <rogerq@kernel.org>
R: Aswath Govindraju <a-govindraju@ti.com>
L: linux-usb@vger.kernel.org
S: Maintained
@ -3961,7 +3960,7 @@ F: net/can/
CAN-J1939 NETWORK LAYER
M: Robin van der Gracht <robin@protonic.nl>
M: Oleksij Rempel <o.rempel@pengutronix.de>
R: Pengutronix Kernel Team <kernel@pengutronix.de>
R: kernel@pengutronix.de
L: linux-can@vger.kernel.org
S: Maintained
F: Documentation/networking/j1939.rst
@ -4163,7 +4162,7 @@ S: Maintained
F: Documentation/translations/zh_CN/
CHIPIDEA USB HIGH SPEED DUAL ROLE CONTROLLER
M: Peter Chen <Peter.Chen@nxp.com>
M: Peter Chen <peter.chen@kernel.org>
L: linux-usb@vger.kernel.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
@ -4305,7 +4304,7 @@ S: Maintained
F: .clang-format
CLANG/LLVM BUILD SUPPORT
M: Nathan Chancellor <natechancellor@gmail.com>
M: Nathan Chancellor <nathan@kernel.org>
M: Nick Desaulniers <ndesaulniers@google.com>
L: clang-built-linux@googlegroups.com
S: Supported
@ -4313,7 +4312,9 @@ W: https://clangbuiltlinux.github.io/
B: https://github.com/ClangBuiltLinux/linux/issues
C: irc://chat.freenode.net/clangbuiltlinux
F: Documentation/kbuild/llvm.rst
F: include/linux/compiler-clang.h
F: scripts/clang-tools/
F: scripts/clang-version.sh
F: scripts/lld-version.sh
K: \b(?i:clang|llvm)\b
@ -4467,7 +4468,7 @@ F: include/linux/console*
CONTROL GROUP (CGROUP)
M: Tejun Heo <tj@kernel.org>
M: Li Zefan <lizefan@huawei.com>
M: Zefan Li <lizefan.x@bytedance.com>
M: Johannes Weiner <hannes@cmpxchg.org>
L: cgroups@vger.kernel.org
S: Maintained
@ -4491,11 +4492,9 @@ F: block/blk-throttle.c
F: include/linux/blk-cgroup.h
CONTROL GROUP - CPUSET
M: Li Zefan <lizefan@huawei.com>
M: Zefan Li <lizefan.x@bytedance.com>
L: cgroups@vger.kernel.org
S: Maintained
W: http://www.bullopensource.org/cpuset/
W: http://oss.sgi.com/projects/cpusets/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
F: Documentation/admin-guide/cgroup-v1/cpusets.rst
F: include/linux/cpuset.h
@ -4922,9 +4921,8 @@ F: Documentation/scsi/dc395x.rst
F: drivers/scsi/dc395x.*
DCCP PROTOCOL
M: Gerrit Renker <gerrit@erg.abdn.ac.uk>
L: dccp@vger.kernel.org
S: Maintained
S: Orphan
W: http://www.linuxfoundation.org/collaborate/workgroups/networking/dccp
F: include/linux/dccp.h
F: include/linux/tfrc.h
@ -6474,9 +6472,9 @@ S: Maintained
F: drivers/edac/skx_*.[ch]
EDAC-TI
M: Tero Kristo <t-kristo@ti.com>
M: Tero Kristo <kristo@kernel.org>
L: linux-edac@vger.kernel.org
S: Maintained
S: Odd Fixes
F: drivers/edac/ti_edac.c
EDIROL UA-101/UA-1000 DRIVER
@ -7363,7 +7361,6 @@ L: linux-hardening@vger.kernel.org
S: Maintained
F: Documentation/kbuild/gcc-plugins.rst
F: scripts/Makefile.gcc-plugins
F: scripts/gcc-plugin.sh
F: scripts/gcc-plugins/
GCOV BASED KERNEL PROFILING
@ -8435,11 +8432,8 @@ F: drivers/i3c/
F: include/linux/i3c/
IA64 (Itanium) PLATFORM
M: Tony Luck <tony.luck@intel.com>
M: Fenghua Yu <fenghua.yu@intel.com>
L: linux-ia64@vger.kernel.org
S: Odd Fixes
T: git git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux.git
S: Orphan
F: Documentation/ia64/
F: arch/ia64/
@ -9240,7 +9234,7 @@ F: tools/testing/selftests/sgx/*
K: \bSGX_
INTERCONNECT API
M: Georgi Djakov <georgi.djakov@linaro.org>
M: Georgi Djakov <djakov@kernel.org>
L: linux-pm@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/interconnect/
@ -9273,7 +9267,7 @@ F: drivers/net/ethernet/sgi/ioc3-eth.c
IOMAP FILESYSTEM LIBRARY
M: Christoph Hellwig <hch@infradead.org>
M: Darrick J. Wong <darrick.wong@oracle.com>
M: Darrick J. Wong <djwong@kernel.org>
M: linux-xfs@vger.kernel.org
M: linux-fsdevel@vger.kernel.org
L: linux-xfs@vger.kernel.org
@ -9327,7 +9321,6 @@ W: http://www.adaptec.com/
F: drivers/scsi/ips*
IPVS
M: Wensong Zhang <wensong@linux-vs.org>
M: Simon Horman <horms@verge.net.au>
M: Julian Anastasov <ja@ssi.bg>
L: netdev@vger.kernel.org
@ -9564,16 +9557,18 @@ F: Documentation/hwmon/k8temp.rst
F: drivers/hwmon/k8temp.c
KASAN
M: Andrey Ryabinin <aryabinin@virtuozzo.com>
M: Andrey Ryabinin <ryabinin.a.a@gmail.com>
R: Alexander Potapenko <glider@google.com>
R: Andrey Konovalov <andreyknvl@gmail.com>
R: Dmitry Vyukov <dvyukov@google.com>
L: kasan-dev@googlegroups.com
S: Maintained
F: Documentation/dev-tools/kasan.rst
F: arch/*/include/asm/kasan.h
F: arch/*/include/asm/*kasan.h
F: arch/*/mm/kasan_init*
F: include/linux/kasan*.h
F: lib/test_kasan.c
F: lib/Kconfig.kasan
F: lib/test_kasan*.c
F: mm/kasan/
F: scripts/Makefile.kasan
@ -9588,7 +9583,7 @@ F: scripts/kconfig/
KCOV
R: Dmitry Vyukov <dvyukov@google.com>
R: Andrey Konovalov <andreyknvl@google.com>
R: Andrey Konovalov <andreyknvl@gmail.com>
L: kasan-dev@googlegroups.com
S: Maintained
F: Documentation/dev-tools/kcov.rst
@ -9776,7 +9771,7 @@ F: tools/testing/selftests/kvm/s390x/
KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)
M: Paolo Bonzini <pbonzini@redhat.com>
R: Sean Christopherson <sean.j.christopherson@intel.com>
R: Sean Christopherson <seanjc@google.com>
R: Vitaly Kuznetsov <vkuznets@redhat.com>
R: Wanpeng Li <wanpengli@tencent.com>
R: Jim Mattson <jmattson@google.com>
@ -10260,7 +10255,6 @@ S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev
F: Documentation/atomic_bitops.txt
F: Documentation/atomic_t.txt
F: Documentation/core-api/atomic_ops.rst
F: Documentation/core-api/refcount-vs-atomic.rst
F: Documentation/litmus-tests/
F: Documentation/memory-barriers.txt
@ -10847,7 +10841,7 @@ F: drivers/media/radio/radio-maxiradio*
MCAN MMIO DEVICE DRIVER
M: Dan Murphy <dmurphy@ti.com>
M: Sriram Dash <sriram.dash@samsung.com>
M: Pankaj Sharma <pankj.sharma@samsung.com>
L: linux-can@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
@ -11667,7 +11661,7 @@ F: drivers/media/platform/atmel/atmel-isi.h
MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
M: Woojung Huh <woojung.huh@microchip.com>
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
M: UNGLinuxDriver@microchip.com
L: netdev@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
@ -11677,7 +11671,7 @@ F: net/dsa/tag_ksz.c
MICROCHIP LAN743X ETHERNET DRIVER
M: Bryan Whitehead <bryan.whitehead@microchip.com>
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
M: UNGLinuxDriver@microchip.com
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/microchip/lan743x_*
@ -11771,7 +11765,7 @@ F: drivers/net/wireless/microchip/wilc1000/
MICROSEMI MIPS SOCS
M: Alexandre Belloni <alexandre.belloni@bootlin.com>
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
M: UNGLinuxDriver@microchip.com
L: linux-mips@vger.kernel.org
S: Supported
F: Documentation/devicetree/bindings/mips/mscc.txt
@ -12418,8 +12412,8 @@ F: tools/testing/selftests/net/ipsec.c
NETWORKING [IPv4/IPv6]
M: "David S. Miller" <davem@davemloft.net>
M: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
M: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
M: David Ahern <dsahern@kernel.org>
L: netdev@vger.kernel.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
@ -12475,7 +12469,6 @@ F: net/ipv6/tcp*.c
NETWORKING [TLS]
M: Boris Pismenny <borisp@nvidia.com>
M: Aviad Yehezkel <aviadye@nvidia.com>
M: John Fastabend <john.fastabend@gmail.com>
M: Daniel Borkmann <daniel@iogearbox.net>
M: Jakub Kicinski <kuba@kernel.org>
@ -12825,10 +12818,10 @@ F: tools/objtool/
F: include/linux/objtool.h
OCELOT ETHERNET SWITCH DRIVER
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
M: Vladimir Oltean <vladimir.oltean@nxp.com>
M: Claudiu Manoil <claudiu.manoil@nxp.com>
M: Alexandre Belloni <alexandre.belloni@bootlin.com>
M: UNGLinuxDriver@microchip.com
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/dsa/ocelot/*
@ -12850,7 +12843,7 @@ F: include/misc/ocxl*
F: include/uapi/misc/ocxl.h
OMAP AUDIO SUPPORT
M: Peter Ujfalusi <peter.ujfalusi@ti.com>
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
M: Jarkko Nikula <jarkko.nikula@bitmer.com>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
L: linux-omap@vger.kernel.org
@ -13890,7 +13883,7 @@ F: drivers/platform/x86/peaq-wmi.c
PENSANDO ETHERNET DRIVERS
M: Shannon Nelson <snelson@pensando.io>
M: Pensando Drivers <drivers@pensando.io>
M: drivers@pensando.io
L: netdev@vger.kernel.org
S: Supported
F: Documentation/networking/device_drivers/ethernet/pensando/ionic.rst
@ -14512,10 +14505,18 @@ S: Supported
F: drivers/crypto/qat/
QCOM AUDIO (ASoC) DRIVERS
M: Patrick Lai <plai@codeaurora.org>
M: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
M: Banajit Goswami <bgoswami@codeaurora.org>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Supported
F: sound/soc/codecs/lpass-va-macro.c
F: sound/soc/codecs/lpass-wsa-macro.*
F: sound/soc/codecs/msm8916-wcd-analog.c
F: sound/soc/codecs/msm8916-wcd-digital.c
F: sound/soc/codecs/wcd9335.*
F: sound/soc/codecs/wcd934x.c
F: sound/soc/codecs/wcd-clsh-v2.*
F: sound/soc/codecs/wsa881x.c
F: sound/soc/qcom/
QCOM IPA DRIVER
@ -14669,7 +14670,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
F: drivers/net/wireless/ath/ath11k/
QUALCOMM ATHEROS ATH9K WIRELESS DRIVER
M: QCA ath9k Development <ath9k-devel@qca.qualcomm.com>
M: ath9k-devel@qca.qualcomm.com
L: linux-wireless@vger.kernel.org
S: Supported
W: https://wireless.wiki.kernel.org/en/users/Drivers/ath9k
@ -14820,7 +14821,7 @@ M: Alex Deucher <alexander.deucher@amd.com>
M: Christian König <christian.koenig@amd.com>
L: amd-gfx@lists.freedesktop.org
S: Supported
T: git git://people.freedesktop.org/~agd5f/linux
T: git https://gitlab.freedesktop.org/agd5f/linux.git
F: drivers/gpu/drm/amd/
F: drivers/gpu/drm/radeon/
F: include/uapi/drm/amdgpu_drm.h
@ -16321,6 +16322,7 @@ M: Pekka Enberg <penberg@kernel.org>
M: David Rientjes <rientjes@google.com>
M: Joonsoo Kim <iamjoonsoo.kim@lge.com>
M: Andrew Morton <akpm@linux-foundation.org>
M: Vlastimil Babka <vbabka@suse.cz>
L: linux-mm@kvack.org
S: Maintained
F: include/linux/sl?b*.h
@ -16710,6 +16712,8 @@ M: Samuel Thibault <samuel.thibault@ens-lyon.org>
L: speakup@linux-speakup.org
S: Odd Fixes
W: http://www.linux-speakup.org/
W: https://github.com/linux-speakup/speakup
B: https://github.com/linux-speakup/speakup/issues
F: drivers/accessibility/speakup/
SPEAR CLOCK FRAMEWORK SUPPORT
@ -16964,7 +16968,7 @@ M: Olivier Moysan <olivier.moysan@st.com>
M: Arnaud Pouliquen <arnaud.pouliquen@st.com>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/sound/st,stm32-*.txt
F: Documentation/devicetree/bindings/iio/adc/st,stm32-*.yaml
F: sound/soc/stm/
STM32 TIMER/LPTIMER DRIVERS
@ -17541,7 +17545,7 @@ F: arch/xtensa/
F: drivers/irqchip/irq-xtensa-*
TEXAS INSTRUMENTS ASoC DRIVERS
M: Peter Ujfalusi <peter.ujfalusi@ti.com>
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
F: sound/soc/ti/
@ -17553,9 +17557,22 @@ S: Supported
F: Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt
F: drivers/iio/dac/ti-dac7612.c
TEXAS INSTRUMENTS DMA DRIVERS
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
L: dmaengine@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
F: Documentation/devicetree/bindings/dma/ti-edma.txt
F: Documentation/devicetree/bindings/dma/ti/
F: drivers/dma/ti/
X: drivers/dma/ti/cppi41.c
F: include/linux/dma/k3-udma-glue.h
F: include/linux/dma/ti-cppi5.h
F: include/linux/dma/k3-psil.h
TEXAS INSTRUMENTS' SYSTEM CONTROL INTERFACE (TISCI) PROTOCOL DRIVER
M: Nishanth Menon <nm@ti.com>
M: Tero Kristo <t-kristo@ti.com>
M: Tero Kristo <kristo@kernel.org>
M: Santosh Shilimkar <ssantosh@kernel.org>
L: linux-arm-kernel@lists.infradead.org
S: Maintained
@ -17699,9 +17716,9 @@ S: Maintained
F: drivers/clk/clk-cdce706.c
TI CLOCK DRIVER
M: Tero Kristo <t-kristo@ti.com>
M: Tero Kristo <kristo@kernel.org>
L: linux-omap@vger.kernel.org
S: Maintained
S: Odd Fixes
F: drivers/clk/ti/
F: include/linux/clk/ti.h
@ -17838,7 +17855,7 @@ F: Documentation/devicetree/bindings/net/nfc/trf7970a.txt
F: drivers/nfc/trf7970a.c
TI TWL4030 SERIES SOC CODEC DRIVER
M: Peter Ujfalusi <peter.ujfalusi@ti.com>
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
F: sound/soc/codecs/twl4030*
@ -18370,7 +18387,7 @@ F: include/linux/usb/isp116x.h
USB LAN78XX ETHERNET DRIVER
M: Woojung Huh <woojung.huh@microchip.com>
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
M: UNGLinuxDriver@microchip.com
L: netdev@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/net/microchip,lan78xx.txt
@ -18404,7 +18421,7 @@ F: Documentation/usb/ohci.rst
F: drivers/usb/host/ohci*
USB OTG FSM (Finite State Machine)
M: Peter Chen <Peter.Chen@nxp.com>
M: Peter Chen <peter.chen@kernel.org>
L: linux-usb@vger.kernel.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
@ -18484,7 +18501,7 @@ F: drivers/net/usb/smsc75xx.*
USB SMSC95XX ETHERNET DRIVER
M: Steve Glendinning <steve.glendinning@shawell.net>
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
M: UNGLinuxDriver@microchip.com
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/usb/smsc95xx.*
@ -19031,7 +19048,7 @@ F: drivers/input/mouse/vmmouse.h
VMWARE VMXNET3 ETHERNET DRIVER
M: Ronak Doshi <doshir@vmware.com>
M: "VMware, Inc." <pv-drivers@vmware.com>
M: pv-drivers@vmware.com
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/vmxnet3/
@ -19058,7 +19075,6 @@ K: regulator_get_optional
VRF
M: David Ahern <dsahern@kernel.org>
M: Shrijeet Mukherjee <shrijeet@gmail.com>
L: netdev@vger.kernel.org
S: Maintained
F: Documentation/networking/vrf.rst
@ -19409,7 +19425,7 @@ F: drivers/net/ethernet/*/*/*xdp*
K: (?:\b|_)xdp(?:\b|_)
XDP SOCKETS (AF_XDP)
M: Björn Töpel <bjorn.topel@intel.com>
M: Björn Töpel <bjorn@kernel.org>
M: Magnus Karlsson <magnus.karlsson@intel.com>
R: Jonathan Lemon <jonathan.lemon@gmail.com>
L: netdev@vger.kernel.org
@ -19505,7 +19521,7 @@ F: arch/x86/xen/*swiotlb*
F: drivers/xen/*swiotlb*
XFS FILESYSTEM
M: Darrick J. Wong <darrick.wong@oracle.com>
M: Darrick J. Wong <djwong@kernel.org>
M: linux-xfs@vger.kernel.org
L: linux-xfs@vger.kernel.org
S: Supported

17
Makefile
View File

@ -2,8 +2,8 @@
VERSION = 5
PATCHLEVEL = 11
SUBLEVEL = 0
EXTRAVERSION = -rc2
NAME = Kleptomaniac Octopus
EXTRAVERSION =
NAME = 💕 Valentine's Day Edition 💕
# *DOCUMENTATION*
# To see a list of typical targets execute "make help"
@ -452,7 +452,6 @@ AWK = awk
INSTALLKERNEL := installkernel
DEPMOD = depmod
PERL = perl
PYTHON = python
PYTHON3 = python3
CHECK = sparse
BASH = bash
@ -508,7 +507,7 @@ CLANG_FLAGS :=
export ARCH SRCARCH CONFIG_SHELL BASH HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE LD CC
export CPP AR NM STRIP OBJCOPY OBJDUMP READELF PAHOLE RESOLVE_BTFIDS LEX YACC AWK INSTALLKERNEL
export PERL PYTHON PYTHON3 CHECK CHECKFLAGS MAKE UTS_MACHINE HOSTCXX
export PERL PYTHON3 CHECK CHECKFLAGS MAKE UTS_MACHINE HOSTCXX
export KGZIP KBZIP2 KLZOP LZMA LZ4 XZ ZSTD
export KBUILD_HOSTCXXFLAGS KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS LDFLAGS_MODULE
@ -812,10 +811,12 @@ KBUILD_CFLAGS += -ftrivial-auto-var-init=zero
KBUILD_CFLAGS += -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
endif
DEBUG_CFLAGS :=
# Workaround for GCC versions < 5.0
# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
ifdef CONFIG_CC_IS_GCC
DEBUG_CFLAGS := $(call cc-ifversion, -lt, 0500, $(call cc-option, -fno-var-tracking-assignments))
DEBUG_CFLAGS += $(call cc-ifversion, -lt, 0500, $(call cc-option, -fno-var-tracking-assignments))
endif
ifdef CONFIG_DEBUG_INFO
@ -948,12 +949,6 @@ KBUILD_CFLAGS += $(call cc-option,-Werror=designated-init)
# change __FILE__ to the relative path from the srctree
KBUILD_CPPFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
# ensure -fcf-protection is disabled when using retpoline as it is
# incompatible with -mindirect-branch=thunk-extern
ifdef CONFIG_RETPOLINE
KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none)
endif
# include additional Makefiles when needed
include-y := scripts/Makefile.extrawarn
include-$(CONFIG_KASAN) += scripts/Makefile.kasan

6
arch/Kconfig
View File

@ -1105,6 +1105,12 @@ config HAVE_ARCH_PFN_VALID
config ARCH_SUPPORTS_DEBUG_PAGEALLOC
bool
config ARCH_SPLIT_ARG64
bool
help
If a 32-bit architecture requires 64-bit arguments to be split into
pairs of 32-bit arguments, select this option.
source "kernel/gcov/Kconfig"
source "scripts/gcc-plugins/Kconfig"

20
arch/arc/Makefile
View File

@ -102,16 +102,22 @@ libs-y += arch/arc/lib/ $(LIBGCC)
boot := arch/arc/boot
#default target for make without any arguments.
KBUILD_IMAGE := $(boot)/bootpImage
all: bootpImage
bootpImage: vmlinux
boot_targets += uImage uImage.bin uImage.gz
boot_targets := uImage.bin uImage.gz uImage.lzma
PHONY += $(boot_targets)
$(boot_targets): vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
uimage-default-y := uImage.bin
uimage-default-$(CONFIG_KERNEL_GZIP) := uImage.gz
uimage-default-$(CONFIG_KERNEL_LZMA) := uImage.lzma
PHONY += uImage
uImage: $(uimage-default-y)
@ln -sf $< $(boot)/uImage
@$(kecho) ' Image $(boot)/uImage is ready'
CLEAN_FILES += $(boot)/uImage
archclean:
$(Q)$(MAKE) $(clean)=$(boot)

18
arch/arc/boot/Makefile
View File

@ -1,5 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
targets := vmlinux.bin vmlinux.bin.gz uImage
# uImage build relies on mkimage being availble on your host for ARC target
# You will need to build u-boot for ARC, rename mkimage to arc-elf32-mkimage
@ -7,23 +6,18 @@ targets := vmlinux.bin vmlinux.bin.gz uImage
OBJCOPYFLAGS= -O binary -R .note -R .note.gnu.build-id -R .comment -S
LINUX_START_TEXT = $$(readelf -h vmlinux | \
LINUX_START_TEXT = $$($(READELF) -h vmlinux | \
grep "Entry point address" | grep -o 0x.*)
UIMAGE_LOADADDR = $(CONFIG_LINUX_LINK_BASE)
UIMAGE_ENTRYADDR = $(LINUX_START_TEXT)
suffix-y := bin
suffix-$(CONFIG_KERNEL_GZIP) := gz
suffix-$(CONFIG_KERNEL_LZMA) := lzma
targets += uImage
targets += vmlinux.bin
targets += vmlinux.bin.gz
targets += vmlinux.bin.lzma
targets += uImage.bin
targets += uImage.gz
targets += uImage.lzma
extra-y += vmlinux.bin
extra-y += vmlinux.bin.gz
extra-y += vmlinux.bin.lzma
$(obj)/vmlinux.bin: vmlinux FORCE
$(call if_changed,objcopy)
@ -42,7 +36,3 @@ $(obj)/uImage.gz: $(obj)/vmlinux.bin.gz FORCE
$(obj)/uImage.lzma: $(obj)/vmlinux.bin.lzma FORCE
$(call if_changed,uimage,lzma)
$(obj)/uImage: $(obj)/uImage.$(suffix-y)
@ln -sf $(notdir $<) $@
@echo ' Image $@ is ready'

1
arch/arc/include/asm/page.h
View File

@ -10,6 +10,7 @@
#ifndef __ASSEMBLY__
#define clear_page(paddr) memset((paddr), 0, PAGE_SIZE)
#define copy_user_page(to, from, vaddr, pg) copy_page(to, from)
#define copy_page(to, from) memcpy((to), (from), PAGE_SIZE)
struct vm_area_struct;

2
arch/arc/kernel/entry.S
View File

@ -307,7 +307,7 @@ resume_user_mode_begin:
mov r0, sp ; pt_regs for arg to do_signal()/do_notify_resume()
GET_CURR_THR_INFO_FLAGS r9
and.f 0, r9, TIF_SIGPENDING|TIF_NOTIFY_SIGNAL
and.f 0, r9, _TIF_SIGPENDING|_TIF_NOTIFY_SIGNAL
bz .Lchk_notify_resume
; Normal Trap/IRQ entry only saves Scratch (caller-saved) regs

1
arch/arc/plat-hsdk/Kconfig
View File

@ -7,6 +7,7 @@ menuconfig ARC_SOC_HSDK
depends on ISA_ARCV2
select ARC_HAS_ACCL_REGS
select ARC_IRQ_NO_AUTOSAVE
select ARC_FPU_SAVE_RESTORE
select CLK_HSDK
select RESET_CONTROLLER
select RESET_HSDK

3
arch/arm/boot/compressed/atags_to_fdt.c
View File

@ -15,7 +15,8 @@ static int node_offset(void *fdt, const char *node_path)
{
int offset = fdt_path_offset(fdt, node_path);
if (offset == -FDT_ERR_NOTFOUND)
offset = fdt_add_subnode(fdt, 0, node_path);
/* Add the node to root if not found, dropping the leading '/' */
offset = fdt_add_subnode(fdt, 0, node_path + 1);
return offset;
}

7
arch/arm/boot/dts/imx6q-tbs2910.dts
View File

@ -16,6 +16,13 @@
stdout-path = &uart1;
};
aliases {
mmc0 = &usdhc2;
mmc1 = &usdhc3;
mmc2 = &usdhc4;
/delete-property/ mmc3;
};
memory@10000000 {
device_type = "memory";
reg = <0x10000000 0x80000000>;

2
arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
View File

@ -418,7 +418,7 @@
/* VDD_AUD_1P8: Audio codec */
reg_aud_1p8v: ldo3 {
regulator-name = "vdd1p8";
regulator-name = "vdd1p8a";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-boot-on;

6
arch/arm/boot/dts/imx6qdl-kontron-samx6i.dtsi
View File

@ -137,7 +137,7 @@
lcd_backlight: lcd-backlight {
compatible = "pwm-backlight";
pwms = <&pwm4 0 5000000>;
pwms = <&pwm4 0 5000000 0>;
pwm-names = "LCD_BKLT_PWM";
brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
@ -167,7 +167,7 @@
i2c-gpio,delay-us = <2>; /* ~100 kHz */
#address-cells = <1>;
#size-cells = <0>;
status = "disabld";
status = "disabled";
};
i2c_cam: i2c-gpio-cam {
@ -179,7 +179,7 @@
i2c-gpio,delay-us = <2>; /* ~100 kHz */
#address-cells = <1>;
#size-cells = <0>;
status = "disabld";
status = "disabled";
};
};

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