Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Ayush Singh <ayush@beagleboard.org>]

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