[PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10
Heiko Stübner
heiko at sntech.de
Sat Dec 2 04:12:32 PST 2023
Am Samstag, 2. Dezember 2023, 12:51:03 CET schrieb Francesco Dolcini:
> On Fri, Dec 01, 2023 at 09:56:27PM +0100, Heiko Stübner wrote:
> > Hi,
> >
> > Am Freitag, 1. Dezember 2023, 21:09:29 CET schrieb Francesco Dolcini:
> > > On Fri, Dec 01, 2023 at 11:57:53AM -0800, Florian Fainelli wrote:
> > > > +Francesco,
> > > >
> > > > On 12/1/23 11:12, Heiko Stuebner wrote:
> > > > > From: Heiko Stuebner <heiko.stuebner at cherry.de>
> > > > >
> > > > > Boards using socs like the rk3588 can use up to 10 uarts, so the default
> > > > > of 4 is way too low. Therefore increase the maximum number to 10.
> > > Do you have an actual need of 10, e.g. an existing board with 10 uarts
> > > enabled supported by the mainline kernel? Just thinking at the last arm64 SoC I
> > > am working with it should be 12 if we use this as a metric.
> >
> > The rk3588 can do 10 (0-9), the board I'm working on is using up to uart7 (aka 8 uarts).
> > Reasoning below in the 3rd paragraph.
> >
> >
> > > > > SERIAL_8250_RUNTIME_UARTS on the other hand describes the number of uart
> > > > > data structures to prepare before registering them. This option can stay
> > > > > at its default value of 4 since for one it can be changed via a boot
> > > > > parameter 8250.nr_uarts but also since
> > > > > commit 9d86719f8769 ("serial: 8250: Allow using ports higher than SERIAL_8250_RUNTIME_UARTS")
> > > > >
> > > > > the kernel can register uarts dynamically that are above the
> > > > > SERIAL_8250_RUNTIME_UARTS threshold.
> > > > >
> > > > > Signed-off-by: Heiko Stuebner <heiko.stuebner at cherry.de>
> > > >
> > > > There is a competing patch set from Francesco being submitted as well:
> > > > https://lore.kernel.org/all/20231201171544.1901-1-francesco@dolcini.it/
> > > >
> > > > looks like some coordination is necessary.
> >
> >
> > So TL;DR:
> > I could live with the 8 from your original patch, but I guess would prefer
> > going with a safer value, so the 10 or your 12 from above.
> >
> > Because I guess if a controller is present, someone will use it
> > eventually ;-).
>
> There was an explicit push back on this approach from Arnd, see
> https://lore.kernel.org/all/CAK8P3a2VSBvOn1o+q1PYZaQ6LS9U4cz+DZGuDbisHkwNs2dAAw@mail.gmail.com/
aliases really are a matter of difficult discussions ;-)
I.e. Krzysztof's argument some days ago was
"No, this should be per-board to match board labeling/schematics."
https://lore.kernel.org/all/813224c2-398d-4c2d-8909-1839ce63be60@linaro.org/
And on Rockchip socs everyting from soc manual, board schematics down to
the description of pin headers use the uart controller number so people will
expect uart9 to be ttyS9 on the system as well.
> I would propose that we stay with my current proposal of 8.
But ok we can go this route, simply as the current board I'm working on
only use 8, so I can leave that "fight" to someone else ;-)
Heiko
More information about the Linux-rockchip
mailing list