Re: [RFC] mpc5200 device tree bindings refinement

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> I am concerned that this ends up been premature optimization (of the
> device tree).  Hardware designers are fickle people and like to change
> shared registers between different chips.  I do agree that logically
> the device is attached to a block of registers that can be described
> in a separate node (child of the soc node).  But since we have no idea
> if it's going to change in the next chip, it's probably better just to
> describe it as the block-index on the soc.
> 
> Of course, I this begs the argument: "why do we describe anything
> about an soc at all; why not just specify the SoC name/revision and be
> done with it?"  I don't like that direction myself, but I do find it
> non-trivial to find the sweet spot between minimal and "fully-loaded"
> device trees.  That just highlights to me that this is just as much of
> an art as it is science.  :)

Yeah. Let's keep it simple. For example, with EMAC, well, when you look
at all the 4xx specs around, they all talk about EMAC 0, EMAC 1, ... and
the registers that might have bits for all emacs around (like clock
control) do the same.

Thus it makes sense to use a property like cell-index or block-index to
identify which EMAC within an ASIC a given node refers to. I don't think
it's justified to have a complex mecanism to describe those registers
individual bits however.

It's a matter of taste/common sense when faced with a given situation,
pick up the simplest thing that is a good enough solution for the
problem and will reasonably not rot as soon as the next chip is
released. On the other hand, don't try to solve problems you don't have
and fall into an over-engineering pitfall :-)

Ben.