Skip to content

Commit

Permalink
gpio: TODO: track the removal of regulator-related workarounds
Browse files Browse the repository at this point in the history
The GPIOD_FLAGS_BIT_NONEXCLUSIVE flag and devm_gpiod_unhinge() function
should be replaced with a better solution. The pwrseq subsystem is a good
candidate. GPIOs themselves should remain a unique resource. Add a task
for tracking the removal of these deprecated symbols.

Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250401-gpio-todo-remove-nonexclusive-v2-4-7c1380797b0d@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
  • Loading branch information
Bartosz Golaszewski committed Apr 8, 2025
1 parent 3af64f1 commit 2de1cf1
Showing 1 changed file with 34 additions and 0 deletions.
34 changes: 34 additions & 0 deletions drivers/gpio/TODO
Original file line number Diff line number Diff line change
Expand Up @@ -186,3 +186,37 @@ their hardware offsets within the chip.

Encourage users to switch to using them and eventually remove the existing
global export/unexport attribues.

-------------------------------------------------------------------------------

Remove GPIOD_FLAGS_BIT_NONEXCLUSIVE

GPIOs in the linux kernel are meant to be an exclusive resource. This means
that the GPIO descriptors (the software representation of the hardware concept)
are not reference counted and - in general - only one user at a time can
request a GPIO line and control its settings. The consumer API is designed
around full control of the line's state as evidenced by the fact that, for
instance, gpiod_set_value() does indeed drive the line as requested, instead
of bumping an enable counter of some sort.

A problematic use-case for GPIOs is when two consumers want to use the same
descriptor independently. An example of such a user is the regulator subsystem
which may instantiate several struct regulator_dev instances containing
a struct device but using the same enable GPIO line.

A workaround was introduced in the form of the GPIOD_FLAGS_BIT_NONEXCLUSIVE
flag but its implementation is problematic: it does not provide any
synchronization of usage nor did it introduce any enable count meaning the
non-exclusive users of the same descriptor will in fact "fight" for the
control over it. This flag should be removed and replaced with a better
solution, possibly based on the new power sequencing subsystem.

-------------------------------------------------------------------------------

Remove devm_gpiod_unhinge()

devm_gpiod_unhinge() is provided as a way to transfer the ownership of managed
enable GPIOs to the regulator core. Rather than doing that however, we should
make it possible for the regulator subsystem to deal with GPIO resources the
lifetime of which it doesn't control as logically, a GPIO obtained by a caller
should also be freed by it.

0 comments on commit 2de1cf1

Please sign in to comment.