linux-kernel - Re: [PATCH v5 00/20] gpio: cdev: add uAPI v2

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:   Tue, 1 Sep 2020 11:28:13 +0200
From:   Bartosz Golaszewski <bgolaszewski@...libre.com>
To:     Kent Gibson <warthog618@...il.com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH v5 00/20] gpio: cdev: add uAPI v2

On Sat, Aug 29, 2020 at 3:35 AM Kent Gibson <warthog618@...il.com> wrote:
>
> On Fri, Aug 28, 2020 at 04:37:19PM +0200, Linus Walleij wrote:
> > On Fri, Aug 28, 2020 at 12:47 AM Kent Gibson <warthog618@...il.com> wrote:
> >
> > > The particular use case I am considering is one I had been asked about -
> > > changing a requested line from input with edge detection to output, and
> > > vice versa. Losing interrupts isn't really an issue for this use case -
> > > it is expected.  Yet the current implementation requires a re-request.
> >
> > This is possible to do for in-kernel users, but I don't know if that makes
> > sense for userspace. It is for one-offs and prototyping after all, there
> > is no need (IMO) to make it overly convenient for users to implement
> > all kind of weirdness in userspace unless there is a very real use case.
> >
>
> Fair point - in fact it is the same one that made me reconsider why I
> was so concerned about potentially losing an edge event in a few rare
> corner cases.
>
> Another point for this change are that it actually simplifies the kernel
> code, as it takes as much code to detect and filter these cases as it
> does to include them in the normal flow.
>
> I had a play with it yesterday and the change removes two whole
> functions, gpio_v2_line_config_change_validate() and
> gpio_v2_line_config_has_edge_detection() at the expense of making
> debounce_update() a little more complicated. I'm happy to put together a
> v6 that incorporates those changes if there aren't any strenuous
> objections - we can always revert to v5.  Or I could mail the couple of
> patches I've made and if they seem reasonable then I could merge them
> into this set?
>
> Cheers,
> Kent.

I personally like v6 more. The code is more elegant and we've also
tried limiting GPIO chardev features before and now we're doing v2 so
let's not make the same mistake twice. :)

I'll try to review v6 in detail later today.

Bartosz