On Mon, Jun 8, 2015 at 9:57 PM, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > On Sun, 2015-06-07 at 08:54 +0100, Grant Likely wrote: >> > IE. conceptually, what overlays do today is quite rooted around the idea >> > of having a fixed "base" DT and some pre-compiled DTB overlays that >> > get added/removed. The design completely ignore the idea of a FW that >> > maintains a "live" tree which we want to keep in sync, which is what we >> > want to do here, or what we could do with a "live" open firmware >> > implementation. >> >> Right, which is exactly the reason for the changeset/overlay split. >> Overlays assume a fixed base, and that overlays are kind of like plug-in >> modules. changeset makes no such assumption. > > So you suggest we create a function that takes an fdt and an "anchor" as input, > and expands that FDT below that anchor, but does so by using the changeset API > under the hood ? > > Even that looks somewhat tricky (turn that bit of FDT into a pile of changeset > actions), however, I can see how we could create a new function inside changeset > to attach a subtree. > > Ie. of_attach_subtree() (which could have it's own reconfig action but we > don't care that much yet), which takes an expanded subtree and an anchor, and > calls of_attach_node() in effect for all nodes in there. > > We could then have a two pass mechanism in our hotplug code: > > - Expand the bit of fdt into a separate tree > - Use of_attach_subtree to "add" that subtree to the main tree > > What do you think ? I like that. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
