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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMRc=McfTsAw4d+hEeRzm5XZ0uGiWEZYCjyFP0xTvN=L1gYh3A@mail.gmail.com>
Date:   Mon, 1 Feb 2021 13:50:59 +0100
From:   Bartosz Golaszewski <brgl@...ev.pl>
To:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Joel Becker <jlbec@...lplan.org>,
        Christoph Hellwig <hch@....de>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Jonathan Corbet <corbet@....net>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Kent Gibson <warthog618@...il.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-doc <linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH 0/8] gpio: implement the configfs testing module

On Mon, Feb 1, 2021 at 10:24 AM Uwe Kleine-König
<u.kleine-koenig@...gutronix.de> 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@...gutronix.de> wrote:
> > >
> > > Hello,
> > >
> > > On Fri, Jan 29, 2021 at 02:46:16PM +0100, Bartosz Golaszewski wrote:
> > > > From: Bartosz Golaszewski <bgolaszewski@...libre.com>
> > > >
> > > > 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