[PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10

Quentin Schulz quentin.schulz at theobroma-systems.com
Mon Dec 4 01:32:03 PST 2023


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



More information about the Linux-rockchip mailing list