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_5rCSBnUgZ6cVO4odjjDfeS0rx3iMw4vj...
(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.d...
(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