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:   Mon, 25 May 2020 10:22:52 +0800
From:   Kent Gibson <>
To:     Linus Walleij <>
Cc:     Bartosz Golaszewski <>,
        Hector Bujanda <>,
        "open list:GPIO SUBSYSTEM" <>,
        Linux Kernel Mailing List <>
Subject: Re: [PATCH] gpiolib: add GPIO_SET_DEBOUNCE_IOCTL

On Wed, Apr 29, 2020 at 02:38:13PM +0200, Linus Walleij wrote:
> On Wed, Apr 29, 2020 at 2:06 PM Bartosz Golaszewski <> wrote:
> > I understand the need to set debounce time to make line events
> > reliable. As I see it: there'll be a couple steps to add this.
> I think there is a serious user-facing problem here though, because
> not all GPIO controllers supports debounce, so the call may return
> "nope" (error code).
> I think that is unavoidable with things like pull-up/down or drive
> strength, but for debounce I think we could do better.
> drivers/input/keyboard/gpio_keys.c contains generic
> debounce code using kernel timers if the GPIO driver
> cannot provide debouncing, and I have thought for a long
> time that it would be nice if we could do this generic, so that
> we always provide debouncing if requested, even for in-kernel
> consumers but most certainly for userspace consumers,
> else userspace will just start to reinvent this too.

I'm looking at implementing the software debounce you suggest here,
using the gpio_keys example as a starting point, but find that there are
actually two different debounce strategies in gpio_keys. For gpio pins
that don't support debounce in hw, it uses mod_delayed_work to put off
reading the new value until the line has settled (i.e. no interrupts
received) for the debounce period.
For non-gpio lines it uses timers to poll the line at the debounce

You mention timers for the gpio pins that cannot provide debounce, 
so I'm confused. Could you clarify which strategy you have in mind?

I've also had a quick look at the possibility of providing the software
debounce for in-kernel consumers.  Are you anticipating new API for
that?  e.g. allowing consumers to request gpio events?  Cos, gpio_keys
grabs the irq itself - and that would bypass the software debouncer,
or even conflict with it.


Powered by blists - more mailing lists