On Sat, Mar 14, 2026 at 1:37 AM Russell King (Oracle)
[off-list ref] wrote:

On Sat, Mar 14, 2026 at 12:44:56AM +0100, Linus Walleij wrote:

quoted

On Fri, Mar 13, 2026 at 12:08 PM Russell King (Oracle)
[off-list ref] wrote:

quoted

On Fri, Mar 13, 2026 at 11:57:16AM +0100, Christophe Roullier wrote:

quoted

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.

Shouldn't the pin state be restored by the pinctrl layer?

What we have in the device core only applies "init" and "default"
states, and provides these handles for transitioning to "sleep"
and "default" again (like a state machine).

What I was meaning is that - for a driver using the "default" state,
if the hardware loses the pinctrl state during sleep, isn't it the
responsibility of the pinctrl driver to restore the state rather
than leaving it in whatever states it happens to be when the SoC
comes back from suspend?

Aha I understand.

Some pin controllers are aware of the different states from an
electronic point of view, so different states are programmed into
the hardware for suspend/sleep and "active". This programming
can be both implicit (fixed in the pin controller hardware) or
programmable by the operating system. Then a hardware
line tells the pin controller when the system goes to sleep so it
autonomously apply some sleep mode settings to the pins
and reverse this back when waking up. These pin controllers
themselves are "always on", in a specific power domain that
never shuts down so they can keep track of this.

In other cases the pin controller lacks this autonomous ability
and then each driver need to transition its pin state to the
right one when going to sleep and coming back up.

In some further cases the pin controller does some power
management but it's sub-optimal such as leaving I2C bus lines
floating on pull-up when they should be pulled to VDD
to minimize leaks during sleep (for example). The default
is OK but with some pin control state intervention we can do
better, sometimes.

If that is not the case, then don't we have a major issue where
drivers using pinctrl but do not issue any pinctrl calls in the
resume function are buggy?

Sadly, in my experience, the power management features of an
SoC is the last step or an "afterthought" when companies
upstream their changes to the Linux kernel, this comes last
and often never. The code is there in the downstream (vendor)
kernels. Running the mainline kernel works but eats power :(

I think what we see when we do:
$ git grep  pinctrl_pm_select_sleep_state |wc -l
107
are the companies that have actually gotten around to do this
properly and test it. There are some very generic hardware blocks
such as the designware USB controller in that list.

Some SoCs may benefit from autonomous power state control
in the hardware, all ACPI platforms for example, I *think* have
the ambition that firmware/BIOS deals with this and we need not
think about it. For devicetree I think it depends, it's up to the
SoC how much is autonomous and how much needs to be
initiated by the driver.

Yours,
Linus Walleij