[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdbiSAFoJP_JB1d_6gQ+Xx7Y+mLAh=C6Za+fpyWuRe6Gbw@mail.gmail.com>
Date: Tue, 16 May 2023 15:57:57 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Chris Packham <Chris.Packham@...iedtelesis.co.nz>
Cc: "brgl@...ev.pl" <brgl@...ev.pl>,
"johan@...nel.org" <johan@...nel.org>,
"andy.shevchenko@...il.com" <andy.shevchenko@...il.com>,
"maz@...nel.org" <maz@...nel.org>,
Ben Brown <Ben.Brown@...iedtelesis.co.nz>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] gpiolib: Avoid side effects in gpio_is_visible()
On Mon, May 15, 2023 at 12:27 AM Chris Packham
<Chris.Packham@...iedtelesis.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.
> In some cases we know the GPIO pin is an output so we
> could avoid it, in others we could delay the creation until an interrupt
> is actually requested (which is what I'm attempting to do).
Yeah I guess. If we wanna keep papering over issues created
by the sysfs ABI.
Yours,
Linus Walleij
Powered by blists - more mailing lists