On Mon, Jun 08, 2015 at 10:34:13PM +0100, Grant Likely wrote: >On Mon, Jun 8, 2015 at 9:57 PM, Benjamin Herrenschmidt ><b...@kernel.crashing.org> 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. >
Thanks, Grant and Ben. Currently, I'm collecting more feedbacks for v5. So it's something I will address in v6. Thanks, Gavin >g. > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
