linux-kernel - Re: [PATCH V11 3/5] kbuild: Allow .dtso format for overlay source files

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:   Wed, 10 Mar 2021 16:42:43 -0600
From:   Frank Rowand <frowand.list@...il.com>
To:     Masahiro Yamada <masahiroy@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Michal Marek <michal.lkml@...kovi.net>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        David Gibson <david@...son.dropbear.id.au>,
        Michal Simek <michal.simek@...inx.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Anmar Oueja <anmar.oueja@...aro.org>,
        Bill Mills <bill.mills@...aro.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V11 3/5] kbuild: Allow .dtso format for overlay source
 files

On 3/10/21 9:15 AM, Masahiro Yamada wrote:
> On Wed, Mar 10, 2021 at 11:47 PM Viresh Kumar <viresh.kumar@...aro.org> wrote:
>>
>> On 10-03-21, 20:24, Masahiro Yamada wrote:
>>> On Wed, Mar 10, 2021 at 2:35 PM Viresh Kumar <viresh.kumar@...aro.org> wrote:
>>>> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
>>>> index bc045a54a34e..59e86f67f9e0 100644
>>>> --- a/scripts/Makefile.lib
>>>> +++ b/scripts/Makefile.lib
>>>> @@ -339,7 +339,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb FORCE
>>>>
>>>>  quiet_cmd_dtc = DTC     $@
>>>>  cmd_dtc = $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \
>>>> -       $(DTC) -O $(patsubst .%,%,$(suffix $@)) -o $@ -b 0 \
>>>> +       $(DTC) -I dts -O $(patsubst .%,%,$(suffix $@)) -o $@ -b 0 \
>>>
>>> Even without "-I dts",
>>>
>>>    inform = guess_input_format(arg, "dts");
>>>
>>> seems to fall back to "dts" anyway,
>>
>> I missed this TBH.
>>
>>> but I guess you wanted to make this explicit, correct?
>>
>> That can be a reason now :)
>>
>>> I will drop the ugly -O.
>>> https://patchwork.kernel.org/project/linux-kbuild/patch/20210310110824.782209-1-masahiroy@kernel.org/
>>
>> But if we are going to depend on DTC to guess it right, then we
>> shouldn't add -I at all..
>>
>>> I will queue it to linux-kbuild/fixes.
>>>
>>>
>>>
>>>>                 $(addprefix -i,$(dir $<) $(DTC_INCLUDE)) $(DTC_FLAGS) \
>>>>                 -d $(depfile).dtc.tmp $(dtc-tmp) ; \
>>>>         cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)
>>>> @@ -347,9 +347,13 @@ cmd_dtc = $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ;
>>>>  $(obj)/%.dtb: $(src)/%.dts $(DTC) FORCE
>>>>         $(call if_changed_dep,dtc)
>>>>
>>>> +# Required for of unit-test files as they can't be renamed to .dtso
>>>
>>> If you go with *.dtso, I think you will rename
>>> all *.dts under the drivers/ directory.
>>>
>>> What is blocking you from making this consistent?
>>
>> The unit-test dts files are designed differently (we have had lots of
>> discussion between Frank and David on that) and they aren't purely
>> overlay or base files. They are designed to do some tricky testing and
>> renaming them to .dtso won't be right, we are just reusing them to do
>> static (build time) testing as well.
> 
> 
> I still do not understand.
> 
> If they are not overlay files, why
> do you need to have them suffixed with .dtbo?
> 
> ".dts -> .dtb" should be enough.
> 
> Why do you need to do ".dts  -> .dtbo" ?
> 
> 
> 
> 
>> I think it would be better if we can drop the existing %.dtbo rule
>> here (i.e. dtbo from .dts) and do some magic in unit-test's Makefile,
>> so it is localised at least instead of it here.
>>
>> Any ideas for that ?
> 
> I do not know.
> 


> My impression is you are doing something fishy.

That is accurate.  Devicetree unittest plays some tricks to enable
testing to occur.  These tricks will never be used anywhere else
in the kernel.

-Frank