Hi Lukas,
On Wed, Sep 17, 2025 at 08:58:17PM +0200, Lukas Wunner wrote:
On Wed, Sep 17, 2025 at 11:54:57AM +0200, Oleksij Rempel wrote:
Forbid USB runtime PM (autosuspend) for AX88772* in bind.
[...]
With autosuspend active, resume paths may require calling phylink/phylib (caller must hold RTNL) and doing MDIO I/O. Taking RTNL from a USB PM resume can deadlock (RTNL may already be held), and MDIO can attempt a runtime-wake while the USB PM lock is held.
FWIW, for smsc95xx.c, the MDIO deadlock issue was resolved by commit 7b960c967f2a ("usbnet: smsc95xx: Fix deadlock on runtime resume"). I would assume that something similar would be possible for asix_devices.c as well.
thanks for the recommendation.
Right now I’m juggling two goals: - Stable: provide a simple and robust fix with minimal risk. - net-next: design a clean and reliable solution that keeps autosuspend working.
For -stable, keeping autosuspend disabled per AX88772* seems to be the most straightforward and low-risk way to avoid the problematic autoresume path. Autosuspend isn’t on by default in most distros anyway, so the behavioral impact is minimal.
If we keep autosuspend enabled, the driver has to be careful about multiple contexts: - Runtime PM callbacks: asix_{suspend,resume,reset_resume} running under the USB PM lock.
- System sleep/resume: asix_resume() via dpm_run_callback() workqueues (no pm_runtime involved).
- ndo_open() path (RTNL held): usbnet_open() -> usb_autopm_get_interface() -> synchronous autoresume into asix_resume().
- ethtool / netlink control paths: often under RTNL, may trigger autoresume and/or MDIO via phylib.
- phylink/MAC ops: may touch MDIO; caller is expected to hold RTNL.
- status URB / NAPI: atomic/BH context (no sleeping, no RTNL).
If maintainers prefer attempting the smsc95xx-style change right away, I can draft it; my preference for -stable is still the minimal forbid to limit churn.
Best Regards, Oleksij