Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Kent Gibson <warthog618@gmail.com>]

On Sun, Feb 02, 2025 at 01:45:58PM +0100, Bartosz Golaszewski wrote:
> Hi!

Sorry for being late to the party - was AFK for a bit.

>
> 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?
>

TBH, I think you will have trouble getting users to adopt it - they
require a solution no more complex than what they already have or they
will resist the change for as long as they possibly can.  So if you want
them to migrate before removing the global numberspace then that will
never happen.

As it stands the user needs to search the gpiochipXYZs looking for the
matching label. It would be easier if the chip was identified in sysfs by
its label, rather than (as well as) its base address.
So no searching required.

Aside: Speaking of which, once the global numberspace is removed does
exposing the base address serve any purpose?

Similarly, it would be even simpler if the line could be exported by
name, so the user wouldn't need to pull magic chip labels and offsets out
of the air.
Though that would be a much more extensive change.

Btw, I am well aware that line names are not guaranteed unique, so this
approach would only be viable/enabled (potentially on a line by line
basis) where they are - and that would provide some incentive for them to
be made unique downstream, if not in mainline.

> 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/

My primary takeaway from your talk is that you are more of a thrill
seeker than I am comfortable with - making jokes about Rust in a
live forum - THAT is living on the edge ;).

Wrt the Q&A at 19:42 - the Pi BCM driver with its module parameter and
"why only this one driver is allowed to have it and the others not" and
the suggestion that there be some flag that can be passed to the driver
to request persistence:  I don't like your answer - it conflates specifying
the default/safe state, generally defined at boot time, with an ability to
override that at runtime.
Extending the driver API to allow the gpio_chip user to request that the
driver NOT reset an output to its default state when released seems like a
viable solution to me.  Am I missing something?

It also didn't address the fact that, even at FOSDEM, there are developers
out there that think that some drivers are getting special treatment.
In this case the Pi devs have pushed their own downstream solution
upstream to reduce their own maintenance burden.  And that was accepted as
it didn't conflict with anything in mainline.
There is nothing preventing other drivers doing the same, though no one
has AFAIAA.
Though the module parameter solution is rather crude - if we are going to
start touching all the drivers then why not address it via the API?

Cheers,
Kent.