* [REPORT] serial: 8250: BREAK + SysRq dispatch silently broken since 8324a54f604d
From: Jacques Nilo @ 2026-05-12 12:38 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-serial, linux-kernel, Ilpo Järvinen, Johan Hovold
Hi,
We hit what looks like a silent SysRq-over-serial regression on a 6.18
build of the 8250 driver. Posting as a report rather than a patch because
there are at least two reasonable fixes and I'd like a maintainer call
before sending one.
Symptom
=======
CONFIG_MAGIC_SYSRQ=y, CONFIG_MAGIC_SYSRQ_SERIAL=y,
CONFIG_SERIAL_8250_CONSOLE=y.
A BREAK followed by a SysRq key on the console UART is consumed by the
kernel (BREAK counter in /proc/tty/driver/serial increments correctly)
but is never dispatched to handle_sysrq(). dmesg shows no "sysrq: ..."
line.
`echo h > /proc/sysrq-trigger` still works, isolating the regression to
the serial input path. Verified end-to-end on an RTL8196E MIPS board
running 6.18.24; the affected code is in the generic 8250 core, so the
issue is not platform-specific.
Path
====
serial8250_default_handle_irq()
-> serial8250_handle_irq() [8250_port.c:1835]
guard(uart_port_lock_irqsave)(port); [8250_port.c:1840]
serial8250_handle_irq_locked()
-> serial8250_rx_chars()
-> serial8250_read_char()
-> uart_handle_break() -- arms port->sysrq
-> uart_prepare_sysrq_char(port, ch) -- captures
sysrq_ch
/* guard scope ends -> port unlock */
The captured port->sysrq_ch is dispatched to handle_sysrq() at unlock
time -- but only by uart_unlock_and_check_sysrq[_irqrestore]() (see
include/linux/serial_core.h:1239). The scope guard's destructor at
serial_core.h:797 is plain uart_port_unlock_irqrestore(), which skips
the dispatch:
DEFINE_LOCK_GUARD_1(uart_port_lock_irqsave, struct uart_port,
uart_port_lock_irqsave(_T->lock, &_T->flags),
uart_port_unlock_irqrestore(_T->lock, _T->flags),
unsigned long flags);
So sysrq_ch stays in the struct until the next BREAK clears it.
Bisection
=========
commit 8324a54f604d ("serial: 8250: Add serial8250_handle_irq_locked()")
Pre-split serial8250_handle_irq() used explicit uart_port_lock_irqsave()
+ uart_unlock_and_check_sysrq_irqrestore(). The split moved the body into
_locked() and replaced the explicit lock pair with
guard(uart_port_lock_irqsave), losing the sysrq-aware unlock.
This was the very condition Johan Hovold's 853a9ae29e978 ("serial: 8250:
fix handle_irq locking", 2021) introduced
uart_unlock_and_check_sysrq_irqrestore() to address -- the new helper was
deliberately the sysrq-aware variant. The guard() conversion undoes that
intent.
Reproducer
==========
On any 8250-driven console with CONFIG_MAGIC_SYSRQ_SERIAL=y:
# On the host side:
python3 -c 'import os,fcntl,termios,time
fd=os.open("/dev/ttyUSB0",os.O_RDWR|os.O_NOCTTY)
fcntl.ioctl(fd,0x5427); time.sleep(0.3); fcntl.ioctl(fd,0x5428)
time.sleep(0.05); os.write(fd,b"h"); time.sleep(0.3)'
# On the gateway:
grep brk /proc/tty/driver/serial # counter increments
dmesg | grep sysrq: # empty -- no dispatch
Two ways to fix
===============
Option A -- surgical, only fix serial8250_handle_irq():
int serial8250_handle_irq(struct uart_port *port, unsigned int iir)
{
unsigned long flags;
if (iir & UART_IIR_NO_INT)
return 0;
uart_port_lock_irqsave(port, &flags);
serial8250_handle_irq_locked(port, iir);
uart_unlock_and_check_sysrq_irqrestore(port, flags);
return 1;
}
Restores the pre-split behaviour. Doesn't touch the guard infrastructure.
Drawback: leaves uart_port_lock_irqsave() as a generic primitive that
silently swallows pending sysrq_ch in any other call site that processes
RX under the guard. There are no such sites today in 8250_port.c
(uart_prepare_sysrq_char is only reachable through serial8250_handle_irq),
but the trap remains.
Option B -- fix the guard destructor in serial_core.h:
DEFINE_LOCK_GUARD_1(uart_port_lock_irqsave, struct uart_port,
uart_port_lock_irqsave(_T->lock, &_T->flags),
uart_unlock_and_check_sysrq_irqrestore(_T->lock,
_T->flags),
unsigned long flags);
uart_unlock_and_check_sysrq_irqrestore() short-circuits to plain unlock
when !port->has_sysrq, so no overhead on non-sysrq ports. Fixes all
current and future guard(uart_port_lock_irqsave) users in one place.
Drawback: changes the semantics of a shared serial primitive. Some
callers in 8250_port.c run under that guard from non-RX contexts
(serial8250_set_mctrl, wait_for_xmitr, etc.); the only observable effect
there would be a one-time handle_sysrq() call if a previous BREAK left
sysrq_ch set -- functionally desirable, but a behaviour change worth
documenting.
I have a tested Option A patch against 6.18.24 (verified the dispatch
fires and produces the SysRq help dump). Happy to send it formally, or
to retarget to Option B if that's the preferred direction.
Thanks,
Jacques
^ permalink raw reply
* [tty:tty-next 28/31] drivers/tty/serial/max310x.c:1727:25: error: use of undeclared identifier 'max310x_spi_driver'; did you mean 'max310x_i2c_driver'?
From: kernel test robot @ 2026-05-12 11:52 UTC (permalink / raw)
To: Hugo Villeneuve; +Cc: oe-kbuild-all, linux-serial, Greg Kroah-Hartman
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-next
head: 16e95bfb79b5d9d01dc7651d98caf3c2ace331cd
commit: 20ffe4b3330a8bde9e933e9ba2323d5e9386caa5 [28/31] serial: max310x: allow driver to be built with SPI or I2C
config: sparc64-randconfig-r122-20260512 (https://download.01.org/0day-ci/archive/20260512/202605121900.SP8ZoaTw-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 5bac06718f502014fade905512f1d26d578a18f3)
sparse: v0.6.5-rc1
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260512/202605121900.SP8ZoaTw-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605121900.SP8ZoaTw-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/tty/serial/max310x.c:1727:25: error: use of undeclared identifier 'max310x_spi_driver'; did you mean 'max310x_i2c_driver'?
1727 | spi_unregister_driver(&max310x_spi_driver);
| ^~~~~~~~~~~~~~~~~~
| max310x_i2c_driver
drivers/tty/serial/max310x.c:1689:26: note: 'max310x_i2c_driver' declared here
1689 | static struct i2c_driver max310x_i2c_driver = {
| ^
>> drivers/tty/serial/max310x.c:1727:24: error: incompatible pointer types passing 'struct i2c_driver *' to parameter of type 'struct spi_driver *' [-Wincompatible-pointer-types]
1727 | spi_unregister_driver(&max310x_spi_driver);
| ^~~~~~~~~~~~~~~~~~~
include/linux/spi/spi.h:378:61: note: passing argument to parameter 'sdrv' here
378 | static inline void spi_unregister_driver(struct spi_driver *sdrv)
| ^
2 errors generated.
vim +1727 drivers/tty/serial/max310x.c
6286767ad3afc88 Alexander Shiyan 2016-06-07 1722
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1723 return 0;
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1724
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1725 #ifdef CONFIG_I2C
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1726 err_i2c_register:
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 @1727 spi_unregister_driver(&max310x_spi_driver);
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1728 #endif
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1729
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1730 err_spi_register:
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1731 uart_unregister_driver(&max310x_uart);
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1732
51f689cc1133394 Kangjie Lu 2018-12-25 1733 return ret;
6286767ad3afc88 Alexander Shiyan 2016-06-07 1734 }
6286767ad3afc88 Alexander Shiyan 2016-06-07 1735 module_init(max310x_uart_init);
6286767ad3afc88 Alexander Shiyan 2016-06-07 1736
:::::: The code at line 1727 was first introduced by commit
:::::: 2e1f2d9a9bdbe12ee475c82a45ac46a278e8049a serial: max310x: implement I2C support
:::::: TO: Cosmin Tanislav <cosmin.tanislav@analog.com>
:::::: CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [tty:tty-next 28/31] drivers/tty/serial/max310x.c:1727:32: error: 'max310x_spi_driver' undeclared; did you mean 'max310x_i2c_driver'?
From: kernel test robot @ 2026-05-12 10:59 UTC (permalink / raw)
To: Hugo Villeneuve; +Cc: oe-kbuild-all, linux-serial, Greg Kroah-Hartman
Hi Hugo,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-next
head: 16e95bfb79b5d9d01dc7651d98caf3c2ace331cd
commit: 20ffe4b3330a8bde9e933e9ba2323d5e9386caa5 [28/31] serial: max310x: allow driver to be built with SPI or I2C
config: um-randconfig-r112-20260512 (https://download.01.org/0day-ci/archive/20260512/202605121847.N9DVLNg2-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
sparse: v0.6.5-rc1
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260512/202605121847.N9DVLNg2-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605121847.N9DVLNg2-lkp@intel.com/
All error/warnings (new ones prefixed by >>):
drivers/tty/serial/max310x.c: In function 'max310x_uart_init':
>> drivers/tty/serial/max310x.c:1727:32: error: 'max310x_spi_driver' undeclared (first use in this function); did you mean 'max310x_i2c_driver'?
1727 | spi_unregister_driver(&max310x_spi_driver);
| ^~~~~~~~~~~~~~~~~~
| max310x_i2c_driver
drivers/tty/serial/max310x.c:1727:32: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/tty/serial/max310x.c:1730:1: warning: label 'err_spi_register' defined but not used [-Wunused-label]
1730 | err_spi_register:
| ^~~~~~~~~~~~~~~~
drivers/tty/serial/max310x.c: At top level:
>> drivers/tty/serial/max310x.c:1492:29: warning: 'regcfg' defined but not used [-Wunused-variable]
1492 | static struct regmap_config regcfg = {
| ^~~~~~
vim +1727 drivers/tty/serial/max310x.c
6286767ad3afc88 Alexander Shiyan 2016-06-07 1722
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1723 return 0;
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1724
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1725 #ifdef CONFIG_I2C
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1726 err_i2c_register:
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 @1727 spi_unregister_driver(&max310x_spi_driver);
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1728 #endif
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1729
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 @1730 err_spi_register:
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1731 uart_unregister_driver(&max310x_uart);
2e1f2d9a9bdbe12 Cosmin Tanislav 2022-06-05 1732
51f689cc1133394 Kangjie Lu 2018-12-25 1733 return ret;
6286767ad3afc88 Alexander Shiyan 2016-06-07 1734 }
6286767ad3afc88 Alexander Shiyan 2016-06-07 1735 module_init(max310x_uart_init);
6286767ad3afc88 Alexander Shiyan 2016-06-07 1736
:::::: The code at line 1727 was first introduced by commit
:::::: 2e1f2d9a9bdbe12ee475c82a45ac46a278e8049a serial: max310x: implement I2C support
:::::: TO: Cosmin Tanislav <cosmin.tanislav@analog.com>
:::::: CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH tty v5 3/3] serial: 8250: Add support for console flow control
From: John Ogness @ 2026-05-12 9:29 UTC (permalink / raw)
To: Ilpo Järvinen, Andy Shevchenko
Cc: Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko, LKML,
Ilpo Järvinen, Thomas Gleixner, Ingo Molnar, Kees Cook,
Osama Abdelkader, Randy Dunlap, Joseph Tilahun,
Krzysztof Kozlowski, Dr. David Alan Gilbert, linux-serial
In-Reply-To: <f9f408c5-72f5-4be8-7471-e9aee2935a5b@linux.intel.com>
On 2026-05-11, Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
>> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
>> index 4f7bbdd900176..17fcff466e301 100644
>> --- a/include/linux/serial_core.h
>> +++ b/include/linux/serial_core.h
>> @@ -1175,6 +1175,14 @@ static inline bool uart_cons_flow_enabled(const struct uart_port *uport)
>> return uport->cons_flow;
>> }
>>
>> +static inline bool uart_console_hwflow_active(struct uart_port *uport)
>> +{
>> + return uart_console(uport) &&
>> + !(uport->rs485.flags & SER_RS485_ENABLED) &&
>> + uart_cons_flow_enabled(uport) &&
>> + uart_cts_enabled(uport);
>> +}
>> +
>> /*
>> * The following are helper functions for the low level drivers.
>> */
>
> Did you miss Andy's comments or choose to not act on them?
You mean these [0]? For the getter, yes. (Although I left the "is_" off
so that it matches other existing flag checking functions.)
For the setter, Andy suggested explicit enable/disable
variants. However, all the users enable/disable based on some
condition. That would mean that there would be a repeated pattern of:
if (condition)
uart_cons_flow_enable();
else
uart_cons_flow_disable();
So I decided to keep a single setter.
uart_set_cons_flow_enabled(condition);
I renamed the setter so that it is clearer that only the enabled flag is
being set and not any other special procedures.
John Ogness
[0] https://lore.kernel.org/lkml/CAHp75Vf4YZVqXa7eH-RFeVsycdzoHijcWFnUbGv2PSmtPya1-w@mail.gmail.com
^ permalink raw reply
* Re: [LINUX PATCH] serial: xilinx_uartps: fix runtime PM race during probe
From: Greg Kroah-Hartman @ 2026-05-12 7:38 UTC (permalink / raw)
To: Shubhrajyoti Datta
Cc: linux-kernel, git, shubhrajyoti.datta, Jiri Slaby, Michal Simek,
linux-serial, linux-arm-kernel
In-Reply-To: <176bdb50948e99c40f8baaeaac9ffc5eaf10816f.1778567817.git.shubhrajyoti.datta@amd.com>
On Tue, May 12, 2026 at 12:11:33PM +0530, Shubhrajyoti Datta wrote:
> pm_runtime_enable() was called with usage_count=0, allowing the PM
> core to immediately queue a deferred suspend via pm_runtime_work.
> This raced with console write, causing cdns_runtime_suspend to
> fire before the port was fully registered.
>
> Hold a reference with pm_runtime_get_noresume() before enabling
> runtime PM.
>
> Fixes: d62100f1aac2 ("serial: xilinx_uartps: Add pm runtime support")
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
> ---
> drivers/tty/serial/xilinx_uartps.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
> index a072b75dbaf2..e316cac4f35b 100644
> --- a/drivers/tty/serial/xilinx_uartps.c
> +++ b/drivers/tty/serial/xilinx_uartps.c
> @@ -1800,6 +1800,7 @@ static int cdns_uart_probe(struct platform_device *pdev)
> pm_runtime_use_autosuspend(&pdev->dev);
> pm_runtime_set_autosuspend_delay(&pdev->dev, UART_AUTOSUSPEND_TIMEOUT);
> pm_runtime_set_active(&pdev->dev);
> + pm_runtime_get_noresume(&pdev->dev);
> pm_runtime_enable(&pdev->dev);
> device_init_wakeup(port->dev, true);
>
> @@ -1824,6 +1825,8 @@ static int cdns_uart_probe(struct platform_device *pdev)
> "uart_add_one_port() failed; err=%i\n", rc);
> goto err_out_pm_disable;
> }
> + pm_runtime_mark_last_busy(&pdev->dev);
> + pm_runtime_put_autosuspend(&pdev->dev);
>
> #ifdef CONFIG_SERIAL_XILINX_PS_UART_CONSOLE
> /* This is not port which is used for console that's why clean it up */
> @@ -1842,6 +1845,7 @@ static int cdns_uart_probe(struct platform_device *pdev)
> return 0;
>
> err_out_pm_disable:
> + pm_runtime_put_noidle(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
> pm_runtime_set_suspended(&pdev->dev);
> pm_runtime_dont_use_autosuspend(&pdev->dev);
> --
> 2.49.1
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- You have marked a patch with a "Fixes:" tag for a commit that is in an
older released kernel, yet you do not have a cc: stable line in the
signed-off-by area at all, which means that the patch will not be
applied to any older kernel releases. To properly fix this, please
follow the documented rules in the
Documentation/process/stable-kernel-rules.rst file for how to resolve
this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* [PATCH v2] serial: altera_jtaguart: handle uart_add_one_port() failures
From: Myeonghun Pak @ 2026-05-12 6:56 UTC (permalink / raw)
To: Tobias Klauser, Greg Kroah-Hartman, Jiri Slaby
Cc: Myeonghun Pak, linux-serial, linux-kernel, Ijae Kim
altera_jtaguart_probe() maps the register window before registering the
UART port, but it ignores failures from uart_add_one_port(). If port
registration fails, probe still returns success and the mapping remains
live until a later remove path that is not part of probe failure cleanup.
Return the uart_add_one_port() error and unmap the register window on
that failure path.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Fixes: 5bcd601049c6 ("serial: Add driver for the Altera JTAG UART")
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
---
Changes in v2:
- Drop the unnecessary port->membase = NULL assignment.
drivers/tty/serial/altera_jtaguart.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/altera_jtaguart.c b/drivers/tty/serial/altera_jtaguart.c
index d47a62d1c9..20f079fe11 100644
--- a/drivers/tty/serial/altera_jtaguart.c
+++ b/drivers/tty/serial/altera_jtaguart.c
@@ -379,6 +379,7 @@ static int altera_jtaguart_probe(struct platform_device *pdev)
struct resource *res_mem;
int i = pdev->id;
int irq;
+ int ret;
/* -1 emphasizes that the platform must have one port, no .N suffix */
if (i == -1)
@@ -418,7 +419,11 @@ static int altera_jtaguart_probe(struct platform_device *pdev)
port->flags = UPF_BOOT_AUTOCONF;
port->dev = &pdev->dev;
- uart_add_one_port(&altera_jtaguart_driver, port);
+ ret = uart_add_one_port(&altera_jtaguart_driver, port);
+ if (ret) {
+ iounmap(port->membase);
+ return ret;
+ }
return 0;
}
--
2.47.1
^ permalink raw reply related
* [tty:tty-linus] BUILD SUCCESS 452d6fa37ae9b021f4f6d397dbae077f7296f6f4
From: kernel test robot @ 2026-05-12 6:52 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-serial
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-linus
branch HEAD: 452d6fa37ae9b021f4f6d397dbae077f7296f6f4 serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ
elapsed time: 932m
configs tested: 231
configs skipped: 18
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260512 gcc-11.5.0
arc randconfig-002-20260512 gcc-11.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm pxa3xx_defconfig clang-23
arm randconfig-001-20260512 gcc-11.5.0
arm randconfig-002-20260512 gcc-11.5.0
arm randconfig-003-20260512 gcc-11.5.0
arm randconfig-004-20260512 gcc-11.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260512 clang-23
arm64 randconfig-001-20260512 gcc-14.3.0
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260512 clang-23
arm64 randconfig-002-20260512 gcc-14.3.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260512 clang-23
arm64 randconfig-003-20260512 gcc-14.3.0
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260512 clang-23
arm64 randconfig-004-20260512 gcc-14.3.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001 clang-23
csky randconfig-001-20260512 clang-23
csky randconfig-001-20260512 gcc-14.3.0
csky randconfig-002 clang-23
csky randconfig-002-20260512 clang-23
csky randconfig-002-20260512 gcc-14.3.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260512 gcc-10.5.0
hexagon randconfig-002-20260512 gcc-10.5.0
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001 gcc-14
i386 buildonly-randconfig-001-20260512 gcc-14
i386 buildonly-randconfig-002 gcc-14
i386 buildonly-randconfig-002-20260512 gcc-14
i386 buildonly-randconfig-003 gcc-14
i386 buildonly-randconfig-003-20260512 gcc-14
i386 buildonly-randconfig-004 gcc-14
i386 buildonly-randconfig-004-20260512 gcc-14
i386 buildonly-randconfig-005 gcc-14
i386 buildonly-randconfig-005-20260512 gcc-14
i386 buildonly-randconfig-006 gcc-14
i386 buildonly-randconfig-006-20260512 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260512 gcc-14
i386 randconfig-002-20260512 gcc-14
i386 randconfig-003-20260512 gcc-14
i386 randconfig-004-20260512 gcc-14
i386 randconfig-005-20260512 gcc-14
i386 randconfig-006-20260512 gcc-14
i386 randconfig-007-20260512 gcc-14
i386 randconfig-011-20260512 clang-20
i386 randconfig-011-20260512 gcc-14
i386 randconfig-012-20260512 clang-20
i386 randconfig-013-20260512 clang-20
i386 randconfig-014-20260512 clang-20
i386 randconfig-015-20260512 clang-20
i386 randconfig-015-20260512 gcc-14
i386 randconfig-016-20260512 clang-20
i386 randconfig-016-20260512 gcc-14
i386 randconfig-017-20260512 clang-20
i386 randconfig-017-20260512 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260512 gcc-10.5.0
loongarch randconfig-002-20260512 gcc-10.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
m68k defconfig gcc-15.2.0
m68k m5272c3_defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
microblaze defconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips jazz_defconfig clang-17
mips sb1250_swarm_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 defconfig gcc-15.2.0
nios2 randconfig-001-20260512 gcc-10.5.0
nios2 randconfig-002-20260512 gcc-10.5.0
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260512 gcc-12.5.0
parisc randconfig-002-20260512 gcc-12.5.0
parisc64 defconfig clang-19
parisc64 defconfig gcc-15.2.0
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc holly_defconfig clang-23
powerpc randconfig-001-20260512 gcc-12.5.0
powerpc randconfig-002-20260512 gcc-12.5.0
powerpc64 randconfig-001-20260512 gcc-12.5.0
powerpc64 randconfig-002-20260512 gcc-12.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001 gcc-15.2.0
riscv randconfig-001-20260512 gcc-15.2.0
riscv randconfig-002 gcc-15.2.0
riscv randconfig-002-20260512 gcc-15.2.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001 gcc-15.2.0
s390 randconfig-001-20260512 gcc-15.2.0
s390 randconfig-002 gcc-15.2.0
s390 randconfig-002-20260512 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001 gcc-15.2.0
sh randconfig-001-20260512 gcc-15.2.0
sh randconfig-002 gcc-15.2.0
sh randconfig-002-20260512 gcc-15.2.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001 gcc-13.4.0
sparc randconfig-001-20260512 gcc-13.4.0
sparc randconfig-002 gcc-13.4.0
sparc randconfig-002-20260512 gcc-13.4.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-13.4.0
sparc64 randconfig-001-20260512 gcc-13.4.0
sparc64 randconfig-002 gcc-13.4.0
sparc64 randconfig-002-20260512 gcc-13.4.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 gcc-13.4.0
um randconfig-001-20260512 gcc-13.4.0
um randconfig-002 gcc-13.4.0
um randconfig-002-20260512 gcc-13.4.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260512 gcc-14
x86_64 buildonly-randconfig-002-20260512 gcc-14
x86_64 buildonly-randconfig-003-20260512 gcc-14
x86_64 buildonly-randconfig-004-20260512 gcc-14
x86_64 buildonly-randconfig-005-20260512 gcc-14
x86_64 buildonly-randconfig-006-20260512 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260512 gcc-14
x86_64 randconfig-002-20260512 gcc-14
x86_64 randconfig-003-20260512 gcc-14
x86_64 randconfig-004-20260512 gcc-14
x86_64 randconfig-005-20260512 gcc-14
x86_64 randconfig-006-20260512 gcc-14
x86_64 randconfig-011-20260512 clang-20
x86_64 randconfig-012-20260512 clang-20
x86_64 randconfig-013-20260512 clang-20
x86_64 randconfig-014-20260512 clang-20
x86_64 randconfig-015-20260512 clang-20
x86_64 randconfig-016-20260512 clang-20
x86_64 randconfig-071-20260512 clang-20
x86_64 randconfig-071-20260512 gcc-14
x86_64 randconfig-072-20260512 clang-20
x86_64 randconfig-073-20260512 clang-20
x86_64 randconfig-074-20260512 clang-20
x86_64 randconfig-074-20260512 gcc-14
x86_64 randconfig-075-20260512 clang-20
x86_64 randconfig-076-20260512 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa randconfig-001 gcc-13.4.0
xtensa randconfig-001-20260512 gcc-13.4.0
xtensa randconfig-002 gcc-13.4.0
xtensa randconfig-002-20260512 gcc-13.4.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [LINUX PATCH] serial: xilinx_uartps: fix runtime PM race during probe
From: Shubhrajyoti Datta @ 2026-05-12 6:41 UTC (permalink / raw)
To: linux-kernel
Cc: git, shubhrajyoti.datta, Greg Kroah-Hartman, Jiri Slaby,
Michal Simek, Shubhrajyoti Datta, linux-serial, linux-arm-kernel
pm_runtime_enable() was called with usage_count=0, allowing the PM
core to immediately queue a deferred suspend via pm_runtime_work.
This raced with console write, causing cdns_runtime_suspend to
fire before the port was fully registered.
Hold a reference with pm_runtime_get_noresume() before enabling
runtime PM.
Fixes: d62100f1aac2 ("serial: xilinx_uartps: Add pm runtime support")
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
---
drivers/tty/serial/xilinx_uartps.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index a072b75dbaf2..e316cac4f35b 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1800,6 +1800,7 @@ static int cdns_uart_probe(struct platform_device *pdev)
pm_runtime_use_autosuspend(&pdev->dev);
pm_runtime_set_autosuspend_delay(&pdev->dev, UART_AUTOSUSPEND_TIMEOUT);
pm_runtime_set_active(&pdev->dev);
+ pm_runtime_get_noresume(&pdev->dev);
pm_runtime_enable(&pdev->dev);
device_init_wakeup(port->dev, true);
@@ -1824,6 +1825,8 @@ static int cdns_uart_probe(struct platform_device *pdev)
"uart_add_one_port() failed; err=%i\n", rc);
goto err_out_pm_disable;
}
+ pm_runtime_mark_last_busy(&pdev->dev);
+ pm_runtime_put_autosuspend(&pdev->dev);
#ifdef CONFIG_SERIAL_XILINX_PS_UART_CONSOLE
/* This is not port which is used for console that's why clean it up */
@@ -1842,6 +1845,7 @@ static int cdns_uart_probe(struct platform_device *pdev)
return 0;
err_out_pm_disable:
+ pm_runtime_put_noidle(&pdev->dev);
pm_runtime_disable(&pdev->dev);
pm_runtime_set_suspended(&pdev->dev);
pm_runtime_dont_use_autosuspend(&pdev->dev);
--
2.49.1
^ permalink raw reply related
* [tty:tty-testing] BUILD SUCCESS 16e95bfb79b5d9d01dc7651d98caf3c2ace331cd
From: kernel test robot @ 2026-05-12 4:09 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-serial
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing
branch HEAD: 16e95bfb79b5d9d01dc7651d98caf3c2ace331cd serial: qcom-geni: Avoid probing debug console UART without console support
elapsed time: 738m
configs tested: 145
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig gcc-15.2.0
arc randconfig-001-20260512 gcc-11.5.0
arc randconfig-001-20260512 gcc-8.5.0
arc randconfig-002-20260512 gcc-11.5.0
arc randconfig-002-20260512 gcc-8.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm randconfig-001-20260512 clang-23
arm randconfig-001-20260512 gcc-11.5.0
arm randconfig-002-20260512 gcc-11.5.0
arm randconfig-003-20260512 clang-23
arm randconfig-003-20260512 gcc-11.5.0
arm randconfig-004-20260512 gcc-11.5.0
arm randconfig-004-20260512 gcc-8.5.0
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon randconfig-001-20260512 clang-23
hexagon randconfig-002-20260512 clang-23
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260512 gcc-14
i386 buildonly-randconfig-002-20260512 gcc-14
i386 buildonly-randconfig-003-20260512 gcc-14
i386 buildonly-randconfig-004-20260512 clang-20
i386 buildonly-randconfig-005-20260512 clang-20
i386 buildonly-randconfig-006-20260512 clang-20
i386 randconfig-011-20260512 clang-20
i386 randconfig-012-20260512 clang-20
i386 randconfig-013-20260512 clang-20
i386 randconfig-014-20260512 clang-20
i386 randconfig-015-20260512 clang-20
i386 randconfig-016-20260512 clang-20
i386 randconfig-017-20260512 clang-20
loongarch allmodconfig clang-19
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260512 clang-18
loongarch randconfig-002-20260512 gcc-15.2.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig gcc-15.2.0
m68k m5272c3_defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips jazz_defconfig clang-17
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20260512 gcc-11.5.0
nios2 randconfig-002-20260512 gcc-10.5.0
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260512 gcc-11.5.0
parisc randconfig-001-20260512 gcc-12.5.0
parisc randconfig-002-20260512 gcc-12.5.0
parisc randconfig-002-20260512 gcc-9.5.0
parisc64 defconfig gcc-15.2.0
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc holly_defconfig clang-23
powerpc randconfig-001-20260512 clang-23
powerpc randconfig-001-20260512 gcc-12.5.0
powerpc randconfig-002-20260512 gcc-12.5.0
powerpc64 randconfig-001-20260512 clang-17
powerpc64 randconfig-001-20260512 gcc-12.5.0
powerpc64 randconfig-002-20260512 clang-23
powerpc64 randconfig-002-20260512 gcc-12.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
s390 allmodconfig clang-18
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-071-20260512 clang-20
x86_64 randconfig-072-20260512 clang-20
x86_64 randconfig-073-20260512 clang-20
x86_64 randconfig-074-20260512 clang-20
x86_64 randconfig-075-20260512 clang-20
x86_64 randconfig-076-20260512 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa allyesconfig gcc-15.2.0
xtensa randconfig-001-20260512 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2] tty: serial: atmel: Ignore chars when CREAD is cleared
From: Rakesh Alasyam @ 2026-05-11 16:59 UTC (permalink / raw)
To: gregkh
Cc: richard.genoud, jirislaby, nicolas.ferre, alexandre.belloni,
claudiu.beznea, linux-serial, linux-kernel, linux-arm-kernel,
Rakesh Alasyam
In-Reply-To: <2026051106-obliged-dismount-d85f@gregkh>
Ignore received characters when CREAD is cleared by adding RXRDY
to ignore_status_mask.
This replaces an existing TODO in the driver.
Tested on hardware.
Signed-off-by: Rakesh Alasyam <alasyamrakesh77@gmail.com>
---
v2:
- Add blank line before comment
- Tested on hardware
---
drivers/tty/serial/atmel_serial.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 5d8c1cfc1c60..5c756dc904b0 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -2184,7 +2184,8 @@ static void atmel_set_termios(struct uart_port *port,
if (termios->c_iflag & IGNPAR)
port->ignore_status_mask |= ATMEL_US_OVRE;
}
- /* TODO: Ignore all characters if CREAD is set.*/
+ if (!(termios->c_cflag & CREAD))
+ port->ignore_status_mask |= ATMEL_US_RXRDY;
/* update the per-port timeout */
uart_update_timeout(port, termios->c_cflag, baud);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] tty: serial: atmel: Ignore chars when CREAD is cleared
From: Greg KH @ 2026-05-11 16:54 UTC (permalink / raw)
To: Rakesh Alasyam
Cc: richard.genoud, jirislaby, nicolas.ferre, alexandre.belloni,
claudiu.beznea, linux-serial, linux-kernel, linux-arm-kernel
In-Reply-To: <20260511155655.26435-1-alasyamrakesh77@gmail.com>
On Mon, May 11, 2026 at 09:26:55PM +0530, Rakesh Alasyam wrote:
> Ignore received characters when CREAD is cleared by adding RXRDY
> to ignore_status_mask.
>
> This replaces an existing TODO in the driver.
>
> Tested on hardware.
>
> Signed-off-by: Rakesh Alasyam <alasyamrakesh77@gmail.com>
>
> ---
>
> v2:
> - Add blank line before comment
> - Tested on hardware
> ---
> drivers/tty/serial/atmel_serial.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 5d8c1cfc1c60..5c756dc904b0 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -2184,7 +2184,8 @@ static void atmel_set_termios(struct uart_port *port,
> if (termios->c_iflag & IGNPAR)
> port->ignore_status_mask |= ATMEL_US_OVRE;
> }
> - /* TODO: Ignore all characters if CREAD is set.*/
> + if (!(termios->c_cflag & CREAD))
> + port->ignore_status_mask |= ATMEL_US_RXRDY;
>
> /* update the per-port timeout */
> uart_update_timeout(port, termios->c_cflag, baud);
> --
> 2.43.0
>
No v2 in the subject line :(
^ permalink raw reply
* Re: [PATCH tty v5 3/3] serial: 8250: Add support for console flow control
From: Ilpo Järvinen @ 2026-05-11 16:07 UTC (permalink / raw)
To: John Ogness, Andy Shevchenko
Cc: Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko, LKML,
Ilpo Järvinen, Thomas Gleixner, Ingo Molnar, Kees Cook,
Osama Abdelkader, Randy Dunlap, Joseph Tilahun,
Krzysztof Kozlowski, Dr. David Alan Gilbert, linux-serial
In-Reply-To: <20260511152706.151498-4-john.ogness@linutronix.de>
On Mon, 11 May 2026, John Ogness 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.
>
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
> ---
> drivers/tty/serial/8250/8250_core.c | 6 +++++-
> drivers/tty/serial/8250/8250_port.c | 13 +++++++++++--
> drivers/tty/serial/serial_core.c | 21 ++++++++++++++++++++-
> include/linux/serial_core.h | 8 ++++++++
> 4 files changed, 44 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
> index b0275204e1167..1f03da85e3414 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -693,6 +693,7 @@ static void serial_8250_overrun_backoff_work(struct work_struct *work)
> int serial8250_register_8250_port(const struct uart_8250_port *up)
> {
> struct uart_8250_port *uart;
> + bool cons_flow;
> int ret;
>
> if (up->port.uartclk == 0)
> @@ -716,6 +717,9 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
> if (uart->port.type == PORT_8250_CIR)
> return -ENODEV;
>
> + /* Preserve specified console flow control. */
> + cons_flow = uart_cons_flow_enabled(&uart->port);
> +
> if (uart->port.dev)
> uart_remove_one_port(&serial8250_reg, &uart->port);
>
> @@ -746,7 +750,7 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
> uart->lsr_save_mask = up->lsr_save_mask;
> uart->dma = up->dma;
>
> - uart_set_cons_flow_enabled(&uart->port, uart_cons_flow_enabled(&up->port));
> + uart_set_cons_flow_enabled(&uart->port, uart_cons_flow_enabled(&up->port) | cons_flow);
>
> /* Take tx_loadsz from fifosize if it wasn't set separately */
> if (uart->port.fifosize && !uart->tx_loadsz)
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index fe2e0f1e66c21..ef245114105bc 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -1991,7 +1991,7 @@ static void wait_for_xmitr(struct uart_8250_port *up, int bits)
> tx_ready = wait_for_lsr(up, bits);
>
> /* Wait up to 1s for flow control if necessary */
> - if (uart_cons_flow_enabled(&up->port)) {
> + if (uart_console_hwflow_active(&up->port)) {
> for (tmout = 1000000; tmout; tmout--) {
> unsigned int msr = serial_in(up, UART_MSR);
> up->msr_saved_flags |= msr & MSR_SAVE_FLAGS;
> @@ -2788,6 +2788,12 @@ serial8250_do_set_termios(struct uart_port *port, struct ktermios *termios,
> serial8250_set_efr(port, termios);
> serial8250_set_divisor(port, baud, quot, frac);
> serial8250_set_fcr(port, termios);
> + /* Consoles manually poll CTS for hardware flow control. */
> + if (uart_console(port) &&
> + !(port->rs485.flags & SER_RS485_ENABLED)
> + && termios->c_cflag & CRTSCTS) {
> + port->mctrl |= TIOCM_RTS;
> + }
> serial8250_set_mctrl(port, port->mctrl);
> }
>
> @@ -3357,7 +3363,7 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s,
> * it regardless of the CTS state. Therefore, only use fifo
> * if we don't use control flow.
> */
> - !uart_cons_flow_enabled(&up->port);
> + !uart_console_hwflow_active(&up->port);
>
> if (likely(use_fifo))
> serial8250_console_fifo_write(up, s, count);
> @@ -3427,6 +3433,9 @@ int serial8250_console_setup(struct uart_port *port, char *options, bool probe)
> if (ret)
> return ret;
>
> + /* Track user-specified console flow control. */
> + uart_set_cons_flow_enabled(port, flow == 'r');
> +
> if (port->dev)
> pm_runtime_get_sync(port->dev);
>
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 89cebdd278410..840336f95c5f6 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -2235,6 +2235,18 @@ uart_set_options(struct uart_port *port, struct console *co,
> port->mctrl |= TIOCM_DTR;
>
> port->ops->set_termios(port, &termios, &dummy);
> +
> + /*
> + * If console hardware flow control was specified and is supported,
> + * the related policy UPSTAT_CTS_ENABLE must be set to allow console
> + * drivers to identify if CTS should be used for polling.
> + */
> + if (flow == 'r' && (termios.c_cflag & CRTSCTS)) {
> + /* Synchronize @status RMW update against the console. */
> + guard(uart_port_lock_irqsave)(port);
> + port->status |= UPSTAT_CTS_ENABLE;
> + }
> +
> /*
> * Allow the setting of the UART parameters with a NULL console
> * too:
> @@ -2541,7 +2553,14 @@ uart_configure_port(struct uart_driver *drv, struct uart_state *state,
> * We probably don't need a spinlock around this, but
> */
> scoped_guard(uart_port_lock_irqsave, port) {
> - port->mctrl &= TIOCM_DTR;
> + unsigned int mask = TIOCM_DTR;
> +
> + /* Console hardware flow control polls CTS. */
> + if (uart_console_hwflow_active(port))
> + mask |= TIOCM_RTS;
> +
> + port->mctrl &= mask;
> +
> if (!(port->rs485.flags & SER_RS485_ENABLED))
> port->ops->set_mctrl(port, port->mctrl);
> }
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index 4f7bbdd900176..17fcff466e301 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -1175,6 +1175,14 @@ static inline bool uart_cons_flow_enabled(const struct uart_port *uport)
> return uport->cons_flow;
> }
>
> +static inline bool uart_console_hwflow_active(struct uart_port *uport)
> +{
> + return uart_console(uport) &&
> + !(uport->rs485.flags & SER_RS485_ENABLED) &&
> + uart_cons_flow_enabled(uport) &&
> + uart_cts_enabled(uport);
> +}
> +
> /*
> * The following are helper functions for the low level drivers.
> */
>
Hi,
Did you miss Andy's comments or choose to not act on them?
--
i.
^ permalink raw reply
* [PATCH] tty: serial: atmel: Ignore chars when CREAD is cleared
From: Rakesh Alasyam @ 2026-05-11 15:56 UTC (permalink / raw)
To: gregkh
Cc: richard.genoud, jirislaby, nicolas.ferre, alexandre.belloni,
claudiu.beznea, linux-serial, linux-kernel, linux-arm-kernel,
Rakesh Alasyam
In-Reply-To: <2026051106-obliged-dismount-d85f@gregkh>
Ignore received characters when CREAD is cleared by adding RXRDY
to ignore_status_mask.
This replaces an existing TODO in the driver.
Tested on hardware.
Signed-off-by: Rakesh Alasyam <alasyamrakesh77@gmail.com>
---
v2:
- Add blank line before comment
- Tested on hardware
---
drivers/tty/serial/atmel_serial.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 5d8c1cfc1c60..5c756dc904b0 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -2184,7 +2184,8 @@ static void atmel_set_termios(struct uart_port *port,
if (termios->c_iflag & IGNPAR)
port->ignore_status_mask |= ATMEL_US_OVRE;
}
- /* TODO: Ignore all characters if CREAD is set.*/
+ if (!(termios->c_cflag & CREAD))
+ port->ignore_status_mask |= ATMEL_US_RXRDY;
/* update the per-port timeout */
uart_update_timeout(port, termios->c_cflag, baud);
--
2.43.0
^ permalink raw reply related
* [PATCH tty v5 3/3] serial: 8250: Add support for console flow control
From: John Ogness @ 2026-05-11 15:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: Andy Shevchenko, linux-kernel, Ilpo Järvinen,
Thomas Gleixner, Ingo Molnar, Kees Cook, Osama Abdelkader,
Randy Dunlap, Joseph Tilahun, Krzysztof Kozlowski,
Dr. David Alan Gilbert, linux-serial
In-Reply-To: <20260511152706.151498-1-john.ogness@linutronix.de>
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.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
drivers/tty/serial/8250/8250_core.c | 6 +++++-
drivers/tty/serial/8250/8250_port.c | 13 +++++++++++--
drivers/tty/serial/serial_core.c | 21 ++++++++++++++++++++-
include/linux/serial_core.h | 8 ++++++++
4 files changed, 44 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index b0275204e1167..1f03da85e3414 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -693,6 +693,7 @@ static void serial_8250_overrun_backoff_work(struct work_struct *work)
int serial8250_register_8250_port(const struct uart_8250_port *up)
{
struct uart_8250_port *uart;
+ bool cons_flow;
int ret;
if (up->port.uartclk == 0)
@@ -716,6 +717,9 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
if (uart->port.type == PORT_8250_CIR)
return -ENODEV;
+ /* Preserve specified console flow control. */
+ cons_flow = uart_cons_flow_enabled(&uart->port);
+
if (uart->port.dev)
uart_remove_one_port(&serial8250_reg, &uart->port);
@@ -746,7 +750,7 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
uart->lsr_save_mask = up->lsr_save_mask;
uart->dma = up->dma;
- uart_set_cons_flow_enabled(&uart->port, uart_cons_flow_enabled(&up->port));
+ uart_set_cons_flow_enabled(&uart->port, uart_cons_flow_enabled(&up->port) | cons_flow);
/* Take tx_loadsz from fifosize if it wasn't set separately */
if (uart->port.fifosize && !uart->tx_loadsz)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index fe2e0f1e66c21..ef245114105bc 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1991,7 +1991,7 @@ static void wait_for_xmitr(struct uart_8250_port *up, int bits)
tx_ready = wait_for_lsr(up, bits);
/* Wait up to 1s for flow control if necessary */
- if (uart_cons_flow_enabled(&up->port)) {
+ if (uart_console_hwflow_active(&up->port)) {
for (tmout = 1000000; tmout; tmout--) {
unsigned int msr = serial_in(up, UART_MSR);
up->msr_saved_flags |= msr & MSR_SAVE_FLAGS;
@@ -2788,6 +2788,12 @@ serial8250_do_set_termios(struct uart_port *port, struct ktermios *termios,
serial8250_set_efr(port, termios);
serial8250_set_divisor(port, baud, quot, frac);
serial8250_set_fcr(port, termios);
+ /* Consoles manually poll CTS for hardware flow control. */
+ if (uart_console(port) &&
+ !(port->rs485.flags & SER_RS485_ENABLED)
+ && termios->c_cflag & CRTSCTS) {
+ port->mctrl |= TIOCM_RTS;
+ }
serial8250_set_mctrl(port, port->mctrl);
}
@@ -3357,7 +3363,7 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s,
* it regardless of the CTS state. Therefore, only use fifo
* if we don't use control flow.
*/
- !uart_cons_flow_enabled(&up->port);
+ !uart_console_hwflow_active(&up->port);
if (likely(use_fifo))
serial8250_console_fifo_write(up, s, count);
@@ -3427,6 +3433,9 @@ int serial8250_console_setup(struct uart_port *port, char *options, bool probe)
if (ret)
return ret;
+ /* Track user-specified console flow control. */
+ uart_set_cons_flow_enabled(port, flow == 'r');
+
if (port->dev)
pm_runtime_get_sync(port->dev);
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 89cebdd278410..840336f95c5f6 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2235,6 +2235,18 @@ uart_set_options(struct uart_port *port, struct console *co,
port->mctrl |= TIOCM_DTR;
port->ops->set_termios(port, &termios, &dummy);
+
+ /*
+ * If console hardware flow control was specified and is supported,
+ * the related policy UPSTAT_CTS_ENABLE must be set to allow console
+ * drivers to identify if CTS should be used for polling.
+ */
+ if (flow == 'r' && (termios.c_cflag & CRTSCTS)) {
+ /* Synchronize @status RMW update against the console. */
+ guard(uart_port_lock_irqsave)(port);
+ port->status |= UPSTAT_CTS_ENABLE;
+ }
+
/*
* Allow the setting of the UART parameters with a NULL console
* too:
@@ -2541,7 +2553,14 @@ uart_configure_port(struct uart_driver *drv, struct uart_state *state,
* We probably don't need a spinlock around this, but
*/
scoped_guard(uart_port_lock_irqsave, port) {
- port->mctrl &= TIOCM_DTR;
+ unsigned int mask = TIOCM_DTR;
+
+ /* Console hardware flow control polls CTS. */
+ if (uart_console_hwflow_active(port))
+ mask |= TIOCM_RTS;
+
+ port->mctrl &= mask;
+
if (!(port->rs485.flags & SER_RS485_ENABLED))
port->ops->set_mctrl(port, port->mctrl);
}
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 4f7bbdd900176..17fcff466e301 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -1175,6 +1175,14 @@ static inline bool uart_cons_flow_enabled(const struct uart_port *uport)
return uport->cons_flow;
}
+static inline bool uart_console_hwflow_active(struct uart_port *uport)
+{
+ return uart_console(uport) &&
+ !(uport->rs485.flags & SER_RS485_ENABLED) &&
+ uart_cons_flow_enabled(uport) &&
+ uart_cts_enabled(uport);
+}
+
/*
* The following are helper functions for the low level drivers.
*/
--
2.47.3
^ permalink raw reply related
* [PATCH tty v5 2/3] serial: 8250: Check LSR timeout on console flow control
From: John Ogness @ 2026-05-11 15:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: Andy Shevchenko, linux-kernel, Ilpo Järvinen,
Andy Shevchenko, linux-serial
In-Reply-To: <20260511152706.151498-1-john.ogness@linutronix.de>
wait_for_xmitr() calls wait_for_lsr() to wait for the transmission
registers to be empty. wait_for_lsr() can timeout after a reasonable
amount of time.
When console flow control is active, wait_for_xmitr() additionally
polls CTS, waiting for the peer to signal that it is ready to receive
more data.
If hardware flow control is enabled (auto CTS) and the peer deasserts
CTS, wait_for_lsr() will timeout. If additionally console flow
control is active and while polling CTS the peer asserts CTS, the
console will assume it can immediately transmit, even though the
transmission registers may not be empty. This can lead to data loss.
Avoid this problem by performing an extra wait_for_lsr() upon CTS
assertion if wait_for_lsr() previously timed out.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
drivers/tty/serial/8250/8250_port.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index e4e6a53ebea39..fe2e0f1e66c21 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1986,16 +1986,20 @@ static bool wait_for_lsr(struct uart_8250_port *up, int bits)
static void wait_for_xmitr(struct uart_8250_port *up, int bits)
{
unsigned int tmout;
+ bool tx_ready;
- wait_for_lsr(up, bits);
+ tx_ready = wait_for_lsr(up, bits);
/* Wait up to 1s for flow control if necessary */
if (uart_cons_flow_enabled(&up->port)) {
for (tmout = 1000000; tmout; tmout--) {
unsigned int msr = serial_in(up, UART_MSR);
up->msr_saved_flags |= msr & MSR_SAVE_FLAGS;
- if (msr & UART_MSR_CTS)
+ if (msr & UART_MSR_CTS) {
+ if (!tx_ready)
+ wait_for_lsr(up, bits);
break;
+ }
udelay(1);
touch_nmi_watchdog();
}
--
2.47.3
^ permalink raw reply related
* [PATCH tty v5 1/3] serial: 8250: Set cons_flow on port registration
From: John Ogness @ 2026-05-11 15:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: Andy Shevchenko, linux-kernel, Ilpo Järvinen, Xin Zhao,
Kees Cook, Osama Abdelkader, linux-serial
In-Reply-To: <20260511152706.151498-1-john.ogness@linutronix.de>
Since console flow control policy is no longer part of uart_port.flags,
explicitly set the policy for the port.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
drivers/tty/serial/8250/8250_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index a428e88938eb7..b0275204e1167 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -746,6 +746,8 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
uart->lsr_save_mask = up->lsr_save_mask;
uart->dma = up->dma;
+ uart_set_cons_flow_enabled(&uart->port, uart_cons_flow_enabled(&up->port));
+
/* Take tx_loadsz from fifosize if it wasn't set separately */
if (uart->port.fifosize && !uart->tx_loadsz)
uart->tx_loadsz = uart->port.fifosize;
--
2.47.3
^ permalink raw reply related
* [PATCH tty v5 0/3] 8250: Add console flow control
From: John Ogness @ 2026-05-11 15:26 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: Andy Shevchenko, linux-kernel, Ilpo Järvinen, Xin Zhao,
Kees Cook, Osama Abdelkader, linux-serial, Andy Shevchenko,
Thomas Gleixner, Ingo Molnar, Randy Dunlap, Joseph Tilahun,
Krzysztof Kozlowski, Dr. David Alan Gilbert
Hi,
As requested by Greg [0], this is a resend of the last 3 patches from
v4 of a series to implement console flow control for the 8250 serial
driver. v4 is here [1] (including all the details about the entirety
of the series).
John Ogness
[0] https://lore.kernel.org/lkml/2026051134-revisable-sherry-e5b5@gregkh
[1] https://lore.kernel.org/lkml/20260506121606.5805-1-john.ogness@linutronix.de
John Ogness (3):
serial: 8250: Set cons_flow on port registration
serial: 8250: Check LSR timeout on console flow control
serial: 8250: Add support for console flow control
drivers/tty/serial/8250/8250_core.c | 6 ++++++
drivers/tty/serial/8250/8250_port.c | 21 +++++++++++++++++----
drivers/tty/serial/serial_core.c | 21 ++++++++++++++++++++-
include/linux/serial_core.h | 8 ++++++++
4 files changed, 51 insertions(+), 5 deletions(-)
base-commit: 4a9a0b1a82a8b23eb68032dd19b120e82cd67004
--
2.47.3
^ permalink raw reply
* Re: [PATCH] tty: serial: qcom-geni: re-arm RX DMA on spurious zero-length interrupt
From: Greg KH @ 2026-05-11 15:21 UTC (permalink / raw)
To: vyndiktus; +Cc: linux-serial, linux-kernel
In-Reply-To: <20260422-qcom-geni-uart-dma-rearm-v1-1-76d13aac7fdf@gmail.com>
On Wed, Apr 22, 2026 at 04:13:03PM +0000, Vynnie Von Diktus via B4 Relay wrote:
> From: Vynnie Von Diktus <vyndiktus@gmail.com>
>
> qcom_geni_serial_handle_rx_dma() returns early when SE_DMA_RX_LEN_IN
> reads as zero, interpreting it as a spurious interrupt. The early return
> skips geni_se_rx_dma_prep(), leaving the RX DMA descriptor permanently
> unarmed. All subsequently received bytes are silently dropped until the
> port is closed and reopened.
>
> On cold boots, chip startup transients on the UART lines can produce a
> genuine spurious DMA interrupt with a zero-length count. The bug is
> invisible on warm reboots (the UART stays powered and stable, so no
> spurious interrupt fires), which makes it appear as an intermittent
> failure only on power-cycle reboots.
>
> Fix by restructuring the zero-length check to fall through to
> geni_se_rx_dma_prep() in all cases. Only the data processing
> (handle_rx_uart) is skipped when no bytes arrived.
>
> Tested on SM8150 (Snapdragon 855) with a WCN3990 BT UART — Bluetooth
> firmware download now succeeds on every cold boot without
> "Frame reassembly failed" errors.
>
> The same GENI serial IP block is used across SDM845, SM8150, SM8250,
> SM8350 and many other Snapdragon SoCs; the bug and fix are expected to
> apply to all of them.
>
> Signed-off-by: Vynnie Von Diktus <vyndiktus@gmail.com>
> ---
> drivers/tty/serial/qcom_geni_serial.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
> index 69a632fef..3c950bdc0 100644
> --- a/drivers/tty/serial/qcom_geni_serial.c
> +++ b/drivers/tty/serial/qcom_geni_serial.c
> @@ -837,11 +837,9 @@ static void qcom_geni_serial_handle_rx_dma(struct uart_port *uport, bool drop)
> rx_in = readl(uport->membase + SE_DMA_RX_LEN_IN);
> if (!rx_in) {
> dev_warn(uport->dev, "serial engine reports 0 RX bytes in!\n");
> - return;
> - }
> -
> - if (!drop)
> + } else if (!drop) {
> handle_rx_uart(uport, rx_in, drop);
> + }
>
> ret = geni_se_rx_dma_prep(&port->se, port->rx_buf,
> DMA_RX_BUF_SIZE,
>
> ---
> base-commit: 4a8d8848356e9e4c41e22de9b1ef1507ea21734a
> change-id: 20260422-qcom-geni-uart-dma-rearm-a5df83e164ff
>
> Best regards,
> --
> Vynnie Von Diktus <vyndiktus@gmail.com>
Does not apply to the tty-next tree :(
^ permalink raw reply
* Re: [PATCH] serial: atmel: honor CREAD in atmel_set_termios
From: Greg KH @ 2026-05-11 15:17 UTC (permalink / raw)
To: Rakesh Alasyam
Cc: richard.genoud, jirislaby, nicolas.ferre, alexandre.belloni,
claudiu.beznea, linux-serial, linux-kernel, linux-arm-kernel
In-Reply-To: <20260501081317.15477-1-alasyamrakesh77@gmail.com>
On Fri, May 01, 2026 at 01:43:17PM +0530, Rakesh Alasyam wrote:
> Ignore received characters when CREAD is cleared by adding RXRDY
> to ignore_status_mask.
>
> This replaces an existing TODO in the driver.
>
> Signed-off-by: Rakesh Alasyam <alasyamrakesh77@gmail.com>
> ---
> drivers/tty/serial/atmel_serial.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 5d8c1cfc1c60..5b062d8ccabe 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -2184,8 +2184,8 @@ static void atmel_set_termios(struct uart_port *port,
> if (termios->c_iflag & IGNPAR)
> port->ignore_status_mask |= ATMEL_US_OVRE;
> }
> - /* TODO: Ignore all characters if CREAD is set.*/
> -
> + if (!(termios->c_cflag & CREAD))
> + port->ignore_status_mask |= ATMEL_US_RXRDY;
> /* update the per-port timeout */
> uart_update_timeout(port, termios->c_cflag, baud);
>
> --
> 2.43.0
>
>
Cool, was this tested to work properly?
And a blank line is needed before the comment, right?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] serial: 8250: Clear CON_PRINTBUFFER on port re-registration
From: Greg KH @ 2026-05-11 15:16 UTC (permalink / raw)
To: Fushuai Wang
Cc: jirislaby, ilpo.jarvinen, osama.abdelkader, andy.shevchenko, kees,
linux-kernel, linux-serial, wangfushuai
In-Reply-To: <20260428090349.30047-1-fushuai.wang@linux.dev>
On Tue, Apr 28, 2026 at 05:03:49PM +0800, Fushuai Wang wrote:
> From: Fushuai Wang <wangfushuai@baidu.com>
>
> When two PnP devices map to the same physical port, the serial8250 driver
> removes and re-registers the console structure for the same port.
>
> During re-registration, the console structure still has CON_PRINTBUFFER set
> from the initial registration, which causes console_init_seq() to set
> console->seq to syslog_seq. This results in re-printing the entire
> system log buffer, which may lead to RCU stall on slow serial consoles.
>
> Clear CON_PRINTBUFFER when re-registering a port to prevent duplicate
> log printing.
>
> Fixes: 835d844d1a28 ("8250_pnp: do pnp probe before legacy probe")
> Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
> ---
> V1->V2: Add Fixes tag
> previous discussion: https://lore.kernel.org/all/20260416092917.27301-1-fushuai.wang@linux.dev/T/#u
>
> Please ignore previous email if you received it before. There is something wrong with my email client.
>
> drivers/tty/serial/8250/8250_core.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
> index a428e88938eb..01b14392d9f7 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -694,6 +694,7 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
> {
> struct uart_8250_port *uart;
> int ret;
> + bool was_removed = false;
>
> if (up->port.uartclk == 0)
> return -EINVAL;
> @@ -716,8 +717,10 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
> if (uart->port.type == PORT_8250_CIR)
> return -ENODEV;
>
> - if (uart->port.dev)
> + if (uart->port.dev) {
> uart_remove_one_port(&serial8250_reg, &uart->port);
> + was_removed = true;
> + }
>
> uart->port.ctrl_id = up->port.ctrl_id;
> uart->port.port_id = up->port.port_id;
> @@ -819,6 +822,10 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
> &uart->capabilities);
>
> serial8250_apply_quirks(uart);
> +
> + if (was_removed && uart_console(&uart->port))
> + uart->port.cons->flags &= ~CON_PRINTBUFFER;
Why not set the flag up above when you remove the port? Why down here?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] serial: altera_jtaguart: handle uart_add_one_port() failures
From: Greg Kroah-Hartman @ 2026-05-11 15:15 UTC (permalink / raw)
To: Myeonghun Pak
Cc: Tobias Klauser, Jiri Slaby, linux-serial, linux-kernel, Ijae Kim
In-Reply-To: <20260428064511.8934-1-mhun512@gmail.com>
On Tue, Apr 28, 2026 at 03:44:57PM +0900, Myeonghun Pak wrote:
> altera_jtaguart_probe() maps the register window before registering the
> UART port, but it ignores failures from uart_add_one_port(). If port
> registration fails, probe still returns success and the mapping remains
> live until a later remove path that is not part of probe failure cleanup.
>
> Return the uart_add_one_port() error and unmap the register window on
> that failure path.
>
> Fixes: 5bcd601049c6 ("serial: Add driver for the Altera JTAG UART")
> Co-developed-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
> ---
> drivers/tty/serial/altera_jtaguart.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/altera_jtaguart.c b/drivers/tty/serial/altera_jtaguart.c
> index d47a62d1c9..15588b6dc3 100644
> --- a/drivers/tty/serial/altera_jtaguart.c
> +++ b/drivers/tty/serial/altera_jtaguart.c
> @@ -379,6 +379,7 @@ static int altera_jtaguart_probe(struct platform_device *pdev)
> struct resource *res_mem;
> int i = pdev->id;
> int irq;
> + int ret;
>
> /* -1 emphasizes that the platform must have one port, no .N suffix */
> if (i == -1)
> @@ -418,7 +419,12 @@ static int altera_jtaguart_probe(struct platform_device *pdev)
> port->flags = UPF_BOOT_AUTOCONF;
> port->dev = &pdev->dev;
>
> - uart_add_one_port(&altera_jtaguart_driver, port);
> + ret = uart_add_one_port(&altera_jtaguart_driver, port);
> + if (ret) {
> + iounmap(port->membase);
> + port->membase = NULL;
Why is membase being set to NULL, that should not be needed, right?
How was this tested?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH tty v4 3/6] serial: sh-sci: Avoid deprecated UPF_CONS_FLOW
From: Greg Kroah-Hartman @ 2026-05-11 15:00 UTC (permalink / raw)
To: John Ogness
Cc: Geert Uytterhoeven, Jiri Slaby, Andy Shevchenko, linux-kernel,
Biju Das, Lad Prabhakar, Thierry Bultel, linux-serial,
Linux-sh list
In-Reply-To: <87v7d08ztd.fsf@jogness.linutronix.de>
On Wed, May 06, 2026 at 02:59:02PM +0206, John Ogness wrote:
> Hi Geert,
>
> On 2026-05-06, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >> --- a/drivers/tty/serial/sh-sci.c
> >> +++ b/drivers/tty/serial/sh-sci.c
> >> @@ -3369,9 +3369,12 @@ static int sci_init_single(struct platform_device *dev,
> >> }
> >>
> >> port->type = SCI_PUBLIC_PORT_ID(p->type);
> >> - port->flags = UPF_FIXED_PORT | UPF_BOOT_AUTOCONF | p->flags;
> >> + port->flags = UPF_FIXED_PORT | UPF_BOOT_AUTOCONF |
> >> + (p->flags & ~UPF_CONS_FLOW);
> >
> > This seems over-cautious to me.
> > The last setter of p->flags was removed in commit 37744feebc086908
> > ("sh: remove sh5 support") in v5.8. No platform data ever set the
> > UPF_CONS_FLOW flag before. I would rather remove plat_sci_port.flags
> > and this "| p->flags", so we don't have to care about UPF_CONS_FLOW
> > in this driver at all.
>
> If there is a v5, I will drop this patch. If v4 is acceptable, the
> maintainer can just drop this patch.
>
> I will leave the plat_sci_port.flags removal as an excercise for the sh
> folks.
Ah, this is what confused me. I've taken the first two patches here,
can you respin the rest on my branch and resend them?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH tty v4 0/6] 8250: Add console flow control
From: Greg Kroah-Hartman @ 2026-05-11 14:58 UTC (permalink / raw)
To: John Ogness
Cc: Jiri Slaby, Andy Shevchenko, linux-kernel, linux-serial,
Krzysztof Kozlowski, Alim Akhtar, David S. Miller,
Ilpo Järvinen, Andy Shevchenko, Thomas Fourier, Kees Cook,
linux-arm-kernel, linux-samsung-soc, sparclinux, Biju Das,
Geert Uytterhoeven, Lad Prabhakar, Thierry Bultel,
Osama Abdelkader, Ingo Molnar, Xin Zhao, Joseph Tilahun,
Krzysztof Kozlowski, Lukas Wunner, Dr. David Alan Gilbert
In-Reply-To: <20260506121606.5805-1-john.ogness@linutronix.de>
On Wed, May 06, 2026 at 02:21:55PM +0206, John Ogness wrote:
> Hi,
>
> This is v4 of a series to implement console flow control for the
> 8250 serial driver. v3 is here [0].
>
> The 8250 driver already has code in place to support console flow
> control. However, there is no way to activate it and it is
> incomplete. This series provides the necessary missing pieces while
> attempting to be as conservative as possible, so as not to introduce
> any side effects into the many 8250 variants or other non-8250 serial
> drivers.
This had some rejections in drivers/tty/serial/sh-sci.c, what
branch/tree did you make this against?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v7 0/4] rust: add basic serial device bus abstractions
From: Markus Probst @ 2026-05-11 14:54 UTC (permalink / raw)
To: Rob Herring
Cc: Greg Kroah-Hartman, Jiri Slaby, Miguel Ojeda, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Kari Argillander,
Rafael J. Wysocki, Viresh Kumar, Boqun Feng, David Airlie,
Simona Vetter, linux-serial, linux-kernel, rust-for-linux,
linux-pm, driver-core, dri-devel
In-Reply-To: <20260430195858.GA1650658-robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]
On Thu, 2026-04-30 at 14:58 -0500, Rob Herring wrote:
> On Wed, Apr 29, 2026 at 08:21:30PM +0200, Markus Probst wrote:
> > This patch series adds the serdev device bus rust abstraction into the
> > kernel.
> >
> > This abstraction will be used by a driver,
> > which targets the MCU devices in Synology devices.
> >
> > Kari Argillander also messaged me, stating that he wants to write a
> > watchdog driver with this abstraction (needing initial device data).
> >
> > @Rob: Are you willing to maintain these rust abstractions yourself,
> > as you are the expert on this subsystem, otherwise I would take care of
> > it with a "SERIAL DEVICE BUS [RUST]" section in the MAINTAINERS file. In
> > the second case, I assume you are going to pick those patches as-is into
> > your tree, after they have been reviewed?
>
> Well I can ignore the Rust part as much as I ignore the C serdev part...
> Honestly, I need to find someone else to maintain all of it as I don't
> really have the bandwidth. I don't think we should split it though.
I could maintain both C and Rust.
However my knowledge regarding the tty subsystem is very limited, so I
would need to heavily rely on kernel documentation.
Thanks
- Markus Probst
>
> And I don't have a tree for serdev. Greg picks up the serdev patches. If
> the Rust folks are fine with them, then I am.
>
> Rob
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH] tty: n_gsm: fix memory leak in gsm_activate_mux
From: Greg KH @ 2026-05-11 14:44 UTC (permalink / raw)
To: Minu Jin
Cc: jirislaby, daniel.starke, linux-kernel, linux-serial,
syzbot+b5d1f455d385b2c7da3c
In-Reply-To: <20260422183321.596414-1-s9430939@naver.com>
On Thu, Apr 23, 2026 at 03:33:21AM +0900, Minu Jin wrote:
> syzbot reported a memory leak in gsm_activate_mux().
> The root cause is a missing cleanup path when gsm_register_devices()
> fails. In this case, the previously allocated DLCI 0
> and its associated kfifo remain allocated, leading to a memory leak.
>
> And gsm_dlci_alloc() does not check for already allocated DLCIs.
> Repeated calls to gsm_activate_mux() would overwrite the existing pointer
> in gsm->dlci[addr], causing the original memory to be lost.
>
> Fix this by:
> 1. Adding gsm_dlci_free() in the error path of gsm_activate_mux().
> 2. Adding a check in gsm_dlci_alloc() to return the existing DLCI
> if it is already allocated.
>
> Reported-by: syzbot+b5d1f455d385b2c7da3c@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=b5d1f455d385b2c7da3c
> Tested-by: syzbot+b5d1f455d385b2c7da3c@syzkaller.appspotmail.com
> Fixes: 01aecd917114 ("tty: n_gsm: fix tty registration before control channel open")
> Signed-off-by: Minu Jin <s9430939@naver.com>
> ---
> drivers/tty/n_gsm.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
> index c13e050de83b..de3d30eac86e 100644
> --- a/drivers/tty/n_gsm.c
> +++ b/drivers/tty/n_gsm.c
> @@ -2645,7 +2645,12 @@ static int gsm_dlci_config(struct gsm_dlci *dlci, struct gsm_dlci_config *dc, in
>
> static struct gsm_dlci *gsm_dlci_alloc(struct gsm_mux *gsm, int addr)
> {
> - struct gsm_dlci *dlci = kzalloc_obj(struct gsm_dlci, GFP_ATOMIC);
> + struct gsm_dlci *dlci;
> +
> + if (gsm->dlci[addr])
> + return gsm->dlci[addr];
Why would you be allocating a device twice? Shouldn't that logic be
fixed instead?
> +
> + dlci = kzalloc_obj(struct gsm_dlci, GFP_ATOMIC);
> if (dlci == NULL)
> return NULL;
> spin_lock_init(&dlci->lock);
> @@ -3196,8 +3201,10 @@ static int gsm_activate_mux(struct gsm_mux *gsm)
> gsm->receive = gsm1_receive;
>
> ret = gsm_register_devices(gsm_tty_driver, gsm->num);
> - if (ret)
> + if (ret) {
> + gsm_dlci_free(&dlci->port);
> return ret;
> + }
How was this tested?
thanks,
greg k-h
^ permalink raw reply
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