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

[Francesco Dolcini]

Hello Frank,

On Wed, Sep 23, 2026 at 10:06:55AM -0500, Frank Li wrote:
> On Wed, Sep 23, 2026 at 10:41:11AM +0200, Francesco Dolcini wrote:
> > 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.

I, myself, and us as Toradex, care way more of our users/developer than
just pretending them to know more.

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

And I also disagree on this.

Having consistent and correct file names is important, we have the same
naming scheme for SoM using non-NXP SoC, and there is a clear benefit
from this for the users that has the information complete and correct
just from the file name.

With that said, considering our disagreement, let's try to get to a
point:

 1. is it a requirement to have this changed to have it merged?
 2. if the answer is yes, is imx95-verdin-aquila-uart4-mcu.dtso fine?

Thanks,
Francesco