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
