[PATCH] scripts/Makefile.lib: also consider $(CONFIG_SYS_BOARD)-u-boot.dtsi

[Rasmus Villemoes]

On 29/09/2023 18.02, Tom Rini wrote:
> On Fri, Sep 29, 2023 at 09:15:00AM -0600, Simon Glass wrote:

>> Honestly at this point I've forgotten what this is all about.

Fair enough, let me try to recap, though even a summary is a bit long.

(1) I wanted to do what $subject says, and you seemed to be ok with that

https://lore.kernel.org/u-boot/CAPnjgZ1B+3v_5rCSBnUgZ6cVO4odjjDfeS0rx3iMw4vjXUo0VA@mail.gmail.com/

(2) Tom pointed out that, unfortunately, as-is, the patch caused a bunch
of build failures. With hindsight, that was inevitable.

https://lore.kernel.org/u-boot/c3c94614-9916-7316-e009-04ddbdc205bc@prevas.dk/

(3) I still very much would like the original patch to go in, and so I
pointed out that most of the current arch/*/dts/Makefile are actually
completely redundant, with the logic in scripts/Makefile.dts being in place.

This is when the thread turned away from talking about the original
patch, but rather the cleanup of the makefile logic that turns out to be
a prerequisite for said patch to go anywhere.

(4) Tom tested a patch that nuked most of the arch/arm/dts/Makefile,
which revealed a few defects, partly in Makefile.dts (got fixed in
6923f49d3ac2) partly in a board defconfig (got fixed in 2d158d3c387d).

>> Perhaps the easiest approach is to create a new Kconfig to control
>> whether a board-level .dtsi is included in the list of wildcard
>> searches. Then you can enable it for your board without affecting
>> others.
> 
> That's getting things backwards, from what this cleanup does.  Today we
> have messy lists of "build these device trees" and then don't use most
> of them, and some of the list is just Wrong (listing dts files as an
> output). 

(5) Then a few months passed. I'm still interested in the original
patch, and also the cleanup. So I pinged Tom to redo that build test
with most of the Makefile gone. While revisiting this and doing that
mechanical strip-down of the Makefile, I noticed that the Makefile has
grown not just one but two .dts files listed in dtb-y, which is of
course bogus, and nobody noticed or cared because the
scripts/Makefile.dts logic JustWorks.

So, given that today, each board, in the form of the defconfig used to
build for it, in 99.9% of cases already includes all the information the
build system needs in order to ensure that all relevant .dtb files gets
built [because there's only one and that's DEFAULT_DEVICETREE, or
there's more and those are in OF_LIST or SPL_OF_LIST], and the Makefile
is error-prone to maintain and when adding a new board one chooses some
semi-random-list to add one's .dtbs (or .dts.....) to, we want to simply
stop having all those lists in arch/arm/dts/Makefile (and the other
arch/*/dts/Makefile, but those are much smaller and can be handled
later). No TARGET lists, no SOC lists, no nothing.

Yes, there may still be some 0.1%. We're trying to figure out if they
exist, which they are, and how best to handle them. An easy fix is to
drop the condition on when OF_LIST is settable to something different
from its default (which is DEFAULT_DEVICETREE). But without knowing just
exactly which boards and which .dtbs we're talking about, it's hard to
know what the best solution is or if there is actually anything that
needs to be done.

Rasmus