[RFC] arm64: dts: freescale: Supporting Variscite SoM and carrier revisions
Frank Li
Frank.li at oss.nxp.com
Fri Oct 23 08:15:36 PDT 2026
On Fri, Oct 23, 2026 at 01:52:41PM +0200, Stefano Radaelli wrote:
> 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.
>
> 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?
It is quite depend on how much difference. maybe choose overlay to update.
but some change is quite big. Have to rename to .dtsi and use difference
dts to include dtsi.
>
> 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
How about use boards compatible string? You add new compatible for new
boards, so user know this dts cover which boards.
>
> 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.
>
> 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?
I think it is fine.
Frank
> 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
>
More information about the linux-arm-kernel
mailing list