Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Wed, Feb 26, 2025 at 1:43 PM Marek Vasut <marex@xxxxxxx> wrote:

> That's really all this is about, get rid of the defects of the old sysfs
> API, but keep the tooling requirements to minimum.

I understand.

We should however understand that there are defects in
the sysfs ABI that cannot be designed away:

- The chardev uses the Linux file handler clean-up when an
  applications dies, often sysfs programs poke around and
  export stuff left and right, then if they crash (as bash scripts
  do) then it is left in an undefined state. With the chardev all
  GPIOs get released and cleaned up when this happens.

- The chardev has an "event pipe" using KFIFO which is
  *fast* and provides timestamps (this is why IIO is using it)
  and things such as signal processing in userspace can
  never rely on GPIO events being fast or timestamped
  unless they use the chardev ABI.

- Topology is inherently unstable (also with the current
  global numberspace) so scripts using sysfs actually need
  to do proper topology discovery before using GPIOs,
  and this is an inherent design in sysfs. An example is
  GPIOs on USB expanders, say that you plug in two
  of them, which one gets probed first, really? Which one
  becomes gpiochip0 and which one is gpiochip1?
  It will be the same driver so the label will be the same.
  Most people
  I think currently just ignores this problem and hope their
  system will probe in a certain order despite the
  deferred probe etc has made the global numberspace
  quite shaky.

> Also note that API "v2" attribute layout could differ from API "v1" ,
> that is not a problem.

But does this "v2" include interrupt handling?

I think interrupts should not be part of "v2" in that case. It is
just too shaky and unreliable. Direction/getting/setting is fine (just
does not clean up very well).

The current IRQ crap in sysfs uses sysfs_notify_dirent() which
will squash 100 or 1000 IRQs into one notification if they are
fast and userspace does not react in time and that *will* miss
interrupts and there is no way to design around that.

I think fs notify is not very synchronous, these "IRQs"
will be delivered the next time the system schedules,
or something like that.

It's not very nice for the GPIO maintainers that people
rely on this and then come to us and complain that they
are missing IRQs in userspace, and what shall we say?
Shrug?

> > I understand, I'm fine with sysfs if it needs to be a "support forever"
> > ABI, as long as it's:
> >
> > - Using the per-chip HW numberspace
>
> This is no issue for me.
>
> > - Doesn't need any echo NN > export to see the lines in
> >    sysfs.
>
> Can we really make do without export/unexport ?

I was more thinking that we should not need export/unexport
just to see the line. Propsal elsewhere in this thread:

/sys/bus/gpio/gpiochip0
/sys/bus/gpio/gpiochip0/gpio0
/sys/bus/gpio/gpiochip0/gpio0/userspace
/sys/bus/gpio/gpiochip0/gpio0/value
/sys/bus/gpio/gpiochip0/gpio1
/sys/bus/gpio/gpiochip0/gpio1/userspace
/sys/bus/gpio/gpiochip0/gpio1/value

Take a GPIO, shake it, give it back to the kernel:
echo 1 > /sys/bus/gpio/gpiochip0/gpio1/userspace
echo 0 > /sys/bus/gpio/gpiochip0/gpio1/value
sleep 1
echo 1 > /sys/bus/gpio/gpiochip0/gpio1/value
echo 0 > /sys/bus/gpio/gpiochip0/gpio1/userspace

So we can always "see" this GPIO line, instead of
exporting/unexporting there is a knob to assign/unassign
it to userspace.

> Consider this scenario:
>
> - User open()s and write()s /sys/bus/gpio/gpiochip0/gpio0/value
> - User keeps FD to /sys/bus/gpio/gpiochip0/gpio0/value open
> - Kernel module gets loaded, binds to DT node which references the same GPIO
> - User write()s /sys/bus/gpio/gpiochip0/gpio0/value open again
>
> I wonder if this could pose a problem ?
>
> I suspect the kernel module loading should fail , right ?

Yes the sysfs reserves the GPIO so no kernel module
can come in and use it so this is protected by design,
also in the current sysfs.

Yours,
Linus Walleij