linux-kernel - Re: Pinmux bindings proposal V2

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:	Fri, 3 Feb 2012 09:32:05 -0800
From:	Tony Lindgren <tony@...mide.com>
To:	Dong Aisheng <dongas86@...il.com>
Cc:	Stephen Warren <swarren@...dia.com>,
	Shawn Guo <shawn.guo@...aro.org>,
	Dong Aisheng-B29396 <B29396@...escale.com>,
	"Linus Walleij (linus.walleij@...aro.org)" <linus.walleij@...aro.org>,
	"Sascha Hauer (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>,
	"Simon Glass (sjg@...omium.org)" <sjg@...omium.org>,
	Thomas Abraham <thomas.abraham@...aro.org>,
	"Grant Likely (grant.likely@...retlab.ca)" 
	<grant.likely@...retlab.ca>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: Pinmux bindings proposal V2

* Dong Aisheng <dongas86@...il.com> [120202 11:36]:
> 
> Actually i think i'd rather do not use config property, then i could
> be more compact:
> (anyway it's another issue and is flexible to be controlled by #pinmux-cells)
> pinctrl_usdhc4: pinconfig-usdhc4 {
>         /* 0: pin 1: group */
>         mux-entity = <0>;
>         func-name = "usdhc4func";
>         grp-name = "usdhc4grp";

The func-name and grp-name should be optional here.
This mux entry is already the group, and can be used as
the group name. And the function name can be generated
dynamically in most cases. I'm currently using np->full_name
of the driver claiming these pins as the function name.

>         mux =
>                 <MX6Q_SD4_CMD  0 MX6Q_USDHC_PAD_CTRL>
>                 <MX6Q_SD4_CLK  0 MX6Q_USDHC_PAD_CTRL>
>                 <MX6Q_SD4_DAT0 1 MX6Q_USDHC_PAD_CTRL>
>                 <MX6Q_SD4_DAT1 1 MX6Q_USDHC_PAD_CTRL>
>                 <MX6Q_SD4_DAT2 1 MX6Q_USDHC_PAD_CTRL>
>                 <MX6Q_SD4_DAT3 1 MX6Q_USDHC_PAD_CTRL>
>                 <MX6Q_SD4_DAT4 1 MX6Q_USDHC_PAD_CTRL>
>                 <MX6Q_SD4_DAT5 1 MX6Q_USDHC_PAD_CTRL>
>                 <MX6Q_SD4_DAT6 1 MX6Q_USDHC_PAD_CTRL>
>                 <MX6Q_SD4_DAT7 1 MX6Q_USDHC_PAD_CTRL>;
> };

For listing basic pins this format works fine for me. It seems
to have low overhead for parsing. And the width of the array
can be driver specific.

Looks like it's the binding for altenative states that's still a
bit open..

So how about let's first standardize on the mux format above?

Then we can enhance it later for describing alternative states?
 
Regards,

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