Thread (10 messages) 10 messages, 5 authors, 2025-09-22

Re: [PATCH net v1 1/1] net: usb: asix: forbid runtime PM to avoid PM/MDIO + RTNL deadlock

From: Hubert Wiśniewski <hidden>
Date: 2025-09-17 14:31:46
Also in: linux-usb, lkml, stable

On Wed Sep 17, 2025 at 3:54 PM CEST, Alan Stern wrote:
On Wed, Sep 17, 2025 at 11:54:57AM +0200, Oleksij Rempel wrote:
quoted
Forbid USB runtime PM (autosuspend) for AX88772* in bind.

usbnet enables runtime PM by default in probe, so disabling it via the
usb_driver flag is ineffective. For AX88772B, autosuspend shows no
measurable power saving in my tests (no link partner, admin up/down).
The ~0.453 W -> ~0.248 W reduction on 6.1 comes from phylib powering
the PHY off on admin-down, not from USB autosuspend.

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 affects only AX88772* devices (per-interface in bind). System
sleep/resume is unchanged.
quoted
@@ -919,6 +935,16 @@ static int ax88772_bind(struct usbnet *dev, struct usb_interface *intf)
 	if (ret)
 		goto initphy_err;
 
+	/* Disable USB runtime PM (autosuspend) for this interface.
+	 * Rationale:
+	 * - No measurable power saving from autosuspend for this device.
+	 * - phylink/phylib calls require caller-held RTNL and do MDIO I/O,
+	 *   which is unsafe from USB PM resume paths (possible RTNL already
+	 *   held, USB PM lock held).
+	 * System suspend/resume is unaffected.
+	 */
+	pm_runtime_forbid(&intf->dev);
Are you aware that the action of pm_runtime_forbid() can be reversed by 
the user (by writing "auto" to the .../power/control sysfs file)?
I have tested this. With this patch, it seems that writing "auto" to
power/control has no effect -- power/runtime_status remains "active" and
the device does not get suspended. But maybe there is a way to force the
suspension anyway?
To prevent the user from re-enabling runtime PM, you should call 
pm_runtime_get_noresume() (and then of course pm_runtime_put() or 
equivalent while unbinding).

Alan Stern
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help