Re: [PATCH 0/4] arm64: dts: freescale: Add Toradex iMX95 overlays

[Francesco Dolcini <francesco@dolcini.it>]

Hello Frank,

On Tue, Sep 22, 2026 at 01:31:51PM -0500, Frank Li wrote:
> On Tue, Sep 22, 2026 at 06:58:46PM +0200, Francesco Dolcini wrote:
> > On Tue, Sep 22, 2026 at 11:07:44AM -0500, Frank Li wrote:
> > > On Tue, Sep 22, 2026 at 04:33:45PM +0200, Ernest Van Hoecke wrote:
> > > > This series adds device tree overlays for the Toradex Verdin, Aquila,
> > > > and SMARC iMX95 SoMs.
> > > >
> > > > The series adds support for:
> > > > - NAU8822 Bridge Tied Load configuration on the Verdin Development Board
> > > > - UART_4 reservation for Cortex-M7 firmware on Verdin and Aquila
> > > > - SER0 reservation for Cortex-M7 firmware on SMARC
> > > >
> > > > The UART overlays mark the port as reserved so Linux does not claim it.
> > > > Firmware remains responsible for configuring the UART and its pads.
> > > >
> > > > The Makefile entries build standalone DTBOs and ready-to-use composed
> > > > DTBs for the corresponding Development Boards.
> > > >
> > > > Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
> > > > ---
> > > > Ernest Van Hoecke (4):
> > > >       arm64: dts: freescale: imx95-verdin: Add NAU8822 Bridge Tied Load
> > > >       arm64: dts: freescale: imx95-verdin: Add Cortex-M7 UART_4 overlay
> > > >       arm64: dts: freescale: imx95-aquila: Add Cortex-M7 UART_4 overlay
> > >
> > > both reserved lpuart2, can you share one dtso?
> >
> > The comment in the DT file must be different because it's important to
> > reference the actual board it applies to.
> >
> > So to fulfill this request we would need to add a common dtsi, include
> > it from two different dtso files.
> 
> No, direct use one dtso. see
> 
> https://elixir.bootlin.com/linux/v7.3-rc3/source/arch/arm64/boot/dts/freescale/imx-pcie0-ep.dtso
> 
> And makefile to check how apply the same dtso for difference boards

imx-pcie0-ep.dtso works as a single shared file because its content is
generic, there is no board name anywhere in it, and nobody needs to
apply that specific dtbo by hand to know what it is for.

These overlays are different: they are meant to be picked up and applied
directly by the end user, in addition to also being combined in-tree
into a ready DTB. Put yourself in that user's shoes: they have a Verdin
board, they want to free up UART_4 for their Cortex-M7 firmware, and
they go looking in arch/arm64/boot/dts/freescale/ for the overlay that
does that for their board. What they need at that point is a file name
that says "this is for Verdin" and "this is the UART_4 one", and once
they open it, a comment that confirms both: which board and which
specific UART. That is the whole point of shipping the overlay
separately from a combined DTB: it is meant to be readable and
applicable on its own by someone who is not a DT expert.

There is also a second, even more constrained user: the one who never
looks at the kernel sources at all, and only gets the compiled .dtbo as
deployed on their distribution, e.g. under /boot/overlays/ on the
target, or the more generic paths used by distributions like Debian
(/boot/firmware/overlays/) or Armbian (user_overlays= in
armbianEnv.txt), picking it by name from an overlay list or a U-Boot
env variable. Comments do not survive dtc compilation, so for that user
the file name is the only information available, there is no comment to
fall back on.

A single dtso shared between Verdin and Aquila fails that on both
counts: the name has to become something generic like
imx95-verdin-aquila-uart4-mcu.dtso (immediately confusing: which board
is it really for? can I use it on either?), and the comment inside can
no longer say which board it targets either. That is worse for the
person using it, for the sake of avoiding 2 lines of duplication:

  &lpuart2 {
  	status = "reserved";
  };

It also does not reduce the Makefile churn: we need the same number of
Makefile lines/combos either way, one dtso reused for two boards or two
dedicated ones. And this file will not change once merged, so there is
no maintenance overhead from keeping it per board.

We agree that avoiding duplication is generally the right call. When
there is real, growing duplication across dtso files, the right fix is
a shared dtsi included by the dtso files, not merging them into one. In
this case the duplication is 2 lines that will not change, so it does
not meet that bar either way.

We would like to keep the two dedicated dtso files.

Francesco