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 except that the latter only
implements a minimal subset of the functionality of the former, namely:
only the 'direction' and 'value' attributes and it doesn't support event
polling.

The series contains the 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 as well as a way to 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>
---
Changes in v4:
- make the chip-local, per-line attribute group only have a minimal subset
  of the functionality of the line class device that exists now: only
  expose the direction and value attributes and disable event polling
  for the latter
- subsequently allow to compile-out the code supporting interrupts and
  `edge` and `active_low` attributes
- only add the line to the list of exported lines at the very end of a
  successful gpiod_export()
- add a TODO task to track the removal of the legacy sysfs bits
- Link to v3: https://lore.kernel.org/r/20250630-gpio-sysfs-chip-export-v3-0-b997be9b7137@linaro.org

Changes in v3:
- wrap a local variable in #ifdef's as it's only used if legacy sysfs
  ABI is enabled (Geert)
- fix an issue with jumping over a variable annotated with __free()
- use gpiod_is_equal() where applicable
- fix a use-after-free issue
- remove trailing commas from NULL array terminators
- improve commit messages
- change patch order for smaller diffstats and better readability
- put struct list_head at the beginning of structures for better
  performance
- reshuffle the contents of struct gpiodev_data: put all legacy fields
  at the end
- don't break lines too eagerly
- Link to v2: https://lore.kernel.org/r/20250623-gpio-sysfs-chip-export-v2-0-d592793f8964@linaro.org

Changes in v2:
- add missing call to sysfs_remove_groups() in gpiod_unexport()
- pick up review tags
- drop patches that were already applied
- add missing documentation for the chip-local line attributes
- correct the statement about chip's label uniqueness in docs
- Link to v1: https://lore.kernel.org/r/20250610-gpio-sysfs-chip-export-v1-0-a8c7aa4478b1@linaro.org

---
Bartosz Golaszewski (10):
      gpio: sysfs: use gpiod_is_equal() to compare GPIO descriptors
      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: rename the data variable in gpiod_(un)export()
      gpio: sysfs: don't use driver data in sysfs callbacks for line attributes
      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 |  10 +-
 drivers/gpio/Kconfig                  |   8 +
 drivers/gpio/TODO                     |  14 +-
 drivers/gpio/gpiolib-sysfs.c          | 522 +++++++++++++++++++++++++---------
 4 files changed, 412 insertions(+), 142 deletions(-)
---
base-commit: 8d6c58332c7a8ba025fcfa76888b6c37dbce9633
change-id: 20250402-gpio-sysfs-chip-export-84ac424b61c5

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

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


On Fri, 04 Jul 2025 14:58:47 +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 except that the latter only
> implements a minimal subset of the functionality of the former, namely:
> only the 'direction' and 'value' attributes and it doesn't support event
> polling.
> 
> [...]

Applied, thanks!

[01/10] gpio: sysfs: use gpiod_is_equal() to compare GPIO descriptors
        https://git.kernel.org/brgl/linux/c/32ad0b9a17f9aa8dd9308feda671bda98b274d24
[02/10] gpio: sysfs: add a parallel class device for each GPIO chip using device IDs
        https://git.kernel.org/brgl/linux/c/2028f854b3f5b3816cd5d5dd83057a873eddc4d6
[03/10] gpio: sysfs: only get the dirent reference for the value attr once
        https://git.kernel.org/brgl/linux/c/c38c3a349b7bb994252e93c7c122fa0b50ddf12b
[04/10] gpio: sysfs: pass gpiod_data directly to internal GPIO sysfs functions
        https://git.kernel.org/brgl/linux/c/7c49c1298f3ab3331008e85ac22b2d32b4bb450f
[05/10] gpio: sysfs: rename the data variable in gpiod_(un)export()
        https://git.kernel.org/brgl/linux/c/12faec7ed1793221c1dc9f69575a814528d74691
[06/10] gpio: sysfs: don't use driver data in sysfs callbacks for line attributes
        https://git.kernel.org/brgl/linux/c/f7d4fb62d04542646a48de08b10354692f3b98ce
[07/10] gpio: sysfs: don't look up exported lines as class devices
        https://git.kernel.org/brgl/linux/c/1cd53df733c21ae0d344a2dec941a3e2a06fefd9
[08/10] gpio: sysfs: export the GPIO directory locally in the gpiochip<id> directory
        https://git.kernel.org/brgl/linux/c/4fa93223e03eea3243db83786f556b6c1494de3e
[09/10] gpio: sysfs: allow disabling the legacy parts of the GPIO sysfs interface
        https://git.kernel.org/brgl/linux/c/e69c6db4cdbc149ff090f1449a114c33ba766dc8
[10/10] gpio: TODO: remove the task for the sysfs rework
        https://git.kernel.org/brgl/linux/c/0c0438d444a7814783099c9028823bff5977e4f0

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

On Fri, Jul 4, 2025 at 2:58 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 except that the latter only
> implements a minimal subset of the functionality of the former, namely:
> only the 'direction' and 'value' attributes and it doesn't support event
> polling.
>
> The series contains the 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 as well as a way to 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>
> ---

Alright, so what are we doing about this? Should I queue these patches
for v6.17? Kent, any additional comments? Geert, Jan: did you have the
chance to test it?

Bart

On Sun, 2025-07-13 at 10:48 +0200, Bartosz Golaszewski wrote:
> Alright, so what are we doing about this? Should I queue these patches
> for v6.17? Kent, any additional comments? Geert, Jan: did you have the
> chance to test it?

I've tried it out and didn't find any issues.

Thanks a lot for implementing this!

Regards,
Jan

On Sun, Jul 13, 2025 at 10:48:03AM +0200, Bartosz Golaszewski wrote:
> On Fri, Jul 4, 2025 at 2:58 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 except that the latter only
> > implements a minimal subset of the functionality of the former, namely:
> > only the 'direction' and 'value' attributes and it doesn't support event
> > polling.
> >
> > The series contains the 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 as well as a way to 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>
> > ---
> 
> Alright, so what are we doing about this? Should I queue these patches
> for v6.17? Kent, any additional comments?

Nothing beyond what I've already said.

Cheers,
Kent.

On Mon, Jul 14, 2025 at 3:38 AM Kent Gibson <warthog618@gmail.com> wrote:
>
> On Sun, Jul 13, 2025 at 10:48:03AM +0200, Bartosz Golaszewski wrote:
> > On Fri, Jul 4, 2025 at 2:58 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 except that the latter only
> > > implements a minimal subset of the functionality of the former, namely:
> > > only the 'direction' and 'value' attributes and it doesn't support event
> > > polling.
> > >
> > > The series contains the 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 as well as a way to 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>
> > > ---
> >
> > Alright, so what are we doing about this? Should I queue these patches
> > for v6.17? Kent, any additional comments?
>
> Nothing beyond what I've already said.
>
> Cheers,
> Kent.

Ok, let's queue them up for v6.17 then.

Bart