[PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10
Francesco Dolcini
francesco at dolcini.it
Sat Dec 2 03:51:03 PST 2023
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/
I would propose that we stay with my current proposal of 8.
Francesco
More information about the Linux-rockchip
mailing list