Re: [PATCH] of: Overlay manager

[John Stultz]

On Fri, Sep 9, 2016 at 12:26 PM, Pantelis Antoniou
<pantelis.antoniou@xxxxxxxxxxxx> wrote:
>> On Sep 9, 2016, at 06:06 , John Stultz <john.stultz@xxxxxxxxxx> wrote:
>>
>> So in many cases the dtb is appended when the kernel is built, not
>> when the abootimg is assembled.
>>
>> So its much easier to use abootimg -u to update a prebuilt boot.img in
>> place and reflash. That way users don't need to regenerate the kernel
>> w/ appended dtb.
>>
>
> I understand what youâre trying to do, but itâs not going to work.
>
> It will only work for a very small subset of overlays since you canât
> have more than a single phandle label.
>
> For instance this will not work:
>
> overlays {
>         overlay_0 {
>                 opt: opt_0 { bar; };
>         };
>         overlay_1 {
>                 opt: opt_1 { baz; };
>         };
> };
>
>
> frob_device {
>         compatible = âfrobâ;
>         use = <&opt>;
> };
>
> If your use case is simple enough youâll never hit this, but it does happen in
> more complex examples.

Why not then put the frob_device in the overlays?

And even so, just saying "its not going to work" isn't particularly
helpful since this *does* work for the use cases we currently have, so
lets not let perfect be the enemy of good.

I'm no dts expert (Dmitry wrote the patch), but we'd welcome ideas for
allowing a set of pre-determined dts configurations be boot-time
selectable. It doesn't have to be this solution, but we need something
and this is what we have right now.

Should we revisit multi-appended dtbs w/ a boot argument selector?
(Though this seems less ideal, as generating the various dtbs and the
duplicate waste would be a bit annoying).  Other ideas?

thanks
-john