On Mon, Feb 1, 2021 at 10:24 AM Uwe Kleine-König
[off-list ref] wrote:

On Mon, Feb 01, 2021 at 09:37:30AM +0100, Bartosz Golaszewski wrote:

quoted

On Sat, Jan 30, 2021 at 10:20 PM Uwe Kleine-König
[off-list ref] wrote:

quoted

Hello,

On Fri, Jan 29, 2021 at 02:46:16PM +0100, Bartosz Golaszewski wrote:

quoted

From: Bartosz Golaszewski <redacted>

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.

quoted

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