Re: [PATCH] gpiolib: Avoid side effects in gpio_is_visible()

From: Kent Gibson <warthog618@gmail.com>
To: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	"brgl@bgdev.pl" <brgl@bgdev.pl>,
	"johan@kernel.org" <johan@kernel.org>,
	"andy.shevchenko@gmail.com" <andy.shevchenko@gmail.com>,
	"maz@kernel.org" <maz@kernel.org>,
	Ben Brown <Ben.Brown@alliedtelesis.co.nz>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] gpiolib: Avoid side effects in gpio_is_visible()
Date: Wed, 17 May 2023 06:47:15 +0800	[thread overview]
Message-ID: <ZGQH8/hH0Llx3rzZ@sol> (raw)
In-Reply-To: <31a23398-9b0e-4a19-3576-84fcfd3ce4b5@alliedtelesis.co.nz>

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.