On Wed, Feb 19, 2025 at 02:47:04PM +1000, James Calligeros wrote:

On Wed, Feb 19, 2025 at 1:33 AM Mark Brown [off-list ref] wrote:

quoted

On Tue, Feb 18, 2025 at 06:35:54PM +1000, James Calligeros wrote:

quoted

I get that the reference counting that the regulator API does is useful
here but this isn't a regulator so shouldn't be exposed as such,
particularly since this winds up being visible in the DT ABI.  I
could've sworn that someone did some helpers for this case but now I go
looking I can't find them, we certainly don't use any in the regulator
core.

From what I recall, no attempt at shared GPIO infrastructure has actually
landed. The multiple {de}assertions of SDZ put each chip on the same line

Yeah, I can't find anything.  Perhaps I was thinking of the reset API,
most of the other users were reset lines so it's plausible someone
started and then just ended up with the reset API instead.

into an unusable state that requires a full power cycle to clear, so
we can't live without
handling the shared GPIO somewhat sensibly.

One alternative off the top of my head is adding a dummy reset controller
to the DTs and integrating it into the ASoC machine driver (which we have
downstream). We could then put the GPIO behind a shared reset line, and hit
that instead of the GPIO. This does seem a little complex/odd, and IIRC we
considered this at some point and decided against it.

I'm not sure that's particularly better than the regulator version TBH,
it's still got the problem of showing up in the device ABI.

Is there any other option that may work here? I'm open to ideas.

Perhaps it's time to bite the bullet and do the shared GPIO API?
regulator could certainly use it (and has a bunch of code, we could
probably just pull that out and wrap an API around it?) and now there's
this too.

You could possibly also open code, but that does beg the question about
the shared API.