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