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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 25 May 2020 10:22:52 +0800 From: Kent Gibson <warthog618@...il.com> To: Linus Walleij <linus.walleij@...aro.org> Cc: Bartosz Golaszewski <brgl@...ev.pl>, Hector Bujanda <hector.bujanda@...i.com>, "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> 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 <brgl@...ev.pl> 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 period. 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. Thanks, Kent.
Powered by blists - more mailing lists