[PATCH 0/4] Mainline Protonic PRT8ML board

[PATCH 0/4] Mainline Protonic PRT8ML board

[Jonas Rebmann]

This series adds the Protonic PRT8ML device tree as well as some minor
corrections to the devicetree bindings used.

Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
---
Jonas Rebmann (3):
      dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property
      ASoC: dt-bindings: asahi-kasei,ak4458: Reference common DAI properties
      dt-bindings: arm: fsl: Add Protonic PRT8ML

Lucas Stach (1):
      arm64: dts: add Protonic PRT8ML board

 Documentation/devicetree/bindings/arm/fsl.yaml     |   1 +
 .../devicetree/bindings/net/dsa/nxp,sja1105.yaml   |   5 +
 .../bindings/sound/asahi-kasei,ak4458.yaml         |   4 +
 arch/arm64/boot/dts/freescale/Makefile             |   1 +
 arch/arm64/boot/dts/freescale/imx8mp-prt8ml.dts    | 409 +++++++++++++++++++++
 5 files changed, 420 insertions(+)
---
base-commit: d34bbb45b57c90a5c1bcac5f327df79ddfbfe957
change-id: 20250701-imx8mp-prt8ml-01be34684659

Best regards,
--  
Jonas Rebmann <jre@pengutronix.de>

[PATCH 1/4] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property

[Jonas Rebmann]

Both the nxp,sja1105 and the nxp,sja1110 series feature an active-low
reset pin, rendering reset-gpios a valid property for all of the
nxp,sja1105 family.

Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
---
 Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
index 9432565f4f5d..8f4ef9d64556 100644
--- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
@@ -32,6 +32,11 @@ properties:
   reg:
     maxItems: 1
 
+  reset-gpios:
+    description:
+      GPIO to be used to reset the whole device
+    maxItems: 1
+
   spi-cpha: true
   spi-cpol: true
 

-- 
2.51.0.178.g2462961280

[PATCH 2/4] ASoC: dt-bindings: asahi-kasei,ak4458: Reference common DAI properties

[Jonas Rebmann]

Reference the dai-common.yaml schema to allow '#sound-dai-cells' and
"sound-name-prefix' to be used.

Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
---
 Documentation/devicetree/bindings/sound/asahi-kasei,ak4458.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/asahi-kasei,ak4458.yaml b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4458.yaml
index 4477f84b7acc..1fdbeecc5eff 100644
--- a/Documentation/devicetree/bindings/sound/asahi-kasei,ak4458.yaml
+++ b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4458.yaml
@@ -15,6 +15,9 @@ properties:
       - asahi-kasei,ak4458
       - asahi-kasei,ak4497
 
+  "#sound-dai-cells":
+    const: 0
+
   reg:
     maxItems: 1
 
@@ -46,6 +49,7 @@ required:
   - reg
 
 allOf:
+  - $ref: dai-common.yaml#
   - if:
       properties:
         compatible:

-- 
2.51.0.178.g2462961280

[PATCH 3/4] dt-bindings: arm: fsl: Add Protonic PRT8ML

[Jonas Rebmann]

Add DT compatible string for Protonic PRT8ML board.

Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
---
 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 ebafa6ecbcb6..ce3e53b4513a 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1106,6 +1106,7 @@ properties:
               - gateworks,imx8mp-gw75xx-2x # i.MX8MP Gateworks Board
               - gateworks,imx8mp-gw82xx-2x # i.MX8MP Gateworks Board
               - gocontroll,moduline-display # GOcontroll Moduline Display controller
+              - prt,prt8ml             # Protonic PRT8ML
               - skov,imx8mp-skov-basic # SKOV i.MX8MP baseboard without frontplate
               - skov,imx8mp-skov-revb-hdmi # SKOV i.MX8MP climate control without panel
               - skov,imx8mp-skov-revb-lt6 # SKOV i.MX8MP climate control with 7” panel

-- 
2.51.0.178.g2462961280

[PATCH 4/4] arm64: dts: add Protonic PRT8ML board

[Jonas Rebmann]

From: Lucas Stach <l.stach@pengutronix.de>

Add devicetree for the Protonic PRT8ML.

The board is similar to the Protonic PRT8MM but i.MX8MP based.

Some features have been removed as the drivers haven't been mainlined
yet or other issues where encountered:
 - Stepper motors to be controlled using motion control subsystem
 - MIPI/DSI to eDP USB alt-mode
 - Onboard ethernet (10BASE-T1L+PoDL, 100BASE-T1+PoDL, 1000BASE-T,
   1000BASE-T1)

Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
---
 arch/arm64/boot/dts/freescale/Makefile          |   1 +
 arch/arm64/boot/dts/freescale/imx8mp-prt8ml.dts | 409 ++++++++++++++++++++++++
 2 files changed, 410 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 2be724579632..98ab7387726e 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -222,6 +222,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-nitrogen-smarc-universal-board.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-phyboard-pollux-rdk.dtb
 imx8mp-phyboard-pollux-rdk-no-eth-dtbs += imx8mp-phyboard-pollux-rdk.dtb imx8mp-phycore-no-eth.dtbo
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-phyboard-pollux-rdk-no-eth.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-prt8ml.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-basic.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-hdmi.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-lt6.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-prt8ml.dts b/arch/arm64/boot/dts/freescale/imx8mp-prt8ml.dts
new file mode 100644
index 000000000000..95d5c29b4887
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-prt8ml.dts
@@ -0,0 +1,409 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2020 Protonic Holland
+ * Copyright 2019 NXP
+ */
+
+/dts-v1/;
+
+#include "imx8mp.dtsi"
+
+/ {
+	model = "Protonic PRT8ML";
+	compatible = "prt,prt8ml", "fsl,imx8mp";
+
+	chosen {
+		stdout-path = &uart4;
+	};
+
+	clock_sja1105: clock-sja1105 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <25000000>;
+	};
+
+	pcie_refclk: pcie0-refclk {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <100000000>;
+	};
+
+	pcie_refclk_oe: pcie0-refclk-oe {
+		compatible = "gpio-gate-clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pcie_refclk>;
+		clocks = <&pcie_refclk>;
+		#clock-cells = <0>;
+		enable-gpios = <&gpio5 23 GPIO_ACTIVE_HIGH>;
+	};
+};
+
+&A53_0 {
+	cpu-supply = <&fan53555>;
+};
+
+&A53_1 {
+	cpu-supply = <&fan53555>;
+};
+
+&A53_2 {
+	cpu-supply = <&fan53555>;
+};
+
+&A53_3 {
+	cpu-supply = <&fan53555>;
+};
+
+&a53_opp_table {
+	opp-1200000000 {
+		opp-microvolt = <900000>;
+	};
+
+	opp-1600000000 {
+		opp-microvolt = <980000>;
+	};
+
+	/delete-node/ opp-1800000000;
+};
+
+&flexcan1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan1>;
+	status = "okay";
+};
+
+&flexcan2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan2>;
+	status = "okay";
+};
+
+&i2c1 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1>;
+	status = "okay";
+
+	ak5558: codec@10 {
+		compatible = "asahi-kasei,ak5558";
+		reg = <0x10>;
+		reset-gpios = <&gpio_exp_1 2 GPIO_ACTIVE_LOW>;
+	};
+
+	gpio_exp_1: gpio@25 {
+		compatible = "nxp,pca9571";
+		reg = <0x25>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+};
+
+&i2c2 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	status = "okay";
+
+	tps65987ddh_0: usb-pd@20 {
+		compatible = "ti,tps6598x";
+		reg = <0x20>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_tps65987ddh_0>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
+	};
+
+	gpio_exp_2: gpio@25 {
+		compatible = "nxp,pca9571";
+		reg = <0x25>;
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		c0-hreset-hog {
+			gpio-hog;
+			gpios = <7 GPIO_ACTIVE_LOW>;
+			line-name = "c0-hreset";
+			output-low;
+		};
+
+		c1-hreset-hog {
+			gpio-hog;
+			gpios = <6 GPIO_ACTIVE_LOW>;
+			line-name = "c1-hreset";
+			output-low;
+		};
+	};
+
+	fan53555: regulator@60 {
+		compatible = "fcs,fan53555";
+		reg = <0x60>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_fan53555>;
+		regulator-name = "fan53555";
+		regulator-min-microvolt = <900000>;
+		regulator-max-microvolt = <980000>;
+		regulator-always-on;
+		regulator-boot-on;
+		fcs,suspend-voltage-selector = <1>;
+	};
+};
+
+&i2c3 {
+	clock-frequency = <400000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	status = "okay";
+
+	ak4458: codec@11 {
+		compatible = "asahi-kasei,ak4458";
+		reg = <0x11>;
+		#sound-dai-cells = <0>;
+		reset-gpios = <&gpio_exp_2 5 GPIO_ACTIVE_LOW>;
+	};
+
+	tps65987ddh_1: usb-pd@20 {
+		compatible = "ti,tps6598x";
+		reg = <0x20>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_tps65987ddh_1>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
+&lcdif1 {
+	status = "okay";
+};
+
+&snvs_pwrkey {
+	status = "okay";
+};
+
+&uart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart4>;
+	status = "okay";
+};
+
+&usb3_0 {
+	status = "okay";
+};
+
+&usb3_1 {
+	status = "okay";
+};
+
+&usb3_phy0 {
+	status = "okay";
+};
+
+&usb3_phy1 {
+	status = "okay";
+};
+
+&usb_dwc3_0 {
+	dr_mode = "host";
+	status = "okay";
+};
+
+&usb_dwc3_1 {
+	dr_mode = "host";
+	status = "okay";
+};
+
+&usdhc2 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+	assigned-clocks = <&clk IMX8MP_CLK_USDHC2>;
+	assigned-clock-rates = <100000000>;
+	bus-width = <4>;
+	cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+	no-1-8-v;
+	sd-uhs-sdr12;
+	sd-uhs-sdr25;
+	status = "okay";
+};
+
+&usdhc3 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc3>;
+	pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+	pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+	assigned-clocks = <&clk IMX8MP_CLK_USDHC3_ROOT>;
+	assigned-clock-rates = <400000000>;
+	bus-width = <8>;
+	non-removable;
+	no-sdio;
+	no-sd;
+	status = "okay";
+};
+
+&wdog1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdog>;
+	fsl,ext-reset-output;
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl_fan53555: fan53555grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_SPDIF_EXT_CLK__GPIO5_IO05		0x114
+		>;
+	};
+
+	pinctrl_flexcan1: flexcan1grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_SPDIF_RX__CAN1_RX		0x154
+			MX8MP_IOMUXC_SPDIF_TX__CAN1_TX		0x154
+		>;
+	};
+
+	pinctrl_flexcan2: flexcan2grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_UART3_TXD__CAN2_RX		0x154
+			MX8MP_IOMUXC_UART3_RXD__CAN2_TX		0x154
+		>;
+	};
+
+	pinctrl_i2c1: i2c1grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_ECSPI1_SCLK__I2C1_SCL	0x400000c3
+			MX8MP_IOMUXC_ECSPI1_MOSI__I2C1_SDA	0x400000c3
+		>;
+	};
+
+	pinctrl_i2c2: i2c2grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL		0x400000c3
+			MX8MP_IOMUXC_I2C2_SDA__I2C2_SDA		0x400000c3
+		>;
+	};
+
+	pinctrl_i2c3: i2c3grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_I2C3_SCL__I2C3_SCL		0x400000c3
+			MX8MP_IOMUXC_I2C3_SDA__I2C3_SDA		0x400000c3
+		>;
+	};
+
+	pinctrl_pcie_refclk: pcierefclkgrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_UART1_TXD__GPIO5_IO23	0xc6
+		>;
+	};
+
+	pinctrl_tps65987ddh_0: tps65987ddh_0grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_GPIO1_IO12__GPIO1_IO12	0x1d0
+		>;
+	};
+
+	pinctrl_tps65987ddh_1: tps65987ddh_1grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_GPIO1_IO15__GPIO1_IO15	0x1d0
+		>;
+	};
+
+	pinctrl_uart4: uart4grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_UART4_RXD__UART4_DCE_RX		0x040
+			MX8MP_IOMUXC_UART4_TXD__UART4_DCE_TX		0x040
+		>;
+	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK		0x190
+			MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD		0x1d0
+			MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0		0x1d0
+			MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1		0x1d0
+			MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2		0x1d0
+			MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3		0x1d0
+		>;
+	};
+
+	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK		0x194
+			MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD		0x1d4
+			MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0		0x1d4
+			MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1		0x1d4
+			MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2		0x1d4
+			MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3		0x1d4
+		>;
+	};
+
+	pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK		0x196
+			MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD		0x1d6
+			MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0		0x1d6
+			MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1		0x1d6
+			MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2		0x1d6
+			MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3		0x1d6
+		>;
+	};
+
+	pinctrl_usdhc2_gpio: usdhc2-gpiogrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_SD2_CD_B__GPIO2_IO12		0x0d4
+		>;
+	};
+
+	pinctrl_usdhc3: usdhc3grp {
+		fsl,pins = <
+			MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK		0x190
+			MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD		0x1d0
+			MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0		0x1d0
+			MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1		0x1d0
+			MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2		0x1d0
+			MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3		0x1d0
+			MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4		0x1d0
+			MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5		0x1d0
+			MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6		0x1d0
+			MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7		0x1d0
+			MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE		0x190
+		>;
+	};
+
+	pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK		0x194
+			MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD		0x1d4
+			MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0		0x1d4
+			MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1		0x1d4
+			MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2		0x1d4
+			MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3		0x1d4
+			MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4		0x1d4
+			MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5		0x1d4
+			MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6		0x1d4
+			MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7		0x1d4
+			MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE		0x194
+		>;
+	};
+
+	pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK		0x196
+			MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD		0x1d6
+			MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0		0x1d6
+			MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1		0x1d6
+			MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2		0x1d6
+			MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3		0x1d6
+			MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4		0x1d6
+			MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5		0x1d6
+			MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6		0x1d6
+			MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7		0x1d6
+			MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE		0x196
+		>;
+	};
+
+	pinctrl_wdog: wdoggrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_GPIO1_IO02__WDOG1_WDOG_B		0x166
+		>;
+	};
+};

-- 
2.51.0.178.g2462961280

Re: [PATCH 1/4] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property

[Vladimir Oltean]

On Wed, Sep 10, 2025 at 02:35:21PM +0200, Jonas Rebmann wrote:
> Both the nxp,sja1105 and the nxp,sja1110 series feature an active-low
> reset pin, rendering reset-gpios a valid property for all of the
> nxp,sja1105 family.
> 
> Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
> ---
>  Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
> index 9432565f4f5d..8f4ef9d64556 100644
> --- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
> +++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
> @@ -32,6 +32,11 @@ properties:
>    reg:
>      maxItems: 1
> 
> +  reset-gpios:
> +    description:
> +      GPIO to be used to reset the whole device
> +    maxItems: 1
> +
>    spi-cpha: true
>    spi-cpol: true
> 
> 
> --
> 2.51.0.178.g2462961280
>

There are multiple issues with the reset line and I was considering
dropping driver support for it.

The most important issue is the fact that, according to NXP document
AH1704, the RST_N signal has to be kept asserted for 5 us after power-on
reset. That is hard to achieve if this pin is routed to an SoC GPIO.
Additionally, routing the reset signal to a host SoC GPIO does not bring
any particular benefit, since the switch can be (and is) also reset by
the driver over SPI.

So, at least for this particular switch, having a "reset-gpios" actively
points towards a potential violation of its POR timing requirements.
That is, unless the power rails are also software-controlled. But they
aren't.

Re: [PATCH 1/4] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property

[Marco Felsch]

On 25-09-10, Vladimir Oltean wrote:
> On Wed, Sep 10, 2025 at 02:35:21PM +0200, Jonas Rebmann wrote:
> > Both the nxp,sja1105 and the nxp,sja1110 series feature an active-low
> > reset pin, rendering reset-gpios a valid property for all of the
> > nxp,sja1105 family.
> > 
> > Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
> > ---
> >  Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
> > index 9432565f4f5d..8f4ef9d64556 100644
> > --- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
> > +++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml
> > @@ -32,6 +32,11 @@ properties:
> >    reg:
> >      maxItems: 1
> > 
> > +  reset-gpios:
> > +    description:
> > +      GPIO to be used to reset the whole device
> > +    maxItems: 1
> > +
> >    spi-cpha: true
> >    spi-cpol: true
> > 
> > 
> > --
> > 2.51.0.178.g2462961280
> >
> 
> There are multiple issues with the reset line and I was considering
> dropping driver support for it.
> 
> The most important issue is the fact that, according to NXP document
> AH1704, the RST_N signal has to be kept asserted for 5 us after power-on
> reset. That is hard to achieve if this pin is routed to an SoC GPIO.

Can you please elaborate a bit more? I was curious and checked the
AH1704, it says:

"The RST_N signal must be kept low for at least 5 us after all power
supplies and reference clock signals become stable."

This is very common, so the driver only needs to ensure that the pin was
pulled low for at least 5us but not exact 5us.

> Additionally, routing the reset signal to a host SoC GPIO does not bring
> any particular benefit, since the switch can be (and is) also reset by
> the driver over SPI.

I don't know the switch but it's also common that a so called
software-reset may not reset all registers, state machines, etc.

There it's common practice that the driver tries to pull the hw reset
line and if not present falls back to a software reset.

> So, at least for this particular switch, having a "reset-gpios" actively
> points towards a potential violation of its POR timing requirements.

Really? Please see my above comment.

> That is, unless the power rails are also software-controlled. But they
> aren't.

AH1704 Fig.10 just illustrate a reset and power-on sequence. I highly
doubt that the host can't pull the hw rest line if the supplies and the
clock is already running.

You're right about the fact that the driver is currently not able to do
a proper power-on sequence, so the kernel relies on the prev. firmware
or the hw-setup. But this is another problem.

Regards,
  Marco

Re: [PATCH 1/4] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property

[Vladimir Oltean]

On Wed, Sep 10, 2025 at 04:30:44PM +0200, Marco Felsch wrote:
> Can you please elaborate a bit more? I was curious and checked the
> AH1704, it says:
> 
> "The RST_N signal must be kept low for at least 5 us after all power
> supplies and reference clock signals become stable."
> 
> This is very common, so the driver only needs to ensure that the pin was
> pulled low for at least 5us but not exact 5us.

The statement says that during power-up, when the supply voltages and
clocks rise in order to become within spec, the reset signal must be
held low. This requirement lasts for up to 5 us more after the other
signals are in spec.

> > Additionally, routing the reset signal to a host SoC GPIO does not bring
> > any particular benefit, since the switch can be (and is) also reset by
> > the driver over SPI.
> 
> I don't know the switch but it's also common that a so called
> software-reset may not reset all registers, state machines, etc.

Neither should you assume that RST_N resets everything. I can't be a lot
more specific, but asserting RST_N at runtime is essentially equivalent
to a cold reset as done over SPI, as done by sja1105pqrs_reset_cmd().

> There it's common practice that the driver tries to pull the hw reset
> line and if not present falls back to a software reset.
> 
> > So, at least for this particular switch, having a "reset-gpios" actively
> > points towards a potential violation of its POR timing requirements.
> 
> Really? Please see my above comment.
> 
> > That is, unless the power rails are also software-controlled. But they
> > aren't.
> 
> AH1704 Fig.10 just illustrate a reset and power-on sequence. I highly
> doubt that the host can't pull the hw rest line if the supplies and the
> clock is already running.

I didn't say that it can't pull the reset line if the supplies/clocks
are in spec.

I said that _while the supplies and clocks aren't in spec and 5 us after
they become in spec_, RST_N has to be kept low.

And if you plan to do that from the GPIO function of your SoC, the SoC
might be busy doing other stuff, like booting, and no one might be
driving the RST_N voltage to a defined state.

It really depends on a lot of factors including the reset timing and
supply voltage distribution of the PCB, but RST_N has essentially 2
purposes. One is ensuring proper POR sequencing, the other is cold
resetting at runtime. You can do the latter over SPI with identical
outcome, which leaves proper POR sequencing, which is not best served by
a GPIO in my experience.

> You're right about the fact that the driver is currently not able to do
> a proper power-on sequence, so the kernel relies on the prev. firmware
> or the hw-setup. But this is another problem.
> 
> Regards,
>   Marco

Re: [PATCH 1/4] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]

On Wed, Sep 10, 2025 at 05:43:28PM +0300, Vladimir Oltean wrote:
> On Wed, Sep 10, 2025 at 04:30:44PM +0200, Marco Felsch wrote:

> > Can you please elaborate a bit more? I was curious and checked the
> > AH1704, it says:

> > "The RST_N signal must be kept low for at least 5 us after all power
> > supplies and reference clock signals become stable."

> > This is very common, so the driver only needs to ensure that the pin was
> > pulled low for at least 5us but not exact 5us.

> The statement says that during power-up, when the supply voltages and
> clocks rise in order to become within spec, the reset signal must be
> held low. This requirement lasts for up to 5 us more after the other
> signals are in spec.

...

> I said that _while the supplies and clocks aren't in spec and 5 us after
> they become in spec_, RST_N has to be kept low.

> And if you plan to do that from the GPIO function of your SoC, the SoC
> might be busy doing other stuff, like booting, and no one might be
> driving the RST_N voltage to a defined state.

I suspect you're reading too much into the datasheet there.  I suspect
that what it's trying to say is that the reset signal only works with
stable power and clocks, that it must be held low for the 5us while
those conditions hold and that you have to do at least one cold reset
after power on.  The above wording is pretty common in datasheets and I
know in a bunch of cases it was carried forward kind of blindly rather
than looking at the actual device requirements.

> It really depends on a lot of factors including the reset timing and
> supply voltage distribution of the PCB, but RST_N has essentially 2
> purposes. One is ensuring proper POR sequencing, the other is cold
> resetting at runtime. You can do the latter over SPI with identical
> outcome, which leaves proper POR sequencing, which is not best served by
> a GPIO in my experience.

I'm not sure not including the signal in the DT bindings is going to
influence board designers much either way TBH.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/4] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property

[Vladimir Oltean]

On Wed, Sep 10, 2025 at 04:09:05PM +0100, Mark Brown wrote:
> > And if you plan to do that from the GPIO function of your SoC, the SoC
> > might be busy doing other stuff, like booting, and no one might be
> > driving the RST_N voltage to a defined state.
> 
> I suspect you're reading too much into the datasheet there.  I suspect
> that what it's trying to say is that the reset signal only works with
> stable power and clocks, that it must be held low for the 5us while
> those conditions hold and that you have to do at least one cold reset
> after power on.  The above wording is pretty common in datasheets and I
> know in a bunch of cases it was carried forward kind of blindly rather
> than looking at the actual device requirements.

No, it doesn't say that, and I had discussions with the application
engineering team for this chip about this :-/

I can't comment on anything extrapolated outside of the SJA1105/SJA1110.

> > It really depends on a lot of factors including the reset timing and
> > supply voltage distribution of the PCB, but RST_N has essentially 2
> > purposes. One is ensuring proper POR sequencing, the other is cold
> > resetting at runtime. You can do the latter over SPI with identical
> > outcome, which leaves proper POR sequencing, which is not best served by
> > a GPIO in my experience.
> 
> I'm not sure not including the signal in the DT bindings is going to
> influence board designers much either way TBH.

Either way, something has to nudge at least the software developer
towards finding and reading the vendor's relevant documentation.

In that sense, 'reset-gpios' is misleading to say the least, because
everyone sees a reset GPIO and has the human tendency to think there
isn't anything more to be known about it (like I also did).

To be clear, I'm saying that supporting 'reset-gpios' in this driver was
a mistake, at least in the form where its supplies and clocks aren't
also under control. I'm not sure it's a mistake that we need to document,
and if we do, there need to be a lot more disclaimers. Also, I'm pretty
sure nothing will break if driver support for it is simply removed.

Re: [PATCH 1/4] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]

On Wed, Sep 10, 2025 at 06:34:54PM +0300, Vladimir Oltean wrote:
> On Wed, Sep 10, 2025 at 04:09:05PM +0100, Mark Brown wrote:

> > after power on.  The above wording is pretty common in datasheets and I
> > know in a bunch of cases it was carried forward kind of blindly rather
> > than looking at the actual device requirements.

> No, it doesn't say that, and I had discussions with the application
> engineering team for this chip about this :-/

> I can't comment on anything extrapolated outside of the SJA1105/SJA1110.

Fair enough if this chip is unusually unstable, TBH I'm surprised to
see something currently available that's so fragile - internal POR
circuits aren't exactly new or exciting and do make things so much more
robust.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/4] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property

[Marco Felsch]

On 25-09-10, Vladimir Oltean wrote:
> On Wed, Sep 10, 2025 at 04:09:05PM +0100, Mark Brown wrote:
> > > And if you plan to do that from the GPIO function of your SoC, the SoC
> > > might be busy doing other stuff, like booting, and no one might be
> > > driving the RST_N voltage to a defined state.
> > 
> > I suspect you're reading too much into the datasheet there.  I suspect
> > that what it's trying to say is that the reset signal only works with
> > stable power and clocks, that it must be held low for the 5us while
> > those conditions hold and that you have to do at least one cold reset
> > after power on.  The above wording is pretty common in datasheets and I
> > know in a bunch of cases it was carried forward kind of blindly rather
> > than looking at the actual device requirements.
> 
> No, it doesn't say that, and I had discussions with the application
> engineering team for this chip about this :-/
> 
> I can't comment on anything extrapolated outside of the SJA1105/SJA1110.
> 
> > > It really depends on a lot of factors including the reset timing and
> > > supply voltage distribution of the PCB, but RST_N has essentially 2
> > > purposes. One is ensuring proper POR sequencing, the other is cold
> > > resetting at runtime. You can do the latter over SPI with identical
> > > outcome, which leaves proper POR sequencing, which is not best served by
> > > a GPIO in my experience.
> > 
> > I'm not sure not including the signal in the DT bindings is going to
> > influence board designers much either way TBH.
> 
> Either way, something has to nudge at least the software developer
> towards finding and reading the vendor's relevant documentation.
> 
> In that sense, 'reset-gpios' is misleading to say the least, because
> everyone sees a reset GPIO and has the human tendency to think there
> isn't anything more to be known about it (like I also did).
> 
> To be clear, I'm saying that supporting 'reset-gpios' in this driver was
> a mistake, at least in the form where its supplies and clocks aren't
> also under control. I'm not sure it's a mistake that we need to document,
> and if we do, there need to be a lot more disclaimers. Also, I'm pretty
> sure nothing will break if driver support for it is simply removed.

IMHO silently removing the support will break designs for sure and
should never be done. As said, imagine that the firmware will handle the
supplies and the driver only needs to release the reset. If you silently
remove the support, the device will be kept in reset-state. In field
firmware updates are seldom, so you break your device by updating to a
new kernel.

One could argue that the driver supported it but there was no dt-binding
yet, so it was a hidden/unstable feature but I don't know the policy.

Regards,
  Marco

Re: [PATCH 1/4] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property

[Vladimir Oltean]

On Wed, Sep 10, 2025 at 05:53:59PM +0200, Marco Felsch wrote:
> IMHO silently removing the support will break designs for sure and
> should never be done. As said, imagine that the firmware will handle the
> supplies and the driver only needs to release the reset. If you silently
> remove the support, the device will be kept in reset-state. In field
> firmware updates are seldom, so you break your device by updating to a
> new kernel.
> 
> One could argue that the driver supported it but there was no dt-binding
> yet, so it was a hidden/unstable feature but I don't know the policy.

Ok, I didn't think about, or meet, the case where Linux is required by
previous boot stages to deassert the reset. It is the first time you are
explicitly saying this, though.

So we can keep and document the 'reset-gpios' support, but we need to
explicitly point out that if present, it does not supplant the need to
ensure the proper POR sequence as per AH1704.

Re: [PATCH 1/4] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property

[Marco Felsch]

On 25-09-10, Vladimir Oltean wrote:
> On Wed, Sep 10, 2025 at 05:53:59PM +0200, Marco Felsch wrote:
> > IMHO silently removing the support will break designs for sure and
> > should never be done. As said, imagine that the firmware will handle the
> > supplies and the driver only needs to release the reset. If you silently
> > remove the support, the device will be kept in reset-state. In field
> > firmware updates are seldom, so you break your device by updating to a
> > new kernel.
> > 
> > One could argue that the driver supported it but there was no dt-binding
> > yet, so it was a hidden/unstable feature but I don't know the policy.
> 
> Ok, I didn't think about, or meet, the case where Linux is required by
> previous boot stages to deassert the reset. It is the first time you are
> explicitly saying this, though.
> 
> So we can keep and document the 'reset-gpios' support, but we need to
> explicitly point out that if present, it does not supplant the need to
> ensure the proper POR sequence as per AH1704.

We could do that but I think that no one should assume that the driver
ensures this due to the missing power-supply and clock support. But this
goes to the DT maintainers. IMHO we shouldn't mention any document
within the binding, maybe within the commit message, since those
documents may get removed.

Regards,
  Marco

Re: [PATCH 1/4] dt-bindings: net: dsa: nxp,sja1105: Add reset-gpios property

[Rob Herring]

On Wed, Sep 10, 2025 at 06:55:18PM +0200, Marco Felsch wrote:
> On 25-09-10, Vladimir Oltean wrote:
> > On Wed, Sep 10, 2025 at 05:53:59PM +0200, Marco Felsch wrote:
> > > IMHO silently removing the support will break designs for sure and
> > > should never be done. As said, imagine that the firmware will handle the
> > > supplies and the driver only needs to release the reset. If you silently
> > > remove the support, the device will be kept in reset-state. In field
> > > firmware updates are seldom, so you break your device by updating to a
> > > new kernel.
> > > 
> > > One could argue that the driver supported it but there was no dt-binding
> > > yet, so it was a hidden/unstable feature but I don't know the policy.
> > 
> > Ok, I didn't think about, or meet, the case where Linux is required by
> > previous boot stages to deassert the reset. It is the first time you are
> > explicitly saying this, though.
> > 
> > So we can keep and document the 'reset-gpios' support, but we need to
> > explicitly point out that if present, it does not supplant the need to
> > ensure the proper POR sequence as per AH1704.
> 
> We could do that but I think that no one should assume that the driver
> ensures this due to the missing power-supply and clock support. But this
> goes to the DT maintainers. IMHO we shouldn't mention any document
> within the binding, maybe within the commit message, since those
> documents may get removed.

We probably have lots of dead links... So what's one more possible one. 
If the information is useful, then I'd put the link there.

Rob

Re: [PATCH 2/4] ASoC: dt-bindings: asahi-kasei,ak4458: Reference common DAI properties

[Rob Herring (Arm)]

On Wed, 10 Sep 2025 14:35:22 +0200, Jonas Rebmann wrote:
> Reference the dai-common.yaml schema to allow '#sound-dai-cells' and
> "sound-name-prefix' to be used.
> 
> Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
> ---
>  Documentation/devicetree/bindings/sound/asahi-kasei,ak4458.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH 3/4] dt-bindings: arm: fsl: Add Protonic PRT8ML

[Rob Herring (Arm)]

On Wed, 10 Sep 2025 14:35:23 +0200, Jonas Rebmann wrote:
> Add DT compatible string for Protonic PRT8ML board.
> 
> Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
> ---
>  Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>

Re: (subset) [PATCH 0/4] Mainline Protonic PRT8ML board

[Mark Brown]

On Wed, 10 Sep 2025 14:35:20 +0200, Jonas Rebmann wrote:
> This series adds the Protonic PRT8ML device tree as well as some minor
> corrections to the devicetree bindings used.
> 
> 

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[2/4] ASoC: dt-bindings: asahi-kasei,ak4458: Reference common DAI properties
      commit: 8d7de4a014f589c1776959f7fdadbf7b12045aac

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark