arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10

Commit Message

Heiko Stuebner Dec. 1, 2023, 7:12 p.m. UTC

From: Heiko Stuebner <[e-mail]>

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.

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 <[e-mail]>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

Comments

Florian Fainelli Dec. 1, 2023, 7:57 p.m. UTC | #1

+Francesco,

On 12/1/23 11:12, Heiko Stuebner wrote:
> From: Heiko Stuebner <[e-mail]>
> 
> 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.
> 
> 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 <[e-mail]>

There is a competing patch set from Francesco being submitted as well:

https://lore.kernel.org/all/[e-mail]/

looks like some coordination is necessary.

Francesco Dolcini Dec. 1, 2023, 8:09 p.m. UTC | #2

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 <[e-mail]>
> > 
> > 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.

> > 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 <[e-mail]>
> 
> There is a competing patch set from Francesco being submitted as well:
> https://lore.kernel.org/all/[e-mail]/
>
> looks like some coordination is necessary.

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.

Francesco

Heiko Stuebner Dec. 1, 2023, 8:56 p.m. UTC | #3

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 <[e-mail]>
> > > 
> > > 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 <[e-mail]>
> > 
> > There is a competing patch set from Francesco being submitted as well:
> > https://lore.kernel.org/all/[e-mail]/
> >
> > 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

Heiko Stuebner Dec. 1, 2023, 9:03 p.m. UTC | #4

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 <[e-mail]>
> > > > 
> > > > 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 <[e-mail]>
> > > 
> > > There is a competing patch set from Francesco being submitted as well:
> > > https://lore.kernel.org/all/[e-mail]/
> > >
> > > 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.

Francesco Dolcini Dec. 1, 2023, 9:12 p.m. UTC | #5

On Fri, Dec 01, 2023 at 10:03:07PM +0100, Heiko Stübner wrote:
> 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 <[e-mail]>
> > > > > 
> > > > > 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 <[e-mail]>
> > > > 
> > > > There is a competing patch set from Francesco being submitted as well:
> > > > https://lore.kernel.org/all/[e-mail]/
> > > >
> > > > 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) ;-)

I think this is not relevant. It uses only 2 uart in total, it should just
works with the actual config.

Francesco

Francesco Dolcini Dec. 2, 2023, 11:51 a.m. UTC | #6

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 <[e-mail]>
> > > > 
> > > > 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 <[e-mail]>
> > > 
> > > There is a competing patch set from Francesco being submitted as well:
> > > https://lore.kernel.org/all/[e-mail]/
> > >
> > > 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/[e-mail]/

I would propose that we stay with my current proposal of 8.

Francesco

Heiko Stuebner Dec. 2, 2023, 12:12 p.m. UTC | #7

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 <[e-mail]>
> > > > > 
> > > > > 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 <[e-mail]>
> > > > 
> > > > There is a competing patch set from Francesco being submitted as well:
> > > > https://lore.kernel.org/all/[e-mail]/
> > > >
> > > > 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/[e-mail]/

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/[e-mail]/

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


Heiko

Quentin Schulz Dec. 4, 2023, 9:32 a.m. UTC | #8

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 <[e-mail]>
>>>>>>
>>>>>> 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 <[e-mail]>
>>>>>
>>>>> There is a competing patch set from Francesco being submitted as well:
>>>>> https://lore.kernel.org/all/[e-mail]/
>>>>>
>>>>> 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/[e-mail]/
> 
> 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/[e-mail]/
> 
> 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

Patch

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b60aa1f89343..69835dc43d24 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -448,6 +448,7 @@  CONFIG_SERIO_AMBAKMI=y
 CONFIG_LEGACY_PTY_COUNT=16
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=10
 CONFIG_SERIAL_8250_EXTENDED=y
 CONFIG_SERIAL_8250_SHARE_IRQ=y
 CONFIG_SERIAL_8250_BCM2835AUX=y