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:

quoted

On Mon, Feb 24, 2014 at 11:25 +0100, Gerhard Sittig wrote:

quoted

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 <redacted>

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 at denx.de