| 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
| ||
|
Date: Thu, 5 Jan 2012 21:14:13 +0800
From: Dong Aisheng <dongas86@...il.com>
To: Shawn Guo <shawn.guo@...escale.com>
Cc: Dong Aisheng-B29396 <B29396@...escale.com>,
Stephen Warren <swarren@...dia.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>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
"cjb@...top.org" <cjb@...top.org>,
"devicetree-discuss@...ts.ozlabs.org"
<devicetree-discuss@...ts.ozlabs.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings
On Thu, Dec 29, 2011 at 10:46 AM, Shawn Guo <shawn.guo@...escale.com> wrote:
> On Tue, Dec 27, 2011 at 02:41:25PM +0000, Dong Aisheng-B29396 wrote:
> [...]
>> > You could have nested sub-nodes, say something like:
>> >
>> > iomuxc@...e0000 {
>> > compatible = "fsl,imx6q-iomuxc";
>> > reg = <0x020e0000 0x4000>;
>> > fsl,pins {
>> > ... // fsl-specific pin properties
>> > };
>> > fsl,groups {
>> > ... // fsl-specific group properties
>> > };
>> > fsl,functions {
>> > ... // fsl-specific mux function properties
>> > };
>> > pinmux-usage {
>> > // standardized pinmux "table" properties
>> > sd4 { // pin group name
>> > function = "sdio4"; // this function active on it
>> > ...
>> > };
>> > ...
>> > }
>> > ...
>> > }
>> >
>> Yes, I could do that.
>> The extra effort is that we have to manually exclude one pinmux-usage
>> node in pinmux driver since originally i take the child node count of
>> iomuxc as the function count since all child nodes are functions,
>> that why I firstly took the mapping node out of iomuxc, in addition
>> the old way i used seems to be more brief and clear.
>>
> Stephen suggested you put all the function nodes under node
> 'fsl,functions' (not sure prefix fsl is necessary). In that case,
> of_get_child_count() on 'fsl,functions' still get you the function
> count you want, right?
>
> But we do not bother with it, if we do not have pinmux-usage at all.
> See below ...
>
>> I tried adding pinmux-usage as a sub node of iomuxc and got two issues:
>> Taking imx6q as an example:
>> iomuxc@...e0000 {
>> uart4 {
>> func-name = "uart4";
>> grp-name = "uart4grp";
>> grp-pins = <107 108>;
>> num-pins = <2>;
>> grp-mux = <4 4>;
>> num-mux = <2>;
>> };
>>
>> sd4 {
>> func-name = "sd4";
>> grp-name = "sd4grp";
>> grp-pins = <170 171 180 181 182 183 184 185 186 187>;
>> num-pins = <10>;
>> grp-mux = <0 0 1 1 1 1 1 1 1 1>;
>> num-mux = <10>;
>> };
>>
>> pinmux-mapping {
>> uart4 {
>> function = "uart4";
>> dev = <&uart4>;
>> };
>>
>> usdhc4 {
>> /* ctrl-dev-name = "20e0000.iomuxc"; */
>> function = "sd4";
>> dev = <&usdhc4>;
>> };
>> };
>> };
>>
>> If we remove ctrl-dev-name and get it from its parent node in drivers as
>> you suggested,
>> first, since this work will be done in the common API (pinmux_of_register_mappings
>> Requires pass the pinmux mapping node to it for construct the mapping table)
>> It will introduce a restriction that all platforms should define this node
>> under their pinctrl device node.
>> Second, it seems we cannot get its parent node device or device name in driver
>> (can only get node Name which is not sufficient for construct the pin map table
>> required by pinctrl core) and current device tree subsystem seems do not support
>> get its associated device from a device node.
>> We may not be able to construct ctrl-dev-name or ctrl-dev for struct pinmux_map.
>> I'm not sure if I missed something, if missed please let me know.
>> To support it, we may need to add support for converting device node
>> to device. Not sure it's applicable since I still have not tried it.
>>
>> The same issue applies to dev using a phandle.
>>
> We do not bother with it, if we do not have pinmux-usage at all.
> See below ...
>
> [...]
>
>> I was ever thought putting a phandle of pinmux function in each device,
>> Then pinmux mapping table seems not need anymore. Like:
>>
>> usdhc4: usdhc@...9c000 { /* uSDHC4 */
>> compatible = "fsl,imx6q-usdhc";
>> ....
>> pinmux = <&pinmux-sd4>;
>> };
>>
>> iomuxc@...e0000 {
>> pinmux-sd4 : sd4 {
>> func-name = "sd4";
>> grp-name = "sd4grp";
>> grp-pins = <170 171 180 181 182 183 184 185 186 187>;
>> num-pins = <10>;
>> grp-mux = <0 0 1 1 1 1 1 1 1 1>;
>> num-mux = <10>;
>> };
>>
>> It is a pure hw point of view to define node.
>
> That's the way we should go for. This is exactly the same thing that
> clk and regulator DT support is doing. And right, in that way, we do
> not need pinmux mapping for DT at all.
>
I tried this way and basically it works but has a few limitations due to
via dt.
I will send out patch in this thread for discussion.
>> And it may need to implement a of_pinmux_get.
>
> To make the pinmux api generic for both dt and non-dt users, the pinmux
> client driver should still see/call pinmux_get, something like
> of_pinmux_get should be sorted out behind pinmux_get.
>
>> But what about the pin maps without device associated?
>>
> Do we have such cases?
>
It's hog_on_boot function.
Regards
Dong Aisheng
--
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/
Powered by blists - more mailing lists