[PATCH v2 2/4] net: phy: ksz90x1: Handle ksz9131 LED errata
Quentin Schulz
quentin.schulz at cherry.de
Fri Dec 6 13:41:50 CET 2024
Hi Paul,
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?
>
This patch doesn't change anything or rely on some specific behavior so
I'm of the opinion to merge it. Making the behavior of all MAC drivers
consistent would be nice but has nothing to do with the PHY driver here
I believe.
Cheers,
Quentin
More information about the U-Boot
mailing list