linux-kernel - Re: [PATCH/RFC] hardware irq debouncing support

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200810030145.02779.david-b@pacbell.net>
Date:	Fri, 3 Oct 2008 01:45:01 -0700
From:	David Brownell <david-b@...bell.net>
To:	Tony Lindgren <tony@...mide.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Haavard Skinnemoen <hskinnemoen@...el.com>,
	Andrew Victor <linux@...im.org.za>,
	Kevin Hilman <khilman@...prootsystems.com>
Subject: Re: [PATCH/RFC] hardware irq debouncing support

On Friday 03 October 2008, Tony Lindgren wrote:
> * David Brownell <david-b@...bell.net> [080924 22:51]:
> > Hardware IRQ debouncing is common for IRQ controllers which are
> > part of GPIO modules ... they often deal with mechanical switches,
> > buttons, and so forth.  This patch:
> > 
> >  - Provides simple support for that in genirq
> > 
> >  - Includes sample implementations for some Linux systems
> >    which already include non-generic support for this:
> > 
> >      * Atmel SOCs (AT91, AT32 -- the same GPIO module)
> >      * OMAP2/OMAP3 (not quite as simple)
> >
> > 		...
> > Comments?
> > 
> > Having this mechanism in genirq would let boards remove a bunch of
> > nonportable code, and would let drivers like gpio_keys, gpio_mouse,
> > and various touchscreens work more reliably.  It'd also let various
> > SOC-specific MMC and CF card drivers switch over to more standard
> > (and widely understandable) mechanisms.
> 
> Yeah this would nuke bunch of omap specific code for dealing with
> battery covers, MMC slot open etc..

It would be hidden away behind IRQF_DEBOUNCE ... not so much
making the code vanish, as making hardware-specific interfaces
vanish in favor of what seems to be the most popular idiom.

(Regular input GPIOs could be debounced too, but every time
I've noticed debouncing in use, it's coupled to an IRQ.)


> > I'd like to submit such updates for the 2.6.28 merge window, in
> > part to let mainline avoid needing yet another driver-specific
> > programming interface for IRQ debouncing.  (For TWL4030/TPS659x0,
> > as used in most OMAP3 boards including the Gumstix Overo and the
> > BeagleBoard.)
> 
> What's the plan for sysfs_notify event for these switches? Are you
> planning to add something like that to gpiolib?

I'm not sure what you mean -- which particular switches?
If the issue is the MMC card detect switches, that seems
more like an MMC question...

There was discussion of having the gpio_export() code
support notification that way, triggered by interrupts
on IRQ-capable GPIOs, but nobody seems to have wanted
it enough to translate from talk to code.  ;)

- Dave

 
> Tony
> 
> 
> > p.s. Tony and Kevin:  note the locking bugfix in the OMAP2/3 bit.
> 
> Here's my ack for that:
> 
> Acked-by: Tony Lindgren <tony@...mide.com>

For the whole patch, I'll presume, not just that locking fix.  ;)

> 
> > 
> > ---
> >  arch/arm/mach-at91/gpio.c    |   13 +++++++++++++
> >  arch/arm/plat-omap/gpio.c    |   15 ++++++++++++++-
> >  arch/avr32/mach-at32ap/pio.c |   14 ++++++++++++++
> >  include/linux/interrupt.h    |    2 ++
> >  include/linux/irq.h          |    3 +++
> >  kernel/irq/manage.c          |   27 +++++++++++++++++++++++++++
> >  6 files changed, 73 insertions(+), 1 deletion(-)
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/