linux-kernel - Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 9 Dec 2012 22:36:27 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Guenter Roeck <groeck-dsl@...global.net>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	anish kumar <anish198519851985@...il.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Guenter Roeck <linux@...ck-us.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [PATCH] gpio: export 'debounce' attribute if supported by the
 gpio chip

On Sun, Dec 9, 2012 at 5:07 PM, Guenter Roeck <groeck-dsl@...global.net> wrote:
> On Sun, Dec 09, 2012 at 11:03:19AM +0000, Alan Cox wrote:
>> On Sun, 09 Dec 2012 01:58:19 -0800
>> anish kumar <anish198519851985@...il.com> wrote:
>>
>> > On Fri, 2012-12-07 at 16:49 +0000, Alan Cox wrote:
>> > > > 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.
>> > >
>> > > Android tries to address this with its switch class driver, but I'm not
>> > > sure its actually got anything over making them input devices.
>> >
>> > Sorry for not understanding the context here.How the debounce sysfs
>> > added by Guenter has anything to do with switch driver in android?
>>
>> The other more general option is to make the input layer do the debounce
>> and make them all inputs rather than just relying on any gpio layer
>> support.
>>
> The gpio pins I am dealing with are provided by an FPGA which is used on various
> boards. While the gpio access registers are always the same, the actual usage is
> board specific. This means I either need to write ugly code, or use the gpio
> subsystem to provide access to the gpio pins. Ugly code is out of the question,
> which means I'll need gpio support.
>
> Anyway, I want to keep things simple, not add unnecessary complexity. Having to
> go through the input subsystem just to be able to support debounce on a couple
> of input pins doesn't really sound simple. Guess I'll have to find another
> solution if the patch is not accepted. Maybe I'll add a "debounce" property to
> the gpio driver's of properties.

I haven't looked deeply at the patch to give you an answer yet, but
I'd recommend you go with the DT property approach anyway. The gpio
sysfs interface is horribly designed and I'm not keen on adding new
features to it.

g.
--
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/