* 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 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 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] 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 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 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
* [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 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
* 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 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
* [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
* [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
* Re: [PATCH] clk: clk-imx8mm: Initialize clocks in arch_initcall
From: Paul Geurts @ 2026-04-09 9:16 UTC (permalink / raw)
To: abelvesa, peng.fan, mturquette, sboyd, Frank.Li, s.hauer, kernel,
festevam, shawnguo, linux-clk, imx, linux-arm-kernel,
linux-kernel
Cc: martijn.de.gouw
In-Reply-To: <9f36af74-ef1a-4777-a1c3-ff13b68c2221@pengutronix.de>
> Hello Paul,
>
> On 4/8/26 12:13 PM, Paul Geurts wrote:
> > The i.MX8MM clock driver is implemented as module_platform_driver();,
> > which makes it initialize in device_initcall(). This means that all
> > drivers referencing the clock driver nodes in the device tree are
> > deferred by fw_devlink, which are most of the i.MX8M platform drivers.
> >
> > Explicitly initialize the clock driver in arch_initcall(), to make sure
> > the clock driver is ready when the rest of the drivers are probed.
> >
> > Fixes: af7e7ee0e428 ("clk: imx8mm: Switch to platform driver")
>
> Your commit message doesn't explain why this was a problem for you.
> Does it delay your boot? What makes this patch a fix?
Yes I could update that in the commit description. The problem is that because
of this, _all_ hardware is initialized in late_initcall, as that is where
deferred probes are handled. For embedded devices, some sign of life is
expected by most people during boot. Especially when an initrd needs to be
unpacked, this sign of life is going to take a very long time. Some display
controllers don't even get enough time to show the boot logo because of this.
I don't think the idea behind the initcall levels is that _everything_ is
initialized in late.
>
> > Signed-off-by: Paul Geurts <paul.geurts@prodrive-technologies.com>
> > ---
> > drivers/clk/imx/clk-imx8mm.c | 14 +++++++++++++-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
> > index 319af4deec01..7b2cf867b920 100644
> > --- a/drivers/clk/imx/clk-imx8mm.c
> > +++ b/drivers/clk/imx/clk-imx8mm.c
> > @@ -636,7 +636,19 @@ static struct platform_driver imx8mm_clk_driver = {
> > .of_match_table = imx8mm_clk_of_match,
> > },
> > };
> > -module_platform_driver(imx8mm_clk_driver);
> > +
> > +static int __init imx8mm_clk_init(void)
> > +{
> > + return platform_driver_register(&imx8mm_clk_driver);
> > +}
> > +arch_initcall(imx8mm_clk_init);
>
> What happens if you build the driver as module with your changes applied?
On module insertion, there is no initcall level, and initialization is
performed on insertion (AFAIK). Fact is that the system would probably
not boot when this is built as a module, as there are no peripheral clocks
without it.
>
> Cheers,
> Ahmad
>
> > +
> > +static void __exit imx8mm_clk_exit(void)
> > +{
> > + platform_driver_unregister(&imx8mm_clk_driver);
> > +}
> > +module_exit(imx8mm_clk_exit);
> > +
> > module_param(mcore_booted, bool, S_IRUGO);
> > MODULE_PARM_DESC(mcore_booted, "See Cortex-M core is booted or not");
> >
Thanks!
Paul
^ permalink raw reply
* Re: [PATCH] clk: clk-imx8mm: Initialize clocks in arch_initcall
From: Paul Geurts @ 2026-04-09 9:29 UTC (permalink / raw)
To: peng.fan
Cc: abelvesa, mturquette, sboyd, Frank.Li, s.hauer, kernel, festevam,
shawnguo, linux-clk, imx, linux-arm-kernel, linux-kernel,
martijn.de.gouw, paul.geurts
In-Reply-To: <addMdwvnDkCMJxhx@shlinux89>
> On Wed, Apr 08, 2026 at 12:13:13PM +0200, Paul Geurts wrote:
> >The i.MX8MM clock driver is implemented as module_platform_driver();,
> >which makes it initialize in device_initcall(). This means that all
> >drivers referencing the clock driver nodes in the device tree are
> >deferred by fw_devlink, which are most of the i.MX8M platform drivers.
> >
> >Explicitly initialize the clock driver in arch_initcall(), to make sure
> >the clock driver is ready when the rest of the drivers are probed.
>
> Let's keep as it is, changing to arch_initcall() is not allowed.
Why is it not allowed? This is an arch driver, so I think it should be
initialized in arch? I don't think the initcall system was intended to
initialize everything in late_initcall, which is effectively what this
problem is causing.
>
> Thanks,
> Peng
Thanks!
Paul
^ permalink raw reply
* [PATCH v1] arm64: dts: freescale: imx95-verdin-ivy: fix RS485 RTS polarity
From: Francesco Dolcini @ 2026-04-09 9:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Francesco Dolcini, devicetree, imx, linux-arm-kernel,
linux-kernel
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Fix the RS485 functionality, the RS485 RTS signal is active high on Ivy.
Fixes: f33a1f9a942c ("arm64: dts: freescale: imx95-verdin: Add Ivy carrier board")
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/freescale/imx95-verdin-ivy.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95-verdin-ivy.dtsi b/arch/arm64/boot/dts/freescale/imx95-verdin-ivy.dtsi
index 8337c8b25f05..ff31f7c48cfb 100644
--- a/arch/arm64/boot/dts/freescale/imx95-verdin-ivy.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-verdin-ivy.dtsi
@@ -452,7 +452,6 @@ &lpuart7 {
/* Verdin UART_2, through RS485 transceiver */
&lpuart8 {
- rs485-rts-active-low;
rs485-rx-during-tx;
linux,rs485-enabled-at-boot-time;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Suzuki K Poulose @ 2026-04-09 9:38 UTC (permalink / raw)
To: Catalin Marinas
Cc: Ryan Roberts, Will Deacon, David Hildenbrand (Arm), Dev Jain,
Yang Shi, Jinjiang Tu, Kevin Brodsky, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <adU9KxLC7yKgmyJy@arm.com>
On 07/04/2026 18:21, Catalin Marinas wrote:
> On Tue, Apr 07, 2026 at 10:57:35AM +0100, Suzuki K Poulose wrote:
>> On 02/04/2026 21:43, Catalin Marinas wrote:
>>> On Mon, Mar 30, 2026 at 05:17:02PM +0100, Ryan Roberts wrote:
>>>> int split_kernel_leaf_mapping(unsigned long start, unsigned long end)
>>>> {
>>>> int ret;
>>>> - /*
>>>> - * !BBML2_NOABORT systems should not be trying to change permissions on
>>>> - * anything that is not pte-mapped in the first place. Just return early
>>>> - * and let the permission change code raise a warning if not already
>>>> - * pte-mapped.
>>>> - */
>>>> - if (!system_supports_bbml2_noabort())
>>>> - return 0;
>>>> -
>>>> /*
>>>> * If the region is within a pte-mapped area, there is no need to try to
>>>> * split. Additionally, CONFIG_DEBUG_PAGEALLOC and CONFIG_KFENCE may
>>>> * change permissions from atomic context so for those cases (which are
>>>> * always pte-mapped), we must not go any further because taking the
>>>> - * mutex below may sleep.
>>>> + * mutex below may sleep. Do not call force_pte_mapping() here because
>>>> + * it could return a confusing result if called from a secondary cpu
>>>> + * prior to finalizing caps. Instead, linear_map_requires_bbml2 gives us
>>>> + * what we need.
>>>> */
>>>> - if (force_pte_mapping() || is_kfence_address((void *)start))
>>>> + if (!linear_map_requires_bbml2 || is_kfence_address((void *)start))
>>>> return 0;
>>>> + if (!system_supports_bbml2_noabort()) {
>>>> + /*
>>>> + * !BBML2_NOABORT systems should not be trying to change
>>>> + * permissions on anything that is not pte-mapped in the first
>>>> + * place. Just return early and let the permission change code
>>>> + * raise a warning if not already pte-mapped.
>>>> + */
>>>> + if (system_capabilities_finalized())
>>>> + return 0;
>>>> +
>>>> + /*
>>>> + * Boot-time: split_kernel_leaf_mapping_locked() allocates from
>>>> + * page allocator. Can't split until it's available.
>>>> + */
>>>> + if (WARN_ON(!page_alloc_available))
>>>> + return -EBUSY;
>>>> +
>>>> + /*
>>>> + * Boot-time: Started secondary cpus but don't know if they
>>>> + * support BBML2_NOABORT yet. Can't allow splitting in this
>>>> + * window in case they don't.
>>>> + */
>>>> + if (WARN_ON(num_online_cpus() > 1))
>>>> + return -EBUSY;
>>>> + }
>>>
>>> I think sashiko is over cautions here
>>> (https://sashiko.dev/#/patchset/20260330161705.3349825-1-ryan.roberts@arm.com)
>>> but it has a somewhat valid point from the perspective of
>>> num_online_cpus() semantics. We have have num_online_cpus() == 1 while
>>> having a secondary CPU just booted and with its MMU enabled. I don't
>>> think we can have any asynchronous tasks running at that point to
>>> trigger a spit though. Even async_init() is called after smp_init().
>>>
>>> An option may be to attempt cpus_read_trylock() as this lock is taken by
>>> _cpu_up(). If it fails, return -EBUSY, otherwise check num_online_cpus()
>>> and unlock (and return -EBUSY if secondaries already started).
>>>
>>> Another thing I couldn't get my head around - IIUC is_realm_world()
>>> won't return true for map_mem() yet (if in a realm).
>>
>> That is correct. map_mem() comes from paginig_init(), which gets called
>> before arm64_rsi_init(). Realm check was delayed until psci_xx_init().
>> We had a version which parsed the DT for PSCI conduit early enough
>> to be able to make the SMC calls to detect the Realm. But there
>> were concerns around it.
>
> Ah, yes, I remember.
>
> Does it mean that commit 42be24a4178f ("arm64: Enable memory encrypt for
> Realms") was broken without rodata=full w.r.t. the linear map? Commit
Apparently, it looks like we missed this when we demoted the RSI
detection later.
> a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full")
> introduced force_pte_mapping() but it just copied the logic in the
> existing can_set_direct_map(). Looking at the linear_map_requires_bbml2
> assignment, we get (!is_realm_world() && is_realm_world()) and it
> cancels out, no effect on it but we don't get pte mappings either (even
> if we don't have BBML2).
Yep, that's right.
>
> I think we need at least some safety checks:
>
> 1. BBML2_NOABORT support on the boot CPU - continue with the existing
> logic (as per Ryan's series)
>
> 2. !system_supports_bbml2_noabort() - split in
> linear_map_maybe_split_to_ptes(). This does not currently happen
> because linear_map_requires_bbml2 may be false in the absence of
> rodata=full. Not sure how to fix this without some variable telling
> us how the linear map was mapped. The requires_bbml2 flag doesn't
>
> 3. Panic in arm64_rsi_init() if !BBML2_NOABORT on the boot CPU _and_ we
> have block mappings already. People can avoid it with rodata=full
It looks like this will be a common case :-(
>
> 4. If (3) is a common case, a better alternative is to rewrite the
> linear map sometime after arm64_rsi_init() but before we call
> split_kernel_leaf_mapping().
We will explore this route.
The other option is to move the RSI detection (and the PSCI probe)
earlier to be able to make better decisions early on. I will play with
that a bit too.
Suzuki
>
^ permalink raw reply
* Re: [PATCH v3 0/7] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Vignesh Raghavendra @ 2026-04-09 9:46 UTC (permalink / raw)
To: Rob Herring, Markus Schneider-Pargmann (TI)
Cc: Nishanth Menon, devicetree, Conor Dooley, Tero Kristo,
Mathieu Poirier, Dhruva Gole, Akashdeep Kaur, Kevin Hilman,
Bjorn Andersson, linux-remoteproc, linux-kernel, Kendall Willis,
Vishal Mahaveer, Sebin Francis, Krzysztof Kozlowski,
linux-arm-kernel
In-Reply-To: <CAL_JsqJq=3z7SQX_26MGGRcmysnGHVke8aTwyDCesvOuQjEN+g@mail.gmail.com>
Hi Markus
On 08/04/26 20:33, Rob Herring wrote:
> On Wed, Mar 18, 2026 at 10:14 AM Markus Schneider-Pargmann (TI)
> <msp@baylibre.com> wrote:
>>
>> Hi,
>>
>> Split the firmware memory region in more specific parts so it is better
>> described where which information is stored. Specifically the LPM metadata
>> region is important as bootloader software like U-Boot has to know where
>> that data is to be able to read that data and resume from RAM.
>>
>> IO+DDR is a deep sleep state in which a few pins are set to be sensitive
>> for wakeup while the DDR is kept in self refresh. Everything else is
>> powered off.
>>
>> The changes in this series were suggested as part of the IO+DDR u-boot series:
>> https://lore.kernel.org/r/814c211f-a9eb-4311-bb84-165b1a69755f@ti.com
>>
>> There are currently no real users of the memory-region that is split in
>> this series. The size of the memory-region in total stays the same.
>> The new layout is derived from the software running on the r5f
>> processor:
>> https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62ax-sk/r5fss0-0_freertos/ti-arm-clang/linker.cmd#L172
>> https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/source/drivers/device_manager/sciclient.h#L459
>>
>> Additionally the two important devicetree nodes for resuming from IO+DDR
>> have the bootph-pre-ram flag added as this data needs to be read before
>> the RAM is in use.
>>
>> Best
>> Markus
>>
>> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
>> ---
>> Changes in v3:
>> - Squash the enforcement of the memory-region-names requirement in the
>> patch adding the memory-region-names, as suggested.
>> - Link to v2: https://lore.kernel.org/r/20260312-topic-am62a-ioddr-dt-v6-19-v2-0-37cb7ceec658@baylibre.com
>>
>> Changes in v2:
>> - Make memory-region-names required if memory-region is present
>> - Fixup memory-region and memory-region-names conditions. Require either
>> 2 or 6 regions for memory-region and memory-region-names
>> - Reword and restructure the binding documentation for memory-region and
>> memory-region-names
>> - Add memory-region-names to all uses of memory-region
>> - Link to v1: https://lore.kernel.org/r/20260303-topic-am62a-ioddr-dt-v6-19-v1-0-12fe72bb40d2@baylibre.com
>>
>> ---
>> Markus Schneider-Pargmann (TI) (7):
>> dt-bindings: remoteproc: k3-r5f: Split up memory regions
>> dt-bindings: remoteproc: k3-r5f: Add memory-region-names
>> arm64: dts: ti: k3: Use memory-region-names for r5f
>> arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
>> arm64: dts: ti: k3-am62p5-sk: Split r5f memory region
>> arm64: dts: ti: k3-am62a7-sk: Add r5f nodes to pre-ram bootphase
>> arm64: dts: ti: k3-am62p5-sk: Add r5f nodes to pre-ram bootphase
>
> TI folks, Please make sure these dts patches are picked up for 7.1.
> There's now a crap load of warnings in next with the binding change:
>
> 58 (ti,am62-r5fss): r5f@78000000: 'memory-region-names' is a
> required property
[...]
> If they aren't applied, making 'memory-region-names' required needs
> to be dropped from the binding.
>
This breaks DT backward compatibility. Why is memory-region-names now a
required item and cannot be assumed as "dma" and "firmware" as default?
Is that intentional (should have at least had a Fixes tag then if the
original definition was wrong)?
--
Regards
Vignesh
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH v1] phy: rockchip-snps-pcie3:phy: Configure clkreq_n and PowerDown for all lanes
From: Niklas Cassel @ 2026-04-09 9:49 UTC (permalink / raw)
To: Anand Moon, Shawn Lin
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner,
open list:GENERIC PHY FRAMEWORK,
moderated list:ARM/Rockchip SoC support,
open list:ARM/Rockchip SoC support, open list
In-Reply-To: <20260409044939.7647-1-linux.amoon@gmail.com>
+Shawn
Hello Anand,
On Thu, Apr 09, 2026 at 10:19:30AM +0530, Anand Moon wrote:
> During the rk3588_p3phy_init sequence, the driver now explicitly
Please use imperative mood, active voice.
> configures each lane's CON0 register to ensure
> - PIPE 4.3 Compliance: clkreq_n (bit 6) is forced low (asserted) to meet
> sideband signal requirements.
> - Active Power State: PowerDown[3:0] (bits 11:8) is set to P0
> (Normal Operational State) to ensure the PHY is fully powered and ready
> for link training.
>
> These changes ensure that all lanes are consistently transitioned from
> reset into a known-good operational state, preventing undefined behavior
> and ensuring the PHY is ready for high-speed data transmission.
First describe the problem, then describe how you fix it.
Kind regards,
Niklas
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Kevin Brodsky @ 2026-04-09 9:53 UTC (permalink / raw)
To: Catalin Marinas, Ryan Roberts
Cc: Will Deacon, David Hildenbrand (Arm), Dev Jain, Yang Shi,
Suzuki K Poulose, Jinjiang Tu, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <adTh8d9k3y5ybemL@arm.com>
On 07/04/2026 12:52, Catalin Marinas wrote:
>> if we have forced pte mapping then the value of
>> can_set_direct_map() is irrelevant - we will never need to split because we are
>> already pte-mapped.
> can_set_direct_map() is used in other places, so its value is
> relevant, e.g. sys_memfd_secret() is rejected if this function returns
> false.
Indeed, I have noticed this before: currently set_direct_map_*_noflush()
and other functions will either fail or do nothing if none of the
features (rodata=full, etc.) is enabled, even if we would be able to
split the linear map using BBML2-noabort.
What would make more sense to me is to enable the use of BBML2-noabort
unconditionally if !force_pte_mapping(). We can then have
can_set_direct_map() return true if we have BBML2-noabort, and we no
longer need to check it in map_mem().
This is a functional change that doesn't have anything to do with realms
so it should probably be a separate series - happy to take care of it
once the dust settles on the realm handling.
- Kevin
^ permalink raw reply
* [PATCH v1 2/7] arm64: dts: freescale: imx8mm-verdin: Split UART_2 pinctrl group
From: Francesco Dolcini @ 2026-04-09 9:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: Francesco Dolcini, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260409095855.61252-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Some carrier board reuse the UART_2 control signals as GPIO, split
the pinctrl RTS/CTS in separated nodes to maximize flexibility.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
index 1594ce9182a5..5fc177f589cb 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
@@ -735,7 +735,7 @@ &uart2 {
/* Verdin UART_2 */
&uart3 {
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart3>;
+ pinctrl-0 = <&pinctrl_uart3>, <&pinctrl_uart3_cts>, <&pinctrl_uart3_rts>;
uart-has-rtscts;
};
@@ -1144,12 +1144,20 @@ pinctrl_uart2: uart2grp {
<MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX 0x146>; /* SODIMM 129 */
};
+ pinctrl_uart3_cts: uart3ctsgrp {
+ fsl,pins =
+ <MX8MM_IOMUXC_ECSPI1_SS0_UART3_DCE_RTS_B 0x146>; /* SODIMM 143 */
+ };
+
+ pinctrl_uart3_rts: uart3rtsgrp {
+ fsl,pins =
+ <MX8MM_IOMUXC_ECSPI1_MISO_UART3_DCE_CTS_B 0x146>; /* SODIMM 141 */
+ };
+
pinctrl_uart3: uart3grp {
fsl,pins =
- <MX8MM_IOMUXC_ECSPI1_MISO_UART3_DCE_CTS_B 0x146>, /* SODIMM 141 */
<MX8MM_IOMUXC_ECSPI1_MOSI_UART3_DCE_TX 0x146>, /* SODIMM 139 */
- <MX8MM_IOMUXC_ECSPI1_SCLK_UART3_DCE_RX 0x146>, /* SODIMM 137 */
- <MX8MM_IOMUXC_ECSPI1_SS0_UART3_DCE_RTS_B 0x146>; /* SODIMM 143 */
+ <MX8MM_IOMUXC_ECSPI1_SCLK_UART3_DCE_RX 0x146>; /* SODIMM 137 */
};
pinctrl_uart4: uart4grp {
--
2.47.3
^ permalink raw reply related
* [PATCH v1 0/7] Add verdin imx8m[mp] and imx95 zinnia board
From: Francesco Dolcini @ 2026-04-09 9:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: Francesco Dolcini, devicetree, linux-kernel, imx,
linux-arm-kernel
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Add Zinnia Carrier Board mated with Verdin iMX8M Plus, Verdin iMX8M Mini and
Verdin iMX95.
It features 1 x RS232, 1 x RS485, 1 x CAN, 3 x isolated digital I/O,
2 x 1GBit/s Ethernet, a mini PCIe slot with USB / SIM card connector
for a modem, USB and SD card interfaces.
Some small fixes and cleanup are done on the SOM dtsi file, in preparation
for the Zinnia addition.
Shawn, Frank: bindings/arm/fsl.yaml still list Shawn as maintainer, maybe
confirm that this is wanted.
Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
Francesco Dolcini (7):
dt-bindings: arm: fsl: Add verdin imx8m[mp] and imx95 zinnia board
arm64: dts: freescale: imx8mm-verdin: Split UART_2 pinctrl group
arm64: dts: freescale: imx8mm-verdin: Add Zinnia
arm64: dts: freescale: imx8mp-verdin: Split UART_2 pinctrl group
arm64: dts: freescale: imx8mp-verdin: Add Zinnia
arm64: dts: freescale: imx95-verdin: Split UART_2 pinctrl group
arm64: dts: freescale: imx95-verdin: Add Zinnia
.../devicetree/bindings/arm/fsl.yaml | 6 +
arch/arm64/boot/dts/freescale/Makefile | 6 +
.../imx8mm-verdin-nonwifi-zinnia.dts | 21 +
.../freescale/imx8mm-verdin-wifi-zinnia.dts | 21 +
.../dts/freescale/imx8mm-verdin-zinnia.dtsi | 383 ++++++++++++++++
.../boot/dts/freescale/imx8mm-verdin.dtsi | 16 +-
.../imx8mp-verdin-nonwifi-zinnia.dts | 21 +
.../freescale/imx8mp-verdin-wifi-zinnia.dts | 21 +
.../dts/freescale/imx8mp-verdin-zinnia.dtsi | 422 +++++++++++++++++
.../boot/dts/freescale/imx8mp-verdin.dtsi | 14 +-
.../freescale/imx95-verdin-nonwifi-zinnia.dts | 21 +
.../freescale/imx95-verdin-wifi-zinnia.dts | 21 +
.../dts/freescale/imx95-verdin-zinnia.dtsi | 429 ++++++++++++++++++
.../boot/dts/freescale/imx95-verdin.dtsi | 18 +-
14 files changed, 1408 insertions(+), 12 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-zinnia.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-zinnia.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-wifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-zinnia.dtsi
--
2.47.3
^ permalink raw reply
* [PATCH v1 6/7] arm64: dts: freescale: imx95-verdin: Split UART_2 pinctrl group
From: Francesco Dolcini @ 2026-04-09 9:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: Francesco Dolcini, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260409095855.61252-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Some carrier board reuse the UART_2 control signals as GPIO, split
the pinctrl RTS/CTS in separated nodes to maximize flexibility.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
.../arm64/boot/dts/freescale/imx95-verdin.dtsi | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx95-verdin.dtsi
index d3737956e2f9..72e7f1e88409 100644
--- a/arch/arm64/boot/dts/freescale/imx95-verdin.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-verdin.dtsi
@@ -541,7 +541,7 @@ &lpuart7 {
/* Verdin UART_2 */
&lpuart8 {
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart8>;
+ pinctrl-0 = <&pinctrl_uart8>, <&pinctrl_uart8_cts>, <&pinctrl_uart8_rts>;
uart-has-rtscts;
};
@@ -1058,12 +1058,20 @@ pinctrl_uart7: uart7grp {
<IMX95_PAD_GPIO_IO11__LPUART7_RTS_B 0x31e>; /* SODIMM 133 */
};
- /* Verdin UART_2 */
+ /* Verdin UART_2 CTS */
+ pinctrl_uart8_cts: uart8ctsgrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO14__LPUART8_CTS_B 0x31e>; /* SODIMM 143 */
+ };
+
+ /* Verdin UART_2 RTS */
+ pinctrl_uart8_rts: uart8rtsgrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO15__LPUART8_RTS_B 0x31e>; /* SODIMM 141 */
+ };
+
+ /* Verdin UART_2 RX/TX */
pinctrl_uart8: uart8grp {
fsl,pins = <IMX95_PAD_GPIO_IO12__LPUART8_TX 0x31e>, /* SODIMM 139 */
- <IMX95_PAD_GPIO_IO13__LPUART8_RX 0x31e>, /* SODIMM 137 */
- <IMX95_PAD_GPIO_IO14__LPUART8_CTS_B 0x31e>, /* SODIMM 143 */
- <IMX95_PAD_GPIO_IO15__LPUART8_RTS_B 0x31e>; /* SODIMM 141 */
+ <IMX95_PAD_GPIO_IO13__LPUART8_RX 0x31e>; /* SODIMM 137 */
};
/* On-module eMMC */
--
2.47.3
^ permalink raw reply related
* [PATCH v1 3/7] arm64: dts: freescale: imx8mm-verdin: Add Zinnia
From: Francesco Dolcini @ 2026-04-09 9:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: Francesco Dolcini, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260409095855.61252-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Add Zinnia Carrier Board mated with Verdin iMX8M Mini.
It features 1 x RS232, 1 x RS485, 1 x CAN, 3 x isolated digital I/O,
1 x GBit/s Ethernet, a mini PCIe slot with USB / SIM card connector
for a modem, USB and SD card interfaces.
Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../imx8mm-verdin-nonwifi-zinnia.dts | 21 +
.../freescale/imx8mm-verdin-wifi-zinnia.dts | 21 +
.../dts/freescale/imx8mm-verdin-zinnia.dtsi | 383 ++++++++++++++++++
4 files changed, 427 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-zinnia.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 711e36cc2c99..072df4128716 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -177,11 +177,13 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-ivy.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-mallow.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-yavia.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-zinnia.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-dahlia.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-ivy.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-mallow.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-yavia.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-zinnia.dtb
imx8mm-tqma8mqml-mba8mx-lvds-g133han01-dtbs += imx8mm-tqma8mqml-mba8mx.dtb imx8mm-tqma8mqml-mba8mx-lvds-g133han01.dtbo
imx8mm-tqma8mqml-mba8mx-lvds-tm070jvhg33-dtbs += imx8mm-tqma8mqml-mba8mx.dtb imx8mm-tqma8mqml-mba8mx-lvds-tm070jvhg33.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-zinnia.dts b/arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-zinnia.dts
new file mode 100644
index 000000000000..07b4daf916c2
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-zinnia.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-mini-nano
+ * https://www.toradex.com/products/carrier-board/zinnia-carrier-board
+ */
+
+/dts-v1/;
+
+#include "imx8mm-verdin.dtsi"
+#include "imx8mm-verdin-nonwifi.dtsi"
+#include "imx8mm-verdin-zinnia.dtsi"
+
+/ {
+ model = "Toradex Verdin iMX8M Mini on Zinnia";
+ compatible = "toradex,verdin-imx8mm-nonwifi-zinnia",
+ "toradex,verdin-imx8mm-nonwifi",
+ "toradex,verdin-imx8mm",
+ "fsl,imx8mm";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-zinnia.dts b/arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-zinnia.dts
new file mode 100644
index 000000000000..01a254dc1e6c
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-zinnia.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-mini-nano
+ * https://www.toradex.com/products/carrier-board/zinnia-carrier-board
+ */
+
+/dts-v1/;
+
+#include "imx8mm-verdin.dtsi"
+#include "imx8mm-verdin-wifi.dtsi"
+#include "imx8mm-verdin-zinnia.dtsi"
+
+/ {
+ model = "Toradex Verdin iMX8M Mini WB on Zinnia";
+ compatible = "toradex,verdin-imx8mm-wifi-zinnia",
+ "toradex,verdin-imx8mm-wifi",
+ "toradex,verdin-imx8mm",
+ "fsl,imx8mm";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin-zinnia.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-verdin-zinnia.dtsi
new file mode 100644
index 000000000000..686486e03178
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin-zinnia.dtsi
@@ -0,0 +1,383 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * Common dtsi for Verdin IMX8MM SoM on Zinnia carrier board
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-mini-nano
+ * https://www.toradex.com/products/carrier-board/zinnia-carrier-board
+ */
+
+#include <dt-bindings/leds/common.h>
+
+/ {
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_zinnia_leds>;
+
+ /* LED1 Red - SODIMM 48 - LED1_R */
+ led-0 {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <1>;
+ gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED1 Blue - SODIMM 46 - LED1_B */
+ led-1 {
+ color = <LED_COLOR_ID_BLUE>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <1>;
+ gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED3 Red - SODIMM 44 - LED3_R */
+ led-2 {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <3>;
+ gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED3 Green - SODIMM 54 - LED3_G */
+ led-3 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <3>;
+ gpios = <&gpio3 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED3 Blue - SODIMM 36 - LED3_B */
+ led-4 {
+ color = <LED_COLOR_ID_BLUE>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <3>;
+ gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED4 Red - SODIMM 34 - LED4_R */
+ led-5 {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <4>;
+ gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED4 Green - SODIMM 32 - LED4_G */
+ led-6 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <4>;
+ gpios = <&gpio4 24 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED4 Blue - SODIMM 30 - LED4_B */
+ led-7 {
+ color = <LED_COLOR_ID_BLUE>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <4>;
+ gpios = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ zinnia-1v8-voltage {
+ compatible = "voltage-divider";
+ full-ohms = <39000>; /* 12k + 27k */
+ /* Verdin ADC_4 */
+ io-channels = <&verdin_som_adc 4>;
+ output-ohms = <27000>;
+ };
+
+ zinnia-3v3-voltage {
+ compatible = "voltage-divider";
+ full-ohms = <54000>; /* 27k + 27k */
+ /* Verdin ADC_3 */
+ io-channels = <&verdin_som_adc 5>;
+ output-ohms = <27000>;
+ };
+
+ zinnia-5v-voltage {
+ compatible = "voltage-divider";
+ full-ohms = <39000>; /* 27k + 12k */
+ /* Verdin ADC_2 */
+ io-channels = <&verdin_som_adc 6>;
+ output-ohms = <12000>;
+ };
+
+ /* Zinnia Power Supply Input Voltage */
+ zinnia-input-voltage {
+ compatible = "voltage-divider";
+ full-ohms = <204700>; /* 200k + 4.7k */
+ /* Verdin ADC_1 */
+ io-channels = <&verdin_som_adc 7>;
+ output-ohms = <4700>;
+ };
+};
+
+/* Verdin SPI_1 */
+&ecspi2 {
+ pinctrl-0 = <&pinctrl_ecspi2>, <&pinctrl_uart3_cts_gpio>;
+ cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>, <&gpio5 13 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+
+ tpm@1 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ reg = <1>;
+ spi-max-frequency = <18500000>;
+ };
+};
+
+/* EEPROM on Zinnia */
+&eeprom_carrier_board {
+ status = "okay";
+};
+
+/* Verdin ETH_1 */
+&fec1 {
+ status = "okay";
+};
+
+&gpio1 {
+ gpio-line-names =
+ "DI2_RB", /* SODIMM 216 */ /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "DO3_EN", /* SODIMM 220 */
+ "DI3_EN", /* SODIMM 222 */
+ "", /* 10 */
+ "DI2_EN", /* SODIMM 218 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "",
+ "";
+};
+
+&gpio2 {
+ gpio-line-names =
+ "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ ""; /* 20 */
+};
+
+&gpio3 {
+ gpio-line-names =
+ "", /* 0 */
+ "",
+ "",
+ "",
+ "DO1_EN", /* SODIMM 206 */
+ "",
+ "DI3_RB", /* SODIMM 56 */
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "",
+ "";
+};
+
+&gpio4 {
+ gpio-line-names =
+ "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "";
+};
+
+&gpio5 {
+ gpio-line-names =
+ "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "DI1_EN", /* SODIMM 208 */
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "DI1_RB", /* SODIMM 210 */
+ "DO2_EN", /* SODIMM 212 */
+ "",
+ "";
+};
+
+/* Temperature sensor on Zinnia */
+&hwmon_temp {
+ compatible = "ti,tmp1075";
+
+ status = "okay";
+};
+
+/* Verdin I2C_1 */
+&i2c4 {
+ status = "okay";
+};
+
+/* Verdin UART_3 */
+&uart1 {
+ status = "okay";
+};
+
+/* Verdin UART_1 */
+&uart2 {
+ status = "okay";
+};
+
+/* Verdin UART_2 */
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>, <&pinctrl_uart3_rts>;
+ rs485-rx-during-tx;
+ linux,rs485-enabled-at-boot-time;
+
+ status = "okay";
+};
+
+/* Verdin USB_1 */
+&usbotg1 {
+ status = "okay";
+};
+
+/* Verdin USB_2 */
+&usbotg2 {
+ status = "okay";
+};
+
+/* Verdin SD_1 */
+&usdhc2 {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio1>,
+ <&pinctrl_gpio2>,
+ <&pinctrl_gpio3>,
+ <&pinctrl_gpio4>,
+ <&pinctrl_gpio5>,
+ <&pinctrl_gpio6>,
+ <&pinctrl_gpio7>,
+ <&pinctrl_gpio8>,
+ <&pinctrl_qspi1_io0_gpio>;
+
+ pinctrl_qspi1_io0_gpio: gpio3io6grp {
+ fsl,pins = <MX8MM_IOMUXC_NAND_DATA00_GPIO3_IO6 0x184>; /* SODIMM 56 */
+ };
+
+ pinctrl_uart3_cts_gpio: gpio5io9grp {
+ fsl,pins = <MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x184>; /* SODIMM 143 */
+ };
+
+ pinctrl_zinnia_leds: zinnialedsgrp {
+ fsl,pins =
+ <MX8MM_IOMUXC_SAI2_TXC_GPIO4_IO25 0x16>, /* SODIMM 30 */
+ <MX8MM_IOMUXC_SAI2_TXFS_GPIO4_IO24 0x16>, /* SODIMM 32 */
+ <MX8MM_IOMUXC_SAI2_TXD0_GPIO4_IO26 0x16>, /* SODIMM 34 */
+ <MX8MM_IOMUXC_SAI2_RXD0_GPIO4_IO23 0x16>, /* SODIMM 36 */
+ <MX8MM_IOMUXC_SAI5_RXD1_GPIO3_IO22 0x16>, /* SODIMM 44 */
+ <MX8MM_IOMUXC_SAI5_RXD3_GPIO3_IO24 0x16>, /* SODIMM 46 */
+ <MX8MM_IOMUXC_SAI5_RXD0_GPIO3_IO21 0x16>, /* SODIMM 48 */
+ <MX8MM_IOMUXC_NAND_CE0_B_GPIO3_IO1 0x16>; /* SODIMM 54 */
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 1/7] dt-bindings: arm: fsl: Add verdin imx8m[mp] and imx95 zinnia board
From: Francesco Dolcini @ 2026-04-09 9:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: Francesco Dolcini, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260409095855.61252-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Add Toradex Verdin Zinnia carrier board mated with Verdin
iMX8M Plus, Verdin iMX8M Mini and Verdin iMX95.
Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 0023cd126807..f5429e6c86ff 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1025,6 +1025,7 @@ properties:
- toradex,verdin-imx8mm-nonwifi-ivy # Verdin iMX8M Mini Module on Ivy
- toradex,verdin-imx8mm-nonwifi-mallow # Verdin iMX8M Mini Module on Mallow
- toradex,verdin-imx8mm-nonwifi-yavia # Verdin iMX8M Mini Module on Yavia
+ - toradex,verdin-imx8mm-nonwifi-zinnia # Verdin iMX8M Mini Module on Zinnia
- const: toradex,verdin-imx8mm-nonwifi # Verdin iMX8M Mini Module without Wi-Fi / BT
- const: toradex,verdin-imx8mm # Verdin iMX8M Mini Module
- const: fsl,imx8mm
@@ -1037,6 +1038,7 @@ properties:
- toradex,verdin-imx8mm-wifi-ivy # Verdin iMX8M Mini Wi-Fi / BT Module on Ivy
- toradex,verdin-imx8mm-wifi-mallow # Verdin iMX8M Mini Wi-Fi / BT Module on Mallow
- toradex,verdin-imx8mm-wifi-yavia # Verdin iMX8M Mini Wi-Fi / BT Module on Yavia
+ - toradex,verdin-imx8mm-wifi-zinnia # Verdin iMX8M Mini Wi-Fi / BT Module on Zinnia
- const: toradex,verdin-imx8mm-wifi # Verdin iMX8M Mini Wi-Fi / BT Module
- const: toradex,verdin-imx8mm # Verdin iMX8M Mini Module
- const: fsl,imx8mm
@@ -1271,6 +1273,7 @@ properties:
- toradex,verdin-imx8mp-nonwifi-ivy # Verdin iMX8M Plus Module on Ivy
- toradex,verdin-imx8mp-nonwifi-mallow # Verdin iMX8M Plus Module on Mallow
- toradex,verdin-imx8mp-nonwifi-yavia # Verdin iMX8M Plus Module on Yavia
+ - toradex,verdin-imx8mp-nonwifi-zinnia # Verdin iMX8M Plus Module on Zinnia
- const: toradex,verdin-imx8mp-nonwifi # Verdin iMX8M Plus Module without Wi-Fi / BT
- const: toradex,verdin-imx8mp # Verdin iMX8M Plus Module
- const: fsl,imx8mp
@@ -1283,6 +1286,7 @@ properties:
- toradex,verdin-imx8mp-wifi-ivy # Verdin iMX8M Plus Wi-Fi / BT Module on Ivy
- toradex,verdin-imx8mp-wifi-mallow # Verdin iMX8M Plus Wi-Fi / BT Module on Mallow
- toradex,verdin-imx8mp-wifi-yavia # Verdin iMX8M Plus Wi-Fi / BT Module on Yavia
+ - toradex,verdin-imx8mp-wifi-zinnia # Verdin iMX8M Plus Wi-Fi / BT Module on Zinnia
- const: toradex,verdin-imx8mp-wifi # Verdin iMX8M Plus Wi-Fi / BT Module
- const: toradex,verdin-imx8mp # Verdin iMX8M Plus Module
- const: fsl,imx8mp
@@ -1515,6 +1519,7 @@ properties:
- toradex,verdin-imx95-nonwifi-ivy # Verdin iMX95 Module on Ivy
- toradex,verdin-imx95-nonwifi-mallow # Verdin iMX95 Module on Mallow
- toradex,verdin-imx95-nonwifi-yavia # Verdin iMX95 Module on Yavia
+ - toradex,verdin-imx95-nonwifi-zinnia # Verdin iMX95 Module on Zinnia
- const: toradex,verdin-imx95-nonwifi # Verdin iMX95 Module without Wi-Fi / BT
- const: toradex,verdin-imx95 # Verdin iMX95 Module
- const: fsl,imx95
@@ -1527,6 +1532,7 @@ properties:
- toradex,verdin-imx95-wifi-ivy # Verdin iMX95 Wi-Fi / BT Module on Ivy
- toradex,verdin-imx95-wifi-mallow # Verdin iMX95 Wi-Fi / BT Module on Mallow
- toradex,verdin-imx95-wifi-yavia # Verdin iMX95 Wi-Fi / BT Module on Yavia
+ - toradex,verdin-imx95-wifi-zinnia # Verdin iMX95 Wi-Fi / BT Module on Zinnia
- const: toradex,verdin-imx95-wifi # Verdin iMX95 Wi-Fi / BT Module
- const: toradex,verdin-imx95 # Verdin iMX95 Module
- const: fsl,imx95
--
2.47.3
^ permalink raw reply related
* [PATCH v1 4/7] arm64: dts: freescale: imx8mp-verdin: Split UART_2 pinctrl group
From: Francesco Dolcini @ 2026-04-09 9:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: Francesco Dolcini, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260409095855.61252-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Some carrier board reuse the UART_2 control signals as GPIO, split
the pinctrl RTS/CTS in separated nodes to maximize flexibility.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
index d31f8082394f..9fee2cf9ef54 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
@@ -846,7 +846,7 @@ &uart1 {
/* Verdin UART_2 */
&uart2 {
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart2>;
+ pinctrl-0 = <&pinctrl_uart2>, <&pinctrl_uart2_cts>, <&pinctrl_uart2_rts>;
uart-has-rtscts;
};
@@ -1277,10 +1277,18 @@ pinctrl_uart1: uart1grp {
<MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x1c4>; /* SODIMM 131 */
};
+ pinctrl_uart2_cts: uart2ctsgrp {
+ fsl,pins =
+ <MX8MP_IOMUXC_SD1_DATA4__UART2_DCE_RTS 0x1c4>; /* SODIMM 143 */
+ };
+
+ pinctrl_uart2_rts: uart2rtsgrp {
+ fsl,pins =
+ <MX8MP_IOMUXC_SD1_DATA5__UART2_DCE_CTS 0x1c4>; /* SODIMM 141 */
+ };
+
pinctrl_uart2: uart2grp {
fsl,pins =
- <MX8MP_IOMUXC_SD1_DATA4__UART2_DCE_RTS 0x1c4>, /* SODIMM 143 */
- <MX8MP_IOMUXC_SD1_DATA5__UART2_DCE_CTS 0x1c4>, /* SODIMM 141 */
<MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x1c4>, /* SODIMM 137 */
<MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX 0x1c4>; /* SODIMM 139 */
};
--
2.47.3
^ permalink raw reply related
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