Am 26.05.25 um 11:09 schrieb Christoph Stoidner:

Hi Stefan,

On Mo, 2025-05-26 at 08:44 +0200, Stefan Wahren wrote:

quoted

Hi Andrew,
hi Christoph

Am 24.05.25 um 19:44 schrieb Andrew Lunn:

quoted

quoted

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

quoted

quoted

Anyway:

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

      Andrew