linux-kernel - Re: [PATCH v9 0/4] gpio-sim: configfs-based GPIO simulator

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 18 Nov 2021 17:46:56 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Bartosz Golaszewski <brgl@...ev.pl>
Cc:     Kent Gibson <warthog618@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Shuah Khan <shuah@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v9 0/4] gpio-sim: configfs-based GPIO simulator

On Thu, Nov 18, 2021 at 03:51:38PM +0100, Bartosz Golaszewski wrote:
> This is another shot at the gpio-sim testing module. As there was no
> reasoning with configfs maintainers for many months, this time the whole
> concept of committable items has been dropped. Instead, each configfs
> chip item (or rather a group - more on that later) exposes a new
> attribute called 'live'. Writing 1 to it brings the chip on-line
> (registers the platform device) and writing 0 tears it down.
> 
> There are some caveats to that approach - for example: we can't block
> the user-space from deleting chip items when chips are live but is just
> handled by silently destroying the chip device in the background.
> 
> Andy (rightfully) pointed out that parsing of the lists of line names is
> awkward so in this iteration it's been replaced by a system that is more
> elegant and will allow to easily extend configuration options for
> specific GPIO lines. This is achieved by turning the chip's configfs
> item into a configfs group and allowing the user-space to create
> additional items inside it. The items must be called line<offset> (e.g.
> line0, line12 etc.) where the offset part indicates to the module the
> offset for which given item stores the configuration for. Within each
> such line item, there are additional attributes that allow specifying
> configuration for specific lines. Currently we only support the 'name'
> attribute but I plan to extend that to support GPIO hogging too.

One question here. Since you know how the driver looks like in both cases
(with and without committable items), would it be possible to modify what
you proposed here to the former one in case ConfigFS gains the feature?


-- 
With Best Regards,
Andy Shevchenko