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

[Stefano Radaelli <stefano.radaelli21@gmail.com>]

Hi Frank,

On Mon, Jun 29, 2026 at 12:48:37PM -0400, Frank Li wrote:
> >
> > > +/* 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

This is intentional,
these pins are not meant to be controlled by the Bluetooth kernel
driver. They only need to be muxed as GPIOs in the device tree so they
are not configured with different alternate function, since they are
handled by our userspace initialization script following the power-on
rules.

This is also consistent with the existing Variscite DTS files, where
these BT/WBE control pins are only muxed and not mapped to Bluetooth
driver properties.

Best Regards,
Stefano

> 
> >
> > 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
> > > +		>;

Thank you,
I will remove this GPIO.

Best regards,
Stefano