[PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Christoph Stoidner]

According to the datasheet the phy needs to be held in reset until the
reference clock got stable. Even though no issue was observed, fix this
as the software should always comply with the specification.

Use gpio4 23, which is connected to the phy reset pin. On the same pin
RX_ER was used before, but this signal is optional and can be dropped.

Note: This comes into effect with the phyCOREs SOM hardware revision 4.
In revisions before, this gpio is not connected, and the phy reset is
managed with the global hardware reset circuit.

Signed-off-by: Christoph Stoidner <c.stoidner@phytec.de>
---
Changes in v3:
- use reset-gpios (from ethernet-phy.yaml) instead of phy-reset-gpios

Changes in v2:
- remove paragraph "Fix this in the bootloader..." from commit message
- fix checkpatch warning

 arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
index 88c2657b50e6..b481097f08a4 100644
--- a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
@@ -68,6 +68,8 @@ mdio: mdio {
 		ethphy1: ethernet-phy@1 {
 			compatible = "ethernet-phy-ieee802.3-c22";
 			reg = <1>;
+			reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
+			reset-assert-us = <30>;
 		};
 	};
 };
@@ -91,14 +93,17 @@ pinctrl_fec: fecgrp {
 		fsl,pins = <
 			MX93_PAD_ENET2_MDC__ENET1_MDC			0x50e
 			MX93_PAD_ENET2_MDIO__ENET1_MDIO			0x502
-			MX93_PAD_ENET2_RD0__ENET1_RGMII_RD0		0x57e
-			MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1		0x57e
-			MX93_PAD_ENET2_RXC__ENET1_RX_ER			0x5fe
+			/* the three pins below are connected to PHYs straps,
+			 * that is what the pull-up/down setting is for.
+			 */
+			MX93_PAD_ENET2_RD0__ENET1_RGMII_RD0		0x37e
+			MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1		0x37e
 			MX93_PAD_ENET2_RX_CTL__ENET1_RGMII_RX_CTL	0x57e
 			MX93_PAD_ENET2_TD0__ENET1_RGMII_TD0		0x50e
 			MX93_PAD_ENET2_TD1__ENET1_RGMII_TD1		0x50e
 			MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL	0x50e
 			MX93_PAD_ENET2_TD2__ENET1_TX_CLK		0x4000050e
+			MX93_PAD_ENET2_RXC__GPIO4_IO23			0x51e
 		>;
 	};
 
-- 
2.43.0

Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Andrew Lunn]

> diff --git a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
> index 88c2657b50e6..b481097f08a4 100644
> --- a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
> @@ -68,6 +68,8 @@ mdio: mdio {
>  		ethphy1: ethernet-phy@1 {
>  			compatible = "ethernet-phy-ieee802.3-c22";
>  			reg = <1>;
> +			reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
> +			reset-assert-us = <30>;

Is there anything in the datasheet about needing a delay after the
reset? There is a DT property for this:

  reset-deassert-us:
    description:
      Delay after the reset was deasserted in microseconds. If
      this property is missing the delay will be skipped.

Anyway:

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

AW: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Christoph Stoidner]

Hi Andrew,

> On Di, 2025-05-24 at 19:44 -0300, Andrew Lunn wrote:
>
>> diff --git a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
>> index 88c2657b50e6..b481097f08a4 100644
>> --- a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
>> @@ -68,6 +68,8 @@ mdio: mdio {
>>               ethphy1: ethernet-phy@1 {
>>                       compatible = "ethernet-phy-ieee802.3-c22";
>>                       reg = <1>;
>> +                     reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
>> +                     reset-assert-us = <30>;
>
>Is there anything in the datasheet about needing a delay after the
>reset? There is a DT property for this:
>
>  reset-deassert-us:
>    description:
>      Delay after the reset was deasserted in microseconds. If
>      this property is missing the delay will be skipped.
No, there is no need for a delay after the reset mentioned in the datasheet.
There is only the delay after the assert (i.E. the pulse width), that I
declared with the property reset-assert-us.

>
>Anyway:
>
>Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Thanks, and regards,
Christoph

>
>    Andrew

Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Stefan Wahren]

Hi Andrew,
hi Christoph

Am 24.05.25 um 19:44 schrieb Andrew Lunn:
>> diff --git a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
>> index 88c2657b50e6..b481097f08a4 100644
>> --- a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
>> @@ -68,6 +68,8 @@ mdio: mdio {
>>   		ethphy1: ethernet-phy@1 {
>>   			compatible = "ethernet-phy-ieee802.3-c22";
>>   			reg = <1>;
>> +			reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
>> +			reset-assert-us = <30>;
> Is there anything in the datasheet about needing a delay after the
> reset? There is a DT property for this:
>
>    reset-deassert-us:
>      description:
>        Delay after the reset was deasserted in microseconds. If
>        this property is missing the delay will be skipped.
is it the time until the PHY finished its post reset stabilization 
(datasheet to call it T2 "reset to SMI ready")?
>
> Anyway:
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>
>      Andrew
>

Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Christoph Stoidner]

Hi Stefan,

On Mo, 2025-05-26 at 08:44 +0200, Stefan Wahren wrote:
> Hi Andrew,
> hi Christoph
> 
> Am 24.05.25 um 19:44 schrieb Andrew Lunn:
> > > diff --git a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
> > > b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
> > > index 88c2657b50e6..b481097f08a4 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
> > > @@ -68,6 +68,8 @@ mdio: mdio {
> > >    ethphy1: ethernet-phy@1 {
> > >    compatible = "ethernet-phy-ieee802.3-c22";
> > >    reg = <1>;
> > > + reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
> > > + reset-assert-us = <30>;
> > Is there anything in the datasheet about needing a delay after the
> > reset? There is a DT property for this:
> > 
> >    reset-deassert-us:
> >      description:
> >        Delay after the reset was deasserted in microseconds. If
> >        this property is missing the delay will be skipped.
> is it the time until the PHY finished its post reset stabilization 
> (datasheet to call it T2 "reset to SMI ready")?

The T2 ("Post reset stabilization time") in the datasheet is the time
"prior to MDC preamble for register access", that is defined with 2ms.
I did not use reset-deassert-us for it, because the first register 
access does anyway occur much later (I measured 4000ms).

And we have the same for T4, the "Post power-up stabilization time". 
It is defined with a time of 50ms as "prior to MDC preamble for
register access". But also here we just know, the register access
happens much later - and treated it as enough.

Formally, this may be valid to specify the 2ms as reset-deassert-us. 
But since the first register access is so much later, I thought we can
save those 2ms.

Are you fine with that?

Regards,
Christoph


> > 
> > Anyway:
> > 
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> > 
> >      Andrew
> > 
> 

Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Stefan Wahren]

Am 26.05.25 um 11:09 schrieb Christoph Stoidner:
> Hi Stefan,
>
> On Mo, 2025-05-26 at 08:44 +0200, Stefan Wahren wrote:
>> Hi Andrew,
>> hi Christoph
>>
>> Am 24.05.25 um 19:44 schrieb Andrew Lunn:
>>>> diff --git a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
>>>> b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
>>>> index 88c2657b50e6..b481097f08a4 100644
>>>> --- a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
>>>> +++ b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
>>>> @@ -68,6 +68,8 @@ mdio: mdio {
>>>>     ethphy1: ethernet-phy@1 {
>>>>     compatible = "ethernet-phy-ieee802.3-c22";
>>>>     reg = <1>;
>>>> + reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
>>>> + reset-assert-us = <30>;
>>> Is there anything in the datasheet about needing a delay after the
>>> reset? There is a DT property for this:
>>>
>>>     reset-deassert-us:
>>>       description:
>>>         Delay after the reset was deasserted in microseconds. If
>>>         this property is missing the delay will be skipped.
>> is it the time until the PHY finished its post reset stabilization
>> (datasheet to call it T2 "reset to SMI ready")?
> The T2 ("Post reset stabilization time") in the datasheet is the time
> "prior to MDC preamble for register access", that is defined with 2ms.
> I did not use reset-deassert-us for it, because the first register
> access does anyway occur much later (I measured 4000ms).
>
> And we have the same for T4, the "Post power-up stabilization time".
> It is defined with a time of 50ms as "prior to MDC preamble for
> register access". But also here we just know, the register access
> happens much later - and treated it as enough.
>
> Formally, this may be valid to specify the 2ms as reset-deassert-us.
> But since the first register access is so much later, I thought we can
> save those 2ms.
>
> Are you fine with that?
I don't insist on an additional "reset-deassert-us". The question was 
more about understanding.
>
> Regards,
> Christoph
>
>
>>> Anyway:
>>>
>>> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>>>
>>>       Andrew
>>>

Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Christoph Stoidner]

On Mo, 2025-05-26 at 11:24 +0200, Stefan Wahren wrote:
> Am 26.05.25 um 11:09 schrieb Christoph Stoidner:
> > Hi Stefan,
> > 
> > On Mo, 2025-05-26 at 08:44 +0200, Stefan Wahren wrote:
> > > Hi Andrew,
> > > hi Christoph
> > > 
> > > Am 24.05.25 um 19:44 schrieb Andrew Lunn:
> > > > > diff --git a/arch/arm64/boot/dts/freescale/imx93-phycore-
> > > > > som.dtsi
> > > > > b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
> > > > > index 88c2657b50e6..b481097f08a4 100644
> > > > > --- a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
> > > > > +++ b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
> > > > > @@ -68,6 +68,8 @@ mdio: mdio {
> > > > >     ethphy1: ethernet-phy@1 {
> > > > >     compatible = "ethernet-phy-ieee802.3-c22";
> > > > >     reg = <1>;
> > > > > + reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
> > > > > + reset-assert-us = <30>;
> > > > Is there anything in the datasheet about needing a delay after
> > > > the
> > > > reset? There is a DT property for this:
> > > > 
> > > >     reset-deassert-us:
> > > >       description:
> > > >         Delay after the reset was deasserted in microseconds.
> > > > If
> > > >         this property is missing the delay will be skipped.
> > > is it the time until the PHY finished its post reset
> > > stabilization
> > > (datasheet to call it T2 "reset to SMI ready")?
> > The T2 ("Post reset stabilization time") in the datasheet is the
> > time
> > "prior to MDC preamble for register access", that is defined with
> > 2ms.
> > I did not use reset-deassert-us for it, because the first register
> > access does anyway occur much later (I measured 4000ms).
> > 
> > And we have the same for T4, the "Post power-up stabilization
> > time".
> > It is defined with a time of 50ms as "prior to MDC preamble for
> > register access". But also here we just know, the register access
> > happens much later - and treated it as enough.
> > 
> > Formally, this may be valid to specify the 2ms as reset-deassert-
> > us.
> > But since the first register access is so much later, I thought we
> > can
> > save those 2ms.
> > 
> > Are you fine with that?
> I don't insist on an additional "reset-deassert-us". The question was
> more about understanding.
Great, thanks for thr feedback.

> > 
> > Regards,
> > Christoph
> > 
> > 
> > > > Anyway:
> > > > 
> > > > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> > > > 
> > > >       Andrew
> > > > 
> 

Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Stefan Wahren]

Am 26.05.25 um 12:04 schrieb Christoph Stoidner:
> On Mo, 2025-05-26 at 11:24 +0200, Stefan Wahren wrote:
>> Am 26.05.25 um 11:09 schrieb Christoph Stoidner:
>>> Hi Stefan,
>>>
>>> On Mo, 2025-05-26 at 08:44 +0200, Stefan Wahren wrote:
>>>> Hi Andrew,
>>>> hi Christoph
>>>>
>>>> Am 24.05.25 um 19:44 schrieb Andrew Lunn:
>>>>>> diff --git a/arch/arm64/boot/dts/freescale/imx93-phycore-
>>>>>> som.dtsi
>>>>>> b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
>>>>>> index 88c2657b50e6..b481097f08a4 100644
>>>>>> --- a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
>>>>>> @@ -68,6 +68,8 @@ mdio: mdio {
>>>>>>      ethphy1: ethernet-phy@1 {
>>>>>>      compatible = "ethernet-phy-ieee802.3-c22";
>>>>>>      reg = <1>;
>>>>>> + reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
>>>>>> + reset-assert-us = <30>;
>>>>> Is there anything in the datasheet about needing a delay after
>>>>> the
>>>>> reset? There is a DT property for this:
>>>>>
>>>>>      reset-deassert-us:
>>>>>        description:
>>>>>          Delay after the reset was deasserted in microseconds.
>>>>> If
>>>>>          this property is missing the delay will be skipped.
>>>> is it the time until the PHY finished its post reset
>>>> stabilization
>>>> (datasheet to call it T2 "reset to SMI ready")?
>>> The T2 ("Post reset stabilization time") in the datasheet is the
>>> time
>>> "prior to MDC preamble for register access", that is defined with
>>> 2ms.
>>> I did not use reset-deassert-us for it, because the first register
>>> access does anyway occur much later (I measured 4000ms).
Just to be sure, do you really mean 4000 milliseconds ?
>>>
>>> And we have the same for T4, the "Post power-up stabilization
>>> time".
>>> It is defined with a time of 50ms as "prior to MDC preamble for
>>> register access". But also here we just know, the register access
>>> happens much later - and treated it as enough.
>>>
>>> Formally, this may be valid to specify the 2ms as reset-deassert-
>>> us.
>>> But since the first register access is so much later, I thought we
>>> can
>>> save those 2ms.
>>>
>>> Are you fine with that?
>> I don't insist on an additional "reset-deassert-us". The question was
>> more about understanding.
> Great, thanks for thr feedback.
>
>>> Regards,
>>> Christoph
>>>
>>>
>>>>> Anyway:
>>>>>
>>>>> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>>>>>
>>>>>        Andrew
>>>>>

Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Christoph Stoidner]

On Mo, 2025-05-26 at 14:14 +0200, Stefan Wahren wrote:
> Am 26.05.25 um 12:04 schrieb Christoph Stoidner:
> > On Mo, 2025-05-26 at 11:24 +0200, Stefan Wahren wrote:
> > > Am 26.05.25 um 11:09 schrieb Christoph Stoidner:
> > > > Hi Stefan,
> > > > 
> > > > On Mo, 2025-05-26 at 08:44 +0200, Stefan Wahren wrote:
> > > > > Hi Andrew,
> > > > > hi Christoph
> > > > > 
> > > > > Am 24.05.25 um 19:44 schrieb Andrew Lunn:
> > > > > > > diff --git a/arch/arm64/boot/dts/freescale/imx93-phycore-
> > > > > > > som.dtsi
> > > > > > > b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
> > > > > > > index 88c2657b50e6..b481097f08a4 100644
> > > > > > > --- a/arch/arm64/boot/dts/freescale/imx93-phycore-
> > > > > > > som.dtsi
> > > > > > > +++ b/arch/arm64/boot/dts/freescale/imx93-phycore-
> > > > > > > som.dtsi
> > > > > > > @@ -68,6 +68,8 @@ mdio: mdio {
> > > > > > >      ethphy1: ethernet-phy@1 {
> > > > > > >      compatible = "ethernet-phy-ieee802.3-c22";
> > > > > > >      reg = <1>;
> > > > > > > + reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
> > > > > > > + reset-assert-us = <30>;
> > > > > > Is there anything in the datasheet about needing a delay
> > > > > > after
> > > > > > the
> > > > > > reset? There is a DT property for this:
> > > > > > 
> > > > > >      reset-deassert-us:
> > > > > >        description:
> > > > > >          Delay after the reset was deasserted in
> > > > > > microseconds.
> > > > > > If
> > > > > >          this property is missing the delay will be
> > > > > > skipped.
> > > > > is it the time until the PHY finished its post reset
> > > > > stabilization
> > > > > (datasheet to call it T2 "reset to SMI ready")?
> > > > The T2 ("Post reset stabilization time") in the datasheet is
> > > > the
> > > > time
> > > > "prior to MDC preamble for register access", that is defined
> > > > with
> > > > 2ms.
> > > > I did not use reset-deassert-us for it, because the first
> > > > register
> > > > access does anyway occur much later (I measured 4000ms).
> Just to be sure, do you really mean 4000 milliseconds ?
> 
Yes, that's what I measured. For analysis, I added some debug outputs
to
the phy reset and the 1st phy register access. And as I can see, the
phy register access happens when userland sets up the network:


       [   1.723298] DEB-PHY: mdio reset exeucted
       ...
       ...
       ...
       [  OK  ] Started Network Configuration.
       [   5.792705] DEB-PHY: register access


The calculated delta of 4,069407 seconds fits to what I measured with
the oscilloscope (4040ms).

Regards,
Christoph


> > > > 
> > > > And we have the same for T4, the "Post power-up stabilization
> > > > time".
> > > > It is defined with a time of 50ms as "prior to MDC preamble for
> > > > register access". But also here we just know, the register
> > > > access
> > > > happens much later - and treated it as enough.
> > > > 
> > > > Formally, this may be valid to specify the 2ms as reset-
> > > > deassert-
> > > > us.
> > > > But since the first register access is so much later, I thought
> > > > we
> > > > can
> > > > save those 2ms.
> > > > 
> > > > Are you fine with that?
> > > I don't insist on an additional "reset-deassert-us". The question
> > > was
> > > more about understanding.
> > Great, thanks for thr feedback.
> > 
> > > > Regards,
> > > > Christoph
> > > > 
> > > > 
> > > > > > Anyway:
> > > > > > 
> > > > > > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> > > > > > 
> > > > > >        Andrew
> > > > > > 
> 

Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Andrew Lunn]

> Yes, that's what I measured. For analysis, I added some debug outputs
> to
> the phy reset and the 1st phy register access. And as I can see, the
> phy register access happens when userland sets up the network:

Please repeat the measurements with NFS root.

You will find that the kernel brings the interface up right have
register_netdev() is called, and starts transmitting. It can happen
before register_netdev() even returns.

	Andrew

Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Christoph Stoidner]

On Mi, 2025-05-28 at 21:29 +0200, Andrew Lunn wrote:
> > Yes, that's what I measured. For analysis, I added some
> > debug outputs
> > to
> > the phy reset and the 1st phy register access. And as I can see,
> > the
> > phy register access happens when userland sets up the network:
> 
> Please repeat the measurements with NFS root.
> 
> You will find that the kernel brings the interface up right have
> register_netdev() is called, and starts transmitting. It can happen
> before register_netdev() even returns.

Thanks for that hint. As you said, with nfs root the register access
happens much earlier. I measured:

       [   1.713185] DEB-PHY: mdio reset exeucted
       ...
       ...
       ...
       [   2.672892] DEB-PHY: register access

However, the delta time of 0.959707s (9597ms) still meets the T2
("prior to MDC preamble for register access") that is defined in the
PHY's datasheet with 2ms.

Seems to be fine from my point of view.

Regards,
Christoph

> 
>  Andrew

Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Andrew Lunn]

On Fri, May 30, 2025 at 01:40:38PM +0000, Christoph Stoidner wrote:
> 
> 
> On Mi, 2025-05-28 at 21:29 +0200, Andrew Lunn wrote:
> > > Yes, that's what I measured. For analysis, I added some
> > > debug outputs
> > > to
> > > the phy reset and the 1st phy register access. And as I can see,
> > > the
> > > phy register access happens when userland sets up the network:
> > 
> > Please repeat the measurements with NFS root.
> > 
> > You will find that the kernel brings the interface up right have
> > register_netdev() is called, and starts transmitting. It can happen
> > before register_netdev() even returns.
> 
> Thanks for that hint. As you said, with nfs root the register access
> happens much earlier. I measured:
> 
>        [   1.713185] DEB-PHY: mdio reset exeucted
>        ...
>        ...
>        ...
>        [   2.672892] DEB-PHY: register access
> 
> However, the delta time of 0.959707s (9597ms) still meets the T2
> ("prior to MDC preamble for register access") that is defined in the
> PHY's datasheet with 2ms.

I agree it is long enough, but i'm also surprised how slow the kernel
was. Are you using a fixed IP address, or dhcp?

	Andrew

Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Christoph Stoidner]

Hi Andrew,

On Mo, 2025-06-02 at 04:09 +0200, Andrew Lunn wrote:
> On Fri, May 30, 2025 at 01:40:38PM +0000, Christoph Stoidner wrote:
> > 
> > 
> > On Mi, 2025-05-28 at 21:29 +0200, Andrew Lunn wrote:
> > > > Yes, that's what I measured. For analysis, I added some
> > > > debug outputs
> > > > to
> > > > the phy reset and the 1st phy register access. And as I can
> > > > see,
> > > > the
> > > > phy register access happens when userland sets up the network:
> > > 
> > > Please repeat the measurements with NFS root.
> > > 
> > > You will find that the kernel brings the interface up right have
> > > register_netdev() is called, and starts transmitting. It can
> > > happen
> > > before register_netdev() even returns.
> > 
> > Thanks for that hint. As you said, with nfs root the register
> > access
> > happens much earlier. I measured:
> > 
> >        [   1.713185] DEB-PHY: mdio reset exeucted
> >        ...
> >        ...
> >        ...
> >        [   2.672892] DEB-PHY: register access
> > 
> > However, the delta time of 0.959707s (9597ms) still meets the T2
> > ("prior to MDC preamble for register access") that is defined in
> > the
> > PHY's datasheet with 2ms.
> 
> I agree it is long enough, but i'm also surprised how slow the kernel
> was. Are you using a fixed IP address, or dhcp?

I use a fixed IP address.

But isn't the bringup of ethernet+phy interface one of the last things
that happens during the kernel boot-up?

When I boot my system from sd-card, I can see that mounting the rootfs
on the sdcard occurs at about 2500ms after kernel start:

      [    0.000000] Booting Linux on physical CPU 0x0000000000 ...
                ...
                ...
                ...
      [    2.538013] EXT4-fs (mmcblk1p2): mounted filesystem a500e519-
d77b-471c-8215-e4f51236aaaa r/w with ordered data mode. Quota mode:
none.
      [    2.550189] VFS: Mounted root (ext4 filesystem) on device
179:98.
      [    2.556871] devtmpfs: mounted
      [    2.562733] Freeing unused kernel memory: 4032K

And thats very near to what I saw with NFS root (to remember: 2672ms
from kernel start). So I feel that patch itself and its corresponding 
measured timings are valid.

However, what timing would you expect?

Thanks, 
Christoph

> 
>  Andrew

Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Andrew Lunn]

> > I agree it is long enough, but i'm also surprised how slow the kernel
> > was. Are you using a fixed IP address, or dhcp?
> 
> I use a fixed IP address.
> 
> But isn't the bringup of ethernet+phy interface one of the last things
> that happens during the kernel boot-up?

Mounting the rootfs is somewhat towards the end of the core
kernel. But if you have an initramfs, there can be modules loaded both
before and afterwards, and once the rootfs has been mounted, yet more
modules can be loaded.

> However, what timing would you expect?

I've seen interfaces configured up from deep within
register_netdev(). I don't remember the exact configuration, but i
thought it was NFS root. It might be in combination with initramfs. If
you have the Ethernet driver as a module in the initramfs, and are
using the "rootwait" option, it could be that you are already past the
point it would first mount the rootfs, and with every new device
popping into existence it is trying to see if the just created device
allows it to do the mount. At that point, register_netdev() is going
to trigger actions.

	Andrew

Re: [Upstream] Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Primoz Fiser]

Hi all,

is there something holding up this patch?

BR,
Primoz

On 2. 06. 25 14:26, Andrew Lunn wrote:
>>> I agree it is long enough, but i'm also surprised how slow the kernel
>>> was. Are you using a fixed IP address, or dhcp?
>>
>> I use a fixed IP address.
>>
>> But isn't the bringup of ethernet+phy interface one of the last things
>> that happens during the kernel boot-up?
> 
> Mounting the rootfs is somewhat towards the end of the core
> kernel. But if you have an initramfs, there can be modules loaded both
> before and afterwards, and once the rootfs has been mounted, yet more
> modules can be loaded.
> 
>> However, what timing would you expect?
> 
> I've seen interfaces configured up from deep within
> register_netdev(). I don't remember the exact configuration, but i
> thought it was NFS root. It might be in combination with initramfs. If
> you have the Ethernet driver as a module in the initramfs, and are
> using the "rootwait" option, it could be that you are already past the
> point it would first mount the rootfs, and with every new device
> popping into existence it is trying to see if the just created device
> allows it to do the mount. At that point, register_netdev() is going
> to trigger actions.
> 
> 	Andrew
> _______________________________________________
> upstream mailing list -- upstream@lists.phytec.de
> To unsubscribe send an email to upstream-leave@lists.phytec.de

-- 
Primoz Fiser
phone: +386-41-390-545
email: primoz.fiser@norik.com
--
Norik systems d.o.o.
Your embedded software partner
Slovenia, EU
phone: +386-41-540-545
email: info@norik.com

Re: [Upstream] Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Christoph Stoidner]

On Di, 2025-07-08 at 10:35 +0200, Primoz Fiser wrote:
> Hi all,
> 
> is there something holding up this patch?

I dont see any blocker.
@Maintainers: If there is any missing/blocking point, could you
please comment.

Thanks,
Christoph

> 
> BR,
> Primoz
> 
> On 2. 06. 25 14:26, Andrew Lunn wrote:
> > > > I agree it is long enough, but i'm also surprised how slow the
> > > > kernel
> > > > was. Are you using a fixed IP address, or dhcp?
> > > 
> > > I use a fixed IP address.
> > > 
> > > But isn't the bringup of ethernet+phy interface one of the last
> > > things
> > > that happens during the kernel boot-up?
> > 
> > Mounting the rootfs is somewhat towards the end of the core
> > kernel. But if you have an initramfs, there can be modules loaded
> > both
> > before and afterwards, and once the rootfs has been mounted, yet
> > more
> > modules can be loaded.
> > 
> > > However, what timing would you expect?
> > 
> > I've seen interfaces configured up from deep within
> > register_netdev(). I don't remember the exact configuration, but i
> > thought it was NFS root. It might be in combination with initramfs.
> > If
> > you have the Ethernet driver as a module in the initramfs, and are
> > using the "rootwait" option, it could be that you are already past
> > the
> > point it would first mount the rootfs, and with every new device
> > popping into existence it is trying to see if the just created
> > device
> > allows it to do the mount. At that point, register_netdev() is
> > going
> > to trigger actions.
> > 
> >  Andrew
> > _______________________________________________
> > upstream mailing list -- upstream@lists.phytec.de
> > To unsubscribe send an email to upstream-leave@lists.phytec.de
> 

Re: [Upstream] Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Andrew Lunn]

On Fri, Jul 18, 2025 at 05:33:05PM +0000, Christoph Stoidner wrote:
> On Di, 2025-07-08 at 10:35 +0200, Primoz Fiser wrote:
> > Hi all,
> > 
> > is there something holding up this patch?
> 
> I dont see any blocker.
> @Maintainers: If there is any missing/blocking point, could you
> please comment.

This _might_ be broken for NFS root. But that can be fixed when
somebody actually has a problem with it.

	Andrew

Re: [Upstream] Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Christoph Stoidner]

Hello Shawn,

sorry for bothering.

Can you tell me if there's anything missing or wrong with this patch,
or if there's anything else I can do so that it becomes applied?

Thanks and regards,
Christoph

On Fr, 2025-07-18 at 17:33 +0000, Christoph Stoidner wrote:
> On Di, 2025-07-08 at 10:35 +0200, Primoz Fiser wrote:
> > Hi all,
> > 
> > is there something holding up this patch?
> 
> I dont see any blocker.
> @Maintainers: If there is any missing/blocking point, could you
> please comment.
> 
> Thanks,
> Christoph
> 
> > 
> > BR,
> > Primoz
> > 
> > On 2. 06. 25 14:26, Andrew Lunn wrote:
> > > > > I agree it is long enough, but i'm also surprised how slow
> > > > > the
> > > > > kernel
> > > > > was. Are you using a fixed IP address, or dhcp?
> > > > 
> > > > I use a fixed IP address.
> > > > 
> > > > But isn't the bringup of ethernet+phy interface one of the last
> > > > things
> > > > that happens during the kernel boot-up?
> > > 
> > > Mounting the rootfs is somewhat towards the end of the core
> > > kernel. But if you have an initramfs, there can be modules loaded
> > > both
> > > before and afterwards, and once the rootfs has been mounted, yet
> > > more
> > > modules can be loaded.
> > > 
> > > > However, what timing would you expect?
> > > 
> > > I've seen interfaces configured up from deep within
> > > register_netdev(). I don't remember the exact configuration, but
> > > i
> > > thought it was NFS root. It might be in combination with
> > > initramfs.
> > > If
> > > you have the Ethernet driver as a module in the initramfs, and
> > > are
> > > using the "rootwait" option, it could be that you are already
> > > past
> > > the
> > > point it would first mount the rootfs, and with every new device
> > > popping into existence it is trying to see if the just created
> > > device
> > > allows it to do the mount. At that point, register_netdev() is
> > > going
> > > to trigger actions.
> > > 
> > >  Andrew
> > > _______________________________________________
> > > upstream mailing list -- upstream@lists.phytec.de
> > > To unsubscribe send an email to upstream-leave@lists.phytec.de
> > 
> _______________________________________________
> upstream mailing list -- upstream@lists.phytec.de
> To unsubscribe send an email to upstream-leave@lists.phytec.de

Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the phy reset by a gpio

[Shawn Guo]

On Sat, May 24, 2025 at 01:23:15PM +0200, Christoph Stoidner wrote:
> According to the datasheet the phy needs to be held in reset until the
> reference clock got stable. Even though no issue was observed, fix this
> as the software should always comply with the specification.
> 
> Use gpio4 23, which is connected to the phy reset pin. On the same pin
> RX_ER was used before, but this signal is optional and can be dropped.
> 
> Note: This comes into effect with the phyCOREs SOM hardware revision 4.
> In revisions before, this gpio is not connected, and the phy reset is
> managed with the global hardware reset circuit.
> 
> Signed-off-by: Christoph Stoidner <c.stoidner@phytec.de>

Applied, thanks!