Re: [PATCH v5 2/3] arm64: dts: freescale: Add support for Variscite DART-MX8M-PLUS

[Frank Li <Frank.li@oss.nxp.com>]

On Tue, Jun 09, 2026 at 10:07:29AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Medium] The eqos pinctrl group claims GPIO2_IO20 but no driver or regulator uses it, potentially breaking Ethernet or SD2.
> - [Medium] Bluetooth control GPIOs are muxed but not assigned to the bluetooth node, leaving the chip in an uncontrolled state.
> --
>
> commit 7c8394d85e349e14bbf3796b542f8e133683dff3
> Author: Stefano Radaelli <stefano.r@variscite.com>
>
> arm64: dts: freescale: Add support for Variscite DART-MX8M-PLUS
>
> Add device tree support for the Variscite DART-MX8MP system on module.
> This SOM is designed to be used with various carrier boards.
>
> Link: https://variscite.com/system-on-module-som/i-mx-8/i-mx-8m-plus/dart-mx8m-plus/
>
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-var-dart.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-var-dart.dtsi
> > new file mode 100644
> > index 0000000000000..a647a2e0ab94b
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp-var-dart.dtsi
>
> [ ... ]
>
> > +/* BT module */
> > +&uart4 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_uart4>, <&pinctrl_bt>;
> > +	assigned-clocks = <&clk IMX8MP_CLK_UART4>;
> > +	assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>;
> > +	uart-has-rtscts;
> > +	status = "okay";
> > +
> > +	bluetooth_iw61x: bluetooth {
> > +		compatible = "nxp,88w8987-bt";
> > +	};
>
> [Severity: Medium]
> The pinctrl_bt group configures GPIO2_IO06 and GPIO2_IO09 as GPIOs and attaches
> them to uart4, but this bluetooth_iw61x node does not map these pins to any
> properties like device-wakeup-gpios or reset-gpios.

Please check it, look like make sense

>
> Will the kernel driver fail to toggle these pins, leaving the chip in an
> uncontrolled state? Is it relying on bootloader defaults or userspace sysfs
> toggling for these pins?
>
> > +};
>
> [ ... ]
>
> > +	pinctrl_eqos: eqosgrp {
> > +		fsl,pins = <
> > +			MX8MP_IOMUXC_ENET_MDC__ENET_QOS_MDC				0x2
> > +			MX8MP_IOMUXC_ENET_MDIO__ENET_QOS_MDIO				0x2
> > +			MX8MP_IOMUXC_ENET_RD0__ENET_QOS_RGMII_RD0			0x90
> > +			MX8MP_IOMUXC_ENET_RD1__ENET_QOS_RGMII_RD1			0x90
> > +			MX8MP_IOMUXC_ENET_RD2__ENET_QOS_RGMII_RD2			0x90
> > +			MX8MP_IOMUXC_ENET_RD3__ENET_QOS_RGMII_RD3			0x90
> > +			MX8MP_IOMUXC_ENET_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK	0x90
> > +			MX8MP_IOMUXC_ENET_RX_CTL__ENET_QOS_RGMII_RX_CTL			0x90
> > +			MX8MP_IOMUXC_ENET_TD0__ENET_QOS_RGMII_TD0			0x16
> > +			MX8MP_IOMUXC_ENET_TD1__ENET_QOS_RGMII_TD1			0x16
> > +			MX8MP_IOMUXC_ENET_TD2__ENET_QOS_RGMII_TD2			0x16
> > +			MX8MP_IOMUXC_ENET_TD3__ENET_QOS_RGMII_TD3			0x16
> > +			MX8MP_IOMUXC_ENET_TX_CTL__ENET_QOS_RGMII_TX_CTL			0x16
> > +			MX8MP_IOMUXC_ENET_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK	0x16
> > +			MX8MP_IOMUXC_SD2_WP__GPIO2_IO20					0x10
>
> [Severity: Medium]
> The pinctrl_eqos node configures MX8MP_IOMUXC_SD2_WP__GPIO2_IO20 as a GPIO, but
> there is no corresponding regulator or driver property that requests this GPIO.
>
> Could this unnecessarily block GPIO2_IO20 and cause a pin conflict for any
> carrier board that attempts to use it (for example, for usdhc2 write protect)?
> Was this possibly a copy-paste error from imx8mp-var-som.dtsi?

Look like make sense, are you really use GPIO2_IO20 for eqos?

Frank

>
> > +			MX8MP_IOMUXC_SD1_STROBE__GPIO2_IO11				0x150
> > +		>;
> > +	};
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/cover.1780998600.git.stefano.r@variscite.com?part=2