Re: [PATCH net v4 0/3] net: phy: smsc: use IRQ + relaxed polling to fix missed link-up

[Oleksij Rempel <o.rempel@pengutronix.de>]

Hi Andrew,

On Fri, Jul 18, 2025 at 03:58:56PM +0200, Andrew Lunn wrote:
> On Mon, Jul 14, 2025 at 11:52:37AM +0200, Oleksij Rempel wrote:
> > This series makes the SMSC LAN8700 (as used in LAN9512 and similar USB
> > adapters) reliable again in configurations where it is forced to 10 Mb/s
> > and the link partner still advertises autonegotiation.
> 
> I've seen a comment from another Maintainer that thinks this is rather
> hackish. I tend to agree, you are adding complexity to the core to
> handle one broken PHY, and a corner case in that PHY. It would be
> better to hide as much of this in the PHY driver.
> 
> I'm wondering if there is a much simpler solution, which does not need
> the core changing. Have the driver dynamically flip between interrupts
> and polling, depending on the link mode.
> 
> Start up in the usual way. If the platform supports interrupts, let
> the core get the interrupt, install the handler and use
> interrupts. Otherwise do polling.
> 
> If .config_aneg() puts the PHY into the broken state, forced to 10
> Mb/s, and interrupts are used, set phydev->irq = PHY_POLL, and call
> phy_trigger_machine() to kick off polling.
> 
> If .config_aneg() is called to take it out of the broken state,
> restore phydev->irq. An additional poll up to one second later should
> not cause any issues.
> 
> I don't think this needs any core code changes.
> 
> Maybe there is an issue with phy_free_interrupt() being called while
> irq has been set to polling? You might be able to use the
> phy_driver.remove() to handle that?

I tried to go this way, but it feels even dirtier. The driver would need
to overwrite phydev->irq and phydev->interrupts, and also care about
proper interrupt (re)configuration. On disconnect, phy_disconnect()
unconditionally calls phy_free_interrupt() if phy_interrupt_is_valid(),
but phy_driver.remove() is invoked too late. This leads to warnings
like:
removing non-empty directory 'irq/210', leaking at least 'usb-001:003:01'

So the driver ends up fighting with core assumptions about IRQ lifetime.

How about a minimal change instead: conditionally call
phy_queue_state_machine() from lan87xx_config_aneg()? That would trigger
a poll in the broken mode without touching phydev->irq or core teardown
paths. Seems less intrusive than rewriting IRQ handling.

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |