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

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

Message-ID: <CACRpkdao8ZzyhvUMBSxFDJJiut9myxfPPEamnaP4cU6mWTTYVQ@mail.gmail.com>
Date:	Mon, 10 Dec 2012 11:11:44 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Guenter Roeck <groeck-dsl@...global.net>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	anish kumar <anish198519851985@...il.com>,
	Guenter Roeck <linux@...ck-us.net>,
	linux-kernel@...r.kernel.org,
	Grant Likely <grant.likely@...retlab.ca>,
	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 6:07 PM, Guenter Roeck <groeck-dsl@...global.net> wrote:

> 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 would like you to seriously consider both gpio-input and the new
drivers/extcon/extcon-gpio.c driver (maybe adding debounce into that
driver). The latter also has a sysfs interface.

Your usecases seem to be EXTCON_MECHANICAL. If not, new classes
can surely be added.

There is some risk that sysfs makes everything that is a GPIO line
appear as GPIO instead of what it really is, which is not helpful
for userspace which will have to keep track of all the routing of the
electronics.

The latter might be comfortable if you're designing and maintaining the
whole system with firmware and so on, but from a newcomer
examining the system in sysfs it's not helpful, and we're designing
that ABI for a purpose.

(And I share Grant's hesitant stance on extending the GPIO sysfs.)

Yours,
Linus Walleij
--
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/