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: <17133691.o4iLtizVux@percival>
Date:	Thu, 1 Nov 2012 11:48:13 +0900
From:	Alex Courbot <acourbot@...dia.com>
To:	Stephen Warren <swarren@...dotorg.org>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Linus Walleij <linus.walleij@...aro.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 Wednesday 31 October 2012 23:25:41 Stephen Warren wrote:
> On 10/31/2012 03:04 AM, Alex Courbot wrote:
> > Hi,
> > 
> > Would anyone be opposed to having a gpio_get() function that works
> > similarly to e.g. regulator_get() and clk_get()?
> 
> One major stumbling block is that with device tree, each individual
> binding gets to decide on the specific naming of the propert{y,ies} that
> define the GPIO(s) for the device, and so there's no way to provide a
> generic implementation of that function.

The idea is not to make every GPIOs declared so far accessible through this 
function - as you point out this would be tricky at best - but to also define 
how they should be properly declared (similarly to regulators and pals) for 
bindings that need to use get_gpio(). Existing bindings and drivers that can 
live without it should not be modified. And now that you mention it, the end of 
the GPIO declaration anarchy would be another point in favor of this feature.

Now I am aware that almost every subsystem comes with its own scheme for 
declaring resources in the DT and there will be an long fight to decide which 
one should apply here, but I'm willing to take that road.

> Related, I've always wished that DT nodes looked like:
> 
> device {
>     reg = <...>;
>     compatible = <...>;
>     resources {
>         pwms = <...>;
>         regulators = <...>;
>         clocks = <...>;
>         gpios = <...>;
>         other-devices = <...>; /* for custom API dependencies */
>     };
>     config {
>         /* device-specific properties */
>     };
>     child-busses {
>         0 = { ... };
>         1 = { ... };
>     };
> };
> 
> ... specifically so that all resource allocation, and perhaps even child
> bus enumeration, could be completely standardized in the DT/device core.
> This could also feed into deferred probe, which could then be purely
> implemented inside the DT/driver core. However, that'd require something
> incompatible like "device tree 2.0"

I think this would be awesome. This could even probably be implemented without 
breaking things, if everything takes place inside well-defined subnodes of the 
device.

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/