Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Mon, Feb 3, 2025 at 3:23 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
>
> Hi Bartosz et al,
>
> On Sun, 2 Feb 2025 at 13:46, Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
> > 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?
>
> I like it. Note that there are other caveats of the old API to
> take into account...
>

I don't want to extend it more than this really.

> The other thing to consider is why people are playing with GPIOs
> directly: do they lack hardware descriptions? Or do they lack proper
> Linux drivers for their use cases? Something else (people brought up
> testing random pins, or plugging random things into a Pi)?
>

I think you're speaking from the position of an experienced kernel
hacker. The majority of libgpiod users with whom I interact on github
or via email have never even compiled the kernel. They're working on
some kind of RPi or BeagleBone project and want to have their python
script fiddle with the pins. These are hardware people and makers. So
to answer your question: they play with GPIOs from user-space because
they don't know better and can't be bothered to learn - developing
kernel drivers is not on their roadmap.

> Personally, I still use the GPIO sysfs interface to control my board
> farm (opto-couplers for reset, wake-up, and key-presses; MOSFETs
> for power).  If appropriate drivers would be available, incl. their
> own sysfs APIs, I could use that instead (technically I can already
> describe opto-couplers using gpio-leds, and be done with it ;-)
>
> Do we need (simple) driver(s) for relays, solenoids, motors?
> E.g. gpio-actuator?

Sure we do. Now if only we could just find volunteers...  :)

Bartosz

> A more advanced example would be an H-bridge motor driver, combining
> GPIO and (optionally) PWM.
> Thanks!
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
>
> 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