linux-kernel - Re: [PATCH] of: Overlay manager

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 9 Sep 2016 12:56:03 -0700
From:   John Stultz <john.stultz@...aro.org>
To:     Pantelis Antoniou <pantelis.antoniou@...sulko.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Dmitry Shmidt <dimitrysh@...gle.com>,
        Frank Rowand <frowand.list@...il.com>,
        "<linux-kernel@...r.kernel.org>" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [PATCH] of: Overlay manager

On Fri, Sep 9, 2016 at 12:26 PM, Pantelis Antoniou
<pantelis.antoniou@...sulko.com> wrote:
>> On Sep 9, 2016, at 06:06 , John Stultz <john.stultz@...aro.org> 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