Re: [PATCH v1 1/1] arm64: dts: freescale: imx9-var-dart-sonata: fix Ethernet PHY configuration

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

Hi,

On Fri, Jul 03, 2026 at 03:41:38PM +0000, sashiko-bot@kernel.org wrote:

> > +		regulator-always-on;
> > +	};
> [ ... ]
> > @@ -139,9 +150,6 @@ mdio {
> >  		ethphy1: ethernet-phy@1 {
> >  			compatible = "ethernet-phy-ieee802.3-c22";
> >  			reg = <1>;
> 
> [Severity: High]
> Since the explicitly linked reset-gpios property was removed below, shouldn't
> there be a corresponding phy-supply = <&reg_phy1_supply>; link here to maintain
> the device link dependency?
> 
> Without this link, fw_devlink no longer sees any dependency between the
> Ethernet subsystem and the GPIO expander. Could the MAC driver probe and scan
> the MDIO bus before the I2C GPIO expander (pca6408_2) and the new always-on
> regulator are initialized, resulting in get_phy_device() failing with -ENODEV?

I did try modelling this GPIO as a PHY supply using phy-supply, but
that configuration does not work correctly on these boards.
The PHY is still not detected reliably during boot.

> [Severity: Medium]
> Does this same reduction to a 10ms startup delay also risk initialization
> failure here?
> 

the startup-delay-us value is intentionally set to 10 ms.
This delay reflects the enable timing of the board-level signal and is
not intended to match the previous reset-deassert-us delay, as the
signal is no longer being used as a reset.

> > +		regulator-always-on;
> > +	};
> [ ... ]
> > @@ -180,9 +191,6 @@ mdio {
> >  		ethphy1: ethernet-phy@1 {
> >  			compatible = "ethernet-phy-ieee802.3-c22";
> >  			reg = <1>;
> 
> [Severity: High]
> Does this node also need a phy-supply = <&reg_phy1_supply>; property to prevent
> the probe race condition described above?

I did try modelling this GPIO as a PHY supply using phy-supply, but
that configuration does not work correctly on these boards.
The PHY is still not detected reliably during boot.

> 
> > -			reset-assert-us = <15000>;
> > -			reset-deassert-us = <100000>;
> > -			reset-gpios = <&pca6408_2 0 GPIO_ACTIVE_LOW>;
> >  
> >  			leds {
> >  				#address-cells = <1>;
> [ ... ]
> > diff --git a/arch/arm64/boot/dts/freescale/imx95-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx95-var-dart-sonata.dts
> > index 7a58ad38ffb46..ccf7e77016e48 100644
> > --- a/arch/arm64/boot/dts/freescale/imx95-var-dart-sonata.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx95-var-dart-sonata.dts
> [ ... ]
> > @@ -346,9 +346,6 @@ &netc_emdio {
> >  	ethphy1: ethernet-phy@1 {
> >  		compatible = "ethernet-phy-ieee802.3-c22";
> >  		reg = <1>;
> 
> [Severity: High]
> Does this PHY node also require a phy-supply property to maintain its
> dependency ordering after the reset-gpios removal?
> 

I did try modelling this GPIO as a PHY supply using phy-supply, but
that configuration does not work correctly on these boards.
The PHY is still not detected reliably during boot.

> > -		reset-gpios = <&pca6408_2 0 GPIO_ACTIVE_LOW>;
> > -		reset-assert-us = <10000>;
> > -		reset-deassert-us = <100000>;
> >  
> >  		leds {
> >  			#address-cells = <1>;
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260703152731.236793-1-stefano.r@variscite.com?part=1