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

[Pantelis Antoniou]

Hi Ben,

> On May 14, 2015, at 10:14 , Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote:
> 
> On Thu, 2015-05-14 at 10:04 +0300, Pantelis Antoniou wrote:
> 
>> Hmm, since you just want to transmit a whole subtree things are a bit
>> simpler.
>> 
>> You don’t need any of the fixups, and your target node is known.
>> 
>> So your overlay is simply:
>> 
>> / {
>> 	fragment at 0 {
>> 		target-path = “/foo”;
>> 		__overlay__ {
>> 			/* contents of the slot */
>> 		};
>> 	}; 
>> };
>> 
>> I think it’s possible to just bit-mangle a blob (in pseudo code).
>> 
>> 	const u8 template_overlay_blob[] = { <compiled blob of the above> };
>> 
>> 	flatten_slot(slot_blob);
>> 
>> 	overlay_blob = allocate_new_blob(template_overlay_blob, slot_blob);
>> 
>> 	overlay_node = find_node(overlay_blob, “/fragment at 0/__overlay__);
>> 	target_prop = find_prop(overlay_blob, “/fragment at 0/target-path”);
>> 
>> 	inject_slot_blob(overlay_blob, overlay_node, slot_blob);
>> 	modify_slot_target(overlay_blob, target_prop, slot_target);
>> 	
>> I don’t think you need to re-flatten anything, shuffling bits around with
>> memmove should work.
> 
> Fairly gross :-)
> 

You don’t want to know how sausages are made, but they are delicious :)

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

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.

> - No support for "committing" the overlay which needs to be added as
> well.
> 

That’s the easiest part.

>>>>> 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
>>> 
>>> Not sure how that applies in my case ... I can't change the
>>> representation of the PCI subtree, this is standard OFW representation,
>>> I can't change the FW to make it an overlay-like thing at boot time,
>>> that would break existing kernels.
>>> 
>> 
>> The idea is to append the ‘quirk’ to the already booting device tree blob.
> 
> I know but that's not how things work for me. At boot time the FW passes
> me one tree that contains all the PCI stuff it has probed.
> 
>> Another idea floating around was to simple concatenate the booting blob with
>> any overlay blobs you want applied at boot time.
> 
> Sure but I don't get overlay blobs at boot time.
> 
>>>>> 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.
>>> 
>>> Yes but as I said it's not really thought in term of keeping the kernel
>>> tree in sync with an external dynamically generated tree. Maybe we can
>>> fix it, but it's more complex…
>>> 
>> 
>> Yes it is, unfortunately.
> 
> Right. Which makes the solution of just passing my bit of tree as a blob
> which I expand in Linux where I want it rather than an overlay tempting
> if we can make Gavin patch more palatable (removing the hybrid stuff
> etc…)
> .
> 

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.

> Cheers,
> Ben.
> 
>>> Ben.
>>> 
>>>>> Ben.
>>>>> 
>>>>> 
>>>> 
>>>> Regards
>>>> 
>>>> — Pantelis
>>> 
>>> 
>> 
>> Regards
>> 
>> — Pantelis
> 
> 

Regards

— Pantelis