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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdXTZZK-Tk0gerpARfr+jUNGPhEfRqGOtTvTTJp=SZ2ayg@mail.gmail.com>
Date: Fri, 24 Oct 2025 09:56:57 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Ryan Chen <ryan_chen@...eedtech.com>, 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

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

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