Re: [PATCH] gpio: export 'debounce' attribute if supported by thegpio chip

[Guenter Roeck]

On Fri, Dec 07, 2012 at 09:07:28AM +0100, Linus Walleij wrote:
> On Thu, Dec 6, 2012 at 7:32 AM, Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
> 
> > Create a 'debounce' attribute if debounce is supported by the gpio
> > chip and a gpio pin is exported.
> >
> > Signed-off-by: Guenter Roeck <linux@xxxxxxxxxxxx>
> 
> Can you describe the usecase for this?
> 
> I have this problem when working as a back-up GPIO maintainer that
> I don't really understand the userspace apps doing this.
> 
> I would guess something like a userspace app reading a GPIO switch
> and needing to set this to avoid key bounces, but it'd be nice to know
> if this is really the case.
> 
Yes, that is one if the use cases. Button pressed on the chassis/board
requesting user space action. Another is board presence detect pins which
require rebounce support and are handled in user space. Yes, the later should be
handled in the kernel, and most of them are, but there are some which don't need
immediate kernel activity and are handled completely by applications.

There may be other use cases - there are hundreds of gpio pins in the system I
am working on, and I have not looked into all of them.

> If this is the usecase I am slightly concerned why these are not used:
> drivers/input/keyboard/gpio_keys_polled.c
> drivers/input/keyboard/gpio_keys.c
> 
> The latter even uses the in-kernel debounce interface.
> 
> I'd agree if this is not user input at all but something like a switch
> in a factory production line.
> 
I could imagine declaring the activity request buttons to be "input", but for
presence detects it is a bit far fetched and would add too much complexity.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/