* [PATCH v8 3/6] ARM: zte: Add support for zx29 low level debug
From: Stefan Dösinger @ 2026-05-06 19:33 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial, Stefan Dösinger
In-Reply-To: <20260506-send-v8-0-f1bdf3243b34@gmail.com>
This is based on the removed zx29 code. A separate (more complicated)
patch will re-add the register map to the pl011 serial driver.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Patch changelog:
v8: Adjust UART01x_FR_BUSY to match the different ZX UART registers
(Sashiko). I am unsure about UART01x_FR_TXFF and my boards do not expose
flow control pins to allow me to test if it works.
I am unsure about the virtual address. It doesn't seem to matter, as
long as it is a valid address. This address is based on the old removed
code. Is there a rule-of-thumb physical to virtual mapping I can use to
give a sensible default value?
---
arch/arm/Kconfig.debug | 12 ++++++++++++
arch/arm/include/debug/pl01x.S | 9 +++++++++
2 files changed, 21 insertions(+)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 366f162e147d..98d8a5a60048 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1331,6 +1331,16 @@ choice
This option selects UART0 on VIA/Wondermedia System-on-a-chip
devices, including VT8500, WM8505, WM8650 and WM8850.
+ config DEBUG_ZTE_ZX
+ bool "Kernel low-level debugging via zx29 UART"
+ select DEBUG_UART_PL01X
+ depends on ARCH_ZTE
+ help
+ Say Y here if you are enabling ZTE zx297520v3 SOC and need
+ debug UART support. This UART is a PL011 with different
+ register addresses. The UART for boot messages on zx29 boards
+ is usually UART1 and is operating at 921600 8N1.
+
config DEBUG_ZYNQ_UART0
bool "Kernel low-level debugging on Xilinx Zynq using UART0"
depends on ARCH_ZYNQ
@@ -1545,6 +1555,7 @@ config DEBUG_UART_8250
config DEBUG_UART_PHYS
hex "Physical base address of debug UART"
+ default 0x01408000 if DEBUG_ZTE_ZX
default 0x01c28000 if DEBUG_SUNXI_UART0
default 0x01c28400 if DEBUG_SUNXI_UART1
default 0x01d0c000 if DEBUG_DAVINCI_DA8XX_UART1
@@ -1701,6 +1712,7 @@ config DEBUG_UART_VIRT
default 0xf31004c0 if DEBUG_MESON_UARTAO
default 0xf4090000 if DEBUG_LPC32XX
default 0xf4200000 if DEBUG_GEMINI
+ default 0xf4708000 if DEBUG_ZTE_ZX
default 0xf6200000 if DEBUG_PXA_UART1
default 0xf7000000 if DEBUG_SUN9I_UART0
default 0xf7000000 if DEBUG_S3C64XX_UART && DEBUG_S3C_UART0
diff --git a/arch/arm/include/debug/pl01x.S b/arch/arm/include/debug/pl01x.S
index c7e02d0628bf..9dcdeed2357d 100644
--- a/arch/arm/include/debug/pl01x.S
+++ b/arch/arm/include/debug/pl01x.S
@@ -8,6 +8,15 @@
*/
#include <linux/amba/serial.h>
+#ifdef CONFIG_DEBUG_ZTE_ZX
+#undef UART01x_DR
+#undef UART01x_FR
+#undef UART01x_FR_BUSY
+#define UART01x_DR 0x04
+#define UART01x_FR 0x14
+#define UART01x_FR_BUSY (1<<8)
+#endif
+
#ifdef CONFIG_DEBUG_UART_PHYS
.macro addruart, rp, rv, tmp
ldr \rp, =CONFIG_DEBUG_UART_PHYS
--
2.53.0
^ permalink raw reply related
* [PATCH v8 2/6] ARM: zte: Add zx297520v3 platform support
From: Stefan Dösinger @ 2026-05-06 19:33 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial, Stefan Dösinger, Krzysztof Kozlowski
In-Reply-To: <20260506-send-v8-0-f1bdf3243b34@gmail.com>
This SoC is used in low end LTE-to-WiFi routers, for example some D-Link
DWR 932 revisions, ZTE K10, ZLT S10 4G, but also models that are branded
and sold by ISPs themselves. They are widespread in Africa, China,
Russia and Eastern Europe.
This SoC is a relative of the zx296702 and zx296718 that had some
upstream support until commit 89d4f98ae90d ("ARM: remove zte zx
platform"). My eventual goal is to enable OpenWRT to run on these
devices.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Patch changelog:
v8:
* Select ARM_PSCI_FW (Sashiko). This is an issue make defconfig pointed
out in the last patch in this series. The board does not have PSCI
firmware as far as I can tell, but the ARM_GIC_V3 option indirectly
assumes ARM_PSCI_FW is enabled.
* Include <linux/init.h> in the board file for __initdata (Sashiko),
removed other includes copypasted from another platform that aren't
needed. Let's see if Sashiko agrees.
* Add the SoC documentation to the documentation index (Sashiko)
* Add the SoC documentation to MAINTAINERS (Sashiko)
* Removed redundant if ARCH_ZTE (Sashiko)
* Point towards a sane (USB-Only) U-Boot and modify the example code for
booting from NAND to detect already fixed GIC setups.
---
Documentation/arch/arm/index.rst | 2 +
Documentation/arch/arm/zte/index.rst | 10 ++
Documentation/arch/arm/zte/zx297520v3.rst | 167 ++++++++++++++++++++++++++++++
MAINTAINERS | 2 +
arch/arm/Kconfig | 2 +
arch/arm/Makefile | 1 +
arch/arm/mach-zte/Kconfig | 29 ++++++
arch/arm/mach-zte/Makefile | 2 +
arch/arm/mach-zte/zx297520v3.c | 16 +++
9 files changed, 231 insertions(+)
diff --git a/Documentation/arch/arm/index.rst b/Documentation/arch/arm/index.rst
index afe17db294c4..b15621093f7a 100644
--- a/Documentation/arch/arm/index.rst
+++ b/Documentation/arch/arm/index.rst
@@ -75,3 +75,5 @@ SoC-specific documents
sti/overview
vfp/release-notes
+
+ zte/index
diff --git a/Documentation/arch/arm/zte/index.rst b/Documentation/arch/arm/zte/index.rst
new file mode 100644
index 000000000000..0ed80b60b746
--- /dev/null
+++ b/Documentation/arch/arm/zte/index.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+=======
+ZTE SoC
+=======
+
+.. toctree::
+ :maxdepth: 1
+
+ zx297520v3
diff --git a/Documentation/arch/arm/zte/zx297520v3.rst b/Documentation/arch/arm/zte/zx297520v3.rst
new file mode 100644
index 000000000000..2122887e391a
--- /dev/null
+++ b/Documentation/arch/arm/zte/zx297520v3.rst
@@ -0,0 +1,167 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+====================================
+Booting Linux on ZTE zx297520v3 SoCs
+====================================
+
+...............................................................................
+
+Author: Stefan Dösinger
+
+Date : 27 Jan 2026
+
+1. Hardware description
+---------------------------
+Zx297520v3 SoCs use a 64 bit capable Cortex-A53 CPU and GICv3, although they
+run in arm32 mode only. The CPU has support EL3, but no hypervisor (EL2) and
+it seems to lack VFP and NEON.
+
+The SoC is used in a number of cheap LTE to WiFi routers, both battery powered
+MiFis and stationary CPEs. In addition to the CPU these devices usually have
+64 MB Ram (although some is shared with the LTE chip), 128 MB NAND flash, an
+SDIO connected RTL8192-type Wifi chip limited to 2.4 ghz operation, USB 2,
+and buttons. Devices with as low as 32 MB or as high as 128 MB ram exist, as
+do devices with 8 or 16 MB of NOR flash.
+
+Some devices, especially the stationary ones, have 100 mbit Ethernet and an
+Ethernet switch.
+
+Usually the devices have LEDs for status indication, although some have SPI or
+I2C connected displays
+
+Some have an SD card slot. If it exists, it is a better choice for the root
+file system because it easily outperforms the built-in NAND.
+
+The LTE interface runs on a separate DSP called ZSP880. It is probably derived
+from LSI ZSPs and has an undocumented instruction set. The ZSP communicates
+with the main CPU via SRAM and DRAM and a mailbox hardware that can generate
+IRQs on either ends.
+
+There is also a Cortex M0 CPU, which is responsible for early HW initialization
+and starting the Cortex A53 CPU. It does not have any essential purpose once
+U-Boot is started. A SRAM-Based handover protocol exists to run custom code on
+this CPU.
+
+2. Booting via USB
+---------------------------
+
+The Boot ROM has support for booting custom code via USB. This mode can be
+entered by connecting a Boot PIN to GND or by modifying the third byte on NAND
+(set it to anything other than 0x5A aka 'Z'). A free software tool to start
+custom U-Boot and kernels can be found here:
+
+https://github.com/zx297520v3-mainline/zx297520v3-loader
+
+If USB download mode is entered but no boot commands are sent through USB, the
+device will proceed to boot normally after a few seconds. It is therefore
+possible to enable USB boot permanently and still leave the default boot files
+in place.
+
+https://github.com/zx297520v3-mainline/u-boot-mainline
+
+Contains an U-Boot version that can be used with the USB loader and sets up the
+CPU and interrupt controller to comply with Linux's booting requirements.
+
+3. Building for built-in U-Boot
+---------------------------
+The devices come with an ancient U-Boot that loads legacy uImages from NAND and
+boots them without a chance for the user to interrupt. The images are stored in
+files ap_cpuap.bin and ap_recovery.bin on a jffs2 partition named imagefs,
+usually mtd4. A file named "fotaflag" switches between the two modes.
+
+In addition to the uImage header, those files have a 384 byte signature header,
+which is used for authenticating the images on some devices. Most devices have
+this authentication disabled and it is enough to pad the uImage files with 384
+zero bytes.
+
+Builtin U-Boot also poorly sets up the CPU. Read the next section for details
+on this. It has no support for loading DTBs, so CONFIG_ARM_APPENDED_DTB is
+needed.
+
+So to build an image that boots from NAND the following steps are necessary:
+
+1) Patch the assembly code from section 3 into arch/arm/kernel/head.S.
+2) make zx29_defconfig
+3) make [-j x]
+4) cat arch/arm/boot/zImage arch/arm/boot/dts/zte/[device].dtb > kernel+dtb
+5) mkimage -A arm -O linux -T kernel -C none -a 0x20008000 -d kernel+dtb uimg
+6) dd if=/dev/zero bs=1 count=384 of=ap_recovery.bin
+7) cat uimg >> ap_recovery.bin
+8) Place this file onto imagefs on the device. Delete ap_cpuap.bin if the
+free space is not enough.
+9) Create the file fotaflag: echo -n FOTA-RECOVERY > fotaflag
+
+For development, booting ap_recovery.bin is recommended because the normal boot
+mode arms the watchdog before starting the kernel.
+
+4. CPU and GIC Setup
+---------------------------
+
+Generally CPU and GICv3 need to be set up according to the requirements spelled
+out in Documentation/arch/arm64/booting.rst. For zx297520v3 this means:
+
+1. GICD_CTLR.DS=1 to disable GIC security
+2. Enable access to ICC_SRE
+3. Disable trapping IRQs into monitor mode
+4. Configure EL2 and below to run in insecure mode.
+5. Configure timer PPIs to active-low.
+
+The kernel sources provided by ZTE do not boot either (interrupts do not work
+at all). They are incomplete in other aspects too, so it is assumed that there
+is some workaround similar to the one described in this document somewhere in
+the binary blobs.
+
+The assembly code below is given as an example of how to achieve this:
+
+```
+#include <linux/irqchip/arm-gic-v3.h>
+#include <asm/assembler.h>
+#include <asm/cp15.h>
+
+@ Detect sane bootloaders and skip the hack
+ldr r3, =0xf2000000
+ldr r3, [r3]
+ldr r4, =(GICD_CTLR_ARE_NS | GICD_CTLR_DS)
+cmp r3, r4
+beq skip_zx_hack
+@ This allows EL1 to handle ints hat are normally handled by EL2/3.
+ldr r3, =0xf2000000
+str r4, [r3]
+
+cps #MON_MODE
+
+@ Work in non-secure physical address space: SCR_EL3.NS = 1. At least the UART
+@ seems to respond only to non-secure addresses. I have taken insipiration from
+@ Raspberry pi's armstub7.S here.
+mov r3, #0x131 @ non-secure, Make F, A bits in CPSR writeable
+ @ Allow hypervisor call.
+mcr p15, 0, r3, c1, c1, 0
+
+@ AP_PPI_MODE_REG: Configure timer PPIs (10, 11, 13, 14) to active-low.
+ldr r3, =0xF22020a8
+ldr r4, =0x50
+str r4, [r3]
+ldr r3, =0xF22020ac
+ldr r4, =0x14
+str r4, [r3]
+
+@ Enable EL2 access to ICC_SRE (bit 3, ICC_SRE_EL3.Enable). Enable system reg
+@ access to GICv3 registers (bit 0, ICC_SRE_EL3.SRE) for EL1 and EL3.
+mrc p15, 6, r3, c12, c12, 5 @ ICC_SRE_EL3
+orr r3, #0x9 @ FIXME: No defines for SRE_EL3 values?
+mcr p15, 6, r3, c12, c12, 5
+mrc p15, 0, r3, c12, c12, 5 @ ICC_SRE_EL1
+orr r3, #(ICC_SRE_EL1_SRE)
+mcr p15, 0, r3, c12, c12, 5
+
+@ Like ICC_SRE_EL3, enable EL1 access to ICC_SRE and system register access
+@ for EL2.
+mrc p15, 4, r3, c12, c9, 5 @ ICC_SRE_EL2 aka ICC_HSRE
+orr r3, r3, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE)
+mcr p15, 4, r3, c12, c9, 5
+isb
+
+@ Back to SVC mode
+cps #SVC_MODE
+skip_zx_hack:
+```
diff --git a/MAINTAINERS b/MAINTAINERS
index b768b9da37a4..697287d1b372 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3774,7 +3774,9 @@ F: drivers/video/fbdev/wmt_ge_rops.*
ARM/ZTE ZX29 SOC SUPPORT
M: Stefan Dösinger <stefandoesinger@gmail.com>
+F: Documentation/arch/arm/zte/
F: Documentation/devicetree/bindings/arm/zte.yaml
+F: arch/arm/mach-zte/
ARM/ZYNQ ARCHITECTURE
M: Michal Simek <michal.simek@amd.com>
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ec33376f8e2b..4217ed704e48 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -464,6 +464,8 @@ source "arch/arm/mach-versatile/Kconfig"
source "arch/arm/mach-vt8500/Kconfig"
+source "arch/arm/mach-zte/Kconfig"
+
source "arch/arm/mach-zynq/Kconfig"
# ARMv7-M architecture
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index b7de4b6b284c..573813ef5e77 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -223,6 +223,7 @@ machine-$(CONFIG_ARCH_SUNXI) += sunxi
machine-$(CONFIG_ARCH_TEGRA) += tegra
machine-$(CONFIG_ARCH_U8500) += ux500
machine-$(CONFIG_ARCH_VT8500) += vt8500
+machine-$(CONFIG_ARCH_ZTE) += zte
machine-$(CONFIG_ARCH_ZYNQ) += zynq
machine-$(CONFIG_PLAT_VERSATILE) += versatile
machine-$(CONFIG_PLAT_SPEAR) += spear
diff --git a/arch/arm/mach-zte/Kconfig b/arch/arm/mach-zte/Kconfig
new file mode 100644
index 000000000000..d3b404ca488d
--- /dev/null
+++ b/arch/arm/mach-zte/Kconfig
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: GPL-2.0-only
+menuconfig ARCH_ZTE
+ bool "ZTE zx family"
+ depends on ARCH_MULTI_V7
+ help
+ Support for ZTE zx-based family of processors.
+
+if ARCH_ZTE
+
+config SOC_ZX297520V3
+ bool "zx297520v3 SoC"
+ default y
+ select ARM_GIC_V3
+ # This board does not have PSCI firmware, but ARM_GIC_V3 depends on
+ # ARM_PSCI_FW being enabled.
+ select ARM_PSCI_FW
+ select ARM_AMBA
+ select HAVE_ARM_ARCH_TIMER
+ select PM_GENERIC_DOMAINS if PM
+ help
+ Support for ZTE zx297520v3 SoC. It is a single core SoC used in cheap
+ LTE to WiFi routers. These devices can be identified by the occurrence
+ of the string "zx297520v3" in the boot output and /proc/cpuinfo of
+ their stock firmware.
+
+ Please read Documentation/arch/arm/zte/zx297520v3.rst on how to boot
+ the kernel.
+
+endif
diff --git a/arch/arm/mach-zte/Makefile b/arch/arm/mach-zte/Makefile
new file mode 100644
index 000000000000..1bfe4fddd6af
--- /dev/null
+++ b/arch/arm/mach-zte/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_SOC_ZX297520V3) += zx297520v3.o
diff --git a/arch/arm/mach-zte/zx297520v3.c b/arch/arm/mach-zte/zx297520v3.c
new file mode 100644
index 000000000000..06f71348459e
--- /dev/null
+++ b/arch/arm/mach-zte/zx297520v3.c
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2026 Stefan Dösinger
+ */
+
+#include <asm/mach/arch.h>
+#include <linux/init.h>
+
+static const char *const zx297520v3_dt_compat[] __initconst = {
+ "zte,zx297520v3",
+ NULL,
+};
+
+DT_MACHINE_START(ZX, "ZTE zx297520v3 (Device Tree)")
+ .dt_compat = zx297520v3_dt_compat,
+MACHINE_END
--
2.53.0
^ permalink raw reply related
* [PATCH v8 1/6] dt-bindings: arm: zte: Add D-Link DWR932M board based on zx297520v3 SoC
From: Stefan Dösinger @ 2026-05-06 19:33 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial, Stefan Dösinger, Krzysztof Kozlowski
In-Reply-To: <20260506-send-v8-0-f1bdf3243b34@gmail.com>
This adds a new binding file for ZTE, containing their zx297520v3 SoC
and one board (D-Link DWR-932M) based on it.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Changelog:
v6:
Removed extra boards, I'll add them when submitting their individual
DTS files. Rephrase the subject to add "zte" and remove the redundant
use of "binding".
Moved the devicetree bindings patch ahead of the implementation patches.
Moved the MAINTAINERS section from "ZX29" to "ARM/ZTE".
---
Documentation/devicetree/bindings/arm/zte.yaml | 26 ++++++++++++++++++++++++++
MAINTAINERS | 4 ++++
2 files changed, 30 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/zte.yaml b/Documentation/devicetree/bindings/arm/zte.yaml
new file mode 100644
index 000000000000..f028d2cec7ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/zte.yaml
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/zte.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ZTE zx platforms
+
+maintainers:
+ - Stefan Dösinger <stefandoesinger@gmail.com>
+
+description: |
+ ARM platforms using SoCs designed by ZTE. Currently this supports devices
+ based on the zx297520v3 SoC which is found in LTE routers.
+
+properties:
+ $nodename:
+ const: "/"
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - dlink,dwr932m
+ - const: zte,zx297520v3
+
+additionalProperties: true
diff --git a/MAINTAINERS b/MAINTAINERS
index d1cc0e12fe1f..b768b9da37a4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3772,6 +3772,10 @@ F: drivers/video/fbdev/vt8500lcdfb.*
F: drivers/video/fbdev/wm8505fb*
F: drivers/video/fbdev/wmt_ge_rops.*
+ARM/ZTE ZX29 SOC SUPPORT
+M: Stefan Dösinger <stefandoesinger@gmail.com>
+F: Documentation/devicetree/bindings/arm/zte.yaml
+
ARM/ZYNQ ARCHITECTURE
M: Michal Simek <michal.simek@amd.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
--
2.53.0
^ permalink raw reply related
* [PATCH v8 0/6] Add support for ZTE zx297520v3
From: Stefan Dösinger @ 2026-05-06 19:33 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial, Stefan Dösinger, Krzysztof Kozlowski
Hi,
This is a follow-up on my RFC patches from January [0] for ZTE's
zx297520v3 chipset. This chipset is popular in cheap LTE-to-wifi routers
sold in developing countries. My goal is to run OpenWRT on them. I made
more progress in more work on this SoC and it is time to get serious
about code review and upstreaming.
Since my version in January I managed to get more hardware running: SPI,
I2C, PMIC with real time clock and voltage regulators, Watchdog. LTE is
not working yet, but I am able to start the coprocessor that handles it
and talk to it via mailbox + shared memory. Wifi is working on a few
more devices. Since WiFi, USB and Ethernet are working, the devices can
have actual use with OpenWRT even without LTE.
Another hacker created a free software program to talk to the USB loader
[1] and boot U-Boot and Linux without modifying the on disk files. At
the moment it needs a proprietary blob, so my documentation is
emphasising booting with the on-device U-Boot.
This patchset here is mostly unmodified from the version I sent in
January. It is the bare minimum to get an interactive shell working on
the UART. Future patches can be found on my git repository [2] for those
curious to peek ahead. The first 30 patches are in reasonable shape, but
the further you go the more cleanup is necessary. I expect all of the
patches go require a few rounds of feedback though.
My plan for upstreaming is largly this:
1) This bare minimum boot patchset
2) Add clock and pinctrl drivers
3) Add standard hardware to the device tree
4) Add zx29 specific drivers one by one: Watchdog, spi, i2c, DMA, PMIC,
battery
5) SDIO backend for rtl8xxxu
6) rproc, mailbox and rpmsg
I am willing to maintain support for the SoC within reason. My patches
add myself as maintainer. This is a hobby project for me though, keep
that in mind if you want to ship a commercial product with these SoCs
and upstreaming Linux.
Cheers,
Stefan
0: https://lists.infradead.org/pipermail/linux-arm-kernel/2026-January/1099306.html
1: https://github.com/zx297520v3-mainline/zx297520v3-loader
2: https://gitlab.com/stefandoesinger/zx297520-kernel/
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Changes in v8: A number of Sashiko suggestions:
Add new documentation files to the documentation index
Add new documentation directory to MAINTAINERS
Remove a redundant "if ARCH_ZTE"
Set ARM_PSCI_FW because ARM_GIC_V3 needs it
Use the correct UART01x_FR_BUSY flag in lldebug asm
Remove an accidentally duplicated label from the DTSI file, properly use
"arm,pl011", "arm,primecell" for all UARTs
Remove BINFMT_FLAT from defconfig. I have no idea how that got enabled.
Point to a sane (but not yet upstream) U-Boot that sets up the GIC
correctly for this board. Improve the provided example GIC setup code to
detect this for reusing one binary for both boot chains.
Changes in v7:
Fix line order in mach-zte/Kconfig
Use "zx297520v3 SoC" as the option name for CONFIG_SOC_ZX297520V3
Changes in v6:
Squashed DT commits into one
Removed for-now unused board DT bindings
Add "zte" to DT patch subject
Regenerate the defconfig with make savedefconfig
- Link to v5: https://lore.kernel.org/r/20260421-send-v5-0-ace038e63515@gmail.com
v5:
Spelling fixes
Renamed dlink-dwr-932m.dts to zx297520v3-dlink-dwr932m.dts
DT binding indentation fixes
Use a manufacturer 0x8b for the UART, fix patch prefix
Declare all UARTs, remove uart aliases for now
Consistent license declarations. I made every new file except the DT
binding GPL-2.0-only but I don't particularly mind GPL-2.0-or-later
either.
- Link to v4: https://lore.kernel.org/r/20260416-send-v4-0-e19d02b944ec@gmail.com
v4: rename zx29.yaml to zte.yaml and add board enums
v3: Remove [RFC] tag, add defconfig
v2: checkpatch.pl fixes
---
Stefan Dösinger (6):
dt-bindings: arm: zte: Add D-Link DWR932M board based on zx297520v3 SoC
ARM: zte: Add zx297520v3 platform support
ARM: zte: Add support for zx29 low level debug
amba/serial: amba-pl011: Bring back zx29 UART support
ARM: dts: zte: Add D-Link DWR-932M support
ARM: zte: defconfig: Add a zx29 defconfig file
Documentation/arch/arm/index.rst | 2 +
Documentation/arch/arm/zte/index.rst | 10 ++
Documentation/arch/arm/zte/zx297520v3.rst | 167 +++++++++++++++++++++
Documentation/devicetree/bindings/arm/zte.yaml | 26 ++++
MAINTAINERS | 8 +
arch/arm/Kconfig | 2 +
arch/arm/Kconfig.debug | 12 ++
arch/arm/Makefile | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/zte/Makefile | 3 +
arch/arm/boot/dts/zte/zx297520v3-dlink-dwr932m.dts | 22 +++
arch/arm/boot/dts/zte/zx297520v3.dtsi | 103 +++++++++++++
arch/arm/configs/zx29_defconfig | 53 +++++++
arch/arm/include/debug/pl01x.S | 9 ++
arch/arm/mach-zte/Kconfig | 29 ++++
arch/arm/mach-zte/Makefile | 2 +
arch/arm/mach-zte/zx297520v3.c | 16 ++
drivers/tty/serial/amba-pl011.c | 42 ++++++
18 files changed, 508 insertions(+)
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260416-send-5c08e095e5c9
Best regards,
--
Stefan Dösinger <stefandoesinger@gmail.com>
^ permalink raw reply
* Re: [PATCH v17 11/11] Documentation: cxl: Document CXL protocol error handling
From: Dave Jiang @ 2026-05-06 18:34 UTC (permalink / raw)
To: Terry Bowman, dave, jic23, alison.schofield, djbw, bhelgaas,
shiju.jose, ming.li, Smita.KoralahalliChannabasappa, rrichter,
dan.carpenter, PradeepVineshReddy.Kodamati, lukas,
Benjamin.Cheatham, sathyanarayanan.kuppuswamy, vishal.l.verma,
alucerop, ira.weiny, corbet, rafael, xueshuai, linux-cxl
Cc: linux-kernel, linux-pci, linux-acpi, linux-doc
In-Reply-To: <20260505173029.2718246-12-terry.bowman@amd.com>
On 5/5/26 10:30 AM, Terry Bowman wrote:
> Add Documentation/driver-api/cxl/linux/protocol-error-handling.rst
> describing the end-to-end CXL protocol error path: AER ingress, the
> AER-CXL kfifo handoff, the cxl_core consumer worker, RCD/RCH special
> cases, severity policy, trace events, and a source code map.
>
> This documents the architecture introduced by the preceding patches in
> this series.
>
> This was generated by claude-opus-4.7.
>
> Assisted-by: Claude:claude-opus-4.7
> Signed-off-by: Terry Bowman <terry.bowman@amd.com>
> ---
> Documentation/driver-api/cxl/index.rst | 1 +
> .../cxl/linux/protocol-error-handling.rst | 440 ++++++++++++++++++
> 2 files changed, 441 insertions(+)
> create mode 100644 Documentation/driver-api/cxl/linux/protocol-error-handling.rst
>
> diff --git a/Documentation/driver-api/cxl/index.rst b/Documentation/driver-api/cxl/index.rst
> index 3dfae1d310ca..6861b2e5726a 100644
> --- a/Documentation/driver-api/cxl/index.rst
> +++ b/Documentation/driver-api/cxl/index.rst
> @@ -42,6 +42,7 @@ that have impacts on each other. The docs here break up configurations steps.
> linux/dax-driver
> linux/memory-hotplug
> linux/access-coordinates
> + linux/protocol-error-handling
>
> .. toctree::
> :maxdepth: 2
> diff --git a/Documentation/driver-api/cxl/linux/protocol-error-handling.rst b/Documentation/driver-api/cxl/linux/protocol-error-handling.rst
> new file mode 100644
> index 000000000000..4d6f33f0ed31
> --- /dev/null
> +++ b/Documentation/driver-api/cxl/linux/protocol-error-handling.rst
> @@ -0,0 +1,440 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +==============================
> +CXL Protocol Error Handling
> +==============================
> +
> +This document describes how the kernel detects, classifies, dispatches,
> +logs, and recovers from CXL protocol errors signaled through the PCIe
> +Advanced Error Reporting (AER) interface. It covers both Virtual
> +Hierarchy (VH) topologies (Root Ports, Upstream/Downstream Switch
> +Ports, and Endpoints) and Restricted CXL Host (RCH) topologies
> +(Root Complex Event Collectors driving Restricted CXL Devices).
> +
> +It is intended for kernel developers maintaining or extending
> +``drivers/pci/pcie/aer*.c``, ``drivers/cxl/core/ras.c``, and the
> +related plumbing in ``include/linux/aer.h``.
> +
> +
> +Background
> +==========
> +
> +A CXL device reports protocol-layer failures (CXL.cachemem RAS) as
> +PCIe AER **Internal Errors**: ``PCI_ERR_COR_INTERNAL`` for correctable
> +events and ``PCI_ERR_UNC_INTN`` for uncorrectable events. From the AER
> +core's point of view these look like ordinary PCIe AER messages, but
> +their semantics are CXL-specific: the actual fault information lives
> +in CXL RAS capability registers, not in the PCIe AER status registers.
> +
> +Historically, native CXL.cachemem RAS handling was implemented only
> +for CXL Endpoints and for RCH Downstream Ports. CXL Root Ports,
> +Upstream Switch Ports, and Downstream Switch Ports were not covered.
> +This left the kernel unable to log or react to protocol errors
> +signaled by switch components.
> +
> +The unified CXL protocol error path closes that gap by routing every
> +CXL Internal Error through a single producer/consumer pipeline shared
> +by all CXL device types.
> +
> +
> +Architecture overview
> +=====================
> +
> +CXL protocol error handling is implemented as a distinct error plane
> +layered on top of the existing PCIe AER infrastructure. The two planes
> +are kept separate:
> +
> +* The **PCIe AER plane** continues to handle native PCIe errors
> + (Receiver overflows, malformed TLPs, completion timeouts, and so
> + on). This is unchanged.
> +
> +* The **CXL protocol error plane** owns CXL Internal Errors. The AER
> + core forwards them to ``cxl_core`` via a dedicated kfifo; ``cxl_core``
> + then dispatches to CE/UE handlers and drives the recovery and
> + panic policy.
> +
> +The boundary between the two planes is ``is_cxl_error()`` in
> +``drivers/pci/pcie/aer_cxl_vh.c``, which inspects ``info->is_cxl``
> +(set from ``pcie_is_cxl()``) together with the PCIe device type and
> +the AER status word. When ``is_cxl_error()`` returns true the event
> +is enqueued into the AER-CXL kfifo; otherwise the event flows through
> +``pci_aer_handle_error()`` as before.
> +
> +The pipeline has three layers:
> +
> +1. **Producer** (``aer_cxl_vh.c``, ``aer_cxl_rch.c``) - runs in AER
> + IRQ/threaded context, classifies, clears the AER CE status, and
> + enqueues ``struct cxl_proto_err_work_data``.
> +2. **Queue** - the AER-CXL kfifo plus a backing ``struct work_struct``.
> +3. **Consumer** (``cxl_core/ras.c``) - workqueue-context worker that
> + resolves the CXL Port topology and dispatches to CE/UE handlers.
> +
> +
> +Topologies
> +==========
> +
> +Two topologies are supported, and both feed the same kfifo.
> +
> +Virtual Hierarchy (VH)
> +----------------------
> +
> +A standard CXL VH consists of a CXL Root Port (RP), an optional CXL
> +Upstream Switch Port (USP), one or more CXL Downstream Switch Ports
I think it's clearer if you say "an optional CXL Upstream Switch Port (USP)
with one or more CXL Downstream Switch Ports (DSP)" to indicate that this is
a wholly contained component. Otherwise it reads that only the USP is
optional.
DJ
> +(DSPs), and CXL Endpoints (EPs) attached to the DSPs. Each component
> +is a regular PCIe device with a CXL DVSEC and a CXL RAS capability,
> +and it raises Internal Errors directly to the AER subsystem via the
> +RP's MSI/MSI-X interrupt.
> +
> +The VH producer is ``cxl_forward_error()`` in
> +``drivers/pci/pcie/aer_cxl_vh.c``.
> +
> +Restricted CXL Host (RCH)
> +-------------------------
> +
> +In the RCH topology, a Root Complex Event Collector (RCEC) aggregates
> +errors from one or more Restricted CXL Devices (RCDs) attached as
> +Root Complex Integrated Endpoints. The RCEC delivers the AER
> +interrupt; the AER driver iterates the RCDs beneath it.
> +
> +The RCH producer is ``cxl_rch_handle_error_iter()`` in
> +``drivers/pci/pcie/aer_cxl_rch.c``. For each RCD it finds, it calls
> +``cxl_forward_error()`` (the same producer helper used by the VH
> +path), so RCH events end up in the same AER-CXL kfifo as VH events.
> +
> +
> +End-to-end flow
> +===============
> +
> +The diagram below shows the full path from an AER interrupt through
> +producer classification, kfifo handoff, and consumer dispatch.
> +
> +.. code-block:: text
> +
> + +-------------------------------------------------------------------------+
> + | CXL Internal Error Packet Flow |
> + | From PCIe AER Interrupt to CXL Protocol Error Handling and Logging |
> + +-------------------------------------------------------------------------+
> +
> + CXL device (RP / USP / DSP / EP / RCD) raises AER Internal Error
> + (correctable PCI_ERR_COR_INTERNAL or uncorrectable PCI_ERR_UNC_INTN)
> + |
> + v
> + +-------------------------------------------------------------+
> + | PCIe Root Port AER MSI/MSI-X interrupt fires |
> + +-------------------------------------------------------------+
> + |
> + ============= drivers/pci/pcie/aer.c (AER core) =============
> + |
> + v
> + +---------------------------------+
> + | aer_irq() / aer_isr() | (top + threaded handler)
> + +---------------------------------+
> + |
> + v
> + +---------------------------------+
> + | aer_isr_one_error() |
> + | aer_isr_one_error_type() |
> + +---------------------------------+
> + |
> + v
> + +------------------------------------------+
> + | aer_get_device_error_info() |
> + | - reads PCI_ERR_COR_STATUS |
> + | - reads PCI_ERR_UNCOR_STATUS (*if RP/ |
> + | RCEC/DSP, or non-fatal severity) |
> + | - sets info->is_cxl = pcie_is_cxl(dev) |
> + +------------------------------------------+
> + |
> + v
> + +---------------------------------+
> + | handle_error_source(dev, info) |
> + +---------------------------------+
> + | |
> + | is_cxl_error() +---> pci_aer_handle_error()
> + | (CXL device + Internal) (native PCIe AER path,
> + v not covered here)
> + +-------------------------------------------------------------+
> + | Topology dispatch within AER core: |
> + | |
> + | - VH topology (RP / USP / DSP / EP) |
> + | -> drivers/pci/pcie/aer_cxl_vh.c |
> + | |
> + | - RCH topology (RCEC iterates RCDs under it) |
> + | -> drivers/pci/pcie/aer_cxl_rch.c |
> + +-------------------------------------------------------------+
> + | |
> + | VH path RCH path (RCEC AER)
> + v v
> + ============= aer_cxl_vh.c (VH ============= aer_cxl_rch.c (RCH
> + producer) ============= producer) ==========
> + | |
> + v v
> + +-----------------------------+ +-------------------------------+
> + | cxl_forward_error(pdev,info)| | cxl_rch_handle_error_iter() |
> + | - if AER_CORRECTABLE: | | - iterate each RCD pdev |
> + | clear PCI_ERR_COR_STATUS| | beneath the RCEC |
> + | - pci_dev_get(pdev) | | - call cxl_forward_error() |
> + | - build cxl_proto_err_ | | for each RCD |
> + | work_data | | (same producer helper as |
> + | { pdev, severity } | | the VH path uses) |
> + | - kfifo_in_spinlocked(...) | +-------------------------------+
> + | - schedule_work(...) | |
> + +-----------------------------+ |
> + | |
> + +-----------------+---------------------------+
> + |
> + v
> + +--------------------------+
> + | AER-CXL kfifo |
> + | (work_struct) |
> + +--------------------------+
> + |
> + v
> + ============= drivers/cxl/core/ras.c (consumer worker) =======
> + |
> + v
> + +-------------------------------------------------------------+
> + | cxl_proto_err_work_fn() (workqueue handler) |
> + | for_each_cxl_proto_err(&wd, __cxl_proto_err_work_fn) |
> + +-------------------------------------------------------------+
> + |
> + v
> + +-------------------------------------------------------------+
> + | __cxl_proto_err_work_fn(wd) |
> + | port = find_cxl_port_by_dev(&pdev->dev, &dport) |
> + | cxl_handle_proto_error(pdev, port, dport, severity) |
> + | pci_dev_put(pdev) |
> + +-------------------------------------------------------------+
> + |
> + v
> + +-------------------------------------------------------------+
> + | cxl_handle_proto_error() |
> + +-------------------------------------------------------------+
> + | |
> + pci_pcie_type == pci_pcie_type !=
> + PCI_EXP_TYPE_RC_END PCI_EXP_TYPE_RC_END
> + (RCD Endpoint) (VH: RP/USP/DSP/EP)
> + | |
> + v |
> + +-------------------------------------+ |
> + | cxl_handle_rdport_errors(pdev) | |
> + | - process RCH Downstream Port's | |
> + | RAS register block first | |
> + | - cxl_handle_cor_ras() for CE | |
> + | - cxl_handle_ras() for UE | |
> + | (log only; does NOT panic) | |
> + +-------------------------------------+ |
> + | |
> + +--------------------+-----------------------+
> + |
> + v
> + +-----------------------------+
> + | severity == AER_CORRECTABLE |
> + +-----------------------------+
> + | |
> + yes no
> + v v
> + +----------------------+ +-------------------------+
> + | cxl_handle_cor_ras() | | cxl_do_recovery() |
> + | - emit cxl_aer_ | | (described below) |
> + | correctable_ | +-------------------------+
> + | error trace |
> + | pcie_clear_device_ |
> + | status() |
> + +----------------------+
> +
> + +-------------------------------+
> + | cxl_do_recovery() |
> + | if pci_dev_is_disconnected: |
> + | panic("CXL cachemem err.") |
> + | |
> + | ue = cxl_handle_ras() |
> + | -> emit |
> + | cxl_aer_uncorrectable_ |
> + | error trace event |
> + | |
> + | if (ue): |
> + | panic("CXL cachemem err.") |
> + | |
> + | pcie_clear_device_status() |
> + | pci_aer_clear_nonfatal_status|
> + | pci_aer_clear_fatal_status |
> + +-------------------------------+
> +
> +
> +Severity policy
> +===============
> +
> +The kernel's response to a CXL protocol error depends on the AER
> +severity reported by the device and on the result of inspecting the
> +CXL RAS registers.
> +
> +Correctable Error (CE)
> +----------------------
> +
> +* The AER driver clears ``PCI_ERR_COR_STATUS`` in the producer
> + (``cxl_forward_error()``) before enqueue, so the device is
> + acknowledged even if the consumer drops the event.
> +* The consumer's ``cxl_handle_cor_ras()`` reads and clears the CXL
> + RAS correctable status and emits a ``cxl_aer_correctable_error``
> + trace event.
> +* No recovery action is taken.
> +
> +Uncorrectable Error (UE), non-fatal
> +-----------------------------------
> +
> +* The producer enqueues the event without clearing the AER UCE
> + status.
> +* The consumer enters ``cxl_do_recovery()``.
> +* ``cxl_handle_ras()`` reads the CXL RAS uncorrectable status and
> + emits a ``cxl_aer_uncorrectable_error`` trace event.
> +* If ``cxl_handle_ras()`` returns true (a CXL RAS UE bit was set),
> + the kernel panics with ``"CXL cachemem error."``. CXL.cachemem
> + traffic cannot be safely recovered in software once corruption is
> + observed; continuing risks silent data loss across all devices in
> + an interleaved HDM region.
> +* If ``cxl_handle_ras()`` returns false (no CXL RAS bit set, i.e.
> + the AER UCE was a PCIe-side issue rather than a CXL.cachemem
> + issue), the AER UCE status is cleared and execution continues.
> +
> +Uncorrectable Error (UE), fatal
> +-------------------------------
> +
> +Fatal severity follows the same recovery path as non-fatal in
> +``cxl_do_recovery()``, with one important caveat: the AER core only
> +reads ``PCI_ERR_UNCOR_STATUS`` for Root Ports, RCECs, Downstream
> +Ports, or non-fatal severities (see ``aer_get_device_error_info()``
> +in ``drivers/pci/pcie/aer.c``). For a fatal UE signaled by an
> +upstream component, PCI config reads to the source device are
> +expected to fail, so ``UNCOR_STATUS`` is never retrieved and
> +``info->status`` stays zero.
> +
> +The practical consequence: a fatal UE on an Upstream Switch Port or
> +Endpoint is **not** classified as a CXL error by ``is_cxl_error()``.
> +It falls through to ``pci_aer_handle_error()`` and is processed by
> +the standard AER recovery flow. Only the CXL trace events emitted by
> +the AER core (``aer_event``) appear; the CXL-specific
> +``cxl_aer_uncorrectable_error`` event is not emitted on this path.
> +
> +Disconnect during recovery
> +--------------------------
> +
> +``cxl_do_recovery()`` checks ``pci_dev_is_disconnected(pdev)`` before
> +touching the RAS registers. A device disconnecting during an
> +uncorrectable error event is itself unrecoverable, particularly when
> +the device backs an interleaved HDM region; in that case the kernel
> +panics directly rather than returning ``~0u`` from the readl() and
> +masking the cause.
> +
> +
> +RCD/RCH special cases
> +=====================
> +
> +RCD Endpoint flow
> +-----------------
> +
> +When ``cxl_handle_proto_error()`` sees ``pci_pcie_type(pdev) ==
> +PCI_EXP_TYPE_RC_END`` (i.e. an RCD Endpoint), it calls
> +``cxl_handle_rdport_errors()`` first. This processes the RAS state
> +of the RCH Downstream Port that hosts the RCD before falling through
> +to the common CE/UE dispatch on the RCD Endpoint itself.
> +
> +The RCH Downstream Port's RAS UE is **logged only**: it emits the
> +trace event but does not panic. The panic decision is taken on the
> +RCD Endpoint's own RAS in ``cxl_do_recovery()``.
> +
> +This split mirrors the structure of an RCH topology: the RCH dport
> +is functionally a CXL infrastructure component (similar to a switch
> +port), while the RCD itself is the actual CXL.cachemem source whose
> +corruption drives the recovery decision.
> +
> +RCH ingress aggregation
> +-----------------------
> +
> +RCH errors do not arrive on a per-RCD interrupt. The RCEC is the AER
> +source, and the AER driver drives ``cxl_rch_handle_error_iter()`` to
> +walk each RCD beneath it and forward an event per RCD through the
> +shared kfifo. From the consumer's point of view, RCH-originated
> +events are indistinguishable from VH events.
> +
> +
> +Trace events
> +============
> +
> +Two unified trace events are emitted from ``cxl_handle_cor_ras()``
> +and ``cxl_handle_ras()`` and are used by every CXL device type and
> +both topologies:
> +
> +* ``cxl_aer_correctable_error`` - emitted when a CXL RAS CE bit is
> + set; carries the human-readable status string.
> +* ``cxl_aer_uncorrectable_error`` - emitted when a CXL RAS UE bit is
> + set; carries both the current status and the first-error pointer.
> +
> +Common fields:
> +
> +* ``device=<PCI BDF>`` - the source device (always a PCI BDF, even
> + for RCH paths where the trace was historically a memdev name).
> +* ``host=<bridge>`` - the parent host bridge or PCI host BDF.
> +* ``serial=<u64>`` - the device serial from ``pci_get_dsn()``.
> +
> +The ``device`` field replaces the older ``memdev`` field that earlier
> +revisions emitted on Endpoint events. Userspace consumers
> +(rasdaemon's ``ras-cxl-handler.c``) need a corresponding update to
> +read the new field name.
> +
> +
> +Source code map
> +===============
> +
> +============================================ ==============================
> +File Role
> +============================================ ==============================
> +``drivers/pci/pcie/aer.c`` AER core; receives the IRQ,
> + builds ``aer_err_info``,
> + dispatches to either the CXL
> + path (``is_cxl_error()``) or
> + ``pci_aer_handle_error()``.
> +``drivers/pci/pcie/aer_cxl_vh.c`` VH producer; provides
> + ``is_cxl_error()``,
> + ``cxl_forward_error()``, the
> + AER-CXL kfifo, and the
> + consumer registration
> + helpers.
> +``drivers/pci/pcie/aer_cxl_rch.c`` RCH producer; iterates RCDs
> + under an RCEC and forwards
> + each via
> + ``cxl_forward_error()``.
> +``drivers/cxl/core/ras.c`` Consumer; defines
> + ``cxl_proto_err_work_fn()``,
> + ``cxl_handle_proto_error()``,
> + ``cxl_handle_rdport_errors()``,
> + ``cxl_do_recovery()``,
> + ``cxl_handle_cor_ras()`` and
> + ``cxl_handle_ras()``.
> +``include/linux/aer.h`` Public declarations:
> + ``struct cxl_proto_err_work_data``,
> + ``cxl_proto_err_fn_t``,
> + ``cxl_register_proto_err_work()``
> + and ``for_each_cxl_proto_err()``.
> +============================================ ==============================
> +
> +
> +Limitations and future work
> +===========================
> +
> +* **USP/EP fatal UCE is not classified as CXL.** As described under
> + `Severity policy`_, the AER core never retrieves
> + ``PCI_ERR_UNCOR_STATUS`` in this scenario, so ``is_cxl_error()``
> + cannot tag the event as CXL. The event is handled by the AER path
> + only. Resolving this requires either an AER-core change to attempt
> + a config read with link-validity gating, or a separate CXL-side
> + notification mechanism for upstream-signaled fatal events.
> +* **User-defined status masks** are not yet supported. All CE and UE
> + status bits are reported as they appear in the RAS register.
> +* **Port traversing in cxl_do_recovery()** is not yet implemented; a
> + CXL UE today is reported and acted on at the source device only,
> + not propagated to ancestor ports.
> +* The RCH producer (``aer_cxl_rch.c``) currently lives under
> + ``drivers/pci/pcie/`` for historical reasons. Moving it to
> + ``drivers/cxl/core/ras_rch.c`` is on the roadmap.
> +
^ permalink raw reply
* Re: [PATCH v17 10/11] PCI/CXL: Mask/Unmask CXL protocol errors
From: Dave Jiang @ 2026-05-06 18:00 UTC (permalink / raw)
To: Terry Bowman, dave, jic23, alison.schofield, djbw, bhelgaas,
shiju.jose, ming.li, Smita.KoralahalliChannabasappa, rrichter,
dan.carpenter, PradeepVineshReddy.Kodamati, lukas,
Benjamin.Cheatham, sathyanarayanan.kuppuswamy, vishal.l.verma,
alucerop, ira.weiny, corbet, rafael, xueshuai, linux-cxl
Cc: linux-kernel, linux-pci, linux-acpi, linux-doc
In-Reply-To: <20260505173029.2718246-11-terry.bowman@amd.com>
On 5/5/26 10:30 AM, Terry Bowman wrote:
> CXL protocol errors are not enabled for all CXL devices after boot. They
> must be enabled in order to process CXL protocol errors. Provide matching
> teardown helpers so the masks are restored when a CXL Port or Downstream
> Port goes away.
>
> Add pci_aer_mask_internal_errors() as the symmetric counterpart to
> pci_aer_unmask_internal_errors() and export both for the cxl_core module.
>
> Introduce cxl_unmask_proto_interrupts() and cxl_mask_proto_interrupts()
> in cxl_core to wrap the PCI helpers with the dev_is_pci() and
> pcie_aer_is_native() gating CXL needs. Both helpers tolerate a NULL
> @dev so teardown callers do not have to special-case it.
>
> Wire cxl_unmask_proto_interrupts() into the success path of
> cxl_dport_map_ras() and devm_cxl_port_ras_setup() so the unmask only
> runs when the RAS register block was actually mapped. Pair each unmask
> with a devm_add_action_or_reset() registration of
> cxl_mask_proto_interrupts() scoped to the cxl_port device. The mask is
> then restored when the cxl_port device releases its devres. This
> applies to Endpoints, Upstream Switch Ports, Downstream Switch Ports,
> and Root Ports.
>
> Co-developed-by: Dan Williams <djbw@kernel.org>
> Signed-off-by: Dan Williams <djbw@kernel.org>
> Signed-off-by: Terry Bowman <terry.bowman@amd.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
I do wonder if we should save the original mask values and write those back rather than blindly remask everything when we are done.
>
> ---
>
> Changes in v16->v17:
> - Drop redundant cxl_mask_proto_interrupts() calls from unregister_port()
> and cxl_dport_remove(); the devres action registered alongside the unmask
> is the sole mask path.
> - Update title
> - Remove unnecessary check for aer_capabilities
> - Gate cxl_unmask_proto_interrupts() on pcie_aer_is_native()
> - Add pci_aer_mask_internal_errors() and cxl_mask_proto_interrupts()
> - Only unmask on successful cxl_map_component_regs()
> - NULL-check @dev in cxl_{un,}mask_proto_interrupts()
> - Drop static and declare in core/core.h
>
> Change in v15 -> v16:
> - None
>
> Change in v14 -> v15:
> - None
>
> Changes in v13->v14:
> - Update commit title's prefix (Bjorn)
>
> Changes in v12->v13:
> - Add dev and dev_is_pci() NULL checks in cxl_unmask_proto_interrupts() (Terry)
> - Add Dave Jiang's and Ben's review-by
>
> Changes in v11->v12:
> - None
> ---
> drivers/cxl/core/core.h | 4 +++
> drivers/cxl/core/ras.c | 63 ++++++++++++++++++++++++++++++++++++++---
> drivers/pci/pcie/aer.c | 25 ++++++++++++++++
> include/linux/aer.h | 2 ++
> 4 files changed, 90 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cxl/core/core.h b/drivers/cxl/core/core.h
> index 2c7387506dfb..ff39985d363f 100644
> --- a/drivers/cxl/core/core.h
> +++ b/drivers/cxl/core/core.h
> @@ -190,6 +190,8 @@ void cxl_dport_map_rch_aer(struct cxl_dport *dport);
> void cxl_disable_rch_root_ints(struct cxl_dport *dport);
> void cxl_handle_rdport_errors(struct pci_dev *pdev);
> void devm_cxl_dport_ras_setup(struct cxl_dport *dport);
> +void cxl_unmask_proto_interrupts(struct device *dev);
> +void cxl_mask_proto_interrupts(struct device *dev);
> #else
> static inline int cxl_ras_init(void)
> {
> @@ -207,6 +209,8 @@ static inline void cxl_dport_map_rch_aer(struct cxl_dport *dport) { }
> static inline void cxl_disable_rch_root_ints(struct cxl_dport *dport) { }
> static inline void cxl_handle_rdport_errors(struct pci_dev *pdev) { }
> static inline void devm_cxl_dport_ras_setup(struct cxl_dport *dport) { }
> +static inline void cxl_unmask_proto_interrupts(struct device *dev) { }
> +static inline void cxl_mask_proto_interrupts(struct device *dev) { }
> #endif /* CONFIG_CXL_RAS */
>
> int cxl_gpf_port_setup(struct cxl_dport *dport);
> diff --git a/drivers/cxl/core/ras.c b/drivers/cxl/core/ras.c
> index a98ce0f412ad..b45e2b539b5f 100644
> --- a/drivers/cxl/core/ras.c
> +++ b/drivers/cxl/core/ras.c
> @@ -66,16 +66,59 @@ static void cxl_cper_prot_err_work_fn(struct work_struct *work)
> }
> static DECLARE_WORK(cxl_cper_prot_err_work, cxl_cper_prot_err_work_fn);
>
> +void cxl_unmask_proto_interrupts(struct device *dev)
> +{
> + struct pci_dev *pdev;
> +
> + if (!dev || !dev_is_pci(dev))
> + return;
> +
> + pdev = to_pci_dev(dev);
> + if (!pcie_aer_is_native(pdev))
> + return;
> +
> + pci_aer_unmask_internal_errors(pdev);
> +}
> +
> +void cxl_mask_proto_interrupts(struct device *dev)
> +{
> + struct pci_dev *pdev;
> +
> + if (!dev || !dev_is_pci(dev))
> + return;
> +
> + pdev = to_pci_dev(dev);
> + if (!pcie_aer_is_native(pdev))
> + return;
> +
> + pci_aer_mask_internal_errors(pdev);
> +}
> +
> +static void cxl_mask_proto_irqs(void *dev)
> +{
> + cxl_mask_proto_interrupts(dev);
> +}
> +
> static void cxl_dport_map_ras(struct cxl_dport *dport)
> {
> struct cxl_register_map *map = &dport->reg_map;
> struct device *dev = dport->dport_dev;
>
> - if (!map->component_map.ras.valid)
> + if (!map->component_map.ras.valid) {
> dev_dbg(dev, "RAS registers not found\n");
> - else if (cxl_map_component_regs(map, &dport->regs.component,
> - BIT(CXL_CM_CAP_CAP_ID_RAS)))
> + return;
> + }
> +
> + if (cxl_map_component_regs(map, &dport->regs.component,
> + BIT(CXL_CM_CAP_CAP_ID_RAS))) {
> dev_dbg(dev, "Failed to map RAS capability.\n");
> + return;
> + }
> +
> + cxl_unmask_proto_interrupts(dev);
> + if (devm_add_action_or_reset(dport_to_host(dport),
> + cxl_mask_proto_irqs, dev))
> + dev_warn(dev, "failed to register CXL proto-irq mask cleanup\n");
> }
>
> /**
> @@ -109,6 +152,7 @@ EXPORT_SYMBOL_NS_GPL(devm_cxl_dport_rch_ras_setup, "CXL");
> void devm_cxl_port_ras_setup(struct cxl_port *port)
> {
> struct cxl_register_map *map = &port->reg_map;
> + struct device *dev;
>
> if (!map->component_map.ras.valid) {
> dev_dbg(&port->dev, "RAS registers not found\n");
> @@ -117,8 +161,19 @@ void devm_cxl_port_ras_setup(struct cxl_port *port)
>
> map->host = &port->dev;
> if (cxl_map_component_regs(map, &port->regs,
> - BIT(CXL_CM_CAP_CAP_ID_RAS)))
> + BIT(CXL_CM_CAP_CAP_ID_RAS))) {
> dev_dbg(&port->dev, "Failed to map RAS capability\n");
> + return;
> + }
> +
> + dev = is_cxl_endpoint(port) ? port->uport_dev->parent : port->uport_dev;
> + if (!dev_is_pci(dev))
> + return;
> +
> + cxl_unmask_proto_interrupts(dev);
> + if (devm_add_action_or_reset(&port->dev, cxl_mask_proto_irqs, dev))
> + dev_warn(&port->dev,
> + "Failed to register CXL proto-irq mask cleanup\n");
> }
> EXPORT_SYMBOL_NS_GPL(devm_cxl_port_ras_setup, "CXL");
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index b9c6c7b97217..eaa36fe0eb31 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -1151,6 +1151,31 @@ void pci_aer_unmask_internal_errors(struct pci_dev *dev)
> */
> EXPORT_SYMBOL_FOR_MODULES(pci_aer_unmask_internal_errors, "cxl_core");
>
> +/**
> + * pci_aer_mask_internal_errors - mask internal errors
> + * @dev: pointer to the pci_dev data structure
> + *
> + * Mask internal errors in the Uncorrectable and Correctable Error
> + * Mask registers.
> + *
> + * Note: AER must be enabled and supported by the device which must be
> + * checked in advance, e.g. with pcie_aer_is_native().
> + */
> +void pci_aer_mask_internal_errors(struct pci_dev *dev)
> +{
> + int aer = dev->aer_cap;
> + u32 mask;
> +
> + pci_read_config_dword(dev, aer + PCI_ERR_UNCOR_MASK, &mask);
> + mask |= PCI_ERR_UNC_INTN;
> + pci_write_config_dword(dev, aer + PCI_ERR_UNCOR_MASK, mask);
> +
> + pci_read_config_dword(dev, aer + PCI_ERR_COR_MASK, &mask);
> + mask |= PCI_ERR_COR_INTERNAL;
> + pci_write_config_dword(dev, aer + PCI_ERR_COR_MASK, mask);
> +}
> +EXPORT_SYMBOL_FOR_MODULES(pci_aer_mask_internal_errors, "cxl_core");
> +
> /**
> * pci_aer_handle_error - handle logging error into an event log
> * @dev: pointer to pci_dev data structure of error source device
> diff --git a/include/linux/aer.h b/include/linux/aer.h
> index 979ed2f9fd38..c52db62d4c7e 100644
> --- a/include/linux/aer.h
> +++ b/include/linux/aer.h
> @@ -71,6 +71,7 @@ int pci_aer_clear_nonfatal_status(struct pci_dev *dev);
> void pci_aer_clear_fatal_status(struct pci_dev *dev);
> int pcie_aer_is_native(struct pci_dev *dev);
> void pci_aer_unmask_internal_errors(struct pci_dev *dev);
> +void pci_aer_mask_internal_errors(struct pci_dev *dev);
> #else
> static inline int pci_aer_clear_nonfatal_status(struct pci_dev *dev)
> {
> @@ -79,6 +80,7 @@ static inline int pci_aer_clear_nonfatal_status(struct pci_dev *dev)
> static inline void pci_aer_clear_fatal_status(struct pci_dev *dev) { }
> static inline int pcie_aer_is_native(struct pci_dev *dev) { return 0; }
> static inline void pci_aer_unmask_internal_errors(struct pci_dev *dev) { }
> +static inline void pci_aer_mask_internal_errors(struct pci_dev *dev) { }
> #endif
>
> #ifdef CONFIG_CXL_RAS
^ permalink raw reply
* Re: [PATCH v17 09/11] cxl: Update Endpoint AER uncorrectable handler
From: Dave Jiang @ 2026-05-06 17:43 UTC (permalink / raw)
To: Terry Bowman, dave, jic23, alison.schofield, djbw, bhelgaas,
shiju.jose, ming.li, Smita.KoralahalliChannabasappa, rrichter,
dan.carpenter, PradeepVineshReddy.Kodamati, lukas,
Benjamin.Cheatham, sathyanarayanan.kuppuswamy, vishal.l.verma,
alucerop, ira.weiny, corbet, rafael, xueshuai, linux-cxl
Cc: linux-kernel, linux-pci, linux-acpi, linux-doc
In-Reply-To: <20260505173029.2718246-10-terry.bowman@amd.com>
On 5/5/26 10:30 AM, Terry Bowman wrote:
> The CXL cxl_core driver now implements protocol RAS support. PCI
> uncorrectable (UCE) protocol errors, however, continue to be reported via
> the AER capability and must still be handled by a PCI error recovery callback.
> UCE handling is required to provide direction for recovery.
>
> Replace the existing cxl_error_detected() callback in cxl/pci.c with a new
> cxl_pci_error_detected() implementation that handles uncorrectable AER PCI
> protocol errors.
>
> The handler decides solely based on the pci_channel_state_t parameter and
> does not access PCIe AER capability registers from .error_detected, matching
> the pattern used by other drivers including the NVMe and ixgbe drivers.
> CXL.cachemem-corrupting protocol errors are routed separately through the
> AER-CXL kfifo to cxl_handle_proto_error(), so cxl_pci does not need to
> second-guess the AER core's classification.
>
> claude-opus-4.7 was used for research on PCI error state transitions and
> requirements.
>
> Assisted-by: Claude:claude-opus-4.7
> Signed-off-by: Terry Bowman <terry.bowman@amd.com>
>
> ---
>
> Changes in v16->v17:
> - Rename pci_error_handlers struct instance to cxl_pci_error_handlers to
> avoid shadowing the struct type tag.
> - Restore scoped_guard(device) and dev->driver check around AER read.
> - NULL-check find_cxl_port_by_dev() before deref of port->uport_dev.
> - Updated commit message. (Terry)
> - Add scope cleanup for port variable in cxl_pci_error_detected() (Terry)
> - Drop cxl_uncor_aer_present(), rely on AER state
>
> Changes in v15->v16:
> - Update commit message (DaveJ)
> - s/cxl_handle_aer()/cxl_uncor_aer_present()/g (Jonathan)
> - cxl_uncor_aer_present(): Leave original result calculation based on
> if a UCE is present and the provided state (Terry)
> - Add call to pci_print_aer(). AER fails to log because is upstream
> link (Terry)
>
> Changes in v14->v15:
> - Update commit message and title. Added Bjorn's ack.
> - Move CE and UCE handling logic here
>
> Changes in v13->v14:
> - Add Dave Jiang's review-by
> - Update commit message & headline (Bjorn)
> - Refactor cxl_port_error_detected()/cxl_port_cor_error_detected() to
> one line (Jonathan)
> - Remove cxl_walk_port() (Dan)
> - Remove cxl_pci_drv_bound(). Check for 'is_cxl' parent port is
> sufficient (Dan)
> - Remove device_lock_if()
> - Combined CE and UCE here (Terry)
>
> Changes in v12->v13:
> - Move get_pci_cxl_host_dev() and cxl_handle_proto_error() to Dequeue
> patch (Terry)
> - Remove EP case in cxl_get_ras_base(), not used. (Terry)
> - Remove check for dport->dport_dev (Dave)
> - Remove whitespace (Terry)
>
> Changes in v11->v12:
> - Add call to cxl_pci_drv_bound() in cxl_handle_proto_error() and
> pci_to_cxl_dev()
> - Change cxl_error_detected() -> cxl_cor_error_detected()
> - Remove NULL variable assignments
> - Replace bus_find_device() with find_cxl_port_by_uport() for upstream
> port searches.
>
> Changes in v10->v11:
> - None
> ---
> drivers/cxl/core/ras.c | 43 ++++++++++++++++--------------------------
> drivers/cxl/cxlpci.h | 8 ++++----
> drivers/cxl/pci.c | 6 +++---
> 3 files changed, 23 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/cxl/core/ras.c b/drivers/cxl/core/ras.c
> index 5cc4087c2807..a98ce0f412ad 100644
> --- a/drivers/cxl/core/ras.c
> +++ b/drivers/cxl/core/ras.c
> @@ -253,38 +253,27 @@ bool cxl_handle_ras(struct device *dev, u64 serial, void __iomem *ras_base)
> return true;
> }
>
> -pci_ers_result_t cxl_error_detected(struct pci_dev *pdev,
> - pci_channel_state_t state)
> +pci_ers_result_t cxl_pci_error_detected(struct pci_dev *pdev,
> + pci_channel_state_t state)
> {
> - struct cxl_dev_state *cxlds = pci_get_drvdata(pdev);
> - struct cxl_memdev *cxlmd = cxlds->cxlmd;
> - struct device *dev = &cxlmd->dev;
> - bool ue;
> + struct cxl_dport *dport;
> + struct cxl_port *port __free(put_cxl_port) =
> + find_cxl_port_by_dev(&pdev->dev, &dport);
Move this to right before 'port' is being checked. It's ok to do inline var declaration with __free().
DJ
> + struct cxl_memdev *cxlmd;
> + struct device *dev;
>
> - scoped_guard(device, dev) {
> - if (!dev->driver) {
> - dev_warn(&pdev->dev,
> - "%s: memdev disabled, abort error handling\n",
> - dev_name(dev));
> - return PCI_ERS_RESULT_DISCONNECT;
> - }
> + if (!port)
> + return PCI_ERS_RESULT_DISCONNECT;
>
> - /*
> - * A frozen channel indicates an impending reset which is fatal to
> - * CXL.mem operation, and will likely crash the system. On the off
> - * chance the situation is recoverable dump the status of the RAS
> - * capability registers and bounce the active state of the memdev.
> - */
> - ue = cxl_handle_ras(&cxlds->cxlmd->dev, pci_get_dsn(pdev),
> - cxlmd->endpoint->regs.ras);
> - }
> + cxlmd = to_cxl_memdev(port->uport_dev);
> + dev = &cxlmd->dev;
>
> switch (state) {
> case pci_channel_io_normal:
> - if (ue) {
> - device_release_driver(dev);
> - return PCI_ERS_RESULT_NEED_RESET;
> - }
> + /*
> + * Non-fatal CXL protocol errors are handled asynchronously
> + * by the AER-CXL kfifo worker (cxl_proto_err_work_fn).
> + */
> return PCI_ERS_RESULT_CAN_RECOVER;
> case pci_channel_io_frozen:
> dev_warn(&pdev->dev,
> @@ -299,7 +288,7 @@ pci_ers_result_t cxl_error_detected(struct pci_dev *pdev,
> }
> return PCI_ERS_RESULT_NEED_RESET;
> }
> -EXPORT_SYMBOL_NS_GPL(cxl_error_detected, "CXL");
> +EXPORT_SYMBOL_NS_GPL(cxl_pci_error_detected, "CXL");
>
> static void cxl_handle_proto_error(struct pci_dev *pdev, struct cxl_port *port,
> struct cxl_dport *dport, int severity)
> diff --git a/drivers/cxl/cxlpci.h b/drivers/cxl/cxlpci.h
> index 06c46adcf0f6..8aeb80a4e573 100644
> --- a/drivers/cxl/cxlpci.h
> +++ b/drivers/cxl/cxlpci.h
> @@ -89,13 +89,13 @@ struct cxl_dev_state;
> void read_cdat_data(struct cxl_port *port);
>
> #ifdef CONFIG_CXL_RAS
> -pci_ers_result_t cxl_error_detected(struct pci_dev *pdev,
> - pci_channel_state_t state);
> +pci_ers_result_t cxl_pci_error_detected(struct pci_dev *pdev,
> + pci_channel_state_t state);
> void devm_cxl_dport_rch_ras_setup(struct cxl_dport *dport);
> void devm_cxl_port_ras_setup(struct cxl_port *port);
> #else
> -static inline pci_ers_result_t cxl_error_detected(struct pci_dev *pdev,
> - pci_channel_state_t state)
> +static inline pci_ers_result_t cxl_pci_error_detected(struct pci_dev *pdev,
> + pci_channel_state_t state)
> {
> return PCI_ERS_RESULT_NONE;
> }
> diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c
> index 5eb64ced0de5..6459f94f8fa8 100644
> --- a/drivers/cxl/pci.c
> +++ b/drivers/cxl/pci.c
> @@ -1000,8 +1000,8 @@ static void cxl_reset_done(struct pci_dev *pdev)
> }
> }
>
> -static const struct pci_error_handlers cxl_error_handlers = {
> - .error_detected = cxl_error_detected,
> +static const struct pci_error_handlers cxl_pci_error_handlers = {
> + .error_detected = cxl_pci_error_detected,
> .slot_reset = cxl_slot_reset,
> .resume = cxl_error_resume,
> .reset_done = cxl_reset_done,
> @@ -1011,7 +1011,7 @@ static struct pci_driver cxl_pci_driver = {
> .name = KBUILD_MODNAME,
> .id_table = cxl_mem_pci_tbl,
> .probe = cxl_pci_probe,
> - .err_handler = &cxl_error_handlers,
> + .err_handler = &cxl_pci_error_handlers,
> .dev_groups = cxl_rcd_groups,
> .driver = {
> .probe_type = PROBE_PREFER_ASYNCHRONOUS,
^ permalink raw reply
* Re: [PATCH v7 6/6] ARM: zte: defconfig: Add a zx29 defconfig file
From: Stefan Dösinger @ 2026-05-06 17:39 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <CAD++jL=S6DSOuC-PXFn76SA7e-Lgueu9Z2wuF7icXCVX7MBpJw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]
Hi,
Am Dienstag, 5. Mai 2026, 12:54:29 Ostafrikanische Zeit schrieb Linus Walleij:
> On Wed, Apr 29, 2026 at 9:14 PM Stefan Dösinger
> I'm in favor of this, mainly because multi_v7 is pretty useless
> for this board, it is absolutely too big to boot on the machine,
> the board is odd and need some ARM64 stuff.
I added it more out of cluenessness, thought that every board should have a
defconfig and Sashiko let me know that multi_v7 is the preferred. But I like
your reasoning. I'll send a v8 with some of Sashiko's (very impressive)
findings but keep the defconfig.
> Reviewed-by: Linus Walleij <linusw@kernel.org>
Thanks for the reviews as always, and thanks to Krzysztof for the yeoman's
work of guiding noobs over and over again!
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH] docs: fix typos in reporting-issues.rst
From: Felipe Matarazzo @ 2026-05-06 17:36 UTC (permalink / raw)
To: Thorsten Leemhuis; +Cc: Jonathan Corbet, Shuah Khan, linux-doc, linux-kernel
In-Reply-To: <45e18079-ab21-478b-904d-41dc67041f71@leemhuis.info>
Hi Thorsten,
Thanks for the review and the Acked-by!
You're right about the underline — the kernel test robot caught the same issue [1],
so v2 already addresses both the underline length and includes the Reported-by tag.
[1] https://lore.kernel.org/oe-kbuild-all/202605041002.NG14fe8J-lkp@intel.com/
Thanks,
Felipe
^ permalink raw reply
* Re: [RFC net-next 0/4] devlink: Add boot-time defaults
From: Mark Bloch @ 2026-05-06 17:35 UTC (permalink / raw)
To: Jiri Pirko
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller, Jonathan Corbet, Shuah Khan, Simon Horman,
Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Andrew Morton,
Borislav Petkov (AMD), Randy Dunlap, Dave Hansen,
Christian Brauner, Petr Mladek, Peter Zijlstra (Intel),
Thomas Gleixner, Pawan Gupta, Dapeng Mi, Kees Cook, Marco Elver,
Eric Biggers, Li RongQing, Paul E. McKenney, linux-doc,
linux-kernel, netdev, linux-rdma
In-Reply-To: <aftaW-irGmkfA7FS@FV6GYCPJ69>
On 06/05/2026 18:22, Jiri Pirko wrote:
> Wed, May 06, 2026 at 02:37:35PM +0200, mbloch@nvidia.com wrote:
>> This series adds a devlink= kernel command line parameter for applying
>> selected devlink settings during device initialization.
>>
>> Following a discussion with Jakub[1], I am sending this RFC to get the
>> conversation moving. I started from Jakub's example/request and extended
>> it to cover requirements from production systems and configurations that
>> customers use.
>>
>> One important caveat is that the parsing logic in this RFC was written
>> with AI assistance. I am also not sure whether the resulting syntax and
>> parser are too complex for a kernel command line interface. This is part
>> of why I am sending it as an RFC: to understand what direction and level
>> of complexity would be acceptable to people.
>>
>> The implementation is intended to support the following properties:
>>
>> - A system may have multiple devlink devices that usually need the same
>> configuration. For a configuration such as eswitch mode switchdev, a
>> user should be able to specify multiple devices to which that
>> configuration applies.
>>
>> - There may be ordering dependencies between options. For example, in
>> mlx5, flow_steering_mode should be set before moving to switchdev.
>> With this in mind, defaults are applied per device in the left-to-right
>> order in which they appear on the command line.
>>
>> The intent is to let deployments set devlink defaults before normal
>> userspace orchestration runs, while still using devlink concepts and
>
> "defaults before normal userspace orchestrarion". I read it as config
> before config, which eventually could be skipped.
>
>
>> driver callbacks rather than adding driver-specific module parameters.
>> A default is scoped to one or more devlink handles, for example:
>>
>> devlink=[pci/0000:08:00.0]:esw:mode:switchdev
>> devlink=[pci/0000:08:00.0]:param:flow_steering_mode:smfs
>> devlink=[pci/0000:08:00.0,pci/0000:08:00.1]:param:flow_steering_mode:hmfs,[pci/0000:08:00.0,pci/0000:08:00.1]:esw:mode:switchdev
>
> I don't like this. What you do, you are basically introducing user
> configuration tool on kernel cmdline.
>
> The same you would achieve with a proper userspace tool/daemon.
> I did try to come up with it and push it here:
> https://github.com/systemd/systemd/pull/37393
> That didn't get merged for unknown reason, but the idea is sound. You
> provide configuration files for devlink object and systemd-devlinkd
> will apply when they appear. Wouldn't this help your case?
I agree that systemd-devlinkd is the right shape for normal
devlink configuration, and it could probably replace the udev/devlink
plumbing we use today.
The case I am trying to cover is earlier than that.
On BlueField/ECPF/DPU systems, the host PF driver cannot always finish
probing independently of the ECPF side. When the ECPF is the eswitch
manager, the host PF is kept in initializing state until the ECPF eswitch
side is set up and mlx5 enables the external host PF HCA. That happens as
part of moving the ECPF to switchdev.
Today userspace observes the ECPF instance and then switches the
mode through devlink, usually via udev or similar plumbing. That still
leaves a window where the ECPF has probed, userspace has not applied the
mode yet, and the host PF is waiting. With many ECPFs this becomes visible
in host PF probe/boot time. A daemon reacting to the devlink object
appearing can make the userspace side cleaner, but it still runs after the
device has appeared and after userspace scheduling/uevent handling.
Long term, for these DPU deployments, we would like mlx5 to initialize
directly in switchdev. I am hesitant to make that unconditional because it
changes existing behavior and there is no early opt-out before probe. The
cmdline parameter was meant as an explicit opt-in middle step: ask the
driver to apply the same devlink operation during init, before this path
depends on userspace.
We previously tried to address this with an mlx5 module parameter. By
design, that was too coarse: it applied to all mlx5 devices handled by the
module. That makes it usable only for narrow DPU-only configurations. The
devlink-handle based cmdline syntax was intended to keep the opt-in scoped
to the specific devices that need this early switchdev transition.
Mark
>
> [..]
^ permalink raw reply
* Re: [PATCH] Documentation: fix typo and formattting in security/credentials.rst
From: Randy Dunlap @ 2026-05-06 17:31 UTC (permalink / raw)
To: Mayank Gite, Paul Moore
Cc: Serge Hallyn, Jonathan Corbet, Shuah Khan, linux-security-module,
linux-doc, linux-kernel
In-Reply-To: <20260506054914.162806-1-drapl0n@protonmail.com>
Hi--
On 5/5/26 10:49 PM, Mayank Gite wrote:
> - Fixes a typo in "Keys and keyrings" section. Replaces "keying" with
> "keyring".
> - Updates formatting of keyring types.
>
> Signed-off-by: Mayank Gite <drapl0n@protonmail.com>
Something (protonmail?) split some lines of your patch so that it
cannot be applied:
patch: **** malformed patch at line 24: tials:
See https://lore.kernel.org/linux-doc/20260506054914.162806-1-drapl0n@protonmail.com/raw
You can see if Documentation/process/email-clients.rst can help you any,
or just do an web search for using Proton mail to send plain text patches,
but using Proton might be difficult (IDK).
> ---
> Documentation/security/credentials.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/security/credentials.rst b/Documentation/security/credentials.rst
> index d0191c8b8060..4996838491b1 100644
> --- a/Documentation/security/credentials.rst
> +++ b/Documentation/security/credentials.rst
> @@ -189,9 +189,9 @@ The Linux kernel supports the following types of credentials:
> be searched for the desired key. Each process may subscribe to a number
> of keyrings:
>
> - Per-thread keying
> - Per-process keyring
> - Per-session keyring
> + - Per-thread keyring
> + - Per-process keyring
> + - Per-session keyring
>
> When a process accesses a key, if not already present, it will normally be
> cached on one of these keyrings for future accesses to find.
The change itself looks good - if you can find a good way to email it.
thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH v5 2/4] mm/memory-failure: add panic option for unrecoverable pages
From: Breno Leitao @ 2026-05-06 16:18 UTC (permalink / raw)
To: Lance Yang
Cc: david, linmiaohe, nao.horiguchi, akpm, corbet, skhan, ljs,
Liam.Howlett, vbabka, rppt, surenb, mhocko, shuah, linux-mm,
linux-kernel, linux-doc, linux-kselftest, kernel-team
In-Reply-To: <20260428030721.51274-1-lance.yang@linux.dev>
On Tue, Apr 28, 2026 at 11:07:21AM +0800, Lance Yang wrote:
>
> On Mon, Apr 27, 2026 at 05:49:28PM +0200, David Hildenbrand (Arm) wrote:
> >> + switch (type) {
> >> + case MF_MSG_KERNEL:
> >> + case MF_MSG_UNKNOWN:
> >> + return true;
> >> + case MF_MSG_KERNEL_HIGH_ORDER:
> >> + /*
> >> + * Rule out a concurrent buddy allocation: give the
> >> + * allocator a moment to finish prep_new_page() and
> >> + * re-check. A genuine high-order kernel tail page stays
> >> + * unowned; an in-flight allocation will have bumped the
> >> + * refcount, attached a mapping, or placed the page on
> >> + * an LRU by now.
> >> + */
> >> + p = pfn_to_online_page(pfn);
> >> + if (!p)
> >> + return true;
> >> + /*
> >> + * Yield so a concurrent allocator on another CPU can
> >> + * finish prep_new_page() and have its writes become
> >> + * visible before we resample the page state.
> >> + */
> >> + cpu_relax();
> >> + return page_count(p) == 0 &&
> >> + !PageLRU(p) &&
> >> + !page_mapped(p) &&
> >> + !page_folio(p)->mapping &&
> >> + !is_free_buddy_page(p);
> >
> >I don't get what you are doing here. The right way to check for a tail page is
> >not by checking the refcount.
> >
> >Further, you are not holding a folio reference? If so, calling
> >page_mapped/folio_mapped is shaky. On concurrent folio split you can trigger a
> >VM_WARN_ON_FOLIO().
> >
> >
> >Maybe folio_snapshot() is what you are looking for, if you are in fact not
> >holding a reference?
>
> Right! Maybe we should not try to make this decision in
> panic_on_unrecoverable_mf().
>
> By the time we get here, we only know the final MF_MSG_* type. The
> real reason why get_hwpoison_page() failed is already lost.
>
> Wonder if it would be better to split that earlier, around
> __get_unpoison_page()/get_any_page(). That code still knows why
> grabbing the page failed, either an unsupported kernel page or
> just a temporary race we cannot really trust :)
>
> Then the later panic logic can be simple: panic for the stable
> unsupported kernel page case, and not for the temporary race case.
>
> That would also avoid trying to guess MF_MSG_KERNEL_HIGH_ORDER here:)
This is a very good feedback, and definitely what I wanted to do, but,
failed. Once we have the reason, we don't need this dance to guess the
reason.
I've hacked a patch based on this approach. How does it sound?
commit ae7a09c989afe7aaed7ac4b5090d993ef1de0b38
Author: Breno Leitao <leitao@debian.org>
Date: Wed May 6 07:41:30 2026 -0700
mm/memory-failure: classify get_any_page() failures by reason
When get_any_page() fails to grab a page reference, the *reason* it
failed is known at the call site but is not surfaced to callers: the
HWPoisonHandlable() rejection path (a stable kernel page hwpoison cannot
handle — slab, vmalloc, page tables, kernel stacks, ...) and the
page_count() / put_page race paths (a transient page-allocator lifecycle
race) all collapse to a single negative errno by the time
memory_failure() sees them. memory_failure() can only observe the
conflated result and reports both as MF_MSG_GET_HWPOISON.
Surface the diagnosis explicitly. Add an mf_get_page_status enum,
plumbed out through get_any_page() and get_hwpoison_page() (NULL is
accepted by callers that do not care — unpoison_memory() and
soft_offline_page() pass NULL). get_any_page() sets the status at the
moment it gives up:
MF_GET_PAGE_UNHANDLABLE — HWPoisonHandlable() rejected the page
after retries.
MF_GET_PAGE_RACE — exhausted retries on a refcount /
lifecycle race with the allocator.
memory_failure() then promotes the unhandlable case to MF_MSG_KERNEL
alongside the existing PageReserved branch, and leaves the
transient-race case as MF_MSG_GET_HWPOISON. The user-visible report
now distinguishes the two; this also forms the foundation a later
patch will rely on to decide whether an unrecoverable failure should
panic.
Suggested-by: Lance Yang <lance.yang@linux.dev>
Signed-off-by: Breno Leitao <leitao@debian.org>
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index f112fb27a8ff6..a83fabadbce99 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1389,7 +1389,32 @@ static int __get_hwpoison_page(struct page *page, unsigned long flags)
#define GET_PAGE_MAX_RETRY_NUM 3
-static int get_any_page(struct page *p, unsigned long flags)
+/*
+ * Diagnosis of why get_any_page() failed to grab a page reference.
+ *
+ * Set when ret < 0 so callers (notably memory_failure()) can tell apart
+ * a stable kernel page type that hwpoison cannot handle — slab, vmalloc,
+ * page tables, kernel stacks, etc. — from a transient race with the page
+ * allocator lifecycle (allocation/free in flight). The distinction
+ * matters for panic_on_unrecoverable_mf(): the former is a real
+ * unrecoverable kernel-owned poisoning, the latter must not panic since
+ * the page may be destined for userspace where SIGBUS recovery would
+ * otherwise apply.
+ */
+enum mf_get_page_status {
+ MF_GET_PAGE_OK = 0,
+ /*
+ * Transient lifecycle race with the page allocator. Recorded for
+ * symmetry and for future callers that may want to distinguish a
+ * race from an unhandlable kernel page; no in-tree caller acts on
+ * this value yet.
+ */
+ MF_GET_PAGE_RACE,
+ MF_GET_PAGE_UNHANDLABLE, /* stable kernel page hwpoison cannot handle */
+};
+
+static int get_any_page(struct page *p, unsigned long flags,
+ enum mf_get_page_status *status)
{
int ret = 0, pass = 0;
bool count_increased = false;
@@ -1406,11 +1431,15 @@ static int get_any_page(struct page *p, unsigned long flags)
if (pass++ < GET_PAGE_MAX_RETRY_NUM)
goto try_again;
ret = -EBUSY;
+ if (status)
+ *status = MF_GET_PAGE_RACE;
} else if (!PageHuge(p) && !is_free_buddy_page(p)) {
/* We raced with put_page, retry. */
if (pass++ < GET_PAGE_MAX_RETRY_NUM)
goto try_again;
ret = -EIO;
+ if (status)
+ *status = MF_GET_PAGE_RACE;
}
goto out;
} else if (ret == -EBUSY) {
@@ -1423,6 +1452,8 @@ static int get_any_page(struct page *p, unsigned long flags)
goto try_again;
}
ret = -EIO;
+ if (status)
+ *status = MF_GET_PAGE_UNHANDLABLE;
goto out;
}
}
@@ -1442,6 +1473,8 @@ static int get_any_page(struct page *p, unsigned long flags)
}
put_page(p);
ret = -EIO;
+ if (status)
+ *status = MF_GET_PAGE_UNHANDLABLE;
}
out:
if (ret == -EIO)
@@ -1503,7 +1536,8 @@ static int __get_unpoison_page(struct page *page)
* operations like allocation and free,
* -EHWPOISON when the page is hwpoisoned and taken off from buddy.
*/
-static int get_hwpoison_page(struct page *p, unsigned long flags)
+static int get_hwpoison_page(struct page *p, unsigned long flags,
+ enum mf_get_page_status *status)
{
int ret;
@@ -1511,7 +1545,7 @@ static int get_hwpoison_page(struct page *p, unsigned long flags)
if (flags & MF_UNPOISON)
ret = __get_unpoison_page(p);
else
- ret = get_any_page(p, flags);
+ ret = get_any_page(p, flags, status);
zone_pcp_enable(page_zone(p));
return ret;
@@ -2349,6 +2383,7 @@ int memory_failure(unsigned long pfn, int flags)
bool retry = true;
int hugetlb = 0;
bool is_reserved;
+ enum mf_get_page_status gp_status = MF_GET_PAGE_OK;
if (!sysctl_memory_failure_recovery)
panic("Memory failure on page %lx", pfn);
@@ -2424,7 +2459,7 @@ int memory_failure(unsigned long pfn, int flags)
*/
is_reserved = PageReserved(p);
- res = get_hwpoison_page(p, flags);
+ res = get_hwpoison_page(p, flags, &gp_status);
if (!res) {
if (is_free_buddy_page(p)) {
if (take_page_off_buddy(p)) {
@@ -2445,7 +2480,12 @@ int memory_failure(unsigned long pfn, int flags)
}
goto unlock_mutex;
} else if (res < 0) {
- if (is_reserved)
+ /*
+ * Promote a stable unhandlable kernel page diagnosed by
+ * get_hwpoison_page() to MF_MSG_KERNEL alongside reserved
+ * pages; transient lifecycle races stay as MF_MSG_GET_HWPOISON.
+ */
+ if (is_reserved || gp_status == MF_GET_PAGE_UNHANDLABLE)
res = action_result(pfn, MF_MSG_KERNEL, MF_IGNORED);
else
res = action_result(pfn, MF_MSG_GET_HWPOISON,
@@ -2750,7 +2790,7 @@ int unpoison_memory(unsigned long pfn)
goto unlock_mutex;
}
- ghp = get_hwpoison_page(p, MF_UNPOISON);
+ ghp = get_hwpoison_page(p, MF_UNPOISON, NULL);
if (!ghp) {
if (folio_test_hugetlb(folio)) {
huge = true;
@@ -2957,7 +2997,7 @@ int soft_offline_page(unsigned long pfn, int flags)
retry:
get_online_mems();
- ret = get_hwpoison_page(page, flags | MF_SOFT_OFFLINE);
+ ret = get_hwpoison_page(page, flags | MF_SOFT_OFFLINE, NULL);
put_online_mems();
if (hwpoison_filter(page)) {
^ permalink raw reply related
* Re: [PATCH v2] rust: maple_tree: implement Send and Sync for MapleTree
From: Joel Fernandes @ 2026-05-06 16:18 UTC (permalink / raw)
To: Boqun Feng
Cc: linux-kernel, Miguel Ojeda, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, dri-devel,
rust-for-linux, nova-gpu, Nikola Djukic, David Airlie, Boqun Feng,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, alexeyi, Eliot Courtney, joel,
linux-doc
In-Reply-To: <aftiZGt3HQe0Bf_x@tardis.local>
On 5/6/2026 11:46 AM, Boqun Feng wrote:
> On Wed, May 06, 2026 at 09:51:22AM -0400, Joel Fernandes wrote:
>> The C maple_tree struct contains a *mut c_void, which prevents Rust from
>> auto-deriving Send/Sync. Following is an example error message when using
>> MapleTree in nova-core's Vmm.
>>
>> This propagates up through MapleTreeAlloc to Vmm, BarUser, Gpu, and NovaCore,
>> causing NovaCore to fail the Send bound required by pci::Driver:
>>
>> error[E0277]: `*mut c_void` cannot be sent between threads safely
>> --> drivers/gpu/nova-core/driver.rs:77:22
>> |
>> 77 | impl pci::Driver for NovaCore {
>> | ^^^^^^^^ `*mut c_void` cannot be sent between threads safely
>> |
>> = help: within `MapleTreeAlloc<()>`, the trait `Send` is not implemented for `*mut c_void`
>> note: required because it appears within the type `kernel::bindings::maple_tree`
>> note: required because it appears within the type `Opaque<kernel::bindings::maple_tree>`
>> note: required because it appears within the type `MapleTree<()>`
>> note: required because it appears within the type `MapleTreeAlloc<()>`
>> = note: required for `Box<MapleTreeAlloc<()>, Kmalloc>` to implement `Send`
>> note: required because it appears within the type `core::pin::Pin<Box<MapleTreeAlloc<()>, Kmalloc>>`
>> note: required because it appears within the type `Vmm`
>> note: required because it appears within the type `BarUser`
>> note: required because it appears within the type `Gpu`
>> note: required because it appears within the type `NovaCore`
>> note: required by a bound in `kernel::pci::Driver`
>> --> rust/kernel/pci.rs:294:19
>>
>> Implement Send and Sync for MapleTree. The tree contains no thread-local
>> state, and all shared access goes through the internal ma_lock spinlock.
>>
>> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
>> ---
>> RFC->v2: Just adjusted a few comments as suggested by Gary.
>>
>> Sending this separately as discussed in the nova mm patch series that needs it:
>> https://lore.kernel.org/all/252a4eef-f4f4-4edf-8154-06cae4ad8518@nvidia.com/
>>
>> rust/kernel/maple_tree.rs | 29 +++++++++++++++++++++++------
>> 1 file changed, 23 insertions(+), 6 deletions(-)
>>
>> diff --git a/rust/kernel/maple_tree.rs b/rust/kernel/maple_tree.rs
>> index 265d6396a78a..2400c905270d 100644
>> --- a/rust/kernel/maple_tree.rs
>> +++ b/rust/kernel/maple_tree.rs
>> @@ -16,7 +16,11 @@
>> alloc::Flags,
>> error::to_result,
>> prelude::*,
>> - types::{ForeignOwnable, Opaque},
>> + types::{
>> + ForeignOwnable,
>> + NotThreadSafe,
>> + Opaque, //
>> + },
>> };
>>
>> /// A maple tree optimized for storing non-overlapping ranges.
>> @@ -240,7 +244,10 @@ pub fn lock(&self) -> MapleGuard<'_, T> {
>> unsafe { bindings::spin_lock(self.ma_lock()) };
>>
>> // INVARIANT: We just took the spinlock.
>> - MapleGuard(self)
>> + MapleGuard {
>> + tree: self,
>> + _not_send: NotThreadSafe,
>> + }
>> }
>>
>> #[inline]
>> @@ -302,19 +309,29 @@ fn drop(mut self: Pin<&mut Self>) {
>> }
>> }
>>
>> +// SAFETY: `MapleTree<T>` is `Send` if `T` is `Send` because `MapleTree` owns its elements.
>> +unsafe impl<T: ForeignOwnable + Send> Send for MapleTree<T> {}
>> +// SAFETY: `&MapleTree<T>` never hands out `&T`; all entry access is serialized
>> +// by `ma_lock` or `&mut Guard`, so `T: Send` suffices (`T: Sync` not required).
>> +unsafe impl<T: ForeignOwnable + Send> Sync for MapleTree<T> {}
>
> I think you missed this:
>
> https://lore.kernel.org/rust-for-linux/aepRx2jgIKmoRp-r@tardis.local/
>
> ;-)
Oops, sorry about that.
>
> But on a second thought, should that (we have methods of `&MapleTree<T>`
> -> `&T`) happen, we could always guard those methods with T: Sync. Maybe
> it's worth to keep a note on that but, anyway
>
> Reviewed-by: Boqun Feng <boqun@kernel.org>
Ok, so I will leave as it is then, thanks for the tag!
--
Joel Fernandes
^ permalink raw reply
* Re: [PATCH v2 8/9] crash_dump: Disallow configfs/crash_dm_crypt_key/reuse if CONFIG_CRASH_HOTPLUG enabled
From: Sourabh Jain @ 2026-05-06 16:09 UTC (permalink / raw)
To: Coiby Xu, kexec
Cc: Andrew Morton, Baoquan He, Dave Young, Mike Rapoport,
Pasha Tatashin, Pratyush Yadav, Jonathan Corbet, Shuah Khan,
Coiby Xu, open list:DOCUMENTATION, open list
In-Reply-To: <20260501234342.2518281-9-coiby.xu@gmail.com>
On 02/05/26 05:13, Coiby Xu wrote:
> If CONFIG_CRASH_HOTPLUG is enabled, dm-crypt keys saved to reserved
> memory will be took care of automatically. Thus it doesn't make sense
> to use configfs/crash_dm_crypt_key/reuse. Reserving
> image->dm_crypt_keys_addr is also unnecessary. Currently x86_64 and
> ppc64le have implemented CONFIG_CRASH_HOTPLUG feature.
>
> Also update the doc accordingly. Note two doc issues are fixed as well.
>
> Fixes: 9ebfa8dcaea7 ("crash_dump: reuse saved dm crypt keys for CPU/memory hot-plugging")
> Signed-off-by: Coiby Xu <coiby.xu@gmail.com>
> ---
> Documentation/admin-guide/kdump/kdump.rst | 9 ++++++---
> kernel/crash_dump_dm_crypt.c | 14 +++++++++++---
> 2 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst
> index 7587caadbae1..73f2e9500c60 100644
> --- a/Documentation/admin-guide/kdump/kdump.rst
> +++ b/Documentation/admin-guide/kdump/kdump.rst
> @@ -577,9 +577,10 @@ with /sys/kernel/config/crash_dm_crypt_keys for setup,
>
> 1. Tell the first kernel what logon keys are needed to unlock the disk volumes,
> # Add key #1
> - mkdir /sys/kernel/config/crash_dm_crypt_keys/7d26b7b4-e342-4d2d-b660-7426b0996720
> + VOL1_UUID=7d26b7b4-e342-4d2d-b660-7426b0996720
> + mkdir /sys/kernel/config/crash_dm_crypt_keys/$VOL1_UUID
> # Add key #1's description
> - echo cryptsetup:7d26b7b4-e342-4d2d-b660-7426b0996720 > /sys/kernel/config/crash_dm_crypt_keys/description
> + echo cryptsetup:$VOL1_UUID > /sys/kernel/config/crash_dm_crypt_keys/$VOL1_UUID/description
>
> # how many keys do we have now?
> cat /sys/kernel/config/crash_dm_crypt_keys/count
> @@ -593,7 +594,9 @@ with /sys/kernel/config/crash_dm_crypt_keys for setup,
>
> # To support CPU/memory hot-plugging, reuse keys already saved to reserved
> # memory
> - echo true > /sys/kernel/config/crash_dm_crypt_key/reuse
> + # Note if CONFIG_CRASH_HOTPLUG is enabled, this API is totally unnecessary
> + # thus will be disabled.
> + echo true > /sys/kernel/config/crash_dm_crypt_keys/reuse
>
> 2. Load the dump-capture kernel
>
> diff --git a/kernel/crash_dump_dm_crypt.c b/kernel/crash_dump_dm_crypt.c
> index 36e51807d94f..7a7cae17f578 100644
> --- a/kernel/crash_dump_dm_crypt.c
> +++ b/kernel/crash_dump_dm_crypt.c
> @@ -304,6 +304,11 @@ static ssize_t config_keys_reuse_store(struct config_item *item,
> bool val;
> int r;
>
> + if (IS_ENABLED(CONFIG_CRASH_HOTPLUG)) {
> + pr_info("CONFIG_CRASH_HOTPLUG already enabled");
> + return -EINVAL;
> + }
> +
Deciding this solely at compile time can create issues. For example, the
kernel
may be built with CONFIG_CRASH_HOTPLUG, but if kexec tool loads the kdump
kernel using the kexec_load system call without hotplug support, it can
cause problems. It is rare but possible.
How about this:
#ifdef CONFIG_CRASH_HOTPLUG
if (kexec_crash_image->hotplug_support) {
pr_info("crash image is loaded with hotplug support\n");return -EINVAL;
}
#endif
This code should be placed after validating kexec_crash_image.
- Sourabh Jain
> if (!kexec_crash_image || !kexec_crash_image->dm_crypt_keys_addr) {
> pr_info("dm-crypt keys haven't be saved to crash-reserved memory\n");
> return -EINVAL;
> @@ -486,15 +491,18 @@ int crash_load_dm_crypt_keys(struct kimage *image)
> void kexec_file_post_load_cleanup_dm_crypt(struct kimage *image)
> {
> /*
> - * For CPU/memory hot-plugging, the kdump image will be reloaded. Prevent
> - * keys_header from being cleaned up during unloading when
> - * is_dm_key_reused=true
> + * For CPU/memory hot-plugging without CONFIG_CRASH_HOTPLUG, the whole kdump
> + * image will be reloaded. Prevent keys_header from being cleaned up during
> + * unloading when is_dm_key_reused=true
> */
> if (!is_dm_key_reused) {
> kfree_sensitive(keys_header);
> keys_header = NULL;
> }
>
> + if (IS_ENABLED(CONFIG_CRASH_HOTPLUG))
> + image->dm_crypt_keys_addr = 0;
> +
> if (mutex_is_locked(&config_keys_subsys.su_mutex))
> mutex_unlock(&config_keys_subsys.su_mutex);
> }
^ permalink raw reply
* Re: [PATCH v4] iio: adxl313: fix typos in documentation
From: Jonathan Cameron @ 2026-05-06 16:07 UTC (permalink / raw)
To: Wang Zihan
Cc: corbet, dlechner, nuno.sa, andy, skhan, linux-iio, linux-doc,
linux-kernel
In-Reply-To: <tencent_96704F824670A593EC348F183D5C5AAC5C0A@qq.com>
On Tue, 5 May 2026 17:22:43 +0800
Wang Zihan <jiyu03@qq.com> wrote:
> Add missing space in "ADXL313is" and improve grammar for
> "a single types of channels" to "multiple channels of a single type"
> as suggested by Jonathan Cameron.
>
> Wrap long line as suggested by Andy Shevchenko.
>
> Signed-off-by: Wang Zihan <jiyu03@qq.com>
Applied to the testing branch of iio.git.
Thanks,
Jonathan
>
> ---
> Changes in v4:
> - Wrapped long line per Andy Shevchenko's suggestion
>
> Changes in v3:
> - Reworded "a single type of channels" to "multiple channels of a single type"
> per Jonathan Cameron's suggestion
> - Split into two sentences for better readability
> - Added this changelog as requested
>
> Changes in v2:
> - Fixed subject line format (was incorrectly [PATCH 1/4])
> ---
> Documentation/iio/adxl313.rst | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/iio/adxl313.rst b/Documentation/iio/adxl313.rst
> index 966e72c0109a..cc0829be0447 100644
> --- a/Documentation/iio/adxl313.rst
> +++ b/Documentation/iio/adxl313.rst
> @@ -11,7 +11,7 @@ This driver supports Analog Device's ADXL313 on SPI/I2C bus.
>
> * `ADXL313 <https://www.analog.com/ADXL313>`_
>
> -The ADXL313is a low noise density, low power, 3-axis accelerometer with
> +The ADXL313 is a low noise density, low power, 3-axis accelerometer with
> selectable measurement ranges. The ADXL313 supports the ±0.5 g, ±1 g, ±2 g and
> ±4 g ranges.
>
> @@ -112,9 +112,9 @@ apply the following formula:
> Where _offset and _scale are device attributes. If no _offset attribute is
> present, simply assume its value is 0.
>
> -The ADXL313 driver offers data for a single types of channels, the table below
> -shows the measurement units for the processed value, which are defined by the
> -IIO framework:
> +The ADXL313 driver offers data for multiple channels of a single type.
> +The table below shows the measurement units for the processed value,
> +which are defined by the IIO framework:
>
> +-------------------------------------+---------------------------+
> | Channel type | Measurement unit |
^ permalink raw reply
* Re: [PATCH v2 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Willy Tarreau @ 2026-05-06 16:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: greg, leon, security, Jonathan Corbet, skhan, workflows,
linux-doc, linux-kernel, Greg KH
In-Reply-To: <CAHk-=wi6z5BGUUT2p+=qrJg+obom8VnCo3MqB=7xp3Gw+UMMkg@mail.gmail.com>
Hi Linus,
On Wed, May 06, 2026 at 08:46:07AM -0700, Linus Torvalds wrote:
> [ Coming back to this after a week of trying to clean up the disaster
> that is my inbox after the merge window ]
>
> On Sun, 3 May 2026 at 04:35, Willy Tarreau <w@1wt.eu> wrote:
> >
> > The use of automated tools to find bugs in random locations of the kernel
> > induces a raise of security reports even if most of them should just be
> > reported as regular bugs. This patch is an attempt at drawing a line
> > between what qualifies as a security bug and what does not, hoping to
> > improve the situation and ease decision on the reporter's side.
>
> I actually think we may want to go further than this.
>
> I think we should simply make it a rule that "a 'security' bug that is
> found by AI is public".
This would definitely help us a lot on sec@k.o, but...
> Now, I may be influenced by that "my inbox is a disaster during the
> merge window" thing, but I do think this is pretty fundamental: if
> somebody finds a bug with more or less standard AI tools (ie we're not
> talking magical special hardware and nation-state level efforts), then
> that bug pretty much by definition IS NOT SECRET.
I think it's only 99.9% true. I mean, I've used such tools myself to
find bugs that were not found otherwise and I know that:
- interactions with the tools count a lot
- luck counts even more
There remains a faint possibility that the reporter has worked a lot
with their tool to be able to find the problem. I.e. the user helped
the LLM and not the opposite. In this case it might be possible that
it's not public. But clearly from what we've seen over the last few
weeks, the number of duplicates has exploded, with up to 3 reports
for the same issue within 2 days, so it's clear that they're not in
the category I mention above.
Maybe we should leave some rope for "if you are fairly confident that
the work you did is unlikely to have been replicated by anyone else,
the you can report it here" but I think we'll both agree that for now
most reporters really think they did something exceptional while we all
saw it was not the case (or they all do the same exceptional thing).
Thus I'm embarrassed with that.
> So why should be consider it special and have it be on the security list?
>
> Yes, yes, I know - some people think that "security bugs are special".
> And I've been on the record before calling that opinion special - in
> the short bus sense.
>
> Bugs are bugs. And not having them in public only makes them harder to
> deal with.
>
> Do we want to make bugs with potential security impact harder to deal
> with? No. No, we really don't.
>
> So I claim that the only reason for a security list is the non-public
> nature of the bug and the whole "responsible disclosure" argument.
As you probably guess, I totally agree with these points. I'm just
trying to leave the door open for the rare exceptions without having
to accept all the flood.
> But that argument is complete and utter garbage in the face of some
> mostly automated AI discovery (now, that argument is mostly a fiction
> in the first place, but I am not going to argue with people who have
> vested interest in making their special patches "security bugs").
>
> To recap - I think this "document the scope of security bugs" is good,
Thanks for the feedback.
> but I think we should go even further, and just document the fact that
> anything found by regular AI tools should just always go to public
> lists and is simply not special.
I'm fine with that but I'd like to add "except..." though I don't know
how to phrase it. If you have any idea, we can write something for a
start and see how it goes. It looks like these tools are pretty good
at swallowing our doc updates to help reporters so the good thing is
that we can now write instructions that are mostly followed in process
docs ;-)
Willy
^ permalink raw reply
* Re: [PATCH v2] rust: maple_tree: implement Send and Sync for MapleTree
From: Boqun Feng @ 2026-05-06 15:46 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Gary Guo, Bjorn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, dri-devel,
rust-for-linux, nova-gpu, Nikola Djukic, David Airlie, Boqun Feng,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, alexeyi, Eliot Courtney, joel,
linux-doc
In-Reply-To: <20260506135122.GA1432412@joelbox2>
On Wed, May 06, 2026 at 09:51:22AM -0400, Joel Fernandes wrote:
> The C maple_tree struct contains a *mut c_void, which prevents Rust from
> auto-deriving Send/Sync. Following is an example error message when using
> MapleTree in nova-core's Vmm.
>
> This propagates up through MapleTreeAlloc to Vmm, BarUser, Gpu, and NovaCore,
> causing NovaCore to fail the Send bound required by pci::Driver:
>
> error[E0277]: `*mut c_void` cannot be sent between threads safely
> --> drivers/gpu/nova-core/driver.rs:77:22
> |
> 77 | impl pci::Driver for NovaCore {
> | ^^^^^^^^ `*mut c_void` cannot be sent between threads safely
> |
> = help: within `MapleTreeAlloc<()>`, the trait `Send` is not implemented for `*mut c_void`
> note: required because it appears within the type `kernel::bindings::maple_tree`
> note: required because it appears within the type `Opaque<kernel::bindings::maple_tree>`
> note: required because it appears within the type `MapleTree<()>`
> note: required because it appears within the type `MapleTreeAlloc<()>`
> = note: required for `Box<MapleTreeAlloc<()>, Kmalloc>` to implement `Send`
> note: required because it appears within the type `core::pin::Pin<Box<MapleTreeAlloc<()>, Kmalloc>>`
> note: required because it appears within the type `Vmm`
> note: required because it appears within the type `BarUser`
> note: required because it appears within the type `Gpu`
> note: required because it appears within the type `NovaCore`
> note: required by a bound in `kernel::pci::Driver`
> --> rust/kernel/pci.rs:294:19
>
> Implement Send and Sync for MapleTree. The tree contains no thread-local
> state, and all shared access goes through the internal ma_lock spinlock.
>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> RFC->v2: Just adjusted a few comments as suggested by Gary.
>
> Sending this separately as discussed in the nova mm patch series that needs it:
> https://lore.kernel.org/all/252a4eef-f4f4-4edf-8154-06cae4ad8518@nvidia.com/
>
> rust/kernel/maple_tree.rs | 29 +++++++++++++++++++++++------
> 1 file changed, 23 insertions(+), 6 deletions(-)
>
> diff --git a/rust/kernel/maple_tree.rs b/rust/kernel/maple_tree.rs
> index 265d6396a78a..2400c905270d 100644
> --- a/rust/kernel/maple_tree.rs
> +++ b/rust/kernel/maple_tree.rs
> @@ -16,7 +16,11 @@
> alloc::Flags,
> error::to_result,
> prelude::*,
> - types::{ForeignOwnable, Opaque},
> + types::{
> + ForeignOwnable,
> + NotThreadSafe,
> + Opaque, //
> + },
> };
>
> /// A maple tree optimized for storing non-overlapping ranges.
> @@ -240,7 +244,10 @@ pub fn lock(&self) -> MapleGuard<'_, T> {
> unsafe { bindings::spin_lock(self.ma_lock()) };
>
> // INVARIANT: We just took the spinlock.
> - MapleGuard(self)
> + MapleGuard {
> + tree: self,
> + _not_send: NotThreadSafe,
> + }
> }
>
> #[inline]
> @@ -302,19 +309,29 @@ fn drop(mut self: Pin<&mut Self>) {
> }
> }
>
> +// SAFETY: `MapleTree<T>` is `Send` if `T` is `Send` because `MapleTree` owns its elements.
> +unsafe impl<T: ForeignOwnable + Send> Send for MapleTree<T> {}
> +// SAFETY: `&MapleTree<T>` never hands out `&T`; all entry access is serialized
> +// by `ma_lock` or `&mut Guard`, so `T: Send` suffices (`T: Sync` not required).
> +unsafe impl<T: ForeignOwnable + Send> Sync for MapleTree<T> {}
I think you missed this:
https://lore.kernel.org/rust-for-linux/aepRx2jgIKmoRp-r@tardis.local/
;-)
But on a second thought, should that (we have methods of `&MapleTree<T>`
-> `&T`) happen, we could always guard those methods with T: Sync. Maybe
it's worth to keep a note on that but, anyway
Reviewed-by: Boqun Feng <boqun@kernel.org>
Regards,
Boqun
> +
> /// A reference to a [`MapleTree`] that owns the inner lock.
> ///
> /// # Invariants
> ///
> /// This guard owns the inner spinlock.
> #[must_use = "if unused, the lock will be immediately unlocked"]
> -pub struct MapleGuard<'tree, T: ForeignOwnable>(&'tree MapleTree<T>);
> +pub struct MapleGuard<'tree, T: ForeignOwnable> {
> + tree: &'tree MapleTree<T>,
> + // A held spinlock must be released on the same CPU that acquired it.
> + _not_send: NotThreadSafe,
> +}
>
> impl<'tree, T: ForeignOwnable> Drop for MapleGuard<'tree, T> {
> #[inline]
> fn drop(&mut self) {
> // SAFETY: By the type invariants, we hold this spinlock.
> - unsafe { bindings::spin_unlock(self.0.ma_lock()) };
> + unsafe { bindings::spin_unlock(self.tree.ma_lock()) };
> }
> }
>
> @@ -323,7 +340,7 @@ impl<'tree, T: ForeignOwnable> MapleGuard<'tree, T> {
> pub fn ma_state(&mut self, first: usize, end: usize) -> MaState<'_, T> {
> // SAFETY: The `MaState` borrows this `MapleGuard`, so it can also borrow the `MapleGuard`s
> // read/write permissions to the maple tree.
> - unsafe { MaState::new_raw(self.0, first, end) }
> + unsafe { MaState::new_raw(self.tree, first, end) }
> }
>
> /// Load the value at the given index.
> @@ -375,7 +392,7 @@ pub fn ma_state(&mut self, first: usize, end: usize) -> MaState<'_, T> {
> #[inline]
> pub fn load(&mut self, index: usize) -> Option<T::BorrowedMut<'_>> {
> // SAFETY: `self.tree` contains a valid maple tree.
> - let ret = unsafe { bindings::mtree_load(self.0.tree.get(), index) };
> + let ret = unsafe { bindings::mtree_load(self.tree.tree.get(), index) };
> if ret.is_null() {
> return None;
> }
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Linus Torvalds @ 2026-05-06 15:46 UTC (permalink / raw)
To: Willy Tarreau
Cc: greg, leon, security, Jonathan Corbet, skhan, workflows,
linux-doc, linux-kernel, Greg KH
In-Reply-To: <20260503113506.5710-3-w@1wt.eu>
[ Coming back to this after a week of trying to clean up the disaster
that is my inbox after the merge window ]
On Sun, 3 May 2026 at 04:35, Willy Tarreau <w@1wt.eu> wrote:
>
> The use of automated tools to find bugs in random locations of the kernel
> induces a raise of security reports even if most of them should just be
> reported as regular bugs. This patch is an attempt at drawing a line
> between what qualifies as a security bug and what does not, hoping to
> improve the situation and ease decision on the reporter's side.
I actually think we may want to go further than this.
I think we should simply make it a rule that "a 'security' bug that is
found by AI is public".
Now, I may be influenced by that "my inbox is a disaster during the
merge window" thing, but I do think this is pretty fundamental: if
somebody finds a bug with more or less standard AI tools (ie we're not
talking magical special hardware and nation-state level efforts), then
that bug pretty much by definition IS NOT SECRET.
So why should be consider it special and have it be on the security list?
Yes, yes, I know - some people think that "security bugs are special".
And I've been on the record before calling that opinion special - in
the short bus sense.
Bugs are bugs. And not having them in public only makes them harder to
deal with.
Do we want to make bugs with potential security impact harder to deal
with? No. No, we really don't.
So I claim that the only reason for a security list is the non-public
nature of the bug and the whole "responsible disclosure" argument.
But that argument is complete and utter garbage in the face of some
mostly automated AI discovery (now, that argument is mostly a fiction
in the first place, but I am not going to argue with people who have
vested interest in making their special patches "security bugs").
To recap - I think this "document the scope of security bugs" is good,
but I think we should go even further, and just document the fact that
anything found by regular AI tools should just always go to public
lists and is simply not special.
Linus
^ permalink raw reply
* Re: [PATCH v5 3/4] Documentation: document panic_on_unrecoverable_memory_failure sysctl
From: Breno Leitao @ 2026-05-06 15:38 UTC (permalink / raw)
To: Andrew Morton
Cc: Miaohe Lin, Naoya Horiguchi, Jonathan Corbet, Shuah Khan,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Shuah Khan, linux-mm, linux-kernel, linux-doc, linux-kselftest,
kernel-team
In-Reply-To: <20260424054840.a63d80ed01b968caf9d9ef64@linux-foundation.org>
On Fri, Apr 24, 2026 at 05:48:40AM -0700, Andrew Morton wrote:
> On Fri, 24 Apr 2026 05:24:01 -0700 Breno Leitao <leitao@debian.org> wrote:
>
> > Add documentation for the new vm.panic_on_unrecoverable_memory_failure
> > sysctl, describing the three categories of failures that trigger a
> > panic and noting which kernel page types are not yet covered.
> >
> >
> > ...
> >
> > +When enabled, this sysctl triggers a panic on three categories of
> > +unrecoverable failures: reserved kernel pages, non-buddy kernel pages
> > +with zero refcount (e.g. tail pages of high-order allocations), and
> > +pages whose state cannot be classified as recoverable.
>
> Before someone asks, I wonder if we should make this a bitfield thing,
> so people can select which of the above three should get the panic
> treatment.
That's an interesting idea, though I think the necessary infrastructure
doesn't exist yet. As discussed in this thread, even distinguishing
non-userspace pages from userspace pages presents non-trivial challenges.
Implementing a bitfield-based approach would require significant
groundwork. If we want to pursue that direction, it might make sense to
defer this patchset and focus on building that infrastructure first.
My preference would be to start with the coarse-grained approach
(current approach) and refine it incrementally based on actual needs.
^ permalink raw reply
* Re: [PATCH v10 1/2] dt-bindings: hwmon: temperature: add support for EMC1812
From: Rob Herring (Arm) @ 2026-05-06 15:37 UTC (permalink / raw)
To: Marius Cristea
Cc: Conor Dooley, Jonathan Corbet, linux-hwmon, Krzysztof Kozlowski,
devicetree, linux-doc, linux-kernel, Guenter Roeck
In-Reply-To: <20260429-hw_mon-emc1812-v10-1-a8ca1d779502@microchip.com>
On Wed, 29 Apr 2026 15:58:07 +0300, Marius Cristea wrote:
> This is the devicetree schema for Microchip EMC1812/13/14/15/33
> Multichannel Low-Voltage Remote Diode Sensor Family. It also
> updates the MAINTAINERS file to include the new driver.
>
> EMC1812 has one external remote temperature monitoring channel.
> EMC1813 has two external remote temperature monitoring channels.
> EMC1814 has three external remote temperature monitoring channels and
> channels 2 and 3 support anti parallel diode.
> EMC1815 has four external remote temperature monitoring channels and
> channels 1/2 and 3/4 support anti parallel diode.
> EMC1833 has two external remote temperature monitoring channels and
> channels 1 and 2 support anti parallel diode.
> Resistance Error Correction is supported on channels 1/2 and 3/4.
>
> Signed-off-by: Marius Cristea <marius.cristea@microchip.com>
> ---
> .../bindings/hwmon/microchip,emc1812.yaml | 193 +++++++++++++++++++++
> MAINTAINERS | 6 +
> 2 files changed, 199 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] docs: fix typos in reporting-issues.rst
From: Thorsten Leemhuis @ 2026-05-06 15:21 UTC (permalink / raw)
To: Felipe Matarazzo, Jonathan Corbet; +Cc: Shuah Khan, linux-doc, linux-kernel
In-Reply-To: <20260503232816.70687-1-felipemps@protonmail.com>
On 5/4/26 01:28, Felipe Matarazzo wrote:
> Fix 33 typos: wrong words (want→what, is→if/it, sent→send,
> abound→about, exiting→existing, option→opinion, and→an),
> missing words (of, a, too, s), extra words (on, over), wrong
> word forms (built, stops, advice, severity, lists, types,
> Inquiries, requests) and garbled phrases.
>
> Signed-off-by: Felipe Matarazzo <felipemps@protonmail.com>
Many thx for this. Spotted one problem though:
> [...]
> @@ -1386,7 +1386,7 @@ writing something anyway.
> With all these general things off the table let's get into the details of how
> to help to get issues resolved once they were reported.
>
> -Inquires and testing request
> +Inquiries and testing requests
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That subheading (the lines with all those "~") is now to short. Have you
tried building this? I'd assume there would have been a warning pointing
this out.
Apart from that:
Acked-by: Thorsten Leemhuis <linux@leemhuis.info>
Ciao, Thorsten
^ permalink raw reply
* Re: [RFC net-next 0/4] devlink: Add boot-time defaults
From: Jiri Pirko @ 2026-05-06 15:22 UTC (permalink / raw)
To: Mark Bloch
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller, Jonathan Corbet, Shuah Khan, Simon Horman,
Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Andrew Morton,
Borislav Petkov (AMD), Randy Dunlap, Dave Hansen,
Christian Brauner, Petr Mladek, Peter Zijlstra (Intel),
Thomas Gleixner, Pawan Gupta, Dapeng Mi, Kees Cook, Marco Elver,
Eric Biggers, Li RongQing, Paul E. McKenney, linux-doc,
linux-kernel, netdev, linux-rdma
In-Reply-To: <20260506123739.1959770-1-mbloch@nvidia.com>
Wed, May 06, 2026 at 02:37:35PM +0200, mbloch@nvidia.com wrote:
>This series adds a devlink= kernel command line parameter for applying
>selected devlink settings during device initialization.
>
>Following a discussion with Jakub[1], I am sending this RFC to get the
>conversation moving. I started from Jakub's example/request and extended
>it to cover requirements from production systems and configurations that
>customers use.
>
>One important caveat is that the parsing logic in this RFC was written
>with AI assistance. I am also not sure whether the resulting syntax and
>parser are too complex for a kernel command line interface. This is part
>of why I am sending it as an RFC: to understand what direction and level
>of complexity would be acceptable to people.
>
>The implementation is intended to support the following properties:
>
>- A system may have multiple devlink devices that usually need the same
> configuration. For a configuration such as eswitch mode switchdev, a
> user should be able to specify multiple devices to which that
> configuration applies.
>
>- There may be ordering dependencies between options. For example, in
> mlx5, flow_steering_mode should be set before moving to switchdev.
> With this in mind, defaults are applied per device in the left-to-right
> order in which they appear on the command line.
>
>The intent is to let deployments set devlink defaults before normal
>userspace orchestration runs, while still using devlink concepts and
"defaults before normal userspace orchestrarion". I read it as config
before config, which eventually could be skipped.
>driver callbacks rather than adding driver-specific module parameters.
>A default is scoped to one or more devlink handles, for example:
>
> devlink=[pci/0000:08:00.0]:esw:mode:switchdev
> devlink=[pci/0000:08:00.0]:param:flow_steering_mode:smfs
> devlink=[pci/0000:08:00.0,pci/0000:08:00.1]:param:flow_steering_mode:hmfs,[pci/0000:08:00.0,pci/0000:08:00.1]:esw:mode:switchdev
I don't like this. What you do, you are basically introducing user
configuration tool on kernel cmdline.
The same you would achieve with a proper userspace tool/daemon.
I did try to come up with it and push it here:
https://github.com/systemd/systemd/pull/37393
That didn't get merged for unknown reason, but the idea is sound. You
provide configuration files for devlink object and systemd-devlinkd
will apply when they appear. Wouldn't this help your case?
[..]
^ permalink raw reply
* Re: [PATCH 6/8] drm/panthor: Explicit expansion of locked VM region
From: Nicolas Frattaroli @ 2026-05-06 15:14 UTC (permalink / raw)
To: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Boris Brezillon, Steven Price, Liviu Dudau,
Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno, Ketil Johnsen, Ketil Johnsen
Cc: dri-devel, linux-doc, linux-kernel, linux-media, linaro-mm-sig,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260505140516.1372388-7-ketil.johnsen@arm.com>
On Tuesday, 5 May 2026 16:05:12 Central European Summer Time Ketil Johnsen wrote:
> Currently the panthor_vm_lock_region() function will implicitly expand
> an already locked VM region. This can be problematic because the caller
> do not reliably know if it needs to call panthor_vm_unlock_region()
> or not.
>
> Worth noting, there is currently no known issues with this as the code
> is written today.
>
> This change introduces panthor_vm_expand_region() which will only work
> if there is already a locked VM region. This again means that the
> original lock and unlock functions can work as a pair. This pairing is
> needed for subsequent protected memory changes.
>
> Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com>
> ---
> drivers/gpu/drm/panthor/panthor_mmu.c | 69 +++++++++++++++++++--------
> 1 file changed, 50 insertions(+), 19 deletions(-)
>
While trying this series, I attempted my usual
`modprobe -r panthor && modprobe panthor protected_heap_name=default_cma_region`.
Unfortunately, it oopses when attempting to unmap the sg for a bo labeled
"FW section" on panthor module unload, and I bisected it to this patch.
The oops:
[ 598.515550] Unable to handle kernel paging request at virtual address 0000000000400267
[ 598.516864] Mem abort info:
[ 598.517676] ESR = 0x0000000096000004
[ 598.518560] EC = 0x25: DABT (current EL), IL = 32 bits
[ 598.520414] SET = 0, FnV = 0
[ 598.521275] EA = 0, S1PTW = 0
[ 598.522099] FSC = 0x04: level 0 translation fault
[ 598.523069] Data abort info:
[ 598.524311] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 598.525566] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 598.526850] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 598.527905] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000104056000
[ 598.529019] [0000000000400267] pgd=0000000000000000, p4d=0000000000000000
[ 598.530170] Internal error: Oops: 0000000096000004 [#1] SMP
[ 598.531158] Modules linked in: btusb btrtl btmtk btintel btbcm bluetooth ecdh_generic ecc kpp snd_soc_hdmi_codec cfg80211 r8169 rfkill_gpio pwm_fan rfkill snd_soc_es8316 rtc_hym8563 rk805_pwrkey at24 fusb302 tcpm aux_hpd_bridge display_connector snd_soc_simple_card phy_rockchip_samsung_hdptx phy_rockchip_usbdp rockchip_thermal typec phy_rockchip_naneng_combphy rockchip_saradc industrialio_triggered_buffer kfifo_buf rockchipdrm inno_hdmi dw_dp hantro_vpu rockchip_vdec dw_mipi_dsi2 v4l2_jpeg v4l2_vp9 rockchip_rga dw_mipi_dsi v4l2_h264 synopsys_hdmirx v4l2_dv_timings spi_rockchip_sfc videobuf2_dma_contig videobuf2_dma_sg v4l2_mem2mem videobuf2_memops dw_hdmi_qp onboard_usb_dev analogix_dp videobuf2_v4l2 videobuf2_common snd_soc_rockchip_i2s_tdm dw_hdmi videodev mc drm_display_helper nvme cec panthor(-) drm_gpuvm drm_exec gpu_sched drm_dp_aux_bus drm_dma_helper drm_client_lib nvme_core drm_kms_helper drm pci_endpoint_test backlight snd_soc_audio_graph_card snd_soc_simple_card_utils fuse dm_mod
[ 598.541237] CPU: 6 UID: 0 PID: 806 Comm: modprobe Not tainted 7.1.0-rc2-00726-g8ab0a3092b56-dirty #2 PREEMPT
[ 598.542733] Hardware name: Radxa ROCK 5T (DT)
[ 598.543746] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 598.544991] pc : dma_unmap_sg_attrs (kernel/dma/mapping.c:0)
[ 598.546021] lr : panthor_gem_free_object (include/linux/dma-mapping.h:565 drivers/gpu/drm/panthor/panthor_gem.c:308 drivers/gpu/drm/panthor/panthor_gem.c:469) panthor
[ 598.547180] sp : ffff80008835bb90
[ 598.548123] x29: ffff80008835bb90 x28: ffff00012610bf00 x27: 0000000000000000
[ 598.549412] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[ 598.550696] x23: ffff000127194600 x22: ffff0001271943d0 x21: ffff000118671000
[ 598.551984] x20: ffff000127194200 x19: ffff000127194600 x18: 00000000002ab980
[ 598.553273] x17: 00000000002ab980 x16: ffffa39a6b372a04 x15: 0000000000000000
[ 598.554568] x14: 0000000000000010 x13: 0000000000000000 x12: 000000000000003c
[ 598.555864] x11: 0000000000000002 x10: ffff000100a5d000 x9 : ffff000118671000
[ 598.557164] x8 : ffff000102f8b490 x7 : ffff000149569000 x6 : ffff000149569000
[ 598.558461] x5 : ffff000100faa7e8 x4 : 0000000000000000 x3 : 0000000000000000
[ 598.559763] x2 : 0000000000000010 x1 : ffff000127194000 x0 : 000000000040000f
[ 598.561069] Call trace:
[ 598.561961] dma_unmap_sg_attrs (kernel/dma/mapping.c:0) (P)
[ 598.563038] panthor_gem_free_object (include/linux/dma-mapping.h:565 drivers/gpu/drm/panthor/panthor_gem.c:308 drivers/gpu/drm/panthor/panthor_gem.c:469) panthor
[ 598.564218] drm_gem_object_free (drivers/gpu/drm/drm_gem.c:1148) drm
[ 598.565386] panthor_kernel_bo_destroy (include/linux/kref.h:65 include/drm/drm_gem.h:565 include/drm/drm_gem.h:578 drivers/gpu/drm/panthor/panthor_gem.c:1317) panthor
[ 598.566575] panthor_fw_unplug (drivers/gpu/drm/panthor/panthor_fw.c:1306) panthor
[ 598.567705] panthor_device_unplug (drivers/gpu/drm/panthor/panthor_device.c:103) panthor
[ 598.568878] panthor_remove (drivers/gpu/drm/panthor/panthor_drv.c:1846) panthor
[ 598.569991] platform_remove (drivers/base/platform.c:1435)
[ 598.571029] device_release_driver_internal (drivers/base/dd.c:619 drivers/base/dd.c:1352 drivers/base/dd.c:1375)
[ 598.572209] driver_detach (drivers/base/dd.c:1438)
[ 598.573237] bus_remove_driver (drivers/base/bus.c:825)
[ 598.574304] driver_unregister (drivers/base/driver.c:277)
[ 598.575363] platform_driver_unregister (drivers/base/platform.c:920)
[ 598.576494] cleanup_module (drivers/gpu/drm/panthor/panthor_devfreq.c:134) panthor
[ 598.577617] __arm64_sys_delete_module (kernel/module/main.c:863 kernel/module/main.c:804 kernel/module/main.c:804)
[ 598.578751] invoke_syscall (arch/arm64/kernel/syscall.c:35 arch/arm64/kernel/syscall.c:49)
[ 598.579794] el0_svc_common (arch/arm64/kernel/syscall.c:121)
[ 598.580842] do_el0_svc (arch/arm64/kernel/syscall.c:140)
[ 598.581862] el0_svc (arch/arm64/kernel/entry-common.c:723)
[ 598.582853] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:742)
[ 598.583949] el0t_64_sync (arch/arm64/kernel/entry.S:594)
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* Re: [PATCH 0/2] cgroup/dmem: introduce a peak file
From: Michal Koutný @ 2026-05-06 15:09 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: Tejun Heo, Johannes Weiner, Michal Hocko, Roman Gushchin,
Shakeel Butt, Muchun Song, Andrew Morton, Jonathan Corbet,
Shuah Khan, Maarten Lankhorst, Maxime Ripard, Natalie Vock,
Tvrtko Ursulin, cgroups, linux-kernel, linux-mm, linux-doc,
dri-devel, kernel-dev
In-Reply-To: <aftNsqrv2sGPOPHX@quatroqueijos.cascardo.eti.br>
[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]
On Wed, May 06, 2026 at 11:18:26AM -0300, Thadeu Lima de Souza Cascardo <cascardo@igalia.com> wrote:
> I used void *, at first, but as the only current use is for the pool and as
> mixing different uses may lead to misuse, I thought it would be safer to
> use the type directly. This has been pointed out before for other members
> of cgroup_file_ctx. See [1].
That mail reacts to union overlaps and pointer vs embedded struct
allocations. Correct me if I missed your part.
I agree that having properly typed pointer is safer.
cgroup_file_ctx sub-structs are for generic cgroup files. But here
somehow a specific controller needs propagated to the generic member.
What about storing also the `list_head *watchers` inside `struct
cgroup_of_peak` and each subsys would manage it as needed?
(ofp->watchers == NULL could also substitute ofp->value ==
OFP_PEAK_UNSET)
> I started with a non-resettable peak file, but as memory.peak can be reset,
> I added that feature too.
At the same time pids.peak has survived without reset option till today.
> If we want to merge a non-resettable support ealier and need to take
> longer to discuss how to work on the resettable support given the
> above, I can resubmit. But I guess we can see if we can reach an
> agreement sonner rather than later.
What kind of users do you envision (i.e. would they need resets at all)?
Anyway, the behavior should be explained in cgroup-v2.rst since that's
where they'll look for it.
HTH,
Michal
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply
* Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor
From: Boris Brezillon @ 2026-05-06 15:05 UTC (permalink / raw)
To: Maxime Ripard
Cc: Ketil Johnsen, David Airlie, Simona Vetter, Maarten Lankhorst,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Steven Price, Liviu Dudau, Daniel Almeida,
Alice Ryhl, Matthias Brugger, AngeloGioacchino Del Regno,
dri-devel, linux-doc, linux-kernel, linux-media, linaro-mm-sig,
linux-arm-kernel, linux-mediatek, Florent Tomasin
In-Reply-To: <20260506-golden-python-of-aptitude-ff972a@houat>
On Wed, 6 May 2026 15:12:37 +0200
Maxime Ripard <mripard@kernel.org> wrote:
> On Wed, May 06, 2026 at 12:50:15PM +0200, Boris Brezillon wrote:
> > On Wed, 6 May 2026 12:08:24 +0200
> > Maxime Ripard <mripard@kernel.org> wrote:
> >
> > > Hi,
> > >
> > > On Tue, May 05, 2026 at 04:05:10PM +0200, Ketil Johnsen wrote:
> > > > From: Florent Tomasin <florent.tomasin@arm.com>
> > > >
> > > > This patch allows Panthor to allocate buffer objects from a
> > > > protected heap. The Panthor driver should be seen as a consumer
> > > > of the heap and not an exporter.
> > > >
> > > > Protected memory buffers needed by the Panthor driver:
> > > > - On CSF FW load, the Panthor driver must allocate a protected
> > > > buffer object to hold data to use by the FW when in protected
> > > > mode. This protected buffer object is owned by the device
> > > > and does not belong to a process.
> > > > - On CSG creation, the Panthor driver must allocate a protected
> > > > suspend buffer object for the FW to store data when suspending
> > > > the CSG while in protected mode. The kernel owns this allocation
> > > > and does not allow user space mapping. The format of the data
> > > > in this buffer is only known by the FW and does not need to be
> > > > shared with other entities.
> > > >
> > > > The driver will retrieve the protected heap using the name of the
> > > > heap provided to the driver as module parameter.
> > >
> > > I know it's what dma_heap_find asks for, but I wonder if it wouldn't be
> > > better in the device tree and lookup through the device node? heaps are
> > > going to have a node anyway, right?
> >
> > I'm not too sure. Take the PROTMEM (name="protected,xxxx") dma_heaps
> > instantiated by optee for instance, I don't think the originating
> > tee_device comes from a device node, nor is the underlying heap
> > described as a device node. The reserved memory pool this protected heap
> > comes from is most likely defined somewhere as reserved memory in the
> > DT, but there's nothing to correlate this range of reserved mem to some
> > sub-range that the TEE implementation is carving out to provide
> > protected memory.
>
> Maybe we should be working on a dt bindings for heaps then? Something
> simple like we have for clocks with a phandle and an ID would probably
> be enough. In optee's case, it looks like it would map nicely with
> TEE_DMA_HEAP_* flags too.
Sure.
>
> The only two that wouldn't be covered would be the system and default
> CMA heap if not setup in the DT, which shouldn't be too bad for this
> particular use-case.
I'm not opposed to the idea of describing the association through the
DT (with a <phandle, ID> pair). My main fear is that it drags us into
endless discussions around what's considered HW description and what's
not (PTSD of all those DT-bindings discussions I suppose :-)), which
ends up delaying the merging of Panthor's protected memory support.
Honestly, at this point I'm considering going back to my initial
suggestion to add a dedicated ioctl() (requiring high privilege) to let
the user pass the memory for the FW protected sections as a dmabuf FD.
Given we don't need those sections to be populated for the FW to boot,
it wouldn't block the probe of the driver, it would just prevent PROTM
usage until those sections are populated.
This would let us make progress with the rest of the changes in this
patchset, while the community decides how they want to expose dma_heaps
to in-kernel users.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox