* Re: [PATCH tty v3 6/6] serial: 8250: Add support for console flow control
From: John Ogness @ 2026-04-20 9:57 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Greg Kroah-Hartman, Jiri Slaby, linux-kernel, Ilpo Järvinen,
Ingo Molnar, Osama Abdelkader, Krzysztof Kozlowski,
Gerhard Engleder, Lukas Wunner, Dr. David Alan Gilbert,
Joseph Tilahun, linux-serial
In-Reply-To: <CAHp75Vf4YZVqXa7eH-RFeVsycdzoHijcWFnUbGv2PSmtPya1-w@mail.gmail.com>
On 2026-04-20, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>> struct uart_8250_port *uart;
>> + bool cons_flow;
>
>> + /* Preserve specified console flow control. */
>> + cons_flow = uart_get_cons_flow(&uart->port);
>
> Sorry for nit-picking, but when I see 'bool' and see a getter, I got
> confused.
Understandable. Right now the wrappers are a bit overkill since it is
just a single boolean and there are no locking constraints.
> I would rather see getter/setter to be something like
>
> cons_flow = uart_is_cons_flow_enabled(&uart->port);
> uart_enable_cons_flow(&uart->port);
> uart_disable_cons_flow(&uart->port);
I will use your suggested API for v4 unless someone makes a case for a
different API (or just direct accessing with no wrappers).
Note that this comment actually applies to patch 1 of the series.
John
^ permalink raw reply
* Re: [PATCH] tty: n_gsm: fix use-after-free in gsmtty_install
From: Greg KH @ 2026-04-20 9:26 UTC (permalink / raw)
To: Kito Xu (veritas501); +Cc: jirislaby, linux-serial, linux-kernel
In-Reply-To: <20260415031731.107667-1-hxzene@gmail.com>
On Wed, Apr 15, 2026 at 11:17:31AM +0800, Kito Xu (veritas501) wrote:
> gsmtty_install() reads gsm_mux[] without holding gsm_mux_lock and
> defers mux_get() about 40 lines later. A concurrent gsmld_close() can
> free the mux through gsm_cleanup_mux() -> mux_put() -> kfree(gsm) in
> that window, leading to a use-after-free when gsmtty_install() later
> dereferences the stale pointer.
>
> race condition:
>
> cpu 0 | cpu 1
> gsmtty_install() | gsmld_close()
> gsm = gsm_mux[mux] // no lock |
> // CFS preempts here | gsm_cleanup_mux(gsm)
> | gsm->dead = true
> | mux_put(gsm)
> | -> kfree(gsm)
> gsm->dead // UAF! |
> mutex_lock(&gsm->mutex) // UAF! |
>
> KASAN report:
>
> BUG: KASAN: slab-use-after-free in gsmtty_install+0x6cf/0x830
> Read of size 1 at addr ffff88800fd440ac by task poc/170
Do you have this hardware to test with, or was this done in a virtual
machine?
>
> CPU: 0 UID: 0 PID: 170 Comm: poc Not tainted 7.0.0-rc7-next-20260410+ #20
> Call Trace:
> <TASK>
> dump_stack_lvl+0x64/0x80
> print_report+0xd0/0x5e0
> kasan_report+0xce/0x100
> gsmtty_install+0x6cf/0x830
> tty_init_dev.part.0+0x92/0x4a0
> tty_open+0x8ab/0x1050
> chrdev_open+0x1ec/0x5e0
> do_dentry_open+0x419/0x1260
> vfs_open+0x79/0x350
> path_openat+0x212c/0x3a70
> do_file_open+0x1d2/0x400
> do_sys_openat2+0xdc/0x170
> __x64_sys_openat+0x122/0x1e0
> do_syscall_64+0x64/0x680
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
> </TASK>
>
> Allocated by task 169 on cpu 0 at 3.824684s:
> Freed by task 169 on cpu 0 at 3.892012s:
>
> The buggy address belongs to the object at ffff88800fd44000
> which belongs to the cache kmalloc-1k of size 1024
> The buggy address is located 172 bytes inside of
> freed 1024-byte region [ffff88800fd44000, ffff88800fd44400)
>
> Acquire gsm_mux_lock before reading gsm_mux[] and take the refcount
> via kref_get() while still holding the lock, so the mux cannot be
> freed between lookup and refcount increment.
>
> Fixes: 86176ed90545 ("TTY: n_gsm, use tty_port_install")
> Signed-off-by: Kito Xu (veritas501) <hxzene@gmail.com>
Did you test this change out?
Why was one version sent as "RFC" folllowed by this?
> ---
> drivers/tty/n_gsm.c | 23 ++++++++++++++++-------
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
> index c13e050de83b..6519f1c92fc5 100644
> --- a/drivers/tty/n_gsm.c
> +++ b/drivers/tty/n_gsm.c
> @@ -4288,14 +4288,20 @@ static int gsmtty_install(struct tty_driver *driver, struct tty_struct *tty)
>
> if (mux >= MAX_MUX)
> return -ENXIO;
> - /* FIXME: we need to lock gsm_mux for lifetimes of ttys eventually */
> - if (gsm_mux[mux] == NULL)
> - return -EUNATCH;
> if (line == 0 || line > 61) /* 62/63 reserved */
> return -ECHRNG;
> +
> + /* Acquire gsm_mux_lock to prevent concurrent gsmld_close() from
> + * freeing the mux between reading gsm_mux[] and taking a refcount.
> + */
> + spin_lock(&gsm_mux_lock);
Wrong comment style :(
Also, how was this tested, last time this was attempted, lockups
happened, hence the FIXME line.
And why isn't this the irqsave version of the lock? Why is that not
needed here? Have you searched the email archives for when this was
attempted in the past? What has now changed?
> gsm = gsm_mux[mux];
> - if (gsm->dead)
> - return -EL2HLT;
> + if (!gsm || gsm->dead) {
> + spin_unlock(&gsm_mux_lock);
> + return gsm ? -EL2HLT : -EUNATCH;
Please spell out inline if statements like this.
> + }
> + kref_get(&gsm->ref);
Shouldn't this be mux_get() somehow? Open-coding it like this is
confusing.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH tty v3 6/6] serial: 8250: Add support for console flow control
From: Andy Shevchenko @ 2026-04-20 9:12 UTC (permalink / raw)
To: John Ogness
Cc: Greg Kroah-Hartman, Jiri Slaby, linux-kernel, Ilpo Järvinen,
Ingo Molnar, Osama Abdelkader, Krzysztof Kozlowski,
Gerhard Engleder, Lukas Wunner, Dr. David Alan Gilbert,
Joseph Tilahun, linux-serial
In-Reply-To: <20260417102423.40984-7-john.ogness@linutronix.de>
On Fri, Apr 17, 2026 at 1:24 PM John Ogness <john.ogness@linutronix.de> wrote:
>
> The kernel documentation specifies that the console option 'r' can
> be used to enable hardware flow control for console writes. The 8250
> driver does include code for hardware flow control on the console if
> cons_flow is set, but there is no code path that actually sets this.
> However, that is not the only issue. The problems are:
>
> 1. Specifying the console option 'r' does not lead to cons_flow being
> set.
>
> 2. Even if cons_flow would be set, serial8250_register_8250_port()
> clears it.
>
> 3. When the console option 'r' is specified, uart_set_options()
> attempts to initialize the port for CRTSCTS. However, afterwards
> it does not set the UPSTAT_CTS_ENABLE status bit and therefore on
> boot, uart_cts_enabled() is always false. This policy bit is
> important for console drivers as a criteria if they may poll CTS.
>
> 4. Even though uart_set_options() attempts to initialize the port
> for CRTSCTS, the 8250 set_termios() callback does not enable the
> RTS signal (TIOCM_RTS) and thus the hardware is not properly
> initialized for CTS polling.
>
> 5. Even if modem control was properly setup for CTS polling
> (TIOCM_RTS), uart_configure_port() clears TIOCM_RTS, thus
> breaking CTS polling.
>
> 6. wait_for_xmitr() and serial8250_console_write() use cons_flow
> to decide if CTS polling should occur. However, the condition
> should also include a check that it is not in RS485 mode and
> CRTSCTS is actually enabled in the hardware.
>
> Address all these issues as conservatively as possible by gating them
> behind checks focussed on the user specifying console hardware flow
> control support and the hardware being configured for CTS polling
> at the time of the write to the UART.
>
> Since checking the UPSTAT_CTS_ENABLE status bit is a part of the new
> condition gate, these changes also support runtime termios updates to
> disable/enable CRTSCTS.
...
> struct uart_8250_port *uart;
> + bool cons_flow;
> + /* Preserve specified console flow control. */
> + cons_flow = uart_get_cons_flow(&uart->port);
Sorry for nit-picking, but when I see 'bool' and see a getter, I got
confused. I would rather see getter/setter to be something like
cons_flow = uart_is_cons_flow_enabled(&uart->port);
uart_enable_cons_flow(&uart->port);
uart_disable_cons_flow(&uart->port);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] dt-bindings: qcom: geni-se-qup: Add compatible for Nord SoC
From: Rob Herring (Arm) @ 2026-04-20 8:33 UTC (permalink / raw)
To: Shawn Guo
Cc: Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, linux-serial,
devicetree, linux-arm-msm, Deepti Jaggi, linux-kernel,
Praveen Talari, Bjorn Andersson, Dmitry Baryshkov,
Bartosz Golaszewski
In-Reply-To: <20260420064401.1248833-1-shengchao.guo@oss.qualcomm.com>
On Mon, 20 Apr 2026 14:44:01 +0800, Shawn Guo wrote:
> From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>
> Add compatibles for GENI Serial Engine QUP Wrapper Controller on Nord SoC
> with fallback on SA8255P compatibles.
>
> Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
> .../soc/qcom/qcom,sa8255p-geni-se-qup.yaml | 20 +++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml:77:13: [warning] wrong indentation: expected 14 but found 12 (indentation)
./Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml:80:13: [warning] wrong indentation: expected 14 but found 12 (indentation)
./Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml:83:13: [warning] wrong indentation: expected 14 but found 12 (indentation)
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260420064401.1248833-1-shengchao.guo@oss.qualcomm.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: 答复: [External Mail]Re: [PATCH] sysrq: add optional logging of caller info on /proc/sysrq-trigger write
From: Greg KH @ 2026-04-20 8:05 UTC (permalink / raw)
To: 高翔
Cc: Xiang Gao, jirislaby@kernel.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
In-Reply-To: <e973ea4e812b4aef95bce54732c406d7@xiaomi.com>
On Mon, Apr 20, 2026 at 07:32:45AM +0000, 高翔 wrote:
<snip>
you sent this in html format, which was rejected by the public lists :(
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: optimize max_freq determination
From: Geert Uytterhoeven @ 2026-04-20 7:23 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Greg Kroah-Hartman, Jiri Slaby, Hugo Villeneuve, biju.das.jz,
linux-kernel, linux-serial
In-Reply-To: <20260417193603.3906568-1-hugo@hugovil.com>
Hi Hugo,
On Sat, 18 Apr 2026 at 07:24, Hugo Villeneuve <hugo@hugovil.com> wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Follow example of rsci driver to avoid code duplication and useless
> max_freq search when port->uartclk is set to zero.
>
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Thanks for your patch!
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2711,14 +2711,15 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
> * setup the baud rate generator hardware for us already.
> */
> if (!port->uartclk) {
> - baud = uart_get_baud_rate(port, termios, old, 0, 115200);
> - goto done;
There was no "useless max_freq search", due to this goto?
> + max_freq = 115200;
> + } else {
> + for (i = 0; i < SCI_NUM_CLKS; i++)
> + max_freq = max(max_freq, s->clk_rates[i]);
> +
> + max_freq /= min_sr(s);
> }
>
> - for (i = 0; i < SCI_NUM_CLKS; i++)
> - max_freq = max(max_freq, s->clk_rates[i]);
> -
> - baud = uart_get_baud_rate(port, termios, old, 0, max_freq / min_sr(s));
> + baud = uart_get_baud_rate(port, termios, old, 0, max_freq);
> if (!baud)
> goto done;
>
Due to removing the goto above (for the casual reader: this is the
earlyprintk case, when port->uartclk is zero), the code will now
continue here, calculating transmission parameters and setting best_clk,
and overwriting the register configuration done by the bootloader.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: optimize max_freq determination
From: Geert Uytterhoeven @ 2026-04-20 7:13 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Biju Das, Greg Kroah-Hartman, Jiri Slaby, Hugo Villeneuve,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
In-Reply-To: <20260418103936.a3651d1606db7178fa7ff854@hugovil.com>
Hi Hugo,
On Sat, 18 Apr 2026 at 16:39, Hugo Villeneuve <hugo@hugovil.com> wrote:
> On Sat, 18 Apr 2026 07:12:57 +0000
> Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > > From: Hugo Villeneuve <hugo@hugovil.com>
> > > Follow example of rsci driver to avoid code duplication and useless max_freq search when port->uartclk
> > > is set to zero.
> > >
> > > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > > ---
> > > Cc: biju.das.jz@bp.renesas.com
> > >
> > > Biju: if you want, feel free to pickup this patch when you resubmit your serie for "sh-sci/rsci: Fix
> > > divide by zero and clean up baud rate logic".
> > > ---
> > > drivers/tty/serial/sh-sci.c | 13 +++++++------
> > > 1 file changed, 7 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index
> > > 6c819b6b24258..dcee8b69adab2 100644
> > > --- a/drivers/tty/serial/sh-sci.c
> > > +++ b/drivers/tty/serial/sh-sci.c
> > > @@ -2711,14 +2711,15 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
> > > * setup the baud rate generator hardware for us already.
> > > */
> > > if (!port->uartclk) {
> > > - baud = uart_get_baud_rate(port, termios, old, 0, 115200);
> > > - goto done;
> > > + max_freq = 115200;
> >
> > I have thought about this change. but the below comment made me not to do this change.
> >
> > <snippet from Geert>
> > IIRC, baud == 0 can (only?) happen when using earlyprintk on a non-DT
> > system, where the serial console should just keep on using the settings
> > programmed by the firmware. So any config register writes should
> > be skipped.
> > </snippet>
>
> I think Geert comments referred to the clock (port->uartclk) being zero,
> not the baud (the baud rate cannot be zero)...
I did mean the baud variable being zero.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] dt-bindings: qcom: geni-se-qup: Add compatible for Nord SoC
From: Shawn Guo @ 2026-04-20 6:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Praveen Talari,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-serial, devicetree, linux-arm-msm,
linux-kernel, Shawn Guo
From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Add compatibles for GENI Serial Engine QUP Wrapper Controller on Nord SoC
with fallback on SA8255P compatibles.
Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
.../soc/qcom/qcom,sa8255p-geni-se-qup.yaml | 20 +++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
index 352af3426d34..d73f9edcbbdb 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,sa8255p-geni-se-qup.yaml
@@ -19,7 +19,12 @@ description:
properties:
compatible:
- const: qcom,sa8255p-geni-se-qup
+ oneOf:
+ - enum:
+ - qcom,sa8255p-geni-se-qup
+ - items:
+ - const: qcom,nord-auto-geni-se-qup
+ - const: qcom,sa8255p-geni-se-qup
reg:
description: QUP wrapper common register address and length.
@@ -67,9 +72,16 @@ patternProperties:
properties:
compatible:
- enum:
- - qcom,sa8255p-geni-uart
- - qcom,sa8255p-geni-debug-uart
+ oneOf:
+ - enum:
+ - qcom,sa8255p-geni-uart
+ - qcom,sa8255p-geni-debug-uart
+ - items:
+ - const: qcom,nord-auto-geni-uart
+ - const: qcom,sa8255p-geni-uart
+ - items:
+ - const: qcom,nord-auto-geni-debug-uart
+ - const: qcom,sa8255p-geni-debug-uart
required:
- compatible
--
2.43.0
^ permalink raw reply related
* [PATCH] dt-bindings: serial: Add compatible for Qualcomm Nord SoC
From: Shawn Guo @ 2026-04-20 6:05 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Praveen Talari,
Konrad Dybcio, Dmitry Baryshkov, Bartosz Golaszewski,
Deepti Jaggi, linux-serial, devicetree, linux-arm-msm,
linux-kernel, Shawn Guo
From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Document compatibles for QUP GENI UART controller on Nord SoC with
fallback on SA8255P compatibles.
Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
.../bindings/serial/qcom,sa8255p-geni-uart.yaml | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml b/Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml
index c8f01923cb25..55e73b359f04 100644
--- a/Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/qcom,sa8255p-geni-uart.yaml
@@ -14,9 +14,16 @@ allOf:
properties:
compatible:
- enum:
- - qcom,sa8255p-geni-uart
- - qcom,sa8255p-geni-debug-uart
+ oneOf:
+ - enum:
+ - qcom,sa8255p-geni-uart
+ - qcom,sa8255p-geni-debug-uart
+ - items:
+ - const: qcom,nord-auto-geni-uart
+ - const: qcom,sa8255p-geni-uart
+ - items:
+ - const: qcom,nord-auto-geni-debug-uart
+ - const: qcom,sa8255p-geni-debug-uart
reg:
maxItems: 1
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] riscv: ultrarisc: 8250_dw: support DP1000 uart
From: Jia Wang @ 2026-04-20 5:27 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jia Wang, Ilpo Järvinen, Greg Kroah-Hartman, Jiri Slaby,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-kernel,
linux-serial, linux-riscv, devicetree, Zhang Xincheng
In-Reply-To: <aeHlaTIKm1wl0J0_@ashevche-desk.local>
On 2026-04-17 10:46 +0300, Andy Shevchenko wrote:
> On Fri, Apr 17, 2026 at 03:32:17PM +0800, Jia Wang wrote:
> > On 2026-03-16 13:35 +0200, Andy Shevchenko wrote:
> > > On Mon, Mar 16, 2026 at 02:33:23PM +0800, Jia Wang via B4 Relay wrote:
>
> ...
>
> > > > +#define DW_UART_QUIRK_FIXED_TYPE BIT(6)
> > >
> > > Seems unrequired.
> > >
> > > But to make sure, can you elaborate what's going on here?
> > > What is the reads from UCV and CPR registers?
> >
> > Apologies for the delayed response.
> >
> > Our DW UART implementation on DP1000 does not provide the CPR/UCV capability
> > registers, and reads from both registers always return 0. As a result, the
> > autodetection logic in 8250_dw cannot obtain meaningful capability
> > information.
> >
> > To handle this, the current approach is to skip autodetection and rely on
> > fixed configuration via a quirk.
> >
> > If there is a preferred or more appropriate way to support DW UART instances
> > without CPR/UCV, I would be happy to adjust the implementation based on your
> > suggestions.
>
> Why can't you provide a CPR value via the existing quirk?
>
Thanks for the feedback.
I will switch to using DW_UART_QUIRK_CPR_VALUE in v3.
> --
> With Best Regards,
> Andy Shevchenko
>
>
>
Best Regards,
Jia Wang
^ permalink raw reply
* Re: [GIT PULL] TTY/Serial driver changes for 7.1-rc1
From: pr-tracker-bot @ 2026-04-19 15:54 UTC (permalink / raw)
To: Greg KH
Cc: Linus Torvalds, Jiri Slaby, Andrew Morton, linux-kernel,
linux-serial
In-Reply-To: <aeTena-xiaqaffDG@kroah.com>
The pull request you sent on Sun, 19 Apr 2026 15:54:37 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-7.1-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/73398c2772d04ee656a654c63db85851381cd147
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* [GIT PULL] TTY/Serial driver changes for 7.1-rc1
From: Greg KH @ 2026-04-19 13:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jiri Slaby, Andrew Morton, linux-kernel, linux-serial
The following changes since commit c369299895a591d96745d6492d4888259b004a9e:
Linux 7.0-rc5 (2026-03-22 14:42:17 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-7.1-rc1
for you to fetch changes up to a1a81aef99e853dec84241d701fbf587d713eb5b:
tty: serial: ip22zilog: Fix section mispatch warning (2026-04-02 15:59:56 +0200)
----------------------------------------------------------------
TTY/Serial changes for 7.1-rc1
Here is the set of tty and serial driver changes for 7.1-rc1.
Not much here this cycle, biggest thing is the removal of an old driver
that never got any actual hardware support (esp32), and the second try
to moving the tty ports to their own workqueues (first try was in
7.0-rc1 but was reverted due to problems.)
Otherwise it's just a small set of driver updates and some vt modifier
key enhancements.
All have been in linux-next for a while with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Alyssa Milburn (1):
tty: serial: samsung_tty: avoid dev_dbg deadlock
Andy Shevchenko (2):
serial: 8250_port: Drop duplicate NULL check
serial: xilinx_uartps: Drop unused include
Anup Kulkarni (1):
serial: qcom-geni: Fix RTS behavior with flow control
Biju Das (2):
dt-bindings: serial: renesas,rsci: Document RZ/G3L SoC
serial: sh-sci: Add support for RZ/G3L RSCI
Brian Masney (1):
serial: pic32_uart: allow driver to be compiled on all architectures with COMPILE_TEST
Fabio Estevam (1):
dt-bindings: serial: snps-dw-apb-uart: Add RV1103B compatible
Francesco Lavra (1):
serial: tegra: remove Kconfig dependency on APB DMA controller
Greg Kroah-Hartman (1):
Merge 7.0-rc5 into tty-next
Jason Andryuk (1):
hvc/xen: Check console connection flag
Julian Braha (1):
serial: remove drivers for espressif esp32
Kartik Rajput (4):
serial: amba-pl011: Introduce skip_ibrd_fbrd vendor flag
serial: amba-pl011: Introduce set_uartclk_rate vendor flag
serial: amba-pl011: Add Tegra264 UART support
serial: amba-pl011: Respect DMA controller's copy_align requirement
Kathiravan Thirumoorthy (1):
serial: qcom-geni: drop stray newline format specifier
Kexin Sun (1):
tty: atmel_serial: update outdated reference to atmel_tasklet_func()
Michael Walle (1):
tty: serial: 8250: Add SystemBase Multi I/O cards
Nicolas Pitre (3):
vt: add modifier support to cursor keys
vt: add KT_CSI keysym type for modifier-aware CSI sequences
vt: add fallback to plain map for modifier-aware key types
Peter Maydell (1):
serial: amba-pl011: Enable UART in earlycon setup
Qingfang Deng (1):
tty: constify tty_ldisc_ops
Randy Dunlap (2):
tty: hvc_iucv: fix off-by-one in number of supported devices
serdev: serdev.h: clean up kernel-doc comments
Ravi Rama (1):
serial: 8250_fintek: Add support for F81214E
Robert Marko (1):
dt-bindings: serial: atmel,at91-usart: add microchip,lan9691-usart
Robin Gong (1):
tty: serial: imx: keep dma request disabled before dma transfer setup
Ronan Pigott (1):
vt: support ITU-T T.416 color subparameters
Rong Zhang (2):
dt-bindings: serial: 8250: Add Loongson 3A4000 uart compatible
serial: 8250: loongson: Enable building on MIPS Loongson64
Thomas Bogendoerfer (1):
tty: serial: ip22zilog: Fix section mispatch warning
Xianwei Zhao (1):
dt-bindings: serial: amlogic,meson-uart: Add compatible string for A9
Xin Zhao (1):
tty: tty_port: add workqueue to flip TTY buffer
Zhaoyang Yu (1):
serial: auart: check clk_enable() return in console write
Documentation/devicetree/bindings/serial/8250.yaml | 1 +
.../bindings/serial/amlogic,meson-uart.yaml | 1 +
.../bindings/serial/atmel,at91-usart.yaml | 1 +
.../devicetree/bindings/serial/renesas,rsci.yaml | 26 +
.../bindings/serial/snps-dw-apb-uart.yaml | 1 +
drivers/tty/hvc/hvc_iucv.c | 2 +-
drivers/tty/hvc/hvc_xen.c | 3 +
drivers/tty/pty.c | 12 +-
drivers/tty/serial/8250/8250_core.c | 2 +-
drivers/tty/serial/8250/8250_fintek.c | 10 +-
drivers/tty/serial/8250/8250_pci.c | 51 ++
drivers/tty/serial/8250/8250_port.c | 4 +-
drivers/tty/serial/8250/Kconfig | 9 +-
drivers/tty/serial/Kconfig | 33 +-
drivers/tty/serial/Makefile | 2 -
drivers/tty/serial/amba-pl011.c | 153 +++-
drivers/tty/serial/apbuart.c | 2 +-
drivers/tty/serial/atmel_serial.c | 2 +-
drivers/tty/serial/dz.c | 2 +-
drivers/tty/serial/esp32_acm.c | 459 ------------
drivers/tty/serial/esp32_uart.c | 779 ---------------------
drivers/tty/serial/imx.c | 7 +-
drivers/tty/serial/ip22zilog.c | 4 +-
drivers/tty/serial/mxs-auart.c | 3 +-
drivers/tty/serial/qcom_geni_serial.c | 21 +-
drivers/tty/serial/rsci.c | 13 +
drivers/tty/serial/rsci.h | 1 +
drivers/tty/serial/samsung_tty.c | 10 +-
drivers/tty/serial/sh-sci-common.h | 1 +
drivers/tty/serial/sh-sci.c | 14 +-
drivers/tty/serial/xilinx_uartps.c | 1 -
drivers/tty/serial/zs.c | 2 +-
drivers/tty/tty_buffer.c | 15 +-
drivers/tty/tty_io.c | 25 +-
drivers/tty/tty_ldisc.c | 16 +-
drivers/tty/tty_port.c | 22 +
drivers/tty/vt/keyboard.c | 80 ++-
drivers/tty/vt/vt.c | 48 +-
include/linux/serdev.h | 9 +-
include/linux/tty_buffer.h | 1 +
include/linux/tty_driver.h | 7 +
include/linux/tty_ldisc.h | 6 +-
include/linux/tty_port.h | 13 +
include/uapi/linux/keyboard.h | 29 +
include/xen/interface/io/console.h | 13 +
45 files changed, 550 insertions(+), 1366 deletions(-)
delete mode 100644 drivers/tty/serial/esp32_acm.c
delete mode 100644 drivers/tty/serial/esp32_uart.c
^ permalink raw reply
* Re: [PATCH v4 2/8] dt-bindings: arm: Add zx297520v3 board binding
From: Stefan Dösinger @ 2026-04-19 8:30 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: linux-kernel, Conor Dooley, Jonathan Corbet, Alexandre Belloni,
Greg Kroah-Hartman, linux-doc, devicetree, Drew Fustini,
Linus Walleij, Jiri Slaby, Russell King, soc, Arnd Bergmann,
Krzysztof Kozlowski, Krzysztof Kozlowski, linux-arm-kernel,
linux-serial, Shuah Khan
In-Reply-To: <177646012448.2165534.5760108355183774935.robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]
Hi Rob,
Am Samstag, 18. April 2026, 00:08:44 Ostafrikanische Zeit schrieben Sie:
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
Here is a new PEBKAC issue for your mail template: I ran dt_binding_check, it
wrote the warning you pointed out, but I only checked the return value - which
indicated success. Which I guess makes sense for a warning, since there seem
to be a few preexisting ones. The warning itself was somewhere in the
scrollback because I let dt_binding_check check all the files.
So I learned I have to actually look at the output to see if there are any
warnings.
Cheers,
Stefan
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: optimize max_freq determination
From: Hugo Villeneuve @ 2026-04-18 14:39 UTC (permalink / raw)
To: Biju Das
Cc: Greg Kroah-Hartman, Jiri Slaby, Geert Uytterhoeven,
Hugo Villeneuve, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org
In-Reply-To: <TY3PR01MB1134667FC9A3920ADC444C21A86212@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Hi Biju,
On Sat, 18 Apr 2026 07:12:57 +0000
Biju Das <biju.das.jz@bp.renesas.com> wrote:
> Hi Hugo,
>
> > -----Original Message-----
> > From: Hugo Villeneuve <hugo@hugovil.com>
> > Sent: 17 April 2026 20:36
> > Subject: [PATCH] serial: sh-sci: optimize max_freq determination
> >
> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >
> > Follow example of rsci driver to avoid code duplication and useless max_freq search when port->uartclk
> > is set to zero.
> >
> > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > ---
> > Cc: biju.das.jz@bp.renesas.com
> >
> > Biju: if you want, feel free to pickup this patch when you resubmit your serie for "sh-sci/rsci: Fix
> > divide by zero and clean up baud rate logic".
> > ---
> > drivers/tty/serial/sh-sci.c | 13 +++++++------
> > 1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index
> > 6c819b6b24258..dcee8b69adab2 100644
> > --- a/drivers/tty/serial/sh-sci.c
> > +++ b/drivers/tty/serial/sh-sci.c
> > @@ -2711,14 +2711,15 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
> > * setup the baud rate generator hardware for us already.
> > */
> > if (!port->uartclk) {
> > - baud = uart_get_baud_rate(port, termios, old, 0, 115200);
> > - goto done;
> > + max_freq = 115200;
>
> I have thought about this change. but the below comment made me not to do this change.
>
> <snippet from Geert>
> IIRC, baud == 0 can (only?) happen when using earlyprintk on a non-DT
> system, where the serial console should just keep on using the settings
> programmed by the firmware. So any config register writes should
> be skipped.
> </snippet>
I think Geert comments referred to the clock (port->uartclk) being zero,
not the baud (the baud rate cannot be zero)...
But I am not sure how it is relevant here because the modification is
not changing the behavior of the existing code, it is an optimization
and a simplification. In fact, it is exactly the change I proposed [1]
when you submitted the rsci driver (and yoyu accepted), unless I am
missing something?
[1]
https://lore.kernel.org/all/20251028112236.c832fb48ad9fafcd2cf34b57@hugovil.com/
The goal of this patch is to have both rsci and sh-sci code to be the
same for this specific section at least. If you modify it to take into
account Geert's comments, then It think you need to do it both for rsci
and sh-sci drivers, no?
>
> Cheers,
> Biju
>
> > + } else {
> > + for (i = 0; i < SCI_NUM_CLKS; i++)
> > + max_freq = max(max_freq, s->clk_rates[i]);
> > +
> > + max_freq /= min_sr(s);
> > }
> >
> > - for (i = 0; i < SCI_NUM_CLKS; i++)
> > - max_freq = max(max_freq, s->clk_rates[i]);
> > -
> > - baud = uart_get_baud_rate(port, termios, old, 0, max_freq / min_sr(s));
> > + baud = uart_get_baud_rate(port, termios, old, 0, max_freq);
> > if (!baud)
> > goto done;
> >
> >
> > base-commit: a1a81aef99e853dec84241d701fbf587d713eb5b
> > --
> > 2.47.3
>
>
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH] sysrq: add optional logging of caller info on /proc/sysrq-trigger write
From: Greg KH @ 2026-04-18 7:20 UTC (permalink / raw)
To: Xiang Gao; +Cc: jirislaby, akpm, linux-kernel, linux-serial, Xiang Gao
In-Reply-To: <20260416131419.1231012-1-gxxa03070307@gmail.com>
On Thu, Apr 16, 2026 at 09:14:19PM +0800, Xiang Gao wrote:
> From: Xiang Gao <gaoxiang17@xiaomi.com>
>
> When /proc/sysrq-trigger is written to, there is no record of which
> process triggered the sysrq operation. This makes it difficult to audit
> or debug who initiated a sysrq action, especially when the write comes
> from a shell spawned by system()/popen() where the immediate caller is
> "sh" rather than the originating application.
>
> Add CONFIG_MAGIC_SYSRQ_TRIGGER_LOG (default n) and a runtime toggle via
> module parameter sysrq.trigger_log (default off). When both are enabled,
> the kernel logs the triggering process's comm, pid, tgid, uid, and walks
> up to 5 levels of the parent process chain. This allows tracing the
> original initiator even through system()/popen()/fork+exec indirection.
>
> Example output:
> sysrq: proc trigger: comm=sh pid=68 tgid=68 uid=0
> sysrq: parent[0]: comm=my_app pid=67 tgid=67
> sysrq: parent[1]: comm=init pid=1 tgid=1
>
> Usage:
> # Compile-time: enable CONFIG_MAGIC_SYSRQ_TRIGGER_LOG=y
> # Runtime: echo 1 > /sys/module/sysrq/parameters/trigger_log
> # Or boot parameter: sysrq.trigger_log=1
>
> Signed-off-by: Xiang Gao <gaoxiang17@xiaomi.com>
> ---
> drivers/tty/sysrq.c | 29 +++++++++++++++++++++++++++++
> lib/Kconfig.debug | 16 ++++++++++++++++
> 2 files changed, 45 insertions(+)
>
> diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
> index c2e4b31b699a..e9277e7de35b 100644
> --- a/drivers/tty/sysrq.c
> +++ b/drivers/tty/sysrq.c
> @@ -48,6 +48,9 @@
> #include <linux/uaccess.h>
> #include <linux/moduleparam.h>
> #include <linux/jiffies.h>
> +#ifdef CONFIG_MAGIC_SYSRQ_TRIGGER_LOG
> +#include <linux/cred.h>
> +#endif
We really do not want or like #ifdef in .c files, and for stuff like
this, it is not needed at all.
> #include <linux/syscalls.h>
> #include <linux/of.h>
> #include <linux/rcupdate.h>
> @@ -59,6 +62,12 @@
> static int __read_mostly sysrq_enabled = CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE;
> static bool __read_mostly sysrq_always_enabled;
>
> +#ifdef CONFIG_MAGIC_SYSRQ_TRIGGER_LOG
> +static bool sysrq_trigger_log;
> +module_param_named(trigger_log, sysrq_trigger_log, bool, 0644);
> +MODULE_PARM_DESC(trigger_log, "Log caller info on /proc/sysrq-trigger write");
> +#endif
Module parameters are really not the way for stuff like this. And why
would such a "tiny" option need a config option at all? If you don't
use/need it, it's only a single bool being used?
> +
> static bool sysrq_on(void)
> {
> return sysrq_enabled || sysrq_always_enabled;
> @@ -1209,6 +1218,26 @@ static ssize_t write_sysrq_trigger(struct file *file, const char __user *buf,
> bool bulk = false;
> size_t i;
>
> +#ifdef CONFIG_MAGIC_SYSRQ_TRIGGER_LOG
> + if (sysrq_trigger_log) {
> + struct task_struct *task;
> + int depth = 0;
> +
> + pr_info("proc trigger: comm=%s pid=%d tgid=%d uid=%u\n",
> + current->comm, current->pid, current->tgid,
> + from_kuid(&init_user_ns, current_uid()));
The kernel log is not there for doing audits and the like, so is this
just a debug option?
> +
> + rcu_read_lock();
> + task = current;
> + while (task->pid > 1 && depth < 5) {
> + task = rcu_dereference(task->real_parent);
> + pr_info(" parent[%d]: comm=%s pid=%d tgid=%d\n",
> + depth++, task->comm, task->pid, task->tgid);
> + }
> + rcu_read_unlock();
This might cause problems for when the system is hung and sysrq is the
only way to reboot the box. Have you tried it in that situation?
> + }
> +#endif
> +
> for (i = 0; i < count; i++) {
> char c;
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index aac60b6cfa4b..46bd361decd0 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -705,6 +705,22 @@ config MAGIC_SYSRQ_SERIAL_SEQUENCE
>
> If unsure, leave an empty string and the option will not be enabled.
>
> +config MAGIC_SYSRQ_TRIGGER_LOG
> + bool "Log caller info on /proc/sysrq-trigger write"
> + depends on MAGIC_SYSRQ
> + default n
n is always the default, no need to add it again.
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH] serial: sh-sci: optimize max_freq determination
From: Biju Das @ 2026-04-18 7:12 UTC (permalink / raw)
To: Hugo Villeneuve, Greg Kroah-Hartman, Jiri Slaby,
Geert Uytterhoeven
Cc: Hugo Villeneuve, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org
In-Reply-To: <20260417193603.3906568-1-hugo@hugovil.com>
Hi Hugo,
> -----Original Message-----
> From: Hugo Villeneuve <hugo@hugovil.com>
> Sent: 17 April 2026 20:36
> Subject: [PATCH] serial: sh-sci: optimize max_freq determination
>
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Follow example of rsci driver to avoid code duplication and useless max_freq search when port->uartclk
> is set to zero.
>
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> ---
> Cc: biju.das.jz@bp.renesas.com
>
> Biju: if you want, feel free to pickup this patch when you resubmit your serie for "sh-sci/rsci: Fix
> divide by zero and clean up baud rate logic".
> ---
> drivers/tty/serial/sh-sci.c | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index
> 6c819b6b24258..dcee8b69adab2 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2711,14 +2711,15 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
> * setup the baud rate generator hardware for us already.
> */
> if (!port->uartclk) {
> - baud = uart_get_baud_rate(port, termios, old, 0, 115200);
> - goto done;
> + max_freq = 115200;
I have thought about this change. but the below comment made me not to do this change.
<snippet from Geert>
IIRC, baud == 0 can (only?) happen when using earlyprintk on a non-DT
system, where the serial console should just keep on using the settings
programmed by the firmware. So any config register writes should
be skipped.
</snippet>
Cheers,
Biju
> + } else {
> + for (i = 0; i < SCI_NUM_CLKS; i++)
> + max_freq = max(max_freq, s->clk_rates[i]);
> +
> + max_freq /= min_sr(s);
> }
>
> - for (i = 0; i < SCI_NUM_CLKS; i++)
> - max_freq = max(max_freq, s->clk_rates[i]);
> -
> - baud = uart_get_baud_rate(port, termios, old, 0, max_freq / min_sr(s));
> + baud = uart_get_baud_rate(port, termios, old, 0, max_freq);
> if (!baud)
> goto done;
>
>
> base-commit: a1a81aef99e853dec84241d701fbf587d713eb5b
> --
> 2.47.3
^ permalink raw reply
* Re: [PATCH v4 2/8] dt-bindings: arm: Add zx297520v3 board binding
From: Rob Herring (Arm) @ 2026-04-17 21:08 UTC (permalink / raw)
To: Stefan Dösinger
Cc: linux-kernel, Conor Dooley, Jonathan Corbet, Alexandre Belloni,
Greg Kroah-Hartman, linux-doc, devicetree, Drew Fustini,
Linus Walleij, Jiri Slaby, Russell King, soc, Arnd Bergmann,
Krzysztof Kozlowski, Krzysztof Kozlowski, linux-arm-kernel,
linux-serial, Shuah Khan
In-Reply-To: <20260416-send-v4-2-e19d02b944ec@gmail.com>
On Thu, 16 Apr 2026 23:19:10 +0300, Stefan Dösinger wrote:
> Add a compatible for boards based on the ZTE zx297520v3 SoC.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>
> ---
>
> The list of devices is the devices I have access to for testing. There
> are many more devices based on this board and it is not always easy to
> identify them. Often they are sold without any branding ("4G home
> router") or with mobile carrier branding.
> ---
> Documentation/devicetree/bindings/arm/zte.yaml | 25 +++++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 26 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
./Documentation/devicetree/bindings/arm/zte.yaml:19:13: [warning] wrong indentation: expected 14 but found 12 (indentation)
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260416-send-v4-2-e19d02b944ec@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* [PATCH] serial: sh-sci: optimize max_freq determination
From: Hugo Villeneuve @ 2026-04-17 19:35 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, Hugo Villeneuve, biju.das.jz, linux-kernel, linux-serial
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Follow example of rsci driver to avoid code duplication and useless
max_freq search when port->uartclk is set to zero.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
Cc: biju.das.jz@bp.renesas.com
Biju: if you want, feel free to pickup this patch when you resubmit your
serie for "sh-sci/rsci: Fix divide by zero and clean up baud rate logic".
---
drivers/tty/serial/sh-sci.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 6c819b6b24258..dcee8b69adab2 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2711,14 +2711,15 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
* setup the baud rate generator hardware for us already.
*/
if (!port->uartclk) {
- baud = uart_get_baud_rate(port, termios, old, 0, 115200);
- goto done;
+ max_freq = 115200;
+ } else {
+ for (i = 0; i < SCI_NUM_CLKS; i++)
+ max_freq = max(max_freq, s->clk_rates[i]);
+
+ max_freq /= min_sr(s);
}
- for (i = 0; i < SCI_NUM_CLKS; i++)
- max_freq = max(max_freq, s->clk_rates[i]);
-
- baud = uart_get_baud_rate(port, termios, old, 0, max_freq / min_sr(s));
+ baud = uart_get_baud_rate(port, termios, old, 0, max_freq);
if (!baud)
goto done;
base-commit: a1a81aef99e853dec84241d701fbf587d713eb5b
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v4 7/8] ARM: dts: Declare UART1 on zx297520v3 boards
From: Stefan Dösinger @ 2026-04-17 17:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krzysztof Kozlowski,
Alexandre Belloni, Linus Walleij, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <0d80dcbe-cb46-45e5-821a-de5299d6a663@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 2283 bytes --]
Hi Arnd,
Thanks for your comments.
> Am 17.04.2026 um 11:59 schrieb Arnd Bergmann <arnd@arndb.de>:
>
> On Thu, Apr 16, 2026, at 22:19, Stefan Dösinger wrote:
>>
>> The reason why I add the serial1=uart1 alias is to keep console=ttyAMA1
>> stable regardless of the other enabled UARTs. UART0, as the name
>> implies, has a lower MMIO address, but uart1 is the one that usually has
>> the boot output and console.
>
> I'm not sure I'm following here. You generally want to either make
> sure the alias matches whatever number is printed on the product
> if there are multiple numbered ports, or you just use 'serial0'
> as the only alias if there is only one port.
Not all boards have their uart pins labeled, but those that do have the pins that connect to the UART at 0x01408000 named UART1RX/UART1TX. Most boards have only one though. I have seen a picture of only one that has UART0 and UART1. I could not test that board myself yet.
My original reason is one of developer convenience: If I have
uart0=serial@131000{
reg = <0x00131000 0x1000>;
...
status = "disabled";
};
uart1=serial@1408000{
reg = <0x01408000 0x1000>;
...
status = "okay";
};
cmdline="... console=ttyAMA{0/1} ..."
changing uart0.status between disabled and okay (e.g. to experiment with uart0 and pinctrl) required changing the command line to match. I found that pretty annoying and the aliases seemed like the best way to avoid this.
Either way I am open to do whatever. I can keep the current naming for the reasons stated above, I can name serial@1408000 "uart0" and leave the others without an alias or I can drop the alias altogether.
> Either way, the alias should go into the board specific file, not
> the general SoC file, as a board might be using a different
> set of UARTs.
That works for me, I'll move them. The aliases will most likely be the same for all boards based on this chipset, meaning duplicate code, but matching the alias to the board labels makes sense to me.
> Since you know the addresses of the other uart instances, I would
> suggest you add all of them at the same time.
Will do.
I'll hold off for a bit before I resend the patches to see if some other comments come up.
Cheers,
Stefan
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 01/10] serial: max310x: uniformize clock/freq types
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260417-max310x-2-v1-0-b424e105ecac@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
max310x_set_ref_clk() returns a 32-bits clock value, so there is no need
to have parameters and intermediate values defined as long. Change
clock and freq types to int.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
drivers/tty/serial/max310x.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index ac7d3f197c3a5ce3531d5607f48e21a807314021..7c1c3696f5684d6dcaf1149e54bfa96c202c7b26 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -545,7 +545,7 @@ static int max310x_set_baud(struct uart_port *port, int baud)
return (16*port->uartclk) / (c*(16*div + frac));
}
-static int max310x_update_best_err(unsigned long f, long *besterr)
+static int max310x_update_best_err(unsigned int f, long *besterr)
{
/* Use baudrate 115200 for calculate error */
long err = f % (460800 * 16);
@@ -559,11 +559,11 @@ static int max310x_update_best_err(unsigned long f, long *besterr)
}
static s32 max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
- unsigned long freq, bool xtal)
+ unsigned int freq, bool xtal)
{
unsigned int div, clksrc, pllcfg = 0;
long besterr = -1;
- unsigned long fdiv, fmul, bestfreq = freq;
+ unsigned int fdiv, fmul, bestfreq = freq;
/* First, update error without PLL */
max310x_update_best_err(freq, &besterr);
@@ -1268,7 +1268,8 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
const struct max310x_if_cfg *if_cfg,
struct regmap *regmaps[], int irq)
{
- int i, ret, fmin, fmax, freq;
+ unsigned int fmin, fmax, freq;
+ int i, ret;
struct max310x_port *s;
s32 uartclk = 0;
bool xtal;
--
2.47.3
^ permalink raw reply related
* [PATCH 00/10] serial: max310x: improvements and cleanups
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
Hello,
this patch series brings a few improvements and cleanups to the max310x
driver.
Note that I do not have access to a board with an actual max310x IC on it,
but I have tested it by using i2c-stub to simulate the four ports on a
virtual max14830 device.
Tests for patch "serial: max310x: use regmap_read_poll_timeout() for busy
wait":
Tested by setting the initial register values to 0x00, then loading the
driver with a (temporary) modified delay of 10s and using i2c-stub
to set register values to 0x01 after 5 seconds. Also tested by leaving
register to 0x00 and confirming the timout is properly handled.
Tests for reference clock computations:
Tested all possible frequencies from 5KHz to 35MHz in 1z increment
(osc mode) and comparing the resulting reference clock between the original
code and the new one, again using i2c-stub.
Thank you.
---
Hugo Villeneuve (10):
serial: max310x: uniformize clock/freq types
serial: max310x: simplify max310x_update_best_err()
serial: max310x: change return type of max310x_set_ref_clk()
serial: max310x: update baudrate comments for err calculation
serial: max310x: improve max310x_set_ref_clk() efficiency
serial: max310x: use regmap_read_poll_timeout() for busy wait
serial: max310x: use FIELD_PREP macro to set PLL bitfields
serial: max310x: allow driver to be built with SPI or I2C
serial: max310x: move variables to while() scope
serial: max310x: add comments for PLL limits
drivers/tty/serial/Kconfig | 2 +-
drivers/tty/serial/max310x.c | 179 ++++++++++++++++++++++++-------------------
2 files changed, 103 insertions(+), 78 deletions(-)
---
base-commit: a1a81aef99e853dec84241d701fbf587d713eb5b
change-id: 20260417-max310x-2-965fe921aea6
Best regards,
--
Hugo Villeneuve <hvilleneuve@dimonoff.com>
^ permalink raw reply
* [PATCH 02/10] serial: max310x: simplify max310x_update_best_err()
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260417-max310x-2-v1-0-b424e105ecac@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
besterr was defined as a signed type was to make sure that the first call
to max310x_update_best_err() would always set besterr. Also there is no
need for it to be a long. By changing its type to unsigned int and initial
value to UINT_MAX, max310x_update_best_err() can be simplified and be more
efficient while achieving the same initial result.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
drivers/tty/serial/max310x.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index 7c1c3696f5684d6dcaf1149e54bfa96c202c7b26..b68a17ebd10b84fa2ecfc521efa454cb248f90b5 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -545,12 +545,12 @@ static int max310x_set_baud(struct uart_port *port, int baud)
return (16*port->uartclk) / (c*(16*div + frac));
}
-static int max310x_update_best_err(unsigned int f, long *besterr)
+static int max310x_update_best_err(unsigned int f, unsigned int *besterr)
{
/* Use baudrate 115200 for calculate error */
- long err = f % (460800 * 16);
+ unsigned int err = f % (460800 * 16);
- if ((*besterr < 0) || (*besterr > err)) {
+ if (*besterr > err) {
*besterr = err;
return 0;
}
@@ -562,7 +562,7 @@ static s32 max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
unsigned int freq, bool xtal)
{
unsigned int div, clksrc, pllcfg = 0;
- long besterr = -1;
+ unsigned int besterr = UINT_MAX;
unsigned int fdiv, fmul, bestfreq = freq;
/* First, update error without PLL */
--
2.47.3
^ permalink raw reply related
* [PATCH 04/10] serial: max310x: update baudrate comments for err calculation
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260417-max310x-2-v1-0-b424e105ecac@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
The baudrate used to compute the best error was changed from 115200 to
460800 in commit 35240ba26a93 ("tty: max310x: Fix invalid baudrate
divisors calculator"), but the comment was not updated, so fix it.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
drivers/tty/serial/max310x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index cf27e597ea41541331c8786fe4b4ded39b53d291..f689958736f71b15b7c113214cda60db4aa7c593 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -547,7 +547,7 @@ static int max310x_set_baud(struct uart_port *port, int baud)
static int max310x_update_best_err(unsigned int f, unsigned int *besterr)
{
- /* Use baudrate 115200 for calculate error */
+ /* Use high-enough baudrate to calculate error */
unsigned int err = f % (460800 * 16);
if (*besterr > err) {
--
2.47.3
^ permalink raw reply related
* [PATCH 03/10] serial: max310x: change return type of max310x_set_ref_clk()
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260417-max310x-2-v1-0-b424e105ecac@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Having max310x_set_ref_clk() return an s32 as both an error code
and a frequency value is ambiguous. Fix by passing a pointer to the
frequency value that will then be updated, and simply return a status.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
drivers/tty/serial/max310x.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index b68a17ebd10b84fa2ecfc521efa454cb248f90b5..cf27e597ea41541331c8786fe4b4ded39b53d291 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -558,8 +558,8 @@ static int max310x_update_best_err(unsigned int f, unsigned int *besterr)
return 1;
}
-static s32 max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
- unsigned int freq, bool xtal)
+static int max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
+ unsigned int freq, unsigned int *fref, bool xtal)
{
unsigned int div, clksrc, pllcfg = 0;
unsigned int besterr = UINT_MAX;
@@ -632,7 +632,9 @@ static s32 max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
"clock is not stable\n");
}
- return bestfreq;
+ *fref = bestfreq;
+
+ return 0;
}
static void max310x_batch_write(struct uart_port *port, u8 *txbuf, unsigned int len)
@@ -1271,7 +1273,7 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
unsigned int fmin, fmax, freq;
int i, ret;
struct max310x_port *s;
- s32 uartclk = 0;
+ unsigned int uartclk = 0;
bool xtal;
for (i = 0; i < devtype->nr; i++)
@@ -1357,11 +1359,9 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
regmap_write(regmaps[i], MAX310X_MODE1_REG, devtype->mode1);
}
- uartclk = max310x_set_ref_clk(dev, s, freq, xtal);
- if (uartclk < 0) {
- ret = uartclk;
+ ret = max310x_set_ref_clk(dev, s, freq, &uartclk, xtal);
+ if (ret < 0)
goto out_uart;
- }
dev_dbg(dev, "Reference clock set to %i Hz\n", uartclk);
--
2.47.3
^ permalink raw reply related
* [PATCH 10/10] serial: max310x: add comments for PLL limits
From: Hugo Villeneuve @ 2026-04-17 14:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: hugo, linux-kernel, linux-serial, Hugo Villeneuve
In-Reply-To: <20260417-max310x-2-v1-0-b424e105ecac@dimonoff.com>
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Add comments to help clarify the provenance of the various hardcoded values
used in computing the ref clk.
Assisted-by: Gemini:Pro
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
drivers/tty/serial/max310x.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index 748306d1a9329694e90ec4f096dd00e39d457fda..9f423b3b4201d0db07bbd7b15934db36249e7620 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -585,6 +585,23 @@ static u8 max310x_pll_mult_to_id(u8 pll_mult)
}
}
+/*
+ * From table 7 in datasheet: PLLFactor Selector Guide
+ *
+ * +-----------+----------------+-------------------+-------------------+
+ * | PLLFactor | MULTIPLICATION | fPLLIN | fREF |
+ * | (1 & 0) | FACTOR +---------+---------+---------+---------+
+ * | | | MIN | MAX | MIN | MAX |
+ * +-----------+----------------+---------+---------+---------+---------+
+ * | 0 | 6 | 500kHz | 800kHz | 3MHz | 4.8MHz |
+ * +-----------+----------------+---------+---------+---------+---------+
+ * | 1 | 48 | 850kHz | 1.2MHz | 40.8MHz | 56MHz |
+ * +-----------+----------------+---------+---------+---------+---------+
+ * | 2 | 96 | 425kHz | 1MHz | 40.8MHz | 96MHz |
+ * +-----------+----------------+---------+---------+---------+---------+
+ * | 3 | 144 | 390kHz | 667kHz | 56MHz | 96MHz |
+ * +-----------+----------------+---------+---------+---------+---------+
+ */
static int max310x_set_ref_clk(struct device *dev, struct max310x_port *s,
unsigned int freq, unsigned int *fref, bool xtal)
{
--
2.47.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox