[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 at 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 at lunn.ch>
>>>
>>>       Andrew
>>>