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  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:   Sat, 29 Aug 2020 09:35:32 +0800
From:   Kent Gibson <>
To:     Linus Walleij <>
Cc:     Bartosz Golaszewski <>,
        Andy Shevchenko <>,
        "" <>,
        "open list:GPIO SUBSYSTEM" <>
Subject: Re: [PATCH v5 00/20] gpio: cdev: add uAPI v2

On Fri, Aug 28, 2020 at 04:37:19PM +0200, Linus Walleij wrote:
> On Fri, Aug 28, 2020 at 12:47 AM Kent Gibson <> 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?


Powered by blists - more mailing lists