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]

Date:	Sun, 15 Jan 2012 01:58:03 +0800
From:	Dong Aisheng <dongas86@...il.com>
To:	Stephen Warren <swarren@...dia.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

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)
>> >
>> > 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,
Ok, looks .init_machine is the level of ARCH_INIT, will try a earlier one.
and we may add that init function in pinctrl core if it's reasonable.

> but...
but what?

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