diff mbox series

[3/6] gpio: TODO: remove the pinctrl integration task

Message ID 20250321-gpio-todo-updates-v1-3-7b38f07110ee@linaro.org
State New
Headers show
Series gpio: update the TODO list | expand

Commit Message

Bartosz Golaszewski March 21, 2025, 3:49 p.m. UTC 
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

While there are surely some arguments in favor of integrating the GPIO
and pinctrl subsystems into one, I believe this is not the right
approach.

The GPIO subsystem uses intricate locking with SRCU to handle the fact
that both consumers and providers may run in different contexts.
Pin-controller drivers are always meant to run in process context. This
alone is a huge obstacle to any attempt at integration as evident by
many problems we already encountered during the hotplug rework.

The current glue code is pretty minimal and for most part already allows
GPIO controllers to query pinctrl about the information they need.

I suggest to drop this task and keep the subsystems separate even if
many pin-controllers implement GPIO functionality in addition to pin
functions.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 drivers/gpio/TODO | 11 -----------
 1 file changed, 11 deletions(-)

Comments

Linus Walleij March 22, 2025, 8:28 p.m. UTC | #1 
On Fri, Mar 21, 2025 at 4:49 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> While there are surely some arguments in favor of integrating the GPIO
> and pinctrl subsystems into one, I believe this is not the right
> approach.
>
> The GPIO subsystem uses intricate locking with SRCU to handle the fact
> that both consumers and providers may run in different contexts.
> Pin-controller drivers are always meant to run in process context. This
> alone is a huge obstacle to any attempt at integration as evident by
> many problems we already encountered during the hotplug rework.
>
> The current glue code is pretty minimal and for most part already allows
> GPIO controllers to query pinctrl about the information they need.
>
> I suggest to drop this task and keep the subsystems separate even if
> many pin-controllers implement GPIO functionality in addition to pin
> functions.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

I used to get this push a lot in the past from users, that it should be
the same subsystem, but I haven't heard it much recently so I
guess they have finally given up on it.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij
diff mbox series

Patch

diff --git a/drivers/gpio/TODO b/drivers/gpio/TODO
index ff955befd0ccf..08ff60c65abbb 100644
--- a/drivers/gpio/TODO
+++ b/drivers/gpio/TODO
@@ -136,17 +136,6 @@  try to cover any generic kind of irqchip cascaded from a GPIO.
   dry-code conversions to gpiolib irqchip for maintainers to test
 
 
-Increase integration with pin control
-
-There are already ways to use pin control as back-end for GPIO and
-it may make sense to bring these subsystems closer. One reason for
-creating pin control as its own subsystem was that we could avoid any
-use of the global GPIO numbers. Once the above is complete, it may
-make sense to simply join the subsystems into one and make pin
-multiplexing, pin configuration, GPIO, etc selectable options in one
-and the same pin control and GPIO subsystem.
-
-
 Moving over to immutable irq_chip structures
 
 Most of the gpio chips implementing interrupt support rely on gpiolib