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

[Frank Li]

On Wed, Sep 23, 2026 at 10:41:11AM +0200, Francesco Dolcini wrote:
> 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@xxxxxxxxxxx>
> > > > > ---
> > > > > 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.

If someone is not DT expert, most likely direct use your prebuild dtbs,
not apply dtso theyself.

>
> 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.

It is not exactly true. include dtsi only one method. Basic there are two
kind type overy all files

- one is for addtional boards.
- change configuration.

You provide difference configuration, basically it is developping boards.
The real productions is fixed.

Your uboot scripts or other manually should hide complex. like PC grub
menu, just choose 1,2,3...

If someone like advance, he need know more knowledge.

Makefile show how to apply dtso to correct dtb.  filename rule can't
resolve problems without know detail.

The put lpuart2 as reserved also used by other boards, not only verdin
and aquila.

Frank

>
> We would like to keep the two dedicated dtso files.
>
> Francesco