Re: [PATCH 0/8] gpio: implement the configfs testing module

[Bartosz Golaszewski]

On Mon, Feb 1, 2021 at 10:24 AM Uwe Kleine-König
<u.kleine-koenig@xxxxxxxxxxxxxx> wrote:
>
> On Mon, Feb 01, 2021 at 09:37:30AM +0100, Bartosz Golaszewski wrote:
> > On Sat, Jan 30, 2021 at 10:20 PM Uwe Kleine-König
> > <u.kleine-koenig@xxxxxxxxxxxxxx> wrote:
> > >
> > > Hello,
> > >
> > > On Fri, Jan 29, 2021 at 02:46:16PM +0100, Bartosz Golaszewski wrote:
> > > > From: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx>
> > > >
> > > > This series adds a new GPIO testing module based on configfs committable items
> > > > and sysfs. The goal is to provide a testing driver that will be configurable
> > > > at runtime (won't need module reload) and easily extensible. The control over
> > > > the attributes is also much more fine-grained than in gpio-mockup.
> > > >
> > > > I am aware that Uwe submitted a virtual driver called gpio-simulator some time
> > > > ago and I was against merging it as it wasn't much different from gpio-mockup.
> > > > I would ideally want to have a single testing driver to maintain so I am
> > > > proposing this module as a replacement for gpio-mockup but since selftests
> > > > and libgpiod depend on it and it also has users in the community, we can't
> > > > outright remove it until everyone switched to the new interface. As for Uwe's
> > > > idea for linking two simulated chips so that one controls the other - while
> > > > I prefer to have an independent code path for controlling the lines (hence
> > > > the sysfs attributes), I'm open to implementing it in this new driver. It
> > > > should be much more feature friendly thanks to configfs than gpio-mockup.
> > >
> > > Funny you still think about my simulator driver. I recently thought
> >
> > It's because I always feel bad when I refuse to merge someone's hard work.
> >
> > > about reanimating it for my private use. The idea was to implement a
> > > rotary-encoder driver (that contrast to
> > > drivers/input/misc/rotary_encoder.c really implements an encoder and not
> > > a decoder). With the two linked chips I can plug
> > > drivers/input/misc/rotary_encoder.c on one side and my encoder on the
> > > other to test both drivers completely in software.
> > >
> > > I didn't look into your driver yet, but getting such a driver into
> > > mainline would be very welcome!
> > >
> >
> > My idea for linking chips (although that's not implemented yet) is an
> > attribute in each configfs group called 'link' or something like that,
> > that would take as argument the name of the chip to link to making the
> > 'linker' the input and the 'linkee' the output.
>
> I still wonder why you prefer to drive the lines using configfs (or
> sysfs before). Using the idea of two interlinked chips and being able to
> use gpio functions on one side to modify the other side is (in my eyes)
> so simple and beautiful that it's obviously the right choice. But note I
> still didn't look into details so there might be stuff you can modify
> that wouldn't be possible with my idea. But obviously your mileage
> varies here.
>

Not only drive but also check the input mode using a different code
path. My thinking is this: if, for example, we're checking the input
mode, let's not involve the core gpiolib's output code from a
different chip. Let's try to isolate the specific use-cases. Keep in
mind that my particular use-case is testing the uAPI with libgpiod's
test suite.

Also: previously it was debugfs, now we're switching to configs (for
configuring the devices) and sysfs (for controlling them).

Bart