linux-kernel - Re: How about a gpio_get(device *, char *) function?

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] [day] [month] [year] [list]

Message-Id: <20121203141528.436BF3E0A4C@localhost>
Date:	Mon, 03 Dec 2012 14:15:28 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Alex Courbot <acourbot@...dia.com>,
	Stephen Warren <swarren@...dotorg.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: How about a gpio_get(device *, char *) function?

On Sat, 1 Dec 2012 19:41:39 +0100, Linus Walleij <linus.walleij@...aro.org> wrote:
> On Thu, Nov 29, 2012 at 6:34 PM, Grant Likely <grant.likely@...retlab.ca> wrote:
> > On Wed, 28 Nov 2012 12:38:38 +0900, Alex Courbot <acourbot@...dia.com> wrote:
> >> On Monday 26 November 2012 19:14:31 Grant Likely wrote:
> >> > I don't have any problem with a gpio_get function, but I do agree that
> >> > making it return an opaque handle is how it should be written with a new
> >> > set of accessors. The handle should probably be simply the pointer to
> >> > the &gpio_desc[number] which is a private table in gpiolib.c. The
> >> > definition of it isn't available outside of gpiolib.c
> >>
> >> That looks like a reasonable approach, but this would make the new API
> >> available only to systems that use GPIOlib. Shouldn't we be concerned about
> >> making this available to all GPIO implementations? Or is GPIOlib so widely
> >> used that we don't care?
> >
> > I'm tempted to say non-gpiolib is not supported. However, there isn't
> > anything that would prevent non-gpiolib users from implementing the api
> > themselves, but they'd need to provide their own handle..
> 
> I get the creeps when you say that ...

hahaha.  Well, what else do we do? By definiton the custom
implementations are custom. We've got no way to support them unless we
cast the gpio number to the gpio handle in that case. That would work
but it would be mighty ugly.

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/