linuxmsm/laptops-kernel
0
0
Fork 0
mirror of https://github.com/linux-msm/laptops-kernel.git synced 2026-08-13 14:19:53 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

Browse Source 
Cross-merge networking fixes after downstream PR (net-6.15-rc3).

No conflicts. Adjacent changes:

tools/net/ynl/pyynl/ynl_gen_c.py
  4d07bbf2d4 ("tools: ynl-gen: don't declare loop iterator in place")
  7e8ba0c7de ("tools: ynl: don't use genlmsghdr in classic netlink")

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This commit is contained in:
Jakub Kicinski
2025-04-17 12:26:50 -07:00
parent 22ab6b9467 b5c6891b2c
commit 240ce924d2
451 changed files with 5288 additions and 2649 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.mailmap
+5
View File
@@ -322,6 +322,7 @@ Jayachandran C <c.jayachandran@gmail.com> <jchandra@broadcom.com>
Jayachandran C <c.jayachandran@gmail.com> <jchandra@digeo.com>
Jayachandran C <c.jayachandran@gmail.com> <jnair@caviumnetworks.com>
<jean-philippe@linaro.org> <jean-philippe.brucker@arm.com>
Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org> <jeanmichel.hautbois@ideasonboard.com>
Jean Tourrilhes <jt@hpl.hp.com>
Jeevan Shriram <quic_jshriram@quicinc.com> <jshriram@codeaurora.org>
Jeff Garzik <jgarzik@pretzel.yyz.us>
@@ -438,6 +439,8 @@ Linus Lüssing <linus.luessing@c0d3.blue> <ll@simonwunderlich.de>
Li Yang <leoyang.li@nxp.com> <leoli@freescale.com>
Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
Lior David <quic_liord@quicinc.com> <liord@codeaurora.org>
Loic Poulain <loic.poulain@oss.qualcomm.com> <loic.poulain@linaro.org>
Loic Poulain <loic.poulain@oss.qualcomm.com> <loic.poulain@intel.com>
Lorenzo Pieralisi <lpieralisi@kernel.org> <lorenzo.pieralisi@arm.com>
Lorenzo Stoakes <lorenzo.stoakes@oracle.com> <lstoakes@gmail.com>
Luca Ceresoli <luca.ceresoli@bootlin.com> <luca@lucaceresoli.net>
@@ -685,6 +688,8 @@ Simon Wunderlich <sw@simonwunderlich.de> <simon.wunderlich@saxnet.de>
Simon Wunderlich <sw@simonwunderlich.de> <simon@open-mesh.com>
Simon Wunderlich <sw@simonwunderlich.de> <siwu@hrz.tu-chemnitz.de>
Sricharan Ramabadhran <quic_srichara@quicinc.com> <sricharan@codeaurora.org>
Srinivas Kandagatla <srini@kernel.org> <srinivas.kandagatla@st.com>
Srinivas Kandagatla <srini@kernel.org> <srinivas.kandagatla@linaro.org>
Srinivas Ramana <quic_sramana@quicinc.com> <sramana@codeaurora.org>
Sriram R <quic_srirrama@quicinc.com> <srirrama@codeaurora.org>
Sriram Yagnaraman <sriram.yagnaraman@ericsson.com> <sriram.yagnaraman@est.tech>
Documentation/ABI/testing/sysfs-driver-ufs
+32
View File
@@ -1604,3 +1604,35 @@ Description:
prevent the UFS from frequently performing clock gating/ungating.
The attribute is read/write.
What: /sys/bus/platform/drivers/ufshcd/*/device_lvl_exception_count
What: /sys/bus/platform/devices/*.ufs/device_lvl_exception_count
Date: March 2025
Contact: Bao D. Nguyen <quic_nguyenb@quicinc.com>
Description:
This attribute is applicable to ufs devices compliant to the
JEDEC specifications version 4.1 or later. The
device_lvl_exception_count is a counter indicating the number of
times the device level exceptions have occurred since the last
time this variable is reset. Writing a 0 value to this
attribute will reset the device_lvl_exception_count. If the
device_lvl_exception_count reads a positive value, the user
application should read the device_lvl_exception_id attribute to
know more information about the exception.
The attribute is read/write.
What: /sys/bus/platform/drivers/ufshcd/*/device_lvl_exception_id
What: /sys/bus/platform/devices/*.ufs/device_lvl_exception_id
Date: March 2025
Contact: Bao D. Nguyen <quic_nguyenb@quicinc.com>
Description:
Reading the device_lvl_exception_id returns the
qDeviceLevelExceptionID attribute of the ufs device JEDEC
specification version 4.1. The definition of the
qDeviceLevelExceptionID is the ufs device vendor specific
implementation. Refer to the device manufacturer datasheet for
more information on the meaning of the qDeviceLevelExceptionID
attribute value.
The attribute is read only.
Documentation/admin-guide/hw-vuln/index.rst
+1
View File
@@ -22,3 +22,4 @@ are configurable at compile, boot or run time.
srso
gather_data_sampling
reg-file-data-sampling
rsb
Documentation/admin-guide/hw-vuln/rsb.rst
+268
View File
@@ -0,0 +1,268 @@
.. SPDX-License-Identifier: GPL-2.0
=======================
RSB-related mitigations
=======================
.. warning::
Please keep this document up-to-date, otherwise you will be
volunteered to update it and convert it to a very long comment in
bugs.c!
Since 2018 there have been many Spectre CVEs related to the Return Stack
Buffer (RSB) (sometimes referred to as the Return Address Stack (RAS) or
Return Address Predictor (RAP) on AMD).
Information about these CVEs and how to mitigate them is scattered
amongst a myriad of microarchitecture-specific documents.
This document attempts to consolidate all the relevant information in
once place and clarify the reasoning behind the current RSB-related
mitigations. It's meant to be as concise as possible, focused only on
the current kernel mitigations: what are the RSB-related attack vectors
and how are they currently being mitigated?
It's *not* meant to describe how the RSB mechanism operates or how the
exploits work. More details about those can be found in the references
below.
Rather, this is basically a glorified comment, but too long to actually
be one. So when the next CVE comes along, a kernel developer can
quickly refer to this as a refresher to see what we're actually doing
and why.
At a high level, there are two classes of RSB attacks: RSB poisoning
(Intel and AMD) and RSB underflow (Intel only). They must each be
considered individually for each attack vector (and microarchitecture
where applicable).
----
RSB poisoning (Intel and AMD)
=============================
SpectreRSB
~~~~~~~~~~
RSB poisoning is a technique used by SpectreRSB [#spectre-rsb]_ where
an attacker poisons an RSB entry to cause a victim's return instruction
to speculate to an attacker-controlled address. This can happen when
there are unbalanced CALLs/RETs after a context switch or VMEXIT.
* All attack vectors can potentially be mitigated by flushing out any
poisoned RSB entries using an RSB filling sequence
[#intel-rsb-filling]_ [#amd-rsb-filling]_ when transitioning between
untrusted and trusted domains. But this has a performance impact and
should be avoided whenever possible.
.. DANGER::
**FIXME**: Currently we're flushing 32 entries. However, some CPU
models have more than 32 entries. The loop count needs to be
increased for those. More detailed information is needed about RSB
sizes.
* On context switch, the user->user mitigation requires ensuring the
RSB gets filled or cleared whenever IBPB gets written [#cond-ibpb]_
during a context switch:
* AMD:
On Zen 4+, IBPB (or SBPB [#amd-sbpb]_ if used) clears the RSB.
This is indicated by IBPB_RET in CPUID [#amd-ibpb-rsb]_.
On Zen < 4, the RSB filling sequence [#amd-rsb-filling]_ must be
always be done in addition to IBPB [#amd-ibpb-no-rsb]_. This is
indicated by X86_BUG_IBPB_NO_RET.
* Intel:
IBPB always clears the RSB:
"Software that executed before the IBPB command cannot control
the predicted targets of indirect branches executed after the
command on the same logical processor. The term indirect branch
in this context includes near return instructions, so these
predicted targets may come from the RSB." [#intel-ibpb-rsb]_
* On context switch, user->kernel attacks are prevented by SMEP. User
space can only insert user space addresses into the RSB. Even
non-canonical addresses can't be inserted due to the page gap at the
end of the user canonical address space reserved by TASK_SIZE_MAX.
A SMEP #PF at instruction fetch prevents the kernel from speculatively
executing user space.
* AMD:
"Finally, branches that are predicted as 'ret' instructions get
their predicted targets from the Return Address Predictor (RAP).
AMD recommends software use a RAP stuffing sequence (mitigation
V2-3 in [2]) and/or Supervisor Mode Execution Protection (SMEP)
to ensure that the addresses in the RAP are safe for
speculation. Collectively, we refer to these mitigations as "RAP
Protection"." [#amd-smep-rsb]_
* Intel:
"On processors with enhanced IBRS, an RSB overwrite sequence may
not suffice to prevent the predicted target of a near return
from using an RSB entry created in a less privileged predictor
mode. Software can prevent this by enabling SMEP (for
transitions from user mode to supervisor mode) and by having
IA32_SPEC_CTRL.IBRS set during VM exits." [#intel-smep-rsb]_
* On VMEXIT, guest->host attacks are mitigated by eIBRS (and PBRSB
mitigation if needed):
* AMD:
"When Automatic IBRS is enabled, the internal return address
stack used for return address predictions is cleared on VMEXIT."
[#amd-eibrs-vmexit]_
* Intel:
"On processors with enhanced IBRS, an RSB overwrite sequence may
not suffice to prevent the predicted target of a near return
from using an RSB entry created in a less privileged predictor
mode. Software can prevent this by enabling SMEP (for
transitions from user mode to supervisor mode) and by having
IA32_SPEC_CTRL.IBRS set during VM exits. Processors with
enhanced IBRS still support the usage model where IBRS is set
only in the OS/VMM for OSes that enable SMEP. To do this, such
processors will ensure that guest behavior cannot control the
RSB after a VM exit once IBRS is set, even if IBRS was not set
at the time of the VM exit." [#intel-eibrs-vmexit]_
Note that some Intel CPUs are susceptible to Post-barrier Return
Stack Buffer Predictions (PBRSB) [#intel-pbrsb]_, where the last
CALL from the guest can be used to predict the first unbalanced RET.
In this case the PBRSB mitigation is needed in addition to eIBRS.
AMD RETBleed / SRSO / Branch Type Confusion
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On AMD, poisoned RSB entries can also be created by the AMD RETBleed
variant [#retbleed-paper]_ [#amd-btc]_ or by Speculative Return Stack
Overflow [#amd-srso]_ (Inception [#inception-paper]_). The kernel
protects itself by replacing every RET in the kernel with a branch to a
single safe RET.
----
RSB underflow (Intel only)
==========================
RSB Alternate (RSBA) ("Intel Retbleed")
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Some Intel Skylake-generation CPUs are susceptible to the Intel variant
of RETBleed [#retbleed-paper]_ (Return Stack Buffer Underflow
[#intel-rsbu]_). If a RET is executed when the RSB buffer is empty due
to mismatched CALLs/RETs or returning from a deep call stack, the branch
predictor can fall back to using the Branch Target Buffer (BTB). If a
user forces a BTB collision then the RET can speculatively branch to a
user-controlled address.
* Note that RSB filling doesn't fully mitigate this issue. If there
are enough unbalanced RETs, the RSB may still underflow and fall back
to using a poisoned BTB entry.
* On context switch, user->user underflow attacks are mitigated by the
conditional IBPB [#cond-ibpb]_ on context switch which effectively
clears the BTB:
* "The indirect branch predictor barrier (IBPB) is an indirect branch
control mechanism that establishes a barrier, preventing software
that executed before the barrier from controlling the predicted
targets of indirect branches executed after the barrier on the same
logical processor." [#intel-ibpb-btb]_
* On context switch and VMEXIT, user->kernel and guest->host RSB
underflows are mitigated by IBRS or eIBRS:
* "Enabling IBRS (including enhanced IBRS) will mitigate the "RSBU"
attack demonstrated by the researchers. As previously documented,
Intel recommends the use of enhanced IBRS, where supported. This
includes any processor that enumerates RRSBA but not RRSBA_DIS_S."
[#intel-rsbu]_
However, note that eIBRS and IBRS do not mitigate intra-mode attacks.
Like RRSBA below, this is mitigated by clearing the BHB on kernel
entry.
As an alternative to classic IBRS, call depth tracking (combined with
retpolines) can be used to track kernel returns and fill the RSB when
it gets close to being empty.
Restricted RSB Alternate (RRSBA)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Some newer Intel CPUs have Restricted RSB Alternate (RRSBA) behavior,
which, similar to RSBA described above, also falls back to using the BTB
on RSB underflow. The only difference is that the predicted targets are
restricted to the current domain when eIBRS is enabled:
* "Restricted RSB Alternate (RRSBA) behavior allows alternate branch
predictors to be used by near RET instructions when the RSB is
empty. When eIBRS is enabled, the predicted targets of these
alternate predictors are restricted to those belonging to the
indirect branch predictor entries of the current prediction domain.
[#intel-eibrs-rrsba]_
When a CPU with RRSBA is vulnerable to Branch History Injection
[#bhi-paper]_ [#intel-bhi]_, an RSB underflow could be used for an
intra-mode BTI attack. This is mitigated by clearing the BHB on
kernel entry.
However if the kernel uses retpolines instead of eIBRS, it needs to
disable RRSBA:
* "Where software is using retpoline as a mitigation for BHI or
intra-mode BTI, and the processor both enumerates RRSBA and
enumerates RRSBA_DIS controls, it should disable this behavior."
[#intel-retpoline-rrsba]_
----
References
==========
.. [#spectre-rsb] `Spectre Returns! Speculation Attacks using the Return Stack Buffer <https://arxiv.org/pdf/1807.07940.pdf>`_
.. [#intel-rsb-filling] "Empty RSB Mitigation on Skylake-generation" in `Retpoline: A Branch Target Injection Mitigation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/retpoline-branch-target-injection-mitigation.html#inpage-nav-5-1>`_
.. [#amd-rsb-filling] "Mitigation V2-3" in `Software Techniques for Managing Speculation <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/software-techniques-for-managing-speculation.pdf>`_
.. [#cond-ibpb] Whether IBPB is written depends on whether the prev and/or next task is protected from Spectre attacks. It typically requires opting in per task or system-wide. For more details see the documentation for the ``spectre_v2_user`` cmdline option in Documentation/admin-guide/kernel-parameters.txt.
.. [#amd-sbpb] IBPB without flushing of branch type predictions. Only exists for AMD.
.. [#amd-ibpb-rsb] "Function 8000_0008h -- Processor Capacity Parameters and Extended Feature Identification" in `AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System Instructions <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24594.pdf>`_. SBPB behaves the same way according to `this email <https://lore.kernel.org/5175b163a3736ca5fd01cedf406735636c99a>`_.
.. [#amd-ibpb-no-rsb] `Spectre Attacks: Exploiting Speculative Execution <https://comsec.ethz.ch/wp-content/files/ibpb_sp25.pdf>`_
.. [#intel-ibpb-rsb] "Introduction" in `Post-barrier Return Stack Buffer Predictions / CVE-2022-26373 / INTEL-SA-00706 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/post-barrier-return-stack-buffer-predictions.html>`_
.. [#amd-smep-rsb] "Existing Mitigations" in `Technical Guidance for Mitigating Branch Type Confusion <https://www.amd.com/content/dam/amd/en/documents/resources/technical-guidance-for-mitigating-branch-type-confusion.pdf>`_
.. [#intel-smep-rsb] "Enhanced IBRS" in `Indirect Branch Restricted Speculation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-restricted-speculation.html>`_
.. [#amd-eibrs-vmexit] "Extended Feature Enable Register (EFER)" in `AMD64 Architecture Programmer's Manual Volume 2: System Programming <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf>`_
.. [#intel-eibrs-vmexit] "Enhanced IBRS" in `Indirect Branch Restricted Speculation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-restricted-speculation.html>`_
.. [#intel-pbrsb] `Post-barrier Return Stack Buffer Predictions / CVE-2022-26373 / INTEL-SA-00706 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/post-barrier-return-stack-buffer-predictions.html>`_
.. [#retbleed-paper] `RETBleed: Arbitrary Speculative Code Execution with Return Instruction <https://comsec.ethz.ch/wp-content/files/retbleed_sec22.pdf>`_
.. [#amd-btc] `Technical Guidance for Mitigating Branch Type Confusion <https://www.amd.com/content/dam/amd/en/documents/resources/technical-guidance-for-mitigating-branch-type-confusion.pdf>`_
.. [#amd-srso] `Technical Update Regarding Speculative Return Stack Overflow <https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf>`_
.. [#inception-paper] `Inception: Exposing New Attack Surfaces with Training in Transient Execution <https://comsec.ethz.ch/wp-content/files/inception_sec23.pdf>`_
.. [#intel-rsbu] `Return Stack Buffer Underflow / Return Stack Buffer Underflow / CVE-2022-29901, CVE-2022-28693 / INTEL-SA-00702 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html>`_
.. [#intel-ibpb-btb] `Indirect Branch Predictor Barrier' <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-predictor-barrier.html>`_
.. [#intel-eibrs-rrsba] "Guidance for RSBU" in `Return Stack Buffer Underflow / Return Stack Buffer Underflow / CVE-2022-29901, CVE-2022-28693 / INTEL-SA-00702 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html>`_
.. [#bhi-paper] `Branch History Injection: On the Effectiveness of Hardware Mitigations Against Cross-Privilege Spectre-v2 Attacks <http://download.vusec.net/papers/bhi-spectre-bhb_sec22.pdf>`_
.. [#intel-bhi] `Branch History Injection and Intra-mode Branch Target Injection / CVE-2022-0001, CVE-2022-0002 / INTEL-SA-00598 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html>`_
.. [#intel-retpoline-rrsba] "Retpoline" in `Branch History Injection and Intra-mode Branch Target Injection / CVE-2022-0001, CVE-2022-0002 / INTEL-SA-00598 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html>`_
Documentation/admin-guide/kernel-parameters.txt
+1 -4
View File
@@ -1407,18 +1407,15 @@
earlyprintk=serial[,0x...[,baudrate]]
earlyprintk=ttySn[,baudrate]
earlyprintk=dbgp[debugController#]
earlyprintk=mmio32,membase[,{nocfg|baudrate}]
earlyprintk=pciserial[,force],bus:device.function[,{nocfg|baudrate}]
earlyprintk=xdbc[xhciController#]
earlyprintk=bios
earlyprintk=mmio,membase[,{nocfg|baudrate}]
earlyprintk is useful when the kernel crashes before
the normal console is initialized. It is not enabled by
default because it has some cosmetic problems.
Only 32-bit memory addresses are supported for "mmio"
and "pciserial" devices.
Use "nocfg" to skip UART configuration, assume
BIOS/firmware has configured UART correctly.
Documentation/admin-guide/xfs.rst
+50
View File
@@ -124,6 +124,14 @@ When mounting an XFS filesystem, the following options are accepted.
controls the size of each buffer and so is also relevant to
this case.
lifetime (default) or nolifetime
Enable data placement based on write life time hints provided
by the user. This turns on co-allocation of data of similar
life times when statistically favorable to reduce garbage
collection cost.
These options are only available for zoned rt file systems.
logbsize=value
Set the size of each in-memory log buffer. The size may be
specified in bytes, or in kilobytes with a "k" suffix.
@@ -143,6 +151,14 @@ When mounting an XFS filesystem, the following options are accepted.
optional, and the log section can be separate from the data
section or contained within it.
max_open_zones=value
Specify the max number of zones to keep open for writing on a
zoned rt device. Many open zones aids file data separation
but may impact performance on HDDs.
If ``max_open_zones`` is not specified, the value is determined
by the capabilities and the size of the zoned rt device.
noalign
Data allocations will not be aligned at stripe unit
boundaries. This is only relevant to filesystems created
@@ -542,3 +558,37 @@ The interesting knobs for XFS workqueues are as follows:
nice Relative priority of scheduling the threads. These are the
same nice levels that can be applied to userspace processes.
============ ===========
Zoned Filesystems
=================
For zoned file systems, the following attribute is exposed in:
/sys/fs/xfs/<dev>/zoned/
max_open_zones (Min: 1 Default: Varies Max: UINTMAX)
This read-only attribute exposes the maximum number of open zones
available for data placement. The value is determined at mount time and
is limited by the capabilities of the backing zoned device, file system
size and the max_open_zones mount option.
Zoned Filesystems
=================
For zoned file systems, the following attributes are exposed in:
/sys/fs/xfs/<dev>/zoned/
max_open_zones (Min: 1 Default: Varies Max: UINTMAX)
This read-only attribute exposes the maximum number of open zones
available for data placement. The value is determined at mount time and
is limited by the capabilities of the backing zoned device, file system
size and the max_open_zones mount option.
zonegc_low_space (Min: 0 Default: 0 Max: 100)
Define a percentage for how much of the unused space that GC should keep
available for writing. A high value will reclaim more of the space
occupied by unused blocks, creating a larger buffer against write
bursts at the cost of increased write amplification. Regardless
of this value, garbage collection will always aim to free a minimum
amount of blocks to keep max_open_zones open for data placement purposes.
Documentation/arch/x86/cpuinfo.rst
+36 -33
View File
@@ -79,8 +79,9 @@ feature flags.
How are feature flags created?
==============================
a: Feature flags can be derived from the contents of CPUID leaves.
------------------------------------------------------------------
Feature flags can be derived from the contents of CPUID leaves
--------------------------------------------------------------
These feature definitions are organized mirroring the layout of CPUID
leaves and grouped in words with offsets as mapped in enum cpuid_leafs
in cpufeatures.h (see arch/x86/include/asm/cpufeatures.h for details).
@@ -89,8 +90,9 @@ cpufeatures.h, and if it is detected at run time, the flags will be
displayed accordingly in /proc/cpuinfo. For example, the flag "avx2"
comes from X86_FEATURE_AVX2 in cpufeatures.h.
b: Flags can be from scattered CPUID-based features.
----------------------------------------------------
Flags can be from scattered CPUID-based features
------------------------------------------------
Hardware features enumerated in sparsely populated CPUID leaves get
software-defined values. Still, CPUID needs to be queried to determine
if a given feature is present. This is done in init_scattered_cpuid_features().
@@ -104,8 +106,9 @@ has only one feature and would waste 31 bits of space in the x86_capability[]
array. Since there is a struct cpuinfo_x86 for each possible CPU, the wasted
memory is not trivial.
c: Flags can be created synthetically under certain conditions for hardware features.
-------------------------------------------------------------------------------------
Flags can be created synthetically under certain conditions for hardware features
---------------------------------------------------------------------------------
Examples of conditions include whether certain features are present in
MSR_IA32_CORE_CAPS or specific CPU models are identified. If the needed
conditions are met, the features are enabled by the set_cpu_cap or
@@ -114,8 +117,8 @@ the feature X86_FEATURE_SPLIT_LOCK_DETECT will be enabled and
"split_lock_detect" will be displayed. The flag "ring3mwait" will be
displayed only when running on INTEL_XEON_PHI_[KNL|KNM] processors.
d: Flags can represent purely software features.
------------------------------------------------
Flags can represent purely software features
--------------------------------------------
These flags do not represent hardware features. Instead, they represent a
software feature implemented in the kernel. For example, Kernel Page Table
Isolation is purely software feature and its feature flag X86_FEATURE_PTI is
@@ -130,14 +133,18 @@ x86_cap/bug_flags[] arrays in kernel/cpu/capflags.c. The names in the
resulting x86_cap/bug_flags[] are used to populate /proc/cpuinfo. The naming
of flags in the x86_cap/bug_flags[] are as follows:
a: The name of the flag is from the string in X86_FEATURE_<name> by default.
----------------------------------------------------------------------------
By default, the flag <name> in /proc/cpuinfo is extracted from the respective
X86_FEATURE_<name> in cpufeatures.h. For example, the flag "avx2" is from
X86_FEATURE_AVX2.
Flags do not appear by default in /proc/cpuinfo
-----------------------------------------------
Feature flags are omitted by default from /proc/cpuinfo as it does not make
sense for the feature to be exposed to userspace in most cases. For example,
X86_FEATURE_ALWAYS is defined in cpufeatures.h but that flag is an internal
kernel feature used in the alternative runtime patching functionality. So the
flag does not appear in /proc/cpuinfo.
Specify a flag name if absolutely needed
----------------------------------------
b: The naming can be overridden.
--------------------------------
If the comment on the line for the #define X86_FEATURE_* starts with a
double-quote character (""), the string inside the double-quote characters
will be the name of the flags. For example, the flag "sse4_1" comes from
@@ -148,36 +155,31 @@ needed. For instance, /proc/cpuinfo is a userspace interface and must remain
constant. If, for some reason, the naming of X86_FEATURE_<name> changes, one
shall override the new naming with the name already used in /proc/cpuinfo.
c: The naming override can be "", which means it will not appear in /proc/cpuinfo.
----------------------------------------------------------------------------------
The feature shall be omitted from /proc/cpuinfo if it does not make sense for
the feature to be exposed to userspace. For example, X86_FEATURE_ALWAYS is
defined in cpufeatures.h but that flag is an internal kernel feature used
in the alternative runtime patching functionality. So, its name is overridden
with "". Its flag will not appear in /proc/cpuinfo.
Flags are missing when one or more of these happen
==================================================
a: The hardware does not enumerate support for it.
--------------------------------------------------
The hardware does not enumerate support for it
----------------------------------------------
For example, when a new kernel is running on old hardware or the feature is
not enabled by boot firmware. Even if the hardware is new, there might be a
problem enabling the feature at run time, the flag will not be displayed.
b: The kernel does not know about the flag.
-------------------------------------------
The kernel does not know about the flag
---------------------------------------
For example, when an old kernel is running on new hardware.
c: The kernel disabled support for it at compile-time.
------------------------------------------------------
The kernel disabled support for it at compile-time
--------------------------------------------------
For example, if 5-level-paging is not enabled when building (i.e.,
CONFIG_X86_5LEVEL is not selected) the flag "la57" will not show up [#f1]_.
Even though the feature will still be detected via CPUID, the kernel disables
it by clearing via setup_clear_cpu_cap(X86_FEATURE_LA57).
d: The feature is disabled at boot-time.
----------------------------------------
The feature is disabled at boot-time
------------------------------------
A feature can be disabled either using a command-line parameter or because
it failed to be enabled. The command-line parameter clearcpuid= can be used
to disable features using the feature number as defined in
@@ -190,8 +192,9 @@ disable specific features. The list of parameters includes, but is not limited
to, nofsgsbase, nosgx, noxsave, etc. 5-level paging can also be disabled using
"no5lvl".
e: The feature was known to be non-functional.
----------------------------------------------
The feature was known to be non-functional
------------------------------------------
The feature was known to be non-functional because a dependency was
missing at runtime. For example, AVX flags will not show up if XSAVE feature
is disabled since they depend on XSAVE feature. Another example would be broken
Documentation/devicetree/bindings/ata/ceva,ahci-1v84.yaml
-1
View File
@@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Ceva AHCI SATA Controller
maintainers:
- Mubin Sayyed <mubin.sayyed@amd.com>
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
description: |
Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
+17 -1
View File
@@ -111,11 +111,27 @@ properties:
unevaluatedProperties: false
port@1:
$ref: /schemas/graph.yaml#/properties/port
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
DSI output port node to the panel or the next bridge
in the chain
properties:
endpoint:
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
data-lanes:
description: array of physical DSI data lane indexes.
minItems: 1
items:
- const: 1
- const: 2
- const: 3
- const: 4
required:
- port@0
- port@1
Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml
-1
View File
@@ -12,7 +12,6 @@ description:
PS_MODE). Every pin can be configured as input/output.
maintainers:
- Mubin Sayyed <mubin.sayyed@amd.com>
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
properties:
Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
+1
View File
@@ -19,6 +19,7 @@ properties:
- fsl,imx8mp-irqsteer
- fsl,imx8qm-irqsteer
- fsl,imx8qxp-irqsteer
- fsl,imx94-irqsteer
- const: fsl,imx-irqsteer
reg:
Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml
-9
View File
@@ -9,15 +9,6 @@ title: Renesas R-Car Timer Pulse Unit PWM Controller
maintainers:
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
select:
properties:
compatible:
contains:
const: renesas,tpu
required:
- compatible
- '#pwm-cells'
properties:
compatible:
items:
Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.yaml
-1
View File
@@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Zynq UltraScale+ MPSoC and Versal reset
maintainers:
- Mubin Sayyed <mubin.sayyed@amd.com>
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
description: |
Documentation/devicetree/bindings/soc/fsl/fsl,ls1028a-reset.yaml
+1 -1
View File
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale Layerscape Reset Registers Module
maintainers:
- Frank Li
- Frank Li <Frank.Li@nxp.com>
description:
Reset Module includes chip reset, service processor control and Reset Control
Documentation/devicetree/bindings/timer/nxp,sysctr-timer.yaml
+8 -3
View File
@@ -18,9 +18,14 @@ description: |
properties:
compatible:
enum:
- nxp,imx95-sysctr-timer
- nxp,sysctr-timer
oneOf:
- enum:
- nxp,imx95-sysctr-timer
- nxp,sysctr-timer
- items:
- enum:
- nxp,imx94-sysctr-timer
- const: nxp,imx95-sysctr-timer
reg:
maxItems: 1
Documentation/devicetree/bindings/timer/renesas,tpu.yaml
-56
View File
@@ -1,56 +0,0 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/timer/renesas,tpu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas H8/300 Timer Pulse Unit
maintainers:
- Yoshinori Sato <ysato@users.sourceforge.jp>
description:
The TPU is a 16bit timer/counter with configurable clock inputs and
programmable compare match.
This implementation supports only cascade mode.
select:
properties:
compatible:
contains:
const: renesas,tpu
'#pwm-cells': false
required:
- compatible
properties:
compatible:
const: renesas,tpu
reg:
items:
- description: First channel
- description: Second channel
clocks:
maxItems: 1
clock-names:
const: fck
required:
- compatible
- reg
- clocks
- clock-names
additionalProperties: false
examples:
- |
tpu: tpu@ffffe0 {
compatible = "renesas,tpu";
reg = <0xffffe0 16>, <0xfffff0 12>;
clocks = <&pclk>;
clock-names = "fck";
};
Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
-1
View File
@@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx SuperSpeed DWC3 USB SoC controller
maintainers:
- Mubin Sayyed <mubin.sayyed@amd.com>
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
properties:
Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
-1
View File
@@ -17,7 +17,6 @@ description:
maintainers:
- Michal Simek <michal.simek@amd.com>
- Mubin Sayyed <mubin.sayyed@amd.com>
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
properties:
Documentation/devicetree/bindings/usb/xlnx,usb2.yaml
-1
View File
@@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx udc controller
maintainers:
- Mubin Sayyed <mubin.sayyed@amd.com>
- Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
properties:
Documentation/filesystems/ext4/super.rst
+14 -6
View File
@@ -328,9 +328,13 @@ The ext4 superblock is laid out as follows in
- s_checksum_type
- Metadata checksum algorithm type. The only valid value is 1 (crc32c).
* - 0x176
- __le16
- s_reserved_pad
-
- \_\_u8
- s\_encryption\_level
- Versioning level for encryption.
* - 0x177
- \_\_u8
- s\_reserved\_pad
- Padding to next 32bits.
* - 0x178
- __le64
- s_kbytes_written
@@ -466,9 +470,13 @@ The ext4 superblock is laid out as follows in
- s_last_error_time_hi
- Upper 8 bits of the s_last_error_time field.
* - 0x27A
- __u8
- s_pad[2]
- Zero padding.
- \_\_u8
- s\_first\_error\_errcode
-
* - 0x27B
- \_\_u8
- s\_last\_error\_errcode
-
* - 0x27C
- __le16
- s_encoding

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