[PATCH v2 2/4] net: phy: ksz90x1: Handle ksz9131 LED errata

[Marek Vasut]

On 12/5/24 7:58 PM, Paul Barker wrote:
> Hi Marek, Quentin,
> 
> On 01/12/2024 18:57, Marek Vasut wrote:
>> On 11/25/24 6:23 PM, Quentin Schulz wrote:
>>
>> [...]
>>
>>>> @@ -446,6 +474,10 @@ static int ksz9131_config(struct phy_device *phydev)
>>>>                return ret;
>>>>        }
>>>> +    ret = ksz9131_led_errata(phydev);
>>>> +    if (ret < 0)
>>>> +        return ret;
>>>> +
>>>
>>> This seems to work but is happening a bit late.
>>>
>>> Indeed, I need something to call the network stack for this to be
>>> happening. Meaning until I e.g. run `dhcp` in the CLI, the LED is still
>>> following the bad behavior.
>>>
>>> I assume we cannot use the probe() callback for writing to registers?
>> I'm afraid there is an inconsistency between U-Boot MAC drivers and when
>> they configure the PHY. This is well visible on MX8MP, which has both
>> FEC and EQoS/DWMAC MACs and they behave differently in this aspect. The
>> question is, whether it makes sense to initialize the PHY before the MAC
>> has been used, probably no, because that brings up hardware and adds to
>> boot time. But at least aligning the behavior of the various MAC drivers
>> would be nice.
> 
> Is there anything we can do in this driver to fix this?
> 
> Or should we merge this as-is and improve the MAC drivers later?
I'd say merge it for 2025.04 , since this is an errata fix, but it would 
also be able to clean up the MAC driver mess eventually.