[PATCH 2/3] Introduce new CPM device bindings.

[Scott Wood]

On Wed, Aug 29, 2007 at 03:39:41PM +1000, David Gibson wrote:
> On Tue, Aug 28, 2007 at 03:16:19PM -0500, Scott Wood wrote:
> > Boards that do not require the legacy bindings should select
> > CONFIG_PPC_CPM_NEW_BINDING to enable the of_platform CPM devices. Once
> > all existing boards are converted and tested, the config option can
> > become default y to prevent new boards from using the old model.  Once
> > arch/ppc is gone, the config option can be removed altogether.
> 
> I think it would be better to change the name and reverse the sense of
> this config option, since what it actually does is disable the old
> binding, not enable the new one.

But then boards would have to deselect rather than select the option...
can kconfig do that?

> Your example has bus-frequency, but lacks fsl,brg-frequency, in
> contrast to the description above.

Oops...

> Since you have a separate brg node defined below, maybe
> fsl,brg-frequency should just be replaced with a 'clock-frequency'
> property in that subnode.

Sounds good.

> > +   ii) Properties common to mulitple CPM/QE devices
> > +
> > +   - fsl,cpm-command : This value is ORed with the opcode and command flag
> > +                       to specify the device on which a CPM command operates.
> > +
> > +   - fsl,cpm-brg : Indicates which baud rate generator the device
> > +                   is associated with.  If absent, an unused BRG
> > +                   should be dynamically allocated.
> 
> Maybe a property with the brg node's phandle could be included as
> well, to avoid having to hop up to the CPM node, then back down to the
> brg-compatible node to find it?

Enh... it doesn't convey any new information, and in practice, it's done
by common CPM code that doesn't know about the individual device's node
anyway.

> Or maybe even have a separate subnode for each brg, and just have a
> phandle to reference it from the other devices, rather than using this
> index.

Seems a little complex relative to the gain.

> > +   Example:
> > +
> > +	ethernet at 11300 {
> > +		device_type = "network";
> > +		compatible = "fsl,mpc8272-fcc-enet",
> > +		             "fsl,cpm2-fcc-enet";
> > +		reg = <11300 20 8400 100 11390 1>;
> > +		local-mac-address = [ 00 00 00 00 00 00 ];
> > +		interrupts = <20 8>;
> > +		interrupt-parent = <&PIC>;
> > +		phy-handle = <&PHY0>;
> > +		linux,network-index = <0>;
> > +		fsl,cpm-command = <12000300>;
> > +	};
> 
> Should this also have a phandle pointer to the mdio node?

It has a phandle to the phy node...  if you mean the mdio bus node, why?

-Scott