Hi Ben, > On May 14, 2015, at 10:25 , Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, 2015-05-14 at 10:19 +0300, Pantelis Antoniou wrote: > >> >> You don’t want to know how sausages are made, but they are delicious :) > > ... most of the time :) > >>> But yeah generating the overlay doesn't necessarily scare me, I can >>> generate a temp tree that is the overlay in which I "copy" the subtree >>> (or in my internal ptr-based representation I could have a concept of >>> alias which I follow while flattening). >>> >>> That leaves me with these problems: >>> >>> - No support for removing of nodes, so that needs to be added back to >>> the format and to Linux unless I continue removing by hand in the PCI >>> hotplug code itself >>> >> >> What kind of nodes/properties you need to remove at _application_ time? > > Well, if we stick to removing by hand in Linux for the unplug case, then > none. > OK >> What you describe is inserting a bunch of properties and nodes under >> a slot’s device node. Reverting the overlay removes them all just fine. > > Except that still doesn't work for boot time :-) > > So I would have to do a special case on unplug: > > if (slot->dt_is_overlay) /* set to false at boot */ > remove_subtree_myself(); > else > undo_overlay(slot->overlay); > OK, in that case you do require removal. But in any case it’s the ‘negative’ of an already applied one, either at boot time or not. Modifying the overlay code to apply a ‘negative’ property should do the trick. Is that correct? >>> - No support for "committing" the overlay which needs to be added as >>> well. >>> >> >> That’s the easiest part. > > Yeah, I will need to get my head around the code a bit more but it > doesn't seem too scary. > >> I see. Well, how about this? >> >> Who said you have to do the whole blob dance in the firmware? >> >> You can just as easily pass the blob as it is to the linux kernel and >> the kernel there can convert it to an overlay and apply it. > > That's not that pretty but we can do that too which solve the problem of > fixing the FW interface. > > There is however an argument to be made in having the FW be able to > generate arbitrary overlays. If we ever want to pass more "property" > updates or node updates to Linux at runtime. > > A few cases have crept up on the radar, like updating the pstate tables > or VPD informations ... > > If we go down that path, then I would implement a concept of generation > count in the firmware, so I can generate an overlay that include all the > changes since the last "generation" given to Linux. > I will probably need that generation count myself for my PCI use case. > However that requires supporting removal of nodes/properties. So I'm > tempted to keep that feature on the back burner and go with an ad-hoc > interface for PCI for now. > I see. Bonne chance :) > 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
