[PATCH 0/6] gpio: update the TODO list

[PATCH 0/6] gpio: update the TODO list

[Bartosz Golaszewski]

Here are a couple proposed updates to the TODO file for your
consideration.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
Bartosz Golaszewski (6):
      gpio: TODO: remove the item about the new debugfs interface
      gpio: TODO: remove task duplication
      gpio: TODO: remove the pinctrl integration task
      gpio: TODO: add delimiters between tasks for better readability
      gpio: TODO: add an item to track the conversion to the new value setters
      gpio: TODO: add an item to track reworking the sysfs interface

 drivers/gpio/TODO | 89 +++++++++++++++++++++----------------------------------
 1 file changed, 33 insertions(+), 56 deletions(-)
---
base-commit: 9388ec571cb1adba59d1cded2300eeb11827679c
change-id: 20250321-gpio-todo-updates-d4af632d6126

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

[PATCH 1/6] gpio: TODO: remove the item about the new debugfs interface

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

The consensus among core GPIO stakeholders seems to be that a new
debugfs interface will only increase maintenance burden and will fail
to attract users that care about long-term stability of the ABI[1].
Let's not go this way and not add a fourth user-facing interface to the
GPIO subsystem.

[1] https://lore.kernel.org/all/9d3f1ca4-d865-45af-9032-c38cacc7fe93@pengutronix.de/

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

diff --git a/drivers/gpio/TODO b/drivers/gpio/TODO
index 942d1cd2bd3c9..9cf7b84cdb869 100644
--- a/drivers/gpio/TODO
+++ b/drivers/gpio/TODO
@@ -156,42 +156,6 @@ multiplexing, pin configuration, GPIO, etc selectable options in one
 and the same pin control and GPIO subsystem.
 
 
-Debugfs in place of sysfs
-
-The old sysfs code that enables simple uses of GPIOs from the
-command line is still popular despite the existance of the proper
-character device. The reason is that it is simple to use on
-root filesystems where you only have a minimal set of tools such
-as "cat", "echo" etc.
-
-The old sysfs still need to be strongly deprecated and removed
-as it relies on the global GPIO numberspace that assume a strict
-order of global GPIO numbers that do not change between boots
-and is independent of probe order.
-
-To solve this and provide an ABI that people can use for hacks
-and development, implement a debugfs interface to manipulate
-GPIO lines that can do everything that sysfs can do today: one
-directory per gpiochip and one file entry per line:
-
-/sys/kernel/debug/gpiochip/gpiochip0
-/sys/kernel/debug/gpiochip/gpiochip0/gpio0
-/sys/kernel/debug/gpiochip/gpiochip0/gpio1
-/sys/kernel/debug/gpiochip/gpiochip0/gpio2
-/sys/kernel/debug/gpiochip/gpiochip0/gpio3
-...
-/sys/kernel/debug/gpiochip/gpiochip1
-/sys/kernel/debug/gpiochip/gpiochip1/gpio0
-/sys/kernel/debug/gpiochip/gpiochip1/gpio1
-...
-
-The exact files and design of the debugfs interface can be
-discussed but the idea is to provide a low-level access point
-for debugging and hacking and to expose all lines without the
-need of any exporting. Also provide ample ammunition to shoot
-oneself in the foot, because this is debugfs after all.
-
-
 Moving over to immutable irq_chip structures
 
 Most of the gpio chips implementing interrupt support rely on gpiolib

-- 
2.45.2

Re: [PATCH 1/6] gpio: TODO: remove the item about the new debugfs interface

[Linus Walleij]

On Fri, Mar 21, 2025 at 4:49 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> The consensus among core GPIO stakeholders seems to be that a new
> debugfs interface will only increase maintenance burden and will fail
> to attract users that care about long-term stability of the ABI[1].
> Let's not go this way and not add a fourth user-facing interface to the
> GPIO subsystem.
>
> [1] https://lore.kernel.org/all/9d3f1ca4-d865-45af-9032-c38cacc7fe93@pengutronix.de/
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Okay then,
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

[PATCH 2/6] gpio: TODO: remove task duplication

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

The removal of linux/gpio.h is already tracked by the item about
converting drivers to using the descriptor-based API. Remove the
duplicate.

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

diff --git a/drivers/gpio/TODO b/drivers/gpio/TODO
index 9cf7b84cdb869..ff955befd0ccf 100644
--- a/drivers/gpio/TODO
+++ b/drivers/gpio/TODO
@@ -86,15 +86,6 @@ Work items:
   CONFIG_OF_GPIO_MM_GPIOCHIP from the kernel.
 
 
-Get rid of <linux/gpio.h>
-
-This legacy header is a one stop shop for anything GPIO is closely tied
-to the global GPIO numberspace. The endgame of the above refactorings will
-be the removal of <linux/gpio.h> and from that point only the specialized
-headers under <linux/gpio/*.h> will be used. This requires all the above to
-be completed and is expected to take a long time.
-
-
 Collect drivers
 
 Collect GPIO drivers from arch/* and other places that should be placed

-- 
2.45.2

Re: [PATCH 2/6] gpio: TODO: remove task duplication

[Linus Walleij]

On Fri, Mar 21, 2025 at 4:49 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> The removal of linux/gpio.h is already tracked by the item about
> converting drivers to using the descriptor-based API. Remove the
> duplicate.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

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

[Bartosz Golaszewski]

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(-)

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

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

[Linus Walleij]

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

[PATCH 4/6] gpio: TODO: add delimiters between tasks for better readability

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

For better readability of the TODO, let's add some graphical delimiters
between tasks.

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

diff --git a/drivers/gpio/TODO b/drivers/gpio/TODO
index 08ff60c65abbb..052ba70070033 100644
--- a/drivers/gpio/TODO
+++ b/drivers/gpio/TODO
@@ -1,6 +1,7 @@
 This is a place for planning the ongoing long-term work in the GPIO
 subsystem.
 
+===============================================================================
 
 GPIO descriptors
 
@@ -48,6 +49,7 @@ Work items:
   numberspace accessors from <linux/gpio.h> and eventually delete
   <linux/gpio.h> altogether.
 
+-------------------------------------------------------------------------------
 
 Get rid of <linux/of_gpio.h>
 
@@ -75,6 +77,7 @@ Work items:
 - Delete <linux/of_gpio.h> when all the above is complete and everything
   uses <linux/gpio/consumer.h> or <linux/gpio/driver.h> instead.
 
+-------------------------------------------------------------------------------
 
 Get rid of <linux/gpio/legacy-of-mm-gpiochip.h>
 
@@ -85,6 +88,7 @@ Work items:
   to_of_mm_gpio_chip(), of_mm_gpiochip_add_data(), of_mm_gpiochip_remove(),
   CONFIG_OF_GPIO_MM_GPIOCHIP from the kernel.
 
+-------------------------------------------------------------------------------
 
 Collect drivers
 
@@ -99,6 +103,7 @@ At the same time it makes sense to get rid of code duplication in existing or
 new coming drivers. For example, gpio-ml-ioh should be incorporated into
 gpio-pch.
 
+-------------------------------------------------------------------------------
 
 Generic MMIO GPIO
 
@@ -119,6 +124,7 @@ Work items:
   helpers (x86 inb()/outb()) and convert port-mapped I/O drivers to use
   this with dry-coding and sending to maintainers to test
 
+-------------------------------------------------------------------------------
 
 Generic regmap GPIO
 
@@ -126,6 +132,7 @@ In the very similar way to Generic MMIO GPIO convert the users which can
 take advantage of using regmap over direct IO accessors. Note, even in
 MMIO case the regmap MMIO with gpio-regmap.c is preferable over gpio-mmio.c.
 
+-------------------------------------------------------------------------------
 
 GPIOLIB irqchip
 
@@ -135,6 +142,7 @@ try to cover any generic kind of irqchip cascaded from a GPIO.
 - Look over and identify any remaining easily converted drivers and
   dry-code conversions to gpiolib irqchip for maintainers to test
 
+-------------------------------------------------------------------------------
 
 Moving over to immutable irq_chip structures
 

-- 
2.45.2

Re: [PATCH 4/6] gpio: TODO: add delimiters between tasks for better readability

[Linus Walleij]

On Fri, Mar 21, 2025 at 4:49 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> For better readability of the TODO, let's add some graphical delimiters
> between tasks.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

[PATCH 5/6] gpio: TODO: add an item to track the conversion to the new value setters

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Add an item tracking the treewide conversion of GPIO drivers to using
the new line value setter callbacks in struct gpio_chip instead of the
old ones that don't allow drivers to signal failures to callers.

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

diff --git a/drivers/gpio/TODO b/drivers/gpio/TODO
index 052ba70070033..3abf4805335f1 100644
--- a/drivers/gpio/TODO
+++ b/drivers/gpio/TODO
@@ -161,3 +161,15 @@ A small number of drivers have been converted (pl061, tegra186, msm,
 amd, apple), and can be used as examples of how to proceed with this
 conversion. Note that drivers using the generic irqchip framework
 cannot be converted yet, but watch this space!
+
+-------------------------------------------------------------------------------
+
+Convert all GPIO chips to using the new, value returning line setters
+
+struct gpio_chip's set() and set_multiple() callbacks are now deprecated. They
+return void and thus do not allow drivers to indicate failure to set the line
+value back to the caller.
+
+We've now added new variants - set_rv() and set_multiple_rv() that return an
+integer. Let's convert all GPIO drivers treewide to use the new callbacks,
+remove the old ones and finally rename the new ones back to the old names.

-- 
2.45.2

Re: [PATCH 5/6] gpio: TODO: add an item to track the conversion to the new value setters

[Linus Walleij]

On Fri, Mar 21, 2025 at 4:49 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> Add an item tracking the treewide conversion of GPIO drivers to using
> the new line value setter callbacks in struct gpio_chip instead of the
> old ones that don't allow drivers to signal failures to callers.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Actually I have memories of thinking "we should really fix this" ages
ago, but didn't want to put it on my TBD because there were so
overwhelmingly many things to fix already. Then I forgot to add it
here instead. So:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

[PATCH 6/6] gpio: TODO: add an item to track reworking the sysfs interface

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

It seems there really exists the need for a simple sysfs interface that
can be easily used from minimal initramfs images that don't contain much
more than busybox. However the current interface poses a challenge to
the removal of global GPIO numberspace. Add an item that tracks
extending the existing ABI with a per-chip export/unexport attribute
pair.

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

diff --git a/drivers/gpio/TODO b/drivers/gpio/TODO
index 3abf4805335f1..b5f0a7a2e1bf1 100644
--- a/drivers/gpio/TODO
+++ b/drivers/gpio/TODO
@@ -173,3 +173,16 @@ value back to the caller.
 We've now added new variants - set_rv() and set_multiple_rv() that return an
 integer. Let's convert all GPIO drivers treewide to use the new callbacks,
 remove the old ones and finally rename the new ones back to the old names.
+
+-------------------------------------------------------------------------------
+
+Extend the sysfs ABI to allow exporting lines by their HW offsets
+
+The need to support the sysfs GPIO class is one of the main obstacles to
+removing the global GPIO numberspace from the kernel. In order to wean users
+off using global numbers from user-space, extend the existing interface with
+new per-gpiochip export/unexport attributes that allow to refer to GPIOs using
+their hardware offsets within the chip.
+
+Encourage users to switch to using them and eventually remove the existing
+global export/unexport attribues.

-- 
2.45.2

Re: [PATCH 6/6] gpio: TODO: add an item to track reworking the sysfs interface

[Linus Walleij]

On Fri, Mar 21, 2025 at 4:49 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> It seems there really exists the need for a simple sysfs interface that
> can be easily used from minimal initramfs images that don't contain much
> more than busybox. However the current interface poses a challenge to
> the removal of global GPIO numberspace. Add an item that tracks
> extending the existing ABI with a per-chip export/unexport attribute
> pair.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

100% agreed.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH 0/6] gpio: update the TODO list

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>


On Fri, 21 Mar 2025 16:49:32 +0100, Bartosz Golaszewski wrote:
> Here are a couple proposed updates to the TODO file for your
> consideration.
> 
> 

Applied, thanks!

[1/6] gpio: TODO: remove the item about the new debugfs interface
      commit: 0c6dcc49487608e460b89ff7a6a50c084b01f3d8
[2/6] gpio: TODO: remove task duplication
      commit: 01cbfc45b48beafdab84524df14b0b4a863ea495
[3/6] gpio: TODO: remove the pinctrl integration task
      commit: c36420dc4f9e11d4e494a6182586008d7969c841
[4/6] gpio: TODO: add delimiters between tasks for better readability
      commit: 5ceb3536f2f9ec4fcbe5f83cde6766c6cb673dce
[5/6] gpio: TODO: add an item to track the conversion to the new value setters
      commit: 9ff2443b37d8db5b4712afb1cf44a1e75803407a
[6/6] gpio: TODO: add an item to track reworking the sysfs interface
      commit: af54a2fbdf45b1fd32cdcab916f422e6d097f430

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>