linux-kernel - Re: [PATCH 1/1] of: unittest: rename overlay source files from .dts to .dtso

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] [day] [month] [year] [list]

Message-ID: <93d88940-1fb1-ce6c-4e1e-84bc868e7ff9@gmail.com>
Date:   Thu, 28 Apr 2022 13:16:31 -0500
From:   Frank Rowand <frowand.list@...il.com>
To:     Rob Herring <robh@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     David Gibson <david@...son.dropbear.id.au>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Michal Simek <michal.simek@...inx.com>,
        Anmar Oueja <anmar.oueja@...aro.org>,
        Bill Mills <bill.mills@...aro.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        linux-kbuild <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Pantelis Antoniou <pantelis.antoniou@...sulko.com>
Subject: Re: [PATCH 1/1] of: unittest: rename overlay source files from .dts
 to .dtso

On 4/28/22 08:05, Rob Herring wrote:
> On Thu, Apr 28, 2022 at 08:25:31AM +0200, Geert Uytterhoeven wrote:
>> Hi Rob,
>>
>> On Wed, Apr 27, 2022 at 11:14 PM Rob Herring <robh@...nel.org> wrote:
>>> On Wed, Jan 26, 2022 at 1:31 PM Rob Herring <robh@...nel.org> wrote:
>>>> On Fri, Jan 14, 2022 at 3:25 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>>>>> On Fri, Jan 14, 2022 at 3:10 AM Rob Herring <robh@...nel.org> wrote:
>>>>>> On Thu, Jan 6, 2022 at 11:23 AM Frank Rowand <frowand.list@...il.com> wrote:
>>>>>>> Patient Geert has pinged again.
>>>>>>
>>>>>> If it's not a patch to be reviewed, then I'm not going to see it most
>>>>>> likely. I don't read the DT list regularly...
>>>>>
>>>>> Fair enough...
>>>>>
>>>>>>> If I remember correctly you guys were not thrilled with this idea, but
>>>>>>> also did not seem strongly against it.  Are you willing to go along
>>>>>>> with .dtso for overlay source files?  If so, I will revive this patch
>>>>>>> series.
>>>>>>>
>>>>>>> David, if you are against supporting .dtso in the dtc compiler then
>>>>>>> the kernel can still support it through make rules.
>>>>>>
>>>>>> I'm not really interested in diverging from dtc. I'd suggest moving
>>>>>> the discussion to dtc list and/or devicetree-spec if you want to get
>>>>>> more attention on this.
>>>>>
>>>>> What needs to be supported in the dtc compiler?
>>>>> The fallback passed to guess_input_format() is "dts".
>>>>> So this has been working out-of-the-box since forever?
>>>>
>>>> Ah, okay.
>>>>
>>>>>> Also, keep in mind that extensions also affect MIME types which
>>>>>> someone was also asking about recently.
>>>>>
>>>>> You mean "MIME type of Devicetree Blobs and Sources"[1]?
>>>>> According to [2](2022-01-13), none of that has happened.
>>>>
>>>> This is what I was thinking of:
>>>>
>>>> https://github.com/devicetree-org/devicetree-specification/issues/46
>>>>
>>>> In any case, given everyone is ambivalent, send me an updated patch
>>>> and I'll apply it.
> 
> ^^^^^^^^
> 
>>>
>>> Ping! Anyone still want this?
>>>
>>> What I don't want to see is a mixture of .dts and .dtso. And now I'm
>>> reviewing RPi overlay patches[1] with .dts.
>>
>> I still prefer .dtso over .dts, as it allows tools to detect the file
>> type without having to read the file's contents.
>> Without this, e.g. make needs to have all overlays listed explicitly
>> in a Makefile.
>>
>> We do have .c, .h, .s (even .S), .dtsi. So why not .dtso?
> 
> Read above! I said to resend this patch and I will apply it.

Sorry for the delay.  Earlier I said the I would rework the patch (if needed
for the current kernel) and resend.  I've been distracted by other things
like bug fixes.  Otherwise resending this patch is at the top of my todo
list.

-Frank

> 
> Rob