[PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10

[Quentin Schulz]

Hi all,

On 12/2/23 13:12, Heiko Stübner wrote:
> 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 ;-)
> 

Actually, UART8 and UART9 (so the 9th and 10th controllers) are exposed 
on the Mezzanine connector and we have a HW design for a daughterboard 
using that already. So we'll eventually support it upstream as well.

So at least 10 is necessary if I understood correctly.

And yes, those are really named after their controller indices on the 
schematics. So we need the value of the symbol to be that high.

Cheers,
Quentin