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

[Frank Li]

On Thu, Sep 24, 2026 at 12:13:08PM +0200, Francesco Dolcini wrote:
> 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?

Yes, I will stop pick up overlay files, if context is the same.

>  2. if the answer is yes, is imx95-verdin-aquila-uart4-mcu.dtso fine?

imx-uart<n>-mcu.dtso. similar case imx9-mqs.dtso.  Uart<n> is cross while
imx famililer.

Frank

>
> Thanks,
> Francesco