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

* Stephen Warren <swarren@...dia.com> [120127 09:05]:
> Tony Lindgren wrote at Thursday, January 26, 2012 7:09 PM:
> ...
> > I don't think we should try to pass the different possible states from
> > device tree. The pinmux/pinconf driver should know how to deal with that,
> 
> Somehow, the pinctrl driver needs to know how to implement each state. In 
> general, I believe this will be board-specific.
> 
> Do you disagree with this assertion?
> 
> If the data is board-specific, I don't see how it can be represented
> anywhere but the device tree.

Agreed, for board specific things device tree is the place to put it.
 
> > and the driver using the mux should be able to communicate what it wants
> > to the pinmux/pinconf driver. If people really want to be able to pass
> > alternative mux states from device tree, they should be standard bindings
> > for things like active/idle/suspend/off.
> 
> As I've mentioned before, people have asked for driver-specific states to
> handle the case where e.g. drive strength must be adjusted based on clock
> rates of the interface. Again, I believe that's board-specific data since
> the actual values to use may be derived during board calibration, not
> SoC design.
> 
> Do you disagree that this data may be board specific?

Right, but for the dynamic mux cases I've seen the alternative states
are usually specific to the driver using the mux. That's why I'm
suspicious of the board specific custom alternative states :)

Anyways, do you think the pinctrl-static + pinctrl-dynamic binding
I just posted as a reply to Simon's email would work for you?

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/