From: "Heiko Stübner" <heiko@sntech.de> To: Francesco Dolcini <francesco@dolcini.it> Cc: Florian Fainelli <f.fainelli@gmail.com>, Francesco Dolcini <francesco@dolcini.it>, linux-rockchip@lists.infradead.org, Francesco Dolcini <francesco.dolcini@toradex.com>, linux-arm-kernel@lists.infradead.org, quentin.schulz@theobroma-systems.com, Heiko Stuebner <heiko.stuebner@cherry.de> Subject: Re: [PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10 Date: Sat, 02 Dec 2023 13:12:32 +0100 [thread overview] Message-ID: <3898725.Zkmt1EvEu4@diego> (raw) In-Reply-To: <ZWsaJ-3bWZbjtFiz@livingston.pivistrello.it> 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@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@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 ;-) Heiko _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de> To: Francesco Dolcini <francesco@dolcini.it> Cc: Florian Fainelli <f.fainelli@gmail.com>, Francesco Dolcini <francesco@dolcini.it>, linux-rockchip@lists.infradead.org, Francesco Dolcini <francesco.dolcini@toradex.com>, linux-arm-kernel@lists.infradead.org, quentin.schulz@theobroma-systems.com, Heiko Stuebner <heiko.stuebner@cherry.de> Subject: Re: [PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10 Date: Sat, 02 Dec 2023 13:12:32 +0100 [thread overview] Message-ID: <3898725.Zkmt1EvEu4@diego> (raw) In-Reply-To: <ZWsaJ-3bWZbjtFiz@livingston.pivistrello.it> 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@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@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 ;-) Heiko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-12-02 12:13 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-12-01 19:12 [PATCH] arm64: defconfig: Increase SERIAL_8250_NR_UARTS to 10 Heiko Stuebner 2023-12-01 19:12 ` Heiko Stuebner 2023-12-01 19:57 ` Florian Fainelli 2023-12-01 19:57 ` Florian Fainelli 2023-12-01 20:09 ` Francesco Dolcini 2023-12-01 20:09 ` Francesco Dolcini 2023-12-01 20:56 ` Heiko Stübner 2023-12-01 20:56 ` Heiko Stübner 2023-12-01 21:03 ` Heiko Stübner 2023-12-01 21:03 ` Heiko Stübner 2023-12-01 21:12 ` Francesco Dolcini 2023-12-01 21:12 ` Francesco Dolcini 2023-12-02 11:51 ` Francesco Dolcini 2023-12-02 11:51 ` Francesco Dolcini 2023-12-02 12:12 ` Heiko Stübner [this message] 2023-12-02 12:12 ` Heiko Stübner 2023-12-04 9:32 ` Quentin Schulz 2023-12-04 9:32 ` Quentin Schulz
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3898725.Zkmt1EvEu4@diego \ --to=heiko@sntech.de \ --cc=f.fainelli@gmail.com \ --cc=francesco.dolcini@toradex.com \ --cc=francesco@dolcini.it \ --cc=heiko.stuebner@cherry.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-rockchip@lists.infradead.org \ --cc=quentin.schulz@theobroma-systems.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.