[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <841a919f-2a13-4488-aa1e-a5a07824ed76@sirena.org.uk>
Date: Mon, 7 Apr 2025 14:52:57 +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 02:33:53PM +0100, Mark Brown wrote:
> On Mon, Apr 07, 2025 at 03:29:09PM +0200, Bartosz Golaszewski wrote:
>
> > Basically: we may set the GPIO to 1 but it was already enabled and we
> > tell consumers the regulator was just enabled when it wasn't OR we set
> > the GPIO to 0 and tell consumers the regulator was disabled when there
> > are still users of this GPIO so it's not true either.
>
> > AFAICT, it's used in a few places to put the regulator consumer in
> > reset if the power was *actually* disabled.
>
> Yes, and also do things like not bother to reinitialise the hardware if
> we kept the power on.
BTW, as an example of something that might go wrong if we didn't get
reset when we expected to be one common thing the would be for the
driver to reset it's register cache back to the hardware defaults but if
the power wasn't really lost that won't reflect the actual hardware
state.
back to the hardware defaults
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists