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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aMqw4LuoTTRspqfA@pengutronix.de>
Date: Wed, 17 Sep 2025 15:00:16 +0200
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Andrew Lunn <andrew@...n.ch>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	kernel@...gutronix.de, linux-kernel@...r.kernel.org,
	Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
	Andre Edich <andre.edich@...rochip.com>,
	Lukas Wunner <lukas@...ner.de>
Subject: Re: [PATCH net v4 0/3] net: phy: smsc: use IRQ + relaxed polling to
 fix missed link-up

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 |