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. It would be tempting to use symbolic links too but I'm afraid this would need further extension of configfs. > I intend to look into your driver next week, but please don't hold back > on merging for my feedback. > Don't worry, I'm not really aiming at v5.12 with this. > Best regards > Uwe > Bart
