[PATCH v4 19/21] drivers/of: Support adding sub-tree
panto at antoniou-consulting.com
Thu May 14 17:34:26 AEST 2015
> On May 14, 2015, at 10:25 , Benjamin Herrenschmidt <benh at kernel.crashing.org> 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
>> 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 */
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
>> 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 :)
More information about the Linuxppc-dev