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

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

[Stefano Radaelli]

From: Stefano Radaelli <stefano.r@variscite.com>

Fix the Ethernet PHY description on the DART-MX9 Sonata boards.

The GPIO previously described as the PHY reset line is actually a
board-level enable signal required by the PHY. Model it accordingly and
remove the incorrect reset GPIO description from the PHY nodes.

On i.MX91 and i.MX93 the signal is described as a fixed regulator,
whereas the existing regulator description on i.MX95 is reused.

Keeping the PHY enable asserted during boot ensures that Ethernet
initialization completes successfully.

Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
 .../boot/dts/freescale/imx91-var-dart-sonata.dts   | 14 +++++++++++---
 .../boot/dts/freescale/imx93-var-dart-sonata.dts   | 14 +++++++++++---
 .../boot/dts/freescale/imx95-var-dart-sonata.dts   |  3 ---
 3 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
index 3f0fd321d95f..f7e32f9375f5 100644
--- a/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
+++ b/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
@@ -97,6 +97,17 @@ reg_rgb_sel: regulator-rgb-enable {
 		enable-active-high;
 	};
 
+	reg_phy1_supply: regulator-phy1 {
+		compatible = "regulator-fixed";
+		regulator-name = "SUPPLY_PHY1";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&pca6408_2 0 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		startup-delay-us = <10000>;
+		regulator-always-on;
+	};
+
 	reg_usdhc2_vmmc: regulator-vmmc-usdhc2 {
 		compatible = "regulator-fixed";
 		pinctrl-names = "default";
@@ -139,9 +150,6 @@ mdio {
 		ethphy1: ethernet-phy@1 {
 			compatible = "ethernet-phy-ieee802.3-c22";
 			reg = <1>;
-			reset-gpios = <&pca6408_2 0 GPIO_ACTIVE_LOW>;
-			reset-assert-us = <15000>;
-			reset-deassert-us = <100000>;
 
 			leds {
 				#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
index 5513d3b148a2..1ca3ec8330d0 100644
--- a/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
+++ b/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
@@ -103,6 +103,17 @@ reg_vref_1v8: regulator-adc-vref {
 		regulator-min-microvolt = <1800000>;
 	};
 
+	reg_phy1_supply: regulator-phy1 {
+		compatible = "regulator-fixed";
+		regulator-name = "SUPPLY_PHY1";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&pca6408_2 0 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		startup-delay-us = <10000>;
+		regulator-always-on;
+	};
+
 	reg_usdhc2_vmmc: regulator-vmmc-usdhc2 {
 		compatible = "regulator-fixed";
 		regulator-name = "VDD_SD2_3V3";
@@ -180,9 +191,6 @@ mdio {
 		ethphy1: ethernet-phy@1 {
 			compatible = "ethernet-phy-ieee802.3-c22";
 			reg = <1>;
-			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 7a58ad38ffb4..ccf7e77016e4 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>;
-		reset-gpios = <&pca6408_2 0 GPIO_ACTIVE_LOW>;
-		reset-assert-us = <10000>;
-		reset-deassert-us = <100000>;
 
 		leds {
 			#address-cells = <1>;
-- 
2.47.3

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Removing the explicitly linked `reset-gpios` property from the PHY nodes without adding a corresponding `-supply` reference breaks `fw_devlink` dependency ordering, creating a probe race condition.
- [Medium] Replacing the PHY reset configuration with a fixed regulator reduces the post-enable delay from 100ms to 10ms, which may violate the PHY's initialization timing requirements.
--

commit aa29283e1adc330c15b9cab63314f0eec59e0b65
Author: Stefano Radaelli <stefano.r@variscite.com>
arm64: dts: freescale: imx9-var-dart-sonata: fix Ethernet PHY configuration

This commit corrects the Ethernet PHY description on DART-MX9 Sonata boards by
modeling the PHY reset line as a fixed regulator instead. It removes the
reset-gpios property from the PHY nodes and asserts the enable signal during
boot to ensure initialization completes successfully.

> diff --git a/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
> index 3f0fd321d95f0..f7e32f9375f50 100644
> --- a/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
> +++ b/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
[ ... ]
> +	reg_phy1_supply: regulator-phy1 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "SUPPLY_PHY1";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		gpio = <&pca6408_2 0 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +		startup-delay-us = <10000>;

[Severity: Medium]
Could reducing the post-enable delay from 100ms (originally in
reset-deassert-us) to 10ms violate the PHY's initialization timing
requirements?

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

> -			reset-gpios = <&pca6408_2 0 GPIO_ACTIVE_LOW>;
> -			reset-assert-us = <15000>;
> -			reset-deassert-us = <100000>;
>  
>  			leds {
>  				#address-cells = <1>;
[ ... ]
> diff --git a/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
> index 5513d3b148a2f..1ca3ec8330d07 100644
> --- a/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
> +++ b/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
[ ... ]
> +	reg_phy1_supply: regulator-phy1 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "SUPPLY_PHY1";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		gpio = <&pca6408_2 0 GPIO_ACTIVE_HIGH>;
> +		enable-active-high;
> +		startup-delay-us = <10000>;

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

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

> -			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?

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

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

[Stefano Radaelli]

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