Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC 2/2] scripts: dtc: Handle outform dtbo
To:     Rob Herring <robh+dt@kernel.org>,
        Viresh Kumar <viresh.kumar@linaro.org>
Cc:     Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
        devicetree@vger.kernel.org,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Bill Mills <bill.mills@linaro.org>, tero.kristo@gmail.com
References: <cover.1609844956.git.viresh.kumar@linaro.org>
 <7aa70809eff3f32d821761d2a763e4fb72ecc8fb.1609844956.git.viresh.kumar@linaro.org>
 <CAL_Jsq+0dL=LHo8r9mY_weBP_bQ97UOBnt596J3JoVHwGNinHA@mail.gmail.com>
From:   Frank Rowand <frowand.list@gmail.com>
Message-ID: <500e233e-77d5-698c-cca5-7f6f1cbb890e@gmail.com>
Date:   Mon, 11 Jan 2021 18:18:31 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CAL_Jsq+0dL=LHo8r9mY_weBP_bQ97UOBnt596J3JoVHwGNinHA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 1/5/21 9:37 AM, Rob Herring wrote:
> On Tue, Jan 5, 2021 at 4:24 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
>>
>> Update dtc compiler to accept dtbo as an outform.
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.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
>