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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 3 Feb 2012 22:02:41 +0800
From:	Shawn Guo <shawn.guo@...aro.org>
To:	Dong Aisheng <dongas86@...il.com>
Cc:	Stephen Warren <swarren@...dia.com>,
	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>,
	Tony Lindgren <tony@...mide.com>,
	"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

On Fri, Feb 03, 2012 at 04:07:23AM +0800, Dong Aisheng wrote:
...
> However If IMX uses the data model i described above, the binding is
> then a little different from tegra. that means we may need to change
> to  let each soc's pinctrl driver do real pinmux map parsing (maybe
> add a callback in pinctrl.ops) based on their soc specific pinctrl
> configuration node like pmx_usdhc4 above instread of let pinctrl core
> do a standard pinmux map parsing which is our target we discussed so
> long for.
> 
Yeah, this seems a reasonable alternative to me.  Pushing the pinmux_map
construction down to individual pinctrl driver, who can interpret 'mux'
property best, will relieve the pinctrl core from understanding the
property for different cases, so that we can even save the property
'mux-unit' I asked for.  And doing so somehow aligns with non-dt case,
where the pinmux_map is constructed by individual pinctrl driver too
(with help from PINMUX_MAP_* macros in board file).

-- 
Regards,
Shawn
--
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/