linux-kernel - Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins

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:	Tue, 30 Dec 2008 23:45:58 +0800
From:	"Jaya Kumar" <jayakumar.lkml@...il.com>
To:	"David Brownell" <david-b@...bell.net>
Cc:	"Eric Miao" <eric.y.miao@...il.com>,
	"Sam Ravnborg" <sam@...nborg.org>,
	"Eric Miao" <eric.miao@...vell.com>,
	"Haavard Skinnemoen" <hskinnemoen@...el.com>,
	"Philipp Zabel" <philipp.zabel@...il.com>,
	"Russell King" <rmk@....linux.org.uk>,
	"Ben Gardner" <bgardner@...tec.com>, "Greg KH" <greg@...ah.com>,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-fbdev-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org
Subject: Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins

Hi David,

On Mon, Dec 29, 2008 at 2:32 PM, David Brownell <david-b@...bell.net> wrote:
>
>  - passing bitmasks as {unsigned long *bits, int count} tuples
>  - separate calls to:
>     * zero a set of bits (loop: gpio_set_value to 0)
>     * fill a set of bits (loop: gpio_set_value to 1)
>     * copy a set of bits (loop: gpio_set_value to src[i])
>     * read a set of bits (loop: dst[i] = gpio_get_value)
>     * ... maybe more

I had read bitmasks.h as per your recommendation and my thought on
that was: How do I reconcile such a substantial API when the use case
is just setting/getting a bunch of gpio pins?

>
> Any restriction to 32 bit value seems shortsighted.  It would
> make sense to wrap the GPIO bitmask descriptions in a struct,
> letting drivers work with smaller sets -- probably most would
> fit into a single "unsigned long".
>

Hmm. Well. Currently, there's only been 1 bit support and its been
that way for years, hasn't it? It was not shortsighted at that time to
have only 1 bit access. No one raised a need for more. There weren't
any complaints about the 1-bit gpio API until am300epd.c came along.

You had correctly pointed out "I happen not to have come across the
need for such ganged access from Linux" in the start of this thread. I
think that you raised a strong point there. If I understood you
correctly, it implies it is NOT likely that there'll be many users of
this ganged access API.

Which is precisely why I took your suggestion to heart and stuck to
the middle path. For better or worse, we currently have a grand total
of just one use case for this ganged API: am300epd.c which does a
16-bit write. No one has spoken up with another concrete use case. So
I say we stick to the simple 32-bit startpin/mask/length API. Lets see
if people start using it. If more than a few do and issues are raised
with it being limited to "just 32 bits", then we can rearchitecht as
needed. After all, as you requested, it's an optional in-kernel only
API so we're in no danger of shooting ourselves in the foot here.
Further more, we've gone from years of 1-bit access with no complaints
to 32-bit access. A factor of 32 improvement seems a reasonably good
bet for the next few years to me. :-)

If any of my assertions are mistaken, I'll need your help to
understand which specific part of the conversation I've misunderstood.

Thanks,
jaya
--
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/