Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 17 May 2023 06:47:15 +0800
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()
Message-ID: <ZGQH8/hH0Llx3rzZ@sol>
References: <20230512042806.3438373-1-chris.packham@alliedtelesis.co.nz>
 <CACRpkdYz9ipNTo2ORXKWy5Q4uCpKL=9Gd+kK76pestX7Onuz-Q@mail.gmail.com>
 <b36fcdf1-45ab-0c06-efe4-237df0612466@alliedtelesis.co.nz>
 <CACRpkdbiSAFoJP_JB1d_6gQ+Xx7Y+mLAh=C6Za+fpyWuRe6Gbw@mail.gmail.com>
 <31a23398-9b0e-4a19-3576-84fcfd3ce4b5@alliedtelesis.co.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <31a23398-9b0e-4a19-3576-84fcfd3ce4b5@alliedtelesis.co.nz>
Precedence: bulk

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.