Documentation/ABI/obsolete/sysfs-gpio | 12 +- drivers/gpio/Kconfig | 8 + drivers/gpio/TODO | 13 - drivers/gpio/gpiolib-sysfs.c | 650 ++++++++++++++++++++++++---------- drivers/gpio/gpiolib.h | 3 - 5 files changed, 474 insertions(+), 212 deletions(-)
Following our discussion[1], here's a proposal for extending the sysfs
interface with attributes not referring to GPIO lines by their global
numbers in a backward compatible way.
Long story short: there is now a new class device for each GPIO chip.
It's called chipX where X is the ID of the device as per the driver
model and it lives next to the old gpiochipABC where ABC is the GPIO
base. Each new chip class device has a pair of export/unexport
attributes which work similarly to the global ones under /sys/class/gpio
but take hardware offsets within the chip as input, instead of the
global numbers. Finally, each exported line appears at the same time as
the global /sys/class/gpio/gpioABC as well as per-chip
/sys/class/gpio/chipX/gpioY sysfs group.
First, there are some documentation updates, followed by a set of
updates to the sysfs code that's useful even without the new
functionality. Then the actual implementation of a parallel GPIO chip
entry not containing the base GPIO number in the name and the
corresponding sysfs attribute group for each exported line that lives
under the new chip class device. Finally: also allow to compile out the
legacy parts leaving only the new elements of the sysfs ABI.
This series passes the compatibility tests I wrote while working on the
user-space compatibility layer for sysfs[2].
[1] https://lore.kernel.org/all/CAMRc=McUCeZcU6co1aN54rTudo+JfPjjForu4iKQ5npwXk6GXA@mail.gmail.com/
[2] https://github.com/brgl/gpio-sysfs-compat-tests
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
Bartosz Golaszewski (15):
Documentation: gpio: undocument removed behavior
Documentation: gpio: document the active_low field in the sysfs ABI
gpio: sysfs: call mutex_destroy() in gpiod_unexport()
gpio: sysfs: refactor the coding style
gpio: sysfs: remove unneeded headers
gpio: sysfs: remove the mockdev pointer from struct gpio_device
gpio: sysfs: add a parallel class device for each GPIO chip using device IDs
gpio: sysfs: only get the dirent reference for the value attr once
gpio: sysfs: pass gpiod_data directly to internal GPIO sysfs functions
gpio: sysfs: don't use driver data in sysfs callbacks for line attributes
gpio: sysfs: rename the data variable in gpiod_(un)export()
gpio: sysfs: don't look up exported lines as class devices
gpio: sysfs: export the GPIO directory locally in the gpiochip<id> directory
gpio: sysfs: allow disabling the legacy parts of the GPIO sysfs interface
gpio: TODO: remove the task for the sysfs rework
Documentation/ABI/obsolete/sysfs-gpio | 12 +-
drivers/gpio/Kconfig | 8 +
drivers/gpio/TODO | 13 -
drivers/gpio/gpiolib-sysfs.c | 650 ++++++++++++++++++++++++----------
drivers/gpio/gpiolib.h | 3 -
5 files changed, 474 insertions(+), 212 deletions(-)
---
base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494
change-id: 20250402-gpio-sysfs-chip-export-84ac424b61c5
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
On Tue, Jun 10, 2025 at 4:38 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > Following our discussion[1], here's a proposal for extending the sysfs > interface with attributes not referring to GPIO lines by their global > numbers in a backward compatible way. > > Long story short: there is now a new class device for each GPIO chip. > It's called chipX where X is the ID of the device as per the driver > model and it lives next to the old gpiochipABC where ABC is the GPIO > base. Each new chip class device has a pair of export/unexport > attributes which work similarly to the global ones under /sys/class/gpio > but take hardware offsets within the chip as input, instead of the > global numbers. Finally, each exported line appears at the same time as > the global /sys/class/gpio/gpioABC as well as per-chip > /sys/class/gpio/chipX/gpioY sysfs group. > > First, there are some documentation updates, followed by a set of > updates to the sysfs code that's useful even without the new > functionality. Then the actual implementation of a parallel GPIO chip > entry not containing the base GPIO number in the name and the > corresponding sysfs attribute group for each exported line that lives > under the new chip class device. Finally: also allow to compile out the > legacy parts leaving only the new elements of the sysfs ABI. > > This series passes the compatibility tests I wrote while working on the > user-space compatibility layer for sysfs[2]. > > [1] https://lore.kernel.org/all/CAMRc=McUCeZcU6co1aN54rTudo+JfPjjForu4iKQ5npwXk6GXA@mail.gmail.com/ > [2] https://github.com/brgl/gpio-sysfs-compat-tests > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > --- > Bartosz Golaszewski (15): > Documentation: gpio: undocument removed behavior > Documentation: gpio: document the active_low field in the sysfs ABI > gpio: sysfs: call mutex_destroy() in gpiod_unexport() > gpio: sysfs: refactor the coding style > gpio: sysfs: remove unneeded headers > gpio: sysfs: remove the mockdev pointer from struct gpio_device If there are no objections, I'd like to queue patches 1-6 for v6.17 already in the coming days. They are largely preparatory, have been reviewed by Linus and don't introduce any changes to the sysfs interface. Bart > gpio: sysfs: add a parallel class device for each GPIO chip using device IDs > gpio: sysfs: only get the dirent reference for the value attr once > gpio: sysfs: pass gpiod_data directly to internal GPIO sysfs functions > gpio: sysfs: don't use driver data in sysfs callbacks for line attributes > gpio: sysfs: rename the data variable in gpiod_(un)export() > gpio: sysfs: don't look up exported lines as class devices > gpio: sysfs: export the GPIO directory locally in the gpiochip<id> directory > gpio: sysfs: allow disabling the legacy parts of the GPIO sysfs interface > gpio: TODO: remove the task for the sysfs rework > > Documentation/ABI/obsolete/sysfs-gpio | 12 +- > drivers/gpio/Kconfig | 8 + > drivers/gpio/TODO | 13 - > drivers/gpio/gpiolib-sysfs.c | 650 ++++++++++++++++++++++++---------- > drivers/gpio/gpiolib.h | 3 - > 5 files changed, 474 insertions(+), 212 deletions(-) > --- > base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494 > change-id: 20250402-gpio-sysfs-chip-export-84ac424b61c5 > > Best regards, > -- > Bartosz Golaszewski <bartosz.golaszewski@linaro.org> >
Hi Bartosz, On Tue, 2025-06-10 at 16:38 +0200, Bartosz Golaszewski wrote: > Following our discussion[1], here's a proposal for extending the sysfs > interface with attributes not referring to GPIO lines by their global > numbers in a backward compatible way. > > Long story short: there is now a new class device for each GPIO chip. > It's called chipX where X is the ID of the device as per the driver > model and it lives next to the old gpiochipABC where ABC is the GPIO > base. Each new chip class device has a pair of export/unexport > attributes which work similarly to the global ones under /sys/class/gpio > but take hardware offsets within the chip as input, instead of the > global numbers. Finally, each exported line appears at the same time as > the global /sys/class/gpio/gpioABC as well as per-chip > /sys/class/gpio/chipX/gpioY sysfs group. > > First, there are some documentation updates, followed by a set of > updates to the sysfs code that's useful even without the new > functionality. Then the actual implementation of a parallel GPIO chip > entry not containing the base GPIO number in the name and the > corresponding sysfs attribute group for each exported line that lives > under the new chip class device. Finally: also allow to compile out the > legacy parts leaving only the new elements of the sysfs ABI. > > This series passes the compatibility tests I wrote while working on the > user-space compatibility layer for sysfs[2]. > > [1] https://lore.kernel.org/all/CAMRc=McUCeZcU6co1aN54rTudo+JfPjjForu4iKQ5npwXk6GXA@mail.gmail.com/ > [2] https://github.com/brgl/gpio-sysfs-compat-tests > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> thanks for implementing this! I tried it on one of our boards and noticed a few things. After unexporting a GPIO from the chipX dir, the subdirectory is not removed: root@lxatac-00006:/sys/class/gpio/chip9# echo 1 > export root@lxatac-00006:/sys/class/gpio/chip9# echo 1 > unexport root@lxatac-00006:/sys/class/gpio/chip9# ls -l gpio1/ total 0 -rw-r--r-- 1 root root 4096 Jun 18 12:52 active_low -rw-r--r-- 1 root root 4096 Jun 18 12:52 direction -rw-r--r-- 1 root root 4096 Jun 18 12:52 edge -rw-r--r-- 1 root root 4096 Jun 18 12:52 value Subsequent attempts to export it again fail. The contents of /sys/kernel/debug/gpio don't really fit any more: gpiochip10: GPIOs 660-663, parent: i2c/0-0024, pca9570, can sleep: gpio-660 (DUT_PWR_EN |tacd ) out hi gpio-661 (DUT_PWR_DISCH |tacd ) out lo gpio-662 (DUT_PWR_ADCRST |reset ) out lo The header is inconsistent: it uses the 'gpiochip' prefix, but not the base as the old class devices in /sys/class/gpio/. Perhaps something like this? chip10: GPIOs 0-2 (global IDs 660-663), parent: i2c/0-0024, pca9570, can sleep: gpio-0 (660) (DUT_PWR_EN |tacd ) out hi gpio-1 (661) (DUT_PWR_DISCH |tacd ) out lo gpio-2 (662) (DUT_PWR_ADCRST |reset ) out lo If GPIO_SYSFS_LEGACY is disabled, the global IDs could be hidden. Unix permissions/ownership just works. As far as I can see, this is basically everything I need to replace the old global ID based GPIO access in labgrid. Thanks again! :) Regards, Jan -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Wed, Jun 18, 2025 at 3:38 PM Jan Lübbe <jlu@pengutronix.de> wrote: > [snip] > The contents of /sys/kernel/debug/gpio don't really fit any more: > gpiochip10: GPIOs 660-663, parent: i2c/0-0024, pca9570, can sleep: > gpio-660 (DUT_PWR_EN |tacd ) out hi > gpio-661 (DUT_PWR_DISCH |tacd ) out lo > gpio-662 (DUT_PWR_ADCRST |reset ) out lo > The header is inconsistent: it uses the 'gpiochip' prefix, but not the base as > the old class devices in /sys/class/gpio/. Perhaps something like this? > chip10: GPIOs 0-2 (global IDs 660-663), parent: i2c/0-0024, pca9570, can sleep: > gpio-0 (660) (DUT_PWR_EN |tacd ) out hi > gpio-1 (661) (DUT_PWR_DISCH |tacd ) out lo > gpio-2 (662) (DUT_PWR_ADCRST |reset ) out lo > If GPIO_SYSFS_LEGACY is disabled, the global IDs could be hidden. > After a second look: IMO this is unrelated to the sysfs changes. We definitely should change the debugfs output and rid it off the global numbers but it shouldn't be part of this series. Also: are you using this output in some way? Technically debugfs output is not stable ABI so we can modify it without considering existing users but wanted to run it by you to know if I'm going to break something for you. Bart
On Wed, 2025-06-18 at 17:56 +0200, Bartosz Golaszewski wrote: > On Wed, Jun 18, 2025 at 3:38 PM Jan Lübbe <jlu@pengutronix.de> wrote: > > > > [snip] > > > > The contents of /sys/kernel/debug/gpio don't really fit any more: > > gpiochip10: GPIOs 660-663, parent: i2c/0-0024, pca9570, can sleep: > > gpio-660 (DUT_PWR_EN |tacd ) out hi > > gpio-661 (DUT_PWR_DISCH |tacd ) out lo > > gpio-662 (DUT_PWR_ADCRST |reset ) out lo > > The header is inconsistent: it uses the 'gpiochip' prefix, but not the base as > > the old class devices in /sys/class/gpio/. Perhaps something like this? > > chip10: GPIOs 0-2 (global IDs 660-663), parent: i2c/0-0024, pca9570, can sleep: > > gpio-0 (660) (DUT_PWR_EN |tacd ) out hi > > gpio-1 (661) (DUT_PWR_DISCH |tacd ) out lo > > gpio-2 (662) (DUT_PWR_ADCRST |reset ) out lo > > If GPIO_SYSFS_LEGACY is disabled, the global IDs could be hidden. > > > > After a second look: IMO this is unrelated to the sysfs changes. We > definitely should change the debugfs output and rid it off the global > numbers but it shouldn't be part of this series. Agreed. > Also: are you using > this output in some way? Technically debugfs output is not stable ABI > so we can modify it without considering existing users but wanted to > run it by you to know if I'm going to break something for you. We're not parsing debugfs. :) I just checked manually if it matched the new naming and saw that it didn't. Regards, Jan -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Wed, Jun 18, 2025 at 3:38 PM Jan Lübbe <jlu@pengutronix.de> wrote: > > Hi Bartosz, > > On Tue, 2025-06-10 at 16:38 +0200, Bartosz Golaszewski wrote: > > Following our discussion[1], here's a proposal for extending the sysfs > > interface with attributes not referring to GPIO lines by their global > > numbers in a backward compatible way. > > > > Long story short: there is now a new class device for each GPIO chip. > > It's called chipX where X is the ID of the device as per the driver > > model and it lives next to the old gpiochipABC where ABC is the GPIO > > base. Each new chip class device has a pair of export/unexport > > attributes which work similarly to the global ones under /sys/class/gpio > > but take hardware offsets within the chip as input, instead of the > > global numbers. Finally, each exported line appears at the same time as > > the global /sys/class/gpio/gpioABC as well as per-chip > > /sys/class/gpio/chipX/gpioY sysfs group. > > > > First, there are some documentation updates, followed by a set of > > updates to the sysfs code that's useful even without the new > > functionality. Then the actual implementation of a parallel GPIO chip > > entry not containing the base GPIO number in the name and the > > corresponding sysfs attribute group for each exported line that lives > > under the new chip class device. Finally: also allow to compile out the > > legacy parts leaving only the new elements of the sysfs ABI. > > > > This series passes the compatibility tests I wrote while working on the > > user-space compatibility layer for sysfs[2]. > > > > [1] https://lore.kernel.org/all/CAMRc=McUCeZcU6co1aN54rTudo+JfPjjForu4iKQ5npwXk6GXA@mail.gmail.com/ > > [2] https://github.com/brgl/gpio-sysfs-compat-tests > > > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > thanks for implementing this! I tried it on one of our boards and noticed a few > things. > > After unexporting a GPIO from the chipX dir, the subdirectory is not removed: > root@lxatac-00006:/sys/class/gpio/chip9# echo 1 > export > root@lxatac-00006:/sys/class/gpio/chip9# echo 1 > unexport > root@lxatac-00006:/sys/class/gpio/chip9# ls -l gpio1/ > total 0 > -rw-r--r-- 1 root root 4096 Jun 18 12:52 active_low > -rw-r--r-- 1 root root 4096 Jun 18 12:52 direction > -rw-r--r-- 1 root root 4096 Jun 18 12:52 edge > -rw-r--r-- 1 root root 4096 Jun 18 12:52 value > Subsequent attempts to export it again fail. > Ah, seems like one of the last-minute rebases made me drop the relevant sysfs_remove_groups(). Thanks for catching it. > The contents of /sys/kernel/debug/gpio don't really fit any more: > gpiochip10: GPIOs 660-663, parent: i2c/0-0024, pca9570, can sleep: > gpio-660 (DUT_PWR_EN |tacd ) out hi > gpio-661 (DUT_PWR_DISCH |tacd ) out lo > gpio-662 (DUT_PWR_ADCRST |reset ) out lo > The header is inconsistent: it uses the 'gpiochip' prefix, but not the base as > the old class devices in /sys/class/gpio/. Perhaps something like this? > chip10: GPIOs 0-2 (global IDs 660-663), parent: i2c/0-0024, pca9570, can sleep: > gpio-0 (660) (DUT_PWR_EN |tacd ) out hi > gpio-1 (661) (DUT_PWR_DISCH |tacd ) out lo > gpio-2 (662) (DUT_PWR_ADCRST |reset ) out lo > If GPIO_SYSFS_LEGACY is disabled, the global IDs could be hidden. > I have not paid attention to the debugfs output TBH. Let me check it in v2. > Unix permissions/ownership just works. > > > As far as I can see, this is basically everything I need to replace the old > global ID based GPIO access in labgrid. Thanks again! :) > Bart
Hi Bartosz,
On Tue, 10 Jun 2025 at 16:38, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> Following our discussion[1], here's a proposal for extending the sysfs
> interface with attributes not referring to GPIO lines by their global
> numbers in a backward compatible way.
>
> Long story short: there is now a new class device for each GPIO chip.
> It's called chipX where X is the ID of the device as per the driver
> model and it lives next to the old gpiochipABC where ABC is the GPIO
> base. Each new chip class device has a pair of export/unexport
> attributes which work similarly to the global ones under /sys/class/gpio
> but take hardware offsets within the chip as input, instead of the
> global numbers. Finally, each exported line appears at the same time as
> the global /sys/class/gpio/gpioABC as well as per-chip
> /sys/class/gpio/chipX/gpioY sysfs group.
>
> First, there are some documentation updates, followed by a set of
> updates to the sysfs code that's useful even without the new
> functionality. Then the actual implementation of a parallel GPIO chip
> entry not containing the base GPIO number in the name and the
> corresponding sysfs attribute group for each exported line that lives
> under the new chip class device. Finally: also allow to compile out the
> legacy parts leaving only the new elements of the sysfs ABI.
>
> This series passes the compatibility tests I wrote while working on the
> user-space compatibility layer for sysfs[2].
>
> [1] https://lore.kernel.org/all/CAMRc=McUCeZcU6co1aN54rTudo+JfPjjForu4iKQ5npwXk6GXA@mail.gmail.com/
> [2] https://github.com/brgl/gpio-sysfs-compat-tests
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Thanks for your series!
I gave it a quick try, and it seems to work as expected, great!
Given the /sys/class/gpio/chip* numbering is volatile, I expect
script writers should use topological path names instead, .e.g.
/sys/devices/platform/soc/e6052000.gpio/gpio/chip*/export and
sys/devices/platform/soc/e6052000.gpio/gpio/chip*/gpio19
(note the wildcards).
I hope to find time to do a review of the patches soon...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, Jun 13, 2025 at 10:02 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Bartosz, > > On Tue, 10 Jun 2025 at 16:38, Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > Following our discussion[1], here's a proposal for extending the sysfs > > interface with attributes not referring to GPIO lines by their global > > numbers in a backward compatible way. > > > > Long story short: there is now a new class device for each GPIO chip. > > It's called chipX where X is the ID of the device as per the driver > > model and it lives next to the old gpiochipABC where ABC is the GPIO > > base. Each new chip class device has a pair of export/unexport > > attributes which work similarly to the global ones under /sys/class/gpio > > but take hardware offsets within the chip as input, instead of the > > global numbers. Finally, each exported line appears at the same time as > > the global /sys/class/gpio/gpioABC as well as per-chip > > /sys/class/gpio/chipX/gpioY sysfs group. > > > > First, there are some documentation updates, followed by a set of > > updates to the sysfs code that's useful even without the new > > functionality. Then the actual implementation of a parallel GPIO chip > > entry not containing the base GPIO number in the name and the > > corresponding sysfs attribute group for each exported line that lives > > under the new chip class device. Finally: also allow to compile out the > > legacy parts leaving only the new elements of the sysfs ABI. > > > > This series passes the compatibility tests I wrote while working on the > > user-space compatibility layer for sysfs[2]. > > > > [1] https://lore.kernel.org/all/CAMRc=McUCeZcU6co1aN54rTudo+JfPjjForu4iKQ5npwXk6GXA@mail.gmail.com/ > > [2] https://github.com/brgl/gpio-sysfs-compat-tests > > > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > Thanks for your series! > > I gave it a quick try, and it seems to work as expected, great! > > Given the /sys/class/gpio/chip* numbering is volatile, I expect > script writers should use topological path names instead, .e.g. > /sys/devices/platform/soc/e6052000.gpio/gpio/chip*/export and > sys/devices/platform/soc/e6052000.gpio/gpio/chip*/gpio19 > (note the wildcards). > Or they can use the chip label like what they would do with the character device. The relevant attribute is still there. Bartosz
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
On Tue, 10 Jun 2025 16:38:15 +0200, Bartosz Golaszewski wrote:
> Following our discussion[1], here's a proposal for extending the sysfs
> interface with attributes not referring to GPIO lines by their global
> numbers in a backward compatible way.
>
> Long story short: there is now a new class device for each GPIO chip.
> It's called chipX where X is the ID of the device as per the driver
> model and it lives next to the old gpiochipABC where ABC is the GPIO
> base. Each new chip class device has a pair of export/unexport
> attributes which work similarly to the global ones under /sys/class/gpio
> but take hardware offsets within the chip as input, instead of the
> global numbers. Finally, each exported line appears at the same time as
> the global /sys/class/gpio/gpioABC as well as per-chip
> /sys/class/gpio/chipX/gpioY sysfs group.
>
> [...]
Applied, thanks!
[01/15] Documentation: gpio: undocument removed behavior
https://git.kernel.org/brgl/linux/c/5ed0d32805c19cfa5f03a25ec7e041dc845d3062
[02/15] Documentation: gpio: document the active_low field in the sysfs ABI
https://git.kernel.org/brgl/linux/c/1ae86030745013d9d54fc287c1ce875f7ddd99e6
[03/15] gpio: sysfs: call mutex_destroy() in gpiod_unexport()
https://git.kernel.org/brgl/linux/c/e1f02b40a741aac47016765c21b61e91d19aa1ec
[04/15] gpio: sysfs: refactor the coding style
https://git.kernel.org/brgl/linux/c/dc665b5248f90aa2dc74ecc1f2ebb731a6f5afd6
[05/15] gpio: sysfs: remove unneeded headers
https://git.kernel.org/brgl/linux/c/982ec96c3876349e65e60c7b4fd91d767099837e
[06/15] gpio: sysfs: remove the mockdev pointer from struct gpio_device
https://git.kernel.org/brgl/linux/c/fd19792851db77e74cff4e2dc772d25a83cdc34d
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
© 2016 - 2025 Red Hat, Inc.