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

[Paolo Abeni]

On 10/5/26 21:09, 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.
>
> For MAC WoL, finish the deferred link-down and clear the WoL disable bit.
> Otherwise, avoid repeating PHY, SFP and PCS shutdown, but suspend a PHY
> that prepare_resume() powered up for the MAC reset clock.
>
> Retain the saved link state if MAC WoL is suspended again after a failed
> resume. For example, fbnic can fail to allocate IRQs on resume and call
> phylink_suspend() again on the next system suspend. The carrier is already
> off, so taking another snapshot loses the deferred mac_link_down(). Keep
> the original snapshot until resume or stop completes, allowing the next
> suspend cycle to capture the new link state.
>
> Do not enter MAC WoL suspend on an already stopped instance. The wake
> policy can change between a failed resume and the next suspend, for
> example when fbnic learns a different BMC presence from firmware. Setting
> MAC_WOL alongside STOPPED would leave stop/start gated by MAC_WOL, while
> resume would take the MAC-only path without restarting the PHY, SFP or
> PCS. Keep the stopped state so resume performs the required full start.
>
> Restore any PHY advertisement reduced by suspend. Track that reduction
> separately from explicit driver speed-down requests, so stopping a
> suspended instance does not undo a driver's close-time power saving.
>
> Fixes: f97493657c63 ("net: phylink: add suspend/resume support")
> Fixes: 4c8925cb9db1 ("net: phylink: fix suspend/resume with WoL enabled and link down")
> Signed-off-by: James Hilliard <james.hilliard1@xxxxxxxxx>
This needs an explicit ack from the phy crew. Also I understand this
is a pre-req for another fix; if so it would be probably better see
both at the same time/in the same series.

/P