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.
- k _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
