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

[Uwe Kleine-König]

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.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Attachment: signature.asc
Description: PGP signature