mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-11-15 00:04:15 +08:00
Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf
Cross-merge bpf fixes after downstream PR including important fixes (from bpf-next point of view): commit41c24102af("selftests/bpf: Filter out _GNU_SOURCE when compiling test_cpp") commitfdad456cbc("bpf: Fix updating attached freplace prog in prog_array map") No conflicts. Adjacent changes in: include/linux/bpf_verifier.h kernel/bpf/verifier.c tools/testing/selftests/bpf/Makefile Link: https://lore.kernel.org/bpf/20240813234307.82773-1-alexei.starovoitov@gmail.com/ Signed-off-by: Alexei Starovoitov <ast@kernel.org>
This commit is contained in:
Alexei Starovoitov
commit
50c374c6d1
2
.mailmap
2
.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>
|
||||
@ -260,6 +261,7 @@ Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@motorola.com>
|
||||
Jakub Kicinski <kuba@kernel.org> <jakub.kicinski@netronome.com>
|
||||
James Bottomley <jejb@mulgrave.(none)>
|
||||
James Bottomley <jejb@titanic.il.steeleye.com>
|
||||
James Clark <james.clark@linaro.org> <james.clark@arm.com>
|
||||
James E Wilson <wilson@specifix.com>
|
||||
James Hogan <jhogan@kernel.org> <james@albanarts.com>
|
||||
James Hogan <jhogan@kernel.org> <james.hogan@imgtec.com>
|
||||
|
||||
@ -14,9 +14,10 @@ Description:
|
||||
event to its internal Informational Event log, updates the
|
||||
Event Status register, and if configured, interrupts the host.
|
||||
It is not an error to inject poison into an address that
|
||||
already has poison present and no error is returned. The
|
||||
inject_poison attribute is only visible for devices supporting
|
||||
the capability.
|
||||
already has poison present and no error is returned. If the
|
||||
device returns 'Inject Poison Limit Reached' an -EBUSY error
|
||||
is returned to the user. The inject_poison attribute is only
|
||||
visible for devices supporting the capability.
|
||||
|
||||
|
||||
What: /sys/kernel/debug/memX/clear_poison
|
||||
|
||||
@ -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
|
||||
|
||||
@ -3830,9 +3830,6 @@
|
||||
|
||||
noalign [KNL,ARM]
|
||||
|
||||
noaltinstr [S390,EARLY] Disables alternative instructions
|
||||
patching (CPU alternatives feature).
|
||||
|
||||
noapic [SMP,APIC,EARLY] Tells the kernel to not make use of any
|
||||
IOAPICs that may be present in the system.
|
||||
|
||||
@ -4801,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,28 +239,38 @@ 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.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_HIGHEST_VIRT_ADDRESS`: An unsigned long which
|
||||
represent the highest userspace virtual address usable.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_TIME_CSR_FREQ`: Frequency (in Hz) of `time CSR`.
|
||||
|
||||
@ -47,11 +47,12 @@ RISC-V Linux Kernel SV39
|
||||
| Kernel-space virtual memory, shared between all processes:
|
||||
____________________________________________________________|___________________________________________________________
|
||||
| | | |
|
||||
ffffffc6fea00000 | -228 GB | ffffffc6feffffff | 6 MB | fixmap
|
||||
ffffffc6ff000000 | -228 GB | ffffffc6ffffffff | 16 MB | PCI io
|
||||
ffffffc700000000 | -228 GB | ffffffc7ffffffff | 4 GB | vmemmap
|
||||
ffffffc800000000 | -224 GB | ffffffd7ffffffff | 64 GB | vmalloc/ioremap space
|
||||
ffffffd800000000 | -160 GB | fffffff6ffffffff | 124 GB | direct mapping of all physical memory
|
||||
ffffffc4fea00000 | -236 GB | ffffffc4feffffff | 6 MB | fixmap
|
||||
ffffffc4ff000000 | -236 GB | ffffffc4ffffffff | 16 MB | PCI io
|
||||
ffffffc500000000 | -236 GB | ffffffc5ffffffff | 4 GB | vmemmap
|
||||
ffffffc600000000 | -232 GB | ffffffd5ffffffff | 64 GB | vmalloc/ioremap space
|
||||
ffffffd600000000 | -168 GB | fffffff5ffffffff | 128 GB | direct mapping of all physical memory
|
||||
| | | |
|
||||
fffffff700000000 | -36 GB | fffffffeffffffff | 32 GB | kasan
|
||||
__________________|____________|__________________|_________|____________________________________________________________
|
||||
|
|
||||
|
||||
@ -30,7 +30,7 @@ description: |
|
||||
maintainers:
|
||||
- Mike Leach <mike.leach@linaro.org>
|
||||
- Suzuki K Poulose <suzuki.poulose@arm.com>
|
||||
- James Clark <james.clark@arm.com>
|
||||
- James Clark <james.clark@linaro.org>
|
||||
- Mao Jinlong <quic_jinlmao@quicinc.com>
|
||||
- Hao Zhang <quic_hazha@quicinc.com>
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@ description: |
|
||||
maintainers:
|
||||
- Mike Leach <mike.leach@linaro.org>
|
||||
- Suzuki K Poulose <suzuki.poulose@arm.com>
|
||||
- James Clark <james.clark@arm.com>
|
||||
- James Clark <james.clark@linaro.org>
|
||||
- Mao Jinlong <quic_jinlmao@quicinc.com>
|
||||
- Hao Zhang <quic_hazha@quicinc.com>
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -14,7 +14,16 @@ allOf:
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: samsung,atna33xc20
|
||||
oneOf:
|
||||
# Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel
|
||||
- const: samsung,atna33xc20
|
||||
- items:
|
||||
- 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
|
||||
port: 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
|
||||
|
||||
@ -91,6 +91,7 @@ patternProperties:
|
||||
- const: 0
|
||||
- description: |
|
||||
Shall encode the I3C LVR (Legacy Virtual Register):
|
||||
See include/dt-bindings/i3c/i3c.h
|
||||
bit[31:8]: unused/ignored
|
||||
bit[7:5]: I2C device index. Possible values:
|
||||
* 0: I2C device has a 50 ns spike filter
|
||||
@ -153,6 +154,8 @@ additionalProperties: true
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/i3c/i3c.h>
|
||||
|
||||
i3c@d040000 {
|
||||
compatible = "cdns,i3c-master";
|
||||
clocks = <&coreclock>, <&i3csysclock>;
|
||||
@ -166,7 +169,7 @@ examples:
|
||||
/* I2C device. */
|
||||
eeprom@57 {
|
||||
compatible = "atmel,24c01";
|
||||
reg = <0x57 0x0 0x10>;
|
||||
reg = <0x57 0x0 (I2C_FM | I2C_FILTER)>;
|
||||
pagesize = <0x8>;
|
||||
};
|
||||
|
||||
|
||||
@ -20,7 +20,16 @@ properties:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
minItems: 1
|
||||
items:
|
||||
- description: Core clock
|
||||
- description: APB clock
|
||||
|
||||
clock-names:
|
||||
minItems: 1
|
||||
items:
|
||||
- const: core
|
||||
- const: apb
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
@ -120,9 +120,8 @@ patternProperties:
|
||||
description:
|
||||
Positive input can be connected to pins AIN1 to AIN16 by choosing the
|
||||
appropriate value from 1 to 16. Negative input is connected to AINCOM.
|
||||
items:
|
||||
minimum: 1
|
||||
maximum: 16
|
||||
minimum: 1
|
||||
maximum: 16
|
||||
|
||||
oneOf:
|
||||
- required:
|
||||
|
||||
@ -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>;
|
||||
|
||||
@ -328,7 +328,9 @@ properties:
|
||||
- renesas,hs3001
|
||||
# Renesas ISL29501 time-of-flight sensor
|
||||
- renesas,isl29501
|
||||
# Rohm DH2228FV
|
||||
# Rohm BH2228FV 8 channel DAC
|
||||
- rohm,bh2228fv
|
||||
# Rohm DH2228FV - This device does not exist, use rohm,bh2228fv instead.
|
||||
- rohm,dh2228fv
|
||||
# S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
|
||||
- samsung,24ad0xd1
|
||||
|
||||
@ -18,6 +18,7 @@ properties:
|
||||
- usb424,2412
|
||||
- usb424,2417
|
||||
- usb424,2514
|
||||
- usb424,2517
|
||||
|
||||
reg: true
|
||||
|
||||
|
||||
@ -21,6 +21,7 @@ properties:
|
||||
- amlogic,t7-wdt
|
||||
- items:
|
||||
- enum:
|
||||
- amlogic,a4-wdt
|
||||
- amlogic,c3-wdt
|
||||
- amlogic,s4-wdt
|
||||
- const: amlogic,t7-wdt
|
||||
|
||||
@ -9,4 +9,6 @@ Compute Express Link
|
||||
|
||||
memory-devices
|
||||
|
||||
maturity-map
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
202
Documentation/driver-api/cxl/maturity-map.rst
Normal file
202
Documentation/driver-api/cxl/maturity-map.rst
Normal file
@ -0,0 +1,202 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
.. include:: <isonum.txt>
|
||||
|
||||
===========================================
|
||||
Compute Express Link Subsystem Maturity Map
|
||||
===========================================
|
||||
|
||||
The Linux CXL subsystem tracks the dynamic `CXL specification
|
||||
<https://computeexpresslink.org/cxl-specification-landing-page>`_ that
|
||||
continues to respond to new use cases with new features, capability
|
||||
updates and fixes. At any given point some aspects of the subsystem are
|
||||
more mature than others. While the periodic pull requests summarize the
|
||||
`work being incorporated each merge window
|
||||
<https://lore.kernel.org/linux-cxl/?q=s%3APULL+s%3ACXL+tc%3Atorvalds+NOT+s%3ARe>`_,
|
||||
those do not always convey progress relative to a starting point and a
|
||||
future end goal.
|
||||
|
||||
What follows is a coarse breakdown of the subsystem's major
|
||||
responsibilities along with a maturity score. The expectation is that
|
||||
the change-history of this document provides an overview summary of the
|
||||
subsystem maturation over time.
|
||||
|
||||
The maturity scores are:
|
||||
|
||||
- [3] Mature: Work in this area is complete and no changes on the horizon.
|
||||
Note that this score can regress from one kernel release to the next
|
||||
based on new test results or end user reports.
|
||||
|
||||
- [2] Stabilizing: Major functionality operational, common cases are
|
||||
mature, but known corner cases are still a work in progress.
|
||||
|
||||
- [1] Initial: Capability that has exited the Proof of Concept phase, but
|
||||
may still have significant gaps to close and fixes to apply as real
|
||||
world testing occurs.
|
||||
|
||||
- [0] Known gap: Feature is on a medium to long term horizon to
|
||||
implement. If the specification has a feature that does not even have
|
||||
a '0' score in this document, there is a good chance that no one in
|
||||
the linux-cxl@vger.kernel.org community has started to look at it.
|
||||
|
||||
- X: Out of scope for kernel enabling, or kernel enabling not required
|
||||
|
||||
Feature and Capabilities
|
||||
========================
|
||||
|
||||
Enumeration / Provisioning
|
||||
--------------------------
|
||||
All of the fundamental enumeration an object model of the subsystem is
|
||||
in place, but there are several corner cases that are pending closure.
|
||||
|
||||
|
||||
* [2] CXL Window Enumeration
|
||||
|
||||
* [0] :ref:`Extended-linear memory-side cache <extended-linear>`
|
||||
* [0] Low Memory-hole
|
||||
* [0] Hetero-interleave
|
||||
|
||||
* [2] Switch Enumeration
|
||||
|
||||
* [0] CXL register enumeration link-up dependency
|
||||
|
||||
* [2] HDM Decoder Configuration
|
||||
|
||||
* [0] Decoder target and granularity constraints
|
||||
|
||||
* [2] Performance enumeration
|
||||
|
||||
* [3] Endpoint CDAT
|
||||
* [3] Switch CDAT
|
||||
* [1] CDAT to Core-mm integration
|
||||
|
||||
* [1] x86
|
||||
* [0] Arm64
|
||||
* [0] All other arch.
|
||||
|
||||
* [0] Shared link
|
||||
|
||||
* [2] Hotplug
|
||||
(see CXL Window Enumeration)
|
||||
|
||||
* [0] Handle Soft Reserved conflicts
|
||||
|
||||
* [0] :ref:`RCH link status <rch-link-status>`
|
||||
* [0] Fabrics / G-FAM (chapter 7)
|
||||
* [0] Global Access Endpoint
|
||||
|
||||
|
||||
RAS
|
||||
---
|
||||
In many ways CXL can be seen as a standardization of what would normally
|
||||
be handled by custom EDAC drivers. The open development here is
|
||||
mainly caused by the enumeration corner cases above.
|
||||
|
||||
* [3] Component events (OS)
|
||||
* [2] Component events (FFM)
|
||||
* [1] Endpoint protocol errors (OS)
|
||||
* [1] Endpoint protocol errors (FFM)
|
||||
* [0] Switch protocol errors (OS)
|
||||
* [1] Switch protocol errors (FFM)
|
||||
* [2] DPA->HPA Address translation
|
||||
|
||||
* [1] XOR Interleave translation
|
||||
(see CXL Window Enumeration)
|
||||
|
||||
* [1] Memory Failure coordination
|
||||
* [0] Scrub control
|
||||
* [2] ACPI error injection EINJ
|
||||
|
||||
* [0] EINJ v2
|
||||
* [X] Compliance DOE
|
||||
|
||||
* [2] Native error injection
|
||||
* [3] RCH error handling
|
||||
* [1] VH error handling
|
||||
* [0] PPR
|
||||
* [0] Sparing
|
||||
* [0] Device built in test
|
||||
|
||||
|
||||
Mailbox commands
|
||||
----------------
|
||||
|
||||
* [3] Firmware update
|
||||
* [3] Health / Alerts
|
||||
* [1] :ref:`Background commands <background-commands>`
|
||||
* [3] Sanitization
|
||||
* [3] Security commands
|
||||
* [3] RAW Command Debug Passthrough
|
||||
* [0] CEL-only-validation Passthrough
|
||||
* [0] Switch CCI
|
||||
* [3] Timestamp
|
||||
* [1] PMEM labels
|
||||
* [0] PMEM GPF / Dirty Shutdown
|
||||
* [0] Scan Media
|
||||
|
||||
PMU
|
||||
---
|
||||
* [1] Type 3 PMU
|
||||
* [0] Switch USP/ DSP, Root Port
|
||||
|
||||
Security
|
||||
--------
|
||||
|
||||
* [X] CXL Trusted Execution Environment Security Protocol (TSP)
|
||||
* [X] CXL IDE (subsumed by TSP)
|
||||
|
||||
Memory-pooling
|
||||
--------------
|
||||
|
||||
* [1] Hotplug of LDs (via PCI hotplug)
|
||||
* [0] Dynamic Capacity Device (DCD) Support
|
||||
|
||||
Multi-host sharing
|
||||
------------------
|
||||
|
||||
* [0] Hardware coherent shared memory
|
||||
* [0] Software managed coherency shared memory
|
||||
|
||||
Multi-host memory
|
||||
-----------------
|
||||
|
||||
* [0] Dynamic Capacity Device Support
|
||||
* [0] Sharing
|
||||
|
||||
Accelerator
|
||||
-----------
|
||||
|
||||
* [0] Accelerator memory enumeration HDM-D (CXL 1.1/2.0 Type-2)
|
||||
* [0] Accelerator memory enumeration HDM-DB (CXL 3.0 Type-2)
|
||||
* [0] CXL.cache 68b (CXL 2.0)
|
||||
* [0] CXL.cache 256b Cache IDs (CXL 3.0)
|
||||
|
||||
User Flow Support
|
||||
-----------------
|
||||
|
||||
* [0] HPA->DPA Address translation (need xormaps export solution)
|
||||
|
||||
Details
|
||||
=======
|
||||
|
||||
.. _extended-linear:
|
||||
|
||||
* **Extended-linear memory-side cache**: An HMAT proposal to enumerate the presence of a
|
||||
memory-side cache where the cache capacity extends the SRAT address
|
||||
range capacity. `See the ECN
|
||||
<https://lore.kernel.org/linux-cxl/6650e4f835a0e_195e294a8@dwillia2-mobl3.amr.corp.intel.com.notmuch/>`_
|
||||
for more details:
|
||||
|
||||
.. _rch-link-status:
|
||||
|
||||
* **RCH Link Status**: RCH (Restricted CXL Host) topologies, end up
|
||||
hiding some standard registers like PCIe Link Status / Capabilities in
|
||||
the CXL RCRB (Root Complex Register Block).
|
||||
|
||||
.. _background-commands:
|
||||
|
||||
* **Background commands**: The CXL background command mechanism is
|
||||
awkward as the single slot is monopolized potentially indefinitely by
|
||||
various commands. A `cancel on conflict
|
||||
<http://lore.kernel.org/r/66035c2e8ba17_770232948b@dwillia2-xfh.jf.intel.com.notmuch>`_
|
||||
facility is needed to make sure the kernel can ensure forward progress
|
||||
of priority commands.
|
||||
@ -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.
|
||||
|
||||
@ -8,37 +8,22 @@ and the code documentation when it is automatically generated.
|
||||
DCHUBBUB
|
||||
--------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/dchubbub.h
|
||||
:doc: overview
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h
|
||||
:internal:
|
||||
|
||||
HUBP
|
||||
----
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h
|
||||
:doc: overview
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h
|
||||
:internal:
|
||||
|
||||
DPP
|
||||
---
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
|
||||
:doc: overview
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
|
||||
:internal:
|
||||
|
||||
MPC
|
||||
@ -47,11 +32,9 @@ MPC
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
|
||||
:doc: overview
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
|
||||
:internal:
|
||||
:no-identifiers: mpcc_blnd_cfg mpcc_alpha_blend_mode
|
||||
|
||||
OPP
|
||||
---
|
||||
@ -59,20 +42,14 @@ OPP
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/opp.h
|
||||
:doc: overview
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/opp.h
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/opp.h
|
||||
:internal:
|
||||
|
||||
DIO
|
||||
---
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.c
|
||||
:doc: overview
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.h
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/link/hwss/link_hwss_dio.c
|
||||
:internal:
|
||||
|
||||
@ -132,7 +132,7 @@ The DRM blend mode and its elements are then mapped by AMDGPU display manager
|
||||
(MPC), as follows:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
|
||||
:functions: mpcc_blnd_cfg
|
||||
:identifiers: mpcc_blnd_cfg
|
||||
|
||||
Therefore, the blending configuration for a single MPCC instance on the MPC
|
||||
tree is defined by :c:type:`mpcc_blnd_cfg`, where
|
||||
@ -144,7 +144,7 @@ alpha and plane alpha values. It sets one of the three modes for
|
||||
:c:type:`MPCC_ALPHA_BLND_MODE`, as described below.
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h
|
||||
:functions: mpcc_alpha_blend_mode
|
||||
:identifiers: mpcc_alpha_blend_mode
|
||||
|
||||
DM then maps the elements of `enum mpcc_alpha_blend_mode` to those in the DRM
|
||||
blend formula, as follows:
|
||||
|
||||
@ -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
|
||||
|
||||
@ -89,14 +89,7 @@ docs on :ref:`Building Linux with Clang/LLVM <kbuild_llvm>`.
|
||||
Rust (optional)
|
||||
---------------
|
||||
|
||||
A particular version of the Rust toolchain is required. Newer versions may or
|
||||
may not work because the kernel depends on some unstable Rust features, for
|
||||
the moment.
|
||||
|
||||
Each Rust toolchain comes with several "components", some of which are required
|
||||
(like ``rustc``) and some that are optional. The ``rust-src`` component (which
|
||||
is optional) needs to be installed to build the kernel. Other components are
|
||||
useful for developing.
|
||||
A recent version of the Rust compiler is required.
|
||||
|
||||
Please see Documentation/rust/quick-start.rst for instructions on how to
|
||||
satisfy the build requirements of Rust support. In particular, the ``Makefile``
|
||||
|
||||
@ -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
|
||||
|
||||
@ -7,6 +7,14 @@ This document contains useful information to know when working with
|
||||
the Rust support in the kernel.
|
||||
|
||||
|
||||
``no_std``
|
||||
----------
|
||||
|
||||
The Rust support in the kernel can link only `core <https://doc.rust-lang.org/core/>`_,
|
||||
but not `std <https://doc.rust-lang.org/std/>`_. Crates for use in the
|
||||
kernel must opt into this behavior using the ``#![no_std]`` attribute.
|
||||
|
||||
|
||||
Code documentation
|
||||
------------------
|
||||
|
||||
|
||||
@ -5,17 +5,93 @@ Quick Start
|
||||
|
||||
This document describes how to get started with kernel development in Rust.
|
||||
|
||||
There are a few ways to install a Rust toolchain needed for kernel development.
|
||||
A simple way is to use the packages from your Linux distribution if they are
|
||||
suitable -- the first section below explains this approach. An advantage of this
|
||||
approach is that, typically, the distribution will match the LLVM used by Rust
|
||||
and Clang.
|
||||
|
||||
Another way is using the prebuilt stable versions of LLVM+Rust provided on
|
||||
`kernel.org <https://kernel.org/pub/tools/llvm/rust/>`_. These are the same slim
|
||||
and fast LLVM toolchains from :ref:`Getting LLVM <getting_llvm>` with versions
|
||||
of Rust added to them that Rust for Linux supports. Two sets are provided: the
|
||||
"latest LLVM" and "matching LLVM" (please see the link for more information).
|
||||
|
||||
Alternatively, the next two "Requirements" sections explain each component and
|
||||
how to install them through ``rustup``, the standalone installers from Rust
|
||||
and/or building them.
|
||||
|
||||
The rest of the document explains other aspects on how to get started.
|
||||
|
||||
|
||||
Distributions
|
||||
-------------
|
||||
|
||||
Arch Linux
|
||||
**********
|
||||
|
||||
Arch Linux provides recent Rust releases and thus it should generally work out
|
||||
of the box, e.g.::
|
||||
|
||||
pacman -S rust rust-src rust-bindgen
|
||||
|
||||
|
||||
Debian
|
||||
******
|
||||
|
||||
Debian Unstable (Sid), outside of the freeze period, provides recent Rust
|
||||
releases and thus it should generally work out of the box, e.g.::
|
||||
|
||||
apt install rustc rust-src bindgen rustfmt rust-clippy
|
||||
|
||||
|
||||
Fedora Linux
|
||||
************
|
||||
|
||||
Fedora Linux provides recent Rust releases and thus it should generally work out
|
||||
of the box, e.g.::
|
||||
|
||||
dnf install rust rust-src bindgen-cli rustfmt clippy
|
||||
|
||||
|
||||
Gentoo Linux
|
||||
************
|
||||
|
||||
Gentoo Linux (and especially the testing branch) provides recent Rust releases
|
||||
and thus it should generally work out of the box, e.g.::
|
||||
|
||||
USE='rust-src rustfmt clippy' emerge dev-lang/rust dev-util/bindgen
|
||||
|
||||
``LIBCLANG_PATH`` may need to be set.
|
||||
|
||||
|
||||
Nix
|
||||
***
|
||||
|
||||
Nix (unstable channel) provides recent Rust releases and thus it should
|
||||
generally work out of the box, e.g.::
|
||||
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
pkgs.mkShell {
|
||||
nativeBuildInputs = with pkgs; [ rustc rust-bindgen rustfmt clippy ];
|
||||
RUST_LIB_SRC = "${pkgs.rust.packages.stable.rustPlatform.rustLibSrc}";
|
||||
}
|
||||
|
||||
|
||||
openSUSE
|
||||
********
|
||||
|
||||
openSUSE Slowroll and openSUSE Tumbleweed provide recent Rust releases and thus
|
||||
they should generally work out of the box, e.g.::
|
||||
|
||||
zypper install rust rust1.79-src rust-bindgen clang
|
||||
|
||||
|
||||
Requirements: Building
|
||||
----------------------
|
||||
|
||||
This section explains how to fetch the tools needed for building.
|
||||
|
||||
Some of these requirements might be available from Linux distributions
|
||||
under names like ``rustc``, ``rust-src``, ``rust-bindgen``, etc. However,
|
||||
at the time of writing, they are likely not to be recent enough unless
|
||||
the distribution tracks the latest releases.
|
||||
|
||||
To easily check whether the requirements are met, the following target
|
||||
can be used::
|
||||
|
||||
@ -29,16 +105,15 @@ if that is the case.
|
||||
rustc
|
||||
*****
|
||||
|
||||
A particular version of the Rust compiler is required. Newer versions may or
|
||||
may not work because, for the moment, the kernel depends on some unstable
|
||||
Rust features.
|
||||
A recent version of the Rust compiler is required.
|
||||
|
||||
If ``rustup`` is being used, enter the kernel build directory (or use
|
||||
``--path=<build-dir>`` argument to the ``set`` sub-command) and run::
|
||||
``--path=<build-dir>`` argument to the ``set`` sub-command) and run,
|
||||
for instance::
|
||||
|
||||
rustup override set $(scripts/min-tool-version.sh rustc)
|
||||
rustup override set stable
|
||||
|
||||
This will configure your working directory to use the correct version of
|
||||
This will configure your working directory to use the given version of
|
||||
``rustc`` without affecting your default toolchain.
|
||||
|
||||
Note that the override applies to the current working directory (and its
|
||||
@ -65,9 +140,9 @@ version later on requires re-adding the component.
|
||||
Otherwise, if a standalone installer is used, the Rust source tree may be
|
||||
downloaded into the toolchain's installation folder::
|
||||
|
||||
curl -L "https://static.rust-lang.org/dist/rust-src-$(scripts/min-tool-version.sh rustc).tar.gz" |
|
||||
curl -L "https://static.rust-lang.org/dist/rust-src-$(rustc --version | cut -d' ' -f2).tar.gz" |
|
||||
tar -xzf - -C "$(rustc --print sysroot)/lib" \
|
||||
"rust-src-$(scripts/min-tool-version.sh rustc)/rust-src/lib/" \
|
||||
"rust-src-$(rustc --version | cut -d' ' -f2)/rust-src/lib/" \
|
||||
--strip-components=3
|
||||
|
||||
In this case, upgrading the Rust compiler version later on requires manually
|
||||
@ -101,26 +176,22 @@ bindgen
|
||||
*******
|
||||
|
||||
The bindings to the C side of the kernel are generated at build time using
|
||||
the ``bindgen`` tool. A particular version is required.
|
||||
the ``bindgen`` tool.
|
||||
|
||||
Install it via (note that this will download and build the tool from source)::
|
||||
Install it, for instance, via (note that this will download and build the tool
|
||||
from source)::
|
||||
|
||||
cargo install --locked --version $(scripts/min-tool-version.sh bindgen) bindgen-cli
|
||||
cargo install --locked bindgen-cli
|
||||
|
||||
``bindgen`` needs to find a suitable ``libclang`` in order to work. If it is
|
||||
not found (or a different ``libclang`` than the one found should be used),
|
||||
the process can be tweaked using the environment variables understood by
|
||||
``clang-sys`` (the Rust bindings crate that ``bindgen`` uses to access
|
||||
``libclang``):
|
||||
``bindgen`` uses the ``clang-sys`` crate to find a suitable ``libclang`` (which
|
||||
may be linked statically, dynamically or loaded at runtime). By default, the
|
||||
``cargo`` command above will produce a ``bindgen`` binary that will load
|
||||
``libclang`` at runtime. If it is not found (or a different ``libclang`` than
|
||||
the one found should be used), the process can be tweaked, e.g. by using the
|
||||
``LIBCLANG_PATH`` environment variable. For details, please see ``clang-sys``'s
|
||||
documentation at:
|
||||
|
||||
* ``LLVM_CONFIG_PATH`` can be pointed to an ``llvm-config`` executable.
|
||||
|
||||
* Or ``LIBCLANG_PATH`` can be pointed to a ``libclang`` shared library
|
||||
or to the directory containing it.
|
||||
|
||||
* Or ``CLANG_PATH`` can be pointed to a ``clang`` executable.
|
||||
|
||||
For details, please see ``clang-sys``'s documentation at:
|
||||
https://github.com/KyleMayes/clang-sys#linking
|
||||
|
||||
https://github.com/KyleMayes/clang-sys#environment-variables
|
||||
|
||||
@ -164,20 +235,6 @@ can be installed manually::
|
||||
The standalone installers also come with ``clippy``.
|
||||
|
||||
|
||||
cargo
|
||||
*****
|
||||
|
||||
``cargo`` is the Rust native build system. It is currently required to run
|
||||
the tests since it is used to build a custom standard library that contains
|
||||
the facilities provided by the custom ``alloc`` in the kernel. The tests can
|
||||
be run using the ``rusttest`` Make target.
|
||||
|
||||
If ``rustup`` is being used, all the profiles already install the tool,
|
||||
thus nothing needs to be done.
|
||||
|
||||
The standalone installers also come with ``cargo``.
|
||||
|
||||
|
||||
rustdoc
|
||||
*******
|
||||
|
||||
|
||||
@ -131,9 +131,8 @@ Additionally, there are the ``#[test]`` tests. These can be run using the
|
||||
|
||||
make LLVM=1 rusttest
|
||||
|
||||
This requires the kernel ``.config`` and downloads external repositories. It
|
||||
runs the ``#[test]`` tests on the host (currently) and thus is fairly limited in
|
||||
what these tests can test.
|
||||
This requires the kernel ``.config``. It runs the ``#[test]`` tests on the host
|
||||
(currently) and thus is fairly limited in what these tests can test.
|
||||
|
||||
The Kselftests
|
||||
--------------
|
||||
|
||||
@ -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.
|
||||
|
||||
19
MAINTAINERS
19
MAINTAINERS
@ -2196,7 +2196,7 @@ N: digicolor
|
||||
ARM/CORESIGHT FRAMEWORK AND DRIVERS
|
||||
M: Suzuki K Poulose <suzuki.poulose@arm.com>
|
||||
R: Mike Leach <mike.leach@linaro.org>
|
||||
R: James Clark <james.clark@arm.com>
|
||||
R: James Clark <james.clark@linaro.org>
|
||||
L: coresight@lists.linaro.org (moderated for non-subscribers)
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
@ -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
|
||||
@ -5613,6 +5613,7 @@ M: Ira Weiny <ira.weiny@intel.com>
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
L: linux-cxl@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/driver-api/cxl
|
||||
F: drivers/cxl/
|
||||
F: include/linux/einj-cxl.h
|
||||
F: include/linux/cxl-event.h
|
||||
@ -10655,6 +10656,7 @@ F: Documentation/ABI/testing/sysfs-bus-i3c
|
||||
F: Documentation/devicetree/bindings/i3c/
|
||||
F: Documentation/driver-api/i3c
|
||||
F: drivers/i3c/
|
||||
F: include/dt-bindings/i3c/
|
||||
F: include/linux/i3c/
|
||||
|
||||
IBM Operation Panel Input Driver
|
||||
@ -13322,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
|
||||
@ -13537,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
|
||||
@ -15934,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
|
||||
@ -17894,7 +17899,7 @@ F: tools/perf/
|
||||
PERFORMANCE EVENTS TOOLING ARM64
|
||||
R: John Garry <john.g.garry@oracle.com>
|
||||
R: Will Deacon <will@kernel.org>
|
||||
R: James Clark <james.clark@arm.com>
|
||||
R: James Clark <james.clark@linaro.org>
|
||||
R: Mike Leach <mike.leach@linaro.org>
|
||||
R: Leo Yan <leo.yan@linux.dev>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
@ -18554,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
|
||||
|
||||
34
Makefile
34
Makefile
@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
VERSION = 6
|
||||
PATCHLEVEL = 10
|
||||
PATCHLEVEL = 11
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION =
|
||||
EXTRAVERSION = -rc4
|
||||
NAME = Baby Opossum Posse
|
||||
|
||||
# *DOCUMENTATION*
|
||||
@ -445,17 +445,17 @@ KBUILD_USERLDFLAGS := $(USERLDFLAGS)
|
||||
# host programs.
|
||||
export rust_common_flags := --edition=2021 \
|
||||
-Zbinary_dep_depinfo=y \
|
||||
-Dunsafe_op_in_unsafe_fn -Drust_2018_idioms \
|
||||
-Dunreachable_pub -Dnon_ascii_idents \
|
||||
-Dunsafe_op_in_unsafe_fn \
|
||||
-Dnon_ascii_idents \
|
||||
-Wrust_2018_idioms \
|
||||
-Wunreachable_pub \
|
||||
-Wmissing_docs \
|
||||
-Drustdoc::missing_crate_level_docs \
|
||||
-Dclippy::correctness -Dclippy::style \
|
||||
-Dclippy::suspicious -Dclippy::complexity \
|
||||
-Dclippy::perf \
|
||||
-Dclippy::let_unit_value -Dclippy::mut_mut \
|
||||
-Dclippy::needless_bitwise_bool \
|
||||
-Dclippy::needless_continue \
|
||||
-Dclippy::no_mangle_with_rust_abi \
|
||||
-Wrustdoc::missing_crate_level_docs \
|
||||
-Wclippy::all \
|
||||
-Wclippy::mut_mut \
|
||||
-Wclippy::needless_bitwise_bool \
|
||||
-Wclippy::needless_continue \
|
||||
-Wclippy::no_mangle_with_rust_abi \
|
||||
-Wclippy::dbg_macro
|
||||
|
||||
KBUILD_HOSTCFLAGS := $(KBUILD_USERHOSTCFLAGS) $(HOST_LFS_CFLAGS) \
|
||||
@ -493,7 +493,6 @@ RUSTDOC = rustdoc
|
||||
RUSTFMT = rustfmt
|
||||
CLIPPY_DRIVER = clippy-driver
|
||||
BINDGEN = bindgen
|
||||
CARGO = cargo
|
||||
PAHOLE = pahole
|
||||
RESOLVE_BTFIDS = $(objtree)/tools/bpf/resolve_btfids/resolve_btfids
|
||||
LEX = flex
|
||||
@ -559,7 +558,7 @@ KBUILD_RUSTFLAGS := $(rust_common_flags) \
|
||||
-Csymbol-mangling-version=v0 \
|
||||
-Crelocation-model=static \
|
||||
-Zfunction-sections=n \
|
||||
-Dclippy::float_arithmetic
|
||||
-Wclippy::float_arithmetic
|
||||
|
||||
KBUILD_AFLAGS_KERNEL :=
|
||||
KBUILD_CFLAGS_KERNEL :=
|
||||
@ -587,7 +586,7 @@ endif
|
||||
export RUSTC_BOOTSTRAP := 1
|
||||
|
||||
export ARCH SRCARCH CONFIG_SHELL BASH HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE LD CC HOSTPKG_CONFIG
|
||||
export RUSTC RUSTDOC RUSTFMT RUSTC_OR_CLIPPY_QUIET RUSTC_OR_CLIPPY BINDGEN CARGO
|
||||
export RUSTC RUSTDOC RUSTFMT RUSTC_OR_CLIPPY_QUIET RUSTC_OR_CLIPPY BINDGEN
|
||||
export HOSTRUSTC KBUILD_HOSTRUSTFLAGS
|
||||
export CPP AR NM STRIP OBJCOPY OBJDUMP READELF PAHOLE RESOLVE_BTFIDS LEX YACC AWK INSTALLKERNEL
|
||||
export PERL PYTHON3 CHECK CHECKFLAGS MAKE UTS_MACHINE HOSTCXX
|
||||
@ -1959,9 +1958,12 @@ quiet_cmd_tags = GEN $@
|
||||
tags TAGS cscope gtags: FORCE
|
||||
$(call cmd,tags)
|
||||
|
||||
# IDE support targets
|
||||
# Generate rust-project.json (a file that describes the structure of non-Cargo
|
||||
# Rust projects) for rust-analyzer (an implementation of the Language Server
|
||||
# Protocol).
|
||||
PHONY += rust-analyzer
|
||||
rust-analyzer:
|
||||
+$(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 @@
|
||||
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);
|
||||
|
||||
@ -168,9 +168,9 @@ config ARM64
|
||||
select HAVE_ARCH_JUMP_LABEL
|
||||
select HAVE_ARCH_JUMP_LABEL_RELATIVE
|
||||
select HAVE_ARCH_KASAN
|
||||
select HAVE_ARCH_KASAN_VMALLOC if HAVE_ARCH_KASAN
|
||||
select HAVE_ARCH_KASAN_SW_TAGS if HAVE_ARCH_KASAN
|
||||
select HAVE_ARCH_KASAN_HW_TAGS if (HAVE_ARCH_KASAN && ARM64_MTE)
|
||||
select HAVE_ARCH_KASAN_VMALLOC
|
||||
select HAVE_ARCH_KASAN_SW_TAGS
|
||||
select HAVE_ARCH_KASAN_HW_TAGS if ARM64_MTE
|
||||
# Some instrumentation may be unsound, hence EXPERT
|
||||
select HAVE_ARCH_KCSAN if EXPERT
|
||||
select HAVE_ARCH_KFENCE
|
||||
@ -211,8 +211,8 @@ config ARM64
|
||||
select HAVE_FTRACE_MCOUNT_RECORD
|
||||
select HAVE_FUNCTION_TRACER
|
||||
select HAVE_FUNCTION_ERROR_INJECTION
|
||||
select HAVE_FUNCTION_GRAPH_RETVAL if HAVE_FUNCTION_GRAPH_TRACER
|
||||
select HAVE_FUNCTION_GRAPH_TRACER
|
||||
select HAVE_FUNCTION_GRAPH_RETVAL
|
||||
select HAVE_GCC_PLUGINS
|
||||
select HAVE_HARDLOCKUP_DETECTOR_PERF if PERF_EVENTS && \
|
||||
HW_PERF_EVENTS && HAVE_PERF_EVENTS_NMI
|
||||
@ -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.
|
||||
|
||||
@ -1471,7 +1481,6 @@ config HOTPLUG_CPU
|
||||
config NUMA
|
||||
bool "NUMA Memory Allocation and Scheduler Support"
|
||||
select GENERIC_ARCH_NUMA
|
||||
select ACPI_NUMA if ACPI
|
||||
select OF_NUMA
|
||||
select HAVE_SETUP_PER_CPU_AREA
|
||||
select NEED_PER_CPU_EMBED_FIRST_CHUNK
|
||||
@ -2337,6 +2346,17 @@ config EFI
|
||||
allow the kernel to be booted as an EFI application. This
|
||||
is only useful on systems that have UEFI firmware.
|
||||
|
||||
config COMPRESSED_INSTALL
|
||||
bool "Install compressed image by default"
|
||||
help
|
||||
This makes the regular "make install" install the compressed
|
||||
image we built, not the legacy uncompressed one.
|
||||
|
||||
You can check that a compressed image works for you by doing
|
||||
"make zinstall" first, and verifying that everything is fine
|
||||
in your environment before making "make install" do this for
|
||||
you.
|
||||
|
||||
config DMI
|
||||
bool "Enable support for SMBIOS (DMI) tables"
|
||||
depends on EFI
|
||||
|
||||
@ -182,7 +182,13 @@ $(BOOT_TARGETS): vmlinux
|
||||
Image.%: Image
|
||||
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
|
||||
|
||||
install: KBUILD_IMAGE := $(boot)/Image
|
||||
ifeq ($(CONFIG_COMPRESSED_INSTALL),y)
|
||||
DEFAULT_KBUILD_IMAGE = $(KBUILD_IMAGE)
|
||||
else
|
||||
DEFAULT_KBUILD_IMAGE = $(boot)/Image
|
||||
endif
|
||||
|
||||
install: KBUILD_IMAGE := $(DEFAULT_KBUILD_IMAGE)
|
||||
install zinstall:
|
||||
$(call cmd,install)
|
||||
|
||||
@ -229,7 +235,7 @@ define archhelp
|
||||
echo '* Image.gz - Compressed kernel image (arch/$(ARCH)/boot/Image.gz)'
|
||||
echo ' Image - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
|
||||
echo ' image.fit - Flat Image Tree (arch/$(ARCH)/boot/image.fit)'
|
||||
echo ' install - Install uncompressed kernel'
|
||||
echo ' install - Install kernel (compressed if COMPRESSED_INSTALL set)'
|
||||
echo ' zinstall - Install compressed kernel'
|
||||
echo ' Install using (your) ~/bin/installkernel or'
|
||||
echo ' (distribution) /sbin/installkernel or'
|
||||
|
||||
@ -43,15 +43,6 @@
|
||||
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 @@
|
||||
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 @@
|
||||
};
|
||||
|
||||
&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 @@
|
||||
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 @@
|
||||
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 @@
|
||||
&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 @@
|
||||
&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 @@
|
||||
&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 @@
|
||||
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 @@
|
||||
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 @@
|
||||
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); \
|
||||
|
||||
@ -1065,6 +1065,28 @@ static inline bool pgtable_l5_enabled(void) { return false; }
|
||||
|
||||
#define p4d_offset_kimg(dir,addr) ((p4d_t *)dir)
|
||||
|
||||
static inline
|
||||
p4d_t *p4d_offset_lockless_folded(pgd_t *pgdp, pgd_t pgd, unsigned long addr)
|
||||
{
|
||||
/*
|
||||
* With runtime folding of the pud, pud_offset_lockless() passes
|
||||
* the 'pgd_t *' we return here to p4d_to_folded_pud(), which
|
||||
* will offset the pointer assuming that it points into
|
||||
* a page-table page. However, the fast GUP path passes us a
|
||||
* pgd_t allocated on the stack and so we must use the original
|
||||
* pointer in 'pgdp' to construct the p4d pointer instead of
|
||||
* using the generic p4d_offset_lockless() implementation.
|
||||
*
|
||||
* Note: reusing the original pointer means that we may
|
||||
* dereference the same (live) page-table entry multiple times.
|
||||
* This is safe because it is still only loaded once in the
|
||||
* context of each level and the CPU guarantees same-address
|
||||
* read-after-read ordering.
|
||||
*/
|
||||
return p4d_offset(pgdp, addr);
|
||||
}
|
||||
#define p4d_offset_lockless p4d_offset_lockless_folded
|
||||
|
||||
#endif /* CONFIG_PGTABLE_LEVELS > 4 */
|
||||
|
||||
#define pgd_ERROR(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