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

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

Hi all,

At Variscite, we are starting to look at how best to maintain upstream
Linux support for multiple hardware revisions of our SoMs and carrier
boards. We would appreciate guidance before settling on an approach.
Our goal is to support new revisions while allowing customers to keep
using current kernels on older hardware.

Our platforms are typically described by a SoM .dtsi and a carrier-board
.dts, for example imx8mm-var-som.dtsi and imx8mm-var-som-symphony.dts.
Both the SoM and the carrier can evolve independently. Some revisions
require changes to the hardware description, while others may work with
the same DT. Over time, this leaves us with several combinations to
support, without wanting to duplicate complete device trees for each one.

What would be the recommended upstream approach to organizing and
maintaining these revisions and their supported combinations?

One possibility we have considered is keeping the common SoM and carrier
descriptions in .dtsi files, with revision-specific .dtsi files extending
or overriding them, and small top-level .dts files selecting the required
combination. Would this be a suitable structure? Are there established
patterns or existing platforms we should follow, particularly to keep
changes for newer revisions from affecting older ones?

We are also wondering how to handle revisions that can share the same
description. As a concrete example, we have discussed the following
possible grouping for DART-MX8M Mini and Sonata:

  imx8mm-var-dart-2.0-sonata-1.0.dtb
    DART-MX8M Mini v2.0-v2.1 on Sonata v1.0-v1.3

  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.

Would it be acceptable to keep updating the first DTS to support a
compatible revision such as v2.1, retaining the v2.0 filename, as long as
it remains correct for all previously supported hardware? In this scheme,
we would add a separate DTS/DTB for v2.2 only if a different description
were needed.

This is an initial idea rather than a settled design, so suggestions for
a different approach would be very welcome.

Thanks,
Best Regards,
Stefano