Re: removing get_immrbase()??

[Anton Vorontsov <avorontsov@ru.mvista.com>]

On Thu, Apr 23, 2009 at 09:02:49AM -0500, Timur Tabi wrote:
> Anton Vorontsov wrote:
> 
> > And note that most developers are using up-to-date firmwares
> > (U-Boots), device trees, and kernels. 
> 
> Developers? Yes.
> End-users? No.

If end-users upgraded the kernel on some FSL board, then there
should be no technical problem upgrading device tree too.

> Updating U-Boot itself is often unacceptable for end-users.  There's
> also a strong connection between U-Boot and the device tree.  That
> connection gets stronger with every release, as U-Boot makes more and
> more changes to the device tree before passing it to the kernel.  This
> means that if you cannot update U-Boot, you might not be able to update
> your device tree either.

As I said, this case is a separate matter. Just as device_type = "soc",
yes we should avoid removing it. But if we 100% sure that our device
tree changes won't break compatibility with officially supported
firmware, then IMO we should just go ahead with the changes.

> We've run into plenty of situations where customers will update the
> kernel, but insist that U-Boot

That I can understand.

> and the device tree remain unchanged.

That I can't. I wonder what was the rationale behind this.

> > And that means that old
> > device-tree + new kernel combination is left untested for years.
> > And untested stuff is broken stuff, by definition.
> 
> I'm not saying that should officially support it.  I'm saying we should
> make an effort to minimize the problem.

That doesn't work in practice. I bet if I'll try booting recent Linux
with FSL-provided device-tree on, say, MPC8323E-RDB it simply won't
boot.

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2