[PATCH 10/11] Add MPC8360EMDS board support

[Dan Malek]

On Sep 27, 2006, at 8:55 AM, Vitaly Bordug wrote:

> hence let's open a discussion what others think about that. The  
> problem seems common (and for some boards
> is called somewhat else apparently), but at this point we should  
> come to some conclusion, document it, and use it.

Well, I haven't voiced my opinion lately..........  :-)

I think this is totally out of control.  I don't even know what
we are trying to create here any more.  We took a reasonable
idea to express some configuration flexibility and are running
off into into some world that we think we need to create
something infinitely flexible that anyone can use for anything
they wish.  I could expect this from a university research
project, but not from seasoned developers that are trying
to create products where only a few real configuration
combinations make sense.

Since BCSRs are board specific, does anyone remember
the day when a simple #define, ioremap, and a few lines
of code in the board setup file was all that was needed? :-)
What wrong with still doing that?  It seems everyone is
obsessed with device tree syntax and forget that a
few lines of code may still be a reasonable solution.

I still think an embedded_feature_call() support in a
board port would be the best solution to many of these
complex things we are trying to define in this device
tree information.  In the places where we need some
kind of board specific support, like hardware set up for
some peripheral, just do the feature_call, passing enough
information to indicate what is needed, and let the
board support do what is necessary.  This could be
setting bits in a BCSR, setting up the processor IO
ports, enabling power to external logic, etc.  This has
been proven to work well on the PMAC, just extend it
to be used on embedded boards.

Thanks.

	-- Dan