[PATCH 10/11] Add MPC8360EMDS board support

[Eugene Surovegin]

On Thu, Oct 05, 2006 at 10:27:14AM +1000, Paul Mackerras wrote:
> Dan Malek writes:
> 
> > I'm not against using the device tree (or platform data
> > or #defines) when it's appropriate to do so.  I think our
> > obsession to represent everything there is what is
> > creating the complexity.  If a #define in a board
> > specific port file makes sense, then just do that,
> > even if it is a BSCR address.
> 
> So, where this discussion started was that I saw an ioremap in an
> ethernet driver using a physical address defined with #define, and I
> said "that should go in the device tree".  And I would still say that
> if the ioremap was still there, since the driver is one that is useful
> across a range of boards and chips.
> 
> My other point would be that what you say is valid *until* the
> hardware engineers come to you and say "we're doing rev 2 of the
> board, and we had to move the BCSR a bit.  That's OK with you, isn't
> it?".
> 
> If you have the BCSR address in the device tree, you don't even need
> to recompile your kernel.  You can just copy your board.dts to
> board-rev2.dts, change the address in there, and rerun the wrapper
> script to create the flash image to put on the new board.  Or if you
> are using a bootloader that knows how to supply a device-tree blob,
> you just put board-rev2.dtb into flash along with your existing kernel
> image.

Paul,

it doesn't really matter if you have to rebuild a kernel or some 
other blob and have it re-flashed in the actual board.

Having something in device tree doesn't change a simple fact that you 
have to update some firmware component, be it boot code, kernel or 
some dts blob. You still have to prepare new flash image, period.

-- 
Eugene