[PATCH 2/3] dts: Add ability to build DTOs only from arch/$(ARCH)/dts

[Sumit Garg]

On Tue, 1 Oct 2024 at 20:57, Marek Vasut <marex at denx.de> wrote:
>
> On 10/1/24 3:35 PM, Sumit Garg wrote:
>
> Hi,
>
> >>> On Sat, 28 Sept 2024 at 03:20, Marek Vasut <marex at denx.de> wrote:
> >>>>
> >>>> Currently the enablement of OF_UPSTREAM results on the build system
> >>>> searching for DTs only in dts/upstream/ . There are platforms which
> >>>> use U-Boot specific DTBOs applied on top of U-Boot control DT during
> >>>> SPL stage, and source DTs for these are located in arch/$(ARCH)/dtb.
> >>>
> >>> I would like to understand the need to maintain DTBOs separately from
> >>> DTBs. Why aren't we pushing DTBOs to Linux kernel sources as we do for
> >>> DTBs?
> >>
> >> This is a stopgap measure, I would like to start reducing the amount of
> >> U-Boot DTs for iMX platforms, but the DTBOs are still in U-Boot only, so
> >> I would like to have some middle-of-the-road solution until the DTOs get
> >> upstreamed to Linux too.
> >>
> >>> Jan recently pushed those so-called U-Boot specific DTBOs for a
> >>> TI platform which were accepted in the Linux kernel upstream. This
> >>> patch will just deny the ability to build those DTBOs from dts
> >>> upstream tree. IMHO, this takes a step backwards on the whole notion
> >>> of OF_UPSTREAM.
> >>
> >> I don't think this will deny building those DTOs which are already
> >> upstream. With OF_UPSTREAM enabled, this will build:
> >> - Upstream DTBs
> >> - Upstream DTBOs
> >> - U-Boot local DTBOs (and NOT U-Boot local DTBs)
> >> The DTs that are bundled into u-boot.itb are searched exactly in that
> >> order too, upstream ones first, upstream DTBOs second and finally the
> >> U-Boot local DTBOs. The upstream content should always get higher
> >> priority if there are any leftover DTBOs in U-Boot which are also upstream.
> >>
> >>> If we really want a middle ground solution to allow migration to
> >>> OF_UPSTREAM easier then we need to find a way to build DTBOs from both
> >>> directories (local and upstream dts). I would imagine that will likely
> >>> complicate building and packaging DTBOs.
> >>
> >> I believe this is exactly what this commit does ?
> >
> > Okay I see, probably the commit subject was too confusing for me:
> >
> > "dts: Add ability to build DTOs only from arch/$(ARCH)/dts"
> >
> > I can see the benefit that it provides to people migrating to
> > OF_UPSTREAM. The negative part can be people just not pushing the
> > DTBOs upstream which should rather be easier as we have seen Jan
> > pushing DTBOs upstream.
>
> That (push your stuff upstream, reduce the duplication in U-Boot) is up
> to maintainers to request.
>
> Strictly enforcing either/or means setting the entry bar to OF_UPSTREAM
> higher than the entry bar to Linux kernel, which is not gonna work.
>
> Giving contributors some middle-of-the-road solution might in fact
> expedite the switch to OF_UPSTREAM, even if it may not happen all at once.
>
> > There is also magic added by this patch
> > regarding which DTBO is actually being used (local or upstream one),
> > the packaging ordering can be magic to someone debugging a boot issue
> > on a particular platform.
>
> See discussion above, the ordering is well defined.
>
> > IMHO, the OF_UPSTREAM migration can wait until all the required DT
> > sources (.dts and .dtso) are present upstream. If we start to mix and
> > match DT sources then it is going to turn into maintainers' hardship
> > again. However, I am still open to further convincing arguments for
> > this.
> With some Linux kernel architectures, it takes months to get a singular
> patch review out of the maintainers.

Okay I see the pain but we already have that rule for .dts files for
OF_UPSTREAM switch but having a different rule for .dtso files is
going to make maintainability complex. The Linux kernel
sub-architecture maintainers remain the same for both .dts and .dtso
files.

> For systems which already have DTs
> upstream and only have DTOs left, the OF_UPSTREAM conversion and DTO
> upstreaming can be done in parallel, hence expedite the process.

Fair enough, let's try to find a middle ground to gate the local DTOs
behind a config to make the use of local DTOs explicit. How about
CONFIG_OF_UPSTREAM_LOCAL_DTOS?

-Sumit