Re: [PATCH net v2] net: phylink: allow stopping a suspended instance

[James Hilliard]

On Wed, Oct 14, 2026 at 11:13 AM Andrew Lunn <andrew@xxxxxxx> wrote:
>
> On Wed, Oct 14, 2026 at 11:07:27AM -0600, James Hilliard wrote:
> > On Wed, Oct 14, 2026 at 10:02 AM Andrew Lunn <andrew@xxxxxxx> wrote:
> > >
> > > On Tue, Oct 13, 2026 at 01:46:24PM -0600, James Hilliard wrote:
> > > > On Mon, Oct 12, 2026 at 7:22 PM Andrew Lunn <andrew@xxxxxxx> wrote:
> > > > >
> > > > > On Mon, Oct 05, 2026 at 01:09:05PM -0600, James Hilliard wrote:
> > > > > > After a failed MAC resume, a driver must be able to stop phylink without
> > > > > > resuming it and reconfiguring the failed MAC. This is needed when recovery
> > > > > > leaves the interface administratively up but detached until a subsequent
> > > > > > down/up: ndo_stop() must finish the suspended phylink lifetime even though
> > > > > > the MAC could not be restored. The missing transition was identified by
> > > > > > code inspection of the stmmac recovery paths.
> > > > >
> > > > > I don't particularly like this. It feels like a workaround for a
> > > > > broken MAC. It would be better to fix the MAC so that resume does not
> > > > > fail.
> > > >
> > > > Fixing an identified cause of resume failure belongs in the MAC
> > > > driver. The intended purpose here is narrower: allow orderly shutdown
> > > > after the driver has returned an error, rather than recover the MAC
> > > > through phylink.
> > > >
> > > > stmmac_resume() already returns before phylink_resume() when hardware
> > > > setup fails.
> > >
> > > But why did the hardware setup fail?
> >
> > The exercised failure was injected, rather than a diagnosed spontaneous
> > MAC fault. This change comes from auditing the existing error paths for
> > the deferred stmmac recovery fix.
> >
> > > This is what i mean about it being a workaround.
> >
> > The deferred fix addresses a separate software failure: suspend has
> > already disabled NAPI, but an unsuccessful resume leaves the interface
> > administratively up.
>
> But why was the resume unsuccessful?

There is an independently reported case where resume cannot happen:
an ASIX USB Ethernet adapter unplugged while the system is suspended.

Xu Yang reported this on an i.MX93 EVK, with a warning and call trace
showing phy_stop() called from PHY_HALTED through phylink_stop(),
ax88772_stop(), usbnet_stop() and usbnet_disconnect().[1]

The sequence is:

- Suspend calls phylink_suspend(false), which stops the PHY.
- The adapter is physically removed while suspended.
- USB core skips the disconnected interface's resume callback.
- Disconnect unregisters the netdev, whose stop callback calls
phylink_stop() on the still-suspended instance.

That call sequence remains in the current code. Successful MAC resume
is not an option once the device has been removed.

There is also an existing resume failure path in UCC GETH. On
CONFIG_PPC_85xx, resume rebuilds the controller resources, including RX
buffers allocated using netdev_alloc_skb(). That helper uses GFP_ATOMIC,
so allocation can fail under memory pressure without a hardware fault.

The allocation failure propagates through ucc_geth_startup() to
ucc_geth_init_mac(), whose error cleanup calls ucc_geth_stop() and then
phylink_stop(). With non-MAC-WoL suspend, the PHY was already stopped.
This reaches the transition directly during resume error cleanup,
without the deferred stmmac changes. This second case is from code
inspection, not a hardware reproduction.

These are independent of the injected stmmac failure discussed earlier.
The USB case provides an existing hardware report of why shutdown may
need to proceed without a matching resume.

The earlier discussion favored handling that case in usbnet.[2] That
is a separate question about where to handle the transition, rather
than whether the transition occurs in practice.

These examples most directly support avoiding repeated shutdown of an
already-stopped instance.

[1] https://lore.kernel.org/r/20250806083017.3289300-1-xu.yang_2@xxxxxxx/
[2] https://lore.kernel.org/r/1c352c2f-c8b3-4cbe-9921-8ba5f0e4b433@xxxxxxx/

> Sorry, but i've asked this multiple times. You never give a good
> answer, so i'm just going to:
>
> NACK.
>
>         Andrew