Messages in this thread | | | Date | Wed, 17 May 2023 06:47:15 +0800 | From | Kent Gibson <> | Subject | Re: [PATCH] gpiolib: Avoid side effects in gpio_is_visible() |
| |
On Tue, May 16, 2023 at 10:19:14PM +0000, Chris Packham wrote: > > On 17/05/23 01:57, Linus Walleij wrote: > > On Mon, May 15, 2023 at 12:27 AM Chris Packham > > <Chris.Packham@alliedtelesis.co.nz> wrote: > > > >> In my original case which is a kernel module that exports a GPIO for > >> userspace using gpiod_export() > > We should not add new users for that API as it increase the usage > > of the sysfs ABI but if it's an existing in-tree usecase I buy it. > > > >> The crux of the problem is that the irq_desc is created when it hasn't > >> been requested. > > The right solution to me seems to be to not use gpiod_export() > > and not use sysfs TBH. > > That's not really a feasible solution. I'm dealing with application code > that has been happily using the sysfs interface for many years. > > I actually did look at getting that code updated to use libgpio earlier > this year but found the API was in a state of flux and I wasn't going to > recommend re-writing the application code to use libgpio if I knew the > API was going to change and we'd have to re-write it again. >
Its 'libgpiod'.
> Even now with the 2.0.1 libgpio there doesn't seem to be a way of asking > about just GPIO lines in the system, application code would still need > to open every /dev/gpiochipN device and ask what lines are on the chip > and keep the fds open for the chips that have lines the application > cares about but make sure to close the fd for the ones that don't. So > now the application code has to care about GPIO chips in addition to the > GPIO lines. >
Trying to better understand your use case - how does your application identify lines of interest - just whatever lines pop up in /sys/class/gpio?
Cheers, Kent.
| |