linux-kernel - RE: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings

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: <74CDBE0F657A3D45AFBB94109FB122FF17801D2304@HQMAIL01.nvidia.com>
Date:	Tue, 17 Jan 2012 11:44:11 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Dong Aisheng <dongas86@...il.com>
CC:	Dong Aisheng-B29396 <B29396@...escale.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linus.walleij@...ricsson.com" <linus.walleij@...ricsson.com>,
	"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>,
	"cjb@...top.org" <cjb@...top.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"Simon Glass (sjg@...omium.org)" <sjg@...omium.org>,
	"Shawn Guo (shawn.guo@...aro.org)" <shawn.guo@...aro.org>
Subject: RE: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux
 mappings

Dong Aisheng wrote at Saturday, January 14, 2012 10:58 AM:
> On Sat, Jan 14, 2012 at 2:33 AM, Stephen Warren <swarren@...dia.com> wrote:
> > Dong Aisheng wrote at Friday, January 13, 2012 10:12 AM:
> >> On Thu, Jan 12, 2012 at 4:17 AM, Stephen Warren <swarren@...dia.com> wrote:
> >> ...
> >> >> To keep consistency as the currently design of pinctrl subsystem and also meet
> >> >> the dt design philosophy, we still do not introduce a pinmux map in dt.
> >> >> Instead, we choose to scan all the device node with a 'pinmux' phandle to construct
> >> >> a pinmux map table before register the pin controller device(here we may also scan
> >> >> the hog_on_boot node) and I guess it's easy to do that.
> >> > ...
> >> >> (Without scan the device node to construct the pinmux map table, we can only get the map
> >> >> Information when we run the pinmux_get.
> >> >> See: https://lkml.org/lkml/2012/1/5/153
> >> >> So no pinmux map table exists and we surely do not want to see that the sysfs exporting
> >> >> pinmux map information works in dt but unwork in non-dt)
...
> >> And i'm not sure it's the right place for of_platform.c to handle
> >> pinmux things when create new devices.
> >
> > So of_device_alloc(), which is called by of_platform_populate() for each
> > device, already parses basic DT content such as reg and interrupts, and
> > converts them to Linux resources. I'd consider parsing any pinmux properties
> > and registering them with the pinctrl subsystem to be of a similar nature,
> > so adding some code to of_device_alloc() that calls a core pinmux function
> > to parse the DT node seems reasonable to me.
> >
> It's not perfect to me since pinmux map looks not the pure hw
> conception like reg/int.
> but i wonder if we can find a better way, (scanning?)

I suppose up-front scanning might work. To be fully safe, I think you'd
need to:

Enumerate all nodes with a compatible property (for anything without,
it won't be a device node, so who knows what it is).

In those nodes, look for pinctrl and pinctrl-names properties. If they're
present, process them.

For each phandle, make sure the referenced "pin configuration node" has
a specific pinctrl compatible flag (just to make sure it really is pin
control data, not some random other thing that happens to be pointed at
by a property named pinctrl from some random binding developed by some
3rd-party without review.)

I propose for this:

    compatible = "pinctrl-configuration";

Now, you know the device node and the pin configuration, so you can create
the pinctrl mapping table entries.

-- 
nvpublic

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