linux-kernel - Re: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib

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]

Message-ID: <CACRpkdbEgBqSdZmebw+PBMo9G_Y24mgz17=dp11VrbKf5fKyDQ@mail.gmail.com>
Date:	Fri, 28 Sep 2012 13:34:18 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Roland Stigge <stigge@...com.de>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	w.sang@...gutronix.de, jbe@...gutronix.de,
	Bill Gatliff <bgat@...lgatliff.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>
Subject: Re: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib

On Fri, Sep 28, 2012 at 11:52 AM, Roland Stigge <stigge@...com.de> wrote:

> It's hard to do the one-value-per-file right for a several-gpios-at-once
> goal. :-)

That's true. This is one of the reasons I think GPIO chips should
be /dev/gpioN device nodes and this business be handled by
ioctl():s instead, it is harder from an ABI point of view but can
do several things at once.

> I originally had a one-value solution: A bit map, continuously
> hex coded, like in the original kernel API idea (e.g. 0x000F0A0010).
> Wasn't sure because it encodes GPIO numbers in a weird way.

Yeah, well that is not so nice either.

> Strictly formally: Isn't a comma-separated list of a GPIO block (e.g.
> "80,81,85") a singe value in a sense? :-)

I think it's called an array ...

> Or other possibilities? Maybe
> some node in /proc?

Heaven's no.

> Or some kind of new character device node?

Yes, I don't know if we should create /dev/gpioN or /dev/pinctrlN for
this, and add GPIO functions to pinctrl (while wrapping it in the
gpiolib to aid migration) the latter would encourage users of the
new ABI to switch to writing pinctrl drivers.

> Otherwise, I need to think about leaving out the sysfs for this purpose.

Do you really need it?

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/