[PATCH v4] powerpc/mpc85xx: Update the clock device tree nodes

[Scott Wood]

On Thu, 2013-09-12 at 21:50 -0500, Tang Yuantian-B29983 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: 2013年9月12日 星期四 22:44
> > To: Tang Yuantian-B29983
> > Cc: Wood Scott-B07421; galak at kernel.crashing.org; linuxppc-
> > dev at lists.ozlabs.org; devicetree at vger.kernel.org; Li Yang-Leo-R58472
> > Subject: Re: [PATCH v4] powerpc/mpc85xx: Update the clock device tree
> > nodes
> > 
> > On Wed, 2013-09-11 at 20:31 -0500, Tang Yuantian-B29983 wrote:
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: 2013年9月12日 星期四 9:10
> > > > To: Tang Yuantian-B29983
> > > > Cc: galak at kernel.crashing.org; linuxppc-dev at lists.ozlabs.org;
> > > > devicetree at vger.kernel.org; Li Yang-Leo-R58472
> > > > Subject: Re: [PATCH v4] powerpc/mpc85xx: Update the clock device
> > > > tree nodes
> > > >
> > > > This description of "reg" is overly specific (assumes how the parent
> > > > node's ranges are set up), incomplete (there's a size as well as the
> > > > offset), and does not apply to the clockgen node itself (you
> > > > probably shouldn't lump them together like this).
> > > >
> > > Do you mean I should explain the REG of clockgen and its child node
> > respectively?
> > >
> > > > > +- clocks : shall be the input parent clock phandle for the clock.
> > > >
> > > > Not required on the clockgen node
> > > >
> > > Required by child node of clockgen.
> > 
> > My point is that you're lumping several different types of nodes together
> > with one binding, when some parts of the binding are not applicable to
> > the clockgen node.
> > 
> Not several, just two types of nodes.
> One is clockgen node, the other is PLL and mux nodes.

clockgen + PLL + mux = 3 = several :-)

> The reason they lumped together is that the clockgen node is not only IP block
> Node but also a clock provider node

I don't understand why that merits lumping them together.

Just describe them separately.

> At first, I want to add a extra fixed-clock node and move the clock-frequency of clockgen 
> Node to it, but it is against the backward compatibility

Right.

> which I think it is not a big deal, Because nobody hasn't used it yet.

The point is it will require updating U-Boot to use it, versus existing
U-Boots which already patch up the clock-frequency in the clockgen node.
And there's nothing semantically wrong with the way it currently is.

> If I add a extra node with the clock-frequency property and don't move the
> clock-frequency property of clockgen, that would be redundant because both clockgen node
> and the extra node have the same clock-frequency node.
> So, I choose what I did now.

I'm not complaining about how you structured the nodes, just how you
documented them.

-Scott