Re: [RFC] arm64: dts: freescale: Supporting Variscite SoM and carrier revisions

[Stefano Radaelli <stefano.radaelli21@gmail.com>]

Hi Frank,

On Fri, Oct 23, 2026 at 10:15:36AM -0500, Frank Li wrote:
> >
> >   imx8mm-var-dart-2.2-sonata-1.4.dtb
> >     DART-MX8M Mini v2.2 on Sonata v1.4
> >
> > These are proposed names, assuming that the same DT correctly describes
> > all the hardware combinations covered by each entry.
> 
> If new boards 2.3 appear, do you plan change to
> imx8mm-var-dart-2.2-sonata-1.4-2.3.dtb?
> 
> Rename affect addtional problem or efforts when back port.

No, our intention is to keep the filename unchanged. For example,
imx8mm-var-dart-2.0-sonata-1.0.dtb would retain that name even if it
also supports later revisions, provided that the same description
remains correct for all previously supported hardware.

Regarding the filename itself, would it be acceptable to include both
the SoM and carrier hardware revisions, as in the example above?
Or is there a preferred upstream naming convention for distinguishing
these combinations? I have not found a clear example to follow where
both revisions are included in the filename.

We would introduce a separate DTS/DTB only when the hardware requires
a different description, sharing the common parts through .dtsi files.
Our preference is to distribute complete DTBs that the bootloader
can load directly.

> How about use boards compatible string? You add new compatible for new
> boards, so user know this dts cover which boards.

Could you give an example of how you would handle the root compatible
property when the same DTB is used unchanged on multiple revisions?

For instance, if SoM v2.0 and v2.1 on the same carrier can share exactly
the same DT, would you retain the existing board compatible, or
introduce revision-specific strings? How would those be represented
in the shared DTS?

Thanks,
Stefano