On Wed, Apr 22, 2009 at 11:41:31PM -0500, Kumar Gala wrote:
>
> On Apr 22, 2009, at 11:06 PM, David Gibson wrote:
>
>> Well, yes, I guess I agree. How immutable you consider the device
>> tree blob to be is a judgement call based on the specific details of
>> platform/board in question. If it is indeed a reference platform, in
>> the early stages of development where it's reasonably easy to change
>> the dtb, then it's probably best to change the dtb in sync with the
>> kernel to reduce long-term cruft build-up. But once the board is
>> sufficiently widely deployed, you want to stop doing that and include
>> backwards compatibility workarounds in the kernel to cope with the
>> widely deployed broken trees.
>
> I disagree with the point about providing workarounds to cope w/deployed
> device trees (at least for the problems I'm thinking off in which nodes
> didn't exist). This just sounds like double work and is a disincentive
> to actually making such changes.
>
> Lets say I had an error driver for our MCM (core to soc coherency
> module). It was getting the base address by using get_immrbase().
> Today I proposed a proper device node for the MCM block as it doesn't
> exist in .dts today. We add such a node into .dts and I can clean up my
> error driver to use proper device node information. However I've just
> broken any old .dts that didn't have this node. You are saying I need to
> add code into the kernel to create this new node and we have to keep that
> code around for ever in the kernel.. why would I ever bother to actually
> changing anything than.
Well, again. It's a judgement call, balancing the pain of having to
update the dts files (which depends on how widely deployed the
platform is) versus the pain of having to keep the bacwards
compatibility shim in the kernel.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
