microsoft
/
WSL2-Linux-Kernel
зеркало из https://github.com/microsoft/WSL2-Linux-Kernel.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность

Linux 5.11-rc6 

-----BEGIN PGP SIGNATURE-----
 
 iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmAXJhEeHHRvcnZhbGRz
 QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGXF0H/jwVgN3VudFrc5xb
 F1KV/eLz2wp3KHCh8TrdhyItUv9qYZnwroNSFuwQsKyeOHeod192oHda9UCIoCAo
 k8aFG4iILwXfVnhNUXeLjJD7WfP7AaJZpPqn6pvzJH9ONN1GsLO41iYO/v/MKcmS
 OLPivR1/Yv3ON0SktEXK57kxGGKEcgSRRBmlouo16qhb1ME8flUphx9eLZ7uchAm
 bQ2Ui/F6TmsUD1BaPl8scC/FWbbeu5fZtAkL/VxuGGJh5Uisb/yTQluG4+mCGw4y
 zTPsHI3D59QP3YePO5cbq8h1F4V88rCt/EHn4/RmRpRgvgHT8XbvG223/CVw9h3R
 26E6z2k=
 =3w5Q
 -----END PGP SIGNATURE-----

Merge tag 'v5.11-rc6' into patchwork

Linux 5.11-rc6

* tag 'v5.11-rc6': (1466 commits)
  Linux 5.11-rc6
  leds: rt8515: Add Richtek RT8515 LED driver
  dt-bindings: leds: Add DT binding for Richtek RT8515
  leds: trigger: fix potential deadlock with libata
  leds: leds-ariel: convert comma to semicolon
  leds: leds-lm3533: convert comma to semicolon
  dt-bindings: Cleanup standard unit properties
  soc: litex: Properly depend on HAS_IOMEM
  tty: avoid using vfs_iocb_iter_write() for redirected console writes
  null_blk: cleanup zoned mode initialization
  cifs: fix dfs domain referrals
  drm/nouveau/kms/gk104-gp1xx: Fix > 64x64 cursors
  drm/nouveau/kms/nv50-: Report max cursor size to userspace
  drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes
  drm/nouveau/svm: fail NOUVEAU_SVM_INIT ioctl on unsupported devices
  drm/nouveau/dispnv50: Restore pushing of all data.
  io_uring: reinforce cancel on flush during exit
  cifs: returning mount parm processing errors correctly
  rxrpc: Fix memory leak in rxrpc_lookup_local
  mlxsw: spectrum_span: Do not overwrite policer configuration
  ...
This commit is contained in:
Mauro Carvalho Chehab 2021-02-01 10:03:45 +01:00
Родитель f0ddb4e991 1048ba83fb
Коммит 0b9112a588
1401 изменённых файлов: 15275 добавлений и 8156 удалений
Показать статистику Скачать Patch файл Скачать Diff файл Показать все файлы Свернуть все файлы

5
.mailmap
Просмотреть файл

@ -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>
@ -55,6 +52,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>

24
CREDITS
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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

8
Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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

12
Documentation/admin-guide/device-mapper/dm-integrity.rst
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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

2
Documentation/admin-guide/mm/concepts.rst
Просмотреть файл

@ -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

5
Documentation/asm-annotations.rst
Просмотреть файл

@ -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
Просмотреть файл

@ -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

27
Documentation/dev-tools/kasan.rst
Просмотреть файл

@ -160,29 +160,14 @@ 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`` for ``CONFIG_DEBUG_KERNEL=y``, otherwise
``off``).
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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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: |

2
Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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**::

4
Documentation/firmware-guide/acpi/apei/einj.rst
Просмотреть файл

@ -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
Просмотреть файл

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

2
Documentation/kbuild/makefiles.rst
Просмотреть файл

@ -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

8
Documentation/kernel-hacking/locking.rst
Просмотреть файл

@ -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
Просмотреть файл

@ -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

12
Documentation/networking/ip-sysctl.rst
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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.

110
MAINTAINERS
Просмотреть файл

@ -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*
@ -821,7 +821,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
@ -908,7 +907,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
@ -2120,7 +2119,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
@ -2943,7 +2942,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
@ -3242,6 +3240,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
@ -3337,7 +3336,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
@ -3414,7 +3413,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>
@ -3557,7 +3556,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>
@ -3882,9 +3881,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
@ -3962,7 +3961,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
@ -4164,7 +4163,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
@ -4314,7 +4313,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
@ -4589,7 +4590,7 @@ B: https://bugzilla.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
F: Documentation/admin-guide/pm/cpuidle.rst
F: Documentation/driver-api/pm/cpuidle.rst
F: drivers/cpuidle/*
F: drivers/cpuidle/
F: include/linux/cpuidle.h
CPU POWER MONITORING SUBSYSTEM
@ -4923,9 +4924,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
@ -7364,7 +7364,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
@ -8436,11 +8435,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/
@ -9243,7 +9239,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/
@ -9276,7 +9272,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
@ -9330,7 +9326,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
@ -9779,7 +9774,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>
@ -10263,7 +10258,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
@ -10850,7 +10844,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
@ -11670,7 +11664,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
@ -11680,7 +11674,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_*
@ -11774,7 +11768,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
@ -12423,8 +12417,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
@ -12480,7 +12474,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>
@ -12830,10 +12823,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/*
@ -12855,7 +12848,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
@ -13895,7 +13888,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
@ -14517,10 +14510,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
@ -14674,7 +14675,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
@ -14825,7 +14826,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
@ -16326,6 +16327,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
@ -16715,6 +16717,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
@ -16969,7 +16973,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
@ -17546,7 +17550,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/
@ -17558,6 +17562,19 @@ 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>
@ -17843,7 +17860,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*
@ -18375,7 +18392,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
@ -18409,7 +18426,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
@ -18489,7 +18506,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.*
@ -19036,7 +19053,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/
@ -19063,7 +19080,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
@ -19414,7 +19430,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
@ -19510,7 +19526,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

2
Makefile
Просмотреть файл

@ -2,7 +2,7 @@
VERSION = 5
PATCHLEVEL = 11
SUBLEVEL = 0
EXTRAVERSION = -rc1
EXTRAVERSION = -rc6
NAME = Kleptomaniac Octopus
# *DOCUMENTATION*

6
arch/Kconfig
Просмотреть файл

@ -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"

1
arch/alpha/include/asm/local64.h
Просмотреть файл

@ -1 +0,0 @@
#include <asm-generic/local64.h>

20
arch/arc/Makefile
Просмотреть файл

@ -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
Просмотреть файл

@ -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/Kbuild
Просмотреть файл

@ -1,7 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
generic-y += extable.h
generic-y += kvm_para.h
generic-y += local64.h
generic-y += mcs_spinlock.h
generic-y += parport.h
generic-y += user.h

1
arch/arc/include/asm/page.h
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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
Просмотреть файл

@ -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";
};
};

12
arch/arm/boot/dts/imx6qdl-sr-som.dtsi
Просмотреть файл

@ -53,7 +53,6 @@
&fec {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_microsom_enet_ar8035>;
phy-handle = <&phy>;
phy-mode = "rgmii-id";
phy-reset-duration = <2>;
phy-reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
@ -63,10 +62,19 @@
#address-cells = <1>;
#size-cells = <0>;
phy: ethernet-phy@0 {
/*
* The PHY can appear at either address 0 or 4 due to the
* configuration (LED) pin not being pulled sufficiently.
*/
ethernet-phy@0 {
reg = <0>;
qca,clk-out-frequency = <125000000>;
};
ethernet-phy@4 {
reg = <4>;
qca,clk-out-frequency = <125000000>;
};
};
};

1
arch/arm/boot/dts/imx7d-flex-concentrator.dts
Просмотреть файл

@ -115,6 +115,7 @@
compatible = "nxp,pcf2127";
reg = <0>;
spi-max-frequency = <2000000>;
reset-source;
};
};

8
arch/arm/boot/dts/omap3-n950-n9.dtsi
Просмотреть файл

@ -494,3 +494,11 @@
clock-names = "sysclk";
};
};
&aes1_target {
status = "disabled";
};
&aes2_target {
status = "disabled";
};

4
arch/arm/boot/dts/picoxcell-pc3x2.dtsi
Просмотреть файл

@ -45,18 +45,21 @@
emac: gem@30000 {
compatible = "cadence,gem";
reg = <0x30000 0x10000>;
interrupt-parent = <&vic0>;
interrupts = <31>;
};
dmac1: dmac@40000 {
compatible = "snps,dw-dmac";
reg = <0x40000 0x10000>;
interrupt-parent = <&vic0>;
interrupts = <25>;
};
dmac2: dmac@50000 {
compatible = "snps,dw-dmac";
reg = <0x50000 0x10000>;
interrupt-parent = <&vic0>;
interrupts = <26>;
};
@ -233,6 +236,7 @@
axi2pico@c0000000 {
compatible = "picochip,axi2pico-pc3x2";
reg = <0xc0000000 0x10000>;
interrupt-parent = <&vic0>;
interrupts = <13 14 15 16 17 18 19 20 21>;
};
};

38
arch/arm/boot/dts/ste-db8500.dtsi
Просмотреть файл

@ -12,4 +12,42 @@
200000 0>;
};
};
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
/* Modem trace memory */
ram@06000000 {
reg = <0x06000000 0x00f00000>;
no-map;
};
/* Modem shared memory */
ram@06f00000 {
reg = <0x06f00000 0x00100000>;
no-map;
};
/* Modem private memory */
ram@07000000 {
reg = <0x07000000 0x01000000>;
no-map;
};
/*
* Initial Secure Software ISSW memory
*
* This is probably only used if the kernel tries
* to actually call into trustzone to run secure
* applications, which the mainline kernel probably
* will not do on this old chipset. But you can never
* be too careful, so reserve this memory anyway.
*/
ram@17f00000 {
reg = <0x17f00000 0x00100000>;
no-map;
};
};
};

38
arch/arm/boot/dts/ste-db8520.dtsi
Просмотреть файл

@ -12,4 +12,42 @@
200000 0>;
};
};
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
/* Modem trace memory */
ram@06000000 {
reg = <0x06000000 0x00f00000>;
no-map;
};
/* Modem shared memory */
ram@06f00000 {
reg = <0x06f00000 0x00100000>;
no-map;
};
/* Modem private memory */
ram@07000000 {
reg = <0x07000000 0x01000000>;
no-map;
};
/*
* Initial Secure Software ISSW memory
*
* This is probably only used if the kernel tries
* to actually call into trustzone to run secure
* applications, which the mainline kernel probably
* will not do on this old chipset. But you can never
* be too careful, so reserve this memory anyway.
*/
ram@17f00000 {
reg = <0x17f00000 0x00100000>;
no-map;
};
};
};

35
arch/arm/boot/dts/ste-db9500.dtsi Normal file
Просмотреть файл

@ -0,0 +1,35 @@
// SPDX-License-Identifier: GPL-2.0-or-later
#include "ste-dbx5x0.dtsi"
/ {
cpus {
cpu@300 {
/* cpufreq controls */
operating-points = <1152000 0
800000 0
400000 0
200000 0>;
};
};
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
/*
* Initial Secure Software ISSW memory
*
* This is probably only used if the kernel tries
* to actually call into trustzone to run secure
* applications, which the mainline kernel probably
* will not do on this old chipset. But you can never
* be too careful, so reserve this memory anyway.
*/
ram@17f00000 {
reg = <0x17f00000 0x00100000>;
no-map;
};
};
};

2
arch/arm/boot/dts/ste-snowball.dts
Просмотреть файл

@ -4,7 +4,7 @@
*/
/dts-v1/;
#include "ste-db8500.dtsi"
#include "ste-db9500.dtsi"
#include "ste-href-ab8500.dtsi"
#include "ste-href-family-pinctrl.dtsi"

1
arch/arm/boot/dts/ste-ux500-samsung-golden.dts
Просмотреть файл

@ -329,6 +329,7 @@
panel@0 {
compatible = "samsung,s6e63m0";
reg = <0>;
max-brightness = <15>;
vdd3-supply = <&panel_reg_3v0>;
vci-supply = <&panel_reg_1v8>;
reset-gpios = <&gpio4 11 GPIO_ACTIVE_LOW>;

2
arch/arm/configs/omap2plus_defconfig
Просмотреть файл

@ -279,6 +279,7 @@ CONFIG_SERIAL_OMAP_CONSOLE=y
CONFIG_SERIAL_DEV_BUS=y
CONFIG_I2C_CHARDEV=y
CONFIG_SPI=y
CONFIG_SPI_GPIO=m
CONFIG_SPI_OMAP24XX=y
CONFIG_SPI_TI_QSPI=m
CONFIG_HSI=m
@ -296,7 +297,6 @@ CONFIG_GPIO_TWL4030=y
CONFIG_W1=m
CONFIG_HDQ_MASTER_OMAP=m
CONFIG_W1_SLAVE_DS250X=m
CONFIG_POWER_AVS=y
CONFIG_POWER_RESET=y
CONFIG_POWER_RESET_GPIO=y
CONFIG_BATTERY_BQ27XXX=m

Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше