mirror of
https://github.com/armbian/linux-cix.git
synced 2026-01-06 12:30:45 -08:00
Merge tag 'asoc-v6.6' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v6.6 The rest of the updates for v6.6, some of the highlights include: - A big API cleanup from Morimoto-san, rationalising the places we put functions. - Lots of work on the SOF framework, AMD and Intel drivers, including a lot of cleanup and new device support. - Standardisation of the presentation of jacks from drivers. - Provision of some generic sound card DT properties. - Conversion oof more drivers to the maple tree register cache. - New drivers for AMD Van Gogh, AWInic AW88261, Cirrus Logic cs42l43, various Intel platforms, Mediatek MT7986, RealTek RT1017 and StarFive JH7110.
This commit is contained in:
@@ -82,7 +82,12 @@ Description:
|
||||
whether it resides in persistent capacity, volatile capacity,
|
||||
or the LSA, is made permanently unavailable by whatever means
|
||||
is appropriate for the media type. This functionality requires
|
||||
the device to be not be actively decoding any HPA ranges.
|
||||
the device to be disabled, that is, not actively decoding any
|
||||
HPA ranges. This permits avoiding explicit global CPU cache
|
||||
management, relying instead for it to be done when a region
|
||||
transitions between software programmed and hardware committed
|
||||
states. If this file is not present, then there is no hardware
|
||||
support for the operation.
|
||||
|
||||
|
||||
What /sys/bus/cxl/devices/memX/security/erase
|
||||
@@ -92,7 +97,13 @@ Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(WO) Write a boolean 'true' string value to this attribute to
|
||||
secure erase user data by changing the media encryption keys for
|
||||
all user data areas of the device.
|
||||
all user data areas of the device. This functionality requires
|
||||
the device to be disabled, that is, not actively decoding any
|
||||
HPA ranges. This permits avoiding explicit global CPU cache
|
||||
management, relying instead for it to be done when a region
|
||||
transitions between software programmed and hardware committed
|
||||
states. If this file is not present, then there is no hardware
|
||||
support for the operation.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/memX/firmware/
|
||||
|
||||
@@ -513,17 +513,18 @@ Description: information about CPUs heterogeneity.
|
||||
cpu_capacity: capacity of cpuX.
|
||||
|
||||
What: /sys/devices/system/cpu/vulnerabilities
|
||||
/sys/devices/system/cpu/vulnerabilities/meltdown
|
||||
/sys/devices/system/cpu/vulnerabilities/spectre_v1
|
||||
/sys/devices/system/cpu/vulnerabilities/spectre_v2
|
||||
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
|
||||
/sys/devices/system/cpu/vulnerabilities/gather_data_sampling
|
||||
/sys/devices/system/cpu/vulnerabilities/itlb_multihit
|
||||
/sys/devices/system/cpu/vulnerabilities/l1tf
|
||||
/sys/devices/system/cpu/vulnerabilities/mds
|
||||
/sys/devices/system/cpu/vulnerabilities/srbds
|
||||
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
|
||||
/sys/devices/system/cpu/vulnerabilities/itlb_multihit
|
||||
/sys/devices/system/cpu/vulnerabilities/meltdown
|
||||
/sys/devices/system/cpu/vulnerabilities/mmio_stale_data
|
||||
/sys/devices/system/cpu/vulnerabilities/retbleed
|
||||
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
|
||||
/sys/devices/system/cpu/vulnerabilities/spectre_v1
|
||||
/sys/devices/system/cpu/vulnerabilities/spectre_v2
|
||||
/sys/devices/system/cpu/vulnerabilities/srbds
|
||||
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
|
||||
Date: January 2018
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description: Information about CPU vulnerabilities
|
||||
|
||||
@@ -2,7 +2,7 @@ What: /sys/devices/platform/hidma-*/chid
|
||||
/sys/devices/platform/QCOM8061:*/chid
|
||||
Date: Dec 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@codeaurora.org>"
|
||||
Contact: "Sinan Kaya <okaya@kernel.org>"
|
||||
Description:
|
||||
Contains the ID of the channel within the HIDMA instance.
|
||||
It is used to associate a given HIDMA channel with the
|
||||
|
||||
@@ -2,7 +2,7 @@ What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority
|
||||
/sys/devices/platform/QCOM8060:*/chanops/chan*/priority
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@codeaurora.org>"
|
||||
Contact: "Sinan Kaya <okaya@kernel.org>"
|
||||
Description:
|
||||
Contains either 0 or 1 and indicates if the DMA channel is a
|
||||
low priority (0) or high priority (1) channel.
|
||||
@@ -11,7 +11,7 @@ What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/weight
|
||||
/sys/devices/platform/QCOM8060:*/chanops/chan*/weight
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@codeaurora.org>"
|
||||
Contact: "Sinan Kaya <okaya@kernel.org>"
|
||||
Description:
|
||||
Contains 0..15 and indicates the weight of the channel among
|
||||
equal priority channels during round robin scheduling.
|
||||
@@ -20,7 +20,7 @@ What: /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles
|
||||
/sys/devices/platform/QCOM8060:*/chreset_timeout_cycles
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@codeaurora.org>"
|
||||
Contact: "Sinan Kaya <okaya@kernel.org>"
|
||||
Description:
|
||||
Contains the platform specific cycle value to wait after a
|
||||
reset command is issued. If the value is chosen too short,
|
||||
@@ -32,7 +32,7 @@ What: /sys/devices/platform/hidma-mgmt*/dma_channels
|
||||
/sys/devices/platform/QCOM8060:*/dma_channels
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@codeaurora.org>"
|
||||
Contact: "Sinan Kaya <okaya@kernel.org>"
|
||||
Description:
|
||||
Contains the number of dma channels supported by one instance
|
||||
of HIDMA hardware. The value may change from chip to chip.
|
||||
@@ -41,7 +41,7 @@ What: /sys/devices/platform/hidma-mgmt*/hw_version_major
|
||||
/sys/devices/platform/QCOM8060:*/hw_version_major
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@codeaurora.org>"
|
||||
Contact: "Sinan Kaya <okaya@kernel.org>"
|
||||
Description:
|
||||
Version number major for the hardware.
|
||||
|
||||
@@ -49,7 +49,7 @@ What: /sys/devices/platform/hidma-mgmt*/hw_version_minor
|
||||
/sys/devices/platform/QCOM8060:*/hw_version_minor
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@codeaurora.org>"
|
||||
Contact: "Sinan Kaya <okaya@kernel.org>"
|
||||
Description:
|
||||
Version number minor for the hardware.
|
||||
|
||||
@@ -57,7 +57,7 @@ What: /sys/devices/platform/hidma-mgmt*/max_rd_xactions
|
||||
/sys/devices/platform/QCOM8060:*/max_rd_xactions
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@codeaurora.org>"
|
||||
Contact: "Sinan Kaya <okaya@kernel.org>"
|
||||
Description:
|
||||
Contains a value between 0 and 31. Maximum number of
|
||||
read transactions that can be issued back to back.
|
||||
@@ -69,7 +69,7 @@ What: /sys/devices/platform/hidma-mgmt*/max_read_request
|
||||
/sys/devices/platform/QCOM8060:*/max_read_request
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@codeaurora.org>"
|
||||
Contact: "Sinan Kaya <okaya@kernel.org>"
|
||||
Description:
|
||||
Size of each read request. The value needs to be a power
|
||||
of two and can be between 128 and 1024.
|
||||
@@ -78,7 +78,7 @@ What: /sys/devices/platform/hidma-mgmt*/max_wr_xactions
|
||||
/sys/devices/platform/QCOM8060:*/max_wr_xactions
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@codeaurora.org>"
|
||||
Contact: "Sinan Kaya <okaya@kernel.org>"
|
||||
Description:
|
||||
Contains a value between 0 and 31. Maximum number of
|
||||
write transactions that can be issued back to back.
|
||||
@@ -91,7 +91,7 @@ What: /sys/devices/platform/hidma-mgmt*/max_write_request
|
||||
/sys/devices/platform/QCOM8060:*/max_write_request
|
||||
Date: Nov 2015
|
||||
KernelVersion: 4.4
|
||||
Contact: "Sinan Kaya <okaya@codeaurora.org>"
|
||||
Contact: "Sinan Kaya <okaya@kernel.org>"
|
||||
Description:
|
||||
Size of each write request. The value needs to be a power
|
||||
of two and can be between 128 and 1024.
|
||||
|
||||
109
Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
Normal file
109
Documentation/admin-guide/hw-vuln/gather_data_sampling.rst
Normal file
@@ -0,0 +1,109 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
GDS - Gather Data Sampling
|
||||
==========================
|
||||
|
||||
Gather Data Sampling is a hardware vulnerability which allows unprivileged
|
||||
speculative access to data which was previously stored in vector registers.
|
||||
|
||||
Problem
|
||||
-------
|
||||
When a gather instruction performs loads from memory, different data elements
|
||||
are merged into the destination vector register. However, when a gather
|
||||
instruction that is transiently executed encounters a fault, stale data from
|
||||
architectural or internal vector registers may get transiently forwarded to the
|
||||
destination vector register instead. This will allow a malicious attacker to
|
||||
infer stale data using typical side channel techniques like cache timing
|
||||
attacks. GDS is a purely sampling-based attack.
|
||||
|
||||
The attacker uses gather instructions to infer the stale vector register data.
|
||||
The victim does not need to do anything special other than use the vector
|
||||
registers. The victim does not need to use gather instructions to be
|
||||
vulnerable.
|
||||
|
||||
Because the buffers are shared between Hyper-Threads cross Hyper-Thread attacks
|
||||
are possible.
|
||||
|
||||
Attack scenarios
|
||||
----------------
|
||||
Without mitigation, GDS can infer stale data across virtually all
|
||||
permission boundaries:
|
||||
|
||||
Non-enclaves can infer SGX enclave data
|
||||
Userspace can infer kernel data
|
||||
Guests can infer data from hosts
|
||||
Guest can infer guest from other guests
|
||||
Users can infer data from other users
|
||||
|
||||
Because of this, it is important to ensure that the mitigation stays enabled in
|
||||
lower-privilege contexts like guests and when running outside SGX enclaves.
|
||||
|
||||
The hardware enforces the mitigation for SGX. Likewise, VMMs should ensure
|
||||
that guests are not allowed to disable the GDS mitigation. If a host erred and
|
||||
allowed this, a guest could theoretically disable GDS mitigation, mount an
|
||||
attack, and re-enable it.
|
||||
|
||||
Mitigation mechanism
|
||||
--------------------
|
||||
This issue is mitigated in microcode. The microcode defines the following new
|
||||
bits:
|
||||
|
||||
================================ === ============================
|
||||
IA32_ARCH_CAPABILITIES[GDS_CTRL] R/O Enumerates GDS vulnerability
|
||||
and mitigation support.
|
||||
IA32_ARCH_CAPABILITIES[GDS_NO] R/O Processor is not vulnerable.
|
||||
IA32_MCU_OPT_CTRL[GDS_MITG_DIS] R/W Disables the mitigation
|
||||
0 by default.
|
||||
IA32_MCU_OPT_CTRL[GDS_MITG_LOCK] R/W Locks GDS_MITG_DIS=0. Writes
|
||||
to GDS_MITG_DIS are ignored
|
||||
Can't be cleared once set.
|
||||
================================ === ============================
|
||||
|
||||
GDS can also be mitigated on systems that don't have updated microcode by
|
||||
disabling AVX. This can be done by setting gather_data_sampling="force" or
|
||||
"clearcpuid=avx" on the kernel command-line.
|
||||
|
||||
If used, these options will disable AVX use by turning off XSAVE YMM support.
|
||||
However, the processor will still enumerate AVX support. Userspace that
|
||||
does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM
|
||||
support will break.
|
||||
|
||||
Mitigation control on the kernel command line
|
||||
---------------------------------------------
|
||||
The mitigation can be disabled by setting "gather_data_sampling=off" or
|
||||
"mitigations=off" on the kernel command line. Not specifying either will default
|
||||
to the mitigation being enabled. Specifying "gather_data_sampling=force" will
|
||||
use the microcode mitigation when available or disable AVX on affected systems
|
||||
where the microcode hasn't been updated to include the mitigation.
|
||||
|
||||
GDS System Information
|
||||
------------------------
|
||||
The kernel provides vulnerability status information through sysfs. For
|
||||
GDS this can be accessed by the following sysfs file:
|
||||
|
||||
/sys/devices/system/cpu/vulnerabilities/gather_data_sampling
|
||||
|
||||
The possible values contained in this file are:
|
||||
|
||||
============================== =============================================
|
||||
Not affected Processor not vulnerable.
|
||||
Vulnerable Processor vulnerable and mitigation disabled.
|
||||
Vulnerable: No microcode Processor vulnerable and microcode is missing
|
||||
mitigation.
|
||||
Mitigation: AVX disabled,
|
||||
no microcode Processor is vulnerable and microcode is missing
|
||||
mitigation. AVX disabled as mitigation.
|
||||
Mitigation: Microcode Processor is vulnerable and mitigation is in
|
||||
effect.
|
||||
Mitigation: Microcode (locked) Processor is vulnerable and mitigation is in
|
||||
effect and cannot be disabled.
|
||||
Unknown: Dependent on
|
||||
hypervisor status Running on a virtual guest processor that is
|
||||
affected but with no way to know if host
|
||||
processor is mitigated or vulnerable.
|
||||
============================== =============================================
|
||||
|
||||
GDS Default mitigation
|
||||
----------------------
|
||||
The updated microcode will enable the mitigation by default. The kernel's
|
||||
default action is to leave the mitigation enabled.
|
||||
@@ -13,9 +13,11 @@ are configurable at compile, boot or run time.
|
||||
l1tf
|
||||
mds
|
||||
tsx_async_abort
|
||||
multihit.rst
|
||||
special-register-buffer-data-sampling.rst
|
||||
core-scheduling.rst
|
||||
l1d_flush.rst
|
||||
processor_mmio_stale_data.rst
|
||||
cross-thread-rsb.rst
|
||||
multihit
|
||||
special-register-buffer-data-sampling
|
||||
core-scheduling
|
||||
l1d_flush
|
||||
processor_mmio_stale_data
|
||||
cross-thread-rsb
|
||||
srso
|
||||
gather_data_sampling
|
||||
|
||||
150
Documentation/admin-guide/hw-vuln/srso.rst
Normal file
150
Documentation/admin-guide/hw-vuln/srso.rst
Normal file
@@ -0,0 +1,150 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
Speculative Return Stack Overflow (SRSO)
|
||||
========================================
|
||||
|
||||
This is a mitigation for the speculative return stack overflow (SRSO)
|
||||
vulnerability found on AMD processors. The mechanism is by now the well
|
||||
known scenario of poisoning CPU functional units - the Branch Target
|
||||
Buffer (BTB) and Return Address Predictor (RAP) in this case - and then
|
||||
tricking the elevated privilege domain (the kernel) into leaking
|
||||
sensitive data.
|
||||
|
||||
AMD CPUs predict RET instructions using a Return Address Predictor (aka
|
||||
Return Address Stack/Return Stack Buffer). In some cases, a non-architectural
|
||||
CALL instruction (i.e., an instruction predicted to be a CALL but is
|
||||
not actually a CALL) can create an entry in the RAP which may be used
|
||||
to predict the target of a subsequent RET instruction.
|
||||
|
||||
The specific circumstances that lead to this varies by microarchitecture
|
||||
but the concern is that an attacker can mis-train the CPU BTB to predict
|
||||
non-architectural CALL instructions in kernel space and use this to
|
||||
control the speculative target of a subsequent kernel RET, potentially
|
||||
leading to information disclosure via a speculative side-channel.
|
||||
|
||||
The issue is tracked under CVE-2023-20569.
|
||||
|
||||
Affected processors
|
||||
-------------------
|
||||
|
||||
AMD Zen, generations 1-4. That is, all families 0x17 and 0x19. Older
|
||||
processors have not been investigated.
|
||||
|
||||
System information and options
|
||||
------------------------------
|
||||
|
||||
First of all, it is required that the latest microcode be loaded for
|
||||
mitigations to be effective.
|
||||
|
||||
The sysfs file showing SRSO mitigation status is:
|
||||
|
||||
/sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
|
||||
|
||||
The possible values in this file are:
|
||||
|
||||
* 'Not affected':
|
||||
|
||||
The processor is not vulnerable
|
||||
|
||||
* 'Vulnerable: no microcode':
|
||||
|
||||
The processor is vulnerable, no microcode extending IBPB
|
||||
functionality to address the vulnerability has been applied.
|
||||
|
||||
* 'Mitigation: microcode':
|
||||
|
||||
Extended IBPB functionality microcode patch has been applied. It does
|
||||
not address User->Kernel and Guest->Host transitions protection but it
|
||||
does address User->User and VM->VM attack vectors.
|
||||
|
||||
Note that User->User mitigation is controlled by how the IBPB aspect in
|
||||
the Spectre v2 mitigation is selected:
|
||||
|
||||
* conditional IBPB:
|
||||
|
||||
where each process can select whether it needs an IBPB issued
|
||||
around it PR_SPEC_DISABLE/_ENABLE etc, see :doc:`spectre`
|
||||
|
||||
* strict:
|
||||
|
||||
i.e., always on - by supplying spectre_v2_user=on on the kernel
|
||||
command line
|
||||
|
||||
(spec_rstack_overflow=microcode)
|
||||
|
||||
* 'Mitigation: safe RET':
|
||||
|
||||
Software-only mitigation. It complements the extended IBPB microcode
|
||||
patch functionality by addressing User->Kernel and Guest->Host
|
||||
transitions protection.
|
||||
|
||||
Selected by default or by spec_rstack_overflow=safe-ret
|
||||
|
||||
* 'Mitigation: IBPB':
|
||||
|
||||
Similar protection as "safe RET" above but employs an IBPB barrier on
|
||||
privilege domain crossings (User->Kernel, Guest->Host).
|
||||
|
||||
(spec_rstack_overflow=ibpb)
|
||||
|
||||
* 'Mitigation: IBPB on VMEXIT':
|
||||
|
||||
Mitigation addressing the cloud provider scenario - the Guest->Host
|
||||
transitions only.
|
||||
|
||||
(spec_rstack_overflow=ibpb-vmexit)
|
||||
|
||||
|
||||
|
||||
In order to exploit vulnerability, an attacker needs to:
|
||||
|
||||
- gain local access on the machine
|
||||
|
||||
- break kASLR
|
||||
|
||||
- find gadgets in the running kernel in order to use them in the exploit
|
||||
|
||||
- potentially create and pin an additional workload on the sibling
|
||||
thread, depending on the microarchitecture (not necessary on fam 0x19)
|
||||
|
||||
- run the exploit
|
||||
|
||||
Considering the performance implications of each mitigation type, the
|
||||
default one is 'Mitigation: safe RET' which should take care of most
|
||||
attack vectors, including the local User->Kernel one.
|
||||
|
||||
As always, the user is advised to keep her/his system up-to-date by
|
||||
applying software updates regularly.
|
||||
|
||||
The default setting will be reevaluated when needed and especially when
|
||||
new attack vectors appear.
|
||||
|
||||
As one can surmise, 'Mitigation: safe RET' does come at the cost of some
|
||||
performance depending on the workload. If one trusts her/his userspace
|
||||
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
|
||||
microcode patch for one's system. This mitigation comes also at
|
||||
a performance cost.
|
||||
|
||||
Mitigation: safe RET
|
||||
--------------------
|
||||
|
||||
The mitigation works by ensuring all RET instructions speculate to
|
||||
a controlled location, similar to how speculation is controlled in the
|
||||
retpoline sequence. To accomplish this, the __x86_return_thunk forces
|
||||
the CPU to mispredict every function return using a 'safe return'
|
||||
sequence.
|
||||
|
||||
To ensure the safety of this mitigation, the kernel must ensure that the
|
||||
safe return sequence is itself free from attacker interference. In Zen3
|
||||
and Zen4, this is accomplished by creating a BTB alias between the
|
||||
untraining function srso_untrain_ret_alias() and the safe return
|
||||
function srso_safe_ret_alias() which results in evicting a potentially
|
||||
poisoned BTB entry and using that safe one for all function returns.
|
||||
|
||||
In older Zen1 and Zen2, this is accomplished using a reinterpretation
|
||||
technique similar to Retbleed one: srso_untrain_ret() and
|
||||
srso_safe_ret().
|
||||
@@ -624,3 +624,9 @@ Used to get the correct ranges:
|
||||
* VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space.
|
||||
* VMEMMAP_START ~ VMEMMAP_END : vmemmap space, used for struct page array.
|
||||
* KERNEL_LINK_ADDR : start address of Kernel link and BPF
|
||||
|
||||
va_kernel_pa_offset
|
||||
-------------------
|
||||
|
||||
Indicates the offset between the kernel virtual and physical mappings.
|
||||
Used to translate virtual to physical addresses.
|
||||
|
||||
@@ -1623,6 +1623,26 @@
|
||||
Format: off | on
|
||||
default: on
|
||||
|
||||
gather_data_sampling=
|
||||
[X86,INTEL] Control the Gather Data Sampling (GDS)
|
||||
mitigation.
|
||||
|
||||
Gather Data Sampling is a hardware vulnerability which
|
||||
allows unprivileged speculative access to data which was
|
||||
previously stored in vector registers.
|
||||
|
||||
This issue is mitigated by default in updated microcode.
|
||||
The mitigation may have a performance impact but can be
|
||||
disabled. On systems without the microcode mitigation
|
||||
disabling AVX serves as a mitigation.
|
||||
|
||||
force: Disable AVX to mitigate systems without
|
||||
microcode mitigation. No effect if the microcode
|
||||
mitigation is present. Known to cause crashes in
|
||||
userspace with buggy AVX enumeration.
|
||||
|
||||
off: Disable GDS mitigation.
|
||||
|
||||
gcov_persist= [GCOV] When non-zero (default), profiling data for
|
||||
kernel modules is saved and remains accessible via
|
||||
debugfs, even when the module is unloaded/reloaded.
|
||||
@@ -3273,24 +3293,25 @@
|
||||
Disable all optional CPU mitigations. This
|
||||
improves system performance, but it may also
|
||||
expose users to several CPU vulnerabilities.
|
||||
Equivalent to: nopti [X86,PPC]
|
||||
if nokaslr then kpti=0 [ARM64]
|
||||
nospectre_v1 [X86,PPC]
|
||||
nobp=0 [S390]
|
||||
nospectre_v2 [X86,PPC,S390,ARM64]
|
||||
spectre_v2_user=off [X86]
|
||||
spec_store_bypass_disable=off [X86,PPC]
|
||||
ssbd=force-off [ARM64]
|
||||
nospectre_bhb [ARM64]
|
||||
Equivalent to: if nokaslr then kpti=0 [ARM64]
|
||||
gather_data_sampling=off [X86]
|
||||
kvm.nx_huge_pages=off [X86]
|
||||
l1tf=off [X86]
|
||||
mds=off [X86]
|
||||
tsx_async_abort=off [X86]
|
||||
kvm.nx_huge_pages=off [X86]
|
||||
srbds=off [X86,INTEL]
|
||||
mmio_stale_data=off [X86]
|
||||
no_entry_flush [PPC]
|
||||
no_uaccess_flush [PPC]
|
||||
mmio_stale_data=off [X86]
|
||||
nobp=0 [S390]
|
||||
nopti [X86,PPC]
|
||||
nospectre_bhb [ARM64]
|
||||
nospectre_v1 [X86,PPC]
|
||||
nospectre_v2 [X86,PPC,S390,ARM64]
|
||||
retbleed=off [X86]
|
||||
spec_store_bypass_disable=off [X86,PPC]
|
||||
spectre_v2_user=off [X86]
|
||||
srbds=off [X86,INTEL]
|
||||
ssbd=force-off [ARM64]
|
||||
tsx_async_abort=off [X86]
|
||||
|
||||
Exceptions:
|
||||
This does not have any effect on
|
||||
@@ -5875,6 +5896,17 @@
|
||||
Not specifying this option is equivalent to
|
||||
spectre_v2_user=auto.
|
||||
|
||||
spec_rstack_overflow=
|
||||
[X86] Control RAS overflow mitigation on AMD Zen CPUs
|
||||
|
||||
off - Disable mitigation
|
||||
microcode - Enable microcode mitigation only
|
||||
safe-ret - Enable sw-only safe RET mitigation (default)
|
||||
ibpb - Enable mitigation by issuing IBPB on
|
||||
kernel entry
|
||||
ibpb-vmexit - Issue IBPB only on VMEXIT
|
||||
(cloud-specific mitigation)
|
||||
|
||||
spec_store_bypass_disable=
|
||||
[HW] Control Speculative Store Bypass (SSB) Disable mitigation
|
||||
(Speculative Store Bypass vulnerability)
|
||||
|
||||
@@ -166,7 +166,6 @@ Integer log and power Functions
|
||||
-------------------------------
|
||||
|
||||
.. kernel-doc:: include/linux/int_log.h
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: lib/math/int_pow.c
|
||||
:export:
|
||||
|
||||
@@ -216,7 +216,6 @@ properties:
|
||||
description: Whether to enable burnout current for EXT1.
|
||||
|
||||
adi,ext1-burnout-current-nanoamp:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
Burnout current in nanoamps to be applied to EXT1.
|
||||
enum: [0, 50, 500, 1000, 10000]
|
||||
@@ -233,7 +232,6 @@ properties:
|
||||
description: Whether to enable burnout current for EXT2.
|
||||
|
||||
adi,ext2-burnout-current-nanoamp:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: Burnout current in nanoamps to be applied to EXT2.
|
||||
enum: [0, 50, 500, 1000, 10000]
|
||||
default: 0
|
||||
@@ -249,7 +247,6 @@ properties:
|
||||
description: Whether to enable burnout current for VIOUT.
|
||||
|
||||
adi,viout-burnout-current-nanoamp:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: Burnout current in nanoamps to be applied to VIOUT.
|
||||
enum: [0, 1000, 10000]
|
||||
default: 0
|
||||
|
||||
@@ -293,7 +293,7 @@ allOf:
|
||||
patternProperties:
|
||||
"^mac@[0-1]$":
|
||||
type: object
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
allOf:
|
||||
- $ref: ethernet-controller.yaml#
|
||||
description:
|
||||
@@ -305,14 +305,9 @@ patternProperties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
phy-handle: true
|
||||
|
||||
phy-mode: true
|
||||
|
||||
required:
|
||||
- reg
|
||||
- compatible
|
||||
- phy-handle
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
@@ -91,12 +91,18 @@ properties:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
|
||||
tx_delay:
|
||||
description: Delay value for TXD timing. Range value is 0~0x7F, 0x30 as default.
|
||||
description: Delay value for TXD timing.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
minimum: 0
|
||||
maximum: 0x7F
|
||||
default: 0x30
|
||||
|
||||
rx_delay:
|
||||
description: Delay value for RXD timing. Range value is 0~0x7F, 0x10 as default.
|
||||
description: Delay value for RXD timing.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
minimum: 0
|
||||
maximum: 0x7F
|
||||
default: 0x10
|
||||
|
||||
phy-supply:
|
||||
description: PHY regulator
|
||||
|
||||
@@ -16,13 +16,15 @@ properties:
|
||||
- enum:
|
||||
- atmel,at91rm9200-usart
|
||||
- atmel,at91sam9260-usart
|
||||
- microchip,sam9x60-usart
|
||||
- items:
|
||||
- const: atmel,at91rm9200-dbgu
|
||||
- const: atmel,at91rm9200-usart
|
||||
- items:
|
||||
- const: atmel,at91sam9260-dbgu
|
||||
- const: atmel,at91sam9260-usart
|
||||
- items:
|
||||
- const: microchip,sam9x60-usart
|
||||
- const: atmel,at91sam9260-usart
|
||||
- items:
|
||||
- const: microchip,sam9x60-dbgu
|
||||
- const: microchip,sam9x60-usart
|
||||
|
||||
@@ -9,6 +9,9 @@ title: Amlogic AXG sound card
|
||||
maintainers:
|
||||
- Jerome Brunet <jbrunet@baylibre.com>
|
||||
|
||||
allOf:
|
||||
- $ref: sound-card-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: amlogic,axg-sound-card
|
||||
@@ -17,23 +20,12 @@ properties:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description: list of auxiliary devices
|
||||
|
||||
audio-routing:
|
||||
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
|
||||
description:
|
||||
A list of the connections between audio components. Each entry is a
|
||||
pair of strings, the first being the connection's sink, the second
|
||||
being the connection's source.
|
||||
|
||||
audio-widgets:
|
||||
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
|
||||
description:
|
||||
A list off component DAPM widget. Each entry is a pair of strings,
|
||||
the first being the widget type, the second being the widget name
|
||||
|
||||
model:
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
description: User specified audio sound card name
|
||||
|
||||
patternProperties:
|
||||
"^dai-link-[0-9]+$":
|
||||
type: object
|
||||
@@ -108,7 +100,6 @@ patternProperties:
|
||||
- sound-dai
|
||||
|
||||
required:
|
||||
- model
|
||||
- dai-link-0
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
@@ -9,6 +9,9 @@ title: Amlogic GX sound card
|
||||
maintainers:
|
||||
- Jerome Brunet <jbrunet@baylibre.com>
|
||||
|
||||
allOf:
|
||||
- $ref: sound-card-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
@@ -18,14 +21,6 @@ properties:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description: list of auxiliary devices
|
||||
|
||||
audio-routing:
|
||||
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
|
||||
minItems: 2
|
||||
description: |-
|
||||
A list of the connections between audio components. Each entry is a
|
||||
pair of strings, the first being the connection's sink, the second
|
||||
being the connection's source.
|
||||
|
||||
audio-widgets:
|
||||
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
|
||||
minItems: 2
|
||||
@@ -33,10 +28,6 @@ properties:
|
||||
A list off component DAPM widget. Each entry is a pair of strings,
|
||||
the first being the widget type, the second being the widget name
|
||||
|
||||
model:
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
description: User specified audio sound card name
|
||||
|
||||
patternProperties:
|
||||
"^dai-link-[0-9]+$":
|
||||
type: object
|
||||
@@ -86,7 +77,7 @@ required:
|
||||
- model
|
||||
- dai-link-0
|
||||
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
||||
@@ -19,7 +19,9 @@ allOf:
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: awinic,aw88395
|
||||
enum:
|
||||
- awinic,aw88395
|
||||
- awinic,aw88261
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
313
Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml
Normal file
313
Documentation/devicetree/bindings/sound/cirrus,cs42l43.yaml
Normal file
@@ -0,0 +1,313 @@
|
||||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/sound/cirrus,cs42l43.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Cirrus Logic CS42L43 Audio CODEC
|
||||
|
||||
maintainers:
|
||||
- patches@opensource.cirrus.com
|
||||
|
||||
description: |
|
||||
The CS42L43 is an audio CODEC with integrated MIPI SoundWire interface
|
||||
(Version 1.2.1 compliant), I2C, SPI, and I2S/TDM interfaces designed
|
||||
for portable applications. It provides a high dynamic range, stereo
|
||||
DAC for headphone output, two integrated Class D amplifiers for
|
||||
loudspeakers, and two ADCs for wired headset microphone input or
|
||||
stereo line input. PDM inputs are provided for digital microphones.
|
||||
|
||||
allOf:
|
||||
- $ref: dai-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- cirrus,cs42l43
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
vdd-p-supply:
|
||||
description:
|
||||
Power supply for the high voltage interface.
|
||||
|
||||
vdd-a-supply:
|
||||
description:
|
||||
Power supply for internal analog circuits.
|
||||
|
||||
vdd-d-supply:
|
||||
description:
|
||||
Power supply for internal digital circuits. Can be internally supplied.
|
||||
|
||||
vdd-io-supply:
|
||||
description:
|
||||
Power supply for external interface and internal digital logic.
|
||||
|
||||
vdd-cp-supply:
|
||||
description:
|
||||
Power supply for the amplifier 3 and 4 charge pump.
|
||||
|
||||
vdd-amp-supply:
|
||||
description:
|
||||
Power supply for amplifier 1 and 2.
|
||||
|
||||
reset-gpios:
|
||||
maxItems: 1
|
||||
|
||||
interrupt-controller: true
|
||||
|
||||
"#interrupt-cells":
|
||||
const: 2
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
"#sound-dai-cells":
|
||||
const: 1
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Synchronous audio clock provided on mclk_in.
|
||||
|
||||
clock-names:
|
||||
const: mclk
|
||||
|
||||
cirrus,bias-low:
|
||||
type: boolean
|
||||
description:
|
||||
Select a 1.8V headset micbias rather than 2.8V.
|
||||
|
||||
cirrus,bias-sense-microamp:
|
||||
description:
|
||||
Current at which the headset micbias sense clamp will engage, 0 to
|
||||
disable.
|
||||
enum: [ 0, 14, 23, 41, 50, 60, 68, 86, 95 ]
|
||||
default: 0
|
||||
|
||||
cirrus,bias-ramp-ms:
|
||||
description:
|
||||
Time in milliseconds the hardware allows for the headset micbias to
|
||||
ramp up.
|
||||
enum: [ 10, 40, 90, 170 ]
|
||||
default: 170
|
||||
|
||||
cirrus,detect-us:
|
||||
description:
|
||||
Time in microseconds the type detection will run for. Long values will
|
||||
cause more audible effects, but give more accurate detection.
|
||||
enum: [ 20, 100, 1000, 10000, 50000, 75000, 100000, 200000 ]
|
||||
default: 10000
|
||||
|
||||
cirrus,button-automute:
|
||||
type: boolean
|
||||
description:
|
||||
Enable the hardware automuting of decimator 1 when a headset button is
|
||||
pressed.
|
||||
|
||||
cirrus,buttons-ohms:
|
||||
description:
|
||||
Impedance in Ohms for each headset button, these should be listed in
|
||||
ascending order.
|
||||
minItems: 1
|
||||
maxItems: 6
|
||||
|
||||
cirrus,tip-debounce-ms:
|
||||
description:
|
||||
Software debounce on tip sense triggering in milliseconds.
|
||||
default: 0
|
||||
|
||||
cirrus,tip-invert:
|
||||
type: boolean
|
||||
description:
|
||||
Indicates tip detect polarity, inverted implies open-circuit whilst the
|
||||
jack is inserted.
|
||||
|
||||
cirrus,tip-disable-pullup:
|
||||
type: boolean
|
||||
description:
|
||||
Indicates if the internal pullup on the tip detect should be disabled.
|
||||
|
||||
cirrus,tip-fall-db-ms:
|
||||
description:
|
||||
Time in milliseconds a falling edge on the tip detect should be hardware
|
||||
debounced for. Note the falling edge is considered after the invert.
|
||||
enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ]
|
||||
default: 500
|
||||
|
||||
cirrus,tip-rise-db-ms:
|
||||
description:
|
||||
Time in milliseconds a rising edge on the tip detect should be hardware
|
||||
debounced for. Note the rising edge is considered after the invert.
|
||||
enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ]
|
||||
default: 500
|
||||
|
||||
cirrus,use-ring-sense:
|
||||
type: boolean
|
||||
description:
|
||||
Indicates if the ring sense should be used.
|
||||
|
||||
cirrus,ring-invert:
|
||||
type: boolean
|
||||
description:
|
||||
Indicates ring detect polarity, inverted implies open-circuit whilst the
|
||||
jack is inserted.
|
||||
|
||||
cirrus,ring-disable-pullup:
|
||||
type: boolean
|
||||
description:
|
||||
Indicates if the internal pullup on the ring detect should be disabled.
|
||||
|
||||
cirrus,ring-fall-db-ms:
|
||||
description:
|
||||
Time in milliseconds a falling edge on the ring detect should be hardware
|
||||
debounced for. Note the falling edge is considered after the invert.
|
||||
enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ]
|
||||
default: 500
|
||||
|
||||
cirrus,ring-rise-db-ms:
|
||||
description:
|
||||
Time in milliseconds a rising edge on the ring detect should be hardware
|
||||
debounced for. Note the rising edge is considered after the invert.
|
||||
enum: [ 0, 125, 250, 500, 750, 1000, 1250, 1500 ]
|
||||
default: 500
|
||||
|
||||
pinctrl:
|
||||
type: object
|
||||
$ref: /schemas/pinctrl/pinctrl.yaml#
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
gpio-controller: true
|
||||
|
||||
"#gpio-cells":
|
||||
const: 2
|
||||
|
||||
gpio-ranges:
|
||||
items:
|
||||
- description: A phandle to the CODEC pinctrl node
|
||||
minimum: 0
|
||||
- const: 0
|
||||
- const: 0
|
||||
- const: 3
|
||||
|
||||
patternProperties:
|
||||
"-state$":
|
||||
oneOf:
|
||||
- $ref: "#/$defs/cirrus-cs42l43-state"
|
||||
- patternProperties:
|
||||
"-pins$":
|
||||
$ref: "#/$defs/cirrus-cs42l43-state"
|
||||
additionalProperties: false
|
||||
|
||||
spi:
|
||||
type: object
|
||||
$ref: /schemas/spi/spi-controller.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
$defs:
|
||||
cirrus-cs42l43-state:
|
||||
type: object
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/pinctrl/pincfg-node.yaml#
|
||||
- $ref: /schemas/pinctrl/pinmux-node.yaml#
|
||||
|
||||
oneOf:
|
||||
- required: [ groups ]
|
||||
- required: [ pins ]
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
groups:
|
||||
enum: [ gpio1, gpio2, gpio3, asp, pdmout2, pdmout1, i2c, spi ]
|
||||
|
||||
pins:
|
||||
enum: [ gpio1, gpio2, gpio3,
|
||||
asp_dout, asp_fsync, asp_bclk,
|
||||
pdmout2_clk, pdmout2_data, pdmout1_clk, pdmout1_data,
|
||||
i2c_sda, i2c_scl,
|
||||
spi_miso, spi_sck, spi_ssb ]
|
||||
|
||||
function:
|
||||
enum: [ gpio, spdif, irq, mic-shutter, spk-shutter ]
|
||||
|
||||
drive-strength:
|
||||
description: Set drive strength in mA
|
||||
enum: [ 1, 2, 4, 8, 9, 10, 12, 16 ]
|
||||
|
||||
input-debounce:
|
||||
description: Set input debounce in uS
|
||||
enum: [ 0, 85 ]
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- vdd-p-supply
|
||||
- vdd-a-supply
|
||||
- vdd-io-supply
|
||||
- vdd-cp-supply
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cs42l43: codec@1a {
|
||||
compatible = "cirrus,cs42l43";
|
||||
reg = <0x1a>;
|
||||
|
||||
vdd-p-supply = <&vdd5v0>;
|
||||
vdd-a-supply = <&vdd1v8>;
|
||||
vdd-io-supply = <&vdd1v8>;
|
||||
vdd-cp-supply = <&vdd1v8>;
|
||||
vdd-amp-supply = <&vdd5v0>;
|
||||
|
||||
reset-gpios = <&gpio 0>;
|
||||
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-parent = <&gpio>;
|
||||
interrupts = <56 IRQ_TYPE_LEVEL_LOW>;
|
||||
|
||||
#sound-dai-cells = <1>;
|
||||
|
||||
clocks = <&clks 0>;
|
||||
clock-names = "mclk";
|
||||
|
||||
cs42l43_pins: pinctrl {
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
gpio-ranges = <&cs42l43_pins 0 0 3>;
|
||||
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinsettings>;
|
||||
|
||||
pinsettings: default-state {
|
||||
shutter-pins {
|
||||
groups = "gpio3";
|
||||
function = "mic-shutter";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
spi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cs-gpios = <&cs42l43_pins 1 0>;
|
||||
|
||||
sensor@0 {
|
||||
compatible = "bosch,bme680";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <1400000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -17,6 +17,9 @@ description: |
|
||||
such as SAI, MICFIL, .etc through building rpmsg channels between
|
||||
Cortex-A and Cortex-M.
|
||||
|
||||
allOf:
|
||||
- $ref: sound-card-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
@@ -27,10 +30,6 @@ properties:
|
||||
- fsl,imx8ulp-rpmsg-audio
|
||||
- fsl,imx93-rpmsg-audio
|
||||
|
||||
model:
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
description: User specified audio sound card name
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Peripheral clock for register access
|
||||
@@ -66,13 +65,6 @@ properties:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description: The phandle to a node of audio codec
|
||||
|
||||
audio-routing:
|
||||
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
|
||||
description: |
|
||||
A list of the connections between audio components. Each entry is a
|
||||
pair of strings, the first being the connection's sink, the second
|
||||
being the connection's source.
|
||||
|
||||
fsl,enable-lpa:
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description: enable low power audio path.
|
||||
@@ -101,9 +93,8 @@ properties:
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- model
|
||||
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
||||
@@ -13,23 +13,15 @@ maintainers:
|
||||
description:
|
||||
This binding describes the SC7180 sound card which uses LPASS for audio.
|
||||
|
||||
allOf:
|
||||
- $ref: sound-card-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- google,sc7180-trogdor
|
||||
- google,sc7180-coachz
|
||||
|
||||
audio-routing:
|
||||
$ref: /schemas/types.yaml#/definitions/non-unique-string-array
|
||||
description:
|
||||
A list of the connections between audio components. Each entry is a
|
||||
pair of strings, the first being the connection's sink, the second
|
||||
being the connection's source.
|
||||
|
||||
model:
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
description: User specified audio sound card name
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
@@ -86,11 +78,10 @@ patternProperties:
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- model
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user