Re: [PATCH 0/2] pps-gpio: restore pin mux on unbind and shutdown

[Rodolfo Giometti <giometti@enneenne.com>]

On 16/09/2026 15:47, Eliav Farber wrote:
> This series lets pps-gpio select an optional "idle" pinctrl state in
> remove() and shutdown(), so a board can describe the alternate mux there
> and have it restored. It is a no-op for boards that do not describe an
> "idle" state, and depends on CONFIG_PM (which performs the idle-state
> lookup).

Thanks, the problem is real: the pinctrl core never reverts the mux on
unbind, so the pins stay stuck in the GPIO function for whatever comes
next, kexec included.

But "idle" does not mean "not bound", so are you sure this is the
right-thing(TM) to do? pinctrl-state.h documents it as the runtime PM
state and, AFAIK, that is how the rest of the tree uses it. If pps-gpio
ever grows a real runtime PM or a .suspend(), "idle" is already taken
with another meaning -- and 1/2 turns that choice into ABI.

Same question for the CONFIG_PM dependency: why should a CONFIG_PM=n
kernel not get this? A PPS box built without PM is not an odd
configuration, and there the board describes an "idle" state and
nothing happens, silently.

Wouldn't looking the state up in the driver (devm_pinctrl_get() +
pinctrl_lookup_state() + pinctrl_select_state()) avoid both, and leave
you free to pick a name that says what it means?

One thing that does not depend on any of the above: your shutdown()
changes the mux but shuts nothing down. The IRQ is still requested
(request_irq() here is not devm-managed) and the echo timer may still
be armed, so a timer callback can still poke a pin that by then belongs
to somebody else, and the PPS handler stays attached to a line that
other function is now driving. And device_shutdown() is not the end of
the road: the kernel keeps running to load and start the kexec image,
which is the case you are after. Shouldn't it tear down in the same
order remove() does, free_irq() and timer_delete_sync() first and the
mux change last?

Ciao,

Rodolfo