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

On Tue, Mar 17, 2026 at 2:11 PM Russell King (Oracle)
[off-list ref] wrote:

On Tue, Mar 17, 2026 at 01:13:14AM +0100, Linus Walleij wrote:

quoted

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