mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
synced 2024-12-28 16:52:18 +00:00
Linux 6.12-rc7
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmcxMXceHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiG1IgH/A3O7KIy/VR7D7O3
usbLqk1V+YWs/NsVdewEL/SYfXjCxqnejdk/AvN3ZAIxFeMHhAmcSCKno3zKgK9L
ML4kDrz22dPlA0XncNM8qKTCqAMgXTur1wafv3NAjutg0D3eHvAp0BW0GO5px93G
+kt3kOY32UaB+2Fl1GIub777pRi5U4u5AboQTu3x0TdRZJtV1pqgeddGoymNn6mi
xmMVbY3r5MXJQyHntoT9FIuxK3d+jGcgRHP5RWr53+vAUEFdlXiGcJV4dUXsuQNa
sEKJutCaUqQeiamjoo4bRZO7/2OAPX9Sv7sNIXD/irZZJmCcWr+GDCcUmL69Mjg7
7mx6XrM=
=HYUx
-----END PGP SIGNATURE-----
Merge tag 'v6.12-rc7' into __tmp-hansg-linux-tags_media_atomisp_6_13_1
Linux 6.12-rc7
* tag 'v6.12-rc7': (1909 commits)
Linux 6.12-rc7
filemap: Fix bounds checking in filemap_read()
i2c: designware: do not hold SCL low when I2C_DYNAMIC_TAR_UPDATE is not set
mailmap: add entry for Thorsten Blum
ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()
signal: restore the override_rlimit logic
fs/proc: fix compile warning about variable 'vmcore_mmap_ops'
ucounts: fix counter leak in inc_rlimit_get_ucounts()
selftests: hugetlb_dio: check for initial conditions to skip in the start
mm: fix docs for the kernel parameter ``thp_anon=``
mm/damon/core: avoid overflow in damon_feed_loop_next_input()
mm/damon/core: handle zero schemes apply interval
mm/damon/core: handle zero {aggregation,ops_update} intervals
mm/mlock: set the correct prev on failure
objpool: fix to make percpu slot allocation more robust
mm/page_alloc: keep track of free highatomic
bcachefs: Fix UAF in __promote_alloc() error path
bcachefs: Change OPT_STR max to be 1 less than the size of choices array
bcachefs: btree_cache.freeable list fixes
bcachefs: check the invalid parameter for perf test
...
This commit is contained in:
Mauro Carvalho Chehab
commit
5516200c46
17
.mailmap
17
.mailmap
@ -74,6 +74,8 @@ Andrey Ryabinin <ryabinin.a.a@gmail.com> <aryabinin@virtuozzo.com>
|
||||
Andrzej Hajda <andrzej.hajda@intel.com> <a.hajda@samsung.com>
|
||||
André Almeida <andrealmeid@igalia.com> <andrealmeid@collabora.com>
|
||||
Andy Adamson <andros@citi.umich.edu>
|
||||
Andy Chiu <andybnac@gmail.com> <andy.chiu@sifive.com>
|
||||
Andy Chiu <andybnac@gmail.com> <taochiu@synology.com>
|
||||
Andy Shevchenko <andy@kernel.org> <andy@smile.org.ua>
|
||||
Andy Shevchenko <andy@kernel.org> <ext-andriy.shevchenko@nokia.com>
|
||||
Anilkumar Kolli <quic_akolli@quicinc.com> <akolli@codeaurora.org>
|
||||
@ -198,18 +200,23 @@ Elliot Berman <quic_eberman@quicinc.com> <eberman@codeaurora.org>
|
||||
Enric Balletbo i Serra <eballetbo@kernel.org> <enric.balletbo@collabora.com>
|
||||
Enric Balletbo i Serra <eballetbo@kernel.org> <eballetbo@iseebcn.com>
|
||||
Erik Kaneda <erik.kaneda@intel.com> <erik.schmauss@intel.com>
|
||||
Eugen Hristev <eugen.hristev@collabora.com> <eugen.hristev@microchip.com>
|
||||
Eugen Hristev <eugen.hristev@linaro.org> <eugen.hristev@microchip.com>
|
||||
Eugen Hristev <eugen.hristev@linaro.org> <eugen.hristev@collabora.com>
|
||||
Evgeniy Polyakov <johnpol@2ka.mipt.ru>
|
||||
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> <ezequiel@collabora.com>
|
||||
Faith Ekstrand <faith.ekstrand@collabora.com> <jason@jlekstrand.net>
|
||||
Faith Ekstrand <faith.ekstrand@collabora.com> <jason.ekstrand@intel.com>
|
||||
Faith Ekstrand <faith.ekstrand@collabora.com> <jason.ekstrand@collabora.com>
|
||||
Fangrui Song <i@maskray.me> <maskray@google.com>
|
||||
Felipe W Damasio <felipewd@terra.com.br>
|
||||
Felix Kuhling <fxkuehl@gmx.de>
|
||||
Felix Moeller <felix@derklecks.de>
|
||||
Fenglin Wu <quic_fenglinw@quicinc.com> <fenglinw@codeaurora.org>
|
||||
Filipe Lautert <filipe@icewall.org>
|
||||
Finn Thain <fthain@linux-m68k.org> <fthain@telegraphics.com.au>
|
||||
Fiona Behrens <me@kloenk.dev>
|
||||
Fiona Behrens <me@kloenk.dev> <me@kloenk.de>
|
||||
Fiona Behrens <me@kloenk.dev> <fin@nyantec.com>
|
||||
Franck Bui-Huu <vagabon.xyz@gmail.com>
|
||||
Frank Rowand <frowand.list@gmail.com> <frank.rowand@am.sony.com>
|
||||
Frank Rowand <frowand.list@gmail.com> <frank.rowand@sony.com>
|
||||
@ -280,7 +287,7 @@ Jan Glauber <jan.glauber@gmail.com> <jglauber@cavium.com>
|
||||
Jan Kuliga <jtkuliga.kdev@gmail.com> <jankul@alatek.krakow.pl>
|
||||
Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@linux.intel.com>
|
||||
Jarkko Sakkinen <jarkko@kernel.org> <jarkko@profian.com>
|
||||
Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@tuni.fi>
|
||||
Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@parity.io>
|
||||
Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com>
|
||||
Jason Gunthorpe <jgg@ziepe.ca> <jgg@nvidia.com>
|
||||
Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
|
||||
@ -304,6 +311,11 @@ Jens Axboe <axboe@kernel.dk> <axboe@fb.com>
|
||||
Jens Axboe <axboe@kernel.dk> <axboe@meta.com>
|
||||
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
|
||||
Jernej Skrabec <jernej.skrabec@gmail.com> <jernej.skrabec@siol.net>
|
||||
Jesper Dangaard Brouer <hawk@kernel.org> <brouer@redhat.com>
|
||||
Jesper Dangaard Brouer <hawk@kernel.org> <hawk@comx.dk>
|
||||
Jesper Dangaard Brouer <hawk@kernel.org> <jbrouer@redhat.com>
|
||||
Jesper Dangaard Brouer <hawk@kernel.org> <jdb@comx.dk>
|
||||
Jesper Dangaard Brouer <hawk@kernel.org> <netoptimizer@brouer.com>
|
||||
Jessica Zhang <quic_jesszhan@quicinc.com> <jesszhan@codeaurora.org>
|
||||
Jilai Wang <quic_jilaiw@quicinc.com> <jilaiw@codeaurora.org>
|
||||
Jiri Kosina <jikos@kernel.org> <jikos@jikos.cz>
|
||||
@ -657,6 +669,7 @@ Tomeu Vizoso <tomeu@tomeuvizoso.net> <tomeu.vizoso@collabora.com>
|
||||
Thomas Graf <tgraf@suug.ch>
|
||||
Thomas Körper <socketcan@esd.eu> <thomas.koerper@esd.eu>
|
||||
Thomas Pedersen <twp@codeaurora.org>
|
||||
Thorsten Blum <thorsten.blum@linux.dev> <thorsten.blum@toblux.com>
|
||||
Tiezhu Yang <yangtiezhu@loongson.cn> <kernelpatch@126.com>
|
||||
Tingwei Zhang <quic_tingwei@quicinc.com> <tingwei@codeaurora.org>
|
||||
Tirupathi Reddy <quic_tirupath@quicinc.com> <tirupath@codeaurora.org>
|
||||
|
||||
58
CREDITS
58
CREDITS
@ -1204,6 +1204,10 @@ S: Dreisbachstrasse 24
|
||||
S: D-57250 Netphen
|
||||
S: Germany
|
||||
|
||||
N: Florian Fainelli
|
||||
E: f.fainelli@gmail.com
|
||||
D: DSA
|
||||
|
||||
N: Rik Faith
|
||||
E: faith@acm.org
|
||||
D: Future Domain TMC-16x0 SCSI driver (author)
|
||||
@ -1358,10 +1362,6 @@ 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
|
||||
@ -1677,11 +1677,6 @@ W: http://www.carumba.com/
|
||||
D: bug toaster (A1 sauce makes all the difference)
|
||||
D: Random linux hacker
|
||||
|
||||
N: James Hogan
|
||||
E: jhogan@kernel.org
|
||||
D: Metag architecture maintainer
|
||||
D: TZ1090 SoC maintainer
|
||||
|
||||
N: Tim Hockin
|
||||
E: thockin@hockin.org
|
||||
W: http://www.hockin.org/~thockin
|
||||
@ -1697,6 +1692,11 @@ D: hwmon subsystem maintainer
|
||||
D: i2c-sis96x and i2c-stub SMBus drivers
|
||||
S: USA
|
||||
|
||||
N: James Hogan
|
||||
E: jhogan@kernel.org
|
||||
D: Metag architecture maintainer
|
||||
D: TZ1090 SoC maintainer
|
||||
|
||||
N: Dirk Hohndel
|
||||
E: hohndel@suse.de
|
||||
D: The XFree86[tm] Project
|
||||
@ -1872,6 +1872,10 @@ S: K osmidomkum 723
|
||||
S: 160 00 Praha 6
|
||||
S: Czech Republic
|
||||
|
||||
N: Seth Jennings
|
||||
E: sjenning@redhat.com
|
||||
D: Creation and maintenance of zswap
|
||||
|
||||
N: Jeremy Kerr
|
||||
D: Maintainer of SPU File System
|
||||
|
||||
@ -2188,19 +2192,6 @@ N: Mike Kravetz
|
||||
E: mike.kravetz@oracle.com
|
||||
D: Maintenance and development of the hugetlb subsystem
|
||||
|
||||
N: Seth Jennings
|
||||
E: sjenning@redhat.com
|
||||
D: Creation and maintenance of zswap
|
||||
|
||||
N: Dan Streetman
|
||||
E: ddstreet@ieee.org
|
||||
D: Maintenance and development of zswap
|
||||
D: Creation and maintenance of the zpool API
|
||||
|
||||
N: Vitaly Wool
|
||||
E: vitaly.wool@konsulko.com
|
||||
D: Maintenance and development of zswap
|
||||
|
||||
N: Andreas S. Krebs
|
||||
E: akrebs@altavista.net
|
||||
D: CYPRESS CY82C693 chipset IDE, Digital's PC-Alpha 164SX boards
|
||||
@ -3191,6 +3182,11 @@ N: Ken Pizzini
|
||||
E: ken@halcyon.com
|
||||
D: CDROM driver "sonycd535" (Sony CDU-535/531)
|
||||
|
||||
N: Mathieu Poirier
|
||||
E: mathieu.poirier@linaro.org
|
||||
D: CoreSight kernel subsystem, Maintainer 2014-2022
|
||||
D: Perf tool support for CoreSight
|
||||
|
||||
N: Stelian Pop
|
||||
E: stelian@popies.net
|
||||
P: 1024D/EDBB6147 7B36 0E07 04BC 11DC A7A0 D3F7 7185 9E7A EDBB 6147
|
||||
@ -3300,6 +3296,10 @@ S: Schlossbergring 9
|
||||
S: 79098 Freiburg
|
||||
S: Germany
|
||||
|
||||
N: Gerrit Renker
|
||||
E: gerrit@erg.abdn.ac.uk
|
||||
D: DCCP protocol support.
|
||||
|
||||
N: Thomas Renninger
|
||||
E: trenn@suse.de
|
||||
D: cpupowerutils
|
||||
@ -3576,11 +3576,6 @@ D: several improvements to system programs
|
||||
S: Oldenburg
|
||||
S: Germany
|
||||
|
||||
N: Mathieu Poirier
|
||||
E: mathieu.poirier@linaro.org
|
||||
D: CoreSight kernel subsystem, Maintainer 2014-2022
|
||||
D: Perf tool support for CoreSight
|
||||
|
||||
N: Robert Schwebel
|
||||
E: robert@schwebel.de
|
||||
W: https://www.schwebel.de
|
||||
@ -3771,6 +3766,11 @@ S: Chr. Winthersvej 1 B, st.th.
|
||||
S: DK-1860 Frederiksberg C
|
||||
S: Denmark
|
||||
|
||||
N: Dan Streetman
|
||||
E: ddstreet@ieee.org
|
||||
D: Maintenance and development of zswap
|
||||
D: Creation and maintenance of the zpool API
|
||||
|
||||
N: Drew Sullivan
|
||||
E: drew@ss.org
|
||||
W: http://www.ss.org/
|
||||
@ -4286,6 +4286,10 @@ S: Pipers Way
|
||||
S: Swindon. SN3 1RJ
|
||||
S: England
|
||||
|
||||
N: Vitaly Wool
|
||||
E: vitaly.wool@konsulko.com
|
||||
D: Maintenance and development of zswap
|
||||
|
||||
N: Chris Wright
|
||||
E: chrisw@sous-sol.org
|
||||
D: hacking on LSM framework and security modules.
|
||||
|
||||
@ -223,7 +223,10 @@ are signed through the PKCS#7 message format to enforce some level of
|
||||
authorization of the policies (prohibiting an attacker from gaining
|
||||
unconstrained root, and deploying an "allow all" policy). These
|
||||
policies must be signed by a certificate that chains to the
|
||||
``SYSTEM_TRUSTED_KEYRING``. With openssl, the policy can be signed by::
|
||||
``SYSTEM_TRUSTED_KEYRING``, or to the secondary and/or platform keyrings if
|
||||
``CONFIG_IPE_POLICY_SIG_SECONDARY_KEYRING`` and/or
|
||||
``CONFIG_IPE_POLICY_SIG_PLATFORM_KEYRING`` are enabled, respectively.
|
||||
With openssl, the policy can be signed by::
|
||||
|
||||
openssl smime -sign \
|
||||
-in "$MY_POLICY" \
|
||||
@ -266,7 +269,7 @@ in the kernel. This file is write-only and accepts a PKCS#7 signed
|
||||
policy. Two checks will always be performed on this policy: First, the
|
||||
``policy_names`` must match with the updated version and the existing
|
||||
version. Second the updated policy must have a policy version greater than
|
||||
or equal to the currently-running version. This is to prevent rollback attacks.
|
||||
the currently-running version. This is to prevent rollback attacks.
|
||||
|
||||
The ``delete`` file is used to remove a policy that is no longer needed.
|
||||
This file is write-only and accepts a value of ``1`` to delete the policy.
|
||||
|
||||
@ -6688,7 +6688,7 @@
|
||||
0: no polling (default)
|
||||
|
||||
thp_anon= [KNL]
|
||||
Format: <size>,<size>[KMG]:<state>;<size>-<size>[KMG]:<state>
|
||||
Format: <size>[KMG],<size>[KMG]:<state>;<size>[KMG]-<size>[KMG]:<state>
|
||||
state is one of "always", "madvise", "never" or "inherit".
|
||||
Control the default behavior of the system with respect
|
||||
to anonymous transparent hugepages.
|
||||
|
||||
@ -303,7 +303,7 @@ control by passing the parameter ``transparent_hugepage=always`` or
|
||||
kernel command line.
|
||||
|
||||
Alternatively, each supported anonymous THP size can be controlled by
|
||||
passing ``thp_anon=<size>,<size>[KMG]:<state>;<size>-<size>[KMG]:<state>``,
|
||||
passing ``thp_anon=<size>[KMG],<size>[KMG]:<state>;<size>[KMG]-<size>[KMG]:<state>``,
|
||||
where ``<size>`` is the THP size (must be a power of 2 of PAGE_SIZE and
|
||||
supported anonymous THP) and ``<state>`` is one of ``always``, ``madvise``,
|
||||
``never`` or ``inherit``.
|
||||
|
||||
@ -425,8 +425,8 @@ This governor exposes only one tunable:
|
||||
|
||||
``rate_limit_us``
|
||||
Minimum time (in microseconds) that has to pass between two consecutive
|
||||
runs of governor computations (default: 1000 times the scaling driver's
|
||||
transition latency).
|
||||
runs of governor computations (default: 1.5 times the scaling driver's
|
||||
transition latency or the maximum 2ms).
|
||||
|
||||
The purpose of this tunable is to reduce the scheduler context overhead
|
||||
of the governor which might be excessive without it.
|
||||
@ -474,17 +474,17 @@ This governor exposes the following tunables:
|
||||
This is how often the governor's worker routine should run, in
|
||||
microseconds.
|
||||
|
||||
Typically, it is set to values of the order of 10000 (10 ms). Its
|
||||
default value is equal to the value of ``cpuinfo_transition_latency``
|
||||
for each policy this governor is attached to (but since the unit here
|
||||
is greater by 1000, this means that the time represented by
|
||||
``sampling_rate`` is 1000 times greater than the transition latency by
|
||||
default).
|
||||
Typically, it is set to values of the order of 2000 (2 ms). Its
|
||||
default value is to add a 50% breathing room
|
||||
to ``cpuinfo_transition_latency`` on each policy this governor is
|
||||
attached to. The minimum is typically the length of two scheduler
|
||||
ticks.
|
||||
|
||||
If this tunable is per-policy, the following shell command sets the time
|
||||
represented by it to be 750 times as high as the transition latency::
|
||||
represented by it to be 1.5 times as high as the transition latency
|
||||
(the default)::
|
||||
|
||||
# echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) > ondemand/sampling_rate
|
||||
# echo `$(($(cat cpuinfo_transition_latency) * 3 / 2)) > ondemand/sampling_rate
|
||||
|
||||
``up_threshold``
|
||||
If the estimated CPU load is above this value (in percent), the governor
|
||||
|
||||
@ -12,7 +12,7 @@ ones.
|
||||
|
||||
Of course this is a bad idea to rely on the alignment trap to perform
|
||||
unaligned memory access in general. If those access are predictable, you
|
||||
are better to use the macros provided by include/asm/unaligned.h. The
|
||||
are better to use the macros provided by include/linux/unaligned.h. The
|
||||
alignment trap can fixup misaligned access for the exception cases, but at
|
||||
a high performance cost. It better be rare.
|
||||
|
||||
|
||||
@ -146,6 +146,8 @@ stable kernels.
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A715 | #2645198 | ARM64_ERRATUM_2645198 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A715 | #3456084 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A720 | #3456091 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A725 | #3456106 | ARM64_ERRATUM_3194386 |
|
||||
@ -186,6 +188,8 @@ stable kernels.
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N2 | #3324339 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N3 | #3456111 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V1 | #1619801 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V1 | #3324341 | ARM64_ERRATUM_3194386 |
|
||||
@ -289,3 +293,5 @@ stable kernels.
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Microsoft | Azure Cobalt 100| #2253138 | ARM64_ERRATUM_2253138 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Microsoft | Azure Cobalt 100| #3324339 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
|
||||
212
Documentation/core-api/folio_queue.rst
Normal file
212
Documentation/core-api/folio_queue.rst
Normal file
@ -0,0 +1,212 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
|
||||
===========
|
||||
Folio Queue
|
||||
===========
|
||||
|
||||
:Author: David Howells <dhowells@redhat.com>
|
||||
|
||||
.. Contents:
|
||||
|
||||
* Overview
|
||||
* Initialisation
|
||||
* Adding and removing folios
|
||||
* Querying information about a folio
|
||||
* Querying information about a folio_queue
|
||||
* Folio queue iteration
|
||||
* Folio marks
|
||||
* Lockless simultaneous production/consumption issues
|
||||
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
The folio_queue struct forms a single segment in a segmented list of folios
|
||||
that can be used to form an I/O buffer. As such, the list can be iterated over
|
||||
using the ITER_FOLIOQ iov_iter type.
|
||||
|
||||
The publicly accessible members of the structure are::
|
||||
|
||||
struct folio_queue {
|
||||
struct folio_queue *next;
|
||||
struct folio_queue *prev;
|
||||
...
|
||||
};
|
||||
|
||||
A pair of pointers are provided, ``next`` and ``prev``, that point to the
|
||||
segments on either side of the segment being accessed. Whilst this is a
|
||||
doubly-linked list, it is intentionally not a circular list; the outward
|
||||
sibling pointers in terminal segments should be NULL.
|
||||
|
||||
Each segment in the list also stores:
|
||||
|
||||
* an ordered sequence of folio pointers,
|
||||
* the size of each folio and
|
||||
* three 1-bit marks per folio,
|
||||
|
||||
but hese should not be accessed directly as the underlying data structure may
|
||||
change, but rather the access functions outlined below should be used.
|
||||
|
||||
The facility can be made accessible by::
|
||||
|
||||
#include <linux/folio_queue.h>
|
||||
|
||||
and to use the iterator::
|
||||
|
||||
#include <linux/uio.h>
|
||||
|
||||
|
||||
Initialisation
|
||||
==============
|
||||
|
||||
A segment should be initialised by calling::
|
||||
|
||||
void folioq_init(struct folio_queue *folioq);
|
||||
|
||||
with a pointer to the segment to be initialised. Note that this will not
|
||||
necessarily initialise all the folio pointers, so care must be taken to check
|
||||
the number of folios added.
|
||||
|
||||
|
||||
Adding and removing folios
|
||||
==========================
|
||||
|
||||
Folios can be set in the next unused slot in a segment struct by calling one
|
||||
of::
|
||||
|
||||
unsigned int folioq_append(struct folio_queue *folioq,
|
||||
struct folio *folio);
|
||||
|
||||
unsigned int folioq_append_mark(struct folio_queue *folioq,
|
||||
struct folio *folio);
|
||||
|
||||
Both functions update the stored folio count, store the folio and note its
|
||||
size. The second function also sets the first mark for the folio added. Both
|
||||
functions return the number of the slot used. [!] Note that no attempt is made
|
||||
to check that the capacity wasn't overrun and the list will not be extended
|
||||
automatically.
|
||||
|
||||
A folio can be excised by calling::
|
||||
|
||||
void folioq_clear(struct folio_queue *folioq, unsigned int slot);
|
||||
|
||||
This clears the slot in the array and also clears all the marks for that folio,
|
||||
but doesn't change the folio count - so future accesses of that slot must check
|
||||
if the slot is occupied.
|
||||
|
||||
|
||||
Querying information about a folio
|
||||
==================================
|
||||
|
||||
Information about the folio in a particular slot may be queried by the
|
||||
following function::
|
||||
|
||||
struct folio *folioq_folio(const struct folio_queue *folioq,
|
||||
unsigned int slot);
|
||||
|
||||
If a folio has not yet been set in that slot, this may yield an undefined
|
||||
pointer. The size of the folio in a slot may be queried with either of::
|
||||
|
||||
unsigned int folioq_folio_order(const struct folio_queue *folioq,
|
||||
unsigned int slot);
|
||||
|
||||
size_t folioq_folio_size(const struct folio_queue *folioq,
|
||||
unsigned int slot);
|
||||
|
||||
The first function returns the size as an order and the second as a number of
|
||||
bytes.
|
||||
|
||||
|
||||
Querying information about a folio_queue
|
||||
========================================
|
||||
|
||||
Information may be retrieved about a particular segment with the following
|
||||
functions::
|
||||
|
||||
unsigned int folioq_nr_slots(const struct folio_queue *folioq);
|
||||
|
||||
unsigned int folioq_count(struct folio_queue *folioq);
|
||||
|
||||
bool folioq_full(struct folio_queue *folioq);
|
||||
|
||||
The first function returns the maximum capacity of a segment. It must not be
|
||||
assumed that this won't vary between segments. The second returns the number
|
||||
of folios added to a segments and the third is a shorthand to indicate if the
|
||||
segment has been filled to capacity.
|
||||
|
||||
Not that the count and fullness are not affected by clearing folios from the
|
||||
segment. These are more about indicating how many slots in the array have been
|
||||
initialised, and it assumed that slots won't get reused, but rather the segment
|
||||
will get discarded as the queue is consumed.
|
||||
|
||||
|
||||
Folio marks
|
||||
===========
|
||||
|
||||
Folios within a queue can also have marks assigned to them. These marks can be
|
||||
used to note information such as if a folio needs folio_put() calling upon it.
|
||||
There are three marks available to be set for each folio.
|
||||
|
||||
The marks can be set by::
|
||||
|
||||
void folioq_mark(struct folio_queue *folioq, unsigned int slot);
|
||||
void folioq_mark2(struct folio_queue *folioq, unsigned int slot);
|
||||
void folioq_mark3(struct folio_queue *folioq, unsigned int slot);
|
||||
|
||||
Cleared by::
|
||||
|
||||
void folioq_unmark(struct folio_queue *folioq, unsigned int slot);
|
||||
void folioq_unmark2(struct folio_queue *folioq, unsigned int slot);
|
||||
void folioq_unmark3(struct folio_queue *folioq, unsigned int slot);
|
||||
|
||||
And the marks can be queried by::
|
||||
|
||||
bool folioq_is_marked(const struct folio_queue *folioq, unsigned int slot);
|
||||
bool folioq_is_marked2(const struct folio_queue *folioq, unsigned int slot);
|
||||
bool folioq_is_marked3(const struct folio_queue *folioq, unsigned int slot);
|
||||
|
||||
The marks can be used for any purpose and are not interpreted by this API.
|
||||
|
||||
|
||||
Folio queue iteration
|
||||
=====================
|
||||
|
||||
A list of segments may be iterated over using the I/O iterator facility using
|
||||
an ``iov_iter`` iterator of ``ITER_FOLIOQ`` type. The iterator may be
|
||||
initialised with::
|
||||
|
||||
void iov_iter_folio_queue(struct iov_iter *i, unsigned int direction,
|
||||
const struct folio_queue *folioq,
|
||||
unsigned int first_slot, unsigned int offset,
|
||||
size_t count);
|
||||
|
||||
This may be told to start at a particular segment, slot and offset within a
|
||||
queue. The iov iterator functions will follow the next pointers when advancing
|
||||
and prev pointers when reverting when needed.
|
||||
|
||||
|
||||
Lockless simultaneous production/consumption issues
|
||||
===================================================
|
||||
|
||||
If properly managed, the list can be extended by the producer at the head end
|
||||
and shortened by the consumer at the tail end simultaneously without the need
|
||||
to take locks. The ITER_FOLIOQ iterator inserts appropriate barriers to aid
|
||||
with this.
|
||||
|
||||
Care must be taken when simultaneously producing and consuming a list. If the
|
||||
last segment is reached and the folios it refers to are entirely consumed by
|
||||
the IOV iterators, an iov_iter struct will be left pointing to the last segment
|
||||
with a slot number equal to the capacity of that segment. The iterator will
|
||||
try to continue on from this if there's another segment available when it is
|
||||
used again, but care must be taken lest the segment got removed and freed by
|
||||
the consumer before the iterator was advanced.
|
||||
|
||||
It is recommended that the queue always contain at least one segment, even if
|
||||
that segment has never been filled or is entirely spent. This prevents the
|
||||
head and tail pointers from collapsing.
|
||||
|
||||
|
||||
API Function Reference
|
||||
======================
|
||||
|
||||
.. kernel-doc:: include/linux/folio_queue.h
|
||||
@ -37,6 +37,7 @@ Library functionality that is used throughout the kernel.
|
||||
kref
|
||||
cleanup
|
||||
assoc_array
|
||||
folio_queue
|
||||
xarray
|
||||
maple_tree
|
||||
idr
|
||||
|
||||
@ -12,7 +12,10 @@ Pkeys Userspace (PKU) is a feature which can be found on:
|
||||
* Intel server CPUs, Skylake and later
|
||||
* Intel client CPUs, Tiger Lake (11th Gen Core) and later
|
||||
* Future AMD CPUs
|
||||
* arm64 CPUs implementing the Permission Overlay Extension (FEAT_S1POE)
|
||||
|
||||
x86_64
|
||||
======
|
||||
Pkeys work by dedicating 4 previously Reserved bits in each page table entry to
|
||||
a "protection key", giving 16 possible keys.
|
||||
|
||||
@ -28,6 +31,22 @@ register. The feature is only available in 64-bit mode, even though there is
|
||||
theoretically space in the PAE PTEs. These permissions are enforced on data
|
||||
access only and have no effect on instruction fetches.
|
||||
|
||||
arm64
|
||||
=====
|
||||
|
||||
Pkeys use 3 bits in each page table entry, to encode a "protection key index",
|
||||
giving 8 possible keys.
|
||||
|
||||
Protections for each key are defined with a per-CPU user-writable system
|
||||
register (POR_EL0). This is a 64-bit register encoding read, write and execute
|
||||
overlay permissions for each protection key index.
|
||||
|
||||
Being a CPU register, POR_EL0 is inherently thread-local, potentially giving
|
||||
each thread a different set of protections from every other thread.
|
||||
|
||||
Unlike x86_64, the protection key permissions also apply to instruction
|
||||
fetches.
|
||||
|
||||
Syscalls
|
||||
========
|
||||
|
||||
@ -38,11 +57,10 @@ There are 3 system calls which directly interact with pkeys::
|
||||
int pkey_mprotect(unsigned long start, size_t len,
|
||||
unsigned long prot, int pkey);
|
||||
|
||||
Before a pkey can be used, it must first be allocated with
|
||||
pkey_alloc(). An application calls the WRPKRU instruction
|
||||
directly in order to change access permissions to memory covered
|
||||
with a key. In this example WRPKRU is wrapped by a C function
|
||||
called pkey_set().
|
||||
Before a pkey can be used, it must first be allocated with pkey_alloc(). An
|
||||
application writes to the architecture specific CPU register directly in order
|
||||
to change access permissions to memory covered with a key. In this example
|
||||
this is wrapped by a C function called pkey_set().
|
||||
::
|
||||
|
||||
int real_prot = PROT_READ|PROT_WRITE;
|
||||
@ -64,9 +82,9 @@ is no longer in use::
|
||||
munmap(ptr, PAGE_SIZE);
|
||||
pkey_free(pkey);
|
||||
|
||||
.. note:: pkey_set() is a wrapper for the RDPKRU and WRPKRU instructions.
|
||||
An example implementation can be found in
|
||||
tools/testing/selftests/x86/protection_keys.c.
|
||||
.. note:: pkey_set() is a wrapper around writing to the CPU register.
|
||||
Example implementations can be found in
|
||||
tools/testing/selftests/mm/pkey-{arm64,powerpc,x86}.h
|
||||
|
||||
Behavior
|
||||
========
|
||||
@ -96,3 +114,7 @@ with a read()::
|
||||
The kernel will send a SIGSEGV in both cases, but si_code will be set
|
||||
to SEGV_PKERR when violating protection keys versus SEGV_ACCERR when
|
||||
the plain mprotect() permissions are violated.
|
||||
|
||||
Note that kernel accesses from a kthread (such as io_uring) will use a default
|
||||
value for the protection key register and so will not be consistent with
|
||||
userspace's value of the register or mprotect().
|
||||
|
||||
@ -203,7 +203,7 @@ Avoiding unaligned accesses
|
||||
===========================
|
||||
|
||||
The easiest way to avoid unaligned access is to use the get_unaligned() and
|
||||
put_unaligned() macros provided by the <asm/unaligned.h> header file.
|
||||
put_unaligned() macros provided by the <linux/unaligned.h> header file.
|
||||
|
||||
Going back to an earlier example of code that potentially causes unaligned
|
||||
access::
|
||||
|
||||
@ -0,0 +1,54 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/elgin,jg10309-01.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Elgin JG10309-01 SPI-controlled display
|
||||
|
||||
maintainers:
|
||||
- Fabio Estevam <festevam@gmail.com>
|
||||
|
||||
description: |
|
||||
The Elgin JG10309-01 SPI-controlled display is used on the RV1108-Elgin-r1
|
||||
board and is a custom display.
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: elgin,jg10309-01
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
spi-max-frequency:
|
||||
maximum: 24000000
|
||||
|
||||
spi-cpha: true
|
||||
|
||||
spi-cpol: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- spi-cpha
|
||||
- spi-cpol
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
spi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
display@0 {
|
||||
compatible = "elgin,jg10309-01";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <24000000>;
|
||||
spi-cpha;
|
||||
spi-cpol;
|
||||
};
|
||||
};
|
||||
@ -63,6 +63,16 @@ properties:
|
||||
- const: sleep
|
||||
|
||||
power-domains:
|
||||
description: |
|
||||
The MediaTek DPI module is typically associated with one of the
|
||||
following multimedia power domains:
|
||||
POWER_DOMAIN_DISPLAY
|
||||
POWER_DOMAIN_VDOSYS
|
||||
POWER_DOMAIN_MM
|
||||
The specific power domain used varies depending on the SoC design.
|
||||
|
||||
It is recommended to explicitly add the appropriate power domain
|
||||
property to the DPI node in the device tree.
|
||||
maxItems: 1
|
||||
|
||||
port:
|
||||
@ -79,20 +89,6 @@ required:
|
||||
- clock-names
|
||||
- port
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
not:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- mediatek,mt6795-dpi
|
||||
- mediatek,mt8173-dpi
|
||||
- mediatek,mt8186-dpi
|
||||
then:
|
||||
properties:
|
||||
power-domains: false
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
|
||||
@ -38,6 +38,7 @@ properties:
|
||||
description: A phandle and PM domain specifier as defined by bindings of
|
||||
the power controller specified by phandle. See
|
||||
Documentation/devicetree/bindings/power/power-domain.yaml for details.
|
||||
maxItems: 1
|
||||
|
||||
mediatek,gce-client-reg:
|
||||
description:
|
||||
@ -57,6 +58,9 @@ properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: SPLIT Clock
|
||||
- description: Used for interfacing with the HDMI RX signal source.
|
||||
- description: Paired with receiving HDMI RX metadata.
|
||||
minItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
@ -72,9 +76,24 @@ allOf:
|
||||
const: mediatek,mt8195-mdp3-split
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
minItems: 3
|
||||
|
||||
required:
|
||||
- mediatek,gce-client-reg
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: mediatek,mt8173-disp-split
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
|
||||
@ -124,7 +124,7 @@ properties:
|
||||
atomic mode of operation, even if requested.
|
||||
default: 0
|
||||
|
||||
max-rx-timeout-ms:
|
||||
arm,max-rx-timeout-ms:
|
||||
description:
|
||||
An optional time value, expressed in milliseconds, representing the
|
||||
transport maximum timeout value for the receive channel. The value should
|
||||
|
||||
@ -67,6 +67,10 @@ properties:
|
||||
A 2.5V to 3.3V supply for the external reference voltage. When omitted,
|
||||
the internal 2.5V reference is used.
|
||||
|
||||
refin-supply:
|
||||
description:
|
||||
A 2.5V to 3.3V supply for external reference voltage, for ad7380-4 only.
|
||||
|
||||
aina-supply:
|
||||
description:
|
||||
The common mode voltage supply for the AINA- pin on pseudo-differential
|
||||
@ -135,6 +139,23 @@ allOf:
|
||||
ainc-supply: false
|
||||
aind-supply: false
|
||||
|
||||
# ad7380-4 uses refin-supply as external reference.
|
||||
# All other chips from ad738x family use refio as optional external reference.
|
||||
# When refio-supply is omitted, internal reference is used.
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- adi,ad7380-4
|
||||
then:
|
||||
properties:
|
||||
refio-supply: false
|
||||
required:
|
||||
- refin-supply
|
||||
else:
|
||||
properties:
|
||||
refin-supply: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
$id: http://devicetree.org/schemas/iio/dac/adi,ad5686.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Analog Devices AD5360 and similar DACs
|
||||
title: Analog Devices AD5360 and similar SPI DACs
|
||||
|
||||
maintainers:
|
||||
- Michael Hennerich <michael.hennerich@analog.com>
|
||||
@ -12,41 +12,22 @@ maintainers:
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- description: SPI devices
|
||||
enum:
|
||||
- adi,ad5310r
|
||||
- adi,ad5672r
|
||||
- adi,ad5674r
|
||||
- adi,ad5676
|
||||
- adi,ad5676r
|
||||
- adi,ad5679r
|
||||
- adi,ad5681r
|
||||
- adi,ad5682r
|
||||
- adi,ad5683
|
||||
- adi,ad5683r
|
||||
- adi,ad5684
|
||||
- adi,ad5684r
|
||||
- adi,ad5685r
|
||||
- adi,ad5686
|
||||
- adi,ad5686r
|
||||
- description: I2C devices
|
||||
enum:
|
||||
- adi,ad5311r
|
||||
- adi,ad5337r
|
||||
- adi,ad5338r
|
||||
- adi,ad5671r
|
||||
- adi,ad5675r
|
||||
- adi,ad5691r
|
||||
- adi,ad5692r
|
||||
- adi,ad5693
|
||||
- adi,ad5693r
|
||||
- adi,ad5694
|
||||
- adi,ad5694r
|
||||
- adi,ad5695r
|
||||
- adi,ad5696
|
||||
- adi,ad5696r
|
||||
|
||||
enum:
|
||||
- adi,ad5310r
|
||||
- adi,ad5672r
|
||||
- adi,ad5674r
|
||||
- adi,ad5676
|
||||
- adi,ad5676r
|
||||
- adi,ad5679r
|
||||
- adi,ad5681r
|
||||
- adi,ad5682r
|
||||
- adi,ad5683
|
||||
- adi,ad5683r
|
||||
- adi,ad5684
|
||||
- adi,ad5684r
|
||||
- adi,ad5685r
|
||||
- adi,ad5686
|
||||
- adi,ad5686r
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
$id: http://devicetree.org/schemas/iio/dac/adi,ad5696.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Analog Devices AD5696 and similar multi-channel DACs
|
||||
title: Analog Devices AD5696 and similar I2C multi-channel DACs
|
||||
|
||||
maintainers:
|
||||
- Michael Auchter <michael.auchter@ni.com>
|
||||
@ -16,6 +16,7 @@ properties:
|
||||
compatible:
|
||||
enum:
|
||||
- adi,ad5311r
|
||||
- adi,ad5337r
|
||||
- adi,ad5338r
|
||||
- adi,ad5671r
|
||||
- adi,ad5675r
|
||||
|
||||
@ -82,9 +82,6 @@ allOf:
|
||||
enum:
|
||||
- fsl,ls1043a-extirq
|
||||
- fsl,ls1046a-extirq
|
||||
- fsl,ls1088a-extirq
|
||||
- fsl,ls2080a-extirq
|
||||
- fsl,lx2160a-extirq
|
||||
then:
|
||||
properties:
|
||||
interrupt-map:
|
||||
@ -95,6 +92,29 @@ allOf:
|
||||
- const: 0xf
|
||||
- const: 0
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- fsl,ls1088a-extirq
|
||||
- fsl,ls2080a-extirq
|
||||
- fsl,lx2160a-extirq
|
||||
# The driver(drivers/irqchip/irq-ls-extirq.c) have not use standard DT
|
||||
# function to parser interrupt-map. So it doesn't consider '#address-size'
|
||||
# in parent interrupt controller, such as GIC.
|
||||
#
|
||||
# When dt-binding verify interrupt-map, item data matrix is spitted at
|
||||
# incorrect position. Remove interrupt-map restriction because it always
|
||||
# wrong.
|
||||
|
||||
then:
|
||||
properties:
|
||||
interrupt-map-mask:
|
||||
items:
|
||||
- const: 0xf
|
||||
- const: 0
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
|
||||
@ -113,7 +113,7 @@ properties:
|
||||
|
||||
msi-parent:
|
||||
deprecated: true
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
maxItems: 1
|
||||
description:
|
||||
Describes the MSI controller node handling message
|
||||
interrupts for the MC. When there is no translation
|
||||
|
||||
@ -26,6 +26,7 @@ properties:
|
||||
- brcm,asp-v2.1-mdio
|
||||
- brcm,asp-v2.2-mdio
|
||||
- brcm,unimac-mdio
|
||||
- brcm,bcm6846-mdio
|
||||
|
||||
reg:
|
||||
minItems: 1
|
||||
|
||||
@ -34,6 +34,7 @@ properties:
|
||||
and length of the AXI DMA controller IO space, unless
|
||||
axistream-connected is specified, in which case the reg
|
||||
attribute of the node referenced by it is used.
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
interrupts:
|
||||
@ -60,7 +61,7 @@ properties:
|
||||
- gmii
|
||||
- rgmii
|
||||
- sgmii
|
||||
- 1000BaseX
|
||||
- 1000base-x
|
||||
|
||||
xlnx,phy-type:
|
||||
description:
|
||||
@ -181,7 +182,7 @@ examples:
|
||||
clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk";
|
||||
clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>;
|
||||
phy-mode = "mii";
|
||||
reg = <0x00 0x40000000 0x00 0x40000>;
|
||||
reg = <0x40000000 0x40000>;
|
||||
xlnx,rxcsum = <0x2>;
|
||||
xlnx,rxmem = <0x800>;
|
||||
xlnx,txcsum = <0x2>;
|
||||
|
||||
@ -154,8 +154,6 @@ allOf:
|
||||
- qcom,sm8550-qmp-gen4x2-pcie-phy
|
||||
- qcom,sm8650-qmp-gen3x2-pcie-phy
|
||||
- qcom,sm8650-qmp-gen4x2-pcie-phy
|
||||
- qcom,x1e80100-qmp-gen3x2-pcie-phy
|
||||
- qcom,x1e80100-qmp-gen4x2-pcie-phy
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
@ -171,6 +169,8 @@ allOf:
|
||||
- qcom,sc8280xp-qmp-gen3x1-pcie-phy
|
||||
- qcom,sc8280xp-qmp-gen3x2-pcie-phy
|
||||
- qcom,sc8280xp-qmp-gen3x4-pcie-phy
|
||||
- qcom,x1e80100-qmp-gen3x2-pcie-phy
|
||||
- qcom,x1e80100-qmp-gen4x2-pcie-phy
|
||||
- qcom,x1e80100-qmp-gen4x4-pcie-phy
|
||||
then:
|
||||
properties:
|
||||
@ -201,6 +201,7 @@ allOf:
|
||||
- qcom,sm8550-qmp-gen4x2-pcie-phy
|
||||
- qcom,sm8650-qmp-gen4x2-pcie-phy
|
||||
- qcom,x1e80100-qmp-gen4x2-pcie-phy
|
||||
- qcom,x1e80100-qmp-gen4x4-pcie-phy
|
||||
then:
|
||||
properties:
|
||||
resets:
|
||||
|
||||
@ -102,21 +102,21 @@ properties:
|
||||
default: 2
|
||||
|
||||
interrupts:
|
||||
anyOf:
|
||||
- minItems: 1
|
||||
items:
|
||||
- description: TX interrupt
|
||||
- description: RX interrupt
|
||||
- items:
|
||||
- description: common/combined interrupt
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
interrupt-names:
|
||||
oneOf:
|
||||
- minItems: 1
|
||||
- description: TX interrupt
|
||||
const: tx
|
||||
- description: RX interrupt
|
||||
const: rx
|
||||
- description: TX and RX interrupts
|
||||
items:
|
||||
- const: tx
|
||||
- const: rx
|
||||
- const: common
|
||||
- description: Common/combined interrupt
|
||||
const: common
|
||||
|
||||
fck_parent:
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
|
||||
@ -30,6 +30,7 @@ properties:
|
||||
- qcom,apq8096-sndcard
|
||||
- qcom,qcm6490-idp-sndcard
|
||||
- qcom,qcs6490-rb3gen2-sndcard
|
||||
- qcom,qrb4210-rb2-sndcard
|
||||
- qcom,qrb5165-rb5-sndcard
|
||||
- qcom,sc7180-qdsp6-sndcard
|
||||
- qcom,sc8280xp-sndcard
|
||||
|
||||
@ -302,7 +302,7 @@ allOf:
|
||||
reg-names:
|
||||
items:
|
||||
enum:
|
||||
- scu
|
||||
- sru
|
||||
- ssi
|
||||
- adg
|
||||
# for Gen2/Gen3
|
||||
|
||||
@ -48,6 +48,10 @@ properties:
|
||||
- const: mclk_rx
|
||||
- const: hclk
|
||||
|
||||
port:
|
||||
$ref: audio-graph-port.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
|
||||
@ -101,8 +101,6 @@ properties:
|
||||
- domintech,dmard09
|
||||
# DMARD10: 3-axis Accelerometer
|
||||
- domintech,dmard10
|
||||
# Elgin SPI-controlled LCD
|
||||
- elgin,jg10309-01
|
||||
# MMA7660FC: 3-Axis Orientation/Motion Detection Sensor
|
||||
- fsl,mma7660
|
||||
# MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer
|
||||
|
||||
@ -7,12 +7,11 @@ WMI Driver API
|
||||
The WMI driver core supports a more modern bus-based interface for interacting
|
||||
with WMI devices, and an older GUID-based interface. The latter interface is
|
||||
considered to be deprecated, so new WMI drivers should generally avoid it since
|
||||
it has some issues with multiple WMI devices and events sharing the same GUIDs
|
||||
and/or notification IDs. The modern bus-based interface instead maps each
|
||||
WMI device to a :c:type:`struct wmi_device <wmi_device>`, so it supports
|
||||
WMI devices sharing GUIDs and/or notification IDs. Drivers can then register
|
||||
a :c:type:`struct wmi_driver <wmi_driver>`, which will be bound to compatible
|
||||
WMI devices by the driver core.
|
||||
it has some issues with multiple WMI devices sharing the same GUID.
|
||||
The modern bus-based interface instead maps each WMI device to a
|
||||
:c:type:`struct wmi_device <wmi_device>`, so it supports WMI devices sharing the
|
||||
same GUID. Drivers can then register a :c:type:`struct wmi_driver <wmi_driver>`
|
||||
which will be bound to compatible WMI devices by the driver core.
|
||||
|
||||
.. kernel-doc:: include/linux/wmi.h
|
||||
:internal:
|
||||
|
||||
@ -115,7 +115,7 @@ set up cache ready for use. The following script commands are available:
|
||||
|
||||
This mask can also be set through sysfs, eg::
|
||||
|
||||
echo 5 >/sys/modules/cachefiles/parameters/debug
|
||||
echo 5 > /sys/module/cachefiles/parameters/debug
|
||||
|
||||
|
||||
Starting the Cache
|
||||
|
||||
@ -208,7 +208,7 @@ The filesystem must arrange to `cancel
|
||||
such `reservations
|
||||
<https://lore.kernel.org/linux-xfs/20220817093627.GZ3600936@dread.disaster.area/>`_
|
||||
because writeback will not consume the reservation.
|
||||
The ``iomap_file_buffered_write_punch_delalloc`` can be called from a
|
||||
The ``iomap_write_delalloc_release`` can be called from a
|
||||
``->iomap_end`` function to find all the clean areas of the folios
|
||||
caching a fresh (``IOMAP_F_NEW``) delalloc mapping.
|
||||
It takes the ``invalidate_lock``.
|
||||
|
||||
@ -592,4 +592,3 @@ API Function Reference
|
||||
|
||||
.. kernel-doc:: include/linux/netfs.h
|
||||
.. kernel-doc:: fs/netfs/buffered_read.c
|
||||
.. kernel-doc:: fs/netfs/io.c
|
||||
|
||||
@ -181,7 +181,7 @@ Bridge Operations
|
||||
Bridge Connector Helper
|
||||
-----------------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_bridge_connector.c
|
||||
.. kernel-doc:: drivers/gpu/drm/display/drm_bridge_connector.c
|
||||
:doc: overview
|
||||
|
||||
|
||||
@ -204,7 +204,7 @@ MIPI-DSI bridge operation
|
||||
Bridge Connector Helper Reference
|
||||
---------------------------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_bridge_connector.c
|
||||
.. kernel-doc:: drivers/gpu/drm/display/drm_bridge_connector.c
|
||||
:export:
|
||||
|
||||
Panel-Bridge Helper Reference
|
||||
|
||||
@ -41,13 +41,22 @@ supports only 1 SDO line.
|
||||
Reference voltage
|
||||
-----------------
|
||||
|
||||
2 possible reference voltage sources are supported:
|
||||
ad7380-4
|
||||
~~~~~~~~
|
||||
|
||||
ad7380-4 supports only an external reference voltage (2.5V to 3.3V). It must be
|
||||
declared in the device tree as ``refin-supply``.
|
||||
|
||||
All other devices from ad738x family
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
All other devices from ad738x support 2 possible reference voltage sources:
|
||||
|
||||
- Internal reference (2.5V)
|
||||
- External reference (2.5V to 3.3V)
|
||||
|
||||
The source is determined by the device tree. If ``refio-supply`` is present,
|
||||
then the external reference is used, else the internal reference is used.
|
||||
then it is used as external reference, else the internal reference is used.
|
||||
|
||||
Oversampling and resolution boost
|
||||
---------------------------------
|
||||
|
||||
@ -7,26 +7,26 @@ The DAMON subsystem covers the files that are listed in 'DATA ACCESS MONITOR'
|
||||
section of 'MAINTAINERS' file.
|
||||
|
||||
The mailing lists for the subsystem are damon@lists.linux.dev and
|
||||
linux-mm@kvack.org. Patches should be made against the mm-unstable `tree
|
||||
<https://git.kernel.org/akpm/mm/h/mm-unstable>` whenever possible and posted to
|
||||
the mailing lists.
|
||||
linux-mm@kvack.org. Patches should be made against the `mm-unstable tree
|
||||
<https://git.kernel.org/akpm/mm/h/mm-unstable>`_ whenever possible and posted
|
||||
to the mailing lists.
|
||||
|
||||
SCM Trees
|
||||
---------
|
||||
|
||||
There are multiple Linux trees for DAMON development. Patches under
|
||||
development or testing are queued in `damon/next
|
||||
<https://git.kernel.org/sj/h/damon/next>` by the DAMON maintainer.
|
||||
<https://git.kernel.org/sj/h/damon/next>`_ by the DAMON maintainer.
|
||||
Sufficiently reviewed patches will be queued in `mm-unstable
|
||||
<https://git.kernel.org/akpm/mm/h/mm-unstable>` by the memory management
|
||||
<https://git.kernel.org/akpm/mm/h/mm-unstable>`_ by the memory management
|
||||
subsystem maintainer. After more sufficient tests, the patches will be queued
|
||||
in `mm-stable <https://git.kernel.org/akpm/mm/h/mm-stable>` , and finally
|
||||
in `mm-stable <https://git.kernel.org/akpm/mm/h/mm-stable>`_, and finally
|
||||
pull-requested to the mainline by the memory management subsystem maintainer.
|
||||
|
||||
Note again the patches for mm-unstable `tree
|
||||
<https://git.kernel.org/akpm/mm/h/mm-unstable>` are queued by the memory
|
||||
Note again the patches for `mm-unstable tree
|
||||
<https://git.kernel.org/akpm/mm/h/mm-unstable>`_ are queued by the memory
|
||||
management subsystem maintainer. If the patches requires some patches in
|
||||
damon/next `tree <https://git.kernel.org/sj/h/damon/next>` which not yet merged
|
||||
`damon/next tree <https://git.kernel.org/sj/h/damon/next>`_ which not yet merged
|
||||
in mm-unstable, please make sure the requirement is clearly specified.
|
||||
|
||||
Submit checklist addendum
|
||||
@ -37,25 +37,25 @@ When making DAMON changes, you should do below.
|
||||
- Build changes related outputs including kernel and documents.
|
||||
- Ensure the builds introduce no new errors or warnings.
|
||||
- Run and ensure no new failures for DAMON `selftests
|
||||
<https://github.com/awslabs/damon-tests/blob/master/corr/run.sh#L49>` and
|
||||
<https://github.com/damonitor/damon-tests/blob/master/corr/run.sh#L49>`_ and
|
||||
`kunittests
|
||||
<https://github.com/awslabs/damon-tests/blob/master/corr/tests/kunit.sh>`.
|
||||
<https://github.com/damonitor/damon-tests/blob/master/corr/tests/kunit.sh>`_.
|
||||
|
||||
Further doing below and putting the results will be helpful.
|
||||
|
||||
- Run `damon-tests/corr
|
||||
<https://github.com/awslabs/damon-tests/tree/master/corr>` for normal
|
||||
<https://github.com/damonitor/damon-tests/tree/master/corr>`_ for normal
|
||||
changes.
|
||||
- Run `damon-tests/perf
|
||||
<https://github.com/awslabs/damon-tests/tree/master/perf>` for performance
|
||||
<https://github.com/damonitor/damon-tests/tree/master/perf>`_ for performance
|
||||
changes.
|
||||
|
||||
Key cycle dates
|
||||
---------------
|
||||
|
||||
Patches can be sent anytime. Key cycle dates of the `mm-unstable
|
||||
<https://git.kernel.org/akpm/mm/h/mm-unstable>` and `mm-stable
|
||||
<https://git.kernel.org/akpm/mm/h/mm-stable>` trees depend on the memory
|
||||
<https://git.kernel.org/akpm/mm/h/mm-unstable>`_ and `mm-stable
|
||||
<https://git.kernel.org/akpm/mm/h/mm-stable>`_ trees depend on the memory
|
||||
management subsystem maintainer.
|
||||
|
||||
Review cadence
|
||||
@ -72,13 +72,13 @@ Mailing tool
|
||||
Like many other Linux kernel subsystems, DAMON uses the mailing lists
|
||||
(damon@lists.linux.dev and linux-mm@kvack.org) as the major communication
|
||||
channel. There is a simple tool called `HacKerMaiL
|
||||
<https://github.com/damonitor/hackermail>` (``hkml``), which is for people who
|
||||
<https://github.com/damonitor/hackermail>`_ (``hkml``), which is for people who
|
||||
are not very familiar with the mailing lists based communication. The tool
|
||||
could be particularly helpful for DAMON community members since it is developed
|
||||
and maintained by DAMON maintainer. The tool is also officially announced to
|
||||
support DAMON and general Linux kernel development workflow.
|
||||
|
||||
In other words, `hkml <https://github.com/damonitor/hackermail>` is a mailing
|
||||
In other words, `hkml <https://github.com/damonitor/hackermail>`_ is a mailing
|
||||
tool for DAMON community, which DAMON maintainer is committed to support.
|
||||
Please feel free to try and report issues or feature requests for the tool to
|
||||
the maintainer.
|
||||
@ -98,8 +98,8 @@ slots, and attendees should reserve one of those at least 24 hours before the
|
||||
time slot, by reaching out to the maintainer.
|
||||
|
||||
Schedules and available reservation time slots are available at the Google `doc
|
||||
<https://docs.google.com/document/d/1v43Kcj3ly4CYqmAkMaZzLiM2GEnWfgdGbZAH3mi2vpM/edit?usp=sharing>`.
|
||||
<https://docs.google.com/document/d/1v43Kcj3ly4CYqmAkMaZzLiM2GEnWfgdGbZAH3mi2vpM/edit?usp=sharing>`_.
|
||||
There is also a public Google `calendar
|
||||
<https://calendar.google.com/calendar/u/0?cid=ZDIwOTA4YTMxNjc2MDQ3NTIyMmUzYTM5ZmQyM2U4NDA0ZGIwZjBiYmJlZGQxNDM0MmY4ZTRjOTE0NjdhZDRiY0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t>`
|
||||
<https://calendar.google.com/calendar/u/0?cid=ZDIwOTA4YTMxNjc2MDQ3NTIyMmUzYTM5ZmQyM2U4NDA0ZGIwZjBiYmJlZGQxNDM0MmY4ZTRjOTE0NjdhZDRiY0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t>`_
|
||||
that has the events. Anyone can subscribe it. DAMON maintainer will also
|
||||
provide periodic reminder to the mailing list (damon@lists.linux.dev).
|
||||
|
||||
@ -293,7 +293,6 @@ operations:
|
||||
doc: Get endpoint information
|
||||
attribute-set: attr
|
||||
dont-validate: [ strict ]
|
||||
flags: [ uns-admin-perm ]
|
||||
do: &get-addr-attrs
|
||||
request:
|
||||
attributes:
|
||||
|
||||
@ -121,7 +121,7 @@ format, the Group Extension is set in the PS-field.
|
||||
|
||||
On the other hand, when using PDU1 format, the PS-field contains a so-called
|
||||
Destination Address, which is _not_ part of the PGN. When communicating a PGN
|
||||
from user space to kernel (or vice versa) and PDU2 format is used, the PS-field
|
||||
from user space to kernel (or vice versa) and PDU1 format is used, the PS-field
|
||||
of the PGN shall be set to zero. The Destination Address shall be set
|
||||
elsewhere.
|
||||
|
||||
|
||||
@ -144,9 +144,8 @@ IRQ should only be unmasked after a successful call to napi_complete_done():
|
||||
|
||||
napi_schedule_irqoff() is a variant of napi_schedule() which takes advantage
|
||||
of guarantees given by being invoked in IRQ context (no need to
|
||||
mask interrupts). Note that PREEMPT_RT forces all interrupts
|
||||
to be threaded so the interrupt may need to be marked ``IRQF_NO_THREAD``
|
||||
to avoid issues on real-time kernel configurations.
|
||||
mask interrupts). napi_schedule_irqoff() will fall back to napi_schedule() if
|
||||
IRQs are threaded (such as if ``PREEMPT_RT`` is enabled).
|
||||
|
||||
Instance to queue mapping
|
||||
-------------------------
|
||||
|
||||
@ -16,7 +16,7 @@ ii) transmit network traffic, or any other that needs raw
|
||||
|
||||
Howto can be found at:
|
||||
|
||||
https://sites.google.com/site/packetmmap/
|
||||
https://web.archive.org/web/20220404160947/https://sites.google.com/site/packetmmap/
|
||||
|
||||
Please send your comments to
|
||||
- Ulisses Alonso Camaró <uaca@i.hate.spam.alumni.uv.es>
|
||||
@ -166,7 +166,8 @@ As capture, each frame contains two parts::
|
||||
/* bind socket to eth0 */
|
||||
bind(this->socket, (struct sockaddr *)&my_addr, sizeof(struct sockaddr_ll));
|
||||
|
||||
A complete tutorial is available at: https://sites.google.com/site/packetmmap/
|
||||
A complete tutorial is available at:
|
||||
https://web.archive.org/web/20220404160947/https://sites.google.com/site/packetmmap/
|
||||
|
||||
By default, the user should put data at::
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ segments between trusted peers. It adds a new TCP header option with
|
||||
a Message Authentication Code (MAC). MACs are produced from the content
|
||||
of a TCP segment using a hashing function with a password known to both peers.
|
||||
The intent of TCP-AO is to deprecate TCP-MD5 providing better security,
|
||||
key rotation and support for variety of hashing algorithms.
|
||||
key rotation and support for a variety of hashing algorithms.
|
||||
|
||||
1. Introduction
|
||||
===============
|
||||
@ -164,9 +164,9 @@ A: It should not, no action needs to be performed [7.5.2.e]::
|
||||
is not available, no action is required (RNextKeyID of a received
|
||||
segment needs to match the MKT’s SendID).
|
||||
|
||||
Q: How current_key is set and when does it change? It is a user-triggered
|
||||
change, or is it by a request from the remote peer? Is it set by the user
|
||||
explicitly, or by a matching rule?
|
||||
Q: How is current_key set, and when does it change? Is it a user-triggered
|
||||
change, or is it triggered by a request from the remote peer? Is it set by the
|
||||
user explicitly, or by a matching rule?
|
||||
|
||||
A: current_key is set by RNextKeyID [6.1]::
|
||||
|
||||
@ -233,8 +233,8 @@ always have one current_key [3.3]::
|
||||
|
||||
Q: Can a non-TCP-AO connection become a TCP-AO-enabled one?
|
||||
|
||||
A: No: for already established non-TCP-AO connection it would be impossible
|
||||
to switch using TCP-AO as the traffic key generation requires the initial
|
||||
A: No: for an already established non-TCP-AO connection it would be impossible
|
||||
to switch to using TCP-AO, as the traffic key generation requires the initial
|
||||
sequence numbers. Paraphrasing, starting using TCP-AO would require
|
||||
re-establishing the TCP connection.
|
||||
|
||||
@ -292,7 +292,7 @@ no transparency is really needed and modern BGP daemons already have
|
||||
|
||||
Linux provides a set of ``setsockopt()s`` and ``getsockopt()s`` that let
|
||||
userspace manage TCP-AO on a per-socket basis. In order to add/delete MKTs
|
||||
``TCP_AO_ADD_KEY`` and ``TCP_AO_DEL_KEY`` TCP socket options must be used
|
||||
``TCP_AO_ADD_KEY`` and ``TCP_AO_DEL_KEY`` TCP socket options must be used.
|
||||
It is not allowed to add a key on an established non-TCP-AO connection
|
||||
as well as to remove the last key from TCP-AO connection.
|
||||
|
||||
@ -361,7 +361,7 @@ not implemented.
|
||||
4. ``setsockopt()`` vs ``accept()`` race
|
||||
========================================
|
||||
|
||||
In contrast with TCP-MD5 established connection which has just one key,
|
||||
In contrast with an established TCP-MD5 connection which has just one key,
|
||||
TCP-AO connections may have many keys, which means that accepted connections
|
||||
on a listen socket may have any amount of keys as well. As copying all those
|
||||
keys on a first properly signed SYN would make the request socket bigger, that
|
||||
@ -374,7 +374,7 @@ keys from sockets that were already established, but not yet ``accept()``'ed,
|
||||
hanging in the accept queue.
|
||||
|
||||
The reverse is valid as well: if userspace adds a new key for a peer on
|
||||
a listener socket, the established sockets in accept queue won't
|
||||
a listener socket, the established sockets in the accept queue won't
|
||||
have the new keys.
|
||||
|
||||
At this moment, the resolution for the two races:
|
||||
@ -382,7 +382,7 @@ At this moment, the resolution for the two races:
|
||||
and ``setsockopt(TCP_AO_DEL_KEY)`` vs ``accept()`` is delegated to userspace.
|
||||
This means that it's expected that userspace would check the MKTs on the socket
|
||||
that was returned by ``accept()`` to verify that any key rotation that
|
||||
happened on listen socket is reflected on the newly established connection.
|
||||
happened on the listen socket is reflected on the newly established connection.
|
||||
|
||||
This is a similar "do-nothing" approach to TCP-MD5 from the kernel side and
|
||||
may be changed later by introducing new flags to ``tcp_ao_add``
|
||||
|
||||
@ -355,6 +355,8 @@ just do it. As a result, a sequence of smaller series gets merged quicker and
|
||||
with better review coverage. Re-posting large series also increases the mailing
|
||||
list traffic.
|
||||
|
||||
.. _rcs:
|
||||
|
||||
Local variable ordering ("reverse xmas tree", "RCS")
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -391,6 +393,21 @@ APIs and helpers, especially scoped iterators. However, direct use of
|
||||
``__free()`` within networking core and drivers is discouraged.
|
||||
Similar guidance applies to declaring variables mid-function.
|
||||
|
||||
Clean-up patches
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Netdev discourages patches which perform simple clean-ups, which are not in
|
||||
the context of other work. For example:
|
||||
|
||||
* Addressing ``checkpatch.pl`` warnings
|
||||
* Addressing :ref:`Local variable ordering<rcs>` issues
|
||||
* Conversions to device-managed APIs (``devm_`` helpers)
|
||||
|
||||
This is because it is felt that the churn that such changes produce comes
|
||||
at a greater cost than the value of such clean-ups.
|
||||
|
||||
Conversely, spelling and grammar fixes are not discouraged.
|
||||
|
||||
Resending after review
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
@ -30,10 +30,13 @@ tree as a dedicated branch covering multiple subsystems.
|
||||
The main SoC tree is housed on git.kernel.org:
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/
|
||||
|
||||
Maintainers
|
||||
-----------
|
||||
|
||||
Clearly this is quite a wide range of topics, which no one person, or even
|
||||
small group of people are capable of maintaining. Instead, the SoC subsystem
|
||||
is comprised of many submaintainers, each taking care of individual platforms
|
||||
and driver subdirectories.
|
||||
is comprised of many submaintainers (platform maintainers), each taking care of
|
||||
individual platforms and driver subdirectories.
|
||||
In this regard, "platform" usually refers to a series of SoCs from a given
|
||||
vendor, for example, Nvidia's series of Tegra SoCs. Many submaintainers operate
|
||||
on a vendor level, responsible for multiple product lines. For several reasons,
|
||||
@ -43,14 +46,43 @@ MAINTAINERS file.
|
||||
|
||||
Most of these submaintainers have their own trees where they stage patches,
|
||||
sending pull requests to the main SoC tree. These trees are usually, but not
|
||||
always, listed in MAINTAINERS. The main SoC maintainers can be reached via the
|
||||
alias soc@kernel.org if there is no platform-specific maintainer, or if they
|
||||
are unresponsive.
|
||||
always, listed in MAINTAINERS.
|
||||
|
||||
What the SoC tree is not, however, is a location for architecture-specific code
|
||||
changes. Each architecture has its own maintainers that are responsible for
|
||||
architectural details, CPU errata and the like.
|
||||
|
||||
Submitting Patches for Given SoC
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
All typical platform related patches should be sent via SoC submaintainers
|
||||
(platform-specific maintainers). This includes also changes to per-platform or
|
||||
shared defconfigs (scripts/get_maintainer.pl might not provide correct
|
||||
addresses in such case).
|
||||
|
||||
Submitting Patches to the Main SoC Maintainers
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The main SoC maintainers can be reached via the alias soc@kernel.org only in
|
||||
following cases:
|
||||
|
||||
1. There are no platform-specific maintainers.
|
||||
|
||||
2. Platform-specific maintainers are unresponsive.
|
||||
|
||||
3. Introducing a completely new SoC platform. Such new SoC work should be sent
|
||||
first to common mailing lists, pointed out by scripts/get_maintainer.pl, for
|
||||
community review. After positive community review, work should be sent to
|
||||
soc@kernel.org in one patchset containing new arch/foo/Kconfig entry, DTS
|
||||
files, MAINTAINERS file entry and optionally initial drivers with their
|
||||
Devicetree bindings. The MAINTAINERS file entry should list new
|
||||
platform-specific maintainers, who are going to be responsible for handling
|
||||
patches for the platform from now on.
|
||||
|
||||
Note that the soc@kernel.org is usually not the place to discuss the patches,
|
||||
thus work sent to this address should be already considered as acceptable by
|
||||
the community.
|
||||
|
||||
Information for (new) Submaintainers
|
||||
------------------------------------
|
||||
|
||||
|
||||
@ -17,7 +17,7 @@ Architecture Level of support Constraints
|
||||
============= ================ ==============================================
|
||||
``arm64`` Maintained Little Endian only.
|
||||
``loongarch`` Maintained \-
|
||||
``riscv`` Maintained ``riscv64`` only.
|
||||
``riscv`` Maintained ``riscv64`` and LLVM/Clang only.
|
||||
``um`` Maintained \-
|
||||
``x86`` Maintained ``x86_64`` only.
|
||||
============= ================ ==============================================
|
||||
|
||||
@ -66,7 +66,7 @@ BPF scheduler and reverts all tasks back to CFS.
|
||||
.. code-block:: none
|
||||
|
||||
# make -j16 -C tools/sched_ext
|
||||
# tools/sched_ext/scx_simple
|
||||
# tools/sched_ext/build/bin/scx_simple
|
||||
local=0 global=3
|
||||
local=5 global=24
|
||||
local=9 global=44
|
||||
|
||||
@ -175,7 +175,7 @@ field2会导致非对齐访问，这并不是不合理的。你会期望field2
|
||||
避免非对齐访问
|
||||
==============
|
||||
|
||||
避免非对齐访问的最简单方法是使用<asm/unaligned.h>头文件提供的get_unaligned()和
|
||||
避免非对齐访问的最简单方法是使用<linux/unaligned.h>头文件提供的get_unaligned()和
|
||||
put_unaligned()宏。
|
||||
|
||||
回到前面的一个可能导致非对齐访问的代码例子::
|
||||
|
||||
@ -23,177 +23,166 @@ applications can additionally seal security critical data at runtime.
|
||||
A similar feature already exists in the XNU kernel with the
|
||||
VM_FLAGS_PERMANENT flag [1] and on OpenBSD with the mimmutable syscall [2].
|
||||
|
||||
User API
|
||||
========
|
||||
mseal()
|
||||
-----------
|
||||
The mseal() syscall has the following signature:
|
||||
SYSCALL
|
||||
=======
|
||||
mseal syscall signature
|
||||
-----------------------
|
||||
``int mseal(void \* addr, size_t len, unsigned long flags)``
|
||||
|
||||
``int mseal(void addr, size_t len, unsigned long flags)``
|
||||
**addr**/**len**: virtual memory address range.
|
||||
The address range set by **addr**/**len** must meet:
|
||||
- The start address must be in an allocated VMA.
|
||||
- The start address must be page aligned.
|
||||
- The end address (**addr** + **len**) must be in an allocated VMA.
|
||||
- no gap (unallocated memory) between start and end address.
|
||||
|
||||
**addr/len**: virtual memory address range.
|
||||
The ``len`` will be paged aligned implicitly by the kernel.
|
||||
|
||||
The address range set by ``addr``/``len`` must meet:
|
||||
- The start address must be in an allocated VMA.
|
||||
- The start address must be page aligned.
|
||||
- The end address (``addr`` + ``len``) must be in an allocated VMA.
|
||||
- no gap (unallocated memory) between start and end address.
|
||||
**flags**: reserved for future use.
|
||||
|
||||
The ``len`` will be paged aligned implicitly by the kernel.
|
||||
**Return values**:
|
||||
- **0**: Success.
|
||||
- **-EINVAL**:
|
||||
* Invalid input ``flags``.
|
||||
* The start address (``addr``) is not page aligned.
|
||||
* Address range (``addr`` + ``len``) overflow.
|
||||
- **-ENOMEM**:
|
||||
* The start address (``addr``) is not allocated.
|
||||
* The end address (``addr`` + ``len``) is not allocated.
|
||||
* A gap (unallocated memory) between start and end address.
|
||||
- **-EPERM**:
|
||||
* sealing is supported only on 64-bit CPUs, 32-bit is not supported.
|
||||
|
||||
**flags**: reserved for future use.
|
||||
**Note about error return**:
|
||||
- For above error cases, users can expect the given memory range is
|
||||
unmodified, i.e. no partial update.
|
||||
- There might be other internal errors/cases not listed here, e.g.
|
||||
error during merging/splitting VMAs, or the process reaching the maximum
|
||||
number of supported VMAs. In those cases, partial updates to the given
|
||||
memory range could happen. However, those cases should be rare.
|
||||
|
||||
**return values**:
|
||||
**Architecture support**:
|
||||
mseal only works on 64-bit CPUs, not 32-bit CPUs.
|
||||
|
||||
- ``0``: Success.
|
||||
**Idempotent**:
|
||||
users can call mseal multiple times. mseal on an already sealed memory
|
||||
is a no-action (not error).
|
||||
|
||||
- ``-EINVAL``:
|
||||
- Invalid input ``flags``.
|
||||
- The start address (``addr``) is not page aligned.
|
||||
- Address range (``addr`` + ``len``) overflow.
|
||||
**no munseal**
|
||||
Once mapping is sealed, it can't be unsealed. The kernel should never
|
||||
have munseal, this is consistent with other sealing feature, e.g.
|
||||
F_SEAL_SEAL for file.
|
||||
|
||||
- ``-ENOMEM``:
|
||||
- The start address (``addr``) is not allocated.
|
||||
- The end address (``addr`` + ``len``) is not allocated.
|
||||
- A gap (unallocated memory) between start and end address.
|
||||
Blocked mm syscall for sealed mapping
|
||||
-------------------------------------
|
||||
It might be important to note: **once the mapping is sealed, it will
|
||||
stay in the process's memory until the process terminates**.
|
||||
|
||||
- ``-EPERM``:
|
||||
- sealing is supported only on 64-bit CPUs, 32-bit is not supported.
|
||||
Example::
|
||||
|
||||
- For above error cases, users can expect the given memory range is
|
||||
unmodified, i.e. no partial update.
|
||||
*ptr = mmap(0, 4096, PROT_READ, MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
|
||||
rc = mseal(ptr, 4096, 0);
|
||||
/* munmap will fail */
|
||||
rc = munmap(ptr, 4096);
|
||||
assert(rc < 0);
|
||||
|
||||
- There might be other internal errors/cases not listed here, e.g.
|
||||
error during merging/splitting VMAs, or the process reaching the max
|
||||
number of supported VMAs. In those cases, partial updates to the given
|
||||
memory range could happen. However, those cases should be rare.
|
||||
Blocked mm syscall:
|
||||
- munmap
|
||||
- mmap
|
||||
- mremap
|
||||
- mprotect and pkey_mprotect
|
||||
- some destructive madvise behaviors: MADV_DONTNEED, MADV_FREE,
|
||||
MADV_DONTNEED_LOCKED, MADV_FREE, MADV_DONTFORK, MADV_WIPEONFORK
|
||||
|
||||
**Blocked operations after sealing**:
|
||||
Unmapping, moving to another location, and shrinking the size,
|
||||
via munmap() and mremap(), can leave an empty space, therefore
|
||||
can be replaced with a VMA with a new set of attributes.
|
||||
The first set of syscalls to block is munmap, mremap, mmap. They can
|
||||
either leave an empty space in the address space, therefore allowing
|
||||
replacement with a new mapping with new set of attributes, or can
|
||||
overwrite the existing mapping with another mapping.
|
||||
|
||||
Moving or expanding a different VMA into the current location,
|
||||
via mremap().
|
||||
mprotect and pkey_mprotect are blocked because they changes the
|
||||
protection bits (RWX) of the mapping.
|
||||
|
||||
Modifying a VMA via mmap(MAP_FIXED).
|
||||
Certain destructive madvise behaviors, specifically MADV_DONTNEED,
|
||||
MADV_FREE, MADV_DONTNEED_LOCKED, and MADV_WIPEONFORK, can introduce
|
||||
risks when applied to anonymous memory by threads lacking write
|
||||
permissions. Consequently, these operations are prohibited under such
|
||||
conditions. The aforementioned behaviors have the potential to modify
|
||||
region contents by discarding pages, effectively performing a memset(0)
|
||||
operation on the anonymous memory.
|
||||
|
||||
Size expansion, via mremap(), does not appear to pose any
|
||||
specific risks to sealed VMAs. It is included anyway because
|
||||
the use case is unclear. In any case, users can rely on
|
||||
merging to expand a sealed VMA.
|
||||
Kernel will return -EPERM for blocked syscalls.
|
||||
|
||||
mprotect() and pkey_mprotect().
|
||||
When blocked syscall return -EPERM due to sealing, the memory regions may
|
||||
or may not be changed, depends on the syscall being blocked:
|
||||
|
||||
Some destructive madvice() behaviors (e.g. MADV_DONTNEED)
|
||||
for anonymous memory, when users don't have write permission to the
|
||||
memory. Those behaviors can alter region contents by discarding pages,
|
||||
effectively a memset(0) for anonymous memory.
|
||||
- munmap: munmap is atomic. If one of VMAs in the given range is
|
||||
sealed, none of VMAs are updated.
|
||||
- mprotect, pkey_mprotect, madvise: partial update might happen, e.g.
|
||||
when mprotect over multiple VMAs, mprotect might update the beginning
|
||||
VMAs before reaching the sealed VMA and return -EPERM.
|
||||
- mmap and mremap: undefined behavior.
|
||||
|
||||
Kernel will return -EPERM for blocked operations.
|
||||
|
||||
For blocked operations, one can expect the given address is unmodified,
|
||||
i.e. no partial update. Note, this is different from existing mm
|
||||
system call behaviors, where partial updates are made till an error is
|
||||
found and returned to userspace. To give an example:
|
||||
|
||||
Assume following code sequence:
|
||||
|
||||
- ptr = mmap(null, 8192, PROT_NONE);
|
||||
- munmap(ptr + 4096, 4096);
|
||||
- ret1 = mprotect(ptr, 8192, PROT_READ);
|
||||
- mseal(ptr, 4096);
|
||||
- ret2 = mprotect(ptr, 8192, PROT_NONE);
|
||||
|
||||
ret1 will be -ENOMEM, the page from ptr is updated to PROT_READ.
|
||||
|
||||
ret2 will be -EPERM, the page remains to be PROT_READ.
|
||||
|
||||
**Note**:
|
||||
|
||||
- mseal() only works on 64-bit CPUs, not 32-bit CPU.
|
||||
|
||||
- users can call mseal() multiple times, mseal() on an already sealed memory
|
||||
is a no-action (not error).
|
||||
|
||||
- munseal() is not supported.
|
||||
|
||||
Use cases:
|
||||
==========
|
||||
Use cases
|
||||
=========
|
||||
- glibc:
|
||||
The dynamic linker, during loading ELF executables, can apply sealing to
|
||||
non-writable memory segments.
|
||||
mapping segments.
|
||||
|
||||
- Chrome browser: protect some security sensitive data-structures.
|
||||
- Chrome browser: protect some security sensitive data structures.
|
||||
|
||||
Notes on which memory to seal:
|
||||
==============================
|
||||
|
||||
It might be important to note that sealing changes the lifetime of a mapping,
|
||||
i.e. the sealed mapping won’t be unmapped till the process terminates or the
|
||||
exec system call is invoked. Applications can apply sealing to any virtual
|
||||
memory region from userspace, but it is crucial to thoroughly analyze the
|
||||
mapping's lifetime prior to apply the sealing.
|
||||
When not to use mseal
|
||||
=====================
|
||||
Applications can apply sealing to any virtual memory region from userspace,
|
||||
but it is *crucial to thoroughly analyze the mapping's lifetime* prior to
|
||||
apply the sealing. This is because the sealed mapping *won’t be unmapped*
|
||||
until the process terminates or the exec system call is invoked.
|
||||
|
||||
For example:
|
||||
- aio/shm
|
||||
aio/shm can call mmap and munmap on behalf of userspace, e.g.
|
||||
ksys_shmdt() in shm.c. The lifetimes of those mapping are not tied to
|
||||
the lifetime of the process. If those memories are sealed from userspace,
|
||||
then munmap will fail, causing leaks in VMA address space during the
|
||||
lifetime of the process.
|
||||
|
||||
- aio/shm
|
||||
- ptr allocated by malloc (heap)
|
||||
Don't use mseal on the memory ptr return from malloc().
|
||||
malloc() is implemented by allocator, e.g. by glibc. Heap manager might
|
||||
allocate a ptr from brk or mapping created by mmap.
|
||||
If an app calls mseal on a ptr returned from malloc(), this can affect
|
||||
the heap manager's ability to manage the mappings; the outcome is
|
||||
non-deterministic.
|
||||
|
||||
aio/shm can call mmap()/munmap() on behalf of userspace, e.g. ksys_shmdt() in
|
||||
shm.c. The lifetime of those mapping are not tied to the lifetime of the
|
||||
process. If those memories are sealed from userspace, then munmap() will fail,
|
||||
causing leaks in VMA address space during the lifetime of the process.
|
||||
Example::
|
||||
|
||||
- Brk (heap)
|
||||
ptr = malloc(size);
|
||||
/* don't call mseal on ptr return from malloc. */
|
||||
mseal(ptr, size);
|
||||
/* free will success, allocator can't shrink heap lower than ptr */
|
||||
free(ptr);
|
||||
|
||||
Currently, userspace applications can seal parts of the heap by calling
|
||||
malloc() and mseal().
|
||||
let's assume following calls from user space:
|
||||
mseal doesn't block
|
||||
===================
|
||||
In a nutshell, mseal blocks certain mm syscall from modifying some of VMA's
|
||||
attributes, such as protection bits (RWX). Sealed mappings doesn't mean the
|
||||
memory is immutable.
|
||||
|
||||
- ptr = malloc(size);
|
||||
- mprotect(ptr, size, RO);
|
||||
- mseal(ptr, size);
|
||||
- free(ptr);
|
||||
|
||||
Technically, before mseal() is added, the user can change the protection of
|
||||
the heap by calling mprotect(RO). As long as the user changes the protection
|
||||
back to RW before free(), the memory range can be reused.
|
||||
|
||||
Adding mseal() into the picture, however, the heap is then sealed partially,
|
||||
the user can still free it, but the memory remains to be RO. If the address
|
||||
is re-used by the heap manager for another malloc, the process might crash
|
||||
soon after. Therefore, it is important not to apply sealing to any memory
|
||||
that might get recycled.
|
||||
|
||||
Furthermore, even if the application never calls the free() for the ptr,
|
||||
the heap manager may invoke the brk system call to shrink the size of the
|
||||
heap. In the kernel, the brk-shrink will call munmap(). Consequently,
|
||||
depending on the location of the ptr, the outcome of brk-shrink is
|
||||
nondeterministic.
|
||||
|
||||
|
||||
Additional notes:
|
||||
=================
|
||||
As Jann Horn pointed out in [3], there are still a few ways to write
|
||||
to RO memory, which is, in a way, by design. Those cases are not covered
|
||||
by mseal(). If applications want to block such cases, sandbox tools (such as
|
||||
seccomp, LSM, etc) might be considered.
|
||||
to RO memory, which is, in a way, by design. And those could be blocked
|
||||
by different security measures.
|
||||
|
||||
Those cases are:
|
||||
|
||||
- Write to read-only memory through /proc/self/mem interface.
|
||||
- Write to read-only memory through ptrace (such as PTRACE_POKETEXT).
|
||||
- userfaultfd.
|
||||
- Write to read-only memory through /proc/self/mem interface (FOLL_FORCE).
|
||||
- Write to read-only memory through ptrace (such as PTRACE_POKETEXT).
|
||||
- userfaultfd.
|
||||
|
||||
The idea that inspired this patch comes from Stephen Röttger’s work in V8
|
||||
CFI [4]. Chrome browser in ChromeOS will be the first user of this API.
|
||||
|
||||
Reference:
|
||||
==========
|
||||
[1] https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/osfmk/mach/vm_statistics.h#L274
|
||||
|
||||
[2] https://man.openbsd.org/mimmutable.2
|
||||
|
||||
[3] https://lore.kernel.org/lkml/CAG48ez3ShUYey+ZAFsU2i1RpQn0a5eOs2hzQ426FkcgnfUGLvA@mail.gmail.com
|
||||
|
||||
[4] https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdvxQMyXgeaRHo/edit#heading=h.bvaojj9fu6hc
|
||||
Reference
|
||||
=========
|
||||
- [1] https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/osfmk/mach/vm_statistics.h#L274
|
||||
- [2] https://man.openbsd.org/mimmutable.2
|
||||
- [3] https://lore.kernel.org/lkml/CAG48ez3ShUYey+ZAFsU2i1RpQn0a5eOs2hzQ426FkcgnfUGLvA@mail.gmail.com
|
||||
- [4] https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdvxQMyXgeaRHo/edit#heading=h.bvaojj9fu6hc
|
||||
|
||||
@ -8098,13 +8098,15 @@ KVM_X86_QUIRK_MWAIT_NEVER_UD_FAULTS By default, KVM emulates MONITOR/MWAIT (if
|
||||
KVM_X86_QUIRK_MISC_ENABLE_NO_MWAIT is
|
||||
disabled.
|
||||
|
||||
KVM_X86_QUIRK_SLOT_ZAP_ALL By default, KVM invalidates all SPTEs in
|
||||
fast way for memslot deletion when VM type
|
||||
is KVM_X86_DEFAULT_VM.
|
||||
When this quirk is disabled or when VM type
|
||||
is other than KVM_X86_DEFAULT_VM, KVM zaps
|
||||
only leaf SPTEs that are within the range of
|
||||
the memslot being deleted.
|
||||
KVM_X86_QUIRK_SLOT_ZAP_ALL By default, for KVM_X86_DEFAULT_VM VMs, KVM
|
||||
invalidates all SPTEs in all memslots and
|
||||
address spaces when a memslot is deleted or
|
||||
moved. When this quirk is disabled (or the
|
||||
VM type isn't KVM_X86_DEFAULT_VM), KVM only
|
||||
ensures the backing memory of the deleted
|
||||
or moved memslot isn't reachable, i.e KVM
|
||||
_may_ invalidate only SPTEs related to the
|
||||
memslot.
|
||||
=================================== ============================================
|
||||
|
||||
7.32 KVM_CAP_MAX_VCPU_ID
|
||||
|
||||
@ -136,7 +136,7 @@ For direct sp, we can easily avoid it since the spte of direct sp is fixed
|
||||
to gfn. For indirect sp, we disabled fast page fault for simplicity.
|
||||
|
||||
A solution for indirect sp could be to pin the gfn, for example via
|
||||
kvm_vcpu_gfn_to_pfn_atomic, before the cmpxchg. After the pinning:
|
||||
gfn_to_pfn_memslot_atomic, before the cmpxchg. After the pinning:
|
||||
|
||||
- We have held the refcount of pfn; that means the pfn can not be freed and
|
||||
be reused for another gfn.
|
||||
|
||||
@ -8,7 +8,7 @@ Introduction
|
||||
============
|
||||
|
||||
Many Dell notebooks made after ~2020 support a WMI-based interface for
|
||||
retrieving various system data like battery temperature, ePPID, diagostic data
|
||||
retrieving various system data like battery temperature, ePPID, diagnostic data
|
||||
and fan/thermal sensor data.
|
||||
|
||||
This interface is likely used by the `Dell Data Vault` software on Windows,
|
||||
@ -277,7 +277,7 @@ Reverse-Engineering the DDV WMI interface
|
||||
4. Try to deduce the meaning of a certain WMI method by comparing the control
|
||||
flow with other ACPI methods (_BIX or _BIF for battery related methods
|
||||
for example).
|
||||
5. Use the built-in UEFI diagostics to view sensor types/values for fan/thermal
|
||||
5. Use the built-in UEFI diagnostics to view sensor types/values for fan/thermal
|
||||
related methods (sometimes overwriting static ACPI data fields can be used
|
||||
to test different sensor type values, since on some machines this data is
|
||||
not reinitialized upon a warm reset).
|
||||
|
||||
332
MAINTAINERS
332
MAINTAINERS
@ -258,12 +258,6 @@ L: linux-acenic@sunsite.dk
|
||||
S: Maintained
|
||||
F: drivers/net/ethernet/alteon/acenic*
|
||||
|
||||
ACER ASPIRE 1 EMBEDDED CONTROLLER DRIVER
|
||||
M: Nikita Travkin <nikita@trvn.ru>
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/platform/acer,aspire1-ec.yaml
|
||||
F: drivers/platform/arm64/acer-aspire1-ec.c
|
||||
|
||||
ACER ASPIRE ONE TEMPERATURE AND FAN DRIVER
|
||||
M: Peter Kaestle <peter@piie.net>
|
||||
L: platform-driver-x86@vger.kernel.org
|
||||
@ -860,7 +854,7 @@ F: drivers/crypto/allwinner/
|
||||
|
||||
ALLWINNER DMIC DRIVERS
|
||||
M: Ban Tao <fengzheng923@gmail.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/allwinner,sun50i-h6-dmic.yaml
|
||||
F: sound/soc/sunxi/sun50i-dmic.c
|
||||
@ -888,7 +882,6 @@ F: drivers/staging/media/sunxi/cedrus/
|
||||
|
||||
ALPHA PORT
|
||||
M: Richard Henderson <richard.henderson@linaro.org>
|
||||
M: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
|
||||
M: Matt Turner <mattst88@gmail.com>
|
||||
L: linux-alpha@vger.kernel.org
|
||||
S: Odd Fixes
|
||||
@ -1181,8 +1174,9 @@ F: Documentation/hid/amd-sfh*
|
||||
F: drivers/hid/amd-sfh-hid/
|
||||
|
||||
AMD SPI DRIVER
|
||||
M: Sanjay R Mehta <sanju.mehta@amd.com>
|
||||
S: Maintained
|
||||
M: Raju Rangoju <Raju.Rangoju@amd.com>
|
||||
L: linux-spi@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/spi/spi-amd.c
|
||||
|
||||
AMD XGBE DRIVER
|
||||
@ -1517,7 +1511,7 @@ F: drivers/iio/gyro/adxrs290.c
|
||||
ANALOG DEVICES INC ASOC CODEC DRIVERS
|
||||
M: Lars-Peter Clausen <lars@metafoo.de>
|
||||
M: Nuno Sá <nuno.sa@analog.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Supported
|
||||
W: http://wiki.analog.com/
|
||||
W: https://ez.analog.com/linux-software-drivers
|
||||
@ -1594,7 +1588,7 @@ F: drivers/rtc/rtc-goldfish.c
|
||||
AOA (Apple Onboard Audio) ALSA DRIVER
|
||||
M: Johannes Berg <johannes@sipsolutions.net>
|
||||
L: linuxppc-dev@lists.ozlabs.org
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: sound/aoa/
|
||||
|
||||
@ -1761,8 +1755,8 @@ F: include/uapi/linux/if_arcnet.h
|
||||
ARM AND ARM64 SoC SUB-ARCHITECTURES (COMMON PARTS)
|
||||
M: Arnd Bergmann <arnd@arndb.de>
|
||||
M: Olof Johansson <olof@lixom.net>
|
||||
M: soc@kernel.org
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: soc@lists.linux.dev
|
||||
S: Maintained
|
||||
P: Documentation/process/maintainer-soc.rst
|
||||
C: irc://irc.libera.chat/armlinux
|
||||
@ -2091,7 +2085,7 @@ F: drivers/crypto/amlogic/
|
||||
|
||||
ARM/Amlogic Meson SoC Sound Drivers
|
||||
M: Jerome Brunet <jbrunet@baylibre.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/amlogic*
|
||||
F: sound/soc/meson/
|
||||
@ -2129,7 +2123,7 @@ F: drivers/*/*alpine*
|
||||
ARM/APPLE MACHINE SOUND DRIVERS
|
||||
M: Martin Povišer <povik+lin@cutebit.org>
|
||||
L: asahi@lists.linux.dev
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/adi,ssm3515.yaml
|
||||
F: Documentation/devicetree/bindings/sound/apple,*
|
||||
@ -2263,12 +2257,6 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/mach-ep93xx/ts72xx.c
|
||||
|
||||
ARM/CIRRUS LOGIC CLPS711X ARM ARCHITECTURE
|
||||
M: Alexander Shiyan <shc_work@mail.ru>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Odd Fixes
|
||||
N: clps711x
|
||||
|
||||
ARM/CIRRUS LOGIC EP93XX ARM ARCHITECTURE
|
||||
M: Hartley Sweeten <hsweeten@visionengravers.com>
|
||||
M: Alexander Sverdlin <alexander.sverdlin@gmail.com>
|
||||
@ -2865,7 +2853,7 @@ F: Documentation/devicetree/bindings/arm/qcom.yaml
|
||||
F: Documentation/devicetree/bindings/bus/qcom*
|
||||
F: Documentation/devicetree/bindings/cache/qcom,llcc.yaml
|
||||
F: Documentation/devicetree/bindings/firmware/qcom,scm.yaml
|
||||
F: Documentation/devicetree/bindings/reserved-memory/qcom
|
||||
F: Documentation/devicetree/bindings/reserved-memory/qcom*
|
||||
F: Documentation/devicetree/bindings/soc/qcom/
|
||||
F: arch/arm/boot/dts/qcom/
|
||||
F: arch/arm/configs/qcom_defconfig
|
||||
@ -3732,7 +3720,7 @@ F: arch/arm/boot/dts/microchip/at91-tse850-3.dts
|
||||
|
||||
AXENTIA ASOC DRIVERS
|
||||
M: Peter Rosin <peda@axentia.se>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/axentia,*
|
||||
F: sound/soc/atmel/tse850-pcm5142.c
|
||||
@ -3758,6 +3746,7 @@ F: drivers/spi/spi-axi-spi-engine.c
|
||||
AXI PWM GENERATOR
|
||||
M: Michael Hennerich <michael.hennerich@analog.com>
|
||||
M: Nuno Sá <nuno.sa@analog.com>
|
||||
R: Trevor Gamblin <tgamblin@baylibre.com>
|
||||
L: linux-pwm@vger.kernel.org
|
||||
S: Supported
|
||||
W: https://ez.analog.com/linux-software-drivers
|
||||
@ -3815,14 +3804,6 @@ F: drivers/video/backlight/
|
||||
F: include/linux/backlight.h
|
||||
F: include/linux/pwm_backlight.h
|
||||
|
||||
BAIKAL-T1 PVT HARDWARE MONITOR DRIVER
|
||||
M: Serge Semin <fancer.lancer@gmail.com>
|
||||
L: linux-hwmon@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml
|
||||
F: Documentation/hwmon/bt1-pvt.rst
|
||||
F: drivers/hwmon/bt1-pvt.[ch]
|
||||
|
||||
BARCO P50 GPIO DRIVER
|
||||
M: Santosh Kumar Yadav <santoshkumar.yadav@barco.com>
|
||||
M: Peter Korsgaard <peter.korsgaard@barco.com>
|
||||
@ -4851,7 +4832,7 @@ F: include/uapi/linux/bsg.h
|
||||
|
||||
BT87X AUDIO DRIVER
|
||||
M: Clemens Ladisch <clemens@ladisch.de>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
||||
F: Documentation/sound/cards/bt87x.rst
|
||||
@ -4913,7 +4894,7 @@ F: drivers/net/can/bxcan.c
|
||||
|
||||
C-MEDIA CMI8788 DRIVER
|
||||
M: Clemens Ladisch <clemens@ladisch.de>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
||||
F: sound/pci/oxygen/
|
||||
@ -6476,7 +6457,6 @@ F: drivers/mtd/nand/raw/denali*
|
||||
|
||||
DESIGNWARE EDMA CORE IP DRIVER
|
||||
M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
||||
R: Serge Semin <fancer.lancer@gmail.com>
|
||||
L: dmaengine@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/dma/dw-edma/
|
||||
@ -7832,6 +7812,8 @@ F: drivers/gpu/drm/xlnx/
|
||||
DRM GPU SCHEDULER
|
||||
M: Luben Tuikov <ltuikov89@gmail.com>
|
||||
M: Matthew Brost <matthew.brost@intel.com>
|
||||
M: Danilo Krummrich <dakr@kernel.org>
|
||||
M: Philipp Stanner <pstanner@redhat.com>
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
S: Maintained
|
||||
T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
|
||||
@ -8252,7 +8234,7 @@ F: drivers/edac/ti_edac.c
|
||||
|
||||
EDIROL UA-101/UA-1000 DRIVER
|
||||
M: Clemens Ladisch <clemens@ladisch.de>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
||||
F: sound/usb/misc/ua101.c
|
||||
@ -8814,7 +8796,7 @@ F: drivers/net/can/usb/f81604.c
|
||||
FIREWIRE AUDIO DRIVERS and IEC 61883-1/6 PACKET STREAMING ENGINE
|
||||
M: Clemens Ladisch <clemens@ladisch.de>
|
||||
M: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
||||
F: include/uapi/sound/firewire.h
|
||||
@ -8888,7 +8870,7 @@ F: drivers/input/joystick/fsia6b.c
|
||||
|
||||
FOCUSRITE SCARLETT2 MIXER DRIVER (Scarlett Gen 2+ and Clarett)
|
||||
M: Geoffrey D. Bennett <g@b4.vu>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
W: https://github.com/geoffreybennett/scarlett-gen2
|
||||
B: https://github.com/geoffreybennett/scarlett-gen2/issues
|
||||
@ -8912,6 +8894,7 @@ F: include/linux/fortify-string.h
|
||||
F: lib/fortify_kunit.c
|
||||
F: lib/memcpy_kunit.c
|
||||
F: lib/test_fortify/*
|
||||
K: \bunsafe_memcpy\b
|
||||
K: \b__NO_FORTIFY\b
|
||||
|
||||
FPGA DFL DRIVERS
|
||||
@ -9209,7 +9192,7 @@ M: Shengjiu Wang <shengjiu.wang@gmail.com>
|
||||
M: Xiubo Li <Xiubo.Lee@gmail.com>
|
||||
R: Fabio Estevam <festevam@gmail.com>
|
||||
R: Nicolin Chen <nicoleotsuka@gmail.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
L: linuxppc-dev@lists.ozlabs.org
|
||||
S: Maintained
|
||||
F: sound/soc/fsl/fsl*
|
||||
@ -9219,7 +9202,7 @@ FREESCALE SOC LPC32XX SOUND DRIVERS
|
||||
M: J.M.B. Downing <jonathan.downing@nautel.com>
|
||||
M: Piotr Wojtaszczyk <piotr.wojtaszczyk@timesys.com>
|
||||
R: Vladimir Zapolskiy <vz@mleia.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
L: linuxppc-dev@lists.ozlabs.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/nxp,lpc3220-i2s.yaml
|
||||
@ -9227,7 +9210,7 @@ F: sound/soc/fsl/lpc3xxx-*
|
||||
|
||||
FREESCALE SOC SOUND QMC DRIVER
|
||||
M: Herve Codina <herve.codina@bootlin.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
L: linuxppc-dev@lists.ozlabs.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/fsl,qmc-audio.yaml
|
||||
@ -9742,6 +9725,7 @@ F: include/dt-bindings/gpio/
|
||||
F: include/linux/gpio.h
|
||||
F: include/linux/gpio/
|
||||
F: include/linux/of_gpio.h
|
||||
K: (devm_)?gpio_(request|free|direction|get|set)
|
||||
|
||||
GPIO UAPI
|
||||
M: Bartosz Golaszewski <brgl@bgdev.pl>
|
||||
@ -9756,14 +9740,6 @@ F: drivers/gpio/gpiolib-cdev.c
|
||||
F: include/uapi/linux/gpio.h
|
||||
F: tools/gpio/
|
||||
|
||||
GRE DEMULTIPLEXER DRIVER
|
||||
M: Dmitry Kozlov <xeb@mail.ru>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: include/net/gre.h
|
||||
F: net/ipv4/gre_demux.c
|
||||
F: net/ipv4/gre_offload.c
|
||||
|
||||
GRETH 10/100/1G Ethernet MAC device driver
|
||||
M: Andreas Larsson <andreas@gaisler.com>
|
||||
L: netdev@vger.kernel.org
|
||||
@ -10267,7 +10243,7 @@ F: Documentation/devicetree/bindings/arm/hisilicon/low-pin-count.yaml
|
||||
F: drivers/bus/hisi_lpc.c
|
||||
|
||||
HISILICON NETWORK SUBSYSTEM 3 DRIVER (HNS3)
|
||||
M: Yisen Zhuang <yisen.zhuang@huawei.com>
|
||||
M: Jian Shen <shenjian15@huawei.com>
|
||||
M: Salil Mehta <salil.mehta@huawei.com>
|
||||
M: Jijie Shao <shaojijie@huawei.com>
|
||||
L: netdev@vger.kernel.org
|
||||
@ -10276,7 +10252,7 @@ W: http://www.hisilicon.com
|
||||
F: drivers/net/ethernet/hisilicon/hns3/
|
||||
|
||||
HISILICON NETWORK SUBSYSTEM DRIVER
|
||||
M: Yisen Zhuang <yisen.zhuang@huawei.com>
|
||||
M: Jian Shen <shenjian15@huawei.com>
|
||||
M: Salil Mehta <salil.mehta@huawei.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
@ -11154,7 +11130,7 @@ F: drivers/iio/pressure/dps310.c
|
||||
|
||||
INFINEON PEB2466 ASoC CODEC
|
||||
M: Herve Codina <herve.codina@bootlin.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/infineon,peb2466.yaml
|
||||
F: sound/soc/codecs/peb2466.c
|
||||
@ -11280,10 +11256,10 @@ F: security/integrity/
|
||||
F: security/integrity/ima/
|
||||
|
||||
INTEGRITY POLICY ENFORCEMENT (IPE)
|
||||
M: Fan Wu <wufan@linux.microsoft.com>
|
||||
M: Fan Wu <wufan@kernel.org>
|
||||
L: linux-security-module@vger.kernel.org
|
||||
S: Supported
|
||||
T: git https://github.com/microsoft/ipe.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe.git
|
||||
F: Documentation/admin-guide/LSM/ipe.rst
|
||||
F: Documentation/security/ipe.rst
|
||||
F: scripts/ipe/
|
||||
@ -11317,7 +11293,7 @@ M: Bard Liao <yung-chuan.liao@linux.intel.com>
|
||||
M: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
|
||||
M: Kai Vehmanen <kai.vehmanen@linux.intel.com>
|
||||
R: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Supported
|
||||
F: sound/soc/intel/
|
||||
|
||||
@ -11496,7 +11472,7 @@ F: include/uapi/linux/idxd.h
|
||||
|
||||
INTEL IN FIELD SCAN (IFS) DEVICE
|
||||
M: Jithu Joseph <jithu.joseph@intel.com>
|
||||
R: Ashok Raj <ashok.raj@intel.com>
|
||||
R: Ashok Raj <ashok.raj.linux@gmail.com>
|
||||
R: Tony Luck <tony.luck@intel.com>
|
||||
S: Maintained
|
||||
F: drivers/platform/x86/intel/ifs
|
||||
@ -11601,6 +11577,16 @@ F: drivers/crypto/intel/keembay/keembay-ocs-hcu-core.c
|
||||
F: drivers/crypto/intel/keembay/ocs-hcu.c
|
||||
F: drivers/crypto/intel/keembay/ocs-hcu.h
|
||||
|
||||
INTEL LA JOLLA COVE ADAPTER (LJCA) USB I/O EXPANDER DRIVERS
|
||||
M: Wentong Wu <wentong.wu@intel.com>
|
||||
M: Sakari Ailus <sakari.ailus@linux.intel.com>
|
||||
S: Maintained
|
||||
F: drivers/gpio/gpio-ljca.c
|
||||
F: drivers/i2c/busses/i2c-ljca.c
|
||||
F: drivers/spi/spi-ljca.c
|
||||
F: drivers/usb/misc/usb-ljca.c
|
||||
F: include/linux/usb/ljca.h
|
||||
|
||||
INTEL MANAGEMENT ENGINE (mei)
|
||||
M: Tomas Winkler <tomas.winkler@intel.com>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
@ -12001,7 +11987,7 @@ F: drivers/tty/ipwireless/
|
||||
|
||||
IRON DEVICE AUDIO CODEC DRIVERS
|
||||
M: Kiseok Jo <kiseok.jo@irondevice.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/irondevice,*
|
||||
F: sound/soc/codecs/sma*
|
||||
@ -12239,6 +12225,7 @@ R: Dmitry Vyukov <dvyukov@google.com>
|
||||
R: Vincenzo Frascino <vincenzo.frascino@arm.com>
|
||||
L: kasan-dev@googlegroups.com
|
||||
S: Maintained
|
||||
B: https://bugzilla.kernel.org/buglist.cgi?component=Sanitizers&product=Memory%20Management
|
||||
F: Documentation/dev-tools/kasan.rst
|
||||
F: arch/*/include/asm/*kasan.h
|
||||
F: arch/*/mm/kasan_init*
|
||||
@ -12262,6 +12249,7 @@ R: Dmitry Vyukov <dvyukov@google.com>
|
||||
R: Andrey Konovalov <andreyknvl@gmail.com>
|
||||
L: kasan-dev@googlegroups.com
|
||||
S: Maintained
|
||||
B: https://bugzilla.kernel.org/buglist.cgi?component=Sanitizers&product=Memory%20Management
|
||||
F: Documentation/dev-tools/kcov.rst
|
||||
F: include/linux/kcov.h
|
||||
F: include/uapi/linux/kcov.h
|
||||
@ -12343,6 +12331,7 @@ F: include/linux/randomize_kstack.h
|
||||
F: kernel/configs/hardening.config
|
||||
F: lib/usercopy_kunit.c
|
||||
F: mm/usercopy.c
|
||||
F: security/Kconfig.hardening
|
||||
K: \b(add|choose)_random_kstack_offset\b
|
||||
K: \b__check_(object_size|heap_object)\b
|
||||
K: \b__counted_by\b
|
||||
@ -12459,7 +12448,7 @@ F: virt/kvm/*
|
||||
KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
|
||||
M: Marc Zyngier <maz@kernel.org>
|
||||
M: Oliver Upton <oliver.upton@linux.dev>
|
||||
R: James Morse <james.morse@arm.com>
|
||||
R: Joey Gouly <joey.gouly@arm.com>
|
||||
R: Suzuki K Poulose <suzuki.poulose@arm.com>
|
||||
R: Zenghui Yu <yuzenghui@huawei.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
@ -12940,49 +12929,29 @@ LIBATA PATA ARASAN COMPACT FLASH CONTROLLER
|
||||
M: Viresh Kumar <vireshk@kernel.org>
|
||||
L: linux-ide@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
|
||||
F: drivers/ata/pata_arasan_cf.c
|
||||
F: include/linux/pata_arasan_cf_data.h
|
||||
|
||||
LIBATA PATA DRIVERS
|
||||
R: Sergey Shtylyov <s.shtylyov@omp.ru>
|
||||
L: linux-ide@vger.kernel.org
|
||||
F: drivers/ata/ata_*.c
|
||||
F: drivers/ata/pata_*.c
|
||||
|
||||
LIBATA PATA FARADAY FTIDE010 AND GEMINI SATA BRIDGE DRIVERS
|
||||
M: Linus Walleij <linus.walleij@linaro.org>
|
||||
L: linux-ide@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
|
||||
F: drivers/ata/pata_ftide010.c
|
||||
F: drivers/ata/sata_gemini.c
|
||||
F: drivers/ata/sata_gemini.h
|
||||
|
||||
LIBATA SATA AHCI PLATFORM devices support
|
||||
M: Hans de Goede <hdegoede@redhat.com>
|
||||
M: Jens Axboe <axboe@kernel.dk>
|
||||
L: linux-ide@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
|
||||
F: drivers/ata/ahci_platform.c
|
||||
F: drivers/ata/libahci_platform.c
|
||||
F: include/linux/ahci_platform.h
|
||||
|
||||
LIBATA SATA AHCI SYNOPSYS DWC CONTROLLER DRIVER
|
||||
M: Serge Semin <fancer.lancer@gmail.com>
|
||||
L: linux-ide@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata.git
|
||||
F: Documentation/devicetree/bindings/ata/baikal,bt1-ahci.yaml
|
||||
F: Documentation/devicetree/bindings/ata/snps,dwc-ahci.yaml
|
||||
F: drivers/ata/ahci_dwc.c
|
||||
|
||||
LIBATA SATA PROMISE TX2/TX4 CONTROLLER DRIVER
|
||||
M: Mikael Pettersson <mikpelinux@gmail.com>
|
||||
L: linux-ide@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
|
||||
F: drivers/ata/sata_promise.*
|
||||
|
||||
LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)
|
||||
@ -13952,7 +13921,7 @@ F: drivers/media/i2c/max96717.c
|
||||
|
||||
MAX9860 MONO AUDIO VOICE CODEC DRIVER
|
||||
M: Peter Rosin <peda@axentia.se>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/max9860.txt
|
||||
F: sound/soc/codecs/max9860.*
|
||||
@ -14175,8 +14144,7 @@ T: git git://linuxtv.org/media_tree.git
|
||||
F: drivers/media/platform/nxp/imx-pxp.[ch]
|
||||
|
||||
MEDIA DRIVERS FOR ASCOT2E
|
||||
M: Sergey Kozlov <serjk@netup.ru>
|
||||
M: Abylay Ospan <aospan@netup.ru>
|
||||
M: Abylay Ospan <aospan@amazon.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
S: Supported
|
||||
W: https://linuxtv.org
|
||||
@ -14193,8 +14161,7 @@ T: git git://linuxtv.org/media_tree.git
|
||||
F: drivers/media/dvb-frontends/cxd2099*
|
||||
|
||||
MEDIA DRIVERS FOR CXD2841ER
|
||||
M: Sergey Kozlov <serjk@netup.ru>
|
||||
M: Abylay Ospan <aospan@netup.ru>
|
||||
M: Abylay Ospan <aospan@amazon.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
S: Supported
|
||||
W: https://linuxtv.org
|
||||
@ -14247,7 +14214,7 @@ F: drivers/media/platform/nxp/imx7-media-csi.c
|
||||
F: drivers/media/platform/nxp/imx8mq-mipi-csi2.c
|
||||
|
||||
MEDIA DRIVERS FOR HELENE
|
||||
M: Abylay Ospan <aospan@netup.ru>
|
||||
M: Abylay Ospan <aospan@amazon.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
S: Supported
|
||||
W: https://linuxtv.org
|
||||
@ -14256,8 +14223,7 @@ T: git git://linuxtv.org/media_tree.git
|
||||
F: drivers/media/dvb-frontends/helene*
|
||||
|
||||
MEDIA DRIVERS FOR HORUS3A
|
||||
M: Sergey Kozlov <serjk@netup.ru>
|
||||
M: Abylay Ospan <aospan@netup.ru>
|
||||
M: Abylay Ospan <aospan@amazon.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
S: Supported
|
||||
W: https://linuxtv.org
|
||||
@ -14266,8 +14232,7 @@ T: git git://linuxtv.org/media_tree.git
|
||||
F: drivers/media/dvb-frontends/horus3a*
|
||||
|
||||
MEDIA DRIVERS FOR LNBH25
|
||||
M: Sergey Kozlov <serjk@netup.ru>
|
||||
M: Abylay Ospan <aospan@netup.ru>
|
||||
M: Abylay Ospan <aospan@amazon.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
S: Supported
|
||||
W: https://linuxtv.org
|
||||
@ -14283,8 +14248,7 @@ T: git git://linuxtv.org/media_tree.git
|
||||
F: drivers/media/dvb-frontends/mxl5xx*
|
||||
|
||||
MEDIA DRIVERS FOR NETUP PCI UNIVERSAL DVB devices
|
||||
M: Sergey Kozlov <serjk@netup.ru>
|
||||
M: Abylay Ospan <aospan@netup.ru>
|
||||
M: Abylay Ospan <aospan@amazon.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
S: Supported
|
||||
W: https://linuxtv.org
|
||||
@ -14909,9 +14873,10 @@ N: include/linux/page[-_]*
|
||||
|
||||
MEMORY MAPPING
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
R: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||
M: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||
M: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||
R: Vlastimil Babka <vbabka@suse.cz>
|
||||
R: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||
R: Jann Horn <jannh@google.com>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
W: http://www.linux-mm.org
|
||||
@ -14934,13 +14899,6 @@ F: drivers/mtd/
|
||||
F: include/linux/mtd/
|
||||
F: include/uapi/mtd/
|
||||
|
||||
MEMSENSING MICROSYSTEMS MSA311 DRIVER
|
||||
M: Dmitry Rokosov <ddrokosov@sberdevices.ru>
|
||||
L: linux-iio@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/iio/accel/memsensing,msa311.yaml
|
||||
F: drivers/iio/accel/msa311.c
|
||||
|
||||
MEN A21 WATCHDOG DRIVER
|
||||
M: Johannes Thumshirn <morbidrsa@gmail.com>
|
||||
L: linux-watchdog@vger.kernel.org
|
||||
@ -15085,7 +15043,8 @@ F: drivers/spi/spi-at91-usart.c
|
||||
|
||||
MICROCHIP AUDIO ASOC DRIVERS
|
||||
M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
M: Andrei Simion <andrei.simion@microchip.com>
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/sound/atmel*
|
||||
F: Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
|
||||
@ -15193,6 +15152,7 @@ F: include/video/atmel_lcdc.h
|
||||
|
||||
MICROCHIP MCP16502 PMIC DRIVER
|
||||
M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
|
||||
M: Andrei Simion <andrei.simion@microchip.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml
|
||||
@ -15274,7 +15234,6 @@ F: drivers/tty/serial/8250/8250_pci1xxxx.c
|
||||
|
||||
MICROCHIP POLARFIRE FPGA DRIVERS
|
||||
M: Conor Dooley <conor.dooley@microchip.com>
|
||||
R: Vladimir Georgiev <v.georgiev@metrotek.ru>
|
||||
L: linux-fpga@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/fpga/microchip,mpf-spi-fpga-mgr.yaml
|
||||
@ -15324,6 +15283,7 @@ F: drivers/spi/spi-atmel.*
|
||||
|
||||
MICROCHIP SSC DRIVER
|
||||
M: Claudiu Beznea <claudiu.beznea@tuxon.dev>
|
||||
M: Andrei Simion <andrei.simion@microchip.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/misc/atmel-ssc.txt
|
||||
@ -15529,17 +15489,6 @@ F: arch/mips/
|
||||
F: drivers/platform/mips/
|
||||
F: include/dt-bindings/mips/
|
||||
|
||||
MIPS BAIKAL-T1 PLATFORM
|
||||
M: Serge Semin <fancer.lancer@gmail.com>
|
||||
L: linux-mips@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/bus/baikal,bt1-*.yaml
|
||||
F: Documentation/devicetree/bindings/clock/baikal,bt1-*.yaml
|
||||
F: drivers/bus/bt1-*.c
|
||||
F: drivers/clk/baikal-t1/
|
||||
F: drivers/memory/bt1-l2-ctl.c
|
||||
F: drivers/mtd/maps/physmap-bt1-rom.[ch]
|
||||
|
||||
MIPS BOSTON DEVELOPMENT BOARD
|
||||
M: Paul Burton <paulburton@kernel.org>
|
||||
L: linux-mips@vger.kernel.org
|
||||
@ -15552,7 +15501,6 @@ F: include/dt-bindings/clock/boston-clock.h
|
||||
|
||||
MIPS CORE DRIVERS
|
||||
M: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
||||
M: Serge Semin <fancer.lancer@gmail.com>
|
||||
L: linux-mips@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/bus/mips_cdmm.c
|
||||
@ -15956,7 +15904,7 @@ F: include/linux/mtd/*nand*.h
|
||||
|
||||
NATIVE INSTRUMENTS USB SOUND INTERFACE DRIVER
|
||||
M: Daniel Mack <zonque@gmail.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
W: http://www.native-instruments.com
|
||||
F: sound/usb/caiaq/
|
||||
@ -16087,6 +16035,7 @@ F: include/uapi/linux/net_dropmon.h
|
||||
F: net/core/drop_monitor.c
|
||||
|
||||
NETWORKING DRIVERS
|
||||
M: Andrew Lunn <andrew+netdev@lunn.ch>
|
||||
M: "David S. Miller" <davem@davemloft.net>
|
||||
M: Eric Dumazet <edumazet@google.com>
|
||||
M: Jakub Kicinski <kuba@kernel.org>
|
||||
@ -16134,7 +16083,6 @@ F: drivers/net/wireless/
|
||||
|
||||
NETWORKING [DSA]
|
||||
M: Andrew Lunn <andrew@lunn.ch>
|
||||
M: Florian Fainelli <f.fainelli@gmail.com>
|
||||
M: Vladimir Oltean <olteanv@gmail.com>
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/net/dsa/
|
||||
@ -16152,6 +16100,7 @@ M: "David S. Miller" <davem@davemloft.net>
|
||||
M: Eric Dumazet <edumazet@google.com>
|
||||
M: Jakub Kicinski <kuba@kernel.org>
|
||||
M: Paolo Abeni <pabeni@redhat.com>
|
||||
R: Simon Horman <horms@kernel.org>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
P: Documentation/process/maintainer-netdev.rst
|
||||
@ -16194,10 +16143,22 @@ F: include/uapi/linux/rtnetlink.h
|
||||
F: lib/net_utils.c
|
||||
F: lib/random32.c
|
||||
F: net/
|
||||
F: samples/pktgen/
|
||||
F: tools/net/
|
||||
F: tools/testing/selftests/net/
|
||||
X: Documentation/networking/mac80211-injection.rst
|
||||
X: Documentation/networking/mac80211_hwsim/
|
||||
X: Documentation/networking/regulatory.rst
|
||||
X: include/net/cfg80211.h
|
||||
X: include/net/ieee80211_radiotap.h
|
||||
X: include/net/iw_handler.h
|
||||
X: include/net/mac80211.h
|
||||
X: include/net/wext.h
|
||||
X: net/9p/
|
||||
X: net/bluetooth/
|
||||
X: net/mac80211/
|
||||
X: net/rfkill/
|
||||
X: net/wireless/
|
||||
|
||||
NETWORKING [IPSEC]
|
||||
M: Steffen Klassert <steffen.klassert@secunet.com>
|
||||
@ -16507,12 +16468,6 @@ F: include/linux/ntb.h
|
||||
F: include/linux/ntb_transport.h
|
||||
F: tools/testing/selftests/ntb/
|
||||
|
||||
NTB IDT DRIVER
|
||||
M: Serge Semin <fancer.lancer@gmail.com>
|
||||
L: ntb@lists.linux.dev
|
||||
S: Supported
|
||||
F: drivers/ntb/hw/idt/
|
||||
|
||||
NTB INTEL DRIVER
|
||||
M: Dave Jiang <dave.jiang@intel.com>
|
||||
L: ntb@lists.linux.dev
|
||||
@ -16727,7 +16682,7 @@ F: drivers/extcon/extcon-ptn5150.c
|
||||
|
||||
NXP SGTL5000 DRIVER
|
||||
M: Fabio Estevam <festevam@gmail.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/fsl,sgtl5000.yaml
|
||||
F: sound/soc/codecs/sgtl5000*
|
||||
@ -16751,7 +16706,7 @@ K: "nxp,tda998x"
|
||||
|
||||
NXP TFA9879 DRIVER
|
||||
M: Peter Rosin <peda@axentia.se>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/nxp,tfa9879.yaml
|
||||
F: sound/soc/codecs/tfa9879*
|
||||
@ -16763,7 +16718,7 @@ F: drivers/nfc/nxp-nci
|
||||
|
||||
NXP/Goodix TFA989X (TFA1) DRIVER
|
||||
M: Stephan Gerhold <stephan@gerhold.net>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml
|
||||
F: sound/soc/codecs/tfa989x.c
|
||||
@ -16849,7 +16804,7 @@ F: include/uapi/misc/ocxl.h
|
||||
OMAP AUDIO SUPPORT
|
||||
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-sound@vger.kernel.org
|
||||
L: linux-omap@vger.kernel.org
|
||||
S: Maintained
|
||||
F: sound/soc/ti/n810.c
|
||||
@ -17399,7 +17354,7 @@ F: include/linux/pm_opp.h
|
||||
|
||||
OPL4 DRIVER
|
||||
M: Clemens Ladisch <clemens@ladisch.de>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
||||
F: sound/drivers/opl4/
|
||||
@ -18526,13 +18481,6 @@ F: drivers/pps/
|
||||
F: include/linux/pps*.h
|
||||
F: include/uapi/linux/pps.h
|
||||
|
||||
PPTP DRIVER
|
||||
M: Dmitry Kozlov <xeb@mail.ru>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
W: http://sourceforge.net/projects/accel-pptp
|
||||
F: drivers/net/ppp/pptp.c
|
||||
|
||||
PRESSURE STALL INFORMATION (PSI)
|
||||
M: Johannes Weiner <hannes@cmpxchg.org>
|
||||
M: Suren Baghdasaryan <surenb@google.com>
|
||||
@ -18782,7 +18730,7 @@ F: drivers/crypto/intel/qat/
|
||||
|
||||
QCOM AUDIO (ASoC) DRIVERS
|
||||
M: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/soc/qcom/qcom,apr*
|
||||
@ -19513,6 +19461,14 @@ S: Maintained
|
||||
F: Documentation/tools/rtla/
|
||||
F: tools/tracing/rtla/
|
||||
|
||||
Real-time Linux (PREEMPT_RT)
|
||||
M: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
|
||||
M: Clark Williams <clrkwllms@kernel.org>
|
||||
M: Steven Rostedt <rostedt@goodmis.org>
|
||||
L: linux-rt-devel@lists.linux.dev
|
||||
S: Supported
|
||||
K: PREEMPT_RT
|
||||
|
||||
REALTEK AUDIO CODECS
|
||||
M: Oder Chiou <oder_chiou@realtek.com>
|
||||
S: Maintained
|
||||
@ -19622,15 +19578,6 @@ S: Supported
|
||||
F: Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml
|
||||
F: drivers/i2c/busses/i2c-emev2.c
|
||||
|
||||
RENESAS ETHERNET AVB DRIVER
|
||||
R: Sergey Shtylyov <s.shtylyov@omp.ru>
|
||||
L: netdev@vger.kernel.org
|
||||
L: linux-renesas-soc@vger.kernel.org
|
||||
F: Documentation/devicetree/bindings/net/renesas,etheravb.yaml
|
||||
F: drivers/net/ethernet/renesas/Kconfig
|
||||
F: drivers/net/ethernet/renesas/Makefile
|
||||
F: drivers/net/ethernet/renesas/ravb*
|
||||
|
||||
RENESAS ETHERNET SWITCH DRIVER
|
||||
R: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
|
||||
L: netdev@vger.kernel.org
|
||||
@ -19651,7 +19598,7 @@ F: drivers/net/ethernet/renesas/rtsn.*
|
||||
|
||||
RENESAS IDT821034 ASoC CODEC
|
||||
M: Herve Codina <herve.codina@bootlin.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/renesas,idt821034.yaml
|
||||
F: sound/soc/codecs/idt821034.c
|
||||
@ -19680,14 +19627,6 @@ F: Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml
|
||||
F: drivers/i2c/busses/i2c-rcar.c
|
||||
F: drivers/i2c/busses/i2c-sh_mobile.c
|
||||
|
||||
RENESAS R-CAR SATA DRIVER
|
||||
R: Sergey Shtylyov <s.shtylyov@omp.ru>
|
||||
L: linux-ide@vger.kernel.org
|
||||
L: linux-renesas-soc@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml
|
||||
F: drivers/ata/sata_rcar.c
|
||||
|
||||
RENESAS R-CAR THERMAL DRIVERS
|
||||
M: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
||||
L: linux-renesas-soc@vger.kernel.org
|
||||
@ -19763,16 +19702,6 @@ S: Supported
|
||||
F: Documentation/devicetree/bindings/i2c/renesas,rzv2m.yaml
|
||||
F: drivers/i2c/busses/i2c-rzv2m.c
|
||||
|
||||
RENESAS SUPERH ETHERNET DRIVER
|
||||
R: Sergey Shtylyov <s.shtylyov@omp.ru>
|
||||
L: netdev@vger.kernel.org
|
||||
L: linux-renesas-soc@vger.kernel.org
|
||||
F: Documentation/devicetree/bindings/net/renesas,ether.yaml
|
||||
F: drivers/net/ethernet/renesas/Kconfig
|
||||
F: drivers/net/ethernet/renesas/Makefile
|
||||
F: drivers/net/ethernet/renesas/sh_eth*
|
||||
F: include/linux/sh_eth.h
|
||||
|
||||
RENESAS USB PHY DRIVER
|
||||
M: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
|
||||
L: linux-renesas-soc@vger.kernel.org
|
||||
@ -19917,12 +19846,10 @@ L: linux-riscv@lists.infradead.org
|
||||
S: Maintained
|
||||
Q: https://patchwork.kernel.org/project/linux-riscv/list/
|
||||
T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/
|
||||
F: Documentation/devicetree/bindings/riscv/
|
||||
F: arch/riscv/boot/dts/
|
||||
X: arch/riscv/boot/dts/allwinner/
|
||||
X: arch/riscv/boot/dts/renesas/
|
||||
X: arch/riscv/boot/dts/sophgo/
|
||||
X: arch/riscv/boot/dts/thead/
|
||||
F: arch/riscv/boot/dts/canaan/
|
||||
F: arch/riscv/boot/dts/microchip/
|
||||
F: arch/riscv/boot/dts/sifive/
|
||||
F: arch/riscv/boot/dts/starfive/
|
||||
|
||||
RISC-V PMU DRIVERS
|
||||
M: Atish Patra <atishp@atishpatra.org>
|
||||
@ -20402,7 +20329,7 @@ F: security/safesetid/
|
||||
|
||||
SAMSUNG AUDIO (ASoC) DRIVERS
|
||||
M: Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
B: mailto:linux-samsung-soc@vger.kernel.org
|
||||
F: Documentation/devicetree/bindings/sound/samsung*
|
||||
@ -20938,7 +20865,7 @@ F: drivers/media/rc/serial_ir.c
|
||||
|
||||
SERIAL LOW-POWER INTER-CHIP MEDIA BUS (SLIMbus)
|
||||
M: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/slimbus/
|
||||
F: drivers/slimbus/
|
||||
@ -21372,7 +21299,7 @@ F: Documentation/devicetree/bindings/i2c/socionext,synquacer-i2c.yaml
|
||||
F: drivers/i2c/busses/i2c-synquacer.c
|
||||
|
||||
SOCIONEXT UNIPHIER SOUND DRIVER
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Orphan
|
||||
F: sound/soc/uniphier/
|
||||
|
||||
@ -21631,7 +21558,7 @@ F: tools/testing/selftests/alsa
|
||||
|
||||
SOUND - COMPRESSED AUDIO
|
||||
M: Vinod Koul <vkoul@kernel.org>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Supported
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
||||
F: Documentation/sound/designs/compress-offload.rst
|
||||
@ -21689,12 +21616,21 @@ S: Supported
|
||||
W: https://github.com/thesofproject/linux/
|
||||
F: sound/soc/sof/
|
||||
|
||||
SOUND - GENERIC SOUND CARD (Simple-Audio-Card, Audio-Graph-Card)
|
||||
M: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
|
||||
S: Supported
|
||||
L: linux-sound@vger.kernel.org
|
||||
F: sound/soc/generic/
|
||||
F: include/sound/simple_card*
|
||||
F: Documentation/devicetree/bindings/sound/simple-card.yaml
|
||||
F: Documentation/devicetree/bindings/sound/audio-graph*.yaml
|
||||
|
||||
SOUNDWIRE SUBSYSTEM
|
||||
M: Vinod Koul <vkoul@kernel.org>
|
||||
M: Bard Liao <yung-chuan.liao@linux.intel.com>
|
||||
R: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
|
||||
R: Sanyog Kale <sanyog.r.kale@intel.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Supported
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire.git
|
||||
F: Documentation/driver-api/soundwire/
|
||||
@ -21767,8 +21703,8 @@ F: drivers/accessibility/speakup/
|
||||
SPEAR PLATFORM/CLOCK/PINCTRL SUPPORT
|
||||
M: Viresh Kumar <vireshk@kernel.org>
|
||||
M: Shiraz Hashim <shiraz.linux.kernel@gmail.com>
|
||||
M: soc@kernel.org
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: soc@lists.linux.dev
|
||||
S: Maintained
|
||||
W: http://www.st.com/spear
|
||||
F: arch/arm/boot/dts/st/spear*
|
||||
@ -22167,7 +22103,7 @@ F: kernel/static_call.c
|
||||
|
||||
STI AUDIO (ASoC) DRIVERS
|
||||
M: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/st,sti-asoc-card.txt
|
||||
F: sound/soc/sti/
|
||||
@ -22188,7 +22124,7 @@ F: drivers/media/usb/stk1160/
|
||||
STM32 AUDIO (ASoC) DRIVERS
|
||||
M: Olivier Moysan <olivier.moysan@foss.st.com>
|
||||
M: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
|
||||
F: Documentation/devicetree/bindings/sound/st,stm32-*.yaml
|
||||
@ -22426,19 +22362,11 @@ F: drivers/tty/serial/8250/8250_lpss.c
|
||||
|
||||
SYNOPSYS DESIGNWARE APB GPIO DRIVER
|
||||
M: Hoan Tran <hoan@os.amperecomputing.com>
|
||||
M: Serge Semin <fancer.lancer@gmail.com>
|
||||
L: linux-gpio@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/gpio/snps,dw-apb-gpio.yaml
|
||||
F: drivers/gpio/gpio-dwapb.c
|
||||
|
||||
SYNOPSYS DESIGNWARE APB SSI DRIVER
|
||||
M: Serge Semin <fancer.lancer@gmail.com>
|
||||
L: linux-spi@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
|
||||
F: drivers/spi/spi-dw*
|
||||
|
||||
SYNOPSYS DESIGNWARE AXI DMAC DRIVER
|
||||
M: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
|
||||
S: Maintained
|
||||
@ -22891,7 +22819,7 @@ F: drivers/irqchip/irq-xtensa-*
|
||||
|
||||
TEXAS INSTRUMENTS ASoC DRIVERS
|
||||
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml
|
||||
F: sound/soc/ti/
|
||||
@ -22900,7 +22828,7 @@ TEXAS INSTRUMENTS AUDIO (ASoC/HDA) DRIVERS
|
||||
M: Shenghao Ding <shenghao-ding@ti.com>
|
||||
M: Kevin Lu <kevin-lu@ti.com>
|
||||
M: Baojun Xu <baojun.xu@ti.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/tas2552.txt
|
||||
F: Documentation/devicetree/bindings/sound/ti,tas2562.yaml
|
||||
@ -23268,7 +23196,7 @@ F: drivers/soc/ti/*
|
||||
TI LM49xxx FAMILY ASoC CODEC DRIVERS
|
||||
M: M R Swami Reddy <mr.swami.reddy@ti.com>
|
||||
M: Vishwas A Deshpande <vishwas.a.deshpande@ti.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: sound/soc/codecs/isabelle*
|
||||
F: sound/soc/codecs/lm49453*
|
||||
@ -23282,15 +23210,15 @@ F: Documentation/devicetree/bindings/iio/adc/ti,lmp92064.yaml
|
||||
F: drivers/iio/adc/ti-lmp92064.c
|
||||
|
||||
TI PCM3060 ASoC CODEC DRIVER
|
||||
M: Kirill Marinushkin <kmarinushkin@birdec.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
M: Kirill Marinushkin <k.marinushkin@gmail.com>
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/pcm3060.txt
|
||||
F: sound/soc/codecs/pcm3060*
|
||||
|
||||
TI TAS571X FAMILY ASoC CODEC DRIVER
|
||||
M: Kevin Cernekee <cernekee@chromium.org>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Odd Fixes
|
||||
F: sound/soc/codecs/tas571x*
|
||||
|
||||
@ -23318,7 +23246,7 @@ F: drivers/iio/adc/ti-tsc2046.c
|
||||
|
||||
TI TWL4030 SERIES SOC CODEC DRIVER
|
||||
M: Peter Ujfalusi <peter.ujfalusi@gmail.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: sound/soc/codecs/twl4030*
|
||||
|
||||
@ -23748,12 +23676,6 @@ L: linux-input@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/hid/hid-udraw-ps3.c
|
||||
|
||||
UFS FILESYSTEM
|
||||
M: Evgeniy Dushistov <dushistov@mail.ru>
|
||||
S: Maintained
|
||||
F: Documentation/admin-guide/ufs.rst
|
||||
F: fs/ufs/
|
||||
|
||||
UHID USERSPACE HID IO DRIVER
|
||||
M: David Rheinsberg <david@readahead.eu>
|
||||
L: linux-input@vger.kernel.org
|
||||
@ -23994,7 +23916,7 @@ F: drivers/usb/storage/
|
||||
|
||||
USB MIDI DRIVER
|
||||
M: Clemens Ladisch <clemens@ladisch.de>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
||||
F: sound/usb/midi.*
|
||||
@ -24056,6 +23978,7 @@ USB RAW GADGET DRIVER
|
||||
R: Andrey Konovalov <andreyknvl@gmail.com>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
B: https://github.com/xairy/raw-gadget/issues
|
||||
F: Documentation/usb/raw-gadget.rst
|
||||
F: drivers/usb/gadget/legacy/raw_gadget.c
|
||||
F: include/uapi/linux/usb/raw_gadget.h
|
||||
@ -24172,8 +24095,12 @@ F: drivers/usb/host/xhci*
|
||||
|
||||
USER DATAGRAM PROTOCOL (UDP)
|
||||
M: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: include/linux/udp.h
|
||||
F: include/net/udp.h
|
||||
F: include/trace/events/udp.h
|
||||
F: include/uapi/linux/udp.h
|
||||
F: net/ipv4/udp.c
|
||||
F: net/ipv6/udp.c
|
||||
|
||||
@ -24654,7 +24581,7 @@ VIRTIO SOUND DRIVER
|
||||
M: Anton Yakovlev <anton.yakovlev@opensynergy.com>
|
||||
M: "Michael S. Tsirkin" <mst@redhat.com>
|
||||
L: virtualization@lists.linux.dev
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Maintained
|
||||
F: include/uapi/linux/virtio_snd.h
|
||||
F: sound/virtio/*
|
||||
@ -24723,9 +24650,10 @@ F: tools/testing/vsock/
|
||||
|
||||
VMA
|
||||
M: Andrew Morton <akpm@linux-foundation.org>
|
||||
R: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||
M: Liam R. Howlett <Liam.Howlett@oracle.com>
|
||||
M: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||
R: Vlastimil Babka <vbabka@suse.cz>
|
||||
R: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
|
||||
R: Jann Horn <jannh@google.com>
|
||||
L: linux-mm@kvack.org
|
||||
S: Maintained
|
||||
W: https://www.linux-mm.org
|
||||
@ -25383,7 +25311,7 @@ F: include/xen/interface/io/usbif.h
|
||||
XEN SOUND FRONTEND DRIVER
|
||||
M: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
|
||||
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
S: Supported
|
||||
F: sound/xen/*
|
||||
|
||||
@ -25399,7 +25327,7 @@ F: include/xen/arm/swiotlb-xen.h
|
||||
F: include/xen/swiotlb-xen.h
|
||||
|
||||
XFS FILESYSTEM
|
||||
M: Chandan Babu R <chandan.babu@oracle.com>
|
||||
M: Carlos Maiolino <cem@kernel.org>
|
||||
R: Darrick J. Wong <djwong@kernel.org>
|
||||
L: linux-xfs@vger.kernel.org
|
||||
S: Supported
|
||||
|
||||
4
Makefile
4
Makefile
@ -2,7 +2,7 @@
|
||||
VERSION = 6
|
||||
PATCHLEVEL = 12
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc1
|
||||
EXTRAVERSION = -rc7
|
||||
NAME = Baby Opossum Posse
|
||||
|
||||
# *DOCUMENTATION*
|
||||
@ -1645,7 +1645,7 @@ help:
|
||||
echo '* dtbs - Build device tree blobs for enabled boards'; \
|
||||
echo ' dtbs_install - Install dtbs to $(INSTALL_DTBS_PATH)'; \
|
||||
echo ' dt_binding_check - Validate device tree binding documents and examples'; \
|
||||
echo ' dt_binding_schema - Build processed device tree binding schemas'; \
|
||||
echo ' dt_binding_schemas - Build processed device tree binding schemas'; \
|
||||
echo ' dtbs_check - Validate device tree source files';\
|
||||
echo '')
|
||||
|
||||
|
||||
16
arch/Kconfig
16
arch/Kconfig
@ -838,7 +838,7 @@ config CFI_CLANG
|
||||
config CFI_ICALL_NORMALIZE_INTEGERS
|
||||
bool "Normalize CFI tags for integers"
|
||||
depends on CFI_CLANG
|
||||
depends on $(cc-option,-fsanitize=kcfi -fsanitize-cfi-icall-experimental-normalize-integers)
|
||||
depends on HAVE_CFI_ICALL_NORMALIZE_INTEGERS_CLANG
|
||||
help
|
||||
This option normalizes the CFI tags for integer types so that all
|
||||
integer types of the same size and signedness receive the same CFI
|
||||
@ -851,6 +851,20 @@ config CFI_ICALL_NORMALIZE_INTEGERS
|
||||
|
||||
This option is necessary for using CFI with Rust. If unsure, say N.
|
||||
|
||||
config HAVE_CFI_ICALL_NORMALIZE_INTEGERS_CLANG
|
||||
def_bool y
|
||||
depends on $(cc-option,-fsanitize=kcfi -fsanitize-cfi-icall-experimental-normalize-integers)
|
||||
# With GCOV/KASAN we need this fix: https://github.com/llvm/llvm-project/pull/104826
|
||||
depends on CLANG_VERSION >= 190103 || (!GCOV_KERNEL && !KASAN_GENERIC && !KASAN_SW_TAGS)
|
||||
|
||||
config HAVE_CFI_ICALL_NORMALIZE_INTEGERS_RUSTC
|
||||
def_bool y
|
||||
depends on HAVE_CFI_ICALL_NORMALIZE_INTEGERS_CLANG
|
||||
depends on RUSTC_VERSION >= 107900
|
||||
# With GCOV/KASAN we need this fix: https://github.com/rust-lang/rust/pull/129373
|
||||
depends on (RUSTC_LLVM_VERSION >= 190103 && RUSTC_VERSION >= 108200) || \
|
||||
(!GCOV_KERNEL && !KASAN_GENERIC && !KASAN_SW_TAGS)
|
||||
|
||||
config CFI_PERMISSIVE
|
||||
bool "Use CFI in permissive mode"
|
||||
depends on CFI_CLANG
|
||||
|
||||
@ -22,7 +22,7 @@
|
||||
|
||||
#include <asm/gentrap.h>
|
||||
#include <linux/uaccess.h>
|
||||
#include <asm/unaligned.h>
|
||||
#include <linux/unaligned.h>
|
||||
#include <asm/sysinfo.h>
|
||||
#include <asm/hwrpb.h>
|
||||
#include <asm/mmu_context.h>
|
||||
|
||||
@ -9,7 +9,7 @@
|
||||
#include <linux/types.h>
|
||||
#include <asm/byteorder.h>
|
||||
#include <asm/page.h>
|
||||
#include <asm/unaligned.h>
|
||||
#include <linux/unaligned.h>
|
||||
|
||||
#ifdef CONFIG_ISA_ARCV2
|
||||
#include <asm/barrier.h>
|
||||
|
||||
@ -14,6 +14,7 @@ typedef struct {
|
||||
unsigned long asid[NR_CPUS]; /* 8 bit MMU PID + Generation cycle */
|
||||
} mm_context_t;
|
||||
|
||||
struct pt_regs;
|
||||
extern void do_tlb_overlap_fault(unsigned long, unsigned long, struct pt_regs *);
|
||||
|
||||
#endif
|
||||
|
||||
@ -1,27 +0,0 @@
|
||||
/* SPDX-License-Identifier: GPL-2.0-only */
|
||||
/*
|
||||
* Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. (www.synopsys.com)
|
||||
*/
|
||||
|
||||
#ifndef _ASM_ARC_UNALIGNED_H
|
||||
#define _ASM_ARC_UNALIGNED_H
|
||||
|
||||
/* ARC700 can't handle unaligned Data accesses. */
|
||||
|
||||
#include <asm-generic/unaligned.h>
|
||||
#include <asm/ptrace.h>
|
||||
|
||||
#ifdef CONFIG_ARC_EMUL_UNALIGNED
|
||||
int misaligned_fixup(unsigned long address, struct pt_regs *regs,
|
||||
struct callee_regs *cregs);
|
||||
#else
|
||||
static inline int
|
||||
misaligned_fixup(unsigned long address, struct pt_regs *regs,
|
||||
struct callee_regs *cregs)
|
||||
{
|
||||
/* Not fixed */
|
||||
return 1;
|
||||
}
|
||||
#endif
|
||||
|
||||
#endif /* _ASM_ARC_UNALIGNED_H */
|
||||
@ -18,8 +18,9 @@
|
||||
#include <linux/kgdb.h>
|
||||
#include <asm/entry.h>
|
||||
#include <asm/setup.h>
|
||||
#include <asm/unaligned.h>
|
||||
#include <linux/unaligned.h>
|
||||
#include <asm/kprobes.h>
|
||||
#include "unaligned.h"
|
||||
|
||||
void die(const char *str, struct pt_regs *regs, unsigned long address)
|
||||
{
|
||||
|
||||
@ -12,6 +12,7 @@
|
||||
#include <linux/ptrace.h>
|
||||
#include <linux/uaccess.h>
|
||||
#include <asm/disasm.h>
|
||||
#include "unaligned.h"
|
||||
|
||||
#ifdef CONFIG_CPU_BIG_ENDIAN
|
||||
#define BE 1
|
||||
|
||||
16
arch/arc/kernel/unaligned.h
Normal file
16
arch/arc/kernel/unaligned.h
Normal file
@ -0,0 +1,16 @@
|
||||
struct pt_regs;
|
||||
struct callee_regs;
|
||||
|
||||
#ifdef CONFIG_ARC_EMUL_UNALIGNED
|
||||
int misaligned_fixup(unsigned long address, struct pt_regs *regs,
|
||||
struct callee_regs *cregs);
|
||||
#else
|
||||
static inline int
|
||||
misaligned_fixup(unsigned long address, struct pt_regs *regs,
|
||||
struct callee_regs *cregs)
|
||||
{
|
||||
/* Not fixed */
|
||||
return 1;
|
||||
}
|
||||
#endif
|
||||
|
||||
@ -19,7 +19,7 @@
|
||||
#include <linux/uaccess.h>
|
||||
#include <linux/ptrace.h>
|
||||
#include <asm/sections.h>
|
||||
#include <asm/unaligned.h>
|
||||
#include <linux/unaligned.h>
|
||||
#include <asm/unwind.h>
|
||||
|
||||
extern char __start_unwind[], __end_unwind[];
|
||||
|
||||
@ -77,7 +77,7 @@ &gpio {
|
||||
};
|
||||
|
||||
&hdmi {
|
||||
hpd-gpios = <&expgpio 1 GPIO_ACTIVE_LOW>;
|
||||
hpd-gpios = <&expgpio 0 GPIO_ACTIVE_LOW>;
|
||||
power-domains = <&power RPI_POWER_DOMAIN_HDMI>;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
@ -325,8 +325,8 @@ regulator-state-mem {
|
||||
&i2c2 {
|
||||
status = "okay";
|
||||
|
||||
rt5616: rt5616@1b {
|
||||
compatible = "rt5616";
|
||||
rt5616: audio-codec@1b {
|
||||
compatible = "realtek,rt5616";
|
||||
reg = <0x1b>;
|
||||
clocks = <&cru SCLK_I2S_OUT>;
|
||||
clock-names = "mclk";
|
||||
|
||||
@ -384,12 +384,13 @@ reboot-mode {
|
||||
};
|
||||
};
|
||||
|
||||
acodec: acodec-ana@20030000 {
|
||||
compatible = "rk3036-codec";
|
||||
acodec: audio-codec@20030000 {
|
||||
compatible = "rockchip,rk3036-codec";
|
||||
reg = <0x20030000 0x4000>;
|
||||
rockchip,grf = <&grf>;
|
||||
clock-names = "acodec_pclk";
|
||||
clocks = <&cru PCLK_ACODEC>;
|
||||
rockchip,grf = <&grf>;
|
||||
#sound-dai-cells = <0>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
@ -399,7 +400,6 @@ hdmi: hdmi@20034000 {
|
||||
interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cru PCLK_HDMI>;
|
||||
clock-names = "pclk";
|
||||
rockchip,grf = <&grf>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&hdmi_ctl>;
|
||||
#sound-dai-cells = <0>;
|
||||
@ -553,11 +553,11 @@ i2c0: i2c@20072000 {
|
||||
};
|
||||
|
||||
spi: spi@20074000 {
|
||||
compatible = "rockchip,rockchip-spi";
|
||||
compatible = "rockchip,rk3036-spi";
|
||||
reg = <0x20074000 0x1000>;
|
||||
interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cru PCLK_SPI>, <&cru SCLK_SPI>;
|
||||
clock-names = "apb-pclk","spi_pclk";
|
||||
clocks = <&cru SCLK_SPI>, <&cru PCLK_SPI>;
|
||||
clock-names = "spiclk", "apb_pclk";
|
||||
dmas = <&pdma 8>, <&pdma 9>;
|
||||
dma-names = "tx", "rx";
|
||||
pinctrl-names = "default";
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
#include <asm/hwcap.h>
|
||||
#include <asm/neon.h>
|
||||
#include <asm/simd.h>
|
||||
#include <asm/unaligned.h>
|
||||
#include <linux/unaligned.h>
|
||||
#include <crypto/aes.h>
|
||||
#include <crypto/ctr.h>
|
||||
#include <crypto/internal/simd.h>
|
||||
|
||||
@ -18,7 +18,7 @@
|
||||
#include <asm/hwcap.h>
|
||||
#include <asm/neon.h>
|
||||
#include <asm/simd.h>
|
||||
#include <asm/unaligned.h>
|
||||
#include <linux/unaligned.h>
|
||||
|
||||
#define PMULL_MIN_LEN 64L /* minimum size of buffer
|
||||
* for crc32_pmull_le_16 */
|
||||
|
||||
@ -9,7 +9,7 @@
|
||||
#include <asm/hwcap.h>
|
||||
#include <asm/neon.h>
|
||||
#include <asm/simd.h>
|
||||
#include <asm/unaligned.h>
|
||||
#include <linux/unaligned.h>
|
||||
#include <crypto/aes.h>
|
||||
#include <crypto/gcm.h>
|
||||
#include <crypto/b128ops.h>
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
#include <asm/hwcap.h>
|
||||
#include <asm/neon.h>
|
||||
#include <asm/simd.h>
|
||||
#include <asm/unaligned.h>
|
||||
#include <linux/unaligned.h>
|
||||
#include <crypto/algapi.h>
|
||||
#include <crypto/internal/hash.h>
|
||||
#include <crypto/internal/poly1305.h>
|
||||
|
||||
@ -16,7 +16,7 @@
|
||||
#include <asm/hwcap.h>
|
||||
#include <asm/simd.h>
|
||||
#include <asm/neon.h>
|
||||
#include <asm/unaligned.h>
|
||||
#include <linux/unaligned.h>
|
||||
|
||||
#include "sha256_glue.h"
|
||||
|
||||
|
||||
@ -12,7 +12,7 @@
|
||||
#include <linux/string.h>
|
||||
#include <asm/page.h>
|
||||
#include <asm/domain.h>
|
||||
#include <asm/unaligned.h>
|
||||
#include <linux/unaligned.h>
|
||||
#include <asm/unified.h>
|
||||
#include <asm/pgtable.h>
|
||||
#include <asm/proc-fns.h>
|
||||
|
||||
@ -22,7 +22,7 @@
|
||||
|
||||
#include <asm/cp15.h>
|
||||
#include <asm/system_info.h>
|
||||
#include <asm/unaligned.h>
|
||||
#include <linux/unaligned.h>
|
||||
#include <asm/opcodes.h>
|
||||
|
||||
#include "fault.h"
|
||||
|
||||
@ -200,7 +200,8 @@ config ARM64
|
||||
select HAVE_DMA_CONTIGUOUS
|
||||
select HAVE_DYNAMIC_FTRACE
|
||||
select HAVE_DYNAMIC_FTRACE_WITH_ARGS \
|
||||
if $(cc-option,-fpatchable-function-entry=2)
|
||||
if (GCC_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS || \
|
||||
CLANG_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS)
|
||||
select HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS \
|
||||
if DYNAMIC_FTRACE_WITH_ARGS && DYNAMIC_FTRACE_WITH_CALL_OPS
|
||||
select HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS \
|
||||
@ -286,12 +287,10 @@ config CLANG_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS
|
||||
def_bool CC_IS_CLANG
|
||||
# https://github.com/ClangBuiltLinux/linux/issues/1507
|
||||
depends on AS_IS_GNU || (AS_IS_LLVM && (LD_IS_LLD || LD_VERSION >= 23600))
|
||||
select HAVE_DYNAMIC_FTRACE_WITH_ARGS
|
||||
|
||||
config GCC_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS
|
||||
def_bool CC_IS_GCC
|
||||
depends on $(cc-option,-fpatchable-function-entry=2)
|
||||
select HAVE_DYNAMIC_FTRACE_WITH_ARGS
|
||||
|
||||
config 64BIT
|
||||
def_bool y
|
||||
@ -1097,6 +1096,7 @@ config ARM64_ERRATUM_3194386
|
||||
* ARM Cortex-A78C erratum 3324346
|
||||
* ARM Cortex-A78C erratum 3324347
|
||||
* ARM Cortex-A710 erratam 3324338
|
||||
* ARM Cortex-A715 errartum 3456084
|
||||
* ARM Cortex-A720 erratum 3456091
|
||||
* ARM Cortex-A725 erratum 3456106
|
||||
* ARM Cortex-X1 erratum 3324344
|
||||
@ -1107,6 +1107,7 @@ config ARM64_ERRATUM_3194386
|
||||
* ARM Cortex-X925 erratum 3324334
|
||||
* ARM Neoverse-N1 erratum 3324349
|
||||
* ARM Neoverse N2 erratum 3324339
|
||||
* ARM Neoverse-N3 erratum 3456111
|
||||
* ARM Neoverse-V1 erratum 3324341
|
||||
* ARM Neoverse V2 erratum 3324336
|
||||
* ARM Neoverse-V3 erratum 3312417
|
||||
@ -2213,6 +2214,7 @@ config ARM64_SME
|
||||
bool "ARM Scalable Matrix Extension support"
|
||||
default y
|
||||
depends on ARM64_SVE
|
||||
depends on BROKEN
|
||||
help
|
||||
The Scalable Matrix Extension (SME) is an extension to the AArch64
|
||||
execution state which utilises a substantial subset of the SVE
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
#
|
||||
# Copyright (C) 1995-2001 by Russell King
|
||||
|
||||
LDFLAGS_vmlinux :=--no-undefined -X
|
||||
LDFLAGS_vmlinux :=--no-undefined -X --pic-veneer
|
||||
|
||||
ifeq ($(CONFIG_RELOCATABLE), y)
|
||||
# Pass --no-apply-dynamic-relocs to restore pre-binutils-2.27 behaviour
|
||||
|
||||
@ -14,7 +14,7 @@ qm_lvds0_lis_lpcg: qxp_mipi1_lis_lpcg: clock-controller@56243000 {
|
||||
compatible = "fsl,imx8qxp-lpcg";
|
||||
reg = <0x56243000 0x4>;
|
||||
#clock-cells = <1>;
|
||||
clock-output-names = "mipi1_lis_lpcg_ipg_clk";
|
||||
clock-output-names = "lvds0_lis_lpcg_ipg_clk";
|
||||
power-domains = <&pd IMX_SC_R_MIPI_1>;
|
||||
};
|
||||
|
||||
@ -22,9 +22,9 @@ qm_lvds0_pwm_lpcg: qxp_mipi1_pwm_lpcg: clock-controller@5624300c {
|
||||
compatible = "fsl,imx8qxp-lpcg";
|
||||
reg = <0x5624300c 0x4>;
|
||||
#clock-cells = <1>;
|
||||
clock-output-names = "mipi1_pwm_lpcg_clk",
|
||||
"mipi1_pwm_lpcg_ipg_clk",
|
||||
"mipi1_pwm_lpcg_32k_clk";
|
||||
clock-output-names = "lvds0_pwm_lpcg_clk",
|
||||
"lvds0_pwm_lpcg_ipg_clk",
|
||||
"lvds0_pwm_lpcg_32k_clk";
|
||||
power-domains = <&pd IMX_SC_R_MIPI_1_PWM_0>;
|
||||
};
|
||||
|
||||
@ -32,8 +32,8 @@ qm_lvds0_i2c0_lpcg: qxp_mipi1_i2c0_lpcg: clock-controller@56243010 {
|
||||
compatible = "fsl,imx8qxp-lpcg";
|
||||
reg = <0x56243010 0x4>;
|
||||
#clock-cells = <1>;
|
||||
clock-output-names = "mipi1_i2c0_lpcg_clk",
|
||||
"mipi1_i2c0_lpcg_ipg_clk";
|
||||
clock-output-names = "lvds0_i2c0_lpcg_clk",
|
||||
"lvds0_i2c0_lpcg_ipg_clk";
|
||||
power-domains = <&pd IMX_SC_R_MIPI_1_I2C_0>;
|
||||
};
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@ vpu: vpu@2c000000 {
|
||||
mu_m0: mailbox@2d000000 {
|
||||
compatible = "fsl,imx6sx-mu";
|
||||
reg = <0x2d000000 0x20000>;
|
||||
interrupts = <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupts = <GIC_SPI 472 IRQ_TYPE_LEVEL_HIGH>;
|
||||
#mbox-cells = <2>;
|
||||
power-domains = <&pd IMX_SC_R_VPU_MU_0>;
|
||||
status = "disabled";
|
||||
@ -24,7 +24,7 @@ mu_m0: mailbox@2d000000 {
|
||||
mu1_m0: mailbox@2d020000 {
|
||||
compatible = "fsl,imx6sx-mu";
|
||||
reg = <0x2d020000 0x20000>;
|
||||
interrupts = <GIC_SPI 470 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupts = <GIC_SPI 473 IRQ_TYPE_LEVEL_HIGH>;
|
||||
#mbox-cells = <2>;
|
||||
power-domains = <&pd IMX_SC_R_VPU_MU_1>;
|
||||
status = "disabled";
|
||||
|
||||
@ -218,6 +218,18 @@ ldb_lvds_ch1: endpoint {
|
||||
};
|
||||
};
|
||||
|
||||
&media_blk_ctrl {
|
||||
/*
|
||||
* The LVDS panel on this device uses 72.4 MHz pixel clock,
|
||||
* set IMX8MP_VIDEO_PLL1 to 72.4 * 7 = 506.8 MHz so the LDB
|
||||
* serializer and LCDIFv3 scanout engine can reach accurate
|
||||
* pixel clock of exactly 72.4 MHz.
|
||||
*/
|
||||
assigned-clock-rates = <500000000>, <200000000>,
|
||||
<0>, <0>, <500000000>,
|
||||
<506800000>;
|
||||
};
|
||||
|
||||
&snvs_pwrkey {
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
@ -71,6 +71,7 @@ &media_blk_ctrl {
|
||||
assigned-clock-rates = <500000000>, <200000000>, <0>,
|
||||
/* IMX8MP_CLK_MEDIA_DISP2_PIX = pixelclk of lvds panel */
|
||||
<68900000>,
|
||||
<500000000>,
|
||||
/* IMX8MP_VIDEO_PLL1 = IMX8MP_CLK_MEDIA_LDB * 2 */
|
||||
<964600000>;
|
||||
};
|
||||
|
||||
@ -1261,7 +1261,7 @@ usdhc1: mmc@30b40000 {
|
||||
compatible = "fsl,imx8mp-usdhc", "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc";
|
||||
reg = <0x30b40000 0x10000>;
|
||||
interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&clk IMX8MP_CLK_DUMMY>,
|
||||
clocks = <&clk IMX8MP_CLK_IPG_ROOT>,
|
||||
<&clk IMX8MP_CLK_NAND_USDHC_BUS>,
|
||||
<&clk IMX8MP_CLK_USDHC1_ROOT>;
|
||||
clock-names = "ipg", "ahb", "per";
|
||||
@ -1275,7 +1275,7 @@ usdhc2: mmc@30b50000 {
|
||||
compatible = "fsl,imx8mp-usdhc", "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc";
|
||||
reg = <0x30b50000 0x10000>;
|
||||
interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&clk IMX8MP_CLK_DUMMY>,
|
||||
clocks = <&clk IMX8MP_CLK_IPG_ROOT>,
|
||||
<&clk IMX8MP_CLK_NAND_USDHC_BUS>,
|
||||
<&clk IMX8MP_CLK_USDHC2_ROOT>;
|
||||
clock-names = "ipg", "ahb", "per";
|
||||
@ -1289,7 +1289,7 @@ usdhc3: mmc@30b60000 {
|
||||
compatible = "fsl,imx8mp-usdhc", "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc";
|
||||
reg = <0x30b60000 0x10000>;
|
||||
interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&clk IMX8MP_CLK_DUMMY>,
|
||||
clocks = <&clk IMX8MP_CLK_IPG_ROOT>,
|
||||
<&clk IMX8MP_CLK_NAND_USDHC_BUS>,
|
||||
<&clk IMX8MP_CLK_USDHC3_ROOT>;
|
||||
clock-names = "ipg", "ahb", "per";
|
||||
|
||||
@ -5,6 +5,14 @@
|
||||
* Author: Alexander Stein
|
||||
*/
|
||||
|
||||
&mu_m0 {
|
||||
interrupts = <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>;
|
||||
};
|
||||
|
||||
&mu1_m0 {
|
||||
interrupts = <GIC_SPI 470 IRQ_TYPE_LEVEL_HIGH>;
|
||||
};
|
||||
|
||||
&vpu_core0 {
|
||||
reg = <0x2d040000 0x10000>;
|
||||
};
|
||||
|
||||
@ -384,7 +384,7 @@ pcc4: clock-controller@29800000 {
|
||||
};
|
||||
|
||||
flexspi2: spi@29810000 {
|
||||
compatible = "nxp,imx8mm-fspi";
|
||||
compatible = "nxp,imx8ulp-fspi";
|
||||
reg = <0x29810000 0x10000>, <0x60000000 0x10000000>;
|
||||
reg-names = "fspi_base", "fspi_mmap";
|
||||
#address-cells = <1>;
|
||||
|
||||
@ -136,7 +136,7 @@ cp0_i2c0_pins: cp0-i2c0-pins {
|
||||
};
|
||||
|
||||
cp0_mdio_pins: cp0-mdio-pins {
|
||||
marvell,pins = "mpp40", "mpp41";
|
||||
marvell,pins = "mpp0", "mpp1";
|
||||
marvell,function = "ge";
|
||||
};
|
||||
|
||||
|
||||
@ -248,7 +248,7 @@ rpm: remoteproc {
|
||||
|
||||
smd-edge {
|
||||
interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
|
||||
mboxes = <&apcs1_mbox 0>;
|
||||
qcom,ipc = <&apcs1_mbox 8 0>;
|
||||
qcom,smd-edge = <15>;
|
||||
|
||||
rpm_requests: rpm-requests {
|
||||
|
||||
@ -1973,7 +1973,7 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
|
||||
|
||||
clocks = <&gcc GCC_PCIE_1_PIPE_CLK>,
|
||||
<&gcc GCC_PCIE_1_PIPE_CLK_SRC>,
|
||||
<&pcie1_phy>,
|
||||
<&pcie1_phy QMP_PCIE_PIPE_CLK>,
|
||||
<&rpmhcc RPMH_CXO_CLK>,
|
||||
<&gcc GCC_PCIE_1_AUX_CLK>,
|
||||
<&gcc GCC_PCIE_1_CFG_AHB_CLK>,
|
||||
|
||||
@ -139,6 +139,8 @@ vreg_nvme: regulator-nvme {
|
||||
|
||||
pinctrl-0 = <&nvme_reg_en>;
|
||||
pinctrl-names = "default";
|
||||
|
||||
regulator-boot-on;
|
||||
};
|
||||
|
||||
vph_pwr: regulator-vph-pwr {
|
||||
|
||||
@ -134,6 +134,8 @@ vreg_nvme: regulator-nvme {
|
||||
|
||||
pinctrl-0 = <&nvme_reg_en>;
|
||||
pinctrl-names = "default";
|
||||
|
||||
regulator-boot-on;
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
@ -177,9 +177,9 @@ sound {
|
||||
compatible = "qcom,x1e80100-sndcard";
|
||||
model = "X1E80100-CRD";
|
||||
audio-routing = "WooferLeft IN", "WSA WSA_SPK1 OUT",
|
||||
"TwitterLeft IN", "WSA WSA_SPK2 OUT",
|
||||
"TweeterLeft IN", "WSA WSA_SPK2 OUT",
|
||||
"WooferRight IN", "WSA2 WSA_SPK2 OUT",
|
||||
"TwitterRight IN", "WSA2 WSA_SPK2 OUT",
|
||||
"TweeterRight IN", "WSA2 WSA_SPK2 OUT",
|
||||
"IN1_HPHL", "HPHL_OUT",
|
||||
"IN2_HPHR", "HPHR_OUT",
|
||||
"AMIC2", "MIC BIAS2",
|
||||
@ -300,6 +300,8 @@ vreg_nvme: regulator-nvme {
|
||||
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&nvme_reg_en>;
|
||||
|
||||
regulator-boot-on;
|
||||
};
|
||||
|
||||
vreg_wwan: regulator-wwan {
|
||||
@ -933,7 +935,7 @@ left_tweeter: speaker@0,1 {
|
||||
reg = <0 1>;
|
||||
reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
|
||||
#sound-dai-cells = <0>;
|
||||
sound-name-prefix = "TwitterLeft";
|
||||
sound-name-prefix = "TweeterLeft";
|
||||
vdd-1p8-supply = <&vreg_l15b_1p8>;
|
||||
vdd-io-supply = <&vreg_l12b_1p2>;
|
||||
qcom,port-mapping = <4 5 6 7 11 13>;
|
||||
@ -986,7 +988,7 @@ right_tweeter: speaker@0,1 {
|
||||
reg = <0 1>;
|
||||
reset-gpios = <&lpass_tlmm 13 GPIO_ACTIVE_LOW>;
|
||||
#sound-dai-cells = <0>;
|
||||
sound-name-prefix = "TwitterRight";
|
||||
sound-name-prefix = "TweeterRight";
|
||||
vdd-1p8-supply = <&vreg_l15b_1p8>;
|
||||
vdd-io-supply = <&vreg_l12b_1p2>;
|
||||
qcom,port-mapping = <4 5 6 7 11 13>;
|
||||
|
||||
@ -205,6 +205,8 @@ vreg_nvme: regulator-nvme {
|
||||
|
||||
pinctrl-0 = <&nvme_reg_en>;
|
||||
pinctrl-names = "default";
|
||||
|
||||
regulator-boot-on;
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
@ -164,6 +164,8 @@ vreg_nvme: regulator-nvme {
|
||||
|
||||
pinctrl-0 = <&nvme_reg_en>;
|
||||
pinctrl-names = "default";
|
||||
|
||||
regulator-boot-on;
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
@ -253,6 +253,8 @@ vreg_nvme: regulator-nvme {
|
||||
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&nvme_reg_en>;
|
||||
|
||||
regulator-boot-on;
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
@ -2924,14 +2924,14 @@ pcie6a: pci@1bf8000 {
|
||||
"mhi";
|
||||
#address-cells = <3>;
|
||||
#size-cells = <2>;
|
||||
ranges = <0x01000000 0 0x00000000 0 0x70200000 0 0x100000>,
|
||||
<0x02000000 0 0x70300000 0 0x70300000 0 0x3d00000>;
|
||||
bus-range = <0 0xff>;
|
||||
ranges = <0x01000000 0x0 0x00000000 0x0 0x70200000 0x0 0x100000>,
|
||||
<0x02000000 0x0 0x70300000 0x0 0x70300000 0x0 0x1d00000>;
|
||||
bus-range = <0x00 0xff>;
|
||||
|
||||
dma-coherent;
|
||||
|
||||
linux,pci-domain = <6>;
|
||||
num-lanes = <2>;
|
||||
num-lanes = <4>;
|
||||
|
||||
interrupts = <GIC_SPI 773 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 774 IRQ_TYPE_LEVEL_HIGH>,
|
||||
@ -2997,19 +2997,22 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
|
||||
};
|
||||
|
||||
pcie6a_phy: phy@1bfc000 {
|
||||
compatible = "qcom,x1e80100-qmp-gen4x2-pcie-phy";
|
||||
reg = <0 0x01bfc000 0 0x2000>;
|
||||
compatible = "qcom,x1e80100-qmp-gen4x4-pcie-phy";
|
||||
reg = <0 0x01bfc000 0 0x2000>,
|
||||
<0 0x01bfe000 0 0x2000>;
|
||||
|
||||
clocks = <&gcc GCC_PCIE_6A_PHY_AUX_CLK>,
|
||||
<&gcc GCC_PCIE_6A_CFG_AHB_CLK>,
|
||||
<&rpmhcc RPMH_CXO_CLK>,
|
||||
<&tcsr TCSR_PCIE_4L_CLKREF_EN>,
|
||||
<&gcc GCC_PCIE_6A_PHY_RCHNG_CLK>,
|
||||
<&gcc GCC_PCIE_6A_PIPE_CLK>;
|
||||
<&gcc GCC_PCIE_6A_PIPE_CLK>,
|
||||
<&gcc GCC_PCIE_6A_PIPEDIV2_CLK>;
|
||||
clock-names = "aux",
|
||||
"cfg_ahb",
|
||||
"ref",
|
||||
"rchng",
|
||||
"pipe";
|
||||
"pipe",
|
||||
"pipediv2";
|
||||
|
||||
resets = <&gcc GCC_PCIE_6A_PHY_BCR>,
|
||||
<&gcc GCC_PCIE_6A_NOCSR_COM_PHY_BCR>;
|
||||
@ -3021,6 +3024,8 @@ pcie6a_phy: phy@1bfc000 {
|
||||
|
||||
power-domains = <&gcc GCC_PCIE_6_PHY_GDSC>;
|
||||
|
||||
qcom,4ln-config-sel = <&tcsr 0x1a000 0>;
|
||||
|
||||
#clock-cells = <0>;
|
||||
clock-output-names = "pcie6a_pipe_clk";
|
||||
|
||||
@ -3097,7 +3102,7 @@ pcie5: pci@1c00000 {
|
||||
assigned-clocks = <&gcc GCC_PCIE_5_AUX_CLK>;
|
||||
assigned-clock-rates = <19200000>;
|
||||
|
||||
interconnects = <&pcie_south_anoc MASTER_PCIE_5 QCOM_ICC_TAG_ALWAYS
|
||||
interconnects = <&pcie_north_anoc MASTER_PCIE_5 QCOM_ICC_TAG_ALWAYS
|
||||
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
|
||||
<&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS
|
||||
&cnoc_main SLAVE_PCIE_5 QCOM_ICC_TAG_ALWAYS>;
|
||||
@ -3124,14 +3129,16 @@ pcie5_phy: phy@1c06000 {
|
||||
|
||||
clocks = <&gcc GCC_PCIE_5_AUX_CLK>,
|
||||
<&gcc GCC_PCIE_5_CFG_AHB_CLK>,
|
||||
<&rpmhcc RPMH_CXO_CLK>,
|
||||
<&tcsr TCSR_PCIE_2L_5_CLKREF_EN>,
|
||||
<&gcc GCC_PCIE_5_PHY_RCHNG_CLK>,
|
||||
<&gcc GCC_PCIE_5_PIPE_CLK>;
|
||||
<&gcc GCC_PCIE_5_PIPE_CLK>,
|
||||
<&gcc GCC_PCIE_5_PIPEDIV2_CLK>;
|
||||
clock-names = "aux",
|
||||
"cfg_ahb",
|
||||
"ref",
|
||||
"rchng",
|
||||
"pipe";
|
||||
"pipe",
|
||||
"pipediv2";
|
||||
|
||||
resets = <&gcc GCC_PCIE_5_PHY_BCR>;
|
||||
reset-names = "phy";
|
||||
@ -3166,8 +3173,8 @@ pcie4: pci@1c08000 {
|
||||
"mhi";
|
||||
#address-cells = <3>;
|
||||
#size-cells = <2>;
|
||||
ranges = <0x01000000 0 0x00000000 0 0x7c200000 0 0x100000>,
|
||||
<0x02000000 0 0x7c300000 0 0x7c300000 0 0x3d00000>;
|
||||
ranges = <0x01000000 0x0 0x00000000 0x0 0x7c200000 0x0 0x100000>,
|
||||
<0x02000000 0x0 0x7c300000 0x0 0x7c300000 0x0 0x1d00000>;
|
||||
bus-range = <0x00 0xff>;
|
||||
|
||||
dma-coherent;
|
||||
@ -3217,7 +3224,7 @@ pcie4: pci@1c08000 {
|
||||
assigned-clocks = <&gcc GCC_PCIE_4_AUX_CLK>;
|
||||
assigned-clock-rates = <19200000>;
|
||||
|
||||
interconnects = <&pcie_south_anoc MASTER_PCIE_4 QCOM_ICC_TAG_ALWAYS
|
||||
interconnects = <&pcie_north_anoc MASTER_PCIE_4 QCOM_ICC_TAG_ALWAYS
|
||||
&mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
|
||||
<&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS
|
||||
&cnoc_main SLAVE_PCIE_4 QCOM_ICC_TAG_ALWAYS>;
|
||||
@ -3254,14 +3261,16 @@ pcie4_phy: phy@1c0e000 {
|
||||
|
||||
clocks = <&gcc GCC_PCIE_4_AUX_CLK>,
|
||||
<&gcc GCC_PCIE_4_CFG_AHB_CLK>,
|
||||
<&rpmhcc RPMH_CXO_CLK>,
|
||||
<&tcsr TCSR_PCIE_2L_4_CLKREF_EN>,
|
||||
<&gcc GCC_PCIE_4_PHY_RCHNG_CLK>,
|
||||
<&gcc GCC_PCIE_4_PIPE_CLK>;
|
||||
<&gcc GCC_PCIE_4_PIPE_CLK>,
|
||||
<&gcc GCC_PCIE_4_PIPEDIV2_CLK>;
|
||||
clock-names = "aux",
|
||||
"cfg_ahb",
|
||||
"ref",
|
||||
"rchng",
|
||||
"pipe";
|
||||
"pipe",
|
||||
"pipediv2";
|
||||
|
||||
resets = <&gcc GCC_PCIE_4_PHY_BCR>;
|
||||
reset-names = "phy";
|
||||
@ -6084,7 +6093,8 @@ system-cache-controller@25000000 {
|
||||
<0 0x25a00000 0 0x200000>,
|
||||
<0 0x25c00000 0 0x200000>,
|
||||
<0 0x25e00000 0 0x200000>,
|
||||
<0 0x26000000 0 0x200000>;
|
||||
<0 0x26000000 0 0x200000>,
|
||||
<0 0x26200000 0 0x200000>;
|
||||
reg-names = "llcc0_base",
|
||||
"llcc1_base",
|
||||
"llcc2_base",
|
||||
@ -6093,7 +6103,8 @@ system-cache-controller@25000000 {
|
||||
"llcc5_base",
|
||||
"llcc6_base",
|
||||
"llcc7_base",
|
||||
"llcc_broadcast_base";
|
||||
"llcc_broadcast_base",
|
||||
"llcc_broadcast_and_base";
|
||||
interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
|
||||
};
|
||||
|
||||
|
||||
@ -66,7 +66,6 @@ &emmc {
|
||||
bus-width = <8>;
|
||||
cap-mmc-highspeed;
|
||||
mmc-hs200-1_8v;
|
||||
supports-emmc;
|
||||
mmc-pwrseq = <&emmc_pwrseq>;
|
||||
non-removable;
|
||||
vmmc-supply = <&vcc_3v3>;
|
||||
|
||||
@ -36,14 +36,14 @@ leds {
|
||||
|
||||
power_led: led-0 {
|
||||
label = "firefly:red:power";
|
||||
linux,default-trigger = "ir-power-click";
|
||||
linux,default-trigger = "default-on";
|
||||
default-state = "on";
|
||||
gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
|
||||
};
|
||||
|
||||
user_led: led-1 {
|
||||
label = "firefly:blue:user";
|
||||
linux,default-trigger = "ir-user-click";
|
||||
linux,default-trigger = "rc-feedback";
|
||||
default-state = "off";
|
||||
gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_HIGH>;
|
||||
};
|
||||
|
||||
@ -24,9 +24,7 @@ &emmc {
|
||||
disable-wp;
|
||||
mmc-hs200-1_8v;
|
||||
non-removable;
|
||||
num-slots = <1>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_bus8>;
|
||||
supports-emmc;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
@ -754,8 +754,7 @@ hdmi: hdmi@ff3c0000 {
|
||||
compatible = "rockchip,rk3328-dw-hdmi";
|
||||
reg = <0x0 0xff3c0000 0x0 0x20000>;
|
||||
reg-io-width = <4>;
|
||||
interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cru PCLK_HDMI>,
|
||||
<&cru SCLK_HDMI_SFC>,
|
||||
<&cru SCLK_RTC32K>;
|
||||
|
||||
@ -61,7 +61,6 @@ i2c_lvds_blc: i2c@0 {
|
||||
fan: fan@18 {
|
||||
compatible = "ti,amc6821";
|
||||
reg = <0x18>;
|
||||
#cooling-cells = <2>;
|
||||
};
|
||||
|
||||
rtc_twi: rtc@6f {
|
||||
|
||||
@ -541,7 +541,7 @@ &i2c1 {
|
||||
status = "okay";
|
||||
|
||||
rt5651: audio-codec@1a {
|
||||
compatible = "rockchip,rt5651";
|
||||
compatible = "realtek,rt5651";
|
||||
reg = <0x1a>;
|
||||
clocks = <&cru SCLK_I2S_8CH_OUT>;
|
||||
clock-names = "mclk";
|
||||
|
||||
@ -166,7 +166,6 @@ vcc1v8_lcd: vcc1v8-lcd {
|
||||
regulator-max-microvolt = <1800000>;
|
||||
vin-supply = <&vcc3v3_sys>;
|
||||
gpio = <&gpio3 RK_PA5 GPIO_ACTIVE_HIGH>;
|
||||
pinctrl-names = "default";
|
||||
};
|
||||
|
||||
/* MIPI DSI panel 2.8v supply */
|
||||
@ -178,7 +177,6 @@ vcc2v8_lcd: vcc2v8-lcd {
|
||||
regulator-max-microvolt = <2800000>;
|
||||
vin-supply = <&vcc3v3_sys>;
|
||||
gpio = <&gpio3 RK_PA1 GPIO_ACTIVE_HIGH>;
|
||||
pinctrl-names = "default";
|
||||
};
|
||||
|
||||
vibrator {
|
||||
|
||||
@ -114,7 +114,6 @@ &i2c1 {
|
||||
es8388: es8388@11 {
|
||||
compatible = "everest,es8388";
|
||||
reg = <0x11>;
|
||||
clock-names = "mclk";
|
||||
clocks = <&cru SCLK_I2S_8CH_OUT>;
|
||||
#sound-dai-cells = <0>;
|
||||
};
|
||||
|
||||
@ -576,7 +576,7 @@ &uart0 {
|
||||
bluetooth {
|
||||
compatible = "brcm,bcm43438-bt";
|
||||
clocks = <&rk808 1>;
|
||||
clock-names = "ext_clock";
|
||||
clock-names = "txco";
|
||||
device-wakeup-gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH>;
|
||||
host-wakeup-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_HIGH>;
|
||||
shutdown-gpios = <&gpio0 RK_PB1 GPIO_ACTIVE_HIGH>;
|
||||
|
||||
@ -163,7 +163,7 @@ &i2c1 {
|
||||
status = "okay";
|
||||
|
||||
rt5651: rt5651@1a {
|
||||
compatible = "rockchip,rt5651";
|
||||
compatible = "realtek,rt5651";
|
||||
reg = <0x1a>;
|
||||
clocks = <&cru SCLK_I2S_8CH_OUT>;
|
||||
clock-names = "mclk";
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user