[PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10

[Heiko Stübner]

Am Freitag, 1. Dezember 2023, 21:56:27 CET schrieb 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 ;-).

and looking at other rk3588 boards the indiedroid-nova actually
uses the uart9 (aka the 10th uart) ;-)

Also the turing-rk1 and orangepi-5-plus as well.