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: <74CDBE0F657A3D45AFBB94109FB122FF17801D1FAB@HQMAIL01.nvidia.com>
Date:	Fri, 13 Jan 2012 10:33:21 -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>
Subject: RE: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux
 mappings

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)
> >
> > Hmmm. I'm not sure that the pinctrl code should actively scan all nodes
> > in the device tree for pin mux properties. That seems a little invasive;
> > how does pinctrl know which nodes it really should be looking at, and
> > which nodes are random internal parts of some device's custom binding?
> >
> > Personally, I think I'd be OK with the sysfs pinctrl map file only
> > containing the map entries for devices that had used the pinctrl API,
> > and hence only parsing the pinmux properties in pinmux_get().
> >
> > However, we could perhaps do better by registering a bus notifier, and
> > pro-actively parsing the top-level DT node (if there is one) for every
> > device that is created. That way, the mapping would be parsed as soon
> > as the device was created (or perhaps after probe?).
>
> After refer to usb bus notifier, usb core will register a bus notifier.
> When a new usb bus is registered, it will notify the usb core for a
> new bus added.
> 
> So i guess you mean pinctrl core provides a notifier to handle the map
> creation when new map is found during parsing each device node, right?

Yes.

> But it seems parsing of device node and creation of device is at the very early
> stage when call of_platform_populate in .init_machine code and pinctrl subsystem
> may still have not change to run to register a bus notifier.

That's possible. There are some early initcalls that might work out
fine for this, but...

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

> I wonder it may not work for pinmux map case.
> If pinctrl core does not provide notifier, who else can be the right
> one to privide it?
> 
> > The only case this
> > might not cover is DT nodes for which the kernel doesn't actually have
> > a driver, and hence no device is created.
>
> Per my understanding, the device creation should be independent on the driver.
> I don't know why no device is created if not have a driver.
> Did i miss something?

Yes, I think the device gets created irrespective, so this isn't actually a problem

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