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.
