renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-11-23 10:06:28 +08:00
Code

Merge branch 'ext/anand/skip-reg-v5-for-merge' into for-next-current-v6.8-20240318

Browse Source
This commit is contained in:
David Sterba 2024-03-18 19:49:47 +01:00
commit eb63949f4f
2229 changed files with 81393 additions and 55204 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
.mailmap
View File

@ -325,6 +325,7 @@ Kenneth W Chen <kenneth.w.chen@intel.com>
Kenneth Westfield <quic_kwestfie@quicinc.com> <kwestfie@codeaurora.org>
Kiran Gunda <quic_kgunda@quicinc.com> <kgunda@codeaurora.org>
Kirill Tkhai <tkhai@ya.ru> <ktkhai@virtuozzo.com>
Kishon Vijay Abraham I <kishon@kernel.org> <kishon@ti.com>
Konstantin Khlebnikov <koct9i@gmail.com> <khlebnikov@yandex-team.ru>
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
Koushik <raghavendra.koushik@neterion.com>
@ -609,6 +610,11 @@ TripleX Chung <xxx.phy@gmail.com> <triplex@zh-kernel.org>
TripleX Chung <xxx.phy@gmail.com> <zhongyu@18mail.cn>
Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>
Tudor Ambarus <tudor.ambarus@linaro.org> <tudor.ambarus@microchip.com>
Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko.ursulin@intel.com>
Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko.ursulin@linux.intel.com>
Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko.ursulin@sophos.com>
Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko.ursulin@onelan.co.uk>
Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko@ursulin.net>
Tycho Andersen <tycho@tycho.pizza> <tycho@tycho.ws>
Tzung-Bi Shih <tzungbi@kernel.org> <tzungbi@google.com>
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>

5
CREDITS
View File

@ -63,6 +63,11 @@ D: dosfs, LILO, some fd features, ATM, various other hacks here and there
S: Buenos Aires
S: Argentina
NTFS FILESYSTEM
N: Anton Altaparmakov
E: anton@tuxera.com
D: NTFS filesystem
N: Tim Alpaerts
E: tim_alpaerts@toyota-motor-europe.com
D: 802.2 class II logical link control layer,

1
Documentation/ABI/testing/sysfs-devices-system-cpu
View File

@ -516,6 +516,7 @@ What: /sys/devices/system/cpu/vulnerabilities
/sys/devices/system/cpu/vulnerabilities/mds
/sys/devices/system/cpu/vulnerabilities/meltdown
/sys/devices/system/cpu/vulnerabilities/mmio_stale_data
/sys/devices/system/cpu/vulnerabilities/reg_file_data_sampling
/sys/devices/system/cpu/vulnerabilities/retbleed
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
/sys/devices/system/cpu/vulnerabilities/spectre_v1

32
Documentation/RCU/checklist.rst
View File

@ -68,7 +68,8 @@ over a rather long period of time, but improvements are always welcome!
rcu_read_lock_sched(), or by the appropriate update-side lock.
Explicit disabling of preemption (preempt_disable(), for example)
can serve as rcu_read_lock_sched(), but is less readable and
prevents lockdep from detecting locking issues.
prevents lockdep from detecting locking issues. Acquiring a
spinlock also enters an RCU read-side critical section.
Please note that you *cannot* rely on code known to be built
only in non-preemptible kernels. Such code can and will break,
@ -382,16 +383,17 @@ over a rather long period of time, but improvements are always welcome!
must use whatever locking or other synchronization is required
to safely access and/or modify that data structure.
Do not assume that RCU callbacks will be executed on the same
CPU that executed the corresponding call_rcu() or call_srcu().
For example, if a given CPU goes offline while having an RCU
callback pending, then that RCU callback will execute on some
surviving CPU. (If this was not the case, a self-spawning RCU
callback would prevent the victim CPU from ever going offline.)
Furthermore, CPUs designated by rcu_nocbs= might well *always*
have their RCU callbacks executed on some other CPUs, in fact,
for some real-time workloads, this is the whole point of using
the rcu_nocbs= kernel boot parameter.
Do not assume that RCU callbacks will be executed on
the same CPU that executed the corresponding call_rcu(),
call_srcu(), call_rcu_tasks(), call_rcu_tasks_rude(), or
call_rcu_tasks_trace(). For example, if a given CPU goes offline
while having an RCU callback pending, then that RCU callback
will execute on some surviving CPU. (If this was not the case,
a self-spawning RCU callback would prevent the victim CPU from
ever going offline.) Furthermore, CPUs designated by rcu_nocbs=
might well *always* have their RCU callbacks executed on some
other CPUs, in fact, for some real-time workloads, this is the
whole point of using the rcu_nocbs= kernel boot parameter.
In addition, do not assume that callbacks queued in a given order
will be invoked in that order, even if they all are queued on the
@ -444,7 +446,7 @@ over a rather long period of time, but improvements are always welcome!
real-time workloads than is synchronize_rcu_expedited().
It is also permissible to sleep in RCU Tasks Trace read-side
critical, which are delimited by rcu_read_lock_trace() and
critical section, which are delimited by rcu_read_lock_trace() and
rcu_read_unlock_trace(). However, this is a specialized flavor
of RCU, and you should not use it without first checking with
its current users. In most cases, you should instead use SRCU.
@ -490,6 +492,12 @@ over a rather long period of time, but improvements are always welcome!
since the last time that you passed that same object to
call_rcu() (or friends).
CONFIG_RCU_STRICT_GRACE_PERIOD:
combine with KASAN to check for pointers leaked out
of RCU read-side critical sections. This Kconfig
option is tough on both performance and scalability,
and so is limited to four-CPU systems.
__rcu sparse checks:
tag the pointer to the RCU-protected data structure
with __rcu, and sparse will warn you if you access that

5
Documentation/RCU/rcu_dereference.rst
View File

@ -408,7 +408,10 @@ member of the rcu_dereference() to use in various situations:
RCU flavors, an RCU read-side critical section is entered
using rcu_read_lock(), anything that disables bottom halves,
anything that disables interrupts, or anything that disables
preemption.
preemption. Please note that spinlock critical sections
are also implied RCU read-side critical sections, even when
they are preemptible, as they are in kernels built with
CONFIG_PREEMPT_RT=y.
2. If the access might be within an RCU read-side critical section
on the one hand, or protected by (say) my_lock on the other,

19
Documentation/RCU/whatisRCU.rst
View File

@ -172,14 +172,25 @@ rcu_read_lock()
critical section. Reference counts may be used in conjunction
with RCU to maintain longer-term references to data structures.
Note that anything that disables bottom halves, preemption,
or interrupts also enters an RCU read-side critical section.
Acquiring a spinlock also enters an RCU read-side critical
sections, even for spinlocks that do not disable preemption,
as is the case in kernels built with CONFIG_PREEMPT_RT=y.
Sleeplocks do *not* enter RCU read-side critical sections.
rcu_read_unlock()
^^^^^^^^^^^^^^^^^
void rcu_read_unlock(void);
This temporal primitives is used by a reader to inform the
reclaimer that the reader is exiting an RCU read-side critical
section. Note that RCU read-side critical sections may be nested
and/or overlapping.
section. Anything that enables bottom halves, preemption,
or interrupts also exits an RCU read-side critical section.
Releasing a spinlock also exits an RCU read-side critical section.
Note that RCU read-side critical sections may be nested and/or
overlapping.
synchronize_rcu()
^^^^^^^^^^^^^^^^^
@ -952,8 +963,8 @@ unfortunately any spinlock in a ``SLAB_TYPESAFE_BY_RCU`` object must be
initialized after each and every call to kmem_cache_alloc(), which renders
reference-free spinlock acquisition completely unsafe. Therefore, when
using ``SLAB_TYPESAFE_BY_RCU``, make proper use of a reference counter.
(Those willing to use a kmem_cache constructor may also use locking,
including cache-friendly sequence locking.)
(Those willing to initialize their locks in a kmem_cache constructor
may also use locking, including cache-friendly sequence locking.)
With traditional reference counting -- such as that implemented by the
kref library in Linux -- there is typically code that runs when the last

24
Documentation/admin-guide/RAS/address-translation.rst Normal file
View File

@ -0,0 +1,24 @@
.. SPDX-License-Identifier: GPL-2.0
Address translation
===================
x86 AMD
-------
Zen-based AMD systems include a Data Fabric that manages the layout of
physical memory. Devices attached to the Fabric, like memory controllers,
I/O, etc., may not have a complete view of the system physical memory map.
These devices may provide a "normalized", i.e. device physical, address
when reporting memory errors. Normalized addresses must be translated to
a system physical address for the kernel to action on the memory.
AMD Address Translation Library (CONFIG_AMD_ATL) provides translation for
this case.
Glossary of acronyms used in address translation for Zen-based systems
* CCM = Cache Coherent Moderator
* COD = Cluster-on-Die
* COH_ST = Coherent Station
* DF = Data Fabric

11
Documentation/RAS/ras.rst → Documentation/admin-guide/RAS/error-decoding.rst
View File

@ -1,15 +1,10 @@
.. SPDX-License-Identifier: GPL-2.0
Reliability, Availability and Serviceability features
=====================================================
This documents different aspects of the RAS functionality present in the
kernel.
Error decoding
---------------
==============
* x86
x86
---
Error decoding on AMD systems should be done using the rasdaemon tool:
https://github.com/mchehab/rasdaemon/

7
Documentation/admin-guide/RAS/index.rst Normal file
View File

@ -0,0 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
.. toctree::
:maxdepth: 2
main
error-decoding
address-translation

10
Documentation/admin-guide/ras.rst → Documentation/admin-guide/RAS/main.rst
View File

@ -1,8 +1,12 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
============================================
Reliability, Availability and Serviceability
============================================
==================================================
Reliability, Availability and Serviceability (RAS)
==================================================
This documents different aspects of the RAS functionality present in the
kernel.
RAS concepts
************

2
Documentation/admin-guide/cgroup-v1/cpusets.rst
View File

@ -179,7 +179,7 @@ files describing that cpuset:
- cpuset.mem_hardwall flag: is memory allocation hardwalled
- cpuset.memory_pressure: measure of how much paging pressure in cpuset
- cpuset.memory_spread_page flag: if set, spread page cache evenly on allowed nodes
- cpuset.memory_spread_slab flag: if set, spread slab cache evenly on allowed nodes
- cpuset.memory_spread_slab flag: OBSOLETE. Doesn't have any function.
- cpuset.sched_load_balance flag: if set, load balance within CPUs on that cpuset
- cpuset.sched_relax_domain_level: the searching range when migrating tasks

20
Documentation/admin-guide/cgroup-v1/hugetlb.rst
View File

@ -65,10 +65,12 @@ files include::
1. Page fault accounting
hugetlb.<hugepagesize>.limit_in_bytes
hugetlb.<hugepagesize>.max_usage_in_bytes
hugetlb.<hugepagesize>.usage_in_bytes
hugetlb.<hugepagesize>.failcnt
::
hugetlb.<hugepagesize>.limit_in_bytes
hugetlb.<hugepagesize>.max_usage_in_bytes
hugetlb.<hugepagesize>.usage_in_bytes
hugetlb.<hugepagesize>.failcnt
The HugeTLB controller allows users to limit the HugeTLB usage (page fault) per
control group and enforces the limit during page fault. Since HugeTLB
@ -82,10 +84,12 @@ getting SIGBUS.
2. Reservation accounting
hugetlb.<hugepagesize>.rsvd.limit_in_bytes
hugetlb.<hugepagesize>.rsvd.max_usage_in_bytes
hugetlb.<hugepagesize>.rsvd.usage_in_bytes
hugetlb.<hugepagesize>.rsvd.failcnt
::
hugetlb.<hugepagesize>.rsvd.limit_in_bytes
hugetlb.<hugepagesize>.rsvd.max_usage_in_bytes
hugetlb.<hugepagesize>.rsvd.usage_in_bytes
hugetlb.<hugepagesize>.rsvd.failcnt
The HugeTLB controller allows to limit the HugeTLB reservations per control
group and enforces the controller limit at reservation time and at the fault of

1
Documentation/admin-guide/hw-vuln/index.rst
View File

@ -21,3 +21,4 @@ are configurable at compile, boot or run time.
cross-thread-rsb
srso
gather_data_sampling
reg-file-data-sampling

104
Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst Normal file
View File

@ -0,0 +1,104 @@
==================================
Register File Data Sampling (RFDS)
==================================
Register File Data Sampling (RFDS) is a microarchitectural vulnerability that
only affects Intel Atom parts(also branded as E-cores). RFDS may allow
a malicious actor to infer data values previously used in floating point
registers, vector registers, or integer registers. RFDS does not provide the
ability to choose which data is inferred. CVE-2023-28746 is assigned to RFDS.
Affected Processors
===================
Below is the list of affected Intel processors [#f1]_:
=================== ============
Common name Family_Model
=================== ============
ATOM_GOLDMONT 06_5CH
ATOM_GOLDMONT_D 06_5FH
ATOM_GOLDMONT_PLUS 06_7AH
ATOM_TREMONT_D 06_86H
ATOM_TREMONT 06_96H
ALDERLAKE 06_97H
ALDERLAKE_L 06_9AH
ATOM_TREMONT_L 06_9CH
RAPTORLAKE 06_B7H
RAPTORLAKE_P 06_BAH
ATOM_GRACEMONT 06_BEH
RAPTORLAKE_S 06_BFH
=================== ============
As an exception to this table, Intel Xeon E family parts ALDERLAKE(06_97H) and
RAPTORLAKE(06_B7H) codenamed Catlow are not affected. They are reported as
vulnerable in Linux because they share the same family/model with an affected
part. Unlike their affected counterparts, they do not enumerate RFDS_CLEAR or
CPUID.HYBRID. This information could be used to distinguish between the
affected and unaffected parts, but it is deemed not worth adding complexity as
the reporting is fixed automatically when these parts enumerate RFDS_NO.
Mitigation
==========
Intel released a microcode update that enables software to clear sensitive
information using the VERW instruction. Like MDS, RFDS deploys the same
mitigation strategy to force the CPU to clear the affected buffers before an
attacker can extract the secrets. This is achieved by using the otherwise
unused and obsolete VERW instruction in combination with a microcode update.
The microcode clears the affected CPU buffers when the VERW instruction is
executed.
Mitigation points
-----------------
VERW is executed by the kernel before returning to user space, and by KVM
before VMentry. None of the affected cores support SMT, so VERW is not required
at C-state transitions.
New bits in IA32_ARCH_CAPABILITIES
----------------------------------
Newer processors and microcode update on existing affected processors added new
bits to IA32_ARCH_CAPABILITIES MSR. These bits can be used to enumerate
vulnerability and mitigation capability:
- Bit 27 - RFDS_NO - When set, processor is not affected by RFDS.
- Bit 28 - RFDS_CLEAR - When set, processor is affected by RFDS, and has the
microcode that clears the affected buffers on VERW execution.
Mitigation control on the kernel command line
---------------------------------------------
The kernel command line allows to control RFDS mitigation at boot time with the
parameter "reg_file_data_sampling=". The valid arguments are:
========== =================================================================
on If the CPU is vulnerable, enable mitigation; CPU buffer clearing
on exit to userspace and before entering a VM.
off Disables mitigation.
========== =================================================================
Mitigation default is selected by CONFIG_MITIGATION_RFDS.
Mitigation status information
-----------------------------
The Linux kernel provides a sysfs interface to enumerate the current
vulnerability status of the system: whether the system is vulnerable, and
which mitigations are active. The relevant sysfs file is:
/sys/devices/system/cpu/vulnerabilities/reg_file_data_sampling
The possible values in this file are:
.. list-table::
* - 'Not affected'
- The processor is not vulnerable
* - 'Vulnerable'
- The processor is vulnerable, but no mitigation enabled
* - 'Vulnerable: No microcode'
- The processor is vulnerable but microcode is not updated.
* - 'Mitigation: Clear Register File'
- The processor is vulnerable and the CPU buffer clearing mitigation is
enabled.
References
----------
.. [#f1] Affected Processors
https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html

8
Documentation/admin-guide/hw-vuln/spectre.rst
View File

@ -473,8 +473,8 @@ Spectre variant 2
-mindirect-branch=thunk-extern -mindirect-branch-register options.
If the kernel is compiled with a Clang compiler, the compiler needs
to support -mretpoline-external-thunk option. The kernel config
CONFIG_RETPOLINE needs to be turned on, and the CPU needs to run with
the latest updated microcode.
CONFIG_MITIGATION_RETPOLINE needs to be turned on, and the CPU needs
to run with the latest updated microcode.
On Intel Skylake-era systems the mitigation covers most, but not all,
cases. See :ref:`[3] <spec_ref3>` for more details.
@ -609,8 +609,8 @@ kernel command line.
Selecting 'on' will, and 'auto' may, choose a
mitigation method at run time according to the
CPU, the available microcode, the setting of the
CONFIG_RETPOLINE configuration option, and the
compiler with which the kernel was built.
CONFIG_MITIGATION_RETPOLINE configuration option,
and the compiler with which the kernel was built.
Selecting 'on' will also enable the mitigation
against user space to user space task attacks.

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

@ -122,7 +122,7 @@ configure specific aspects of kernel behavior to your liking.
pmf
pnp
rapidio
ras
RAS/index
rtc
serial-console
svga

7
Documentation/admin-guide/kdump/kdump.rst
View File

@ -191,9 +191,7 @@ Dump-capture kernel config options (Arch Dependent, i386 and x86_64)
CPU is enough for kdump kernel to dump vmcore on most of systems.
However, you can also specify nr_cpus=X to enable multiple processors
in kdump kernel. In this case, "disable_cpu_apicid=" is needed to
tell kdump kernel which cpu is 1st kernel's BSP. Please refer to
admin-guide/kernel-parameters.txt for more details.
in kdump kernel.
With CONFIG_SMP=n, the above things are not related.
@ -454,8 +452,7 @@ Notes on loading the dump-capture kernel:
to use multi-thread programs with it, such as parallel dump feature of
makedumpfile. Otherwise, the multi-thread program may have a great
performance degradation. To enable multi-cpu support, you should bring up an
SMP dump-capture kernel and specify maxcpus/nr_cpus, disable_cpu_apicid=[X]
options while loading it.
SMP dump-capture kernel and specify maxcpus/nr_cpus options while loading it.
* For s390x there are two kdump modes: If a ELF header is specified with
the elfcorehdr= kernel parameter, it is used by the kdump kernel as it

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

@ -108,6 +108,7 @@ is applicable::
CMA Contiguous Memory Area support is enabled.
DRM Direct Rendering Management support is enabled.
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
EARLY Parameter processed too early to be embedded in initrd.
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
EFI EFI Partitioning (GPT) is enabled
EVM Extended Verification Module

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

File diff suppressed because it is too large Load Diff

16
Documentation/arch/x86/amd-memory-encryption.rst
View File

@ -87,14 +87,14 @@ The state of SME in the Linux kernel can be documented as follows:
kernel is non-zero).
SME can also be enabled and activated in the BIOS. If SME is enabled and
activated in the BIOS, then all memory accesses will be encrypted and it will
not be necessary to activate the Linux memory encryption support. If the BIOS
merely enables SME (sets bit 23 of the MSR_AMD64_SYSCFG), then Linux can activate
memory encryption by default (CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y) or
by supplying mem_encrypt=on on the kernel command line. However, if BIOS does
not enable SME, then Linux will not be able to activate memory encryption, even
if configured to do so by default or the mem_encrypt=on command line parameter
is specified.
activated in the BIOS, then all memory accesses will be encrypted and it
will not be necessary to activate the Linux memory encryption support.
If the BIOS merely enables SME (sets bit 23 of the MSR_AMD64_SYSCFG),
then memory encryption can be enabled by supplying mem_encrypt=on on the
kernel command line. However, if BIOS does not enable SME, then Linux
will not be able to activate memory encryption, even if configured to do
so by default or the mem_encrypt=on command line parameter is specified.
Secure Nested Paging (SNP)
==========================

3
Documentation/arch/x86/boot.rst
View File

@ -878,7 +878,8 @@ Protocol: 2.10+
address if possible.
A non-relocatable kernel will unconditionally move itself and to run
at this address.
at this address. A relocatable kernel will move itself to this address if it
loaded below this address.
============ =======
Field name: init_size

6
Documentation/arch/x86/pti.rst
View File

@ -26,9 +26,9 @@ comments in pti.c).
This approach helps to ensure that side-channel attacks leveraging
the paging structures do not function when PTI is enabled. It can be
enabled by setting CONFIG_PAGE_TABLE_ISOLATION=y at compile time.
Once enabled at compile-time, it can be disabled at boot with the
'nopti' or 'pti=' kernel parameters (see kernel-parameters.txt).
enabled by setting CONFIG_MITIGATION_PAGE_TABLE_ISOLATION=y at compile
time. Once enabled at compile-time, it can be disabled at boot with
the 'nopti' or 'pti=' kernel parameters (see kernel-parameters.txt).
Page Table Management
=====================

24
Documentation/arch/x86/topology.rst
View File

@ -47,17 +47,21 @@ AMD nomenclature for package is 'Node'.
Package-related topology information in the kernel:
- cpuinfo_x86.x86_max_cores:
- topology_num_threads_per_package()
The number of cores in a package. This information is retrieved via CPUID.
The number of threads in a package.
- cpuinfo_x86.x86_max_dies:
- topology_num_cores_per_package()
The number of dies in a package. This information is retrieved via CPUID.
The number of cores in a package.
- topology_max_dies_per_package()
The maximum number of dies in a package.
- cpuinfo_x86.topo.die_id:
The physical ID of the die. This information is retrieved via CPUID.
The physical ID of the die.
- cpuinfo_x86.topo.pkg_id:
@ -96,16 +100,6 @@ are SMT- or CMT-type threads.
AMDs nomenclature for a CMT core is "Compute Unit". The kernel always uses
"core".
Core-related topology information in the kernel:
- smp_num_siblings:
The number of threads in a core. The number of threads in a package can be
calculated by::
threads_per_package = cpuinfo_x86.x86_max_cores * smp_num_siblings
Threads
=======
A thread is a single scheduling unit. It's the equivalent to a logical Linux

96
Documentation/arch/x86/x86_64/fred.rst Normal file
View File

@ -0,0 +1,96 @@
.. SPDX-License-Identifier: GPL-2.0
=========================================
Flexible Return and Event Delivery (FRED)
=========================================
Overview
========
The FRED architecture defines simple new transitions that change
privilege level (ring transitions). The FRED architecture was
designed with the following goals:
1) Improve overall performance and response time by replacing event
delivery through the interrupt descriptor table (IDT event
delivery) and event return by the IRET instruction with lower
latency transitions.
2) Improve software robustness by ensuring that event delivery
establishes the full supervisor context and that event return
establishes the full user context.
The new transitions defined by the FRED architecture are FRED event
delivery and, for returning from events, two FRED return instructions.
FRED event delivery can effect a transition from ring 3 to ring 0, but
it is used also to deliver events incident to ring 0. One FRED
instruction (ERETU) effects a return from ring 0 to ring 3, while the
other (ERETS) returns while remaining in ring 0. Collectively, FRED
event delivery and the FRED return instructions are FRED transitions.
In addition to these transitions, the FRED architecture defines a new
instruction (LKGS) for managing the state of the GS segment register.
The LKGS instruction can be used by 64-bit operating systems that do
not use the new FRED transitions.
Furthermore, the FRED architecture is easy to extend for future CPU
architectures.
Software based event dispatching
================================
FRED operates differently from IDT in terms of event handling. Instead
of directly dispatching an event to its handler based on the event
vector, FRED requires the software to dispatch an event to its handler
based on both the event's type and vector. Therefore, an event dispatch
framework must be implemented to facilitate the event-to-handler
dispatch process. The FRED event dispatch framework takes control
once an event is delivered, and employs a two-level dispatch.
The first level dispatching is event type based, and the second level
dispatching is event vector based.
Full supervisor/user context
============================
FRED event delivery atomically save and restore full supervisor/user
context upon event delivery and return. Thus it avoids the problem of
transient states due to %cr2 and/or %dr6, and it is no longer needed
to handle all the ugly corner cases caused by half baked entry states.
FRED allows explicit unblock of NMI with new event return instructions
ERETS/ERETU, avoiding the mess caused by IRET which unconditionally
unblocks NMI, e.g., when an exception happens during NMI handling.
FRED always restores the full value of %rsp, thus ESPFIX is no longer
needed when FRED is enabled.
LKGS
====
LKGS behaves like the MOV to GS instruction except that it loads the
base address into the IA32_KERNEL_GS_BASE MSR instead of the GS
segment’s descriptor cache. With LKGS, it ends up with avoiding
mucking with kernel GS, i.e., an operating system can always operate
with its own GS base address.
Because FRED event delivery from ring 3 and ERETU both swap the value
of the GS base address and that of the IA32_KERNEL_GS_BASE MSR, plus
the introduction of LKGS instruction, the SWAPGS instruction is no
longer needed when FRED is enabled, thus is disallowed (#UD).
Stack levels
============
4 stack levels 0~3 are introduced to replace the nonreentrant IST for
event handling, and each stack level should be configured to use a
dedicated stack.
The current stack level could be unchanged or go higher upon FRED
event delivery. If unchanged, the CPU keeps using the current event
stack. If higher, the CPU switches to a new event stack specified by
the MSR of the new stack level, i.e., MSR_IA32_FRED_RSP[123].
Only execution of a FRED return instruction ERET[US], could lower the
current stack level, causing the CPU to switch back to the stack it was
on before a previous event delivery that promoted the stack level.

1
Documentation/arch/x86/x86_64/index.rst
View File

@ -15,3 +15,4 @@ x86_64 Support
cpu-hotplug-spec
machinecheck
fsgs
fred

43
Documentation/core-api/workqueue.rst
View File

@ -77,10 +77,12 @@ wants a function to be executed asynchronously it has to set up a work
item pointing to that function and queue that work item on a
workqueue.
Special purpose threads, called worker threads, execute the functions
off of the queue, one after the other. If no work is queued, the
worker threads become idle. These worker threads are managed in so
called worker-pools.
A work item can be executed in either a thread or the BH (softirq) context.
For threaded workqueues, special purpose threads, called [k]workers, execute
the functions off of the queue, one after the other. If no work is queued,
the worker threads become idle. These worker threads are managed in
worker-pools.
The cmwq design differentiates between the user-facing workqueues that
subsystems and drivers queue work items on and the backend mechanism
@ -91,6 +93,12 @@ for high priority ones, for each possible CPU and some extra
worker-pools to serve work items queued on unbound workqueues - the
number of these backing pools is dynamic.
BH workqueues use the same framework. However, as there can only be one
concurrent execution context, there's no need to worry about concurrency.
Each per-CPU BH worker pool contains only one pseudo worker which represents
the BH execution context. A BH workqueue can be considered a convenience
interface to softirq.
Subsystems and drivers can create and queue work items through special
workqueue API functions as they see fit. They can influence some
aspects of the way the work items are executed by setting flags on the
@ -106,7 +114,7 @@ unless specifically overridden, a work item of a bound workqueue will
be queued on the worklist of either normal or highpri worker-pool that
is associated to the CPU the issuer is running on.
For any worker pool implementation, managing the concurrency level
For any thread pool implementation, managing the concurrency level
(how many execution contexts are active) is an important issue. cmwq
tries to keep the concurrency at a minimal but sufficient level.
Minimal to save resources and sufficient in that the system is used at
@ -164,6 +172,17 @@ resources, scheduled and executed.
``flags``
---------
``WQ_BH``
BH workqueues can be considered a convenience interface to softirq. BH
workqueues are always per-CPU and all BH work items are executed in the
queueing CPU's softirq context in the queueing order.
All BH workqueues must have 0 ``max_active`` and ``WQ_HIGHPRI`` is the
only allowed additional flag.
BH work items cannot sleep. All other features such as delayed queueing,
flushing and canceling are supported.
``WQ_UNBOUND``
Work items queued to an unbound wq are served by the special
worker-pools which host workers which are not bound to any
@ -237,15 +256,11 @@ may queue at the same time. Unless there is a specific need for
throttling the number of active work items, specifying '0' is
recommended.
Some users depend on the strict execution ordering of ST wq. The
combination of ``@max_active`` of 1 and ``WQ_UNBOUND`` used to
achieve this behavior. Work items on such wq were always queued to the
unbound worker-pools and only one work item could be active at any given
time thus achieving the same ordering property as ST wq.
In the current implementation the above configuration only guarantees
ST behavior within a given NUMA node. Instead ``alloc_ordered_workqueue()`` should
be used to achieve system-wide ST behavior.
Some users depend on strict execution ordering where only one work item
is in flight at any given time and the work items are processed in
queueing order. While the combination of ``@max_active`` of 1 and
``WQ_UNBOUND`` used to achieve this behavior, this is no longer the
case. Use ``alloc_ordered_queue()`` instead.
Example Execution Scenarios

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

@ -245,6 +245,10 @@ Contributing new tests (details)
TEST_PROGS, TEST_GEN_PROGS mean it is the executable tested by
default.
TEST_GEN_MODS_DIR should be used by tests that require modules to be built
before the test starts. The variable will contain the name of the directory
containing the modules.
TEST_CUSTOM_PROGS should be used by tests that require custom build
rules and prevent common build rule use.

15
Documentation/devicetree/bindings/arm/amlogic.yaml
View File

@ -7,19 +7,11 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Amlogic SoC based Platforms
maintainers:
- Neil Armstrong <neil.armstrong@linaro.org>
- Martin Blumenstingl <martin.blumenstingl@googlemail.com>
- Jerome Brunet <jbrunet@baylibre.com>
- Kevin Hilman <khilman@baylibre.com>
description: |+
Work in progress statement:
Device tree files and bindings applying to Amlogic SoCs and boards are
considered "unstable". Any Amlogic device tree binding may change at
any time. Be sure to use a device tree binary and a kernel image
generated from the same source tree.
Please refer to Documentation/devicetree/bindings/ABI.rst for a definition of a
stable binding/ABI.
properties:
$nodename:
const: '/'
@ -146,6 +138,7 @@ properties:
- enum:
- amediatech,x96-max
- amlogic,u200
- freebox,fbx8am
- radxa,zero
- seirobotics,sei510
- const: amlogic,g12a

6
Documentation/devicetree/bindings/arm/arm,realview.yaml
View File

@ -10,9 +10,9 @@ maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |+
The ARM RealView series of reference designs were built to explore the ARM
11, Cortex A-8 and Cortex A-9 CPUs. This included new features compared to
the earlier CPUs such as TrustZone and multicore (MPCore).
The ARM RealView series of reference designs were built to explore the Arm11,
Cortex-A8, and Cortex-A9 CPUs. This included new features compared to the
earlier CPUs such as TrustZone and multicore (MPCore).
properties:
$nodename:

6
Documentation/devicetree/bindings/arm/atmel-at91.yaml
View File

@ -179,6 +179,12 @@ properties:
- const: microchip,sama7g5
- const: microchip,sama7
- description: Microchip SAMA7G54 Curiosity Board
items:
- const: microchip,sama7g54-curiosity
- const: microchip,sama7g5
- const: microchip,sama7
- description: Microchip LAN9662 Evaluation Boards.
items:
- enum:

41
Documentation/devicetree/bindings/arm/fsl.yaml
View File

@ -384,7 +384,8 @@ properties:
- toradex,apalis_imx6q-ixora # Apalis iMX6Q/D Module on Ixora Carrier Board
- toradex,apalis_imx6q-ixora-v1.1 # Apalis iMX6Q/D Module on Ixora V1.1 Carrier Board
- toradex,apalis_imx6q-ixora-v1.2 # Apalis iMX6Q/D Module on Ixora V1.2 Carrier Board
- toradex,apalis_imx6q-eval # Apalis iMX6Q/D Module on Apalis Evaluation Board
- toradex,apalis_imx6q-eval # Apalis iMX6Q/D Module on Apalis Evaluation Board v1.0/v1.1
- toradex,apalis_imx6q-eval-v1.2 # Apalis iMX6Q/D Module on Apalis Evaluation Board v1.2
- const: toradex,apalis_imx6q
- const: fsl,imx6q
@ -469,6 +470,7 @@ properties:
- prt,prtvt7 # Protonic VT7 board
- rex,imx6dl-rex-basic # Rex Basic i.MX6 Dual Lite Board
- riot,imx6s-riotboard # RIoTboard i.MX6S
- sielaff,imx6dl-board # Sielaff i.MX6 Solo Board
- skov,imx6dl-skov-revc-lt2 # SKOV IMX6 CPU SoloCore lt2
- skov,imx6dl-skov-revc-lt6 # SKOV IMX6 CPU SoloCore lt6
- solidrun,cubox-i/dl # SolidRun Cubox-i Solo/DualLite
@ -708,6 +710,7 @@ properties:
- toradex,colibri-imx6ull # Colibri iMX6ULL Modules
- toradex,colibri-imx6ull-emmc # Colibri iMX6ULL 1GB (eMMC) Module
- toradex,colibri-imx6ull-wifi # Colibri iMX6ULL Wi-Fi / BT Modules
- uni-t,uti260b # UNI-T UTi260B Thermal Camera
- const: fsl,imx6ull
- description: i.MX6ULL Armadeus Systems OPOS6ULDev Board
@ -1026,7 +1029,7 @@ properties:
items:
- enum:
- dimonoff,gateway-evk # i.MX8MN Dimonoff Gateway EVK Board
- rve,rve-gateway # i.MX8MN RVE Gateway Board
- rve,gateway # i.MX8MN RVE Gateway Board
- variscite,var-som-mx8mn-symphony
- const: variscite,var-som-mx8mn
- const: fsl,imx8mn
@ -1194,7 +1197,8 @@ properties:
- description: i.MX8QM Boards with Toradex Apalis iMX8 Modules
items:
- enum:
- toradex,apalis-imx8-eval # Apalis iMX8 Module on Apalis Evaluation Board
- toradex,apalis-imx8-eval # Apalis iMX8 Module on Apalis Evaluation V1.0/V1.1 Board
- toradex,apalis-imx8-eval-v1.2 # Apalis iMX8 Module on Apalis Evaluation V1.2 Board
- toradex,apalis-imx8-ixora-v1.1 # Apalis iMX8 Module on Ixora V1.1 Carrier Board
- const: toradex,apalis-imx8
- const: fsl,imx8qm
@ -1202,7 +1206,8 @@ properties:
- description: i.MX8QM Boards with Toradex Apalis iMX8 V1.1 Modules
items:
- enum:
- toradex,apalis-imx8-v1.1-eval # Apalis iMX8 V1.1 Module on Apalis Eval. Board
- toradex,apalis-imx8-v1.1-eval # Apalis iMX8 V1.1 Module on Apalis Eval. V1.0/V1.1 Board
- toradex,apalis-imx8-v1.1-eval-v1.2 # Apalis iMX8 V1.1 Module on Apalis Eval. V1.2 Board
- toradex,apalis-imx8-v1.1-ixora-v1.1 # Apalis iMX8 V1.1 Module on Ixora V1.1 C. Board
- toradex,apalis-imx8-v1.1-ixora-v1.2 # Apalis iMX8 V1.1 Module on Ixora V1.2 C. Board
- const: toradex,apalis-imx8-v1.1
@ -1232,6 +1237,22 @@ properties:
- const: toradex,colibri-imx8x
- const: fsl,imx8qxp
- description:
TQMa8Xx is a series of SOM featuring NXP i.MX8X system-on-chip
variants. It is designed to be clicked on different carrier boards
MBa8Xx is the starterkit
oneOf:
- items:
- enum:
- tq,imx8dxp-tqma8xdp-mba8xx # TQ-Systems GmbH TQMa8XDP SOM on MBa8Xx
- const: tq,imx8dxp-tqma8xdp # TQ-Systems GmbH TQMa8XDP SOM (with i.MX8DXP)
- const: fsl,imx8dxp
- items:
- enum:
- tq,imx8qxp-tqma8xqp-mba8xx # TQ-Systems GmbH TQMa8XQP SOM on MBa8Xx
- const: tq,imx8qxp-tqma8xqp # TQ-Systems GmbH TQMa8XQP SOM (with i.MX8QXP)
- const: fsl,imx8qxp
- description: i.MX8ULP based Boards
items:
- enum:
@ -1275,6 +1296,18 @@ properties:
- const: tq,imx93-tqma9352 # TQ-Systems GmbH i.MX93 TQMa93xxCA/LA SOM
- const: fsl,imx93
- description: PHYTEC phyCORE-i.MX93 SoM based boards
items:
- const: phytec,imx93-phyboard-segin # phyBOARD-Segin with i.MX93
- const: phytec,imx93-phycore-som # phyCORE-i.MX93 SoM
- const: fsl,imx93
- description: Variscite VAR-SOM-MX93 based boards
items:
- const: variscite,var-som-mx93-symphony
- const: variscite,var-som-mx93
- const: fsl,imx93
- description:
Freescale Vybrid Platform Device Tree Bindings

27
Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
View File

@ -1,27 +0,0 @@
Marvell Armada 38x Platforms Device Tree Bindings
-------------------------------------------------
Boards with a SoC of the Marvell Armada 38x family shall have the
following property:
Required root node property:
- compatible: must contain "marvell,armada380"
In addition, boards using the Marvell Armada 385 SoC shall have the
following property before the previous one:
Required root node property:
compatible: must contain "marvell,armada385"
In addition, boards using the Marvell Armada 388 SoC shall have the
following property before the previous one:
Required root node property:
compatible: must contain "marvell,armada388"
Example:
compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada380";

70
Documentation/devicetree/bindings/arm/marvell/armada-38x.yaml Normal file
View File

@ -0,0 +1,70 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/marvell/armada-38x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Marvell Armada 38x Platforms
maintainers:
- Gregory CLEMENT <gregory.clement@bootlin.com>
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description:
Netgear Armada 380 GS110EM Managed Switch.
items:
- const: netgear,gs110emx
- const: marvell,armada380
- description:
Marvell Armada 385 Development Boards.
items:
- enum:
- marvell,a385-db-amc
- marvell,a385-db-ap
- const: marvell,armada385
- const: marvell,armada380
- description:
SolidRun Armada 385 based single-board computers.
items:
- enum:
- solidrun,clearfog-gtr-l8
- solidrun,clearfog-gtr-s4
- const: marvell,armada385
- const: marvell,armada380
- description:
Kobol Armada 388 based Helios-4 NAS.
items:
- const: kobol,helios4
- const: marvell,armada388
- const: marvell,armada385
- const: marvell,armada380
- description:
Marvell Armada 388 Development Boards.
items:
- enum:
- marvell,a388-gp
- const: marvell,armada388
- const: marvell,armada385
- const: marvell,armada380
- description:
SolidRun Armada 388 clearfog family single-board computers.
items:
- enum:
- solidrun,clearfog-base-a1
- solidrun,clearfog-pro-a1
- const: solidrun,clearfog-a1
- const: marvell,armada388
- const: marvell,armada385
- const: marvell,armada380
additionalProperties: true

198
Documentation/devicetree/bindings/arm/mediatek.yaml
View File

@ -17,6 +17,7 @@ properties:
const: '/'
compatible:
oneOf:
# Sort by SoC (last) compatible, then board compatible
- items:
- enum:
- mediatek,mt2701-evb
@ -84,6 +85,11 @@ properties:
- const: mediatek,mt7629
- items:
- enum:
- xiaomi,ax3000t
- const: mediatek,mt7981b
- items:
- enum:
- acelink,ew-7886cax
- bananapi,bpi-r3
- mediatek,mt7986a-rfb
- const: mediatek,mt7986a
@ -91,6 +97,10 @@ properties:
- enum:
- mediatek,mt7986b-rfb
- const: mediatek,mt7986b
- items:
- enum:
- bananapi,bpi-r4
- const: mediatek,mt7988a
- items:
- enum:
- mediatek,mt8127-moose
@ -129,75 +139,10 @@ properties:
- enum:
- mediatek,mt8173-evb
- const: mediatek,mt8173
- items:
- enum:
- mediatek,mt8183-evb
- const: mediatek,mt8183
- description: Google Hayato rev5
items:
- const: google,hayato-rev5-sku2
- const: google,hayato-sku2
- const: google,hayato
- const: mediatek,mt8192
- description: Google Hayato
items:
- const: google,hayato-rev1
- const: google,hayato
- const: mediatek,mt8192
- description: Google Spherion rev4 (Acer Chromebook 514)
items:
- const: google,spherion-rev4
- const: google,spherion
- const: mediatek,mt8192
- description: Google Spherion (Acer Chromebook 514)
items:
- const: google,spherion-rev3
- const: google,spherion-rev2
- const: google,spherion-rev1
- const: google,spherion-rev0
- const: google,spherion
- const: mediatek,mt8192
- description: Acer Tomato (Acer Chromebook Spin 513 CP513-2H)
items:
- enum:
- google,tomato-rev2
- google,tomato-rev1
- const: google,tomato
- const: mediatek,mt8195
- description: Acer Tomato rev3 - 4 (Acer Chromebook Spin 513 CP513-2H)
items:
- const: google,tomato-rev4
- const: google,tomato-rev3
- const: google,tomato
- const: mediatek,mt8195
- items:
- enum:
- mediatek,mt8186-evb
- const: mediatek,mt8186
- items:
- enum:
- mediatek,mt8188-evb
- const: mediatek,mt8188
- items:
- enum:
- mediatek,mt8192-evb
- const: mediatek,mt8192
- items:
- enum:
- mediatek,mt8195-demo
- mediatek,mt8195-evb
- const: mediatek,mt8195
- description: Google Burnet (HP Chromebook x360 11MK G3 EE)
items:
- const: google,burnet
- const: mediatek,mt8183
- description: Google Krane (Lenovo IdeaPad Duet, 10e,...)
items:
- enum:
- google,krane-sku0
- google,krane-sku176
- const: google,krane
- const: mediatek,mt8183
- description: Google Cozmo (Acer Chromebook 314)
items:
- const: google,cozmo
@ -255,6 +200,13 @@ properties:
- google,kodama-sku32
- const: google,kodama
- const: mediatek,mt8183
- description: Google Krane (Lenovo IdeaPad Duet, 10e,...)
items:
- enum:
- google,krane-sku0
- google,krane-sku176
- const: google,krane
- const: mediatek,mt8183
- description: Google Makomo (Lenovo 100e Chromebook 2nd Gen MTK 2)
items:
- enum:
@ -276,10 +228,125 @@ properties:
- google,willow-sku1
- const: google,willow
- const: mediatek,mt8183
- items:
- enum:
- mediatek,mt8183-evb
- const: mediatek,mt8183
- items:
- enum:
- mediatek,mt8183-pumpkin
- const: mediatek,mt8183
- description: Google Magneton (Lenovo IdeaPad Slim 3 Chromebook (14M868))
items:
- const: google,steelix-sku393219
- const: google,steelix-sku393216
- const: google,steelix
- const: mediatek,mt8186
- description: Google Magneton (Lenovo IdeaPad Slim 3 Chromebook (14M868))
items:
- const: google,steelix-sku393220
- const: google,steelix-sku393217
- const: google,steelix
- const: mediatek,mt8186
- description: Google Magneton (Lenovo IdeaPad Slim 3 Chromebook (14M868))
items:
- const: google,steelix-sku393221
- const: google,steelix-sku393218
- const: google,steelix
- const: mediatek,mt8186
- description: Google Rusty (Lenovo 100e Chromebook Gen 4)
items:
- const: google,steelix-sku196609
- const: google,steelix-sku196608
- const: google,steelix
- const: mediatek,mt8186
- description: Google Steelix (Lenovo 300e Yoga Chromebook Gen 4)
items:
- enum:
- google,steelix-sku131072
- google,steelix-sku131073
- const: google,steelix
- const: mediatek,mt8186
- description: Google Tentacruel (ASUS Chromebook CM14 Flip CM1402F)
items:
- const: google,tentacruel-sku262147
- const: google,tentacruel-sku262146
- const: google,tentacruel-sku262145
- const: google,tentacruel-sku262144
- const: google,tentacruel
- const: mediatek,mt8186
- description: Google Tentacruel (ASUS Chromebook CM14 Flip CM1402F)
items:
- const: google,tentacruel-sku262151
- const: google,tentacruel-sku262150
- const: google,tentacruel-sku262149
- const: google,tentacruel-sku262148
- const: google,tentacruel
- const: mediatek,mt8186
- description: Google Tentacool (ASUS Chromebook CM14 CM1402C)
items:
- const: google,tentacruel-sku327681
- const: google,tentacruel
- const: mediatek,mt8186
- description: Google Tentacool (ASUS Chromebook CM14 CM1402C)
items:
- const: google,tentacruel-sku327683
- const: google,tentacruel
- const: mediatek,mt8186
- items:
- enum:
- mediatek,mt8186-evb
- const: mediatek,mt8186
- items:
- enum:
- mediatek,mt8188-evb
- const: mediatek,mt8188
- description: Google Hayato
items:
- const: google,hayato-rev1
- const: google,hayato
- const: mediatek,mt8192
- description: Google Hayato rev5
items:
- const: google,hayato-rev5-sku2
- const: google,hayato-sku2
- const: google,hayato
- const: mediatek,mt8192
- description: Google Spherion (Acer Chromebook 514)
items:
- const: google,spherion-rev3
- const: google,spherion-rev2
- const: google,spherion-rev1
- const: google,spherion-rev0
- const: google,spherion
- const: mediatek,mt8192
- description: Google Spherion rev4 (Acer Chromebook 514)
items:
- const: google,spherion-rev4
- const: google,spherion
- const: mediatek,mt8192
- items:
- enum:
- mediatek,mt8192-evb
- const: mediatek,mt8192
- description: Acer Tomato (Acer Chromebook Spin 513 CP513-2H)
items:
- enum:
- google,tomato-rev2
- google,tomato-rev1
- const: google,tomato
- const: mediatek,mt8195
- description: Acer Tomato rev3 - 4 (Acer Chromebook Spin 513 CP513-2H)
items:
- const: google,tomato-rev4
- const: google,tomato-rev3
- const: google,tomato
- const: mediatek,mt8195
- items:
- enum:
- mediatek,mt8195-demo
- mediatek,mt8195-evb
- const: mediatek,mt8195
- items:
- enum:
- mediatek,mt8365-evk
@ -287,6 +354,7 @@ properties:
- items:
- enum:
- mediatek,mt8395-evk
- radxa,nio-12l
- const: mediatek,mt8395
- const: mediatek,mt8195
- items:

58
Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
View File

@ -1,58 +0,0 @@
SPM AVS Wrapper 2 (SAW2)
The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable
power-controller that transitions a piece of hardware (like a processor or
subsystem) into and out of low power modes via a direct connection to
the PMIC. It can also be wired up to interact with other processors in the
system, notifying them when a low power state is entered or exited.
Multiple revisions of the SAW hardware are supported using these Device Nodes.
SAW2 revisions differ in the register offset and configuration data. Also, the
same revision of the SAW in different SoCs may have different configuration
data due the differences in hardware capabilities. Hence the SoC name, the
version of the SAW hardware in that SoC and the distinction between cpu (big
or Little) or cache, may be needed to uniquely identify the SAW register
configuration and initialization data. The compatible string is used to
indicate this parameter.
PROPERTIES
- compatible:
Usage: required
Value type: <string>
Definition: Must have
"qcom,saw2"
A more specific value could be one of:
"qcom,apq8064-saw2-v1.1-cpu"
"qcom,msm8226-saw2-v2.1-cpu"
"qcom,msm8974-saw2-v2.1-cpu"
"qcom,apq8084-saw2-v2.1-cpu"
- reg:
Usage: required
Value type: <prop-encoded-array>
Definition: the first element specifies the base address and size of
the register region. An optional second element specifies
the base address and size of the alias register region.
- regulator:
Usage: optional
Value type: boolean
Definition: Indicates that this SPM device acts as a regulator device
device for the core (CPU or Cache) the SPM is attached
to.
Example 1:
power-controller@2099000 {
compatible = "qcom,saw2";
reg = <0x02099000 0x1000>, <0x02009000 0x1000>;
regulator;
};
Example 2:
saw0: power-controller@f9089000 {
compatible = "qcom,apq8084-saw2-v2.1-cpu", "qcom,saw2";
reg = <0xf9089000 0x1000>, <0xf9009000 0x1000>;
};

58
Documentation/devicetree/bindings/arm/qcom.yaml
View File

@ -10,17 +10,10 @@ maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
description: |
Some qcom based bootloaders identify the dtb blob based on a set of
device properties like SoC and platform and revisions of those components.
To support this scheme, we encode this information into the board compatible
string.
Each board must specify a top-level board compatible string with the following
format:
compatible = "qcom,<SoC>[-<soc_version>][-<foundry_id>]-<board>[/<subtype>][-<board_version>]"
The 'SoC' and 'board' elements are required. All other elements are optional.
For devices using the Qualcomm SoC the "compatible" properties consists of
one or several "manufacturer,model" strings, describing the device itself,
followed by one or several "qcom,<SoC>" strings, describing the SoC used in
the device.
The 'SoC' element must be one of the following strings:
@ -90,43 +83,9 @@ description: |
sm8650
x1e80100
The 'board' element must be one of the following strings:
adp
cdp
dragonboard
idp
liquid
mtp
qcp
qrd
rb2
ride
sbc
x100
The 'soc_version' and 'board_version' elements take the form of v<Major>.<Minor>
where the minor number may be omitted when it's zero, i.e. v1.0 is the same
as v1. If all versions of the 'board_version' elements match, then a
wildcard '*' should be used, e.g. 'v*'.
The 'foundry_id' and 'subtype' elements are one or more digits from 0 to 9.
Examples:
"qcom,msm8916-v1-cdp-pm8916-v2.1"
A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of version
2.1.
"qcom,apq8074-v2.0-2-dragonboard/1-v0.1"
A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in
foundry 2.
There are many devices in the list below that run the standard ChromeOS
bootloader setup and use the open source depthcharge bootloader to boot the
OS. These devices do not use the scheme described above. For details, see:
OS. These devices use the bootflow explained at
https://docs.kernel.org/arch/arm/google/chromebook-boot-flow.html
properties:
@ -187,6 +146,7 @@ properties:
- microsoft,superman-lte
- microsoft,tesla
- motorola,peregrine
- samsung,matisselte
- const: qcom,msm8926
- const: qcom,msm8226
@ -244,11 +204,15 @@ properties:
- samsung,a5u-eur
- samsung,e5
- samsung,e7
- samsung,fortuna3g
- samsung,gprimeltecan
- samsung,grandmax
- samsung,grandprimelte
- samsung,gt510
- samsung,gt58
- samsung,j5
- samsung,j5x
- samsung,rossa
- samsung,serranove
- thwc,uf896
- thwc,ufi001c
@ -988,6 +952,7 @@ properties:
- items:
- enum:
- xiaomi,curtana
- xiaomi,joyeuse
- const: qcom,sm7125
@ -1035,6 +1000,7 @@ properties:
- items:
- enum:
- qcom,sm8550-hdk
- qcom,sm8550-mtp
- qcom,sm8550-qrd
- const: qcom,sm8550

71
Documentation/devicetree/bindings/arm/rockchip.yaml
View File

@ -37,29 +37,16 @@ properties:
- anbernic,rg351v
- const: rockchip,rk3326
- description: Anbernic RG353P
- description: Anbernic RK3566 Handheld Gaming Console
items:
- const: anbernic,rg353p
- const: rockchip,rk3566
- description: Anbernic RG353PS
items:
- const: anbernic,rg353ps
- const: rockchip,rk3566
- description: Anbernic RG353V
items:
- const: anbernic,rg353v
- const: rockchip,rk3566
- description: Anbernic RG353VS
items:
- const: anbernic,rg353vs
- const: rockchip,rk3566
- description: Anbernic RG503
items:
- const: anbernic,rg503
- enum:
- anbernic,rg353p
- anbernic,rg353ps
- anbernic,rg353v
- anbernic,rg353vs
- anbernic,rg503
- anbernic,rg-arc-d
- anbernic,rg-arc-s
- const: rockchip,rk3566
- description: Asus Tinker board
@ -237,6 +224,13 @@ properties:
- friendlyarm,nanopi-r5s
- const: rockchip,rk3568
- description: FriendlyElec NanoPi R6 series boards
items:
- enum:
- friendlyarm,nanopi-r6c
- friendlyarm,nanopi-r6s
- const: rockchip,rk3588s
- description: FriendlyElec NanoPC T6
items:
- const: friendlyarm,nanopc-t6
@ -626,9 +620,9 @@ properties:
- const: openailab,eaidk-610
- const: rockchip,rk3399
- description: Orange Pi RK3399 board
- description: Xunlong Orange Pi RK3399 board
items:
- const: rockchip,rk3399-orangepi
- const: xunlong,rk3399-orangepi
- const: rockchip,rk3399
- description: Phytec phyCORE-RK3288 Rapid Development Kit
@ -655,6 +649,14 @@ properties:
- const: pine64,pinephone-pro
- const: rockchip,rk3399
- description: Pine64 PineTab2
items:
- enum:
- pine64,pinetab2-v0.1
- pine64,pinetab2-v2.0
- const: pine64,pinetab2
- const: rockchip,rk3566
- description: Pine64 Rock64
items:
- const: pine64,rock64
@ -692,11 +694,17 @@ properties:
- description: Powkiddy RK3566 Handheld Gaming Console
items:
- enum:
- powkiddy,rgb10max3
- powkiddy,rgb30
- powkiddy,rk2023
- powkiddy,x55
- const: rockchip,rk3566
- description: QNAP TS-433-4G 4-Bay NAS
items:
- const: qnap,ts433
- const: rockchip,rk3568
- description: Radxa Compute Module 3(CM3)
items:
- enum:
@ -878,6 +886,11 @@ properties:
- const: rockchip,rv1108-evb
- const: rockchip,rv1108
- description: Rockchip Toybrick TB-RK3588X board
items:
- const: rockchip,rk3588-toybrick-x0
- const: rockchip,rk3588
- description: Theobroma Systems PX30-uQ7 with Haikou baseboard
items:
- const: tsd,px30-ringneck-haikou
@ -898,6 +911,12 @@ properties:
- const: tsd,rk3588-jaguar
- const: rockchip,rk3588
- description: Theobroma Systems RK3588-Q7 with Haikou baseboard
items:
- const: tsd,rk3588-tiger-haikou
- const: tsd,rk3588-tiger
- const: rockchip,rk3588
- description: Tronsmart Orion R68 Meta
items:
- const: tronsmart,orion-r68-meta
@ -940,9 +959,9 @@ properties:
- const: rockchip,rk3568-evb1-v10
- const: rockchip,rk3568
- description: Rockchip RK3568 Banana Pi R2 Pro
- description: Sinovoip RK3568 Banana Pi R2 Pro
items:
- const: rockchip,rk3568-bpi-r2pro
- const: sinovoip,rk3568-bpi-r2pro
- const: rockchip,rk3568
- description: Sonoff iHost Smart Home Hub

12
Documentation/devicetree/bindings/arm/sunxi.yaml
View File

@ -815,6 +815,12 @@ properties:
- const: allwinner,r7-tv-dongle
- const: allwinner,sun5i-a10s
- description: Remix Mini PC
items:
- const: jide,remix-mini-pc
- const: allwinner,sun50i-h64
- const: allwinner,sun50i-a64
- description: RerVision H3-DVK
items:
- const: rervision,h3-dvk
@ -835,6 +841,12 @@ properties:
- const: sinlinx,sina33
- const: allwinner,sun8i-a33
- description: Sipeed Longan Pi 3H board for the Sipeed Longan Module 3H
items:
- const: sipeed,longan-pi-3h
- const: sipeed,longan-module-3h
- const: allwinner,sun50i-h618
- description: SourceParts PopStick v1.1
items:
- const: sourceparts,popstick-v1.1

8
Documentation/devicetree/bindings/arm/tegra.yaml
View File

@ -64,6 +64,14 @@ properties:
- items:
- const: asus,tf700t
- const: nvidia,tegra30
- description: LG Optimus 4X P880
items:
- const: lg,p880
- const: nvidia,tegra30
- description: LG Optimus Vu P895
items:
- const: lg,p895
- const: nvidia,tegra30
- items:
- const: toradex,apalis_t30-eval
- const: toradex,apalis_t30

54
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.yaml
View File

@ -27,7 +27,7 @@ properties:
- const: pmc
- const: wake
- const: aotag
- const: scratch
- enum: [ scratch, misc ]
- const: misc
interrupt-controller: true
@ -41,25 +41,43 @@ properties:
description: If present, inverts the PMU interrupt signal.
$ref: /schemas/types.yaml#/definitions/flag
if:
properties:
compatible:
contains:
const: nvidia,tegra186-pmc
then:
properties:
reg:
maxItems: 4
allOf:
- if:
properties:
compatible:
contains:
const: nvidia,tegra186-pmc
then:
properties:
reg:
maxItems: 4
reg-names:
maxItems: 4
contains:
const: scratch
reg-names:
maxItems: 4
else:
properties:
reg:
minItems: 5
- if:
properties:
compatible:
contains:
const: nvidia,tegra194-pmc
then:
properties:
reg:
minItems: 5
reg-names:
minItems: 5
reg-names:
minItems: 5
- if:
properties:
compatible:
contains:
const: nvidia,tegra234-pmc
then:
properties:
reg-names:
contains:
const: misc
patternProperties:
"^[a-z0-9]+-[a-z0-9]+$":

14
Documentation/devicetree/bindings/arm/ti/k3.yaml
View File

@ -87,12 +87,20 @@ properties:
- const: tq,am642-tqma6442l
- const: ti,am642
- description: K3 AM642 SoC SolidRun SoM based boards
items:
- enum:
- solidrun,am642-hummingboard-t
- const: solidrun,am642-sr-som
- const: ti,am642
- description: K3 AM654 SoC
items:
- enum:
- siemens,iot2050-advanced
- siemens,iot2050-advanced-m2
- siemens,iot2050-advanced-pg2
- siemens,iot2050-advanced-sm
- siemens,iot2050-basic
- siemens,iot2050-basic-pg2
- ti,am654-evm
@ -123,6 +131,12 @@ properties:
- ti,j721s2-evm
- const: ti,j721s2
- description: K3 J722S SoC and Boards
items:
- enum:
- ti,j722s-evm
- const: ti,j722s
- description: K3 J784s4 SoC
items:
- enum:

117
Documentation/devicetree/bindings/bus/imx-weim.txt
View File

@ -1,117 +0,0 @@
Device tree bindings for i.MX Wireless External Interface Module (WEIM)
The term "wireless" does not imply that the WEIM is literally an interface
without wires. It simply means that this module was originally designed for
wireless and mobile applications that use low-power technology.
The actual devices are instantiated from the child nodes of a WEIM node.
Required properties:
- compatible: Should contain one of the following:
"fsl,imx1-weim"
"fsl,imx27-weim"
"fsl,imx51-weim"
"fsl,imx50-weim"
"fsl,imx6q-weim"
- reg: A resource specifier for the register space
(see the example below)
- clocks: the clock, see the example below.
- #address-cells: Must be set to 2 to allow memory address translation
- #size-cells: Must be set to 1 to allow CS address passing
- ranges: Must be set up to reflect the memory layout with four
integer values for each chip-select line in use:
<cs-number> 0 <physical address of mapping> <size>
Optional properties:
- fsl,weim-cs-gpr: For "fsl,imx50-weim" and "fsl,imx6q-weim" type of
devices, it should be the phandle to the system General
Purpose Register controller that contains WEIM CS GPR
register, e.g. IOMUXC_GPR1 on i.MX6Q. IOMUXC_GPR1[11:0]
should be set up as one of the following 4 possible
values depending on the CS space configuration.
IOMUXC_GPR1[11:0] CS0 CS1 CS2 CS3
---------------------------------------------
05 128M 0M 0M 0M
033 64M 64M 0M 0M
0113 64M 32M 32M 0M
01111 32M 32M 32M 32M
In case that the property is absent, the reset value or
what bootloader sets up in IOMUXC_GPR1[11:0] will be
used.
- fsl,burst-clk-enable For "fsl,imx50-weim" and "fsl,imx6q-weim" type of
devices, the presence of this property indicates that
the weim bus should operate in Burst Clock Mode.
- fsl,continuous-burst-clk Make Burst Clock to output continuous clock.
Without this option Burst Clock will output clock
only when necessary. This takes effect only if
"fsl,burst-clk-enable" is set.
Timing property for child nodes. It is mandatory, not optional.
- fsl,weim-cs-timing: The timing array, contains timing values for the
child node. We get the CS indexes from the address
ranges in the child node's "reg" property.
The number of registers depends on the selected chip:
For i.MX1, i.MX21 ("fsl,imx1-weim") there are two
registers: CSxU, CSxL.
For i.MX25, i.MX27, i.MX31 and i.MX35 ("fsl,imx27-weim")
there are three registers: CSCRxU, CSCRxL, CSCRxA.
For i.MX50, i.MX53 ("fsl,imx50-weim"),
i.MX51 ("fsl,imx51-weim") and i.MX6Q ("fsl,imx6q-weim")
there are six registers: CSxGCR1, CSxGCR2, CSxRCR1,
CSxRCR2, CSxWCR1, CSxWCR2.
Example for an imx6q-sabreauto board, the NOR flash connected to the WEIM:
weim: weim@21b8000 {
compatible = "fsl,imx6q-weim";
reg = <0x021b8000 0x4000>;
clocks = <&clks 196>;
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x08000000 0x08000000>;
fsl,weim-cs-gpr = <&gpr>;
nor@0,0 {
compatible = "cfi-flash";
reg = <0 0 0x02000000>;
#address-cells = <1>;
#size-cells = <1>;
bank-width = <2>;
fsl,weim-cs-timing = <0x00620081 0x00000001 0x1c022000
0x0000c000 0x1404a38e 0x00000000>;
};
};
Example for an imx6q-based board, a multi-chipselect device connected to WEIM:
In this case, both chip select 0 and 1 will be configured with the same timing
array values.
weim: weim@21b8000 {
compatible = "fsl,imx6q-weim";
reg = <0x021b8000 0x4000>;
clocks = <&clks 196>;
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x08000000 0x02000000
1 0 0x0a000000 0x02000000
2 0 0x0c000000 0x02000000
3 0 0x0e000000 0x02000000>;
fsl,weim-cs-gpr = <&gpr>;
acme@0 {
compatible = "acme,whatever";
reg = <0 0 0x100>, <0 0x400000 0x800>,
<1 0x400000 0x800>;
fsl,weim-cs-timing = <0x024400b1 0x00001010 0x20081100
0x00000000 0xa0000240 0x00000000>;
};
};

28
Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
View File

@ -30,14 +30,16 @@ properties:
- google,gs101-cmu-top
- google,gs101-cmu-apm
- google,gs101-cmu-misc
- google,gs101-cmu-peric0
- google,gs101-cmu-peric1
clocks:
minItems: 1
maxItems: 2
maxItems: 3
clock-names:
minItems: 1
maxItems: 2
maxItems: 3
"#clock-cells":
const: 1
@ -88,6 +90,28 @@ allOf:
- const: bus
- const: sss
- if:
properties:
compatible:
contains:
enum:
- google,gs101-cmu-peric0
- google,gs101-cmu-peric1
then:
properties:
clocks:
items:
- description: External reference clock (24.576 MHz)
- description: Connectivity Peripheral 0/1 bus clock (from CMU_TOP)
- description: Connectivity Peripheral 0/1 IP clock (from CMU_TOP)
clock-names:
items:
- const: oscclk
- const: bus
- const: ip
additionalProperties: false
examples:

7
Documentation/devicetree/bindings/clock/qcom,gcc-sc8180x.yaml
View File

@ -31,10 +31,15 @@ properties:
- const: bi_tcxo_ao
- const: sleep_clk
power-domains:
items:
- description: CX domain
required:
- compatible
- clocks
- clock-names
- power-domains
allOf:
- $ref: qcom,gcc.yaml#
@ -44,6 +49,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/power/qcom-rpmpd.h>
clock-controller@100000 {
compatible = "qcom,gcc-sc8180x";
reg = <0x00100000 0x1f0000>;
@ -51,6 +57,7 @@ examples:
<&rpmhcc RPMH_CXO_CLK_A>,
<&sleep_clk>;
clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk";
power-domains = <&rpmhpd SC8180X_CX>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;

2
Documentation/devicetree/bindings/clock/qcom,sm8450-camcc.yaml
View File

@ -17,6 +17,7 @@ description: |
include/dt-bindings/clock/qcom,sm8450-camcc.h
include/dt-bindings/clock/qcom,sm8550-camcc.h
include/dt-bindings/clock/qcom,sc8280xp-camcc.h
include/dt-bindings/clock/qcom,x1e80100-camcc.h
allOf:
- $ref: qcom,gcc.yaml#
@ -27,6 +28,7 @@ properties:
- qcom,sc8280xp-camcc
- qcom,sm8450-camcc
- qcom,sm8550-camcc
- qcom,x1e80100-camcc
clocks:
items:

2
Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
View File

@ -18,6 +18,7 @@ description: |
include/dt-bindings/clock/qcom,sm8550-gpucc.h
include/dt-bindings/reset/qcom,sm8450-gpucc.h
include/dt-bindings/reset/qcom,sm8650-gpucc.h
include/dt-bindings/reset/qcom,x1e80100-gpucc.h
properties:
compatible:
@ -25,6 +26,7 @@ properties:
- qcom,sm8450-gpucc
- qcom,sm8550-gpucc
- qcom,sm8650-gpucc
- qcom,x1e80100-gpucc
clocks:
items:

7
Documentation/devicetree/bindings/clock/qcom,sm8550-dispcc.yaml
View File

@ -14,12 +14,17 @@ description: |
Qualcomm display clock control module provides the clocks, resets and power
domains on SM8550.
See also:: include/dt-bindings/clock/qcom,sm8550-dispcc.h
See also:
- include/dt-bindings/clock/qcom,sm8550-dispcc.h
- include/dt-bindings/clock/qcom,sm8650-dispcc.h
- include/dt-bindings/clock/qcom,x1e80100-dispcc.h
properties:
compatible:
enum:
- qcom,sm8550-dispcc
- qcom,sm8650-dispcc
- qcom,x1e80100-dispcc
clocks:
items:

1
Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
View File

@ -23,6 +23,7 @@ properties:
- enum:
- qcom,sm8550-tcsr
- qcom,sm8650-tcsr
- qcom,x1e80100-tcsr
- const: syscon
clocks:

106
Documentation/devicetree/bindings/clock/qcom,sm8650-dispcc.yaml
View File

@ -1,106 +0,0 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,sm8650-dispcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Display Clock & Reset Controller for SM8650
maintainers:
- Bjorn Andersson <andersson@kernel.org>
- Neil Armstrong <neil.armstrong@linaro.org>
description: |
Qualcomm display clock control module provides the clocks, resets and power
domains on SM8650.
See also:: include/dt-bindings/clock/qcom,sm8650-dispcc.h
properties:
compatible:
enum:
- qcom,sm8650-dispcc
clocks:
items:
- description: Board XO source
- description: Board Always On XO source
- description: Display's AHB clock
- description: sleep clock
- description: Byte clock from DSI PHY0
- description: Pixel clock from DSI PHY0
- description: Byte clock from DSI PHY1
- description: Pixel clock from DSI PHY1
- description: Link clock from DP PHY0
- description: VCO DIV clock from DP PHY0
- description: Link clock from DP PHY1
- description: VCO DIV clock from DP PHY1
- description: Link clock from DP PHY2
- description: VCO DIV clock from DP PHY2
- description: Link clock from DP PHY3
- description: VCO DIV clock from DP PHY3
'#clock-cells':
const: 1
'#reset-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
maxItems: 1
power-domains:
description:
A phandle and PM domain specifier for the MMCX power domain.
maxItems: 1
required-opps:
description:
A phandle to an OPP node describing required MMCX performance point.
maxItems: 1
required:
- compatible
- reg
- clocks
- '#clock-cells'
- '#reset-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,sm8650-gcc.h>
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/power/qcom-rpmpd.h>
#include <dt-bindings/power/qcom,rpmhpd.h>
clock-controller@af00000 {
compatible = "qcom,sm8650-dispcc";
reg = <0x0af00000 0x10000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
<&rpmhcc RPMH_CXO_CLK_A>,
<&gcc GCC_DISP_AHB_CLK>,
<&sleep_clk>,
<&dsi0_phy 0>,
<&dsi0_phy 1>,
<&dsi1_phy 0>,
<&dsi1_phy 1>,
<&dp0_phy 0>,
<&dp0_phy 1>,
<&dp1_phy 0>,
<&dp1_phy 1>,
<&dp2_phy 0>,
<&dp2_phy 1>,
<&dp3_phy 0>,
<&dp3_phy 1>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
power-domains = <&rpmhpd RPMHPD_MMCX>;
required-opps = <&rpmhpd_opp_low_svs>;
};
...

1
Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml
View File

@ -50,6 +50,7 @@ properties:
- renesas,r8a779a0-cpg-mssr # R-Car V3U
- renesas,r8a779f0-cpg-mssr # R-Car S4-8
- renesas,r8a779g0-cpg-mssr # R-Car V4H
- renesas,r8a779h0-cpg-mssr # R-Car V4M
reg:
maxItems: 1

1
Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
View File

@ -29,6 +29,7 @@ properties:
vddi-supply:
description: regulator that supplies the vddi voltage
backlight: true
port: true
required:
- compatible

96
Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
View File

@ -26,6 +26,12 @@ properties:
- description: For implementations complying for Versal.
const: xlnx,versal-firmware
- description: For implementations complying for Versal NET.
items:
- enum:
- xlnx,versal-net-firmware
- const: xlnx,versal-firmware
method:
description: |
The method of calling the PM-API firmware layer.
@ -41,7 +47,53 @@ properties:
"#power-domain-cells":
const: 1
versal_fpga:
clock-controller:
$ref: /schemas/clock/xlnx,versal-clk.yaml#
description: The clock controller is a hardware block of Xilinx versal
clock tree. It reads required input clock frequencies from the devicetree
and acts as clock provider for all clock consumers of PS clocks.list of
clock specifiers which are external input clocks to the given clock
controller.
type: object
gpio:
$ref: /schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#
description: The gpio node describes connect to PS_MODE pins via firmware
interface.
type: object
soc-nvmem:
$ref: /schemas/nvmem/xlnx,zynqmp-nvmem.yaml#
description: The ZynqMP MPSoC provides access to the hardware related data
like SOC revision, IDCODE and specific purpose efuses.
type: object
pcap:
$ref: /schemas/fpga/xlnx,zynqmp-pcap-fpga.yaml
description: The ZynqMP SoC uses the PCAP (Processor Configuration Port) to
configure the Programmable Logic (PL). The configuration uses the
firmware interface.
type: object
pinctrl:
$ref: /schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
description: The pinctrl node provides access to pinconfig and pincontrol
functionality available in firmware.
type: object
power-management:
$ref: /schemas/power/reset/xlnx,zynqmp-power.yaml#
description: The zynqmp-power node describes the power management
configurations. It will control remote suspend/shutdown interfaces.
type: object
reset-controller:
$ref: /schemas/reset/xlnx,zynqmp-reset.yaml#
description: The reset-controller node describes connection to the reset
functionality via firmware interface.
type: object
versal-fpga:
$ref: /schemas/fpga/xlnx,versal-fpga.yaml#
description: Compatible of the FPGA device.
type: object
@ -53,15 +105,6 @@ properties:
vector.
type: object
clock-controller:
$ref: /schemas/clock/xlnx,versal-clk.yaml#
description: The clock controller is a hardware block of Xilinx versal
clock tree. It reads required input clock frequencies from the devicetree
and acts as clock provider for all clock consumers of PS clocks.list of
clock specifiers which are external input clocks to the given clock
controller.
type: object
required:
- compatible
@ -73,7 +116,38 @@ examples:
firmware {
zynqmp_firmware: zynqmp-firmware {
#power-domain-cells = <1>;
soc-nvmem {
compatible = "xlnx,zynqmp-nvmem-fw";
nvmem-layout {
compatible = "fixed-layout";
#address-cells = <1>;
#size-cells = <1>;
soc_revision: soc-revision@0 {
reg = <0x0 0x4>;
};
};
};
gpio {
compatible = "xlnx,zynqmp-gpio-modepin";
gpio-controller;
#gpio-cells = <2>;
};
pcap {
compatible = "xlnx,zynqmp-pcap-fpga";
};
pinctrl {
compatible = "xlnx,zynqmp-pinctrl";
};
power-management {
compatible = "xlnx,zynqmp-power";
interrupts = <0 35 4>;
};
reset-controller {
compatible = "xlnx,zynqmp-reset";
#reset-cells = <1>;
};
};
};
sata {
@ -84,7 +158,7 @@ examples:
compatible = "xlnx,versal-firmware";
method = "smc";
versal_fpga: versal_fpga {
versal_fpga: versal-fpga {
compatible = "xlnx,versal-fpga";
};

2
Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
View File

@ -26,7 +26,7 @@ additionalProperties: false
examples:
- |
versal_fpga: versal_fpga {
versal_fpga: versal-fpga {
compatible = "xlnx,versal-fpga";
};

4
Documentation/devicetree/bindings/gpu/img,powervr.yaml → Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
View File

@ -2,10 +2,10 @@
# Copyright (c) 2023 Imagination Technologies Ltd.
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpu/img,powervr.yaml#
$id: http://devicetree.org/schemas/gpu/img,powervr-rogue.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Imagination Technologies PowerVR and IMG GPU
title: Imagination Technologies PowerVR and IMG Rogue GPUs
maintainers:
- Frank Binns <frank.binns@imgtec.com>

138
Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml Normal file
View File

@ -0,0 +1,138 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (c) 2023 Imagination Technologies Ltd.
# Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpu/img,powervr-sgx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Imagination Technologies PowerVR SGX GPUs
maintainers:
- Frank Binns <frank.binns@imgtec.com>
properties:
compatible:
oneOf:
- items:
- enum:
- ti,omap3430-gpu # Rev 121
- ti,omap3630-gpu # Rev 125
- const: img,powervr-sgx530
- items:
- enum:
- ingenic,jz4780-gpu # Rev 130
- ti,omap4430-gpu # Rev 120
- const: img,powervr-sgx540
- items:
- enum:
- allwinner,sun6i-a31-gpu # MP2 Rev 115
- ti,omap4470-gpu # MP1 Rev 112
- ti,omap5432-gpu # MP2 Rev 105
- ti,am5728-gpu # MP2 Rev 116
- ti,am6548-gpu # MP1 Rev 117
- const: img,powervr-sgx544
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
minItems: 1
maxItems: 3
clock-names:
minItems: 1
items:
- const: core
- const: mem
- const: sys
power-domains:
maxItems: 1
required:
- compatible
- reg
- interrupts
allOf:
- if:
properties:
compatible:
contains:
const: ti,am6548-gpu
then:
required:
- power-domains
else:
properties:
power-domains: false
- if:
properties:
compatible:
contains:
enum:
- allwinner,sun6i-a31-gpu
- ingenic,jz4780-gpu
then:
required:
- clocks
- clock-names
else:
properties:
clocks: false
clock-names: false
- if:
properties:
compatible:
contains:
const: allwinner,sun6i-a31-gpu
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
minItems: 2
maxItems: 2
- if:
properties:
compatible:
contains:
const: ingenic,jz4780-gpu
then:
properties:
clocks:
maxItems: 1
clock-names:
maxItems: 1
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/soc/ti,sci_pm_domain.h>
gpu@7000000 {
compatible = "ti,am6548-gpu", "img,powervr-sgx544";
reg = <0x7000000 0x10000>;
interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
power-domains = <&k3_pds 65 TI_SCI_PD_EXCLUSIVE>;
};
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
gpu: gpu@1c40000 {
compatible = "allwinner,sun6i-a31-gpu", "img,powervr-sgx544";
reg = <0x01c40000 0x10000>;
interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu 1>, <&ccu 2>;
clock-names = "core", "mem";
};

1
Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
View File

@ -33,6 +33,7 @@ properties:
- const: samsung,exynos7-hsi2c
- items:
- enum:
- google,gs101-hsi2c
- samsung,exynos850-hsi2c
- const: samsung,exynosautov9-hsi2c
- const: samsung,exynos5-hsi2c # Exynos5250 and Exynos5420

1
Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.yaml
View File

@ -36,6 +36,7 @@ properties:
- amlogic,meson-a1-gpio-intc
- amlogic,meson-s4-gpio-intc
- amlogic,c3-gpio-intc
- amlogic,t7-gpio-intc
- const: amlogic,meson-gpio-intc
reg:

61
Documentation/devicetree/bindings/interrupt-controller/starfive,jh8100-intc.yaml Normal file
View File

@ -0,0 +1,61 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/interrupt-controller/starfive,jh8100-intc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: StarFive External Interrupt Controller
description:
StarFive SoC JH8100 contain a external interrupt controller. It can be used
to handle high-level input interrupt signals. It also send the output
interrupt signal to RISC-V PLIC.
maintainers:
- Changhuang Liang <changhuang.liang@starfivetech.com>
properties:
compatible:
const: starfive,jh8100-intc
reg:
maxItems: 1
clocks:
description: APB clock for the interrupt controller
maxItems: 1
resets:
description: APB reset for the interrupt controller
maxItems: 1
interrupts:
maxItems: 1
interrupt-controller: true
"#interrupt-cells":
const: 1
required:
- compatible
- reg
- clocks
- resets
- interrupts
- interrupt-controller
- "#interrupt-cells"
additionalProperties: false
examples:
- |
interrupt-controller@12260000 {
compatible = "starfive,jh8100-intc";
reg = <0x12260000 0x10000>;
clocks = <&syscrg_ne 76>;
resets = <&syscrg_ne 13>;
interrupts = <45>;
interrupt-controller;
#interrupt-cells = <1>;
};

31
Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
View File

@ -16,14 +16,18 @@ description: |+
properties:
compatible:
enum:
- mediatek,mt8173-vcodec-enc-vp8
- mediatek,mt8173-vcodec-enc
- mediatek,mt8183-vcodec-enc
- mediatek,mt8188-vcodec-enc
- mediatek,mt8192-vcodec-enc
- mediatek,mt8195-vcodec-enc
oneOf:
- items:
- enum:
- mediatek,mt8173-vcodec-enc-vp8
- mediatek,mt8173-vcodec-enc
- mediatek,mt8183-vcodec-enc
- mediatek,mt8188-vcodec-enc
- mediatek,mt8192-vcodec-enc
- mediatek,mt8195-vcodec-enc
- items:
- const: mediatek,mt8186-vcodec-enc
- const: mediatek,mt8183-vcodec-enc
reg:
maxItems: 1
@ -109,10 +113,7 @@ allOf:
properties:
compatible:
enum:
- mediatek,mt8173-vcodec-enc
- mediatek,mt8188-vcodec-enc
- mediatek,mt8192-vcodec-enc
- mediatek,mt8195-vcodec-enc
- mediatek,mt8173-vcodec-enc-vp8
then:
properties:
@ -122,8 +123,8 @@ allOf:
maxItems: 1
clock-names:
items:
- const: venc_sel
else: # for vp8 hw encoder
- const: venc_lt_sel
else:
properties:
clock:
items:
@ -131,7 +132,7 @@ allOf:
maxItems: 1
clock-names:
items:
- const: venc_lt_sel
- const: venc_sel
additionalProperties: false

3
Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
View File

@ -38,7 +38,8 @@ properties:
maxItems: 1
iommus:
maxItems: 2
minItems: 2
maxItems: 4
description: |
Points to the respective IOMMU block with master port as argument, see
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details.

31
Documentation/devicetree/bindings/memory-controllers/fsl/fsl,imx-weim-peripherals.yaml Normal file
View File

@ -0,0 +1,31 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/memory-controllers/fsl/fsl,imx-weim-peripherals.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: i.MX WEIM Bus Peripheral Nodes
maintainers:
- Shawn Guo <shawnguo@kernel.org>
- Sascha Hauer <s.hauer@pengutronix.de>
description:
This binding is meant for the child nodes of the WEIM node. The node
represents any device connected to the WEIM bus. It may be a Flash chip,
RAM chip or Ethernet controller, etc. These properties are meant for
configuring the WEIM settings/timings and will accompany the bindings
supported by the respective device.
properties:
reg: true
fsl,weim-cs-timing:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
Timing values for the child node.
minItems: 2
maxItems: 6
# the WEIM child will have its own native properties
additionalProperties: true

204
Documentation/devicetree/bindings/memory-controllers/fsl/fsl,imx-weim.yaml Normal file
View File

@ -0,0 +1,204 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/memory-controllers/fsl/fsl,imx-weim.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: i.MX Wireless External Interface Module (WEIM)
maintainers:
- Shawn Guo <shawnguo@kernel.org>
- Sascha Hauer <s.hauer@pengutronix.de>
description:
The term "wireless" does not imply that the WEIM is literally an interface
without wires. It simply means that this module was originally designed for
wireless and mobile applications that use low-power technology. The actual
devices are instantiated from the child nodes of a WEIM node.
properties:
$nodename:
pattern: "^memory-controller@[0-9a-f]+$"
compatible:
oneOf:
- enum:
- fsl,imx1-weim
- fsl,imx27-weim
- fsl,imx50-weim
- fsl,imx51-weim
- fsl,imx6q-weim
- items:
- enum:
- fsl,imx31-weim
- fsl,imx35-weim
- const: fsl,imx27-weim
- items:
- enum:
- fsl,imx6sx-weim
- fsl,imx6ul-weim
- const: fsl,imx6q-weim
"#address-cells":
const: 2
"#size-cells":
const: 1
reg:
maxItems: 1
clocks:
maxItems: 1
interrupts:
maxItems: 1
ranges: true
fsl,weim-cs-gpr:
$ref: /schemas/types.yaml#/definitions/phandle
description: |
Phandle to the system General Purpose Register controller that contains
WEIM CS GPR register, e.g. IOMUXC_GPR1 on i.MX6Q. IOMUXC_GPR1[11:0]
should be set up as one of the following 4 possible values depending on
the CS space configuration.
IOMUXC_GPR1[11:0] CS0 CS1 CS2 CS3
---------------------------------------------
05 128M 0M 0M 0M
033 64M 64M 0M 0M
0113 64M 32M 32M 0M
01111 32M 32M 32M 32M
In case that the property is absent, the reset value or what bootloader
sets up in IOMUXC_GPR1[11:0] will be used.
fsl,burst-clk-enable:
type: boolean
description:
The presence of this property indicates that the weim bus should operate
in Burst Clock Mode.
fsl,continuous-burst-clk:
type: boolean
description:
Make Burst Clock to output continuous clock. Without this option Burst
Clock will output clock only when necessary.
patternProperties:
"^.*@[0-7],[0-9a-f]+$":
type: object
description: Devices attached to chip selects are represented as subnodes.
$ref: fsl,imx-weim-peripherals.yaml
additionalProperties: true
required:
- fsl,weim-cs-timing
required:
- compatible
- reg
- clocks
- "#address-cells"
- "#size-cells"
- ranges
allOf:
- if:
properties:
compatible:
not:
contains:
enum:
- fsl,imx50-weim
- fsl,imx6q-weim
then:
properties:
fsl,weim-cs-gpr: false
fsl,burst-clk-enable: false
- if:
not:
required:
- fsl,burst-clk-enable
then:
properties:
fsl,continuous-burst-clk: false
- if:
properties:
compatible:
contains:
const: fsl,imx1-weim
then:
patternProperties:
"^.*@[0-7],[0-9a-f]+$":
properties:
fsl,weim-cs-timing:
items:
items:
- description: CSxU
- description: CSxL
- if:
properties:
compatible:
contains:
enum:
- fsl,imx27-weim
- fsl,imx31-weim
- fsl,imx35-weim
then:
patternProperties:
"^.*@[0-7],[0-9a-f]+$":
properties:
fsl,weim-cs-timing:
items:
items:
- description: CSCRxU
- description: CSCRxL
- description: CSCRxA
- if:
properties:
compatible:
contains:
enum:
- fsl,imx50-weim
- fsl,imx51-weim
- fsl,imx6q-weim
- fsl,imx6sx-weim
- fsl,imx6ul-weim
then:
patternProperties:
"^.*@[0-7],[0-9a-f]+$":
properties:
fsl,weim-cs-timing:
items:
items:
- description: CSxGCR1
- description: CSxGCR2
- description: CSxRCR1
- description: CSxRCR2
- description: CSxWCR1
- description: CSxWCR2
additionalProperties: false
examples:
- |
memory-controller@21b8000 {
compatible = "fsl,imx6q-weim";
reg = <0x021b8000 0x4000>;
clocks = <&clks 196>;
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x08000000 0x08000000>;
fsl,weim-cs-gpr = <&gpr>;
flash@0,0 {
compatible = "cfi-flash";
reg = <0 0 0x02000000>;
#address-cells = <1>;
#size-cells = <1>;
bank-width = <2>;
fsl,weim-cs-timing = <0x00620081 0x00000001 0x1c022000
0x0000c000 0x1404a38e 0x00000000>;
};
};

1
Documentation/devicetree/bindings/memory-controllers/mc-peripheral-props.yaml
View File

@ -37,5 +37,6 @@ allOf:
- $ref: ingenic,nemc-peripherals.yaml#
- $ref: intel,ixp4xx-expansion-peripheral-props.yaml#
- $ref: ti,gpmc-child.yaml#
- $ref: fsl/fsl,imx-weim-peripherals.yaml
additionalProperties: true

2
Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml
View File

@ -145,7 +145,7 @@ patternProperties:
"^emc-table@[0-9]+$":
$ref: "#/$defs/emc-table"
"^emc-tables@[a-z0-9-]+$":
"^emc-tables@[a-f0-9-]+$":
type: object
properties:
reg:

1
Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml
View File

@ -45,6 +45,7 @@ properties:
- items:
- enum:
- renesas,r8a779g0-rpc-if # R-Car V4H
- renesas,r8a779h0-rpc-if # R-Car V4M
- const: renesas,rcar-gen4-rpc-if # a generic R-Car gen4 device
- items:

7
Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml
View File

@ -23,7 +23,9 @@ maintainers:
properties:
compatible:
const: st,stm32mp1-fmc2-ebi
enum:
- st,stm32mp1-fmc2-ebi
- st,stm32mp25-fmc2-ebi
reg:
maxItems: 1
@ -34,6 +36,9 @@ properties:
resets:
maxItems: 1
power-domains:
maxItems: 1
"#address-cells":
const: 2

2
Documentation/devicetree/bindings/net/renesas,ethertsn.yaml
View File

@ -65,9 +65,11 @@ properties:
rx-internal-delay-ps:
enum: [0, 1800]
default: 0
tx-internal-delay-ps:
enum: [0, 2000]
default: 0
'#address-cells':
const: 1

1
Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
View File

@ -45,6 +45,7 @@ properties:
- renesas,r8a779a0-sysc # R-Car V3U
- renesas,r8a779f0-sysc # R-Car S4-8
- renesas,r8a779g0-sysc # R-Car V4H
- renesas,r8a779h0-sysc # R-Car V4M
reg:
maxItems: 1

1
Documentation/devicetree/bindings/reset/renesas,rst.yaml
View File

@ -50,6 +50,7 @@ properties:
- renesas,r8a779a0-rst # R-Car V3U
- renesas,r8a779f0-rst # R-Car S4-8
- renesas,r8a779g0-rst # R-Car V4H
- renesas,r8a779h0-rst # R-Car V4M
reg:
maxItems: 1

46
Documentation/devicetree/bindings/soc/qcom/qcom,pbs.yaml Normal file
View File

@ -0,0 +1,46 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/soc/qcom/qcom,pbs.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Technologies, Inc. Programmable Boot Sequencer
maintainers:
- Anjelique Melendez <quic_amelende@quicinc.com>
description: |
The Qualcomm Technologies, Inc. Programmable Boot Sequencer (PBS)
supports triggering power up and power down sequences for clients
upon request.
properties:
compatible:
items:
- enum:
- qcom,pmi632-pbs
- const: qcom,pbs
reg:
maxItems: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/spmi/spmi.h>
pmic@0 {
reg = <0x0 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
pbs@7400 {
compatible = "qcom,pmi632-pbs", "qcom,pbs";
reg = <0x7400>;
};
};

2
Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
View File

@ -32,6 +32,7 @@ properties:
- items:
- enum:
- qcom,sm8650-pmic-glink
- qcom,x1e80100-pmic-glink
- const: qcom,sm8550-pmic-glink
- const: qcom,pmic-glink
@ -65,6 +66,7 @@ allOf:
enum:
- qcom,sm8450-pmic-glink
- qcom,sm8550-pmic-glink
- qcom,x1e80100-pmic-glink
then:
properties:
orientation-gpios: false

2
Documentation/devicetree/bindings/soc/qcom/qcom,rpm-master-stats.yaml
View File

@ -35,6 +35,8 @@ properties:
description: Phandle to an RPM MSG RAM slice containing the master stats
minItems: 1
maxItems: 5
items:
maxItems: 1
qcom,master-names:
$ref: /schemas/types.yaml#/definitions/string-array

46
Documentation/devicetree/bindings/soc/qcom/qcom,spm.yaml → Documentation/devicetree/bindings/soc/qcom/qcom,saw2.yaml
View File

@ -1,23 +1,33 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/soc/qcom/qcom,spm.yaml#
$id: http://devicetree.org/schemas/soc/qcom/qcom,saw2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Subsystem Power Manager
title: Qualcomm Subsystem Power Manager / SPM AVS Wrapper 2 (SAW2)
maintainers:
- Andy Gross <agross@kernel.org>
- Bjorn Andersson <bjorn.andersson@linaro.org>
description: |
This binding describes the Qualcomm Subsystem Power Manager, used to control
the peripheral logic surrounding the application cores in Qualcomm platforms.
The Qualcomm Subsystem Power Manager is used to control the peripheral logic
surrounding the application cores in Qualcomm platforms.
The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable
power-controller that transitions a piece of hardware (like a processor or
subsystem) into and out of low power modes via a direct connection to
the PMIC. It can also be wired up to interact with other processors in the
system, notifying them when a low power state is entered or exited.
properties:
compatible:
items:
- enum:
- qcom,ipq4019-saw2-cpu
- qcom,ipq4019-saw2-l2
- qcom,ipq8064-saw2-cpu
- qcom,sdm660-gold-saw2-v4.1-l2
- qcom,sdm660-silver-saw2-v4.1-l2
- qcom,msm8998-gold-saw2-v4.1-l2
@ -26,16 +36,27 @@ properties:
- qcom,msm8916-saw2-v3.0-cpu
- qcom,msm8939-saw2-v3.0-cpu
- qcom,msm8226-saw2-v2.1-cpu
- qcom,msm8226-saw2-v2.1-l2
- qcom,msm8960-saw2-cpu
- qcom,msm8974-saw2-v2.1-cpu
- qcom,msm8974-saw2-v2.1-l2
- qcom,msm8976-gold-saw2-v2.3-l2
- qcom,msm8976-silver-saw2-v2.3-l2
- qcom,apq8084-saw2-v2.1-cpu
- qcom,apq8084-saw2-v2.1-l2
- qcom,apq8064-saw2-v1.1-cpu
- const: qcom,saw2
reg:
description: Base address and size of the SPM register region
maxItems: 1
items:
- description: Base address and size of the SPM register region
- description: Base address and size of the alias register region
minItems: 1
regulator:
$ref: /schemas/regulator/regulator.yaml#
description: Indicates that this SPM device acts as a regulator device
device for the core (CPU or Cache) the SPM is attached to.
required:
- compatible
@ -82,4 +103,17 @@ examples:
reg = <0x17912000 0x1000>;
};
- |
/*
* Example 3: SAW2 with the bundled regulator definition.
*/
power-manager@2089000 {
compatible = "qcom,apq8064-saw2-v1.1-cpu", "qcom,saw2";
reg = <0x02089000 0x1000>, <0x02009000 0x1000>;
regulator {
regulator-min-microvolt = <850000>;
regulator-max-microvolt = <1300000>;
};
};
...

73
Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml Normal file
View File

@ -0,0 +1,73 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/soc/renesas/renesas-soc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas SoC compatibles naming convention
maintainers:
- Geert Uytterhoeven <geert+renesas@glider.be>
- Niklas Söderlund <niklas.soderlund@ragnatech.se>
description: |
Guidelines for new compatibles for SoC blocks/components.
When adding new compatibles in new bindings, use the format::
renesas,SoC-IP
For example::
renesas,r8a77965-csi2
When adding new compatibles to existing bindings, use the format in the
existing binding, even if it contradicts the above.
select:
properties:
compatible:
contains:
pattern: "^renesas,.+-.+$"
required:
- compatible
properties:
compatible:
minItems: 1
maxItems: 4
items:
anyOf:
# Preferred naming style for compatibles of SoC components
- pattern: "^renesas,(emev2|r(7s|8a|9a)[a-z0-9]+|rcar|rmobile|rz[a-z0-9]*|sh(7[a-z0-9]+)?|mobile)-[a-z0-9-]+$"
- pattern: "^renesas,(condor|falcon|gr-peach|gray-hawk|salvator|sk-rz|smar(c(2)?)?|spider|white-hawk)(.*)?$"
# Legacy compatibles
#
# New compatibles are not allowed.
- pattern: "^renesas,(can|cpg|dmac|du|(g)?ether(avb)?|gpio|hscif|(r)?i[i2]c|imr|intc|ipmmu|irqc|jpu|mmcif|msiof|mtu2|pci(e)?|pfc|pwm|[rq]spi|rcar_sound|sata|scif[ab]*|sdhi|thermal|tmu|tpu|usb(2|hs)?|vin|xhci)-[a-z0-9-]+$"
- pattern: "^renesas,(d|s)?bsc(3)?-(r8a73a4|r8a7740|sh73a0)$"
- pattern: "^renesas,em-(gio|sti|uart)$"
- pattern: "^renesas,fsi2-(r8a7740|sh73a0)$"
- pattern: "^renesas,hspi-r8a777[89]$"
- pattern: "^renesas,sysc-(r8a73a4|r8a7740|rmobile|sh73a0)$"
- enum:
- renesas,imr-lx4
- renesas,mtu2-r7s72100
# None SoC component compatibles
#
# Compatibles with the Renesas vendor prefix that do not relate to any SoC
# component are OK. New compatibles are allowed.
- enum:
- renesas,smp-sram
# Do not fail compatibles not matching the select pattern
#
# Some SoC components in addition to a Renesas compatible list
# compatibles not related to Renesas. The select pattern for this
# schema hits all compatibles that have at lest one Renesas compatible
# and try to validate all values in that compatible array, allow all
# that don't match the schema select pattern. For example,
#
# compatible = "renesas,r9a07g044-mali", "arm,mali-bifrost";
- pattern: "^(?!renesas,.+-.+).+$"
additionalProperties: true

25
Documentation/devicetree/bindings/soc/renesas/renesas.yaml
View File

@ -348,12 +348,25 @@ properties:
- renesas,white-hawk-cpu # White Hawk CPU board (RTP8A779G0ASKB0FC0SA000)
- const: renesas,r8a779g0
- description: R-Car V4H (R8A779G2)
items:
- enum:
- renesas,white-hawk-single # White Hawk Single board (RTP8A779G2ASKB0F10SA001)
- const: renesas,r8a779g2
- const: renesas,r8a779g0
- items:
- enum:
- renesas,white-hawk-breakout # White Hawk BreakOut board (RTP8A779G0ASKB0SB0SA000)
- const: renesas,white-hawk-cpu
- const: renesas,r8a779g0
- description: R-Car V4M (R8A779H0)
items:
- enum:
- renesas,gray-hawk-single # Gray Hawk Single board (RTP8A779H0ASKB0F10S)
- const: renesas,r8a779h0
- description: R-Car H3e (R8A779M0)
items:
- enum:
@ -475,12 +488,6 @@ properties:
- renesas,r9a07g054l2 # Dual Cortex-A55 RZ/V2L
- const: renesas,r9a07g054
- description: RZ/V2M (R9A09G011)
items:
- enum:
- renesas,rzv2mevk2 # RZ/V2M Eval Board v2.0
- const: renesas,r9a09g011
- description: RZ/G3S (R9A08G045)
items:
- enum:
@ -500,6 +507,12 @@ properties:
- const: renesas,r9a08g045s33 # PCIe support
- const: renesas,r9a08g045
- description: RZ/V2M (R9A09G011)
items:
- enum:
- renesas,rzv2mevk2 # RZ/V2M Eval Board v2.0
- const: renesas,r9a09g011
additionalProperties: true
...

22
Documentation/devicetree/bindings/soc/rockchip/grf.yaml
View File

@ -22,12 +22,15 @@ properties:
- rockchip,rk3568-usb2phy-grf
- rockchip,rk3588-bigcore0-grf
- rockchip,rk3588-bigcore1-grf
- rockchip,rk3588-hdptxphy-grf
- rockchip,rk3588-ioc
- rockchip,rk3588-php-grf
- rockchip,rk3588-pipe-phy-grf
- rockchip,rk3588-sys-grf
- rockchip,rk3588-pcie3-phy-grf
- rockchip,rk3588-pcie3-pipe-grf
- rockchip,rk3588-usb-grf
- rockchip,rk3588-usbdpphy-grf
- rockchip,rk3588-vo-grf
- rockchip,rk3588-vop-grf
- rockchip,rv1108-usbgrf
@ -66,6 +69,9 @@ properties:
reg:
maxItems: 1
clocks:
maxItems: 1
"#address-cells":
const: 1
@ -248,6 +254,22 @@ allOf:
unevaluatedProperties: false
- if:
properties:
compatible:
contains:
enum:
- rockchip,rk3588-vo-grf
then:
required:
- clocks
else:
properties:
clocks: false
examples:
- |
#include <dt-bindings/clock/rk3399-cru.h>

2
Documentation/devicetree/bindings/soc/samsung/samsung,exynos-sysreg.yaml
View File

@ -72,6 +72,8 @@ allOf:
compatible:
contains:
enum:
- google,gs101-peric0-sysreg
- google,gs101-peric1-sysreg
- samsung,exynos850-cmgp-sysreg
- samsung,exynos850-peri-sysreg
- samsung,exynos850-sysreg

70
Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml
View File

@ -117,20 +117,70 @@ properties:
- const: xlnx,zynqmp
- description: Xilinx Kria SOMs
minItems: 3
items:
- const: xlnx,zynqmp-sm-k26-rev1
- const: xlnx,zynqmp-sm-k26-revB
- const: xlnx,zynqmp-sm-k26-revA
- const: xlnx,zynqmp-sm-k26
- const: xlnx,zynqmp
enum:
- xlnx,zynqmp-sm-k26-rev2
- xlnx,zynqmp-sm-k26-rev1
- xlnx,zynqmp-sm-k26-revB
- xlnx,zynqmp-sm-k26-revA
- xlnx,zynqmp-sm-k26
- xlnx,zynqmp
allOf:
- contains:
const: xlnx,zynqmp
- contains:
const: xlnx,zynqmp-sm-k26
- description: Xilinx Kria SOMs (starter)
minItems: 3
items:
- const: xlnx,zynqmp-smk-k26-rev1
- const: xlnx,zynqmp-smk-k26-revB
- const: xlnx,zynqmp-smk-k26-revA
- const: xlnx,zynqmp-smk-k26
- const: xlnx,zynqmp
enum:
- xlnx,zynqmp-smk-k26-rev2
- xlnx,zynqmp-smk-k26-rev1
- xlnx,zynqmp-smk-k26-revB
- xlnx,zynqmp-smk-k26-revA
- xlnx,zynqmp-smk-k26
- xlnx,zynqmp
allOf:
- contains:
const: xlnx,zynqmp
- contains:
const: xlnx,zynqmp-smk-k26
- description: Xilinx Kria SOM KV260 revA/Y/Z
minItems: 3
items:
enum:
- xlnx,zynqmp-sk-kv260-revA
- xlnx,zynqmp-sk-kv260-revY
- xlnx,zynqmp-sk-kv260-revZ
- xlnx,zynqmp-sk-kv260
- xlnx,zynqmp
allOf:
- contains:
const: xlnx,zynqmp-sk-kv260-revA
- contains:
const: xlnx,zynqmp-sk-kv260
- contains:
const: xlnx,zynqmp
- description: Xilinx Kria SOM KV260 rev2/1/B
minItems: 3
items:
enum:
- xlnx,zynqmp-sk-kv260-rev2
- xlnx,zynqmp-sk-kv260-rev1
- xlnx,zynqmp-sk-kv260-revB
- xlnx,zynqmp-sk-kv260
- xlnx,zynqmp
allOf:
- contains:
const: xlnx,zynqmp-sk-kv260-revB
- contains:
const: xlnx,zynqmp-sk-kv260
- contains:
const: xlnx,zynqmp
- description: AMD MicroBlaze V (QEMU)
items:

2
Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max9808x.yaml
View File

@ -64,7 +64,7 @@ examples:
#include <dt-bindings/clock/tegra30-car.h>
#include <dt-bindings/soc/tegra-pmc.h>
sound {
compatible = "lge,tegra-audio-max98089-p895",
compatible = "lg,tegra-audio-max98089-p895",
"nvidia,tegra-audio-max98089";
nvidia,model = "LG Optimus Vu MAX98089";

2
Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
View File

@ -56,7 +56,7 @@ properties:
ranges: true
patternProperties:
"^sram@[a-z0-9]+":
"^sram@[a-f0-9]+":
$ref: /schemas/sram/sram.yaml#
unevaluatedProperties: false

8
Documentation/devicetree/bindings/vendor-prefixes.yaml
View File

@ -39,6 +39,8 @@ patternProperties:
description: ShenZhen Asia Better Technology Ltd.
"^acbel,.*":
description: Acbel Polytech Inc.
"^acelink,.*":
description: Acelink Technology Co., Ltd.
"^acer,.*":
description: Acer Inc.
"^acme,.*":
@ -500,6 +502,8 @@ patternProperties:
description: FocalTech Systems Co.,Ltd
"^forlinx,.*":
description: Baoding Forlinx Embedded Technology Co., Ltd.
"^freebox,.*":
description: Freebox SAS
"^freecom,.*":
description: Freecom Gmbh
"^frida,.*":
@ -719,6 +723,8 @@ patternProperties:
description: JetHome (IP Sokolov P.A.)
"^jianda,.*":
description: Jiandangjing Technology Co., Ltd.
"^jide,.*":
description: Jide Tech
"^joz,.*":
description: JOZ BV
"^kam,.*":
@ -1484,6 +1490,8 @@ patternProperties:
description: Ufi Space Co., Ltd.
"^ugoos,.*":
description: Ugoos Industrial Co., Ltd.
"^uni-t,.*":
description: Uni-Trend Technology (China) Co., Ltd.
"^uniwest,.*":
description: United Western Technologies Corp (UniWest)
"^upisemi,.*":

2
Documentation/driver-api/dpll.rst
View File

@ -545,7 +545,7 @@ In such scenario, dpll device input signal shall be also configurable
to drive dpll with signal recovered from the PHY netdevice.
This is done by exposing a pin to the netdevice - attaching pin to the
netdevice itself with
``netdev_dpll_pin_set(struct net_device *dev, struct dpll_pin *dpll_pin)``.
``dpll_netdev_pin_set(struct net_device *dev, struct dpll_pin *dpll_pin)``.
Exposed pin id handle ``DPLL_A_PIN_ID`` is then identifiable by the user
as it is attached to rtnetlink respond to get ``RTM_NEWLINK`` command in
nested attribute ``IFLA_DPLL_PIN``.

2
Documentation/filesystems/files.rst
View File

@ -116,7 +116,7 @@ before and after the reference count increment. This pattern can be seen
in get_file_rcu() and __files_get_rcu().
In addition, it isn't possible to access or check fields in struct file
without first aqcuiring a reference on it under rcu lookup. Not doing
without first acquiring a reference on it under rcu lookup. Not doing
that was always very dodgy and it was only usable for non-pointer data
in struct file. With SLAB_TYPESAFE_BY_RCU it is necessary that callers
either first acquire a reference or they must hold the files_lock of the

1
Documentation/filesystems/index.rst
View File

@ -98,7 +98,6 @@ Documentation for filesystem implementations.
isofs
nilfs2
nfs/index
ntfs
ntfs3
ocfs2
ocfs2-online-filecheck

2
Documentation/filesystems/locking.rst
View File

@ -29,7 +29,7 @@ prototypes::
char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
struct vfsmount *(*d_automount)(struct path *path);
int (*d_manage)(const struct path *, bool);
struct dentry *(*d_real)(struct dentry *, const struct inode *);
struct dentry *(*d_real)(struct dentry *, enum d_real_type type);
locking rules:

466
Documentation/filesystems/ntfs.rst
View File

@ -1,466 +0,0 @@
.. SPDX-License-Identifier: GPL-2.0
================================
The Linux NTFS filesystem driver
================================
.. Table of contents
- Overview
- Web site
- Features
- Supported mount options
- Known bugs and (mis-)features
- Using NTFS volume and stripe sets
- The Device-Mapper driver
- The Software RAID / MD driver
- Limitations when using the MD driver
Overview
========
Linux-NTFS comes with a number of user-space programs known as ntfsprogs.
These include mkntfs, a full-featured ntfs filesystem format utility,
ntfsundelete used for recovering files that were unintentionally deleted
from an NTFS volume and ntfsresize which is used to resize an NTFS partition.
See the web site for more information.
To mount an NTFS 1.2/3.x (Windows NT4/2000/XP/2003) volume, use the file
system type 'ntfs'. The driver currently supports read-only mode (with no
fault-tolerance, encryption or journalling) and very limited, but safe, write
support.
For fault tolerance and raid support (i.e. volume and stripe sets), you can
use the kernel's Software RAID / MD driver. See section "Using Software RAID
with NTFS" for details.
Web site
========
There is plenty of additional information on the linux-ntfs web site
at http://www.linux-ntfs.org/
The web site has a lot of additional information, such as a comprehensive
FAQ, documentation on the NTFS on-disk format, information on the Linux-NTFS
userspace utilities, etc.
Features
========
- This is a complete rewrite of the NTFS driver that used to be in the 2.4 and
earlier kernels. This new driver implements NTFS read support and is
functionally equivalent to the old ntfs driver and it also implements limited
write support. The biggest limitation at present is that files/directories
cannot be created or deleted. See below for the list of write features that
are so far supported. Another limitation is that writing to compressed files
is not implemented at all. Also, neither read nor write access to encrypted
files is so far implemented.
- The new driver has full support for sparse files on NTFS 3.x volumes which
the old driver isn't happy with.
- The new driver supports execution of binaries due to mmap() now being
supported.
- The new driver supports loopback mounting of files on NTFS which is used by
some Linux distributions to enable the user to run Linux from an NTFS
partition by creating a large file while in Windows and then loopback
mounting the file while in Linux and creating a Linux filesystem on it that
is used to install Linux on it.
- A comparison of the two drivers using::
time find . -type f -exec md5sum "{}" \;
run three times in sequence with each driver (after a reboot) on a 1.4GiB
NTFS partition, showed the new driver to be 20% faster in total time elapsed
(from 9:43 minutes on average down to 7:53). The time spent in user space
was unchanged but the time spent in the kernel was decreased by a factor of
2.5 (from 85 CPU seconds down to 33).
- The driver does not support short file names in general. For backwards
compatibility, we implement access to files using their short file names if
they exist. The driver will not create short file names however, and a
rename will discard any existing short file name.
- The new driver supports exporting of mounted NTFS volumes via NFS.
- The new driver supports async io (aio).
- The new driver supports fsync(2), fdatasync(2), and msync(2).
- The new driver supports readv(2) and writev(2).
- The new driver supports access time updates (including mtime and ctime).
- The new driver supports truncate(2) and open(2) with O_TRUNC. But at present
only very limited support for highly fragmented files, i.e. ones which have
their data attribute split across multiple extents, is included. Another
limitation is that at present truncate(2) will never create sparse files,
since to mark a file sparse we need to modify the directory entry for the
file and we do not implement directory modifications yet.
- The new driver supports write(2) which can both overwrite existing data and
extend the file size so that you can write beyond the existing data. Also,
writing into sparse regions is supported and the holes are filled in with
clusters. But at present only limited support for highly fragmented files,
i.e. ones which have their data attribute split across multiple extents, is
included. Another limitation is that write(2) will never create sparse
files, since to mark a file sparse we need to modify the directory entry for
the file and we do not implement directory modifications yet.
Supported mount options
=======================
In addition to the generic mount options described by the manual page for the
mount command (man 8 mount, also see man 5 fstab), the NTFS driver supports the
following mount options:
======================= =======================================================
iocharset=name Deprecated option. Still supported but please use
nls=name in the future. See description for nls=name.
nls=name Character set to use when returning file names.
Unlike VFAT, NTFS suppresses names that contain
unconvertible characters. Note that most character
sets contain insufficient characters to represent all
possible Unicode characters that can exist on NTFS.
To be sure you are not missing any files, you are
advised to use nls=utf8 which is capable of
representing all Unicode characters.
utf8=<bool> Option no longer supported. Currently mapped to
nls=utf8 but please use nls=utf8 in the future and
make sure utf8 is compiled either as module or into
the kernel. See description for nls=name.
uid=
gid=
umask= Provide default owner, group, and access mode mask.
These options work as documented in mount(8). By
default, the files/directories are owned by root and
he/she has read and write permissions, as well as
browse permission for directories. No one else has any
access permissions. I.e. the mode on all files is by
default rw------- and for directories rwx------, a
consequence of the default fmask=0177 and dmask=0077.
Using a umask of zero will grant all permissions to
everyone, i.e. all files and directories will have mode
rwxrwxrwx.
fmask=
dmask= Instead of specifying umask which applies both to
files and directories, fmask applies only to files and
dmask only to directories.
sloppy=<BOOL> If sloppy is specified, ignore unknown mount options.
Otherwise the default behaviour is to abort mount if
any unknown options are found.
show_sys_files=<BOOL> If show_sys_files is specified, show the system files
in directory listings. Otherwise the default behaviour
is to hide the system files.
Note that even when show_sys_files is specified, "$MFT"
will not be visible due to bugs/mis-features in glibc.
Further, note that irrespective of show_sys_files, all
files are accessible by name, i.e. you can always do
"ls -l \$UpCase" for example to specifically show the
system file containing the Unicode upcase table.
case_sensitive=<BOOL> If case_sensitive is specified, treat all file names as
case sensitive and create file names in the POSIX
namespace. Otherwise the default behaviour is to treat
file names as case insensitive and to create file names
in the WIN32/LONG name space. Note, the Linux NTFS
driver will never create short file names and will
remove them on rename/delete of the corresponding long
file name.
Note that files remain accessible via their short file
name, if it exists. If case_sensitive, you will need
to provide the correct case of the short file name.
disable_sparse=<BOOL> If disable_sparse is specified, creation of sparse
regions, i.e. holes, inside files is disabled for the
volume (for the duration of this mount only). By
default, creation of sparse regions is enabled, which
is consistent with the behaviour of traditional Unix
filesystems.
errors=opt What to do when critical filesystem errors are found.
Following values can be used for "opt":
======== =========================================
continue DEFAULT, try to clean-up as much as
possible, e.g. marking a corrupt inode as
bad so it is no longer accessed, and then
continue.
recover At present only supported is recovery of
the boot sector from the backup copy.
If read-only mount, the recovery is done
in memory only and not written to disk.
======== =========================================
Note that the options are additive, i.e. specifying::
errors=continue,errors=recover
means the driver will attempt to recover and if that
fails it will clean-up as much as possible and
continue.
mft_zone_multiplier= Set the MFT zone multiplier for the volume (this
setting is not persistent across mounts and can be
changed from mount to mount but cannot be changed on
remount). Values of 1 to 4 are allowed, 1 being the
default. The MFT zone multiplier determines how much
space is reserved for the MFT on the volume. If all
other space is used up, then the MFT zone will be
shrunk dynamically, so this has no impact on the
amount of free space. However, it can have an impact
on performance by affecting fragmentation of the MFT.
In general use the default. If you have a lot of small
files then use a higher value. The values have the
following meaning:
===== =================================
Value MFT zone size (% of volume size)
===== =================================
1 12.5%
2 25%
3 37.5%
4 50%
===== =================================
Note this option is irrelevant for read-only mounts.
======================= =======================================================
Known bugs and (mis-)features
=============================
- The link count on each directory inode entry is set to 1, due to Linux not
supporting directory hard links. This may well confuse some user space
applications, since the directory names will have the same inode numbers.
This also speeds up ntfs_read_inode() immensely. And we haven't found any
problems with this approach so far. If you find a problem with this, please
let us know.
Please send bug reports/comments/feedback/abuse to the Linux-NTFS development
list at sourceforge: linux-ntfs-dev@lists.sourceforge.net
Using NTFS volume and stripe sets
=================================
For support of volume and stripe sets, you can either use the kernel's
Device-Mapper driver or the kernel's Software RAID / MD driver. The former is
the recommended one to use for linear raid. But the latter is required for
raid level 5. For striping and mirroring, either driver should work fine.
The Device-Mapper driver
------------------------
You will need to create a table of the components of the volume/stripe set and
how they fit together and load this into the kernel using the dmsetup utility
(see man 8 dmsetup).
Linear volume sets, i.e. linear raid, has been tested and works fine. Even
though untested, there is no reason why stripe sets, i.e. raid level 0, and
mirrors, i.e. raid level 1 should not work, too. Stripes with parity, i.e.
raid level 5, unfortunately cannot work yet because the current version of the
Device-Mapper driver does not support raid level 5. You may be able to use the
Software RAID / MD driver for raid level 5, see the next section for details.
To create the table describing your volume you will need to know each of its
components and their sizes in sectors, i.e. multiples of 512-byte blocks.
For NT4 fault tolerant volumes you can obtain the sizes using fdisk. So for
example if one of your partitions is /dev/hda2 you would do::
$ fdisk -ul /dev/hda
Disk /dev/hda: 81.9 GB, 81964302336 bytes
255 heads, 63 sectors/track, 9964 cylinders, total 160086528 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 63 4209029 2104483+ 83 Linux
/dev/hda2 4209030 37768814 16779892+ 86 NTFS
/dev/hda3 37768815 46170809 4200997+ 83 Linux
And you would know that /dev/hda2 has a size of 37768814 - 4209030 + 1 =
33559785 sectors.
For Win2k and later dynamic disks, you can for example use the ldminfo utility
which is part of the Linux LDM tools (the latest version at the time of
writing is linux-ldm-0.0.8.tar.bz2). You can download it from:
http://www.linux-ntfs.org/
Simply extract the downloaded archive (tar xvjf linux-ldm-0.0.8.tar.bz2), go
into it (cd linux-ldm-0.0.8) and change to the test directory (cd test). You
will find the precompiled (i386) ldminfo utility there. NOTE: You will not be
able to compile this yourself easily so use the binary version!
Then you would use ldminfo in dump mode to obtain the necessary information::
$ ./ldminfo --dump /dev/hda
This would dump the LDM database found on /dev/hda which describes all of your
dynamic disks and all the volumes on them. At the bottom you will see the
VOLUME DEFINITIONS section which is all you really need. You may need to look
further above to determine which of the disks in the volume definitions is
which device in Linux. Hint: Run ldminfo on each of your dynamic disks and
look at the Disk Id close to the top of the output for each (the PRIVATE HEADER
section). You can then find these Disk Ids in the VBLK DATABASE section in the
<Disk> components where you will get the LDM Name for the disk that is found in
the VOLUME DEFINITIONS section.
Note you will also need to enable the LDM driver in the Linux kernel. If your
distribution did not enable it, you will need to recompile the kernel with it
enabled. This will create the LDM partitions on each device at boot time. You
would then use those devices (for /dev/hda they would be /dev/hda1, 2, 3, etc)
in the Device-Mapper table.
You can also bypass using the LDM driver by using the main device (e.g.
/dev/hda) and then using the offsets of the LDM partitions into this device as
the "Start sector of device" when creating the table. Once again ldminfo would
give you the correct information to do this.
Assuming you know all your devices and their sizes things are easy.
For a linear raid the table would look like this (note all values are in
512-byte sectors)::
# Offset into Size of this Raid type Device Start sector
# volume device of device
0 1028161 linear /dev/hda1 0
1028161 3903762 linear /dev/hdb2 0
4931923 2103211 linear /dev/hdc1 0
For a striped volume, i.e. raid level 0, you will need to know the chunk size
you used when creating the volume. Windows uses 64kiB as the default, so it
will probably be this unless you changes the defaults when creating the array.
For a raid level 0 the table would look like this (note all values are in
512-byte sectors)::
# Offset Size Raid Number Chunk 1st Start 2nd Start
# into of the type of size Device in Device in
# volume volume stripes device device
0 2056320 striped 2 128 /dev/hda1 0 /dev/hdb1 0
If there are more than two devices, just add each of them to the end of the
line.
Finally, for a mirrored volume, i.e. raid level 1, the table would look like
this (note all values are in 512-byte sectors)::
# Ofs Size Raid Log Number Region Should Number Source Start Target Start
# in of the type type of log size sync? of Device in Device in
# vol volume params mirrors Device Device
0 2056320 mirror core 2 16 nosync 2 /dev/hda1 0 /dev/hdb1 0
If you are mirroring to multiple devices you can specify further targets at the
end of the line.
Note the "Should sync?" parameter "nosync" means that the two mirrors are
already in sync which will be the case on a clean shutdown of Windows. If the
mirrors are not clean, you can specify the "sync" option instead of "nosync"
and the Device-Mapper driver will then copy the entirety of the "Source Device"
to the "Target Device" or if you specified multiple target devices to all of
them.
Once you have your table, save it in a file somewhere (e.g. /etc/ntfsvolume1),
and hand it over to dmsetup to work with, like so::
$ dmsetup create myvolume1 /etc/ntfsvolume1
You can obviously replace "myvolume1" with whatever name you like.
If it all worked, you will now have the device /dev/device-mapper/myvolume1
which you can then just use as an argument to the mount command as usual to
mount the ntfs volume. For example::
$ mount -t ntfs -o ro /dev/device-mapper/myvolume1 /mnt/myvol1
(You need to create the directory /mnt/myvol1 first and of course you can use
anything you like instead of /mnt/myvol1 as long as it is an existing
directory.)
It is advisable to do the mount read-only to see if the volume has been setup
correctly to avoid the possibility of causing damage to the data on the ntfs
volume.
The Software RAID / MD driver
-----------------------------
An alternative to using the Device-Mapper driver is to use the kernel's
Software RAID / MD driver. For which you need to set up your /etc/raidtab
appropriately (see man 5 raidtab).
Linear volume sets, i.e. linear raid, as well as stripe sets, i.e. raid level
0, have been tested and work fine (though see section "Limitations when using
the MD driver with NTFS volumes" especially if you want to use linear raid).
Even though untested, there is no reason why mirrors, i.e. raid level 1, and
stripes with parity, i.e. raid level 5, should not work, too.
You have to use the "persistent-superblock 0" option for each raid-disk in the
NTFS volume/stripe you are configuring in /etc/raidtab as the persistent
superblock used by the MD driver would damage the NTFS volume.
Windows by default uses a stripe chunk size of 64k, so you probably want the
"chunk-size 64k" option for each raid-disk, too.
For example, if you have a stripe set consisting of two partitions /dev/hda5
and /dev/hdb1 your /etc/raidtab would look like this::
raiddev /dev/md0
raid-level 0
nr-raid-disks 2
nr-spare-disks 0
persistent-superblock 0
chunk-size 64k
device /dev/hda5
raid-disk 0
device /dev/hdb1
raid-disk 1
For linear raid, just change the raid-level above to "raid-level linear", for
mirrors, change it to "raid-level 1", and for stripe sets with parity, change
it to "raid-level 5".
Note for stripe sets with parity you will also need to tell the MD driver
which parity algorithm to use by specifying the option "parity-algorithm
which", where you need to replace "which" with the name of the algorithm to
use (see man 5 raidtab for available algorithms) and you will have to try the
different available algorithms until you find one that works. Make sure you
are working read-only when playing with this as you may damage your data
otherwise. If you find which algorithm works please let us know (email the
linux-ntfs developers list linux-ntfs-dev@lists.sourceforge.net or drop in on
IRC in channel #ntfs on the irc.freenode.net network) so we can update this
documentation.
Once the raidtab is setup, run for example raid0run -a to start all devices or
raid0run /dev/md0 to start a particular md device, in this case /dev/md0.
Then just use the mount command as usual to mount the ntfs volume using for
example::
mount -t ntfs -o ro /dev/md0 /mnt/myntfsvolume
It is advisable to do the mount read-only to see if the md volume has been
setup correctly to avoid the possibility of causing damage to the data on the
ntfs volume.
Limitations when using the Software RAID / MD driver
-----------------------------------------------------
Using the md driver will not work properly if any of your NTFS partitions have
an odd number of sectors. This is especially important for linear raid as all
data after the first partition with an odd number of sectors will be offset by
one or more sectors so if you mount such a partition with write support you
will cause massive damage to the data on the volume which will only become
apparent when you try to use the volume again under Windows.
So when using linear raid, make sure that all your partitions have an even
number of sectors BEFORE attempting to use it. You have been warned!
Even better is to simply use the Device-Mapper for linear raid and then you do
not have this problem with odd numbers of sectors.

16
Documentation/filesystems/vfs.rst
View File

@ -1264,7 +1264,7 @@ defined:
char *(*d_dname)(struct dentry *, char *, int);
struct vfsmount *(*d_automount)(struct path *);
int (*d_manage)(const struct path *, bool);
struct dentry *(*d_real)(struct dentry *, const struct inode *);
struct dentry *(*d_real)(struct dentry *, enum d_real_type type);
};
``d_revalidate``
@ -1419,16 +1419,14 @@ defined:
the dentry being transited from.
``d_real``
overlay/union type filesystems implement this method to return
one of the underlying dentries hidden by the overlay. It is
used in two different modes:
overlay/union type filesystems implement this method to return one
of the underlying dentries of a regular file hidden by the overlay.
Called from file_dentry() it returns the real dentry matching
the inode argument. The real dentry may be from a lower layer
already copied up, but still referenced from the file. This
mode is selected with a non-NULL inode argument.
The 'type' argument takes the values D_REAL_DATA or D_REAL_METADATA
for returning the real underlying dentry that refers to the inode
hosting the file's data or metadata respectively.
With NULL inode the topmost real underlying dentry is returned.
For non-regular files, the 'dentry' argument is returned.
Each dentry has a pointer to its parent dentry, as well as a hash list
of child dentries. Child dentries are basically like files in a

1
Documentation/index.rst
View File

@ -113,7 +113,6 @@ to ReStructured Text format, or are simply too old.
:maxdepth: 1
staging/index
RAS/ras
Translations

2
Documentation/process/changes.rst
View File

@ -31,7 +31,7 @@ you probably needn't concern yourself with pcmciautils.
====================== =============== ========================================
GNU C 5.1 gcc --version
Clang/LLVM (optional) 11.0.0 clang --version
Rust (optional) 1.74.1 rustc --version
Rust (optional) 1.76.0 rustc --version
bindgen (optional) 0.65.1 bindgen --version
GNU make 3.82 make --version
bash 4.2 bash --version

34
Documentation/process/maintainer-tip.rst
View File

@ -304,13 +304,15 @@ following tag ordering scheme:
- Reported-by: ``Reporter <reporter@mail>``
- Closes: ``URL or Message-ID of the bug report this is fixing``
- Originally-by: ``Original author <original-author@mail>``
- Suggested-by: ``Suggester <suggester@mail>``
- Co-developed-by: ``Co-author <co-author@mail>``
Signed-off: ``Co-author <co-author@mail>``
Signed-off-by: ``Co-author <co-author@mail>``
Note, that Co-developed-by and Signed-off-by of the co-author(s) must
come in pairs.
@ -478,7 +480,7 @@ Multi-line comments::
* Larger multi-line comments should be split into paragraphs.
*/
No tail comments:
No tail comments (see below):
Please refrain from using tail comments. Tail comments disturb the
reading flow in almost all contexts, but especially in code::
@ -499,6 +501,34 @@ No tail comments:
/* This magic initialization needs a comment. Maybe not? */
seed = MAGIC_CONSTANT;
Use C++ style, tail comments when documenting structs in headers to
achieve a more compact layout and better readability::
// eax
u32 x2apic_shift : 5, // Number of bits to shift APIC ID right
// for the topology ID at the next level
: 27; // Reserved
// ebx
u32 num_processors : 16, // Number of processors at current level
: 16; // Reserved
versus::
/* eax */
/*
* Number of bits to shift APIC ID right for the topology ID
* at the next level
*/
u32 x2apic_shift : 5,
/* Reserved */
: 27;
/* ebx */
/* Number of processors at current level */
u32 num_processors : 16,
/* Reserved */
: 16;
Comment the important things:
Comments should be added where the operation is not obvious. Documenting

24
Documentation/rust/general-information.rst
View File

@ -77,27 +77,3 @@ configuration:
#[cfg(CONFIG_X="y")] // Enabled as a built-in (`y`)
#[cfg(CONFIG_X="m")] // Enabled as a module (`m`)
#[cfg(not(CONFIG_X))] // Disabled
Testing
-------
There are the tests that come from the examples in the Rust documentation
and get transformed into KUnit tests. These can be run via KUnit. For example
via ``kunit_tool`` (``kunit.py``) on the command line::
./tools/testing/kunit/kunit.py run --make_options LLVM=1 --arch x86_64 --kconfig_add CONFIG_RUST=y
Alternatively, KUnit can run them as kernel built-in at boot. Refer to
Documentation/dev-tools/kunit/index.rst for the general KUnit documentation
and Documentation/dev-tools/kunit/architecture.rst for the details of kernel
built-in vs. command line testing.
Additionally, there are the ``#[test]`` tests. These can be run using
the ``rusttest`` Make target::
make LLVM=1 rusttest
This requires the kernel ``.config`` and downloads external repositories.
It runs the ``#[test]`` tests on the host (currently) and thus is fairly
limited in what these tests can test.

1
Documentation/rust/index.rst
View File

@ -40,6 +40,7 @@ configurations.
general-information
coding-guidelines
arch-support
testing
.. only:: subproject and html

135
Documentation/rust/testing.rst Normal file
View File

@ -0,0 +1,135 @@
.. SPDX-License-Identifier: GPL-2.0
Testing
=======
This document contains useful information how to test the Rust code in the
kernel.
There are two sorts of tests:
- The KUnit tests.
- The ``#[test]`` tests.
The KUnit tests
---------------
These are the tests that come from the examples in the Rust documentation. They
get transformed into KUnit tests.
Usage
*****
These tests can be run via KUnit. For example via ``kunit_tool`` (``kunit.py``)
on the command line::
./tools/testing/kunit/kunit.py run --make_options LLVM=1 --arch x86_64 --kconfig_add CONFIG_RUST=y
Alternatively, KUnit can run them as kernel built-in at boot. Refer to
Documentation/dev-tools/kunit/index.rst for the general KUnit documentation
and Documentation/dev-tools/kunit/architecture.rst for the details of kernel
built-in vs. command line testing.
To use these KUnit doctests, the following must be enabled::
CONFIG_KUNIT
Kernel hacking -> Kernel Testing and Coverage -> KUnit - Enable support for unit tests
CONFIG_RUST_KERNEL_DOCTESTS
Kernel hacking -> Rust hacking -> Doctests for the `kernel` crate
in the kernel config system.
KUnit tests are documentation tests
***********************************
These documentation tests are typically examples of usage of any item (e.g.
function, struct, module...).
They are very convenient because they are just written alongside the
documentation. For instance:
.. code-block:: rust
/// Sums two numbers.
///
/// ```
/// assert_eq!(mymod::f(10, 20), 30);
/// ```
pub fn f(a: i32, b: i32) -> i32 {
a + b
}
In userspace, the tests are collected and run via ``rustdoc``. Using the tool
as-is would be useful already, since it allows verifying that examples compile
(thus enforcing they are kept in sync with the code they document) and as well
as running those that do not depend on in-kernel APIs.
For the kernel, however, these tests get transformed into KUnit test suites.
This means that doctests get compiled as Rust kernel objects, allowing them to
run against a built kernel.
A benefit of this KUnit integration is that Rust doctests get to reuse existing
testing facilities. For instance, the kernel log would look like::
KTAP version 1
1..1
KTAP version 1
# Subtest: rust_doctests_kernel
1..59
# rust_doctest_kernel_build_assert_rs_0.location: rust/kernel/build_assert.rs:13
ok 1 rust_doctest_kernel_build_assert_rs_0
# rust_doctest_kernel_build_assert_rs_1.location: rust/kernel/build_assert.rs:56
ok 2 rust_doctest_kernel_build_assert_rs_1
# rust_doctest_kernel_init_rs_0.location: rust/kernel/init.rs:122
ok 3 rust_doctest_kernel_init_rs_0
...
# rust_doctest_kernel_types_rs_2.location: rust/kernel/types.rs:150
ok 59 rust_doctest_kernel_types_rs_2
# rust_doctests_kernel: pass:59 fail:0 skip:0 total:59
# Totals: pass:59 fail:0 skip:0 total:59
ok 1 rust_doctests_kernel
Tests using the `? <https://doc.rust-lang.org/reference/expressions/operator-expr.html#the-question-mark-operator>`_
operator are also supported as usual, e.g.:
.. code-block:: rust
/// ```
/// # use kernel::{spawn_work_item, workqueue};
/// spawn_work_item!(workqueue::system(), || pr_info!("x"))?;
/// # Ok::<(), Error>(())
/// ```
The tests are also compiled with Clippy under ``CLIPPY=1``, just like normal
code, thus also benefitting from extra linting.
In order for developers to easily see which line of doctest code caused a
failure, a KTAP diagnostic line is printed to the log. This contains the
location (file and line) of the original test (i.e. instead of the location in
the generated Rust file)::
# rust_doctest_kernel_types_rs_2.location: rust/kernel/types.rs:150
Rust tests appear to assert using the usual ``assert!`` and ``assert_eq!``
macros from the Rust standard library (``core``). We provide a custom version
that forwards the call to KUnit instead. Importantly, these macros do not
require passing context, unlike those for KUnit testing (i.e.
``struct kunit *``). This makes them easier to use, and readers of the
documentation do not need to care about which testing framework is used. In
addition, it may allow us to test third-party code more easily in the future.
A current limitation is that KUnit does not support assertions in other tasks.
Thus, we presently simply print an error to the kernel log if an assertion
actually failed. Additionally, doctests are not run for nonpublic functions.
The ``#[test]`` tests
---------------------
Additionally, there are the ``#[test]`` tests. These can be run using the
``rusttest`` Make target::
make LLVM=1 rusttest
This requires the kernel ``.config`` and downloads external repositories. It
runs the ``#[test]`` tests on the host (currently) and thus is fairly limited in
what these tests can test.

3
Documentation/userspace-api/ioctl/ioctl-number.rst
View File

@ -82,8 +82,9 @@ Code Seq# Include File Comments
0x10 00-0F drivers/char/s390/vmcp.h
0x10 10-1F arch/s390/include/uapi/sclp_ctl.h
0x10 20-2F arch/s390/include/uapi/asm/hypfs.h
0x12 all linux/fs.h
0x12 all linux/fs.h BLK* ioctls
linux/blkpg.h
0x15 all linux/fs.h FS_IOC_* ioctls
0x1b all InfiniBand Subsystem
<http://infiniband.sourceforge.net/>
0x20 all drivers/cdrom/cm206.h

52
Documentation/virt/coco/sev-guest.rst
View File

@ -67,6 +67,23 @@ counter (e.g. counter overflow), then -EIO will be returned.
};
};
The host ioctls are issued to a file descriptor of the /dev/sev device.
The ioctl accepts the command ID/input structure documented below.
::
struct sev_issue_cmd {
/* Command ID */
__u32 cmd;
/* Command request structure */
__u64 data;
/* Firmware error code on failure (see psp-sev.h) */
__u32 error;
};
2.1 SNP_GET_REPORT
------------------
@ -124,6 +141,41 @@ be updated with the expected value.
See GHCB specification for further detail on how to parse the certificate blob.
2.4 SNP_PLATFORM_STATUS
-----------------------
:Technology: sev-snp
:Type: hypervisor ioctl cmd
:Parameters (out): struct sev_user_data_snp_status
:Returns (out): 0 on success, -negative on error
The SNP_PLATFORM_STATUS command is used to query the SNP platform status. The
status includes API major, minor version and more. See the SEV-SNP
specification for further details.
2.5 SNP_COMMIT
--------------
:Technology: sev-snp
:Type: hypervisor ioctl cmd
:Returns (out): 0 on success, -negative on error
SNP_COMMIT is used to commit the currently installed firmware using the
SEV-SNP firmware SNP_COMMIT command. This prevents roll-back to a previously
committed firmware version. This will also update the reported TCB to match
that of the currently installed firmware.
2.6 SNP_SET_CONFIG
------------------
:Technology: sev-snp
:Type: hypervisor ioctl cmd
:Parameters (in): struct sev_user_data_snp_config
:Returns (out): 0 on success, -negative on error
SNP_SET_CONFIG is used to set the system-wide configuration such as
reported TCB version in the attestation report. The command is similar
to SNP_CONFIG command defined in the SEV-SNP spec. The current values of
the firmware parameters affected by this command can be queried via
SNP_PLATFORM_STATUS.
3. SEV-SNP CPUID Enforcement
============================

1
Documentation/virt/hyperv/index.rst
View File

@ -10,3 +10,4 @@ Hyper-V Enlightenments
overview
vmbus
clocks
vpci

316
Documentation/virt/hyperv/vpci.rst Normal file
View File

@ -0,0 +1,316 @@
.. SPDX-License-Identifier: GPL-2.0
PCI pass-thru devices
=========================
In a Hyper-V guest VM, PCI pass-thru devices (also called
virtual PCI devices, or vPCI devices) are physical PCI devices
that are mapped directly into the VM's physical address space.
Guest device drivers can interact directly with the hardware
without intermediation by the host hypervisor. This approach
provides higher bandwidth access to the device with lower
latency, compared with devices that are virtualized by the
hypervisor. The device should appear to the guest just as it
would when running on bare metal, so no changes are required
to the Linux device drivers for the device.
Hyper-V terminology for vPCI devices is "Discrete Device
Assignment" (DDA). Public documentation for Hyper-V DDA is
available here: `DDA`_
.. _DDA: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/plan-for-deploying-devices-using-discrete-device-assignment
DDA is typically used for storage controllers, such as NVMe,
and for GPUs. A similar mechanism for NICs is called SR-IOV
and produces the same benefits by allowing a guest device
driver to interact directly with the hardware. See Hyper-V
public documentation here: `SR-IOV`_
.. _SR-IOV: https://learn.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-single-root-i-o-virtualization--sr-iov-
This discussion of vPCI devices includes DDA and SR-IOV
devices.
Device Presentation
-------------------
Hyper-V provides full PCI functionality for a vPCI device when
it is operating, so the Linux device driver for the device can
be used unchanged, provided it uses the correct Linux kernel
APIs for accessing PCI config space and for other integration
with Linux. But the initial detection of the PCI device and
its integration with the Linux PCI subsystem must use Hyper-V
specific mechanisms. Consequently, vPCI devices on Hyper-V
have a dual identity. They are initially presented to Linux
guests as VMBus devices via the standard VMBus "offer"
mechanism, so they have a VMBus identity and appear under
/sys/bus/vmbus/devices. The VMBus vPCI driver in Linux at
drivers/pci/controller/pci-hyperv.c handles a newly introduced
vPCI device by fabricating a PCI bus topology and creating all
the normal PCI device data structures in Linux that would
exist if the PCI device were discovered via ACPI on a bare-
metal system. Once those data structures are set up, the
device also has a normal PCI identity in Linux, and the normal
Linux device driver for the vPCI device can function as if it
were running in Linux on bare-metal. Because vPCI devices are
presented dynamically through the VMBus offer mechanism, they
do not appear in the Linux guest's ACPI tables. vPCI devices
may be added to a VM or removed from a VM at any time during
the life of the VM, and not just during initial boot.
With this approach, the vPCI device is a VMBus device and a
PCI device at the same time. In response to the VMBus offer
message, the hv_pci_probe() function runs and establishes a
VMBus connection to the vPCI VSP on the Hyper-V host. That
connection has a single VMBus channel. The channel is used to
exchange messages with the vPCI VSP for the purpose of setting
up and configuring the vPCI device in Linux. Once the device
is fully configured in Linux as a PCI device, the VMBus
channel is used only if Linux changes the vCPU to be interrupted
in the guest, or if the vPCI device is removed from
the VM while the VM is running. The ongoing operation of the
device happens directly between the Linux device driver for
the device and the hardware, with VMBus and the VMBus channel
playing no role.
PCI Device Setup
----------------
PCI device setup follows a sequence that Hyper-V originally
created for Windows guests, and that can be ill-suited for
Linux guests due to differences in the overall structure of
the Linux PCI subsystem compared with Windows. Nonetheless,
with a bit of hackery in the Hyper-V virtual PCI driver for
Linux, the virtual PCI device is setup in Linux so that
generic Linux PCI subsystem code and the Linux driver for the
device "just work".
Each vPCI device is set up in Linux to be in its own PCI
domain with a host bridge. The PCI domainID is derived from
bytes 4 and 5 of the instance GUID assigned to the VMBus vPCI
device. The Hyper-V host does not guarantee that these bytes
are unique, so hv_pci_probe() has an algorithm to resolve
collisions. The collision resolution is intended to be stable
across reboots of the same VM so that the PCI domainIDs don't
change, as the domainID appears in the user space
configuration of some devices.
hv_pci_probe() allocates a guest MMIO range to be used as PCI
config space for the device. This MMIO range is communicated
to the Hyper-V host over the VMBus channel as part of telling
the host that the device is ready to enter d0. See
hv_pci_enter_d0(). When the guest subsequently accesses this
MMIO range, the Hyper-V host intercepts the accesses and maps
them to the physical device PCI config space.
hv_pci_probe() also gets BAR information for the device from
the Hyper-V host, and uses this information to allocate MMIO
space for the BARs. That MMIO space is then setup to be
associated with the host bridge so that it works when generic
PCI subsystem code in Linux processes the BARs.
Finally, hv_pci_probe() creates the root PCI bus. At this
point the Hyper-V virtual PCI driver hackery is done, and the
normal Linux PCI machinery for scanning the root bus works to
detect the device, to perform driver matching, and to
initialize the driver and device.
PCI Device Removal
------------------
A Hyper-V host may initiate removal of a vPCI device from a
guest VM at any time during the life of the VM. The removal
is instigated by an admin action taken on the Hyper-V host and
is not under the control of the guest OS.
A guest VM is notified of the removal by an unsolicited
"Eject" message sent from the host to the guest over the VMBus
channel associated with the vPCI device. Upon receipt of such
a message, the Hyper-V virtual PCI driver in Linux
asynchronously invokes Linux kernel PCI subsystem calls to
shutdown and remove the device. When those calls are
complete, an "Ejection Complete" message is sent back to
Hyper-V over the VMBus channel indicating that the device has
been removed. At this point, Hyper-V sends a VMBus rescind
message to the Linux guest, which the VMBus driver in Linux
processes by removing the VMBus identity for the device. Once
that processing is complete, all vestiges of the device having
been present are gone from the Linux kernel. The rescind
message also indicates to the guest that Hyper-V has stopped
providing support for the vPCI device in the guest. If the
guest were to attempt to access that device's MMIO space, it
would be an invalid reference. Hypercalls affecting the device
return errors, and any further messages sent in the VMBus
channel are ignored.
After sending the Eject message, Hyper-V allows the guest VM
60 seconds to cleanly shutdown the device and respond with
Ejection Complete before sending the VMBus rescind
message. If for any reason the Eject steps don't complete
within the allowed 60 seconds, the Hyper-V host forcibly
performs the rescind steps, which will likely result in
cascading errors in the guest because the device is now no
longer present from the guest standpoint and accessing the
device MMIO space will fail.
Because ejection is asynchronous and can happen at any point
during the guest VM lifecycle, proper synchronization in the
Hyper-V virtual PCI driver is very tricky. Ejection has been
observed even before a newly offered vPCI device has been
fully setup. The Hyper-V virtual PCI driver has been updated
several times over the years to fix race conditions when
ejections happen at inopportune times. Care must be taken when
modifying this code to prevent re-introducing such problems.
See comments in the code.
Interrupt Assignment
--------------------
The Hyper-V virtual PCI driver supports vPCI devices using
MSI, multi-MSI, or MSI-X. Assigning the guest vCPU that will
receive the interrupt for a particular MSI or MSI-X message is
complex because of the way the Linux setup of IRQs maps onto
the Hyper-V interfaces. For the single-MSI and MSI-X cases,
Linux calls hv_compse_msi_msg() twice, with the first call
containing a dummy vCPU and the second call containing the
real vCPU. Furthermore, hv_irq_unmask() is finally called
(on x86) or the GICD registers are set (on arm64) to specify
the real vCPU again. Each of these three calls interact
with Hyper-V, which must decide which physical CPU should
receive the interrupt before it is forwarded to the guest VM.
Unfortunately, the Hyper-V decision-making process is a bit
limited, and can result in concentrating the physical
interrupts on a single CPU, causing a performance bottleneck.
See details about how this is resolved in the extensive
comment above the function hv_compose_msi_req_get_cpu().
The Hyper-V virtual PCI driver implements the
irq_chip.irq_compose_msi_msg function as hv_compose_msi_msg().
Unfortunately, on Hyper-V the implementation requires sending
a VMBus message to the Hyper-V host and awaiting an interrupt
indicating receipt of a reply message. Since
irq_chip.irq_compose_msi_msg can be called with IRQ locks
held, it doesn't work to do the normal sleep until awakened by
the interrupt. Instead hv_compose_msi_msg() must send the
VMBus message, and then poll for the completion message. As
further complexity, the vPCI device could be ejected/rescinded
while the polling is in progress, so this scenario must be
detected as well. See comments in the code regarding this
very tricky area.
Most of the code in the Hyper-V virtual PCI driver (pci-
hyperv.c) applies to Hyper-V and Linux guests running on x86
and on arm64 architectures. But there are differences in how
interrupt assignments are managed. On x86, the Hyper-V
virtual PCI driver in the guest must make a hypercall to tell
Hyper-V which guest vCPU should be interrupted by each
MSI/MSI-X interrupt, and the x86 interrupt vector number that
the x86_vector IRQ domain has picked for the interrupt. This
hypercall is made by hv_arch_irq_unmask(). On arm64, the
Hyper-V virtual PCI driver manages the allocation of an SPI
for each MSI/MSI-X interrupt. The Hyper-V virtual PCI driver
stores the allocated SPI in the architectural GICD registers,
which Hyper-V emulates, so no hypercall is necessary as with
x86. Hyper-V does not support using LPIs for vPCI devices in
arm64 guest VMs because it does not emulate a GICv3 ITS.
The Hyper-V virtual PCI driver in Linux supports vPCI devices
whose drivers create managed or unmanaged Linux IRQs. If the
smp_affinity for an unmanaged IRQ is updated via the /proc/irq
interface, the Hyper-V virtual PCI driver is called to tell
the Hyper-V host to change the interrupt targeting and
everything works properly. However, on x86 if the x86_vector
IRQ domain needs to reassign an interrupt vector due to
running out of vectors on a CPU, there's no path to inform the
Hyper-V host of the change, and things break. Fortunately,
guest VMs operate in a constrained device environment where
using all the vectors on a CPU doesn't happen. Since such a
problem is only a theoretical concern rather than a practical
concern, it has been left unaddressed.
DMA
---
By default, Hyper-V pins all guest VM memory in the host
when the VM is created, and programs the physical IOMMU to
allow the VM to have DMA access to all its memory. Hence
it is safe to assign PCI devices to the VM, and allow the
guest operating system to program the DMA transfers. The
physical IOMMU prevents a malicious guest from initiating
DMA to memory belonging to the host or to other VMs on the
host. From the Linux guest standpoint, such DMA transfers
are in "direct" mode since Hyper-V does not provide a virtual
IOMMU in the guest.
Hyper-V assumes that physical PCI devices always perform
cache-coherent DMA. When running on x86, this behavior is
required by the architecture. When running on arm64, the
architecture allows for both cache-coherent and
non-cache-coherent devices, with the behavior of each device
specified in the ACPI DSDT. But when a PCI device is assigned
to a guest VM, that device does not appear in the DSDT, so the
Hyper-V VMBus driver propagates cache-coherency information
from the VMBus node in the ACPI DSDT to all VMBus devices,
including vPCI devices (since they have a dual identity as a VMBus
device and as a PCI device). See vmbus_dma_configure().
Current Hyper-V versions always indicate that the VMBus is
cache coherent, so vPCI devices on arm64 always get marked as
cache coherent and the CPU does not perform any sync
operations as part of dma_map/unmap_*() calls.
vPCI protocol versions
----------------------
As previously described, during vPCI device setup and teardown
messages are passed over a VMBus channel between the Hyper-V
host and the Hyper-v vPCI driver in the Linux guest. Some
messages have been revised in newer versions of Hyper-V, so
the guest and host must agree on the vPCI protocol version to
be used. The version is negotiated when communication over
the VMBus channel is first established. See
hv_pci_protocol_negotiation(). Newer versions of the protocol
extend support to VMs with more than 64 vCPUs, and provide
additional information about the vPCI device, such as the
guest virtual NUMA node to which it is most closely affined in
the underlying hardware.
Guest NUMA node affinity
------------------------
When the vPCI protocol version provides it, the guest NUMA
node affinity of the vPCI device is stored as part of the Linux
device information for subsequent use by the Linux driver. See
hv_pci_assign_numa_node(). If the negotiated protocol version
does not support the host providing NUMA affinity information,
the Linux guest defaults the device NUMA node to 0. But even
when the negotiated protocol version includes NUMA affinity
information, the ability of the host to provide such
information depends on certain host configuration options. If
the guest receives NUMA node value "0", it could mean NUMA
node 0, or it could mean "no information is available".
Unfortunately it is not possible to distinguish the two cases
from the guest side.
PCI config space access in a CoCo VM
------------------------------------
Linux PCI device drivers access PCI config space using a
standard set of functions provided by the Linux PCI subsystem.
In Hyper-V guests these standard functions map to functions
hv_pcifront_read_config() and hv_pcifront_write_config()
in the Hyper-V virtual PCI driver. In normal VMs,
these hv_pcifront_*() functions directly access the PCI config
space, and the accesses trap to Hyper-V to be handled.
But in CoCo VMs, memory encryption prevents Hyper-V
from reading the guest instruction stream to emulate the
access, so the hv_pcifront_*() functions must invoke
hypercalls with explicit arguments describing the access to be
made.
Config Block back-channel
-------------------------
The Hyper-V host and Hyper-V virtual PCI driver in Linux
together implement a non-standard back-channel communication
path between the host and guest. The back-channel path uses
messages sent over the VMBus channel associated with the vPCI
device. The functions hyperv_read_cfg_blk() and
hyperv_write_cfg_blk() are the primary interfaces provided to
other parts of the Linux kernel. As of this writing, these
interfaces are used only by the Mellanox mlx5 driver to pass
diagnostic data to a Hyper-V host running in the Azure public
cloud. The functions hyperv_read_cfg_blk() and
hyperv_write_cfg_blk() are implemented in a separate module
(pci-hyperv-intf.c, under CONFIG_PCI_HYPERV_INTERFACE) that
effectively stubs them out when running in non-Hyper-V
environments.

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

@ -8791,6 +8791,11 @@ means the VM type with value @n is supported. Possible values of @n are::
#define KVM_X86_DEFAULT_VM 0
#define KVM_X86_SW_PROTECTED_VM 1
Note, KVM_X86_SW_PROTECTED_VM is currently only for development and testing.
Do not use KVM_X86_SW_PROTECTED_VM for "real" VMs, and especially not in
production. The behavior and effective ABI for software-protected VMs is
unstable.
9. Known KVM API problems
=========================

102
MAINTAINERS
View File

@ -897,6 +897,12 @@ Q: https://patchwork.kernel.org/project/linux-rdma/list/
F: drivers/infiniband/hw/efa/
F: include/uapi/rdma/efa-abi.h
AMD ADDRESS TRANSLATION LIBRARY (ATL)
M: Yazen Ghannam <Yazen.Ghannam@amd.com>
L: linux-edac@vger.kernel.org
S: Supported
F: drivers/ras/amd/atl/*
AMD AXI W1 DRIVER
M: Kris Chaplin <kris.chaplin@amd.com>
R: Thomas Delev <thomas.delev@amd.com>
@ -2157,7 +2163,7 @@ M: Shawn Guo <shawnguo@kernel.org>
M: Sascha Hauer <s.hauer@pengutronix.de>
R: Pengutronix Kernel Team <kernel@pengutronix.de>
R: Fabio Estevam <festevam@gmail.com>
R: NXP Linux Team <linux-imx@nxp.com>
L: imx@lists.linux.dev
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git
@ -2543,13 +2549,14 @@ F: drivers/*/*/*wpcm*
F: drivers/*/*wpcm*
ARM/NXP S32G ARCHITECTURE
M: Chester Lin <chester62515@gmail.com>
R: Andreas Färber <afaerber@suse.de>
R: Chester Lin <chester62515@gmail.com>
R: Matthias Brugger <mbrugger@suse.com>
R: NXP S32 Linux Team <s32@nxp.com>
R: Ghennadi Procopciuc <ghennadi.procopciuc@oss.nxp.com>
L: NXP S32 Linux Team <s32@nxp.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm64/boot/dts/freescale/s32g*.dts*
F: drivers/pinctrl/nxp/
ARM/Orion SoC/Technologic Systems TS-78xx platform support
M: Alexander Clouter <alex@digriz.org.uk>
@ -7583,7 +7590,6 @@ R: Robert Richter <rric@kernel.org>
L: linux-edac@vger.kernel.org
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git edac-for-next
F: Documentation/admin-guide/ras.rst
F: Documentation/driver-api/edac.rst
F: drivers/edac/
F: include/linux/edac.h
@ -8496,7 +8502,7 @@ FREESCALE IMX / MXC FEC DRIVER
M: Wei Fang <wei.fang@nxp.com>
R: Shenwei Wang <shenwei.wang@nxp.com>
R: Clark Wang <xiaoning.wang@nxp.com>
R: NXP Linux Team <linux-imx@nxp.com>
L: imx@lists.linux.dev
L: netdev@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/net/fsl,fec.yaml
@ -8531,7 +8537,7 @@ F: drivers/i2c/busses/i2c-imx.c
FREESCALE IMX LPI2C DRIVER
M: Dong Aisheng <aisheng.dong@nxp.com>
L: linux-i2c@vger.kernel.org
L: linux-imx@nxp.com
L: imx@lists.linux.dev
S: Maintained
F: Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
F: drivers/i2c/busses/i2c-imx-lpi2c.c
@ -9086,6 +9092,7 @@ F: Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
F: arch/arm64/boot/dts/exynos/google/
F: drivers/clk/samsung/clk-gs101.c
F: include/dt-bindings/clock/google,gs101.h
K: [gG]oogle.?[tT]ensor
GPD POCKET FAN DRIVER
M: Hans de Goede <hdegoede@redhat.com>
@ -10477,7 +10484,8 @@ M: Donald Robson <donald.robson@imgtec.com>
M: Matt Coster <matt.coster@imgtec.com>
S: Supported
T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/gpu/img,powervr.yaml
F: Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
F: Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
F: Documentation/gpu/imagination/
F: drivers/gpu/drm/imagination/
F: include/uapi/drm/pvr_drm.h
@ -10735,7 +10743,7 @@ INTEL DRM I915 DRIVER (Meteor Lake, DG2 and older excluding Poulsbo, Moorestown
M: Jani Nikula <jani.nikula@linux.intel.com>
M: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
M: Rodrigo Vivi <rodrigo.vivi@intel.com>
M: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
M: Tvrtko Ursulin <tursulin@ursulin.net>
L: intel-gfx@lists.freedesktop.org
S: Supported
W: https://drm.pages.freedesktop.org/intel-docs/
@ -11157,6 +11165,16 @@ L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/wwan/iosm/
INTEL(R) FLEXIBLE RETURN AND EVENT DELIVERY
M: Xin Li <xin@zytor.com>
M: "H. Peter Anvin" <hpa@zytor.com>
S: Supported
F: Documentation/arch/x86/x86_64/fred.rst
F: arch/x86/entry/entry_64_fred.S
F: arch/x86/entry/entry_fred.c
F: arch/x86/include/asm/fred.h
F: arch/x86/kernel/fred.c
INTEL(R) TRACE HUB
M: Alexander Shishkin <alexander.shishkin@linux.intel.com>
S: Supported
@ -12517,7 +12535,6 @@ F: arch/powerpc/include/asm/livepatch.h
F: include/linux/livepatch.h
F: kernel/livepatch/
F: kernel/module/livepatch.c
F: lib/livepatch/
F: samples/livepatch/
F: tools/testing/selftests/livepatch/
@ -15590,16 +15607,6 @@ W: https://github.com/davejiang/linux/wiki
T: git https://github.com/davejiang/linux.git
F: drivers/ntb/hw/intel/
NTFS FILESYSTEM
M: Anton Altaparmakov <anton@tuxera.com>
R: Namjae Jeon <linkinjeon@kernel.org>
L: linux-ntfs-dev@lists.sourceforge.net
S: Supported
W: http://www.tuxera.com/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/aia21/ntfs.git
F: Documentation/filesystems/ntfs.rst
F: fs/ntfs/
NTFS3 FILESYSTEM
M: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
L: ntfs3@lists.linux.dev
@ -15728,7 +15735,7 @@ F: drivers/iio/gyro/fxas21002c_spi.c
NXP i.MX 7D/6SX/6UL/93 AND VF610 ADC DRIVER
M: Haibo Chen <haibo.chen@nxp.com>
L: linux-iio@vger.kernel.org
L: linux-imx@nxp.com
L: imx@lists.linux.dev
S: Maintained
F: Documentation/devicetree/bindings/iio/adc/fsl,imx7d-adc.yaml
F: Documentation/devicetree/bindings/iio/adc/fsl,vf610-adc.yaml
@ -15765,7 +15772,7 @@ F: drivers/gpu/drm/imx/dcss/
NXP i.MX 8QXP ADC DRIVER
M: Cai Huoqing <cai.huoqing@linux.dev>
M: Haibo Chen <haibo.chen@nxp.com>
L: linux-imx@nxp.com
L: imx@lists.linux.dev
L: linux-iio@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/iio/adc/nxp,imx8qxp-adc.yaml
@ -15773,7 +15780,7 @@ F: drivers/iio/adc/imx8qxp-adc.c
NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER
M: Mirela Rabulea <mirela.rabulea@nxp.com>
R: NXP Linux Team <linux-imx@nxp.com>
L: imx@lists.linux.dev
L: linux-media@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
@ -15783,7 +15790,7 @@ NXP i.MX CLOCK DRIVERS
M: Abel Vesa <abelvesa@kernel.org>
R: Peng Fan <peng.fan@nxp.com>
L: linux-clk@vger.kernel.org
L: linux-imx@nxp.com
L: imx@lists.linux.dev
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/abelvesa/linux.git clk/imx
F: Documentation/devicetree/bindings/clock/imx*
@ -17284,9 +17291,12 @@ M: Shawn Guo <shawnguo@kernel.org>
M: Jacky Bai <ping.bai@nxp.com>
R: Pengutronix Kernel Team <kernel@pengutronix.de>
L: linux-gpio@vger.kernel.org
L: NXP S32 Linux Team <s32@nxp.com>
S: Maintained
F: Documentation/devicetree/bindings/pinctrl/fsl,*
F: Documentation/devicetree/bindings/pinctrl/nxp,s32*
F: drivers/pinctrl/freescale/
F: drivers/pinctrl/nxp/
PIN CONTROLLER - INTEL
M: Mika Westerberg <mika.westerberg@linux.intel.com>
@ -17340,14 +17350,6 @@ S: Supported
F: drivers/gpio/gpio-sama5d2-piobu.c
F: drivers/pinctrl/pinctrl-at91*
PIN CONTROLLER - NXP S32
M: Chester Lin <clin@suse.com>
R: NXP S32 Linux Team <s32@nxp.com>
L: linux-gpio@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/pinctrl/nxp,s32*
F: drivers/pinctrl/nxp/
PIN CONTROLLER - QUALCOMM
M: Bjorn Andersson <andersson@kernel.org>
L: linux-arm-msm@vger.kernel.org
@ -17364,7 +17366,6 @@ F: Documentation/devicetree/bindings/pinctrl/renesas,*
F: drivers/pinctrl/renesas/
PIN CONTROLLER - SAMSUNG
M: Tomasz Figa <tomasz.figa@gmail.com>
M: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
M: Sylwester Nawrocki <s.nawrocki@samsung.com>
R: Alim Akhtar <alim.akhtar@samsung.com>
@ -17514,6 +17515,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
F: fs/timerfd.c
F: include/linux/time_namespace.h
F: include/linux/timer*
F: include/trace/events/timer*
F: kernel/time/*timer*
F: kernel/time/namespace.c
@ -17550,6 +17552,7 @@ F: Documentation/devicetree/bindings/power/supply/
F: drivers/power/supply/
F: include/linux/power/
F: include/linux/power_supply.h
F: tools/testing/selftests/power_supply/
POWERNV OPERATOR PANEL LCD DISPLAY DRIVER
M: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
@ -18378,11 +18381,17 @@ M: Tony Luck <tony.luck@intel.com>
M: Borislav Petkov <bp@alien8.de>
L: linux-edac@vger.kernel.org
S: Maintained
F: Documentation/admin-guide/ras.rst
F: Documentation/admin-guide/RAS
F: drivers/ras/
F: include/linux/ras.h
F: include/ras/ras_event.h
RAS FRU MEMORY POISON MANAGER (FMPM)
M: Yazen Ghannam <Yazen.Ghannam@amd.com>
L: linux-edac@vger.kernel.org
S: Maintained
F: drivers/ras/amd/fmpm.c
RC-CORE / LIRC FRAMEWORK
M: Sean Young <sean@mess.org>
L: linux-media@vger.kernel.org
@ -18872,6 +18881,7 @@ 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/
RISC-V PMU DRIVERS
M: Atish Patra <atishp@atishpatra.org>
@ -19120,6 +19130,7 @@ F: Documentation/rust/
F: rust/
F: samples/rust/
F: scripts/*rust*
F: tools/testing/selftests/rust/
K: \b(?i:rust)\b
RXRPC SOCKETS (AF_RXRPC)
@ -19413,7 +19424,6 @@ F: drivers/media/platform/samsung/exynos4-is/
SAMSUNG SOC CLOCK DRIVERS
M: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
M: Sylwester Nawrocki <s.nawrocki@samsung.com>
M: Tomasz Figa <tomasz.figa@gmail.com>
M: Chanwoo Choi <cw00.choi@samsung.com>
R: Alim Akhtar <alim.akhtar@samsung.com>
L: linux-samsung-soc@vger.kernel.org
@ -19655,7 +19665,7 @@ F: drivers/mmc/host/sdhci-of-at91.c
SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) NXP i.MX DRIVER
M: Haibo Chen <haibo.chen@nxp.com>
L: linux-imx@nxp.com
L: imx@lists.linux.dev
L: linux-mmc@vger.kernel.org
S: Maintained
F: drivers/mmc/host/sdhci-esdhc-imx.c
@ -20207,8 +20217,8 @@ F: Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml
F: drivers/net/ethernet/socionext/sni_ave.c
SOCIONEXT (SNI) NETSEC NETWORK DRIVER
M: Jassi Brar <jaswinder.singh@linaro.org>
M: Ilias Apalodimas <ilias.apalodimas@linaro.org>
M: Masahisa Kojima <kojima.masahisa@socionext.com>
L: netdev@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/net/socionext,synquacer-netsec.yaml
@ -20449,12 +20459,13 @@ F: drivers/char/sonypi.c
F: drivers/platform/x86/sony-laptop.c
F: include/linux/sony-laptop.h
SOPHGO DEVICETREES
M: Chao Wei <chao.wei@sophgo.com>
SOPHGO DEVICETREES and DRIVERS
M: Chen Wang <unicorn_wang@outlook.com>
M: Inochi Amaoto <inochiama@outlook.com>
T: git https://github.com/sophgo/linux.git
S: Maintained
F: arch/riscv/boot/dts/sophgo/
F: Documentation/devicetree/bindings/riscv/sophgo.yaml
N: sophgo
K: sophgo
SOUND
M: Jaroslav Kysela <perex@perex.cz>
@ -20961,6 +20972,12 @@ F: Documentation/devicetree/bindings/phy/starfive,jh7110-usb-phy.yaml
F: drivers/phy/starfive/phy-jh7110-pcie.c
F: drivers/phy/starfive/phy-jh7110-usb.c
STARFIVE JH8100 EXTERNAL INTERRUPT CONTROLLER DRIVER
M: Changhuang Liang <changhuang.liang@starfivetech.com>
S: Supported
F: Documentation/devicetree/bindings/interrupt-controller/starfive,jh8100-intc.yaml
F: drivers/irqchip/irq-starfive-jh8100-intc.c
STATIC BRANCH/CALL
M: Peter Zijlstra <peterz@infradead.org>
M: Josh Poimboeuf <jpoimboe@kernel.org>
@ -21326,6 +21343,7 @@ F: drivers/clk/clk-sc[mp]i.c
F: drivers/cpufreq/sc[mp]i-cpufreq.c
F: drivers/firmware/arm_scmi/
F: drivers/firmware/arm_scpi.c
F: drivers/hwmon/scmi-hwmon.c
F: drivers/pmdomain/arm/
F: drivers/powercap/arm_scmi_powercap.c
F: drivers/regulator/scmi-regulator.c
@ -24137,7 +24155,7 @@ F: Documentation/devicetree/bindings/net/can/xilinx,can.yaml
F: drivers/net/can/xilinx_can.c
XILINX EVENT MANAGEMENT DRIVER
M: Abhyuday Godhasara <abhyuday.godhasara@xilinx.com>
M: Michal Simek <michal.simek@amd.com>
S: Maintained
F: drivers/soc/xilinx/xlnx_event_manager.c
F: include/linux/firmware/xlnx-event-manager.h

6
Makefile
View File

@ -2,7 +2,7 @@
VERSION = 6
PATCHLEVEL = 8
SUBLEVEL = 0
EXTRAVERSION = -rc7
EXTRAVERSION =
NAME = Hurr durr I'ma ninja sloth
# *DOCUMENTATION*
@ -1201,7 +1201,7 @@ prepare0: archprepare
# All the preparing..
prepare: prepare0
ifdef CONFIG_RUST
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/rust_is_available.sh
+$(Q)$(CONFIG_SHELL) $(srctree)/scripts/rust_is_available.sh
$(Q)$(MAKE) $(build)=rust
endif
@ -1711,7 +1711,7 @@ $(DOC_TARGETS):
# "Is Rust available?" target
PHONY += rustavailable
rustavailable:
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/rust_is_available.sh && echo "Rust is available!"
+$(Q)$(CONFIG_SHELL) $(srctree)/scripts/rust_is_available.sh && echo "Rust is available!"
# Documentation target
#

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