* [PATCH v3 2/8] dt-bindings: arm: Add zx297520v3 board binding
From: Stefan Dösinger @ 2026-04-14 21:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Linus Walleij, Arnd Bergmann, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260414211215.152850-1-stefandoesinger@gmail.com>
Add a compatible for boards based on the ZTE zx297520v3 SoC.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
.../devicetree/bindings/arm/zx29.yaml | 20 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/zx29.yaml
diff --git a/Documentation/devicetree/bindings/arm/zx29.yaml b/Documentation/devicetree/bindings/arm/zx29.yaml
new file mode 100644
index 000000000000..717ca6413993
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/zx29.yaml
@@ -0,0 +1,20 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/zx29.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ZTE zx29
+
+maintainers:
+ - Stefan Dösinger <stefandoesinger@gmail.com>
+
+properties:
+ $nodename:
+ const: "/"
+ compatible:
+ oneOf:
+ - items:
+ - const: zte,zx297520v3
+
+additionalProperties: true
diff --git a/MAINTAINERS b/MAINTAINERS
index 974d7a98956a..c29eb2dfb1b3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -29202,6 +29202,7 @@ F: tools/testing/selftests/cgroup/test_zswap.c
ZX29
M: Stefan Dösinger <stefandoesinger@gmail.com>
+F: Documentation/devicetree/bindings/arm/zx29.yaml
F: arch/arm/mach-zte/
SENARYTECH AUDIO CODEC DRIVER
--
2.52.0
^ permalink raw reply related
* [PATCH v3 3/8] ARM: dts: Add D-Link DWR-932M support
From: Stefan Dösinger @ 2026-04-14 21:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Linus Walleij, Arnd Bergmann, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260414211215.152850-1-stefandoesinger@gmail.com>
This adds DT bindings for zx297520v3 and one board that consumes it.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
MAINTAINERS | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/zte/Makefile | 3 ++
arch/arm/boot/dts/zte/dlink-dwr-932m.dts | 21 ++++++++++++++
arch/arm/boot/dts/zte/zx297520v3.dtsi | 37 ++++++++++++++++++++++++
5 files changed, 63 insertions(+)
create mode 100644 arch/arm/boot/dts/zte/Makefile
create mode 100644 arch/arm/boot/dts/zte/dlink-dwr-932m.dts
create mode 100644 arch/arm/boot/dts/zte/zx297520v3.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index c29eb2dfb1b3..21f87d1e0e9a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -29203,6 +29203,7 @@ F: tools/testing/selftests/cgroup/test_zswap.c
ZX29
M: Stefan Dösinger <stefandoesinger@gmail.com>
F: Documentation/devicetree/bindings/arm/zx29.yaml
+F: arch/arm/boot/dts/zte
F: arch/arm/mach-zte/
SENARYTECH AUDIO CODEC DRIVER
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index efe38eb25301..28fba538d552 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -39,3 +39,4 @@ subdir-y += unisoc
subdir-y += vt8500
subdir-y += xen
subdir-y += xilinx
+subdir-y += zte
diff --git a/arch/arm/boot/dts/zte/Makefile b/arch/arm/boot/dts/zte/Makefile
new file mode 100644
index 000000000000..416c24a489cd
--- /dev/null
+++ b/arch/arm/boot/dts/zte/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_SOC_ZX297520V3) += \
+ dlink-dwr-932m.dtb
diff --git a/arch/arm/boot/dts/zte/dlink-dwr-932m.dts b/arch/arm/boot/dts/zte/dlink-dwr-932m.dts
new file mode 100644
index 000000000000..a062c40c467b
--- /dev/null
+++ b/arch/arm/boot/dts/zte/dlink-dwr-932m.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * D-Link DWR-932M Board
+ *
+ * (C) Copyright 2026 Stefan Dösinger
+ *
+ */
+
+/dts-v1/;
+
+#include "zx297520v3.dtsi"
+
+/ {
+ model = "D-Link DWR-932M";
+ compatible = "zte,zx297520v3";
+
+ memory@20000000 {
+ device_type = "memory";
+ reg = <0x20000000 0x04000000>;
+ };
+};
diff --git a/arch/arm/boot/dts/zte/zx297520v3.dtsi b/arch/arm/boot/dts/zte/zx297520v3.dtsi
new file mode 100644
index 000000000000..d6c71d52b26c
--- /dev/null
+++ b/arch/arm/boot/dts/zte/zx297520v3.dtsi
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0>;
+ };
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+ ranges;
+
+ gic: interrupt-controller@f2000000 {
+ compatible = "arm,gic-v3";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xf2000000 0x10000>,
+ <0xf2040000 0x20000>;
+ };
+ };
+};
--
2.52.0
^ permalink raw reply related
* [PATCH v3 1/8] ARM: zte: Add zx297520v3 platform support
From: Stefan Dösinger @ 2026-04-14 21:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Linus Walleij, Arnd Bergmann, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260414211215.152850-1-stefandoesinger@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.
Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
---
Documentation/arch/arm/zte/zx297520v3.rst | 158 ++++++++++++++++++++++
MAINTAINERS | 4 +
arch/arm/Kconfig | 2 +
arch/arm/Makefile | 1 +
arch/arm/mach-zte/Kconfig | 24 ++++
arch/arm/mach-zte/Makefile | 2 +
arch/arm/mach-zte/zx297520v3.c | 19 +++
7 files changed, 210 insertions(+)
create mode 100644 Documentation/arch/arm/zte/zx297520v3.rst
create mode 100644 arch/arm/mach-zte/Kconfig
create mode 100644 arch/arm/mach-zte/Makefile
create mode 100644 arch/arm/mach-zte/zx297520v3.c
diff --git a/Documentation/arch/arm/zte/zx297520v3.rst b/Documentation/arch/arm/zte/zx297520v3.rst
new file mode 100644
index 000000000000..a0f25ade0a3d
--- /dev/null
+++ b/Documentation/arch/arm/zte/zx297520v3.rst
@@ -0,0 +1,158 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====================================
+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 aarch32 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 uboot 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.
+
+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>
+
+@ This allows EL1 to handle ints hat are normally handled by EL2/3.
+ldr r3, =0xf2000000
+ldr r4, =#(GICD_CTLR_ARE_NS | GICD_CTLR_DS)
+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.
+@
+@ ARM docs say modify this bit in monitor mode only...
+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. TODO: Doesn't safe_svcmode_maskall do this for us anyway?
+cps #SVC_MODE
+```
diff --git a/MAINTAINERS b/MAINTAINERS
index d1cc0e12fe1f..974d7a98956a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -29200,6 +29200,10 @@ F: include/linux/zswap.h
F: mm/zswap.c
F: tools/testing/selftests/cgroup/test_zswap.c
+ZX29
+M: Stefan Dösinger <stefandoesinger@gmail.com>
+F: arch/arm/mach-zte/
+
SENARYTECH AUDIO CODEC DRIVER
M: bo liu <bo.liu@senarytech.com>
S: Maintained
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..24699256863b
--- /dev/null
+++ b/arch/arm/mach-zte/Kconfig
@@ -0,0 +1,24 @@
+# SPDX-License-Identifier: GPL-2.0
+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
+ default y if ARCH_ZTE
+ bool "ZX297520v3"
+ select ARM_GIC_V3
+ select ARM_AMBA
+ select HAVE_ARM_ARCH_TIMER
+ select PM_GENERIC_DOMAINS if PM
+ help
+ Support for ZTE zx297520v3 SoC. It 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..c11c7e836f91
--- /dev/null
+++ b/arch/arm/mach-zte/zx297520v3.c
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2026 Stefan Dösinger
+ */
+
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+
+#include <linux/of_address.h>
+#include <linux/of_platform.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.52.0
^ permalink raw reply related
* [PATCH v3 0/8] Add support for ZTE zx297520v3
From: Stefan Dösinger @ 2026-04-14 21:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Linus Walleij, Arnd Bergmann, Krzysztof Kozlowski, Rob Herring
Hi,
This is a follow-up on my RFC patches from January [0]. 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 uboot 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 hardware to the device tree that already has existing drivers
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/
Stefan Dösinger (8):
ARM: zte: Add zx297520v3 platform support
dt-bindings: arm: Add zx297520v3 board binding
ARM: dts: Add D-Link DWR-932M support
ARM: zte: Add support for zx29 low level debug
ARM: dts: Add an armv7 timer for zx297520v3
ARM: zte: Bring back zx29 UART support
ARM: dts: Declare UART1 on zx297520v3 boards
ARM: defconfig: Add a zx29 defconfig file
Documentation/arch/arm/zte/zx297520v3.rst | 158 ++++++++++++++++++
.../devicetree/bindings/arm/zx29.yaml | 20 +++
MAINTAINERS | 6 +
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/dlink-dwr-932m.dts | 21 +++
arch/arm/boot/dts/zte/zx297520v3.dtsi | 83 +++++++++
arch/arm/configs/zx29_defconfig | 90 ++++++++++
arch/arm/include/debug/pl01x.S | 7 +
arch/arm/mach-zte/Kconfig | 24 +++
arch/arm/mach-zte/Makefile | 2 +
arch/arm/mach-zte/zx297520v3.c | 19 +++
drivers/tty/serial/amba-pl011.c | 37 ++++
include/linux/amba/bus.h | 6 +
17 files changed, 492 insertions(+)
create mode 100644 Documentation/arch/arm/zte/zx297520v3.rst
create mode 100644 Documentation/devicetree/bindings/arm/zx29.yaml
create mode 100644 arch/arm/boot/dts/zte/Makefile
create mode 100644 arch/arm/boot/dts/zte/dlink-dwr-932m.dts
create mode 100644 arch/arm/boot/dts/zte/zx297520v3.dtsi
create mode 100644 arch/arm/configs/zx29_defconfig
create mode 100644 arch/arm/mach-zte/Kconfig
create mode 100644 arch/arm/mach-zte/Makefile
create mode 100644 arch/arm/mach-zte/zx297520v3.c
--
2.52.0
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Alexis Lothoré @ 2026-04-14 20:44 UTC (permalink / raw)
To: Alexei Starovoitov, Alexis Lothoré
Cc: Andrey Konovalov, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
John Fastabend, David S. Miller, David Ahern, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, X86 ML, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, LKML, Network Development,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CAADnVQ+c9h_wuNwj8pjx885oNErGY7bxxCwKi+DiJ0XKSpyYfg@mail.gmail.com>
On Tue Apr 14, 2026 at 9:16 PM CEST, Alexei Starovoitov wrote:
> On Tue, Apr 14, 2026 at 11:41 AM Alexis Lothoré
> <alexis.lothore@bootlin.com> wrote:
>>
>> On Tue Apr 14, 2026 at 4:36 PM CEST, Alexei Starovoitov wrote:
>> > On Tue, Apr 14, 2026 at 6:13 AM Alexis Lothoré
>> > <alexis.lothore@bootlin.com> wrote:
>> >>
>> >> Hi Andrey, thanks for the prompt review !
[...]
>> > No. The performance penalty will be too high.
>>
>> Since we are mentioning it, I did not consider yet any performance
>> comparision/benchmarking (and I am not really familiar with usual bpf
>> performance validation practices for new bpf features). Is there any
>> existing test I should take a look at for this ? Maybe some specific
>> benches in tools/testing/selftests/bpf/bench ?
>
> So far everything in bpf/bench/ measures bpf infra like
> maps, kprobes, tracepoints, etc.
> We don't have benchmarks for bpf programs.
> So we don't know how well JITs are generating code
> and how much inlining done by the verifier, JITs actually helps.
>
> Puranjay is working on creating a SPECint like set of benchmarks.
>
> For this kasan work we should make the best decisions from
> performance point of view, like not wasting unnecessary call
> and not saving unnecessary registers. btw in the other patch
> I think you can skip saving of r10 and r11.
Noted, I'll do some checks and tests without those two.
> But we cannot quantify yet that avoiding extra call gives us N%.
>
> You can micro-benchmark, of course, but gotta be careful
> interpreting the results. It might be too easy to get into
> thinking that JIT must inline __asan_load() for the sake of performance.
Ok, interesting, thanks for those details
Alexis
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [GIT PULL] Apple SoC fixes for v7.0
From: Sven Peter @ 2026-04-14 20:24 UTC (permalink / raw)
To: soc; +Cc: asahi, linux-arm-kernel, linux-kernel
Hi,
Two fixes without any functional changes, they just update Sasha's email
everywhere and fix a typo in a dtsi file comment.
As discussed with Arnd I'm already sending out the PR now so that you guys can
decide when to merge this.
Thanks,
Sven
The following changes since commit 028ef9c96e96197026887c0f092424679298aae8:
Linux 7.0 (2026-04-12 13:48:06 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/sven/linux.git tags/apple-soc-fixes-7.0
for you to fetch changes up to c7ff53ef45b2f879576f7bbeb163828d04f5f491:
arm64: dts: apple: Fix spelling error (2026-04-14 22:13:19 +0200)
----------------------------------------------------------------
Apple SoC fixes for 7.0
Two commits without any functional changes that arrived just before the
merge window opened:
- Update Sasha's email address in all dt-bindings, MAINTAINERS and add
him to mailmap
- Fix a typo in spi1-nvram.dtsi
----------------------------------------------------------------
Axel Flordal (1):
arm64: dts: apple: Fix spelling error
Sasha Finkelstein (2):
mailmap: Update Sasha Finkelstein's email address
dt-bindings: Update Sasha Finkelstein's email address
.mailmap | 1 +
.../devicetree/bindings/display/apple,h7-display-pipe-mipi.yaml | 2 +-
Documentation/devicetree/bindings/display/apple,h7-display-pipe.yaml | 2 +-
Documentation/devicetree/bindings/display/panel/apple,summit.yaml | 2 +-
Documentation/devicetree/bindings/gpu/apple,agx.yaml | 2 +-
.../devicetree/bindings/input/touchscreen/apple,z2-multitouch.yaml | 2 +-
Documentation/devicetree/bindings/nvmem/apple,spmi-nvmem.yaml | 2 +-
Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml | 2 +-
Documentation/devicetree/bindings/spmi/apple,spmi.yaml | 2 +-
MAINTAINERS | 2 +-
arch/arm64/boot/dts/apple/spi1-nvram.dtsi | 2 +-
11 files changed, 11 insertions(+), 10 deletions(-)
^ permalink raw reply
* Re: [PATCH RESEND] arm64: dts: apple: fix spelling error
From: Sven Peter @ 2026-04-14 20:21 UTC (permalink / raw)
To: asahi, linux-arm-kernel, devicetree, linux-kernel, Axel Flordal
Cc: Sven Peter, Janne Grunau, Neal Gompa, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <2338500.vFx2qVVIhK@fedora>
On Wed, 08 Apr 2026 07:21:23 +0000, Axel Flordal wrote:
> Change "configiguration" to "configuration".
>
>
Applied to local tree (apple-soc/fixes-7.0), thanks!
[1/1] arm64: dts: apple: fix spelling error
https://github.com/AsahiLinux/linux/commit/c7ff53ef45b2
Best regards,
--
Sven Peter <sven@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 00/24] ARM64 PMU Partitioning
From: Colton Lewis @ 2026-04-14 19:55 UTC (permalink / raw)
To: Colton Lewis
Cc: will, oupton, kvm, pbonzini, corbet, linux, catalin.marinas, maz,
oliver.upton, mizhang, joey.gouly, suzuki.poulose, yuzenghui,
mark.rutland, shuah, gankulkarni, linux-doc, linux-kernel,
linux-arm-kernel, kvmarm, linux-perf-users, linux-kselftest
In-Reply-To: <gsntpl7a694p.fsf@coltonlewis-kvm.c.googlers.com>
Colton Lewis <coltonlewis@google.com> writes:
> Will Deacon <will@kernel.org> writes:
>> On Tue, Dec 09, 2025 at 03:00:59PM -0800, Oliver Upton wrote:
>>> On Tue, Dec 09, 2025 at 08:50:57PM +0000, Colton Lewis wrote:
>>> > This series creates a new PMU scheme on ARM, a partitioned PMU that
>>> > allows reserving a subset of counters for more direct guest access,
>>> > significantly reducing overhead. More details, including performance
>>> > benchmarks, can be read in the v1 cover letter linked below.
>>> >
>>> > An overview of what this series accomplishes was presented at KVM
>>> > Forum 2025. Slides [1] and video [2] are linked below.
>>> >
>>> > The long duration between v4 and v5 is due to time spent on this
>>> > project being monopolized preparing this feature for internal
>>> > production. As a result, there are too many improvements to fully list
>>> > here, but I will cover the notable ones.
>>> Thanks for reposting. I think there's still quite a bit of ground to
>>> cover on the KVM side of this, but I would definitely appreciate it if
>>> someone with more context on the perf side of things could chime in.
>>> Will, IIRC you had some thoughts around counter allocation, right?
>> Right, I was hoping that the host counter reservation could be more
>> dynamic than a cmdline option. Perf already has support for pinning
>> events to a CPU, so the concept of some counters being unavailable
>> shouldn't be too much for the driver to handle. You might just need to
>> create some fake pinned events so that perf code understands what is
>> happening.
> Thanks Will. I have a few followup questions:
> 1. Are you suggesting this be done whenever we enter a guest so the host
> always has access to the full range in host context? That would be the
> most dynamic.
> 2. How should we handle the possibility a real event already occupies a
> counter wanted by the guest? Is there a good way to create our fake
> pinned events then force a reschedule so perf moves the real events out
> of the way?
> 3. Is there an existing fake event type that tells perf not to touch
> hardware?
> 4. Can you point to any example code that already does something like
> this?
Thank you Will and Mark for meeting with me to discuss things in person.
Here's my main takeaways so the list can comment:
Will's initial idea doesn't work because there is no way for KVM to pin
counters in a way that takes priority over counters pinned by the host
and therefore guarantee reservation.
An alternate idea I am proposing is to call the perf core
sched_in/sched_out functionality during vcpu_load/vcpu_put when guest
counters need to be reserved/unreserved.
That means having perf vacate all the host counters temporarily,
modifying the arm_pmu.cntr_mask to add/remove the appropriate counters,
then having perf schedule all host events back on the new set. Perf is
capable of doing that without any significant changes.
This is simple and should work because arm_pmu.cntr_mask is already
accessible from the vcpu struct and modifying it is already how the
existing boot-time counter reservation works.
There are some tradeoffs to this approach that will need further
consideration. The first is how to handle event groups. Perf allows
events to be grouped such that they must all be scheduled in at once. If
the host has a larger group than the number of counters available while
the vcpu is loaded, then it simply won't be able to schedule that group
in for that time period. Another is whether it will be acceptable
performance-wise to put perf sched_in/sched_out in
vcpu_load/vcpu_put. I'm unsure how much delay that would add to those
paths.
Absent strong objections, I will be posting a series using this method.
Another idea that was not discussed that I had later is a middle
approach that is less dynamic but gives the user control over when the
perf sched_in/sched_out happens. Expose the existing boot-time parameter
as writable in sysfs and do the sched_out/modify mask/sched_in when that
is written rather than in vcpu_load.
^ permalink raw reply
* [PATCH 1/4] dt-bindings: clock: marvell,pxa1908: Add #reset-cells
From: Duje Mihanović @ 2026-04-14 19:51 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Karel Balej, linux-arm-kernel, linux-clk, devicetree,
linux-kernel, phone-devel, ~postmarketos/upstreaming,
Duje Mihanović
In-Reply-To: <20260414-pxa1908-clk-reset-v1-0-94bae5f3a8cf@dujemihanovic.xyz>
From: Duje Mihanović <duje@dujemihanovic.xyz>
The APBC and APBCP controllers have reset lines exposed. Give them
a #reset-cells so that they may be used as reset controllers.
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
.../devicetree/bindings/clock/marvell,pxa1908.yaml | 34 +++++++++++++++-------
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml b/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml
index 6f3a8578fe2a..0db5504013d5 100644
--- a/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml
+++ b/Documentation/devicetree/bindings/clock/marvell,pxa1908.yaml
@@ -37,6 +37,9 @@ properties:
'#power-domain-cells':
const: 1
+ '#reset-cells':
+ const: 1
+
required:
- compatible
- reg
@@ -44,16 +47,27 @@ required:
additionalProperties: false
-if:
- not:
- properties:
- compatible:
- contains:
- const: marvell,pxa1908-apmu
-
-then:
- properties:
- '#power-domain-cells': false
+allOf:
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ const: marvell,pxa1908-apmu
+ then:
+ properties:
+ '#power-domain-cells': false
+ - if:
+ not:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - marvell,pxa1908-apbc
+ - marvell,pxa1908-apbcp
+ then:
+ properties:
+ '#reset-cells': false
examples:
# APMU block:
--
2.53.0
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: marvell: mmp: pxa1908: Add reset cells
From: Duje Mihanović @ 2026-04-14 19:51 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Karel Balej, linux-arm-kernel, linux-clk, devicetree,
linux-kernel, phone-devel, ~postmarketos/upstreaming,
Duje Mihanović
In-Reply-To: <20260414-pxa1908-clk-reset-v1-0-94bae5f3a8cf@dujemihanovic.xyz>
From: Duje Mihanović <duje@dujemihanovic.xyz>
Add the newly implemented reset cells to the SoC dtsi.
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi b/arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi
index 5778bfdb8567..05b56a759e27 100644
--- a/arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi
+++ b/arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi
@@ -132,6 +132,7 @@ twsi1: i2c@10800 {
reg = <0x10800 0x64>;
interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&apbc PXA1908_CLK_TWSI1>;
+ resets = <&apbc PXA1908_CLK_TWSI1>;
mrvl,i2c-fast-mode;
status = "disabled";
};
@@ -143,6 +144,7 @@ twsi0: i2c@11000 {
reg = <0x11000 0x64>;
interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&apbc PXA1908_CLK_TWSI0>;
+ resets = <&apbc PXA1908_CLK_TWSI0>;
mrvl,i2c-fast-mode;
status = "disabled";
};
@@ -154,6 +156,7 @@ twsi3: i2c@13800 {
reg = <0x13800 0x64>;
interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&apbc PXA1908_CLK_TWSI3>;
+ resets = <&apbc PXA1908_CLK_TWSI3>;
mrvl,i2c-fast-mode;
status = "disabled";
};
@@ -162,6 +165,7 @@ apbc: clock-controller@15000 {
compatible = "marvell,pxa1908-apbc";
reg = <0x15000 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
uart0: serial@17000 {
@@ -169,6 +173,7 @@ uart0: serial@17000 {
reg = <0x17000 0x1000>;
interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&apbc PXA1908_CLK_UART0>;
+ resets = <&apbc PXA1908_CLK_UART0>;
reg-shift = <2>;
};
@@ -177,6 +182,7 @@ uart1: serial@18000 {
reg = <0x18000 0x1000>;
interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&apbc PXA1908_CLK_UART1>;
+ resets = <&apbc PXA1908_CLK_UART1>;
reg-shift = <2>;
};
@@ -188,6 +194,7 @@ gpio: gpio@19000 {
gpio-controller;
#gpio-cells = <2>;
clocks = <&apbc PXA1908_CLK_GPIO>;
+ resets = <&apbc PXA1908_CLK_GPIO>;
interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "gpio_mux";
interrupt-controller;
@@ -215,6 +222,7 @@ pwm0: pwm@1a000 {
compatible = "marvell,pxa250-pwm";
reg = <0x1a000 0x10>;
clocks = <&apbc PXA1908_CLK_PWM0>;
+ resets = <&apbc PXA1908_CLK_PWM0>;
#pwm-cells = <1>;
status = "disabled";
};
@@ -223,6 +231,7 @@ pwm1: pwm@1a400 {
compatible = "marvell,pxa250-pwm";
reg = <0x1a400 0x10>;
clocks = <&apbc PXA1908_CLK_PWM1>;
+ resets = <&apbc PXA1908_CLK_PWM1>;
#pwm-cells = <1>;
status = "disabled";
};
@@ -231,6 +240,7 @@ pwm2: pwm@1a800 {
compatible = "marvell,pxa250-pwm";
reg = <0x1a800 0x10>;
clocks = <&apbc PXA1908_CLK_PWM2>;
+ resets = <&apbc PXA1908_CLK_PWM2>;
#pwm-cells = <1>;
status = "disabled";
};
@@ -239,6 +249,7 @@ pwm3: pwm@1ac00 {
compatible = "marvell,pxa250-pwm";
reg = <0x1ac00 0x10>;
clocks = <&apbc PXA1908_CLK_PWM3>;
+ resets = <&apbc PXA1908_CLK_PWM3>;
#pwm-cells = <1>;
status = "disabled";
};
@@ -261,6 +272,7 @@ uart2: serial@36000 {
reg = <0x36000 0x1000>;
interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&apbcp PXA1908_CLK_UART2>;
+ resets = <&apbcp PXA1908_CLK_UART2>;
reg-shift = <2>;
};
@@ -271,6 +283,7 @@ twsi2: i2c@37000 {
reg = <0x37000 0x64>;
interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&apbcp PXA1908_CLK_TWSI2>;
+ resets = <&apbcp PXA1908_CLK_TWSI2>;
mrvl,i2c-fast-mode;
status = "disabled";
};
@@ -279,6 +292,7 @@ apbcp: clock-controller@3b000 {
compatible = "marvell,pxa1908-apbcp";
reg = <0x3b000 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
mpmu: clock-controller@50000 {
--
2.53.0
^ permalink raw reply related
* [PATCH 2/4] clk: mmp: pxa1908-apbc: Add reset cells
From: Duje Mihanović @ 2026-04-14 19:51 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Karel Balej, linux-arm-kernel, linux-clk, devicetree,
linux-kernel, phone-devel, ~postmarketos/upstreaming,
Duje Mihanović
In-Reply-To: <20260414-pxa1908-clk-reset-v1-0-94bae5f3a8cf@dujemihanovic.xyz>
From: Duje Mihanović <duje@dujemihanovic.xyz>
It has been concluded by comparing the gate clock masks and vendor code
between PXA1908/28 that PXA1908's APBC, similarly to PXA1928's APBC, has
controllable reset lines. Describe these in the driver for correctness.
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
drivers/clk/mmp/clk-pxa1908-apbc.c | 58 +++++++++++++++++++++++++++++---------
1 file changed, 44 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/mmp/clk-pxa1908-apbc.c b/drivers/clk/mmp/clk-pxa1908-apbc.c
index 3fd7b5e644f3..438ece4f047d 100644
--- a/drivers/clk/mmp/clk-pxa1908-apbc.c
+++ b/drivers/clk/mmp/clk-pxa1908-apbc.c
@@ -7,6 +7,7 @@
#include <dt-bindings/clock/marvell,pxa1908.h>
#include "clk.h"
+#include "reset.h"
#define APBC_UART0 0x0
#define APBC_UART1 0x4
@@ -44,22 +45,25 @@ static const char * const uart_parent_names[] = {"pll1_117", "uart_pll"};
static const char * const ssp_parent_names[] = {"pll1_d16", "pll1_d48", "pll1_d24", "pll1_d12"};
static struct mmp_param_gate_clk apbc_gate_clks[] = {
- {PXA1908_CLK_TWSI0, "twsi0_clk", "pll1_32", CLK_SET_RATE_PARENT, APBC_TWSI0, 0x7, 3, 0, 0, NULL},
- {PXA1908_CLK_TWSI1, "twsi1_clk", "pll1_32", CLK_SET_RATE_PARENT, APBC_TWSI1, 0x7, 3, 0, 0, NULL},
- {PXA1908_CLK_TWSI3, "twsi3_clk", "pll1_32", CLK_SET_RATE_PARENT, APBC_TWSI3, 0x7, 3, 0, 0, NULL},
- {PXA1908_CLK_GPIO, "gpio_clk", "vctcxo", CLK_SET_RATE_PARENT, APBC_GPIO, 0x7, 3, 0, 0, NULL},
- {PXA1908_CLK_KPC, "kpc_clk", "clk32", CLK_SET_RATE_PARENT, APBC_KPC, 0x7, 3, 0, MMP_CLK_GATE_NEED_DELAY, NULL},
- {PXA1908_CLK_RTC, "rtc_clk", "clk32", CLK_SET_RATE_PARENT, APBC_RTC, 0x87, 0x83, 0, MMP_CLK_GATE_NEED_DELAY, NULL},
+ {PXA1908_CLK_TWSI0, "twsi0_clk", "pll1_32", CLK_SET_RATE_PARENT, APBC_TWSI0, 0x3, 3, 0, 0, NULL},
+ {PXA1908_CLK_TWSI1, "twsi1_clk", "pll1_32", CLK_SET_RATE_PARENT, APBC_TWSI1, 0x3, 3, 0, 0, NULL},
+ {PXA1908_CLK_TWSI3, "twsi3_clk", "pll1_32", CLK_SET_RATE_PARENT, APBC_TWSI3, 0x3, 3, 0, 0, NULL},
+ {PXA1908_CLK_GPIO, "gpio_clk", "vctcxo", CLK_SET_RATE_PARENT, APBC_GPIO, 0x3, 3, 0, 0, NULL},
+ {PXA1908_CLK_KPC, "kpc_clk", "clk32", CLK_SET_RATE_PARENT, APBC_KPC, 0x3, 3, 0, MMP_CLK_GATE_NEED_DELAY, NULL},
+ {PXA1908_CLK_RTC, "rtc_clk", "clk32", CLK_SET_RATE_PARENT, APBC_RTC, 0x83, 0x83, 0, MMP_CLK_GATE_NEED_DELAY, NULL},
+ {PXA1908_CLK_PWM1, "pwm1_clk", "pwm01_apb_share", CLK_SET_RATE_PARENT, APBC_PWM1, 0x2, 2, 0, 0, NULL},
+ {PXA1908_CLK_PWM3, "pwm3_clk", "pwm23_apb_share", CLK_SET_RATE_PARENT, APBC_PWM3, 0x2, 2, 0, 0, NULL},
+ {PXA1908_CLK_UART0, "uart0_clk", "uart0_mux", CLK_SET_RATE_PARENT, APBC_UART0, 0x3, 3, 0, 0, &uart0_lock},
+ {PXA1908_CLK_UART1, "uart1_clk", "uart1_mux", CLK_SET_RATE_PARENT, APBC_UART1, 0x3, 3, 0, 0, &uart1_lock},
+ {PXA1908_CLK_THERMAL, "thermal_clk", NULL, 0, APBC_THERMAL, 0x3, 3, 0, 0, NULL},
+ {PXA1908_CLK_IPC_RST, "ipc_clk", NULL, 0, APBC_IPC_RST, 0x3, 3, 0, 0, NULL},
+ {PXA1908_CLK_SSP0, "ssp0_clk", "ssp0_mux", 0, APBC_SSP0, 0x3, 3, 0, 0, NULL},
+ {PXA1908_CLK_SSP2, "ssp2_clk", "ssp2_mux", 0, APBC_SSP2, 0x3, 3, 0, 0, NULL},
+};
+
+static struct mmp_param_gate_clk apbc_gate_no_reset_clks[] = {
{PXA1908_CLK_PWM0, "pwm0_clk", "pwm01_apb_share", CLK_SET_RATE_PARENT, APBC_PWM0, 0x2, 2, 0, 0, &pwm0_lock},
- {PXA1908_CLK_PWM1, "pwm1_clk", "pwm01_apb_share", CLK_SET_RATE_PARENT, APBC_PWM1, 0x6, 2, 0, 0, NULL},
{PXA1908_CLK_PWM2, "pwm2_clk", "pwm23_apb_share", CLK_SET_RATE_PARENT, APBC_PWM2, 0x2, 2, 0, 0, NULL},
- {PXA1908_CLK_PWM3, "pwm3_clk", "pwm23_apb_share", CLK_SET_RATE_PARENT, APBC_PWM3, 0x6, 2, 0, 0, NULL},
- {PXA1908_CLK_UART0, "uart0_clk", "uart0_mux", CLK_SET_RATE_PARENT, APBC_UART0, 0x7, 3, 0, 0, &uart0_lock},
- {PXA1908_CLK_UART1, "uart1_clk", "uart1_mux", CLK_SET_RATE_PARENT, APBC_UART1, 0x7, 3, 0, 0, &uart1_lock},
- {PXA1908_CLK_THERMAL, "thermal_clk", NULL, 0, APBC_THERMAL, 0x7, 3, 0, 0, NULL},
- {PXA1908_CLK_IPC_RST, "ipc_clk", NULL, 0, APBC_IPC_RST, 0x7, 3, 0, 0, NULL},
- {PXA1908_CLK_SSP0, "ssp0_clk", "ssp0_mux", 0, APBC_SSP0, 0x7, 3, 0, 0, NULL},
- {PXA1908_CLK_SSP2, "ssp2_clk", "ssp2_mux", 0, APBC_SSP2, 0x7, 3, 0, 0, NULL},
};
static struct mmp_param_mux_clk apbc_mux_clks[] = {
@@ -89,6 +93,30 @@ static void pxa1908_apb_periph_clk_init(struct pxa1908_clk_unit *pxa_unit)
ARRAY_SIZE(apbc_mux_clks));
mmp_register_gate_clks(unit, apbc_gate_clks, pxa_unit->base,
ARRAY_SIZE(apbc_gate_clks));
+ mmp_register_gate_clks(unit, apbc_gate_no_reset_clks, pxa_unit->base,
+ ARRAY_SIZE(apbc_gate_no_reset_clks));
+}
+
+/* Taken from clk-of-pxa1928.c */
+static void pxa1908_clk_reset_init(struct device_node *np,
+ struct pxa1908_clk_unit *pxa_unit)
+{
+ struct mmp_clk_reset_cell *cells;
+ int nr_cells = ARRAY_SIZE(apbc_gate_clks);
+
+ cells = kzalloc_objs(*cells, nr_cells);
+ if (!cells)
+ return;
+
+ for (int i = 0; i < nr_cells; i++) {
+ cells[i].clk_id = apbc_gate_clks[i].id;
+ cells[i].reg = pxa_unit->base + apbc_gate_clks[i].offset;
+ cells[i].bits = BIT(2);
+ cells[i].flags = 0;
+ cells[i].lock = apbc_gate_clks[i].lock;
+ };
+
+ mmp_clk_reset_register(np, cells, nr_cells);
}
static int pxa1908_apbc_probe(struct platform_device *pdev)
@@ -107,6 +135,8 @@ static int pxa1908_apbc_probe(struct platform_device *pdev)
pxa1908_apb_periph_clk_init(pxa_unit);
+ pxa1908_clk_reset_init(pdev->dev.of_node, pxa_unit);
+
return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH 3/4] clk: mmp: pxa1908-apbcp: Add reset cells
From: Duje Mihanović @ 2026-04-14 19:51 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Karel Balej, linux-arm-kernel, linux-clk, devicetree,
linux-kernel, phone-devel, ~postmarketos/upstreaming,
Duje Mihanović
In-Reply-To: <20260414-pxa1908-clk-reset-v1-0-94bae5f3a8cf@dujemihanovic.xyz>
From: Duje Mihanović <duje@dujemihanovic.xyz>
It has been concluded by comparing the gate clock masks and vendor code
between PXA1908/28 that PXA1908's APBCP, similarly to PXA1928's APBC,
has controllable reset lines. Describe these in the driver for
correctness.
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
drivers/clk/mmp/clk-pxa1908-apbcp.c | 31 ++++++++++++++++++++++++++++---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/mmp/clk-pxa1908-apbcp.c b/drivers/clk/mmp/clk-pxa1908-apbcp.c
index f638d7e89b47..1aa476103553 100644
--- a/drivers/clk/mmp/clk-pxa1908-apbcp.c
+++ b/drivers/clk/mmp/clk-pxa1908-apbcp.c
@@ -7,6 +7,7 @@
#include <dt-bindings/clock/marvell,pxa1908.h>
#include "clk.h"
+#include "reset.h"
#define APBCP_UART2 0x1c
#define APBCP_TWSI2 0x28
@@ -24,9 +25,9 @@ static DEFINE_SPINLOCK(uart2_lock);
static const char * const uart_parent_names[] = {"pll1_117", "uart_pll"};
static struct mmp_param_gate_clk apbcp_gate_clks[] = {
- {PXA1908_CLK_UART2, "uart2_clk", "uart2_mux", CLK_SET_RATE_PARENT, APBCP_UART2, 0x7, 0x3, 0x0, 0, &uart2_lock},
- {PXA1908_CLK_TWSI2, "twsi2_clk", "pll1_32", CLK_SET_RATE_PARENT, APBCP_TWSI2, 0x7, 0x3, 0x0, 0, NULL},
- {PXA1908_CLK_AICER, "ripc_clk", NULL, 0, APBCP_AICER, 0x7, 0x2, 0x0, 0, NULL},
+ {PXA1908_CLK_UART2, "uart2_clk", "uart2_mux", CLK_SET_RATE_PARENT, APBCP_UART2, 0x3, 0x3, 0x0, 0, &uart2_lock},
+ {PXA1908_CLK_TWSI2, "twsi2_clk", "pll1_32", CLK_SET_RATE_PARENT, APBCP_TWSI2, 0x3, 0x3, 0x0, 0, NULL},
+ {PXA1908_CLK_AICER, "ripc_clk", NULL, 0, APBCP_AICER, 0x3, 0x2, 0x0, 0, NULL},
};
static struct mmp_param_mux_clk apbcp_mux_clks[] = {
@@ -43,6 +44,28 @@ static void pxa1908_apb_p_periph_clk_init(struct pxa1908_clk_unit *pxa_unit)
ARRAY_SIZE(apbcp_gate_clks));
}
+/* Taken from clk-of-pxa1928.c */
+static void pxa1908_clk_reset_init(struct device_node *np,
+ struct pxa1908_clk_unit *pxa_unit)
+{
+ struct mmp_clk_reset_cell *cells;
+ int nr_cells = ARRAY_SIZE(apbcp_gate_clks);
+
+ cells = kzalloc_objs(*cells, nr_cells);
+ if (!cells)
+ return;
+
+ for (int i = 0; i < nr_cells; i++) {
+ cells[i].clk_id = apbcp_gate_clks[i].id;
+ cells[i].reg = pxa_unit->base + apbcp_gate_clks[i].offset;
+ cells[i].bits = BIT(2);
+ cells[i].flags = 0;
+ cells[i].lock = apbcp_gate_clks[i].lock;
+ };
+
+ mmp_clk_reset_register(np, cells, nr_cells);
+}
+
static int pxa1908_apbcp_probe(struct platform_device *pdev)
{
struct pxa1908_clk_unit *pxa_unit;
@@ -59,6 +82,8 @@ static int pxa1908_apbcp_probe(struct platform_device *pdev)
pxa1908_apb_p_periph_clk_init(pxa_unit);
+ pxa1908_clk_reset_init(pdev->dev.of_node, pxa_unit);
+
return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH 0/4] PXA1908 clock controller resets
From: Duje Mihanović @ 2026-04-14 19:51 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Karel Balej, linux-arm-kernel, linux-clk, devicetree,
linux-kernel, phone-devel, ~postmarketos/upstreaming,
Duje Mihanović
Hello,
This series adds the resets found on Marvell PXA1908's APBC and APBCP
clock controllers.
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
Duje Mihanović (4):
dt-bindings: clock: marvell,pxa1908: Add #reset-cells
clk: mmp: pxa1908-apbc: Add reset cells
clk: mmp: pxa1908-apbcp: Add reset cells
arm64: dts: marvell: mmp: pxa1908: Add reset cells
.../devicetree/bindings/clock/marvell,pxa1908.yaml | 34 +++++++++----
arch/arm64/boot/dts/marvell/mmp/pxa1908.dtsi | 14 ++++++
drivers/clk/mmp/clk-pxa1908-apbc.c | 58 ++++++++++++++++------
drivers/clk/mmp/clk-pxa1908-apbcp.c | 31 ++++++++++--
4 files changed, 110 insertions(+), 27 deletions(-)
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260414-pxa1908-clk-reset-179c3f1d6214
Best regards,
--
Duje Mihanović <duje@dujemihanovic.xyz>
^ permalink raw reply
* Re: [PATCH 1/1] virt: arm-cca-guest: fix error check for RSI_INCOMPLETE
From: Catalin Marinas @ 2026-04-14 19:22 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, Sami Mujawar
Cc: Will Deacon, steven.price, suzuki.poulose, gshan, YeoReum.Yun,
Jagdish Gediya
In-Reply-To: <20260410163636.259443-1-sami.mujawar@arm.com>
On Fri, 10 Apr 2026 17:36:36 +0100, Sami Mujawar wrote:
> The RSI interface can return RSI_INCOMPLETE when a report spans
> multiple granules. This is an expected condition and should not be
> treated as a fatal error.
>
> Currently, arm_cca_report_new() checks for `info.result != RSI_SUCCESS`
> and bails out, which incorrectly flags RSI_INCOMPLETE as a failure.
> Fix the check to only break out on results other than RSI_SUCCESS or
> RSI_INCOMPLETE.
>
> [...]
Applied to arm64 (for-next/misc), thanks!
[1/1] virt: arm-cca-guest: fix error check for RSI_INCOMPLETE
https://git.kernel.org/arm64/c/e534e9d13d0b
^ permalink raw reply
* Re: [PATCH] arm64/hwcap: Include kernel-hwcap.h in list of generated files
From: Catalin Marinas @ 2026-04-14 19:22 UTC (permalink / raw)
To: Will Deacon, Mark Brown; +Cc: Marek Vasut, linux-arm-kernel, linux-kernel
In-Reply-To: <20260413-arm64-hwcap-gen-fix-v1-1-26c56aed6908@kernel.org>
On Mon, 13 Apr 2026 16:44:11 +0100, Mark Brown wrote:
> When adding generation for the kernel internal constants for hwcaps the
> generated file was not explicitly flagged as such in the build system,
> causing it to be regenerated on each build. This wasn't obvious when the
> series the change was included in was developed since it was all about
> changes that trigger rebuilds anyway.
>
>
> [...]
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64/hwcap: Include kernel-hwcap.h in list of generated files
https://git.kernel.org/arm64/c/680b961ebf41
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Alexei Starovoitov @ 2026-04-14 19:16 UTC (permalink / raw)
To: Alexis Lothoré
Cc: Andrey Konovalov, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
John Fastabend, David S. Miller, David Ahern, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, X86 ML, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, LKML, Network Development,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <DHT3JV7GTOBL.29205LGGNEDSH@bootlin.com>
On Tue, Apr 14, 2026 at 11:41 AM Alexis Lothoré
<alexis.lothore@bootlin.com> wrote:
>
> On Tue Apr 14, 2026 at 4:36 PM CEST, Alexei Starovoitov wrote:
> > On Tue, Apr 14, 2026 at 6:13 AM Alexis Lothoré
> > <alexis.lothore@bootlin.com> wrote:
> >>
> >> Hi Andrey, thanks for the prompt review !
> >>
> >> On Tue Apr 14, 2026 at 12:19 AM CEST, Andrey Konovalov wrote:
> >> > On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation)
> >> > <alexis.lothore@bootlin.com> wrote:
> >> >>
> >>
> >> [...]
> >>
> >> >> +#ifdef CONFIG_KASAN_GENERIC
> >> >> +void __asan_load1(void *p);
> >> >> +void __asan_store1(void *p);
> >> >> +void __asan_load2(void *p);
> >> >> +void __asan_store2(void *p);
> >> >> +void __asan_load4(void *p);
> >> >> +void __asan_store4(void *p);
> >> >> +void __asan_load8(void *p);
> >> >> +void __asan_store8(void *p);
> >> >> +void __asan_load16(void *p);
> >> >> +void __asan_store16(void *p);
> >> >> +#endif /* CONFIG_KASAN_GENERIC */
> >> >
> >> > This looks ugly, let's not do this unless it's really required.
> >> >
> >> > You can just use kasan_check_read/write() instead - these are public
> >> > wrappers around the same shadow memory checking functions. And they
> >> > also work with the SW_TAGS mode, in case the BPF would want to use
> >> > that mode at some point. (For HW_TAGS, we only have kasan_check_byte()
> >> > that checks a single byte, but it can be extended in the future if
> >> > required to be used by BPF.)
> >>
> >> ACK, I'll try to use those kasan_check_read and kasan_check_write rather
> >> than __asan_{load,store}X.
> >
> > No. The performance penalty will be too high.
>
> Since we are mentioning it, I did not consider yet any performance
> comparision/benchmarking (and I am not really familiar with usual bpf
> performance validation practices for new bpf features). Is there any
> existing test I should take a look at for this ? Maybe some specific
> benches in tools/testing/selftests/bpf/bench ?
So far everything in bpf/bench/ measures bpf infra like
maps, kprobes, tracepoints, etc.
We don't have benchmarks for bpf programs.
So we don't know how well JITs are generating code
and how much inlining done by the verifier, JITs actually helps.
Puranjay is working on creating a SPECint like set of benchmarks.
For this kasan work we should make the best decisions from
performance point of view, like not wasting unnecessary call
and not saving unnecessary registers. btw in the other patch
I think you can skip saving of r10 and r11.
But we cannot quantify yet that avoiding extra call gives us N%.
You can micro-benchmark, of course, but gotta be careful
interpreting the results. It might be too easy to get into
thinking that JIT must inline __asan_load() for the sake of performance.
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Alexis Lothoré @ 2026-04-14 18:41 UTC (permalink / raw)
To: Alexei Starovoitov, Alexis Lothoré
Cc: Andrey Konovalov, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
John Fastabend, David S. Miller, David Ahern, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, X86 ML, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, LKML, Network Development,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CAADnVQLJ=fJ7t1i2+_RYqU1gqYqiLP9Zrwo4vdZsgzjK_yzJTQ@mail.gmail.com>
On Tue Apr 14, 2026 at 4:36 PM CEST, Alexei Starovoitov wrote:
> On Tue, Apr 14, 2026 at 6:13 AM Alexis Lothoré
> <alexis.lothore@bootlin.com> wrote:
>>
>> Hi Andrey, thanks for the prompt review !
>>
>> On Tue Apr 14, 2026 at 12:19 AM CEST, Andrey Konovalov wrote:
>> > On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation)
>> > <alexis.lothore@bootlin.com> wrote:
>> >>
>>
>> [...]
>>
>> >> +#ifdef CONFIG_KASAN_GENERIC
>> >> +void __asan_load1(void *p);
>> >> +void __asan_store1(void *p);
>> >> +void __asan_load2(void *p);
>> >> +void __asan_store2(void *p);
>> >> +void __asan_load4(void *p);
>> >> +void __asan_store4(void *p);
>> >> +void __asan_load8(void *p);
>> >> +void __asan_store8(void *p);
>> >> +void __asan_load16(void *p);
>> >> +void __asan_store16(void *p);
>> >> +#endif /* CONFIG_KASAN_GENERIC */
>> >
>> > This looks ugly, let's not do this unless it's really required.
>> >
>> > You can just use kasan_check_read/write() instead - these are public
>> > wrappers around the same shadow memory checking functions. And they
>> > also work with the SW_TAGS mode, in case the BPF would want to use
>> > that mode at some point. (For HW_TAGS, we only have kasan_check_byte()
>> > that checks a single byte, but it can be extended in the future if
>> > required to be used by BPF.)
>>
>> ACK, I'll try to use those kasan_check_read and kasan_check_write rather
>> than __asan_{load,store}X.
>
> No. The performance penalty will be too high.
Since we are mentioning it, I did not consider yet any performance
comparision/benchmarking (and I am not really familiar with usual bpf
performance validation practices for new bpf features). Is there any
existing test I should take a look at for this ? Maybe some specific
benches in tools/testing/selftests/bpf/bench ?
> hw_tags won't work without corresponding JIT work.
> I see no point sacrificing performance for aesthetics.
> __asan_load/storeX is what compilers emit.
> In that sense JIT is a compiler it should emit exactly the same.
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 3/3] iio: adc: xilinx-ams: refactor alarm mapping to table-driven approach
From: Andy Shevchenko @ 2026-04-14 18:40 UTC (permalink / raw)
To: Guilherme Ivo Bozi
Cc: Salih Erim, Conall O'Griofa, Jonathan Cameron, Michal Simek,
David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260414103316.18455-4-guilherme.bozi@usp.br>
On Tue, Apr 14, 2026 at 07:29:19AM -0300, Guilherme Ivo Bozi wrote:
> Replace multiple open-coded switch statements that map between
> scan_index, alarm bits, and register offsets with a centralized
> table-driven approach.
>
> Introduce a struct-based alarm_map to describe the relationship
> between scan indices and alarm offsets, and add a helper to
> translate scan_index to event IDs. This removes duplicated logic
> across ams_get_alarm_offset(), ams_event_to_channel(), and
> ams_get_alarm_mask().
>
> The new approach improves maintainability, reduces code size,
> and makes it easier to extend or modify alarm mappings in the
> future, while preserving existing behavior.
...
> +static const struct ams_alarm_map alarm_map[] = {
> + [AMS_ALARM_BIT_TEMP] = { AMS_SEQ_TEMP, AMS_ALARM_TEMP },
> + [AMS_ALARM_BIT_SUPPLY1] = { AMS_SEQ_SUPPLY1, AMS_ALARM_SUPPLY1 },
> + [AMS_ALARM_BIT_SUPPLY2] = { AMS_SEQ_SUPPLY2, AMS_ALARM_SUPPLY2 },
> + [AMS_ALARM_BIT_SUPPLY3] = { AMS_SEQ_SUPPLY3, AMS_ALARM_SUPPLY3 },
> + [AMS_ALARM_BIT_SUPPLY4] = { AMS_SEQ_SUPPLY4, AMS_ALARM_SUPPLY4 },
> + [AMS_ALARM_BIT_SUPPLY5] = { AMS_SEQ_SUPPLY5, AMS_ALARM_SUPPLY5 },
> + [AMS_ALARM_BIT_SUPPLY6] = { AMS_SEQ_SUPPLY6, AMS_ALARM_SUPPLY6 },
> + [AMS_ALARM_BIT_RESERVED] = { 0, AMS_ALARM_NONE },
> + [AMS_ALARM_BIT_SUPPLY7] = { AMS_SEQ_SUPPLY7, AMS_ALARM_SUPPLY7 },
> + [AMS_ALARM_BIT_SUPPLY8] = { AMS_SEQ_SUPPLY8, AMS_ALARM_SUPPLY8 },
> + [AMS_ALARM_BIT_SUPPLY9] = { AMS_SEQ_SUPPLY9, AMS_ALARM_SUPPLY9 },
> + [AMS_ALARM_BIT_SUPPLY10] = { AMS_SEQ_SUPPLY10, AMS_ALARM_SUPPLY10 },
> + [AMS_ALARM_BIT_VCCAMS] = { AMS_SEQ_VCCAMS, AMS_ALARM_VCCAMS },
> + [AMS_ALARM_BIT_TEMP_REMOTE] = { AMS_SEQ_TEMP_REMOTE, AMS_ALARM_TEMP_REMOTE }
Haven't noticed before, please leave a trailing comma here as it is not
semantically a terminator entry.
> +};
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 1/3] iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling
From: Andy Shevchenko @ 2026-04-14 18:37 UTC (permalink / raw)
To: Guilherme Ivo Bozi
Cc: Salih Erim, Conall O'Griofa, Jonathan Cameron, Michal Simek,
David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260414103316.18455-2-guilherme.bozi@usp.br>
On Tue, Apr 14, 2026 at 07:29:17AM -0300, Guilherme Ivo Bozi wrote:
> ams_event_to_channel() may return a pointer past the end of
> dev->channels when no matching scan_index is found. This can lead
> to invalid memory access in ams_handle_event().
>
> Add a bounds check in ams_event_to_channel() and return NULL when
> no channel is found. Also guard the caller to safely handle this
> case.
...
> + if (i >= dev->num_channels)
The '==' is clearer. Otherwise, please justify the '>' part.
> + return NULL;
...
TBH I do not see how this code is not a dead code. But for the sake of
robustness it might be added. I leave it up to the maintainer.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2 2/3] drm/exynos: remove bridge when component_add fails
From: Osama Abdelkader @ 2026-04-14 17:54 UTC (permalink / raw)
To: luca.ceresoli, Inki Dae, Seung-Woo Kim, Kyungmin Park,
David Airlie, Simona Vetter, Krzysztof Kozlowski, Alim Akhtar,
dri-devel, linux-arm-kernel, linux-samsung-soc, linux-kernel
Cc: Osama Abdelkader
In-Reply-To: <20260414175417.144625-1-osama.abdelkader@gmail.com>
Use devm_drm_bridge_add() so the bridge is released if probe fails after
registration, and drop the manual drm_bridge_remove() in remove().
Check the return value of devm_drm_bridge_add().
v2: devm_drm_bridge_add instead of drm_bridge_add + goto remove_bridge
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index 29a8366513fa..e68c954ec3e6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -423,7 +423,9 @@ static int exynos_mic_probe(struct platform_device *pdev)
mic->bridge.of_node = dev->of_node;
- drm_bridge_add(&mic->bridge);
+ ret = devm_drm_bridge_add(dev, &mic->bridge);
+ if (ret)
+ goto err;
pm_runtime_enable(dev);
@@ -443,12 +445,8 @@ static int exynos_mic_probe(struct platform_device *pdev)
static void exynos_mic_remove(struct platform_device *pdev)
{
- struct exynos_mic *mic = platform_get_drvdata(pdev);
-
component_del(&pdev->dev, &exynos_mic_component_ops);
pm_runtime_disable(&pdev->dev);
-
- drm_bridge_remove(&mic->bridge);
}
static const struct of_device_id exynos_mic_of_match[] = {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 2/9] coresight: etm4x: exclude ss_status from drvdata->config
From: Yeoreum Yun @ 2026-04-14 16:59 UTC (permalink / raw)
To: Leo Yan
Cc: coresight, linux-arm-kernel, linux-kernel, suzuki.poulose,
mike.leach, james.clark, alexander.shishkin, jie.gan
In-Reply-To: <20260414160441.GF356832@e132581.arm.com>
Hi Leo,
> On Mon, Apr 13, 2026 at 03:19:55PM +0100, Yeoreum Yun wrote:
> > The purpose of TRCSSCSRn register is to show status of
> > the corresponding Single-shot Comparator Control and input supports.
> > That means writable field's purpose for reset or restore from idle status
> > not for configuration.
> >
> > Therefore, exclude ss_status from drvdata->config, move it to etm4x_caps.
> > This includes remove TRCSSCRn from configurable item and
> > remove saving in etm4_disable_hw().
> >
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > ---
> > .../hwtracing/coresight/coresight-etm4x-cfg.c | 1 -
> > .../hwtracing/coresight/coresight-etm4x-core.c | 18 +++++-------------
> > .../coresight/coresight-etm4x-sysfs.c | 7 ++-----
> > drivers/hwtracing/coresight/coresight-etm4x.h | 4 +++-
> > 4 files changed, 10 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> > index c302072b293a..d14d7c8a23e5 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> > @@ -86,7 +86,6 @@ static int etm4_cfg_map_reg_offset(struct etmv4_drvdata *drvdata,
> > off_mask = (offset & GENMASK(11, 5));
> > do {
> > CHECKREGIDX(TRCSSCCRn(0), ss_ctrl, idx, off_mask);
> > - CHECKREGIDX(TRCSSCSRn(0), ss_status, idx, off_mask);
> > CHECKREGIDX(TRCSSPCICRn(0), ss_pe_cmp, idx, off_mask);
> > } while (0);
> > } else if ((offset >= TRCCIDCVRn(0)) && (offset <= TRCVMIDCVRn(7))) {
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > index 6443f3717b37..8ebfd3924143 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > @@ -91,7 +91,7 @@ static bool etm4x_sspcicrn_present(struct etmv4_drvdata *drvdata, int n)
> > const struct etmv4_caps *caps = &drvdata->caps;
> >
> > return (n < caps->nr_ss_cmp) && caps->nr_pe &&
> > - (drvdata->config.ss_status[n] & TRCSSCSRn_PC);
> > + (caps->ss_status[n] & TRCSSCSRn_PC);
>
> Nitpick: The naming 'ss_status' is a bit confused for capability.
> Could we rename 'ss_status' to 'ss_comparator' or a simple one
> 'ss_cmp' ?
Okay.
>
> > }
> >
> > u64 etm4x_sysreg_read(u32 offset, bool _relaxed, bool _64bit)
> > @@ -571,11 +571,9 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata)
> > etm4x_relaxed_write32(csa, config->res_ctrl[i], TRCRSCTLRn(i));
> >
> > for (i = 0; i < caps->nr_ss_cmp; i++) {
> > - /* always clear status bit on restart if using single-shot */
> > - if (config->ss_ctrl[i] || config->ss_pe_cmp[i])
> > - config->ss_status[i] &= ~TRCSSCSRn_STATUS;
> > etm4x_relaxed_write32(csa, config->ss_ctrl[i], TRCSSCCRn(i));
> > - etm4x_relaxed_write32(csa, config->ss_status[i], TRCSSCSRn(i));
> > + /* always clear status and pending bits on restart if using single-shot */
> > + etm4x_relaxed_write32(csa, caps->ss_status[i], TRCSSCSRn(i));
>
> It is a bit weird to use caps to write a register. A smooth way is to
> clear STATUS and PENDING bits based on the read back value:
>
> val = etm4x_relaxed_read32(csa, TRCSSCSRn(i));
> val &= ~(TRCSSCSRn_STATUS | TRCSSCSRn_PENDING);
> etm4x_relaxed_write32(csa, val, TRCSSCSRn(i));
TBH, this is what I want to avoid. anyway Why do we need to
read again TRCSSCSR<n>? I think it's enough to write caps->ss_cmp
for clear purpose or
since the cap->ss_cmp will be all RO fields, It seems to better
to write "0" in here without reading TRCSSSR again.
>
> > if (etm4x_sspcicrn_present(drvdata, i))
> > etm4x_relaxed_write32(csa, config->ss_pe_cmp[i], TRCSSPCICRn(i));
> > }
> > @@ -1053,12 +1051,6 @@ static void etm4_disable_hw(struct etmv4_drvdata *drvdata)
> >
> > etm4_disable_trace_unit(drvdata);
> >
> > - /* read the status of the single shot comparators */
> > - for (i = 0; i < caps->nr_ss_cmp; i++) {
> > - config->ss_status[i] =
> > - etm4x_relaxed_read32(csa, TRCSSCSRn(i));
> > - }
> > -
> > /* read back the current counter values */
> > for (i = 0; i < caps->nr_cntr; i++) {
> > config->cntr_val[i] =
> > @@ -1501,8 +1493,8 @@ static void etm4_init_arch_data(void *info)
> > */
> > caps->nr_ss_cmp = FIELD_GET(TRCIDR4_NUMSSCC_MASK, etmidr4);
> > for (i = 0; i < caps->nr_ss_cmp; i++) {
> > - drvdata->config.ss_status[i] =
> > - etm4x_relaxed_read32(csa, TRCSSCSRn(i));
> > + caps->ss_status[i] = etm4x_relaxed_read32(csa, TRCSSCSRn(i));
> > + caps->ss_status[i] &= ~(TRCSSCSRn_STATUS | TRCSSCSRn_PENDING);
>
> For init cap, we can use explict way:
>
> caps->ss_cmp &= (TRCSSCSRn_PC | TRCSSCSRn_DV |
> TRCSSCSRn_DA | TRCSSCSRn_INST);
Okay.
>
> > }
> > /* NUMCIDC, bits[27:24] number of Context ID comparators for tracing */
> > caps->numcidc = FIELD_GET(TRCIDR4_NUMCIDC_MASK, etmidr4);
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > index 50408215d1ac..dd62f01674cf 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > @@ -1827,8 +1827,6 @@ static ssize_t sshot_ctrl_store(struct device *dev,
> > raw_spin_lock(&drvdata->spinlock);
> > idx = config->ss_idx;
> > config->ss_ctrl[idx] = FIELD_PREP(TRCSSCCRn_SAC_ARC_RST_MASK, val);
> > - /* must clear bit 31 in related status register on programming */
> > - config->ss_status[idx] &= ~TRCSSCSRn_STATUS;
> > raw_spin_unlock(&drvdata->spinlock);
> > return size;
> > }
> > @@ -1839,10 +1837,11 @@ static ssize_t sshot_status_show(struct device *dev,
> > {
> > unsigned long val;
> > struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + const struct etmv4_caps *caps = &drvdata->caps;
> > struct etmv4_config *config = &drvdata->config;
> >
> > raw_spin_lock(&drvdata->spinlock);
> > - val = config->ss_status[config->ss_idx];
> > + val = caps->ss_status[config->ss_idx];
>
> I think cap->ss_cmp is a good refactoring, but for legacy reason, I am
> just wandering if we still need config->ss_status so that it can record
> the lastest status (mainly for STATUS bit and PENDING bit).
>
> Otherwise, this Sysfs interface can only provide capability rather
> than status value.
The legacy *totally* isn't understandable.
Since config->ss_status is *updated* at "disable" -- end of sysfs session,
STATUS and PENDING bit doesn't have any meaning in here
and while running a session config->ss_status isn't updated all
So, I don't believe there was any user who care about this bit via
sysfs interface.
Therefore, I think we can refactor with caps->ss_cmp. let's drop the
useless and meaningless information.
>
> Thanks,
> Leo
>
> > raw_spin_unlock(&drvdata->spinlock);
> > return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > }
> > @@ -1877,8 +1876,6 @@ static ssize_t sshot_pe_ctrl_store(struct device *dev,
> > raw_spin_lock(&drvdata->spinlock);
> > idx = config->ss_idx;
> > config->ss_pe_cmp[idx] = FIELD_PREP(TRCSSPCICRn_PC_MASK, val);
> > - /* must clear bit 31 in related status register on programming */
> > - config->ss_status[idx] &= ~TRCSSCSRn_STATUS;
> > raw_spin_unlock(&drvdata->spinlock);
> > return size;
> > }
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
> > index 8168676f2945..8864cfb76bad 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x.h
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
> > @@ -213,6 +213,7 @@
> > #define TRCACATRn_EXLEVEL_MASK GENMASK(14, 8)
> >
> > #define TRCSSCSRn_STATUS BIT(31)
> > +#define TRCSSCSRn_PENDING BIT(30)
> > #define TRCSSCCRn_SAC_ARC_RST_MASK GENMASK(24, 0)
> >
> > #define TRCSSPCICRn_PC_MASK GENMASK(7, 0)
> > @@ -861,6 +862,7 @@ enum etm_impdef_type {
> > * @lpoverride: If the implementation can support low-power state over.
> > * @skip_power_up: Indicates if an implementation can skip powering up
> > * the trace unit.
> > + * @ss_status: The status of the corresponding single-shot comparator.
> > */
> > struct etmv4_caps {
> > u8 nr_pe;
> > @@ -899,6 +901,7 @@ struct etmv4_caps {
> > bool atbtrig : 1;
> > bool lpoverride : 1;
> > bool skip_power_up : 1;
> > + u32 ss_status[ETM_MAX_SS_CMP];
> > };
> >
> > /**
> > @@ -977,7 +980,6 @@ struct etmv4_config {
> > u32 res_ctrl[ETM_MAX_RES_SEL]; /* TRCRSCTLRn */
> > u8 ss_idx;
> > u32 ss_ctrl[ETM_MAX_SS_CMP];
> > - u32 ss_status[ETM_MAX_SS_CMP];
> > u32 ss_pe_cmp[ETM_MAX_SS_CMP];
> > u8 addr_idx;
> > u64 addr_val[ETM_MAX_SINGLE_ADDR_CMP];
> > --
> > LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
> >
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH v4 3/9] coresight: etm4x: fix leaked trace id
From: Yeoreum Yun @ 2026-04-14 16:50 UTC (permalink / raw)
To: Leo Yan
Cc: coresight, linux-arm-kernel, linux-kernel, suzuki.poulose,
mike.leach, james.clark, alexander.shishkin, jie.gan
In-Reply-To: <20260414163221.GG356832@e132581.arm.com>
Hi,
> On Mon, Apr 13, 2026 at 03:19:56PM +0100, Yeoreum Yun wrote:
> > If etm4_enable_sysfs() fails in cscfg_csdev_enable_active_config(),
> > the trace ID may be leaked because it is not released.
> >
> > To address this, call etm4_release_trace_id() when etm4_enable_sysfs()
> > fails in cscfg_csdev_enable_active_config().
> >
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > ---
> > drivers/hwtracing/coresight/coresight-etm4x-core.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > index 8ebfd3924143..1bc9f13e33f7 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > @@ -918,8 +918,10 @@ static int etm4_enable_sysfs(struct coresight_device *csdev, struct coresight_pa
> > cscfg_config_sysfs_get_active_cfg(&cfg_hash, &preset);
> > if (cfg_hash) {
> > ret = cscfg_csdev_enable_active_config(csdev, cfg_hash, preset);
> > - if (ret)
> > + if (ret) {
> > + etm4_release_trace_id(drvdata);
>
> I am not familiar with the trace ID, seems to me, it just allocate a ID
> for each tracer from the ID map and then always use this cached ID for
> the tracers.
>
> If so, even an ID is reserved for failures, and the ID map is big enough
> for each CPU, we don't need to worry memory leak or ID used out issue ?
>
Agree. Practically, this is not a big issue and I don't think
because of this new id couldn't be allocated in 128
although the one id is occupied by cpu while source is disabled.
However, in theory, this could lead to an ID leak,
so it would be better to release it in error cases.
[...]
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [GIT PULL] Kbuild and Kconfig changes for v7.1
From: pr-tracker-bot @ 2026-04-14 16:46 UTC (permalink / raw)
To: Nicolas Schier
Cc: Linus Torvalds, Alexander Coffin, Ard Biesheuvel, Arnd Bergmann,
Bill Wendling, David Howells, Dodji Seketeli, H. Peter Anvin,
Helge Deller, John Moon, Jonathan Corbet, Josh Poimboeuf,
Justin Stitt, Kees Cook, Masahiro Yamada, Nathan Chancellor,
Nick Desaulniers, Shuah Khan, Song Liu, Thomas Weißschuh,
Yonghong Song, kernel-team, linux-arm-kernel, linux-efi,
linux-hexagon, linux-kbuild, linux-kernel, linux-parisc,
linux-s390, linuxppc-dev, llvm, loongarch
In-Reply-To: <adu-ZyIv47FnsVLI@levanger>
The pull request you sent on Sun, 12 Apr 2026 17:46:47 +0200:
> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/kbuild/linux.git tags/kbuild-7.1-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5d0d3623303775d750e122a2542d1a26c8573d38
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [RFC PATCH] arm64: mm: support set_memory_encrypted/decrypted for vmalloc addresses
From: Catalin Marinas @ 2026-04-14 16:46 UTC (permalink / raw)
To: Kameron Carr
Cc: will, suzuki.poulose, steven.price, ryan.roberts, dev.jain, yang,
shijie, kevin.brodsky, linux-arm-kernel, linux-kernel
In-Reply-To: <001301dcc932$21cb6d80$65624880$@linux.microsoft.com>
On Fri, Apr 10, 2026 at 02:36:42PM -0700, Kameron Carr wrote:
> On Friday, April 10, 2026 4:06 AM, Catalin Marinas wrote:
> > Could you give more details about the user of set_memory_decrypted() on
> > vmalloc()'ed addresses? I think this came up in the past and I wondered
> > whether something like GFP_DECRYPTED would be simpler to implement (even
> > posted a hack but without vmalloc() support). If it is known upfront
> > that the memory will be decrypted, it's easier/cheaper to do this on the
> > page allocation time to change the linear map and just use
> > pgprot_decrypted() for vmap(). No need to rewrite the page table after
> > mapping the pages.
[...]
> In this use case, whether to decrypt the memory can always be known at
> time of allocation, so a solution like GFP_DECRYPTED is an option.
>
> I think I found the hack you mentioned
> (https://lore.kernel.org/linux-arm-kernel/ZmNJdSxSz-sYpVgI@arm.com/). The
> feedback in Michael Kelley's reply covers the key considerations well.
Yes, that's the thread. It started originally as a GICv3 need
(eventually we went for genpool).
> He likely had netvsc's use of vmalloc in mind when he made the point
> "GFP_DECRYPTED should work for the three memory allocation interfaces and
> their variants: alloc_pages(), kmalloc(), and vmalloc()." His other
> points already cover the concerns I had in mind around handling errors
> from set_memory_decrypted()/encrypted(), etc.
>
> What is the current status of your proposed GFP_DECRYPTED implementation?
> Is this something you are actively working on?
Not really. But I've been looking at it again and I think it adds more
problems than it solves. A GFP flag would be passed down to
kmem_cache_alloc() and confuse the slab management if some pages are
encrypted, others not for the same kmem_cache (SLAB_NO_MERGE wouldn't
help). I wonder whether something like SLAB_DECRYPTED would work better
for this if we really need it (not aware of any user though).
Anyway, let's ignore slab for now and look at vmalloc(). I can see
hv_ringbuffer_init() using an explicit vmap(pgprot_decrypted()). While
you could do this, it might be better to just add a VM_DECRYPTED flag
and a few wrappers like vmalloc_decrypted(). It would call
set_memory_decrypted() for the allocated pages and use
pgprot_decrypted() for vmap. On vfree(), it will have to set the pages
back to encrypted. It should be fairly mechanical to do (or a 5 min job
for an LLM ;)).
--
Catalin
^ permalink raw reply
* Re: [GIT PULL] arm64: dts: ti: k3: Late DT update for v7.1
From: Krzysztof Kozlowski @ 2026-04-14 16:44 UTC (permalink / raw)
To: Vignesh Raghavendra
Cc: SoC, arm, SoC list, linux-arm-kernel, linux-kernel, Tero Kristo,
Nishanth, Menon
In-Reply-To: <6e294d61-9779-41ef-83f8-29f46fd98700@ti.com>
On Sun, Apr 12, 2026 at 12:52:51PM +0530, Vignesh Raghavendra wrote:
> Hi ARM SoC Maintainers,
>
> This contains a single patch that updates r5f remoteproc DT nodes, warranted by recent
> binding update merged via remoteproc tree.
>
> The following changes since commit 47c806de9e9cf171d197f2f0df86df7f2bd1aa56:
>
> arm64: dts: ti: k3-pinctrl: sort shift values numerically (2026-03-27 19:55:06 +0530)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git tags/ti-k3-dt-for-v7.1-part2
>
> for you to fetch changes up to abe76f9f47d59ff80eb2fc59482aa76bbf6fd13a:
>
> arm64: dts: ti: k3: Use memory-region-names for r5f (2026-04-09 17:05:28 +0530)
>
> ----------------------------------------------------------------
> TI K3 device tree updates for v7.1 part2
>
> Late addition:
> - Use memory-region-names for r5f across K3 SoCs
>
Thanks, applied
Best regards,
Krzysztof
^ 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