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]

Date:	Mon, 5 Nov 2012 16:31:23 +0900
From:	Alex Courbot <acourbot@...dia.com>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	"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?

Hi Linus, thanks for the reply!

On Monday 05 November 2012 02:04:33 Linus Walleij wrote:
> On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot <acourbot@...dia.com> wrote:
> > Would anyone be opposed to having a gpio_get() function that works
> > similarly to e.g. regulator_get() and clk_get()?
> 
> I understand the concept and why you want to do this.
> 
> However I think the global GPIO numberspace defeats the
> purpose.
> 
> gpio_get() should get an abstract handle just like clk_get() or
> regulator_get(), not a fixed numeral.
> 
> That is the only way to really transit away from the global GPIO
> numberspace.

Interesting. I see you already gave the whole thing a thought. What I don't 
understand however is what is so wrong with the current GPIO numberspace that 
you want to replace it? Whether we use simple integers or blind pointers, the 
adressable space will basically remain the same. GPIO numbers can actually be 
considered as handles, and actually I would not mind typedef'ing "int" to a 
GPIO handle type in order to add more opacity to the framework.

Also the current DT bindings will likely continue to require the legacy API 
anyway, so I am not sure we can make it go away.

My initial thought was to build something on top of the existing scheme to 
address my immediate needs - what you are talking about is much more scary. :) 
Could you elaborate on your motivations for such a radical direction? 

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