On Wed, Mar 05, 2014 at 09:48 +0800, Shawn Guo wrote: > > On Mon, Mar 03, 2014 at 10:22:31AM +0100, Gerhard Sittig wrote: > > On Mon, Feb 24, 2014 at 11:25 +0100, Gerhard Sittig wrote: > > > > > > a recent FEC binding document update that was motivated by i.MX > > > development revealed that ARM and PowerPC implementations in Linux > > > did not agree on the clock names to use for the FEC nodes > > > > > > change clock names from "per" to "ipg" in the FEC nodes of the > > > mpc5121.dtsi include file such that the .dts specs comply with > > > the common FEC binding > > > > > > this "incompatible" change does not break operation, because > > > - COMMON_CLK support for MPC5121/23/25 and adjusted .dts files > > > were only introduced in Linux v3.14-rc1, no mainline release > > > provided these specs before > > > - if this change won't make it for v3.14, the MPC512x CCF support > > > provides full backwards compability, and keeps operating with > > > device trees which lack clock specs or don't match in the names > > > > > > Signed-off-by: Gerhard Sittig <gsi@xxxxxxx> > > > > ping > > > > Are there opinions about making PowerPC users of FEC use the same > > clock names as ARM users do, to re-use (actually: keep sharing) > > the FEC binding? The alternative would be to fragment the FEC > > binding into several bindings for ARM and PowerPC, which I feel > > would be undesirable, and is not necessary. > > As I already said, Documentation/devicetree/bindings/net/fsl-fec.txt > was created specifically for i.MX FEC controller from day one. And even > as of today, it doesn't serve PowerPC, because for example the property > 'phy-mode' documented as required one is not required by PowerPC FEC. > My opinion would be to patch fsl-fec.txt a little bit to make it clear > that it's a binding doc for i.MX FEC, and create the other one for > PowerPC FEC. This is the way less confusing to people and easier for > binding maintenance. Should we still try to have a common behaviour where possible? Such that even if there are two bindings, they don't diverge in "unnecessary" ways? But given that we already are past -rc5, I guess the suggested change is too late for v3.14 anyway. So we have to live with the fact of a mainline release of different behaviour. And the backwards compatibility support in the MPC512x CCF implementation allows to cope with a potential future "ipg" unification while still working with former "per" using device trees. There's no blocker. So nevermind. virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@xxxxxxx -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
