* [GIT PULL] Serial driver fixes for 6.19-rc7
From: Greg KH @ 2026-01-25 15:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jiri Slaby, Stephen Rothwell, Andrew Morton, linux-kernel,
linux-serial
The following changes since commit f8f9c1f4d0c7a64600e2ca312dec824a0bc2f1da:
Linux 6.19-rc3 (2025-12-28 13:24:26 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-6.19-rc7
for you to fetch changes up to 32f37e57583f869140cff445feedeea8a5fea986:
serial: Fix not set tty->port race condition (2026-01-23 17:23:09 +0100)
----------------------------------------------------------------
Serial driver fixes for 6.19-rc7
Here are 3 small serial driver fixes for 6.19-rc7 that resolve some
reported issues. They include:
- tty->port race condition fix for a reported problem
- qcom_geni serial driver fix
- 8250_pci serial driver fix
All of these have been in linux-next with no reported issues
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Krzysztof Kozlowski (1):
serial: Fix not set tty->port race condition
Marnix Rijnart (1):
serial: 8250_pci: Fix broken RS485 for F81504/508/512
Praveen Talari (1):
serial: qcom_geni: Fix BT failure regression on RB2 platform
drivers/tty/serial/8250/8250_pci.c | 2 +-
drivers/tty/serial/qcom_geni_serial.c | 13 ++++++-------
drivers/tty/serial/serial_core.c | 6 ++++++
3 files changed, 13 insertions(+), 8 deletions(-)
^ permalink raw reply
* [tty:tty-linus] BUILD SUCCESS 32f37e57583f869140cff445feedeea8a5fea986
From: kernel test robot @ 2026-01-24 4:39 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: 32f37e57583f869140cff445feedeea8a5fea986 serial: Fix not set tty->port race condition
elapsed time: 730m
configs tested: 204
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
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-22
arc axs103_smp_defconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260124 clang-18
arc randconfig-002-20260124 clang-18
arm allnoconfig clang-22
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm gemini_defconfig gcc-15.2.0
arm imx_v4_v5_defconfig gcc-15.2.0
arm multi_v4t_defconfig clang-16
arm pxa168_defconfig clang-16
arm randconfig-001-20260124 clang-18
arm randconfig-002-20260124 clang-18
arm randconfig-003-20260124 clang-18
arm randconfig-004-20260124 clang-18
arm sama7_defconfig clang-16
arm spear3xx_defconfig gcc-15.2.0
arm versatile_defconfig gcc-15.2.0
arm vt8500_v6_v7_defconfig gcc-15.2.0
arm64 allmodconfig clang-22
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260124 gcc-15.2.0
arm64 randconfig-002-20260124 gcc-15.2.0
arm64 randconfig-003-20260124 gcc-15.2.0
arm64 randconfig-004-20260124 gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260124 gcc-15.2.0
csky randconfig-002-20260124 gcc-15.2.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-22
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260124 gcc-15.2.0
hexagon randconfig-002-20260124 gcc-15.2.0
i386 alldefconfig clang-16
i386 allmodconfig clang-20
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260124 gcc-14
i386 buildonly-randconfig-002-20260124 gcc-14
i386 buildonly-randconfig-003-20260124 gcc-14
i386 buildonly-randconfig-004-20260124 gcc-14
i386 buildonly-randconfig-005-20260124 gcc-14
i386 buildonly-randconfig-006-20260124 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260124 gcc-14
i386 randconfig-002-20260124 gcc-14
i386 randconfig-003-20260124 gcc-14
i386 randconfig-004-20260124 gcc-14
i386 randconfig-005-20260124 gcc-14
i386 randconfig-006-20260124 gcc-14
i386 randconfig-007-20260124 gcc-14
i386 randconfig-011-20260124 clang-20
i386 randconfig-012-20260124 clang-20
i386 randconfig-013-20260124 clang-20
i386 randconfig-014-20260124 clang-20
i386 randconfig-015-20260124 clang-20
i386 randconfig-016-20260124 clang-20
i386 randconfig-017-20260124 clang-20
loongarch allmodconfig clang-22
loongarch allnoconfig clang-22
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260124 gcc-15.2.0
loongarch randconfig-002-20260124 gcc-15.2.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
m68k m5475evb_defconfig gcc-15.2.0
m68k virt_defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips malta_qemu_32r6_defconfig clang-16
mips maltasmvp_eva_defconfig gcc-15.2.0
mips maltaup_defconfig gcc-15.2.0
mips maltaup_xpa_defconfig gcc-15.2.0
mips qi_lb60_defconfig clang-16
nios2 allmodconfig clang-22
nios2 allnoconfig clang-22
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260124 gcc-15.2.0
nios2 randconfig-002-20260124 gcc-15.2.0
openrisc allmodconfig clang-22
openrisc allnoconfig clang-22
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-22
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260124 gcc-8.5.0
parisc randconfig-002-20260124 gcc-8.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-22
powerpc allnoconfig gcc-15.2.0
powerpc motionpro_defconfig gcc-15.2.0
powerpc ppa8548_defconfig gcc-15.2.0
powerpc randconfig-001-20260124 gcc-8.5.0
powerpc randconfig-002-20260124 gcc-8.5.0
powerpc64 randconfig-001-20260124 gcc-8.5.0
powerpc64 randconfig-002-20260124 gcc-8.5.0
riscv allmodconfig clang-22
riscv allnoconfig clang-22
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260124 gcc-8.5.0
riscv randconfig-002-20260124 gcc-8.5.0
s390 allmodconfig clang-19
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260124 gcc-8.5.0
s390 randconfig-002-20260124 gcc-8.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-22
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh defconfig gcc-14
sh edosk7705_defconfig gcc-15.2.0
sh r7780mp_defconfig clang-16
sh randconfig-001-20260124 gcc-8.5.0
sh randconfig-002-20260124 gcc-8.5.0
sh secureedge5410_defconfig clang-16
sparc allnoconfig clang-22
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260124 gcc-13.4.0
sparc randconfig-002-20260124 gcc-13.4.0
sparc sparc64_defconfig gcc-15.2.0
sparc64 allmodconfig clang-22
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260124 gcc-13.4.0
sparc64 randconfig-002-20260124 gcc-13.4.0
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260124 gcc-13.4.0
um randconfig-002-20260124 gcc-13.4.0
um x86_64_defconfig gcc-14
x86_64 alldefconfig gcc-15.2.0
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260124 clang-20
x86_64 buildonly-randconfig-002-20260124 clang-20
x86_64 buildonly-randconfig-003-20260124 clang-20
x86_64 buildonly-randconfig-004-20260124 clang-20
x86_64 buildonly-randconfig-005-20260124 clang-20
x86_64 buildonly-randconfig-006-20260124 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260124 gcc-13
x86_64 randconfig-002-20260124 gcc-13
x86_64 randconfig-003-20260124 gcc-13
x86_64 randconfig-004-20260124 gcc-13
x86_64 randconfig-005-20260124 gcc-13
x86_64 randconfig-006-20260124 gcc-13
x86_64 randconfig-011-20260124 gcc-12
x86_64 randconfig-012-20260124 gcc-12
x86_64 randconfig-013-20260124 gcc-12
x86_64 randconfig-014-20260124 gcc-12
x86_64 randconfig-015-20260124 gcc-12
x86_64 randconfig-016-20260124 gcc-12
x86_64 randconfig-071-20260124 gcc-14
x86_64 randconfig-072-20260124 gcc-14
x86_64 randconfig-073-20260124 gcc-14
x86_64 randconfig-074-20260124 gcc-14
x86_64 randconfig-075-20260124 gcc-14
x86_64 randconfig-076-20260124 gcc-14
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-22
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-22
xtensa randconfig-001-20260124 gcc-13.4.0
xtensa randconfig-002-20260124 gcc-13.4.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [tty:tty-testing] BUILD SUCCESS d000422a46aad32217cf1be747eb61d641baae2f
From: kernel test robot @ 2026-01-24 4:38 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: d000422a46aad32217cf1be747eb61d641baae2f tty: tty_port: add workqueue to flip TTY buffer
elapsed time: 729m
configs tested: 204
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
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-22
arc axs103_smp_defconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260124 clang-18
arc randconfig-002-20260124 clang-18
arm allnoconfig clang-22
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm gemini_defconfig gcc-15.2.0
arm imx_v4_v5_defconfig gcc-15.2.0
arm multi_v4t_defconfig clang-16
arm pxa168_defconfig clang-16
arm randconfig-001-20260124 clang-18
arm randconfig-002-20260124 clang-18
arm randconfig-003-20260124 clang-18
arm randconfig-004-20260124 clang-18
arm sama7_defconfig clang-16
arm spear3xx_defconfig gcc-15.2.0
arm versatile_defconfig gcc-15.2.0
arm vt8500_v6_v7_defconfig gcc-15.2.0
arm64 allmodconfig clang-22
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260124 gcc-15.2.0
arm64 randconfig-002-20260124 gcc-15.2.0
arm64 randconfig-003-20260124 gcc-15.2.0
arm64 randconfig-004-20260124 gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260124 gcc-15.2.0
csky randconfig-002-20260124 gcc-15.2.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-22
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260124 gcc-15.2.0
hexagon randconfig-002-20260124 gcc-15.2.0
i386 alldefconfig clang-16
i386 allmodconfig clang-20
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260124 gcc-14
i386 buildonly-randconfig-002-20260124 gcc-14
i386 buildonly-randconfig-003-20260124 gcc-14
i386 buildonly-randconfig-004-20260124 gcc-14
i386 buildonly-randconfig-005-20260124 gcc-14
i386 buildonly-randconfig-006-20260124 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260124 gcc-14
i386 randconfig-002-20260124 gcc-14
i386 randconfig-003-20260124 gcc-14
i386 randconfig-004-20260124 gcc-14
i386 randconfig-005-20260124 gcc-14
i386 randconfig-006-20260124 gcc-14
i386 randconfig-007-20260124 gcc-14
i386 randconfig-011-20260124 clang-20
i386 randconfig-012-20260124 clang-20
i386 randconfig-013-20260124 clang-20
i386 randconfig-014-20260124 clang-20
i386 randconfig-015-20260124 clang-20
i386 randconfig-016-20260124 clang-20
i386 randconfig-017-20260124 clang-20
loongarch allmodconfig clang-22
loongarch allnoconfig clang-22
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260124 gcc-15.2.0
loongarch randconfig-002-20260124 gcc-15.2.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
m68k m5475evb_defconfig gcc-15.2.0
m68k virt_defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips malta_qemu_32r6_defconfig clang-16
mips maltasmvp_eva_defconfig gcc-15.2.0
mips maltaup_defconfig gcc-15.2.0
mips maltaup_xpa_defconfig gcc-15.2.0
mips qi_lb60_defconfig clang-16
nios2 allmodconfig clang-22
nios2 allnoconfig clang-22
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260124 gcc-15.2.0
nios2 randconfig-002-20260124 gcc-15.2.0
openrisc allmodconfig clang-22
openrisc allnoconfig clang-22
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-22
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260124 gcc-8.5.0
parisc randconfig-002-20260124 gcc-8.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-22
powerpc allnoconfig gcc-15.2.0
powerpc motionpro_defconfig gcc-15.2.0
powerpc ppa8548_defconfig gcc-15.2.0
powerpc randconfig-001-20260124 gcc-8.5.0
powerpc randconfig-002-20260124 gcc-8.5.0
powerpc64 randconfig-001-20260124 gcc-8.5.0
powerpc64 randconfig-002-20260124 gcc-8.5.0
riscv allmodconfig clang-22
riscv allnoconfig clang-22
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260124 gcc-8.5.0
riscv randconfig-002-20260124 gcc-8.5.0
s390 allmodconfig clang-19
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260124 gcc-8.5.0
s390 randconfig-002-20260124 gcc-8.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-22
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh defconfig gcc-14
sh edosk7705_defconfig gcc-15.2.0
sh r7780mp_defconfig clang-16
sh randconfig-001-20260124 gcc-8.5.0
sh randconfig-002-20260124 gcc-8.5.0
sh secureedge5410_defconfig clang-16
sparc allnoconfig clang-22
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260124 gcc-13.4.0
sparc randconfig-002-20260124 gcc-13.4.0
sparc sparc64_defconfig gcc-15.2.0
sparc64 allmodconfig clang-22
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260124 gcc-13.4.0
sparc64 randconfig-002-20260124 gcc-13.4.0
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260124 gcc-13.4.0
um randconfig-002-20260124 gcc-13.4.0
um x86_64_defconfig gcc-14
x86_64 alldefconfig gcc-15.2.0
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260124 clang-20
x86_64 buildonly-randconfig-002-20260124 clang-20
x86_64 buildonly-randconfig-003-20260124 clang-20
x86_64 buildonly-randconfig-004-20260124 clang-20
x86_64 buildonly-randconfig-005-20260124 clang-20
x86_64 buildonly-randconfig-006-20260124 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260124 gcc-13
x86_64 randconfig-002-20260124 gcc-13
x86_64 randconfig-003-20260124 gcc-13
x86_64 randconfig-004-20260124 gcc-13
x86_64 randconfig-005-20260124 gcc-13
x86_64 randconfig-006-20260124 gcc-13
x86_64 randconfig-011-20260124 gcc-12
x86_64 randconfig-012-20260124 gcc-12
x86_64 randconfig-013-20260124 gcc-12
x86_64 randconfig-014-20260124 gcc-12
x86_64 randconfig-015-20260124 gcc-12
x86_64 randconfig-016-20260124 gcc-12
x86_64 randconfig-071-20260124 gcc-14
x86_64 randconfig-072-20260124 gcc-14
x86_64 randconfig-073-20260124 gcc-14
x86_64 randconfig-074-20260124 gcc-14
x86_64 randconfig-075-20260124 gcc-14
x86_64 randconfig-076-20260124 gcc-14
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-22
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-22
xtensa randconfig-001-20260124 gcc-13.4.0
xtensa randconfig-002-20260124 gcc-13.4.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 6/6] serial: 8250_dw: Ensure BUSY is deasserted
From: Andy Shevchenko @ 2026-01-23 22:42 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Greg Kroah-Hartman, Jiri Slaby, linux-serial, qianfan Zhao,
Adriana Nicolae, Markus Mayer, Tim Kryger, Matt Porter,
Heikki Krogerus, Jamie Iles, linux-kernel, stable,
Bandal, Shankar, Murthy, Shanth
In-Reply-To: <20260123172739.13410-7-ilpo.jarvinen@linux.intel.com>
On Fri, Jan 23, 2026 at 07:27:39PM +0200, Ilpo Järvinen wrote:
> DW UART cannot write to LCR, DLL, and DLH while BUSY is asserted.
> Existance of BUSY depends on uart_16550_compatible, if UART HW is
> configured with 16550 compatible those registers can always be written.
with 16550 compatible --> with it
> There currently is dw8250_force_idle() which attempts to archive
> non-BUSY state by disabling FIFO, however, the solution is unreliable
> when Rx keeps getting more and more characters.
>
> Create a sequence of operations to enforce that ensures UART cannot
> keep BUSY asserted indefinitely. The new sequence relies on enabling
> loopback mode temporarily to prevent incoming Rx characters keeping
> UART BUSY.
What if UART was already in a loopback mode? I assume that Tx pause
described below should not affect the case.
The real case scenario that I am thinking of is a stress test of UART
using loopback mode.
> Ensure no Tx in ongoing while the UART is switches into the loopback
> mode (requires exporting serial8250_fifo_wait_for_lsr_thre() and adding
> DMA Tx pause/resume functions).
>
> According to tests performed by Adriana Nicolae <adriana@arista.com>,
> simply disabling FIFO or clearing FIFOs only once does not always
> ensure BUSY is deasserted but up to two tries may be needed. This could
> be related to ongoing Rx of a character (a guess, not known for sure).
Sounds like a plausible theory because UART has shift registers that are
working independently on the current situation with FIFO. They are actual
frontends for Tx and Rx data on the wire.
> Therefore, retry FIFO clearing a few times (retry limit 4 is arbitrary
> number but using, e.g., p->fifosize seems overly large). Tests
> performed by others did not exhibit similar challenge but it does not
> seem harmful to leave the FIFO clearing loop in place for all DW UARTs
> with BUSY functionality.
>
> Use the new dw8250_idle_enter/exit() to do divisor writes and LCR
> writes. In case of plain LCR writes, opportunistically try to update
> LCR first and only invoke dw8250_idle_enter() if the write did not
> succeed (it has been observed that in practice most LCR writes do
> succeed without complications).
>
> This issue was first reported by qianfan Zhao who put lots of debugging
> effort into understanding the solution space.
...
> + /* Prevent triggering interrupt from RBR filling */
> + p->serial_out(p, UART_IER, 0);
Do we specifically use callbacks directly and not wrappers all over the change?
...
> + serial8250_fifo_wait_for_lsr_thre(up, p->fifosize);
> + ndelay(p->frame_time);
Wouldn't be a problem on lowest baud rates (exempli gratia 110)?
...
> + retries = 4; /* Arbitrary limit, 2 was always enough in tests */
> + do {
> + serial8250_clear_fifos(up);
> + if (!(p->serial_in(p, usr_reg) & DW_UART_USR_BUSY))
> + break;
> + ndelay(p->frame_time);
> + } while (--retries);
read_poll_timeout_atomic() ? I assume it can't be used due to small frame time?
...
> + if (d->in_idle) {
> + /*
> + * FIXME: this deadlocks if port->lock is already held
> + * dev_err(p->dev, "Couldn't set LCR to %d\n", value);
> + */
Hmm... That FIXME should gone since we have non-blocking consoles, no?
> + return;
> + }
...
> + ret = dw8250_idle_enter(p);
> + if (ret < 0) {
> + /*
> + * FIXME: this deadlocks if port->lock is already held
> + * dev_err(p->dev, "Couldn't set LCR to %d\n", value);
> + */
> + goto idle_failed;
> }
> - /*
> - * FIXME: this deadlocks if port->lock is already held
> - * dev_err(p->dev, "Couldn't set LCR to %d\n", value);
> - */
Ditto.
> }
...
> p->dev = dev;
Maybe put an added line here?
> p->set_ldisc = dw8250_set_ldisc;
> p->set_termios = dw8250_set_termios;
> + p->set_divisor = dw8250_set_divisor;
...
> +EXPORT_SYMBOL_GPL(serial8250_clear_fifos);
Same Q, perhaps start exporting with a namespace?
> }
> EXPORT_SYMBOL_GPL(serial8250_set_defaults);
...
> +void serial8250_fifo_wait_for_lsr_thre(struct uart_8250_port *up, unsigned int count)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < count; i++) {
while (count--) ?
Ah, it's existing code... OK then.
> + if (wait_for_lsr(up, UART_LSR_THRE))
> + return;
> + }
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 4/6] serial: 8250_dw: Rework IIR_NO_INT handling to stop interrupt storm
From: Andy Shevchenko @ 2026-01-23 22:13 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Greg Kroah-Hartman, Jiri Slaby, linux-serial, qianfan Zhao,
Adriana Nicolae, linux-kernel, Bandal, Shankar, Murthy, Shanth
In-Reply-To: <20260123172739.13410-5-ilpo.jarvinen@linux.intel.com>
On Fri, Jan 23, 2026 at 07:27:37PM +0200, Ilpo Järvinen wrote:
> INTC10EE UART can end up into an interrupt storm where it reports
> IIR_NO_INT (0x1). If the storm happens during active UART operation, it
> is promptly stopped by IIR value change due to Rx or Tx events.
> However, when there is no activity, either due to idle serial line or
> due to specific circumstances such as during shutdown that writes
> IER=0, there is nothing to stop the storm.
>
> During shutdown the storm is particularly problematic because
> serial8250_do_shutdown() calls synchronize_irq() that will hang in
> waiting for the storm to finish which never happens.
>
> This problem can also result in triggering a warning:
>
> irq 45: nobody cared (try booting with the "irqpoll" option)
> [...snip...]
> handlers:
> serial8250_interrupt
> Disabling IRQ #45
>
> Normal means to reset interrupt status by reading LSR, MSR, USR, or RX
> register do not result in the UART deasserting the IRQ.
>
> Add a quirk to INTC10EE UARTs to enable Tx interrupts if UART's Tx is
> currently empty and inactive. Rework IIR_NO_INT to keep track of the
> number of consecutive IIR_NO_INT, and on third one perform the quirk.
> Enabling Tx interrupts should change IIR value from IIR_NO_INT to
> IIR_THRI which has been observed to stop the storm.
...
> + u64 no_int_count;
Why so big?
...
> + d->no_int_count++;
> + if (d->no_int_count > 2 && quirks & DW_UART_QUIRK_IER_KICK)
> + dw8250_quirk_ier_kick(p);
Usual way is to use modulo. And perhaps use 4 for the sake of avoiding
division:
if (d->no_int_count == 3 && quirks & DW_UART_QUIRK_IER_KICK)
dw8250_quirk_ier_kick(p);
d->no_int_count = (d->no_int_count + 1) % 4;
where 4 may be defined with meaningful name. With that u8 is more than enough.
> return 0;
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 3/6] serial: 8250_dw: Rework dw8250_handle_irq() locking and IIR handling
From: Andy Shevchenko @ 2026-01-23 22:05 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Greg Kroah-Hartman, Jiri Slaby, linux-serial, qianfan Zhao,
Adriana Nicolae, linux-kernel, Bandal, Shankar, Murthy, Shanth
In-Reply-To: <20260123172739.13410-4-ilpo.jarvinen@linux.intel.com>
On Fri, Jan 23, 2026 at 07:27:36PM +0200, Ilpo Järvinen wrote:
> dw8250_handle_irq() takes port's lock multiple times with no good
> reason to release it in between and calls serial8250_handle_irq()
> that also takes port's lock.
>
> As serial8250_handle_irq() takes port's lock itself, create
> serial8250_handle_irq_locked() that allows caller to hold port's lock
> across the call. Take port's lock only once in dw8250_handle_irq() and
> call serial8250_handle_irq_locked() directly.
Sounds to me that the latter can be split to a prerequisite patch.
> As IIR_NO_INT check in serial8250_handle_irq() was outside of port's
> lock, it has to be done already in dw8250_handle_irq().
>
> DW UART can, in addition to IIR_NO_INT, report BUSY_DETECT (0x7) which
> collided with the IIR_NO_INT (0x1) check in serial8250_handle_irq()
> (because & is used instead of ==) meaning that no other work is done by
> serial8250_handle_irq() during an BUSY_DETECT interrupt.
>
> This allows reorganizing code in dw8250_handle_irq() to do both
> IIR_NO_INT and BUSY_DETECT handling right at the start simplifying
> the logic.
...
> +#include <linux/bitfield.h>
> +#include <linux/bits.h>
+ cleanup.h
> #include <linux/clk.h>
> #include <linux/delay.h>
> #include <linux/device.h>
...
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> #include <linux/ioport.h>
> #include <linux/init.h>
> #include <linux/irq.h>
> +#include <linux/lockdep.h>
I would still keep more order.
> #include <linux/console.h>
> #include <linux/gpio/consumer.h>
Giving the context we have, the better place for a new inclusion is somewhere
here.
> #include <linux/sysrq.h>
(Also perhaps sorting headers in a separate patch helps with finding better
places for the future inclusions?)
...
> +EXPORT_SYMBOL_GPL(serial8250_handle_irq_locked);
Wondering if we can start exporting with a namespace...
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 2/6] serial: 8250_dw: Avoid unnecessary LCR writes
From: Andy Shevchenko @ 2026-01-23 21:41 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Greg Kroah-Hartman, Jiri Slaby, linux-serial, qianfan Zhao,
Adriana Nicolae, linux-kernel, Bandal, Shankar, Murthy, Shanth
In-Reply-To: <20260123172739.13410-3-ilpo.jarvinen@linux.intel.com>
On Fri, Jan 23, 2026 at 07:27:35PM +0200, Ilpo Järvinen wrote:
> When DW UART is configured with BUSY flag, LCR writes may not always
> succeed which can make any LCR write complex and very expensive.
> Performing write directly can trigger IRQ and the driver has to perform
> complex and distruptive sequence while retrying the write.
>
> Therefore, it's better to avoid doing LCR write that would not change
> the value of the LCR register. Add LCR write avoidance code into the
> 8250_dw driver's serial_out functions.
.serial_out() ?
...
> +/*
> + * With BUSY, LCR writes can be very expensive (IRQ + complex retry logic).
> + * If the write would not change the value of the LCR register, skip write
would --> does
skip write --> skip it
> + * entirely.
> + */
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 6/6] serial: 8250_dw: Ensure BUSY is deasserted
From: Ilpo Järvinen @ 2026-01-23 17:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, linux-serial, Andy Shevchenko,
qianfan Zhao, Adriana Nicolae, Ilpo Järvinen, Markus Mayer,
Tim Kryger, Matt Porter, Heikki Krogerus, Jamie Iles,
linux-kernel
Cc: stable, Bandal, Shankar, Murthy, Shanth
In-Reply-To: <20260123172739.13410-1-ilpo.jarvinen@linux.intel.com>
DW UART cannot write to LCR, DLL, and DLH while BUSY is asserted.
Existance of BUSY depends on uart_16550_compatible, if UART HW is
configured with 16550 compatible those registers can always be written.
There currently is dw8250_force_idle() which attempts to archive
non-BUSY state by disabling FIFO, however, the solution is unreliable
when Rx keeps getting more and more characters.
Create a sequence of operations to enforce that ensures UART cannot
keep BUSY asserted indefinitely. The new sequence relies on enabling
loopback mode temporarily to prevent incoming Rx characters keeping
UART BUSY.
Ensure no Tx in ongoing while the UART is switches into the loopback
mode (requires exporting serial8250_fifo_wait_for_lsr_thre() and adding
DMA Tx pause/resume functions).
According to tests performed by Adriana Nicolae <adriana@arista.com>,
simply disabling FIFO or clearing FIFOs only once does not always
ensure BUSY is deasserted but up to two tries may be needed. This could
be related to ongoing Rx of a character (a guess, not known for sure).
Therefore, retry FIFO clearing a few times (retry limit 4 is arbitrary
number but using, e.g., p->fifosize seems overly large). Tests
performed by others did not exhibit similar challenge but it does not
seem harmful to leave the FIFO clearing loop in place for all DW UARTs
with BUSY functionality.
Use the new dw8250_idle_enter/exit() to do divisor writes and LCR
writes. In case of plain LCR writes, opportunistically try to update
LCR first and only invoke dw8250_idle_enter() if the write did not
succeed (it has been observed that in practice most LCR writes do
succeed without complications).
This issue was first reported by qianfan Zhao who put lots of debugging
effort into understanding the solution space.
Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround")
Fixes: 7d4008ebb1c9 ("tty: add a DesignWare 8250 driver")
Cc: <stable@vger.kernel.org>
Reported-by: qianfan Zhao <qianfanguijin@163.com>
Link: https://lore.kernel.org/linux-serial/289bb78a-7509-1c5c-2923-a04ed3b6487d@163.com/
Reported-by: Adriana Nicolae <adriana@arista.com>
Link: https://lore.kernel.org/linux-serial/20250819182322.3451959-1-adriana@arista.com/
Reported-by: "Bandal, Shankar" <shankar.bandal@intel.com>
Tested-by: "Bandal, Shankar" <shankar.bandal@intel.com>
Tested-by: "Murthy, Shanth" <shanth.murthy@intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
drivers/tty/serial/8250/8250.h | 25 ++++
drivers/tty/serial/8250/8250_dw.c | 172 ++++++++++++++++++++--------
drivers/tty/serial/8250/8250_port.c | 28 ++---
3 files changed, 166 insertions(+), 59 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 8caecfc85d93..77fe0588fd6b 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -175,7 +175,9 @@ static unsigned int __maybe_unused serial_icr_read(struct uart_8250_port *up,
return value;
}
+void serial8250_clear_fifos(struct uart_8250_port *p);
void serial8250_clear_and_reinit_fifos(struct uart_8250_port *p);
+void serial8250_fifo_wait_for_lsr_thre(struct uart_8250_port *up, unsigned int count);
void serial8250_rpm_get(struct uart_8250_port *p);
void serial8250_rpm_put(struct uart_8250_port *p);
@@ -400,6 +402,26 @@ static inline bool serial8250_tx_dma_running(struct uart_8250_port *p)
return dma && dma->tx_running;
}
+
+static inline void serial8250_tx_dma_pause(struct uart_8250_port *p)
+{
+ struct uart_8250_dma *dma = p->dma;
+
+ if (!dma->tx_running)
+ return;
+
+ dmaengine_pause(dma->txchan);
+}
+
+static inline void serial8250_tx_dma_resume(struct uart_8250_port *p)
+{
+ struct uart_8250_dma *dma = p->dma;
+
+ if (!dma->tx_running)
+ return;
+
+ dmaengine_resume(dma->txchan);
+}
#else
static inline int serial8250_tx_dma(struct uart_8250_port *p)
{
@@ -421,6 +443,9 @@ static inline bool serial8250_tx_dma_running(struct uart_8250_port *p)
{
return false;
}
+
+static inline void serial8250_tx_dma_pause(struct uart_8250_port *p) { }
+static inline void serial8250_tx_dma_resume(struct uart_8250_port *p) { }
#endif
static inline int ns16550a_goto_highspeed(struct uart_8250_port *up)
diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
index a40c0851f39c..8166ed15fd08 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -15,6 +15,7 @@
#include <linux/delay.h>
#include <linux/device.h>
#include <linux/io.h>
+#include <linux/lockdep.h>
#include <linux/mod_devicetable.h>
#include <linux/module.h>
#include <linux/notifier.h>
@@ -46,6 +47,8 @@
#define DW_UART_MCR_SIRE BIT(6)
+#define DW_UART_USR_BUSY BIT(0)
+
/* Renesas specific register fields */
#define RZN1_UART_xDMACR_DMA_EN BIT(0)
#define RZN1_UART_xDMACR_1_WORD_BURST (0 << 1)
@@ -82,6 +85,7 @@ struct dw8250_data {
unsigned int skip_autocfg:1;
unsigned int uart_16550_compatible:1;
+ unsigned int in_idle:1;
u64 no_int_count;
};
@@ -115,77 +119,152 @@ static inline u32 dw8250_modify_msr(struct uart_port *p, unsigned int offset, u3
}
/*
- * This function is being called as part of the uart_port::serial_out()
- * routine. Hence, it must not call serial_port_out() or serial_out()
- * against the modified registers here, i.e. LCR.
+ * Ensure BUSY is not asserted. If DW UART is configured with
+ * !uart_16550_compatible, the writes to LCR, DLL, and DLH fail while
+ * BUSY is asserted.
+ *
+ * Context: port's lock must be held
*/
-static void dw8250_force_idle(struct uart_port *p)
+static int dw8250_idle_enter(struct uart_port *p)
{
+ struct dw8250_data *d = to_dw8250_data(p->private_data);
struct uart_8250_port *up = up_to_u8250p(p);
- unsigned int lsr;
+ unsigned int usr_reg = DW_UART_USR;
+ int retries;
+ u32 lsr;
- /*
- * The following call currently performs serial_out()
- * against the FCR register. Because it differs to LCR
- * there will be no infinite loop, but if it ever gets
- * modified, we might need a new custom version of it
- * that avoids infinite recursion.
- */
- serial8250_clear_and_reinit_fifos(up);
+ lockdep_assert_held_once(&p->lock);
+
+ if (d->uart_16550_compatible)
+ return 0;
+
+ if (d->pdata)
+ usr_reg = d->pdata->usr_reg;
+
+ d->in_idle = 1;
+
+ /* Prevent triggering interrupt from RBR filling */
+ p->serial_out(p, UART_IER, 0);
+
+ if (up->dma) {
+ serial8250_rx_dma_flush(up);
+ if (serial8250_tx_dma_running(up))
+ serial8250_tx_dma_pause(up);
+ }
/*
- * With PSLVERR_RESP_EN parameter set to 1, the device generates an
- * error response when an attempt to read an empty RBR with FIFO
- * enabled.
+ * Wait until Tx becomes empty + one extra frame time to ensure all bits
+ * have been sent on the wire.
*/
- if (up->fcr & UART_FCR_ENABLE_FIFO) {
- lsr = serial_port_in(p, UART_LSR);
- if (!(lsr & UART_LSR_DR))
- return;
+ serial8250_fifo_wait_for_lsr_thre(up, p->fifosize);
+ ndelay(p->frame_time);
+
+ p->serial_out(p, UART_MCR, up->mcr | UART_MCR_LOOP);
+
+ retries = 4; /* Arbitrary limit, 2 was always enough in tests */
+ do {
+ serial8250_clear_fifos(up);
+ if (!(p->serial_in(p, usr_reg) & DW_UART_USR_BUSY))
+ break;
+ ndelay(p->frame_time);
+ } while (--retries);
+
+ lsr = serial_lsr_in(up);
+ if (lsr & UART_LSR_DR) {
+ p->serial_in(p, UART_RX);
+ up->lsr_saved_flags = 0;
}
- serial_port_in(p, UART_RX);
+ /* Now guaranteed to have BUSY deasserted? Just sanity check */
+ if (p->serial_in(p, usr_reg) & DW_UART_USR_BUSY)
+ return -EBUSY;
+
+ return 0;
+}
+
+static void dw8250_idle_exit(struct uart_port *p)
+{
+ struct dw8250_data *d = to_dw8250_data(p->private_data);
+ struct uart_8250_port *up = up_to_u8250p(p);
+
+ if (d->uart_16550_compatible)
+ return;
+
+ if (up->capabilities & UART_CAP_FIFO)
+ p->serial_out(p, UART_FCR, up->fcr);
+ p->serial_out(p, UART_MCR, up->mcr);
+ p->serial_out(p, UART_IER, up->ier);
+
+ /* DMA Rx is restarted by IRQ handler as needed. */
+ if (up->dma)
+ serial8250_tx_dma_resume(up);
+
+ d->in_idle = 0;
+}
+
+static void dw8250_set_divisor(struct uart_port *p, unsigned int baud,
+ unsigned int quot, unsigned int quot_frac)
+{
+ struct uart_8250_port *up = up_to_u8250p(p);
+ int ret;
+
+ ret = dw8250_idle_enter(p);
+ if (ret < 0)
+ goto idle_failed;
+
+ p->serial_out(p, UART_LCR, up->lcr | UART_LCR_DLAB);
+ if (!(p->serial_in(p, UART_LCR) & UART_LCR_DLAB))
+ goto idle_failed;
+
+ serial_dl_write(up, quot);
+ p->serial_out(p, UART_LCR, up->lcr);
+
+idle_failed:
+ dw8250_idle_exit(p);
}
/*
* This function is being called as part of the uart_port::serial_out()
- * routine. Hence, it must not call serial_port_out() or serial_out()
- * against the modified registers here, i.e. LCR.
+ * routine. Hence, special care must be taken when serial_port_out() or
+ * serial_out() against the modified registers here, i.e. LCR (d->in_idle is
+ * used to break recursion loop).
*/
static void dw8250_check_lcr(struct uart_port *p, unsigned int offset, u32 value)
{
struct dw8250_data *d = to_dw8250_data(p->private_data);
- void __iomem *addr = p->membase + (offset << p->regshift);
- int tries = 1000;
+ u32 lcr;
+ int ret;
if (offset != UART_LCR || d->uart_16550_compatible)
return;
- /* Make sure LCR write wasn't ignored */
- while (tries--) {
- u32 lcr = serial_port_in(p, offset);
+ lcr = p->serial_in(p, UART_LCR);
- if ((value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR))
- return;
+ /* Make sure LCR write wasn't ignored */
+ if ((value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR))
+ return;
- dw8250_force_idle(p);
+ if (d->in_idle) {
+ /*
+ * FIXME: this deadlocks if port->lock is already held
+ * dev_err(p->dev, "Couldn't set LCR to %d\n", value);
+ */
+ return;
+ }
-#ifdef CONFIG_64BIT
- if (p->type == PORT_OCTEON)
- __raw_writeq(value & 0xff, addr);
- else
-#endif
- if (p->iotype == UPIO_MEM32)
- writel(value, addr);
- else if (p->iotype == UPIO_MEM32BE)
- iowrite32be(value, addr);
- else
- writeb(value, addr);
+ ret = dw8250_idle_enter(p);
+ if (ret < 0) {
+ /*
+ * FIXME: this deadlocks if port->lock is already held
+ * dev_err(p->dev, "Couldn't set LCR to %d\n", value);
+ */
+ goto idle_failed;
}
- /*
- * FIXME: this deadlocks if port->lock is already held
- * dev_err(p->dev, "Couldn't set LCR to %d\n", value);
- */
+
+ p->serial_out(p, UART_LCR, value);
+
+idle_failed:
+ dw8250_idle_exit(p);
}
/*
@@ -627,6 +706,7 @@ static int dw8250_probe(struct platform_device *pdev)
p->dev = dev;
p->set_ldisc = dw8250_set_ldisc;
p->set_termios = dw8250_set_termios;
+ p->set_divisor = dw8250_set_divisor;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index fa982e5cbe90..d5ea0f08a854 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -489,7 +489,7 @@ serial_port_out_sync(struct uart_port *p, int offset, int value)
/*
* FIFO support.
*/
-static void serial8250_clear_fifos(struct uart_8250_port *p)
+void serial8250_clear_fifos(struct uart_8250_port *p)
{
if (p->capabilities & UART_CAP_FIFO) {
serial_out(p, UART_FCR, UART_FCR_ENABLE_FIFO);
@@ -498,6 +498,7 @@ static void serial8250_clear_fifos(struct uart_8250_port *p)
serial_out(p, UART_FCR, 0);
}
}
+EXPORT_SYMBOL_GPL(serial8250_clear_fifos);
static enum hrtimer_restart serial8250_em485_handle_start_tx(struct hrtimer *t);
static enum hrtimer_restart serial8250_em485_handle_stop_tx(struct hrtimer *t);
@@ -3200,6 +3201,17 @@ void serial8250_set_defaults(struct uart_8250_port *up)
}
EXPORT_SYMBOL_GPL(serial8250_set_defaults);
+void serial8250_fifo_wait_for_lsr_thre(struct uart_8250_port *up, unsigned int count)
+{
+ unsigned int i;
+
+ for (i = 0; i < count; i++) {
+ if (wait_for_lsr(up, UART_LSR_THRE))
+ return;
+ }
+}
+EXPORT_SYMBOL_GPL(serial8250_fifo_wait_for_lsr_thre);
+
#ifdef CONFIG_SERIAL_8250_CONSOLE
static void serial8250_console_putchar(struct uart_port *port, unsigned char ch)
@@ -3241,16 +3253,6 @@ static void serial8250_console_restore(struct uart_8250_port *up)
serial8250_out_MCR(up, up->mcr | UART_MCR_DTR | UART_MCR_RTS);
}
-static void fifo_wait_for_lsr(struct uart_8250_port *up, unsigned int count)
-{
- unsigned int i;
-
- for (i = 0; i < count; i++) {
- if (wait_for_lsr(up, UART_LSR_THRE))
- return;
- }
-}
-
/*
* Print a string to the serial port using the device FIFO
*
@@ -3269,7 +3271,7 @@ static void serial8250_console_fifo_write(struct uart_8250_port *up,
while (s != end) {
/* Allow timeout for each byte of a possibly full FIFO */
- fifo_wait_for_lsr(up, fifosize);
+ serial8250_fifo_wait_for_lsr_thre(up, fifosize);
for (i = 0; i < fifosize && s != end; ++i) {
if (*s == '\n' && !cr_sent) {
@@ -3287,7 +3289,7 @@ static void serial8250_console_fifo_write(struct uart_8250_port *up,
* Allow timeout for each byte written since the caller will only wait
* for UART_LSR_BOTH_EMPTY using the timeout of a single character
*/
- fifo_wait_for_lsr(up, tx_count);
+ serial8250_fifo_wait_for_lsr_thre(up, tx_count);
}
/*
--
2.39.5
^ permalink raw reply related
* [PATCH 5/6] serial: 8250: Add late synchronize_irq() to shutdown to handle DW UART BUSY
From: Ilpo Järvinen @ 2026-01-23 17:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, linux-serial, Andy Shevchenko,
qianfan Zhao, Adriana Nicolae, linux-kernel
Cc: Ilpo Järvinen, Bandal, Shankar, Murthy, Shanth
In-Reply-To: <20260123172739.13410-1-ilpo.jarvinen@linux.intel.com>
When DW UART is !uart_16550_compatible, it can indicate BUSY at any
point (when under constant Rx pressure) unless a complex sequence of
steps is performed. Any LCR write can run a foul with the condition
that prevents writing LCR while the UART is BUSY, which triggers
BUSY_DETECT interrupt that seems unmaskable using IER bits.
Normal flow is that dw8250_handle_irq() handles BUSY_DETECT condition
by reading USR register. This BUSY feature, however, breaks the
assumptions made in serial8250_do_shutdown(), which runs
synchronize_irq() after clearing IER and assumes no interrupts can
occur after that point but then proceeds to update LCR, which on DW
UART can trigger an interrupt.
If serial8250_do_shutdown() releases the interrupt handler before the
handler has run and processed the BUSY_DETECT condition by read the USR
register, the IRQ is not deasserted resulting in interrupt storm that
triggers "irq x: nobody cared" warning leading to disabling the IRQ.
Add late synchronize_irq() into serial8250_do_shutdown() to ensure
BUSY_DETECT from DW UART is handled before port's interrupt handler is
released. Alternative would be to add DW UART specific shutdown
function but it would mostly duplicate the generic code and the extra
synchronize_irq() seems pretty harmless in serial8250_do_shutdown().
Reported-by: "Bandal, Shankar" <shankar.bandal@intel.com>
Tested-by: "Bandal, Shankar" <shankar.bandal@intel.com>
Tested-by: "Murthy, Shanth" <shanth.murthy@intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
drivers/tty/serial/8250/8250_port.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 02576ed30abb..fa982e5cbe90 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2401,6 +2401,12 @@ void serial8250_do_shutdown(struct uart_port *port)
* the IRQ chain.
*/
serial_port_in(port, UART_RX);
+ /*
+ * LCR writes on DW UART can trigger late (unmaskable) IRQs.
+ * Handle them before releasing the handler.
+ */
+ synchronize_irq(port->irq);
+
serial8250_rpm_put(up);
up->ops->release_irq(up);
--
2.39.5
^ permalink raw reply related
* [PATCH 4/6] serial: 8250_dw: Rework IIR_NO_INT handling to stop interrupt storm
From: Ilpo Järvinen @ 2026-01-23 17:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, linux-serial, Andy Shevchenko,
qianfan Zhao, Adriana Nicolae, Ilpo Järvinen, linux-kernel
Cc: Bandal, Shankar, Murthy, Shanth
In-Reply-To: <20260123172739.13410-1-ilpo.jarvinen@linux.intel.com>
INTC10EE UART can end up into an interrupt storm where it reports
IIR_NO_INT (0x1). If the storm happens during active UART operation, it
is promptly stopped by IIR value change due to Rx or Tx events.
However, when there is no activity, either due to idle serial line or
due to specific circumstances such as during shutdown that writes
IER=0, there is nothing to stop the storm.
During shutdown the storm is particularly problematic because
serial8250_do_shutdown() calls synchronize_irq() that will hang in
waiting for the storm to finish which never happens.
This problem can also result in triggering a warning:
irq 45: nobody cared (try booting with the "irqpoll" option)
[...snip...]
handlers:
serial8250_interrupt
Disabling IRQ #45
Normal means to reset interrupt status by reading LSR, MSR, USR, or RX
register do not result in the UART deasserting the IRQ.
Add a quirk to INTC10EE UARTs to enable Tx interrupts if UART's Tx is
currently empty and inactive. Rework IIR_NO_INT to keep track of the
number of consecutive IIR_NO_INT, and on third one perform the quirk.
Enabling Tx interrupts should change IIR value from IIR_NO_INT to
IIR_THRI which has been observed to stop the storm.
Reported-by: "Bandal, Shankar" <shankar.bandal@intel.com>
Tested-by: "Bandal, Shankar" <shankar.bandal@intel.com>
Tested-by: "Murthy, Shanth" <shanth.murthy@intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
drivers/tty/serial/8250/8250_dw.c | 60 ++++++++++++++++++++++++++++---
1 file changed, 56 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
index 7cee89f14179..a40c0851f39c 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -60,6 +60,7 @@
#define DW_UART_QUIRK_IS_DMA_FC BIT(3)
#define DW_UART_QUIRK_APMC0D08 BIT(4)
#define DW_UART_QUIRK_CPR_VALUE BIT(5)
+#define DW_UART_QUIRK_IER_KICK BIT(6)
struct dw8250_platform_data {
u8 usr_reg;
@@ -81,6 +82,8 @@ struct dw8250_data {
unsigned int skip_autocfg:1;
unsigned int uart_16550_compatible:1;
+
+ u64 no_int_count;
};
static inline struct dw8250_data *to_dw8250_data(struct dw8250_port_data *data)
@@ -308,6 +311,29 @@ static u32 dw8250_serial_in32be(struct uart_port *p, unsigned int offset)
return dw8250_modify_msr(p, offset, value);
}
+/*
+ * INTC10EE UART can IRQ storm while reporting IIR_NO_INT. Inducing IIR value
+ * change has been observed to break the storm.
+ *
+ * If Tx is empty (THRE asserted), we use here IER_THRI to cause IIR_NO_INT ->
+ * IIR_THRI transition.
+ */
+static void dw8250_quirk_ier_kick(struct uart_port *p)
+{
+ struct uart_8250_port *up = up_to_u8250p(p);
+ u32 lsr;
+
+ if (up->ier & UART_IER_THRI)
+ return;
+
+ lsr = serial_lsr_in(up);
+ if (!(lsr & UART_LSR_THRE))
+ return;
+
+ serial_out(up, UART_IER, up->ier | UART_IER_THRI);
+ serial_in(up, UART_LCR); /* safe, no side-effects */
+ serial_out(up, UART_IER, up->ier);
+}
static int dw8250_handle_irq(struct uart_port *p)
{
@@ -318,18 +344,29 @@ static int dw8250_handle_irq(struct uart_port *p)
unsigned int quirks = d->pdata->quirks;
unsigned int status;
+ guard(uart_port_lock_irqsave)(p);
+
switch (FIELD_GET(DW_UART_IIR_IID, iir)) {
case UART_IIR_NO_INT:
+ if (d->uart_16550_compatible || up->dma)
+ return 0;
+
+ d->no_int_count++;
+ if (d->no_int_count > 2 && quirks & DW_UART_QUIRK_IER_KICK)
+ dw8250_quirk_ier_kick(p);
+
return 0;
case UART_IIR_BUSY:
/* Clear the USR */
serial_port_in(p, d->pdata->usr_reg);
+ d->no_int_count = 0;
+
return 1;
}
- guard(uart_port_lock_irqsave)(p);
+ d->no_int_count = 0;
/*
* There are ways to get Designware-based UARTs into a state where
@@ -562,6 +599,14 @@ static void dw8250_reset_control_assert(void *data)
reset_control_assert(data);
}
+static void dw8250_shutdown(struct uart_port *port)
+{
+ struct dw8250_data *d = to_dw8250_data(port->private_data);
+
+ serial8250_do_shutdown(port);
+ d->no_int_count = 0;
+}
+
static int dw8250_probe(struct platform_device *pdev)
{
struct uart_8250_port uart = {}, *up = &uart;
@@ -685,10 +730,12 @@ static int dw8250_probe(struct platform_device *pdev)
dw8250_quirks(p, data);
/* If the Busy Functionality is not implemented, don't handle it */
- if (data->uart_16550_compatible)
+ if (data->uart_16550_compatible) {
p->handle_irq = NULL;
- else if (data->pdata)
+ } else if (data->pdata) {
p->handle_irq = dw8250_handle_irq;
+ p->shutdown = dw8250_shutdown;
+ }
dw8250_setup_dma_filter(p, data);
@@ -815,6 +862,11 @@ static const struct dw8250_platform_data dw8250_skip_set_rate_data = {
.quirks = DW_UART_QUIRK_SKIP_SET_RATE,
};
+static const struct dw8250_platform_data dw8250_intc10ee = {
+ .usr_reg = DW_UART_USR,
+ .quirks = DW_UART_QUIRK_IER_KICK,
+};
+
static const struct of_device_id dw8250_of_match[] = {
{ .compatible = "snps,dw-apb-uart", .data = &dw8250_dw_apb },
{ .compatible = "cavium,octeon-3860-uart", .data = &dw8250_octeon_3860_data },
@@ -844,7 +896,7 @@ static const struct acpi_device_id dw8250_acpi_match[] = {
{ "INT33C5", (kernel_ulong_t)&dw8250_dw_apb },
{ "INT3434", (kernel_ulong_t)&dw8250_dw_apb },
{ "INT3435", (kernel_ulong_t)&dw8250_dw_apb },
- { "INTC10EE", (kernel_ulong_t)&dw8250_dw_apb },
+ { "INTC10EE", (kernel_ulong_t)&dw8250_intc10ee },
{ },
};
MODULE_DEVICE_TABLE(acpi, dw8250_acpi_match);
--
2.39.5
^ permalink raw reply related
* [PATCH 3/6] serial: 8250_dw: Rework dw8250_handle_irq() locking and IIR handling
From: Ilpo Järvinen @ 2026-01-23 17:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, linux-serial, Andy Shevchenko,
qianfan Zhao, Adriana Nicolae, Ilpo Järvinen, linux-kernel
Cc: Bandal, Shankar, Murthy, Shanth
In-Reply-To: <20260123172739.13410-1-ilpo.jarvinen@linux.intel.com>
dw8250_handle_irq() takes port's lock multiple times with no good
reason to release it in between and calls serial8250_handle_irq()
that also takes port's lock.
As serial8250_handle_irq() takes port's lock itself, create
serial8250_handle_irq_locked() that allows caller to hold port's lock
across the call. Take port's lock only once in dw8250_handle_irq() and
call serial8250_handle_irq_locked() directly.
As IIR_NO_INT check in serial8250_handle_irq() was outside of port's
lock, it has to be done already in dw8250_handle_irq().
DW UART can, in addition to IIR_NO_INT, report BUSY_DETECT (0x7) which
collided with the IIR_NO_INT (0x1) check in serial8250_handle_irq()
(because & is used instead of ==) meaning that no other work is done by
serial8250_handle_irq() during an BUSY_DETECT interrupt.
This allows reorganizing code in dw8250_handle_irq() to do both
IIR_NO_INT and BUSY_DETECT handling right at the start simplifying
the logic.
Tested-by: "Bandal, Shankar" <shankar.bandal@intel.com>
Tested-by: "Murthy, Shanth" <shanth.murthy@intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
drivers/tty/serial/8250/8250_dw.c | 35 ++++++++++++++++-------------
drivers/tty/serial/8250/8250_port.c | 24 +++++++++++++-------
include/linux/serial_8250.h | 1 +
3 files changed, 36 insertions(+), 24 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
index 57a760b43da9..7cee89f14179 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -9,6 +9,8 @@
* LCR is written whilst busy. If it is, then a busy detect interrupt is
* raised, the LCR needs to be rewritten and the uart status register read.
*/
+#include <linux/bitfield.h>
+#include <linux/bits.h>
#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/device.h>
@@ -40,6 +42,8 @@
#define RZN1_UART_RDMACR 0x110 /* DMA Control Register Receive Mode */
/* DesignWare specific register fields */
+#define DW_UART_IIR_IID GENMASK(3, 0)
+
#define DW_UART_MCR_SIRE BIT(6)
/* Renesas specific register fields */
@@ -313,7 +317,19 @@ static int dw8250_handle_irq(struct uart_port *p)
bool rx_timeout = (iir & 0x3f) == UART_IIR_RX_TIMEOUT;
unsigned int quirks = d->pdata->quirks;
unsigned int status;
- unsigned long flags;
+
+ switch (FIELD_GET(DW_UART_IIR_IID, iir)) {
+ case UART_IIR_NO_INT:
+ return 0;
+
+ case UART_IIR_BUSY:
+ /* Clear the USR */
+ serial_port_in(p, d->pdata->usr_reg);
+
+ return 1;
+ }
+
+ guard(uart_port_lock_irqsave)(p);
/*
* There are ways to get Designware-based UARTs into a state where
@@ -326,20 +342,15 @@ static int dw8250_handle_irq(struct uart_port *p)
* so we limit the workaround only to non-DMA mode.
*/
if (!up->dma && rx_timeout) {
- uart_port_lock_irqsave(p, &flags);
status = serial_lsr_in(up);
if (!(status & (UART_LSR_DR | UART_LSR_BI)))
serial_port_in(p, UART_RX);
-
- uart_port_unlock_irqrestore(p, flags);
}
/* Manually stop the Rx DMA transfer when acting as flow controller */
if (quirks & DW_UART_QUIRK_IS_DMA_FC && up->dma && up->dma->rx_running && rx_timeout) {
- uart_port_lock_irqsave(p, &flags);
status = serial_lsr_in(up);
- uart_port_unlock_irqrestore(p, flags);
if (status & (UART_LSR_DR | UART_LSR_BI)) {
dw8250_writel_ext(p, RZN1_UART_RDMACR, 0);
@@ -347,17 +358,9 @@ static int dw8250_handle_irq(struct uart_port *p)
}
}
- if (serial8250_handle_irq(p, iir))
- return 1;
-
- if ((iir & UART_IIR_BUSY) == UART_IIR_BUSY) {
- /* Clear the USR */
- serial_port_in(p, d->pdata->usr_reg);
+ serial8250_handle_irq_locked(p, iir);
- return 1;
- }
-
- return 0;
+ return 1;
}
static void dw8250_clk_work_cb(struct work_struct *work)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index f7a3c5555204..02576ed30abb 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -16,6 +16,7 @@
#include <linux/ioport.h>
#include <linux/init.h>
#include <linux/irq.h>
+#include <linux/lockdep.h>
#include <linux/console.h>
#include <linux/gpio/consumer.h>
#include <linux/sysrq.h>
@@ -1782,20 +1783,16 @@ static bool handle_rx_dma(struct uart_8250_port *up, unsigned int iir)
}
/*
- * This handles the interrupt from one port.
+ * Context: port's lock must be held by the caller.
*/
-int serial8250_handle_irq(struct uart_port *port, unsigned int iir)
+void serial8250_handle_irq_locked(struct uart_port *port, unsigned int iir)
{
struct uart_8250_port *up = up_to_u8250p(port);
struct tty_port *tport = &port->state->port;
bool skip_rx = false;
- unsigned long flags;
u16 status;
- if (iir & UART_IIR_NO_INT)
- return 0;
-
- uart_port_lock_irqsave(port, &flags);
+ lockdep_assert_held_once(&port->lock);
status = serial_lsr_in(up);
@@ -1828,8 +1825,19 @@ int serial8250_handle_irq(struct uart_port *port, unsigned int iir)
else if (!up->dma->tx_running)
__stop_tx(up);
}
+}
+EXPORT_SYMBOL_GPL(serial8250_handle_irq_locked);
- uart_unlock_and_check_sysrq_irqrestore(port, flags);
+/*
+ * This handles the interrupt from one port.
+ */
+int serial8250_handle_irq(struct uart_port *port, unsigned int iir)
+{
+ if (iir & UART_IIR_NO_INT)
+ return 0;
+
+ guard(uart_port_lock_irqsave)(port);
+ serial8250_handle_irq_locked(port, iir);
return 1;
}
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index 01efdce0fda0..a95b2d143d24 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -195,6 +195,7 @@ void serial8250_do_set_mctrl(struct uart_port *port, unsigned int mctrl);
void serial8250_do_set_divisor(struct uart_port *port, unsigned int baud,
unsigned int quot);
int fsl8250_handle_irq(struct uart_port *port);
+void serial8250_handle_irq_locked(struct uart_port *port, unsigned int iir);
int serial8250_handle_irq(struct uart_port *port, unsigned int iir);
u16 serial8250_rx_chars(struct uart_8250_port *up, u16 lsr);
void serial8250_read_char(struct uart_8250_port *up, u16 lsr);
--
2.39.5
^ permalink raw reply related
* [PATCH 2/6] serial: 8250_dw: Avoid unnecessary LCR writes
From: Ilpo Järvinen @ 2026-01-23 17:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, linux-serial, Andy Shevchenko,
qianfan Zhao, Adriana Nicolae, Ilpo Järvinen, linux-kernel
Cc: Bandal, Shankar, Murthy, Shanth
In-Reply-To: <20260123172739.13410-1-ilpo.jarvinen@linux.intel.com>
When DW UART is configured with BUSY flag, LCR writes may not always
succeed which can make any LCR write complex and very expensive.
Performing write directly can trigger IRQ and the driver has to perform
complex and distruptive sequence while retrying the write.
Therefore, it's better to avoid doing LCR write that would not change
the value of the LCR register. Add LCR write avoidance code into the
8250_dw driver's serial_out functions.
Reported-by: "Bandal, Shankar" <shankar.bandal@intel.com>
Tested-by: "Bandal, Shankar" <shankar.bandal@intel.com>
Tested-by: "Murthy, Shanth" <shanth.murthy@intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
drivers/tty/serial/8250/8250_dw.c | 32 +++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
index 27af83f0ff46..57a760b43da9 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -181,6 +181,23 @@ static void dw8250_check_lcr(struct uart_port *p, unsigned int offset, u32 value
*/
}
+/*
+ * With BUSY, LCR writes can be very expensive (IRQ + complex retry logic).
+ * If the write would not change the value of the LCR register, skip write
+ * entirely.
+ */
+static bool dw8250_can_skip_reg_write(struct uart_port *p, unsigned int offset, u32 value)
+{
+ struct dw8250_data *d = to_dw8250_data(p->private_data);
+ u32 lcr;
+
+ if (offset != UART_LCR || d->uart_16550_compatible)
+ return false;
+
+ lcr = serial_port_in(p, offset);
+ return lcr == value;
+}
+
/* Returns once the transmitter is empty or we run out of retries */
static void dw8250_tx_wait_empty(struct uart_port *p)
{
@@ -207,12 +224,18 @@ static void dw8250_tx_wait_empty(struct uart_port *p)
static void dw8250_serial_out(struct uart_port *p, unsigned int offset, u32 value)
{
+ if (dw8250_can_skip_reg_write(p, offset, value))
+ return;
+
writeb(value, p->membase + (offset << p->regshift));
dw8250_check_lcr(p, offset, value);
}
static void dw8250_serial_out38x(struct uart_port *p, unsigned int offset, u32 value)
{
+ if (dw8250_can_skip_reg_write(p, offset, value))
+ return;
+
/* Allow the TX to drain before we reconfigure */
if (offset == UART_LCR)
dw8250_tx_wait_empty(p);
@@ -237,6 +260,9 @@ static u32 dw8250_serial_inq(struct uart_port *p, unsigned int offset)
static void dw8250_serial_outq(struct uart_port *p, unsigned int offset, u32 value)
{
+ if (dw8250_can_skip_reg_write(p, offset, value))
+ return;
+
value &= 0xff;
__raw_writeq(value, p->membase + (offset << p->regshift));
/* Read back to ensure register write ordering. */
@@ -248,6 +274,9 @@ static void dw8250_serial_outq(struct uart_port *p, unsigned int offset, u32 val
static void dw8250_serial_out32(struct uart_port *p, unsigned int offset, u32 value)
{
+ if (dw8250_can_skip_reg_write(p, offset, value))
+ return;
+
writel(value, p->membase + (offset << p->regshift));
dw8250_check_lcr(p, offset, value);
}
@@ -261,6 +290,9 @@ static u32 dw8250_serial_in32(struct uart_port *p, unsigned int offset)
static void dw8250_serial_out32be(struct uart_port *p, unsigned int offset, u32 value)
{
+ if (dw8250_can_skip_reg_write(p, offset, value))
+ return;
+
iowrite32be(value, p->membase + (offset << p->regshift));
dw8250_check_lcr(p, offset, value);
}
--
2.39.5
^ permalink raw reply related
* [PATCH 1/6] serial: 8250: Protect LCR write in shutdown
From: Ilpo Järvinen @ 2026-01-23 17:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, linux-serial, Andy Shevchenko,
qianfan Zhao, Adriana Nicolae, linux-kernel
Cc: Ilpo Järvinen, Bandal, Shankar, Murthy, Shanth
In-Reply-To: <20260123172739.13410-1-ilpo.jarvinen@linux.intel.com>
The 8250_dw driver needs to potentially perform very complex operations
during LCR writes because its BUSY handling prevents updates to LCR
while UART is BUSY (which is not fully under our control without those
complex operations). Thus, LCR writes should occur under port's lock.
Move LCR write under port's lock in serial8250_do_shutdown(). Also
split the LCR RMW so that the logic is on a separate line for clarity.
Tested-by: "Bandal, Shankar" <shankar.bandal@intel.com>
Tested-by: "Murthy, Shanth" <shanth.murthy@intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
drivers/tty/serial/8250/8250_port.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 719faf92aa8a..f7a3c5555204 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2350,6 +2350,7 @@ static int serial8250_startup(struct uart_port *port)
void serial8250_do_shutdown(struct uart_port *port)
{
struct uart_8250_port *up = up_to_u8250p(port);
+ u32 lcr;
serial8250_rpm_get(up);
/*
@@ -2376,13 +2377,13 @@ void serial8250_do_shutdown(struct uart_port *port)
port->mctrl &= ~TIOCM_OUT2;
serial8250_set_mctrl(port, port->mctrl);
+
+ /* Disable break condition */
+ lcr = serial_port_in(port, UART_LCR);
+ lcr &= ~UART_LCR_SBC;
+ serial_port_out(port, UART_LCR, lcr);
}
- /*
- * Disable break condition and FIFOs
- */
- serial_port_out(port, UART_LCR,
- serial_port_in(port, UART_LCR) & ~UART_LCR_SBC);
serial8250_clear_fifos(up);
rsa_disable(up);
--
2.39.5
^ permalink raw reply related
* [PATCH 0/6] 8250 DW UART fixes when under constant Rx pressure
From: Ilpo Järvinen @ 2026-01-23 17:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, linux-serial, Andy Shevchenko,
qianfan Zhao, Adriana Nicolae
Cc: linux-kernel, Ilpo Järvinen
Hi all,
Here are fixes to 8250 DW UART conditions that mostly occur in scenarios
under constant Rx pressure which are made complicated by BUSY handling
of DW UARTs (used when !uart_16550_compatible).
A few of the changes touch also 8250_port but it's mostly moving existing
code around (except for the extra synchronize_irq() in shutdown).
I'll do UART_IIR_RX_TIMEOUT move to switch/case separately from this
fix series.
Ilpo Järvinen (6):
serial: 8250: Protect LCR write in shutdown
serial: 8250_dw: Avoid unnecessary LCR writes
serial: 8250_dw: Rework dw8250_handle_irq() locking and IIR handling
serial: 8250_dw: Rework IIR_NO_INT handling to stop interrupt storm
serial: 8250: Add late synchronize_irq() to shutdown to handle DW UART
BUSY
serial: 8250_dw: Ensure BUSY is deasserted
drivers/tty/serial/8250/8250.h | 25 +++
drivers/tty/serial/8250/8250_dw.c | 297 ++++++++++++++++++++++------
drivers/tty/serial/8250/8250_port.c | 69 ++++---
include/linux/serial_8250.h | 1 +
4 files changed, 301 insertions(+), 91 deletions(-)
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
--
2.39.5
^ permalink raw reply
* Re: [PATCH v2] serial: Fix not set tty->port race condition
From: Jiri Slaby @ 2026-01-23 7:35 UTC (permalink / raw)
To: Krzysztof Kozlowski, Greg Kroah-Hartman, linux-kernel,
linux-serial; +Cc: stable
In-Reply-To: <20260123072139.53293-2-krzysztof.kozlowski@oss.qualcomm.com>
On 23. 01. 26, 8:21, Krzysztof Kozlowski wrote:
> Revert commit bfc467db60b7 ("serial: remove redundant
> tty_port_link_device()") because the tty_port_link_device() is not
> redundant: the tty->port has to be confured before we call
> uart_configure_port(), otherwise user-space can open console without TTY
> linked to the driver.
>
> This tty_port_link_device() was added explicitly to avoid this exact
> issue in commit fb2b90014d78 ("tty: link tty and port before configuring
> it as console"), so offending commit basically reverted the fix saying
> it is redundant without addressing the actual race condition presented
> there.
>
> Reproducible always as tty->port warning on Qualcomm SoC with most of
> devices disabled, so with very fast boot, and one serial device being
> the console:
>
> printk: legacy console [ttyMSM0] enabled
> printk: legacy console [ttyMSM0] enabled
> printk: legacy bootconsole [qcom_geni0] disabled
> printk: legacy bootconsole [qcom_geni0] disabled
> ------------[ cut here ]------------
> tty_init_dev: ttyMSM driver does not set tty->port. This would crash the kernel. Fix the driver!
> WARNING: drivers/tty/tty_io.c:1414 at tty_init_dev.part.0+0x228/0x25c, CPU#2: systemd/1
> Modules linked in: socinfo tcsrcc_eliza gcc_eliza sm3_ce fuse ipv6
> CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G S 6.19.0-rc4-next-20260108-00024-g2202f4d30aa8 #73 PREEMPT
> Tainted: [S]=CPU_OUT_OF_SPEC
> Hardware name: Qualcomm Technologies, Inc. Eliza (DT)
> ...
> tty_init_dev.part.0 (drivers/tty/tty_io.c:1414 (discriminator 11)) (P)
> tty_open (arch/arm64/include/asm/atomic_ll_sc.h:95 (discriminator 3) drivers/tty/tty_io.c:2073 (discriminator 3) drivers/tty/tty_io.c:2120 (discriminator 3))
> chrdev_open (fs/char_dev.c:411)
> do_dentry_open (fs/open.c:962)
> vfs_open (fs/open.c:1094)
> do_open (fs/namei.c:4634)
> path_openat (fs/namei.c:4793)
> do_filp_open (fs/namei.c:4820)
> do_sys_openat2 (fs/open.c:1391 (discriminator 3))
> ...
> Starting Network Name Resolution...
>
> Apparently the flow with this small Yocto-based ramdisk user-space is:
>
> driver (qcom_geni_serial.c): user-space:
> ============================ ===========
> qcom_geni_serial_probe()
> uart_add_one_port()
> serial_core_register_port()
> serial_core_add_one_port()
> uart_configure_port()
> register_console()
> |
> | open console
> | ...
> | tty_init_dev()
> | driver->ports[idx] is NULL
> |
> tty_port_register_device_attr_serdev()
> tty_port_link_device() <- set driver->ports[idx]
>
> Fixes: bfc467db60b7 ("serial: remove redundant tty_port_link_device()")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Thanks for the update.
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
--
js
suse labs
^ permalink raw reply
* [PATCH v2] serial: Fix not set tty->port race condition
From: Krzysztof Kozlowski @ 2026-01-23 7:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, linux-kernel, linux-serial
Cc: Krzysztof Kozlowski, stable
Revert commit bfc467db60b7 ("serial: remove redundant
tty_port_link_device()") because the tty_port_link_device() is not
redundant: the tty->port has to be confured before we call
uart_configure_port(), otherwise user-space can open console without TTY
linked to the driver.
This tty_port_link_device() was added explicitly to avoid this exact
issue in commit fb2b90014d78 ("tty: link tty and port before configuring
it as console"), so offending commit basically reverted the fix saying
it is redundant without addressing the actual race condition presented
there.
Reproducible always as tty->port warning on Qualcomm SoC with most of
devices disabled, so with very fast boot, and one serial device being
the console:
printk: legacy console [ttyMSM0] enabled
printk: legacy console [ttyMSM0] enabled
printk: legacy bootconsole [qcom_geni0] disabled
printk: legacy bootconsole [qcom_geni0] disabled
------------[ cut here ]------------
tty_init_dev: ttyMSM driver does not set tty->port. This would crash the kernel. Fix the driver!
WARNING: drivers/tty/tty_io.c:1414 at tty_init_dev.part.0+0x228/0x25c, CPU#2: systemd/1
Modules linked in: socinfo tcsrcc_eliza gcc_eliza sm3_ce fuse ipv6
CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G S 6.19.0-rc4-next-20260108-00024-g2202f4d30aa8 #73 PREEMPT
Tainted: [S]=CPU_OUT_OF_SPEC
Hardware name: Qualcomm Technologies, Inc. Eliza (DT)
...
tty_init_dev.part.0 (drivers/tty/tty_io.c:1414 (discriminator 11)) (P)
tty_open (arch/arm64/include/asm/atomic_ll_sc.h:95 (discriminator 3) drivers/tty/tty_io.c:2073 (discriminator 3) drivers/tty/tty_io.c:2120 (discriminator 3))
chrdev_open (fs/char_dev.c:411)
do_dentry_open (fs/open.c:962)
vfs_open (fs/open.c:1094)
do_open (fs/namei.c:4634)
path_openat (fs/namei.c:4793)
do_filp_open (fs/namei.c:4820)
do_sys_openat2 (fs/open.c:1391 (discriminator 3))
...
Starting Network Name Resolution...
Apparently the flow with this small Yocto-based ramdisk user-space is:
driver (qcom_geni_serial.c): user-space:
============================ ===========
qcom_geni_serial_probe()
uart_add_one_port()
serial_core_register_port()
serial_core_add_one_port()
uart_configure_port()
register_console()
|
| open console
| ...
| tty_init_dev()
| driver->ports[idx] is NULL
|
tty_port_register_device_attr_serdev()
tty_port_link_device() <- set driver->ports[idx]
Fixes: bfc467db60b7 ("serial: remove redundant tty_port_link_device()")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v2:
1. Add comment to the code.
---
drivers/tty/serial/serial_core.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 9930023e924c..2805cad10511 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -3074,6 +3074,12 @@ static int serial_core_add_one_port(struct uart_driver *drv, struct uart_port *u
if (uport->cons && uport->dev)
of_console_check(uport->dev->of_node, uport->cons->name, uport->line);
+ /*
+ * TTY port has to be linked with the driver before register_console()
+ * in uart_configure_port(), because user-space could open the console
+ * immediately after.
+ */
+ tty_port_link_device(port, drv->tty_driver, uport->line);
uart_configure_port(drv, state, uport);
port->console = uart_console(uport);
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] serial: Fix not set tty->port race condition
From: Krzysztof Kozlowski @ 2026-01-23 7:13 UTC (permalink / raw)
To: Jiri Slaby, Greg Kroah-Hartman, linux-kernel, linux-serial; +Cc: stable
In-Reply-To: <e0ee73fe-2b9e-4976-9648-35a6822b8ad1@kernel.org>
On 23/01/2026 06:55, Jiri Slaby wrote:
> On 22. 01. 26, 18:00, Krzysztof Kozlowski wrote:
>>
>> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
>> index 0534b2eb1682..116f33f0643f 100644
>> --- a/drivers/tty/serial/serial_core.c
>> +++ b/drivers/tty/serial/serial_core.c
>> @@ -3077,6 +3077,7 @@ static int serial_core_add_one_port(struct uart_driver *drv, struct uart_port *u
>> if (uport->cons && uport->dev)
>> of_console_check(uport->dev->of_node, uport->cons->name, uport->line);
>>
>> + tty_port_link_device(port, drv->tty_driver, uport->line);
>
> Bah, so add a comment or I (or somebody) remove it again eventually :(.
>
Good point.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] serial: Fix not set tty->port race condition
From: Jiri Slaby @ 2026-01-23 5:59 UTC (permalink / raw)
To: Krzysztof Kozlowski, Greg Kroah-Hartman, linux-kernel,
linux-serial; +Cc: stable
In-Reply-To: <d86ad878-a125-41c9-a0a3-bc24c926ba55@oss.qualcomm.com>
On 22. 01. 26, 18:11, Krzysztof Kozlowski wrote:
> On 22/01/2026 18:00, Krzysztof Kozlowski wrote:
>> Revert commit bfc467db60b7 ("serial: remove redundant
>> tty_port_link_device()") because the tty_port_link_device() is not
>
> And grumpy side note because I was looking at this for more than a day
> blaming my new hardware:
>
> I really wish commits (e.g. bfc467db60b7) calling something redundant
> had that much of message written why something is redundant as the
> commit (fb2b90014d78) which introduced that part of code.
It was clear enough: because tty_port_register_device_attr_serdev()
links the port few lines below.
But it/I somehow didn't take the hidden uart_console() in
uart_configure_port() into account.
> If someone wrote one page of text why foo is needed, we should write not
> less why it is not needed :)
I think I could generate a bloat of text. But you will still have a
broken kernel the same way :)?
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH] serial: Fix not set tty->port race condition
From: Jiri Slaby @ 2026-01-23 5:55 UTC (permalink / raw)
To: Krzysztof Kozlowski, Greg Kroah-Hartman, linux-kernel,
linux-serial; +Cc: stable
In-Reply-To: <20260122170031.433724-2-krzysztof.kozlowski@oss.qualcomm.com>
On 22. 01. 26, 18:00, Krzysztof Kozlowski wrote:
> Revert commit bfc467db60b7 ("serial: remove redundant
> tty_port_link_device()") because the tty_port_link_device() is not
> redundant: the tty->port has to be confured before we call
> uart_configure_port(), otherwise user-space can open console without TTY
> linked to the driver.
>
> This tty_port_link_device() was added explicitly to avoid this exact
> issue in commit fb2b90014d78 ("tty: link tty and port before configuring
> it as console"), so offending commit basically reverted the fix saying
> it is redundant without addressing the actual race condition presented
> there.
>
> Reproducible always as tty->port warning on Qualcomm SoC with most of
> devices disabled, so with very fast boot, and one serial device being
> the console:
>
> printk: legacy console [ttyMSM0] enabled
> printk: legacy console [ttyMSM0] enabled
> printk: legacy bootconsole [qcom_geni0] disabled
> printk: legacy bootconsole [qcom_geni0] disabled
> ------------[ cut here ]------------
> tty_init_dev: ttyMSM driver does not set tty->port. This would crash the kernel. Fix the driver!
> WARNING: drivers/tty/tty_io.c:1414 at tty_init_dev.part.0+0x228/0x25c, CPU#2: systemd/1
> Modules linked in: socinfo tcsrcc_eliza gcc_eliza sm3_ce fuse ipv6
> CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G S 6.19.0-rc4-next-20260108-00024-g2202f4d30aa8 #73 PREEMPT
> Tainted: [S]=CPU_OUT_OF_SPEC
> Hardware name: Qualcomm Technologies, Inc. Eliza (DT)
> ...
> tty_init_dev.part.0 (drivers/tty/tty_io.c:1414 (discriminator 11)) (P)
> tty_open (arch/arm64/include/asm/atomic_ll_sc.h:95 (discriminator 3) drivers/tty/tty_io.c:2073 (discriminator 3) drivers/tty/tty_io.c:2120 (discriminator 3))
> chrdev_open (fs/char_dev.c:411)
> do_dentry_open (fs/open.c:962)
> vfs_open (fs/open.c:1094)
> do_open (fs/namei.c:4634)
> path_openat (fs/namei.c:4793)
> do_filp_open (fs/namei.c:4820)
> do_sys_openat2 (fs/open.c:1391 (discriminator 3))
> ...
> Starting Network Name Resolution...
>
> Apparently the flow with this small Yocto-based ramdisk user-space is:
>
> driver (qcom_geni_serial.c): user-space:
> ============================ ===========
> qcom_geni_serial_probe()
> uart_add_one_port()
> serial_core_register_port()
> serial_core_add_one_port()
> uart_configure_port()
> register_console()
> |
> | open console
> | ...
> | tty_init_dev()
> | driver->ports[idx] is NULL
> |
> tty_port_register_device_attr_serdev()
> tty_port_link_device() <- set driver->ports[idx]
>
> Fixes: bfc467db60b7 ("serial: remove redundant tty_port_link_device()")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> drivers/tty/serial/serial_core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 0534b2eb1682..116f33f0643f 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -3077,6 +3077,7 @@ static int serial_core_add_one_port(struct uart_driver *drv, struct uart_port *u
> if (uport->cons && uport->dev)
> of_console_check(uport->dev->of_node, uport->cons->name, uport->line);
>
> + tty_port_link_device(port, drv->tty_driver, uport->line);
Bah, so add a comment or I (or somebody) remove it again eventually :(.
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH v2 00/16] MIPS: move pic32.h header file from asm to platform_data
From: Brian Masney @ 2026-01-23 0:49 UTC (permalink / raw)
To: Thomas Bogendoerfer, Claudiu Beznea
Cc: linux-mips, linux-kernel, Michael Turquette, Stephen Boyd,
linux-clk, Thomas Gleixner, Adrian Hunter, Ulf Hansson, linux-mmc,
Linus Walleij, linux-gpio, Alexandre Belloni, linux-rtc,
Greg Kroah-Hartman, Jiri Slaby, linux-serial, Guenter Roeck,
Wim Van Sebroeck, linux-watchdog
In-Reply-To: <20260112-mips-pic32-header-move-v2-0-927d516b1ff9@redhat.com>
Hi Thomas,
On Mon, Jan 12, 2026 at 05:47:54PM -0500, Brian Masney wrote:
> There are currently some pic32 MIPS drivers that are in tree, and are
> only configured to be compiled on the MIPS pic32 platform. There's a
> risk of breaking some of these drivers when migrating drivers away from
> legacy APIs. It happened to me with a pic32 clk driver.
>
> Let's go ahead and move the pic32.h from the asm to the platform_data
> include directory in the tree. This will make it easier, and cleaner to
> enable COMPILE_TEST for some of these pic32 drivers. To do this requires
> updating some includes, which I do at the beginning of this series.
>
> This series was compile tested on a centos-stream-10 arm64 host in two
> different configurations:
>
> - native arm64 build with COMPILE_TEST (via make allmodconfig)
> - MIPS cross compile on arm64 with:
> ARCH=mips CROSS_COMPILE=mips64-linux-gnu- make pic32mzda_defconfig
>
> Note that there is a separate MIPS compile error in linux-next, and I
> reported it at https://lore.kernel.org/all/aWVs2gVB418WiMVa@redhat.com/
>
> I included a patch at the end that shows enabling COMPILE_TEST for a
> pic32 clk driver.
>
> Merge Strategy
> ==============
> - Patches 1-15 can go through the MIPS tree.
I'm just checking if you'll be able to take patches 1-15 this
development cycle before the merge window opens?
If this series goes to Linus during this upcoming merge window, then
I have 17 patches ready to post in a month for the next development
cycle that can go to various individual subsystems that allows all
of these pic32 MIPS drivers to be compiled on all architectures. The
patches also fix some issues in those drivers that were found by
kernel CI.
This merge strategy makes it so that we won't have to deal with any
cross tree merge issues, or immutable branches.
Thanks,
Brian
^ permalink raw reply
* Re: [PATCH] serial: Fix not set tty->port race condition
From: Krzysztof Kozlowski @ 2026-01-22 17:11 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, linux-kernel, linux-serial; +Cc: stable
In-Reply-To: <20260122170031.433724-2-krzysztof.kozlowski@oss.qualcomm.com>
On 22/01/2026 18:00, Krzysztof Kozlowski wrote:
> Revert commit bfc467db60b7 ("serial: remove redundant
> tty_port_link_device()") because the tty_port_link_device() is not
And grumpy side note because I was looking at this for more than a day
blaming my new hardware:
I really wish commits (e.g. bfc467db60b7) calling something redundant
had that much of message written why something is redundant as the
commit (fb2b90014d78) which introduced that part of code.
If someone wrote one page of text why foo is needed, we should write not
less why it is not needed :)
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] serial: Fix not set tty->port race condition
From: Krzysztof Kozlowski @ 2026-01-22 17:00 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, linux-kernel, linux-serial
Cc: Krzysztof Kozlowski, stable
Revert commit bfc467db60b7 ("serial: remove redundant
tty_port_link_device()") because the tty_port_link_device() is not
redundant: the tty->port has to be confured before we call
uart_configure_port(), otherwise user-space can open console without TTY
linked to the driver.
This tty_port_link_device() was added explicitly to avoid this exact
issue in commit fb2b90014d78 ("tty: link tty and port before configuring
it as console"), so offending commit basically reverted the fix saying
it is redundant without addressing the actual race condition presented
there.
Reproducible always as tty->port warning on Qualcomm SoC with most of
devices disabled, so with very fast boot, and one serial device being
the console:
printk: legacy console [ttyMSM0] enabled
printk: legacy console [ttyMSM0] enabled
printk: legacy bootconsole [qcom_geni0] disabled
printk: legacy bootconsole [qcom_geni0] disabled
------------[ cut here ]------------
tty_init_dev: ttyMSM driver does not set tty->port. This would crash the kernel. Fix the driver!
WARNING: drivers/tty/tty_io.c:1414 at tty_init_dev.part.0+0x228/0x25c, CPU#2: systemd/1
Modules linked in: socinfo tcsrcc_eliza gcc_eliza sm3_ce fuse ipv6
CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G S 6.19.0-rc4-next-20260108-00024-g2202f4d30aa8 #73 PREEMPT
Tainted: [S]=CPU_OUT_OF_SPEC
Hardware name: Qualcomm Technologies, Inc. Eliza (DT)
...
tty_init_dev.part.0 (drivers/tty/tty_io.c:1414 (discriminator 11)) (P)
tty_open (arch/arm64/include/asm/atomic_ll_sc.h:95 (discriminator 3) drivers/tty/tty_io.c:2073 (discriminator 3) drivers/tty/tty_io.c:2120 (discriminator 3))
chrdev_open (fs/char_dev.c:411)
do_dentry_open (fs/open.c:962)
vfs_open (fs/open.c:1094)
do_open (fs/namei.c:4634)
path_openat (fs/namei.c:4793)
do_filp_open (fs/namei.c:4820)
do_sys_openat2 (fs/open.c:1391 (discriminator 3))
...
Starting Network Name Resolution...
Apparently the flow with this small Yocto-based ramdisk user-space is:
driver (qcom_geni_serial.c): user-space:
============================ ===========
qcom_geni_serial_probe()
uart_add_one_port()
serial_core_register_port()
serial_core_add_one_port()
uart_configure_port()
register_console()
|
| open console
| ...
| tty_init_dev()
| driver->ports[idx] is NULL
|
tty_port_register_device_attr_serdev()
tty_port_link_device() <- set driver->ports[idx]
Fixes: bfc467db60b7 ("serial: remove redundant tty_port_link_device()")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/tty/serial/serial_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 0534b2eb1682..116f33f0643f 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -3077,6 +3077,7 @@ static int serial_core_add_one_port(struct uart_driver *drv, struct uart_port *u
if (uport->cons && uport->dev)
of_console_check(uport->dev->of_node, uport->cons->name, uport->line);
+ tty_port_link_device(port, drv->tty_driver, uport->line);
uart_configure_port(drv, state, uport);
port->console = uart_console(uport);
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 00/21] Adding support of ADI ARMv8 ADSP-SC598 SoC.
From: Arturs Artamonovs @ 2026-01-22 15:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: arturs.artamonovs, Catalin Marinas, Will Deacon, Greg Malysa,
Philipp Zabel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Utsav Agarwal, Michael Turquette, Stephen Boyd, Linus Walleij,
Bartosz Golaszewski, Thomas Gleixner, Andi Shyti,
Greg Kroah-Hartman, Jiri Slaby, Arnd Bergmann, Olof Johansson,
soc, linux-arm-kernel, linux-kernel, devicetree, linux-clk,
linux-gpio, linux-i2c, linux-serial, adsp-linux,
Nathan Barrett-Morrison
Hi, big thanks to Krysztof, Arnd, Rob and Linus Walleij for the reviewing first set of patches that were sent some time ago. I have reviewed comments few times since then and Im currently at last stage of internal review for v2 series those are planned to be sent sometime in near future.
> On 16 Sep 2024, at 10:05, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 12/09/2024 20:24, Arturs Artamonovs via B4 Relay wrote:
>> This set of patches based on ADI fork of Linux Kerenl that support family of ADSP-SC5xx
>> SoC's and used by customers for some time . Patch series contains minimal set
>> of changes to add ADSP-SC598 support to upstream kernel. This series include
>> UART,I2C,IRQCHIP,RCU drivers and device-tree to be able boot on EV-SC598-SOM
>> board into serial shell and able to reset the board. Current SOM board
>> requires I2C expander to enable UART output.
>>
>> UART,I2C and PINCTRL drivers are based on old Blackfin drivers with
>> ADSP-SC5xx related bug fixes and improvments.
>>
>> Signed-off-by: Arturs Artamonovs <arturs.artamonovs@analog.com>
>> ---
>
> For new platform, be sure you have 0 warnings:
> 1. Please run standard kernel tools for static analysis, like
> coccinelle, smatch and sparse, and fix reported warnings.
>
> 2. Also check for warnings when building with W=1. Most of these
> commands (checks or W=1 build) can build specific targets, like some
> directory, to narrow the scope to only your code. The code here looks
> like it needs a fix. Feel free to get in touch if the warning is not clear.
>
> 3. Fix all compile test warning reported by LKP and check for common
> configs, regardless of reports.
>
> 4. Please run `make dtbs_check W=1` (see
> Documentation/devicetree/bindings/writing-schema.rst or
> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> for instructions).
>
> 5. Please run scripts/checkpatch.pl and fix reported warnings. Then
> please run `scripts/checkpatch.pl --strict` and (probably) fix more
> warnings. Some warnings can be ignored, especially from --strict run.
>
>
> Best regards,
> Krzysztof
>
>
^ permalink raw reply
* Re: [PATCH] serial: 8250 dw: clear FIFO before writting LCR
From: Ilpo Järvinen @ 2026-01-22 13:18 UTC (permalink / raw)
To: Adriana Nicolae; +Cc: linux-serial, Andy Shevchenko, prasad
In-Reply-To: <CAERbo5z2370GPWUNuSJuwZxga0se7CNH2XAnsnF-vtB7t6XREQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 15950 bytes --]
On Wed, 21 Jan 2026, Adriana Nicolae wrote:
> On Wed, Jan 21, 2026 at 4:31 PM Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> > On Fri, 31 Oct 2025, Adriana Nicolae wrote:
> > > On Wed, Oct 8, 2025 at 4:12 PM Ilpo Järvinen
> > > <ilpo.jarvinen@linux.intel.com> wrote:
> > > > On Wed, 8 Oct 2025, Adriana Nicolae wrote:
> > > > > Hello, Sorry for missing an update, the exact root cause is not clear, currently the
> > > > > brute force method of draining FIFO right before setting or clearing DLAB was stable
> > > > > during tests.
> > > > >
> > > > > The serial stuck seems to be a failed attempt to clear the DLAB.
> > > > > This operation fails because the USR indicates the hardware is
> > > > > still busy, even though the UART is in loopback mode and should
> > > > > be inactive.
> > > > >
> > > > > To isolate the issue, I tried the following without success:
> > > > > - Added delays: I inserted 100 repeated ndelay(p->frame_time)
> > > > > calls before and after enabling loopback mode to allow the FIFO
> > > > > to clear.
> > > > > - Cleared FIFO: I explicitly cleared the FIFO in addition to
> > > > > adding the delay.
> > > > > - Checked status: I printed the LSR just before the DLAB clear
> > > > > attempt and checked the USB busy bit.
> > > >
> > > > Okay, so the BUSY must be stuck asserted.
> > > >
> > > > Another idea, maybe test tx + rx over loopback to see if that manages to
> > > > de-freeze the BUSY bit. A patch to that effect below.
> > > >
> > > > (I've only added the new block into dw8250_idle_enter() compared with the
> > > > old patch but rebasing to tty-next resulted in some other changes due to
> > > > conflicts.)
> > >
> > > I've tested the new dw8250_idle_enter() sequence, and you're right,
> > > the BUSY bit remains set after entering loopback mode.
> > >
> > > However, the sequence in the patch (including the single loopback
> > > tx/rx) wasn't quite enough. I didn't see any kernel panics or console
> > > stuck anymore, but I've monitored the traces and there were cases when
> > > the trace after "p->serial_out(p, UART_LCR, up->lcr);" showed both
> > > BUSY bit set and DLAB bit still enabled.
> > >
> > > >
> > > > Only thing besides BUSY being stuck asserted is something Tx'ing after the
> > > > idle enter sequence. I think we could trap/check that too in
> > > > dw8250_serial_out() by using something along these lines:
> > > >
> > > > if (d->in_idle && offset == UART_TX) {
> > > > WARN_ON_ONCE(1);
> > > > return;
> > > > }
> > > >
> > > > (I think that should catch even console writes but I'm not 100% sure of
> > > > that and it will should get us where the rogue Tx originates from).
> > >
> > > I also added the WARN_ON_ONCE check you suggested in
> > > dw8250_serial_out(). The warning has not triggered, so it seems we
> > > don't have a rogue Tx firing while in_idle is set.
> > >
> > > >
> > > > > The critical finding was that immediately before the DLAB clear
> > > > > operation (p->serial_out(p, UART_LCR, up->lcr);), the LSR value
> > > > > was 0x6a and the USR busy bit [0] was set. This confirms the UART
> > > > > is busy, which blocks the DLAB modification.
> > > > >
> > > > > This is occurring on a device with a single UART console. The setup
> > > > > does not use DMA or modem control; only the Rx/Tx lines are connected.
> > > > >
> > > > > The trace below, from a single process, shows one successful DLAB
> > > > > clear followed by a failing one. The second attempt repeatedly logs
> > > > > "USR still busy" before eventually succeeding. This can lead to
> > > > > subsequent failures in dw8250_check_lcr: dw8250_idle_entered.
> > > > >
> > > > > Trace Log:
> > > > >
> > > > > <...>-15440 8583.592533: dw8250_idle_enter: in_idle = 1
> > > > > login-15440 8583.713817: dw8250_idle_enter: in loopback mode
> > > > > login-15440 8583.835099: dw8250_idle_enter: LSR in loopback mode is 0x63
> > > > > login-15440 8583.835103: dw8250_set_divisor: UART_LCR_DLAB cleared 13
> > > > > login-15440 8583.835104: dw8250_idle_exit: idle exit
> > > > > login-15440 8583.835105: dw8250_idle_exit: out of loopback mode
> > > > > login-15440 8583.835105: dw8250_idle_exit: in_idle = 0
> > > > > login-15440 8583.835352: dw8250_idle_enter: in_idle = 1
> > > > > login-15440 8583.956633: dw8250_idle_enter: in loopback mode
> > > > > login-15440 8583.956638: dw8250_idle_enter: LSR in loopback mode is 0x6a
> > > > > login-15440 8583.963918: dw8250_set_divisor: USR still busy dl_write
> > > > > login-15440 8584.000332: dw8250_set_divisor: USR still busy dl_write
> > > > > login-15440 8584.040385: dw8250_set_divisor: USR still busy dl_write
> > > > > login-15440 8584.078012: dw8250_set_divisor: UART_LCR_DLAB cleared 93
> > > > > login-15440 8584.078013: dw8250_idle_exit: idle exit
> > > > > login-15440 8584.078014: dw8250_idle_exit: out of loopback mode
> > > > > login-15440 8584.078015: dw8250_idle_exit: in_idle = 0
> > > >
> > > >
> > > >
> > > > --
> > > > From 01df58736a10f7f34aca895ef08e5519953f8572 Mon Sep 17 00:00:00 2001
> > > > From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>
> > > > Date: Wed, 8 Oct 2025 15:40:19 +0300
> > > > Subject: [PATCH 1/1] serial: 8250_dw: Ensure BUSY is deasserted
> > > > MIME-Version: 1.0
> > > > Content-Type: text/plain; charset=UTF-8
> > > > Content-Transfer-Encoding: 8bit
> > > >
> > > > DW UART cannot write to LCR, DLL, and DLH while BUSY is asserted.
> > > > Existance of BUSY depends on uart_16550_compatible, if UART HW is
> > > > configured with 16550 compatible those registers can always be
> > > > written.
> > > >
> > > > There currently is dw8250_force_idle() which attempts to archive
> > > > non-BUSY state by disabling FIFO, however, the solution is unreliable
> > > > when Rx keeps getting more and more characters.
> > > >
> > > > Create a sequence of operations to enforce that ensures UART cannot
> > > > keep BUSY asserted indefinitely. The new sequence relies on enabling
> > > > loopback mode temporarily to prevent incoming Rx characters keeping
> > > > UART BUSY.
> > > >
> > > > Use the new dw8250_idle_enter/exit() to do divisor writes and LCR
> > > > writes.
> > > >
> > > > This issue was reported by qianfan Zhao who put lots of debugging
> > > > effort into understanding the solution space.
> > > >
> > > > Reported-by: qianfan Zhao <qianfanguijin@163.com>
> > > > Reported-by: Adriana Nicolae <adriana@arista.com>
> > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > > > ---
> > > > drivers/tty/serial/8250/8250_dw.c | 159 +++++++++++++++++++++---------
> > > > 1 file changed, 115 insertions(+), 44 deletions(-)
> > > >
> > > > diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
> > > > index a53ba04d9770..8e25dfe8e653 100644
> > > > --- a/drivers/tty/serial/8250/8250_dw.c
> > > > +++ b/drivers/tty/serial/8250/8250_dw.c
> > > > @@ -42,6 +42,8 @@
> > > > /* DesignWare specific register fields */
> > > > #define DW_UART_MCR_SIRE BIT(6)
> > > >
> > > > +#define DW_UART_USR_BUSY BIT(0)
> > > > +
> > > > /* Renesas specific register fields */
> > > > #define RZN1_UART_xDMACR_DMA_EN BIT(0)
> > > > #define RZN1_UART_xDMACR_1_WORD_BURST (0 << 1)
> > > > @@ -77,6 +79,7 @@ struct dw8250_data {
> > > >
> > > > unsigned int skip_autocfg:1;
> > > > unsigned int uart_16550_compatible:1;
> > > > + unsigned int in_idle:1;
> > > > };
> > > >
> > > > static inline struct dw8250_data *to_dw8250_data(struct dw8250_port_data *data)
> > > > @@ -108,36 +111,103 @@ static inline u32 dw8250_modify_msr(struct uart_port *p, unsigned int offset, u3
> > > > }
> > > >
> > > > /*
> > > > - * This function is being called as part of the uart_port::serial_out()
> > > > - * routine. Hence, it must not call serial_port_out() or serial_out()
> > > > - * against the modified registers here, i.e. LCR.
> > > > + * Ensure BUSY is not asserted. If DW UART is configured with
> > > > + * !uart_16550_compatible, the writes to LCR, DLL, and DLH fail while
> > > > + * BUSY is asserted.
> > > > + *
> > > > + * Context: port's lock must be held
> > > > */
> > > > -static void dw8250_force_idle(struct uart_port *p)
> > > > +static int dw8250_idle_enter(struct uart_port *p)
> > > > {
> > > > + struct dw8250_data *d = to_dw8250_data(p->private_data);
> > > > struct uart_8250_port *up = up_to_u8250p(p);
> > > > - unsigned int lsr;
> > > > + u32 lsr;
> > > >
> > > > - /*
> > > > - * The following call currently performs serial_out()
> > > > - * against the FCR register. Because it differs to LCR
> > > > - * there will be no infinite loop, but if it ever gets
> > > > - * modified, we might need a new custom version of it
> > > > - * that avoids infinite recursion.
> > > > - */
> > > > - serial8250_clear_and_reinit_fifos(up);
> > > > + if (d->uart_16550_compatible)
> > > > + return 0;
> > > > +
> > > > + d->in_idle = 1;
> > > > +
> > > > + /* Prevent triggering interrupt from RBR filling */
> > > > + p->serial_out(p, UART_IER, 0);
> > > > +
> > > > + serial8250_rx_dma_flush(up);
> > > > + // What about Tx DMA? Should probably pause that too and resume
> > > > + // afterwards.
> > > > +
> > > > + p->serial_out(p, UART_MCR, up->mcr | UART_MCR_LOOP);
> > > > + if (up->capabilities & UART_CAP_FIFO)
> > > > + p->serial_out(p, UART_FCR, 0);
> > >
> > > Changing this to repeatedly clear the FIFO turned out to reliably
> > > clear the BUSY bit , also no kernel panic or device stuck in busy
> > > mode.
> > >
> > > On the device I tested the first clear is not always enough, under
> > > high load I saw it cleared on the second iteration. I'm thinking it
> > > might be some particular issue with the device I'm using where the
> > > first FIFO clear might fail. I never encountered more than 2
> > > iterations with a "ndelay(p->frame_time);" in between here to get out
> > > of BUSY state.
> >
> > Hi,
> >
> > I seem to have missed this email until now (I'm sorry about that, though
> > to my defence, IIRC, I was quite sick around that timeframe it was sent
> > and clear the email backlog isn't ever fun and may end up missing
> > something).
> >
> > Do you mean changing this to a simple loop or writing something else than
> > just 0 to FCR (or perhaps calling serial8250_clear_fifos())?
> >
> > What is the exact code that you found working?
> >
> Yes, everything worked ok for me after changing the dw8250_idle_enter
> function with the one below. From traces added in the function, it
> sometimes reported iterations_in_busy = 2 but never higher than that.
> The function only has the prepended "while(p->serial_in(p,
> d->pdata->usr_reg) & DW_UART_USR_BUSY) {" to iterate forever, although
> it was at most 2 iterations when serial was stressed:
> static int dw8250_idle_enter(struct uart_port *p)
> {
> struct dw8250_data *d = to_dw8250_data(p->private_data);
> struct uart_8250_port *up = up_to_u8250p(p);
> u32 lsr, iterations_in_busy = 0;
>
> if (d->uart_16550_compatible)
> return 0;
>
> d->in_idle = 1;
>
> /* Prevent triggering interrupt from RBR filling */
> p->serial_out(p, UART_IER, 0);
>
> serial8250_rx_dma_flush(up);
> // What about Tx DMA? Should probably pause that too and resume
> // afterwards.
> p->serial_out(p, UART_MCR, up->mcr | UART_MCR_LOOP);
>
> while(p->serial_in(p, d->pdata->usr_reg) & DW_UART_USR_BUSY) {
> if (up->capabilities & UART_CAP_FIFO) {
> p->serial_out(p, UART_FCR, UART_FCR_ENABLE_FIFO);
> p->serial_out(p, UART_FCR, UART_FCR_ENABLE_FIFO |
> UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT);
> p->serial_out(p, UART_FCR, 0);
Thanks for the information!
Okay, so this is same as calling serial8250_clear_fifos() which is what
I'll do here.
> }
> ndelay(p->frame_time);
> iterations_in_busy++;
> }
>
> trace_printk("Not busy got after %d\n", iterations_in_busy);
> lsr = serial_lsr_in(up);
> if (lsr & UART_LSR_DR) {
> p->serial_in(p, UART_RX);
> up->lsr_saved_flags = 0;
> }
>
> /*
> * BUSY might still be frozen to asserted, try to de-freeze it by
> * sending a character over the loopback and receiving it.
> */
> if (p->serial_in(p, d->pdata->usr_reg) & DW_UART_USR_BUSY) {
> trace_printk("Serial USR still busy\n");
> p->serial_out(p, UART_TX, 0);
> ndelay(1000);
> lsr = serial_lsr_in(up);
>
> if (lsr & UART_LSR_DR) {
> p->serial_in(p, UART_RX);
> up->lsr_saved_flags = 0;
> }
> }
So I think this entire tx+rx de-freezing wasn't required at all? Adding
this was based on my guess how the driver could try to force BUSY
deassertion but if the FIFOs were the real culprit to the BUSY remaining
asserted, I'd prefer to remove this block entirely to not add random
complexity just for the sake of doing everything imaginable.
> /* Now guaranteed to have BUSY deasserted? Just sanity check */
> if (p->serial_in(p, d->pdata->usr_reg) & DW_UART_USR_BUSY) {
> trace_printk("BUSY\n");
> return -EBUSY;
> }
>
> return 0;
> }
> > So when you fixed this FIFO clearing thing, everything seemed to work okay
> > after that?
> >
> > In the meantime, this issue has once again been reported to me by somebody
> > else, and I've done improvements to shutdown code as well to address a
> > few BUSY related problems (I'll be posting a series that solved that
> > case soon but I suppose this patch needs amendments based on input from
> > your case).
> >
> > --
> > i.
> >
> > > > + if (p->serial_in(p, d->pdata->usr_reg) & DW_UART_USR_BUSY)
> > > > + ndelay(p->frame_time);
> > > > +
> > > > + lsr = serial_lsr_in(up);
> > > > + if (lsr & UART_LSR_DR) {
> > > > + p->serial_in(p, UART_RX);
> > > > + up->lsr_saved_flags = 0;
> > > > + }
> > > >
> > > > /*
> > > > - * With PSLVERR_RESP_EN parameter set to 1, the device generates an
> > > > - * error response when an attempt to read an empty RBR with FIFO
> > > > - * enabled.
> > > > + * BUSY might still be frozen to asserted, try to de-freeze it by
> > > > + * sending a character over the loopback and receiving it.
> > > > */
> > > > - if (up->fcr & UART_FCR_ENABLE_FIFO) {
> > > > - lsr = serial_port_in(p, UART_LSR);
> > > > - if (!(lsr & UART_LSR_DR))
> > > > - return;
> > > > + if (p->serial_in(p, d->pdata->usr_reg) & DW_UART_USR_BUSY) {
> > > > + p->serial_out(p, UART_TX, 0);
> > > > + ndelay(p->frame_time);
> > > > + lsr = serial_lsr_in(up);
> > > > + if (lsr & UART_LSR_DR) {
> > > > + p->serial_in(p, UART_RX);
> > > > + up->lsr_saved_flags = 0;
> > > > + }
> > > > }
> > > >
> > > > - serial_port_in(p, UART_RX);
> > > > + /* Now guaranteed to have BUSY deasserted? Just sanity check */
> > > > + if (p->serial_in(p, d->pdata->usr_reg) & DW_UART_USR_BUSY)
> > > > + return -EBUSY;
> > > > +
> > > > + return 0;
> > > > +}
--
i.
^ permalink raw reply
* [PATCH v1 0/2] serial: 8250: Remove highly customised deprecated interface
From: Andy Shevchenko @ 2026-01-22 10:19 UTC (permalink / raw)
To: Andy Shevchenko, Greg Kroah-Hartman, Jiri Slaby (SUSE), linux-doc,
linux-kernel, linux-serial
Cc: Jonathan Corbet, Shuah Khan, Kevin Hilman, Tony Lindgren
The custom divisor interface not only old and deprecated, it's too much
driver-dependent. For the user it's not easy to understand what to supply
as a value (usually encoded) via that interface. On top of it, there is
an existing BOTHER mechanism that allows to do the same and more without
any tribal knowledge.
Remove highly customised deprecated interface to set baud rates.
Note, the "standard" custom_divisor that is used as a plain value
for "quot" is still left and may be used by the respective drivers
including but not limited to 8250.
Andy Shevchenko (2):
serial: 8250_omap: Remove custom deprecated baud setting routine
serial: 8250_pci: Remove custom deprecated baud setting routine
Documentation/misc-devices/oxsemi-tornado.rst | 26 +-----
drivers/tty/serial/8250/8250_omap.c | 16 ----
drivers/tty/serial/8250/8250_pci.c | 85 ++++++++-----------
3 files changed, 38 insertions(+), 89 deletions(-)
--
2.50.1
^ 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