Replacing global GPIO numbers in sysfs with hardware offsets

[Bartosz Golaszewski <brgl@xxxxxxxx>]

Hi!

I'll allow myself to start a thread about it before anyone invests a
significant amount of work into it. Yesterday (01.02.2025) during the
"embedded dinner" after the FOSDEM 2025 embedded devroom concluded, we
discussed the motivation behind my wish to remove /sys/class/gpio and
the reasons why many users prefer it over libgpiod or even a
user-space compatibility layer I presented during my talk earlier that
day[1].

The gist of it is: some people need to play with GPIOs very early, for
example in an initramfs that is very limited in size and doesn't
contain anything other than busybox so echoing into sysfs attributes
is preferable over trying to cram additional tools or even the entire
python interpreter into the limited system. An alternative to consider
is of course adding some limited GPIO functionality to busybox.

The main thing that bothers me in the GPIO sysfs class is not its
existence per se but the fact that it identifies individual GPIOs by
their global numbers and not hardware offsets which is the biggest
obstacle to removing the global numberspace and the legacy GPIO API
from the kernel.

I think it was Ahmad or Marek who suggested that users aren't really
attached to the global numbering but to the ease of use of sysfs.

I floated an idea of introducing a backward compatible change to sysfs
that would allow users to identify GPIOs by the label of their parent
chip and the hardware offset of the line within that chip (like what
we do for the character device) in the form of the export/unexport
pair of attributes inside the gpiochipXYZ directory associated with
given controller. These attributes, unlike the "global"
export/unexport would take the hardware offset and create the line
directory within the chip directory of which the layout would be the
same as that of its global counterpart (in fact: it could point to the
same directory in sysfs as a single line can only be requested once).

We could then encourage users to switch to using the chip-local
exports and eventually at least remove the global export/unexport pair
if we cannot make the entire sysfs class go away.

Please let me know what you think about it?

Bart

[1] https://fosdem.org/2025/schedule/event/fosdem-2025-5288-the-status-of-removing-sys-class-gpio-and-the-global-gpio-numberspace-from-the-kernel/