[PATCH v4 19/21] drivers/of: Support adding sub-tree

[Pantelis Antoniou]

Hi Ben,

> 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
> 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