On Mon, Mar 10, 2025 at 05:59:31PM +0100, Fiona Klute wrote:
If a new reset event appears before the previous one has been processed, the device can get stuck into a reset loop. This happens rarely, but blocks the device when it does, and floods the log with messages like the following:
lan78xx 2-3:1.0 enp1s0u3: kevent 4 may have been dropped
The only bit that the driver pays attention to in the interrupt data is "link was reset". If there's a flapping status bit in that endpoint data (such as if PHY negotiation needs a few tries to get a stable link), polling at a slower rate allows the state to settle.
Could you expand on this a little bit more. What is the issue you are seeing?
I had a quick look at the PHY handling code, and it looks broken. The only time a MAC driver should look at members of phydev is during the adjust link callback, so lan78xx_link_status_change(). Everything is guaranteed to be consistent at this time. However, the current lan78xx_link_status_change() only adjusts EEE setting. The PHY code in lan78xx_link_reset() looks wrong. MAC drivers should not be reading PHY registers, or calling functions like phy_read_status(). Setting flow control should be performed in lan78xx_link_status_change() using phydev->pause and phydev->asym_pause.
Andrew