mirror of
https://github.com/torvalds/linux.git
synced 2024-09-20 06:53:04 +00:00
hwmon fixes for v6.11-rc7
hp-wmi-sensors: Check if WMI event data exists before accessing it
ltc2991: fix register bits defines
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEiHPvMQj9QTOCiqgVyx8mb86fmYEFAmbYrGEACgkQyx8mb86f
mYERyw//V+MQSPf+wmRcM7gU0+u+Ylbl98wbyaO6+YyTiq2XQJgbrk2AnNJFxqu9
tkv2Xb3xFu1EB1V6Xz5kADzaP6Wp9W+4TK+PrlN0GCa6FZZwbGZBuhIkLS1492ex
Zf8oRUNNiRnIAHb+5+E0aonDbsHSWe7Ff5WVTRfKBn8rrQW8pchPx4h/Y+o54Llo
BEOQTA0rN51eg0RL7e9ECFUmBLRNuZA6E1w25F15VA50O4Xx2i6lL7PwPDb7KKpa
g6fy2JTtr7+hKOiJMR4KdodsOZHvW4RgZ0MvWQkOZsccHw8CLp8c4egIxPYQ41Zu
Ef4imKHPDVsiSXHW6rjQro0IQWBvRu1/6R1ibbDlXTWN5dkxGaByb0tlrRo3QBQn
CvoHqkQkhioaX2k1I7bBDbyz6AregHLBJ7kpLq4ClcfW4QmxJ9zPPSDekyIyQiTZ
vU/OljM/Je6CIbzspcaKS8uhNdykw3FX/LWLVwUEFJawJHV8b7XD+S3aJq7zQqEl
R0hIeDyWiakP2ca7gozey1RjxpFDNQhCeZUqEaTlLhHlDykvZAceEXNuoczrpKNq
UaBincY64PVBmzLPpjpDVg7C7C023xoqrWKSSd9kFsl9KzbKTH0XzkVPtD9cjQC5
d34++QqhffAtJuekIbrWmtfhZsvkgQrfRv1MowNsbce0Lz7dRGE=
=sSGh
-----END PGP SIGNATURE-----
Merge tag 'hwmon-for-v6.11-rc7' into review-hans
Merge "hwmon fixes for v6.11-rc7" into review-hans to bring in
commit a54da9df75 ("hwmon: (hp-wmi-sensors) Check if WMI event
data exists").
This is a dependency for a set of WMI event data refactoring changes.
This commit is contained in:
Hans de Goede
commit
56d8b784c5
4
.mailmap
4
.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>
|
||||
|
|
@ -353,6 +354,8 @@ Kenneth Westfield <quic_kwestfie@quicinc.com> <kwestfie@codeaurora.org>
|
|||
Kiran Gunda <quic_kgunda@quicinc.com> <kgunda@codeaurora.org>
|
||||
Kirill Tkhai <tkhai@ya.ru> <ktkhai@virtuozzo.com>
|
||||
Kishon Vijay Abraham I <kishon@kernel.org> <kishon@ti.com>
|
||||
Konrad Dybcio <konradybcio@kernel.org> <konrad.dybcio@linaro.org>
|
||||
Konrad Dybcio <konradybcio@kernel.org> <konrad.dybcio@somainline.org>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <khlebnikov@yandex-team.ru>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
|
||||
Koushik <raghavendra.koushik@neterion.com>
|
||||
|
|
@ -613,6 +616,7 @@ Simon Kelley <simon@thekelleys.org.uk>
|
|||
Sricharan Ramabadhran <quic_srichara@quicinc.com> <sricharan@codeaurora.org>
|
||||
Srinivas Ramana <quic_sramana@quicinc.com> <sramana@codeaurora.org>
|
||||
Sriram R <quic_srirrama@quicinc.com> <srirrama@codeaurora.org>
|
||||
Sriram Yagnaraman <sriram.yagnaraman@ericsson.com> <sriram.yagnaraman@est.tech>
|
||||
Stanislav Fomichev <sdf@fomichev.me> <sdf@google.com>
|
||||
Stefan Wahren <wahrenst@gmx.net> <stefan.wahren@i2se.com>
|
||||
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
|
||||
|
|
|
|||
|
|
@ -32,9 +32,9 @@ Description: (RW) The front button on the Turris Omnia router can be
|
|||
interrupt.
|
||||
|
||||
This file switches between these two modes:
|
||||
- "mcu" makes the button press event be handled by the MCU to
|
||||
change the LEDs panel intensity.
|
||||
- "cpu" makes the button press event be handled by the CPU.
|
||||
- ``mcu`` makes the button press event be handled by the MCU to
|
||||
change the LEDs panel intensity.
|
||||
- ``cpu`` makes the button press event be handled by the CPU.
|
||||
|
||||
Format: %s.
|
||||
|
||||
|
|
|
|||
|
|
@ -562,7 +562,8 @@ Description: Control Symmetric Multi Threading (SMT)
|
|||
================ =========================================
|
||||
|
||||
If control status is "forceoff" or "notsupported" writes
|
||||
are rejected.
|
||||
are rejected. Note that enabling SMT on PowerPC skips
|
||||
offline cores.
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/power/energy_perf_bias
|
||||
Date: March 2019
|
||||
|
|
|
|||
|
|
@ -742,7 +742,7 @@ SecurityFlags Flags which control security negotiation and
|
|||
may use NTLMSSP 0x00080
|
||||
must use NTLMSSP 0x80080
|
||||
seal (packet encryption) 0x00040
|
||||
must seal (not implemented yet) 0x40040
|
||||
must seal 0x40040
|
||||
|
||||
cifsFYI If set to non-zero value, additional debug information
|
||||
will be logged to the system error log. This field
|
||||
|
|
|
|||
|
|
@ -162,13 +162,14 @@ iv_large_sectors
|
|||
|
||||
|
||||
Module parameters::
|
||||
max_read_size
|
||||
max_write_size
|
||||
Maximum size of read or write requests. When a request larger than this size
|
||||
is received, dm-crypt will split the request. The splitting improves
|
||||
concurrency (the split requests could be encrypted in parallel by multiple
|
||||
cores), but it also causes overhead. The user should tune these parameters to
|
||||
fit the actual workload.
|
||||
|
||||
max_read_size
|
||||
max_write_size
|
||||
Maximum size of read or write requests. When a request larger than this size
|
||||
is received, dm-crypt will split the request. The splitting improves
|
||||
concurrency (the split requests could be encrypted in parallel by multiple
|
||||
cores), but it also causes overhead. The user should tune these parameters to
|
||||
fit the actual workload.
|
||||
|
||||
|
||||
Example scripts
|
||||
|
|
|
|||
|
|
@ -4798,11 +4798,9 @@
|
|||
|
||||
profile= [KNL] Enable kernel profiling via /proc/profile
|
||||
Format: [<profiletype>,]<number>
|
||||
Param: <profiletype>: "schedule", "sleep", or "kvm"
|
||||
Param: <profiletype>: "schedule" or "kvm"
|
||||
[defaults to kernel profiling]
|
||||
Param: "schedule" - profile schedule points.
|
||||
Param: "sleep" - profile D-state sleeping (millisecs).
|
||||
Requires CONFIG_SCHEDSTATS
|
||||
Param: "kvm" - profile VM exits.
|
||||
Param: <number> - step/bucket size as a power of 2 for
|
||||
statistical time based profiling.
|
||||
|
|
|
|||
|
|
@ -122,10 +122,18 @@ stable kernels.
|
|||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A76 | #1490853 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A76 | #3324349 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A77 | #1491015 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A77 | #3324348 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A78 | #3324344 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A78C | #3324346,3324347| ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |
|
||||
|
|
@ -138,8 +146,14 @@ stable kernels.
|
|||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A720 | #3456091 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A725 | #3456106 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X1 | #1502854 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X1 | #3324344 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X1C | #3324346 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 |
|
||||
|
|
@ -160,6 +174,8 @@ stable kernels.
|
|||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N1 | #3324349 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N2 | #2139208 | ARM64_ERRATUM_2139208 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N2 | #2067961 | ARM64_ERRATUM_2067961 |
|
||||
|
|
@ -170,6 +186,8 @@ stable kernels.
|
|||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V1 | #1619801 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V1 | #3324341 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V2 | #3324336 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3194386 |
|
||||
|
|
|
|||
|
|
@ -239,25 +239,33 @@ The following keys are defined:
|
|||
ratified in commit 98918c844281 ("Merge pull request #1217 from
|
||||
riscv/zawrs") of riscv-isa-manual.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
|
||||
information about the selected set of processors.
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: Deprecated. Returns similar values to
|
||||
:c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`, but the key was
|
||||
mistakenly classified as a bitmask rather than a value.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_UNKNOWN`: The performance of misaligned
|
||||
accesses is unknown.
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`: An enum value describing
|
||||
the performance of misaligned scalar native word accesses on the selected set
|
||||
of processors.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_EMULATED`: Misaligned accesses are
|
||||
emulated via software, either in or below the kernel. These accesses are
|
||||
always extremely slow.
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_UNKNOWN`: The performance of
|
||||
misaligned scalar accesses is unknown.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_SLOW`: Misaligned accesses are slower
|
||||
than equivalent byte accesses. Misaligned accesses may be supported
|
||||
directly in hardware, or trapped and emulated by software.
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_EMULATED`: Misaligned scalar
|
||||
accesses are emulated via software, either in or below the kernel. These
|
||||
accesses are always extremely slow.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_FAST`: Misaligned accesses are faster
|
||||
than equivalent byte accesses.
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_SLOW`: Misaligned scalar native
|
||||
word sized accesses are slower than the equivalent quantity of byte
|
||||
accesses. Misaligned accesses may be supported directly in hardware, or
|
||||
trapped and emulated by software.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_UNSUPPORTED`: Misaligned accesses are
|
||||
not supported at all and will generate a misaligned address fault.
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_FAST`: Misaligned scalar native
|
||||
word sized accesses are faster than the equivalent quantity of byte
|
||||
accesses.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_UNSUPPORTED`: Misaligned scalar
|
||||
accesses are not supported at all and will generate a misaligned address
|
||||
fault.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`: An unsigned int which
|
||||
represents the size of the Zicboz block in bytes.
|
||||
|
|
|
|||
|
|
@ -260,7 +260,7 @@ Some users depend on strict execution ordering where only one work item
|
|||
is in flight at any given time and the work items are processed in
|
||||
queueing order. While the combination of ``@max_active`` of 1 and
|
||||
``WQ_UNBOUND`` used to achieve this behavior, this is no longer the
|
||||
case. Use ``alloc_ordered_queue()`` instead.
|
||||
case. Use alloc_ordered_workqueue() instead.
|
||||
|
||||
|
||||
Example Execution Scenarios
|
||||
|
|
|
|||
|
|
@ -35,6 +35,9 @@ properties:
|
|||
ports-implemented:
|
||||
const: 1
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
sata-port@0:
|
||||
$ref: /schemas/ata/snps,dwc-ahci-common.yaml#/$defs/dwc-ahci-port
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Qualcomm Display Clock & Reset Controller on SM6350
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm display clock control module provides the clocks, resets and power
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Qualcomm Global Clock & Reset Controller on MSM8994
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module provides the clocks, resets and power
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Qualcomm Global Clock & Reset Controller on SM6125
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module provides the clocks, resets and power
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Qualcomm Global Clock & Reset Controller on SM6350
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module provides the clocks, resets and power
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Qualcomm Graphics Clock & Reset Controller on SM6115
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm graphics clock control module provides clocks, resets and power
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Qualcomm Graphics Clock & Reset Controller on SM6125
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm graphics clock control module provides clocks and power domains on
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Qualcomm Camera Clock & Reset Controller on SM6350
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm camera clock control module provides the clocks, resets and power
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Qualcomm Display Clock & Reset Controller on SM6375
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm display clock control module provides the clocks, resets and power
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Qualcomm Global Clock & Reset Controller on SM6375
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module provides the clocks, resets and power
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Qualcomm Graphics Clock & Reset Controller on SM6375
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm graphics clock control module provides clocks, resets and power
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Qualcomm SM8350 Video Clock & Reset Controller
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm video clock control module provides the clocks, resets and power
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Qualcomm Graphics Clock & Reset Controller on SM8450
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
Qualcomm graphics clock control module provides the clocks, resets and power
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Qualcomm SM6375 Display MDSS
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description:
|
||||
SM6375 MSM Mobile Display Subsystem (MDSS), which encapsulates sub-blocks
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: ASUS Z00T TM5P5 NT35596 5.5" 1080×1920 LCD Panel
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konradybcio@gmail.com>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |+
|
||||
This panel seems to only be found in the Asus Z00T
|
||||
|
|
|
|||
|
|
@ -17,9 +17,12 @@ properties:
|
|||
oneOf:
|
||||
# Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel
|
||||
- const: samsung,atna33xc20
|
||||
# Samsung 14.5" WQXGA+ (2880x1800 pixels) eDP AMOLED panel
|
||||
- items:
|
||||
- const: samsung,atna45af01
|
||||
- enum:
|
||||
# Samsung 14.5" WQXGA+ (2880x1800 pixels) eDP AMOLED panel
|
||||
- samsung,atna45af01
|
||||
# Samsung 14.5" 3K (2944x1840 pixels) eDP AMOLED panel
|
||||
- samsung,atna45dc02
|
||||
- const: samsung,atna33xc20
|
||||
|
||||
enable-gpios: true
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Sony TD4353 JDI 5 / 5.7" 2160x1080 MIPI-DSI Panel
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
The Sony TD4353 JDI is a 5 (XZ2c) / 5.7 (XZ2) inch 2160x1080
|
||||
|
|
|
|||
|
|
@ -28,6 +28,7 @@ properties:
|
|||
- anvo,anv32e61w
|
||||
- atmel,at25256B
|
||||
- fujitsu,mb85rs1mt
|
||||
- fujitsu,mb85rs256
|
||||
- fujitsu,mb85rs64
|
||||
- microchip,at25160bn
|
||||
- microchip,25lc040
|
||||
|
|
|
|||
|
|
@ -42,6 +42,7 @@ properties:
|
|||
- focaltech,ft5426
|
||||
- focaltech,ft5452
|
||||
- focaltech,ft6236
|
||||
- focaltech,ft8201
|
||||
- focaltech,ft8719
|
||||
|
||||
reg:
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ maintainers:
|
|||
- Fabio Estevam <festevam@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: usb-hcd.yaml#
|
||||
- $ref: usb-device.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
@ -18,6 +18,7 @@ properties:
|
|||
- usb424,2412
|
||||
- usb424,2417
|
||||
- usb424,2514
|
||||
- usb424,2517
|
||||
|
||||
reg: true
|
||||
|
||||
|
|
@ -35,6 +36,13 @@ required:
|
|||
- compatible
|
||||
- reg
|
||||
|
||||
patternProperties:
|
||||
"^.*@[0-9a-f]{1,2}$":
|
||||
description: The hard wired USB devices
|
||||
type: object
|
||||
$ref: /schemas/usb/usb-device.yaml
|
||||
additionalProperties: true
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ Ccache
|
|||
|
||||
``ccache`` can be used with ``clang`` to improve subsequent builds, (though
|
||||
KBUILD_BUILD_TIMESTAMP_ should be set to a deterministic value between builds
|
||||
in order to avoid 100% cache misses, see Reproducible_builds_ for more info):
|
||||
in order to avoid 100% cache misses, see Reproducible_builds_ for more info)::
|
||||
|
||||
KBUILD_BUILD_TIMESTAMP='' make LLVM=1 CC="ccache clang"
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -629,18 +629,6 @@ The preferred style for long (multi-line) comments is:
|
|||
* with beginning and ending almost-blank lines.
|
||||
*/
|
||||
|
||||
For files in net/ and drivers/net/ the preferred style for long (multi-line)
|
||||
comments is a little different.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
/* The preferred comment style for files in net/ and drivers/net
|
||||
* looks like this.
|
||||
*
|
||||
* It is nearly the same as the generally preferred comment style,
|
||||
* but there is no initial almost-blank line.
|
||||
*/
|
||||
|
||||
It's also important to comment data, whether they are basic types or derived
|
||||
types. To this end, use just one data declaration per line (no commas for
|
||||
multiple data declarations). This leaves you room for a small comment on each
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -355,23 +355,6 @@ just do it. As a result, a sequence of smaller series gets merged quicker and
|
|||
with better review coverage. Re-posting large series also increases the mailing
|
||||
list traffic.
|
||||
|
||||
Multi-line comments
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Comment style convention is slightly different for networking and most of
|
||||
the tree. Instead of this::
|
||||
|
||||
/*
|
||||
* foobar blah blah blah
|
||||
* another line of text
|
||||
*/
|
||||
|
||||
it is requested that you make it look like this::
|
||||
|
||||
/* foobar blah blah blah
|
||||
* another line of text
|
||||
*/
|
||||
|
||||
Local variable ordering ("reverse xmas tree", "RCS")
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
70
MAINTAINERS
70
MAINTAINERS
|
|
@ -1880,6 +1880,10 @@ F: Documentation/devicetree/bindings/iommu/arm,smmu*
|
|||
F: drivers/iommu/arm/
|
||||
F: drivers/iommu/io-pgtable-arm*
|
||||
|
||||
ARM SMMU SVA SUPPORT
|
||||
R: Jean-Philippe Brucker <jean-philippe@linaro.org>
|
||||
F: drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
|
||||
|
||||
ARM SUB-ARCHITECTURES
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
|
|
@ -2535,8 +2539,7 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
|||
S: Supported
|
||||
W: http://www.linux4sam.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git
|
||||
F: arch/arm/boot/dts/microchip/at91*
|
||||
F: arch/arm/boot/dts/microchip/sama*
|
||||
F: arch/arm/boot/dts/microchip/
|
||||
F: arch/arm/include/debug/at91.S
|
||||
F: arch/arm/mach-at91/
|
||||
F: drivers/memory/atmel*
|
||||
|
|
@ -2745,7 +2748,7 @@ F: include/linux/soc/qcom/
|
|||
|
||||
ARM/QUALCOMM SUPPORT
|
||||
M: Bjorn Andersson <andersson@kernel.org>
|
||||
M: Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
M: Konrad Dybcio <konradybcio@kernel.org>
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git
|
||||
|
|
@ -3504,7 +3507,9 @@ S: Maintained
|
|||
W: http://linux-atm.sourceforge.net
|
||||
F: drivers/atm/
|
||||
F: include/linux/atm*
|
||||
F: include/linux/sonet.h
|
||||
F: include/uapi/linux/atm*
|
||||
F: include/uapi/linux/sonet.h
|
||||
|
||||
ATMEL MACB ETHERNET DRIVER
|
||||
M: Nicolas Ferre <nicolas.ferre@microchip.com>
|
||||
|
|
@ -5306,7 +5311,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 +5380,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
|
||||
|
|
@ -7106,7 +7111,7 @@ F: drivers/gpu/drm/tiny/panel-mipi-dbi.c
|
|||
DRM DRIVER for Qualcomm Adreno GPUs
|
||||
M: Rob Clark <robdclark@gmail.com>
|
||||
R: Sean Paul <sean@poorly.run>
|
||||
R: Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
R: Konrad Dybcio <konradybcio@kernel.org>
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
L: freedreno@lists.freedesktop.org
|
||||
|
|
@ -10173,7 +10178,7 @@ F: Documentation/devicetree/bindings/infiniband/hisilicon-hns-roce.txt
|
|||
F: drivers/infiniband/hw/hns/
|
||||
|
||||
HISILICON SAS Controller
|
||||
M: Xiang Chen <chenxiang66@hisilicon.com>
|
||||
M: Yihang Li <liyihang9@huawei.com>
|
||||
S: Supported
|
||||
W: http://www.hisilicon.com
|
||||
F: Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
|
||||
|
|
@ -11994,7 +11999,7 @@ F: fs/jfs/
|
|||
JME NETWORK DRIVER
|
||||
M: Guo-Fu Tseng <cooldavid@cooldavid.org>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
S: Odd Fixes
|
||||
F: drivers/net/ethernet/jme.*
|
||||
|
||||
JOURNALLING FLASH FILE SYSTEM V2 (JFFS2)
|
||||
|
|
@ -12166,7 +12171,7 @@ KERNEL NFSD, SUNRPC, AND LOCKD SERVERS
|
|||
M: Chuck Lever <chuck.lever@oracle.com>
|
||||
M: Jeff Layton <jlayton@kernel.org>
|
||||
R: Neil Brown <neilb@suse.de>
|
||||
R: Olga Kornievskaia <kolga@netapp.com>
|
||||
R: Olga Kornievskaia <okorniev@redhat.com>
|
||||
R: Dai Ngo <Dai.Ngo@oracle.com>
|
||||
R: Tom Talpey <tom@talpey.com>
|
||||
L: linux-nfs@vger.kernel.org
|
||||
|
|
@ -13325,14 +13330,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
|
||||
|
|
@ -13540,7 +13547,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
|
||||
|
|
@ -15876,15 +15883,19 @@ F: drivers/net/
|
|||
F: include/dt-bindings/net/
|
||||
F: include/linux/cn_proc.h
|
||||
F: include/linux/etherdevice.h
|
||||
F: include/linux/ethtool_netlink.h
|
||||
F: include/linux/fcdevice.h
|
||||
F: include/linux/fddidevice.h
|
||||
F: include/linux/hippidevice.h
|
||||
F: include/linux/if_*
|
||||
F: include/linux/inetdevice.h
|
||||
F: include/linux/netdevice.h
|
||||
F: include/linux/netdev*
|
||||
F: include/linux/platform_data/wiznet.h
|
||||
F: include/uapi/linux/cn_proc.h
|
||||
F: include/uapi/linux/ethtool_netlink.h
|
||||
F: include/uapi/linux/if_*
|
||||
F: include/uapi/linux/netdevice.h
|
||||
F: include/uapi/linux/netdev*
|
||||
F: tools/testing/selftests/drivers/net/
|
||||
X: drivers/net/wireless/
|
||||
|
||||
NETWORKING DRIVERS (WIRELESS)
|
||||
|
|
@ -15935,13 +15946,28 @@ F: include/linux/framer/framer-provider.h
|
|||
F: include/linux/framer/framer.h
|
||||
F: include/linux/in.h
|
||||
F: include/linux/indirect_call_wrapper.h
|
||||
F: include/linux/inet.h
|
||||
F: include/linux/inet_diag.h
|
||||
F: include/linux/net.h
|
||||
F: include/linux/netdevice.h
|
||||
F: include/linux/netdev*
|
||||
F: include/linux/netlink.h
|
||||
F: include/linux/netpoll.h
|
||||
F: include/linux/rtnetlink.h
|
||||
F: include/linux/seq_file_net.h
|
||||
F: include/linux/skbuff*
|
||||
F: include/net/
|
||||
F: include/uapi/linux/genetlink.h
|
||||
F: include/uapi/linux/hsr_netlink.h
|
||||
F: include/uapi/linux/in.h
|
||||
F: include/uapi/linux/inet_diag.h
|
||||
F: include/uapi/linux/nbd-netlink.h
|
||||
F: include/uapi/linux/net.h
|
||||
F: include/uapi/linux/net_namespace.h
|
||||
F: include/uapi/linux/netdevice.h
|
||||
F: include/uapi/linux/netconf.h
|
||||
F: include/uapi/linux/netdev*
|
||||
F: include/uapi/linux/netlink.h
|
||||
F: include/uapi/linux/netlink_diag.h
|
||||
F: include/uapi/linux/rtnetlink.h
|
||||
F: lib/net_utils.c
|
||||
F: lib/random32.c
|
||||
F: net/
|
||||
|
|
@ -17413,6 +17439,7 @@ M: Roy Zang <roy.zang@nxp.com>
|
|||
L: linuxppc-dev@lists.ozlabs.org
|
||||
L: linux-pci@vger.kernel.org
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: imx@lists.linux.dev
|
||||
S: Maintained
|
||||
F: drivers/pci/controller/dwc/*layerscape*
|
||||
|
||||
|
|
@ -17439,6 +17466,7 @@ M: Richard Zhu <hongxing.zhu@nxp.com>
|
|||
M: Lucas Stach <l.stach@pengutronix.de>
|
||||
L: linux-pci@vger.kernel.org
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: imx@lists.linux.dev
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-common.yaml
|
||||
F: Documentation/devicetree/bindings/pci/fsl,imx6q-pcie-ep.yaml
|
||||
|
|
@ -17617,6 +17645,7 @@ F: drivers/pci/controller/pci-xgene-msi.c
|
|||
PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS
|
||||
M: Lorenzo Pieralisi <lpieralisi@kernel.org>
|
||||
M: Krzysztof Wilczyński <kw@linux.com>
|
||||
R: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
|
||||
R: Rob Herring <robh@kernel.org>
|
||||
L: linux-pci@vger.kernel.org
|
||||
S: Supported
|
||||
|
|
@ -18523,7 +18552,6 @@ F: drivers/crypto/intel/qat/
|
|||
|
||||
QCOM AUDIO (ASoC) DRIVERS
|
||||
M: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
||||
M: Banajit Goswami <bgoswami@quicinc.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
S: Supported
|
||||
|
|
@ -18557,7 +18585,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
|
||||
|
|
@ -18772,7 +18800,7 @@ F: include/uapi/drm/qaic_accel.h
|
|||
|
||||
QUALCOMM CORE POWER REDUCTION (CPR) AVS DRIVER
|
||||
M: Bjorn Andersson <andersson@kernel.org>
|
||||
M: Konrad Dybcio <konrad.dybcio@linaro.org>
|
||||
M: Konrad Dybcio <konradybcio@kernel.org>
|
||||
L: linux-pm@vger.kernel.org
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
S: Maintained
|
||||
|
|
@ -20352,6 +20380,7 @@ F: Documentation/devicetree/bindings/scsi/
|
|||
F: drivers/scsi/
|
||||
F: drivers/ufs/
|
||||
F: include/scsi/
|
||||
F: include/uapi/scsi/
|
||||
|
||||
SCSI TAPE DRIVER
|
||||
M: Kai Mäkisara <Kai.Makisara@kolumbus.fi>
|
||||
|
|
@ -21052,6 +21081,7 @@ SOCKET TIMESTAMPING
|
|||
M: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
|
||||
S: Maintained
|
||||
F: Documentation/networking/timestamping.rst
|
||||
F: include/linux/net_tstamp.h
|
||||
F: include/uapi/linux/net_tstamp.h
|
||||
F: tools/testing/selftests/net/so_txtime.c
|
||||
|
||||
|
|
@ -23819,10 +23849,8 @@ F: drivers/media/usb/uvc/
|
|||
F: include/uapi/linux/uvcvideo.h
|
||||
|
||||
USB WEBCAM GADGET
|
||||
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
||||
M: Daniel Scally <dan.scally@ideasonboard.com>
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Maintained
|
||||
S: Orphan
|
||||
F: drivers/usb/gadget/function/*uvc*
|
||||
F: drivers/usb/gadget/legacy/webcam.c
|
||||
F: include/uapi/linux/usb/g_uvc.h
|
||||
|
|
|
|||
6
Makefile
6
Makefile
|
|
@ -2,7 +2,7 @@
|
|||
VERSION = 6
|
||||
PATCHLEVEL = 11
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc1
|
||||
EXTRAVERSION = -rc6
|
||||
NAME = Baby Opossum Posse
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
|
@ -1963,7 +1963,7 @@ tags TAGS cscope gtags: FORCE
|
|||
# Protocol).
|
||||
PHONY += rust-analyzer
|
||||
rust-analyzer:
|
||||
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/rust_is_available.sh
|
||||
+$(Q)$(CONFIG_SHELL) $(srctree)/scripts/rust_is_available.sh
|
||||
$(Q)$(MAKE) $(build)=rust $@
|
||||
|
||||
# Script to generate missing namespace dependencies
|
||||
|
|
@ -1980,7 +1980,7 @@ nsdeps: modules
|
|||
quiet_cmd_gen_compile_commands = GEN $@
|
||||
cmd_gen_compile_commands = $(PYTHON3) $< -a $(AR) -o $@ $(filter-out $<, $(real-prereqs))
|
||||
|
||||
$(extmod_prefix)compile_commands.json: scripts/clang-tools/gen_compile_commands.py \
|
||||
$(extmod_prefix)compile_commands.json: $(srctree)/scripts/clang-tools/gen_compile_commands.py \
|
||||
$(if $(KBUILD_EXTMOD),, vmlinux.a $(KBUILD_VMLINUX_LIBS)) \
|
||||
$(if $(CONFIG_MODULES), $(MODORDER)) FORCE
|
||||
$(call if_changed,gen_compile_commands)
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
|
|
|
|||
|
|
@ -274,24 +274,24 @@
|
|||
|
||||
led@0 {
|
||||
chan-name = "R";
|
||||
led-cur = /bits/ 8 <0x20>;
|
||||
max-cur = /bits/ 8 <0x60>;
|
||||
led-cur = /bits/ 8 <0x6e>;
|
||||
max-cur = /bits/ 8 <0xc8>;
|
||||
reg = <0>;
|
||||
color = <LED_COLOR_ID_RED>;
|
||||
};
|
||||
|
||||
led@1 {
|
||||
chan-name = "G";
|
||||
led-cur = /bits/ 8 <0x20>;
|
||||
max-cur = /bits/ 8 <0x60>;
|
||||
led-cur = /bits/ 8 <0xbe>;
|
||||
max-cur = /bits/ 8 <0xc8>;
|
||||
reg = <1>;
|
||||
color = <LED_COLOR_ID_GREEN>;
|
||||
};
|
||||
|
||||
led@2 {
|
||||
chan-name = "B";
|
||||
led-cur = /bits/ 8 <0x20>;
|
||||
max-cur = /bits/ 8 <0x60>;
|
||||
led-cur = /bits/ 8 <0xbe>;
|
||||
max-cur = /bits/ 8 <0xc8>;
|
||||
reg = <2>;
|
||||
color = <LED_COLOR_ID_BLUE>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -781,7 +781,7 @@
|
|||
|
||||
mount-matrix = "-1", "0", "0",
|
||||
"0", "1", "0",
|
||||
"0", "0", "1";
|
||||
"0", "0", "-1";
|
||||
};
|
||||
|
||||
cam1: camera@3e {
|
||||
|
|
|
|||
|
|
@ -26,6 +26,13 @@ struct stackframe {
|
|||
#endif
|
||||
};
|
||||
|
||||
static inline bool on_thread_stack(void)
|
||||
{
|
||||
unsigned long delta = current_stack_pointer ^ (unsigned long)current->stack;
|
||||
|
||||
return delta < THREAD_SIZE;
|
||||
}
|
||||
|
||||
static __always_inline
|
||||
void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame)
|
||||
{
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@
|
|||
#define PROC_INFO \
|
||||
. = ALIGN(4); \
|
||||
__proc_info_begin = .; \
|
||||
*(.proc.info.init) \
|
||||
KEEP(*(.proc.info.init)) \
|
||||
__proc_info_end = .;
|
||||
|
||||
#define IDMAP_TEXT \
|
||||
|
|
|
|||
|
|
@ -1065,6 +1065,7 @@ vector_addrexcptn:
|
|||
.globl vector_fiq
|
||||
|
||||
.section .vectors, "ax", %progbits
|
||||
.reloc .text, R_ARM_NONE, .
|
||||
W(b) vector_rst
|
||||
W(b) vector_und
|
||||
ARM( .reloc ., R_ARM_LDR_PC_G0, .L__vector_swi )
|
||||
|
|
@ -1078,6 +1079,7 @@ THUMB( .reloc ., R_ARM_THM_PC12, .L__vector_swi )
|
|||
|
||||
#ifdef CONFIG_HARDEN_BRANCH_HISTORY
|
||||
.section .vectors.bhb.loop8, "ax", %progbits
|
||||
.reloc .text, R_ARM_NONE, .
|
||||
W(b) vector_rst
|
||||
W(b) vector_bhb_loop8_und
|
||||
ARM( .reloc ., R_ARM_LDR_PC_G0, .L__vector_bhb_loop8_swi )
|
||||
|
|
@ -1090,6 +1092,7 @@ THUMB( .reloc ., R_ARM_THM_PC12, .L__vector_bhb_loop8_swi )
|
|||
W(b) vector_bhb_loop8_fiq
|
||||
|
||||
.section .vectors.bhb.bpiall, "ax", %progbits
|
||||
.reloc .text, R_ARM_NONE, .
|
||||
W(b) vector_rst
|
||||
W(b) vector_bhb_bpiall_und
|
||||
ARM( .reloc ., R_ARM_LDR_PC_G0, .L__vector_bhb_bpiall_swi )
|
||||
|
|
|
|||
|
|
@ -119,6 +119,9 @@ no_work_pending:
|
|||
|
||||
ct_user_enter save = 0
|
||||
|
||||
#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
|
||||
bl stackleak_erase_on_task_stack
|
||||
#endif
|
||||
restore_user_regs fast = 0, offset = 0
|
||||
ENDPROC(ret_to_user_from_irq)
|
||||
ENDPROC(ret_to_user)
|
||||
|
|
|
|||
|
|
@ -395,11 +395,6 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
|
|||
return 0;
|
||||
}
|
||||
|
||||
struct mod_unwind_map {
|
||||
const Elf_Shdr *unw_sec;
|
||||
const Elf_Shdr *txt_sec;
|
||||
};
|
||||
|
||||
static const Elf_Shdr *find_mod_section(const Elf32_Ehdr *hdr,
|
||||
const Elf_Shdr *sechdrs, const char *name)
|
||||
{
|
||||
|
|
|
|||
|
|
@ -85,8 +85,7 @@ static bool
|
|||
callchain_trace(void *data, unsigned long pc)
|
||||
{
|
||||
struct perf_callchain_entry_ctx *entry = data;
|
||||
perf_callchain_store(entry, pc);
|
||||
return true;
|
||||
return perf_callchain_store(entry, pc) == 0;
|
||||
}
|
||||
|
||||
void
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ SECTIONS
|
|||
. = ALIGN(4);
|
||||
__ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
|
||||
__start___ex_table = .;
|
||||
ARM_MMU_KEEP(*(__ex_table))
|
||||
ARM_MMU_KEEP(KEEP(*(__ex_table)))
|
||||
__stop___ex_table = .;
|
||||
}
|
||||
|
||||
|
|
@ -83,7 +83,7 @@ SECTIONS
|
|||
}
|
||||
.init.arch.info : {
|
||||
__arch_info_begin = .;
|
||||
*(.arch.info.init)
|
||||
KEEP(*(.arch.info.init))
|
||||
__arch_info_end = .;
|
||||
}
|
||||
.init.tagtable : {
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ SECTIONS
|
|||
. = ALIGN(4);
|
||||
__ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
|
||||
__start___ex_table = .;
|
||||
ARM_MMU_KEEP(*(__ex_table))
|
||||
ARM_MMU_KEEP(KEEP(*(__ex_table)))
|
||||
__stop___ex_table = .;
|
||||
}
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ SECTIONS
|
|||
}
|
||||
.init.arch.info : {
|
||||
__arch_info_begin = .;
|
||||
*(.arch.info.init)
|
||||
KEEP(*(.arch.info.init))
|
||||
__arch_info_end = .;
|
||||
}
|
||||
.init.tagtable : {
|
||||
|
|
@ -116,7 +116,7 @@ SECTIONS
|
|||
#endif
|
||||
.init.pv_table : {
|
||||
__pv_table_begin = .;
|
||||
*(.pv_table)
|
||||
KEEP(*(.pv_table))
|
||||
__pv_table_end = .;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ int alpine_cpu_wakeup(unsigned int phys_cpu, uint32_t phys_resume_addr)
|
|||
/*
|
||||
* Set CPU resume address -
|
||||
* secure firmware running on boot will jump to this address
|
||||
* after setting proper CPU mode, and initialiing e.g. secure
|
||||
* after setting proper CPU mode, and initializing e.g. secure
|
||||
* regs (the same mode all CPUs are booted to - usually HYP)
|
||||
*/
|
||||
writel(phys_resume_addr,
|
||||
|
|
|
|||
|
|
@ -21,6 +21,7 @@
|
|||
#include <linux/mtd/mtd.h>
|
||||
#include <linux/mtd/partitions.h>
|
||||
#include <linux/gpio/machine.h>
|
||||
#include <linux/gpio/property.h>
|
||||
#include <linux/gpio.h>
|
||||
#include <linux/err.h>
|
||||
#include <linux/clk.h>
|
||||
|
|
@ -40,6 +41,7 @@
|
|||
#include <linux/platform_data/mmc-pxamci.h>
|
||||
#include "udc.h"
|
||||
#include "gumstix.h"
|
||||
#include "devices.h"
|
||||
|
||||
#include "generic.h"
|
||||
|
||||
|
|
@ -99,8 +101,8 @@ static void __init gumstix_mmc_init(void)
|
|||
}
|
||||
#endif
|
||||
|
||||
#ifdef CONFIG_USB_PXA25X
|
||||
static const struct property_entry spitz_mci_props[] __initconst = {
|
||||
#if IS_ENABLED(CONFIG_USB_PXA25X)
|
||||
static const struct property_entry gumstix_vbus_props[] __initconst = {
|
||||
PROPERTY_ENTRY_GPIO("vbus-gpios", &pxa2xx_gpiochip_node,
|
||||
GPIO_GUMSTIX_USB_GPIOn, GPIO_ACTIVE_HIGH),
|
||||
PROPERTY_ENTRY_GPIO("pullup-gpios", &pxa2xx_gpiochip_node,
|
||||
|
|
@ -109,8 +111,9 @@ static const struct property_entry spitz_mci_props[] __initconst = {
|
|||
};
|
||||
|
||||
static const struct platform_device_info gumstix_gpio_vbus_info __initconst = {
|
||||
.name = "gpio-vbus",
|
||||
.id = PLATFORM_DEVID_NONE,
|
||||
.name = "gpio-vbus",
|
||||
.id = PLATFORM_DEVID_NONE,
|
||||
.properties = gumstix_vbus_props,
|
||||
};
|
||||
|
||||
static void __init gumstix_udc_init(void)
|
||||
|
|
|
|||
|
|
@ -1109,7 +1109,7 @@ void ecard_remove_driver(struct ecard_driver *drv)
|
|||
driver_unregister(&drv->drv);
|
||||
}
|
||||
|
||||
static int ecard_match(struct device *_dev, struct device_driver *_drv)
|
||||
static int ecard_match(struct device *_dev, const struct device_driver *_drv)
|
||||
{
|
||||
struct expansion_card *ec = ECARD_DEV(_dev);
|
||||
struct ecard_driver *drv = ECARD_DRV(_drv);
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ void cpu_arm7tdmi_proc_init(void);
|
|||
__ADDRESSABLE(cpu_arm7tdmi_proc_init);
|
||||
void cpu_arm7tdmi_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm7tdmi_proc_fin);
|
||||
void cpu_arm7tdmi_reset(void);
|
||||
void cpu_arm7tdmi_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm7tdmi_reset);
|
||||
int cpu_arm7tdmi_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm7tdmi_do_idle);
|
||||
|
|
@ -32,7 +32,7 @@ void cpu_arm720_proc_init(void);
|
|||
__ADDRESSABLE(cpu_arm720_proc_init);
|
||||
void cpu_arm720_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm720_proc_fin);
|
||||
void cpu_arm720_reset(void);
|
||||
void cpu_arm720_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm720_reset);
|
||||
int cpu_arm720_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm720_do_idle);
|
||||
|
|
@ -49,7 +49,7 @@ void cpu_arm740_proc_init(void);
|
|||
__ADDRESSABLE(cpu_arm740_proc_init);
|
||||
void cpu_arm740_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm740_proc_fin);
|
||||
void cpu_arm740_reset(void);
|
||||
void cpu_arm740_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm740_reset);
|
||||
int cpu_arm740_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm740_do_idle);
|
||||
|
|
@ -64,7 +64,7 @@ void cpu_arm9tdmi_proc_init(void);
|
|||
__ADDRESSABLE(cpu_arm9tdmi_proc_init);
|
||||
void cpu_arm9tdmi_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm9tdmi_proc_fin);
|
||||
void cpu_arm9tdmi_reset(void);
|
||||
void cpu_arm9tdmi_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm9tdmi_reset);
|
||||
int cpu_arm9tdmi_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm9tdmi_do_idle);
|
||||
|
|
@ -79,7 +79,7 @@ void cpu_arm920_proc_init(void);
|
|||
__ADDRESSABLE(cpu_arm920_proc_init);
|
||||
void cpu_arm920_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm920_proc_fin);
|
||||
void cpu_arm920_reset(void);
|
||||
void cpu_arm920_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm920_reset);
|
||||
int cpu_arm920_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm920_do_idle);
|
||||
|
|
@ -102,7 +102,7 @@ void cpu_arm922_proc_init(void);
|
|||
__ADDRESSABLE(cpu_arm922_proc_init);
|
||||
void cpu_arm922_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm922_proc_fin);
|
||||
void cpu_arm922_reset(void);
|
||||
void cpu_arm922_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm922_reset);
|
||||
int cpu_arm922_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm922_do_idle);
|
||||
|
|
@ -119,7 +119,7 @@ void cpu_arm925_proc_init(void);
|
|||
__ADDRESSABLE(cpu_arm925_proc_init);
|
||||
void cpu_arm925_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm925_proc_fin);
|
||||
void cpu_arm925_reset(void);
|
||||
void cpu_arm925_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm925_reset);
|
||||
int cpu_arm925_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm925_do_idle);
|
||||
|
|
@ -159,7 +159,7 @@ void cpu_arm940_proc_init(void);
|
|||
__ADDRESSABLE(cpu_arm940_proc_init);
|
||||
void cpu_arm940_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm940_proc_fin);
|
||||
void cpu_arm940_reset(void);
|
||||
void cpu_arm940_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm940_reset);
|
||||
int cpu_arm940_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm940_do_idle);
|
||||
|
|
@ -174,7 +174,7 @@ void cpu_arm946_proc_init(void);
|
|||
__ADDRESSABLE(cpu_arm946_proc_init);
|
||||
void cpu_arm946_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_arm946_proc_fin);
|
||||
void cpu_arm946_reset(void);
|
||||
void cpu_arm946_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_arm946_reset);
|
||||
int cpu_arm946_do_idle(void);
|
||||
__ADDRESSABLE(cpu_arm946_do_idle);
|
||||
|
|
@ -429,7 +429,7 @@ void cpu_v7_proc_init(void);
|
|||
__ADDRESSABLE(cpu_v7_proc_init);
|
||||
void cpu_v7_proc_fin(void);
|
||||
__ADDRESSABLE(cpu_v7_proc_fin);
|
||||
void cpu_v7_reset(void);
|
||||
void cpu_v7_reset(unsigned long addr, bool hvc);
|
||||
__ADDRESSABLE(cpu_v7_reset);
|
||||
int cpu_v7_do_idle(void);
|
||||
__ADDRESSABLE(cpu_v7_do_idle);
|
||||
|
|
|
|||
|
|
@ -1069,18 +1069,28 @@ config ARM64_ERRATUM_3117295
|
|||
If unsure, say Y.
|
||||
|
||||
config ARM64_ERRATUM_3194386
|
||||
bool "Cortex-{A720,X4,X925}/Neoverse-V3: workaround for MSR SSBS not self-synchronizing"
|
||||
bool "Cortex-*/Neoverse-*: workaround for MSR SSBS not self-synchronizing"
|
||||
default y
|
||||
help
|
||||
This option adds the workaround for the following errata:
|
||||
|
||||
* ARM Cortex-A76 erratum 3324349
|
||||
* ARM Cortex-A77 erratum 3324348
|
||||
* ARM Cortex-A78 erratum 3324344
|
||||
* ARM Cortex-A78C erratum 3324346
|
||||
* ARM Cortex-A78C erratum 3324347
|
||||
* ARM Cortex-A710 erratam 3324338
|
||||
* ARM Cortex-A720 erratum 3456091
|
||||
* ARM Cortex-A725 erratum 3456106
|
||||
* ARM Cortex-X1 erratum 3324344
|
||||
* ARM Cortex-X1C erratum 3324346
|
||||
* ARM Cortex-X2 erratum 3324338
|
||||
* ARM Cortex-X3 erratum 3324335
|
||||
* ARM Cortex-X4 erratum 3194386
|
||||
* ARM Cortex-X925 erratum 3324334
|
||||
* ARM Neoverse-N1 erratum 3324349
|
||||
* ARM Neoverse N2 erratum 3324339
|
||||
* ARM Neoverse-V1 erratum 3324341
|
||||
* ARM Neoverse V2 erratum 3324336
|
||||
* ARM Neoverse-V3 erratum 3312417
|
||||
|
||||
|
|
@ -1088,11 +1098,11 @@ config ARM64_ERRATUM_3194386
|
|||
subsequent speculative instructions, which may permit unexepected
|
||||
speculative store bypassing.
|
||||
|
||||
Work around this problem by placing a speculation barrier after
|
||||
kernel changes to SSBS. The presence of the SSBS special-purpose
|
||||
register is hidden from hwcaps and EL0 reads of ID_AA64PFR1_EL1, such
|
||||
that userspace will use the PR_SPEC_STORE_BYPASS prctl to change
|
||||
SSBS.
|
||||
Work around this problem by placing a Speculation Barrier (SB) or
|
||||
Instruction Synchronization Barrier (ISB) after kernel changes to
|
||||
SSBS. The presence of the SSBS special-purpose register is hidden
|
||||
from hwcaps and EL0 reads of ID_AA64PFR1_EL1, such that userspace
|
||||
will use the PR_SPEC_STORE_BYPASS prctl to change SSBS.
|
||||
|
||||
If unsure, say Y.
|
||||
|
||||
|
|
|
|||
|
|
@ -175,7 +175,7 @@
|
|||
};
|
||||
};
|
||||
|
||||
core-cluster-thermal {
|
||||
cluster-thermal {
|
||||
polling-delay-passive = <1000>;
|
||||
polling-delay = <5000>;
|
||||
thermal-sensors = <&tmu 1>;
|
||||
|
|
|
|||
|
|
@ -214,7 +214,7 @@
|
|||
};
|
||||
};
|
||||
|
||||
core-cluster-thermal {
|
||||
cluster-thermal {
|
||||
polling-delay-passive = <1000>;
|
||||
polling-delay = <5000>;
|
||||
thermal-sensors = <&tmu 3>;
|
||||
|
|
|
|||
|
|
@ -182,7 +182,7 @@
|
|||
};
|
||||
};
|
||||
|
||||
core-cluster-thermal {
|
||||
cluster-thermal {
|
||||
polling-delay-passive = <1000>;
|
||||
polling-delay = <5000>;
|
||||
thermal-sensors = <&tmu 3>;
|
||||
|
|
|
|||
|
|
@ -131,7 +131,7 @@
|
|||
};
|
||||
|
||||
thermal-zones {
|
||||
core-cluster-thermal {
|
||||
cluster-thermal {
|
||||
polling-delay-passive = <1000>;
|
||||
polling-delay = <5000>;
|
||||
thermal-sensors = <&tmu 0>;
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@
|
|||
};
|
||||
};
|
||||
|
||||
core-cluster1-thermal {
|
||||
cluster1-thermal {
|
||||
polling-delay-passive = <1000>;
|
||||
polling-delay = <5000>;
|
||||
thermal-sensors = <&tmu 4>;
|
||||
|
|
@ -151,7 +151,7 @@
|
|||
};
|
||||
};
|
||||
|
||||
core-cluster2-thermal {
|
||||
cluster2-thermal {
|
||||
polling-delay-passive = <1000>;
|
||||
polling-delay = <5000>;
|
||||
thermal-sensors = <&tmu 5>;
|
||||
|
|
@ -180,7 +180,7 @@
|
|||
};
|
||||
};
|
||||
|
||||
core-cluster3-thermal {
|
||||
cluster3-thermal {
|
||||
polling-delay-passive = <1000>;
|
||||
polling-delay = <5000>;
|
||||
thermal-sensors = <&tmu 6>;
|
||||
|
|
@ -209,7 +209,7 @@
|
|||
};
|
||||
};
|
||||
|
||||
core-cluster4-thermal {
|
||||
cluster4-thermal {
|
||||
polling-delay-passive = <1000>;
|
||||
polling-delay = <5000>;
|
||||
thermal-sensors = <&tmu 7>;
|
||||
|
|
|
|||
|
|
@ -492,7 +492,7 @@
|
|||
};
|
||||
};
|
||||
|
||||
ddr-cluster5-thermal {
|
||||
ddr-ctrl5-thermal {
|
||||
polling-delay-passive = <1000>;
|
||||
polling-delay = <5000>;
|
||||
thermal-sensors = <&tmu 1>;
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@
|
|||
|
||||
&gpio3 {
|
||||
pinctrl-names = "default";
|
||||
pinctrcl-0 = <&pinctrl_gpio3_hog>;
|
||||
pinctrl-0 = <&pinctrl_gpio3_hog>;
|
||||
|
||||
uart4_rs485_en {
|
||||
gpio-hog;
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@
|
|||
|
||||
&gpio3 {
|
||||
pinctrl-names = "default";
|
||||
pinctrcl-0 = <&pinctrl_gpio3_hog>;
|
||||
pinctrl-0 = <&pinctrl_gpio3_hog>;
|
||||
|
||||
uart4_rs485_en {
|
||||
gpio-hog;
|
||||
|
|
|
|||
|
|
@ -211,13 +211,12 @@
|
|||
|
||||
simple-audio-card,cpu {
|
||||
sound-dai = <&sai3>;
|
||||
frame-master;
|
||||
bitclock-master;
|
||||
};
|
||||
|
||||
simple-audio-card,codec {
|
||||
sound-dai = <&wm8962>;
|
||||
clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO1>;
|
||||
frame-master;
|
||||
bitclock-master;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -507,10 +506,9 @@
|
|||
&sai3 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_sai3>;
|
||||
assigned-clocks = <&clk IMX8MP_CLK_SAI3>,
|
||||
<&clk IMX8MP_AUDIO_PLL2> ;
|
||||
assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL2_OUT>;
|
||||
assigned-clock-rates = <12288000>, <361267200>;
|
||||
assigned-clocks = <&clk IMX8MP_CLK_SAI3>;
|
||||
assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;
|
||||
assigned-clock-rates = <12288000>;
|
||||
fsl,sai-mclk-direction-output;
|
||||
status = "okay";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -499,7 +499,7 @@
|
|||
pinctrl-0 = <&pinctrl_usdhc2_hs>, <&pinctrl_usdhc2_gpio>;
|
||||
pinctrl-1 = <&pinctrl_usdhc2_uhs>, <&pinctrl_usdhc2_gpio>;
|
||||
pinctrl-2 = <&pinctrl_usdhc2_uhs>, <&pinctrl_usdhc2_gpio>;
|
||||
cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>;
|
||||
cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
|
||||
vmmc-supply = <®_usdhc2_vmmc>;
|
||||
bus-width = <4>;
|
||||
no-sdio;
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@
|
|||
linux,cma {
|
||||
compatible = "shared-dma-pool";
|
||||
reusable;
|
||||
alloc-ranges = <0 0x60000000 0 0x40000000>;
|
||||
alloc-ranges = <0 0x80000000 0 0x40000000>;
|
||||
size = <0 0x10000000>;
|
||||
linux,cma-default;
|
||||
};
|
||||
|
|
@ -156,6 +156,7 @@
|
|||
&wdog3 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_wdog>;
|
||||
fsl,ext-reset-output;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -1105,7 +1105,7 @@
|
|||
<&clk IMX93_CLK_SYS_PLL_PFD0_DIV2>;
|
||||
assigned-clock-rates = <100000000>, <250000000>;
|
||||
intf_mode = <&wakeupmix_gpr 0x28>;
|
||||
snps,clk-csr = <0>;
|
||||
snps,clk-csr = <6>;
|
||||
nvmem-cells = <ð_mac2>;
|
||||
nvmem-cell-names = "mac-address";
|
||||
status = "disabled";
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@
|
|||
reg = <0x0>;
|
||||
enable-method = "psci";
|
||||
#cooling-cells = <2>;
|
||||
power-domains = <&scmi_devpd IMX95_PERF_A55>;
|
||||
power-domains = <&scmi_perf IMX95_PERF_A55>;
|
||||
power-domain-names = "perf";
|
||||
i-cache-size = <32768>;
|
||||
i-cache-line-size = <64>;
|
||||
|
|
@ -44,7 +44,7 @@
|
|||
reg = <0x100>;
|
||||
enable-method = "psci";
|
||||
#cooling-cells = <2>;
|
||||
power-domains = <&scmi_devpd IMX95_PERF_A55>;
|
||||
power-domains = <&scmi_perf IMX95_PERF_A55>;
|
||||
power-domain-names = "perf";
|
||||
i-cache-size = <32768>;
|
||||
i-cache-line-size = <64>;
|
||||
|
|
@ -61,7 +61,7 @@
|
|||
reg = <0x200>;
|
||||
enable-method = "psci";
|
||||
#cooling-cells = <2>;
|
||||
power-domains = <&scmi_devpd IMX95_PERF_A55>;
|
||||
power-domains = <&scmi_perf IMX95_PERF_A55>;
|
||||
power-domain-names = "perf";
|
||||
i-cache-size = <32768>;
|
||||
i-cache-line-size = <64>;
|
||||
|
|
@ -78,7 +78,7 @@
|
|||
reg = <0x300>;
|
||||
enable-method = "psci";
|
||||
#cooling-cells = <2>;
|
||||
power-domains = <&scmi_devpd IMX95_PERF_A55>;
|
||||
power-domains = <&scmi_perf IMX95_PERF_A55>;
|
||||
power-domain-names = "perf";
|
||||
i-cache-size = <32768>;
|
||||
i-cache-line-size = <64>;
|
||||
|
|
@ -93,7 +93,7 @@
|
|||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a55";
|
||||
reg = <0x400>;
|
||||
power-domains = <&scmi_devpd IMX95_PERF_A55>;
|
||||
power-domains = <&scmi_perf IMX95_PERF_A55>;
|
||||
power-domain-names = "perf";
|
||||
enable-method = "psci";
|
||||
#cooling-cells = <2>;
|
||||
|
|
@ -110,7 +110,7 @@
|
|||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a55";
|
||||
reg = <0x500>;
|
||||
power-domains = <&scmi_devpd IMX95_PERF_A55>;
|
||||
power-domains = <&scmi_perf IMX95_PERF_A55>;
|
||||
power-domain-names = "perf";
|
||||
enable-method = "psci";
|
||||
#cooling-cells = <2>;
|
||||
|
|
@ -187,7 +187,7 @@
|
|||
compatible = "cache";
|
||||
cache-size = <524288>;
|
||||
cache-line-size = <64>;
|
||||
cache-sets = <1024>;
|
||||
cache-sets = <512>;
|
||||
cache-level = <3>;
|
||||
cache-unified;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -320,8 +320,8 @@
|
|||
reg = <0x08af8800 0x400>;
|
||||
|
||||
interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 53 IRQ_TYPE_EDGE_BOTH>,
|
||||
<GIC_SPI 52 IRQ_TYPE_EDGE_BOTH>;
|
||||
<GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "pwr_event",
|
||||
"dp_hs_phy_irq",
|
||||
"dm_hs_phy_irq";
|
||||
|
|
|
|||
|
|
@ -278,6 +278,13 @@
|
|||
vdd-l3-supply = <&vreg_s1f_0p7>;
|
||||
vdd-s1-supply = <&vph_pwr>;
|
||||
vdd-s2-supply = <&vph_pwr>;
|
||||
|
||||
vreg_l3i_0p8: ldo3 {
|
||||
regulator-name = "vreg_l3i_0p8";
|
||||
regulator-min-microvolt = <880000>;
|
||||
regulator-max-microvolt = <920000>;
|
||||
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
|
||||
};
|
||||
};
|
||||
|
||||
regulators-7 {
|
||||
|
|
@ -423,11 +430,17 @@
|
|||
};
|
||||
|
||||
&pcie4 {
|
||||
perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
|
||||
wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
|
||||
|
||||
pinctrl-0 = <&pcie4_default>;
|
||||
pinctrl-names = "default";
|
||||
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&pcie4_phy {
|
||||
vdda-phy-supply = <&vreg_l3j_0p8>;
|
||||
vdda-phy-supply = <&vreg_l3i_0p8>;
|
||||
vdda-pll-supply = <&vreg_l3e_1p2>;
|
||||
|
||||
status = "okay";
|
||||
|
|
@ -517,7 +530,30 @@
|
|||
bias-disable;
|
||||
};
|
||||
|
||||
pcie6a_default: pcie2a-default-state {
|
||||
pcie4_default: pcie4-default-state {
|
||||
clkreq-n-pins {
|
||||
pins = "gpio147";
|
||||
function = "pcie4_clk";
|
||||
drive-strength = <2>;
|
||||
bias-pull-up;
|
||||
};
|
||||
|
||||
perst-n-pins {
|
||||
pins = "gpio146";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-disable;
|
||||
};
|
||||
|
||||
wake-n-pins {
|
||||
pins = "gpio148";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-pull-up;
|
||||
};
|
||||
};
|
||||
|
||||
pcie6a_default: pcie6a-default-state {
|
||||
clkreq-n-pins {
|
||||
pins = "gpio153";
|
||||
function = "pcie6a_clk";
|
||||
|
|
@ -529,7 +565,7 @@
|
|||
pins = "gpio152";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-pull-down;
|
||||
bias-disable;
|
||||
};
|
||||
|
||||
wake-n-pins {
|
||||
|
|
|
|||
|
|
@ -268,7 +268,6 @@
|
|||
pinctrl-0 = <&edp_reg_en>;
|
||||
pinctrl-names = "default";
|
||||
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
};
|
||||
|
||||
|
|
@ -637,6 +636,14 @@
|
|||
};
|
||||
};
|
||||
|
||||
&gpu {
|
||||
status = "okay";
|
||||
|
||||
zap-shader {
|
||||
firmware-name = "qcom/x1e80100/gen70500_zap.mbn";
|
||||
};
|
||||
};
|
||||
|
||||
&i2c0 {
|
||||
clock-frequency = <400000>;
|
||||
|
||||
|
|
@ -724,9 +731,13 @@
|
|||
|
||||
aux-bus {
|
||||
panel {
|
||||
compatible = "edp-panel";
|
||||
compatible = "samsung,atna45af01", "samsung,atna33xc20";
|
||||
enable-gpios = <&pmc8380_3_gpios 4 GPIO_ACTIVE_HIGH>;
|
||||
power-supply = <&vreg_edp_3p3>;
|
||||
|
||||
pinctrl-0 = <&edp_bl_en>;
|
||||
pinctrl-names = "default";
|
||||
|
||||
port {
|
||||
edp_panel_in: endpoint {
|
||||
remote-endpoint = <&mdss_dp3_out>;
|
||||
|
|
@ -756,11 +767,17 @@
|
|||
};
|
||||
|
||||
&pcie4 {
|
||||
perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
|
||||
wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
|
||||
|
||||
pinctrl-0 = <&pcie4_default>;
|
||||
pinctrl-names = "default";
|
||||
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&pcie4_phy {
|
||||
vdda-phy-supply = <&vreg_l3j_0p8>;
|
||||
vdda-phy-supply = <&vreg_l3i_0p8>;
|
||||
vdda-pll-supply = <&vreg_l3e_1p2>;
|
||||
|
||||
status = "okay";
|
||||
|
|
@ -785,6 +802,16 @@
|
|||
status = "okay";
|
||||
};
|
||||
|
||||
&pmc8380_3_gpios {
|
||||
edp_bl_en: edp-bl-en-state {
|
||||
pins = "gpio4";
|
||||
function = "normal";
|
||||
power-source = <1>; /* 1.8V */
|
||||
input-disable;
|
||||
output-enable;
|
||||
};
|
||||
};
|
||||
|
||||
&qupv3_0 {
|
||||
status = "okay";
|
||||
};
|
||||
|
|
@ -931,7 +958,30 @@
|
|||
bias-disable;
|
||||
};
|
||||
|
||||
pcie6a_default: pcie2a-default-state {
|
||||
pcie4_default: pcie4-default-state {
|
||||
clkreq-n-pins {
|
||||
pins = "gpio147";
|
||||
function = "pcie4_clk";
|
||||
drive-strength = <2>;
|
||||
bias-pull-up;
|
||||
};
|
||||
|
||||
perst-n-pins {
|
||||
pins = "gpio146";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-disable;
|
||||
};
|
||||
|
||||
wake-n-pins {
|
||||
pins = "gpio148";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-pull-up;
|
||||
};
|
||||
};
|
||||
|
||||
pcie6a_default: pcie6a-default-state {
|
||||
clkreq-n-pins {
|
||||
pins = "gpio153";
|
||||
function = "pcie6a_clk";
|
||||
|
|
@ -943,15 +993,15 @@
|
|||
pins = "gpio152";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-pull-down;
|
||||
bias-disable;
|
||||
};
|
||||
|
||||
wake-n-pins {
|
||||
pins = "gpio154";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-pull-up;
|
||||
};
|
||||
pins = "gpio154";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-pull-up;
|
||||
};
|
||||
};
|
||||
|
||||
tpad_default: tpad-default-state {
|
||||
|
|
|
|||
|
|
@ -625,16 +625,31 @@
|
|||
};
|
||||
|
||||
&pcie4 {
|
||||
perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
|
||||
wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
|
||||
|
||||
pinctrl-0 = <&pcie4_default>;
|
||||
pinctrl-names = "default";
|
||||
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&pcie4_phy {
|
||||
vdda-phy-supply = <&vreg_l3j_0p8>;
|
||||
vdda-phy-supply = <&vreg_l3i_0p8>;
|
||||
vdda-pll-supply = <&vreg_l3e_1p2>;
|
||||
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&pcie4_port0 {
|
||||
wifi@0 {
|
||||
compatible = "pci17cb,1107";
|
||||
reg = <0x10000 0x0 0x0 0x0 0x0>;
|
||||
|
||||
qcom,ath12k-calibration-variant = "LES790";
|
||||
};
|
||||
};
|
||||
|
||||
&pcie6a {
|
||||
perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
|
||||
wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
|
||||
|
|
@ -782,7 +797,30 @@
|
|||
bias-disable;
|
||||
};
|
||||
|
||||
pcie6a_default: pcie2a-default-state {
|
||||
pcie4_default: pcie4-default-state {
|
||||
clkreq-n-pins {
|
||||
pins = "gpio147";
|
||||
function = "pcie4_clk";
|
||||
drive-strength = <2>;
|
||||
bias-pull-up;
|
||||
};
|
||||
|
||||
perst-n-pins {
|
||||
pins = "gpio146";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-disable;
|
||||
};
|
||||
|
||||
wake-n-pins {
|
||||
pins = "gpio148";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-pull-up;
|
||||
};
|
||||
};
|
||||
|
||||
pcie6a_default: pcie6a-default-state {
|
||||
clkreq-n-pins {
|
||||
pins = "gpio153";
|
||||
function = "pcie6a_clk";
|
||||
|
|
@ -794,15 +832,15 @@
|
|||
pins = "gpio152";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-pull-down;
|
||||
bias-disable;
|
||||
};
|
||||
|
||||
wake-n-pins {
|
||||
pins = "gpio154";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-pull-up;
|
||||
};
|
||||
pins = "gpio154";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-pull-up;
|
||||
};
|
||||
};
|
||||
|
||||
tpad_default: tpad-default-state {
|
||||
|
|
|
|||
|
|
@ -606,6 +606,14 @@
|
|||
};
|
||||
};
|
||||
|
||||
&gpu {
|
||||
status = "okay";
|
||||
|
||||
zap-shader {
|
||||
firmware-name = "qcom/x1e80100/gen70500_zap.mbn";
|
||||
};
|
||||
};
|
||||
|
||||
&lpass_tlmm {
|
||||
spkr_01_sd_n_active: spkr-01-sd-n-active-state {
|
||||
pins = "gpio12";
|
||||
|
|
@ -660,11 +668,17 @@
|
|||
};
|
||||
|
||||
&pcie4 {
|
||||
perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
|
||||
wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
|
||||
|
||||
pinctrl-0 = <&pcie4_default>;
|
||||
pinctrl-names = "default";
|
||||
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
&pcie4_phy {
|
||||
vdda-phy-supply = <&vreg_l3j_0p8>;
|
||||
vdda-phy-supply = <&vreg_l3i_0p8>;
|
||||
vdda-pll-supply = <&vreg_l3e_1p2>;
|
||||
|
||||
status = "okay";
|
||||
|
|
@ -804,7 +818,30 @@
|
|||
bias-disable;
|
||||
};
|
||||
|
||||
pcie6a_default: pcie2a-default-state {
|
||||
pcie4_default: pcie4-default-state {
|
||||
clkreq-n-pins {
|
||||
pins = "gpio147";
|
||||
function = "pcie4_clk";
|
||||
drive-strength = <2>;
|
||||
bias-pull-up;
|
||||
};
|
||||
|
||||
perst-n-pins {
|
||||
pins = "gpio146";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-disable;
|
||||
};
|
||||
|
||||
wake-n-pins {
|
||||
pins = "gpio148";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-pull-up;
|
||||
};
|
||||
};
|
||||
|
||||
pcie6a_default: pcie6a-default-state {
|
||||
clkreq-n-pins {
|
||||
pins = "gpio153";
|
||||
function = "pcie6a_clk";
|
||||
|
|
@ -816,15 +853,15 @@
|
|||
pins = "gpio152";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-pull-down;
|
||||
bias-disable;
|
||||
};
|
||||
|
||||
wake-n-pins {
|
||||
pins = "gpio154";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-pull-up;
|
||||
};
|
||||
pins = "gpio154";
|
||||
function = "gpio";
|
||||
drive-strength = <2>;
|
||||
bias-pull-up;
|
||||
};
|
||||
};
|
||||
|
||||
wcd_default: wcd-reset-n-active-state {
|
||||
|
|
|
|||
|
|
@ -2901,7 +2901,7 @@
|
|||
|
||||
dma-coherent;
|
||||
|
||||
linux,pci-domain = <7>;
|
||||
linux,pci-domain = <6>;
|
||||
num-lanes = <2>;
|
||||
|
||||
interrupts = <GIC_SPI 773 IRQ_TYPE_LEVEL_HIGH>,
|
||||
|
|
@ -2959,6 +2959,7 @@
|
|||
"link_down";
|
||||
|
||||
power-domains = <&gcc GCC_PCIE_6A_GDSC>;
|
||||
required-opps = <&rpmhpd_opp_nom>;
|
||||
|
||||
phys = <&pcie6a_phy>;
|
||||
phy-names = "pciephy";
|
||||
|
|
@ -3022,7 +3023,7 @@
|
|||
|
||||
dma-coherent;
|
||||
|
||||
linux,pci-domain = <5>;
|
||||
linux,pci-domain = <4>;
|
||||
num-lanes = <2>;
|
||||
|
||||
interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
|
||||
|
|
@ -3080,11 +3081,22 @@
|
|||
"link_down";
|
||||
|
||||
power-domains = <&gcc GCC_PCIE_4_GDSC>;
|
||||
required-opps = <&rpmhpd_opp_nom>;
|
||||
|
||||
phys = <&pcie4_phy>;
|
||||
phy-names = "pciephy";
|
||||
|
||||
status = "disabled";
|
||||
|
||||
pcie4_port0: pcie@0 {
|
||||
device_type = "pci";
|
||||
reg = <0x0 0x0 0x0 0x0 0x0>;
|
||||
bus-range = <0x01 0xff>;
|
||||
|
||||
#address-cells = <3>;
|
||||
#size-cells = <2>;
|
||||
ranges;
|
||||
};
|
||||
};
|
||||
|
||||
pcie4_phy: phy@1c0e000 {
|
||||
|
|
@ -3155,9 +3167,10 @@
|
|||
interconnects = <&gem_noc MASTER_GFX3D 0 &mc_virt SLAVE_EBI1 0>;
|
||||
interconnect-names = "gfx-mem";
|
||||
|
||||
status = "disabled";
|
||||
|
||||
zap-shader {
|
||||
memory-region = <&gpu_microcode_mem>;
|
||||
firmware-name = "qcom/gen70500_zap.mbn";
|
||||
};
|
||||
|
||||
gpu_opp_table: opp-table {
|
||||
|
|
@ -3288,7 +3301,7 @@
|
|||
reg = <0x0 0x03da0000 0x0 0x40000>;
|
||||
#iommu-cells = <2>;
|
||||
#global-interrupts = <1>;
|
||||
interrupts = <GIC_SPI 673 IRQ_TYPE_LEVEL_HIGH>,
|
||||
interrupts = <GIC_SPI 674 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 678 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 679 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 680 IRQ_TYPE_LEVEL_HIGH>,
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user