Re: [PATCH 2/3] dts: mpc512x: adjust clock specs for FEC nodes

[Gerhard Sittig <gsi-ynQEQJNshbs@public.gmane.org>]

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-ynQEQJNshbs@public.gmane.org>
> > 
> > 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-ynQEQJNshbs@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html