On Mon, 2015-05-04 at 11:30 +1000, Gavin Shan wrote: > Thanks, Ben. If we really need utilize overlay to support our case, > we need some one to parse the input (device-tree changes) from > firmware > and create "overlay" device node and "target" node as I mentioned > above. > It's not simpler than the way we had to support our case. I'm not sure > if we really need utilize overlay for our case. No, if we decide to go down that path, then the FW needs to create the overlay. This could be done by having some kind of versioning to all nodes and properties using a global generation count. Ie, if we "know" what we passed to Linux, we can generate an overlay that contains everything that changed since then using the version numbers. However, we should probably encode the version in the tree itself and have specific APIs to retrieve "from" a given version to properly deal with kexec'ing a kernel since in that case, the new kernel will have something that isn't version 0 but version N where N is the latest applied overlay. Also I don't know how removing nodes works with overlay. IE the overlay system is designed around the idea of removing the overlay to retrieve the original tree. In our case, our overlays are meant to be fully committed, and I don't know whether there's a way to keep track. On unplug, we will just remove all the nodes below the slot. Cheers, Ben. -- 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
