* [PATCH v2] arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlays
From: Florijan Plohl @ 2026-04-09 9:01 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: imx, linux-arm-kernel, devicetree, linux-kernel, upstream
Add overlay for the PHYTEC Audio/Video adapter module PEB-AV-18 on
phyBOARD-Segin-i.MX91/93 boards. The supported AC220 display is
Powertip PH800480T032-ZHC19 panel with a backlight and Ilitek
touch-screen controller.
Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
---
Changes in v2:
- Link to v1: https://lore.kernel.org/all/20260402070826.970012-1-florijan.plohl@norik.com/
- Improve commit message to clarify what PEB-AV-18 is
- Move imx91-phyboard-segin-peb-av-18 dtb entry next to
the other imx91 phyboard-segin definition in Makefile
- Introduce common imx91-93-phyboard-segin-peb-av-18.dtsi
- Adjust drive-strength values
arch/arm64/boot/dts/freescale/Makefile | 6 ++
.../imx91-93-phyboard-segin-peb-av-18.dtsi | 93 +++++++++++++++++++
.../imx91-phyboard-segin-peb-av-18.dtso | 57 ++++++++++++
.../imx93-phyboard-segin-peb-av-18.dtso | 57 ++++++++++++
4 files changed, 213 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx91-93-phyboard-segin-peb-av-18.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index bae24b53bce6..574960280744 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -416,6 +416,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx91-11x11-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx91-11x11-frdm.dtb
dtb-$(CONFIG_ARCH_MXC) += imx91-11x11-frdm-s.dtb
dtb-$(CONFIG_ARCH_MXC) += imx91-phyboard-segin.dtb
+
+imx91-phyboard-segin-peb-av-18-dtbs += imx91-phyboard-segin.dtb imx91-phyboard-segin-peb-av-18.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx91-phyboard-segin-peb-av-18.dtb
+
dtb-$(CONFIG_ARCH_MXC) += imx91-tqma9131-mba91xxca.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb.dtb
@@ -441,6 +445,7 @@ imx93-phyboard-nash-jtag-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-nash-jta
imx93-phyboard-nash-peb-wlbt-07-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-nash-peb-wlbt-07.dtbo
imx93-phyboard-nash-pwm-fan-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-nash-pwm-fan.dtbo
imx93-phyboard-segin-peb-av-02-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-av-02.dtbo
+imx93-phyboard-segin-peb-av-18-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-av-18.dtbo
imx93-phyboard-segin-peb-eval-01-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-eval-01.dtbo
imx93-phyboard-segin-peb-wlbt-05-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-wlbt-05.dtbo
imx93-phycore-rpmsg-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-segin.dtb imx93-phycore-rpmsg.dtbo
@@ -448,6 +453,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash-jtag.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash-peb-wlbt-07.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash-pwm-fan.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-av-02.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-av-18.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-eval-01.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-wlbt-05.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phycore-rpmsg.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx91-93-phyboard-segin-peb-av-18.dtsi b/arch/arm64/boot/dts/freescale/imx91-93-phyboard-segin-peb-av-18.dtsi
new file mode 100644
index 000000000000..53d5cbcd798b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx91-93-phyboard-segin-peb-av-18.dtsi
@@ -0,0 +1,93 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2026 PHYTEC Messtechnik GmbH
+ *
+ * Author: Florijan Plohl <florijan.plohl@norik.com>
+ */
+
+#include <dt-bindings/clock/imx93-clock.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <5>;
+ power-supply = <®_vcc_3v3_con>;
+ pwms = <&pwm7 0 5000000 0>;
+ };
+
+ panel {
+ compatible = "powertip,ph800480t032-zhc19";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_panel>;
+
+ backlight = <&backlight>;
+ enable-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_vcc_3v3_con>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dpi_to_panel>;
+ };
+ };
+ };
+
+ pwm7: pwm-7 {
+ compatible = "pwm-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm7>;
+ gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
+ #pwm-cells = <3>;
+ };
+
+ reg_vcc_3v3_con: regulator-vcc-3v3-con {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC3V3_CON";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ };
+};
+
+&dpi_bridge {
+ status = "okay";
+};
+
+&dpi_to_panel {
+ remote-endpoint = <&panel_in>;
+ bus-width = <18>;
+};
+
+&lcdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif>;
+ assigned-clocks = <&clk IMX93_CLK_VIDEO_PLL>;
+ assigned-clock-rates = <27272728>;
+ status = "okay";
+};
+
+&lpi2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@41 {
+ compatible = "ilitek,ili2130";
+ reg = <0x41>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_touchscreen>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio4 1 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ wakeup-source;
+ };
+};
+
+&media_blk_ctrl {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso b/arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso
new file mode 100644
index 000000000000..35edf9b0fb0f
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso
@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2026 PHYTEC Messtechnik GmbH
+ *
+ * Author: Florijan Plohl <florijan.plohl@norik.com>
+ */
+
+#include "imx91-pinfunc.h"
+#include "imx91-93-phyboard-segin-peb-av-18.dtsi"
+
+&iomuxc {
+ pinctrl_lcdif: lcdifgrp {
+ fsl,pins = <
+ MX91_PAD_GPIO_IO00__MEDIAMIX_DISP_CLK 0x57e
+ MX91_PAD_GPIO_IO01__MEDIAMIX_DISP_DE 0x51e
+ MX91_PAD_GPIO_IO02__MEDIAMIX_DISP_VSYNC 0x51e
+ MX91_PAD_GPIO_IO03__MEDIAMIX_DISP_HSYNC 0x51e
+ MX91_PAD_GPIO_IO04__MEDIAMIX_DISP_DATA0 0x51e
+ MX91_PAD_GPIO_IO05__MEDIAMIX_DISP_DATA1 0x51e
+ MX91_PAD_GPIO_IO06__MEDIAMIX_DISP_DATA2 0x51e
+ MX91_PAD_GPIO_IO07__MEDIAMIX_DISP_DATA3 0x51e
+ MX91_PAD_GPIO_IO08__MEDIAMIX_DISP_DATA4 0x51e
+ MX91_PAD_GPIO_IO09__MEDIAMIX_DISP_DATA5 0x51e
+ MX91_PAD_GPIO_IO10__MEDIAMIX_DISP_DATA6 0x51e
+ MX91_PAD_GPIO_IO11__MEDIAMIX_DISP_DATA7 0x51e
+ MX91_PAD_GPIO_IO12__MEDIAMIX_DISP_DATA8 0x51e
+ MX91_PAD_GPIO_IO13__MEDIAMIX_DISP_DATA9 0x51e
+ MX91_PAD_GPIO_IO14__MEDIAMIX_DISP_DATA10 0x51e
+ MX91_PAD_GPIO_IO15__MEDIAMIX_DISP_DATA11 0x51e
+ MX91_PAD_GPIO_IO16__MEDIAMIX_DISP_DATA12 0x51e
+ MX91_PAD_GPIO_IO17__MEDIAMIX_DISP_DATA13 0x51e
+ MX91_PAD_GPIO_IO18__MEDIAMIX_DISP_DATA14 0x51e
+ MX91_PAD_GPIO_IO19__MEDIAMIX_DISP_DATA15 0x51e
+ MX91_PAD_GPIO_IO20__MEDIAMIX_DISP_DATA16 0x51e
+ MX91_PAD_GPIO_IO21__MEDIAMIX_DISP_DATA17 0x51e
+ >;
+ };
+
+ pinctrl_panel: panelgrp {
+ fsl,pins = <
+ MX91_PAD_CCM_CLKO4__GPIO4_IO29 0x1133e
+ >;
+ };
+
+ pinctrl_pwm7: pwm7grp {
+ fsl,pins = <
+ MX91_PAD_CCM_CLKO3__GPIO4_IO28 0x1133e
+ >;
+ };
+
+ pinctrl_touchscreen: touchscreengrp {
+ fsl,pins = <
+ MX91_PAD_ENET1_MDIO__GPIO4_IO1 0x11e
+ MX91_PAD_ENET1_RD2__GPIO4_IO12 0x1133e
+ >;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso b/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso
new file mode 100644
index 000000000000..11f7d7502be4
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso
@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2026 PHYTEC Messtechnik GmbH
+ *
+ * Author: Florijan Plohl <florijan.plohl@norik.com>
+ */
+
+#include "imx93-pinfunc.h"
+#include "imx91-93-phyboard-segin-peb-av-18.dtsi"
+
+&iomuxc {
+ pinctrl_lcdif: lcdifgrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO00__MEDIAMIX_DISP_CLK 0x57e
+ MX93_PAD_GPIO_IO02__MEDIAMIX_DISP_VSYNC 0x51e
+ MX93_PAD_GPIO_IO01__MEDIAMIX_DISP_DE 0x51e
+ MX93_PAD_GPIO_IO03__MEDIAMIX_DISP_HSYNC 0x51e
+ MX93_PAD_GPIO_IO04__MEDIAMIX_DISP_DATA00 0x51e
+ MX93_PAD_GPIO_IO05__MEDIAMIX_DISP_DATA01 0x51e
+ MX93_PAD_GPIO_IO06__MEDIAMIX_DISP_DATA02 0x51e
+ MX93_PAD_GPIO_IO07__MEDIAMIX_DISP_DATA03 0x51e
+ MX93_PAD_GPIO_IO08__MEDIAMIX_DISP_DATA04 0x51e
+ MX93_PAD_GPIO_IO09__MEDIAMIX_DISP_DATA05 0x51e
+ MX93_PAD_GPIO_IO10__MEDIAMIX_DISP_DATA06 0x51e
+ MX93_PAD_GPIO_IO11__MEDIAMIX_DISP_DATA07 0x51e
+ MX93_PAD_GPIO_IO12__MEDIAMIX_DISP_DATA08 0x51e
+ MX93_PAD_GPIO_IO13__MEDIAMIX_DISP_DATA09 0x51e
+ MX93_PAD_GPIO_IO14__MEDIAMIX_DISP_DATA10 0x51e
+ MX93_PAD_GPIO_IO15__MEDIAMIX_DISP_DATA11 0x51e
+ MX93_PAD_GPIO_IO16__MEDIAMIX_DISP_DATA12 0x51e
+ MX93_PAD_GPIO_IO17__MEDIAMIX_DISP_DATA13 0x51e
+ MX93_PAD_GPIO_IO18__MEDIAMIX_DISP_DATA14 0x51e
+ MX93_PAD_GPIO_IO19__MEDIAMIX_DISP_DATA15 0x51e
+ MX93_PAD_GPIO_IO20__MEDIAMIX_DISP_DATA16 0x51e
+ MX93_PAD_GPIO_IO21__MEDIAMIX_DISP_DATA17 0x51e
+ >;
+ };
+
+ pinctrl_panel: panelgrp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO4__GPIO4_IO29 0x1133e
+ >;
+ };
+
+ pinctrl_pwm7: pwm7grp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO3__GPIO4_IO28 0x1133e
+ >;
+ };
+
+ pinctrl_touchscreen: touchscreengrp {
+ fsl,pins = <
+ MX93_PAD_ENET1_MDIO__GPIO4_IO01 0x11e
+ MX93_PAD_ENET1_RD2__GPIO4_IO12 0x1133e
+ >;
+ };
+};
--
2.43.0
^ permalink raw reply related
* [GIT PULL] ARM: mvebu: dt for v7.1 (#1)
From: Gregory CLEMENT @ 2026-04-09 8:56 UTC (permalink / raw)
To: Arnd Bergmann, arm, soc
Cc: Andrew Lunn, Sebastian Hesselbarth, linux-arm-kernel
Hi,
Here is the first pull request for dt for mvebu for v7.1.
Gregory
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-dt-7.1-1
for you to fetch changes up to 29d8a380643521422a9907f3e982e142fe22d19e:
MAINTAINERS: drop file entry in Marvell Kirkwood and Armada SOC support (2026-03-02 16:24:43 +0100)
----------------------------------------------------------------
mvebu dt for 7.1 (part 1)
Drop unnecessary MAINTAINERS entry for non-existent Marvell db-falcon files
----------------------------------------------------------------
Lukas Bulwahn (1):
MAINTAINERS: drop file entry in Marvell Kirkwood and Armada SOC support
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
--
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: fsl: Add SolidRun i.MX8DXL SoM and HummingBoard
From: Krzysztof Kozlowski @ 2026-04-09 8:48 UTC (permalink / raw)
To: Josua Mayer
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Yazan Shhady, Mikhail Anikin, Alexander Dahl, devicetree,
linux-kernel, imx, linux-arm-kernel
In-Reply-To: <20260408-imx8dxl-sr-som-v1-1-ce5a39acd713@solid-run.com>
On Wed, Apr 08, 2026 at 08:38:36PM +0200, Josua Mayer wrote:
> Add binding for the SolidRun i.MX8DXL based System on Module, and the
> reference HummingBoard Telematics.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/2] Utilize pinctrl-single for bcm7038-style chips
From: Linus Walleij @ 2026-04-09 8:44 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Tony Lindgren, Haojian Zhuang, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:PIN CONTROLLER - SINGLE,
open list:PIN CONTROLLER - SINGLE
In-Reply-To: <20260407235611.550515-1-florian.fainelli@broadcom.com>
On Wed, Apr 8, 2026 at 1:56 AM Florian Fainelli
<florian.fainelli@broadcom.com> wrote:
> This patch set allows Broadcom STB chips with the BCM7038-style
> pinmux/configuration blocks to use pinctrl-single. This does not
> preclude us from making use of a more sophisticated driver in the
> future, should we need to.
Patches applied for v7.1!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/2] Utilize pinctrl-single for bcm7038-style chips
From: Linus Walleij @ 2026-04-09 8:43 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Tony Lindgren, Haojian Zhuang, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:PIN CONTROLLER - SINGLE,
open list:PIN CONTROLLER - SINGLE
In-Reply-To: <20260407235611.550515-1-florian.fainelli@broadcom.com>
On Wed, Apr 8, 2026 at 1:56 AM Florian Fainelli
<florian.fainelli@broadcom.com> wrote:
> This patch set allows Broadcom STB chips with the BCM7038-style
> pinmux/configuration blocks to use pinctrl-single. This does not
> preclude us from making use of a more sophisticated driver in the
> future, should we need to.
OK that's one way to do it. I wonder if this approach also works for
BCMBCA given Haojian's comments on my previous patch attempts.
drivers/pinctrl/bcm/pinctrl-bcm4908.c would then be phased over
to pinctrl-single, or does the MSB/LSB register layout create a
problem? If we always write 0 into MSB I guess we could just add
some quirk...
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v7.0 (#1)
From: Gregory CLEMENT @ 2026-04-09 8:28 UTC (permalink / raw)
To: Arnd Bergmann, arm, soc
Cc: Andrew Lunn, Sebastian Hesselbarth, linux-arm-kernel
Hi,
Here is the first pull request for fixes for mvebu for v7.0.
Gregory
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-fixes-7.0-1
for you to fetch changes up to edb7efa767da8bb82d724b85178be251ec4e060e:
dt-bindings: arm64: add Marvell 7k COMe boards (2026-03-13 16:41:11 +0100)
----------------------------------------------------------------
mvebu fixes for 7.0 (part 1)
A new device tree has been merged without a binding, which triggered
warnings during dtb_checks. The commit in this pull request fixes this
issue, enabling easier detection of new problems in device trees by
reducing the number of false warnings.
----------------------------------------------------------------
Elad Nachman (1):
dt-bindings: arm64: add Marvell 7k COMe boards
.../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
--
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 5/9] dt-bindings: pinctrl: apple,pinctrl: Add t8122 compatible
From: Linus Walleij @ 2026-04-09 8:27 UTC (permalink / raw)
To: Janne Grunau
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi,
Sven Peter, Neal Gompa, Wim Van Sebroeck, Guenter Roeck,
Mark Kettenis, Andi Shyti, Uwe Kleine-König,
Sasha Finkelstein, devicetree, linux-kernel, asahi,
linux-arm-kernel, linux-watchdog, linux-gpio, linux-i2c,
linux-pwm
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-5-5842e1e393a8@jannau.net>
On Fri, Mar 20, 2026 at 1:23 PM Janne Grunau <j@jannau.net> wrote:
> The pin controller on the Apple silicon t8122 (M3) SoC is compatible
> with the existing driver. Add "apple,t8122-pinctrl" as SoC specific
> compatible under "apple,t8103-pinctrl" used by the driver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
This patch applied to the pinctrl tree for v7.1.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver
From: Krzysztof Kozlowski @ 2026-04-09 8:17 UTC (permalink / raw)
To: Gregor Herburger
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260408-rpi-otp-driver-v1-2-e02d1dbe6008@linutronix.de>
On Wed, Apr 08, 2026 at 10:00:16AM +0200, Gregor Herburger wrote:
> Raspberry Pis have OTP registers which can be accessed through the
> videocore firmware. Add a nvmem driver to support these OTP registers.
>
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
> drivers/nvmem/Kconfig | 12 +++
> drivers/nvmem/Makefile | 1 +
> drivers/nvmem/raspberrypi-otp.c | 159 +++++++++++++++++++++++++++++
> include/soc/bcm2835/raspberrypi-firmware.h | 2 +
> 4 files changed, 174 insertions(+)
>
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index 74ddbd0f79b0..892d05fe67be 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -483,4 +483,16 @@ config NVMEM_QORIQ_EFUSE
> This driver can also be built as a module. If so, the module
> will be called nvmem_qoriq_efuse.
>
> +config NVMEM_RASPBERRYPI_OTP
> + tristate "Raspberry Pi OTP support"
> + # Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
> + # happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
Drop comment and use standard rules for multiple modules.
https://lwn.net/Articles/944368/
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm: artpec: Remove unnecessary semicolons in artpec6_init_machine()
From: Jesper Nilsson @ 2026-04-09 8:15 UTC (permalink / raw)
To: Nobuhiro Iwamatsu
Cc: jesper.nilsson, lars.persson, linux-arm-kernel, linux-arm-kernel,
linux-kernel
In-Reply-To: <1775710886-13833-1-git-send-email-nobuhiro.iwamatsu.x90@mail.toshiba>
On Thu, Apr 09, 2026 at 02:01:26PM +0900, Nobuhiro Iwamatsu wrote
> Remove unnecessary semicolons in artpec6_init_machine().
>
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.x90@mail.toshiba>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: marvell: armada-37xx: USB3 PHY cleanup
From: Gregory CLEMENT @ 2026-04-09 8:15 UTC (permalink / raw)
To: Gabor Juhos, Andrew Lunn, Sebastian Hesselbarth, Robert Marko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Stanley Chang
Cc: linux-arm-kernel, devicetree, linux-kernel, Gabor Juhos
In-Reply-To: <20260330-armada-37xx-usb3-phy-cleanup-v1-0-34d77f1a1784@gmail.com>
Gabor Juhos <j4g8y7@gmail.com> writes:
> There are two small patches in the series. The first helps to avoid
> triggering a bug in the USB core code, whereas the second one is a
> small cleanup to align PHY definitions of the USB3 node with other
> platforms.
>
> Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
> ---
> Gabor Juhos (2):
> arm64: dts: marvell: armada-37xx: use 'usb2-phy' in USB3 controller's phy-names
> arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node
>
> arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi | 2 +-
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
Applied on mvebu/dt64
Thanks,
Gregory
> ---
> base-commit: 2ff6cc999a04bcb094b8cbba68a9251f03a5c876
> change-id: 20260330-armada-37xx-usb3-phy-cleanup-922a5472794a
>
> Best regards,
> --
> Gabor Juhos <j4g8y7@gmail.com>
>
--
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware
From: Krzysztof Kozlowski @ 2026-04-09 8:15 UTC (permalink / raw)
To: Gregor Herburger
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260408-rpi-otp-driver-v1-3-e02d1dbe6008@linutronix.de>
On Wed, Apr 08, 2026 at 10:00:17AM +0200, Gregor Herburger wrote:
> The Raspberry Pi 5 has two OTP registers (private and customer), add these
> to the devicetree.
So this sentence confirms my question on bindings - your device
raspberrypi,bcm2835-firmware has these, thus you do not need these child
nodes at all. Neither compatibles.
Drop entire DTS and binding patches.
See also writing-bindings and DTS101 why we do not allow this.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: nvmem: Add a binding for the RPi Firmware OTP register
From: Krzysztof Kozlowski @ 2026-04-09 8:13 UTC (permalink / raw)
To: Gregor Herburger
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260408-rpi-otp-driver-v1-1-e02d1dbe6008@linutronix.de>
On Wed, Apr 08, 2026 at 10:00:15AM +0200, Gregor Herburger wrote:
> The firmware running on the Raspberry Pi VideoCore can be used to access
> OTP registers. There are two OTP regions (private and customer). Add a
> binding for these.
A nit, subject: drop second/last, redundant "a binding for the". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
> .../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> index 983ea80eaec9..975c8927d75b 100644
> --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> @@ -137,6 +137,20 @@ required:
> - compatible
> - mboxes
>
> +patternProperties:
> + "^otp-(customer|private)$":
Not a pattern but just "otp".
> + type: object
> + additionalProperties: false
> +
> + properties:
> + compatible:
> + enum:
> + - raspberrypi,firmware-otp-customer
> + - raspberrypi,firmware-otp-private
I don't understand why having OTP regions is not deducible from
top-level compatible. I also do not get why do you need per OTP
compatible.
There are no resources here, so standard review would be "no" and you
need strong justification in terms of DT.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
From: Krzysztof Kozlowski @ 2026-04-09 8:10 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Rutland, linux-arm-kernel,
iommu, devicetree, linux-kernel, linux-perf-users, Peng Fan
In-Reply-To: <20260408-smmu-perf-v1-1-d75dac96e828@nxp.com>
On Wed, Apr 08, 2026 at 03:51:15PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> The Arm SMMU v3 specification defines an optional PMCG (Performance
"optional" in a meaning some SMMUv3 implementations do not have it?
> Monitor Control Group) block. Per MMU-700 TRM, it has three 64KB pages,
> with TCU Performance Monitor Counter Group (PMCG) registers starting at
> offset 0x02000 in page 0. So PMCG could be described as a child node of the
> SMMU in Devicetree.
>
> Add a patternProperties entry to the arm,smmu-v3 binding to allow child
> nodes matching "pmu@<addr>" and reference the existing
> arm,smmu-v3-pmcg.yaml schema.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> index 82957334bea24402b583e47eb61b5724c91e4378..1d09c5476e5f1a7c3e5c935b677641ee6cc9897e 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> @@ -50,6 +50,10 @@ properties:
> - cmdq-sync # CMD_SYNC complete
> - priq # PRI Queue not empty
>
> + '#address-cells': true
Instead enum [1, 2]
> + '#size-cells': true
Same here
> + ranges: true
I guess only one mapping is allowed so:
maxItems: 1
> +
> '#iommu-cells':
> const: 1
>
> @@ -83,6 +87,12 @@ properties:
> register access with page 0 offsets. Set for Cavium ThunderX2 silicon that
> doesn't support SMMU page1 register space.
>
> +patternProperties:
> + '^pmu@[0-9a-f]+$':
> + type: object
> + $ref: /schemas/perf/arm,smmu-v3-pmcg.yaml#
> + unevaluatedProperties: false
Please add another example with 4-space indentation.
> +
> allOf:
> - if:
> not:
>
> --
> 2.37.1
>
^ permalink raw reply
* Re: [PATCH v4 net-next 10/14] net: dsa: netc: introduce NXP NETC switch driver for i.MX94
From: Vladimir Oltean @ 2026-04-09 8:07 UTC (permalink / raw)
To: Wei Fang
Cc: Jakub Kicinski, Claudiu Manoil, Clark Wang, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
f.fainelli@gmail.com, Frank Li, chleroy@kernel.org,
horms@kernel.org, linux@armlinux.org.uk, andrew@lunn.ch,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <AM8PR04MB72840DBFC7F3FD578DFF6AF8885BA@AM8PR04MB7284.eurprd04.prod.outlook.com>
On Wed, Apr 08, 2026 at 11:59:24AM +0300, Wei Fang wrote:
> > > +static int netc_init_switch_id(struct netc_switch *priv)
> > > +{
> > > + struct netc_switch_regs *regs = &priv->regs;
> > > + struct dsa_switch *ds = priv->ds;
> > > +
> > > + /* The value of 0 is reserved for the VEPA switch and cannot
> > > + * be used.
> > > + */
> > > + if (ds->index > SWCR_SWID || !ds->index) {
> > > + dev_err(priv->dev, "Switch index %d out of range\n",
> > > + ds->index);
> > > + return -ERANGE;
> > > + }
> >
> > Does this check cause the probe to fail unconditionally for standard
> > single-switch topologies?
> >
> > The DSA core typically assigns ds->index = 0 by default for the first switch.
> > Because !ds->index evaluates to true for index 0, this setup function will
> > always fail unless the dsa,member property is explicitly overridden in the
> > device tree.
>
> As I mentioned in another mail, we added the 'dsa,member' property to the
> netc switch DT-binding doc, specifying that the 'member' (switch index) value
> cannot be 0. And 'dsa,member' is a required property for netc switch.
>
> >
> > Could the driver translate the hardware ID internally, for example by writing
> > ds->index + 1 to NETC_SWCR, rather than forcing this hardware-specific
> > restriction onto the software DSA index?
>
> The current approach is based on Vladimir's suggestion. I need to confirm with
> Vladimir which approach is better.
>
> Hi Vladimir,
>
> What are your thoughts on this suggestion? Is this approach better?
I maintain it is preferable/simpler the way you are doing it, with a 1:1 mapping.
The LLM's concern would be more valid if the switch were discrete and every
board DTS author would have to remember to place the dsa,member property.
But the switch OF node will live in an SoC dtsi.
Maybe you could put something along these lines in the commit message,
hopefully the LLM will pick it up and stop complaining.
^ permalink raw reply
* Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver
From: Gregor Herburger @ 2026-04-09 8:05 UTC (permalink / raw)
To: Stefan Wahren
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Srinivas Kandagatla, devicetree, linux-rpi-kernel,
linux-arm-kernel, linux-kernel
In-Reply-To: <90f54202-6eb6-4c44-b029-a4e0dafad861@gmx.net>
On Wed, Apr 08, 2026 at 10:03:47PM +0200, Stefan Wahren wrote:
> Am 08.04.26 um 21:47 schrieb Gregor Herburger:
> > Hi Stefan,
> >
> > thanks for the review.
> > > Is there any reason, why we cannot register this driver in
> > > rpi_firmware_probe() like hwmon and clk driver?
> > >
> > > I like to avoid the complete dt-binding from patch 1.
> > The private OTP registers are not available on all Raspberries. Afaik
> > only on 4 and 5. So I think these registers must be described through
> > the device tree. Therefore the bindings are needed.
> This binding doesn't represent some kind of hardware, it's just some
> firmware interface. A proper DT binding would describe the MMIO address
> range for OTP access.
I think it does represent real hardware. Although it is hidden through the
firmware. Not all hardware must be MMIO addresses.
The only driver that does not have a DT node is the hwmon driver. All
other drivers (clock, gpio, touchscreeen, reset, pwm) do have a DT
binding. Looking at the comment in rpi_register_clk_driver this
seems to be some legacy behaviour for older DTs for the clock driver.
> If you need some distinction between the Raspberry Pi generations there are
> firmware tags to do this.
So what is your suggestion? What tags do you mean?
I don't understand why you want to avoid the dt-binding. What is the
problem with dt-bindings?
What is the benefit of registering the driver in rpi_firmware_probe?
Imho describing this in the DT is the more natural way to do this. E.g.
if in the future there is a raspberry pi with a 64Byte otp it could easily
be supported by adding a devicetree property and add it to the driver.
Regards
Gregor
^ permalink raw reply
* [PATCH v3 2/2] pmdomain: imx: Fix i.MX8MP VC8000E power up sequence
From: Peng Fan (OSS) @ 2026-04-09 8:07 UTC (permalink / raw)
To: Ulf Hansson, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Daniel Baluta
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, Peng Fan, stable
In-Reply-To: <20260409-imx8mp-vc8000e-pm-v3-0-3e023eaa245b@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Per errata[1]:
ERR050531: VPU_NOC power down handshake may hang during VC8000E/VPUMIX
power up/down cycling.
Description: VC8000E reset de-assertion edge and AXI clock may have a
timing issue.
Workaround: Set bit2 (vc8000e_clk_en) of BLK_CLK_EN_CSR to 0 to gate off
both AXI clock and VC8000E clock sent to VC8000E and AXI clock sent to
VPU_NOC m_v_2 interface during VC8000E power up(VC8000E reset is
de-asserted by HW)
Add a bool variable is_errata_err050531 in
'struct imx8m_blk_ctrl_domain_data' to represent whether the workaround
is needed. If is_errata_err050531 is true, first clear the clk before
powering up gpc, then enable the clk after powering up gpc.
[1] https://www.nxp.com/webapp/Download?colCode=IMX8MP_1P33A
Fixes: a1a5f15f7f6cb ("soc: imx: imx8m-blk-ctrl: add i.MX8MP VPU blk ctrl")
Cc: stable@vger.kernel.org
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/pmdomain/imx/imx8m-blk-ctrl.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/pmdomain/imx/imx8m-blk-ctrl.c b/drivers/pmdomain/imx/imx8m-blk-ctrl.c
index e13a47eeed75d7189aa15370a7bee4cceb05a1d6..1cd0a22ce3e533358dd7449da9989162b36c5fe6 100644
--- a/drivers/pmdomain/imx/imx8m-blk-ctrl.c
+++ b/drivers/pmdomain/imx/imx8m-blk-ctrl.c
@@ -54,6 +54,15 @@ struct imx8m_blk_ctrl_domain_data {
* register.
*/
u32 mipi_phy_rst_mask;
+
+ /*
+ * VC8000E reset de-assertion edge and AXI clock may have a timing issue.
+ * Workaround: Set bit2 (vc8000e_clk_en) of BLK_CLK_EN_CSR to 0 to gate off
+ * both AXI clock and VC8000E clock sent to VC8000E and AXI clock sent to
+ * VPU_NOC m_v_2 interface during VC8000E power up(VC8000E reset is
+ * de-asserted by HW)
+ */
+ bool is_errata_err050531;
};
#define DOMAIN_MAX_CLKS 4
@@ -108,7 +117,11 @@ static int imx8m_blk_ctrl_power_on(struct generic_pm_domain *genpd)
dev_err(bc->dev, "failed to enable clocks\n");
goto bus_put;
}
- regmap_set_bits(bc->regmap, BLK_CLK_EN, data->clk_mask);
+
+ if (data->is_errata_err050531)
+ regmap_clear_bits(bc->regmap, BLK_CLK_EN, data->clk_mask);
+ else
+ regmap_set_bits(bc->regmap, BLK_CLK_EN, data->clk_mask);
/* power up upstream GPC domain */
ret = pm_runtime_get_sync(domain->power_dev);
@@ -117,6 +130,9 @@ static int imx8m_blk_ctrl_power_on(struct generic_pm_domain *genpd)
goto clk_disable;
}
+ if (data->is_errata_err050531)
+ regmap_set_bits(bc->regmap, BLK_CLK_EN, data->clk_mask);
+
/* wait for reset to propagate */
udelay(5);
--
2.37.1
^ permalink raw reply related
* [PATCH v3 1/2] pmdomain: imx: Fix i.MX8MP power notifier
From: Peng Fan (OSS) @ 2026-04-09 8:07 UTC (permalink / raw)
To: Ulf Hansson, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Daniel Baluta
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, Peng Fan, stable
In-Reply-To: <20260409-imx8mp-vc8000e-pm-v3-0-3e023eaa245b@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Using imx8mm_vpu_power_notifier() for i.MX8MP is wrong, as it ungates
the VPU clocks to provide the ADB clock, which is necessary on i.MX8MM,
but on i.MX8MP there is a separate gate (bit 3) for the NoC. So add
imx8mp_vpu_power_notifier() for i.MX8MP.
Fixes: a1a5f15f7f6cb ("soc: imx: imx8m-blk-ctrl: add i.MX8MP VPU blk ctrl")
Cc: stable@vger.kernel.org
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/pmdomain/imx/imx8m-blk-ctrl.c | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/pmdomain/imx/imx8m-blk-ctrl.c b/drivers/pmdomain/imx/imx8m-blk-ctrl.c
index 19e992d2ee3b845bc9382bcd494a5d96f9c6ac44..e13a47eeed75d7189aa15370a7bee4cceb05a1d6 100644
--- a/drivers/pmdomain/imx/imx8m-blk-ctrl.c
+++ b/drivers/pmdomain/imx/imx8m-blk-ctrl.c
@@ -514,9 +514,34 @@ static const struct imx8m_blk_ctrl_domain_data imx8mp_vpu_blk_ctl_domain_data[]
},
};
+static int imx8mp_vpu_power_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct imx8m_blk_ctrl *bc = container_of(nb, struct imx8m_blk_ctrl,
+ power_nb);
+
+ if (action == GENPD_NOTIFY_ON) {
+ /*
+ * On power up we have no software backchannel to the GPC to
+ * wait for the ADB handshake to happen, so we just delay for a
+ * bit. On power down the GPC driver waits for the handshake.
+ */
+
+ udelay(5);
+
+ /* set "fuse" bits to enable the VPUs */
+ regmap_set_bits(bc->regmap, 0x8, 0xffffffff);
+ regmap_set_bits(bc->regmap, 0xc, 0xffffffff);
+ regmap_set_bits(bc->regmap, 0x10, 0xffffffff);
+ regmap_set_bits(bc->regmap, 0x14, 0xffffffff);
+ }
+
+ return NOTIFY_OK;
+}
+
static const struct imx8m_blk_ctrl_data imx8mp_vpu_blk_ctl_dev_data = {
.max_reg = 0x18,
- .power_notifier_fn = imx8mm_vpu_power_notifier,
+ .power_notifier_fn = imx8mp_vpu_power_notifier,
.domains = imx8mp_vpu_blk_ctl_domain_data,
.num_domains = ARRAY_SIZE(imx8mp_vpu_blk_ctl_domain_data),
};
--
2.37.1
^ permalink raw reply related
* [PATCH v3 0/2] pmdomain: imx: Fix i.MX8MP VC8000E power up sequence
From: Peng Fan (OSS) @ 2026-04-09 8:07 UTC (permalink / raw)
To: Ulf Hansson, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Daniel Baluta
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, Peng Fan, stable
There is an errata for i.MX8MP VC8000E:
ERR050531: VPU_NOC power down handshake may hang during VC8000E/VPUMIX
power up/down cycling.
Description: VC8000E reset de-assertion edge and AXI clock may have a
timing issue.
Workaround: Set bit2 (vc8000e_clk_en) of BLK_CLK_EN_CSR to 0 to gate off
both AXI clock and VC8000E clock sent to VC8000E and AXI clock sent to
VPU_NOC m_v_2 interface during VC8000E power up(VC8000E reset is
de-asserted by HW)
This patchset is to fix the errata. More info could be found in each
patch commit.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Changes in v3:
- Separate power up notifier fix into patch 1
- Link to v2: https://lore.kernel.org/r/20260228-imx8mp-vc8000e-pm-v2-1-fd255a0d5958@nxp.com
Changes in v2:
- Add errata link in commit message
- Add comment for is_errata_err050531
- Link to v1: https://lore.kernel.org/r/20260128-imx8mp-vc8000e-pm-v1-1-6c171451c732@nxp.com
---
Peng Fan (2):
pmdomain: imx: Fix i.MX8MP power notifier
pmdomain: imx: Fix i.MX8MP VC8000E power up sequence
drivers/pmdomain/imx/imx8m-blk-ctrl.c | 45 +++++++++++++++++++++++++++++++++--
1 file changed, 43 insertions(+), 2 deletions(-)
---
base-commit: b3ab9a7b9b32806b1b68c4fe7d5298702195eb3a
change-id: 20260128-imx8mp-vc8000e-pm-4278e6d48b54
Best regards,
--
Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX91
From: Stefano Radaelli @ 2026-04-09 7:48 UTC (permalink / raw)
To: Frank Li
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Dario Binacchi, Markus Niebel, Maud Spierings, Alexander Stein,
Ernest Van Hoecke, Josua Mayer, Francesco Dolcini, Primoz Fiser
In-Reply-To: <adcdWdTcVR2T2F5c@lizhi-Precision-Tower-5810>
Hi Frank!
On Wed, Apr 08, 2026 at 11:30:33PM -0400, Frank Li wrote:
>
> what' difference with imx93-var-som ? Can you reuse it?
>
The imx91-var-som is conceptually similar to imx93-var-som, and I used
it as a reference while preparing this DTS.
However, it cannot be directly reused as there are several hardware
differences between the two platforms, including SoC integration and
peripheral configuration (e.g. pinctrl, and available IPs).
So a separate description is required for imx91.
Best regards,
Stefano
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Krzysztof Kozlowski @ 2026-04-09 7:43 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, tychang,
linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, james.tai
In-Reply-To: <20260408025243.1155482-3-eleanor.lin@realtek.com>
On Wed, Apr 08, 2026 at 10:52:41AM +0800, Yu-Chun Lin wrote:
> +maintainers:
> + - Tzuyi Chang <tychang@realtek.com>
> +
> +description: |
> + GPIO controller for the Realtek RTD1625 SoC, featuring a per-pin register
> + architecture that differs significantly from earlier RTD series controllers.
> + Each GPIO has dedicated registers for configuration (direction, input/output
> + values, debounce), and interrupt control supporting edge and level detection
> + modes.
> +
> +properties:
> + compatible:
> + enum:
> + - realtek,rtd1625-iso-gpio
> + - realtek,rtd1625-isom-gpio
> +
> + reg:
> + maxItems: 1
> + description: |
> + Memory region containing both interrupt control and GPIO
> + configuration registers in a contiguous address space.
> +
> + For realtek,rtd1625-iso-gpio:
> + - Base + 0x0 ~ 0xff: Interrupt control registers
> + - Base + 0x100 ~ 0x397: GPIO configuration registers
> +
> + For realtek,rtd1625-isom-gpio:
> + - Base + 0x0 ~ 0x1f: Interrupt control registers
> + - Base + 0x20 ~ 0x2f: GPIO configuration registers
Drop description, you are duplicating here DTS. Bindings do not need to
serve as reference manual for the device.
However when you state them like this and give them names, I have the
same concerns as last time - please consult your datasheet whether this
is really one address space.
With description dropped:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v14 2/4] asm-generic: Move TIF_SINGLESTEP to generic TIF bits
From: Mark Rutland @ 2026-04-09 7:42 UTC (permalink / raw)
To: Jinjie Ruan
Cc: catalin.marinas, will, chenhuacai, kernel, hca, gor, agordeev,
borntraeger, svens, oleg, tglx, mingo, bp, dave.hansen, hpa, arnd,
shuah, kevin.brodsky, yeoreum.yun, anshuman.khandual, thuth,
ryan.roberts, song, ziyao, linusw, schuster.simon, jremus, akpm,
mathieu.desnoyers, kmal, dvyukov, reddybalavignesh9979, x86,
linux-arm-kernel, linux-kernel, loongarch, linux-s390, linux-arch,
linux-kselftest
In-Reply-To: <20260320104222.1381274-3-ruanjinjie@huawei.com>
On Fri, Mar 20, 2026 at 06:42:20PM +0800, Jinjie Ruan wrote:
> Currently, x86, ARM64, s390, and LoongArch all define and use
> TIF_SINGLESTEP to track single-stepping state.
Do the architectures actually use the flag in the same way?
I'd expect that this is used subtly differently across those
architectures, and so isn't necessarily generic.
> Since this flag is shared across multiple major architectures and serves
> a common purpose in the generic entry/exit paths, move TIF_SINGLESTEP
> into the generic Thread Information Flags (TIF) infrastructure.
>
> This consolidation reduces architecture-specific boilerplate code and
> ensures consistency for generic features that rely on single-step
> state tracking.
Is it necessary to make this generic in order to move to generic irq
flags? I'd expect that generic code cannot make use of this due to the
different semantics across architectures, as noted abobve.
I think it's probably better to keep this architecture-specific for now,
where architectures can clearly define how they're using this bit.
Am I missing some reason why it's necessary to make this generic?
Mark.
> Cc: Thomas Gleixner <tglx@kernel.org>
> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Acked-by: Heiko Carstens <hca@linux.ibm.com> # s390
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> arch/loongarch/include/asm/thread_info.h | 11 +++++------
> arch/s390/include/asm/thread_info.h | 7 +++----
> arch/x86/include/asm/thread_info.h | 6 ++----
> include/asm-generic/thread_info_tif.h | 5 +++++
> 4 files changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/arch/loongarch/include/asm/thread_info.h b/arch/loongarch/include/asm/thread_info.h
> index 4d7117fcdc78..a2ec87f18e1d 100644
> --- a/arch/loongarch/include/asm/thread_info.h
> +++ b/arch/loongarch/include/asm/thread_info.h
> @@ -70,6 +70,7 @@ register unsigned long current_stack_pointer __asm__("$sp");
> */
> #define HAVE_TIF_NEED_RESCHED_LAZY
> #define HAVE_TIF_RESTORE_SIGMASK
> +#define HAVE_TIF_SINGLESTEP
>
> #include <asm-generic/thread_info_tif.h>
>
> @@ -82,11 +83,10 @@ register unsigned long current_stack_pointer __asm__("$sp");
> #define TIF_32BIT_REGS 21 /* 32-bit general purpose registers */
> #define TIF_32BIT_ADDR 22 /* 32-bit address space */
> #define TIF_LOAD_WATCH 23 /* If set, load watch registers */
> -#define TIF_SINGLESTEP 24 /* Single Step */
> -#define TIF_LSX_CTX_LIVE 25 /* LSX context must be preserved */
> -#define TIF_LASX_CTX_LIVE 26 /* LASX context must be preserved */
> -#define TIF_USEDLBT 27 /* LBT was used by this task this quantum (SMP) */
> -#define TIF_LBT_CTX_LIVE 28 /* LBT context must be preserved */
> +#define TIF_LSX_CTX_LIVE 24 /* LSX context must be preserved */
> +#define TIF_LASX_CTX_LIVE 25 /* LASX context must be preserved */
> +#define TIF_USEDLBT 26 /* LBT was used by this task this quantum (SMP) */
> +#define TIF_LBT_CTX_LIVE 27 /* LBT context must be preserved */
>
> #define _TIF_NOHZ BIT(TIF_NOHZ)
> #define _TIF_USEDFPU BIT(TIF_USEDFPU)
> @@ -96,7 +96,6 @@ register unsigned long current_stack_pointer __asm__("$sp");
> #define _TIF_32BIT_REGS BIT(TIF_32BIT_REGS)
> #define _TIF_32BIT_ADDR BIT(TIF_32BIT_ADDR)
> #define _TIF_LOAD_WATCH BIT(TIF_LOAD_WATCH)
> -#define _TIF_SINGLESTEP BIT(TIF_SINGLESTEP)
> #define _TIF_LSX_CTX_LIVE BIT(TIF_LSX_CTX_LIVE)
> #define _TIF_LASX_CTX_LIVE BIT(TIF_LASX_CTX_LIVE)
> #define _TIF_USEDLBT BIT(TIF_USEDLBT)
> diff --git a/arch/s390/include/asm/thread_info.h b/arch/s390/include/asm/thread_info.h
> index 1bcd42614e41..95be5258a422 100644
> --- a/arch/s390/include/asm/thread_info.h
> +++ b/arch/s390/include/asm/thread_info.h
> @@ -61,6 +61,7 @@ void arch_setup_new_exec(void);
> */
> #define HAVE_TIF_NEED_RESCHED_LAZY
> #define HAVE_TIF_RESTORE_SIGMASK
> +#define HAVE_TIF_SINGLESTEP
>
> #include <asm-generic/thread_info_tif.h>
>
> @@ -69,15 +70,13 @@ void arch_setup_new_exec(void);
> #define TIF_GUARDED_STORAGE 17 /* load guarded storage control block */
> #define TIF_ISOLATE_BP_GUEST 18 /* Run KVM guests with isolated BP */
> #define TIF_PER_TRAP 19 /* Need to handle PER trap on exit to usermode */
> -#define TIF_SINGLESTEP 21 /* This task is single stepped */
> -#define TIF_BLOCK_STEP 22 /* This task is block stepped */
> -#define TIF_UPROBE_SINGLESTEP 23 /* This task is uprobe single stepped */
> +#define TIF_BLOCK_STEP 20 /* This task is block stepped */
> +#define TIF_UPROBE_SINGLESTEP 21 /* This task is uprobe single stepped */
>
> #define _TIF_ASCE_PRIMARY BIT(TIF_ASCE_PRIMARY)
> #define _TIF_GUARDED_STORAGE BIT(TIF_GUARDED_STORAGE)
> #define _TIF_ISOLATE_BP_GUEST BIT(TIF_ISOLATE_BP_GUEST)
> #define _TIF_PER_TRAP BIT(TIF_PER_TRAP)
> -#define _TIF_SINGLESTEP BIT(TIF_SINGLESTEP)
> #define _TIF_BLOCK_STEP BIT(TIF_BLOCK_STEP)
> #define _TIF_UPROBE_SINGLESTEP BIT(TIF_UPROBE_SINGLESTEP)
>
> diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
> index 0067684afb5b..f59072ba1473 100644
> --- a/arch/x86/include/asm/thread_info.h
> +++ b/arch/x86/include/asm/thread_info.h
> @@ -98,9 +98,8 @@ struct thread_info {
> #define TIF_IO_BITMAP 22 /* uses I/O bitmap */
> #define TIF_SPEC_FORCE_UPDATE 23 /* Force speculation MSR update in context switch */
> #define TIF_FORCED_TF 24 /* true if TF in eflags artificially */
> -#define TIF_SINGLESTEP 25 /* reenable singlestep on user return*/
> -#define TIF_BLOCKSTEP 26 /* set when we want DEBUGCTLMSR_BTF */
> -#define TIF_ADDR32 27 /* 32-bit address space on 64 bits */
> +#define TIF_BLOCKSTEP 25 /* set when we want DEBUGCTLMSR_BTF */
> +#define TIF_ADDR32 26 /* 32-bit address space on 64 bits */
>
> #define _TIF_SSBD BIT(TIF_SSBD)
> #define _TIF_SPEC_IB BIT(TIF_SPEC_IB)
> @@ -112,7 +111,6 @@ struct thread_info {
> #define _TIF_SPEC_FORCE_UPDATE BIT(TIF_SPEC_FORCE_UPDATE)
> #define _TIF_FORCED_TF BIT(TIF_FORCED_TF)
> #define _TIF_BLOCKSTEP BIT(TIF_BLOCKSTEP)
> -#define _TIF_SINGLESTEP BIT(TIF_SINGLESTEP)
> #define _TIF_ADDR32 BIT(TIF_ADDR32)
>
> /* flags to check in __switch_to() */
> diff --git a/include/asm-generic/thread_info_tif.h b/include/asm-generic/thread_info_tif.h
> index da1610a78f92..b277fe06aee3 100644
> --- a/include/asm-generic/thread_info_tif.h
> +++ b/include/asm-generic/thread_info_tif.h
> @@ -48,4 +48,9 @@
> #define TIF_RSEQ 11 // Run RSEQ fast path
> #define _TIF_RSEQ BIT(TIF_RSEQ)
>
> +#ifdef HAVE_TIF_SINGLESTEP
> +#define TIF_SINGLESTEP 12 /* reenable singlestep on user return*/
> +#define _TIF_SINGLESTEP BIT(TIF_SINGLESTEP)
> +#endif
> +
> #endif /* _ASM_GENERIC_THREAD_INFO_TIF_H_ */
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v14 00/10] arm64: entry: Convert to Generic Entry
From: Mark Rutland @ 2026-04-09 7:36 UTC (permalink / raw)
To: Jinjie Ruan
Cc: peterz, catalin.marinas, ldv, song, edumazet, will, mingo, kees,
thuth, ryan.roberts, arnd, anshuman.khandual, kevin.brodsky,
pengcan, broonie, mathieu.desnoyers, luto, linux-arm-kernel, wad,
linusw, oleg, linux-kernel, tglx, liqiang01, yeoreum.yun
In-Reply-To: <174e6d08-4922-f42f-2899-4c5b0df13469@huawei.com>
Hi Jinjie,
On Thu, Apr 09, 2026 at 02:29:04PM +0800, Jinjie Ruan wrote:
> On 2026/3/20 18:26, Jinjie Ruan wrote:
> > Currently, x86, Riscv, Loongarch use the Generic Entry which makes
> > maintainers' work easier and codes more elegant. arm64 has already
> > successfully switched to the Generic IRQ Entry in commit
> > b3cf07851b6c ("arm64: entry: Switch to generic IRQ entry"), it is
> > time to completely convert arm64 to Generic Entry.
> >
> > The goal is to bring arm64 in line with other architectures that already
> > use the generic entry infrastructure, reducing duplicated code and
> > making it easier to share future changes in entry/exit paths, such as
> > "Syscall User Dispatch" and RSEQ optimizations.
>
> Hi,
>
> Just a quick ping to see if this series is good to go. Do I need to
> provide a new version rebased on the latest arm64 for-next/generic-entry
> branches, or is the current version acceptable?
Sorry, this is on my list to review, but I've been busy fixing other
issues (e.g. the preemption issues from moving to generic irqentry), and
haven't yet had the time to go over this in detail.
This series might be fine as-is, but given that it's incredibly easy to
introduce subtle and hard-to-fix regressions to user ABI, I don't think
we can assume that it's safe until we've gone over it thoroughly.
For the moment, no need to resend. If you haven't received comments by
v7.1-rc1, please rebase and resend then.
Thanks,
Mark.
> > This patch set is rebased on arm64 for-next/core. This series contains
> > foundational updates for arm64. As suggested by Linus Walleij, these 10
> > patches are being submitted separately for inclusion in the arm64 tree.
> >
> > And the performance benchmarks results on qemu-kvm are below:
> >
> > perf bench syscall usec/op (-ve is improvement)
> >
> > | Syscall | Base | Generic Entry | change % |
> > | ------- | ----------- | ------------- | -------- |
> > | basic | 0.123997 | 0.120872 | -2.57 |
> > | execve | 512.1173 | 504.9966 | -1.52 |
> > | fork | 114.1144 | 113.2301 | -1.06 |
> > | getpgid | 0.120182 | 0.121245 | +0.9 |
> >
> > perf bench syscall ops/sec (+ve is improvement)
> >
> > | Syscall | Base | Generic Entry| change % |
> > | ------- | -------- | ------------ | -------- |
> > | basic | 8064712 | 8273212 | +2.48 |
> > | execve | 1952 | 1980 | +1.52 |
> > | fork | 8763 | 8832 | +1.06 |
> > | getpgid | 8320704 | 8247810 | -0.9 |
> >
> > Therefore, the syscall performance variation ranges from a 1% regression
> > to a 2.5% improvement.
> >
> > It was tested ok with following test cases on QEMU virt platform:
> > - Stress-ng CPU stress test.
> > - Hackbench stress test.
> > - "sud" selftest testcase.
> > - get_set_sud, get_syscall_info, set_syscall_info, peeksiginfo
> > in tools/testing/selftests/ptrace.
> > - breakpoint_test_arm64 in selftests/breakpoints.
> > - syscall-abi and ptrace in tools/testing/selftests/arm64/abi
> > - fp-ptrace, sve-ptrace, za-ptrace in selftests/arm64/fp.
> > - vdso_test_getrandom in tools/testing/selftests/vDSO
> > - Strace tests.
> > - slice_test for rseq optimizations.
> >
> > The test QEMU configuration is as follows:
> >
> > qemu-system-aarch64 \
> > -M virt \
> > -enable-kvm \
> > -cpu host \
> > -kernel Image \
> > -smp 8 \
> > -m 512m \
> > -nographic \
> > -no-reboot \
> > -device virtio-rng-pci \
> > -append "root=/dev/vda rw console=ttyAMA0 kgdboc=ttyAMA0,115200 \
> > earlycon preempt=voluntary irqchip.gicv3_pseudo_nmi=1 audit=1" \
> > -drive if=none,file=images/rootfs.ext4,format=raw,id=hd0 \
> > -device virtio-blk-device,drive=hd0 \
> >
> > Changes in v14:
> > - Initialize ret = 0 in syscall_trace_enter().
> > - Split into two patch sets as Linus Walleij suggested, so this patch set
> > can be applied separately to the arm64 tree.
> > - Rebased on arm64 for-next/core branch.
> > - Collect Reviewed-by and Acked-by.
> > - Link to v13 resend: https://lore.kernel.org/all/20260317082020.737779-15-ruanjinjie@huawei.com/
> >
> > Changes in v13 resend:
> > - Fix exit_to_user_mode_prepare_legacy() issues.
> > - Also move TIF_SINGLESTEP to generic TIF infrastructure for loongarch.
> > - Use generic TIF bits for arm64 and moving TIF_SINGLESTEP to
> > generic TIF for related architectures separately.
> > - Refactor syscall_trace_enter/exit() to accept flags and Use
> > syscall_get_nr() helper separately.
> > - Tested with slice_test for rseq optimizations.
> > - Add acked-by.
> > - Link to v13: https://lore.kernel.org/all/20260313094738.3985794-1-ruanjinjie@huawei.com/
> >
> > Changes in v13:
> > - Rebased on v7.0-rc3, so drop the firt applied arm64 patch.
> > - Use generic TIF bits to enables RSEQ optimization.
> > - Update most of the commit message to make it more clear.
> > - Link to v12: https://lore.kernel.org/all/20260203133728.848283-1-ruanjinjie@huawei.com/
> >
> > Changes in v12:
> > - Rebased on "sched/core", so remove the four generic entry patches.
> > - Move "Expand secure_computing() in place" and
> > "Use syscall_get_arguments() helper" patch forward, which will group all
> > non-functional cleanups at the front.
> > - Adjust the explanation for moving rseq_syscall() before
> > audit_syscall_exit().
> > - Link to v11: https://lore.kernel.org/all/20260128031934.3906955-1-ruanjinjie@huawei.com/
> >
> > Changes in v11:
> > - Remove unused syscall in syscall_trace_enter().
> > - Update and provide a detailed explanation of the differences after
> > moving rseq_syscall() before audit_syscall_exit().
> > - Rebased on arm64 (for-next/entry), and remove the first applied 3 patchs.
> > - syscall_exit_to_user_mode_work() for arch reuse instead of adding
> > new syscall_exit_to_user_mode_work_prepare() helper.
> > - Link to v10: https://lore.kernel.org/all/20251222114737.1334364-1-ruanjinjie@huawei.com/
> >
> > Changes in v10:
> > - Rebased on v6.19-rc1, rename syscall_exit_to_user_mode_prepare() to
> > syscall_exit_to_user_mode_work_prepare() to avoid conflict.
> > - Also inline syscall_trace_enter().
> > - Support aarch64 for sud_benchmark.
> > - Update and correct the commit message.
> > - Add Reviewed-by.
> > - Link to v9: https://lore.kernel.org/all/20251204082123.2792067-1-ruanjinjie@huawei.com/
> >
> > Changes in v9:
> > - Move "Return early for ptrace_report_syscall_entry() error" patch ahead
> > to make it not introduce a regression.
> > - Not check _TIF_SECCOMP/SYSCALL_EMU for syscall_exit_work() in
> > a separate patch.
> > - Do not report_syscall_exit() for PTRACE_SYSEMU_SINGLESTEP in a separate
> > patch.
> > - Add two performance patch to improve the arm64 performance.
> > - Add Reviewed-by.
> > - Link to v8: https://lore.kernel.org/all/20251126071446.3234218-1-ruanjinjie@huawei.com/
> >
> > Changes in v8:
> > - Rename "report_syscall_enter()" to "report_syscall_entry()".
> > - Add ptrace_save_reg() to avoid duplication.
> > - Remove unused _TIF_WORK_MASK in a standalone patch.
> > - Align syscall_trace_enter() return value with the generic version.
> > - Use "scno" instead of regs->syscallno in el0_svc_common().
> > - Move rseq_syscall() ahead in a standalone patch to clarify it clearly.
> > - Rename "syscall_trace_exit()" to "syscall_exit_work()".
> > - Keep the goto in el0_svc_common().
> > - No argument was passed to __secure_computing() and check -1 not -1L.
> > - Remove "Add has_syscall_work() helper" patch.
> > - Move "Add syscall_exit_to_user_mode_prepare() helper" patch later.
> > - Add miss header for asm/entry-common.h.
> > - Update the implementation of arch_syscall_is_vdso_sigreturn().
> > - Add "ARCH_SYSCALL_WORK_EXIT" to be defined as "SECCOMP | SYSCALL_EMU"
> > to keep the behaviour unchanged.
> > - Add more testcases test.
> > - Add Reviewed-by.
> > - Update the commit message.
> > - Link to v7: https://lore.kernel.org/all/20251117133048.53182-1-ruanjinjie@huawei.com/
> >
> > Jinjie Ruan (10):
> > arm64/ptrace: Refactor syscall_trace_enter/exit() to accept flags
> > parameter
> > arm64/ptrace: Use syscall_get_nr() helper for syscall_trace_enter()
> > arm64/ptrace: Expand secure_computing() in place
> > arm64/ptrace: Use syscall_get_arguments() helper for audit
> > arm64: ptrace: Move rseq_syscall() before audit_syscall_exit()
> > arm64: syscall: Introduce syscall_exit_to_user_mode_work()
> > arm64/ptrace: Define and use _TIF_SYSCALL_EXIT_WORK
> > arm64/ptrace: Skip syscall exit reporting for PTRACE_SYSEMU_SINGLESTEP
> > arm64: entry: Convert to generic entry
> > arm64: Inline el0_svc_common()
> >
> > arch/arm64/Kconfig | 2 +-
> > arch/arm64/include/asm/entry-common.h | 76 +++++++++++++++++
> > arch/arm64/include/asm/syscall.h | 19 ++++-
> > arch/arm64/include/asm/thread_info.h | 16 +---
> > arch/arm64/kernel/debug-monitors.c | 7 ++
> > arch/arm64/kernel/entry-common.c | 25 ++++--
> > arch/arm64/kernel/ptrace.c | 115 --------------------------
> > arch/arm64/kernel/signal.c | 2 +-
> > arch/arm64/kernel/syscall.c | 29 ++-----
> > include/linux/irq-entry-common.h | 8 --
> > include/linux/rseq_entry.h | 18 ----
> > 11 files changed, 130 insertions(+), 187 deletions(-)
> >
^ permalink raw reply
* Re: [PATCH v3 2/3] ARM: dts: aspeed-g6: Add nodes for i3c controllers
From: Krzysztof Kozlowski @ 2026-04-09 7:31 UTC (permalink / raw)
To: Dawid Glazik
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed, linux-i3c, devicetree,
linux-arm-kernel, Frank Li, Maciej Lawniczak, Jeremy Kerr
In-Reply-To: <51c4bdc02b45f67a0e32610a228091e137c135a6.1775679285.git.dawid.glazik@linux.intel.com>
On Wed, Apr 08, 2026 at 10:34:34PM +0200, Dawid Glazik wrote:
> + bus@1e7a0000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x1e7a0000 0x8000>;
> +
> + i3c_global: i3c-global@0 {
> + compatible = "aspeed,ast2600-i3c-global", "syscon";
Also undocumented ABI. Apply this patch and run checkpatch.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 3/3] dt-bindings: i3c: Add AST2600 I3C global registers
From: Krzysztof Kozlowski @ 2026-04-09 7:30 UTC (permalink / raw)
To: Dawid Glazik
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed, linux-i3c, devicetree,
linux-arm-kernel, Frank Li, Maciej Lawniczak
In-Reply-To: <20260409-beneficial-sociable-tamarin-dbcaeb@quoll>
On 09/04/2026 09:28, Krzysztof Kozlowski wrote:
> On Wed, Apr 08, 2026 at 10:34:35PM +0200, Dawid Glazik wrote:
>> Introduce the device-tree bindings for I3C global registers found on
>> AST2600 SoCs.
>>
>> Signed-off-by: Dawid Glazik <dawid.glazik@linux.intel.com>
>> ---
>> I wasn't sure if I should add newline at the end of the
>> file or not so I took
>> https://github.com/torvalds/linux/tree/master/Documentation/devicetree/bindings/i3c
>> as an example.
>
> Answer is: you cannot have patch warnings.
>
> Documentation/devicetree/bindings/i3c does not have patch warning, does
> it?
And if you tested this code with standard tools, you would see that...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/3] ARM: dts: aspeed-g6: Add nodes for i3c controllers
From: Krzysztof Kozlowski @ 2026-04-09 7:30 UTC (permalink / raw)
To: Dawid Glazik
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, linux-aspeed, linux-i3c, devicetree,
linux-arm-kernel, Frank Li, Maciej Lawniczak, Jeremy Kerr
In-Reply-To: <51c4bdc02b45f67a0e32610a228091e137c135a6.1775679285.git.dawid.glazik@linux.intel.com>
On Wed, Apr 08, 2026 at 10:34:34PM +0200, Dawid Glazik wrote:
> Add the i3c controller devices to the ast2600 g6 common dts. We add all
> 6 busses to the common g6 definition, but leave disabled through the
> status property, to be enabled per-platform.
>
> Originally-by: Jeremy Kerr <jk@codeconstruct.com.au>
Don't invent tags. This is not used outside of TIP.
> Signed-off-by: Dawid Glazik <dawid.glazik@linux.intel.com>
> ---
> v3:
> - add i3c aliases
> - rebase on top of latest tree and solve conflicts
> - as agreed with Jeremy off-list, he said I can take authorship of this going forward
> v2:
> - use inline bus representation, without the i3c: label
> ---
> arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 97 +++++++++++++++++++++++++
> 1 file changed, 97 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> index f5641128614f..f986fcbed604 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> +++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
> @@ -29,6 +29,12 @@ aliases {
> i2c13 = &i2c13;
> i2c14 = &i2c14;
> i2c15 = &i2c15;
> + i3c0 = &i3c0;
> + i3c1 = &i3c1;
> + i3c2 = &i3c2;
> + i3c3 = &i3c3;
> + i3c4 = &i3c4;
> + i3c5 = &i3c5;
Bus aliases are not properties of SoC DTSI.
> serial0 = &uart1;
> serial1 = &uart2;
> serial2 = &uart3;
> @@ -1066,6 +1072,97 @@ i2c15: i2c@800 {
> };
> };
>
> + bus@1e7a0000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x1e7a0000 0x8000>;
> +
> + i3c_global: i3c-global@0 {
Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
If you cannot find a name matching your device, please check in kernel
sources for similar cases or you can grow the spec (via pull request to
DT spec repo).
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