Hi Oliver,
On Wed, Sep 17, 2025 at 12:10:48PM +0200, Oliver Neukum wrote:
Hi,
On 17.09.25 11:54, Oleksij Rempel wrote:
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. Given the lack of benefit and poor test coverage (autosuspend is usually disabled by default in distros), forbid runtime PM here to avoid these hazards.
This reasoning depends on netif_running() returning false during system resume. Is that guaranteed?
You’re right - there is no guarantee that netif_running() is false during system resume. This change does not rely on that. If my wording suggested otherwise, I’ll reword the commit message to make it explicit.
1) Runtime PM (autosuspend/autoresume)
Typical chain when user does ip link set dev <if> up while autosuspended: rtnl_newlink (RTNL held) -> __dev_open -> usbnet_open -> usb_autopm_get_interface -> __pm_runtime_resume -> usb_resume_interface -> asix_resume
Here resume happens synchronously under RTNL (and with USB PM locking). If the driver then calls phylink/phylib from resume (caller must hold RTNL; MDIO I/O), we can deadlock or hit PM-lock vs MDIO wake issues.
Patch effect: I forbid runtime PM per-interface in ax88772_bind(). This removes the synchronous autoresume path.
2) System suspend/resume
Typical chain: ... dpm_run_callback (workqueue) -> usb_resume_interface -> asix_resume
This is not under RTNL, and no pm_runtime locking is involved. The patch does not change this path and makes no assumption about netif_running() here.
If helpful, I can rework the commit message.
Best Regards, Oleksij