Re: [PATCH 10/11] Add MPC8360EMDS board support

[Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>]

Dan Malek wrote:
> On Oct 4, 2006, at 1:52 AM, Benjamin Herrenschmidt wrote:
> 
>> I don't see how a mecanism of feature call at the board support  
>> level is
>> in any way incompatible with the device-tree thing.
> 
> It isn't.
> 
>> ...  I'm happy mixing
>> both on powermac :)
> 
> I know.  This was just an opportunity to make people
> realize that a board port does require the writing of
> some board specific code.  Using the feature call is
> an excellent model of portability and flexibility.  My
> point was that any BCSR access is necessary to be
> hidden behind such a function, because it is truly
> board specific.  You can't require the drivers to
> have this kind of logic in them, they must call out
> to board support functions for assistance.
> 
> Just like the powermac ports, embedded drivers
> will need a feature call at some points during
> their processing (set up clock routing, IO pin
> configuration, board specific bus connections,
> power management, etc).  Some board ports
> may do nothing, others may do lots of work.
> 
> Therefore, I see no reason why a BSCR address
> and all of it's associated format can't simply
> be a #define in a board specific file.  There is no
> need for this in the device tree.
> 
> 
> 	-- Dan

The promise of OF for me is that it promises to keep configuration 
information in _one place_.  My experience to date is that my u-boot has 
a bunch of semi-hardcoded constants, my linux drivers have a bunch of 
semi-hardcoded constants that likely do not match 1:1 (name and 
definitely not location) with the equivalent u-boot constants, and some 
constants are passed from u-boot to linux using the BD structure, which 
is never defined the same (for me) in u-boot and linux.

The result is that, when I upgrade my u-boot and/or linux sources, I end 
up having to re-find all the places where the constants live (and find 
some new places), fix them, and then make the u-boot and linux BD 
structures match.  Granted, this isn't insurmountable, but it is a major 
hassle and should be unnecessary.

In a perfect world perhaps we would have one (set of) #include file(s) 
that had all the configuration information necessary to build u-boot and 
linux.  In the current world, u-boot and linux are in different 
repositories with different people with different machines (and agendas) 
doing different development on them, and the result is disjoint.

I look at OF to be the /lingua franca/ of PowerPC bootloaders and linux.

gvb