On Wed, 2015-05-13 at 19:18 -0500, Rob Herring wrote: > I haven't decided really. > > The main thing with the current patch is I don't really like the added > complexity to unflatten_dt_node. It is already a fairly complex > function. Perhaps removing of "hybrid" as discussed will help? I agree, we should be able to make that much simpler, I was planning on sorting that out with Gavin. > If there are things we can do to make overlays easier to use in your > use case, I'd like to hear ideas. I don't really buy that being more > complex than needed is an obstacle. That is very often the case to > have common, scale-able solutions. I want to see a simple case be > simple to support. Well, it's a LOT more complex from the FW perspective for a bunch of features we don't really need, in a way because the DT update in our case is just purely informational to avoid keeping wrong/outdated DT bits, it has little functional impact (it might have a bit for interrupt routing through bridges though). However, I am also pursuing an approach on FW side using a generation count in our nodes and properties which we could use to generate arbitrary overlays if we know what generation linux has. There might actual be a usage scenario for a generic way for our firwmare to convey DT updates to Linux for other reasons. A few things that I don't find in the overlay code (but maybe I haven't looked at it hard enough): - Can it remove nodes/properties ? - Can it "commit" a changeset so it's permanently part of the main DT ? We will never have a concept of "revertable" changesets, if we need a subsequent update, we will get a new overlay from FW that will remove what needs to be removed and add what needs to be added. IE, our current mechanism without overlay is fairly simple: - On PCI unplug, we remove all nodes below the slot (from linux), the FW does the equivalent internally. - On PCI re-plug, the FW internally builds new nodes and sends a new subtree as an FDT that we can expand/attach. Now we could consider that subtree as a changeset that can be undone, but that wouldn't work for boot time. And subsequent updates wouldn't have that concept of "undoing" anyway. 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. Now we might be able to reconcile them, but it feels to me that the overlay/changeset stuff is too rooted in the first concept... 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
