Re: [PATCH v2 1/2] net: stmmac: fix pinctrl management during suspend/resume

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Thu, Mar 19, 2026 at 10:43:25AM +0100, Linus Walleij wrote:
> On Tue, Mar 17, 2026 at 2:11 PM Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> > I'm trying to get an answer on this, because the original patch
> > description here says:
> >
> > | In the deepest low-power modes, the pinctrl configuration is
> > | lost and is never restored if the interface is down.
> >
> > stmmac uses the "default" pinctrl state at probe time. This commit
> > says that is lost over suspend/resume - which to me sounds like
> > a pinctrl driver bug, because on resume, the pinctrl driver is not
> > ensuring that the pinctrl state is restored to whatever it was when
> > the suspend happened (whether the driver explicitly changed it or
> > not.)
> >
> > To put it another way...
> >
> > On entry to probe for a non-pinctrl driver, if DT describes a default
> > pinctrl state, that state will be selected by core code.
> >
> > On suspend, the driver is free to select another state if it so wishes,
> > or do nothing (e.g. it's unaware of pinctrl.)
> >
> > On resume, the pinctrl layer, what is expected to happen. Surely, it
> > is reasonable for a pinctrl unaware driver, or at least a driver which
> > has _not_ changed the pinctrl state to expect that the default pinctrl
> > state is still in effect when its resume function is called - and if
> > that is not the case, then there's a bug here.
> >
> > Another way to put it...
> >
> > We shouldn't be expecting device drivers to have to mess with pinctrl
> > e.g. switching to a sleep state and then back to a default state just
> > to have pinctrl settings restored to a functional state on resume.
> 
> OK I see your point, the pinctrl hardware state should not change
> behind the back of the driver, and if it does, and that is worked
> around by these calls to restore the state using the pinctrl PM
> helpers become a messy quirk.
> 
> - Selecting those states to reconfigure pins into special modes
>   during sleep is OK.
> 
> - Selecting those states to restore the hardware state inside the
>   pin controller itself is NOT OK.
> 
> If this is done for the latter reason, you're right of course, there is
> a bug in the pin controller. Certainly it is expected to maintain its
> own state over a suspend/resume cycle.

Thanks for the clarification. So, going back to the original patch:

"In the deepest low-power modes, the pinctrl configuration is lost
 and is never restored if the interface is down.
 This commit ensures that the pinctrl state is set in all cases."

This commit message seems to be suggesting that the switch to sleep
mode and back to default mode is to ensure that the pinctrl driver
for this platform correctly re-sets the pinctrl state back to the
default state - which suggests that this patch is the wrong approach
and there is a bug somewhere in the pin controller layer.

That said, for platforms that do provide a sleep state for stmmac, it
makes sense to switch the pinctrl to that state even when the netif
is down. So, I think there's actually two separate issues:

1. the pin controller not restoring the state that was set at suspend.

2. not switching to sleep state when supported when the netif is down.

and fixing (2) will mask (1) which will be bad. So, I think (1) needs
to be fixed first while we have an easy-to-test case, and my suggested
replacement patch is a better approach for (2).

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!