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

Message-ID: <2022442.P80mCjSeu2@percival>
Date:	Wed, 28 Nov 2012 12:38:38 +0900
From:	Alex Courbot <acourbot@...dia.com>
To:	Grant Likely <grant.likely@...retlab.ca>
CC:	Linus Walleij <linus.walleij@...aro.org>,
	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 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?

Right now I have a very simple wrapper (for testing purposes) around the 
current integer-base GPIO namespace that accepts tables mapping consumers to 
GPIO numbers, much like Thierry did for the PWM subsystem. Integrating it into 
GPIOlib does not seem to be much more difficult ; it would require some 
refactoring though as most of the code should be shared by the two APIs.

This also seems to be the right opportunity (although not directly related) to 
switch the gpio_desc table into something more flexible. Two approaches come to 
mind: either a linked-list of gpio_chips ordered by base GPIO, or a radix-
tree. The small number of gpio chips in a system seem to make the first 
approach reasonable enough - GPIO lookup time would become linear instead of 
constant, but it should not be noticeable from the consumer perspective.

Alex.

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