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

[Andy Shevchenko]

On Tue, Aug 11, 2026 at 06:26:53PM -0700, Doug Anderson wrote:
> On Tue, Aug 11, 2026 at 1:15 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote:

...

> FWIW, we are in basically the same situation for SPI on the same
> board. Specifically, this happens:
> 
> 1. Remote side starts unpowered.
> 
> 2. SPI bus driver probes and pinctrl sets SPI pins to their default
> state. Importantly, the SPI chip select (CS_N) is high, which
> backpowers the device (illegal).
> 
> What we need is we need to _assert_ chip select (make CS_N low) until
> we know that the other side is powered.

Isn't this dangerous? Some noise on the bus for whatever reason might produce
undesired "communication".

> ...we can try to use the "init" state that exists today, but by the
> time the SPI's probe function finishes, there is no guarantee that the
> SPI client's probe function has run. The module might not have been
> loaded yet. This means that "init" state (as currently defined)
> doesn't help.
> 
> ...we can't use the "opened" we've been talking about in UART because
> there's no real idea of "open"ing a SPI bus. It's transaction
> oriented.

But any SPI message that is queued is basically an "open" stage. So, it sounds
like SPI core should change pin control states when message is queued and when
it's done. Like be coupled with runtime PM?

> ...we can't use the normal "runtime pm" concept in SPI and start the
> SPI bus in suspended state because the "runtime suspended" state of
> the bus would want the chip select deasserted (CS_N high).

Sounds like a PCB / electrical level of design issue. I would solve this
by gating CS signal using power of the peripheral connected. Have you talked
to your HW engineers about this problem?

> Using an extended "init" state (as in Michał's patch) and
> transitioning to "default" upon the first SPI transfer would work,
> since we'd know that the client is powered by then. After that point
> in time, if the client wanted to power the device off it could
> manually assert "chip select" before powering off.
> 
> Of course, I'll admit that using the extended "init" state like this
> is still a bit ugly, whether doing it like Michał's patch does or by
> doing something like the "unopened" solution that I talked about.
> 
> Other options for SPI could be:
> 
> 1. Hack something into the SPI bus driver to turn on the regulator for
> the device. This is pretty ugly, but would work. Probably not
> upstreamable.
> 
> 2. Invent a "pwrseq" solution for SPI where we run a sequence of steps
> (turning the regulator on) before probing the SPI bus, like other
> "pwrseq" drivers. Of course, most of those are for "discoverable"
> busses, but the idea of powering up a peripheral before probing the
> bus it's on is similar. This seems an extreme amount of work.

Btw, isn't there some development for the undiscoverable buses?

> 3. Hack the "CS GPIO" to be controlled by the client. It looks like we
> could fully move the GPIO (including the pinctrl in the DT) to the
> client. Then the client could call spi_set_csgpiod() after it's turned
> on the regulator. The client could have an "init" state for the GPIO
> that keeps it low and then transition to "default" right before
> calling spi_set_csgpiod().

> Of everything, solution #3 doesn't seem terrible. I also still don't
> totally hate the idea of extending the "init" state... Of course,
> there's also some chance we can figure out other ways to get this
> regulator turned on sooner.

Yes, #3 seems okay, but wouldn't be even better to have some flag in
SPI core or pin control on per message basis (see also above)?

-- 
With Best Regards,
Andy Shevchenko