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

Hi Ben,

On May 14, 2015, at 10:25 , Benjamin Herrenschmidt =

[off-list ref] wrote:

=20
On Thu, 2015-05-14 at 10:19 +0300, Pantelis Antoniou wrote:
=20

quoted

=20
You don=E2=80=99t want to know how sausages are made, but they are =

delicious :)

=20
... most of the time :)
=20

quoted

quoted

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

quoted

quoted

(or in my internal ptr-based representation I could have a concept =

of

quoted

quoted

alias which I follow while flattening).
=20
That leaves me with these problems:
=20
- No support for removing of nodes, so that needs to be added back =

to

quoted

quoted

the format and to Linux unless I continue removing by hand in the =

PCI

quoted

quoted

hotplug code itself
=20

=20
What kind of nodes/properties you need to remove at _application_ =

time?

=20
Well, if we stick to removing by hand in Linux for the unplug case, =

then

none.
=20

OK

quoted

What you describe is inserting a bunch of properties and nodes under
a slot=E2=80=99s device node. Reverting the overlay removes them all =

just fine.

=20
Except that still doesn't work for boot time :-)
=20
So I would have to do a special case on unplug:
=20
	if (slot->dt_is_overlay) /* set to false at boot */
		remove_subtree_myself();
	else
		undo_overlay(slot->overlay);
=20

OK, in that case you do require removal. But in any case it=E2=80=99s =
the =E2=80=98negative=E2=80=99
of an already applied one, either at boot time or not.

Modifying the overlay code to apply a =E2=80=98negative=E2=80=99 =
property should do the trick.

Is that correct?

quoted

quoted

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

=20
That=E2=80=99s the easiest part.

=20
Yeah, I will need to get my head around the code a bit more but it
doesn't seem too scary.
=20

quoted

I see. Well, how about this?
=20
Who said you have to do the whole blob dance in the firmware?
=20
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.

=20
That's not that pretty but we can do that too which solve the problem =

of

fixing the FW interface.
=20
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.
=20
A few cases have crept up on the radar, like updating the pstate =

tables

or VPD informations ...
=20
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.
=20

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.
=20

I see. Bonne chance :)

Ben.
=20
=20

Regards

=E2=80=94 Pantelis