[PATCH v4 1/3] dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6563

[PATCH v4 1/3] dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6563

[Marek Vasut]

Microchip ATA6563 is High-Speed CAN Transceiver with Standby Mode.
It is pin-compatible with TI TCAN1042 and has a compatible programming
model, therefore use ti,tcan1042 as fallback compatible.

Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: Aswath Govindraju <a-govindraju@ti.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-can@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
V2: No change
V3: No change
V4: No change
---
 Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
index 9f5c37ca6496a..75c276548e122 100644
--- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
@@ -18,6 +18,7 @@ properties:
       - items:
           - enum:
               - microchip,ata6561
+              - microchip,ata6563
               - ti,tcan1051
           - const: ti,tcan1042
       - items:
-- 
2.53.0

[PATCH v4 2/3] dt-bindings: arm: fsl: Document Data Modul i.MX95 eDM SBC

[Marek Vasut]

Document Data Modul i.MX95 eDM SBC board. This is an evaluation
board for various custom display units. Currently supported are
serial console, ethernet, eMMC, SD, SPI NOR, USB host and PCIe.

Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: Aswath Govindraju <a-govindraju@ti.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-can@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
V2: No change
V3: No change
V4: No change
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 36e28e0e4ad99..04abae2018043 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1548,6 +1548,7 @@ properties:
       - description: i.MX95 based Boards
         items:
           - enum:
+              - dmo,imx95-data-modul-edm-sbc # i.MX95 eDM SBC
               - fsl,imx95-15x15-ab2       # i.MX95 15x15 Audio Board V2
               - fsl,imx95-15x15-evk       # i.MX95 15x15 EVK Board
               - fsl,imx95-15x15-frdm      # i.MX95 15x15 FRDM Board
-- 
2.53.0

Re: [PATCH v4 2/3] dt-bindings: arm: fsl: Document Data Modul i.MX95 eDM SBC

[Krzysztof Kozlowski]

On Thu, Sep 17, 2026 at 08:25:27AM +0200, Marek Vasut wrote:
> Document Data Modul i.MX95 eDM SBC board. This is an evaluation
> board for various custom display units. Currently supported are
> serial console, ethernet, eMMC, SD, SPI NOR, USB host and PCIe.
> 
> Signed-off-by: Marek Vasut <marex@nabladev.com>

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

[PATCH v4 3/3] arm64: dts: imx95: Add support for Data Modul i.MX95 eDM SBC

[Marek Vasut]

Add support for Data Modul i.MX95 eDM SBC board. This is an
evaluation board for various custom display units. Currently
supported are serial console, ethernet, eMMC, SD, SPI NOR,
USB host and PCIe.

Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: Aswath Govindraju <a-govindraju@ti.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-can@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
V2: - Rename PCIE_M2-E_EN to PCIE_M2-M_EN
    - Fix the PCAL expander GPIO reset
V3: - Fix regulator-5p0v node name
    - Use reset-gpios consistently
V4: - Replace gpio with gpios DT property
---
 arch/arm64/boot/dts/freescale/Makefile        |    1 +
 .../freescale/imx95-data-modul-edm-sbc.dts    | 1111 +++++++++++++++++
 2 files changed, 1112 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx95-data-modul-edm-sbc.dts

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 7944e3b325130..8e4c4464788e4 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -955,6 +955,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-frdm-pro.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx95-aquila-clover.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx95-aquila-dev.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx95-data-modul-edm-sbc.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596la-mba95xxca.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596sa-mb-smarc-2.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx95-data-modul-edm-sbc.dts b/arch/arm64/boot/dts/freescale/imx95-data-modul-edm-sbc.dts
new file mode 100644
index 0000000000000..0181262eb8a98
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-data-modul-edm-sbc.dts
@@ -0,0 +1,1111 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2025-2026 Marek Vasut <marex@nabladev.com>
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/i3c/i3c.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/usb/pd.h>
+#include "imx95.dtsi"
+
+/ {
+	model = "Data Modul i.MX95 eDM SBC";
+	compatible = "dmo,imx95-data-modul-edm-sbc", "fsl,imx95";
+
+	aliases {
+		ethernet0 = &enetc_port0;
+		ethernet1 = &enetc_port1;
+		gpio0 = &gpio1;
+		gpio1 = &gpio2;
+		gpio2 = &gpio3;
+		gpio3 = &gpio4;
+		gpio4 = &gpio5;
+		i2c0 = &lpi2c1;
+		i2c1 = &lpi2c2;
+		i2c2 = &lpi2c5;
+		mmc0 = &usdhc1;
+		mmc1 = &usdhc2;
+		mmc2 = &usdhc3;
+		serial0 = &lpuart1;
+		serial1 = &lpuart2;
+		serial2 = &lpuart5;
+		serial3 = &lpuart7;
+		serial4 = &lpuart8;
+	};
+
+	chosen {
+		stdout-path = &lpuart1;
+	};
+
+	memory@80000000 {
+		device_type = "memory";
+		reg = <0x0 0x80000000 0 0x80000000>;
+	};
+
+	backlight_dsi: backlight-dsi {
+		compatible = "pwm-backlight";
+		brightness-levels = <0 1 10 20 30 40 50 60 70 75 80 90 100>;
+		default-brightness-level = <7>;
+		enable-gpios = <&i2c2_gpio_expander_21 12 GPIO_ACTIVE_HIGH>;
+		pwms = <&tpm4 3 5000000 0>;
+		/* Disabled by default, unless display board plugged in. */
+		status = "disabled";
+	};
+
+	backlight_lvds: backlight-lvds {
+		compatible = "pwm-backlight";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_panel_backlight_lvds>;
+		brightness-levels = <0 1 10 20 30 40 50 60 70 75 80 90 100>;
+		default-brightness-level = <7>;
+		enable-gpios = <&gpio2 27 GPIO_ACTIVE_HIGH>;
+		pwms = <&tpm3 3 5000000 0>;
+		/* Disabled by default, unless display board plugged in. */
+		status = "disabled";
+	};
+
+	bt_sco_codec: bt-sco-codec {
+		compatible = "linux,bt-sco";
+		#sound-dai-cells = <1>;
+	};
+
+	flexcan3_phy: can-phy0 {
+		compatible = "microchip,ata6563", "ti,tcan1042";
+		#phy-cells = <0>;
+		max-bitrate = <5000000>;
+		standby-gpios = <&i2c2_gpio_expander_20 15 GPIO_ACTIVE_HIGH>;
+	};
+
+	flexcan5_phy: can-phy1 {
+		compatible = "microchip,ata6563", "ti,tcan1042";
+		#phy-cells = <0>;
+		max-bitrate = <5000000>;
+		standby-gpios = <&i2c2_gpio_expander_20 16 GPIO_ACTIVE_HIGH>;
+	};
+
+	led {
+		compatible = "gpio-leds";
+		pinctrl-0 = <&pinctrl_led>;
+		pinctrl-names = "default";
+
+		led-0 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "off";
+			function = LED_FUNCTION_INDICATOR;
+			function-enumerator = <0>;
+			gpios = <&gpio5 9 GPIO_ACTIVE_HIGH>;
+		};
+
+		led-1 {
+			color = <LED_COLOR_ID_RED>;
+			default-state = "off";
+			function = LED_FUNCTION_INDICATOR;
+			function-enumerator = <0>;
+			gpios = <&gpio5 8 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	reg_1p8v: regulator-1p8v {
+		compatible = "regulator-fixed";
+		regulator-max-microvolt = <1800000>;
+		regulator-min-microvolt = <1800000>;
+		regulator-name = "VDD_1V8";
+	};
+
+	/* PF09 SW1, but the PMIC is controlled by CM33 */
+	reg_3p3v: regulator-3p3v {
+		compatible = "regulator-fixed";
+		regulator-max-microvolt = <3300000>;
+		regulator-min-microvolt = <3300000>;
+		regulator-name = "VDD_3V3";
+	};
+
+	reg_5p0v: regulator-5p0v {
+		compatible = "regulator-fixed";
+		regulator-max-microvolt = <5000000>;
+		regulator-min-microvolt = <5000000>;
+		regulator-name = "VDD_5V0";
+	};
+
+	reg_panel_vcc: regulator-panel-vcc {
+		compatible = "regulator-fixed";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-name = "PANEL_VCC";
+		gpios = <&i2c2_gpio_expander_20 17 0>;
+		/* Disabled by default, unless display board plugged in. */
+		status = "disabled";
+	};
+
+	reg_pcie0: regulator-pcie0 {
+		compatible = "regulator-fixed";
+		regulator-max-microvolt = <3300000>;
+		regulator-min-microvolt = <3300000>;
+		regulator-name = "PCIE_M2-B_EN";
+		gpios = <&i2c2_gpio_expander_20 6 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	reg_pcie1: regulator-pcie1 {
+		compatible = "regulator-fixed";
+		regulator-name = "PCIE_M2-M_EN";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpios = <&i2c2_gpio_expander_21 7 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	reg_usb2_vbus: regulator-usb2-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "USB2_VBUS";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpios = <&i2c2_gpio_expander_21 16 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	reg_usdhc2_vmmc: regulator-usdhc2 {
+		compatible = "regulator-fixed";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-name = "VDD_SD2_3V3";
+	};
+
+	sound-bt-sco {
+		compatible = "simple-audio-card";
+		simple-audio-card,bitclock-inversion;
+		simple-audio-card,bitclock-master = <&btcpu>;
+		simple-audio-card,format = "dsp_a";
+		simple-audio-card,frame-master = <&btcpu>;
+		simple-audio-card,name = "bt-sco-audio";
+
+		simple-audio-card,codec {
+			sound-dai = <&bt_sco_codec 1>;
+		};
+
+		btcpu: simple-audio-card,cpu {
+			dai-tdm-slot-num = <2>;
+			dai-tdm-slot-width = <16>;
+			sound-dai = <&sai5>;
+		};
+	};
+
+	sound-micfil {
+		compatible = "fsl,imx-audio-card";
+		model = "micfil-audio";
+
+		pri-dai-link {
+			link-name = "micfil hifi";
+			format = "i2s";
+			cpu {
+				sound-dai = <&micfil>;
+			};
+		};
+	};
+
+	sound-tas2552 {
+		compatible = "simple-audio-card";
+		simple-audio-card,bitclock-master = <&cpudai>;
+		simple-audio-card,format = "i2s";
+		simple-audio-card,frame-master = <&cpudai>;
+		simple-audio-card,mclk-fs = <256>;
+		simple-audio-card,name = "tas2552-audio";
+		simple-audio-card,routing = "Speaker", "OUT";
+		simple-audio-card,widgets = "Speaker", "Speaker";
+
+		simple-audio-card,codec {
+			sound-dai = <&tas2552>;
+		};
+
+		cpudai: simple-audio-card,cpu {
+			sound-dai = <&sai3>;
+		};
+	};
+};
+
+&enetc_port0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enetc0>;
+	phy-handle = <&ethphy0>;
+	phy-mode = "rgmii-id";
+	status = "okay";
+};
+
+&enetc_port1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enetc1>;
+	phy-handle = <&ethphy1>;
+	phy-mode = "rgmii-id";
+	status = "okay";
+};
+
+&flexcan3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan3>;
+	phys = <&flexcan3_phy>;
+	status = "okay";
+};
+
+&flexcan5 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan5>;
+	phys = <&flexcan5_phy>;
+	status = "okay";
+};
+
+&gpio1 {
+	gpio-line-names =
+		"", "", "", "",
+		"", "BOOT_MODE0", "", "BOOT_MODE1",
+		"", "", "SYS_WAKEUP", "BOOT_MODE2",
+		"", "BOOT_MODE3", "", "";
+	status = "okay";
+};
+
+&gpio5 {
+	pcal6524-reset-hog {
+		gpio-hog;
+		gpios = <10 0>;
+		output-high;
+		line-name = "IO_XPNDR_RST_1V8";
+	};
+
+	pewake0-hog {
+		gpio-hog;
+		gpios = <14 0>;
+		input;
+		line-name = "PCIE_PEWAKE_M2-B";
+	};
+
+	pewake1-hog {
+		gpio-hog;
+		gpios = <17 0>;
+		input;
+		line-name = "PCIE_PEWAKE_M2-M";
+	};
+};
+
+&i3c2 {	/* Feature connector I2C/I3C */
+	i2c-scl-hz = <400000>;
+	pinctrl-0 = <&pinctrl_i3c2>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&lpi2c2 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpi2c2>;
+	status = "okay";
+
+	i2c2_gpio_expander_20: gpio@20 {	/* U12 */
+		compatible = "nxp,pcal6524";
+		reg = <0x20>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		interrupts-extended = <&gpio5 11 IRQ_TYPE_LEVEL_HIGH>;
+		vcc-supply = <&reg_3p3v>;
+		/*
+		 * reset-gpios cannot be used because the reset
+		 * line is shared by multiple PCAL6524 consumers.
+		 */
+		gpio-line-names =
+			/* Port 0 */
+			"UART8_RS232-485_MODE0", "UART8_RS232-485_MODE1",
+			"UART8_RS232-485_Term_TX", "UART8_RS232-485_Term_RX",
+			"UART8_RS232-485_EN", "VDD_3V3_M2-E_EN",
+			"VDD_3V3_M2-B_EN", "M2_I2C_ALERT",
+			/* Port 1 */
+			"M2-B_FULL_CARD_PWROFF", "M2-B_W_DISABLE1",
+			"M2-B_W_DISABLE2", "M2-B_RESET",
+			"M2-E_W_DISABLE1", "M2-E_W_DISABLE2",
+			"M2-E_SDIO_RESET", "CAN3_STBY",
+			/* Port 2 */
+			"CAN5_STBY", "V_LCD_EN",
+			"V_LCD_SEL_3V3", "V_LCD_SEL_5V0",
+			"V_LCD_SEL_12V0", "V_12V0_CC",
+			"V_12V0_PG", "AUDIO_EN";
+	};
+
+	i2c2_gpio_expander_21: gpio@21 {	/* U14 */
+		compatible = "nxp,pcal6524";
+		reg = <0x21>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		interrupts-extended = <&gpio5 11 IRQ_TYPE_LEVEL_HIGH>;
+		vcc-supply = <&reg_3p3v>;
+		/*
+		 * reset-gpios cannot be used because the reset
+		 * line is shared by multiple PCAL6524 consumers.
+		 */
+		gpio-line-names =
+			/* Port 0 */
+			"V_BKL_PWM_SEL_5V0", "V_BKL_EN_SEL_5V0",
+			"UART7_RS232-485_MODE0", "UART7_RS232-485_MODE1",
+			"UART7_RS232-485_Term_TX", "UART7_RS232-485_Term_RX",
+			"UART7_RS232-485_EN", "VDD_3V3_M2-M_EN",
+			/* Port 1 */
+			"TOUCH_INT", "TOUCH_RESET",
+			"CAMERA_PWREN", "CAMERA_LED",
+			"MIPI_DSI-CSI_BL_EN", "MIPI_DSI-CSI_RESET",
+			"MIPI_DSI-CSI_INT", "LVDS_PANEL_GPIO",
+			/* Port 2 */
+			"USB2_PWR_EN", "USB2_PWR_OC#",
+			"VDD_1V2_USB_PG", "PF09_PG",
+			"USB_HUB_RESET", "PF09_FS0B",
+			"PF53_VDD_ARM_PG", "PF53_VDD_SOC_PG";
+
+		usb-hub-hog {
+			gpio-hog;
+			gpios = <20 0>;
+			output-high;
+			line-name = "USB_HUB_RESET";
+		};
+	};
+
+	i2c2_gpio_expander_22: gpio@22 {	/* U13 */
+		compatible = "nxp,pcal6524";
+		reg = <0x22>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		interrupts-extended = <&gpio5 11 IRQ_TYPE_LEVEL_HIGH>;
+		vcc-supply = <&reg_3p3v>;
+		/*
+		 * reset-gpios cannot be used because the reset
+		 * line is shared by multiple PCAL6524 consumers.
+		 */
+		gpio-line-names =
+			/* Port 0 */
+			"eMMC_RESET", "WDOG_IRQ#",
+			"FAN_ALERT", "VDD_1V2_ETH_PG",
+			"ENET1_RESET", "ENET2_RESET",
+			"TPM_IRQ", "TPM_RESET",
+			/* Port 1 */
+			"FEATURE_CONN_GPIO1", "FEATURE_CONN_GPIO2",
+			"FEATURE_CONN_GPIO3", "FEATURE_CONN_GPIO4",
+			"FEATURE_CONN_GPIO5", "FEATURE_CONN_GPIO6",
+			"", "",
+			/* Port 2 */
+			"", "", "", "", "", "",
+			"UART5_SEL", "EEPROM_WRITE_ENABLE";
+	};
+
+	fan_controller: fan-controller@2f {
+		compatible = "microchip,emc2301", "microchip,emc2305";
+		reg = <0x2f>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		#pwm-cells = <3>;
+
+		fan@0 {
+			reg = <0x0>;
+			pwms = <&fan_controller 26000 0 1>;
+			#cooling-cells = <2>;
+		};
+	};
+
+	tas2552: audio-codec@40 {
+		compatible = "ti,tas2552";
+		reg = <0x40>;
+		#sound-dai-cells = <0>;
+		avdd-supply = <&reg_1p8v>;
+		iovdd-supply = <&reg_3p3v>;
+		vbat-supply = <&reg_5p0v>;
+		enable-gpio = <&i2c2_gpio_expander_20 23 GPIO_ACTIVE_HIGH>;
+	};
+
+	temperature-sensor@43 {
+		compatible = "ti,tmp110", "ti,tmp102";
+		reg = <0x43>;
+	};
+};
+
+&lpi2c5 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpi2c5>;
+	status = "okay";
+};
+
+&lpuart1 {	/* A55 Debug */
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+	status = "okay";
+};
+
+&lpuart2 {	/* M33 Debug */
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2>;
+	status = "reserved";
+};
+
+&lpuart5 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart5>;
+	uart-has-rtscts;
+	status = "okay";
+};
+
+&lpuart7 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart7>;
+	uart-has-rtscts;
+	status = "okay";
+};
+
+&lpuart8 {	/* M7 Debug */
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart8>;
+	uart-has-rtscts;
+	status = "okay";
+};
+
+&lpspi1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpspi1>;
+	cs-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	flash@0 {	/* W25Q128FVSI */
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <10000000>;
+	};
+};
+
+&lpspi6 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpspi6>;
+	cs-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
+
+&micfil {
+	#sound-dai-cells = <0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pdm>;
+	assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
+			  <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
+			  <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+			  <&scmi_clk IMX95_CLK_AUDIOPLL2>,
+			  <&scmi_clk IMX95_CLK_PDM>;
+	assigned-clock-parents = <0>, <0>, <0>, <0>,
+				 <&scmi_clk IMX95_CLK_AUDIOPLL1>;
+	assigned-clock-rates = <3932160000>,
+			       <3612672000>, <393216000>,
+			       <361267200>, <49152000>;
+	status = "okay";
+};
+
+&mu7 {
+	status = "okay";
+};
+
+&netc_blk_ctrl {
+	status = "okay";
+};
+
+&netc_emdio {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_emdio>;
+	status = "okay";
+
+	ethphy0: ethernet-phy@1 {	/* KSZ9131RNXI U20 */
+		compatible = "ethernet-phy-id0022.1640";
+		reg = <1>;
+		interrupts-extended = <&gpio1 10 IRQ_TYPE_LEVEL_LOW>;
+		reset-assert-us = <1000>;
+		/* RESET_N signal rise time ~100ms */
+		reset-deassert-us = <120000>;
+		reset-gpios = <&i2c2_gpio_expander_22 4 GPIO_ACTIVE_HIGH>;
+	};
+
+	ethphy1: ethernet-phy@2 {	/* KSZ9131RNXI U22 */
+		compatible = "ethernet-phy-id0022.1640";
+		reg = <2>;
+		interrupts-extended = <&gpio1 10 IRQ_TYPE_LEVEL_LOW>;
+		reset-assert-us = <1000>;
+		/* RESET_N signal rise time ~100ms */
+		reset-deassert-us = <120000>;
+		reset-gpios = <&i2c2_gpio_expander_22 5 GPIO_ACTIVE_HIGH>;
+	};
+};
+
+&netc_timer {
+	status = "okay";
+};
+
+&netcmix_blk_ctrl {
+	status = "okay";
+};
+
+&pcie0 {	/* M.2 Key-B */
+	pinctrl-0 = <&pinctrl_pcie0>;
+	pinctrl-names = "default";
+	reset-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
+	vpcie-supply = <&reg_pcie0>;
+	status = "okay";
+};
+
+&pcie1 {	/* M.2 Key-M */
+	pinctrl-0 = <&pinctrl_pcie1>;
+	pinctrl-names = "default";
+	reset-gpios = <&gpio5 16 GPIO_ACTIVE_LOW>;
+	vpcie-supply = <&reg_pcie1>;
+	status = "okay";
+};
+
+&sai3 {
+	#sound-dai-cells = <0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_sai3>;
+	assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
+			  <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
+			  <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+			  <&scmi_clk IMX95_CLK_AUDIOPLL2>,
+			  <&scmi_clk IMX95_CLK_SAI3>;
+	assigned-clock-parents = <0>, <0>, <0>, <0>,
+				 <&scmi_clk IMX95_CLK_AUDIOPLL1>;
+	assigned-clock-rates = <3932160000>,
+			       <3612672000>, <393216000>,
+			       <361267200>, <12288000>;
+	fsl,sai-mclk-direction-output;
+	status = "okay";
+};
+
+&sai4 {
+	assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
+			  <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
+			  <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+			  <&scmi_clk IMX95_CLK_AUDIOPLL2>,
+			  <&scmi_clk IMX95_CLK_SAI4>;
+	assigned-clock-parents = <0>, <0>, <0>, <0>, <&scmi_clk IMX95_CLK_AUDIOPLL1>;
+	assigned-clock-rates = <3932160000>, <3612672000>, <393216000>, <361267200>, <12288000>;
+	#sound-dai-cells = <0>;
+	pinctrl-0 = <&pinctrl_sai4>;
+	pinctrl-names = "default";
+	fsl,sai-mclk-direction-output;
+	status = "okay";
+};
+
+&sai5 {
+	assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
+			  <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
+			  <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+			  <&scmi_clk IMX95_CLK_AUDIOPLL2>,
+			  <&scmi_clk IMX95_CLK_SAI5>;
+	assigned-clock-parents = <0>, <0>, <0>, <0>, <&scmi_clk IMX95_CLK_AUDIOPLL1>;
+	assigned-clock-rates = <3932160000>, <3612672000>, <393216000>, <361267200>, <12288000>;
+	#sound-dai-cells = <0>;
+	pinctrl-0 = <&pinctrl_sai5>;
+	pinctrl-names = "default";
+	fsl,sai-mclk-direction-output;
+	status = "okay";
+};
+
+&thermal_zones {
+	pf09-thermal {
+		polling-delay = <2000>;
+		polling-delay-passive = <250>;
+		thermal-sensors = <&scmi_sensor 2>;
+
+		trips {
+			trip0 {
+				hysteresis = <2000>;
+				temperature = <140000>;
+				type = "passive";
+			};
+
+			trip1 {
+				hysteresis = <2000>;
+				temperature = <155000>;
+				type = "critical";
+			};
+		};
+	};
+
+	pf53arm-thermal {
+		polling-delay = <2000>;
+		polling-delay-passive = <250>;
+		thermal-sensors = <&scmi_sensor 4>;
+
+		cooling-maps {
+			map0 {
+				trip = <&pf5301_alert>;
+				cooling-device =
+					<&A55_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+					<&A55_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+					<&A55_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+					<&A55_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+					<&A55_4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+					<&A55_5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+			};
+		};
+
+		trips {
+			pf5301_alert: trip0 {
+				hysteresis = <2000>;
+				temperature = <140000>;
+				type = "passive";
+			};
+
+			pf5301_crit: trip1 {
+				hysteresis = <2000>;
+				temperature = <155000>;
+				type = "critical";
+			};
+		};
+	};
+
+	pf53soc-thermal {
+		polling-delay = <2000>;
+		polling-delay-passive = <250>;
+		thermal-sensors = <&scmi_sensor 3>;
+
+		trips {
+			pf5302_alert: trip0 {
+				hysteresis = <2000>;
+				temperature = <140000>;
+				type = "passive";
+			};
+
+			pf5302_crit: trip1 {
+				hysteresis = <2000>;
+				temperature = <155000>;
+				type = "critical";
+			};
+		};
+	};
+};
+
+&tpm3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_tpm3>;
+	status = "okay";
+};
+
+&tpm4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_tpm4>;
+	status = "okay";
+};
+
+&usb2 {
+	dr_mode = "host";
+	vbus-supply = <&reg_usb2_vbus>;
+	status = "okay";
+};
+
+&usb3 {
+	status = "okay";
+};
+
+&usb3_dwc3 {
+	dr_mode = "host";
+	status = "okay";
+};
+
+&usb3_phy {
+	status = "okay";
+};
+
+&usdhc1 {	/* eMMC */
+	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+	pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+	pinctrl-3 = <&pinctrl_usdhc1>;
+	bus-width = <8>;
+	non-removable;
+	no-sdio;
+	no-sd;
+	status = "okay";
+};
+
+&usdhc2 {	/* SD-Card */
+	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+	pinctrl-0 = <&pinctrl_usdhc2>;
+	pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
+	pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
+	pinctrl-3 = <&pinctrl_usdhc2>;
+	cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
+	vmmc-supply = <&reg_usdhc2_vmmc>;
+	bus-width = <4>;
+	status = "okay";
+};
+
+&usdhc3 {	/* M.2 Key-E */
+	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+	pinctrl-0 = <&pinctrl_usdhc3>;
+	pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+	pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+	pinctrl-3 = <&pinctrl_usdhc3>;
+	bus-width = <4>;
+	status = "okay";
+};
+
+&wdog3 {
+	fsl,ext-reset-output;
+	status = "okay";
+};
+
+&scmi_iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	pinctrl_hog: hoggrp {
+		fsl,pins = <
+			/* PCIe 0 PEWAKE */
+			IMX95_PAD_GPIO_IO34__GPIO5_IO_BIT14			0x4000031e
+			/* PCIe 1 PEWAKE */
+			IMX95_PAD_GPIO_IO37__GPIO5_IO_BIT17			0x4000031e
+			/* BOOT_MODE2 */
+			IMX95_PAD_SAI1_TXFS__AONMIX_TOP_GPIO1_IO_BIT11		0x4000031e
+			/* IO_XPNDR_RST_1V8 shared by multiple expanders */
+			IMX95_PAD_XSPI1_SS0_B__GPIO5_IO_BIT10			0x40000b9e
+			/* IO_XPNDR_INT_1V8 shared by multiple expanders */
+			IMX95_PAD_XSPI1_SS1_B__GPIO5_IO_BIT11			0x40000b9e
+		>;
+	};
+
+	pinctrl_emdio: emdiogrp {
+		fsl,pins = <
+			IMX95_PAD_ENET2_MDC__NETCMIX_TOP_NETC_MDC		0x50e
+			IMX95_PAD_ENET2_MDIO__NETCMIX_TOP_NETC_MDIO		0x90e
+		>;
+	};
+
+	pinctrl_enetc0: enetc0grp {
+		fsl,pins = <
+			IMX95_PAD_ENET1_RD0__NETCMIX_TOP_ETH0_RGMII_RD0		0x57e
+			IMX95_PAD_ENET1_RD1__NETCMIX_TOP_ETH0_RGMII_RD1		0x57e
+			IMX95_PAD_ENET1_RD2__NETCMIX_TOP_ETH0_RGMII_RD2		0x57e
+			IMX95_PAD_ENET1_RD3__NETCMIX_TOP_ETH0_RGMII_RD3		0x57e
+			IMX95_PAD_ENET1_RXC__NETCMIX_TOP_ETH0_RGMII_RX_CLK	0x58e
+			IMX95_PAD_ENET1_RX_CTL__NETCMIX_TOP_ETH0_RGMII_RX_CTL	0x57e
+			IMX95_PAD_ENET1_TD0__NETCMIX_TOP_ETH0_RGMII_TD0		0x50e
+			IMX95_PAD_ENET1_TD1__NETCMIX_TOP_ETH0_RGMII_TD1		0x50e
+			IMX95_PAD_ENET1_TD2__NETCMIX_TOP_ETH0_RGMII_TD2		0x50e
+			IMX95_PAD_ENET1_TD3__NETCMIX_TOP_ETH0_RGMII_TD3		0x50e
+			IMX95_PAD_ENET1_TXC__NETCMIX_TOP_ETH0_RGMII_TX_CLK	0x58e
+			IMX95_PAD_ENET1_TX_CTL__NETCMIX_TOP_ETH0_RGMII_TX_CTL	0x57e
+		>;
+	};
+
+	pinctrl_enetc1: enetc1grp {
+		fsl,pins = <
+			IMX95_PAD_ENET2_RD0__NETCMIX_TOP_ETH1_RGMII_RD0		0x57e
+			IMX95_PAD_ENET2_RD1__NETCMIX_TOP_ETH1_RGMII_RD1		0x57e
+			IMX95_PAD_ENET2_RD2__NETCMIX_TOP_ETH1_RGMII_RD2		0x57e
+			IMX95_PAD_ENET2_RD3__NETCMIX_TOP_ETH1_RGMII_RD3		0x57e
+			IMX95_PAD_ENET2_RXC__NETCMIX_TOP_ETH1_RGMII_RX_CLK	0x58e
+			IMX95_PAD_ENET2_RX_CTL__NETCMIX_TOP_ETH1_RGMII_RX_CTL	0x57e
+			IMX95_PAD_ENET2_TD0__NETCMIX_TOP_ETH1_RGMII_TD0		0x50e
+			IMX95_PAD_ENET2_TD1__NETCMIX_TOP_ETH1_RGMII_TD1		0x50e
+			IMX95_PAD_ENET2_TD2__NETCMIX_TOP_ETH1_RGMII_TD2		0x50e
+			IMX95_PAD_ENET2_TD3__NETCMIX_TOP_ETH1_RGMII_TD3		0x50e
+			IMX95_PAD_ENET2_TXC__NETCMIX_TOP_ETH1_RGMII_TX_CLK	0x58e
+			IMX95_PAD_ENET2_TX_CTL__NETCMIX_TOP_ETH1_RGMII_TX_CTL	0x57e
+		>;
+	};
+
+	pinctrl_flexcan3: flexcan3grp {
+		fsl,pins = <
+			IMX95_PAD_GPIO_IO28__CAN3_TX				0x39e
+			IMX95_PAD_GPIO_IO29__CAN3_RX				0x39e
+		>;
+	};
+
+	pinctrl_flexcan5: flexcan5grp {
+		fsl,pins = <
+			IMX95_PAD_GPIO_IO30__CAN5_TX				0x39e
+			IMX95_PAD_GPIO_IO31__CAN5_RX				0x39e
+		>;
+	};
+
+	pinctrl_i3c2: i3c2grp {
+		fsl,pins = <
+			IMX95_PAD_ENET1_MDC__I3C2_SCL				0x40000186
+			IMX95_PAD_ENET1_MDIO__I3C2_SDA				0x40000186
+		>;
+	};
+
+	pinctrl_led: ledgrp {
+		fsl,pins = <
+			IMX95_PAD_XSPI1_DQS__GPIO5_IO_BIT8			0x14e
+			IMX95_PAD_XSPI1_SCLK__GPIO5_IO_BIT9			0x14e
+		>;
+	};
+
+	pinctrl_lpi2c2: lpi2c2grp {
+		fsl,pins = <
+			IMX95_PAD_I2C2_SCL__AONMIX_TOP_LPI2C2_SCL		0x40000b9e
+			IMX95_PAD_I2C2_SDA__AONMIX_TOP_LPI2C2_SDA		0x40000b9e
+		>;
+	};
+
+	pinctrl_lpi2c5: lpi2c5grp {
+		fsl,pins = <
+			IMX95_PAD_GPIO_IO22__LPI2C5_SDA				0x40000b9e
+			IMX95_PAD_GPIO_IO23__LPI2C5_SCL				0x40000b9e
+		>;
+	};
+
+	pinctrl_lpspi1: lpspi1grp {
+		fsl,pins = <
+			IMX95_PAD_SAI1_TXC__AONMIX_TOP_LPSPI1_SIN		0x3fe
+			IMX95_PAD_SAI1_TXD0__AONMIX_TOP_LPSPI1_SCK		0x3fe
+			IMX95_PAD_SAI1_RXD0__AONMIX_TOP_LPSPI1_SOUT		0x3fe
+			IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9	0x3fe
+		>;
+	};
+
+	pinctrl_lpspi6: lpspi6grp {
+		fsl,pins = <
+			IMX95_PAD_GPIO_IO00__GPIO2_IO_BIT0			0x3fe
+			IMX95_PAD_GPIO_IO01__LPSPI6_SIN				0x3fe
+			IMX95_PAD_GPIO_IO02__LPSPI6_SOUT			0x3fe
+			IMX95_PAD_GPIO_IO03__LPSPI6_SCK				0x3fe
+		>;
+	};
+
+	pinctrl_pcie0: pcie0grp {
+		fsl,pins = <
+			IMX95_PAD_GPIO_IO32__HSIOMIX_TOP_PCIE1_CLKREQ_B		0x4000031e
+			IMX95_PAD_GPIO_IO33__GPIO5_IO_BIT13			0x31e
+		>;
+	};
+
+	pinctrl_pcie1: pcie1grp {
+		fsl,pins = <
+			IMX95_PAD_GPIO_IO35__HSIOMIX_TOP_PCIE2_CLKREQ_B		0x4000031e
+			IMX95_PAD_GPIO_IO36__GPIO5_IO_BIT16			0x31e
+		>;
+	};
+
+	pinctrl_panel_backlight_lvds: backlightlvdsgrp {
+		fsl,pins = <
+			IMX95_PAD_GPIO_IO27__GPIO2_IO_BIT27			0x31e
+		>;
+	};
+
+	pinctrl_pdm: pdmgrp {
+		fsl,pins = <
+			IMX95_PAD_GPIO_IO04__AONMIX_TOP_PDM_CLK			0x31e
+			IMX95_PAD_GPIO_IO05__AONMIX_TOP_PDM_BIT_STREAM_BIT0	0x31e
+			IMX95_PAD_GPIO_IO06__AONMIX_TOP_PDM_BIT_STREAM_BIT1	0x31e
+		>;
+	};
+
+	pinctrl_sai4: sai4grp {
+		fsl,pins = <
+			IMX95_PAD_XSPI1_DATA0__SAI4_TX_BCLK			0x31e
+			IMX95_PAD_XSPI1_DATA1__SAI4_TX_SYNC			0x31e
+			IMX95_PAD_XSPI1_DATA2__SAI4_TX_DATA_BIT0		0x31e
+			IMX95_PAD_XSPI1_DATA3__SAI4_RX_DATA_BIT0		0x31e
+		>;
+	};
+
+	pinctrl_sai5: sai5grp {
+		fsl,pins = <
+			IMX95_PAD_XSPI1_DATA4__SAI5_TX_DATA_BIT0		0x31e
+			IMX95_PAD_XSPI1_DATA5__SAI5_TX_SYNC			0x31e
+			IMX95_PAD_XSPI1_DATA6__SAI5_TX_BCLK			0x31e
+			IMX95_PAD_XSPI1_DATA7__SAI5_RX_DATA_BIT0		0x31e
+		>;
+	};
+
+	pinctrl_sai3: sai3grp {
+		fsl,pins = <
+			IMX95_PAD_GPIO_IO16__SAI3_TX_BCLK			0x31e
+			IMX95_PAD_GPIO_IO17__SAI3_MCLK				0x31e
+			IMX95_PAD_GPIO_IO18__SAI3_RX_BCLK			0x31e
+			IMX95_PAD_GPIO_IO19__SAI3_RX_SYNC			0x31e
+			IMX95_PAD_GPIO_IO20__SAI3_RX_DATA_BIT0			0x31e
+			IMX95_PAD_GPIO_IO21__SAI3_TX_DATA_BIT0			0x31e
+			IMX95_PAD_GPIO_IO26__SAI3_TX_SYNC			0x31e
+		>;
+	};
+
+	pinctrl_tpm3: tpm3grp {
+		fsl,pins = <
+			IMX95_PAD_GPIO_IO24__TPM3_CH3				0x51e
+		>;
+	};
+
+	pinctrl_tpm4: tpm4grp {
+		fsl,pins = <
+			IMX95_PAD_GPIO_IO25__TPM4_CH3				0x51e
+		>;
+	};
+
+	pinctrl_uart1: uart1grp {
+		fsl,pins = <
+			IMX95_PAD_UART1_RXD__AONMIX_TOP_LPUART1_RX		0x31e
+			IMX95_PAD_UART1_TXD__AONMIX_TOP_LPUART1_TX		0x31e
+		>;
+	};
+
+	pinctrl_uart2: uart2grp {
+		fsl,pins = <
+			IMX95_PAD_UART2_RXD__AONMIX_TOP_LPUART2_RX		0x31e
+			IMX95_PAD_UART2_TXD__AONMIX_TOP_LPUART2_TX		0x31e
+		>;
+	};
+
+	pinctrl_uart5: uart5grp {
+		fsl,pins = <
+			IMX95_PAD_DAP_TDO_TRACESWO__LPUART5_TX			0x31e
+			IMX95_PAD_DAP_TDI__LPUART5_RX				0x31e
+			IMX95_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B			0x31e
+			IMX95_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B			0x31e
+		>;
+	};
+
+	pinctrl_uart7: uart7grp {
+		fsl,pins = <
+			IMX95_PAD_GPIO_IO08__LPUART7_TX				0x31e
+			IMX95_PAD_GPIO_IO09__LPUART7_RX				0x31e
+			IMX95_PAD_GPIO_IO10__LPUART7_CTS_B			0x31e
+			IMX95_PAD_GPIO_IO11__LPUART7_RTS_B			0x31e
+		>;
+	};
+
+	pinctrl_uart8: uart8grp {
+		fsl,pins = <
+			IMX95_PAD_GPIO_IO12__LPUART8_TX				0x31e
+			IMX95_PAD_GPIO_IO13__LPUART8_RX				0x31e
+			IMX95_PAD_GPIO_IO14__LPUART8_CTS_B			0x31e
+			IMX95_PAD_GPIO_IO15__LPUART8_RTS_B			0x31e
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			IMX95_PAD_SD1_CLK__USDHC1_CLK				0x158e
+			IMX95_PAD_SD1_CMD__USDHC1_CMD				0x138e
+			IMX95_PAD_SD1_DATA0__USDHC1_DATA0			0x138e
+			IMX95_PAD_SD1_DATA1__USDHC1_DATA1			0x138e
+			IMX95_PAD_SD1_DATA2__USDHC1_DATA2			0x138e
+			IMX95_PAD_SD1_DATA3__USDHC1_DATA3			0x138e
+			IMX95_PAD_SD1_DATA4__USDHC1_DATA4			0x138e
+			IMX95_PAD_SD1_DATA5__USDHC1_DATA5			0x138e
+			IMX95_PAD_SD1_DATA6__USDHC1_DATA6			0x138e
+			IMX95_PAD_SD1_DATA7__USDHC1_DATA7			0x138e
+			IMX95_PAD_SD1_STROBE__USDHC1_STROBE			0x158e
+		>;
+	};
+
+	pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+		fsl,pins = <
+			IMX95_PAD_SD1_CLK__USDHC1_CLK				0x158e
+			IMX95_PAD_SD1_CMD__USDHC1_CMD				0x138e
+			IMX95_PAD_SD1_DATA0__USDHC1_DATA0			0x138e
+			IMX95_PAD_SD1_DATA1__USDHC1_DATA1			0x138e
+			IMX95_PAD_SD1_DATA2__USDHC1_DATA2			0x138e
+			IMX95_PAD_SD1_DATA3__USDHC1_DATA3			0x138e
+			IMX95_PAD_SD1_DATA4__USDHC1_DATA4			0x138e
+			IMX95_PAD_SD1_DATA5__USDHC1_DATA5			0x138e
+			IMX95_PAD_SD1_DATA6__USDHC1_DATA6			0x138e
+			IMX95_PAD_SD1_DATA7__USDHC1_DATA7			0x138e
+			IMX95_PAD_SD1_STROBE__USDHC1_STROBE			0x158e
+		>;
+	};
+
+	pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+		fsl,pins = <
+			IMX95_PAD_SD1_CLK__USDHC1_CLK				0x15fe
+			IMX95_PAD_SD1_CMD__USDHC1_CMD				0x13fe
+			IMX95_PAD_SD1_DATA0__USDHC1_DATA0			0x13fe
+			IMX95_PAD_SD1_DATA1__USDHC1_DATA1			0x13fe
+			IMX95_PAD_SD1_DATA2__USDHC1_DATA2			0x13fe
+			IMX95_PAD_SD1_DATA3__USDHC1_DATA3			0x13fe
+			IMX95_PAD_SD1_DATA4__USDHC1_DATA4			0x13fe
+			IMX95_PAD_SD1_DATA5__USDHC1_DATA5			0x13fe
+			IMX95_PAD_SD1_DATA6__USDHC1_DATA6			0x13fe
+			IMX95_PAD_SD1_DATA7__USDHC1_DATA7			0x13fe
+			IMX95_PAD_SD1_STROBE__USDHC1_STROBE			0x15fe
+		>;
+	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			IMX95_PAD_SD2_CLK__USDHC2_CLK				0x158e
+			IMX95_PAD_SD2_CMD__USDHC2_CMD				0x138e
+			IMX95_PAD_SD2_DATA0__USDHC2_DATA0			0x138e
+			IMX95_PAD_SD2_DATA1__USDHC2_DATA1			0x138e
+			IMX95_PAD_SD2_DATA2__USDHC2_DATA2			0x138e
+			IMX95_PAD_SD2_DATA3__USDHC2_DATA3			0x138e
+			IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT			0x51e
+			IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0			0x31e
+		>;
+	};
+
+	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+		fsl,pins = <
+			IMX95_PAD_SD2_CLK__USDHC2_CLK				0x158e
+			IMX95_PAD_SD2_CMD__USDHC2_CMD				0x138e
+			IMX95_PAD_SD2_DATA0__USDHC2_DATA0			0x138e
+			IMX95_PAD_SD2_DATA1__USDHC2_DATA1			0x138e
+			IMX95_PAD_SD2_DATA2__USDHC2_DATA2			0x138e
+			IMX95_PAD_SD2_DATA3__USDHC2_DATA3			0x138e
+			IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT			0x51e
+			IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0			0x31e
+		>;
+	};
+
+	pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+		fsl,pins = <
+			IMX95_PAD_SD2_CLK__USDHC2_CLK				0x158e
+			IMX95_PAD_SD2_CMD__USDHC2_CMD				0x138e
+			IMX95_PAD_SD2_DATA0__USDHC2_DATA0			0x138e
+			IMX95_PAD_SD2_DATA1__USDHC2_DATA1			0x138e
+			IMX95_PAD_SD2_DATA2__USDHC2_DATA2			0x138e
+			IMX95_PAD_SD2_DATA3__USDHC2_DATA3			0x138e
+			IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT			0x51e
+			IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0			0x31e
+		>;
+	};
+
+	pinctrl_usdhc3: usdhc3grp {
+		fsl,pins = <
+			IMX95_PAD_SD3_CLK__USDHC3_CLK				0x158e
+			IMX95_PAD_SD3_CMD__USDHC3_CMD				0x138e
+			IMX95_PAD_SD3_DATA0__USDHC3_DATA0			0x138e
+			IMX95_PAD_SD3_DATA1__USDHC3_DATA1			0x138e
+			IMX95_PAD_SD3_DATA2__USDHC3_DATA2			0x138e
+			IMX95_PAD_SD3_DATA3__USDHC3_DATA3			0x138e
+		>;
+	};
+
+	pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+		fsl,pins = <
+			IMX95_PAD_SD3_CLK__USDHC3_CLK				0x158e
+			IMX95_PAD_SD3_CMD__USDHC3_CMD				0x138e
+			IMX95_PAD_SD3_DATA0__USDHC3_DATA0			0x138e
+			IMX95_PAD_SD3_DATA1__USDHC3_DATA1			0x138e
+			IMX95_PAD_SD3_DATA2__USDHC3_DATA2			0x138e
+			IMX95_PAD_SD3_DATA3__USDHC3_DATA3			0x138e
+		>;
+	};
+
+	pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+		fsl,pins = <
+			IMX95_PAD_SD3_CLK__USDHC3_CLK				0x158e
+			IMX95_PAD_SD3_CMD__USDHC3_CMD				0x138e
+			IMX95_PAD_SD3_DATA0__USDHC3_DATA0			0x138e
+			IMX95_PAD_SD3_DATA1__USDHC3_DATA1			0x138e
+			IMX95_PAD_SD3_DATA2__USDHC3_DATA2			0x138e
+			IMX95_PAD_SD3_DATA3__USDHC3_DATA3			0x138e
+		>;
+	};
+};
-- 
2.53.0

Re: [PATCH v4 3/3] arm64: dts: imx95: Add support for Data Modul i.MX95 eDM SBC

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] dts: pcal6524 interrupt polarity is incorrectly set to LEVEL_HIGH
- [Medium] dts: Ethernet PHY reset-gpios configured with wrong polarity
- [Medium] dts: eMMC reset GPIO defined but unused in usdhc1
- [Medium] dts: reg_panel_vcc regulator missing enable-active-high property
- [Medium] dts: M.2 Key-E (usdhc3) slot missing power regulator
- [Low] dts: tas2552 codec uses deprecated enable-gpio instead of enable-gpios
--

commit 5792bafb068af6288c67560ae9fb90a4c34326af
Author: Marek Vasut <marex@nabladev.com>
arm64: dts: imx95: Add support for Data Modul i.MX95 eDM SBC

This commit adds support for the Data Modul i.MX95 eDM SBC evaluation board,
enabling various peripherals like serial console, ethernet, eMMC, SD,
SPI NOR, USB, and PCIe.

> diff --git a/arch/arm64/boot/dts/freescale/imx95-data-modul-edm-sbc.dts b/arch/arm64/boot/dts/freescale/imx95-data-modul-edm-sbc.dts
> new file mode 100644
> index 0000000000000..0181262eb8a98
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx95-data-modul-edm-sbc.dts

[ ... ]

> +	reg_panel_vcc: regulator-panel-vcc {
> +		compatible = "regulator-fixed";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		regulator-name = "PANEL_VCC";
> +		gpios = <&i2c2_gpio_expander_20 17 0>;
> +		/* Disabled by default, unless display board plugged in. */
> +		status = "disabled";
> +	};

[Severity: Medium]
Does reg_panel_vcc need an enable-active-high property? Without it, the
regulator defaults to active-low logic, which will drive the panel VCC low
when the regulator is enabled.

[ ... ]

> +	i2c2_gpio_expander_20: gpio@20 {	/* U12 */
> +		compatible = "nxp,pcal6524";
> +		reg = <0x20>;
> +		#gpio-cells = <2>;
> +		gpio-controller;
> +		#interrupt-cells = <2>;
> +		interrupt-controller;
> +		interrupts-extended = <&gpio5 11 IRQ_TYPE_LEVEL_HIGH>;

[Severity: High]
Will triggering interrupts-extended on IRQ_TYPE_LEVEL_HIGH cause an interrupt
storm? The PCAL6524 INT output is an open-drain, active-low signal, so the
line will idle high.

[ ... ]

> +	i2c2_gpio_expander_21: gpio@21 {	/* U14 */
> +		compatible = "nxp,pcal6524";
> +		reg = <0x21>;
> +		#gpio-cells = <2>;
> +		gpio-controller;
> +		#interrupt-cells = <2>;
> +		interrupt-controller;
> +		interrupts-extended = <&gpio5 11 IRQ_TYPE_LEVEL_HIGH>;

[Severity: High]
Could this IRQ_TYPE_LEVEL_HIGH configuration also lead to an interrupt
storm for i2c2_gpio_expander_21?

[ ... ]

> +	i2c2_gpio_expander_22: gpio@22 {	/* U13 */
> +		compatible = "nxp,pcal6524";
> +		reg = <0x22>;
> +		#gpio-cells = <2>;
> +		gpio-controller;
> +		#interrupt-cells = <2>;
> +		interrupt-controller;
> +		interrupts-extended = <&gpio5 11 IRQ_TYPE_LEVEL_HIGH>;

[Severity: High]
Does i2c2_gpio_expander_22 similarly need to be configured for an active-low
interrupt instead of IRQ_TYPE_LEVEL_HIGH?

[ ... ]

> +	tas2552: audio-codec@40 {
> +		compatible = "ti,tas2552";
> +		reg = <0x40>;
> +		#sound-dai-cells = <0>;
> +		avdd-supply = <&reg_1p8v>;
> +		iovdd-supply = <&reg_3p3v>;
> +		vbat-supply = <&reg_5p0v>;
> +		enable-gpio = <&i2c2_gpio_expander_20 23 GPIO_ACTIVE_HIGH>;

[Severity: Low]
This isn't a bug, but should tas2552 be using the enable-gpios property name
instead of the deprecated enable-gpio? The patch changelog mentions replacing
gpio with gpios DT properties.

[ ... ]

> +	ethphy0: ethernet-phy@1 {	/* KSZ9131RNXI U20 */
> +		compatible = "ethernet-phy-id0022.1640";
> +		reg = <1>;
> +		interrupts-extended = <&gpio1 10 IRQ_TYPE_LEVEL_LOW>;
> +		reset-assert-us = <1000>;
> +		/* RESET_N signal rise time ~100ms */
> +		reset-deassert-us = <120000>;
> +		reset-gpios = <&i2c2_gpio_expander_22 4 GPIO_ACTIVE_HIGH>;

[Severity: Medium]
Will ethphy0 be held in reset permanently? The KSZ9131RNXI RESET_N signal is
active-low, so defining reset-gpios with GPIO_ACTIVE_HIGH will drive the line
high to assert reset.

> +	};
> +
> +	ethphy1: ethernet-phy@2 {	/* KSZ9131RNXI U22 */
> +		compatible = "ethernet-phy-id0022.1640";
> +		reg = <2>;
> +		interrupts-extended = <&gpio1 10 IRQ_TYPE_LEVEL_LOW>;
> +		reset-assert-us = <1000>;
> +		/* RESET_N signal rise time ~100ms */
> +		reset-deassert-us = <120000>;
> +		reset-gpios = <&i2c2_gpio_expander_22 5 GPIO_ACTIVE_HIGH>;

[Severity: Medium]
Does ethphy1 also suffer from the incorrect GPIO_ACTIVE_HIGH reset polarity?

[ ... ]

> +&usdhc1 {	/* eMMC */
> +	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> +	pinctrl-0 = <&pinctrl_usdhc1>;

[Severity: Medium]
Could usdhc1 be missing its reset sequence configuration? The hardware
provides an eMMC_RESET line on the I2C GPIO expander, but it isn't consumed
via mmc-pwrseq or reset-gpios. This might cause the eMMC to fail to initialize
during warm reboots.

[ ... ]

> +&usdhc3 {	/* M.2 Key-E */
> +	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> +	pinctrl-0 = <&pinctrl_usdhc3>;

[Severity: Medium]
Does the usdhc3 node need a vmmc-supply? The VDD_3V3_M2-E_EN pin is defined on
the expander but there is no fixed regulator defined to power the M.2 Key-E
slot, which might leave peripherals undetectable.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917062543.534416-1-marex@nabladev.com?part=3

Re: [PATCH v4 3/3] arm64: dts: imx95: Add support for Data Modul i.MX95 eDM SBC

[Frank Li]

On Thu, Sep 17, 2026 at 06:35:12AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
> - [High] dts: pcal6524 interrupt polarity is incorrectly set to LEVEL_HIGH
> - [Medium] dts: Ethernet PHY reset-gpios configured with wrong polarity
> - [Medium] dts: eMMC reset GPIO defined but unused in usdhc1
> - [Medium] dts: reg_panel_vcc regulator missing enable-active-high property
> - [Medium] dts: M.2 Key-E (usdhc3) slot missing power regulator
> - [Low] dts: tas2552 codec uses deprecated enable-gpio instead of enable-gpios
> --
>
> commit 5792bafb068af6288c67560ae9fb90a4c34326af
> Author: Marek Vasut <marex@nabladev.com>
> arm64: dts: imx95: Add support for Data Modul i.MX95 eDM SBC
>
> This commit adds support for the Data Modul i.MX95 eDM SBC evaluation board,
> enabling various peripherals like serial console, ethernet, eMMC, SD,
> SPI NOR, USB, and PCIe.
>
> > diff --git a/arch/arm64/boot/dts/freescale/imx95-data-modul-edm-sbc.dts b/arch/arm64/boot/dts/freescale/imx95-data-modul-edm-sbc.dts
> > new file mode 100644
> > index 0000000000000..0181262eb8a98
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx95-data-modul-edm-sbc.dts
>
> [ ... ]
>
> > +	reg_panel_vcc: regulator-panel-vcc {
> > +		compatible = "regulator-fixed";
> > +		regulator-min-microvolt = <3300000>;
> > +		regulator-max-microvolt = <3300000>;
> > +		regulator-name = "PANEL_VCC";
> > +		gpios = <&i2c2_gpio_expander_20 17 0>;

gpio third arg 0, means GPIO_ACTIVE_HIGH

	so need enable-active-high

if your boards have invertor should use GPIO_ACTIVE_LOW


> > +		/* Disabled by default, unless display board plugged in. */
> > +		status = "disabled";
> > +	};
>
> [Severity: Medium]
> Does reg_panel_vcc need an enable-active-high property? Without it, the
> regulator defaults to active-low logic, which will drive the panel VCC low
> when the regulator is enabled.
>
> [ ... ]
>
> > +	i2c2_gpio_expander_20: gpio@20 {	/* U12 */
> > +		compatible = "nxp,pcal6524";
> > +		reg = <0x20>;
> > +		#gpio-cells = <2>;
> > +		gpio-controller;
> > +		#interrupt-cells = <2>;
> > +		interrupt-controller;
> > +		interrupts-extended = <&gpio5 11 IRQ_TYPE_LEVEL_HIGH>;
>
> [Severity: High]
> Will triggering interrupts-extended on IRQ_TYPE_LEVEL_HIGH cause an interrupt
> storm? The PCAL6524 INT output is an open-drain, active-low signal, so the
> line will idle high.

Yes, suppose it should LOW to trigger irq.


>
> [ ... ]
>
> > +	i2c2_gpio_expander_21: gpio@21 {	/* U14 */
> > +		compatible = "nxp,pcal6524";
> > +		reg = <0x21>;
> > +		#gpio-cells = <2>;
> > +		gpio-controller;
> > +		#interrupt-cells = <2>;
> > +		interrupt-controller;
> > +		interrupts-extended = <&gpio5 11 IRQ_TYPE_LEVEL_HIGH>;
>
> [Severity: High]
> Could this IRQ_TYPE_LEVEL_HIGH configuration also lead to an interrupt
> storm for i2c2_gpio_expander_21?
>
> [ ... ]
>
> > +	i2c2_gpio_expander_22: gpio@22 {	/* U13 */
> > +		compatible = "nxp,pcal6524";
> > +		reg = <0x22>;
> > +		#gpio-cells = <2>;
> > +		gpio-controller;
> > +		#interrupt-cells = <2>;
> > +		interrupt-controller;
> > +		interrupts-extended = <&gpio5 11 IRQ_TYPE_LEVEL_HIGH>;
>
> [Severity: High]
> Does i2c2_gpio_expander_22 similarly need to be configured for an active-low
> interrupt instead of IRQ_TYPE_LEVEL_HIGH?
>
> [ ... ]
>
> > +	tas2552: audio-codec@40 {
> > +		compatible = "ti,tas2552";
> > +		reg = <0x40>;
> > +		#sound-dai-cells = <0>;
> > +		avdd-supply = <&reg_1p8v>;
> > +		iovdd-supply = <&reg_3p3v>;
> > +		vbat-supply = <&reg_5p0v>;
> > +		enable-gpio = <&i2c2_gpio_expander_20 23 GPIO_ACTIVE_HIGH>;
>
> [Severity: Low]
> This isn't a bug, but should tas2552 be using the enable-gpios property name
> instead of the deprecated enable-gpio? The patch changelog mentions replacing
> gpio with gpios DT properties.

Please fix this one.

>
> [ ... ]
>
> > +	ethphy0: ethernet-phy@1 {	/* KSZ9131RNXI U20 */
> > +		compatible = "ethernet-phy-id0022.1640";
> > +		reg = <1>;
> > +		interrupts-extended = <&gpio1 10 IRQ_TYPE_LEVEL_LOW>;
> > +		reset-assert-us = <1000>;
> > +		/* RESET_N signal rise time ~100ms */
> > +		reset-deassert-us = <120000>;
> > +		reset-gpios = <&i2c2_gpio_expander_22 4 GPIO_ACTIVE_HIGH>;
>
> [Severity: Medium]
> Will ethphy0 be held in reset permanently? The KSZ9131RNXI RESET_N signal is
> active-low, so defining reset-gpios with GPIO_ACTIVE_HIGH will drive the line
> high to assert reset.
>
> > +	};
> > +
> > +	ethphy1: ethernet-phy@2 {	/* KSZ9131RNXI U22 */
> > +		compatible = "ethernet-phy-id0022.1640";
> > +		reg = <2>;
> > +		interrupts-extended = <&gpio1 10 IRQ_TYPE_LEVEL_LOW>;
> > +		reset-assert-us = <1000>;
> > +		/* RESET_N signal rise time ~100ms */
> > +		reset-deassert-us = <120000>;
> > +		reset-gpios = <&i2c2_gpio_expander_22 5 GPIO_ACTIVE_HIGH>;
>
> [Severity: Medium]
> Does ethphy1 also suffer from the incorrect GPIO_ACTIVE_HIGH reset polarity?

Is it correct?

>
> [ ... ]
>
> > +&usdhc1 {	/* eMMC */
> > +	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> > +	pinctrl-0 = <&pinctrl_usdhc1>;
>
> [Severity: Medium]
> Could usdhc1 be missing its reset sequence configuration? The hardware
> provides an eMMC_RESET line on the I2C GPIO expander, but it isn't consumed
> via mmc-pwrseq or reset-gpios. This might cause the eMMC to fail to initialize
> during warm reboots.

Please check this

Frank

>
> [ ... ]
>
> > +&usdhc3 {	/* M.2 Key-E */
> > +	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> > +	pinctrl-0 = <&pinctrl_usdhc3>;
>
> [Severity: Medium]
> Does the usdhc3 node need a vmmc-supply? The VDD_3V3_M2-E_EN pin is defined on
> the expander but there is no fixed regulator defined to power the M.2 Key-E
> slot, which might leave peripherals undetectable.
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260917062543.534416-1-marex@nabladev.com?part=3

Re: [PATCH v4 3/3] arm64: dts: imx95: Add support for Data Modul i.MX95 eDM SBC

[Marek Vasut]

On 9/17/26 6:53 PM, Frank Li wrote:

Hello Frank,

> On Thu, Sep 17, 2026 at 06:35:12AM +0000, sashiko-bot@kernel.org wrote:
>> Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
>> - [High] dts: pcal6524 interrupt polarity is incorrectly set to LEVEL_HIGH
>> - [Medium] dts: Ethernet PHY reset-gpios configured with wrong polarity
>> - [Medium] dts: eMMC reset GPIO defined but unused in usdhc1
>> - [Medium] dts: reg_panel_vcc regulator missing enable-active-high property
>> - [Medium] dts: M.2 Key-E (usdhc3) slot missing power regulator
>> - [Low] dts: tas2552 codec uses deprecated enable-gpio instead of enable-gpios

[...]

>>> +	reg_panel_vcc: regulator-panel-vcc {
>>> +		compatible = "regulator-fixed";
>>> +		regulator-min-microvolt = <3300000>;
>>> +		regulator-max-microvolt = <3300000>;
>>> +		regulator-name = "PANEL_VCC";
>>> +		gpios = <&i2c2_gpio_expander_20 17 0>;
> 
> gpio third arg 0, means GPIO_ACTIVE_HIGH
> 
> 	so need enable-active-high
> 
> if your boards have invertor should use GPIO_ACTIVE_LOW

I already went through all that, please see "Re: [PATCH 3/3] arm64: dts: 
imx95: Add support for Data Modul i.MX95 eDM SBC" .

[...]

>>> +	tas2552: audio-codec@40 {
>>> +		compatible = "ti,tas2552";
>>> +		reg = <0x40>;
>>> +		#sound-dai-cells = <0>;
>>> +		avdd-supply = <&reg_1p8v>;
>>> +		iovdd-supply = <&reg_3p3v>;
>>> +		vbat-supply = <&reg_5p0v>;
>>> +		enable-gpio = <&i2c2_gpio_expander_20 23 GPIO_ACTIVE_HIGH>;
>>
>> [Severity: Low]
>> This isn't a bug, but should tas2552 be using the enable-gpios property name
>> instead of the deprecated enable-gpio? The patch changelog mentions replacing
>> gpio with gpios DT properties.
> 
> Please fix this one.

No, this is correct, see

Documentation/devicetree/bindings/sound/ti,tas2552.yaml:  enable-gpio:

[...]

Re: [PATCH v4 3/3] arm64: dts: imx95: Add support for Data Modul i.MX95 eDM SBC

[Frank Li]

On Thu, Sep 17, 2026 at 07:19:51PM +0200, Marek Vasut wrote:
> On 9/17/26 6:53 PM, Frank Li wrote:
>
> Hello Frank,
>
> > On Thu, Sep 17, 2026 at 06:35:12AM +0000, sashiko-bot@kernel.org wrote:
> > > Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
> > > - [High] dts: pcal6524 interrupt polarity is incorrectly set to LEVEL_HIGH
> > > - [Medium] dts: Ethernet PHY reset-gpios configured with wrong polarity
> > > - [Medium] dts: eMMC reset GPIO defined but unused in usdhc1
> > > - [Medium] dts: reg_panel_vcc regulator missing enable-active-high property
> > > - [Medium] dts: M.2 Key-E (usdhc3) slot missing power regulator
> > > - [Low] dts: tas2552 codec uses deprecated enable-gpio instead of enable-gpios
>
> [...]
>
> > > > +	reg_panel_vcc: regulator-panel-vcc {
> > > > +		compatible = "regulator-fixed";
> > > > +		regulator-min-microvolt = <3300000>;
> > > > +		regulator-max-microvolt = <3300000>;
> > > > +		regulator-name = "PANEL_VCC";
> > > > +		gpios = <&i2c2_gpio_expander_20 17 0>;
> >
> > gpio third arg 0, means GPIO_ACTIVE_HIGH
> >
> > 	so need enable-active-high
> >
> > if your boards have invertor should use GPIO_ACTIVE_LOW
>
> I already went through all that, please see "Re: [PATCH 3/3] arm64: dts:
> imx95: Add support for Data Modul i.MX95 eDM SBC" .

at https://lore.kernel.org/imx/f4dbeaac-ab10-4980-9fc5-533907be223c@nabladev.com/

<&i2c2_gpio_expander_20 17 0>;
                           ^

0 should use predefine MACRO, after I check 0 means GPIO_ACTIVE_HIGH.

so need enable-active-high for regulator.


>
> [...]
>
> > > > +	tas2552: audio-codec@40 {
> > > > +		compatible = "ti,tas2552";
> > > > +		reg = <0x40>;
> > > > +		#sound-dai-cells = <0>;
> > > > +		avdd-supply = <&reg_1p8v>;
> > > > +		iovdd-supply = <&reg_3p3v>;
> > > > +		vbat-supply = <&reg_5p0v>;
> > > > +		enable-gpio = <&i2c2_gpio_expander_20 23 GPIO_ACTIVE_HIGH>;
> > >
> > > [Severity: Low]
> > > This isn't a bug, but should tas2552 be using the enable-gpios property name
> > > instead of the deprecated enable-gpio? The patch changelog mentions replacing
> > > gpio with gpios DT properties.
> >
> > Please fix this one.
>
> No, this is correct, see
>
> Documentation/devicetree/bindings/sound/ti,tas2552.yaml:  enable-gpio:

It is fine now, I suggest update bindings to allow both. which convert
by Rob at Jan 2026. I think Rob may miss it.

kernel hack code covert -gpio to -gpios

Frank

>
> [...]

Re: [PATCH v4 3/3] arm64: dts: imx95: Add support for Data Modul i.MX95 eDM SBC

[Marek Vasut]

On 9/17/26 8:46 PM, Frank Li wrote:

Hello Frank,

[...]

>>>>> +	reg_panel_vcc: regulator-panel-vcc {
>>>>> +		compatible = "regulator-fixed";
>>>>> +		regulator-min-microvolt = <3300000>;
>>>>> +		regulator-max-microvolt = <3300000>;
>>>>> +		regulator-name = "PANEL_VCC";
>>>>> +		gpios = <&i2c2_gpio_expander_20 17 0>;
>>>
>>> gpio third arg 0, means GPIO_ACTIVE_HIGH
>>>
>>> 	so need enable-active-high
>>>
>>> if your boards have invertor should use GPIO_ACTIVE_LOW
>>
>> I already went through all that, please see "Re: [PATCH 3/3] arm64: dts:
>> imx95: Add support for Data Modul i.MX95 eDM SBC" .
> 
> at https://lore.kernel.org/imx/f4dbeaac-ab10-4980-9fc5-533907be223c@nabladev.com/
> 
> <&i2c2_gpio_expander_20 17 0>;
>                             ^
> 
> 0 should use predefine MACRO, after I check 0 means GPIO_ACTIVE_HIGH.
> 
> so need enable-active-high for regulator.

This is extended via a DTO, so no, I must not use a macro because I do 
not know the polarity of this signal, that is why there is 0 here.

The enable-active-high DT property must explicitly NOT be here, because 
the DTO can not remove properties from the base DT. Adding 
enable-active-high here would make the DTO unable to operate this signal 
as active-low .

>>>>> +	tas2552: audio-codec@40 {
>>>>> +		compatible = "ti,tas2552";
>>>>> +		reg = <0x40>;
>>>>> +		#sound-dai-cells = <0>;
>>>>> +		avdd-supply = <&reg_1p8v>;
>>>>> +		iovdd-supply = <&reg_3p3v>;
>>>>> +		vbat-supply = <&reg_5p0v>;
>>>>> +		enable-gpio = <&i2c2_gpio_expander_20 23 GPIO_ACTIVE_HIGH>;
>>>>
>>>> [Severity: Low]
>>>> This isn't a bug, but should tas2552 be using the enable-gpios property name
>>>> instead of the deprecated enable-gpio? The patch changelog mentions replacing
>>>> gpio with gpios DT properties.
>>>
>>> Please fix this one.
>>
>> No, this is correct, see
>>
>> Documentation/devicetree/bindings/sound/ti,tas2552.yaml:  enable-gpio:
> 
> It is fine now, I suggest update bindings to allow both. which convert
> by Rob at Jan 2026. I think Rob may miss it.
> 
> kernel hack code covert -gpio to -gpios
I'll add that into my todo, but that is a separate fix from this DT.

Re: [PATCH v4 3/3] arm64: dts: imx95: Add support for Data Modul i.MX95 eDM SBC

[Frank Li]

On Thu, Sep 17, 2026 at 08:55:56PM +0200, Marek Vasut wrote:
> On 9/17/26 8:46 PM, Frank Li wrote:
>
> Hello Frank,
>
> [...]
>
> > > > > > +	reg_panel_vcc: regulator-panel-vcc {
> > > > > > +		compatible = "regulator-fixed";
> > > > > > +		regulator-min-microvolt = <3300000>;
> > > > > > +		regulator-max-microvolt = <3300000>;
> > > > > > +		regulator-name = "PANEL_VCC";
> > > > > > +		gpios = <&i2c2_gpio_expander_20 17 0>;
> > > >
> > > > gpio third arg 0, means GPIO_ACTIVE_HIGH
> > > >
> > > > 	so need enable-active-high
> > > >
> > > > if your boards have invertor should use GPIO_ACTIVE_LOW
> > >
> > > I already went through all that, please see "Re: [PATCH 3/3] arm64: dts:
> > > imx95: Add support for Data Modul i.MX95 eDM SBC" .
> >
> > at https://lore.kernel.org/imx/f4dbeaac-ab10-4980-9fc5-533907be223c@nabladev.com/
> >
> > <&i2c2_gpio_expander_20 17 0>;
> >                             ^
> >
> > 0 should use predefine MACRO, after I check 0 means GPIO_ACTIVE_HIGH.
> >
> > so need enable-active-high for regulator.
>
> This is extended via a DTO, so no, I must not use a macro because I do not
> know the polarity of this signal, that is why there is 0 here.
>
> The enable-active-high DT property must explicitly NOT be here, because the
> DTO can not remove properties from the base DT. Adding enable-active-high
> here would make the DTO unable to operate this signal as active-low .


But why DTO need update regulator-panel-vcc's gpio informaiton. I suppose
it is fixed when board design.

Does this regulator place at additional boards?

Frank

>
> > > > > > +	tas2552: audio-codec@40 {
> > > > > > +		compatible = "ti,tas2552";
> > > > > > +		reg = <0x40>;
> > > > > > +		#sound-dai-cells = <0>;
> > > > > > +		avdd-supply = <&reg_1p8v>;
> > > > > > +		iovdd-supply = <&reg_3p3v>;
> > > > > > +		vbat-supply = <&reg_5p0v>;
> > > > > > +		enable-gpio = <&i2c2_gpio_expander_20 23 GPIO_ACTIVE_HIGH>;
> > > > >
> > > > > [Severity: Low]
> > > > > This isn't a bug, but should tas2552 be using the enable-gpios property name
> > > > > instead of the deprecated enable-gpio? The patch changelog mentions replacing
> > > > > gpio with gpios DT properties.
> > > >
> > > > Please fix this one.
> > >
> > > No, this is correct, see
> > >
> > > Documentation/devicetree/bindings/sound/ti,tas2552.yaml:  enable-gpio:
> >
> > It is fine now, I suggest update bindings to allow both. which convert
> > by Rob at Jan 2026. I think Rob may miss it.
> >
> > kernel hack code covert -gpio to -gpios
> I'll add that into my todo, but that is a separate fix from this DT.

Re: [PATCH v4 3/3] arm64: dts: imx95: Add support for Data Modul i.MX95 eDM SBC

[Marek Vasut]

On 9/18/26 3:58 PM, Frank Li wrote:

Hello Frank,

>>>>>>> +	reg_panel_vcc: regulator-panel-vcc {
>>>>>>> +		compatible = "regulator-fixed";
>>>>>>> +		regulator-min-microvolt = <3300000>;
>>>>>>> +		regulator-max-microvolt = <3300000>;
>>>>>>> +		regulator-name = "PANEL_VCC";
>>>>>>> +		gpios = <&i2c2_gpio_expander_20 17 0>;
>>>>>
>>>>> gpio third arg 0, means GPIO_ACTIVE_HIGH
>>>>>
>>>>> 	so need enable-active-high
>>>>>
>>>>> if your boards have invertor should use GPIO_ACTIVE_LOW
>>>>
>>>> I already went through all that, please see "Re: [PATCH 3/3] arm64: dts:
>>>> imx95: Add support for Data Modul i.MX95 eDM SBC" .
>>>
>>> at https://lore.kernel.org/imx/f4dbeaac-ab10-4980-9fc5-533907be223c@nabladev.com/
>>>
>>> <&i2c2_gpio_expander_20 17 0>;
>>>                              ^
>>>
>>> 0 should use predefine MACRO, after I check 0 means GPIO_ACTIVE_HIGH.
>>>
>>> so need enable-active-high for regulator.
>>
>> This is extended via a DTO, so no, I must not use a macro because I do not
>> know the polarity of this signal, that is why there is 0 here.
>>
>> The enable-active-high DT property must explicitly NOT be here, because the
>> DTO can not remove properties from the base DT. Adding enable-active-high
>> here would make the DTO unable to operate this signal as active-low .
> 
> 
> But why DTO need update regulator-panel-vcc's gpio informaiton. I suppose
> it is fixed when board design.

It is just a GPIO, it can have either polarity depending on the 
regulator that it controls.

-- 
Best regards,
Marek Vasut

Re: [PATCH v4 3/3] arm64: dts: imx95: Add support for Data Modul i.MX95 eDM SBC

[Frank Li]

On Sun, Sep 20, 2026 at 07:05:58PM +0200, Marek Vasut wrote:
> On 9/18/26 3:58 PM, Frank Li wrote:
>
> Hello Frank,
>
> > > > > > > > +	reg_panel_vcc: regulator-panel-vcc {
> > > > > > > > +		compatible = "regulator-fixed";
> > > > > > > > +		regulator-min-microvolt = <3300000>;
> > > > > > > > +		regulator-max-microvolt = <3300000>;
> > > > > > > > +		regulator-name = "PANEL_VCC";
> > > > > > > > +		gpios = <&i2c2_gpio_expander_20 17 0>;
> > > > > >
> > > > > > gpio third arg 0, means GPIO_ACTIVE_HIGH
> > > > > >
> > > > > > 	so need enable-active-high
> > > > > >
> > > > > > if your boards have invertor should use GPIO_ACTIVE_LOW
> > > > >
> > > > > I already went through all that, please see "Re: [PATCH 3/3] arm64: dts:
> > > > > imx95: Add support for Data Modul i.MX95 eDM SBC" .
> > > >
> > > > at https://lore.kernel.org/imx/f4dbeaac-ab10-4980-9fc5-533907be223c@nabladev.com/
> > > >
> > > > <&i2c2_gpio_expander_20 17 0>;
> > > >                              ^
> > > >
> > > > 0 should use predefine MACRO, after I check 0 means GPIO_ACTIVE_HIGH.
> > > >
> > > > so need enable-active-high for regulator.
> > >
> > > This is extended via a DTO, so no, I must not use a macro because I do not
> > > know the polarity of this signal, that is why there is 0 here.
> > >
> > > The enable-active-high DT property must explicitly NOT be here, because the
> > > DTO can not remove properties from the base DT. Adding enable-active-high
> > > here would make the DTO unable to operate this signal as active-low .
> >
> >
> > But why DTO need update regulator-panel-vcc's gpio informaiton. I suppose
> > it is fixed when board design.
>
> It is just a GPIO, it can have either polarity depending on the regulator
> that it controls.

Understand, But the problem is why polarity change after board design?

If reg_panel_vcc is on added on boards,  should it be in dtso file also to
match your hardware design correctly?

Frank

>
> --
> Best regards,
> Marek Vasut

Re: [PATCH v4 3/3] arm64: dts: imx95: Add support for Data Modul i.MX95 eDM SBC

[Marek Vasut]

On 9/21/26 6:24 PM, Frank Li wrote:

Hello Frank,

>>> But why DTO need update regulator-panel-vcc's gpio informaiton. I suppose
>>> it is fixed when board design.
>>
>> It is just a GPIO, it can have either polarity depending on the regulator
>> that it controls.
> 
> Understand, But the problem is why polarity change after board design?
> 
> If reg_panel_vcc is on added on boards,  should it be in dtso file also to
> match your hardware design correctly?

We want to avoid duplication in the DTOs files, do we not ?

Hence, base common stuff in the base DT, stuff that changes in the DTOs.

Re: [PATCH v4 3/3] arm64: dts: imx95: Add support for Data Modul i.MX95 eDM SBC

[Frank Li]

On Mon, Sep 21, 2026 at 06:37:26PM +0200, Marek Vasut wrote:
> On 9/21/26 6:24 PM, Frank Li wrote:
>
> Hello Frank,
>
> > > > But why DTO need update regulator-panel-vcc's gpio informaiton. I suppose
> > > > it is fixed when board design.
> > >
> > > It is just a GPIO, it can have either polarity depending on the regulator
> > > that it controls.
> >
> > Understand, But the problem is why polarity change after board design?
> >
> > If reg_panel_vcc is on added on boards,  should it be in dtso file also to
> > match your hardware design correctly?
>
> We want to avoid duplication in the DTOs files, do we not ?

Yes, but there are not dtso file yet, I don't know how to share it yet.

>
> Hence, base common stuff in the base DT, stuff that changes in the DTOs.

Idea is good, but avoid hack stuff. Can you show me what's plan use
reg_panel_vcc in dtso and how to share it.

Frank

Re: [PATCH v4 3/3] arm64: dts: imx95: Add support for Data Modul i.MX95 eDM SBC

[Marek Vasut]

On 9/21/26 7:11 PM, Frank Li wrote:

Hello Frank,

>>>>> But why DTO need update regulator-panel-vcc's gpio informaiton. I suppose
>>>>> it is fixed when board design.
>>>>
>>>> It is just a GPIO, it can have either polarity depending on the regulator
>>>> that it controls.
>>>
>>> Understand, But the problem is why polarity change after board design?
>>>
>>> If reg_panel_vcc is on added on boards,  should it be in dtso file also to
>>> match your hardware design correctly?
>>
>> We want to avoid duplication in the DTOs files, do we not ?
> 
> Yes, but there are not dtso file yet, I don't know how to share it yet.

Yes, there is no DTSO, because there is no DPU support for MX95, so 
display support in upstream is missing (check with Victor Liu, they 
might know more about the current state).

>> Hence, base common stuff in the base DT, stuff that changes in the DTOs.
> 
> Idea is good, but avoid hack stuff. Can you show me what's plan use
> reg_panel_vcc in dtso and how to share it.
See above, currently I cannot really use the regulator, because of the 
missing DPU support. The only DTO I temporarily have in tree (used with 
my DPU patchset) is for the RPi 7" display 2, which does not use this 
regulator.

The plan is to use it the same way as on the MX8MM/MX8MP eDM SBC in the DTO:

&reg_panel_vcc {
   gpios = <&i2c2_gpio_expander_20 17 GPIO_ACTIVE_HIGH>;
   enable-active-high;
   status = "okay";
};

or

&reg_panel_vcc {
   gpios = <&i2c2_gpio_expander_20 17 GPIO_ACTIVE_LOW>;
   status = "okay";
};

Re: [PATCH v4 3/3] arm64: dts: imx95: Add support for Data Modul i.MX95 eDM SBC

[Frank Li]

On Mon, Sep 21, 2026 at 08:43:35PM +0200, Marek Vasut wrote:
> On 9/21/26 7:11 PM, Frank Li wrote:
>
> Hello Frank,
>
> > > > > > But why DTO need update regulator-panel-vcc's gpio informaiton. I suppose
> > > > > > it is fixed when board design.
> > > > >
> > > > > It is just a GPIO, it can have either polarity depending on the regulator
> > > > > that it controls.
> > > >
> > > > Understand, But the problem is why polarity change after board design?
> > > >
> > > > If reg_panel_vcc is on added on boards,  should it be in dtso file also to
> > > > match your hardware design correctly?
> > >
> > > We want to avoid duplication in the DTOs files, do we not ?
> >
> > Yes, but there are not dtso file yet, I don't know how to share it yet.
>
> Yes, there is no DTSO, because there is no DPU support for MX95, so display
> support in upstream is missing (check with Victor Liu, they might know more
> about the current state).
>
> > > Hence, base common stuff in the base DT, stuff that changes in the DTOs.
> >
> > Idea is good, but avoid hack stuff. Can you show me what's plan use
> > reg_panel_vcc in dtso and how to share it.
> See above, currently I cannot really use the regulator, because of the
> missing DPU support.

I suggest add it when it will be used.  Or Remove gpios = <&i2c2_gpio_expander_20 17 0>;

Suppose it will be overwrited by dtso future.

> The only DTO I temporarily have in tree (used with my
> DPU patchset) is for the RPi 7" display 2, which does not use this
> regulator.
>
> The plan is to use it the same way as on the MX8MM/MX8MP eDM SBC in the DTO:
>
> &reg_panel_vcc {
>   gpios = <&i2c2_gpio_expander_20 17 GPIO_ACTIVE_HIGH>;
>   enable-active-high;
>   status = "okay";
> };
>
> or
>
> &reg_panel_vcc {
>   gpios = <&i2c2_gpio_expander_20 17 GPIO_ACTIVE_LOW>;
>   status = "okay";
> };

In future, it should be nexus node for it and put reg_panel_vcc into dtso
files, and looks like you use gpio controller add-on boards's regulator.

Frank

Re: [PATCH v4 3/3] arm64: dts: imx95: Add support for Data Modul i.MX95 eDM SBC

[Marek Vasut]

On 9/21/26 9:23 PM, Frank Li wrote:

[...]

>>>> Hence, base common stuff in the base DT, stuff that changes in the DTOs.
>>>
>>> Idea is good, but avoid hack stuff. Can you show me what's plan use
>>> reg_panel_vcc in dtso and how to share it.
>> See above, currently I cannot really use the regulator, because of the
>> missing DPU support.
> 
> I suggest add it when it will be used.

The users can already use it with additional downstream patches, so 
having the base node in the DT is helpful to the users.

> Or Remove gpios = <&i2c2_gpio_expander_20 17 0>;

Having the GPIO described here is also helpful to the users, since they 
won't have to look up which GPIO is controlling this regulator in the 
schematic, and won't make mistakes.

> Suppose it will be overwrited by dtso future.

Only the polarity.

>> The only DTO I temporarily have in tree (used with my
>> DPU patchset) is for the RPi 7" display 2, which does not use this
>> regulator.
>>
>> The plan is to use it the same way as on the MX8MM/MX8MP eDM SBC in the DTO:
>>
>> &reg_panel_vcc {
>>    gpios = <&i2c2_gpio_expander_20 17 GPIO_ACTIVE_HIGH>;
>>    enable-active-high;
>>    status = "okay";
>> };
>>
>> or
>>
>> &reg_panel_vcc {
>>    gpios = <&i2c2_gpio_expander_20 17 GPIO_ACTIVE_LOW>;
>>    status = "okay";
>> };
> 
> In future, it should be nexus node for it and put reg_panel_vcc into dtso
> files, and looks like you use gpio controller add-on boards's regulator.
There is really no need for a nexus node, only for a polarity setting.

Re: [PATCH v4 1/3] dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6563

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt-bindings: phy: incomplete schema validation for microchip,ata6563
--

commit e1e7d148b2a5e6742f485d13055f3692d10dbf6a
Author: Marek Vasut <marex@nabladev.com>

dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6563

Microchip ATA6563 is High-Speed CAN Transceiver with Standby Mode.
It is pin-compatible with TI TCAN1042 and has a compatible programming
model, therefore use ti,tcan1042 as fallback compatible.

> diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> index 9f5c37ca6496a..75c276548e122 100644
> --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> @@ -18,6 +18,7 @@ properties:
>        - items:
>            - enum:
>                - microchip,ata6561
> +              - microchip,ata6563
>                - ti,tcan1051
>            - const: ti,tcan1042

[Severity: Medium]
Will this compatible string bypass the constraints enforced in the allOf block
below?

Since microchip,ata6563 is defined as an array item here, the compatible
property will be an array at runtime (e.g. ["microchip,ata6563",
"ti,tcan1042"]).

Looking at the allOf conditional block for ti,tcan1042:

allOf:
  - if:
      properties:
        compatible:
          enum:
            - nxp,tjr1443
            - ti,tcan1042
            - ti,tcan1043

This block uses an exact enum match. In JSON Schema, an array value will not
match this enum of single strings. 

Does this need to use contains: enum or contains: const to properly apply
constraints (like #phy-cells: const: 0) when a fallback array is used?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917062543.534416-1-marex@nabladev.com?part=1

Re: [PATCH v4 1/3] dt-bindings: phy: ti,tcan104x-can: Document Microchip ATA6563

[Krzysztof Kozlowski]

On Thu, Sep 17, 2026 at 08:25:26AM +0200, Marek Vasut wrote:
> Microchip ATA6563 is High-Speed CAN Transceiver with Standby Mode.
> It is pin-compatible with TI TCAN1042 and has a compatible programming
> model, therefore use ti,tcan1042 as fallback compatible.
> 
> Signed-off-by: Marek Vasut <marex@nabladev.com>

I'll fix up the binding constraints.


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof