mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2024-12-29 09:13:38 +00:00
Merge branch 'bpf/master' into for-6.12
Pull bpf/master to receive baebe9aaba ("bpf: allow passing struct
bpf_iter_<type> as kfunc arguments") and related changes in preparation for
the DSQ iterator patchset.
Signed-off-by: Tejun Heo <tj@kernel.org>
This commit is contained in:
Tejun Heo
commit
649e980dad
1
.mailmap
1
.mailmap
@ -166,6 +166,7 @@ Daniel Borkmann <daniel@iogearbox.net> <dborkman@redhat.com>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <dxchgb@gmail.com>
|
||||
David Brownell <david-b@pacbell.net>
|
||||
David Collins <quic_collinsd@quicinc.com> <collinsd@codeaurora.org>
|
||||
David Heidelberg <david@ixit.cz> <d.okias@gmail.com>
|
||||
David Rheinsberg <david@readahead.eu> <dh.herrmann@gmail.com>
|
||||
David Rheinsberg <david@readahead.eu> <dh.herrmann@googlemail.com>
|
||||
David Rheinsberg <david@readahead.eu> <david.rheinsberg@gmail.com>
|
||||
|
||||
@ -32,9 +32,9 @@ Description: (RW) The front button on the Turris Omnia router can be
|
||||
interrupt.
|
||||
|
||||
This file switches between these two modes:
|
||||
- "mcu" makes the button press event be handled by the MCU to
|
||||
change the LEDs panel intensity.
|
||||
- "cpu" makes the button press event be handled by the CPU.
|
||||
- ``mcu`` makes the button press event be handled by the MCU to
|
||||
change the LEDs panel intensity.
|
||||
- ``cpu`` makes the button press event be handled by the CPU.
|
||||
|
||||
Format: %s.
|
||||
|
||||
|
||||
@ -562,7 +562,8 @@ Description: Control Symmetric Multi Threading (SMT)
|
||||
================ =========================================
|
||||
|
||||
If control status is "forceoff" or "notsupported" writes
|
||||
are rejected.
|
||||
are rejected. Note that enabling SMT on PowerPC skips
|
||||
offline cores.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/power/energy_perf_bias
|
||||
Date: March 2019
|
||||
|
||||
@ -742,7 +742,7 @@ SecurityFlags Flags which control security negotiation and
|
||||
may use NTLMSSP 0x00080
|
||||
must use NTLMSSP 0x80080
|
||||
seal (packet encryption) 0x00040
|
||||
must seal (not implemented yet) 0x40040
|
||||
must seal 0x40040
|
||||
|
||||
cifsFYI If set to non-zero value, additional debug information
|
||||
will be logged to the system error log. This field
|
||||
|
||||
@ -162,13 +162,14 @@ iv_large_sectors
|
||||
|
||||
|
||||
Module parameters::
|
||||
max_read_size
|
||||
max_write_size
|
||||
Maximum size of read or write requests. When a request larger than this size
|
||||
is received, dm-crypt will split the request. The splitting improves
|
||||
concurrency (the split requests could be encrypted in parallel by multiple
|
||||
cores), but it also causes overhead. The user should tune these parameters to
|
||||
fit the actual workload.
|
||||
|
||||
max_read_size
|
||||
max_write_size
|
||||
Maximum size of read or write requests. When a request larger than this size
|
||||
is received, dm-crypt will split the request. The splitting improves
|
||||
concurrency (the split requests could be encrypted in parallel by multiple
|
||||
cores), but it also causes overhead. The user should tune these parameters to
|
||||
fit the actual workload.
|
||||
|
||||
|
||||
Example scripts
|
||||
|
||||
@ -4798,11 +4798,9 @@
|
||||
|
||||
profile= [KNL] Enable kernel profiling via /proc/profile
|
||||
Format: [<profiletype>,]<number>
|
||||
Param: <profiletype>: "schedule", "sleep", or "kvm"
|
||||
Param: <profiletype>: "schedule" or "kvm"
|
||||
[defaults to kernel profiling]
|
||||
Param: "schedule" - profile schedule points.
|
||||
Param: "sleep" - profile D-state sleeping (millisecs).
|
||||
Requires CONFIG_SCHEDSTATS
|
||||
Param: "kvm" - profile VM exits.
|
||||
Param: <number> - step/bucket size as a power of 2 for
|
||||
statistical time based profiling.
|
||||
|
||||
@ -122,10 +122,18 @@ stable kernels.
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A76 | #1490853 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A76 | #3324349 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A77 | #1491015 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A77 | #3324348 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A78 | #3324344 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A78C | #3324346,3324347| ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |
|
||||
@ -138,8 +146,14 @@ stable kernels.
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A720 | #3456091 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A725 | #3456106 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X1 | #1502854 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X1 | #3324344 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X1C | #3324346 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 |
|
||||
@ -160,6 +174,8 @@ stable kernels.
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N1 | #3324349 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N2 | #2139208 | ARM64_ERRATUM_2139208 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N2 | #2067961 | ARM64_ERRATUM_2067961 |
|
||||
@ -170,6 +186,8 @@ stable kernels.
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V1 | #1619801 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V1 | #3324341 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V2 | #3324336 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3194386 |
|
||||
|
||||
@ -239,25 +239,33 @@ The following keys are defined:
|
||||
ratified in commit 98918c844281 ("Merge pull request #1217 from
|
||||
riscv/zawrs") of riscv-isa-manual.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
|
||||
information about the selected set of processors.
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: Deprecated. Returns similar values to
|
||||
:c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`, but the key was
|
||||
mistakenly classified as a bitmask rather than a value.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_UNKNOWN`: The performance of misaligned
|
||||
accesses is unknown.
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`: An enum value describing
|
||||
the performance of misaligned scalar native word accesses on the selected set
|
||||
of processors.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_EMULATED`: Misaligned accesses are
|
||||
emulated via software, either in or below the kernel. These accesses are
|
||||
always extremely slow.
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_UNKNOWN`: The performance of
|
||||
misaligned scalar accesses is unknown.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_SLOW`: Misaligned accesses are slower
|
||||
than equivalent byte accesses. Misaligned accesses may be supported
|
||||
directly in hardware, or trapped and emulated by software.
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_EMULATED`: Misaligned scalar
|
||||
accesses are emulated via software, either in or below the kernel. These
|
||||
accesses are always extremely slow.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_FAST`: Misaligned accesses are faster
|
||||
than equivalent byte accesses.
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_SLOW`: Misaligned scalar native
|
||||
word sized accesses are slower than the equivalent quantity of byte
|
||||
accesses. Misaligned accesses may be supported directly in hardware, or
|
||||
trapped and emulated by software.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_UNSUPPORTED`: Misaligned accesses are
|
||||
not supported at all and will generate a misaligned address fault.
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_FAST`: Misaligned scalar native
|
||||
word sized accesses are faster than the equivalent quantity of byte
|
||||
accesses.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_UNSUPPORTED`: Misaligned scalar
|
||||
accesses are not supported at all and will generate a misaligned address
|
||||
fault.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`: An unsigned int which
|
||||
represents the size of the Zicboz block in bytes.
|
||||
|
||||
@ -418,7 +418,7 @@ The rules for correspondence between registers / stack slots are as follows:
|
||||
linked to the registers and stack slots of the parent state with the same
|
||||
indices.
|
||||
|
||||
* For the outer stack frames, only caller saved registers (r6-r9) and stack
|
||||
* For the outer stack frames, only callee saved registers (r6-r9) and stack
|
||||
slots are linked to the registers and stack slots of the parent state with the
|
||||
same indices.
|
||||
|
||||
|
||||
@ -35,6 +35,9 @@ properties:
|
||||
ports-implemented:
|
||||
const: 1
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
sata-port@0:
|
||||
$ref: /schemas/ata/snps,dwc-ahci-common.yaml#/$defs/dwc-ahci-port
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Display Clock & Reset Controller on SM6350
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm display clock control module provides the clocks, resets and power
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Global Clock & Reset Controller on MSM8994
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module provides the clocks, resets and power
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Global Clock & Reset Controller on SM6125
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module provides the clocks, resets and power
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Global Clock & Reset Controller on SM6350
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module provides the clocks, resets and power
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Graphics Clock & Reset Controller on SM6115
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm graphics clock control module provides clocks, resets and power
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Graphics Clock & Reset Controller on SM6125
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm graphics clock control module provides clocks and power domains on
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Camera Clock & Reset Controller on SM6350
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm camera clock control module provides the clocks, resets and power
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Display Clock & Reset Controller on SM6375
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm display clock control module provides the clocks, resets and power
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Global Clock & Reset Controller on SM6375
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module provides the clocks, resets and power
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Graphics Clock & Reset Controller on SM6375
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm graphics clock control module provides clocks, resets and power
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm SM8350 Video Clock & Reset Controller
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm video clock control module provides the clocks, resets and power
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Graphics Clock & Reset Controller on SM8450
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm graphics clock control module provides the clocks, resets and power
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm SM6375 Display MDSS
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description:
|
||||
SM6375 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: ASUS Z00T TM5P5 NT35596 5.5" 1080×1920 LCD Panel
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konradybcio@gmail.com>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |+
|
||||
This panel seems to only be found in the Asus Z00T
|
||||
|
||||
@ -17,9 +17,12 @@ properties:
|
||||
oneOf:
|
||||
# Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel
|
||||
- const: samsung,atna33xc20
|
||||
# Samsung 14.5" WQXGA+ (2880x1800 pixels) eDP AMOLED panel
|
||||
- items:
|
||||
- const: samsung,atna45af01
|
||||
- enum:
|
||||
# Samsung 14.5" WQXGA+ (2880x1800 pixels) eDP AMOLED panel
|
||||
- samsung,atna45af01
|
||||
# Samsung 14.5" 3K (2944x1840 pixels) eDP AMOLED panel
|
||||
- samsung,atna45dc02
|
||||
- const: samsung,atna33xc20
|
||||
|
||||
enable-gpios: true
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Sony TD4353 JDI 5 / 5.7" 2160x1080 MIPI-DSI Panel
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
The Sony TD4353 JDI is a 5 (XZ2c) / 5.7 (XZ2) inch 2160x1080
|
||||
|
||||
@ -28,6 +28,7 @@ properties:
|
||||
- anvo,anv32e61w
|
||||
- atmel,at25256B
|
||||
- fujitsu,mb85rs1mt
|
||||
- fujitsu,mb85rs256
|
||||
- fujitsu,mb85rs64
|
||||
- microchip,at25160bn
|
||||
- microchip,25lc040
|
||||
|
||||
@ -8,7 +8,7 @@ title: Qualcomm RPMh Network-On-Chip Interconnect on SC7280
|
||||
|
||||
maintainers:
|
||||
- Bjorn Andersson <andersson@kernel.org>
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
RPMh interconnect providers support system bandwidth requirements through
|
||||
|
||||
@ -8,7 +8,7 @@ title: Qualcomm RPMh Network-On-Chip Interconnect on SC8280XP
|
||||
|
||||
maintainers:
|
||||
- Bjorn Andersson <andersson@kernel.org>
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
RPMh interconnect providers support system bandwidth requirements through
|
||||
|
||||
@ -8,7 +8,7 @@ title: Qualcomm RPMh Network-On-Chip Interconnect on SM8450
|
||||
|
||||
maintainers:
|
||||
- Bjorn Andersson <andersson@kernel.org>
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
RPMh interconnect providers support system bandwidth requirements through
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Technologies legacy IOMMU implementations
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm "B" family devices which are not compatible with arm-smmu have
|
||||
|
||||
@ -38,6 +38,10 @@ properties:
|
||||
|
||||
managed: true
|
||||
|
||||
phys:
|
||||
description: A reference to the SerDes lane(s)
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Technologies, Inc. MDM9607 TLMM block
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description:
|
||||
Top Level Mode Multiplexer pin controller in Qualcomm MDM9607 SoC.
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Technologies, Inc. SM6350 TLMM block
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description:
|
||||
Top Level Mode Multiplexer pin controller in Qualcomm SM6350 SoC.
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Technologies, Inc. SM6375 TLMM block
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description:
|
||||
Top Level Mode Multiplexer pin controller in Qualcomm SM6375 SoC.
|
||||
|
||||
@ -8,7 +8,7 @@ title: Qualcomm Resource Power Manager (RPM) Processor/Subsystem
|
||||
|
||||
maintainers:
|
||||
- Bjorn Andersson <andersson@kernel.org>
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
- Stephan Gerhold <stephan@gerhold.net>
|
||||
|
||||
description: |
|
||||
|
||||
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm Technologies, Inc. (QTI) RPM Master Stats
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
The Qualcomm RPM (Resource Power Manager) architecture includes a concept
|
||||
|
||||
@ -199,10 +199,11 @@ additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
codec@1,0{
|
||||
compatible = "slim217,250";
|
||||
reg = <1 0>;
|
||||
reset-gpios = <&tlmm 64 0>;
|
||||
reset-gpios = <&tlmm 64 GPIO_ACTIVE_LOW>;
|
||||
slim-ifc-dev = <&wcd9340_ifd>;
|
||||
#sound-dai-cells = <1>;
|
||||
interrupt-parent = <&tlmm>;
|
||||
|
||||
@ -42,7 +42,7 @@ examples:
|
||||
pinctrl-names = "default", "sleep";
|
||||
pinctrl-0 = <&wcd_reset_n>;
|
||||
pinctrl-1 = <&wcd_reset_n_sleep>;
|
||||
reset-gpios = <&tlmm 83 GPIO_ACTIVE_HIGH>;
|
||||
reset-gpios = <&tlmm 83 GPIO_ACTIVE_LOW>;
|
||||
vdd-buck-supply = <&vreg_l17b_1p8>;
|
||||
vdd-rxtx-supply = <&vreg_l18b_1p8>;
|
||||
vdd-px-supply = <&vreg_l18b_1p8>;
|
||||
|
||||
@ -34,9 +34,10 @@ unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
codec {
|
||||
compatible = "qcom,wcd9380-codec";
|
||||
reset-gpios = <&tlmm 32 0>;
|
||||
reset-gpios = <&tlmm 32 GPIO_ACTIVE_LOW>;
|
||||
#sound-dai-cells = <1>;
|
||||
qcom,tx-device = <&wcd938x_tx>;
|
||||
qcom,rx-device = <&wcd938x_rx>;
|
||||
|
||||
@ -52,10 +52,10 @@ unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
codec {
|
||||
compatible = "qcom,wcd9390-codec";
|
||||
reset-gpios = <&tlmm 32 IRQ_TYPE_NONE>;
|
||||
reset-gpios = <&tlmm 32 GPIO_ACTIVE_LOW>;
|
||||
#sound-dai-cells = <1>;
|
||||
qcom,tx-device = <&wcd939x_tx>;
|
||||
qcom,rx-device = <&wcd939x_rx>;
|
||||
|
||||
@ -18,6 +18,7 @@ properties:
|
||||
- usb424,2412
|
||||
- usb424,2417
|
||||
- usb424,2514
|
||||
- usb424,2517
|
||||
|
||||
reg: true
|
||||
|
||||
|
||||
@ -4,8 +4,6 @@ Generic Thermal Sysfs driver How To
|
||||
|
||||
Written by Sujith Thomas <sujith.thomas@intel.com>, Zhang Rui <rui.zhang@intel.com>
|
||||
|
||||
Updated: 2 January 2008
|
||||
|
||||
Copyright (c) 2008 Intel Corporation
|
||||
|
||||
|
||||
@ -38,23 +36,23 @@ temperature) and throttle appropriate devices.
|
||||
|
||||
::
|
||||
|
||||
struct thermal_zone_device
|
||||
*thermal_zone_device_register(char *type,
|
||||
int trips, int mask, void *devdata,
|
||||
struct thermal_zone_device_ops *ops,
|
||||
const struct thermal_zone_params *tzp,
|
||||
int passive_delay, int polling_delay))
|
||||
struct thermal_zone_device *
|
||||
thermal_zone_device_register_with_trips(const char *type,
|
||||
const struct thermal_trip *trips,
|
||||
int num_trips, void *devdata,
|
||||
const struct thermal_zone_device_ops *ops,
|
||||
const struct thermal_zone_params *tzp,
|
||||
unsigned int passive_delay,
|
||||
unsigned int polling_delay)
|
||||
|
||||
This interface function adds a new thermal zone device (sensor) to
|
||||
This interface function adds a new thermal zone device (sensor) to the
|
||||
/sys/class/thermal folder as `thermal_zone[0-*]`. It tries to bind all the
|
||||
thermal cooling devices registered at the same time.
|
||||
thermal cooling devices registered to it at the same time.
|
||||
|
||||
type:
|
||||
the thermal zone type.
|
||||
trips:
|
||||
the total number of trip points this thermal zone supports.
|
||||
mask:
|
||||
Bit string: If 'n'th bit is set, then trip point 'n' is writable.
|
||||
the table of trip points for this thermal zone.
|
||||
devdata:
|
||||
device private data
|
||||
ops:
|
||||
@ -67,32 +65,29 @@ temperature) and throttle appropriate devices.
|
||||
.get_temp:
|
||||
get the current temperature of the thermal zone.
|
||||
.set_trips:
|
||||
set the trip points window. Whenever the current temperature
|
||||
is updated, the trip points immediately below and above the
|
||||
current temperature are found.
|
||||
.get_mode:
|
||||
get the current mode (enabled/disabled) of the thermal zone.
|
||||
|
||||
- "enabled" means the kernel thermal management is
|
||||
enabled.
|
||||
- "disabled" will prevent kernel thermal driver action
|
||||
upon trip points so that user applications can take
|
||||
charge of thermal management.
|
||||
.set_mode:
|
||||
set the mode (enabled/disabled) of the thermal zone.
|
||||
.get_trip_type:
|
||||
get the type of certain trip point.
|
||||
.get_trip_temp:
|
||||
get the temperature above which the certain trip point
|
||||
will be fired.
|
||||
set the trip points window. Whenever the current temperature
|
||||
is updated, the trip points immediately below and above the
|
||||
current temperature are found.
|
||||
.change_mode:
|
||||
change the mode (enabled/disabled) of the thermal zone.
|
||||
.set_trip_temp:
|
||||
set the temperature of a given trip point.
|
||||
.get_crit_temp:
|
||||
get the critical temperature for this thermal zone.
|
||||
.set_emul_temp:
|
||||
set the emulation temperature which helps in debugging
|
||||
different threshold temperature points.
|
||||
set the emulation temperature which helps in debugging
|
||||
different threshold temperature points.
|
||||
.get_trend:
|
||||
get the trend of most recent zone temperature changes.
|
||||
.hot:
|
||||
hot trip point crossing handler.
|
||||
.critical:
|
||||
critical trip point crossing handler.
|
||||
tzp:
|
||||
thermal zone platform parameters.
|
||||
passive_delay:
|
||||
number of milliseconds to wait between polls when
|
||||
performing passive cooling.
|
||||
number of milliseconds to wait between polls when performing passive
|
||||
cooling.
|
||||
polling_delay:
|
||||
number of milliseconds to wait between polls when checking
|
||||
whether trip points have been crossed (0 for interrupt driven systems).
|
||||
|
||||
@ -318,10 +318,10 @@ where the columns are:
|
||||
Debugging
|
||||
=========
|
||||
|
||||
If CONFIG_FSCACHE_DEBUG is enabled, the FS-Cache facility can have runtime
|
||||
debugging enabled by adjusting the value in::
|
||||
If CONFIG_NETFS_DEBUG is enabled, the FS-Cache facility and NETFS support can
|
||||
have runtime debugging enabled by adjusting the value in::
|
||||
|
||||
/sys/module/fscache/parameters/debug
|
||||
/sys/module/netfs/parameters/debug
|
||||
|
||||
This is a bitmask of debugging streams to enable:
|
||||
|
||||
@ -343,6 +343,6 @@ This is a bitmask of debugging streams to enable:
|
||||
The appropriate set of values should be OR'd together and the result written to
|
||||
the control file. For example::
|
||||
|
||||
echo $((1|8|512)) >/sys/module/fscache/parameters/debug
|
||||
echo $((1|8|512)) >/sys/module/netfs/parameters/debug
|
||||
|
||||
will turn on all function entry debugging.
|
||||
|
||||
@ -75,7 +75,7 @@ Here are the main features of EROFS:
|
||||
|
||||
- Support merging tail-end data into a special inode as fragments.
|
||||
|
||||
- Support large folios for uncompressed files.
|
||||
- Support large folios to make use of THPs (Transparent Hugepages);
|
||||
|
||||
- Support direct I/O on uncompressed files to avoid double caching for loop
|
||||
devices;
|
||||
|
||||
@ -13,7 +13,7 @@ KSMBD architecture
|
||||
The subset of performance related operations belong in kernelspace and
|
||||
the other subset which belong to operations which are not really related with
|
||||
performance in userspace. So, DCE/RPC management that has historically resulted
|
||||
into number of buffer overflow issues and dangerous security bugs and user
|
||||
into a number of buffer overflow issues and dangerous security bugs and user
|
||||
account management are implemented in user space as ksmbd.mountd.
|
||||
File operations that are related with performance (open/read/write/close etc.)
|
||||
in kernel space (ksmbd). This also allows for easier integration with VFS
|
||||
@ -24,8 +24,8 @@ ksmbd (kernel daemon)
|
||||
|
||||
When the server daemon is started, It starts up a forker thread
|
||||
(ksmbd/interface name) at initialization time and open a dedicated port 445
|
||||
for listening to SMB requests. Whenever new clients make request, Forker
|
||||
thread will accept the client connection and fork a new thread for dedicated
|
||||
for listening to SMB requests. Whenever new clients make a request, the Forker
|
||||
thread will accept the client connection and fork a new thread for a dedicated
|
||||
communication channel between the client and the server. It allows for parallel
|
||||
processing of SMB requests(commands) from clients as well as allowing for new
|
||||
clients to make new connections. Each instance is named ksmbd/1~n(port number)
|
||||
@ -34,12 +34,12 @@ thread can decide to pass through the commands to the user space (ksmbd.mountd),
|
||||
currently DCE/RPC commands are identified to be handled through the user space.
|
||||
To further utilize the linux kernel, it has been chosen to process the commands
|
||||
as workitems and to be executed in the handlers of the ksmbd-io kworker threads.
|
||||
It allows for multiplexing of the handlers as the kernel take care of initiating
|
||||
It allows for multiplexing of the handlers as the kernel takes care of initiating
|
||||
extra worker threads if the load is increased and vice versa, if the load is
|
||||
decreased it destroys the extra worker threads. So, after connection is
|
||||
established with client. Dedicated ksmbd/1..n(port number) takes complete
|
||||
decreased it destroys the extra worker threads. So, after the connection is
|
||||
established with the client. Dedicated ksmbd/1..n(port number) takes complete
|
||||
ownership of receiving/parsing of SMB commands. Each received command is worked
|
||||
in parallel i.e., There can be multiple clients commands which are worked in
|
||||
in parallel i.e., there can be multiple client commands which are worked in
|
||||
parallel. After receiving each command a separated kernel workitem is prepared
|
||||
for each command which is further queued to be handled by ksmbd-io kworkers.
|
||||
So, each SMB workitem is queued to the kworkers. This allows the benefit of load
|
||||
@ -49,9 +49,9 @@ performance by handling client commands in parallel.
|
||||
ksmbd.mountd (user space daemon)
|
||||
--------------------------------
|
||||
|
||||
ksmbd.mountd is userspace process to, transfer user account and password that
|
||||
ksmbd.mountd is a userspace process to, transfer the user account and password that
|
||||
are registered using ksmbd.adduser (part of utils for user space). Further it
|
||||
allows sharing information parameters that parsed from smb.conf to ksmbd in
|
||||
allows sharing information parameters that are parsed from smb.conf to ksmbd in
|
||||
kernel. For the execution part it has a daemon which is continuously running
|
||||
and connected to the kernel interface using netlink socket, it waits for the
|
||||
requests (dcerpc and share/user info). It handles RPC calls (at a minimum few
|
||||
@ -124,7 +124,7 @@ How to run
|
||||
1. Download ksmbd-tools(https://github.com/cifsd-team/ksmbd-tools/releases) and
|
||||
compile them.
|
||||
|
||||
- Refer README(https://github.com/cifsd-team/ksmbd-tools/blob/master/README.md)
|
||||
- Refer to README(https://github.com/cifsd-team/ksmbd-tools/blob/master/README.md)
|
||||
to know how to use ksmbd.mountd/adduser/addshare/control utils
|
||||
|
||||
$ ./autogen.sh
|
||||
@ -133,7 +133,7 @@ How to run
|
||||
|
||||
2. Create /usr/local/etc/ksmbd/ksmbd.conf file, add SMB share in ksmbd.conf file.
|
||||
|
||||
- Refer ksmbd.conf.example in ksmbd-utils, See ksmbd.conf manpage
|
||||
- Refer to ksmbd.conf.example in ksmbd-utils, See ksmbd.conf manpage
|
||||
for details to configure shares.
|
||||
|
||||
$ man ksmbd.conf
|
||||
@ -145,7 +145,7 @@ How to run
|
||||
$ man ksmbd.adduser
|
||||
$ sudo ksmbd.adduser -a <Enter USERNAME for SMB share access>
|
||||
|
||||
4. Insert ksmbd.ko module after build your kernel. No need to load module
|
||||
4. Insert the ksmbd.ko module after you build your kernel. No need to load the module
|
||||
if ksmbd is built into the kernel.
|
||||
|
||||
- Set ksmbd in menuconfig(e.g. $ make menuconfig)
|
||||
@ -175,7 +175,7 @@ Each layer
|
||||
1. Enable all component prints
|
||||
# sudo ksmbd.control -d "all"
|
||||
|
||||
2. Enable one of components (smb, auth, vfs, oplock, ipc, conn, rdma)
|
||||
2. Enable one of the components (smb, auth, vfs, oplock, ipc, conn, rdma)
|
||||
# sudo ksmbd.control -d "smb"
|
||||
|
||||
3. Show what prints are enabled.
|
||||
|
||||
@ -1753,6 +1753,7 @@ operations:
|
||||
request:
|
||||
attributes:
|
||||
- header
|
||||
- context
|
||||
reply:
|
||||
attributes:
|
||||
- header
|
||||
@ -1761,7 +1762,6 @@ operations:
|
||||
- indir
|
||||
- hkey
|
||||
- input_xfrm
|
||||
dump: *rss-get-op
|
||||
-
|
||||
name: plca-get-cfg
|
||||
doc: Get PLCA params.
|
||||
|
||||
@ -1875,6 +1875,7 @@ Kernel response contents:
|
||||
|
||||
===================================== ====== ==========================
|
||||
``ETHTOOL_A_RSS_HEADER`` nested reply header
|
||||
``ETHTOOL_A_RSS_CONTEXT`` u32 context number
|
||||
``ETHTOOL_A_RSS_HFUNC`` u32 RSS hash func
|
||||
``ETHTOOL_A_RSS_INDIR`` binary Indir table bytes
|
||||
``ETHTOOL_A_RSS_HKEY`` binary Hash key bytes
|
||||
|
||||
@ -13,9 +13,9 @@ kernel.
|
||||
Hardware issues like Meltdown, Spectre, L1TF etc. must be treated
|
||||
differently because they usually affect all Operating Systems ("OS") and
|
||||
therefore need coordination across different OS vendors, distributions,
|
||||
hardware vendors and other parties. For some of the issues, software
|
||||
mitigations can depend on microcode or firmware updates, which need further
|
||||
coordination.
|
||||
silicon vendors, hardware integrators, and other parties. For some of the
|
||||
issues, software mitigations can depend on microcode or firmware updates,
|
||||
which need further coordination.
|
||||
|
||||
.. _Contact:
|
||||
|
||||
@ -32,8 +32,8 @@ Linux kernel security team (:ref:`Documentation/admin-guide/
|
||||
<securitybugs>`) instead.
|
||||
|
||||
The team can be contacted by email at <hardware-security@kernel.org>. This
|
||||
is a private list of security officers who will help you to coordinate a
|
||||
fix according to our documented process.
|
||||
is a private list of security officers who will help you coordinate a fix
|
||||
according to our documented process.
|
||||
|
||||
The list is encrypted and email to the list can be sent by either PGP or
|
||||
S/MIME encrypted and must be signed with the reporter's PGP key or S/MIME
|
||||
@ -43,7 +43,7 @@ the following URLs:
|
||||
- PGP: https://www.kernel.org/static/files/hardware-security.asc
|
||||
- S/MIME: https://www.kernel.org/static/files/hardware-security.crt
|
||||
|
||||
While hardware security issues are often handled by the affected hardware
|
||||
While hardware security issues are often handled by the affected silicon
|
||||
vendor, we welcome contact from researchers or individuals who have
|
||||
identified a potential hardware flaw.
|
||||
|
||||
@ -65,7 +65,7 @@ of Linux Foundation's IT operations personnel technically have the
|
||||
ability to access the embargoed information, but are obliged to
|
||||
confidentiality by their employment contract. Linux Foundation IT
|
||||
personnel are also responsible for operating and managing the rest of
|
||||
kernel.org infrastructure.
|
||||
kernel.org's infrastructure.
|
||||
|
||||
The Linux Foundation's current director of IT Project infrastructure is
|
||||
Konstantin Ryabitsev.
|
||||
@ -85,7 +85,7 @@ Memorandum of Understanding
|
||||
|
||||
The Linux kernel community has a deep understanding of the requirement to
|
||||
keep hardware security issues under embargo for coordination between
|
||||
different OS vendors, distributors, hardware vendors and other parties.
|
||||
different OS vendors, distributors, silicon vendors, and other parties.
|
||||
|
||||
The Linux kernel community has successfully handled hardware security
|
||||
issues in the past and has the necessary mechanisms in place to allow
|
||||
@ -103,11 +103,11 @@ the issue in the best technical way.
|
||||
All involved developers pledge to adhere to the embargo rules and to keep
|
||||
the received information confidential. Violation of the pledge will lead to
|
||||
immediate exclusion from the current issue and removal from all related
|
||||
mailing-lists. In addition, the hardware security team will also exclude
|
||||
mailing lists. In addition, the hardware security team will also exclude
|
||||
the offender from future issues. The impact of this consequence is a highly
|
||||
effective deterrent in our community. In case a violation happens the
|
||||
hardware security team will inform the involved parties immediately. If you
|
||||
or anyone becomes aware of a potential violation, please report it
|
||||
or anyone else becomes aware of a potential violation, please report it
|
||||
immediately to the Hardware security officers.
|
||||
|
||||
|
||||
@ -124,14 +124,16 @@ method for these types of issues.
|
||||
Start of Disclosure
|
||||
"""""""""""""""""""
|
||||
|
||||
Disclosure starts by contacting the Linux kernel hardware security team by
|
||||
email. This initial contact should contain a description of the problem and
|
||||
a list of any known affected hardware. If your organization builds or
|
||||
distributes the affected hardware, we encourage you to also consider what
|
||||
other hardware could be affected.
|
||||
Disclosure starts by emailing the Linux kernel hardware security team per
|
||||
the Contact section above. This initial contact should contain a
|
||||
description of the problem and a list of any known affected silicon. If
|
||||
your organization builds or distributes the affected hardware, we encourage
|
||||
you to also consider what other hardware could be affected. The disclosing
|
||||
party is responsible for contacting the affected silicon vendors in a
|
||||
timely manner.
|
||||
|
||||
The hardware security team will provide an incident-specific encrypted
|
||||
mailing-list which will be used for initial discussion with the reporter,
|
||||
mailing list which will be used for initial discussion with the reporter,
|
||||
further disclosure, and coordination of fixes.
|
||||
|
||||
The hardware security team will provide the disclosing party a list of
|
||||
@ -158,8 +160,8 @@ This serves several purposes:
|
||||
- The disclosed entities can be contacted to name experts who should
|
||||
participate in the mitigation development.
|
||||
|
||||
- If an expert which is required to handle an issue is employed by an
|
||||
listed entity or member of an listed entity, then the response teams can
|
||||
- If an expert who is required to handle an issue is employed by a listed
|
||||
entity or member of an listed entity, then the response teams can
|
||||
request the disclosure of that expert from that entity. This ensures
|
||||
that the expert is also part of the entity's response team.
|
||||
|
||||
@ -169,8 +171,8 @@ Disclosure
|
||||
The disclosing party provides detailed information to the initial response
|
||||
team via the specific encrypted mailing-list.
|
||||
|
||||
From our experience the technical documentation of these issues is usually
|
||||
a sufficient starting point and further technical clarification is best
|
||||
From our experience, the technical documentation of these issues is usually
|
||||
a sufficient starting point, and further technical clarification is best
|
||||
done via email.
|
||||
|
||||
Mitigation development
|
||||
@ -179,57 +181,93 @@ Mitigation development
|
||||
The initial response team sets up an encrypted mailing-list or repurposes
|
||||
an existing one if appropriate.
|
||||
|
||||
Using a mailing-list is close to the normal Linux development process and
|
||||
has been successfully used in developing mitigations for various hardware
|
||||
Using a mailing list is close to the normal Linux development process and
|
||||
has been successfully used to develop mitigations for various hardware
|
||||
security issues in the past.
|
||||
|
||||
The mailing-list operates in the same way as normal Linux development.
|
||||
Patches are posted, discussed and reviewed and if agreed on applied to a
|
||||
non-public git repository which is only accessible to the participating
|
||||
The mailing list operates in the same way as normal Linux development.
|
||||
Patches are posted, discussed, and reviewed and if agreed upon, applied to
|
||||
a non-public git repository which is only accessible to the participating
|
||||
developers via a secure connection. The repository contains the main
|
||||
development branch against the mainline kernel and backport branches for
|
||||
stable kernel versions as necessary.
|
||||
|
||||
The initial response team will identify further experts from the Linux
|
||||
kernel developer community as needed. Bringing in experts can happen at any
|
||||
time of the development process and needs to be handled in a timely manner.
|
||||
kernel developer community as needed. Any involved party can suggest
|
||||
further experts to be included, each of which will be subject to the same
|
||||
requirements outlined above.
|
||||
|
||||
If an expert is employed by or member of an entity on the disclosure list
|
||||
Bringing in experts can happen at any time in the development process and
|
||||
needs to be handled in a timely manner.
|
||||
|
||||
If an expert is employed by or a member of an entity on the disclosure list
|
||||
provided by the disclosing party, then participation will be requested from
|
||||
the relevant entity.
|
||||
|
||||
If not, then the disclosing party will be informed about the experts
|
||||
If not, then the disclosing party will be informed about the experts'
|
||||
participation. The experts are covered by the Memorandum of Understanding
|
||||
and the disclosing party is requested to acknowledge the participation. In
|
||||
case that the disclosing party has a compelling reason to object, then this
|
||||
objection has to be raised within five work days and resolved with the
|
||||
incident team immediately. If the disclosing party does not react within
|
||||
five work days this is taken as silent acknowledgement.
|
||||
and the disclosing party is requested to acknowledge their participation.
|
||||
In the case where the disclosing party has a compelling reason to object,
|
||||
any objection must to be raised within five working days and resolved with
|
||||
the incident team immediately. If the disclosing party does not react
|
||||
within five working days this is taken as silent acknowledgment.
|
||||
|
||||
After acknowledgement or resolution of an objection the expert is disclosed
|
||||
by the incident team and brought into the development process.
|
||||
After the incident team acknowledges or resolves an objection, the expert
|
||||
is disclosed and brought into the development process.
|
||||
|
||||
List participants may not communicate about the issue outside of the
|
||||
private mailing list. List participants may not use any shared resources
|
||||
(e.g. employer build farms, CI systems, etc) when working on patches.
|
||||
|
||||
Early access
|
||||
""""""""""""
|
||||
|
||||
The patches discussed and developed on the list can neither be distributed
|
||||
to any individual who is not a member of the response team nor to any other
|
||||
organization.
|
||||
|
||||
To allow the affected silicon vendors to work with their internal teams and
|
||||
industry partners on testing, validation, and logistics, the following
|
||||
exception is provided:
|
||||
|
||||
Designated representatives of the affected silicon vendors are
|
||||
allowed to hand over the patches at any time to the silicon
|
||||
vendor’s response team. The representative must notify the kernel
|
||||
response team about the handover. The affected silicon vendor must
|
||||
have and maintain their own documented security process for any
|
||||
patches shared with their response team that is consistent with
|
||||
this policy.
|
||||
|
||||
The silicon vendor’s response team can distribute these patches to
|
||||
their industry partners and to their internal teams under the
|
||||
silicon vendor’s documented security process. Feedback from the
|
||||
industry partners goes back to the silicon vendor and is
|
||||
communicated by the silicon vendor to the kernel response team.
|
||||
|
||||
The handover to the silicon vendor’s response team removes any
|
||||
responsibility or liability from the kernel response team regarding
|
||||
premature disclosure, which happens due to the involvement of the
|
||||
silicon vendor’s internal teams or industry partners. The silicon
|
||||
vendor guarantees this release of liability by agreeing to this
|
||||
process.
|
||||
|
||||
Coordinated release
|
||||
"""""""""""""""""""
|
||||
|
||||
The involved parties will negotiate the date and time where the embargo
|
||||
ends. At that point the prepared mitigations are integrated into the
|
||||
relevant kernel trees and published. There is no pre-notification process:
|
||||
fixes are published in public and available to everyone at the same time.
|
||||
The involved parties will negotiate the date and time when the embargo
|
||||
ends. At that point, the prepared mitigations are published into the
|
||||
relevant kernel trees. There is no pre-notification process: the
|
||||
mitigations are published in public and available to everyone at the same
|
||||
time.
|
||||
|
||||
While we understand that hardware security issues need coordinated embargo
|
||||
time, the embargo time should be constrained to the minimum time which is
|
||||
required for all involved parties to develop, test and prepare the
|
||||
time, the embargo time should be constrained to the minimum time that is
|
||||
required for all involved parties to develop, test, and prepare their
|
||||
mitigations. Extending embargo time artificially to meet conference talk
|
||||
dates or other non-technical reasons is creating more work and burden for
|
||||
the involved developers and response teams as the patches need to be kept
|
||||
up to date in order to follow the ongoing upstream kernel development,
|
||||
which might create conflicting changes.
|
||||
dates or other non-technical reasons creates more work and burden for the
|
||||
involved developers and response teams as the patches need to be kept up to
|
||||
date in order to follow the ongoing upstream kernel development, which
|
||||
might create conflicting changes.
|
||||
|
||||
CVE assignment
|
||||
""""""""""""""
|
||||
@ -275,34 +313,35 @@ an involved disclosed party. The current ambassadors list:
|
||||
|
||||
If you want your organization to be added to the ambassadors list, please
|
||||
contact the hardware security team. The nominated ambassador has to
|
||||
understand and support our process fully and is ideally well connected in
|
||||
understand and support our process fully and is ideally well-connected in
|
||||
the Linux kernel community.
|
||||
|
||||
Encrypted mailing-lists
|
||||
-----------------------
|
||||
|
||||
We use encrypted mailing-lists for communication. The operating principle
|
||||
We use encrypted mailing lists for communication. The operating principle
|
||||
of these lists is that email sent to the list is encrypted either with the
|
||||
list's PGP key or with the list's S/MIME certificate. The mailing-list
|
||||
list's PGP key or with the list's S/MIME certificate. The mailing list
|
||||
software decrypts the email and re-encrypts it individually for each
|
||||
subscriber with the subscriber's PGP key or S/MIME certificate. Details
|
||||
about the mailing-list software and the setup which is used to ensure the
|
||||
about the mailing list software and the setup that is used to ensure the
|
||||
security of the lists and protection of the data can be found here:
|
||||
https://korg.wiki.kernel.org/userdoc/remail.
|
||||
|
||||
List keys
|
||||
^^^^^^^^^
|
||||
|
||||
For initial contact see :ref:`Contact`. For incident specific mailing-lists
|
||||
the key and S/MIME certificate are conveyed to the subscribers by email
|
||||
sent from the specific list.
|
||||
For initial contact see the :ref:`Contact` section above. For incident
|
||||
specific mailing lists, the key and S/MIME certificate are conveyed to the
|
||||
subscribers by email sent from the specific list.
|
||||
|
||||
Subscription to incident specific lists
|
||||
Subscription to incident-specific lists
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Subscription is handled by the response teams. Disclosed parties who want
|
||||
to participate in the communication send a list of potential subscribers to
|
||||
the response team so the response team can validate subscription requests.
|
||||
Subscription to incident-specific lists is handled by the response teams.
|
||||
Disclosed parties who want to participate in the communication send a list
|
||||
of potential experts to the response team so the response team can validate
|
||||
subscription requests.
|
||||
|
||||
Each subscriber needs to send a subscription request to the response team
|
||||
by email. The email must be signed with the subscriber's PGP key or S/MIME
|
||||
|
||||
@ -21,9 +21,9 @@ are often referred to as greyscale formats.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\scriptsize
|
||||
\tiny
|
||||
|
||||
.. tabularcolumns:: |p{3.6cm}|p{3.0cm}|p{1.3cm}|p{2.6cm}|p{1.3cm}|p{1.3cm}|p{1.3cm}|
|
||||
.. tabularcolumns:: |p{3.6cm}|p{2.4cm}|p{1.3cm}|p{1.3cm}|p{1.3cm}|p{1.3cm}|p{1.3cm}|p{1.3cm}|p{1.3cm}|
|
||||
|
||||
.. flat-table:: Luma-Only Image Formats
|
||||
:header-rows: 1
|
||||
|
||||
@ -2592,7 +2592,7 @@ Specifically:
|
||||
0x6030 0000 0010 004a SPSR_ABT 64 spsr[KVM_SPSR_ABT]
|
||||
0x6030 0000 0010 004c SPSR_UND 64 spsr[KVM_SPSR_UND]
|
||||
0x6030 0000 0010 004e SPSR_IRQ 64 spsr[KVM_SPSR_IRQ]
|
||||
0x6060 0000 0010 0050 SPSR_FIQ 64 spsr[KVM_SPSR_FIQ]
|
||||
0x6030 0000 0010 0050 SPSR_FIQ 64 spsr[KVM_SPSR_FIQ]
|
||||
0x6040 0000 0010 0054 V0 128 fp_regs.vregs[0] [1]_
|
||||
0x6040 0000 0010 0058 V1 128 fp_regs.vregs[1] [1]_
|
||||
...
|
||||
@ -6368,7 +6368,7 @@ a single guest_memfd file, but the bound ranges must not overlap).
|
||||
See KVM_SET_USER_MEMORY_REGION2 for additional details.
|
||||
|
||||
4.143 KVM_PRE_FAULT_MEMORY
|
||||
------------------------
|
||||
---------------------------
|
||||
|
||||
:Capability: KVM_CAP_PRE_FAULT_MEMORY
|
||||
:Architectures: none
|
||||
@ -6405,6 +6405,12 @@ for the current vCPU state. KVM maps memory as if the vCPU generated a
|
||||
stage-2 read page fault, e.g. faults in memory as needed, but doesn't break
|
||||
CoW. However, KVM does not mark any newly created stage-2 PTE as Accessed.
|
||||
|
||||
In the case of confidential VM types where there is an initial set up of
|
||||
private guest memory before the guest is 'finalized'/measured, this ioctl
|
||||
should only be issued after completing all the necessary setup to put the
|
||||
guest into a 'finalized' state so that the above semantics can be reliably
|
||||
ensured.
|
||||
|
||||
In some cases, multiple vCPUs might share the page tables. In this
|
||||
case, the ioctl can be called in parallel.
|
||||
|
||||
|
||||
@ -130,12 +130,12 @@ data using the `bmfdec <https://github.com/pali/bmfdec>`_ utility:
|
||||
|
||||
Due to a peculiarity in how Windows handles the ``CreateByteField()`` ACPI operator (errors only
|
||||
happen when a invalid byte field is ultimately accessed), all methods require a 32 byte input
|
||||
buffer, even if the Binay MOF says otherwise.
|
||||
buffer, even if the Binary MOF says otherwise.
|
||||
|
||||
The input buffer contains a single byte to select the subfeature to be accessed and 31 bytes of
|
||||
input data, the meaning of which depends on the subfeature being accessed.
|
||||
|
||||
The output buffer contains a singe byte which signals success or failure (``0x00`` on failure)
|
||||
The output buffer contains a single byte which signals success or failure (``0x00`` on failure)
|
||||
and 31 bytes of output data, the meaning if which depends on the subfeature being accessed.
|
||||
|
||||
WMI method Get_EC()
|
||||
@ -147,7 +147,7 @@ data contains a flag byte and a 28 byte controller firmware version string.
|
||||
The first 4 bits of the flag byte contain the minor version of the embedded controller interface,
|
||||
with the next 2 bits containing the major version of the embedded controller interface.
|
||||
|
||||
The 7th bit signals if the embedded controller page chaged (exact meaning is unknown), and the
|
||||
The 7th bit signals if the embedded controller page changed (exact meaning is unknown), and the
|
||||
last bit signals if the platform is a Tigerlake platform.
|
||||
|
||||
The MSI software seems to only use this interface when the last bit is set.
|
||||
|
||||
13
MAINTAINERS
13
MAINTAINERS
@ -5306,7 +5306,7 @@ F: drivers/media/cec/i2c/ch7322.c
|
||||
CIRRUS LOGIC AUDIO CODEC DRIVERS
|
||||
M: David Rhodes <david.rhodes@cirrus.com>
|
||||
M: Richard Fitzgerald <rf@opensource.cirrus.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
L: patches@opensource.cirrus.com
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/sound/cirrus,cs*
|
||||
@ -5375,7 +5375,7 @@ F: sound/soc/codecs/lochnagar-sc.c
|
||||
CIRRUS LOGIC MADERA CODEC DRIVERS
|
||||
M: Charles Keepax <ckeepax@opensource.cirrus.com>
|
||||
M: Richard Fitzgerald <rf@opensource.cirrus.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-sound@vger.kernel.org
|
||||
L: patches@opensource.cirrus.com
|
||||
S: Supported
|
||||
W: https://github.com/CirrusLogic/linux-drivers/wiki
|
||||
@ -13324,14 +13324,16 @@ F: Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
|
||||
F: drivers/i2c/muxes/i2c-mux-ltc4306.c
|
||||
|
||||
LTP (Linux Test Project)
|
||||
M: Andrea Cervesato <andrea.cervesato@suse.com>
|
||||
M: Cyril Hrubis <chrubis@suse.cz>
|
||||
M: Jan Stancek <jstancek@redhat.com>
|
||||
M: Petr Vorel <pvorel@suse.cz>
|
||||
M: Li Wang <liwang@redhat.com>
|
||||
M: Yang Xu <xuyang2018.jy@fujitsu.com>
|
||||
M: Xiao Yang <yangx.jy@fujitsu.com>
|
||||
L: ltp@lists.linux.it (subscribers-only)
|
||||
S: Maintained
|
||||
W: http://linux-test-project.github.io/
|
||||
W: https://linux-test-project.readthedocs.io/
|
||||
T: git https://github.com/linux-test-project/ltp.git
|
||||
|
||||
LTR390 AMBIENT/UV LIGHT SENSOR DRIVER
|
||||
@ -13539,7 +13541,7 @@ MARVELL GIGABIT ETHERNET DRIVERS (skge/sky2)
|
||||
M: Mirko Lindner <mlindner@marvell.com>
|
||||
M: Stephen Hemminger <stephen@networkplumber.org>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
S: Odd fixes
|
||||
F: drivers/net/ethernet/marvell/sk*
|
||||
|
||||
MARVELL LIBERTAS WIRELESS DRIVER
|
||||
@ -15936,6 +15938,7 @@ F: include/linux/in.h
|
||||
F: include/linux/indirect_call_wrapper.h
|
||||
F: include/linux/net.h
|
||||
F: include/linux/netdevice.h
|
||||
F: include/linux/skbuff.h
|
||||
F: include/net/
|
||||
F: include/uapi/linux/in.h
|
||||
F: include/uapi/linux/net.h
|
||||
@ -18556,7 +18559,7 @@ F: drivers/usb/misc/qcom_eud.c
|
||||
QCOM IPA DRIVER
|
||||
M: Alex Elder <elder@kernel.org>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
S: Maintained
|
||||
F: drivers/net/ipa/
|
||||
|
||||
QEMU MACHINE EMULATOR AND VIRTUALIZER SUPPORT
|
||||
|
||||
4
Makefile
4
Makefile
@ -2,7 +2,7 @@
|
||||
VERSION = 6
|
||||
PATCHLEVEL = 11
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc1
|
||||
EXTRAVERSION = -rc4
|
||||
NAME = Baby Opossum Posse
|
||||
|
||||
# *DOCUMENTATION*
|
||||
@ -1963,7 +1963,7 @@ tags TAGS cscope gtags: FORCE
|
||||
# Protocol).
|
||||
PHONY += rust-analyzer
|
||||
rust-analyzer:
|
||||
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/rust_is_available.sh
|
||||
+$(Q)$(CONFIG_SHELL) $(srctree)/scripts/rust_is_available.sh
|
||||
$(Q)$(MAKE) $(build)=rust $@
|
||||
|
||||
# Script to generate missing namespace dependencies
|
||||
|
||||
@ -534,8 +534,10 @@ extern inline void writeq(u64 b, volatile void __iomem *addr)
|
||||
|
||||
#define ioread16be(p) swab16(ioread16(p))
|
||||
#define ioread32be(p) swab32(ioread32(p))
|
||||
#define ioread64be(p) swab64(ioread64(p))
|
||||
#define iowrite16be(v,p) iowrite16(swab16(v), (p))
|
||||
#define iowrite32be(v,p) iowrite32(swab32(v), (p))
|
||||
#define iowrite64be(v,p) iowrite64(swab64(v), (p))
|
||||
|
||||
#define inb_p inb
|
||||
#define inw_p inw
|
||||
@ -634,8 +636,6 @@ extern void outsl (unsigned long port, const void *src, unsigned long count);
|
||||
*/
|
||||
#define ioread64 ioread64
|
||||
#define iowrite64 iowrite64
|
||||
#define ioread64be ioread64be
|
||||
#define iowrite64be iowrite64be
|
||||
#define ioread8_rep ioread8_rep
|
||||
#define ioread16_rep ioread16_rep
|
||||
#define ioread32_rep ioread32_rep
|
||||
|
||||
@ -87,6 +87,7 @@ config ARM
|
||||
select HAVE_ARCH_PFN_VALID
|
||||
select HAVE_ARCH_SECCOMP
|
||||
select HAVE_ARCH_SECCOMP_FILTER if AEABI && !OABI_COMPAT
|
||||
select HAVE_ARCH_STACKLEAK
|
||||
select HAVE_ARCH_THREAD_STRUCT_WHITELIST
|
||||
select HAVE_ARCH_TRACEHOOK
|
||||
select HAVE_ARCH_TRANSPARENT_HUGEPAGE if ARM_LPAE
|
||||
@ -116,6 +117,7 @@ config ARM
|
||||
select HAVE_KERNEL_XZ
|
||||
select HAVE_KPROBES if !XIP_KERNEL && !CPU_ENDIAN_BE32 && !CPU_V7M
|
||||
select HAVE_KRETPROBES if HAVE_KPROBES
|
||||
select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
|
||||
select HAVE_MOD_ARCH_SPECIFIC
|
||||
select HAVE_NMI
|
||||
select HAVE_OPTPROBES if !THUMB2_KERNEL
|
||||
@ -736,7 +738,7 @@ config ARM_ERRATA_764319
|
||||
bool "ARM errata: Read to DBGPRSR and DBGOSLSR may generate Undefined instruction"
|
||||
depends on CPU_V7
|
||||
help
|
||||
This option enables the workaround for the 764319 Cortex A-9 erratum.
|
||||
This option enables the workaround for the 764319 Cortex-A9 erratum.
|
||||
CP14 read accesses to the DBGPRSR and DBGOSLSR registers generate an
|
||||
unexpected Undefined Instruction exception when the DBGSWENABLE
|
||||
external pin is set to 0, even when the CP14 accesses are performed
|
||||
|
||||
@ -9,6 +9,7 @@ OBJS =
|
||||
|
||||
HEAD = head.o
|
||||
OBJS += misc.o decompress.o
|
||||
CFLAGS_decompress.o += $(DISABLE_STACKLEAK_PLUGIN)
|
||||
ifeq ($(CONFIG_DEBUG_UNCOMPRESS),y)
|
||||
OBJS += debug.o
|
||||
AFLAGS_head.o += -DDEBUG
|
||||
|
||||
@ -125,7 +125,7 @@ SECTIONS
|
||||
|
||||
. = BSS_START;
|
||||
__bss_start = .;
|
||||
.bss : { *(.bss) }
|
||||
.bss : { *(.bss .bss.*) }
|
||||
_end = .;
|
||||
|
||||
. = ALIGN(8); /* the stack must be 64-bit aligned */
|
||||
|
||||
@ -157,7 +157,7 @@ timclk: clock-1000000 {
|
||||
clocks = <&xtal24mhz>;
|
||||
};
|
||||
|
||||
pclk: clock-24000000 {
|
||||
pclk: clock-pclk {
|
||||
#clock-cells = <0>;
|
||||
compatible = "fixed-factor-clock";
|
||||
clock-div = <1>;
|
||||
|
||||
@ -26,6 +26,13 @@ struct stackframe {
|
||||
#endif
|
||||
};
|
||||
|
||||
static inline bool on_thread_stack(void)
|
||||
{
|
||||
unsigned long delta = current_stack_pointer ^ (unsigned long)current->stack;
|
||||
|
||||
return delta < THREAD_SIZE;
|
||||
}
|
||||
|
||||
static __always_inline
|
||||
void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame)
|
||||
{
|
||||
|
||||
@ -42,7 +42,7 @@
|
||||
#define PROC_INFO \
|
||||
. = ALIGN(4); \
|
||||
__proc_info_begin = .; \
|
||||
*(.proc.info.init) \
|
||||
KEEP(*(.proc.info.init)) \
|
||||
__proc_info_end = .;
|
||||
|
||||
#define IDMAP_TEXT \
|
||||
|
||||
@ -1065,6 +1065,7 @@ vector_addrexcptn:
|
||||
.globl vector_fiq
|
||||
|
||||
.section .vectors, "ax", %progbits
|
||||
.reloc .text, R_ARM_NONE, .
|
||||
W(b) vector_rst
|
||||
W(b) vector_und
|
||||
ARM( .reloc ., R_ARM_LDR_PC_G0, .L__vector_swi )
|
||||
@ -1078,6 +1079,7 @@ THUMB( .reloc ., R_ARM_THM_PC12, .L__vector_swi )
|
||||
|
||||
#ifdef CONFIG_HARDEN_BRANCH_HISTORY
|
||||
.section .vectors.bhb.loop8, "ax", %progbits
|
||||
.reloc .text, R_ARM_NONE, .
|
||||
W(b) vector_rst
|
||||
W(b) vector_bhb_loop8_und
|
||||
ARM( .reloc ., R_ARM_LDR_PC_G0, .L__vector_bhb_loop8_swi )
|
||||
@ -1090,6 +1092,7 @@ THUMB( .reloc ., R_ARM_THM_PC12, .L__vector_bhb_loop8_swi )
|
||||
W(b) vector_bhb_loop8_fiq
|
||||
|
||||
.section .vectors.bhb.bpiall, "ax", %progbits
|
||||
.reloc .text, R_ARM_NONE, .
|
||||
W(b) vector_rst
|
||||
W(b) vector_bhb_bpiall_und
|
||||
ARM( .reloc ., R_ARM_LDR_PC_G0, .L__vector_bhb_bpiall_swi )
|
||||
|
||||
@ -119,6 +119,9 @@ no_work_pending:
|
||||
|
||||
ct_user_enter save = 0
|
||||
|
||||
#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
|
||||
bl stackleak_erase_on_task_stack
|
||||
#endif
|
||||
restore_user_regs fast = 0, offset = 0
|
||||
ENDPROC(ret_to_user_from_irq)
|
||||
ENDPROC(ret_to_user)
|
||||
|
||||
@ -395,11 +395,6 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
|
||||
return 0;
|
||||
}
|
||||
|
||||
struct mod_unwind_map {
|
||||
const Elf_Shdr *unw_sec;
|
||||
const Elf_Shdr *txt_sec;
|
||||
};
|
||||
|
||||
static const Elf_Shdr *find_mod_section(const Elf32_Ehdr *hdr,
|
||||
const Elf_Shdr *sechdrs, const char *name)
|
||||
{
|
||||
|
||||
@ -85,8 +85,7 @@ static bool
|
||||
callchain_trace(void *data, unsigned long pc)
|
||||
{
|
||||
struct perf_callchain_entry_ctx *entry = data;
|
||||
perf_callchain_store(entry, pc);
|
||||
return true;
|
||||
return perf_callchain_store(entry, pc) == 0;
|
||||
}
|
||||
|
||||
void
|
||||
|
||||
@ -63,7 +63,7 @@ SECTIONS
|
||||
. = ALIGN(4);
|
||||
__ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
|
||||
__start___ex_table = .;
|
||||
ARM_MMU_KEEP(*(__ex_table))
|
||||
ARM_MMU_KEEP(KEEP(*(__ex_table)))
|
||||
__stop___ex_table = .;
|
||||
}
|
||||
|
||||
@ -83,7 +83,7 @@ SECTIONS
|
||||
}
|
||||
.init.arch.info : {
|
||||
__arch_info_begin = .;
|
||||
*(.arch.info.init)
|
||||
KEEP(*(.arch.info.init))
|
||||
__arch_info_end = .;
|
||||
}
|
||||
.init.tagtable : {
|
||||
|
||||
@ -74,7 +74,7 @@ SECTIONS
|
||||
. = ALIGN(4);
|
||||
__ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
|
||||
__start___ex_table = .;
|
||||
ARM_MMU_KEEP(*(__ex_table))
|
||||
ARM_MMU_KEEP(KEEP(*(__ex_table)))
|
||||
__stop___ex_table = .;
|
||||
}
|
||||
|
||||
@ -99,7 +99,7 @@ SECTIONS
|
||||
}
|
||||
.init.arch.info : {
|
||||
__arch_info_begin = .;
|
||||
*(.arch.info.init)
|
||||
KEEP(*(.arch.info.init))
|
||||
__arch_info_end = .;
|
||||
}
|
||||
.init.tagtable : {
|
||||
@ -116,7 +116,7 @@ SECTIONS
|
||||
#endif
|
||||
.init.pv_table : {
|
||||
__pv_table_begin = .;
|
||||
*(.pv_table)
|
||||
KEEP(*(.pv_table))
|
||||
__pv_table_end = .;
|
||||
}
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@ int alpine_cpu_wakeup(unsigned int phys_cpu, uint32_t phys_resume_addr)
|
||||
/*
|
||||
* Set CPU resume address -
|
||||
* secure firmware running on boot will jump to this address
|
||||
* after setting proper CPU mode, and initialiing e.g. secure
|
||||
* after setting proper CPU mode, and initializing e.g. secure
|
||||
* regs (the same mode all CPUs are booted to - usually HYP)
|
||||
*/
|
||||
writel(phys_resume_addr,
|
||||
|
||||
@ -21,6 +21,7 @@
|
||||
#include <linux/mtd/mtd.h>
|
||||
#include <linux/mtd/partitions.h>
|
||||
#include <linux/gpio/machine.h>
|
||||
#include <linux/gpio/property.h>
|
||||
#include <linux/gpio.h>
|
||||
#include <linux/err.h>
|
||||
#include <linux/clk.h>
|
||||
@ -40,6 +41,7 @@
|
||||
#include <linux/platform_data/mmc-pxamci.h>
|
||||
#include "udc.h"
|
||||
#include "gumstix.h"
|
||||
#include "devices.h"
|
||||
|
||||
#include "generic.h"
|
||||
|
||||
@ -99,8 +101,8 @@ static void __init gumstix_mmc_init(void)
|
||||
}
|
||||
#endif
|
||||
|
||||
#ifdef CONFIG_USB_PXA25X
|
||||
static const struct property_entry spitz_mci_props[] __initconst = {
|
||||
#if IS_ENABLED(CONFIG_USB_PXA25X)
|
||||
static const struct property_entry gumstix_vbus_props[] __initconst = {
|
||||
PROPERTY_ENTRY_GPIO("vbus-gpios", &pxa2xx_gpiochip_node,
|
||||
GPIO_GUMSTIX_USB_GPIOn, GPIO_ACTIVE_HIGH),
|
||||
PROPERTY_ENTRY_GPIO("pullup-gpios", &pxa2xx_gpiochip_node,
|
||||
@ -109,8 +111,9 @@ static const struct property_entry spitz_mci_props[] __initconst = {
|
||||
};
|
||||
|
||||
static const struct platform_device_info gumstix_gpio_vbus_info __initconst = {
|
||||
.name = "gpio-vbus",
|
||||
.id = PLATFORM_DEVID_NONE,
|
||||
.name = "gpio-vbus",
|
||||
.id = PLATFORM_DEVID_NONE,
|
||||
.properties = gumstix_vbus_props,
|
||||
};
|
||||
|
||||
static void __init gumstix_udc_init(void)
|
||||
|
||||
@ -1109,7 +1109,7 @@ void ecard_remove_driver(struct ecard_driver *drv)
|
||||
driver_unregister(&drv->drv);
|
||||
}
|
||||
|
||||
static int ecard_match(struct device *_dev, struct device_driver *_drv)
|
||||
static int ecard_match(struct device *_dev, const struct device_driver *_drv)
|
||||
{
|
||||
struct expansion_card *ec = ECARD_DEV(_dev);
|
||||
struct ecard_driver *drv = ECARD_DRV(_drv);
|
||||
|
||||
@ -17,7 +17,7 @@ void cpu_arm7tdmi_proc_init(void);
|
||||
__ADDRESSABLE(cpu_arm7tdmi_proc_init);
|
||||
void cpu_arm7tdmi_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm7tdmi_proc_fin);
|
||||
void cpu_arm7tdmi_reset(void);
|
||||
void cpu_arm7tdmi_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm7tdmi_reset);
|
||||
int cpu_arm7tdmi_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm7tdmi_do_idle);
|
||||
@ -32,7 +32,7 @@ void cpu_arm720_proc_init(void);
|
||||
__ADDRESSABLE(cpu_arm720_proc_init);
|
||||
void cpu_arm720_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm720_proc_fin);
|
||||
void cpu_arm720_reset(void);
|
||||
void cpu_arm720_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm720_reset);
|
||||
int cpu_arm720_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm720_do_idle);
|
||||
@ -49,7 +49,7 @@ void cpu_arm740_proc_init(void);
|
||||
__ADDRESSABLE(cpu_arm740_proc_init);
|
||||
void cpu_arm740_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm740_proc_fin);
|
||||
void cpu_arm740_reset(void);
|
||||
void cpu_arm740_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm740_reset);
|
||||
int cpu_arm740_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm740_do_idle);
|
||||
@ -64,7 +64,7 @@ void cpu_arm9tdmi_proc_init(void);
|
||||
__ADDRESSABLE(cpu_arm9tdmi_proc_init);
|
||||
void cpu_arm9tdmi_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm9tdmi_proc_fin);
|
||||
void cpu_arm9tdmi_reset(void);
|
||||
void cpu_arm9tdmi_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm9tdmi_reset);
|
||||
int cpu_arm9tdmi_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm9tdmi_do_idle);
|
||||
@ -79,7 +79,7 @@ void cpu_arm920_proc_init(void);
|
||||
__ADDRESSABLE(cpu_arm920_proc_init);
|
||||
void cpu_arm920_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm920_proc_fin);
|
||||
void cpu_arm920_reset(void);
|
||||
void cpu_arm920_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm920_reset);
|
||||
int cpu_arm920_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm920_do_idle);
|
||||
@ -102,7 +102,7 @@ void cpu_arm922_proc_init(void);
|
||||
__ADDRESSABLE(cpu_arm922_proc_init);
|
||||
void cpu_arm922_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm922_proc_fin);
|
||||
void cpu_arm922_reset(void);
|
||||
void cpu_arm922_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm922_reset);
|
||||
int cpu_arm922_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm922_do_idle);
|
||||
@ -119,7 +119,7 @@ void cpu_arm925_proc_init(void);
|
||||
__ADDRESSABLE(cpu_arm925_proc_init);
|
||||
void cpu_arm925_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm925_proc_fin);
|
||||
void cpu_arm925_reset(void);
|
||||
void cpu_arm925_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm925_reset);
|
||||
int cpu_arm925_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm925_do_idle);
|
||||
@ -159,7 +159,7 @@ void cpu_arm940_proc_init(void);
|
||||
__ADDRESSABLE(cpu_arm940_proc_init);
|
||||
void cpu_arm940_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm940_proc_fin);
|
||||
void cpu_arm940_reset(void);
|
||||
void cpu_arm940_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm940_reset);
|
||||
int cpu_arm940_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm940_do_idle);
|
||||
@ -174,7 +174,7 @@ void cpu_arm946_proc_init(void);
|
||||
__ADDRESSABLE(cpu_arm946_proc_init);
|
||||
void cpu_arm946_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm946_proc_fin);
|
||||
void cpu_arm946_reset(void);
|
||||
void cpu_arm946_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm946_reset);
|
||||
int cpu_arm946_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm946_do_idle);
|
||||
@ -429,7 +429,7 @@ void cpu_v7_proc_init(void);
|
||||
__ADDRESSABLE(cpu_v7_proc_init);
|
||||
void cpu_v7_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_v7_proc_fin);
|
||||
void cpu_v7_reset(void);
|
||||
void cpu_v7_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_v7_reset);
|
||||
int cpu_v7_do_idle(void);
|
||||
__ADDRESSABLE(cpu_v7_do_idle);
|
||||
|
||||
@ -1069,18 +1069,28 @@ config ARM64_ERRATUM_3117295
|
||||
If unsure, say Y.
|
||||
|
||||
config ARM64_ERRATUM_3194386
|
||||
bool "Cortex-{A720,X4,X925}/Neoverse-V3: workaround for MSR SSBS not self-synchronizing"
|
||||
bool "Cortex-*/Neoverse-*: workaround for MSR SSBS not self-synchronizing"
|
||||
default y
|
||||
help
|
||||
This option adds the workaround for the following errata:
|
||||
|
||||
* ARM Cortex-A76 erratum 3324349
|
||||
* ARM Cortex-A77 erratum 3324348
|
||||
* ARM Cortex-A78 erratum 3324344
|
||||
* ARM Cortex-A78C erratum 3324346
|
||||
* ARM Cortex-A78C erratum 3324347
|
||||
* ARM Cortex-A710 erratam 3324338
|
||||
* ARM Cortex-A720 erratum 3456091
|
||||
* ARM Cortex-A725 erratum 3456106
|
||||
* ARM Cortex-X1 erratum 3324344
|
||||
* ARM Cortex-X1C erratum 3324346
|
||||
* ARM Cortex-X2 erratum 3324338
|
||||
* ARM Cortex-X3 erratum 3324335
|
||||
* ARM Cortex-X4 erratum 3194386
|
||||
* ARM Cortex-X925 erratum 3324334
|
||||
* ARM Neoverse-N1 erratum 3324349
|
||||
* ARM Neoverse N2 erratum 3324339
|
||||
* ARM Neoverse-V1 erratum 3324341
|
||||
* ARM Neoverse V2 erratum 3324336
|
||||
* ARM Neoverse-V3 erratum 3312417
|
||||
|
||||
@ -1088,11 +1098,11 @@ config ARM64_ERRATUM_3194386
|
||||
subsequent speculative instructions, which may permit unexepected
|
||||
speculative store bypassing.
|
||||
|
||||
Work around this problem by placing a speculation barrier after
|
||||
kernel changes to SSBS. The presence of the SSBS special-purpose
|
||||
register is hidden from hwcaps and EL0 reads of ID_AA64PFR1_EL1, such
|
||||
that userspace will use the PR_SPEC_STORE_BYPASS prctl to change
|
||||
SSBS.
|
||||
Work around this problem by placing a Speculation Barrier (SB) or
|
||||
Instruction Synchronization Barrier (ISB) after kernel changes to
|
||||
SSBS. The presence of the SSBS special-purpose register is hidden
|
||||
from hwcaps and EL0 reads of ID_AA64PFR1_EL1, such that userspace
|
||||
will use the PR_SPEC_STORE_BYPASS prctl to change SSBS.
|
||||
|
||||
If unsure, say Y.
|
||||
|
||||
|
||||
@ -43,15 +43,6 @@ simple-audio-card,cpu {
|
||||
sound-dai = <&mcasp0>;
|
||||
};
|
||||
};
|
||||
|
||||
reg_usb_hub: regulator-usb-hub {
|
||||
compatible = "regulator-fixed";
|
||||
enable-active-high;
|
||||
/* Verdin CTRL_SLEEP_MOCI# (SODIMM 256) */
|
||||
gpio = <&main_gpio0 31 GPIO_ACTIVE_HIGH>;
|
||||
regulator-boot-on;
|
||||
regulator-name = "HUB_PWR_EN";
|
||||
};
|
||||
};
|
||||
|
||||
/* Verdin ETHs */
|
||||
@ -193,11 +184,6 @@ &ospi0 {
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
/* Do not force CTRL_SLEEP_MOCI# always enabled */
|
||||
®_force_sleep_moci {
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
/* Verdin SD_1 */
|
||||
&sdhci1 {
|
||||
status = "okay";
|
||||
@ -218,15 +204,7 @@ &usbss1 {
|
||||
};
|
||||
|
||||
&usb1 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
status = "okay";
|
||||
|
||||
usb-hub@1 {
|
||||
compatible = "usb424,2744";
|
||||
reg = <1>;
|
||||
vdd-supply = <®_usb_hub>;
|
||||
};
|
||||
};
|
||||
|
||||
/* Verdin CTRL_WAKE1_MICO# */
|
||||
|
||||
@ -138,12 +138,6 @@ reg_1v8_eth: regulator-1v8-eth {
|
||||
vin-supply = <®_1v8>;
|
||||
};
|
||||
|
||||
/*
|
||||
* By default we enable CTRL_SLEEP_MOCI#, this is required to have
|
||||
* peripherals on the carrier board powered.
|
||||
* If more granularity or power saving is required this can be disabled
|
||||
* in the carrier board device tree files.
|
||||
*/
|
||||
reg_force_sleep_moci: regulator-force-sleep-moci {
|
||||
compatible = "regulator-fixed";
|
||||
enable-active-high;
|
||||
|
||||
@ -146,6 +146,8 @@ mcu_gpio0: gpio@4201000 {
|
||||
power-domains = <&k3_pds 79 TI_SCI_PD_EXCLUSIVE>;
|
||||
clocks = <&k3_clks 79 0>;
|
||||
clock-names = "gpio";
|
||||
gpio-ranges = <&mcu_pmx0 0 0 21>, <&mcu_pmx0 21 23 1>,
|
||||
<&mcu_pmx0 22 32 2>;
|
||||
};
|
||||
|
||||
mcu_rti0: watchdog@4880000 {
|
||||
|
||||
@ -45,7 +45,8 @@ &inta_main_dmss {
|
||||
&main_pmx0 {
|
||||
pinctrl-single,gpio-range =
|
||||
<&main_pmx0_range 0 32 PIN_GPIO_RANGE_IOPAD>,
|
||||
<&main_pmx0_range 33 92 PIN_GPIO_RANGE_IOPAD>,
|
||||
<&main_pmx0_range 33 38 PIN_GPIO_RANGE_IOPAD>,
|
||||
<&main_pmx0_range 72 22 PIN_GPIO_RANGE_IOPAD>,
|
||||
<&main_pmx0_range 137 5 PIN_GPIO_RANGE_IOPAD>,
|
||||
<&main_pmx0_range 143 3 PIN_GPIO_RANGE_IOPAD>,
|
||||
<&main_pmx0_range 149 2 PIN_GPIO_RANGE_IOPAD>;
|
||||
|
||||
@ -193,7 +193,8 @@ &inta_main_dmss {
|
||||
&main_pmx0 {
|
||||
pinctrl-single,gpio-range =
|
||||
<&main_pmx0_range 0 32 PIN_GPIO_RANGE_IOPAD>,
|
||||
<&main_pmx0_range 33 55 PIN_GPIO_RANGE_IOPAD>,
|
||||
<&main_pmx0_range 33 38 PIN_GPIO_RANGE_IOPAD>,
|
||||
<&main_pmx0_range 72 17 PIN_GPIO_RANGE_IOPAD>,
|
||||
<&main_pmx0_range 101 25 PIN_GPIO_RANGE_IOPAD>,
|
||||
<&main_pmx0_range 137 5 PIN_GPIO_RANGE_IOPAD>,
|
||||
<&main_pmx0_range 143 3 PIN_GPIO_RANGE_IOPAD>,
|
||||
|
||||
@ -1262,6 +1262,14 @@ &dss {
|
||||
&serdes0 {
|
||||
status = "okay";
|
||||
|
||||
serdes0_pcie1_link: phy@0 {
|
||||
reg = <0>;
|
||||
cdns,num-lanes = <2>;
|
||||
#phy-cells = <0>;
|
||||
cdns,phy-type = <PHY_TYPE_PCIE>;
|
||||
resets = <&serdes_wiz0 1>, <&serdes_wiz0 2>;
|
||||
};
|
||||
|
||||
serdes0_usb_link: phy@3 {
|
||||
reg = <3>;
|
||||
cdns,num-lanes = <1>;
|
||||
@ -1386,23 +1394,6 @@ &main_mcan4 {
|
||||
phys = <&transceiver3>;
|
||||
};
|
||||
|
||||
&serdes0 {
|
||||
status = "okay";
|
||||
|
||||
serdes0_pcie1_link: phy@0 {
|
||||
reg = <0>;
|
||||
cdns,num-lanes = <4>;
|
||||
#phy-cells = <0>;
|
||||
cdns,phy-type = <PHY_TYPE_PCIE>;
|
||||
resets = <&serdes_wiz0 1>, <&serdes_wiz0 2>,
|
||||
<&serdes_wiz0 3>, <&serdes_wiz0 4>;
|
||||
};
|
||||
};
|
||||
|
||||
&serdes_wiz0 {
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&pcie1_rc {
|
||||
status = "okay";
|
||||
num-lanes = <2>;
|
||||
|
||||
@ -2755,7 +2755,7 @@ mcasp3: mcasp@2b30000 {
|
||||
interrupts = <GIC_SPI 550 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 551 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "tx", "rx";
|
||||
dmas = <&main_udmap 0xc500>, <&main_udmap 0x4500>;
|
||||
dmas = <&main_udmap 0xc403>, <&main_udmap 0x4403>;
|
||||
dma-names = "tx", "rx";
|
||||
clocks = <&k3_clks 268 0>;
|
||||
clock-names = "fck";
|
||||
@ -2773,7 +2773,7 @@ mcasp4: mcasp@2b40000 {
|
||||
interrupts = <GIC_SPI 552 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 553 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "tx", "rx";
|
||||
dmas = <&main_udmap 0xc501>, <&main_udmap 0x4501>;
|
||||
dmas = <&main_udmap 0xc404>, <&main_udmap 0x4404>;
|
||||
dma-names = "tx", "rx";
|
||||
clocks = <&k3_clks 269 0>;
|
||||
clock-names = "fck";
|
||||
|
||||
@ -86,12 +86,14 @@
|
||||
#define ARM_CPU_PART_CORTEX_X2 0xD48
|
||||
#define ARM_CPU_PART_NEOVERSE_N2 0xD49
|
||||
#define ARM_CPU_PART_CORTEX_A78C 0xD4B
|
||||
#define ARM_CPU_PART_CORTEX_X1C 0xD4C
|
||||
#define ARM_CPU_PART_CORTEX_X3 0xD4E
|
||||
#define ARM_CPU_PART_NEOVERSE_V2 0xD4F
|
||||
#define ARM_CPU_PART_CORTEX_A720 0xD81
|
||||
#define ARM_CPU_PART_CORTEX_X4 0xD82
|
||||
#define ARM_CPU_PART_NEOVERSE_V3 0xD84
|
||||
#define ARM_CPU_PART_CORTEX_X925 0xD85
|
||||
#define ARM_CPU_PART_CORTEX_A725 0xD87
|
||||
|
||||
#define APM_CPU_PART_XGENE 0x000
|
||||
#define APM_CPU_VAR_POTENZA 0x00
|
||||
@ -165,12 +167,14 @@
|
||||
#define MIDR_CORTEX_X2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X2)
|
||||
#define MIDR_NEOVERSE_N2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_N2)
|
||||
#define MIDR_CORTEX_A78C MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A78C)
|
||||
#define MIDR_CORTEX_X1C MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X1C)
|
||||
#define MIDR_CORTEX_X3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X3)
|
||||
#define MIDR_NEOVERSE_V2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V2)
|
||||
#define MIDR_CORTEX_A720 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A720)
|
||||
#define MIDR_CORTEX_X4 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X4)
|
||||
#define MIDR_NEOVERSE_V3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V3)
|
||||
#define MIDR_CORTEX_X925 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X925)
|
||||
#define MIDR_CORTEX_A725 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A725)
|
||||
#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
|
||||
#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
|
||||
#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_83XX)
|
||||
|
||||
@ -13,6 +13,7 @@
|
||||
#include <linux/types.h>
|
||||
#include <asm/insn.h>
|
||||
|
||||
#define HAVE_JUMP_LABEL_BATCH
|
||||
#define JUMP_LABEL_NOP_SIZE AARCH64_INSN_SIZE
|
||||
|
||||
#define JUMP_TABLE_ENTRY(key, label) \
|
||||
|
||||
@ -104,7 +104,7 @@ alternative_else_nop_endif
|
||||
|
||||
#define __ptrauth_save_key(ctxt, key) \
|
||||
do { \
|
||||
u64 __val; \
|
||||
u64 __val; \
|
||||
__val = read_sysreg_s(SYS_ ## key ## KEYLO_EL1); \
|
||||
ctxt_sys_reg(ctxt, key ## KEYLO_EL1) = __val; \
|
||||
__val = read_sysreg_s(SYS_ ## key ## KEYHI_EL1); \
|
||||
|
||||
@ -188,7 +188,7 @@ static inline void __user *__uaccess_mask_ptr(const void __user *ptr)
|
||||
#define __get_mem_asm(load, reg, x, addr, label, type) \
|
||||
asm_goto_output( \
|
||||
"1: " load " " reg "0, [%1]\n" \
|
||||
_ASM_EXTABLE_##type##ACCESS_ERR(1b, %l2, %w0) \
|
||||
_ASM_EXTABLE_##type##ACCESS(1b, %l2) \
|
||||
: "=r" (x) \
|
||||
: "r" (addr) : : label)
|
||||
#else
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
syscall_abis_32 +=
|
||||
syscall_abis_64 += renameat newstat rlimit memfd_secret
|
||||
syscall_abis_64 += renameat rlimit memfd_secret
|
||||
|
||||
syscalltbl = arch/arm64/tools/syscall_%.tbl
|
||||
|
||||
@ -27,7 +27,7 @@
|
||||
|
||||
#include <asm/numa.h>
|
||||
|
||||
static int acpi_early_node_map[NR_CPUS] __initdata = { NUMA_NO_NODE };
|
||||
static int acpi_early_node_map[NR_CPUS] __initdata = { [0 ... NR_CPUS - 1] = NUMA_NO_NODE };
|
||||
|
||||
int __init acpi_numa_get_nid(unsigned int cpu)
|
||||
{
|
||||
|
||||
@ -434,15 +434,24 @@ static const struct midr_range erratum_spec_unpriv_load_list[] = {
|
||||
|
||||
#ifdef CONFIG_ARM64_ERRATUM_3194386
|
||||
static const struct midr_range erratum_spec_ssbs_list[] = {
|
||||
MIDR_ALL_VERSIONS(MIDR_CORTEX_A76),
|
||||
MIDR_ALL_VERSIONS(MIDR_CORTEX_A77),
|
||||
MIDR_ALL_VERSIONS(MIDR_CORTEX_A78),
|
||||
MIDR_ALL_VERSIONS(MIDR_CORTEX_A78C),
|
||||
MIDR_ALL_VERSIONS(MIDR_CORTEX_A710),
|
||||
MIDR_ALL_VERSIONS(MIDR_CORTEX_A720),
|
||||
MIDR_ALL_VERSIONS(MIDR_CORTEX_A725),
|
||||
MIDR_ALL_VERSIONS(MIDR_CORTEX_X1),
|
||||
MIDR_ALL_VERSIONS(MIDR_CORTEX_X1C),
|
||||
MIDR_ALL_VERSIONS(MIDR_CORTEX_X2),
|
||||
MIDR_ALL_VERSIONS(MIDR_CORTEX_X3),
|
||||
MIDR_ALL_VERSIONS(MIDR_CORTEX_X4),
|
||||
MIDR_ALL_VERSIONS(MIDR_CORTEX_X925),
|
||||
MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1),
|
||||
MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N2),
|
||||
MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V3),
|
||||
MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V1),
|
||||
MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V2),
|
||||
MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V3),
|
||||
{}
|
||||
};
|
||||
#endif
|
||||
|
||||
@ -7,11 +7,12 @@
|
||||
*/
|
||||
#include <linux/kernel.h>
|
||||
#include <linux/jump_label.h>
|
||||
#include <linux/smp.h>
|
||||
#include <asm/insn.h>
|
||||
#include <asm/patching.h>
|
||||
|
||||
void arch_jump_label_transform(struct jump_entry *entry,
|
||||
enum jump_label_type type)
|
||||
bool arch_jump_label_transform_queue(struct jump_entry *entry,
|
||||
enum jump_label_type type)
|
||||
{
|
||||
void *addr = (void *)jump_entry_code(entry);
|
||||
u32 insn;
|
||||
@ -25,4 +26,10 @@ void arch_jump_label_transform(struct jump_entry *entry,
|
||||
}
|
||||
|
||||
aarch64_insn_patch_text_nosync(addr, insn);
|
||||
return true;
|
||||
}
|
||||
|
||||
void arch_jump_label_transform_apply(void)
|
||||
{
|
||||
kick_all_cpus_sync();
|
||||
}
|
||||
|
||||
@ -355,9 +355,6 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p)
|
||||
smp_init_cpus();
|
||||
smp_build_mpidr_hash();
|
||||
|
||||
/* Init percpu seeds for random tags after cpus are set up. */
|
||||
kasan_init_sw_tags();
|
||||
|
||||
#ifdef CONFIG_ARM64_SW_TTBR0_PAN
|
||||
/*
|
||||
* Make sure init_thread_info.ttbr0 always generates translation
|
||||
|
||||
@ -467,6 +467,8 @@ void __init smp_prepare_boot_cpu(void)
|
||||
init_gic_priority_masking();
|
||||
|
||||
kasan_init_hw_tags();
|
||||
/* Init percpu seeds for random tags after cpus are set up. */
|
||||
kasan_init_sw_tags();
|
||||
}
|
||||
|
||||
/*
|
||||
|
||||
@ -19,6 +19,7 @@ if VIRTUALIZATION
|
||||
|
||||
menuconfig KVM
|
||||
bool "Kernel-based Virtual Machine (KVM) support"
|
||||
depends on AS_HAS_ARMV8_4
|
||||
select KVM_COMMON
|
||||
select KVM_GENERIC_HARDWARE_ENABLING
|
||||
select KVM_GENERIC_MMU_NOTIFIER
|
||||
|
||||
@ -10,6 +10,9 @@ include $(srctree)/virt/kvm/Makefile.kvm
|
||||
obj-$(CONFIG_KVM) += kvm.o
|
||||
obj-$(CONFIG_KVM) += hyp/
|
||||
|
||||
CFLAGS_sys_regs.o += -Wno-override-init
|
||||
CFLAGS_handle_exit.o += -Wno-override-init
|
||||
|
||||
kvm-y += arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \
|
||||
inject_fault.o va_layout.o handle_exit.o \
|
||||
guest.o debug.o reset.o sys_regs.o stacktrace.o \
|
||||
|
||||
@ -164,6 +164,7 @@ static int kvm_arm_default_max_vcpus(void)
|
||||
/**
|
||||
* kvm_arch_init_vm - initializes a VM data structure
|
||||
* @kvm: pointer to the KVM struct
|
||||
* @type: kvm device type
|
||||
*/
|
||||
int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
|
||||
{
|
||||
@ -521,10 +522,10 @@ void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu)
|
||||
|
||||
static void vcpu_set_pauth_traps(struct kvm_vcpu *vcpu)
|
||||
{
|
||||
if (vcpu_has_ptrauth(vcpu)) {
|
||||
if (vcpu_has_ptrauth(vcpu) && !is_protected_kvm_enabled()) {
|
||||
/*
|
||||
* Either we're running running an L2 guest, and the API/APK
|
||||
* bits come from L1's HCR_EL2, or API/APK are both set.
|
||||
* Either we're running an L2 guest, and the API/APK bits come
|
||||
* from L1's HCR_EL2, or API/APK are both set.
|
||||
*/
|
||||
if (unlikely(vcpu_has_nv(vcpu) && !is_hyp_ctxt(vcpu))) {
|
||||
u64 val;
|
||||
@ -541,16 +542,10 @@ static void vcpu_set_pauth_traps(struct kvm_vcpu *vcpu)
|
||||
* Save the host keys if there is any chance for the guest
|
||||
* to use pauth, as the entry code will reload the guest
|
||||
* keys in that case.
|
||||
* Protected mode is the exception to that rule, as the
|
||||
* entry into the EL2 code eagerly switch back and forth
|
||||
* between host and hyp keys (and kvm_hyp_ctxt is out of
|
||||
* reach anyway).
|
||||
*/
|
||||
if (is_protected_kvm_enabled())
|
||||
return;
|
||||
|
||||
if (vcpu->arch.hcr_el2 & (HCR_API | HCR_APK)) {
|
||||
struct kvm_cpu_context *ctxt;
|
||||
|
||||
ctxt = this_cpu_ptr_hyp_sym(kvm_hyp_ctxt);
|
||||
ptrauth_save_keys(ctxt);
|
||||
}
|
||||
|
||||
@ -27,7 +27,6 @@
|
||||
#include <asm/kvm_hyp.h>
|
||||
#include <asm/kvm_mmu.h>
|
||||
#include <asm/kvm_nested.h>
|
||||
#include <asm/kvm_ptrauth.h>
|
||||
#include <asm/fpsimd.h>
|
||||
#include <asm/debug-monitors.h>
|
||||
#include <asm/processor.h>
|
||||
|
||||
@ -20,6 +20,8 @@ HOST_EXTRACFLAGS += -I$(objtree)/include
|
||||
lib-objs := clear_page.o copy_page.o memcpy.o memset.o
|
||||
lib-objs := $(addprefix ../../../lib/, $(lib-objs))
|
||||
|
||||
CFLAGS_switch.nvhe.o += -Wno-override-init
|
||||
|
||||
hyp-obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o hyp-init.o host.o \
|
||||
hyp-main.o hyp-smp.o psci-relay.o early_alloc.o page_alloc.o \
|
||||
cache.o setup.o mm.o mem_protect.o sys_regs.o pkvm.o stacktrace.o ffa.o
|
||||
|
||||
@ -173,9 +173,8 @@ static void __pmu_switch_to_host(struct kvm_vcpu *vcpu)
|
||||
static bool kvm_handle_pvm_sys64(struct kvm_vcpu *vcpu, u64 *exit_code)
|
||||
{
|
||||
/*
|
||||
* Make sure we handle the exit for workarounds and ptrauth
|
||||
* before the pKVM handling, as the latter could decide to
|
||||
* UNDEF.
|
||||
* Make sure we handle the exit for workarounds before the pKVM
|
||||
* handling, as the latter could decide to UNDEF.
|
||||
*/
|
||||
return (kvm_hyp_handle_sysreg(vcpu, exit_code) ||
|
||||
kvm_handle_pvm_sysreg(vcpu, exit_code));
|
||||
|
||||
@ -6,6 +6,8 @@
|
||||
asflags-y := -D__KVM_VHE_HYPERVISOR__
|
||||
ccflags-y := -D__KVM_VHE_HYPERVISOR__
|
||||
|
||||
CFLAGS_switch.o += -Wno-override-init
|
||||
|
||||
obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o
|
||||
obj-y += ../vgic-v3-sr.o ../aarch32.o ../vgic-v2-cpuif-proxy.o ../entry.o \
|
||||
../fpsimd.o ../hyp-entry.o ../exception.o
|
||||
|
||||
@ -786,7 +786,7 @@ void kvm_arch_flush_shadow_all(struct kvm *kvm)
|
||||
if (!WARN_ON(atomic_read(&mmu->refcnt)))
|
||||
kvm_free_stage2_pgd(mmu);
|
||||
}
|
||||
kfree(kvm->arch.nested_mmus);
|
||||
kvfree(kvm->arch.nested_mmus);
|
||||
kvm->arch.nested_mmus = NULL;
|
||||
kvm->arch.nested_mmus_size = 0;
|
||||
kvm_uninit_stage2_mmu(kvm);
|
||||
|
||||
@ -45,7 +45,8 @@ static void iter_next(struct kvm *kvm, struct vgic_state_iter *iter)
|
||||
* Let the xarray drive the iterator after the last SPI, as the iterator
|
||||
* has exhausted the sequentially-allocated INTID space.
|
||||
*/
|
||||
if (iter->intid >= (iter->nr_spis + VGIC_NR_PRIVATE_IRQS - 1)) {
|
||||
if (iter->intid >= (iter->nr_spis + VGIC_NR_PRIVATE_IRQS - 1) &&
|
||||
iter->nr_lpis) {
|
||||
if (iter->lpi_idx < iter->nr_lpis)
|
||||
xa_find_after(&dist->lpi_xa, &iter->intid,
|
||||
VGIC_LPI_MAX_INTID,
|
||||
@ -112,7 +113,7 @@ static bool end_of_vgic(struct vgic_state_iter *iter)
|
||||
return iter->dist_id > 0 &&
|
||||
iter->vcpu_id == iter->nr_cpus &&
|
||||
iter->intid >= (iter->nr_spis + VGIC_NR_PRIVATE_IRQS) &&
|
||||
iter->lpi_idx > iter->nr_lpis;
|
||||
(!iter->nr_lpis || iter->lpi_idx > iter->nr_lpis);
|
||||
}
|
||||
|
||||
static void *vgic_debug_start(struct seq_file *s, loff_t *pos)
|
||||
|
||||
@ -438,14 +438,13 @@ void kvm_vgic_destroy(struct kvm *kvm)
|
||||
unsigned long i;
|
||||
|
||||
mutex_lock(&kvm->slots_lock);
|
||||
mutex_lock(&kvm->arch.config_lock);
|
||||
|
||||
vgic_debug_destroy(kvm);
|
||||
|
||||
kvm_for_each_vcpu(i, vcpu, kvm)
|
||||
__kvm_vgic_vcpu_destroy(vcpu);
|
||||
|
||||
mutex_lock(&kvm->arch.config_lock);
|
||||
|
||||
kvm_vgic_dist_destroy(kvm);
|
||||
|
||||
mutex_unlock(&kvm->arch.config_lock);
|
||||
|
||||
@ -9,7 +9,7 @@
|
||||
#include <kvm/arm_vgic.h>
|
||||
#include "vgic.h"
|
||||
|
||||
/**
|
||||
/*
|
||||
* vgic_irqfd_set_irq: inject the IRQ corresponding to the
|
||||
* irqchip routing entry
|
||||
*
|
||||
@ -75,7 +75,8 @@ static void kvm_populate_msi(struct kvm_kernel_irq_routing_entry *e,
|
||||
msi->flags = e->msi.flags;
|
||||
msi->devid = e->msi.devid;
|
||||
}
|
||||
/**
|
||||
|
||||
/*
|
||||
* kvm_set_msi: inject the MSI corresponding to the
|
||||
* MSI routing entry
|
||||
*
|
||||
@ -98,7 +99,7 @@ int kvm_set_msi(struct kvm_kernel_irq_routing_entry *e,
|
||||
return vgic_its_inject_msi(kvm, &msi);
|
||||
}
|
||||
|
||||
/**
|
||||
/*
|
||||
* kvm_arch_set_irq_inatomic: fast-path for irqfd injection
|
||||
*/
|
||||
int kvm_arch_set_irq_inatomic(struct kvm_kernel_irq_routing_entry *e,
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user