Re: [PATCH net] net: usb: lan78xx: resume phylink on non-reset USB resume

[Stefano Munari <stefanomunari.sm@gmail.com>]

On Tue, 03 Nov 2026 23:53:35 +0000, Sashiko wrote:
> - [Medium] RTNL self-deadlock.

An open interface holds an autopm reference, so this requires a runtime
resume with a *stale* EVENT_DEV_OPEN, i.e., a failed lan78xx_open().
This error path is fixed separately, moved to net-next per Andrew's review
since the failure is considered theoretical:

https://lore.kernel.org/netdev/20261102211119.8738-1-stefanomunari.sm@gmail.com
https://lore.kernel.org/netdev/1449a6a1-670c-4d1d-bb98-51f92e32d848@lunn.ch

On system resume lan78xx_resume() is not called with RTNL held, so
taking rtnl_lock() is safe there.

> - [Medium] Self-hang caused by re-entering runtime PM from inside the
>   USB resume callback.

Same precondition as above. The hang needs lan78xx_resume() to run
inside a runtime resume, with the interface still RPM_SUSPENDED. An
open interface holds an autopm reference, so its runtime PM status stays
RPM_ACTIVE across system sleep. On system resume the nested
usb_autopm_get_interface() from the MDIO accessors therefore only bumps
the usage count and returns immediately.

> - [Medium] On a normal (non-reset) resume, phylink is now restarted
>   after the MAC datapaths are already enabled.

Pre-existing on the reset_resume path, can be a follow-up.

> - [High] This problem wasn't introduced by this patch, but
>   lan78xx_suspend() inverts the lock order.

Pre-existing, can be a follow-up. An actual deadlock needs a
non-freezable RTNL holder opening or closing this interface during
system suspend: very unlikely in practice. In the commit message,
"mirroring lan78xx_suspend()" refers only to the dev_open condition.

Stefano