linux-kernel - [PATCH 3/6] gpio: TODO: remove the pinctrl integration task

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: <20250321-gpio-todo-updates-v1-3-7b38f07110ee@linaro.org>
Date: Fri, 21 Mar 2025 16:49:35 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Linus Walleij <linus.walleij@...aro.org>, 
 Bartosz Golaszewski <brgl@...ev.pl>
Cc: linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org, 
 Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: [PATCH 3/6] gpio: TODO: remove the pinctrl integration task

From: Bartosz Golaszewski <bartosz.golaszewski@...aro.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@...aro.org>
---
 drivers/gpio/TODO | 11 -----------
 1 file changed, 11 deletions(-)

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

-- 
2.45.2