Hi Ben, Sorry for taking this long to respond, but I am working on the same problem right now. I thought I might have something to show, but not yet :) My PCI overlay case is different. In my case there is no firmware and there is the blob is provided as an overlay. The idea is that for a given PCI bus, when a PCI device with a matching device id, vendor id is probed a matching overlay should be applied. The trickiness lies in the way that the way that the target is different each time and how to handle generational issues (i.e. what happens if the pci device is removed before the application of the overlay occurs, what happens when multiple applications should happen in parallel, etc.) > On May 14, 2015, at 03:54 , Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > > 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. > I think using overlays should cover your case without any issues. I don’t like messing with the unflatten method TBH. >> 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 ? > Yes. > - 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. > The overlay when applied is a part of the kernel DT tree. It is trivial to add a mechanism that simply commits everything and tosses away the revert information. Note that in that case you have to make provisions for the unflatten blob to not be freed or for the device tree nodes/properties to be dynamically allocated. > 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. > If you use an overlay, you just revert it and everything would be as it was before, without anything hanging below the slot node. Note that the ‘remove all nodes below the slot’ does not work for my case. That is because there are devices being instantiated under the slot (i2c busses, i2c devices, FPGAs etc) that need to be removed from the system. > - On PCI re-plug, the FW internally builds new nodes and sends a > new subtree as an FDT that we can expand/attach. > You can easily send a DT blob containing an overlay from firmware. It can be even easy, since you might not have to recreate the full blob each time, but instead using flat device tree methods to populate the few properties that change each time. > 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. > I have posted another patch that does boot-time DT quirk which are non-revertable. https://lkml.org/lkml/2015/2/18/258 > 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… > The first DT overlays use case (beaglebone capes) is what got the concept started. Right now is a generic mechanism to apply modifications to the kernel live tree, with the possibility to revert them. > Ben. > > Regards — Pantelis -- 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
