[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=MeH=BB7QTOa5FoANLPS-BLutT87+E_guVjsWRvpEgDTnA@mail.gmail.com>
Date: Wed, 16 Jul 2025 10:26:44 +0200
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Kent Gibson <warthog618@...il.com>
Cc: Ahmad Fatoum <a.fatoum@...gutronix.de>, Jan Lübbe <jlu@...gutronix.de>,
Marek Vasut <marex@...x.de>, Geert Uytterhoeven <geert+renesas@...der.be>,
Linus Walleij <linus.walleij@...aro.org>, Andy Shevchenko <andriy.shevchenko@...el.com>,
linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v4 00/10] gpio: sysfs: add a per-chip export/unexport
attribute pair
On Mon, Jul 14, 2025 at 3:38 AM Kent Gibson <warthog618@...il.com> wrote:
>
> On Sun, Jul 13, 2025 at 10:48:03AM +0200, Bartosz Golaszewski wrote:
> > On Fri, Jul 4, 2025 at 2:58 PM Bartosz Golaszewski <brgl@...ev.pl> wrote:
> > >
> > > Following our discussion[1], here's a proposal for extending the sysfs
> > > interface with attributes not referring to GPIO lines by their global
> > > numbers in a backward compatible way.
> > >
> > > Long story short: there is now a new class device for each GPIO chip.
> > > It's called chipX where X is the ID of the device as per the driver
> > > model and it lives next to the old gpiochipABC where ABC is the GPIO
> > > base. Each new chip class device has a pair of export/unexport
> > > attributes which work similarly to the global ones under /sys/class/gpio
> > > but take hardware offsets within the chip as input, instead of the
> > > global numbers. Finally, each exported line appears at the same time as
> > > the global /sys/class/gpio/gpioABC as well as per-chip
> > > /sys/class/gpio/chipX/gpioY sysfs group except that the latter only
> > > implements a minimal subset of the functionality of the former, namely:
> > > only the 'direction' and 'value' attributes and it doesn't support event
> > > polling.
> > >
> > > The series contains the implementation of a parallel GPIO chip entry not
> > > containing the base GPIO number in the name and the corresponding sysfs
> > > attribute group for each exported line that lives under the new chip
> > > class device as well as a way to allow to compile out the legacy parts
> > > leaving only the new elements of the sysfs ABI.
> > >
> > > This series passes the compatibility tests I wrote while working on the
> > > user-space compatibility layer for sysfs[2].
> > >
> > > [1] https://lore.kernel.org/all/CAMRc=McUCeZcU6co1aN54rTudo+JfPjjForu4iKQ5npwXk6GXA@mail.gmail.com/
> > > [2] https://github.com/brgl/gpio-sysfs-compat-tests
> > >
> > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> > > ---
> >
> > Alright, so what are we doing about this? Should I queue these patches
> > for v6.17? Kent, any additional comments?
>
> Nothing beyond what I've already said.
>
> Cheers,
> Kent.
Ok, let's queue them up for v6.17 then.
Bart
Powered by blists - more mailing lists