Replacing global GPIO numbers in sysfs with hardware offsets

Replacing global GPIO numbers in sysfs with hardware offsets

[Bartosz Golaszewski]

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/

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Geert Uytterhoeven]

Hi Bartosz et al,

On Sun, 2 Feb 2025 at 13:46, Bartosz Golaszewski <brgl@bgdev.pl> 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...

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

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?
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@linux-m68k.org

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

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Bartosz Golaszewski]

On Mon, Feb 3, 2025 at 3:23 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Bartosz et al,
>
> On Sun, 2 Feb 2025 at 13:46, Bartosz Golaszewski <brgl@bgdev.pl> 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@linux-m68k.org
>
> 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

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Geert Uytterhoeven]

Hi Bartosz,

On Fri, 7 Feb 2025 at 21:18, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> On Mon, Feb 3, 2025 at 3:23 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > 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.

Ah, the dreaded userspace GPIO drivers...

Please point them to my ELCE2020 presentation "Gadgets and Trinkets,
The Upstream Linux Way"
https://elinux.org/ELC_Europe_2020_Presentations#Day_1_Presentations

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Ayush Singh]

> Ah, the dreaded userspace GPIO drivers...

> Please point them to my ELCE2020 presentation "Gadgets and Trinkets,
> The Upstream Linux Way"
> https://elinux.org/ELC_Europe_2020_Presentations#Day_1_Presentations

> Gr{oetje,eeting}s,

>                        Geert


One of the reasons of the prevalence of userspace drivers (and probably
the reason why kernel drivers for stuff like motors are not attractive)
is the lack of upstream solution for runtime devicetree overlays. It is
simply not attractive to have tutorials or examples that will require a
reboot to work. And since a lot of people will start with those examples,
they will continue using userspace drivers for their future projects.

Connectors is also a problem that has been stuck for a while (although
things seem to have started progressing).

I personally, would love if I could use kernel drivers instead of
userspace drivers since they are probably much better quality than
random userspace drivers, and will not require any external deps
(as long as they provide a good sysfs API). But I also dread
having to ask a user to reboot the system to get their blinky
example working, and reboot again, since they used the wrong
pin in the overlay.


Best Regards,
Ayush Singh

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Linus Walleij]

On Tue, Feb 25, 2025 at 7:25 PM Ayush Singh <ayushsingh1325@gmail.com> wrote:

> One of the reasons of the prevalence of userspace drivers (and probably
> the reason why kernel drivers for stuff like motors are not attractive)
> is the lack of upstream solution for runtime devicetree overlays.

Given how long device tree overlays have been talked about
and hypothesized I am of the opinion that they are never
going to fly.

My main complaints being that they are just too complex and hard
on users: special tools needed, compile files, files relate to other
existing dts(i) files that you also need to have at your disposal etc.

It's harder to use than BPF, which is already really hard to use.

I don't think the ACPI situation is any better for the matter, and
a solution using DT overlays will not play nice with ACPI systems
so we just leave that part of the world out.

> It is
> simply not attractive to have tutorials or examples that will require a
> reboot to work. And since a lot of people will start with those examples,
> they will continue using userspace drivers for their future projects.

I agree.

I have an idea about this.

If we want to use an existing kernel drivers for dynamic devices,
something in-kernel and Linux-specific that is easy to use is
needed. I would rather look into something that enables
creation of some devices using the Linux-specific software nodes,
because *those* we can control how we configure, preferably
from configfs I suppose, but Bartosz already burnt himself trying
to use configfs once so I don't know about that specific.

Consider for example, if we have a sysfs like I suggested:

/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

With software nodes we can:

cd /sys/bus/gpio
cat available_gpio_drivers
i2c-gpio leds-gpio
echo leds-gpio > gpio_drivers

[/sys/bus/gpio/drivers/leds-gpio.0 appears in sysfs]

ln -s gpiochip0/gpio4 drivers/leds-gpio.0/gpios

[ probe of leds-gpio driver happens using that gpio line
  now that its GPIO resources are provided]

I easily see this working for any of the drivers in
Documentation/driver-api/gpio/drivers-on-gpio.rst

Yes, it is not a solution to everything no matter how
complex a user may attach to their system, which is
the ambition of device tree overlays.

It solves the issue of dynamically probing devices
*only* using GPIO lines.

Yes: it will drive a truck through any kind of kernel integrity
and security, it provides a userspace footgun to shoot
oneself in the foot. But users want it, so hey. We point it
out. We put it as an expert option. Whatever of those.

However these devices *will* be performant as they are
regular kernel drivers, and they *will* be able to use
interrupts in a proper way.

Yours,
Linus Walleij

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Ayush Singh]

On 2/26/25 01:50, Linus Walleij wrote:

> On Tue, Feb 25, 2025 at 7:25 PM Ayush Singh <ayushsingh1325@gmail.com> wrote:
>
>> One of the reasons of the prevalence of userspace drivers (and probably
>> the reason why kernel drivers for stuff like motors are not attractive)
>> is the lack of upstream solution for runtime devicetree overlays.
> Given how long device tree overlays have been talked about
> and hypothesized I am of the opinion that they are never
> going to fly.
>
> My main complaints being that they are just too complex and hard
> on users: special tools needed, compile files, files relate to other
> existing dts(i) files that you also need to have at your disposal etc.

Well, devicetree overlays also have some benefits. Particularly that it

is an open standard, and can be shared with ZephyrRTOS, if done properly.

The syntax itself is not particularly hard, and it isn't difficult to

create tools to make creating device trees easier.


The current compiler errors are not great to be honest, but that is

mostly due to the fact the barrier to entry for end users is quite

high (go u-boot route or modify the current device tree) instead of

sysfs APIs which other tools can interact with to generate overlays

on the fly. In short, if the kernel provides a userspace API, the

development on compiler and other userspace tools side can make

the process much simpler.

I don't think many people will directly write devicetree overlays,

but generating them is not difficult since it is a defined standard.

> It's harder to use than BPF, which is already really hard to use.
>
> I don't think the ACPI situation is any better for the matter, and
> a solution using DT overlays will not play nice with ACPI systems
> so we just leave that part of the world out.


Can't really comment on ACPI since have not interacted with that much.

>> It is
>> simply not attractive to have tutorials or examples that will require a
>> reboot to work. And since a lot of people will start with those examples,
>> they will continue using userspace drivers for their future projects.
> I agree.
>
> I have an idea about this.
>
> If we want to use an existing kernel drivers for dynamic devices,
> something in-kernel and Linux-specific that is easy to use is
> needed. I would rather look into something that enables
> creation of some devices using the Linux-specific software nodes,
> because *those* we can control how we configure, preferably
> from configfs I suppose, but Bartosz already burnt himself trying
> to use configfs once so I don't know about that specific.
>
> Consider for example, if we have a sysfs like I suggested:
>
> /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
>
> With software nodes we can:
>
> cd /sys/bus/gpio
> cat available_gpio_drivers
> i2c-gpio leds-gpio
> echo leds-gpio > gpio_drivers
>
> [/sys/bus/gpio/drivers/leds-gpio.0 appears in sysfs]
>
> ln -s gpiochip0/gpio4 drivers/leds-gpio.0/gpios
>
> [ probe of leds-gpio driver happens using that gpio line
>    now that its GPIO resources are provided]
>
> I easily see this working for any of the drivers in
> Documentation/driver-api/gpio/drivers-on-gpio.rst
>
> Yes, it is not a solution to everything no matter how
> complex a user may attach to their system, which is
> the ambition of device tree overlays.
>
> It solves the issue of dynamically probing devices
> *only* using GPIO lines.
>
> Yes: it will drive a truck through any kind of kernel integrity
> and security, it provides a userspace footgun to shoot
> oneself in the foot. But users want it, so hey. We point it
> out. We put it as an expert option. Whatever of those.

Well, any solution we come up with, has to be for endusers

and not just a developer interface. I have suggested

maybe locking down the dt overlays to some specific

nodes which need to be declared in devicetree [0], but I am

not the maintainer of the subsystem, so many people need

to agree there, but let's see.


Btw, I do agree that there should be a sysfs based API for GPIO.

It's quite a pain when you want to not have external dependencies.

I have used the `ioctl` based API directly, but even then you end

up depending on libc (and ioctl signature is different between musl

and glibc). Additionally, all the structures and error handling just

builds up.

> However these devices *will* be performant as they are
> regular kernel drivers, and they *will* be able to use
> interrupts in a proper way.
>
> Yours,
> Linus Walleij


[0]: 
https://lore.kernel.org/all/d5bed265-1dbd-44d1-8287-8ca993624b79@beagleboard.org/

Best Regards,

Ayush Singh

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Linus Walleij]

On Sun, Feb 2, 2025 at 1:46 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> 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 (...)
>
> 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?

Yes, I think it is mostly equivalent to what I say in drivers/gpio/TODO,
my only point being that when we add something like this, we
put it in debugfs where it belongs, and as illustrated by your
example, it is indeed used for debugging/exploring the
system:

----------------8<----------------------------8<------------------------
Debugfs in place of sysfs

The old sysfs code that enables simple uses of GPIOs from the
command line is still popular despite the existance of the proper
character device. The reason is that it is simple to use on
root filesystems where you only have a minimal set of tools such
as "cat", "echo" etc.

The old sysfs still need to be strongly deprecated and removed
as it relies on the global GPIO numberspace that assume a strict
order of global GPIO numbers that do not change between boots
and is independent of probe order.

To solve this and provide an ABI that people can use for hacks
and development, implement a debugfs interface to manipulate
GPIO lines that can do everything that sysfs can do today: one
directory per gpiochip and one file entry per line:

/sys/kernel/debug/gpiochip/gpiochip0
/sys/kernel/debug/gpiochip/gpiochip0/gpio0
/sys/kernel/debug/gpiochip/gpiochip0/gpio1
/sys/kernel/debug/gpiochip/gpiochip0/gpio2
/sys/kernel/debug/gpiochip/gpiochip0/gpio3
...
/sys/kernel/debug/gpiochip/gpiochip1
/sys/kernel/debug/gpiochip/gpiochip1/gpio0
/sys/kernel/debug/gpiochip/gpiochip1/gpio1
...

The exact files and design of the debugfs interface can be
discussed but the idea is to provide a low-level access point
for debugging and hacking and to expose all lines without the
need of any exporting. Also provide ample ammunition to shoot
oneself in the foot, because this is debugfs after all.
----------------8<----------------------------8<------------------------

Yours,
Linus Walleij

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Marek Vasut]

On 2/14/25 10:14 AM, Linus Walleij wrote:
> On Sun, Feb 2, 2025 at 1:46 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

Hi,

I'm sorry for the late reply.

>> 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 (...)
>>
>> 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?
> 
> Yes, I think it is mostly equivalent to what I say in drivers/gpio/TODO,
> my only point being that when we add something like this, we
> put it in debugfs where it belongs, and as illustrated by your
> example, it is indeed used for debugging/exploring the
> system:

I would very much like to avoid having to enable debugfs on production 
systems to access GPIOs in early userspace (e.g. initramfs). This was so 
far possible via the sysfs API without tools, currently it is becoming 
not easily possible. A sysfs API "v2" which makes that possible would be 
very much appreciated.

Also note that I do not care about static GPIO number assignment in the 
sysfs API, so that part can go.

> ----------------8<----------------------------8<------------------------
> Debugfs in place of sysfs
> 
> The old sysfs code that enables simple uses of GPIOs from the
> command line is still popular despite the existance of the proper
> character device. The reason is that it is simple to use on
> root filesystems where you only have a minimal set of tools such
> as "cat", "echo" etc.

Yes

> The old sysfs still need to be strongly deprecated and removed
> as it relies on the global GPIO numberspace that assume a strict
> order of global GPIO numbers that do not change between boots
> and is independent of probe order.

Yes

> To solve this and provide an ABI that people can use for hacks
> and development, implement a debugfs

sysfs please.

[...]

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Linus Walleij]

On Fri, Feb 21, 2025 at 8:41 PM Marek Vasut <marex@denx.de> wrote:

> I would very much like to avoid having to enable debugfs on production
> systems to access GPIOs in early userspace (e.g. initramfs).

I didn't understand that. It was because Bartosz used the word "play":

>> The gist of it is: some people need to play with GPIOs very early, for
>> example in an initramfs

So I took that word literal: explore, play around. Not develop
products.

> This was so
> far possible via the sysfs API without tools, currently it is becoming
> not easily possible. A sysfs API "v2" which makes that possible would be
> very much appreciated.

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

- Doesn't need any echo NN > export to see the lines in
  sysfs.

Let's just show them all and introduce an ABI for grabbing one
line at a time and shake it.

/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

 I think at this point all that is needed is a patch set.

Yours,
Linus Walleij

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Marek Vasut]

On 2/25/25 8:54 PM, Linus Walleij wrote:
> On Fri, Feb 21, 2025 at 8:41 PM Marek Vasut <marex@denx.de> wrote:
> 
>> I would very much like to avoid having to enable debugfs on production
>> systems to access GPIOs in early userspace (e.g. initramfs).
> 
> I didn't understand that. It was because Bartosz used the word "play":

Uh oh ... in short, the entire discussion between me and Bartosz at 
FOSDEM could be summarized to (please correct me if I'm wrong and I'm 
stuffing words into someone's mouth):

- Bartosz does not like fixed static GPIO number assignment, we agree
- Bartosz wants to write more userspace tools to operate GPIO chardev
   API, we do not agree, Marek already has all the tools built into shell
   (printf, echo, cat)

=> Some sysfs API "v2" which does not suffer from the defects of the
    current one would be great. The benefit would be:
    - Can be operated without extra tools, simple printf/echo/cat into
      sysfs attributes would suffice
    - Would work even in the simplest of userspaces (initramfs, remote
      access VMs, etc.), which is practical for board bring up and well,
      other limited deployments

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

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

>>> The gist of it is: some people need to play with GPIOs very early, for
>>> example in an initramfs
> 
> So I took that word literal: explore, play around. Not develop
> products.
> 
>> This was so
>> far possible via the sysfs API without tools, currently it is becoming
>> not easily possible. A sysfs API "v2" which makes that possible would be
>> very much appreciated.
> 
> 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 ?

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 ?

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Bartosz Golaszewski]

On Wed, Feb 26, 2025 at 1:43 PM Marek Vasut <marex@denx.de> wrote:
>
> Can we really make do without export/unexport ?
>
> 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 ?

If the kernel module in question registers a driver that will bind to
a device which wants to request the same GPIO that sysfs already
holds, then gpiod_get() will fail with -EBUSY. In other words: even if
we drop export, there still has to be some way of "claiming" the
GPIOs. /sys/bus/gpio/gpiochip0/gpio0/request? I think I prefer
export/unexport.

Bartosz

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Linus Walleij]

On Wed, Feb 26, 2025 at 1:43 PM Marek Vasut <marex@denx.de> 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

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Geert Uytterhoeven]

Hi Linus,

On Fri, 28 Feb 2025 at 08:50, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Feb 26, 2025 at 1:43 PM Marek Vasut <marex@denx.de> wrote:
> > > 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.

So that would be 0..<N-1>, not <base>..<base+N-1>?
Hence you cannot have global (un)export files in sysfs, but need
per-chip (un)export files?

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

Why would you want to always "see" all GPIO lines?
What is the use case for that? What am I missing?

If it is recommended not to use this interface, I think all GPIOs
should be invisible by default.  Hence I still prefer the (un)export
interface.

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Linus Walleij]

On Fri, Feb 28, 2025 at 9:50 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> > /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.
>
> Why would you want to always "see" all GPIO lines?
> What is the use case for that? What am I missing?

Because in the current ABI the user has to implicitly
know how many GPIOs there is on a gpiochip in order
to know which lines can be requested, and that's not
good.

You know you can probably request gpio 0 but can
you request GPIO 104?

Also sysfs is explicitly for topology and this is topology,
by the book.

> If it is recommended not to use this interface, I think all GPIOs
> should be invisible by default.  Hence I still prefer the (un)export
> interface.

I think the whole point of the thread is that this so-called
sysfs v2 is supposed to be recommendable because users
want something like this.

Yours,
Linus Walleij

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Geert Uytterhoeven]

Hi Linus,

On Fri, 28 Feb 2025 at 09:56, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Feb 28, 2025 at 9:50 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > /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.
> >
> > Why would you want to always "see" all GPIO lines?
> > What is the use case for that? What am I missing?
>
> Because in the current ABI the user has to implicitly
> know how many GPIOs there is on a gpiochip in order
> to know which lines can be requested, and that's not
> good.

Doesn't the ngpio virtual file tell you that?

> You know you can probably request gpio 0 but can
> you request GPIO 104?

I guess most people who play/mess/... with GPIOs directly know by
heart how many GPIOs there are on their gpiochips (at least I do ;-)

> Also sysfs is explicitly for topology and this is topology,
> by the book.
>
> > If it is recommended not to use this interface, I think all GPIOs
> > should be invisible by default.  Hence I still prefer the (un)export
> > interface.
>
> I think the whole point of the thread is that this so-called
> sysfs v2 is supposed to be recommendable because users
> want something like this.

Let's keep it simple, and similar/identical to the existing API?

Is there anything in Documentation/ABI/obsolete/sysfs-gpio
we can drop? edge?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Linus Walleij]

On Fri, Feb 28, 2025 at 10:53 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:

> Let's keep it simple, and similar/identical to the existing API?
>
> Is there anything in Documentation/ABI/obsolete/sysfs-gpio
> we can drop? edge?

I suggested dropping all of the irq stuff earlier in the
thread, given how bad quality it is. Especially if it's edge
triggered it can easily squash 100 or 1000 IRQs into one
fsnotify event.

Yours,
Linus Walleij

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Kent Gibson]

On Wed, Mar 05, 2025 at 09:22:42AM +0100, Linus Walleij wrote:
> On Fri, Feb 28, 2025 at 10:53 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>
> > Let's keep it simple, and similar/identical to the existing API?
> >
> > Is there anything in Documentation/ABI/obsolete/sysfs-gpio
> > we can drop? edge?
>
> I suggested dropping all of the irq stuff earlier in the
> thread, given how bad quality it is. Especially if it's edge
> triggered it can easily squash 100 or 1000 IRQs into one
> fsnotify event.
>

+1 for removing edge and poll(2) on value.  Keep the sysfs as a very
basic set/get interface for environments where ioctl()s are too
burdensome.

Not sure that active_low serves any purpose other than adding confusion.
Drop active_low and only support physical levels?

Cheers,
Kent.

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Bartosz Golaszewski]

On Fri, Feb 28, 2025 at 10:53 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> >
> > I think the whole point of the thread is that this so-called
> > sysfs v2 is supposed to be recommendable because users
> > want something like this.
>
> Let's keep it simple, and similar/identical to the existing API?
>
> Is there anything in Documentation/ABI/obsolete/sysfs-gpio
> we can drop? edge?
>

I would like to object here: I really *don't* want a fourth interface
to support. I don't agree to a "sysfs v2" ABI. What I proposed is a
backward-compatible *extension* of the existing interface and then
gradual removal of unwanted features over time.

Bart

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Geert Uytterhoeven]

Hi Bartosz,

On Tue, 11 Mar 2025 at 11:28, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> On Fri, Feb 28, 2025 at 10:53 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > > I think the whole point of the thread is that this so-called
> > > sysfs v2 is supposed to be recommendable because users
> > > want something like this.
> >
> > Let's keep it simple, and similar/identical to the existing API?
> >
> > Is there anything in Documentation/ABI/obsolete/sysfs-gpio
> > we can drop? edge?
>
> I would like to object here: I really *don't* want a fourth interface
> to support. I don't agree to a "sysfs v2" ABI. What I proposed is a
> backward-compatible *extension* of the existing interface and then
> gradual removal of unwanted features over time.

That is exactly what I meant: do not invent with a new sysfs API, but
remove from the existing one, and simplify its backend where possible.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Bartosz Golaszewski]

On Tue, Mar 11, 2025 at 11:52 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Bartosz,
>
> On Tue, 11 Mar 2025 at 11:28, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > On Fri, Feb 28, 2025 at 10:53 AM Geert Uytterhoeven
> > <geert@linux-m68k.org> wrote:
> > > > I think the whole point of the thread is that this so-called
> > > > sysfs v2 is supposed to be recommendable because users
> > > > want something like this.
> > >
> > > Let's keep it simple, and similar/identical to the existing API?
> > >
> > > Is there anything in Documentation/ABI/obsolete/sysfs-gpio
> > > we can drop? edge?
> >
> > I would like to object here: I really *don't* want a fourth interface
> > to support. I don't agree to a "sysfs v2" ABI. What I proposed is a
> > backward-compatible *extension* of the existing interface and then
> > gradual removal of unwanted features over time.
>
> That is exactly what I meant: do not invent with a new sysfs API, but
> remove from the existing one, and simplify its backend where possible.
>

Sure, just clarifying for the record because the "sysfs v2" triggered
an alarm bell in my head.

Bartosz

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Geert Uytterhoeven]

Hi Bartosz,

On Tue, 11 Mar 2025 at 12:54, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> On Tue, Mar 11, 2025 at 11:52 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Tue, 11 Mar 2025 at 11:28, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > On Fri, Feb 28, 2025 at 10:53 AM Geert Uytterhoeven
> > > <geert@linux-m68k.org> wrote:
> > > > > I think the whole point of the thread is that this so-called
> > > > > sysfs v2 is supposed to be recommendable because users
> > > > > want something like this.
> > > >
> > > > Let's keep it simple, and similar/identical to the existing API?
> > > >
> > > > Is there anything in Documentation/ABI/obsolete/sysfs-gpio
> > > > we can drop? edge?
> > >
> > > I would like to object here: I really *don't* want a fourth interface
> > > to support. I don't agree to a "sysfs v2" ABI. What I proposed is a
> > > backward-compatible *extension* of the existing interface and then
> > > gradual removal of unwanted features over time.
> >
> > That is exactly what I meant: do not invent with a new sysfs API, but
> > remove from the existing one, and simplify its backend where possible.
>
> Sure, just clarifying for the record because the "sysfs v2" triggered
> an alarm bell in my head.

IIUIC, "Sysfs v2" was coined by Marek, and dragged forward by Linus.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Ahmad Fatoum]

Hello Linus,

On 14.02.25 10:14, Linus Walleij wrote:
> On Sun, Feb 2, 2025 at 1:46 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> 
>> 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 (...)
>>
>> 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?
> 
> Yes, I think it is mostly equivalent to what I say in drivers/gpio/TODO,

I wasn't aware of this file. Thanks for pointing it out.

> my only point being that when we add something like this, we
> put it in debugfs where it belongs, and as illustrated by your
> example, it is indeed used for debugging/exploring the
> system:

Why does it belong in debugfs? The whole premise of Bartosz's mail is
to provide holdouts that haven't yet migrated away from the sysfs global
number space an alternative _stable_ kernel interface they can rely on.

DebugFS is the opposite of that. It may not even be available in those
resource-constrained systems that this would be useful for.

> ----------------8<----------------------------8<------------------------
> Debugfs in place of sysfs
> 
> The old sysfs code that enables simple uses of GPIOs from the
> command line is still popular despite the existance of the proper
> character device. The reason is that it is simple to use on
> root filesystems where you only have a minimal set of tools such
> as "cat", "echo" etc.

And most importantly having the kernel keep the line requested.

> The old sysfs still need to be strongly deprecated and removed
> as it relies on the global GPIO numberspace that assume a strict
> order of global GPIO numbers that do not change between boots
> and is independent of probe order.

The new proposal gets rid of the global numberspace all the same.

> To solve this and provide an ABI that people can use for hacks
> and development, implement a debugfs interface to manipulate
> GPIO lines that can do everything that sysfs can do today: one
> directory per gpiochip and one file entry per line:

[snip]

> The exact files and design of the debugfs interface can be
> discussed but the idea is to provide a low-level access point
> for debugging and hacking and to expose all lines without the
> need of any exporting. Also provide ample ammunition to shoot
> oneself in the foot, because this is debugfs after all.

I am afraid that if we go the debugfs route, we end up with
a solution that just needs maintenance, but doesn't win users
over.

The target audience is not developers doing interactive debugging
or development. It's embedded folks having init scripts which need
GPIO lines to stay requested or software like labgrid that needs
to login to a remote host outside of its control and needs to toggle
GPIOs.

These users won't consider an unstable debugfs interface.

Thanks,
Ahmad



-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Linus Walleij]

On Fri, Feb 21, 2025 at 8:56 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:

> > my only point being that when we add something like this, we
> > put it in debugfs where it belongs, and as illustrated by your
> > example, it is indeed used for debugging/exploring the
> > system:
>
> Why does it belong in debugfs? The whole premise of Bartosz's mail is
> to provide holdouts that haven't yet migrated away from the sysfs global
> number space an alternative _stable_ kernel interface they can rely on.
>
> DebugFS is the opposite of that. It may not even be available in those
> resource-constrained systems that this would be useful for.

This is in my answer to Marek, I misunderstood the wording
"play with GPIO lines" as "explore, develop, bring up" GPIO lines.
Not as "create products using sysfs GPIOs".

See my mail to Marek.

Yours,
Linus Walleij

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Kent Gibson]

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.

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Geert Uytterhoeven]

Hi Kent,

On Mon, 24 Feb 2025 at 02:49, Kent Gibson <warthog618@gmail.com> wrote:
> 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?

l doubt the global numberspace will really go away: some number
scheme is still needed internally, cfr. I2C bus numbers and virtual
interrupts numbers.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Bartosz Golaszewski]

On Mon, Feb 24, 2025 at 2:49 AM Kent Gibson <warthog618@gmail.com> wrote:
>
> >
> > 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.
>

TBH that's technically easy and backward compatible - just have a link
named after the label pointing to the chip.

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

Good point, at this point we'd have to switch to fully identifying
chips by label and possibly the device name (gpiochipX, not
gpiochip$BASE).

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

Yeah I was taken by surprise, I wasn't aware of the RPi driver having
this parameter.

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

This is not that simple actually. struct gpio_chip has the .free()
callack which leaves to the driver the freedom to do anything at
release - including reverting the state or not. What and when should
the core framework code do then? But I'm not saying no if we can have
a good solution here.

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

I don't know the history of this. It's a driver under drivers/pinctrl/
and I was never Cc'ed on the patch that added it. I probably would
have objected to doing it inside an individual module.

Bart

Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Kent Gibson]

On Wed, Feb 26, 2025 at 10:23:37AM +0100, Bartosz Golaszewski wrote:
> On Mon, Feb 24, 2025 at 2:49 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> >
> > 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.
> >
>
> TBH that's technically easy and backward compatible - just have a link
> named after the label pointing to the chip.
>
> > Aside: Speaking of which, once the global numberspace is removed does
> > exposing the base address serve any purpose?
> >
>
> Good point, at this point we'd have to switch to fully identifying
> chips by label and possibly the device name (gpiochipX, not
> gpiochip$BASE).
>

That works for me.  Though are chip labels quaranteed unique?

> > 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.
>
> Yeah I was taken by surprise, I wasn't aware of the RPi driver having
> this parameter.
>
> > 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?
> >
>
> This is not that simple actually. struct gpio_chip has the .free()
> callack which leaves to the driver the freedom to do anything at
> release - including reverting the state or not. What and when should
> the core framework code do then? But I'm not saying no if we can have
> a good solution here.
>

That is exactly the point - the driver has the freedom to do whatever
once .free() is called.  What I am suggesting is that while the user has
the line requested they could set a flag, say via .set_config(), to request
the driver NOT to revert the line, but to leave it as is when freed.
That would stand until the next time the line is requested when the flag
would automatically be cleared.

It would be opt-in, so the driver would not have to support it.
And it could be exposed to userspace via a flag in the uAPI.

> > 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?
> >
>
> I don't know the history of this. It's a driver under drivers/pinctrl/
> and I was never Cc'ed on the patch that added it. I probably would
> have objected to doing it inside an individual module.
>

Actually you were on the cc list[1], as was I, but it was a pinctrl change
so you probably skimmed over it.
I only looked at it as the bcm caught my eye, and I'm somewhat familiar
with how the Pi devs addressed the gpioset persistence issue downstream.

I wasn't totally comfortable with the change either, certainly not as a
general solution, but it was contained to the module so I didn't object -
I figured either you or Linus would if it bothered you.

Cheers,
Kent.

[1] https://lore.kernel.org/linux-gpio/20240503062745.11298-1-wahrenst@gmx.net/