linux-kernel - Re: [PATCH v2 0/4] gpio: deprecate and track the removal of GPIO workarounds for regulators

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <c16d3116-256d-470d-96dd-7f3dbe3334c3@sirena.org.uk>
Date: Mon, 7 Apr 2025 14:24:38 +0100
From: Mark Brown <broonie@...nel.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Linus Walleij <linus.walleij@...aro.org>, linux-gpio@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v2 0/4] gpio: deprecate and track the removal of GPIO
 workarounds for regulators

On Mon, Apr 07, 2025 at 03:15:13PM +0200, Bartosz Golaszewski wrote:
> On Wed, Apr 2, 2025 at 4:08 PM Mark Brown <broonie@...nel.org> wrote:

> > > I believe pwrseq could actually be used to hide the enable counting
> > > for GPIOs behind a faux GPIO chip and the consumer would never see a
> > > pwrseq handle - they would instead use GPIO consumer interfaces and
> > > we'd have to agree on what logic would we put behind gpiod_set_value()
> > > (should it effectively work as gpiod_enable() meaning: value is 1 as
> > > long as at least one user sets it to 1?) and
> > > gpiod_direction_input()/output() (same thing: highest priority is
> > > gpiod_direction_output(HIGH) and as long as at least one user sets it
> > > as such, we keep it).

> > Like I say that doesn't do the right thing since other users need to be
> > able to see when something changes on the GPIO.  If that just happens on
> > normal gpiolib then that complicates usage for the default case since
> > they now have to worry about things not actually happening when
> > requested which doesn't seem ideal.

> If I understand correctly, regulator_ena_gpio_ctrl()[1] changes the
> GPIO value (even if it's shared) and then notifies regulator consumers
> about a DISABLE event. Now if we'd be implicitly sharing the GPIO with
> an enable-counter, we could possibly emit an event that's a
> false-positive?

Yes (or vice versa for enable).  If the device thinks power got pulled
when it didn't it might get confused about what the hardware is doing.

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