linux-kernel - Re: [RFC 2/2] scripts: dtc: Handle outform dtbo

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]

Message-ID: <500e233e-77d5-698c-cca5-7f6f1cbb890e@gmail.com>
Date:   Mon, 11 Jan 2021 18:18:31 -0600
From:   Frank Rowand <frowand.list@...il.com>
To:     Rob Herring <robh+dt@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
        devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Bill Mills <bill.mills@...aro.org>, tero.kristo@...il.com
Subject: Re: [RFC 2/2] scripts: dtc: Handle outform dtbo

On 1/5/21 9:37 AM, Rob Herring wrote:
> On Tue, Jan 5, 2021 at 4:24 AM Viresh Kumar <viresh.kumar@...aro.org> wrote:
>>
>> Update dtc compiler to accept dtbo as an outform.
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
>>
>> ---
>> I feel that this needs to go directly to
>> https://git.kernel.org/pub/scm/utils/dtc/dtc.git
>>
>> Right ? I will send it separately if the idea is accepted here.
> 
> Yes, needs to go to devicetree-compiler list. I think this came up
> before and IIRC David wasn't completely in agreement. I looked briefly
> and couldn't find the thread though...
> 
> We really don't need a different extension because we could just
> examine the dtb to determine if it is an overlay or not. That's less
> obvious. We could also add meta-data to overlays defining what base
> they apply to. If we had that, a tool could just list all overlays

It may be valid to apply an overlay may be valid to more than one base FDT.

And for connector nodes and plugin overlays (which do not exist yet, I'm
way behind on bringing that concept forward), a single overlay may be
applied to more than one connector node in the base FDT.

> that should apply to a base and we could use that info for build time
> applying overlays. Of course, that and a dtbo extension/format are not
> mutually exclusive.
> 
>> ---
>>  scripts/dtc/dtc.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
>> index bdb3f5945699..40fa7128b3d6 100644
>> --- a/scripts/dtc/dtc.c
>> +++ b/scripts/dtc/dtc.c
>> @@ -357,6 +357,8 @@ int main(int argc, char *argv[])
>>  #endif
>>         } else if (streq(outform, "dtb")) {
>>                 dt_to_blob(outf, dti, outversion);
>> +       } else if (streq(outform, "dtbo")) {
>> +               dt_to_blob(outf, dti, outversion);
>>         } else if (streq(outform, "asm")) {
>>                 dt_to_asm(outf, dti, outversion);
>>         } else if (streq(outform, "null")) {
> 
> You also need to extend guess_type_by_name().
> 
> 
> Rob
>