Re: [PATCH v1 0/2] pinctrl / 8250_dw: Allow drivers to keep init pinctrl state until first open

Hi Doug,

On Tue, Aug 11, 2026 at 7:00 PM Doug Anderson <[email protected]> wrote:

> I don't _think_ that's what his patches are doing, though? It's only
> changing the transition for drivers that actually call
> pinctrl_keep_init_state(). For any drivers that don't call
> pinctrl_keep_init_state() then the behavior is unchanged.

Aha OK I get it. You're right, the behaviour change will only
affect this one device.

> Furthermore, this would only affect hardware that specifically has an
> "init" state defined.
>
> When brainstorming this with Michał, my thought was that for a certain
> class of drivers we could unconditionally declare: if an "init" state
> is defined for the hardware, the correct time to transition away from
> the "init" state is upon the first device open, not upon completion of
> probe. Specifically, I was thinking that for "bus" drivers (UART, SPI,
> I2C) that the end of probe doesn't really mean that everything is set
> up and pins can be configured normally. It's only after the actual
> endpoint driver (the one using the bus) probes that you can really
> transition off the "init" state.

But why is it such a good idea to alter the core semantics of
"init" and "default" for certain devices instead of just coming up
with some custom state?

git grep pinctrl_lookup_state gives a lot of cases of custom
states, it's a normal thing to do. Maybe not common but whenever
you want something not the usual semantics, use a custom
state.

> > What if this is not good for all devices?
>
> At the moment, I couldn't find any device that the above rules would
> break. Certainly I could have missed something.

No you're right, nothing breaks other than the that for one
instance of a driver the default/init semantics change.
Which isn't elegant IMO, but it works.

> Definitely the things Michał wants to achieve can be done without
> changing the pinctrl core by using named pinctrl states and
> transitioning at the right times.

I think we need to do that. This approach is a hack, it will be
hard for others to understand and lead to a lot of questions
about why this is done and so on. Better use a custom state.

> One of the solutions we looked at
> together was functionally equivalent to what he proposed here: he
> defined a state "unopened" that was a complete copy of "init". At the
> end of probe he transitioned to "unopened" and then later transitioned
> to "default" upon the first open, never to use "unopened" again.

I think you should step back and thing about what state names
are the most relevant for a UART.

Why would you want "unopened"? Just use "default".
The states are just state transitions such as any finite
state machine.

These are perfectly fine semantics:

          open()         close()            open()
"default" ------> "open" -------> "default" ------> "open"

The device core doesn't touch the states after probe()
so the "default" state can be reused without any problems.
No need to have any "unopened" state.

Yours,
Linus Walleij