Re: Replacing global GPIO numbers in sysfs with hardware offsets

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Tue, Feb 25, 2025 at 7:25 PM Ayush Singh <ayushsingh1325@xxxxxxxxx> 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