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
