linux-kernel - Re: [PATCH v2 20/29] ASoC: tas2764: Add SDZ regulator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z7aJS_uq75aKLCht@finisterre.sirena.org.uk>
Date: Thu, 20 Feb 2025 01:45:47 +0000
From: Mark Brown <broonie@...nel.org>
To: James Calligeros <jcalligeros99@...il.com>
Cc: Liam Girdwood <lgirdwood@...il.com>, Jaroslav Kysela <perex@...ex.cz>,
	Takashi Iwai <tiwai@...e.com>, Shenghao Ding <shenghao-ding@...com>,
	Kevin Lu <kevin-lu@...com>, Baojun Xu <baojun.xu@...com>,
	Dan Murphy <dmurphy@...com>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Shi Fu <shifu0704@...ndersoft.com>,
	Jean Delvare <jdelvare@...e.com>,
	Guenter Roeck <linux@...ck-us.net>,
	Alyssa Rosenzweig <alyssa@...enzweig.io>,
	Martin Povišer <povik+lin@...ebit.org>,
	Hector Martin <marcan@...can.st>, linux-sound@...r.kernel.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	asahi@...ts.linux.dev, linux-hwmon@...r.kernel.org,
	Neal Gompa <neal@...pa.dev>
Subject: Re: [PATCH v2 20/29] ASoC: tas2764: Add SDZ regulator

On Wed, Feb 19, 2025 at 02:47:04PM +1000, James Calligeros wrote:
> On Wed, Feb 19, 2025 at 1:33 AM Mark Brown <broonie@...nel.org> wrote:
> > On Tue, Feb 18, 2025 at 06:35:54PM +1000, James Calligeros wrote:

> > 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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)