Request review of device tree documentation

[Benjamin Herrenschmidt]

On Sat, 2010-06-12 at 23:07 -0600, Grant Likely wrote:
> 
> What is needed to keep OFW alive?  I've got no problem with doing so
> if it isn't invasive, and as long as the same boot entry interface can
> be used.

Well, no. OF has a well defined "client interface" which is what gets us
in prom_init.c on powerpc when r5 is non NULL. You can use it to do
things like access devices or the device-tree.

We use that to suck the device-tree, which we flatten, and then re-enter
the kernel with the "common" entry interface.

If you want to keep OF alive, you -can- probably do that too, but it's
more tricky. You need to keep the memory where OF resides reserved, OF
might need special MMU translations, you maybe need to install hooks in
OF itself for it to be able to manipulate some of those, etc...

> What is the use-case for having a dynamic device tree?  I can see
> keeping OFW alive being useful for some debug facilities, but once the
> kernel has started, I'm really not interested in relying on firmware
> to manage the hardware.  (but then again it's no secret that I'm
> suspicious of anything that depends on runtime interaction with
> firmware).

As we all are :-)

I see one genuine use of dynamic device-tree though, which is in a
virtualized environment (where the host can be Linux itself). Hotplug
can then be a matter of getting new nodes & properties fed down to the
OS by the hypervisor/firmware.

pSeries somewhat works like that, but using weirdo rtas calls. We could
do something saner for kvm or whatever other hypervisors we have some
amount of control onto, where bits of compiled dtb can be handed down
representing a sub-hierarchy of the tree.

Cheers,
Ben.