[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK7LNASZSSkUOTGeCB-JsSyX8a7EbKOD5UdQPqN4pVnG5rXeKg@mail.gmail.com>
Date: Mon, 21 Oct 2024 10:22:05 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Chris Packham <chris.packham@...iedtelesis.co.nz>
Cc: nathan@...nel.org, nicolas@...sle.eu, linux-kbuild@...r.kernel.org,
linux-kernel@...r.kernel.org,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2] kbuild: Restore the ability to build out of tree dtbs
On Mon, Oct 21, 2024 at 7:57 AM Chris Packham
<chris.packham@...iedtelesis.co.nz> wrote:
>
> +cc devicetree
>
> Hi Masahiro,
>
> On 19/10/24 00:19, Masahiro Yamada wrote:
> > On Thu, Oct 17, 2024 at 4:59 AM Chris Packham
> > <chris.packham@...iedtelesis.co.nz> wrote:
> >> A build pattern to handle out of tree dtbs is to copy the .dts file into
> >> the kernel source tree and run `make myboard.dtb`. This is supported by
> >> the wildcard %.dtb rule in the Makefile but recent changes to split the
> >> dtb handling out of scripts/Makefile.build stopped this from working.
> >> Restore this functionality by looking for .dtb in $(MAKECMDGOALS) as
> >> well as $(targets).
> >>
> >> Fixes: e7e2941300d2 ("kbuild: split device tree build rules into scripts/Makefile.dtbs")
> >> Signed-off-by: Chris Packham <chris.packham@...iedtelesis.co.nz>
> >> ---
> > This is not a use-case in upstream.
> >
> > If you drop-in your downstream DT to the kernel tree,
> > you need to associate it with Makefile.
>
> I agree that this is Hyrum's Law at work. I still feel that handling
> out-of-tree dtbs is something that would be in the best interest of the
> Linux kernel. It doesn't necessarily need to be done by allowing copying
> arbitrary .dts files into the tree, a mechanism like the way out of tree
> kernel modules are handled would be workable.
>
> Often supporting a new hardware platform is just a matter of writing a
> dts that describes the board. Particularly when that board is based on
> an existing one. The way most dts/dtsi files are arranged in-tree
> requires a non trivial amount of handling by the C processor. So while
> one could produce a dtb file by invoking cc -E and dtc with the right
> options pointing at the right paths, having the kernel build system
> provide something that abstracts that would be beneficial for developers
> and even end users.
I also handle a bunch of yet-to-upstream device tree files.
I have them in the proper directory location, and add
dtb-$(CONFIG_ARCH_FOO) += foo-downstream-custom1.dtb
dtb-$(CONFIG_ARCH_FOO) += foo-downstream-custom2.dtb
...
jutt like how they would look when they were upstreamed.
I do not understand why the drop-in way is supported.
> >> Notes:
> >> Changes in v2:
> >> - keep $(target) and search for .dtb in $(MAKECMDGOALS)
> >>
> >> scripts/Makefile.build | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> >> index 8f423a1faf50..78763a4bc58a 100644
> >> --- a/scripts/Makefile.build
> >> +++ b/scripts/Makefile.build
> >> @@ -449,7 +449,7 @@ ifneq ($(userprogs),)
> >> include $(srctree)/scripts/Makefile.userprogs
> >> endif
> >>
> >> -ifneq ($(need-dtbslist)$(dtb-y)$(dtb-)$(filter %.dtb %.dtb.o %.dtbo.o,$(targets)),)
> >> +ifneq ($(need-dtbslist)$(dtb-y)$(dtb-)$(filter %.dtb %.dtb.o %.dtbo.o,$(targets))$(filter %.dtb,$(MAKECMDGOALS)),)
> >> include $(srctree)/scripts/Makefile.dtbs
> >> endif
> >>
> >> --
> >> 2.47.0
> >>
> >>
> >
> > --
> > Best Regards
> > Masahiro Yamada
>
--
Best Regards
Masahiro Yamada
Powered by blists - more mailing lists