[PATCH 0/2] Add i.MX952 FRDM board support

[PATCH 0/2] Add i.MX952 FRDM board support

[Joseph Guo]

i.MX952 FRDM Board is a low-cost and compact board featuring the i.MX952
application processor.
Add dt-bindings and basic device tree for i.MX952 FRDM board.

Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
---
Joseph Guo (2):
      dt-bindings: arm: fsl: add i.MX952 FRDM board
      arm64: dts: freescale: add i.MX952 FRDM Board support device tree

 Documentation/devicetree/bindings/arm/fsl.yaml |   1 +
 arch/arm64/boot/dts/freescale/Makefile         |   2 +
 arch/arm64/boot/dts/freescale/imx952-frdm.dts  |   9 +
 arch/arm64/boot/dts/freescale/imx952-frdm.dtsi | 727 +++++++++++++++++++++++++
 4 files changed, 739 insertions(+)
---
base-commit: 139fb260e37938042c6ffaad796e236fde2bafed
change-id: 20260717-imx952_frdm-e8fb415ae4d4

Best regards,
-- 
Joseph Guo <qijian.guo@nxp.com>

[PATCH 1/2] dt-bindings: arm: fsl: add i.MX952 FRDM board

[Joseph Guo]

Add DT compatible string for NXP i.MX952 FRDM board.

Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
---
 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 7b57a6ee1b50dc22ece292d6d9b53b5aa834ee96..f67b3f6d57d3623d41364f852a64802ad2217560 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1536,6 +1536,7 @@ properties:
         items:
           - enum:
               - fsl,imx952-evk            # i.MX952 EVK Board
+              - fsl,imx952-frdm           # i.MX952 FRDM Board
           - const: fsl,imx952
 
       - description: PHYTEC i.MX 95 FPSC based Boards

-- 
2.34.1

[PATCH 2/2] arm64: dts: freescale: add i.MX952 FRDM Board support device tree

[Joseph Guo]

Add basic device tree support for i.MX952 FRDM Board.

The board-common hardware description is placed in imx952-frdm.dtsi
so that it can be shared with future i.MX952-based FRDM derivative
boards.

The following peripherals are enabled:
- LPUART1 (console), LPUART5 (BT)
- USDHC1, USDHC2, USDHC3,
- FlexCAN2, FlexCAN3,
- USB1, USB2,
- LPI2C2, LPI2C4
- WDOG3
- MICFIL (PDM)
- LPSPI3

Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
---
 arch/arm64/boot/dts/freescale/Makefile         |   2 +
 arch/arm64/boot/dts/freescale/imx952-frdm.dts  |   9 +
 arch/arm64/boot/dts/freescale/imx952-frdm.dtsi | 727 +++++++++++++++++++++++++
 3 files changed, 738 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index be3c858f1eeb1a807cb8ac36269c581143f755df..a9554dfc785fc43305ad45bb0b80772041e91737 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -702,6 +702,8 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-verdin-evk.dtb
 
 dtb-$(CONFIG_ARCH_MXC) += imx952-evk.dtb
 
+dtb-$(CONFIG_ARCH_MXC) += imx952-frdm.dtb
+
 imx8mm-kontron-dl-dtbs			:= imx8mm-kontron-bl.dtb imx8mm-kontron-dl.dtbo
 imx8mm-kontron-bl-lte-dtbs		:= imx8mm-kontron-bl.dtb imx8mm-kontron-bl-lte.dtbo
 
diff --git a/arch/arm64/boot/dts/freescale/imx952-frdm.dts b/arch/arm64/boot/dts/freescale/imx952-frdm.dts
new file mode 100644
index 0000000000000000000000000000000000000000..0b9d74eea37668b455b945b25feb7d9c4fa5a439
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx952-frdm.dts
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+/dts-v1/;
+
+#include "imx952.dtsi"
+#include "imx952-frdm.dtsi"
diff --git a/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi b/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
new file mode 100644
index 0000000000000000000000000000000000000000..b9ef6bec2bd5af522bb63f0244379524000957c8
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
@@ -0,0 +1,727 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+#include <dt-bindings/usb/pd.h>
+
+#define BRD_SM_CTRL_SD3_WAKE		0x8000U /*!< PCAL6408A-0 */
+#define BRD_SM_CTRL_M2M_WAKE		0x8003U /*!< PCAL6408A-6 */
+#define BRD_SM_CTRL_BUTTON		0x8004U /*!< PCAL6408A-7 */
+
+/ {
+	compatible = "fsl,imx952-frdm", "fsl,imx952";
+	model = "NXP i.MX952 FRDM board";
+
+	aliases {
+		gpio0 = &gpio1;
+		gpio1 = &gpio2;
+		gpio2 = &gpio3;
+		gpio3 = &gpio4;
+		gpio4 = &gpio5;
+		i2c0 = &lpi2c1;
+		i2c1 = &lpi2c2;
+		i2c2 = &lpi2c3;
+		i2c3 = &lpi2c4;
+		i2c4 = &lpi2c5;
+		i2c5 = &lpi2c6;
+		i2c6 = &lpi2c7;
+		i2c7 = &lpi2c8;
+		mmc0 = &usdhc1;
+		mmc1 = &usdhc2;
+		serial0 = &lpuart1;
+		serial4 = &lpuart5;
+		spi2 = &lpspi3;
+	};
+
+	bt_sco_codec: audio-codec-bt-sco {
+		compatible = "linux,bt-sco";
+		#sound-dai-cells = <1>;
+	};
+
+	chosen {
+		stdout-path = &lpuart1;
+	};
+
+	dmic: dmic {
+		compatible = "dmic-codec";
+		#sound-dai-cells = <0>;
+		num-channels = <2>;
+	};
+
+	flexcan2_phy: can-phy0 {
+		compatible = "nxp,tja1051";
+		#phy-cells = <0>;
+		max-bitrate = <8000000>;
+		silent-gpios = <&pcal6416 6 GPIO_ACTIVE_HIGH>;
+	};
+
+	flexcan3_phy: can-phy1 {
+		compatible = "nxp,tja1051";
+		#phy-cells = <0>;
+		max-bitrate = <8000000>;
+		silent-gpios = <&pcal6416 6 GPIO_ACTIVE_HIGH>;
+	};
+
+	reg_1p8v: regulator-1p8v {
+		compatible = "regulator-fixed";
+		regulator-name = "+V1.8_SW";
+		regulator-max-microvolt = <1800000>;
+		regulator-min-microvolt = <1800000>;
+	};
+
+	reg_3p3v: regulator-3p3v {
+		compatible = "regulator-fixed";
+		regulator-name = "+V3.3_SW";
+		regulator-max-microvolt = <3300000>;
+		regulator-min-microvolt = <3300000>;
+	};
+
+	reg_5p0v: regulator-5p0v {
+		compatible = "regulator-fixed";
+		regulator-name = "+V5.0_SW";
+		regulator-max-microvolt = <5000000>;
+		regulator-min-microvolt = <5000000>;
+	};
+
+	reg_vref_1v8: regulator-adc-vref {
+		compatible = "regulator-fixed";
+		regulator-name = "vref_1v8";
+		regulator-max-microvolt = <1800000>;
+		regulator-min-microvolt = <1800000>;
+	};
+
+	reg_dummy: regulator-dummy {
+		compatible = "regulator-fixed";
+		regulator-name = "dummy";
+	};
+
+	reg_ext_12v: regulator-ext-12v {
+		compatible = "regulator-fixed";
+		regulator-name = "VCCEXT_12V";
+		regulator-max-microvolt = <12000000>;
+		regulator-min-microvolt = <12000000>;
+		vin-supply = <&reg_ext_5v>;
+	};
+
+	reg_ext_3v3: regulator-ext-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "VCCEXT_3V3";
+		regulator-max-microvolt = <3300000>;
+		regulator-min-microvolt = <3300000>;
+		gpio = <&pcal6416 13 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		regulator-always-on;
+	};
+
+	reg_ext_5v: regulator-ext-5v {
+		compatible = "regulator-fixed";
+		regulator-name = "VCCEXT_5V";
+		regulator-max-microvolt = <5000000>;
+		regulator-min-microvolt = <5000000>;
+		gpio = <&pcal6416 12 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		regulator-always-on;
+	};
+
+	reg_m2_pwr: regulator-m2-pwr {
+		compatible = "regulator-fixed";
+		regulator-name = "M.2-power";
+		regulator-max-microvolt = <3300000>;
+		regulator-min-microvolt = <3300000>;
+		gpio = <&pcal6416 11 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	reg_usdhc2_vmmc: regulator-usdhc2 {
+		compatible = "regulator-fixed";
+		regulator-name = "VDD_SD2_3V3";
+		off-on-delay-us = <12000>;
+		pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+		pinctrl-names = "default";
+		regulator-max-microvolt = <3300000>;
+		regulator-min-microvolt = <3300000>;
+		gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	reg_usdhc3_vmmc: regulator-usdhc3 {
+		compatible = "regulator-fixed";
+		regulator-name = "WLAN_EN";
+		regulator-max-microvolt = <3300000>;
+		regulator-min-microvolt = <3300000>;
+		vin-supply = <&reg_m2_pwr>;
+		gpio = <&pcal6416 9 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		/*
+		 * IW612 wifi chip needs more delay than other wifi chips to complete
+		 * the host interface initialization after power up, otherwise the
+		 * internal state of IW612 may be unstable, resulting in the failure of
+		 * the SDIO3.0 switch voltage.
+		 */
+		startup-delay-us = <20000>;
+	};
+
+	reg_usb_vbus: regulator-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "USB_VBUS";
+		regulator-max-microvolt = <5000000>;
+		regulator-min-microvolt = <5000000>;
+		gpio = <&pcal6416 15 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	reserved-memory {
+		ranges;
+		#address-cells = <2>;
+		#size-cells = <2>;
+
+		linux_cma: linux,cma {
+			compatible = "shared-dma-pool";
+			alloc-ranges = <0 0x80000000 0 0x7f000000>;
+			reusable;
+			size = <0 0x3c000000>;
+			linux,cma-default;
+		};
+	};
+
+	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 {
+			format = "i2s";
+			link-name = "micfil hifi";
+
+			codec {
+				sound-dai = <&dmic>;
+			};
+
+			cpu {
+				sound-dai = <&micfil>;
+			};
+		};
+	};
+
+	usdhc3_pwrseq: usdhc3-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		reset-gpios = <&pcal6416 8 GPIO_ACTIVE_LOW>;
+	};
+
+	memory@80000000 {
+		device_type = "memory";
+		reg = <0x0 0x80000000 0 0x80000000>;
+	};
+};
+
+&adc1 {
+	vref-supply = <&reg_vref_1v8>;
+	status = "okay";
+};
+
+&asrc1 {
+	assigned-clocks = <&scmi_clk IMX952_CLK_AUDIOPLL1_VCO>,
+			  <&scmi_clk IMX952_CLK_AUDIOPLL2_VCO>,
+			  <&scmi_clk IMX952_CLK_AUDIOPLL1>,
+			  <&scmi_clk IMX952_CLK_AUDIOPLL2>,
+			  <&scmi_clk IMX952_CLK_ASRC1>;
+	assigned-clock-parents = <0>, <0>, <0>, <0>,
+				 <&scmi_clk IMX952_CLK_AUDIOPLL1>;
+	assigned-clock-rates = <3932160000>, <3612672000>,
+			       <393216000>, <361267200>, <49152000>;
+	fsl,asrc-rate = <48000>;
+	status = "okay";
+};
+
+&asrc2 {
+	assigned-clocks = <&scmi_clk IMX952_CLK_AUDIOPLL1_VCO>,
+			  <&scmi_clk IMX952_CLK_AUDIOPLL2_VCO>,
+			  <&scmi_clk IMX952_CLK_AUDIOPLL1>,
+			  <&scmi_clk IMX952_CLK_AUDIOPLL2>,
+			  <&scmi_clk IMX952_CLK_ASRC2>;
+	assigned-clock-parents = <0>, <0>, <0>, <0>,
+				 <&scmi_clk IMX952_CLK_AUDIOPLL1>;
+	assigned-clock-rates = <3932160000>, <3612672000>,
+			       <393216000>, <361267200>, <49152000>;
+	fsl,asrc-rate = <48000>;
+	status = "okay";
+};
+
+&flexcan2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan2>;
+	phys = <&flexcan2_phy>;
+	status = "okay";
+};
+
+&flexcan3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan3>;
+	phys = <&flexcan3_phy>;
+	status = "okay";
+};
+
+&lpi2c2 {
+	clock-frequency = <400000>;
+	pinctrl-0 = <&pinctrl_lpi2c2>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	pcal6416: gpio@20 {
+		compatible = "nxp,pcal6416";
+		reg = <0x20>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		interrupt-parent = <&gpio5>;
+		interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+		#gpio-cells = <2>;
+		gpio-controller;
+		pinctrl-0 = <&pinctrl_pcal6416>;
+		pinctrl-names = "default";
+		vcc-supply = <&reg_3p3v>;
+
+		/* When low, select CAN; When high, select gpio. */
+		can-gpio-sel-hog {
+			gpios = <4 GPIO_ACTIVE_HIGH>;
+			gpio-hog;
+			output-low;
+		};
+	};
+};
+
+&lpi2c4 {
+	clock-frequency = <400000>;
+	pinctrl-0 = <&pinctrl_lpi2c4>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	ptn5110: tcpc@50 {
+		compatible = "nxp,ptn5110", "tcpci";
+		reg = <0x50>;
+		interrupt-parent = <&gpio5>;
+		interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-0 = <&pinctrl_ptn5110>;
+		pinctrl-names = "default";
+
+		typec_con: connector {
+			compatible = "usb-c-connector";
+			data-role = "dual";
+			label = "USB-C";
+			op-sink-microwatt = <0>;
+			power-role = "dual";
+			self-powered;
+			sink-pdos = <PDO_FIXED(5000, 0, PDO_FIXED_USB_COMM)>;
+			source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+			try-power-role = "sink";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+
+					typec1_dr_sw: endpoint {
+						remote-endpoint = <&usb1_drd_sw>;
+					};
+				};
+			};
+		};
+	};
+};
+
+&lpspi3 {
+	cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>;
+	pinctrl-0 = <&pinctrl_lpspi3>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&lpuart1 {
+	/* console */
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+	status = "okay";
+};
+
+&lpuart5 {
+	/* BT */
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart5>;
+	status = "okay";
+
+	bluetooth {
+		compatible = "nxp,88w8987-bt";
+	};
+};
+
+&micfil {
+	assigned-clocks = <&scmi_clk IMX952_CLK_AUDIOPLL1_VCO>,
+			  <&scmi_clk IMX952_CLK_AUDIOPLL2_VCO>,
+			  <&scmi_clk IMX952_CLK_AUDIOPLL1>,
+			  <&scmi_clk IMX952_CLK_AUDIOPLL2>,
+			  <&scmi_clk IMX952_CLK_PDM>;
+	assigned-clock-parents = <0>, <0>, <0>, <0>,
+				<&scmi_clk IMX952_CLK_AUDIOPLL1>;
+	assigned-clock-rates = <3932160000>, <3612672000>,
+			       <393216000>, <361267200>, <49152000>;
+	pinctrl-0 = <&pinctrl_pdm>;
+	pinctrl-1 = <&pinctrl_pdm_sleep>;
+	pinctrl-names = "default", "sleep";
+	status = "okay";
+};
+
+&sai5 {
+	assigned-clocks = <&scmi_clk IMX952_CLK_AUDIOPLL1_VCO>,
+			  <&scmi_clk IMX952_CLK_AUDIOPLL2_VCO>,
+			  <&scmi_clk IMX952_CLK_AUDIOPLL1>,
+			  <&scmi_clk IMX952_CLK_AUDIOPLL2>,
+			  <&scmi_clk IMX952_CLK_SAI5>;
+	assigned-clock-parents = <0>, <0>, <0>, <0>, <&scmi_clk IMX952_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";
+};
+
+&scmi_iomuxc {
+	pinctrl_flexcan2: flexcan2grp {
+		fsl,pins = <
+			IMX952_PAD_GPIO_IO25__WAKEUPMIX_TOP_CAN2_TX		0x39e
+			IMX952_PAD_GPIO_IO27__WAKEUPMIX_TOP_CAN2_RX		0x39e
+		>;
+	};
+
+	pinctrl_flexcan3: flexcan3grp {
+		fsl,pins = <
+			IMX952_PAD_CCM_CLKO3__WAKEUPMIX_TOP_CAN3_TX		0x39e
+			IMX952_PAD_CCM_CLKO4__WAKEUPMIX_TOP_CAN3_RX		0x39e
+		>;
+	};
+
+	pinctrl_lpi2c2: lpi2c2grp {
+		fsl,pins = <
+			IMX952_PAD_I2C2_SCL__AONMIX_TOP_LPI2C2_SCL		0x40000b9e
+			IMX952_PAD_I2C2_SDA__AONMIX_TOP_LPI2C2_SDA		0x40000b9e
+		>;
+	};
+
+	pinctrl_lpi2c4: lpi2c4grp {
+		fsl,pins = <
+			IMX952_PAD_GPIO_IO30__WAKEUPMIX_TOP_LPI2C4_SDA		0x40000b9e
+			IMX952_PAD_GPIO_IO31__WAKEUPMIX_TOP_LPI2C4_SCL		0x40000b9e
+		>;
+	};
+
+	pinctrl_lpspi3: lpspi3grp {
+		fsl,pins = <
+			IMX952_PAD_GPIO_IO08__WAKEUPMIX_TOP_GPIO2_IO_8		0x39e
+			IMX952_PAD_GPIO_IO09__WAKEUPMIX_TOP_LPSPI3_SIN		0x39e
+			IMX952_PAD_GPIO_IO10__WAKEUPMIX_TOP_LPSPI3_SOUT		0x39e
+			IMX952_PAD_GPIO_IO11__WAKEUPMIX_TOP_LPSPI3_SCK		0x39e
+		>;
+	};
+
+	pinctrl_pcal6416: pcal6416grp {
+		fsl,pins = <
+			IMX952_PAD_GPIO_IO34__WAKEUPMIX_TOP_GPIO5_IO_14		0x31e
+		>;
+	};
+
+	pinctrl_pdm: pdmgrp {
+		fsl,pins = <
+			IMX952_PAD_PDM_CLK__AONMIX_TOP_PDM_CLK				0x31e
+			IMX952_PAD_PDM_BIT_STREAM0__AONMIX_TOP_PDM_BIT_STREAM_0		0x31e
+		>;
+	};
+
+	pinctrl_pdm_sleep: pdmsleepgrp {
+		fsl,pins = <
+			IMX952_PAD_PDM_CLK__AONMIX_TOP_GPIO1_IO_8		0x31e
+			IMX952_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_9	0x31e
+		>;
+	};
+
+	pinctrl_ptn5110: ptn5110grp {
+		fsl,pins = <
+			IMX952_PAD_XSPI1_DATA2__WAKEUPMIX_TOP_GPIO5_IO_2	0x31e
+		>;
+	};
+
+	pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+		fsl,pins = <
+			IMX952_PAD_SD2_RESET_B__WAKEUPMIX_TOP_GPIO3_IO_7	0x31e
+		>;
+	};
+
+	pinctrl_sai5: sai5grp {
+		fsl,pins = <
+			IMX952_PAD_XSPI1_DATA4__WAKEUPMIX_TOP_SAI5_TX_DATA_0		0x31e
+			IMX952_PAD_XSPI1_DATA5__WAKEUPMIX_TOP_SAI5_TX_SYNC		0x31e
+			IMX952_PAD_XSPI1_DATA6__WAKEUPMIX_TOP_SAI5_TX_BCLK		0x31e
+			IMX952_PAD_XSPI1_DATA7__WAKEUPMIX_TOP_SAI5_RX_DATA_0		0x31e
+		>;
+	};
+
+	pinctrl_tpm3: tpm3grp {
+		fsl,pins = <
+			IMX952_PAD_GPIO_IO04__WAKEUPMIX_TOP_TPM3_CH0		0x51e
+			IMX952_PAD_GPIO_IO12__WAKEUPMIX_TOP_TPM3_CH2		0x51e
+		>;
+	};
+
+	pinctrl_tpm4: tpm4grp {
+		fsl,pins = <
+			IMX952_PAD_GPIO_IO13__WAKEUPMIX_TOP_TPM4_CH2		0x51e
+		>;
+	};
+
+	pinctrl_uart1: uart1grp {
+		fsl,pins = <
+			IMX952_PAD_UART1_RXD__AONMIX_TOP_LPUART1_RX		0x31e
+			IMX952_PAD_UART1_TXD__AONMIX_TOP_LPUART1_TX		0x31e
+		>;
+	};
+
+	pinctrl_uart5: uart5grp {
+		fsl,pins = <
+			IMX952_PAD_DAP_TDO_TRACESWO__WAKEUPMIX_TOP_LPUART5_TX	0x31e
+			IMX952_PAD_DAP_TDI__WAKEUPMIX_TOP_LPUART5_RX		0x31e
+			IMX952_PAD_DAP_TMS_SWDIO__WAKEUPMIX_TOP_LPUART5_RTS_B	0x31e
+			IMX952_PAD_DAP_TCLK_SWCLK__WAKEUPMIX_TOP_LPUART5_CTS_B	0x31e
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			IMX952_PAD_SD1_CLK__WAKEUPMIX_TOP_USDHC1_CLK		0x158e
+			IMX952_PAD_SD1_CMD__WAKEUPMIX_TOP_USDHC1_CMD		0x138e
+			IMX952_PAD_SD1_DATA0__WAKEUPMIX_TOP_USDHC1_DATA0	0x138e
+			IMX952_PAD_SD1_DATA1__WAKEUPMIX_TOP_USDHC1_DATA1	0x138e
+			IMX952_PAD_SD1_DATA2__WAKEUPMIX_TOP_USDHC1_DATA2	0x138e
+			IMX952_PAD_SD1_DATA3__WAKEUPMIX_TOP_USDHC1_DATA3	0x138e
+			IMX952_PAD_SD1_DATA4__WAKEUPMIX_TOP_USDHC1_DATA4	0x138e
+			IMX952_PAD_SD1_DATA5__WAKEUPMIX_TOP_USDHC1_DATA5	0x138e
+			IMX952_PAD_SD1_DATA6__WAKEUPMIX_TOP_USDHC1_DATA6	0x138e
+			IMX952_PAD_SD1_DATA7__WAKEUPMIX_TOP_USDHC1_DATA7	0x138e
+			IMX952_PAD_SD1_STROBE__WAKEUPMIX_TOP_USDHC1_STROBE	0x158e
+		>;
+	};
+
+	pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+		fsl,pins = <
+			IMX952_PAD_SD1_CLK__WAKEUPMIX_TOP_USDHC1_CLK		0x158e
+			IMX952_PAD_SD1_CMD__WAKEUPMIX_TOP_USDHC1_CMD		0x138e
+			IMX952_PAD_SD1_DATA0__WAKEUPMIX_TOP_USDHC1_DATA0	0x138e
+			IMX952_PAD_SD1_DATA1__WAKEUPMIX_TOP_USDHC1_DATA1	0x138e
+			IMX952_PAD_SD1_DATA2__WAKEUPMIX_TOP_USDHC1_DATA2	0x138e
+			IMX952_PAD_SD1_DATA3__WAKEUPMIX_TOP_USDHC1_DATA3	0x138e
+			IMX952_PAD_SD1_DATA4__WAKEUPMIX_TOP_USDHC1_DATA4	0x138e
+			IMX952_PAD_SD1_DATA5__WAKEUPMIX_TOP_USDHC1_DATA5	0x138e
+			IMX952_PAD_SD1_DATA6__WAKEUPMIX_TOP_USDHC1_DATA6	0x138e
+			IMX952_PAD_SD1_DATA7__WAKEUPMIX_TOP_USDHC1_DATA7	0x138e
+			IMX952_PAD_SD1_STROBE__WAKEUPMIX_TOP_USDHC1_STROBE	0x158e
+		>;
+	};
+
+	pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+		fsl,pins = <
+			IMX952_PAD_SD1_CLK__WAKEUPMIX_TOP_USDHC1_CLK		0x159e
+			IMX952_PAD_SD1_CMD__WAKEUPMIX_TOP_USDHC1_CMD		0x139e
+			IMX952_PAD_SD1_DATA0__WAKEUPMIX_TOP_USDHC1_DATA0	0x139e
+			IMX952_PAD_SD1_DATA1__WAKEUPMIX_TOP_USDHC1_DATA1	0x139e
+			IMX952_PAD_SD1_DATA2__WAKEUPMIX_TOP_USDHC1_DATA2	0x139e
+			IMX952_PAD_SD1_DATA3__WAKEUPMIX_TOP_USDHC1_DATA3	0x139e
+			IMX952_PAD_SD1_DATA4__WAKEUPMIX_TOP_USDHC1_DATA4	0x139e
+			IMX952_PAD_SD1_DATA5__WAKEUPMIX_TOP_USDHC1_DATA5	0x139e
+			IMX952_PAD_SD1_DATA6__WAKEUPMIX_TOP_USDHC1_DATA6	0x139e
+			IMX952_PAD_SD1_DATA7__WAKEUPMIX_TOP_USDHC1_DATA7	0x139e
+			IMX952_PAD_SD1_STROBE__WAKEUPMIX_TOP_USDHC1_STROBE	0x159e
+		>;
+	};
+
+	pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+		fsl,pins = <
+			IMX952_PAD_SD2_CD_B__WAKEUPMIX_TOP_GPIO3_IO_0		0x31e
+		>;
+	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			IMX952_PAD_SD2_CLK__WAKEUPMIX_TOP_USDHC2_CLK		0x158e
+			IMX952_PAD_SD2_CMD__WAKEUPMIX_TOP_USDHC2_CMD		0x138e
+			IMX952_PAD_SD2_DATA0__WAKEUPMIX_TOP_USDHC2_DATA0	0x138e
+			IMX952_PAD_SD2_DATA1__WAKEUPMIX_TOP_USDHC2_DATA1	0x138e
+			IMX952_PAD_SD2_DATA2__WAKEUPMIX_TOP_USDHC2_DATA2	0x138e
+			IMX952_PAD_SD2_DATA3__WAKEUPMIX_TOP_USDHC2_DATA3	0x138e
+			IMX952_PAD_SD2_VSELECT__WAKEUPMIX_TOP_USDHC2_VSELECT	0x51e
+		>;
+	};
+
+	pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+		fsl,pins = <
+			IMX952_PAD_SD2_CLK__WAKEUPMIX_TOP_USDHC2_CLK		0x158e
+			IMX952_PAD_SD2_CMD__WAKEUPMIX_TOP_USDHC2_CMD		0x138e
+			IMX952_PAD_SD2_DATA0__WAKEUPMIX_TOP_USDHC2_DATA0	0x138e
+			IMX952_PAD_SD2_DATA1__WAKEUPMIX_TOP_USDHC2_DATA1	0x138e
+			IMX952_PAD_SD2_DATA2__WAKEUPMIX_TOP_USDHC2_DATA2	0x138e
+			IMX952_PAD_SD2_DATA3__WAKEUPMIX_TOP_USDHC2_DATA3	0x138e
+			IMX952_PAD_SD2_VSELECT__WAKEUPMIX_TOP_USDHC2_VSELECT	0x51e
+		>;
+	};
+
+	pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+		fsl,pins = <
+			IMX952_PAD_SD2_CLK__WAKEUPMIX_TOP_USDHC2_CLK		0x158e
+			IMX952_PAD_SD2_CMD__WAKEUPMIX_TOP_USDHC2_CMD		0x138e
+			IMX952_PAD_SD2_DATA0__WAKEUPMIX_TOP_USDHC2_DATA0	0x138e
+			IMX952_PAD_SD2_DATA1__WAKEUPMIX_TOP_USDHC2_DATA1	0x138e
+			IMX952_PAD_SD2_DATA2__WAKEUPMIX_TOP_USDHC2_DATA2	0x138e
+			IMX952_PAD_SD2_DATA3__WAKEUPMIX_TOP_USDHC2_DATA3	0x138e
+			IMX952_PAD_SD2_VSELECT__WAKEUPMIX_TOP_USDHC2_VSELECT	0x51e
+		>;
+	};
+
+	pinctrl_usdhc3: usdhc3grp {
+		fsl,pins = <
+			IMX952_PAD_SD3_CLK__WAKEUPMIX_TOP_USDHC3_CLK			0x158e
+			IMX952_PAD_SD3_CMD__WAKEUPMIX_TOP_USDHC3_CMD			0x138e
+			IMX952_PAD_SD3_DATA0__WAKEUPMIX_TOP_USDHC3_DATA0		0x138e
+			IMX952_PAD_SD3_DATA1__WAKEUPMIX_TOP_USDHC3_DATA1		0x138e
+			IMX952_PAD_SD3_DATA2__WAKEUPMIX_TOP_USDHC3_DATA2		0x138e
+			IMX952_PAD_SD3_DATA3__WAKEUPMIX_TOP_USDHC3_DATA3		0x138e
+		>;
+	};
+
+	pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+		fsl,pins = <
+			IMX952_PAD_SD3_CLK__WAKEUPMIX_TOP_USDHC3_CLK			0x158e
+			IMX952_PAD_SD3_CMD__WAKEUPMIX_TOP_USDHC3_CMD			0x138e
+			IMX952_PAD_SD3_DATA0__WAKEUPMIX_TOP_USDHC3_DATA0		0x138e
+			IMX952_PAD_SD3_DATA1__WAKEUPMIX_TOP_USDHC3_DATA1		0x138e
+			IMX952_PAD_SD3_DATA2__WAKEUPMIX_TOP_USDHC3_DATA2		0x138e
+			IMX952_PAD_SD3_DATA3__WAKEUPMIX_TOP_USDHC3_DATA3		0x138e
+		>;
+	};
+
+	pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+		fsl,pins = <
+			IMX952_PAD_SD3_CLK__WAKEUPMIX_TOP_USDHC3_CLK			0x158e
+			IMX952_PAD_SD3_CMD__WAKEUPMIX_TOP_USDHC3_CMD			0x138e
+			IMX952_PAD_SD3_DATA0__WAKEUPMIX_TOP_USDHC3_DATA0		0x138e
+			IMX952_PAD_SD3_DATA1__WAKEUPMIX_TOP_USDHC3_DATA1		0x138e
+			IMX952_PAD_SD3_DATA2__WAKEUPMIX_TOP_USDHC3_DATA2		0x138e
+			IMX952_PAD_SD3_DATA3__WAKEUPMIX_TOP_USDHC3_DATA3		0x138e
+		>;
+	};
+};
+
+&scmi_misc {
+	nxp,ctrl-ids = <BRD_SM_CTRL_SD3_WAKE		1
+			BRD_SM_CTRL_M2M_WAKE		1
+			BRD_SM_CTRL_BUTTON		1>;
+};
+
+&tpm3 {
+	pinctrl-0 = <&pinctrl_tpm3>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&tpm4 {
+	pinctrl-0 = <&pinctrl_tpm4>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&usb1 {
+	adp-disable;
+	disable-over-current;
+	dr_mode = "otg";
+	hnp-disable;
+	srp-disable;
+	usb-role-switch;
+	samsung,picophy-dc-vol-level-adjust = <7>;
+	samsung,picophy-pre-emp-curr-control = <3>;
+	status = "okay";
+
+	port {
+		usb1_drd_sw: endpoint {
+			remote-endpoint = <&typec1_dr_sw>;
+		};
+	};
+};
+
+&usb2 {
+	disable-over-current;
+	dr_mode = "host";
+	vbus-supply = <&reg_usb_vbus>;
+	status = "okay";
+};
+
+&usdhc1 {
+	bus-width = <8>;
+	non-removable;
+	no-sd;
+	no-sdio;
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+	pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+	pinctrl-3 = <&pinctrl_usdhc1>;
+	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+	status = "okay";
+};
+
+&usdhc2 {
+	bus-width = <4>;
+	cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
+	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-3 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+	vmmc-supply = <&reg_usdhc2_vmmc>;
+	fsl,cd-gpio-wakeup-disable;
+	status = "okay";
+};
+
+&usdhc3 {
+	bus-width = <4>;
+	keep-power-in-suspend;
+	mmc-pwrseq = <&usdhc3_pwrseq>;
+	non-removable;
+	pinctrl-0 = <&pinctrl_usdhc3>;
+	pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+	pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+	pinctrl-3 = <&pinctrl_usdhc3>;
+	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+	vmmc-supply = <&reg_usdhc3_vmmc>;
+	wakeup-source;
+	status = "okay";
+};
+
+&wdog3 {
+	fsl,ext-reset-output;
+	status = "okay";
+};

-- 
2.34.1

Re: [PATCH 2/2] arm64: dts: freescale: add i.MX952 FRDM Board support device tree

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Shared GPIO requested exclusively by two CAN transceivers causes probe failure for the second transceiver.
- [Low] Use of undocumented, downstream-only device tree property `fsl,cd-gpio-wakeup-disable`.
--

--- Patch [2]: [PATCH 2/2] arm64: dts: freescale: add i.MX952 FRDM Board support device tree ---
commit 8bbcb28d08a05e0f4c57023333492b4e023f7caf
Author: Joseph Guo <qijian.guo@nxp.com>

arm64: dts: freescale: add i.MX952 FRDM Board support device tree

Add basic device tree support for i.MX952 FRDM Board. The board-common hardware
description is placed in imx952-frdm.dtsi so that it can be shared with future
i.MX952-based FRDM derivative boards.

> diff --git a/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi b/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
> new file mode 100644
> index 0000000000000..b9ef6bec2bd5a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
> @@ -0,0 +1,727 @@
[ ... ]
> +	flexcan2_phy: can-phy0 {
> +		compatible = "nxp,tja1051";
> +		#phy-cells = <0>;
> +		max-bitrate = <8000000>;
> +		silent-gpios = <&pcal6416 6 GPIO_ACTIVE_HIGH>;
> +	};
> +
> +	flexcan3_phy: can-phy1 {
> +		compatible = "nxp,tja1051";
> +		#phy-cells = <0>;
> +		max-bitrate = <8000000>;
> +		silent-gpios = <&pcal6416 6 GPIO_ACTIVE_HIGH>;

[Severity: High]
Does this cause a probe failure for the second transceiver?

The first PHY node successfully requests this GPIO line, taking exclusive
ownership. Because the phy-can-transceiver driver uses standard exclusive
requests (without GPIOD_FLAGS_BIT_NONEXCLUSIVE), the second request for the
exact same GPIO line fails with -EBUSY. 

This prevents the flexcan3_phy and the flexcan3 controller from probing and
functioning.

> +	};
[ ... ]
> +&usdhc2 {
> +	bus-width = <4>;
> +	cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
> +	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> +	pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
> +	pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
> +	pinctrl-3 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> +	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> +	vmmc-supply = <&reg_usdhc2_vmmc>;
> +	fsl,cd-gpio-wakeup-disable;

[Severity: Low]
Is this out-of-tree vendor property invalid in the upstream kernel?

The property fsl,cd-gpio-wakeup-disable does not exist in any upstream device
tree bindings (such as fsl-imx-esdhc.yaml) and is not handled by any driver
code in the upstream Linux tree. This acts as dead code and will trigger
`make dtbs_check` validation warnings.

> +	status = "okay";
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-imx952_frdm-v1-0-6d145eaaa5c4@nxp.com?part=2

Re: [EXT] Re: [PATCH 2/2] arm64: dts: freescale: add i.MX952 FRDM Board support device tree

[Joseph Guo]

On 7/20/2026 2:55 PM, sashiko-bot@kernel.org wrote:
> [You don't often get email from sashiko-bot@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button
> 
> 
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] Shared GPIO requested exclusively by two CAN transceivers causes probe failure for the second transceiver.
> - [Low] Use of undocumented, downstream-only device tree property `fsl,cd-gpio-wakeup-disable`.
> --
> 
> --- Patch [2]: [PATCH 2/2] arm64: dts: freescale: add i.MX952 FRDM Board support device tree ---
> commit 8bbcb28d08a05e0f4c57023333492b4e023f7caf
> Author: Joseph Guo <qijian.guo@nxp.com>
> 
> arm64: dts: freescale: add i.MX952 FRDM Board support device tree
> 
> Add basic device tree support for i.MX952 FRDM Board. The board-common hardware
> description is placed in imx952-frdm.dtsi so that it can be shared with future
> i.MX952-based FRDM derivative boards.
> 
>> diff --git a/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi b/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
>> new file mode 100644
>> index 0000000000000..b9ef6bec2bd5a
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
>> @@ -0,0 +1,727 @@
> [ ... ]
>> +     flexcan2_phy: can-phy0 {
>> +             compatible = "nxp,tja1051";
>> +             #phy-cells = <0>;
>> +             max-bitrate = <8000000>;
>> +             silent-gpios = <&pcal6416 6 GPIO_ACTIVE_HIGH>;
>> +     };
>> +
>> +     flexcan3_phy: can-phy1 {
>> +             compatible = "nxp,tja1051";
>> +             #phy-cells = <0>;
>> +             max-bitrate = <8000000>;
>> +             silent-gpios = <&pcal6416 6 GPIO_ACTIVE_HIGH>;
> 
> [Severity: High]
> Does this cause a probe failure for the second transceiver?
> 
> The first PHY node successfully requests this GPIO line, taking exclusive
> ownership. Because the phy-can-transceiver driver uses standard exclusive
> requests (without GPIOD_FLAGS_BIT_NONEXCLUSIVE), the second request for the
> exact same GPIO line fails with -EBUSY.
> 
> This prevents the flexcan3_phy and the flexcan3 controller from probing and
> functioning.
> 

This two CAN PHY did share same pin as their silent-gpio on hardware.

The same design on i.MX95 15x15 FRDM. This should be fine.

Regards,
Joseph

>> +     };
> [ ... ]
>> +&usdhc2 {
>> +     bus-width = <4>;
>> +     cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
>> +     pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
>> +     pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
>> +     pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
>> +     pinctrl-3 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
>> +     pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
>> +     vmmc-supply = <&reg_usdhc2_vmmc>;
>> +     fsl,cd-gpio-wakeup-disable;
> 
> [Severity: Low]
> Is this out-of-tree vendor property invalid in the upstream kernel?
> 
> The property fsl,cd-gpio-wakeup-disable does not exist in any upstream device
> tree bindings (such as fsl-imx-esdhc.yaml) and is not handled by any driver
> code in the upstream Linux tree. This acts as dead code and will trigger
> `make dtbs_check` validation warnings.
> 
>> +     status = "okay";
>> +};
> 
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260720-imx952_frdm-v1-0-6d145eaaa5c4@nxp.com?part=2

-- 
Best Regards,
Joseph

Re: [EXT] Re: [PATCH 2/2] arm64: dts: freescale: add i.MX952 FRDM Board support device tree

[Frank Li]

On Mon, Jul 20, 2026 at 03:03:20PM +0800, Joseph Guo wrote:
> On 7/20/2026 2:55 PM, sashiko-bot@kernel.org wrote:
> > [You don't often get email from sashiko-bot@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button
> >
> >
> > Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> > - [High] Shared GPIO requested exclusively by two CAN transceivers causes probe failure for the second transceiver.
> > - [Low] Use of undocumented, downstream-only device tree property `fsl,cd-gpio-wakeup-disable`.
> > --
> >
> > --- Patch [2]: [PATCH 2/2] arm64: dts: freescale: add i.MX952 FRDM Board support device tree ---
> > commit 8bbcb28d08a05e0f4c57023333492b4e023f7caf
> > Author: Joseph Guo <qijian.guo@nxp.com>
> >
> > arm64: dts: freescale: add i.MX952 FRDM Board support device tree
> >
> > Add basic device tree support for i.MX952 FRDM Board. The board-common hardware
> > description is placed in imx952-frdm.dtsi so that it can be shared with future
> > i.MX952-based FRDM derivative boards.
> >
> >> diff --git a/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi b/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
> >> new file mode 100644
> >> index 0000000000000..b9ef6bec2bd5a
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
> >> @@ -0,0 +1,727 @@
> > [ ... ]
> >> +     flexcan2_phy: can-phy0 {
> >> +             compatible = "nxp,tja1051";
> >> +             #phy-cells = <0>;
> >> +             max-bitrate = <8000000>;
> >> +             silent-gpios = <&pcal6416 6 GPIO_ACTIVE_HIGH>;
> >> +     };
> >> +
> >> +     flexcan3_phy: can-phy1 {
> >> +             compatible = "nxp,tja1051";
> >> +             #phy-cells = <0>;
> >> +             max-bitrate = <8000000>;
> >> +             silent-gpios = <&pcal6416 6 GPIO_ACTIVE_HIGH>;
> >
> > [Severity: High]
> > Does this cause a probe failure for the second transceiver?
> >
> > The first PHY node successfully requests this GPIO line, taking exclusive
> > ownership. Because the phy-can-transceiver driver uses standard exclusive
> > requests (without GPIOD_FLAGS_BIT_NONEXCLUSIVE), the second request for the
> > exact same GPIO line fails with -EBUSY.
> >
> > This prevents the flexcan3_phy and the flexcan3 controller from probing and
> > functioning.
> >
>
> This two CAN PHY did share same pin as their silent-gpio on hardware.

Hardware share gpio, but driver may not handle this case. Are you sure

flexcan3_phy probed if can-phy0 already probed?

Frank

>
> The same design on i.MX95 15x15 FRDM. This should be fine.
>
> Regards,
> Joseph
>
> >> +     };
> > [ ... ]
> >> +&usdhc2 {
> >> +     bus-width = <4>;
> >> +     cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
> >> +     pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> >> +     pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
> >> +     pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
> >> +     pinctrl-3 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> >> +     pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> >> +     vmmc-supply = <&reg_usdhc2_vmmc>;
> >> +     fsl,cd-gpio-wakeup-disable;
> >
> > [Severity: Low]
> > Is this out-of-tree vendor property invalid in the upstream kernel?
> >
> > The property fsl,cd-gpio-wakeup-disable does not exist in any upstream device
> > tree bindings (such as fsl-imx-esdhc.yaml) and is not handled by any driver
> > code in the upstream Linux tree. This acts as dead code and will trigger
> > `make dtbs_check` validation warnings.
> >
> >> +     status = "okay";
> >> +};
> >
> > --
> > Sashiko AI review · https://sashiko.dev/#/patchset/20260720-imx952_frdm-v1-0-6d145eaaa5c4@nxp.com?part=2
>
> --
> Best Regards,
> Joseph

RE: [EXT] Re: [PATCH 2/2] arm64: dts: freescale: add i.MX952 FRDM Board support device tree

[Joseph Guo]

> 
> On Mon, Jul 20, 2026 at 03:03:20PM +0800, Joseph Guo wrote:
> > On 7/20/2026 2:55 PM, sashiko-bot@kernel.org wrote:
> > > [You don't often get email from sashiko-bot@kernel.org. Learn why
> > > this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > Caution: This is an external email. Please take care when clicking
> > > links or opening attachments. When in doubt, report the message
> > > using the 'Report this email' button
> > >
> > >
> > > Thank you for your contribution! Sashiko AI review found 2 potential
> issue(s) to consider:
> > > - [High] Shared GPIO requested exclusively by two CAN transceivers
> causes probe failure for the second transceiver.
> > > - [Low] Use of undocumented, downstream-only device tree property
> `fsl,cd-gpio-wakeup-disable`.
> > > --
> > >
> > > --- Patch [2]: [PATCH 2/2] arm64: dts: freescale: add i.MX952 FRDM
> > > Board support device tree --- commit
> > > 8bbcb28d08a05e0f4c57023333492b4e023f7caf
> > > Author: Joseph Guo <qijian.guo@nxp.com>
> > >
> > > arm64: dts: freescale: add i.MX952 FRDM Board support device tree
> > >
> > > Add basic device tree support for i.MX952 FRDM Board. The
> > > board-common hardware description is placed in imx952-frdm.dtsi so
> > > that it can be shared with future i.MX952-based FRDM derivative boards.
> > >
> > >> diff --git a/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
> > >> b/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
> > >> new file mode 100644
> > >> index 0000000000000..b9ef6bec2bd5a
> > >> --- /dev/null
> > >> +++ b/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
> > >> @@ -0,0 +1,727 @@
> > > [ ... ]
> > >> +     flexcan2_phy: can-phy0 {
> > >> +             compatible = "nxp,tja1051";
> > >> +             #phy-cells = <0>;
> > >> +             max-bitrate = <8000000>;
> > >> +             silent-gpios = <&pcal6416 6 GPIO_ACTIVE_HIGH>;
> > >> +     };
> > >> +
> > >> +     flexcan3_phy: can-phy1 {
> > >> +             compatible = "nxp,tja1051";
> > >> +             #phy-cells = <0>;
> > >> +             max-bitrate = <8000000>;
> > >> +             silent-gpios = <&pcal6416 6 GPIO_ACTIVE_HIGH>;
> > >
> > > [Severity: High]
> > > Does this cause a probe failure for the second transceiver?
> > >
> > > The first PHY node successfully requests this GPIO line, taking
> > > exclusive ownership. Because the phy-can-transceiver driver uses
> > > standard exclusive requests (without
> GPIOD_FLAGS_BIT_NONEXCLUSIVE),
> > > the second request for the exact same GPIO line fails with -EBUSY.
> > >
> > > This prevents the flexcan3_phy and the flexcan3 controller from
> > > probing and functioning.
> > >
> >
> > This two CAN PHY did share same pin as their silent-gpio on hardware.
> 
> Hardware share gpio, but driver may not handle this case. Are you sure
> 
> flexcan3_phy probed if can-phy0 already probed?
> 
> Frank
> 
Hi Frank,

root@imx952-15x15-lpddr5-frdm:~# ls /sys/bus/platform/drivers/flexcan/
421d0000.can  42220000.can  bind  module  uevent  unbind
root@imx952-15x15-lpddr5-frdm:~# ls /sys/bus/platform/drivers/can-transceiver-phy/
bind  can-phy0  can-phy1  module  uevent  unbind

From the log I think both can-phy probe successfully.

Regards,
Joseph

> >
> > The same design on i.MX95 15x15 FRDM. This should be fine.
> >
> > Regards,
> > Joseph
> >
> > >> +     };
> > > [ ... ]
> > >> +&usdhc2 {
> > >> +     bus-width = <4>;
> > >> +     cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
> > >> +     pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> > >> +     pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
> > >> +     pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
> > >> +     pinctrl-3 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> > >> +     pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> > >> +     vmmc-supply = <&reg_usdhc2_vmmc>;
> > >> +     fsl,cd-gpio-wakeup-disable;
> > >
> > > [Severity: Low]
> > > Is this out-of-tree vendor property invalid in the upstream kernel?
> > >
> > > The property fsl,cd-gpio-wakeup-disable does not exist in any
> > > upstream device tree bindings (such as fsl-imx-esdhc.yaml) and is
> > > not handled by any driver code in the upstream Linux tree. This acts
> > > as dead code and will trigger `make dtbs_check` validation warnings.
> > >
> > >> +     status = "okay";
> > >> +};
> > >
> > > --
> > > Sashiko AI review *
> > > https://sashiko.dev/#/patchset/20260720-imx952_frdm-v1-0-
> 6d145eaaa5c
> > > 4@nxp.com?part=2
> >
> > --
> > Best Regards,
> > Joseph

RE: [EXT] Re: [PATCH 2/2] arm64: dts: freescale: add i.MX952 FRDM Board support device tree

[Bough Chen]

> -----Original Message-----
> From: Frank Li <Frank.li@oss.nxp.com>
> Sent: 2026年7月20日 23:07
> To: Joseph Guo <qijian.guo@nxp.com>
> Cc: sashiko-reviews@lists.linux.dev; robh@kernel.org; Frank.Li@kernel.org;
> conor+dt@kernel.org; imx@lists.linux.dev; devicetree@vger.kernel.org
> Subject: Re: [EXT] Re: [PATCH 2/2] arm64: dts: freescale: add i.MX952 FRDM
> Board support device tree
> 
> On Mon, Jul 20, 2026 at 03:03:20PM +0800, Joseph Guo wrote:
> > On 7/20/2026 2:55 PM, sashiko-bot@kernel.org wrote:
> > > [You don't often get email from sashiko-bot@kernel.org. Learn why
> > > this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > Caution: This is an external email. Please take care when clicking
> > > links or opening attachments. When in doubt, report the message
> > > using the 'Report this email' button
> > >
> > >
> > > Thank you for your contribution! Sashiko AI review found 2 potential
> issue(s) to consider:
> > > - [High] Shared GPIO requested exclusively by two CAN transceivers
> causes probe failure for the second transceiver.
> > > - [Low] Use of undocumented, downstream-only device tree property
> `fsl,cd-gpio-wakeup-disable`.
> > > --
> > >
> > > --- Patch [2]: [PATCH 2/2] arm64: dts: freescale: add i.MX952 FRDM
> > > Board support device tree --- commit
> > > 8bbcb28d08a05e0f4c57023333492b4e023f7caf
> > > Author: Joseph Guo <qijian.guo@nxp.com>
> > >
> > > arm64: dts: freescale: add i.MX952 FRDM Board support device tree
> > >
> > > Add basic device tree support for i.MX952 FRDM Board. The
> > > board-common hardware description is placed in imx952-frdm.dtsi so
> > > that it can be shared with future i.MX952-based FRDM derivative boards.
> > >
> > >> diff --git a/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
> > >> b/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
> > >> new file mode 100644
> > >> index 0000000000000..b9ef6bec2bd5a
> > >> --- /dev/null
> > >> +++ b/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
> > >> @@ -0,0 +1,727 @@
> > > [ ... ]
> > >> +     flexcan2_phy: can-phy0 {
> > >> +             compatible = "nxp,tja1051";
> > >> +             #phy-cells = <0>;
> > >> +             max-bitrate = <8000000>;
> > >> +             silent-gpios = <&pcal6416 6 GPIO_ACTIVE_HIGH>;
> > >> +     };
> > >> +
> > >> +     flexcan3_phy: can-phy1 {
> > >> +             compatible = "nxp,tja1051";
> > >> +             #phy-cells = <0>;
> > >> +             max-bitrate = <8000000>;
> > >> +             silent-gpios = <&pcal6416 6 GPIO_ACTIVE_HIGH>;
> > >
> > > [Severity: High]
> > > Does this cause a probe failure for the second transceiver?
> > >
> > > The first PHY node successfully requests this GPIO line, taking
> > > exclusive ownership. Because the phy-can-transceiver driver uses
> > > standard exclusive requests (without GPIOD_FLAGS_BIT_NONEXCLUSIVE),
> > > the second request for the exact same GPIO line fails with -EBUSY.
> > >
> > > This prevents the flexcan3_phy and the flexcan3 controller from
> > > probing and functioning.
> > >
> >
> > This two CAN PHY did share same pin as their silent-gpio on hardware.
> 
> Hardware share gpio, but driver may not handle this case. Are you sure
> 
> flexcan3_phy probed if can-phy0 already probed?


Hi Frank

I dug into this. Both of you and sashiko are effectively right, but the outcome depends entirely on kernel config, so let me lay out the facts.

The driver side confirms Frank's/Sashiko's concern. In drivers/phy/phy-can-transceiver.c the silent line is requested exclusively:

silent_gpio = devm_gpiod_get_index_optional(dev, "silent", i,
					    GPIOD_OUT_LOW);
No GPIOD_FLAGS_BIT_NONEXCLUSIVE, and tja1051_drvdata carries CAN_TRANSCEIVER_SILENT_PRESENT, so the line really is requested. On a plain build, the second phy referencing the same pin would hit test_and_set_bit(GPIOD_FLAG_REQUESTED) in gpiod_request_commit() and get -EBUSY, failing the second transceiver and its flexcan controller. And NONEXCLUSIVE cannot be set from DT - the DT gpio flags cell only encodes ACTIVE_LOW / OPEN_DRAIN / PULL etc. So DTS tweaks alone cannot fix it.

Yet on the i.MX95 15x15 FRDM (same design: flexcan2_phy and flexcan5_phy both use silent-gpios = <&pcal6524 7 ...>) I tested it and both can0/can1 probe and pass traffic. The reason is the gpio-shared-proxy framework (drivers/gpio/gpiolib-shared.c, gpio-shared-proxy.c). At postcore_initcall gpiolib scans the DT; when the same controller+offset is referenced by

1 consumer via a "*-gpios" property, it claims the real line once (marked "shared") and hands each consumer its own proxy descriptor with vote-based arbitration - so the second probe no longer returns -EBUSY, with no DTS change.

The important subtlety is how that framework got enabled in my build. It is gated by HAVE_SHARED_GPIOS, and in both your BSP tree(frank.li/linux.git) and current linux-next, the only selector is ARCH_QCOM (commit e511d484cbe4, "arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM"). ARCH_MXC does NOT select it. My kernel has CONFIG_GPIO_SHARED=y because CONFIG_ARCH_QCOM=y is also set (as in the arm64 defconfig), which selects HAVE_SHARED_GPIOS -> GPIO_SHARED=y globally. Since the framework scans the whole DT regardless of SoC, our i.MX CAN nodes benefit from a config that Qualcomm pulled in. It works by coincidence of the multi-platform build, not because i.MX enables it.

Consequences for upstreaming this DTS:

Pure i.MX config (ARCH_MXC=y, no ARCH_QCOM): nothing selects HAVE_SHARED_GPIOS, GPIO_SHARED=n, the framework is compiled out, and the second CAN transceiver fails with -EBUSY. This is exactly Sashiko's scenario, and it is real.

arm64 defconfig (QCOM + i.MX): framework is pulled in by QCOM and it works - what I tested.

So the DTS is fine as written, but to make the shared silent-gpio robust for any i.MX-only configuration we should send a small prerequisite patch mirroring the Qualcomm one:

--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ config ARCH_MXC
	 select IMX_GPCV2
	 select IMX_GPCV2_PM_DOMAINS
+	 select HAVE_SHARED_GPIOS
	 select PM
	 select PM_GENERIC_DOMAINS
(and CONFIG_GPIO_SHARED_PROXY should be built-in/module in the i.MX defconfig; it is default m). With that in place, the shared silent-gpio in the FRDM DTSI probes correctly regardless of whether ARCH_QCOM is also enabled. If you think this method is okay, then I think Joseph can post this Kconfig patch alongside the board DTS.

Separately, on the [Low] finding:  Joseph, please drop the downstream-only "fsl,cd-gpio-wakeup-disable" from &usdhc2 in the upstream DTSI - there is no upstream binding and no driver consumes it, so it is dead code and would trip make dtbs_check

Regards
Haibo Chen

> 
> Frank
> 
> >
> > The same design on i.MX95 15x15 FRDM. This should be fine.
> >
> > Regards,
> > Joseph
> >
> > >> +     };
> > > [ ... ]
> > >> +&usdhc2 {
> > >> +     bus-width = <4>;
> > >> +     cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
> > >> +     pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> > >> +     pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
> > >> +     pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
> > >> +     pinctrl-3 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> > >> +     pinctrl-names = "default", "state_100mhz", "state_200mhz",
> "sleep";
> > >> +     vmmc-supply = <&reg_usdhc2_vmmc>;
> > >> +     fsl,cd-gpio-wakeup-disable;
> > >
> > > [Severity: Low]
> > > Is this out-of-tree vendor property invalid in the upstream kernel?
> > >
> > > The property fsl,cd-gpio-wakeup-disable does not exist in any
> > > upstream device tree bindings (such as fsl-imx-esdhc.yaml) and is
> > > not handled by any driver code in the upstream Linux tree. This acts
> > > as dead code and will trigger `make dtbs_check` validation warnings.
> > >
> > >> +     status = "okay";
> > >> +};
> > >
> > > --
> > > Sashiko AI review ・
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsa
> > >
> shiko.dev%2F%23%2Fpatchset%2F20260720-imx952_frdm-v1-0-6d145eaaa5
> c4%
> > >
> 40nxp.com%3Fpart%3D2&data=05%7C02%7Chaibo.chen%40nxp.com%7C29
> e9bc792
> > >
> 4f2455f2cdd08dee67565f4%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
> %7C0%7
> > >
> C639201589065857811%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> iOnRydWUs
> > >
> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D
> > > %7C0%7C%7C%7C&sdata=hQfdYq0rrk8kvruJk%2FGc32LxLfMMmRAJn7kG
> bT5BMjA%3D
> > > &reserved=0
> >
> > --
> > Best Regards,
> > Joseph

Re: [PATCH 1/2] dt-bindings: arm: fsl: add i.MX952 FRDM board

[Rob Herring (Arm)]

On Mon, 20 Jul 2026 15:28:53 +0900, Joseph Guo wrote:
> Add DT compatible string for NXP i.MX952 FRDM board.
> 
> Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
> ---
>  Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

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

Re: [EXT] Re: [PATCH 2/2] arm64: dts: freescale: add i.MX952 FRDM Board support device tree

[Frank Li]

On Wed, Jul 22, 2026 at 07:57:58AM +0000, Bough Chen wrote:
> > -----Original Message-----
> > From: Frank Li <Frank.li@oss.nxp.com>
> > Sent: 2026年7月20日 23:07
> > To: Joseph Guo <qijian.guo@nxp.com>
> > Cc: sashiko-reviews@lists.linux.dev; robh@kernel.org; Frank.Li@kernel.org;
> > conor+dt@kernel.org; imx@lists.linux.dev; devicetree@vger.kernel.org
> > Subject: Re: [EXT] Re: [PATCH 2/2] arm64: dts: freescale: add i.MX952 FRDM
> > Board support device tree
> >
> > On Mon, Jul 20, 2026 at 03:03:20PM +0800, Joseph Guo wrote:
> > > On 7/20/2026 2:55 PM, sashiko-bot@kernel.org wrote:
> > > > [You don't often get email from sashiko-bot@kernel.org. Learn why
> > > > this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > > >
> > > > Caution: This is an external email. Please take care when clicking
> > > > links or opening attachments. When in doubt, report the message
> > > > using the 'Report this email' button
> > > >
> > > >
> > > > Thank you for your contribution! Sashiko AI review found 2 potential
> > issue(s) to consider:
> > > > - [High] Shared GPIO requested exclusively by two CAN transceivers
> > causes probe failure for the second transceiver.
> > > > - [Low] Use of undocumented, downstream-only device tree property
> > `fsl,cd-gpio-wakeup-disable`.
> > > > --
> > > >
> > > > --- Patch [2]: [PATCH 2/2] arm64: dts: freescale: add i.MX952 FRDM
> > > > Board support device tree --- commit
> > > > 8bbcb28d08a05e0f4c57023333492b4e023f7caf
> > > > Author: Joseph Guo <qijian.guo@nxp.com>
> > > >
> > > > arm64: dts: freescale: add i.MX952 FRDM Board support device tree
> > > >
> > > > Add basic device tree support for i.MX952 FRDM Board. The
> > > > board-common hardware description is placed in imx952-frdm.dtsi so
> > > > that it can be shared with future i.MX952-based FRDM derivative boards.
> > > >
> > > >> diff --git a/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
> > > >> b/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
> > > >> new file mode 100644
> > > >> index 0000000000000..b9ef6bec2bd5a
> > > >> --- /dev/null
> > > >> +++ b/arch/arm64/boot/dts/freescale/imx952-frdm.dtsi
> > > >> @@ -0,0 +1,727 @@
> > > > [ ... ]
> > > >> +     flexcan2_phy: can-phy0 {
> > > >> +             compatible = "nxp,tja1051";
> > > >> +             #phy-cells = <0>;
> > > >> +             max-bitrate = <8000000>;
> > > >> +             silent-gpios = <&pcal6416 6 GPIO_ACTIVE_HIGH>;
> > > >> +     };
> > > >> +
> > > >> +     flexcan3_phy: can-phy1 {
> > > >> +             compatible = "nxp,tja1051";
> > > >> +             #phy-cells = <0>;
> > > >> +             max-bitrate = <8000000>;
> > > >> +             silent-gpios = <&pcal6416 6 GPIO_ACTIVE_HIGH>;
> > > >
> > > > [Severity: High]
> > > > Does this cause a probe failure for the second transceiver?
> > > >
> > > > The first PHY node successfully requests this GPIO line, taking
> > > > exclusive ownership. Because the phy-can-transceiver driver uses
> > > > standard exclusive requests (without GPIOD_FLAGS_BIT_NONEXCLUSIVE),
> > > > the second request for the exact same GPIO line fails with -EBUSY.
> > > >
> > > > This prevents the flexcan3_phy and the flexcan3 controller from
> > > > probing and functioning.
> > > >
> > >
> > > This two CAN PHY did share same pin as their silent-gpio on hardware.
> >
> > Hardware share gpio, but driver may not handle this case. Are you sure
> >
> > flexcan3_phy probed if can-phy0 already probed?
>
>
> Hi Frank
>
> I dug into this. Both of you and sashiko are effectively right, but the outcome depends entirely on kernel config, so let me lay out the facts.
>
> The driver side confirms Frank's/Sashiko's concern. In drivers/phy/phy-can-transceiver.c the silent line is requested exclusively:
>
> silent_gpio = devm_gpiod_get_index_optional(dev, "silent", i,
> 					    GPIOD_OUT_LOW);
> No GPIOD_FLAGS_BIT_NONEXCLUSIVE, and tja1051_drvdata carries CAN_TRANSCEIVER_SILENT_PRESENT, so the line really is requested. On a plain build, the second phy referencing the same pin would hit test_and_set_bit(GPIOD_FLAG_REQUESTED) in gpiod_request_commit() and get -EBUSY, failing the second transceiver and its flexcan controller. And NONEXCLUSIVE cannot be set from DT - the DT gpio flags cell only encodes ACTIVE_LOW / OPEN_DRAIN / PULL etc. So DTS tweaks alone cannot fix it.
>
> Yet on the i.MX95 15x15 FRDM (same design: flexcan2_phy and flexcan5_phy both use silent-gpios = <&pcal6524 7 ...>) I tested it and both can0/can1 probe and pass traffic. The reason is the gpio-shared-proxy framework (drivers/gpio/gpiolib-shared.c, gpio-shared-proxy.c). At postcore_initcall gpiolib scans the DT; when the same controller+offset is referenced by
>
> 1 consumer via a "*-gpios" property, it claims the real line once (marked "shared") and hands each consumer its own proxy descriptor with vote-based arbitration - so the second probe no longer returns -EBUSY, with no DTS change.
>
> The important subtlety is how that framework got enabled in my build. It is gated by HAVE_SHARED_GPIOS, and in both your BSP tree(frank.li/linux.git) and current linux-next, the only selector is ARCH_QCOM (commit e511d484cbe4, "arm64: select HAVE_SHARED_GPIOS for ARCH_QCOM"). ARCH_MXC does NOT select it. My kernel has CONFIG_GPIO_SHARED=y because CONFIG_ARCH_QCOM=y is also set (as in the arm64 defconfig), which selects HAVE_SHARED_GPIOS -> GPIO_SHARED=y globally. Since the framework scans the whole DT regardless of SoC, our i.MX CAN nodes benefit from a config that Qualcomm pulled in. It works by coincidence of the multi-platform build, not because i.MX enables it.
>
> Consequences for upstreaming this DTS:
>
> Pure i.MX config (ARCH_MXC=y, no ARCH_QCOM): nothing selects HAVE_SHARED_GPIOS, GPIO_SHARED=n, the framework is compiled out, and the second CAN transceiver fails with -EBUSY. This is exactly Sashiko's scenario, and it is real.
>
> arm64 defconfig (QCOM + i.MX): framework is pulled in by QCOM and it works - what I tested.
>
> So the DTS is fine as written, but to make the shared silent-gpio robust for any i.MX-only configuration we should send a small prerequisite patch mirroring the Qualcomm one:
>
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ config ARCH_MXC
> 	 select IMX_GPCV2
> 	 select IMX_GPCV2_PM_DOMAINS
> +	 select HAVE_SHARED_GPIOS
> 	 select PM
> 	 select PM_GENERIC_DOMAINS
> (and CONFIG_GPIO_SHARED_PROXY should be built-in/module in the i.MX defconfig; it is default m). With that in place, the shared silent-gpio in the FRDM DTSI probes correctly regardless of whether ARCH_QCOM is also enabled. If you think this method is okay, then I think Joseph can post this Kconfig patch alongside the board DTS.
>

Thanks you for detail information. It is quite helpful.

Frank

> Separately, on the [Low] finding:  Joseph, please drop the downstream-only "fsl,cd-gpio-wakeup-disable" from &usdhc2 in the upstream DTSI - there is no upstream binding and no driver consumes it, so it is dead code and would trip make dtbs_check
>
> Regards
> Haibo Chen
>
> >
> > Frank
> >
> > >
> > > The same design on i.MX95 15x15 FRDM. This should be fine.
> > >
> > > Regards,
> > > Joseph
> > >
> > > >> +     };
> > > > [ ... ]
> > > >> +&usdhc2 {
> > > >> +     bus-width = <4>;
> > > >> +     cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
> > > >> +     pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> > > >> +     pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
> > > >> +     pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
> > > >> +     pinctrl-3 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> > > >> +     pinctrl-names = "default", "state_100mhz", "state_200mhz",
> > "sleep";
> > > >> +     vmmc-supply = <&reg_usdhc2_vmmc>;
> > > >> +     fsl,cd-gpio-wakeup-disable;
> > > >
> > > > [Severity: Low]
> > > > Is this out-of-tree vendor property invalid in the upstream kernel?
> > > >
> > > > The property fsl,cd-gpio-wakeup-disable does not exist in any
> > > > upstream device tree bindings (such as fsl-imx-esdhc.yaml) and is
> > > > not handled by any driver code in the upstream Linux tree. This acts
> > > > as dead code and will trigger `make dtbs_check` validation warnings.
> > > >
> > > >> +     status = "okay";
> > > >> +};
> > > >
> > > > --
> > > > Sashiko AI review ・
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsa
> > > >
> > shiko.dev%2F%23%2Fpatchset%2F20260720-imx952_frdm-v1-0-6d145eaaa5
> > c4%
> > > >
> > 40nxp.com%3Fpart%3D2&data=05%7C02%7Chaibo.chen%40nxp.com%7C29
> > e9bc792
> > > >
> > 4f2455f2cdd08dee67565f4%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
> > %7C0%7
> > > >
> > C639201589065857811%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> > iOnRydWUs
> > > >
> > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D
> > > > %7C0%7C%7C%7C&sdata=hQfdYq0rrk8kvruJk%2FGc32LxLfMMmRAJn7kG
> > bT5BMjA%3D
> > > > &reserved=0
> > >
> > > --
> > > Best Regards,
> > > Joseph
>