[PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10

[Heiko Stübner]

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.

Thanks Florian for catching this coincidence.


> Yep, thanks Florian.
> 
> Heiko: should I include your needs in my patch? It looks like these are the
> days of the 8250 uart, I sent my patch just one day before yours.

yeah, I was surprised by the time overlap as well.

After reading up on NR_UARTS and NR_RUNTIME_UARTS I opted for going with
the maximum possible.

>From what I understood, increasing the runtime-uart-number would incur
overhead in terms of prepared data structures. But the core NR_UARTS
only seems to limit the actual maximum number of uarts in the system.

With the somewhat recent patch named above, even those can still be
registered without bad effects, so I opted with increasing the NR_UARTS
to the maximum to expect at some point, least the next board then needs
yet another patch.
But left the runtime number alone to not create overhead.


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 ;-).


Heiko