Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Li <Frank.li@oss.nxp.com>
To: Stefano Radaelli <stefano.radaelli21@gmail.com>
Cc: devicetree@vger.kernel.org, imx@lists.linux.dev,
	Stefano Radaelli <stefano.r@variscite.com>,
	linux-arm-kernel@lists.infradead.org, Frank Li <Frank.Li@nxp.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Fabio Estevam <festevam@gmail.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	pierluigi.p@variscite.com, Nate.D@variscite.com,
	Peng Fan <peng.fan@nxp.com>, Shawn Guo <shawnguo@kernel.org>
Subject: Re: [RFC] arm64: dts: freescale: Supporting Variscite SoM and carrier revisions
Date: Fri, 23 Oct 2026 10:15:36 -0500	[thread overview]
Message-ID: <att6GNZAVv64Rlnv@SMW015318> (raw)
In-Reply-To: <20261023115242.11197-1-stefano.r@variscite.com>

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
>


  reply	other threads:[~2026-10-23 15:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-23 11:52 [RFC] arm64: dts: freescale: Supporting Variscite SoM and carrier revisions Stefano Radaelli
2026-10-23 15:15 ` Frank Li [this message]
2026-10-26  8:29   ` Stefano Radaelli
2026-10-26 16:37     ` Frank Li
2026-10-26 16:59       ` Stefano Radaelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=att6GNZAVv64Rlnv@SMW015318 \
    --to=frank.li@oss.nxp.com \
    --cc=Frank.Li@nxp.com \
    --cc=Nate.D@variscite.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=peng.fan@nxp.com \
    --cc=pierluigi.p@variscite.com \
    --cc=robh@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=stefano.r@variscite.com \
    --cc=stefano.radaelli21@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox