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

[Linus Walleij]

On Tue, Mar 17, 2026 at 2:11 PM Russell King (Oracle)
<linux@xxxxxxxxxxxxxxx> wrote:
> On Tue, Mar 17, 2026 at 01:13:14AM +0100, Linus Walleij wrote:

> > Aha I understand.
>
> I'm not so sure.

OK let's hash it out.

> 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.

Yours,
Linus Walleij