linux-kernel - RE: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
 <TY2PPF5CB9A1BE6085479040799D70F4BECF2FEA@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Date: Sat, 25 Oct 2025 03:15:51 +0000
From: Ryan Chen <ryan_chen@...eedtech.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>, Arnd Bergmann <arnd@...db.de>
CC: BMC-SW <BMC-SW@...eedtech.com>, Rob Herring <robh@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Joel
 Stanley <joel@....id.au>, Andrew Jeffery <andrew@...econstruct.com.au>,
	Jeremy Kerr <jk@...econstruct.com.au>, Lee Jones <lee@...nel.org>, Catalin
 Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, Bjorn
 Andersson <bjorn.andersson@....qualcomm.com>, Nishanth Menon <nm@...com>,
	Nícolas F. R. A. Prado <nfraprado@...labora.com>,
	Taniya Das <quic_tdas@...cinc.com>, "Lad, Prabhakar"
	<prabhakar.mahadev-lad.rj@...renesas.com>, Kuninori Morimoto
	<kuninori.morimoto.gx@...esas.com>, Eric Biggers <ebiggers@...nel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-aspeed@...ts.ozlabs.org"
	<linux-aspeed@...ts.ozlabs.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
 tree

> Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
> tree
> 
> On Thu, 23 Oct 2025 at 22:11, Arnd Bergmann <arnd@...db.de> wrote:
> > On Thu, Oct 23, 2025, at 09:37, Ryan Chen wrote:
> > >> > +  aliases {
> > >> > +          serial0 = &uart0;
> > >> > +          serial1 = &uart1;
> > >> > +          serial2 = &uart2;
> > >> > +          serial3 = &uart3;
> > >> > +          serial4 = &uart4;
> > >> > +          serial5 = &uart5;
> > >> > +          serial6 = &uart6;
> > >> > +          serial7 = &uart7;
> > >> > +          serial8 = &uart8;
> > >> > +          serial9 = &uart9;
> > >> > +          serial10 = &uart10;
> > >> > +          serial11 = &uart11;
> > >> > +          serial12 = &uart12;
> > >> > +          serial13 = &uart13;
> > >> > +          serial14 = &uart14;
> > >> > +  };
> > >>
> > >> This looks like you just list all the uarts that are present on the
> > >> chip, which is not how the aliases are meant to be used. Move this
> > >> block into the board specific file and only list the ones that are
> > >> actually enabled on that particular board.
> > >>
> > >> In particular, the alias names are meant to be local to the board
> > >> and don't usually correspond to the numbering inside of the chip.
> > >> In the defconfig, we currently set CONFIG_SERIAL_8250_NR_UARTS=8,
> > >> which is enough for any board we support so far, but that means
> > >> only the first
> > >> 8 aliases in the list will actually work.
> > >
> > > Understood. I'll move the aliases block from the SoC dtsi into the
> > > EVB board dts. For the EVB, UART12 is used as the default console,
> > > and the board labels match the SoC numbering, so I plan to keep:
> > >
> > > Does that look acceptable?
> > > ast2700-evb.dts
> > >       aliases {
> > >               serial0 = &uart0;
> > >               serial1 = &uart1;
> > >               serial2 = &uart2;
> > >               serial3 = &uart3;
> > >               serial4 = &uart4;
> > >               serial5 = &uart5;
> > >               serial6 = &uart6;
> > >               serial7 = &uart7;
> > >               serial8 = &uart8;
> > >               serial9 = &uart9;
> > >               serial10 = &uart10;
> > >               serial11 = &uart11;
> > >               serial12 = &uart12;
> > >               serial13 = &uart13;
> > >               serial14 = &uart14;
> > > }
> >
> > I think this would be broken for the defconfig if the consol is on
> > serial12. I would recommend using serial0 as the console, like
> >
> > aliases {
> >        serial0 = &uart12;
> > }
> >
> > in this case. If additional uarts are enabled, add those as further
> > aliases.
> 
> Indeed. Are all these serial ports exposed on the board?
> Aliases is mean to list only the ones that are exposed, and the alias number
> should match the label on the board/port ("serialN", "debugN", ...), ideally.
> 
> Typically only a few ports are exposed, so you may end up with something like:
> 
> arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi:           serial0 = &scif1;
> arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi:           serial1 = &scif3;
> arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi:           serial3 = &scif0;
> 
> I deliberately picked this example, as it shows how the serialN numbering does
> not need to match the scifM (or uartM) numbering.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
Hi Geert,

Thanks for the clarification and the Renesas example — that helps a lot.

Yes, on the AST2700 EVB only a few UARTs are actually routed out,
and UART12 is used as the main console port.

I’ll update the EVB DTS accordingly to list only the exposed ports, e.g.:

```dts
aliases {
    serial0 = &uart12; /* console */
};

> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> geert@...ux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds