On 17.09.25 13:52, Oleksij Rempel wrote:

Hi Oliver,

On Wed, Sep 17, 2025 at 12:10:48PM +0200, Oliver Neukum wrote:

quoted

Hi,

On 17.09.25 11:54, Oleksij Rempel wrote:

quoted

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

This very strongly suggested that the conditional call is the issue.

quoted

quoted

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.

It would maybe good to include a wording like:

With runtime PM, the driver is forced to resume its device while
holding RTNL, if it happens to be suspended. The methods needed
to resume the device take RTNL themselves. Thus runtime PM will deadlock.


	Regards
		Oliver