Merge 8815da98e0 ("Merge tag 'docs-6.10' of git://git.lwn.net/linux") into android-mainline
Steps on the way to 6.10-rc1 Change-Id: I6b3d58454b958b6d0ea518c821cba45ad8abd26f Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This commit is contained in:
Greg Kroah-Hartman
@@ -133,6 +133,7 @@ Bryan Tan <bryan-bt.tan@broadcom.com> <bryantan@vmware.com>
|
||||
Cai Huoqing <cai.huoqing@linux.dev> <caihuoqing@baidu.com>
|
||||
Can Guo <quic_cang@quicinc.com> <cang@codeaurora.org>
|
||||
Carl Huang <quic_cjhuang@quicinc.com> <cjhuang@codeaurora.org>
|
||||
Carlos Bilbao <carlos.bilbao.osdev@gmail.com> <carlos.bilbao@amd.com>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
|
||||
Chao Yu <chao@kernel.org> <chao2.yu@samsung.com>
|
||||
@@ -467,7 +468,8 @@ Nadia Yvette Chambers <nyc@holomorphy.com> William Lee Irwin III <wli@holomorphy
|
||||
Naoya Horiguchi <nao.horiguchi@gmail.com> <n-horiguchi@ah.jp.nec.com>
|
||||
Naoya Horiguchi <nao.horiguchi@gmail.com> <naoya.horiguchi@nec.com>
|
||||
Nathan Chancellor <nathan@kernel.org> <natechancellor@gmail.com>
|
||||
Neeraj Upadhyay <quic_neeraju@quicinc.com> <neeraju@codeaurora.org>
|
||||
Neeraj Upadhyay <neeraj.upadhyay@kernel.org> <quic_neeraju@quicinc.com>
|
||||
Neeraj Upadhyay <neeraj.upadhyay@kernel.org> <neeraju@codeaurora.org>
|
||||
Neil Armstrong <neil.armstrong@linaro.org> <narmstrong@baylibre.com>
|
||||
Nguyen Anh Quynh <aquynh@gmail.com>
|
||||
Nicholas Piggin <npiggin@gmail.com> <npiggen@suse.de>
|
||||
|
||||
@@ -28,6 +28,10 @@ BUILDDIR = $(obj)/output
|
||||
PDFLATEX = xelatex
|
||||
LATEXOPTS = -interaction=batchmode -no-shell-escape
|
||||
|
||||
# For denylisting "variable font" files
|
||||
# Can be overridden by setting as an env variable
|
||||
FONTS_CONF_DENY_VF ?= $(HOME)/deny-vf
|
||||
|
||||
ifeq ($(findstring 1, $(KBUILD_VERBOSE)),)
|
||||
SPHINXOPTS += "-q"
|
||||
endif
|
||||
@@ -151,10 +155,11 @@ pdfdocs:
|
||||
|
||||
else # HAVE_PDFLATEX
|
||||
|
||||
pdfdocs: DENY_VF = XDG_CONFIG_HOME=$(FONTS_CONF_DENY_VF)
|
||||
pdfdocs: latexdocs
|
||||
@$(srctree)/scripts/sphinx-pre-install --version-check
|
||||
$(foreach var,$(SPHINXDIRS), \
|
||||
$(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" -C $(BUILDDIR)/$(var)/latex || exit; \
|
||||
$(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" $(DENY_VF) -C $(BUILDDIR)/$(var)/latex || sh $(srctree)/scripts/check-variable-fonts.sh || exit; \
|
||||
mkdir -p $(BUILDDIR)/$(var)/pdf; \
|
||||
mv $(subst .tex,.pdf,$(wildcard $(BUILDDIR)/$(var)/latex/*.tex)) $(BUILDDIR)/$(var)/pdf/; \
|
||||
)
|
||||
|
||||
@@ -427,7 +427,7 @@ their assorted primitives.
|
||||
|
||||
This section shows a simple use of the core RCU API to protect a
|
||||
global pointer to a dynamically allocated structure. More-typical
|
||||
uses of RCU may be found in listRCU.rst, arrayRCU.rst, and NMI-RCU.rst.
|
||||
uses of RCU may be found in listRCU.rst and NMI-RCU.rst.
|
||||
::
|
||||
|
||||
struct foo {
|
||||
@@ -510,8 +510,8 @@ So, to sum up:
|
||||
data item.
|
||||
|
||||
See checklist.rst for additional rules to follow when using RCU.
|
||||
And again, more-typical uses of RCU may be found in listRCU.rst,
|
||||
arrayRCU.rst, and NMI-RCU.rst.
|
||||
And again, more-typical uses of RCU may be found in listRCU.rst
|
||||
and NMI-RCU.rst.
|
||||
|
||||
.. _4_whatisRCU:
|
||||
|
||||
|
||||
@@ -1572,6 +1572,15 @@ PAGE_SIZE multiple when read back.
|
||||
pglazyfreed (npn)
|
||||
Amount of reclaimed lazyfree pages
|
||||
|
||||
zswpin
|
||||
Number of pages moved in to memory from zswap.
|
||||
|
||||
zswpout
|
||||
Number of pages moved out of memory to zswap.
|
||||
|
||||
zswpwb
|
||||
Number of pages written from zswap to swap.
|
||||
|
||||
thp_fault_alloc (npn)
|
||||
Number of transparent hugepages which were allocated to satisfy
|
||||
a page fault. This counter is not present when CONFIG_TRANSPARENT_HUGEPAGE
|
||||
|
||||
@@ -67,8 +67,8 @@ arg4:
|
||||
will be performed for all tasks in the task group of ``pid``.
|
||||
|
||||
arg5:
|
||||
userspace pointer to an unsigned long for storing the cookie returned by
|
||||
``PR_SCHED_CORE_GET`` command. Should be 0 for all other commands.
|
||||
userspace pointer to an unsigned long long for storing the cookie returned
|
||||
by ``PR_SCHED_CORE_GET`` command. Should be 0 for all other commands.
|
||||
|
||||
In order for a process to push a cookie to, or pull a cookie from a process, it
|
||||
is required to have the ptrace access mode: `PTRACE_MODE_READ_REALCREDS` to the
|
||||
|
||||
@@ -135,7 +135,7 @@ and does not want to suffer the performance impact, one can always
|
||||
disable the mitigation with spec_rstack_overflow=off.
|
||||
|
||||
Similarly, 'Mitigation: IBPB' is another full mitigation type employing
|
||||
an indrect branch prediction barrier after having applied the required
|
||||
an indirect branch prediction barrier after having applied the required
|
||||
microcode patch for one's system. This mitigation comes also at
|
||||
a performance cost.
|
||||
|
||||
|
||||
@@ -4177,13 +4177,11 @@
|
||||
|
||||
page_alloc.shuffle=
|
||||
[KNL] Boolean flag to control whether the page allocator
|
||||
should randomize its free lists. The randomization may
|
||||
be automatically enabled if the kernel detects it is
|
||||
running on a platform with a direct-mapped memory-side
|
||||
cache, and this parameter can be used to
|
||||
override/disable that behavior. The state of the flag
|
||||
can be read from sysfs at:
|
||||
should randomize its free lists. This parameter can be
|
||||
used to enable/disable page randomization. The state of
|
||||
the flag can be read from sysfs at:
|
||||
/sys/module/page_alloc/parameters/shuffle.
|
||||
This parameter is only available if CONFIG_SHUFFLE_PAGE_ALLOCATOR=y.
|
||||
|
||||
page_owner= [KNL,EARLY] Boot-time page_owner enabling option.
|
||||
Storage of the information about who allocated
|
||||
@@ -4789,7 +4787,9 @@
|
||||
|
||||
prot_virt= [S390] enable hosting protected virtual machines
|
||||
isolated from the hypervisor (if hardware supports
|
||||
that).
|
||||
that). If enabled, the default kernel base address
|
||||
might be overridden even when Kernel Address Space
|
||||
Layout Randomization is disabled.
|
||||
Format: <bool>
|
||||
|
||||
psi= [KNL] Enable or disable pressure stall information
|
||||
@@ -5100,6 +5100,20 @@
|
||||
delay, memory pressure or callback list growing too
|
||||
big.
|
||||
|
||||
rcutree.rcu_normal_wake_from_gp= [KNL]
|
||||
Reduces a latency of synchronize_rcu() call. This approach
|
||||
maintains its own track of synchronize_rcu() callers, so it
|
||||
does not interact with regular callbacks because it does not
|
||||
use a call_rcu[_hurry]() path. Please note, this is for a
|
||||
normal grace period.
|
||||
|
||||
How to enable it:
|
||||
|
||||
echo 1 > /sys/module/rcutree/parameters/rcu_normal_wake_from_gp
|
||||
or pass a boot parameter "rcutree.rcu_normal_wake_from_gp=1"
|
||||
|
||||
Default is 0.
|
||||
|
||||
rcuscale.gp_async= [KNL]
|
||||
Measure performance of asynchronous
|
||||
grace-period primitives such as call_rcu().
|
||||
@@ -6768,6 +6782,7 @@
|
||||
- "tpm"
|
||||
- "tee"
|
||||
- "caam"
|
||||
- "dcp"
|
||||
If not specified then it defaults to iterating through
|
||||
the trust source list starting with TPM and assigns the
|
||||
first trust source as a backend which is initialized
|
||||
@@ -6783,6 +6798,18 @@
|
||||
If not specified, "default" is used. In this case,
|
||||
the RNG's choice is left to each individual trust source.
|
||||
|
||||
trusted.dcp_use_otp_key
|
||||
This is intended to be used in combination with
|
||||
trusted.source=dcp and will select the DCP OTP key
|
||||
instead of the DCP UNIQUE key blob encryption.
|
||||
|
||||
trusted.dcp_skip_zk_test
|
||||
This is intended to be used in combination with
|
||||
trusted.source=dcp and will disable the check if the
|
||||
blob key is all zeros. This is helpful for situations where
|
||||
having this key zero'ed is acceptable. E.g. in testing
|
||||
scenarios.
|
||||
|
||||
tsc= Disable clocksource stability checks for TSC.
|
||||
Format: <string>
|
||||
[x86] reliable: mark tsc clocksource as reliable, this
|
||||
@@ -7343,7 +7370,7 @@
|
||||
This can be changed after boot by writing to the
|
||||
matching /sys/module/workqueue/parameters file. All
|
||||
workqueues with the "default" affinity scope will be
|
||||
updated accordignly.
|
||||
updated accordingly.
|
||||
|
||||
workqueue.debug_force_rr_cpu
|
||||
Workqueue used to implicitly guarantee that work
|
||||
|
||||
@@ -308,7 +308,7 @@ limited by the ``advisor_max_cpu`` parameter. In addition there is also the
|
||||
``advisor_target_scan_time`` parameter. This parameter sets the target time to
|
||||
scan all the KSM candidate pages. The parameter ``advisor_target_scan_time``
|
||||
decides how aggressive the scan time advisor scans candidate pages. Lower
|
||||
values make the scan time advisor to scan more aggresively. This is the most
|
||||
values make the scan time advisor to scan more aggressively. This is the most
|
||||
important parameter for the configuration of the scan time advisor.
|
||||
|
||||
The initial value and the maximum value can be changed with
|
||||
|
||||
@@ -42,12 +42,12 @@ The important basics
|
||||
--------------------
|
||||
|
||||
|
||||
What is a "regression" and what is the "no regressions rule"?
|
||||
What is a "regression" and what is the "no regressions" rule?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It's a regression if some application or practical use case running fine with
|
||||
one Linux kernel works worse or not at all with a newer version compiled using a
|
||||
similar configuration. The "no regressions rule" forbids this to take place; if
|
||||
similar configuration. The "no regressions" rule forbids this to take place; if
|
||||
it happens by accident, developers that caused it are expected to quickly fix
|
||||
the issue.
|
||||
|
||||
@@ -173,7 +173,7 @@ Additional details about regressions
|
||||
------------------------------------
|
||||
|
||||
|
||||
What is the goal of the "no regressions rule"?
|
||||
What is the goal of the "no regressions" rule?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Users should feel safe when updating kernel versions and not have to worry
|
||||
@@ -199,8 +199,8 @@ Exceptions to this rule are extremely rare; in the past developers almost always
|
||||
turned out to be wrong when they assumed a particular situation was warranting
|
||||
an exception.
|
||||
|
||||
Who ensures the "no regressions" is actually followed?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Who ensures the "no regressions" rule is actually followed?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The subsystem maintainers should take care of that, which are watched and
|
||||
supported by the tree maintainers -- e.g. Linus Torvalds for mainline and
|
||||
|
||||
@@ -173,7 +173,7 @@ When accessing IDE registers with A6=1 (for example $84x),
|
||||
the timing will always be mode 0 8-bit compatible, no matter
|
||||
what you have selected in the speed register:
|
||||
|
||||
781ns select, IOR/IOW after 4 clock cycles (=314ns) aktive.
|
||||
781ns select, IOR/IOW after 4 clock cycles (=314ns) active.
|
||||
|
||||
All the timings with a very short select-signal (the 355ns
|
||||
fast accesses) depend on the accelerator card used in the
|
||||
|
||||
@@ -8,6 +8,7 @@ s390 Architecture
|
||||
cds
|
||||
3270
|
||||
driver-model
|
||||
mm
|
||||
monreader
|
||||
qeth
|
||||
s390dbf
|
||||
|
||||
@@ -0,0 +1,111 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=================
|
||||
Memory Management
|
||||
=================
|
||||
|
||||
Virtual memory layout
|
||||
=====================
|
||||
|
||||
.. note::
|
||||
|
||||
- Some aspects of the virtual memory layout setup are not
|
||||
clarified (number of page levels, alignment, DMA memory).
|
||||
|
||||
- Unused gaps in the virtual memory layout could be present
|
||||
or not - depending on how partucular system is configured.
|
||||
No page tables are created for the unused gaps.
|
||||
|
||||
- The virtual memory regions are tracked or untracked by KASAN
|
||||
instrumentation, as well as the KASAN shadow memory itself is
|
||||
created only when CONFIG_KASAN configuration option is enabled.
|
||||
|
||||
::
|
||||
|
||||
=============================================================================
|
||||
| Physical | Virtual | VM area description
|
||||
=============================================================================
|
||||
+- 0 --------------+- 0 --------------+
|
||||
| | S390_lowcore | Low-address memory
|
||||
| +- 8 KB -----------+
|
||||
| | |
|
||||
| | |
|
||||
| | ... unused gap | KASAN untracked
|
||||
| | |
|
||||
+- AMODE31_START --+- AMODE31_START --+ .amode31 rand. phys/virt start
|
||||
|.amode31 text/data|.amode31 text/data| KASAN untracked
|
||||
+- AMODE31_END ----+- AMODE31_END ----+ .amode31 rand. phys/virt end (<2GB)
|
||||
| | |
|
||||
| | |
|
||||
+- __kaslr_offset_phys | kernel rand. phys start
|
||||
| | |
|
||||
| kernel text/data | |
|
||||
| | |
|
||||
+------------------+ | kernel phys end
|
||||
| | |
|
||||
| | |
|
||||
| | |
|
||||
| | |
|
||||
+- ident_map_size -+ |
|
||||
| |
|
||||
| ... unused gap | KASAN untracked
|
||||
| |
|
||||
+- __identity_base + identity mapping start (>= 2GB)
|
||||
| |
|
||||
| identity | phys == virt - __identity_base
|
||||
| mapping | virt == phys + __identity_base
|
||||
| |
|
||||
| | KASAN tracked
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
+---- vmemmap -----+ 'struct page' array start
|
||||
| |
|
||||
| virtually mapped |
|
||||
| memory map | KASAN untracked
|
||||
| |
|
||||
+- __abs_lowcore --+
|
||||
| |
|
||||
| Absolute Lowcore | KASAN untracked
|
||||
| |
|
||||
+- __memcpy_real_area
|
||||
| |
|
||||
| Real Memory Copy| KASAN untracked
|
||||
| |
|
||||
+- VMALLOC_START --+ vmalloc area start
|
||||
| | KASAN untracked or
|
||||
| vmalloc area | KASAN shallowly populated in case
|
||||
| | CONFIG_KASAN_VMALLOC=y
|
||||
+- MODULES_VADDR --+ modules area start
|
||||
| | KASAN allocated per module or
|
||||
| modules area | KASAN shallowly populated in case
|
||||
| | CONFIG_KASAN_VMALLOC=y
|
||||
+- __kaslr_offset -+ kernel rand. virt start
|
||||
| | KASAN tracked
|
||||
| kernel text/data | phys == (kvirt - __kaslr_offset) +
|
||||
| | __kaslr_offset_phys
|
||||
+- kernel .bss end + kernel rand. virt end
|
||||
| |
|
||||
| ... unused gap | KASAN untracked
|
||||
| |
|
||||
+------------------+ UltraVisor Secure Storage limit
|
||||
| |
|
||||
| ... unused gap | KASAN untracked
|
||||
| |
|
||||
+KASAN_SHADOW_START+ KASAN shadow memory start
|
||||
| |
|
||||
| KASAN shadow | KASAN untracked
|
||||
| |
|
||||
+------------------+ ASCE limit
|
||||
@@ -380,6 +380,36 @@ matrix device.
|
||||
control_domains:
|
||||
A read-only file for displaying the control domain numbers assigned to the
|
||||
vfio_ap mediated device.
|
||||
ap_config:
|
||||
A read/write file that, when written to, allows all three of the
|
||||
vfio_ap mediated device's ap matrix masks to be replaced in one shot.
|
||||
Three masks are given, one for adapters, one for domains, and one for
|
||||
control domains. If the given state cannot be set then no changes are
|
||||
made to the vfio-ap mediated device.
|
||||
|
||||
The format of the data written to ap_config is as follows:
|
||||
{amask},{dmask},{cmask}\n
|
||||
|
||||
\n is a newline character.
|
||||
|
||||
amask, dmask, and cmask are masks identifying which adapters, domains,
|
||||
and control domains should be assigned to the mediated device.
|
||||
|
||||
The format of a mask is as follows:
|
||||
0xNN..NN
|
||||
|
||||
Where NN..NN is 64 hexadecimal characters representing a 256-bit value.
|
||||
The leftmost (highest order) bit represents adapter/domain 0.
|
||||
|
||||
For an example set of masks that represent your mdev's current
|
||||
configuration, simply cat ap_config.
|
||||
|
||||
Setting an adapter or domain number greater than the maximum allowed for
|
||||
the system will result in an error.
|
||||
|
||||
This attribute is intended to be used by automation. End users would be
|
||||
better served using the respective assign/unassign attributes for
|
||||
adapters, domains, and control domains.
|
||||
|
||||
* functions:
|
||||
|
||||
@@ -550,7 +580,7 @@ These are the steps:
|
||||
following Kconfig elements selected:
|
||||
* IOMMU_SUPPORT
|
||||
* S390
|
||||
* ZCRYPT
|
||||
* AP
|
||||
* VFIO
|
||||
* KVM
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ Chapter 36. Coprocessor services
|
||||
submissions until they succeed; waiting for an outstanding CCB to complete is not necessary, and would
|
||||
not be a guarantee that a future submission would succeed.
|
||||
|
||||
The availablility of DAX coprocessor command service is indicated by the presence of the DAX virtual
|
||||
The availability of DAX coprocessor command service is indicated by the presence of the DAX virtual
|
||||
device node in the guest MD (Section 8.24.17, “Database Analytics Accelerators (DAX) virtual-device
|
||||
node”).
|
||||
|
||||
|
||||
@@ -138,7 +138,7 @@ Note this example does not include the sigaltstack preparation.
|
||||
Dynamic features in signal frames
|
||||
---------------------------------
|
||||
|
||||
Dynamcally enabled features are not written to the signal frame upon signal
|
||||
Dynamically enabled features are not written to the signal frame upon signal
|
||||
entry if the feature is in its initial configuration. This differs from
|
||||
non-dynamic features which are always written regardless of their
|
||||
configuration. Signal handlers can examine the XSAVE buffer's XSTATE_BV
|
||||
|
||||
@@ -171,14 +171,14 @@ The rule of thumb:
|
||||
- RMW operations that are conditional are unordered on FAILURE,
|
||||
otherwise the above rules apply.
|
||||
|
||||
Except of course when an operation has an explicit ordering like:
|
||||
Except of course when a successful operation has an explicit ordering like:
|
||||
|
||||
{}_relaxed: unordered
|
||||
{}_acquire: the R of the RMW (or atomic_read) is an ACQUIRE
|
||||
{}_release: the W of the RMW (or atomic_set) is a RELEASE
|
||||
|
||||
Where 'unordered' is against other memory locations. Address dependencies are
|
||||
not defeated.
|
||||
not defeated. Conditional operations are still unordered on FAILURE.
|
||||
|
||||
Fully ordered primitives are ordered against everything prior and everything
|
||||
subsequent. Therefore a fully ordered primitive is like having an smp_mb()
|
||||
|
||||
@@ -203,13 +203,33 @@ setting the DMA mask fails. In this manner, if a user of your driver reports
|
||||
that performance is bad or that the device is not even detected, you can ask
|
||||
them for the kernel messages to find out exactly why.
|
||||
|
||||
The standard 64-bit addressing device would do something like this::
|
||||
The 24-bit addressing device would do something like this::
|
||||
|
||||
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
|
||||
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(24))) {
|
||||
dev_warn(dev, "mydev: No suitable DMA available\n");
|
||||
goto ignore_this_device;
|
||||
}
|
||||
|
||||
The standard 64-bit addressing device would do something like this::
|
||||
|
||||
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))
|
||||
|
||||
dma_set_mask_and_coherent() never return fail when DMA_BIT_MASK(64). Typical
|
||||
error code like::
|
||||
|
||||
/* Wrong code */
|
||||
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)))
|
||||
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))
|
||||
|
||||
dma_set_mask_and_coherent() will never return failure when bigger than 32.
|
||||
So typical code like::
|
||||
|
||||
/* Recommended code */
|
||||
if (support_64bit)
|
||||
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
|
||||
else
|
||||
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
|
||||
|
||||
If the device only supports 32-bit addressing for descriptors in the
|
||||
coherent allocations, but supports full 64-bits for streaming mappings
|
||||
it would look like this::
|
||||
|
||||
@@ -18,7 +18,7 @@ exceptions`_, `NMI and NMI-like exceptions`_.
|
||||
Non-instrumentable code - noinstr
|
||||
---------------------------------
|
||||
|
||||
Most instrumentation facilities depend on RCU, so intrumentation is prohibited
|
||||
Most instrumentation facilities depend on RCU, so instrumentation is prohibited
|
||||
for entry code before RCU starts watching and exit code after RCU stops
|
||||
watching. In addition, many architectures must save and restore register state,
|
||||
which means that (for example) a breakpoint in the breakpoint entry code would
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
Printk Index
|
||||
============
|
||||
|
||||
There are many ways how to monitor the state of the system. One important
|
||||
There are many ways to monitor the state of the system. One important
|
||||
source of information is the system log. It provides a lot of information,
|
||||
including more or less important warnings and error messages.
|
||||
|
||||
@@ -101,7 +101,7 @@ their own wrappers adding __printk_index_emit().
|
||||
|
||||
Only few subsystem specific wrappers have been updated so far,
|
||||
for example, dev_printk(). As a result, the printk formats from
|
||||
some subsystes can be missing in the printk index.
|
||||
some subsystems can be missing in the printk index.
|
||||
|
||||
|
||||
Subsystem specific prefix
|
||||
|
||||
@@ -91,6 +91,16 @@ the below options are available:
|
||||
behaviour when encountering a data race is deemed safe. Please see
|
||||
`"Marking Shared-Memory Accesses" in the LKMM`_ for more information.
|
||||
|
||||
* Similar to ``data_race(...)``, the type qualifier ``__data_racy`` can be used
|
||||
to document that all data races due to accesses to a variable are intended
|
||||
and should be ignored by KCSAN::
|
||||
|
||||
struct foo {
|
||||
...
|
||||
int __data_racy stats_counter;
|
||||
...
|
||||
};
|
||||
|
||||
* Disabling data race detection for entire functions can be accomplished by
|
||||
using the function attribute ``__no_kcsan``::
|
||||
|
||||
|
||||
@@ -0,0 +1,84 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/access-controllers/access-controllers.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Generic Domain Access Controllers
|
||||
|
||||
maintainers:
|
||||
- Oleksii Moisieiev <oleksii_moisieiev@epam.com>
|
||||
|
||||
description: |+
|
||||
Common access controllers properties
|
||||
|
||||
Access controllers are in charge of stating which of the hardware blocks under
|
||||
their responsibility (their domain) can be accesssed by which compartment. A
|
||||
compartment can be a cluster of CPUs (or coprocessors), a range of addresses
|
||||
or a group of hardware blocks. An access controller's domain is the set of
|
||||
resources covered by the access controller.
|
||||
|
||||
This device tree binding can be used to bind devices to their access
|
||||
controller provided by access-controllers property. In this case, the device
|
||||
is a consumer and the access controller is the provider.
|
||||
|
||||
An access controller can be represented by any node in the device tree and
|
||||
can provide one or more configuration parameters, needed to control parameters
|
||||
of the consumer device. A consumer node can refer to the provider by phandle
|
||||
and a set of phandle arguments, specified by '#access-controller-cells'
|
||||
property in the access controller node.
|
||||
|
||||
Access controllers are typically used to set/read the permissions of a
|
||||
hardware block and grant access to it. Any of which depends on the access
|
||||
controller. The capabilities of each access controller are defined by the
|
||||
binding of the access controller device.
|
||||
|
||||
Each node can be a consumer for the several access controllers.
|
||||
|
||||
# always select the core schema
|
||||
select: true
|
||||
|
||||
properties:
|
||||
"#access-controller-cells":
|
||||
description:
|
||||
Number of cells in an access-controllers specifier;
|
||||
Can be any value as specified by device tree binding documentation
|
||||
of a particular provider. The node is an access controller.
|
||||
|
||||
access-controller-names:
|
||||
$ref: /schemas/types.yaml#/definitions/string-array
|
||||
description:
|
||||
A list of access-controllers names, sorted in the same order as
|
||||
access-controllers entries. Consumer drivers will use
|
||||
access-controller-names to match with existing access-controllers entries.
|
||||
|
||||
access-controllers:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description:
|
||||
A list of access controller specifiers, as defined by the
|
||||
bindings of the access-controllers provider.
|
||||
|
||||
additionalProperties: true
|
||||
|
||||
examples:
|
||||
- |
|
||||
clock_controller: access-controllers@50000 {
|
||||
reg = <0x50000 0x400>;
|
||||
#access-controller-cells = <2>;
|
||||
};
|
||||
|
||||
bus_controller: bus@60000 {
|
||||
reg = <0x60000 0x10000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
#access-controller-cells = <3>;
|
||||
|
||||
uart4: serial@60100 {
|
||||
reg = <0x60100 0x400>;
|
||||
clocks = <&clk_serial>;
|
||||
access-controllers = <&clock_controller 1 2>,
|
||||
<&bus_controller 1 3 5>;
|
||||
access-controller-names = "clock", "bus";
|
||||
};
|
||||
};
|
||||
@@ -53,6 +53,7 @@ properties:
|
||||
- description: BCM4709 based boards
|
||||
items:
|
||||
- enum:
|
||||
- asus,rt-ac3200
|
||||
- asus,rt-ac87u
|
||||
- buffalo,wxr-1900dhp
|
||||
- linksys,ea9200
|
||||
@@ -67,6 +68,7 @@ properties:
|
||||
items:
|
||||
- enum:
|
||||
- asus,rt-ac3100
|
||||
- asus,rt-ac5300
|
||||
- asus,rt-ac88u
|
||||
- dlink,dir-885l
|
||||
- dlink,dir-890l
|
||||
|
||||
@@ -46,6 +46,30 @@ properties:
|
||||
- compatible
|
||||
- "#clock-cells"
|
||||
|
||||
gpio:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: raspberrypi,firmware-gpio
|
||||
|
||||
gpio-controller: true
|
||||
|
||||
"#gpio-cells":
|
||||
const: 2
|
||||
description:
|
||||
The first cell is the pin number, and the second cell is used to
|
||||
specify the gpio polarity (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW).
|
||||
|
||||
gpio-line-names:
|
||||
minItems: 8
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- gpio-controller
|
||||
- "#gpio-cells"
|
||||
|
||||
reset:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
@@ -96,6 +120,12 @@ examples:
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
expgpio: gpio {
|
||||
compatible = "raspberrypi,firmware-gpio";
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
|
||||
reset: reset {
|
||||
compatible = "raspberrypi,firmware-reset";
|
||||
#reset-cells = <1>;
|
||||
|
||||
@@ -813,6 +813,14 @@ properties:
|
||||
- const: tq,imx6ull-tqma6ull2l # MCIMX6Y2, LGA SoM variant
|
||||
- const: fsl,imx6ull
|
||||
|
||||
- description: Seeed Stuido i.MX6ULL SoM on dev boards
|
||||
items:
|
||||
- enum:
|
||||
- seeed,imx6ull-seeed-npi-emmc
|
||||
- seeed,imx6ull-seeed-npi-nand
|
||||
- const: seeed,imx6ull-seeed-npi
|
||||
- const: fsl,imx6ull
|
||||
|
||||
- description: i.MX6ULZ based Boards
|
||||
items:
|
||||
- enum:
|
||||
@@ -1050,6 +1058,7 @@ properties:
|
||||
- enum:
|
||||
- beacon,imx8mp-beacon-kit # i.MX8MP Beacon Development Kit
|
||||
- dmo,imx8mp-data-modul-edm-sbc # i.MX8MP eDM SBC
|
||||
- emcraft,imx8mp-navqp # i.MX8MP Emcraft Systems NavQ+ Kit
|
||||
- fsl,imx8mp-evk # i.MX8MP EVK Board
|
||||
- gateworks,imx8mp-gw71xx-2x # i.MX8MP Gateworks Board
|
||||
- gateworks,imx8mp-gw72xx-2x # i.MX8MP Gateworks Board
|
||||
@@ -1218,7 +1227,6 @@ properties:
|
||||
- enum:
|
||||
- einfochips,imx8qxp-ai_ml # i.MX8QXP AI_ML Board
|
||||
- fsl,imx8qxp-mek # i.MX8QXP MEK Board
|
||||
- toradex,colibri-imx8x # Colibri iMX8X Modules
|
||||
- const: fsl,imx8qxp
|
||||
|
||||
- description: i.MX8DXL based Boards
|
||||
@@ -1227,7 +1235,7 @@ properties:
|
||||
- fsl,imx8dxl-evk # i.MX8DXL EVK Board
|
||||
- const: fsl,imx8dxl
|
||||
|
||||
- description: i.MX8QXP Boards with Toradex Colibri iMX8X Modules
|
||||
- description: i.MX8QXP/i.MX8DX Boards with Toradex Colibri iMX8X Modules
|
||||
items:
|
||||
- enum:
|
||||
- toradex,colibri-imx8x-aster # Colibri iMX8X Module on Aster Board
|
||||
@@ -1235,7 +1243,9 @@ properties:
|
||||
- toradex,colibri-imx8x-iris # Colibri iMX8X Module on Iris Board
|
||||
- toradex,colibri-imx8x-iris-v2 # Colibri iMX8X Module on Iris Board V2
|
||||
- const: toradex,colibri-imx8x
|
||||
- const: fsl,imx8qxp
|
||||
- enum:
|
||||
- fsl,imx8qxp
|
||||
- fsl,imx8dx
|
||||
|
||||
- description:
|
||||
TQMa8Xx is a series of SOM featuring NXP i.MX8X system-on-chip
|
||||
@@ -1536,6 +1546,12 @@ properties:
|
||||
- nxp,s32g274a-rdb2
|
||||
- const: nxp,s32g2
|
||||
|
||||
- description: S32G3 based Boards
|
||||
items:
|
||||
- enum:
|
||||
- nxp,s32g399a-rdb3
|
||||
- const: nxp,s32g3
|
||||
|
||||
- description: S32V234 based Boards
|
||||
items:
|
||||
- enum:
|
||||
|
||||
@@ -61,10 +61,6 @@ properties:
|
||||
mboxes:
|
||||
minItems: 2
|
||||
|
||||
ti,system-reboot-controller:
|
||||
description: Determines If system reboot can be triggered by SoC reboot
|
||||
type: boolean
|
||||
|
||||
ti,host-id:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
@@ -94,7 +90,6 @@ examples:
|
||||
- |
|
||||
pmmc: system-controller@2921800 {
|
||||
compatible = "ti,k2g-sci";
|
||||
ti,system-reboot-controller;
|
||||
mbox-names = "rx", "tx";
|
||||
mboxes = <&msgmgr 5 2>,
|
||||
<&msgmgr 0 0>;
|
||||
|
||||
@@ -137,6 +137,7 @@ properties:
|
||||
- microsoft,dempsey
|
||||
- microsoft,makepeace
|
||||
- microsoft,moneypenny
|
||||
- motorola,falcon
|
||||
- samsung,s3ve3g
|
||||
- const: qcom,msm8226
|
||||
|
||||
@@ -184,13 +185,16 @@ properties:
|
||||
- oneplus,bacon
|
||||
- samsung,klte
|
||||
- sony,xperia-castor
|
||||
- sony,xperia-leo
|
||||
- const: qcom,msm8974pro
|
||||
- const: qcom,msm8974
|
||||
|
||||
- items:
|
||||
- const: qcom,msm8916-mtp
|
||||
- const: qcom,msm8916-mtp/1
|
||||
- const: qcom,msm8916
|
||||
- enum:
|
||||
- samsung,kltechn
|
||||
- const: samsung,klte
|
||||
- const: qcom,msm8974pro
|
||||
- const: qcom,msm8974
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
@@ -200,6 +204,8 @@ properties:
|
||||
- gplus,fl8005a
|
||||
- huawei,g7
|
||||
- longcheer,l8910
|
||||
- longcheer,l8150
|
||||
- qcom,msm8916-mtp
|
||||
- samsung,a3u-eur
|
||||
- samsung,a5u-eur
|
||||
- samsung,e5
|
||||
@@ -220,11 +226,6 @@ properties:
|
||||
- yiming,uz801-v3
|
||||
- const: qcom,msm8916
|
||||
|
||||
- items:
|
||||
- const: longcheer,l8150
|
||||
- const: qcom,msm8916-v1-qrd/9-v1
|
||||
- const: qcom,msm8916
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- motorola,potter
|
||||
@@ -1003,6 +1004,7 @@ properties:
|
||||
- qcom,sm8550-hdk
|
||||
- qcom,sm8550-mtp
|
||||
- qcom,sm8550-qrd
|
||||
- sony,pdx234
|
||||
- const: qcom,sm8550
|
||||
|
||||
- items:
|
||||
|
||||
@@ -49,6 +49,11 @@ properties:
|
||||
- anbernic,rg-arc-s
|
||||
- const: rockchip,rk3566
|
||||
|
||||
- description: ArmSoM Sige7 board
|
||||
items:
|
||||
- const: armsom,sige7
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: Asus Tinker board
|
||||
items:
|
||||
- const: asus,rk3288-tinker
|
||||
@@ -198,6 +203,13 @@ properties:
|
||||
- const: firefly,rk3568-roc-pc
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: Forlinx FET3588-C SoM
|
||||
items:
|
||||
- enum:
|
||||
- forlinx,ok3588-c
|
||||
- const: forlinx,fet3588-c
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: FriendlyElec NanoPi R2 series boards
|
||||
items:
|
||||
- enum:
|
||||
@@ -236,6 +248,11 @@ properties:
|
||||
- const: friendlyarm,nanopc-t6
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: GameForce Chi
|
||||
items:
|
||||
- const: gameforce,chi
|
||||
- const: rockchip,rk3326
|
||||
|
||||
- description: GeekBuying GeekBox
|
||||
items:
|
||||
- const: geekbuying,geekbox
|
||||
@@ -631,7 +648,7 @@ properties:
|
||||
- const: phytec,rk3288-phycore-som
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Pine64 PinebookPro
|
||||
- description: Pine64 Pinebook Pro
|
||||
items:
|
||||
- const: pine64,pinebook-pro
|
||||
- const: rockchip,rk3399
|
||||
@@ -644,7 +661,7 @@ properties:
|
||||
- const: pine64,pinenote
|
||||
- const: rockchip,rk3566
|
||||
|
||||
- description: Pine64 PinePhonePro
|
||||
- description: Pine64 PinePhone Pro
|
||||
items:
|
||||
- const: pine64,pinephone-pro
|
||||
- const: rockchip,rk3399
|
||||
@@ -682,7 +699,7 @@ properties:
|
||||
- const: pine64,quartzpro64
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: Pine64 SoQuartz SoM
|
||||
- description: Pine64 SOQuartz
|
||||
items:
|
||||
- enum:
|
||||
- pine64,soquartz-blade
|
||||
@@ -700,12 +717,17 @@ properties:
|
||||
- powkiddy,x55
|
||||
- const: rockchip,rk3566
|
||||
|
||||
- description: Protonic MECSBC board
|
||||
items:
|
||||
- const: prt,mecsbc
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: QNAP TS-433-4G 4-Bay NAS
|
||||
items:
|
||||
- const: qnap,ts433
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: Radxa Compute Module 3(CM3)
|
||||
- description: Radxa Compute Module 3 (CM3)
|
||||
items:
|
||||
- enum:
|
||||
- radxa,cm3-io
|
||||
@@ -767,22 +789,27 @@ properties:
|
||||
- const: radxa,rockpis
|
||||
- const: rockchip,rk3308
|
||||
|
||||
- description: Radxa Rock2 Square
|
||||
- description: Radxa Rock 2 Square
|
||||
items:
|
||||
- const: radxa,rock2-square
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Radxa ROCK3 Model A
|
||||
- description: Radxa ROCK 3A
|
||||
items:
|
||||
- const: radxa,rock3a
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: Radxa ROCK 5 Model A
|
||||
- description: Radxa ROCK 3C
|
||||
items:
|
||||
- const: radxa,rock-3c
|
||||
- const: rockchip,rk3566
|
||||
|
||||
- description: Radxa ROCK 5A
|
||||
items:
|
||||
- const: radxa,rock-5a
|
||||
- const: rockchip,rk3588s
|
||||
|
||||
- description: Radxa ROCK 5 Model B
|
||||
- description: Radxa ROCK 5B
|
||||
items:
|
||||
- const: radxa,rock-5b
|
||||
- const: rockchip,rk3588
|
||||
@@ -927,6 +954,11 @@ properties:
|
||||
- const: turing,rk1
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: WolfVision PF5 mainboard
|
||||
items:
|
||||
- const: wolfvision,rk3568-pf5
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: Xunlong Orange Pi 5 Plus
|
||||
items:
|
||||
- const: xunlong,orangepi-5-plus
|
||||
|
||||
@@ -56,6 +56,21 @@ properties:
|
||||
- const: anbernic,rg-nano
|
||||
- const: allwinner,sun8i-v3s
|
||||
|
||||
- description: Anbernic RG35XX (2024)
|
||||
- items:
|
||||
- const: anbernic,rg35xx-2024
|
||||
- const: allwinner,sun50i-h700
|
||||
|
||||
- description: Anbernic RG35XX Plus
|
||||
- items:
|
||||
- const: anbernic,rg35xx-plus
|
||||
- const: allwinner,sun50i-h700
|
||||
|
||||
- description: Anbernic RG35XX H
|
||||
- items:
|
||||
- const: anbernic,rg35xx-h
|
||||
- const: allwinner,sun50i-h700
|
||||
|
||||
- description: Amarula A64 Relic
|
||||
items:
|
||||
- const: amarula,a64-relic
|
||||
@@ -774,6 +789,11 @@ properties:
|
||||
- const: pocketbook,touch-lux-3
|
||||
- const: allwinner,sun5i-a13
|
||||
|
||||
- description: PocketBook 614 Plus
|
||||
items:
|
||||
- const: pocketbook,614-plus
|
||||
- const: allwinner,sun5i-a13
|
||||
|
||||
- description: Point of View Protab2-IPS9
|
||||
items:
|
||||
- const: pov,protab2-ips9
|
||||
@@ -860,6 +880,11 @@ properties:
|
||||
- const: allwinner,sl631
|
||||
- const: allwinner,sun8i-v3
|
||||
|
||||
- description: Tanix TX1
|
||||
items:
|
||||
- const: oranth,tanix-tx1
|
||||
- const: allwinner,sun50i-h616
|
||||
|
||||
- description: Tanix TX6
|
||||
items:
|
||||
- const: oranth,tanix-tx6
|
||||
|
||||
@@ -0,0 +1,96 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/bus/st,stm32-etzpc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: STM32 Extended TrustZone protection controller
|
||||
|
||||
description: |
|
||||
The ETZPC configures TrustZone security in a SoC having bus masters and
|
||||
devices with programmable-security attributes (securable resources).
|
||||
|
||||
maintainers:
|
||||
- Gatien Chevallier <gatien.chevallier@foss.st.com>
|
||||
|
||||
select:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: st,stm32-etzpc
|
||||
required:
|
||||
- compatible
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: st,stm32-etzpc
|
||||
- const: simple-bus
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 1
|
||||
|
||||
ranges: true
|
||||
|
||||
"#access-controller-cells":
|
||||
const: 1
|
||||
description:
|
||||
Contains the firewall ID associated to the peripheral.
|
||||
|
||||
patternProperties:
|
||||
"^.*@[0-9a-f]+$":
|
||||
description: Peripherals
|
||||
type: object
|
||||
|
||||
additionalProperties: true
|
||||
|
||||
required:
|
||||
- access-controllers
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
- "#access-controller-cells"
|
||||
- ranges
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
// In this example, the usart2 device refers to rifsc as its access
|
||||
// controller.
|
||||
// Access rights are verified before creating devices.
|
||||
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/clock/stm32mp13-clks.h>
|
||||
#include <dt-bindings/reset/stm32mp13-resets.h>
|
||||
|
||||
etzpc: bus@5c007000 {
|
||||
compatible = "st,stm32-etzpc", "simple-bus";
|
||||
reg = <0x5c007000 0x400>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
#access-controller-cells = <1>;
|
||||
ranges;
|
||||
|
||||
usart2: serial@4c001000 {
|
||||
compatible = "st,stm32h7-uart";
|
||||
reg = <0x4c001000 0x400>;
|
||||
interrupts-extended = <&exti 27 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&rcc USART2_K>;
|
||||
resets = <&rcc USART2_R>;
|
||||
wakeup-source;
|
||||
dmas = <&dmamux1 43 0x400 0x5>,
|
||||
<&dmamux1 44 0x400 0x1>;
|
||||
dma-names = "rx", "tx";
|
||||
access-controllers = <&etzpc 17>;
|
||||
};
|
||||
};
|
||||
@@ -0,0 +1,105 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/bus/st,stm32mp25-rifsc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: STM32 Resource isolation framework security controller
|
||||
|
||||
maintainers:
|
||||
- Gatien Chevallier <gatien.chevallier@foss.st.com>
|
||||
|
||||
description: |
|
||||
Resource isolation framework (RIF) is a comprehensive set of hardware blocks
|
||||
designed to enforce and manage isolation of STM32 hardware resources like
|
||||
memory and peripherals.
|
||||
|
||||
The RIFSC (RIF security controller) is composed of three sets of registers,
|
||||
each managing a specific set of hardware resources:
|
||||
- RISC registers associated with RISUP logic (resource isolation device unit
|
||||
for peripherals), assign all non-RIF aware peripherals to zero, one or
|
||||
any security domains (secure, privilege, compartment).
|
||||
- RIMC registers: associated with RIMU logic (resource isolation master
|
||||
unit), assign all non RIF-aware bus master to one security domain by
|
||||
setting secure, privileged and compartment information on the system bus.
|
||||
Alternatively, the RISUP logic controlling the device port access to a
|
||||
peripheral can assign target bus attributes to this peripheral master port
|
||||
(supported attribute: CID).
|
||||
- RISC registers associated with RISAL logic (resource isolation device unit
|
||||
for address space - Lite version), assign address space subregions to one
|
||||
security domains (secure, privilege, compartment).
|
||||
|
||||
select:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: st,stm32mp25-rifsc
|
||||
required:
|
||||
- compatible
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: st,stm32mp25-rifsc
|
||||
- const: simple-bus
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 1
|
||||
|
||||
ranges: true
|
||||
|
||||
"#access-controller-cells":
|
||||
const: 1
|
||||
description:
|
||||
Contains the firewall ID associated to the peripheral.
|
||||
|
||||
patternProperties:
|
||||
"^.*@[0-9a-f]+$":
|
||||
description: Peripherals
|
||||
type: object
|
||||
|
||||
additionalProperties: true
|
||||
|
||||
required:
|
||||
- access-controllers
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
- "#access-controller-cells"
|
||||
- ranges
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
// In this example, the usart2 device refers to rifsc as its domain
|
||||
// controller.
|
||||
// Access rights are verified before creating devices.
|
||||
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
rifsc: bus@42080000 {
|
||||
compatible = "st,stm32mp25-rifsc", "simple-bus";
|
||||
reg = <0x42080000 0x1000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
#access-controller-cells = <1>;
|
||||
ranges;
|
||||
|
||||
usart2: serial@400e0000 {
|
||||
compatible = "st,stm32h7-uart";
|
||||
reg = <0x400e0000 0x400>;
|
||||
interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&ck_flexgen_08>;
|
||||
access-controllers = <&rifsc 32>;
|
||||
};
|
||||
};
|
||||
@@ -30,16 +30,18 @@ properties:
|
||||
- google,gs101-cmu-top
|
||||
- google,gs101-cmu-apm
|
||||
- google,gs101-cmu-misc
|
||||
- google,gs101-cmu-hsi0
|
||||
- google,gs101-cmu-hsi2
|
||||
- google,gs101-cmu-peric0
|
||||
- google,gs101-cmu-peric1
|
||||
|
||||
clocks:
|
||||
minItems: 1
|
||||
maxItems: 3
|
||||
maxItems: 5
|
||||
|
||||
clock-names:
|
||||
minItems: 1
|
||||
maxItems: 3
|
||||
maxItems: 5
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
@@ -72,6 +74,55 @@ allOf:
|
||||
items:
|
||||
- const: oscclk
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: google,gs101-cmu-hsi0
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: External reference clock (24.576 MHz)
|
||||
- description: HSI0 bus clock (from CMU_TOP)
|
||||
- description: DPGTC (from CMU_TOP)
|
||||
- description: USB DRD controller clock (from CMU_TOP)
|
||||
- description: USB Display Port debug clock (from CMU_TOP)
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: oscclk
|
||||
- const: bus
|
||||
- const: dpgtc
|
||||
- const: usb31drd
|
||||
- const: usbdpdbg
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- google,gs101-cmu-hsi2
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: External reference clock (24.576 MHz)
|
||||
- description: High Speed Interface bus clock (from CMU_TOP)
|
||||
- description: High Speed Interface pcie clock (from CMU_TOP)
|
||||
- description: High Speed Interface ufs clock (from CMU_TOP)
|
||||
- description: High Speed Interface mmc clock (from CMU_TOP)
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: oscclk
|
||||
- const: bus
|
||||
- const: pcie
|
||||
- const: ufs
|
||||
- const: mmc
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@@ -46,6 +46,10 @@ properties:
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@@ -51,6 +51,10 @@ properties:
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@@ -348,15 +348,6 @@ properties:
|
||||
# Yes Optoelectronics YTC700TLAG-05-201C 7" TFT LCD panel
|
||||
- yes-optoelectronics,ytc700tlag-05-201c
|
||||
|
||||
backlight: true
|
||||
ddc-i2c-bus: true
|
||||
enable-gpios: true
|
||||
port: true
|
||||
power-supply: true
|
||||
no-hpd: true
|
||||
hpd-gpios: true
|
||||
data-mapping: true
|
||||
|
||||
if:
|
||||
not:
|
||||
properties:
|
||||
@@ -367,7 +358,7 @@ then:
|
||||
properties:
|
||||
data-mapping: false
|
||||
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
@@ -177,6 +177,15 @@ allOf:
|
||||
|
||||
required:
|
||||
- reg-names
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- nvidia,tegra194-host1x
|
||||
then:
|
||||
properties:
|
||||
dma-coherent: true
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
@@ -226,6 +235,8 @@ allOf:
|
||||
use. Should be a mapping of IDs 0..n to IOMMU entries corresponding to
|
||||
usable stream IDs.
|
||||
|
||||
dma-coherent: true
|
||||
|
||||
required:
|
||||
- reg-names
|
||||
|
||||
|
||||
@@ -82,6 +82,10 @@ properties:
|
||||
description: if defined, it indicates that the controller
|
||||
supports memory-to-memory transfer
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@@ -28,6 +28,10 @@ properties:
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@@ -247,6 +247,37 @@ properties:
|
||||
reg:
|
||||
const: 0x18
|
||||
|
||||
protocol@19:
|
||||
type: object
|
||||
allOf:
|
||||
- $ref: '#/$defs/protocol-node'
|
||||
- $ref: /schemas/pinctrl/pinctrl.yaml
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
reg:
|
||||
const: 0x19
|
||||
|
||||
patternProperties:
|
||||
'-pins$':
|
||||
type: object
|
||||
allOf:
|
||||
- $ref: /schemas/pinctrl/pincfg-node.yaml#
|
||||
- $ref: /schemas/pinctrl/pinmux-node.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
description:
|
||||
A pin multiplexing sub-node describes how to configure a
|
||||
set of pins in some desired function.
|
||||
A single sub-node may define several pin configurations.
|
||||
This sub-node is using the default pinctrl bindings to configure
|
||||
pin multiplexing and using SCMI protocol to apply a specified
|
||||
configuration.
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
$defs:
|
||||
@@ -355,7 +386,7 @@ examples:
|
||||
|
||||
scmi_dvfs: protocol@13 {
|
||||
reg = <0x13>;
|
||||
#clock-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
|
||||
mboxes = <&mhuB 1 0>,
|
||||
<&mhuB 1 1>;
|
||||
@@ -401,6 +432,25 @@ examples:
|
||||
scmi_powercap: protocol@18 {
|
||||
reg = <0x18>;
|
||||
};
|
||||
|
||||
scmi_pinctrl: protocol@19 {
|
||||
reg = <0x19>;
|
||||
|
||||
i2c2-pins {
|
||||
groups = "g_i2c2_a", "g_i2c2_b";
|
||||
function = "f_i2c2";
|
||||
};
|
||||
|
||||
mdio-pins {
|
||||
groups = "g_avb_mdio";
|
||||
drive-strength = <24>;
|
||||
};
|
||||
|
||||
keys_pins: keys-pins {
|
||||
pins = "gpio_5_17", "gpio_5_20", "gpio_5_22", "gpio_2_1";
|
||||
bias-pull-up;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
@@ -468,7 +518,7 @@ examples:
|
||||
reg = <0x13>;
|
||||
linaro,optee-channel-id = <1>;
|
||||
shmem = <&cpu_optee_lpri0>;
|
||||
#clock-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
scmi_clk0: protocol@14 {
|
||||
|
||||
@@ -1,30 +0,0 @@
|
||||
Raspberry Pi GPIO expander
|
||||
|
||||
The Raspberry Pi 3 GPIO expander is controlled by the VC4 firmware. The
|
||||
firmware exposes a mailbox interface that allows the ARM core to control the
|
||||
GPIO lines on the expander.
|
||||
|
||||
The Raspberry Pi GPIO expander node must be a child node of the Raspberry Pi
|
||||
firmware node.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should be "raspberrypi,firmware-gpio"
|
||||
- gpio-controller : Marks the device node as a gpio controller
|
||||
- #gpio-cells : Should be two. The first cell is the pin number, and
|
||||
the second cell is used to specify the gpio polarity:
|
||||
0 = active high
|
||||
1 = active low
|
||||
|
||||
Example:
|
||||
|
||||
firmware: firmware-rpi {
|
||||
compatible = "raspberrypi,bcm2835-firmware";
|
||||
mboxes = <&mailbox>;
|
||||
|
||||
expgpio: gpio {
|
||||
compatible = "raspberrypi,firmware-gpio";
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
};
|
||||
@@ -127,6 +127,10 @@ properties:
|
||||
|
||||
wakeup-source: true
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@@ -93,6 +93,10 @@ properties:
|
||||
'#size-cells':
|
||||
const: 0
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
|
||||
@@ -59,6 +59,10 @@ properties:
|
||||
If not, SPI CLKOUT frequency will not be accurate.
|
||||
maximum: 20000000
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@@ -45,6 +45,10 @@ properties:
|
||||
'#size-cells':
|
||||
const: 0
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
|
||||
@@ -29,6 +29,10 @@ properties:
|
||||
- const: cec
|
||||
- const: hdmi-cec
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@@ -36,6 +36,10 @@ properties:
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
port:
|
||||
$ref: /schemas/graph.yaml#/$defs/port-base
|
||||
unevaluatedProperties: false
|
||||
|
||||
@@ -30,6 +30,10 @@ properties:
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@@ -0,0 +1,33 @@
|
||||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/memory-controllers/samsung,s5pv210-dmc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung S5Pv210 SoC Dynamic Memory Controller
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzk@kernel.org>
|
||||
|
||||
description:
|
||||
Dynamic Memory Controller interfaces external JEDEC DDR-type SDRAM.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: samsung,s5pv210-dmc
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
memory-controller@f0000000 {
|
||||
compatible = "samsung,s5pv210-dmc";
|
||||
reg = <0xf0000000 0x1000>;
|
||||
};
|
||||
@@ -50,6 +50,10 @@ properties:
|
||||
Reflects the memory layout with four integer values per bank. Format:
|
||||
<bank-number> 0 <address of the bank> <size>
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
patternProperties:
|
||||
"^.*@[0-4],[a-f0-9]+$":
|
||||
additionalProperties: true
|
||||
|
||||
@@ -44,6 +44,10 @@ properties:
|
||||
|
||||
wakeup-source: true
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
pwm:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
|
||||
@@ -67,6 +67,10 @@ properties:
|
||||
"#size-cells":
|
||||
const: 0
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
pwm:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
|
||||
@@ -79,6 +79,10 @@ properties:
|
||||
- const: rx
|
||||
- const: tx
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
power-domains: true
|
||||
|
||||
resets:
|
||||
|
||||
@@ -118,6 +118,10 @@ properties:
|
||||
phys:
|
||||
maxItems: 1
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@@ -93,6 +93,10 @@ properties:
|
||||
select RCC clock instead of ETH_REF_CLK.
|
||||
type: boolean
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
|
||||
@@ -55,6 +55,10 @@ properties:
|
||||
description: number of clock cells for ck_usbo_48m consumer
|
||||
const: 0
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
# Required child nodes:
|
||||
|
||||
patternProperties:
|
||||
|
||||
@@ -30,6 +30,10 @@ properties:
|
||||
vdda-supply:
|
||||
description: phandle to the vdda input analog voltage.
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@@ -37,6 +37,10 @@ properties:
|
||||
description: If set, the RNG configuration in RNG_CR, RNG_HTCR and
|
||||
RNG_NSCR will be locked.
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@@ -73,6 +73,10 @@ properties:
|
||||
enum: [1, 2, 4, 8, 12, 14, 16]
|
||||
default: 8
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
allOf:
|
||||
- $ref: rs485.yaml#
|
||||
- $ref: serial.yaml#
|
||||
|
||||
@@ -58,20 +58,6 @@ patternProperties:
|
||||
required:
|
||||
- compatible
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
not:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,sm8450-pmic-glink
|
||||
- qcom,sm8550-pmic-glink
|
||||
- qcom,x1e80100-pmic-glink
|
||||
then:
|
||||
properties:
|
||||
orientation-gpios: false
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
|
||||
@@ -116,8 +116,8 @@ examples:
|
||||
|
||||
bluetooth {
|
||||
compatible = "qcom,wcnss-bt";
|
||||
/* BD address 00:11:22:33:44:55 */
|
||||
local-bd-address = [ 55 44 33 22 11 00 ];
|
||||
/* Updated by boot firmware (little-endian order) */
|
||||
local-bd-address = [ 00 00 00 00 00 00 ];
|
||||
};
|
||||
|
||||
wifi {
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/soc/renesas/renesas,r9a09g057-sys.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Renesas RZ/V2H(P) System Controller (SYS)
|
||||
|
||||
maintainers:
|
||||
- Geert Uytterhoeven <geert+renesas@glider.be>
|
||||
|
||||
description: |
|
||||
The RZ/V2H(P) SYS (System Controller) controls the overall
|
||||
configuration of the LSI and supports the following functions,
|
||||
- Trust zone control
|
||||
- Extend access by specific masters to address beyond 4GB space
|
||||
- GBETH configuration
|
||||
- Control of settings and states of SRAM/PCIe/CM33/CA55/CR8/xSPI/ADC/TSU
|
||||
- LSI version
|
||||
- WDT stop control
|
||||
- General registers
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: renesas,r9a09g057-sys
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- resets
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
sys: system-controller@10430000 {
|
||||
compatible = "renesas,r9a09g057-sys";
|
||||
reg = <0x10430000 0x10000>;
|
||||
clocks = <&cpg 1>;
|
||||
resets = <&cpg 1>;
|
||||
};
|
||||
@@ -513,6 +513,14 @@ properties:
|
||||
- renesas,rzv2mevk2 # RZ/V2M Eval Board v2.0
|
||||
- const: renesas,r9a09g011
|
||||
|
||||
- description: RZ/V2H(P) (R9A09G057)
|
||||
items:
|
||||
- enum:
|
||||
- renesas,r9a09g057h41 # RZ/V2H
|
||||
- renesas,r9a09g057h42 # RZ/V2H with Mali-G31 support
|
||||
- renesas,r9a09g057h44 # RZ/V2HP with Mali-G31 + Mali-C55 support
|
||||
- const: renesas,r9a09g057
|
||||
|
||||
additionalProperties: true
|
||||
|
||||
...
|
||||
|
||||
@@ -15,6 +15,7 @@ properties:
|
||||
- items:
|
||||
- enum:
|
||||
- google,gs101-apm-sysreg
|
||||
- google,gs101-hsi2-sysreg
|
||||
- google,gs101-peric0-sysreg
|
||||
- google,gs101-peric1-sysreg
|
||||
- samsung,exynos3-sysreg
|
||||
@@ -72,6 +73,7 @@ allOf:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- google,gs101-hsi2-sysreg
|
||||
- google,gs101-peric0-sysreg
|
||||
- google,gs101-peric1-sysreg
|
||||
- samsung,exynos850-cmgp-sysreg
|
||||
|
||||
@@ -65,6 +65,10 @@ properties:
|
||||
$ref: audio-graph-port.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- "#sound-dai-cells"
|
||||
|
||||
@@ -48,6 +48,10 @@ properties:
|
||||
clock-names:
|
||||
maxItems: 3
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@@ -50,6 +50,10 @@ properties:
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- "#sound-dai-cells"
|
||||
|
||||
@@ -46,6 +46,10 @@ properties:
|
||||
- const: tx
|
||||
- const: rx
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@@ -52,6 +52,10 @@ properties:
|
||||
- const: rx
|
||||
- const: tx
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@@ -32,6 +32,7 @@ properties:
|
||||
- enum:
|
||||
- infineon,slb9673
|
||||
- nuvoton,npct75x
|
||||
- st,st33ktpm2xi2c
|
||||
- const: tcg,tpm-tis-i2c
|
||||
|
||||
- description: TPM 1.2 and 2.0 chips with vendor-specific I²C interface
|
||||
|
||||
@@ -172,6 +172,10 @@ properties:
|
||||
|
||||
tpl-support: true
|
||||
|
||||
access-controllers:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
dependencies:
|
||||
port: [ usb-role-switch ]
|
||||
role-switch-default-mode: [ usb-role-switch ]
|
||||
|
||||
@@ -33,6 +33,7 @@ properties:
|
||||
- fsl,imx7ulp-usbmisc
|
||||
- fsl,imx8mm-usbmisc
|
||||
- fsl,imx8mn-usbmisc
|
||||
- fsl,imx8ulp-usbmisc
|
||||
- const: fsl,imx7d-usbmisc
|
||||
- const: fsl,imx6q-usbmisc
|
||||
- items:
|
||||
|
||||
@@ -151,6 +151,8 @@ patternProperties:
|
||||
description: ARM Ltd.
|
||||
"^armadeus,.*":
|
||||
description: ARMadeus Systems SARL
|
||||
"^armsom,.*":
|
||||
description: ArmSoM Technology Co., Ltd.
|
||||
"^arrow,.*":
|
||||
description: Arrow Electronics
|
||||
"^artesyn,.*":
|
||||
@@ -438,6 +440,8 @@ patternProperties:
|
||||
description: Dongguan EmbedFire Electronic Technology Co., Ltd.
|
||||
"^embest,.*":
|
||||
description: Shenzhen Embest Technology Co., Ltd.
|
||||
"^emcraft,.*":
|
||||
description: Emcraft Systems
|
||||
"^emlid,.*":
|
||||
description: Emlid, Ltd.
|
||||
"^emmicro,.*":
|
||||
@@ -1627,6 +1631,8 @@ patternProperties:
|
||||
description: Wondermedia Technologies, Inc.
|
||||
"^wobo,.*":
|
||||
description: Wobo
|
||||
"^wolfvision,.*":
|
||||
description: WolfVision GmbH
|
||||
"^x-powers,.*":
|
||||
description: X-Powers
|
||||
"^xen,.*":
|
||||
|
||||
@@ -61,7 +61,7 @@ DESCRIPTION
|
||||
***********
|
||||
|
||||
|
||||
Convert a C header or source file (C_FILE), into a ReStructured Text
|
||||
Convert a C header or source file (C_FILE), into a reStructuredText
|
||||
included via ..parsed-literal block with cross-references for the
|
||||
documentation files that describe the API. It accepts an optional
|
||||
EXCEPTIONS_FILE with describes what elements will be either ignored or
|
||||
|
||||
@@ -196,8 +196,8 @@ eisa_bus.disable_dev
|
||||
virtual_root.force_probe
|
||||
Force the probing code to probe EISA slots even when it cannot find an
|
||||
EISA compliant mainboard (nothing appears on slot 0). Defaults to 0
|
||||
(don't force), and set to 1 (force probing) when either
|
||||
CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING are set.
|
||||
(don't force), and set to 1 (force probing) when
|
||||
CONFIG_EISA_VLB_PRIMING is set.
|
||||
|
||||
Random notes
|
||||
============
|
||||
|
||||
@@ -462,7 +462,7 @@ statements is reduced. This is also reflected in the assembly code.
|
||||
Analysis 3
|
||||
==========
|
||||
|
||||
Very weird. Guess it has to do with caching or instruction parallellism
|
||||
Very weird. Guess it has to do with caching or instruction parallelism
|
||||
or so. I also tried on an eeePC (Celeron, clocked at 900 Mhz). Interesting
|
||||
observation was that this one is only 30% slower (according to time)
|
||||
executing the code as my 3Ghz D920 processor.
|
||||
|
||||
@@ -259,7 +259,7 @@ attributes for Serial Attached SCSI, a variant of SATA aimed at large
|
||||
high-end systems.
|
||||
|
||||
The SAS transport class contains common code to deal with SAS HBAs, an
|
||||
aproximated representation of SAS topologies in the driver model, and
|
||||
approximated representation of SAS topologies in the driver model, and
|
||||
various sysfs attributes to expose these topologies and management
|
||||
interfaces to userspace.
|
||||
|
||||
|
||||
@@ -422,7 +422,7 @@ USBDEVFS_CONNECTINFO
|
||||
|
||||
USBDEVFS_GET_SPEED
|
||||
Returns the speed of the device. The speed is returned as a
|
||||
nummerical value in accordance with enum usb_device_speed
|
||||
numerical value in accordance with enum usb_device_speed
|
||||
|
||||
File modification time is not updated by this request.
|
||||
|
||||
|
||||
@@ -68,7 +68,7 @@ The expected flow for the consumers:
|
||||
can be enabled for the device.
|
||||
2. Call `amd_wbrf_register_notifier` to register for notification
|
||||
of frequency band change(add or remove) from other producers.
|
||||
3. Call the `amd_wbrf_retrieve_freq_band` initally to retrieve
|
||||
3. Call the `amd_wbrf_retrieve_freq_band` initially to retrieve
|
||||
current active frequency bands considering some producers may broadcast
|
||||
such information before the consumer is up.
|
||||
4. On receiving a notification for frequency band change, run
|
||||
|
||||
@@ -44,7 +44,7 @@ For our purposes all operations fall in 6 classes:
|
||||
* decide which of the source and target need to be locked.
|
||||
The source needs to be locked if it's a non-directory, target - if it's
|
||||
a non-directory or about to be removed.
|
||||
* take the locks that need to be taken (exlusive), in inode pointer order
|
||||
* take the locks that need to be taken (exclusive), in inode pointer order
|
||||
if need to take both (that can happen only when both source and target
|
||||
are non-directories - the source because it wouldn't need to be locked
|
||||
otherwise and the target because mixing directory and non-directory is
|
||||
@@ -234,7 +234,7 @@ among the children, in some order. But that is also impossible, since
|
||||
neither of the children is a descendent of another.
|
||||
|
||||
That concludes the proof, since the set of operations with the
|
||||
properties requiered for a minimal deadlock can not exist.
|
||||
properties required for a minimal deadlock can not exist.
|
||||
|
||||
Note that the check for having a common ancestor in cross-directory
|
||||
rename is crucial - without it a deadlock would be possible. Indeed,
|
||||
|
||||
@@ -858,7 +858,7 @@ be misspelled d_alloc_anon().
|
||||
|
||||
**mandatory**
|
||||
|
||||
[should've been added in 2016] stale comment in finish_open() nonwithstanding,
|
||||
[should've been added in 2016] stale comment in finish_open() notwithstanding,
|
||||
failure exits in ->atomic_open() instances should *NOT* fput() the file,
|
||||
no matter what. Everything is handled by the caller.
|
||||
|
||||
@@ -989,7 +989,7 @@ This mechanism would only work for a single device so the block layer couldn't
|
||||
find the owning superblock of any additional devices.
|
||||
|
||||
In the old mechanism reusing or creating a superblock for a racing mount(2) and
|
||||
umount(2) relied on the file_system_type as the holder. This was severly
|
||||
umount(2) relied on the file_system_type as the holder. This was severely
|
||||
underdocumented however:
|
||||
|
||||
(1) Any concurrent mounter that managed to grab an active reference on an
|
||||
|
||||
@@ -107,7 +107,7 @@ Other documentation
|
||||
|
||||
There are several unsorted documents that don't seem to fit on other parts
|
||||
of the documentation body, or may require some adjustments and/or conversion
|
||||
to ReStructured Text format, or are simply too old.
|
||||
to reStructuredText format, or are simply too old.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
@@ -21,6 +21,51 @@ Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus
|
||||
Test that atomic_set() cannot break the atomicity of atomic RMWs.
|
||||
NOTE: Require herd7 7.56 or later which supports "(void)expr".
|
||||
|
||||
cmpxchg-fail-ordered-1.litmus
|
||||
Demonstrate that a failing cmpxchg() operation acts as a full barrier
|
||||
when followed by smp_mb__after_atomic().
|
||||
|
||||
cmpxchg-fail-ordered-2.litmus
|
||||
Demonstrate that a failing cmpxchg() operation acts as an acquire
|
||||
operation when followed by smp_mb__after_atomic().
|
||||
|
||||
cmpxchg-fail-unordered-1.litmus
|
||||
Demonstrate that a failing cmpxchg() operation does not act as a
|
||||
full barrier.
|
||||
|
||||
cmpxchg-fail-unordered-2.litmus
|
||||
Demonstrate that a failing cmpxchg() operation does not act as an
|
||||
acquire operation.
|
||||
|
||||
|
||||
locking (/locking directory)
|
||||
----------------------------
|
||||
|
||||
DCL-broken.litmus
|
||||
Demonstrates that double-checked locking needs more than just
|
||||
the obvious lock acquisitions and releases.
|
||||
|
||||
DCL-fixed.litmus
|
||||
Demonstrates corrected double-checked locking that uses
|
||||
smp_store_release() and smp_load_acquire() in addition to the
|
||||
obvious lock acquisitions and releases.
|
||||
|
||||
RM-broken.litmus
|
||||
Demonstrates problems with "roach motel" locking, where code is
|
||||
freely moved into lock-based critical sections. This example also
|
||||
shows how to use the "filter" clause to discard executions that
|
||||
would be excluded by other code not modeled in the litmus test.
|
||||
Note also that this "roach motel" optimization is emulated by
|
||||
physically moving P1()'s two reads from x under the lock.
|
||||
|
||||
What is a roach motel? This is from an old advertisement for
|
||||
a cockroach trap, much later featured in one of the "Men in
|
||||
Black" movies. "The roaches check in. They don't check out."
|
||||
|
||||
RM-fixed.litmus
|
||||
The counterpart to RM-broken.litmus, showing P0()'s two loads from
|
||||
x safely outside of the critical section.
|
||||
|
||||
|
||||
RCU (/rcu directory)
|
||||
--------------------
|
||||
|
||||
@@ -0,0 +1,35 @@
|
||||
C cmpxchg-fail-ordered-1
|
||||
|
||||
(*
|
||||
* Result: Never
|
||||
*
|
||||
* Demonstrate that a failing cmpxchg() operation will act as a full
|
||||
* barrier when followed by smp_mb__after_atomic().
|
||||
*)
|
||||
|
||||
{}
|
||||
|
||||
P0(int *x, int *y, int *z)
|
||||
{
|
||||
int r0;
|
||||
int r1;
|
||||
|
||||
WRITE_ONCE(*x, 1);
|
||||
r1 = cmpxchg(z, 1, 0);
|
||||
smp_mb__after_atomic();
|
||||
r0 = READ_ONCE(*y);
|
||||
}
|
||||
|
||||
P1(int *x, int *y, int *z)
|
||||
{
|
||||
int r0;
|
||||
int r1;
|
||||
|
||||
WRITE_ONCE(*y, 1);
|
||||
r1 = cmpxchg(z, 1, 0);
|
||||
smp_mb__after_atomic();
|
||||
r0 = READ_ONCE(*x);
|
||||
}
|
||||
|
||||
locations[0:r1;1:r1]
|
||||
exists (0:r0=0 /\ 1:r0=0)
|
||||
@@ -0,0 +1,30 @@
|
||||
C cmpxchg-fail-ordered-2
|
||||
|
||||
(*
|
||||
* Result: Never
|
||||
*
|
||||
* Demonstrate use of smp_mb__after_atomic() to make a failing cmpxchg
|
||||
* operation have acquire ordering.
|
||||
*)
|
||||
|
||||
{}
|
||||
|
||||
P0(int *x, int *y)
|
||||
{
|
||||
int r1;
|
||||
|
||||
WRITE_ONCE(*x, 1);
|
||||
r1 = cmpxchg(y, 0, 1);
|
||||
}
|
||||
|
||||
P1(int *x, int *y)
|
||||
{
|
||||
int r1;
|
||||
int r2;
|
||||
|
||||
r1 = cmpxchg(y, 0, 1);
|
||||
smp_mb__after_atomic();
|
||||
r2 = READ_ONCE(*x);
|
||||
}
|
||||
|
||||
exists (0:r1=0 /\ 1:r1=1 /\ 1:r2=0)
|
||||
@@ -0,0 +1,34 @@
|
||||
C cmpxchg-fail-unordered-1
|
||||
|
||||
(*
|
||||
* Result: Sometimes
|
||||
*
|
||||
* Demonstrate that a failing cmpxchg() operation does not act as a
|
||||
* full barrier. (In contrast, a successful cmpxchg() does act as a
|
||||
* full barrier.)
|
||||
*)
|
||||
|
||||
{}
|
||||
|
||||
P0(int *x, int *y, int *z)
|
||||
{
|
||||
int r0;
|
||||
int r1;
|
||||
|
||||
WRITE_ONCE(*x, 1);
|
||||
r1 = cmpxchg(z, 1, 0);
|
||||
r0 = READ_ONCE(*y);
|
||||
}
|
||||
|
||||
P1(int *x, int *y, int *z)
|
||||
{
|
||||
int r0;
|
||||
int r1;
|
||||
|
||||
WRITE_ONCE(*y, 1);
|
||||
r1 = cmpxchg(z, 1, 0);
|
||||
r0 = READ_ONCE(*x);
|
||||
}
|
||||
|
||||
locations[0:r1;1:r1]
|
||||
exists (0:r0=0 /\ 1:r0=0)
|
||||
@@ -0,0 +1,30 @@
|
||||
C cmpxchg-fail-unordered-2
|
||||
|
||||
(*
|
||||
* Result: Sometimes
|
||||
*
|
||||
* Demonstrate that a failing cmpxchg() operation does not act as either
|
||||
* an acquire release operation. (In contrast, a successful cmpxchg()
|
||||
* does act as both an acquire and a release operation.)
|
||||
*)
|
||||
|
||||
{}
|
||||
|
||||
P0(int *x, int *y)
|
||||
{
|
||||
int r1;
|
||||
|
||||
WRITE_ONCE(*x, 1);
|
||||
r1 = cmpxchg(y, 0, 1);
|
||||
}
|
||||
|
||||
P1(int *x, int *y)
|
||||
{
|
||||
int r1;
|
||||
int r2;
|
||||
|
||||
r1 = cmpxchg(y, 0, 1);
|
||||
r2 = READ_ONCE(*x);
|
||||
}
|
||||
|
||||
exists (0:r1=0 /\ 1:r1=1 /\ 1:r2=0)
|
||||
@@ -80,7 +80,7 @@ to the dentry cache with::
|
||||
|
||||
Debugging options may require the minimum possible slab order to increase as
|
||||
a result of storing the metadata (for example, caches with PAGE_SIZE object
|
||||
sizes). This has a higher liklihood of resulting in slab allocation errors
|
||||
sizes). This has a higher likelihood of resulting in slab allocation errors
|
||||
in low memory situations or if there's high fragmentation of memory. To
|
||||
switch off debugging for such caches by default, use::
|
||||
|
||||
|
||||
@@ -284,7 +284,7 @@ What else is there to known about regressions?
|
||||
Check out Documentation/admin-guide/reporting-regressions.rst, it covers a lot
|
||||
of other aspects you want might want to be aware of:
|
||||
|
||||
* the purpose of the "no regressions rule"
|
||||
* the purpose of the "no regressions" rule
|
||||
|
||||
* what issues actually qualify as regression
|
||||
|
||||
|
||||
@@ -6,29 +6,29 @@ Everything you ever wanted to know about Linux -stable releases
|
||||
Rules on what kind of patches are accepted, and which ones are not, into the
|
||||
"-stable" tree:
|
||||
|
||||
- It or an equivalent fix must already exist in Linus' tree (upstream).
|
||||
- It must be obviously correct and tested.
|
||||
- It cannot be bigger than 100 lines, with context.
|
||||
- It must follow the
|
||||
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
|
||||
rules.
|
||||
- It must either fix a real bug that bothers people or just add a device ID.
|
||||
To elaborate on the former:
|
||||
- It or an equivalent fix must already exist in Linux mainline (upstream).
|
||||
- It must be obviously correct and tested.
|
||||
- It cannot be bigger than 100 lines, with context.
|
||||
- It must follow the
|
||||
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
|
||||
rules.
|
||||
- It must either fix a real bug that bothers people or just add a device ID.
|
||||
To elaborate on the former:
|
||||
|
||||
- It fixes a problem like an oops, a hang, data corruption, a real security
|
||||
issue, a hardware quirk, a build error (but not for things marked
|
||||
CONFIG_BROKEN), or some "oh, that's not good" issue.
|
||||
- Serious issues as reported by a user of a distribution kernel may also
|
||||
be considered if they fix a notable performance or interactivity issue.
|
||||
As these fixes are not as obvious and have a higher risk of a subtle
|
||||
regression they should only be submitted by a distribution kernel
|
||||
maintainer and include an addendum linking to a bugzilla entry if it
|
||||
exists and additional information on the user-visible impact.
|
||||
- No "This could be a problem..." type of things like a "theoretical race
|
||||
condition", unless an explanation of how the bug can be exploited is also
|
||||
provided.
|
||||
- No "trivial" fixes without benefit for users (spelling changes, whitespace
|
||||
cleanups, etc).
|
||||
- It fixes a problem like an oops, a hang, data corruption, a real security
|
||||
issue, a hardware quirk, a build error (but not for things marked
|
||||
CONFIG_BROKEN), or some "oh, that's not good" issue.
|
||||
- Serious issues as reported by a user of a distribution kernel may also
|
||||
be considered if they fix a notable performance or interactivity issue.
|
||||
As these fixes are not as obvious and have a higher risk of a subtle
|
||||
regression they should only be submitted by a distribution kernel
|
||||
maintainer and include an addendum linking to a bugzilla entry if it
|
||||
exists and additional information on the user-visible impact.
|
||||
- No "This could be a problem..." type of things like a "theoretical race
|
||||
condition", unless an explanation of how the bug can be exploited is also
|
||||
provided.
|
||||
- No "trivial" fixes without benefit for users (spelling changes, whitespace
|
||||
cleanups, etc).
|
||||
|
||||
|
||||
Procedure for submitting patches to the -stable tree
|
||||
@@ -42,11 +42,11 @@ Procedure for submitting patches to the -stable tree
|
||||
|
||||
There are three options to submit a change to -stable trees:
|
||||
|
||||
1. Add a 'stable tag' to the description of a patch you then submit for
|
||||
mainline inclusion.
|
||||
2. Ask the stable team to pick up a patch already mainlined.
|
||||
3. Submit a patch to the stable team that is equivalent to a change already
|
||||
mainlined.
|
||||
1. Add a 'stable tag' to the description of a patch you then submit for
|
||||
mainline inclusion.
|
||||
2. Ask the stable team to pick up a patch already mainlined.
|
||||
3. Submit a patch to the stable team that is equivalent to a change already
|
||||
mainlined.
|
||||
|
||||
The sections below describe each of the options in more detail.
|
||||
|
||||
@@ -68,82 +68,72 @@ Option 1
|
||||
********
|
||||
|
||||
To have a patch you submit for mainline inclusion later automatically picked up
|
||||
for stable trees, add the tag
|
||||
for stable trees, add this tag in the sign-off area::
|
||||
|
||||
.. code-block:: none
|
||||
Cc: stable@vger.kernel.org
|
||||
|
||||
Cc: stable@vger.kernel.org
|
||||
Use ``Cc: stable@kernel.org`` instead when fixing unpublished vulnerabilities:
|
||||
it reduces the chance of accidentally exposing the fix to the public by way of
|
||||
'git send-email', as mails sent to that address are not delivered anywhere.
|
||||
|
||||
in the sign-off area. Once the patch is mainlined it will be applied to the
|
||||
stable tree without anything else needing to be done by the author or
|
||||
subsystem maintainer.
|
||||
Once the patch is mainlined it will be applied to the stable tree without
|
||||
anything else needing to be done by the author or subsystem maintainer.
|
||||
|
||||
To sent additional instructions to the stable team, use a shell-style inline
|
||||
comment:
|
||||
To send additional instructions to the stable team, use a shell-style inline
|
||||
comment to pass arbitrary or predefined notes:
|
||||
|
||||
* To specify any additional patch prerequisites for cherry picking use the
|
||||
following format in the sign-off area:
|
||||
* Specify any additional patch prerequisites for cherry picking::
|
||||
|
||||
.. code-block:: none
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x
|
||||
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
||||
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x
|
||||
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
||||
The tag sequence has the meaning of::
|
||||
|
||||
The tag sequence has the meaning of:
|
||||
git cherry-pick a1f84a3
|
||||
git cherry-pick 1b9508f
|
||||
git cherry-pick fd21073
|
||||
git cherry-pick <this commit>
|
||||
|
||||
.. code-block:: none
|
||||
Note that for a patch series, you do not have to list as prerequisites the
|
||||
patches present in the series itself. For example, if you have the following
|
||||
patch series::
|
||||
|
||||
git cherry-pick a1f84a3
|
||||
git cherry-pick 1b9508f
|
||||
git cherry-pick fd21073
|
||||
git cherry-pick <this commit>
|
||||
patch1
|
||||
patch2
|
||||
|
||||
Note that for a patch series, you do not have to list as prerequisites the
|
||||
patches present in the series itself. For example, if you have the following
|
||||
patch series:
|
||||
where patch2 depends on patch1, you do not have to list patch1 as
|
||||
prerequisite of patch2 if you have already marked patch1 for stable
|
||||
inclusion.
|
||||
|
||||
.. code-block:: none
|
||||
* Point out kernel version prerequisites::
|
||||
|
||||
patch1
|
||||
patch2
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x
|
||||
|
||||
where patch2 depends on patch1, you do not have to list patch1 as
|
||||
prerequisite of patch2 if you have already marked patch1 for stable
|
||||
inclusion.
|
||||
The tag has the meaning of::
|
||||
|
||||
* For patches that may have kernel version prerequisites specify them using
|
||||
the following format in the sign-off area:
|
||||
git cherry-pick <this commit>
|
||||
|
||||
.. code-block:: none
|
||||
For each "-stable" tree starting with the specified version.
|
||||
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x
|
||||
Note, such tagging is unnecessary if the stable team can derive the
|
||||
appropriate versions from Fixes: tags.
|
||||
|
||||
The tag has the meaning of:
|
||||
* Delay pick up of patches::
|
||||
|
||||
.. code-block:: none
|
||||
Cc: <stable@vger.kernel.org> # after -rc3
|
||||
|
||||
git cherry-pick <this commit>
|
||||
* Point out known problems::
|
||||
|
||||
For each "-stable" tree starting with the specified version.
|
||||
Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
|
||||
|
||||
Note, such tagging is unnecessary if the stable team can derive the
|
||||
appropriate versions from Fixes: tags.
|
||||
There furthermore is a variant of the stable tag you can use to make the stable
|
||||
team's backporting tools (e.g AUTOSEL or scripts that look for commits
|
||||
containing a 'Fixes:' tag) ignore a change::
|
||||
|
||||
* To delay pick up of patches, use the following format:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
Cc: <stable@vger.kernel.org> # after 4 weeks in mainline
|
||||
|
||||
* For any other requests, just add a note to the stable tag. This for example
|
||||
can be used to point out known problems:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
|
||||
Cc: <stable+noautosel@kernel.org> # reason goes here, and must be present
|
||||
|
||||
.. _option_2:
|
||||
|
||||
@@ -163,17 +153,13 @@ Option 3
|
||||
Send the patch, after verifying that it follows the above rules, to
|
||||
stable@vger.kernel.org and mention the kernel versions you wish it to be applied
|
||||
to. When doing so, you must note the upstream commit ID in the changelog of your
|
||||
submission with a separate line above the commit text, like this:
|
||||
submission with a separate line above the commit text, like this::
|
||||
|
||||
.. code-block:: none
|
||||
commit <sha1> upstream.
|
||||
|
||||
commit <sha1> upstream.
|
||||
Or alternatively::
|
||||
|
||||
or alternatively:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
[ Upstream commit <sha1> ]
|
||||
[ Upstream commit <sha1> ]
|
||||
|
||||
If the submitted patch deviates from the original upstream patch (for example
|
||||
because it had to be adjusted for the older API), this must be very clearly
|
||||
@@ -194,55 +180,55 @@ developers and by the relevant subsystem maintainer.
|
||||
Review cycle
|
||||
------------
|
||||
|
||||
- When the -stable maintainers decide for a review cycle, the patches will be
|
||||
sent to the review committee, and the maintainer of the affected area of
|
||||
the patch (unless the submitter is the maintainer of the area) and CC: to
|
||||
the linux-kernel mailing list.
|
||||
- The review committee has 48 hours in which to ACK or NAK the patch.
|
||||
- If the patch is rejected by a member of the committee, or linux-kernel
|
||||
members object to the patch, bringing up issues that the maintainers and
|
||||
members did not realize, the patch will be dropped from the queue.
|
||||
- The ACKed patches will be posted again as part of release candidate (-rc)
|
||||
to be tested by developers and testers.
|
||||
- Usually only one -rc release is made, however if there are any outstanding
|
||||
issues, some patches may be modified or dropped or additional patches may
|
||||
be queued. Additional -rc releases are then released and tested until no
|
||||
issues are found.
|
||||
- Responding to the -rc releases can be done on the mailing list by sending
|
||||
a "Tested-by:" email with any testing information desired. The "Tested-by:"
|
||||
tags will be collected and added to the release commit.
|
||||
- At the end of the review cycle, the new -stable release will be released
|
||||
containing all the queued and tested patches.
|
||||
- Security patches will be accepted into the -stable tree directly from the
|
||||
security kernel team, and not go through the normal review cycle.
|
||||
Contact the kernel security team for more details on this procedure.
|
||||
- When the -stable maintainers decide for a review cycle, the patches will be
|
||||
sent to the review committee, and the maintainer of the affected area of
|
||||
the patch (unless the submitter is the maintainer of the area) and CC: to
|
||||
the linux-kernel mailing list.
|
||||
- The review committee has 48 hours in which to ACK or NAK the patch.
|
||||
- If the patch is rejected by a member of the committee, or linux-kernel
|
||||
members object to the patch, bringing up issues that the maintainers and
|
||||
members did not realize, the patch will be dropped from the queue.
|
||||
- The ACKed patches will be posted again as part of release candidate (-rc)
|
||||
to be tested by developers and testers.
|
||||
- Usually only one -rc release is made, however if there are any outstanding
|
||||
issues, some patches may be modified or dropped or additional patches may
|
||||
be queued. Additional -rc releases are then released and tested until no
|
||||
issues are found.
|
||||
- Responding to the -rc releases can be done on the mailing list by sending
|
||||
a "Tested-by:" email with any testing information desired. The "Tested-by:"
|
||||
tags will be collected and added to the release commit.
|
||||
- At the end of the review cycle, the new -stable release will be released
|
||||
containing all the queued and tested patches.
|
||||
- Security patches will be accepted into the -stable tree directly from the
|
||||
security kernel team, and not go through the normal review cycle.
|
||||
Contact the kernel security team for more details on this procedure.
|
||||
|
||||
|
||||
Trees
|
||||
-----
|
||||
|
||||
- The queues of patches, for both completed versions and in progress
|
||||
versions can be found at:
|
||||
- The queues of patches, for both completed versions and in progress
|
||||
versions can be found at:
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
|
||||
|
||||
- The finalized and tagged releases of all stable kernels can be found
|
||||
in separate branches per version at:
|
||||
- The finalized and tagged releases of all stable kernels can be found
|
||||
in separate branches per version at:
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
|
||||
|
||||
- The release candidate of all stable kernel versions can be found at:
|
||||
- The release candidate of all stable kernel versions can be found at:
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
|
||||
|
||||
.. warning::
|
||||
The -stable-rc tree is a snapshot in time of the stable-queue tree and
|
||||
will change frequently, hence will be rebased often. It should only be
|
||||
used for testing purposes (e.g. to be consumed by CI systems).
|
||||
.. warning::
|
||||
The -stable-rc tree is a snapshot in time of the stable-queue tree and
|
||||
will change frequently, hence will be rebased often. It should only be
|
||||
used for testing purposes (e.g. to be consumed by CI systems).
|
||||
|
||||
|
||||
Review committee
|
||||
----------------
|
||||
|
||||
- This is made up of a number of kernel developers who have volunteered for
|
||||
this task, and a few that haven't.
|
||||
- This is made up of a number of kernel developers who have volunteered for
|
||||
this task, and a few that haven't.
|
||||
|
||||
@@ -81,7 +81,7 @@ A summary of the ``@optname`` entries is as follows::
|
||||
destination addresses.
|
||||
|
||||
SCTP_SENDMSG_CONNECT - Initiate a connection that is generated by a
|
||||
sendmsg(2) or sctp_sendmsg(3) on a new asociation.
|
||||
sendmsg(2) or sctp_sendmsg(3) on a new association.
|
||||
|
||||
SCTP_PRIMARY_ADDR - Set local primary address.
|
||||
|
||||
|
||||
@@ -42,6 +42,14 @@ safe.
|
||||
randomly generated and fused into each SoC at manufacturing time.
|
||||
Otherwise, a common fixed test key is used instead.
|
||||
|
||||
(4) DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs)
|
||||
|
||||
Rooted to a one-time programmable key (OTP) that is generally burnt
|
||||
in the on-chip fuses and is accessible to the DCP encryption engine only.
|
||||
DCP provides two keys that can be used as root of trust: the OTP key
|
||||
and the UNIQUE key. Default is to use the UNIQUE key, but selecting
|
||||
the OTP key can be done via a module parameter (dcp_use_otp_key).
|
||||
|
||||
* Execution isolation
|
||||
|
||||
(1) TPM
|
||||
@@ -57,6 +65,12 @@ safe.
|
||||
|
||||
Fixed set of operations running in isolated execution environment.
|
||||
|
||||
(4) DCP
|
||||
|
||||
Fixed set of cryptographic operations running in isolated execution
|
||||
environment. Only basic blob key encryption is executed there.
|
||||
The actual key sealing/unsealing is done on main processor/kernel space.
|
||||
|
||||
* Optional binding to platform integrity state
|
||||
|
||||
(1) TPM
|
||||
@@ -79,6 +93,11 @@ safe.
|
||||
Relies on the High Assurance Boot (HAB) mechanism of NXP SoCs
|
||||
for platform integrity.
|
||||
|
||||
(4) DCP
|
||||
|
||||
Relies on Secure/Trusted boot process (called HAB by vendor) for
|
||||
platform integrity.
|
||||
|
||||
* Interfaces and APIs
|
||||
|
||||
(1) TPM
|
||||
@@ -94,6 +113,11 @@ safe.
|
||||
|
||||
Interface is specific to silicon vendor.
|
||||
|
||||
(4) DCP
|
||||
|
||||
Vendor-specific API that is implemented as part of the DCP crypto driver in
|
||||
``drivers/crypto/mxs-dcp.c``.
|
||||
|
||||
* Threat model
|
||||
|
||||
The strength and appropriateness of a particular trust source for a given
|
||||
@@ -129,6 +153,13 @@ selected trust source:
|
||||
CAAM HWRNG, enable CRYPTO_DEV_FSL_CAAM_RNG_API and ensure the device
|
||||
is probed.
|
||||
|
||||
* DCP (Data Co-Processor: crypto accelerator of various i.MX SoCs)
|
||||
|
||||
The DCP hardware device itself does not provide a dedicated RNG interface,
|
||||
so the kernel default RNG is used. SoCs with DCP like the i.MX6ULL do have
|
||||
a dedicated hardware RNG that is independent from DCP which can be enabled
|
||||
to back the kernel RNG.
|
||||
|
||||
Users may override this by specifying ``trusted.rng=kernel`` on the kernel
|
||||
command-line to override the used RNG with the kernel's random number pool.
|
||||
|
||||
@@ -231,6 +262,19 @@ Usage::
|
||||
CAAM-specific format. The key length for new keys is always in bytes.
|
||||
Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
|
||||
|
||||
Trusted Keys usage: DCP
|
||||
-----------------------
|
||||
|
||||
Usage::
|
||||
|
||||
keyctl add trusted name "new keylen" ring
|
||||
keyctl add trusted name "load hex_blob" ring
|
||||
keyctl print keyid
|
||||
|
||||
"keyctl print" returns an ASCII hex copy of the sealed key, which is in format
|
||||
specific to this DCP key-blob implementation. The key length for new keys is
|
||||
always in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
|
||||
|
||||
Encrypted Keys usage
|
||||
--------------------
|
||||
|
||||
@@ -426,3 +470,12 @@ string length.
|
||||
privkey is the binary representation of TPM2B_PUBLIC excluding the
|
||||
initial TPM2B header which can be reconstructed from the ASN.1 octed
|
||||
string length.
|
||||
|
||||
DCP Blob Format
|
||||
---------------
|
||||
|
||||
.. kernel-doc:: security/keys/trusted-keys/trusted_dcp.c
|
||||
:doc: dcp blob format
|
||||
|
||||
.. kernel-doc:: security/keys/trusted-keys/trusted_dcp.c
|
||||
:identifiers: struct dcp_blob_fmt
|
||||
|
||||
@@ -4,7 +4,7 @@ Confidential Computing in Linux for x86 virtualization
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
By: Elena Reshetova <elena.reshetova@intel.com> and Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
By: Elena Reshetova <elena.reshetova@intel.com> and Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
||||
@@ -5,6 +5,8 @@ Trusted Platform Module documentation
|
||||
.. toctree::
|
||||
|
||||
tpm_event_log
|
||||
tpm-security
|
||||
tpm_tis
|
||||
tpm_vtpm_proxy
|
||||
xen-tpmfront
|
||||
tpm_ftpm_tee
|
||||
|
||||
@@ -0,0 +1,216 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0-only
|
||||
|
||||
TPM Security
|
||||
============
|
||||
|
||||
The object of this document is to describe how we make the kernel's
|
||||
use of the TPM reasonably robust in the face of external snooping and
|
||||
packet alteration attacks (called passive and active interposer attack
|
||||
in the literature). The current security document is for TPM 2.0.
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
The TPM is usually a discrete chip attached to a PC via some type of
|
||||
low bandwidth bus. There are exceptions to this such as the Intel
|
||||
PTT, which is a software TPM running inside a software environment
|
||||
close to the CPU, which are subject to different attacks, but right at
|
||||
the moment, most hardened security environments require a discrete
|
||||
hardware TPM, which is the use case discussed here.
|
||||
|
||||
Snooping and Alteration Attacks against the bus
|
||||
-----------------------------------------------
|
||||
|
||||
The current state of the art for snooping the `TPM Genie`_ hardware
|
||||
interposer which is a simple external device that can be installed in
|
||||
a couple of seconds on any system or laptop. Recently attacks were
|
||||
successfully demonstrated against the `Windows Bitlocker TPM`_ system.
|
||||
Most recently the same `attack against TPM based Linux disk
|
||||
encryption`_ schemes. The next phase of research seems to be hacking
|
||||
existing devices on the bus to act as interposers, so the fact that
|
||||
the attacker requires physical access for a few seconds might
|
||||
evaporate. However, the goal of this document is to protect TPM
|
||||
secrets and integrity as far as we are able in this environment and to
|
||||
try to insure that if we can't prevent the attack then at least we can
|
||||
detect it.
|
||||
|
||||
Unfortunately, most of the TPM functionality, including the hardware
|
||||
reset capability can be controlled by an attacker who has access to
|
||||
the bus, so we'll discuss some of the disruption possibilities below.
|
||||
|
||||
Measurement (PCR) Integrity
|
||||
---------------------------
|
||||
|
||||
Since the attacker can send their own commands to the TPM, they can
|
||||
send arbitrary PCR extends and thus disrupt the measurement system,
|
||||
which would be an annoying denial of service attack. However, there
|
||||
are two, more serious, classes of attack aimed at entities sealed to
|
||||
trust measurements.
|
||||
|
||||
1. The attacker could intercept all PCR extends coming from the system
|
||||
and completely substitute their own values, producing a replay of
|
||||
an untampered state that would cause PCR measurements to attest to
|
||||
a trusted state and release secrets
|
||||
|
||||
2. At some point in time the attacker could reset the TPM, clearing
|
||||
the PCRs and then send down their own measurements which would
|
||||
effectively overwrite the boot time measurements the TPM has
|
||||
already done.
|
||||
|
||||
The first can be thwarted by always doing HMAC protection of the PCR
|
||||
extend and read command meaning measurement values cannot be
|
||||
substituted without producing a detectable HMAC failure in the
|
||||
response. However, the second can only really be detected by relying
|
||||
on some sort of mechanism for protection which would change over TPM
|
||||
reset.
|
||||
|
||||
Secrets Guarding
|
||||
----------------
|
||||
|
||||
Certain information passing in and out of the TPM, such as key sealing
|
||||
and private key import and random number generation, is vulnerable to
|
||||
interception which HMAC protection alone cannot protect against, so
|
||||
for these types of command we must also employ request and response
|
||||
encryption to prevent the loss of secret information.
|
||||
|
||||
Establishing Initial Trust with the TPM
|
||||
---------------------------------------
|
||||
|
||||
In order to provide security from the beginning, an initial shared or
|
||||
asymmetric secret must be established which must also be unknown to
|
||||
the attacker. The most obvious avenues for this are the endorsement
|
||||
and storage seeds, which can be used to derive asymmetric keys.
|
||||
However, using these keys is difficult because the only way to pass
|
||||
them into the kernel would be on the command line, which requires
|
||||
extensive support in the boot system, and there's no guarantee that
|
||||
either hierarchy would not have some type of authorization.
|
||||
|
||||
The mechanism chosen for the Linux Kernel is to derive the primary
|
||||
elliptic curve key from the null seed using the standard storage seed
|
||||
parameters. The null seed has two advantages: firstly the hierarchy
|
||||
physically cannot have an authorization, so we are always able to use
|
||||
it and secondly, the null seed changes across TPM resets, meaning if
|
||||
we establish trust on the null seed at start of day, all sessions
|
||||
salted with the derived key will fail if the TPM is reset and the seed
|
||||
changes.
|
||||
|
||||
Obviously using the null seed without any other prior shared secrets,
|
||||
we have to create and read the initial public key which could, of
|
||||
course, be intercepted and substituted by the bus interposer.
|
||||
However, the TPM has a key certification mechanism (using the EK
|
||||
endorsement certificate, creating an attestation identity key and
|
||||
certifying the null seed primary with that key) which is too complex
|
||||
to run within the kernel, so we keep a copy of the null primary key
|
||||
name, which is what is exported via sysfs so user-space can run the
|
||||
full certification when it boots. The definitive guarantee here is
|
||||
that if the null primary key certifies correctly, you know all your
|
||||
TPM transactions since start of day were secure and if it doesn't, you
|
||||
know there's an interposer on your system (and that any secret used
|
||||
during boot may have been leaked).
|
||||
|
||||
Stacking Trust
|
||||
--------------
|
||||
|
||||
In the current null primary scenario, the TPM must be completely
|
||||
cleared before handing it on to the next consumer. However the kernel
|
||||
hands to user-space the name of the derived null seed key which can
|
||||
then be verified by certification in user-space. Therefore, this chain
|
||||
of name handoff can be used between the various boot components as
|
||||
well (via an unspecified mechanism). For instance, grub could use the
|
||||
null seed scheme for security and hand the name off to the kernel in
|
||||
the boot area. The kernel could make its own derivation of the key
|
||||
and the name and know definitively that if they differ from the handed
|
||||
off version that tampering has occurred. Thus it becomes possible to
|
||||
chain arbitrary boot components together (UEFI to grub to kernel) via
|
||||
the name handoff provided each successive component knows how to
|
||||
collect the name and verifies it against its derived key.
|
||||
|
||||
Session Properties
|
||||
------------------
|
||||
|
||||
All TPM commands the kernel uses allow sessions. HMAC sessions may be
|
||||
used to check the integrity of requests and responses and decrypt and
|
||||
encrypt flags may be used to shield parameters and responses. The
|
||||
HMAC and encryption keys are usually derived from the shared
|
||||
authorization secret, but for a lot of kernel operations that is well
|
||||
known (and usually empty). Thus, every HMAC session used by the
|
||||
kernel must be created using the null primary key as the salt key
|
||||
which thus provides a cryptographic input into the session key
|
||||
derivation. Thus, the kernel creates the null primary key once (as a
|
||||
volatile TPM handle) and keeps it around in a saved context stored in
|
||||
tpm_chip for every in-kernel use of the TPM. Currently, because of a
|
||||
lack of de-gapping in the in-kernel resource manager, the session must
|
||||
be created and destroyed for each operation, but, in future, a single
|
||||
session may also be reused for the in-kernel HMAC, encryption and
|
||||
decryption sessions.
|
||||
|
||||
Protection Types
|
||||
----------------
|
||||
|
||||
For every in-kernel operation we use null primary salted HMAC to
|
||||
protect the integrity. Additionally, we use parameter encryption to
|
||||
protect key sealing and parameter decryption to protect key unsealing
|
||||
and random number generation.
|
||||
|
||||
Null Primary Key Certification in Userspace
|
||||
===========================================
|
||||
|
||||
Every TPM comes shipped with a couple of X.509 certificates for the
|
||||
primary endorsement key. This document assumes that the Elliptic
|
||||
Curve version of the certificate exists at 01C00002, but will work
|
||||
equally well with the RSA certificate (at 01C00001).
|
||||
|
||||
The first step in the certification is primary creation using the
|
||||
template from the `TCG EK Credential Profile`_ which allows comparison
|
||||
of the generated primary key against the one in the certificate (the
|
||||
public key must match). Note that generation of the EK primary
|
||||
requires the EK hierarchy password, but a pre-generated version of the
|
||||
EC primary should exist at 81010002 and a TPM2_ReadPublic() may be
|
||||
performed on this without needing the key authority. Next, the
|
||||
certificate itself must be verified to chain back to the manufacturer
|
||||
root (which should be published on the manufacturer website). Once
|
||||
this is done, an attestation key (AK) is generated within the TPM and
|
||||
it's name and the EK public key can be used to encrypt a secret using
|
||||
TPM2_MakeCredential. The TPM then runs TPM2_ActivateCredential which
|
||||
will only recover the secret if the binding between the TPM, the EK
|
||||
and the AK is true. the generated AK may now be used to run a
|
||||
certification of the null primary key whose name the kernel has
|
||||
exported. Since TPM2_MakeCredential/ActivateCredential are somewhat
|
||||
complicated, a more simplified process involving an externally
|
||||
generated private key is described below.
|
||||
|
||||
This process is a simplified abbreviation of the usual privacy CA
|
||||
based attestation process. The assumption here is that the
|
||||
attestation is done by the TPM owner who thus has access to only the
|
||||
owner hierarchy. The owner creates an external public/private key
|
||||
pair (assume elliptic curve in this case) and wraps the private key
|
||||
for import using an inner wrapping process and parented to the EC
|
||||
derived storage primary. The TPM2_Import() is done using a parameter
|
||||
decryption HMAC session salted to the EK primary (which also does not
|
||||
require the EK key authority) meaning that the inner wrapping key is
|
||||
the encrypted parameter and thus the TPM will not be able to perform
|
||||
the import unless is possesses the certified EK so if the command
|
||||
succeeds and the HMAC verifies on return we know we have a loadable
|
||||
copy of the private key only for the certified TPM. This key is now
|
||||
loaded into the TPM and the Storage primary flushed (to free up space
|
||||
for the null key generation).
|
||||
|
||||
The null EC primary is now generated using the Storage profile
|
||||
outlined in the `TCG TPM v2.0 Provisioning Guidance`_; the name of
|
||||
this key (the hash of the public area) is computed and compared to the
|
||||
null seed name presented by the kernel in
|
||||
/sys/class/tpm/tpm0/null_name. If the names do not match, the TPM is
|
||||
compromised. If the names match, the user performs a TPM2_Certify()
|
||||
using the null primary as the object handle and the loaded private key
|
||||
as the sign handle and providing randomized qualifying data. The
|
||||
signature of the returned certifyInfo is verified against the public
|
||||
part of the loaded private key and the qualifying data checked to
|
||||
prevent replay. If all of these tests pass, the user is now assured
|
||||
that TPM integrity and privacy was preserved across the entire boot
|
||||
sequence of this kernel.
|
||||
|
||||
.. _TPM Genie: https://www.nccgroup.trust/globalassets/about-us/us/documents/tpm-genie.pdf
|
||||
.. _Windows Bitlocker TPM: https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network
|
||||
.. _attack against TPM based Linux disk encryption: https://www.secura.com/blog/tpm-sniffing-attacks-against-non-bitlocker-targets
|
||||
.. _TCG EK Credential Profile: https://trustedcomputinggroup.org/resource/tcg-ek-credential-profile-for-tpm-family-2-0/
|
||||
.. _TCG TPM v2.0 Provisioning Guidance: https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
|
||||
@@ -0,0 +1,46 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=========================
|
||||
TPM FIFO interface driver
|
||||
=========================
|
||||
|
||||
TCG PTP Specification defines two interface types: FIFO and CRB. The former is
|
||||
based on sequenced read and write operations, and the latter is based on a
|
||||
buffer containing the full command or response.
|
||||
|
||||
FIFO (First-In-First-Out) interface is used by the tpm_tis_core dependent
|
||||
drivers. Originally Linux had only a driver called tpm_tis, which covered
|
||||
memory mapped (aka MMIO) interface but it was later on extended to cover other
|
||||
physical interfaces supported by the TCG standard.
|
||||
|
||||
For historical reasons above the original MMIO driver is called tpm_tis and the
|
||||
framework for FIFO drivers is named as tpm_tis_core. The postfix "tis" in
|
||||
tpm_tis comes from the TPM Interface Specification, which is the hardware
|
||||
interface specification for TPM 1.x chips.
|
||||
|
||||
Communication is based on a 20 KiB buffer shared by the TPM chip through a
|
||||
hardware bus or memory map, depending on the physical wiring. The buffer is
|
||||
further split into five equal-size 4 KiB buffers, which provide equivalent
|
||||
sets of registers for communication between the CPU and TPM. These
|
||||
communication endpoints are called localities in the TCG terminology.
|
||||
|
||||
When the kernel wants to send commands to the TPM chip, it first reserves
|
||||
locality 0 by setting the requestUse bit in the TPM_ACCESS register. The bit is
|
||||
cleared by the chip when the access is granted. Once it completes its
|
||||
communication, the kernel writes the TPM_ACCESS.activeLocality bit. This
|
||||
informs the chip that the locality has been relinquished.
|
||||
|
||||
Pending localities are served in order by the chip in descending order, one at
|
||||
a time:
|
||||
|
||||
- Locality 0 has the lowest priority.
|
||||
- Locality 5 has the highest priority.
|
||||
|
||||
Further information on the purpose and meaning of the localities can be found
|
||||
in section 3.2 of the TCG PC Client Platform TPM Profile Specification.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
TCG PC Client Platform TPM Profile (PTP) Specification
|
||||
https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/
|
||||
@@ -97,7 +97,6 @@ class KernelInclude(Include):
|
||||
# HINT: this is the only line I had to change / commented out:
|
||||
#path = utils.relative_path(None, path)
|
||||
|
||||
path = nodes.reprunicode(path)
|
||||
encoding = self.options.get(
|
||||
'encoding', self.state.document.settings.input_encoding)
|
||||
e_handler=self.state.document.settings.input_encoding_error_handler
|
||||
|
||||
@@ -215,11 +215,12 @@
|
||||
due to the lack of suitable font families and/or the texlive-xecjk
|
||||
package.
|
||||
|
||||
If you want them, please install ``Noto Sans CJK'' font families
|
||||
along with the texlive-xecjk package by following instructions from
|
||||
If you want them, please install non-variable ``Noto Sans CJK''
|
||||
font families along with the texlive-xecjk package by following
|
||||
instructions from
|
||||
\sphinxcode{./scripts/sphinx-pre-install}.
|
||||
Having optional ``Noto Serif CJK'' font families will improve
|
||||
the looks of those translations.
|
||||
Having optional non-variable ``Noto Serif CJK'' font families will
|
||||
improve the looks of those translations.
|
||||
\end{sphinxadmonition}}
|
||||
\newcommand{\kerneldocEndSC}{}
|
||||
\newcommand{\kerneldocBeginTC}[1]{}
|
||||
|
||||
@@ -10,6 +10,7 @@ TEE Subsystem
|
||||
tee
|
||||
op-tee
|
||||
amd-tee
|
||||
ts-tee
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
|
||||
@@ -0,0 +1,71 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=================================
|
||||
TS-TEE (Trusted Services project)
|
||||
=================================
|
||||
|
||||
This driver provides access to secure services implemented by Trusted Services.
|
||||
|
||||
Trusted Services [1] is a TrustedFirmware.org project that provides a framework
|
||||
for developing and deploying device Root of Trust services in FF-A [2] S-EL0
|
||||
Secure Partitions. The project hosts the reference implementation of the Arm
|
||||
Platform Security Architecture [3] for Arm A-profile devices.
|
||||
|
||||
The FF-A Secure Partitions (SP) are accessible through the FF-A driver [4] which
|
||||
provides the low level communication for this driver. On top of that the Trusted
|
||||
Services RPC protocol is used [5]. To use the driver from user space a reference
|
||||
implementation is provided at [6], which is part of the Trusted Services client
|
||||
library called libts [7].
|
||||
|
||||
All Trusted Services (TS) SPs have the same FF-A UUID; it identifies the TS RPC
|
||||
protocol. A TS SP can host one or more services (e.g. PSA Crypto, PSA ITS, etc).
|
||||
A service is identified by its service UUID; the same type of service cannot be
|
||||
present twice in the same SP. During SP boot each service in the SP is assigned
|
||||
an "interface ID". This is just a short ID to simplify message addressing.
|
||||
|
||||
The generic TEE design is to share memory at once with the Trusted OS, which can
|
||||
then be reused to communicate with multiple applications running on the Trusted
|
||||
OS. However, in case of FF-A, memory sharing works on an endpoint level, i.e.
|
||||
memory is shared with a specific SP. User space has to be able to separately
|
||||
share memory with each SP based on its endpoint ID; therefore a separate TEE
|
||||
device is registered for each discovered TS SP. Opening the SP corresponds to
|
||||
opening the TEE device and creating a TEE context. A TS SP hosts one or more
|
||||
services. Opening a service corresponds to opening a session in the given
|
||||
tee_context.
|
||||
|
||||
Overview of a system with Trusted Services components::
|
||||
|
||||
User space Kernel space Secure world
|
||||
~~~~~~~~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~
|
||||
+--------+ +-------------+
|
||||
| Client | | Trusted |
|
||||
+--------+ | Services SP |
|
||||
/\ +-------------+
|
||||
|| /\
|
||||
|| ||
|
||||
|| ||
|
||||
\/ \/
|
||||
+-------+ +----------+--------+ +-------------+
|
||||
| libts | | TEE | TS-TEE | | FF-A SPMC |
|
||||
| | | subsys | driver | | + SPMD |
|
||||
+-------+----------------+----+-----+--------+-----------+-------------+
|
||||
| Generic TEE API | | FF-A | TS RPC protocol |
|
||||
| IOCTL (TEE_IOC_*) | | driver | over FF-A |
|
||||
+-----------------------------+ +--------+-------------------------+
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
[1] https://www.trustedfirmware.org/projects/trusted-services/
|
||||
|
||||
[2] https://developer.arm.com/documentation/den0077/
|
||||
|
||||
[3] https://www.arm.com/architecture/security-features/platform-security
|
||||
|
||||
[4] drivers/firmware/arm_ffa/
|
||||
|
||||
[5] https://trusted-services.readthedocs.io/en/v1.0.0/developer/service-access-protocols.html#abi
|
||||
|
||||
[6] https://git.trustedfirmware.org/TS/trusted-services.git/tree/components/rpc/ts_rpc/caller/linux/ts_rpc_caller_linux.c?h=v1.0.0
|
||||
|
||||
[7] https://git.trustedfirmware.org/TS/trusted-services.git/tree/deployments/libts/arm-linux/CMakeLists.txt?h=v1.0.0
|
||||
@@ -74,7 +74,7 @@ Function arguments at exit
|
||||
--------------------------
|
||||
Function arguments can be accessed at exit probe using $arg<N> fetcharg. This
|
||||
is useful to record the function parameter and return value at once, and
|
||||
trace the difference of structure fields (for debuging a function whether it
|
||||
trace the difference of structure fields (for debugging a function whether it
|
||||
correctly updates the given data structure or not)
|
||||
See the :ref:`sample<fprobetrace_exit_args_sample>` below for how it works.
|
||||
|
||||
@@ -248,4 +248,4 @@ mode. You can trace that changes with return probe.
|
||||
cat-143 [007] ...1. 1945.720616: vfs_open__entry: (vfs_open+0x4/0x40) mode=0x1 inode=0x0
|
||||
cat-143 [007] ...1. 1945.728263: vfs_open__exit: (do_open+0x274/0x3d0 <- vfs_open) mode=0xa800d inode=0xffff888004ada8d8
|
||||
|
||||
You can see the `file::f_mode` and `file::f_inode` are upated in `vfs_open()`.
|
||||
You can see the `file::f_mode` and `file::f_inode` are updated in `vfs_open()`.
|
||||
|
||||
@@ -1968,7 +1968,7 @@ wakeup
|
||||
One common case that people are interested in tracing is the
|
||||
time it takes for a task that is woken to actually wake up.
|
||||
Now for non Real-Time tasks, this can be arbitrary. But tracing
|
||||
it none the less can be interesting.
|
||||
it nonetheless can be interesting.
|
||||
|
||||
Without function tracing::
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user