Message ID | 20240927074221.9985-1-brgl@bgdev.pl |
---|---|
State | New |
Headers | show |
Series | [RFC] gpio: sysfs: make the sysfs export behavior consistent | expand |
On Fri, Sep 27, 2024 at 09:42:21AM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > For drivers or board files that set gpio_chip->names, the links to the > GPIO attribute group created on sysfs export will be named after the > line's name set in that array. For lines that are named using device > properties, the names pointer of the gpio_chip struct is never assigned > so they are exported as if they're not named. > > The ABI documentation does not mention the former behavior and given > that the majority of modern systems use device-tree, ACPI or other way > of passing GPIO names using device properties - bypassing gc->names - > it's better to make the behavior consistent by always exporting lines as > "gpioXYZ". > I have no opinions on sysfs changes. > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > --- > Story time: > > I decided to learn rust. I figured I'd best find me a project to work on > that would involve some proper coding but wouldn't have much impact on > anything important when I inevitably get it wrong the first few times. > > I decided to write a sysfs-to-libgpiod compatibility layer based on > FUSE. Since Rust is hard, I started prototyping the thing in python > first to at least have the logic nailed down before I tackle the rust > part. > Something along these lines[1]? Cheers, Kent. [1]https://dev.to/krjakbrjak/simulating-gpio-sysfs-interface-with-fuse-and-c-30ga
On Mon, Sep 30, 2024 at 3:03 AM Kent Gibson <warthog618@gmail.com> wrote: > > > I decided to write a sysfs-to-libgpiod compatibility layer based on > > FUSE. Since Rust is hard, I started prototyping the thing in python > > first to at least have the logic nailed down before I tackle the rust > > part. > > > > Something along these lines[1]? > > Cheers, > Kent. > > [1]https://dev.to/krjakbrjak/simulating-gpio-sysfs-interface-with-fuse-and-c-30ga > Well, this doesn't really do anything. I'm thinking about something consuming the libgpiod rust bindings to actually be a useful replacement for kernel sysfs. The master plan is: provide a drop-in user-space replacement for sysfs, make users convert to using it instead of the real thing, eventually remove sysfs from the kernel and then some time after remove the compatibility layer from existence forcing everybody to now move to pure libgpiod. :) Bart
On Mon, Sep 30, 2024 at 09:20:48AM +0200, Bartosz Golaszewski wrote: > On Mon, Sep 30, 2024 at 3:03 AM Kent Gibson <warthog618@gmail.com> wrote: > > > > > I decided to write a sysfs-to-libgpiod compatibility layer based on > > > FUSE. Since Rust is hard, I started prototyping the thing in python > > > first to at least have the logic nailed down before I tackle the rust > > > part. > > > > > > > Something along these lines[1]? > > > > Cheers, > > Kent. > > > > [1]https://dev.to/krjakbrjak/simulating-gpio-sysfs-interface-with-fuse-and-c-30ga > > > > Well, this doesn't really do anything. I'm thinking about something > consuming the libgpiod rust bindings to actually be a useful > replacement for kernel sysfs. > I haven't actually looked at that - but when you mentioned a sysfs fuse interface that rang a bell. > The master plan is: provide a drop-in user-space replacement for > sysfs, make users convert to using it instead of the real thing, > eventually remove sysfs from the kernel and then some time after > remove the compatibility layer from existence forcing everybody to now > move to pure libgpiod. :) > Ironically a lot of users would probably be happier with that than with the D-bus daemon. And for that reason I don't think that last step will ever happen. But that is ok too - as long as we can finally remove the sysfs interface from the kernel. Cheers, Kent.
On Fri, Sep 27, 2024 at 9:42 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > For drivers or board files that set gpio_chip->names, the links to the > GPIO attribute group created on sysfs export will be named after the > line's name set in that array. For lines that are named using device > properties, the names pointer of the gpio_chip struct is never assigned > so they are exported as if they're not named. > > The ABI documentation does not mention the former behavior and given > that the majority of modern systems use device-tree, ACPI or other way > of passing GPIO names using device properties - bypassing gc->names - > it's better to make the behavior consistent by always exporting lines as > "gpioXYZ". > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> I'm in favor of this. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > Story time: That's a good story :) Fun to see how you arrived at this. Yours, Linus Walleij
On Wed, Oct 2, 2024 at 3:12 PM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Fri, Sep 27, 2024 at 9:42 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > For drivers or board files that set gpio_chip->names, the links to the > > GPIO attribute group created on sysfs export will be named after the > > line's name set in that array. For lines that are named using device > > properties, the names pointer of the gpio_chip struct is never assigned > > so they are exported as if they're not named. > > > > The ABI documentation does not mention the former behavior and given > > that the majority of modern systems use device-tree, ACPI or other way > > of passing GPIO names using device properties - bypassing gc->names - > > it's better to make the behavior consistent by always exporting lines as > > "gpioXYZ". > > > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > I'm in favor of this. > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > I take it this also applies to v2 and am picking it up instead of this one. Bart > > Story time: > > That's a good story :) Fun to see how you arrived at this. > > Yours, > Linus Walleij
diff --git a/drivers/gpio/gpiolib-sysfs.c b/drivers/gpio/gpiolib-sysfs.c index 17ed229412af..643620d261f5 100644 --- a/drivers/gpio/gpiolib-sysfs.c +++ b/drivers/gpio/gpiolib-sysfs.c @@ -577,7 +577,7 @@ int gpiod_export(struct gpio_desc *desc, bool direction_may_change) struct gpio_device *gdev; struct gpiod_data *data; struct device *dev; - int status, offset; + int status; /* can't export until sysfs is available ... */ if (!class_is_registered(&gpio_class)) { @@ -626,10 +626,6 @@ int gpiod_export(struct gpio_desc *desc, bool direction_may_change) else data->direction_can_change = false; - offset = gpio_chip_hwgpio(desc); - if (guard.gc->names && guard.gc->names[offset]) - ioname = guard.gc->names[offset]; - dev = device_create_with_groups(&gpio_class, &gdev->dev, MKDEV(0, 0), data, gpio_groups, ioname ? ioname : "gpio%u",