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

[Sumit Garg]

On Fri, 4 Oct 2024 at 07:15, Marek Vasut <marex at denx.de> wrote:
>
> On 10/3/24 9:58 AM, Sumit Garg wrote:
>
> [...]
>
> >>> 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.
>
> What kind of rule is that ?
>
> If the rule for .dts files is either dts/upstream or arch/*/dts, then
> the rule for .dtso is either dts/upstream+fallback to arch/*/dts or only
> arch/*/dts .

Yeah that the rule difference we will have after this patch for .dtso
but I can live with that given it being gated behind the Kconfig
option below.

>
> > The Linux kernel
> > sub-architecture maintainers remain the same for both .dts and .dtso
> > files.
>
> Well, yes.
>
> >> 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?
> Do you think another Kconfig option is really necessary ? I don't mind
> adding one if you think that would make a difference, but I don't see it
> as strictly necessary.

Yeah I think it will make explicit the usage of local DTOs vs upstream DTOs.

-Sumit