linux-kernel - Re: [PATCH 3/3] gpio: TODO: track the removal of GPIOD_FLAGS_BIT

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: <CACRpkdYMRnmYD1YRavZs7MHEVFM42bOL2=6s4rJzFDnfLJ4fAQ@mail.gmail.com>
Date: Tue, 1 Apr 2025 00:48:53 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH 3/3] gpio: TODO: track the removal of GPIOD_FLAGS_BIT_NONEXCLUSIVE

On Mon, Mar 31, 2025 at 11:00 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:

> +Remove GPIOD_FLAGS_BIT_NONEXCLUSIVE
> +
> +This flag is an awful workaround that was created for some regulator
> +corner-cases but got out of hand and is now used in at least 33 places
> +treewide. Unlike what the intuition may tell users, it's not a reference
> +counted mechanisms like what clocks or regulators use but just a raw access
> +to the same GPIO descriptor from multiple places with no synchronization (other
> +than what the underying driver offers). It doesn't even correctly support
> +releasing the supposedly non-exclusive GPIOs. This whole thing should go and be
> +replaced with a better solution - for exampe: using the relatively new power
> +sequencing subsystem.

Try to focus on the solution instead of writing so much about the problem.
We mostly get the information that the GPIO maintainer dislikes them,
not so much about why they exist and what can be done about them.

I would describe the actual problem and the actual solution,
something like:

"A problematic usecase for GPIOs is when two consumers want to use
the same descriptor independently, as a consumer (in Linux a struct
device) is generally assumed to have exclusive access to all of its
resources, with a resource being defined as anything obtained behind
a devm_* managed resource API such as devm_gpiod_get().

Providers such as regulators pose a special problem here since
regulators instantiate several struct regulator_dev instances containing
a struct device but using the *same* enable GPIO line: i.e. from a Linux
point of view this enable line has a many-to-one ownership. You can
imagine a 12V and a 5V regulator being turned on by the same GPIO
line for example. The regulator resources need to have two different
devices in Linux because they have different voltages, but they are enabled
by the same GPIO.

This breaks the devres resource assumptions:

If several providers with their own struct device is using one
and the same GPIO line, the devres consumer is unclear: which
struct device should own the GPIO line?

A hack allows GPIO lines to be shared between several consumers
with the flag GPIOD_FLAGS_BIT_NONEXCLUSIVE but this API is
confusing and prone to abuse, as is the related devm_gpiod_unhinge() API.

A better solution to some of the problems is to use approaches such as
the power sequencing subsystem, which avoids having several owners of
a resource by strictly sequencing the order in which they are obtained
and activated.

For example a GPIO turning on the power for both wireless and bluetooth
chips can be obtained and turned on in a power sequence such that this
problem never occurs: it is always active when when it needs to be, it has
just one owner (the power sequence itself, struct pwrseq_device, which
contains a struct device) and the GPIO regulator driver is not used in this
scenario."

Yours,
Linus Walleij