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: <CAMRc=Mcq9yag6yBswhW0OJ8MKzGBpscwo+UGpfCo2aha93LzXA@mail.gmail.com>
Date: Tue, 1 Apr 2025 16:42:40 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Mark Brown <broonie@...nel.org>
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 Tue, Apr 1, 2025 at 3:27 PM Mark Brown <broonie@...nel.org> wrote:
>
> On Tue, Apr 01, 2025 at 02:46:41PM +0200, Bartosz Golaszewski wrote:
>
> > Let's deprecate both symbols officially, add them to the MAINTAINERS
> > keywords so that it pops up on our radars when used again, add a task to
> > track it and I plan to use the power sequencing subsystem to handle the
> > cases where non-exclusive access to GPIOs is required.
>
> What exactly is the plan here?  The regulator (and reset) usage seems
> like a reasonable one TBH - the real problem is having an API from the
> GPIO subsystem to discover sharing, at the minute you can't resolve a
> binding enough to find out if there's sharing without actually
> requesting the GPIO.

Hard disagree on the reasonable usage. Let's consider the following:

You have two users and one goes gpiod_set_value(desc, 0), the other:
gpiod_set_value(desc, 1). Who is right? Depending on the timing the
resulting value may be either.

For it to make sense, you'd have to add new interfaces:
gpiod_enable(desc) and gpiod_disable(), that would keep track of the
enable count. However you can't remove the hundreds of existing users
of gpiod_set_value() so the problem doesn't go away. But even if you
did introduce these new routines, what about
gpiod_direction_input/output()? My point is: the GPIO consumer API is
designed with exclusive usage in mind and it makes no sense to try to
ram shared GPIOs into the GPIO core.

Also: there are no non-exclusive GPIO usars under drivers/reset/.

What I want to propose is the following:

1. Audit all users of GPIOD_FLAGS_BIT_NONEXCLUSIVE

Outside of drivers/regulator/ it seems that there are several users
who don't really needs this (especially under sound/) and where using
this flag is just a result of a copy-paste.

2. Fix the actual problem with buggy DSDT

Some GPIOs are requested by GPIOLIB ACPI code even though platform
drivers also want them. Those drivers just used the non-exclusive flag
with gpiod_get() but we should instead fix it with an ACPI request
quirk in GPIO core.

3. Use pwrseq where drivers really need non-exclusive GPIOs.

The power sequencing subsystem seems like a good candidate to fix the
issue. I imagine a faux_bus pwrseq driver that would plug into the
right places and provide pwrseq handles which the affected drivers
could either call directly via the pwrseq_get(), pwrseq_power_on/off()
interfaces, or we could have this pwrseq provider register as a GPIO
chip through which the gpiod_ calls from these consumers would go and
the sharing mediated by pwrseq.

Bartosz