[PATCH] of/fdt: Add unflatten_partial_device_tree

[Stephen Neuendorffer]

>> Another question is what to do with the unflattened tree once it is
>> unflattened.  Some of the existing code expects the node to be part of
>> the global tree.  Those could either be refactored, or the new partial
>> tree could be grafted into the global tree.  Grafting will have the
>> least impact, but it probably isn't a good idea in the long term.
>> Grafting together unrelated trees seems messy to me.
>
>I think I must have missed an earlier discussion.  What's the use case
>for multiple fdt blobs?

Basically, we are building systems which have an FPGA sitting on a PCIe.  The
FPGA contains an internal bus with lots of devices.  From the structural point
of view, it seems to make sense to describe the connectivity of this subsystem
with a device tree: albeit a slightly strange one with no processor: just a pcie<->plb
bridge and a number of devices.  Since this subsystem is, in fact, architecture independent
(you could physically plug it into a PCIe slot on a system with any processor architecture)
it is a bit of a poster case for generalizing more of the device tree infrastructure.
In particular, we are most interested in doing this in X86 systems.

Which leads me back to the first question: My approach so far is that the device
tree fragment is completely independent of any toplevel device tree, for the simple
reason that on X86, there *isn't* a toplevel device tree...   The devices that get generated
are in the regular device structure, which is similar to the way pci bridges and pcimcia
drivers work.

Steve



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20100628/01420041/attachment-0001.htm>