* Re: [PATCH v2 08/15] serial: earlycon: use uart_iotype_*() to simplify code
From: Andy Shevchenko @ 2026-05-04 16:01 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Greg Kroah-Hartman, Jiri Slaby, ilpo.jarvinen, linux-kernel,
linux-serial, Hugo Villeneuve
In-Reply-To: <20260504114001.a20541e974060c6fe2f26ba1@hugovil.com>
On Mon, May 04, 2026 at 11:40:01AM -0400, Hugo Villeneuve wrote:
> On Thu, 30 Apr 2026 17:03:35 +0200
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > On Tue, Apr 28, 2026 at 01:53:54PM -0400, Hugo Villeneuve wrote:
...
> > > + char address[64] = "";
> >
> > TBH, I prefer two pr_info() calls as that approach
> > - doesn't require temporary buffer
> > - doesn't use heavy s*printf() on top of the existing printing
> > - doesn't limit the flexibility of each of the strings (64 might
> > become not enough in some cases, however unlikely to happen)
>
> Note that this approach is already used in uart_report_port().
Yeah, yeah... I noticed that after review.
> Also this patch may be reworked if patch "serial: uniformize serial
> port I/O infos display" is deemed ok...
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3] tty: synclink_gt: remove broken driver
From: Jakub Kicinski @ 2026-05-05 0:03 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-doc, netdev, linux-serial, rust-for-linux, Jonathan Corbet,
Shuah Khan, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Greg Kroah-Hartman,
Jiri Slaby, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Bagas Sanjaya, Haren Myneni,
Eric Biggers, Julian Braha, Qingfang Deng
In-Reply-To: <20260504031519.18877-1-enelsonmoore@gmail.com>
On Sun, 3 May 2026 20:14:53 -0700 Ethan Nelson-Moore wrote:
> drivers/net/ppp/Kconfig | 4 +-
Acked-by: Jakub Kicinski <kuba@kernel.org>
^ permalink raw reply
* [PATCH 0/3] Small cleanups to serial driver organization, configuration, and documentation
From: Ethan Nelson-Moore @ 2026-05-05 1:20 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Ilpo Järvinen,
Andy Shevchenko, Ethan Nelson-Moore
This patch series moves some serial drivers into the serial/ directory
to improve organization, and removes the SERIAL_NONSTANDARD config
option, which adds unnecessary complexity. It also fixes a number of
issues in Documentation/driver-api/tty/index.rst, which I noticed
while making the above changes. The patch to remove SERIAL_NONSTANDARD
touches sections of the tty and serial Kconfig files which are also
touched by the patch to move drivers, and therefore the patches would
fail to apply separately, so I am sending them as a series.
Ethan Nelson-Moore (3):
tty: move remaining serial drivers into the serial/ directory
tty: remove unnecessary SERIAL_NONSTANDARD config option
docs: driver-api/tty/index.rst: copy-editing; improve organization
Documentation/driver-api/serial/index.rst | 1 +
.../{tty => serial}/moxa-smartio.rst | 0
Documentation/driver-api/tty/index.rst | 47 +++++++++----------
MAINTAINERS | 4 +-
arch/arm/configs/footbridge_defconfig | 1 -
arch/arm/configs/lpc18xx_defconfig | 1 -
arch/arm/configs/mps2_defconfig | 1 -
arch/arm/configs/neponset_defconfig | 1 -
arch/arm/configs/stm32_defconfig | 1 -
arch/csky/configs/defconfig | 1 -
arch/loongarch/configs/loongson32_defconfig | 1 -
arch/loongarch/configs/loongson64_defconfig | 1 -
arch/mips/configs/bigsur_defconfig | 1 -
arch/mips/configs/lemote2f_defconfig | 1 -
arch/mips/configs/loongson2k_defconfig | 1 -
arch/mips/configs/loongson3_defconfig | 1 -
arch/powerpc/configs/cell_defconfig | 1 -
arch/powerpc/configs/microwatt_defconfig | 1 -
arch/powerpc/configs/ppc6xx_defconfig | 1 -
arch/sh/configs/polaris_defconfig | 1 -
arch/x86/configs/i386_defconfig | 1 -
arch/x86/configs/x86_64_defconfig | 1 -
drivers/tty/Kconfig | 41 ----------------
drivers/tty/Makefile | 3 --
drivers/tty/serial/Kconfig | 23 +++++++++
drivers/tty/serial/Makefile | 6 ++-
drivers/tty/{ => serial}/amiserial.c | 0
drivers/tty/{ => serial}/moxa.c | 0
drivers/tty/{ => serial}/mxser.c | 0
tools/testing/selftests/bpf/config.x86_64 | 1 -
tools/testing/selftests/hid/config.common | 1 -
31 files changed, 54 insertions(+), 91 deletions(-)
rename Documentation/driver-api/{tty => serial}/moxa-smartio.rst (100%)
rename drivers/tty/{ => serial}/amiserial.c (100%)
rename drivers/tty/{ => serial}/moxa.c (100%)
rename drivers/tty/{ => serial}/mxser.c (100%)
--
2.43.0
^ permalink raw reply
* [PATCH 1/3] tty: move remaining serial drivers into the serial/ directory
From: Ethan Nelson-Moore @ 2026-05-05 1:20 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Ilpo Järvinen,
Andy Shevchenko, Ethan Nelson-Moore
In-Reply-To: <cover.1777943090.git.enelsonmoore@gmail.com>
A few TTY drivers are outside the serial/ directory despite being for
serial devices. Move them and their documentation into the correct
directories.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
Documentation/driver-api/serial/index.rst | 1 +
.../{tty => serial}/moxa-smartio.rst | 0
Documentation/driver-api/tty/index.rst | 1 -
MAINTAINERS | 4 ++--
drivers/tty/Kconfig | 23 -------------------
drivers/tty/Makefile | 3 ---
drivers/tty/serial/Kconfig | 23 +++++++++++++++++++
drivers/tty/serial/Makefile | 6 ++++-
drivers/tty/{ => serial}/amiserial.c | 0
drivers/tty/{ => serial}/moxa.c | 0
drivers/tty/{ => serial}/mxser.c | 0
11 files changed, 31 insertions(+), 30 deletions(-)
rename Documentation/driver-api/{tty => serial}/moxa-smartio.rst (100%)
rename drivers/tty/{ => serial}/amiserial.c (100%)
rename drivers/tty/{ => serial}/moxa.c (100%)
rename drivers/tty/{ => serial}/mxser.c (100%)
diff --git a/Documentation/driver-api/serial/index.rst b/Documentation/driver-api/serial/index.rst
index 610744df5e8d..f92581fc3478 100644
--- a/Documentation/driver-api/serial/index.rst
+++ b/Documentation/driver-api/serial/index.rst
@@ -18,3 +18,4 @@ Serial drivers
serial-iso7816
serial-rs485
+ moxa-smartio
diff --git a/Documentation/driver-api/tty/moxa-smartio.rst b/Documentation/driver-api/serial/moxa-smartio.rst
similarity index 100%
rename from Documentation/driver-api/tty/moxa-smartio.rst
rename to Documentation/driver-api/serial/moxa-smartio.rst
diff --git a/Documentation/driver-api/tty/index.rst b/Documentation/driver-api/tty/index.rst
index c1ffe3d1ec46..6a08aebbc47c 100644
--- a/Documentation/driver-api/tty/index.rst
+++ b/Documentation/driver-api/tty/index.rst
@@ -70,6 +70,5 @@ Miscellaneous documentation can be further found in these documents:
.. toctree::
:maxdepth: 2
- moxa-smartio
n_gsm
n_tty
diff --git a/MAINTAINERS b/MAINTAINERS
index 882214b0e7db..c99671d465af 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18022,8 +18022,8 @@ F: net/dsa/tag_yt921x.c
MOXA SMARTIO/INDUSTIO/INTELLIO SERIAL CARD
M: Jiri Slaby <jirislaby@kernel.org>
S: Maintained
-F: Documentation/driver-api/tty/moxa-smartio.rst
-F: drivers/tty/mxser.*
+F: Documentation/driver-api/serial/moxa-smartio.rst
+F: drivers/tty/serial/mxser.*
MP3309C BACKLIGHT DRIVER
M: Flavio Suligoi <f.suligoi@asem.it>
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index df6832a4c237..63b378e44a59 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -208,29 +208,6 @@ config SERIAL_NONSTANDARD
Most people can say N here.
-config MOXA_INTELLIO
- tristate "Moxa Intellio support"
- depends on SERIAL_NONSTANDARD && PCI
- select FW_LOADER
- help
- Say Y here if you have a Moxa Intellio multiport serial card.
-
- To compile this driver as a module, choose M here: the
- module will be called moxa.
-
-config MOXA_SMARTIO
- tristate "Moxa SmartIO support v. 2.0"
- depends on SERIAL_NONSTANDARD && PCI && HAS_IOPORT
- help
- Say Y here if you have a Moxa SmartIO multiport serial card and/or
- want to help develop a new version of this driver.
-
- This is upgraded (1.9.1) driver from original Moxa drivers with
- changes finally resulting in PCI probing.
-
- This driver can also be built as a module. The module will be called
- mxser. If you want to do that, say M here.
-
config N_HDLC
tristate "HDLC line discipline support"
depends on SERIAL_NONSTANDARD
diff --git a/drivers/tty/Makefile b/drivers/tty/Makefile
index 8ca1a0a2229f..fd88830b925d 100644
--- a/drivers/tty/Makefile
+++ b/drivers/tty/Makefile
@@ -16,9 +16,6 @@ obj-y += serial/
obj-$(CONFIG_SERIAL_DEV_BUS) += serdev/
# tty drivers
-obj-$(CONFIG_AMIGA_BUILTIN_SERIAL) += amiserial.o
-obj-$(CONFIG_MOXA_INTELLIO) += moxa.o
-obj-$(CONFIG_MOXA_SMARTIO) += mxser.o
obj-$(CONFIG_NOZOMI) += nozomi.o
obj-$(CONFIG_NULL_TTY) += ttynull.o
obj-$(CONFIG_PPC_EPAPR_HV_BYTECHAN) += ehv_bytechan.o
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 9aa61c93d7bc..999f56307445 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1592,6 +1592,29 @@ config SERIAL_NUVOTON_MA35D1_CONSOLE
but you can alter that using a kernel command line option such as
"console=ttyNVTx".
+config MOXA_INTELLIO
+ tristate "Moxa Intellio support"
+ depends on SERIAL_NONSTANDARD && PCI
+ select FW_LOADER
+ help
+ Say Y here if you have a Moxa Intellio multiport serial card.
+
+ To compile this driver as a module, choose M here: the
+ module will be called moxa.
+
+config MOXA_SMARTIO
+ tristate "Moxa SmartIO support v. 2.0"
+ depends on SERIAL_NONSTANDARD && PCI && HAS_IOPORT
+ help
+ Say Y here if you have a Moxa SmartIO multiport serial card and/or
+ want to help develop a new version of this driver.
+
+ This is upgraded (1.9.1) driver from original Moxa drivers with
+ changes finally resulting in PCI probing.
+
+ This driver can also be built as a module. The module will be called
+ mxser. If you want to do that, say M here.
+
endmenu
config SERIAL_MCTRL_GPIO
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index bba7b21a4a1d..246e0cf29fcc 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -10,9 +10,11 @@ obj-$(CONFIG_SERIAL_EARLYCON) += earlycon.o
obj-$(CONFIG_SERIAL_EARLYCON_SEMIHOST) += earlycon-semihost.o
obj-$(CONFIG_SERIAL_EARLYCON_RISCV_SBI) += earlycon-riscv-sbi.o
-# These Sparc drivers have to appear before others such as 8250
+# These drivers have to appear before others such as 8250
# which share ttySx minor node space. Otherwise console device
# names change and other unplesantries.
+obj-$(CONFIG_AMIGA_BUILTIN_SERIAL) += amiserial.o
+
obj-$(CONFIG_SERIAL_SUNCORE) += suncore.o
obj-$(CONFIG_SERIAL_SUNHV) += sunhv.o
obj-$(CONFIG_SERIAL_SUNZILOG) += sunzilog.o
@@ -53,12 +55,14 @@ obj-$(CONFIG_SERIAL_MCF) += mcf.o
obj-$(CONFIG_SERIAL_MEN_Z135) += men_z135_uart.o
obj-$(CONFIG_SERIAL_MILBEAUT_USIO) += milbeaut_usio.o
obj-$(CONFIG_SERIAL_MESON) += meson_uart.o
+obj-$(CONFIG_MOXA_INTELLIO) += moxa.o
obj-$(CONFIG_SERIAL_MPC52xx) += mpc52xx_uart.o
obj-$(CONFIG_SERIAL_MPS2_UART) += mps2-uart.o
obj-$(CONFIG_SERIAL_MSM) += msm_serial.o
obj-$(CONFIG_SERIAL_MUX) += mux.o
obj-$(CONFIG_SERIAL_MVEBU_UART) += mvebu-uart.o
obj-$(CONFIG_SERIAL_MXS_AUART) += mxs-auart.o
+obj-$(CONFIG_MOXA_SMARTIO) += mxser.o
obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o
obj-$(CONFIG_SERIAL_OWL) += owl-uart.o
obj-$(CONFIG_SERIAL_PCH_UART) += pch_uart.o
diff --git a/drivers/tty/amiserial.c b/drivers/tty/serial/amiserial.c
similarity index 100%
rename from drivers/tty/amiserial.c
rename to drivers/tty/serial/amiserial.c
diff --git a/drivers/tty/moxa.c b/drivers/tty/serial/moxa.c
similarity index 100%
rename from drivers/tty/moxa.c
rename to drivers/tty/serial/moxa.c
diff --git a/drivers/tty/mxser.c b/drivers/tty/serial/mxser.c
similarity index 100%
rename from drivers/tty/mxser.c
rename to drivers/tty/serial/mxser.c
--
2.43.0
^ permalink raw reply related
* [PATCH 2/3] tty: remove unnecessary SERIAL_NONSTANDARD config option
From: Ethan Nelson-Moore @ 2026-05-05 1:20 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Ilpo Järvinen,
Andy Shevchenko, Ethan Nelson-Moore
In-Reply-To: <cover.1777943090.git.enelsonmoore@gmail.com>
The SERIAL_NONSTANDARD config option currently only guards the
selection of two Moxa multiport serial card drivers and the HDLC line
discipline, so it does not significantly simplify configuration. Make
the configuration process more straightforward by dropping this option
and dependencies on it.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
| 1 -
arch/arm/configs/lpc18xx_defconfig | 1 -
arch/arm/configs/mps2_defconfig | 1 -
arch/arm/configs/neponset_defconfig | 1 -
arch/arm/configs/stm32_defconfig | 1 -
arch/csky/configs/defconfig | 1 -
arch/loongarch/configs/loongson32_defconfig | 1 -
arch/loongarch/configs/loongson64_defconfig | 1 -
arch/mips/configs/bigsur_defconfig | 1 -
arch/mips/configs/lemote2f_defconfig | 1 -
arch/mips/configs/loongson2k_defconfig | 1 -
arch/mips/configs/loongson3_defconfig | 1 -
arch/powerpc/configs/cell_defconfig | 1 -
arch/powerpc/configs/microwatt_defconfig | 1 -
arch/powerpc/configs/ppc6xx_defconfig | 1 -
arch/sh/configs/polaris_defconfig | 1 -
arch/x86/configs/i386_defconfig | 1 -
arch/x86/configs/x86_64_defconfig | 1 -
drivers/tty/Kconfig | 18 ------------------
drivers/tty/serial/Kconfig | 4 ++--
tools/testing/selftests/bpf/config.x86_64 | 1 -
tools/testing/selftests/hid/config.common | 1 -
22 files changed, 2 insertions(+), 40 deletions(-)
--git a/arch/arm/configs/footbridge_defconfig b/arch/arm/configs/footbridge_defconfig
index 5f6963687ee4..58234fd3af4b 100644
--- a/arch/arm/configs/footbridge_defconfig
+++ b/arch/arm/configs/footbridge_defconfig
@@ -70,7 +70,6 @@ CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_SERIAL_21285=y
CONFIG_SERIAL_21285_CONSOLE=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_PRINTER=m
CONFIG_DS1620=y
CONFIG_NWBUTTON=y
diff --git a/arch/arm/configs/lpc18xx_defconfig b/arch/arm/configs/lpc18xx_defconfig
index f142a6637ede..9ca18939b82a 100644
--- a/arch/arm/configs/lpc18xx_defconfig
+++ b/arch/arm/configs/lpc18xx_defconfig
@@ -92,7 +92,6 @@ CONFIG_KEYBOARD_GPIO_POLLED=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
-CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C_LPC2K=y
CONFIG_SPI=y
diff --git a/arch/arm/configs/mps2_defconfig b/arch/arm/configs/mps2_defconfig
index e995e50537ef..a1045dee7e8a 100644
--- a/arch/arm/configs/mps2_defconfig
+++ b/arch/arm/configs/mps2_defconfig
@@ -66,7 +66,6 @@ CONFIG_SMSC911X=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_MPS2_UART_CONSOLE=y
CONFIG_SERIAL_MPS2_UART=y
-CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_HW_RANDOM is not set
# CONFIG_HWMON is not set
CONFIG_WATCHDOG=y
diff --git a/arch/arm/configs/neponset_defconfig b/arch/arm/configs/neponset_defconfig
index 8a5dcca743fc..2080e4dfdd6c 100644
--- a/arch/arm/configs/neponset_defconfig
+++ b/arch/arm/configs/neponset_defconfig
@@ -51,7 +51,6 @@ CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CS=y
CONFIG_SERIAL_SA1100=y
CONFIG_SERIAL_SA1100_CONSOLE=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_WATCHDOG=y
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index 82190b155b14..919c70107371 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -39,7 +39,6 @@ CONFIG_KEYBOARD_GPIO=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_STM32=y
CONFIG_SERIAL_STM32_CONSOLE=y
-CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
diff --git a/arch/csky/configs/defconfig b/arch/csky/configs/defconfig
index ff559e5162aa..481b51eadf41 100644
--- a/arch/csky/configs/defconfig
+++ b/arch/csky/configs/defconfig
@@ -20,7 +20,6 @@ CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=65536
CONFIG_VT_HW_CONSOLE_BINDING=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
diff --git a/arch/loongarch/configs/loongson32_defconfig b/arch/loongarch/configs/loongson32_defconfig
index d5ef396dffe3..5dd7b8cb8957 100644
--- a/arch/loongarch/configs/loongson32_defconfig
+++ b/arch/loongarch/configs/loongson32_defconfig
@@ -723,7 +723,6 @@ CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_8250_LOONGSON=y
CONFIG_SERIAL_OF_PLATFORM=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_PRINTER=m
CONFIG_VIRTIO_CONSOLE=y
CONFIG_HW_RANDOM=y
diff --git a/arch/loongarch/configs/loongson64_defconfig b/arch/loongarch/configs/loongson64_defconfig
index cba4cdff5acd..80396cd61755 100644
--- a/arch/loongarch/configs/loongson64_defconfig
+++ b/arch/loongarch/configs/loongson64_defconfig
@@ -739,7 +739,6 @@ CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_8250_LOONGSON=y
CONFIG_SERIAL_OF_PLATFORM=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_PRINTER=m
CONFIG_VIRTIO_CONSOLE=y
CONFIG_IPMI_HANDLER=m
diff --git a/arch/mips/configs/bigsur_defconfig b/arch/mips/configs/bigsur_defconfig
index aa63ada62e28..602795e2659c 100644
--- a/arch/mips/configs/bigsur_defconfig
+++ b/arch/mips/configs/bigsur_defconfig
@@ -121,7 +121,6 @@ CONFIG_SLIP_MODE_SLIP6=y
# CONFIG_INPUT is not set
CONFIG_SERIO_RAW=m
# CONFIG_VT is not set
-CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
diff --git a/arch/mips/configs/lemote2f_defconfig b/arch/mips/configs/lemote2f_defconfig
index b9f3e1641105..084b569cf8d8 100644
--- a/arch/mips/configs/lemote2f_defconfig
+++ b/arch/mips/configs/lemote2f_defconfig
@@ -125,7 +125,6 @@ CONFIG_SERIAL_8250_NR_UARTS=16
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_FOURPORT=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_HW_RANDOM=y
CONFIG_GPIO_LOONGSON=y
CONFIG_THERMAL=y
diff --git a/arch/mips/configs/loongson2k_defconfig b/arch/mips/configs/loongson2k_defconfig
index ca534a6b66de..0b29ad43b62b 100644
--- a/arch/mips/configs/loongson2k_defconfig
+++ b/arch/mips/configs/loongson2k_defconfig
@@ -222,7 +222,6 @@ CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_OF_PLATFORM=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_HW_RANDOM=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_PIIX4=y
diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig
index 12cb1a6a1360..00bf6358357f 100644
--- a/arch/mips/configs/loongson3_defconfig
+++ b/arch/mips/configs/loongson3_defconfig
@@ -254,7 +254,6 @@ CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_OF_PLATFORM=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_HW_RANDOM=y
CONFIG_I2C_CHARDEV=y
diff --git a/arch/powerpc/configs/cell_defconfig b/arch/powerpc/configs/cell_defconfig
index 7a31b52e92e1..439c03172deb 100644
--- a/arch/powerpc/configs/cell_defconfig
+++ b/arch/powerpc/configs/cell_defconfig
@@ -135,7 +135,6 @@ CONFIG_GELIC_WIRELESS=y
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO_I8042 is not set
# CONFIG_LEGACY_PTYS is not set
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
diff --git a/arch/powerpc/configs/microwatt_defconfig b/arch/powerpc/configs/microwatt_defconfig
index d81989a6f59b..60dce8b41f97 100644
--- a/arch/powerpc/configs/microwatt_defconfig
+++ b/arch/powerpc/configs/microwatt_defconfig
@@ -64,7 +64,6 @@ CONFIG_LITEX_LITEETH=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
-CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_NVRAM is not set
CONFIG_SPI=y
CONFIG_SPI_DEBUG=y
diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig
index 4ddd2c01b8b7..b745965c5215 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -550,7 +550,6 @@ CONFIG_GAMEPORT_L4=m
CONFIG_GAMEPORT_EMU10K1=m
CONFIG_GAMEPORT_FM801=m
# CONFIG_LEGACY_PTYS is not set
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_NOZOMI=m
CONFIG_N_HDLC=m
CONFIG_SERIAL_8250=y
diff --git a/arch/sh/configs/polaris_defconfig b/arch/sh/configs/polaris_defconfig
index 4f0396c2ac79..0b51a85300a6 100644
--- a/arch/sh/configs/polaris_defconfig
+++ b/arch/sh/configs/polaris_defconfig
@@ -54,7 +54,6 @@ CONFIG_SMSC911X=y
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO is not set
CONFIG_VT_HW_CONSOLE_BINDING=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_NR_UARTS=3
CONFIG_SERIAL_SH_SCI_CONSOLE=y
diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig
index 79fa38ca954d..b67e7073da10 100644
--- a/arch/x86/configs/i386_defconfig
+++ b/arch/x86/configs/i386_defconfig
@@ -182,7 +182,6 @@ CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_HW_RANDOM=y
CONFIG_NVRAM=y
diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig
index 269f7d808be4..5db8acec1e37 100644
--- a/arch/x86/configs/x86_64_defconfig
+++ b/arch/x86/configs/x86_64_defconfig
@@ -177,7 +177,6 @@ CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_INTEL is not set
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index 63b378e44a59..a9ade8bc88b2 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -191,26 +191,8 @@ config LDISC_AUTOLOAD
source "drivers/tty/serial/Kconfig"
-config SERIAL_NONSTANDARD
- bool "Non-standard serial port support"
- depends on HAS_IOMEM
- help
- Say Y here if you have any non-standard serial boards -- boards
- which aren't supported using the standard "dumb" serial driver.
- This includes intelligent serial boards such as
- Digiboards, etc. These are usually used for systems that need many
- serial ports because they serve many terminals or dial-in
- connections.
-
- Note that the answer to this question won't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about non-standard serial boards.
-
- Most people can say N here.
-
config N_HDLC
tristate "HDLC line discipline support"
- depends on SERIAL_NONSTANDARD
help
Allows synchronous HDLC communications with tty device drivers that
support synchronous HDLC.
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 999f56307445..6e448a6f1020 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1594,7 +1594,7 @@ config SERIAL_NUVOTON_MA35D1_CONSOLE
config MOXA_INTELLIO
tristate "Moxa Intellio support"
- depends on SERIAL_NONSTANDARD && PCI
+ depends on PCI
select FW_LOADER
help
Say Y here if you have a Moxa Intellio multiport serial card.
@@ -1604,7 +1604,7 @@ config MOXA_INTELLIO
config MOXA_SMARTIO
tristate "Moxa SmartIO support v. 2.0"
- depends on SERIAL_NONSTANDARD && PCI && HAS_IOPORT
+ depends on PCI && HAS_IOPORT
help
Say Y here if you have a Moxa SmartIO multiport serial card and/or
want to help develop a new version of this driver.
diff --git a/tools/testing/selftests/bpf/config.x86_64 b/tools/testing/selftests/bpf/config.x86_64
index 42ad817b00ae..2fc3e7e6ae5e 100644
--- a/tools/testing/selftests/bpf/config.x86_64
+++ b/tools/testing/selftests/bpf/config.x86_64
@@ -189,7 +189,6 @@ CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIO_LIBPS2=y
CONFIG_SGI_PARTITION=y
CONFIG_SMP=y
diff --git a/tools/testing/selftests/hid/config.common b/tools/testing/selftests/hid/config.common
index 38c51158adf8..89a83cda737b 100644
--- a/tools/testing/selftests/hid/config.common
+++ b/tools/testing/selftests/hid/config.common
@@ -201,7 +201,6 @@ CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250=y
-CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIO_LIBPS2=y
CONFIG_SGI_PARTITION=y
CONFIG_SMP=y
--
2.43.0
^ permalink raw reply related
* [PATCH 3/3] docs: driver-api/tty/index.rst: copy-editing; improve organization
From: Ethan Nelson-Moore @ 2026-05-05 1:20 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Ilpo Järvinen,
Andy Shevchenko, Ethan Nelson-Moore
In-Reply-To: <cover.1777943090.git.enelsonmoore@gmail.com>
The TTY driver API intro document contains a number of grammar and
capitalization issues. Fix them.
Now that the MOXA Smartio driver documentation is in the serial/
directory, the "Other Documentation" section only contains TTY line
disciplines. Rename it to reflect that.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
Documentation/driver-api/tty/index.rst | 46 +++++++++++++-------------
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/Documentation/driver-api/tty/index.rst b/Documentation/driver-api/tty/index.rst
index 6a08aebbc47c..eb5d602450f8 100644
--- a/Documentation/driver-api/tty/index.rst
+++ b/Documentation/driver-api/tty/index.rst
@@ -4,29 +4,30 @@
TTY
===
-Teletypewriter (TTY) layer takes care of all those serial devices. Including
-the virtual ones like pseudoterminal (PTY).
+The teletypewriter (TTY) layer handles all serial devices, including
+virtual ones like pseudoterminals (PTYs).
-TTY structures
+TTY Structures
==============
There are several major TTY structures. Every TTY device in a system has a
corresponding struct tty_port. These devices are maintained by a TTY driver
-which is struct tty_driver. This structure describes the driver but also
-contains a reference to operations which could be performed on the TTYs. It is
-struct tty_operations. Then, upon open, a struct tty_struct is allocated and
+defined by struct tty_driver. This structure describes the driver but also
+contains a reference to struct tty_operations, which defines operations which
+can be performed on the TTY. Upon open, a struct tty_struct is allocated and
lives until the final close. During this time, several callbacks from struct
tty_operations are invoked by the TTY layer.
-Every character received by the kernel (both from devices and users) is passed
+Every character received by the kernel (from both devices and users) is passed
through a preselected :doc:`tty_ldisc` (in
short ldisc; in C, struct tty_ldisc_ops). Its task is to transform characters
-as defined by a particular ldisc or by user too. The default one is n_tty,
-implementing echoes, signal handling, jobs control, special characters
-processing, and more. The transformed characters are passed further to
-user/device, depending on the source.
+as defined by a particular ldisc or by the user. The default one is n_tty,
+which implements echoes, signal handling, jobs control, special characters
+processing, and more. The transformed characters are passed on further to the
+user or device, depending on the source.
-In-detail description of the named TTY structures is in separate documents:
+A detailed description of the named TTY structures is contained in separate
+documents:
.. toctree::
:maxdepth: 2
@@ -40,14 +41,14 @@ In-detail description of the named TTY structures is in separate documents:
tty_internals
console
-Writing TTY Driver
-==================
+Writing TTY Drivers
+===================
-Before one starts writing a TTY driver, they must consider
-:doc:`Serial <../serial/driver>` and :doc:`USB Serial <../../usb/usb-serial>`
+Before you start writing a TTY driver, you should consider using the
+:doc:`serial <../serial/driver>` and :doc:`USB serial <../../usb/usb-serial>`
layers first. Drivers for serial devices can often use one of these specific
layers to implement a serial driver. Only special devices should be handled
-directly by the TTY Layer. If you are about to write such a driver, read on.
+directly by the TTY layer. If you are about to write such a driver, read on.
A *typical* sequence a TTY driver performs is as follows:
@@ -58,14 +59,13 @@ A *typical* sequence a TTY driver performs is as follows:
#. Remove devices as they are going away (remove function)
#. Unregister and free the TTY driver (module exit)
-Steps regarding driver, i.e. 1., 3., and 5. are described in detail in
-:doc:`tty_driver`. For the other two (devices handling), look into
-:doc:`tty_port`.
+Steps regarding the driver, i.e., steps 1, 3, and 5, are described in detail in
+:doc:`tty_driver`. For the other two (device handling), see :doc:`tty_port`.
-Other Documentation
-===================
+Line Disciplines
+================
-Miscellaneous documentation can be further found in these documents:
+Documentation for TTY line disciplines can be found in the following documents:
.. toctree::
:maxdepth: 2
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/3] tty: move remaining serial drivers into the serial/ directory
From: Jiri Slaby @ 2026-05-05 5:59 UTC (permalink / raw)
To: Ethan Nelson-Moore, linux-serial
Cc: Greg Kroah-Hartman, Ilpo Järvinen, Andy Shevchenko,
Ray Chen (陳松昱), Crescent CY Hsieh,
linux-m68k, Geert Uytterhoeven
In-Reply-To: <042d993686c87fdfd4130f11b57c3b559944603d.1777943090.git.enelsonmoore@gmail.com>
On 05. 05. 26, 3:20, Ethan Nelson-Moore wrote:
> A few TTY drivers are outside the serial/ directory despite being for
> serial devices.
Yes, but serial/ (historically) contains drivers using serial_core. tty/
contains drivers using tty_driver (which all of three unfortunately do).
There was a patchset from Crescent Hsieh (Moxa) to convert mxser [1].
Amiserial should be likely converted too -- Amiga users still around?
There is no MAINTAINERS entry for Amiga, trying to CC m68k...
I am not sure even about users of Moxa Intellio. I think I prompted long
time ago. Oh yes, Ray Chen (CCed) from Moxa wrote me back in 2021:
=== 8< ===
For the Intellio cards, we phased them out in 2017.
You may find the discontinuance notification as attached.
We will keep the software support for 5 years, to 2023.
=== 8< ===
I believe we can mark it as BROKEN to let someone convert it to
serial_core. Or drop it for good already.
[1]
https://lore.kernel.org/all/20251130104222.63077-1-crescentcy.hsieh@moxa.com/
thanks,
--
js
suse labs
^ permalink raw reply
* [PATCH] serial: jsm: Use named initializers for struct pci_device_id
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-05 7:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Lukas Wunner, Dave Jiang,
Giovanni Cabiddu, Kees Cook
Cc: linux-serial, linux-kernel, Markus Schneider-Pargmann
Initializing structures using list initializers is harder to read than
using named initializers. Seeing the member name is more ideomatic and
easier to understand.
Use named initializers for the driver's pci_device_id array. While at it
also drop an explicit zero in the terminating array entry.
There are no changes to the compiled result of the array; verified with
builds for x86 and arm64.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,
this is a preparing change for making struct pci_device_id::driver_data an
anonymous union (similar to
https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/).
This requires named initializers for .driver_data. But even without that
this is a nice cleanup making the array better readable.
Having said that I didn't find where .driver_data is used, so unless I
missed something the assignments can just go away???
For earlier patches of this type against other drivers I got the
feedback to use PCI_DEVICE_DATA() but I don't like that as it mixes
hardware properties (.vendor and .device) with driver specific software
properties (.driver_data) and thus I prefer the explicit listing
(involving more repetition) over the shorter variant (being more opaque
and harder to read).
Best regards
Uwe
drivers/tty/serial/jsm/jsm_driver.c | 75 +++++++++++++++++++++--------
1 file changed, 56 insertions(+), 19 deletions(-)
diff --git a/drivers/tty/serial/jsm/jsm_driver.c b/drivers/tty/serial/jsm/jsm_driver.c
index 4b73e51f83fb..422cac8d8d71 100644
--- a/drivers/tty/serial/jsm/jsm_driver.c
+++ b/drivers/tty/serial/jsm/jsm_driver.c
@@ -296,25 +296,62 @@ static void jsm_remove_one(struct pci_dev *pdev)
}
static const struct pci_device_id jsm_pci_tbl[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9), 0, 0, 0 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9PRI), 0, 0, 1 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45), 0, 0, 2 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45PRI), 0, 0, 3 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4_IBM), 0, 0, 4 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_DIGI_NEO_8), 0, 0, 5 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_4), 0, 0, 6 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422), 0, 0, 7 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422_485), 0, 0, 8 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2_422_485), 0, 0, 9 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8), 0, 0, 10 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4), 0, 0, 11 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4RJ45), 0, 0, 12 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8RJ45), 0, 0, 13 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_4), 0, 0, 14 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_4_422), 0, 0, 15 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_8), 0, 0, 16 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_8_422), 0, 0, 17 },
- { 0, }
+ {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9),
+ .driver_data = 0,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9PRI),
+ .driver_data = 1,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45),
+ .driver_data = 2,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45PRI),
+ .driver_data = 3,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4_IBM),
+ .driver_data = 4,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_DIGI_NEO_8),
+ .driver_data = 5,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_4),
+ .driver_data = 6,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422),
+ .driver_data = 7,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422_485),
+ .driver_data = 8,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2_422_485),
+ .driver_data = 9,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8),
+ .driver_data = 10,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4),
+ .driver_data = 11,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4RJ45),
+ .driver_data = 12,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8RJ45),
+ .driver_data = 13,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_4),
+ .driver_data = 14,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_4_422),
+ .driver_data = 15,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_8),
+ .driver_data = 16,
+ }, {
+ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_8_422),
+ .driver_data = 17,
+ },
+ { }
};
MODULE_DEVICE_TABLE(pci, jsm_pci_tbl);
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] serial: jsm: Use named initializers for struct pci_device_id
From: Jiri Slaby @ 2026-05-05 7:46 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub), Greg Kroah-Hartman,
Lukas Wunner, Dave Jiang, Giovanni Cabiddu, Kees Cook
Cc: linux-serial, linux-kernel, Markus Schneider-Pargmann
In-Reply-To: <20260505073044.2258674-2-u.kleine-koenig@baylibre.com>
On 05. 05. 26, 9:30, Uwe Kleine-König (The Capable Hub) wrote:
> Initializing structures using list initializers is harder to read than
> using named initializers. Seeing the member name is more ideomatic and
> easier to understand.
>
> Use named initializers for the driver's pci_device_id array. While at it
> also drop an explicit zero in the terminating array entry.
>
> There are no changes to the compiled result of the array; verified with
> builds for x86 and arm64.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> Hello,
>
> this is a preparing change for making struct pci_device_id::driver_data an
> anonymous union (similar to
> https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/).
> This requires named initializers for .driver_data. But even without that
> this is a nice cleanup making the array better readable.
>
> Having said that I didn't find where .driver_data is used, so unless I
> missed something the assignments can just go away???
>
> For earlier patches of this type against other drivers I got the
> feedback to use PCI_DEVICE_DATA() but I don't like that as it mixes
> hardware properties (.vendor and .device) with driver specific software
> properties (.driver_data) and thus I prefer the explicit listing
> (involving more repetition) over the shorter variant (being more opaque
> and harder to read).
>
> Best regards
> Uwe
>
> drivers/tty/serial/jsm/jsm_driver.c | 75 +++++++++++++++++++++--------
> 1 file changed, 56 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/tty/serial/jsm/jsm_driver.c b/drivers/tty/serial/jsm/jsm_driver.c
> index 4b73e51f83fb..422cac8d8d71 100644
> --- a/drivers/tty/serial/jsm/jsm_driver.c
> +++ b/drivers/tty/serial/jsm/jsm_driver.c
> @@ -296,25 +296,62 @@ static void jsm_remove_one(struct pci_dev *pdev)
> }
>
> static const struct pci_device_id jsm_pci_tbl[] = {
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9), 0, 0, 0 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9PRI), 0, 0, 1 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45), 0, 0, 2 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45PRI), 0, 0, 3 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4_IBM), 0, 0, 4 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_DIGI_NEO_8), 0, 0, 5 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_4), 0, 0, 6 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422), 0, 0, 7 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422_485), 0, 0, 8 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2_422_485), 0, 0, 9 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8), 0, 0, 10 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4), 0, 0, 11 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4RJ45), 0, 0, 12 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8RJ45), 0, 0, 13 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_4), 0, 0, 14 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_4_422), 0, 0, 15 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_8), 0, 0, 16 },
> - { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_8_422), 0, 0, 17 },
> - { 0, }
> + {
> + PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9),
> + .driver_data = 0,
> + }, {
Sorry, but this is definitely NOT "making the array better readable".
Esp. due to the split to multiple lines. PCI_DEVICE_DATA() would be far
better IMO. Or PCI_VDEVICE() + .driver_data on a single line...
Anyway, you're right, pci_device_id is not currently used at all.
Instead, there are big switches in the probe doing the casing. This
should be rewritten to actually use driver_data and drop the whole
switch-case stuff from probe.
So you can likely drop driver_data completely for now. It won't/can't be
used in the current form anyway.
thanks,
--
js
suse labs
^ permalink raw reply
* [PATCH v2] serial: jsm: Drop unused driver_data assigment and redundant zeros
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-05 8:47 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Lukas Wunner, Dave Jiang,
Giovanni Cabiddu, Kees Cook
Cc: linux-serial, linux-kernel, Markus Schneider-Pargmann
The driver doesn't use the driver_data field, so drop the assigment
together with the then redundant zero assigment for .class and
.class_mask. Also drop the zero in the list terminator.
While at it also use PCI_VDEVICE() to allow dropping "PCI_VENDOR_ID_".
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,
(implicit) v1 is available at
https://lore.kernel.org/linux-serial/20260505073044.2258674-2-u.kleine-koenig@baylibre.com
.
In the v1 discussion I mentioned that I don't spot a usage of
.driver_data and Jiri confirmed these are unused. So this v2 just drops
the respective assignments and thus circumvents the subjective
discussion if my v1 really made the array better readable. Also the
usage of PCI_VDEVICE() is new.
Best regards
Uwe
drivers/tty/serial/jsm/jsm_driver.c | 38 ++++++++++++++---------------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/tty/serial/jsm/jsm_driver.c b/drivers/tty/serial/jsm/jsm_driver.c
index 4b73e51f83fb..8cd9b981bf20 100644
--- a/drivers/tty/serial/jsm/jsm_driver.c
+++ b/drivers/tty/serial/jsm/jsm_driver.c
@@ -296,25 +296,25 @@ static void jsm_remove_one(struct pci_dev *pdev)
}
static const struct pci_device_id jsm_pci_tbl[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9), 0, 0, 0 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2DB9PRI), 0, 0, 1 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45), 0, 0, 2 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2RJ45PRI), 0, 0, 3 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4_IBM), 0, 0, 4 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_DIGI_NEO_8), 0, 0, 5 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_4), 0, 0, 6 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422), 0, 0, 7 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_1_422_485), 0, 0, 8 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_NEO_2_422_485), 0, 0, 9 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8), 0, 0, 10 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4), 0, 0, 11 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_4RJ45), 0, 0, 12 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCIE_DEVICE_ID_NEO_8RJ45), 0, 0, 13 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_4), 0, 0, 14 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_4_422), 0, 0, 15 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_8), 0, 0, 16 },
- { PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_ID_CLASSIC_8_422), 0, 0, 17 },
- { 0, }
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_NEO_2DB9) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_NEO_2DB9PRI) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_NEO_2RJ45) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_NEO_2RJ45PRI) },
+ { PCI_VDEVICE(DIGI, PCIE_DEVICE_ID_NEO_4_IBM) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_DIGI_NEO_8) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_NEO_4) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_NEO_1_422) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_NEO_1_422_485) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_NEO_2_422_485) },
+ { PCI_VDEVICE(DIGI, PCIE_DEVICE_ID_NEO_8) },
+ { PCI_VDEVICE(DIGI, PCIE_DEVICE_ID_NEO_4) },
+ { PCI_VDEVICE(DIGI, PCIE_DEVICE_ID_NEO_4RJ45) },
+ { PCI_VDEVICE(DIGI, PCIE_DEVICE_ID_NEO_8RJ45) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_CLASSIC_4) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_CLASSIC_4_422) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_CLASSIC_8) },
+ { PCI_VDEVICE(DIGI, PCI_DEVICE_ID_CLASSIC_8_422) },
+ { }
};
MODULE_DEVICE_TABLE(pci, jsm_pci_tbl);
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 13/15] serial: 8250_mxpcie: add break support for RS485 using MUEx50 features
From: Andy Shevchenko @ 2026-05-05 9:25 UTC (permalink / raw)
To: Crescent Hsieh
Cc: gregkh, jirislaby, ilpo.jarvinen, fangpingfp.cheng, linux-kernel,
linux-serial
In-Reply-To: <20260504084900.22380-14-crescentcy.hsieh@moxa.com>
On Mon, May 4, 2026 at 11:51 AM Crescent Hsieh
<crescentcy.hsieh@moxa.com> wrote:
>
> On MUEx50, break signaling under RS485 requires a driver-specific
> sequence and cannot be handled correctly by the generic 8250 break
> implementation alone.
>
> Implement a mxpcie break_ctl callback that performs MUEx50-specific
> break handling when RS485 is enabled and fall back to the default 8250
> break handling for other modes.
...
> + uart_port_lock_irqsave(port, &flags);
guard()() ?
> +
> + if (break_state == -1) {
> + serial_out(up, UART_LCR, up->lcr | UART_LCR_DLAB);
> + serial_out(up, UART_DLL, 0);
> + serial_out(up, UART_DLM, 0);
> + serial_out(up, UART_LCR, up->lcr);
Don't we have a helper doing this?
serial_dl_write()
> + serial_out(up, MOXA_PUART_TX_FIFO_MEM, tx_byte);
> +
> + sfr = serial_in(up, MOXA_PUART_SFR);
> + serial_out(up, MOXA_PUART_SFR, sfr | MOXA_PUART_SFR_FORCE_TX);
> +
> + up->lcr |= UART_LCR_SBC;
> + serial_out(up, UART_LCR, up->lcr);
> + } else {
> + up->lcr &= ~UART_LCR_SBC;
> + serial_out(up, UART_LCR, up->lcr);
> +
> + sfr = serial_in(up, MOXA_PUART_SFR);
> + serial_out(up, MOXA_PUART_SFR, sfr &= ~MOXA_PUART_SFR_FORCE_TX);
> +
> + serial_out(up, UART_FCR, UART_FCR_CLEAR_XMIT);
> +
> + baud = tty_get_baud_rate(tty);
> + quot = uart_get_divisor(port, baud);
> + serial8250_do_set_divisor(port, baud, quot);
> + serial_out(up, UART_LCR, up->lcr);
> + }
> + uart_port_unlock_irqrestore(port, flags);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 14/15] serial: 8250: allow UART drivers to override rx_trig_bytes handling
From: Andy Shevchenko @ 2026-05-05 9:30 UTC (permalink / raw)
To: Crescent Hsieh
Cc: gregkh, jirislaby, ilpo.jarvinen, fangpingfp.cheng, linux-kernel,
linux-serial
In-Reply-To: <20260504084900.22380-15-crescentcy.hsieh@moxa.com>
On Mon, May 4, 2026 at 11:51 AM Crescent Hsieh
<crescentcy.hsieh@moxa.com> wrote:
>
> The rx_trig_bytes sysfs attribute currently relies on 8250-internal
> helper functions and assumes a fixed mapping between trigger levels and
> FIFO behavior.
>
> Some UARTs provide hardware-specific RX trigger mechanisms that do not
> fit this model. Add optional uart_port callbacks for setting and getting
> the RX trigger level, and use them when provided, while preserving the
> existing 8250 helpers as the default fallback.
...
> struct uart_port {
> void (*pm)(struct uart_port *, unsigned int state,
> unsigned int old);
> void (*handle_break)(struct uart_port *);
> + int (*set_rxtrig)(struct uart_port *port, unsigned char bytes);
> + int (*get_rxtrig)(struct uart_port *port);
Seems to me a suboptimal location for these. Why not moving up to be
closer to other getter/setter pairs?
> int (*rs485_config)(struct uart_port *,
> struct ktermios *termios,
> struct serial_rs485 *rs485);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 15/15] serial: 8250_mxpcie: implement rx_trig_bytes callbacks via MUEx50 RTL
From: Andy Shevchenko @ 2026-05-05 9:34 UTC (permalink / raw)
To: Crescent Hsieh
Cc: gregkh, jirislaby, ilpo.jarvinen, fangpingfp.cheng, linux-kernel,
linux-serial
In-Reply-To: <20260504084900.22380-16-crescentcy.hsieh@moxa.com>
On Mon, May 4, 2026 at 11:51 AM Crescent Hsieh
<crescentcy.hsieh@moxa.com> wrote:
>
> The MUEx50 UART exposes a programmable RX trigger level via the RTL
> register.
>
> Implement uart_port RX trigger set/get callbacks for the mxpcie driver
> and wire them up to the generic rx_trig_bytes sysfs interface. Store the
> configured trigger level in the per-port private data.
...
> struct mxpcie8250_port {
> int line;
> + u8 rx_trig_level;
> unsigned long event_flags;
> struct uart_port *port;
> struct work_struct work;
Whenever you add a member to or modify existing data structure, always
run `pahole` to check if the layout is good enough (or even the best
fit). Same applies to the whole series.
...
> +static int mxpcie8250_set_rxtrig(struct uart_port *port, unsigned char bytes)
> +{
> + struct mxpcie8250 *priv = dev_get_drvdata(port->dev);
> + struct uart_8250_port *up = up_to_u8250p(port);
> +
> + if (bytes > 128)
Magic! Should it be defined or already has been?
> + return -EINVAL;
> +
> + serial_out(up, MOXA_PUART_RTL, bytes);
> + priv->port[port->port_id].rx_trig_level = bytes;
> +
> + return 0;
> +}
...
> +static int mxpcie8250_get_rxtrig(struct uart_port *port)
> +{
> + struct uart_8250_port *up = up_to_u8250p(port);
> +
> + return serial_in(up, MOXA_PUART_RTL);
No need to have an intermediate pointer as you can simply use
serial_port_in(). Same applies to other places when the uart_8250_port
is not used otherwise.
> +}
...
> + priv->port[i].rx_trig_level = 96;
As per above, this magic together with the above should be defined
somehow. And together they make more context to the reader.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v7 5/6] ARM: dts: zte: Add D-Link DWR-932M support
From: Linus Walleij @ 2026-05-05 9:53 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <20260429-send-v7-5-b432e00d2db8@gmail.com>
On Wed, Apr 29, 2026 at 9:14 PM Stefan Dösinger
<stefandoesinger@gmail.com> wrote:
> This adds base DT definition for zx297520v3 and one board that consumes it.
>
> The stock kernel does not use the armv7 timer, but it seems to work
> fine. The board has other board-specific timers that would need a driver
> and I see no reason to bother with them since the arm standard timer
> works.
>
> The caveat is the non-standard GIC setup needed to handle the timer's
> level-low PPI. This is the responsibility of the boot loader and
> documented in Documentation/arch/arm/zte/zx297520v3.rst.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v7 6/6] ARM: zte: defconfig: Add a zx29 defconfig file
From: Linus Walleij @ 2026-05-05 9:54 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <20260429-send-v7-6-b432e00d2db8@gmail.com>
On Wed, Apr 29, 2026 at 9:14 PM Stefan Dösinger
<stefandoesinger@gmail.com> wrote:
> This enables existing drivers for hardware that is present on this board
> even if it is not present in the DT yet.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
I'm in favor of this, mainly because multi_v7 is pretty useless
for this board, it is absolutely too big to boot on the machine,
the board is odd and need some ARM64 stuff.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net-next 2/3] ppp: unify two channel structs
From: Paolo Abeni @ 2026-05-05 11:16 UTC (permalink / raw)
To: Qingfang Deng, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Jiri Kosina, David Sterba, Greg Kroah-Hartman,
Jiri Slaby, Mitchell Blank Jr, Chas Williams, Simon Horman,
James Chapman, Kees Cook, Sebastian Andrzej Siewior, Taegu Ha,
Guillaume Nault, Eric Woudstra, Arnd Bergmann, Dawid Osuchowski,
Breno Leitao, linux-ppp, netdev, linux-kernel, linux-serial,
linux-atm-general
In-Reply-To: <20260430090532.244758-2-qingfang.deng@linux.dev>
On 4/30/26 11:05 AM, Qingfang Deng wrote:
> Historically, PPP maintained two separate structures for a channel:
> 'struct channel' was internal to ppp_generic.c, while 'struct ppp_channel'
> was the public interface that drivers were required to embed. This
> duplication was redundant and forced drivers to manage the lifecycle of
> the public structure.
>
> Unify these two structures into a single 'struct ppp_channel', which is
> now internal to ppp_generic.c. Drivers now use a 'ppp_channel_conf'
> structure to specify registration parameters and receive an opaque
> pointer to the allocated channel.
>
> Key changes:
> - ppp_register_channel() and ppp_register_net_channel() now return
> a 'struct ppp_channel *' instead of taking a pointer to a driver-
> embedded structure.
> - 'struct ppp_channel_ops' methods now take the driver's 'private'
> pointer directly as their first argument, simplifying driver logic.
> - ppp_unregister_channel() now takes the opaque pointer.
> - Multilink-specific fields are unified and handled via the new
> configuration structure.
>
> This cleanup simplifies the driver interface and makes the channel
> lifecycle management more robust by centralizing allocation in the PPP
> generic layer.
>
> Assisted-by: Gemini:gemini-3-flash
> Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
> ---
> drivers/net/ppp/ppp_async.c | 51 +++++-----
> drivers/net/ppp/ppp_generic.c | 161 +++++++++++++++----------------
> drivers/net/ppp/ppp_synctty.c | 51 +++++-----
> drivers/net/ppp/pppoe.c | 34 ++++---
> drivers/net/ppp/pppox.c | 4 +-
> drivers/net/ppp/pptp.c | 40 ++++----
> drivers/tty/ipwireless/network.c | 30 +++---
> include/linux/if_pppox.h | 2 +-
> include/linux/ppp_channel.h | 49 ++++++----
> net/atm/pppoatm.c | 61 ++++++------
> net/l2tp/l2tp_ppp.c | 34 ++++---
> 11 files changed, 271 insertions(+), 246 deletions(-)
This patch is IMHO a bit too big and should be split. Also this kind of
refactor looks very invasive and potentially regression prone. I think
it should include a signficant self-test coverage increase.
> @@ -391,9 +396,9 @@ ppp_async_init(void)
> * The following routines provide the PPP channel interface.
> */
> static int
> -ppp_async_ioctl(struct ppp_channel *chan, unsigned int cmd, unsigned long arg)
> +ppp_async_ioctl(void *private, unsigned int cmd, unsigned long arg)
> {
> - struct asyncppp *ap = chan->private;
> + struct asyncppp *ap = private;
> void __user *argp = (void __user *)arg;
> int __user *p = argp;
> int err, val;
Minor nit: reverse christmas tree above
> @@ -2985,16 +2983,13 @@ char *ppp_dev_name(struct ppp_channel *chan)
> * This must be called in process context.
> */
> void
> -ppp_unregister_channel(struct ppp_channel *chan)
> +ppp_unregister_channel(struct ppp_channel *pch)
> {
> - struct channel *pch = chan->ppp;
> struct ppp_net *pn;
>
> if (!pch)
> return; /* should never happen */
>
> - chan->ppp = NULL;
> -
Sashiko says:
Could this specific ordering introduce a race condition that might lead
to a use-after-free?
If userspace has a file descriptor attached to this channel, it can
concurrently invoke the PPPIOCCONNECT ioctl. Because
ppp_disconnect_channel()
clears pch->ppp and removes the channel from its current unit before
pch->file.dead is set to 1, the concurrent ioctl could observe
pch->file.dead == 0.
This would allow ppp_connect_channel() to successfully attach the dying
channel to a new PPP unit. Once ppp_unregister_channel() completes and
frees the channel, the new PPP unit would retain a pointer to the freed
memory in its channels list, which might be accessed during a later
packet transmission via ppp_push().
> @@ -215,7 +210,8 @@ static void pppoatm_push(struct atm_vcc *atmvcc, struct sk_buff *skb)
> !memcmp(skb->data, &pppllc[LLC_LEN],
> sizeof(pppllc) - LLC_LEN)) {
> pvcc->encaps = e_vc;
> - pvcc->chan.mtu += LLC_LEN;
> + ppp_channel_update_mtu(pvcc->chan,
> + atmvcc->qos.txtp.max_sdu - PPP_HDRLEN);
Does the above introduce a functional change? At very least some comment
needed. Also possibly better move the update_mtu wrapper to a pre-req patch.
> @@ -221,7 +221,7 @@ static void pppol2tp_recv(struct l2tp_session *session, struct sk_buff *skb, int
> struct pppox_sock *po;
>
> po = pppox_sk(sk);
> - ppp_input(&po->chan, skb);
> + ppp_input(po->chan, skb);
Sashiko says:
Does decoupling the channel lifetime from the driver structure introduce
a use-after-free when receiving packets?
Previously, the struct ppp_channel was embedded in struct pppox_sock,
meaning its lifecycle was safely tied to the socket's refcount. Now that
po->chan is dynamically allocated and freed during pppox_unbind_sock()
via ppp_unregister_channel(), it seems possible for pppol2tp_recv() to
access freed memory.
Since pppol2tp_recv() runs locklessly in softirq context while holding
only rcu_read_lock() and a socket reference, can it observe the
PPPOX_BOUND state and dereference po->chan just after it was freed on
another CPU?
/P
^ permalink raw reply
* Re: [PATCH] serial: 8250_dw: Clean up register macros and error handling
From: Artem Shimko @ 2026-05-05 12:15 UTC (permalink / raw)
To: Andy Shevchenko
Cc: sashal, miquel.raynal, phil.edworthy, Ilpo Järvinen,
Greg Kroah-Hartman, Jiri Slaby, linux-kernel, linux-serial
In-Reply-To: <ae8J6uqgOarcduas@ashevche-desk.local>
HI Andy,
On Mon, Apr 27, 2026 at 10:02 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> https://lore.kernel.org/linux-serial/20260424-ultrarisc-serial-v4-0-1765a0b4c4a0@ultrarisc.com/
Yes, now I see...
Thank you for review =)
Regards,
Artem
^ permalink raw reply
* Re: [PATCH 1/3] tty: move remaining serial drivers into the serial/ directory
From: Crescent Hsieh @ 2026-05-06 3:15 UTC (permalink / raw)
To: Jiri Slaby
Cc: Ethan Nelson-Moore, linux-serial, Greg Kroah-Hartman,
Ilpo Järvinen, Andy Shevchenko,
Ray Chen (陳松昱), linux-m68k,
Geert Uytterhoeven
In-Reply-To: <ed6dce34-2207-4403-bbcf-080db2614241@kernel.org>
On Tue, May 05, 2026 at 07:59:29AM +0200, Jiri Slaby wrote:
> On 05. 05. 26, 3:20, Ethan Nelson-Moore wrote:
> > A few TTY drivers are outside the serial/ directory despite being for
> > serial devices.
>
> Yes, but serial/ (historically) contains drivers using serial_core. tty/
> contains drivers using tty_driver (which all of three unfortunately do).
>
> There was a patchset from Crescent Hsieh (Moxa) to convert mxser [1].
Yes, I have been working on converting mxser.c into an 8250-based serial
driver for some time, and it is still in progress.
> I am not sure even about users of Moxa Intellio. I think I prompted long
> time ago. Oh yes, Ray Chen (CCed) from Moxa wrote me back in 2021:
> === 8< ===
> For the Intellio cards, we phased them out in 2017.
> You may find the discontinuance notification as attached.
> We will keep the software support for 5 years, to 2023.
> === 8< ===
>
> I believe we can mark it as BROKEN to let someone convert it to serial_core.
> Or drop it for good already.
As for Moxa Intellio (moxa.c), I have confirmed internally that both the
hardware and software support have already been phased out.
Therefore, it would be reasonable to drop it at this point. I can help
with preparing a removal patch if this is the preferred direction.
---
Sincerely,
Crescent Hsieh
^ permalink raw reply
* [PATCH v1] serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ
From: Viken Dadhaniya @ 2026-05-06 4:45 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Bartosz Golaszewski
Cc: linux-arm-msm, linux-kernel, linux-serial, stable,
Viken Dadhaniya
When uart_flush_buffer() runs before the DMA completion IRQ is delivered,
the following race can occur (all steps serialized by uart_port_lock):
1. DMA starts: tx_remaining = N, kfifo contains N bytes
2. DMA completes in hardware; IRQ is pending but not yet delivered
3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(),
making kfifo_len() = 0 while tx_remaining remains N
4. uart_flush_buffer() releases the port lock
5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls
uart_xmit_advance(uport, tx_remaining) on an empty kfifo
uart_xmit_advance() increments kfifo->out by tx_remaining. Since
kfifo_reset() already set both in and out to 0, out wraps past in,
causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next
start_tx_dma() call then submits a DMA transfer of stale buffer data.
Fix this by snapshotting kfifo_len() at the start of handle_tx_dma()
and skipping uart_xmit_advance() when fifo_len < tx_remaining, which
indicates the kfifo was reset by a preceding flush.
Fixes: 2aaa43c70778 ("tty: serial: qcom-geni-serial: add support for serial engine DMA")
Cc: stable@vger.kernel.org
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
drivers/tty/serial/qcom_geni_serial.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
index b365dd5da3cb..3c1be7b21290 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -1031,8 +1031,20 @@ static void qcom_geni_serial_handle_tx_dma(struct uart_port *uport)
{
struct qcom_geni_serial_port *port = to_dev_port(uport);
struct tty_port *tport = &uport->state->port;
+ unsigned int fifo_len = kfifo_len(&tport->xmit_fifo);
+
+ /*
+ * Only advance the kfifo if it still contains the bytes that were
+ * transferred. uart_flush_buffer() may have run before this IRQ
+ * fired: it calls kfifo_reset() under the port lock, making
+ * fifo_len = 0 while tx_remaining remains non-zero. Calling
+ * uart_xmit_advance() in that case would underflow kfifo->out past
+ * kfifo->in, making kfifo_len() wrap to UART_XMIT_SIZE - tx_remaining
+ * and triggering a spurious large DMA transfer of stale data.
+ */
+ if (fifo_len >= port->tx_remaining)
+ uart_xmit_advance(uport, port->tx_remaining);
- uart_xmit_advance(uport, port->tx_remaining);
geni_se_tx_dma_unprep(&port->se, port->tx_dma_addr, port->tx_remaining);
port->tx_dma_addr = 0;
port->tx_remaining = 0;
---
base-commit: 4cd074ae20bbcc293bbbce9163abe99d68ae6ae0
change-id: 20260506-serial-dma-stale-tx-buf-f53db336a13a
Best regards,
--
Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v1] serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ
From: Bartosz Golaszewski @ 2026-05-06 8:30 UTC (permalink / raw)
To: Viken Dadhaniya
Cc: linux-arm-msm, linux-kernel, linux-serial, stable,
Greg Kroah-Hartman, Jiri Slaby, Bartosz Golaszewski
In-Reply-To: <20260506-serial-dma-stale-tx-buf-v1-1-e3ccb360d719@oss.qualcomm.com>
On Wed, 6 May 2026 06:45:21 +0200, Viken Dadhaniya
<viken.dadhaniya@oss.qualcomm.com> said:
> When uart_flush_buffer() runs before the DMA completion IRQ is delivered,
> the following race can occur (all steps serialized by uart_port_lock):
>
> 1. DMA starts: tx_remaining = N, kfifo contains N bytes
> 2. DMA completes in hardware; IRQ is pending but not yet delivered
> 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(),
> making kfifo_len() = 0 while tx_remaining remains N
> 4. uart_flush_buffer() releases the port lock
> 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls
> uart_xmit_advance(uport, tx_remaining) on an empty kfifo
>
> uart_xmit_advance() increments kfifo->out by tx_remaining. Since
> kfifo_reset() already set both in and out to 0, out wraps past in,
> causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next
> start_tx_dma() call then submits a DMA transfer of stale buffer data.
>
> Fix this by snapshotting kfifo_len() at the start of handle_tx_dma()
> and skipping uart_xmit_advance() when fifo_len < tx_remaining, which
> indicates the kfifo was reset by a preceding flush.
>
> Fixes: 2aaa43c70778 ("tty: serial: qcom-geni-serial: add support for serial engine DMA")
> Cc: stable@vger.kernel.org
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
Make sense, thanks.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH tty v4 0/6] 8250: Add console flow control
From: John Ogness @ 2026-05-06 12:15 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: Andy Shevchenko, linux-kernel, linux-serial, Krzysztof Kozlowski,
Alim Akhtar, David S. Miller, Ilpo Järvinen, Andy Shevchenko,
Thomas Fourier, Kees Cook, linux-arm-kernel, linux-samsung-soc,
sparclinux, Biju Das, Geert Uytterhoeven, Lad Prabhakar,
Thierry Bultel, Osama Abdelkader, Ingo Molnar, Xin Zhao,
Joseph Tilahun, Krzysztof Kozlowski, Lukas Wunner,
Dr. David Alan Gilbert
Hi,
This is v4 of a series to implement console flow control for the
8250 serial driver. v3 is here [0].
The 8250 driver already has code in place to support console flow
control. However, there is no way to activate it and it is
incomplete. This series provides the necessary missing pieces while
attempting to be as conservative as possible, so as not to introduce
any side effects into the many 8250 variants or other non-8250 serial
drivers.
For patch 2 I used the following Coccinelle script to perform the
modifications...
===== BEGIN cons_flow.cocci =====
// SPDX-License-Identifier: GPL-2.0-only
// Options: --all-includes
virtual patch
@r1@
type T1;
identifier U;
@@
T1 {
...
struct uart_port U;
...
};
@r2@
r1.T1 *E;
@@
- (E->port.flags & UPF_CONS_FLOW)
+ uart_cons_flow_enabled(&E->port)
@r3@
struct uart_port *U;
@@
- (U->flags & UPF_CONS_FLOW)
+ uart_cons_flow_enabled(U)
@r4@
struct uart_port *U;
@@
- U->flags |= UPF_CONS_FLOW
+ uart_set_cons_flow_enabled(U, true)
===== END cons_flow.cocci =====
Changes for v4:
- Rename uart_get_cons_flow() to uart_cons_flow_enabled().
- Rename uart_set_cons_flow() to uart_set_cons_flow_enabled().
Changes for v3:
- Deprecate UPF_CONS_FLOW. Provide separate boolean with wrappers as
alternative.
- Update all UPF_CONS_FLOW users to new cons_flow wrappers.
- Use irqsave variant of spin lock for status update.
- When 8250 console flow control is not specified, clear the policy.
Changes for v2:
- Prepend a patch to perform an extra LSR wait after CTS assertion if
the initial LSR wait timed out.
- Close a window in serial8250_register_8250_port() where console
flow control was briefly disabled.
- Add port lock synchronization to the port->status RMW update in
uart_set_options().
John Ogness
[0] https://lore.kernel.org/lkml/20260417102423.40984-1-john.ogness@linutronix.de
John Ogness (6):
serial: core: Add dedicated uart_port field for console flow
serial: Replace driver usage of UPF_CONS_FLOW
serial: sh-sci: Avoid deprecated UPF_CONS_FLOW
serial: 8250: Set cons_flow on port registration
serial: 8250: Check LSR timeout on console flow control
serial: 8250: Add support for console flow control
drivers/tty/serial/8250/8250_core.c | 6 ++++++
drivers/tty/serial/8250/8250_port.c | 21 +++++++++++++++++----
drivers/tty/serial/bcm63xx_uart.c | 2 +-
drivers/tty/serial/omap-serial.c | 2 +-
drivers/tty/serial/pch_uart.c | 2 +-
drivers/tty/serial/pxa.c | 2 +-
drivers/tty/serial/samsung_tty.c | 8 ++++----
drivers/tty/serial/serial_core.c | 21 ++++++++++++++++++++-
drivers/tty/serial/serial_txx9.c | 4 ++--
drivers/tty/serial/sh-sci.c | 5 ++++-
drivers/tty/serial/sunsu.c | 2 +-
include/linux/serial_core.h | 20 ++++++++++++++++++++
12 files changed, 78 insertions(+), 17 deletions(-)
base-commit: a2083fd1fa7aa0ef5cd8fd92396da0de2d0654b0
--
2.47.3
^ permalink raw reply
* [PATCH tty v4 1/6] serial: core: Add dedicated uart_port field for console flow
From: John Ogness @ 2026-05-06 12:15 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: Andy Shevchenko, linux-kernel, linux-serial
In-Reply-To: <20260506121606.5805-1-john.ogness@linutronix.de>
Currently the UPF_CONS_FLOW bit in the uart_port.flags field is used
by serial console drivers to identify if a user has configured flow
control on the console. Usually this policy is setup during early
boot, but can be changed at runtime.
The bits in uart_port.flags are either hardware and driver
properties that are initialized before usage or are properties that
can be changed via the tty layer.
The UPF_CONS_FLOW bit is an exception because it is a console-only
policy that can change at runtime and its setting and usage have
nothing to do with the tty layer. This actually causes a problem
for its usage because uart_port.flags is synchronized by a related
tty_port.mutex, but a console has no relation to a tty (other than
sharing the port).
This is probably why console flow control is not properly available
for most serial drivers. And it is hindering being able to provide a
proper implementation. Commit d01f4d181c92 ("serial: core: Privatize
tty->hw_stopped") addressed a similar issue to deal with software
assisted CTS flow state tracking.
Add a new uart_port boolean field "cons_flow" to store the user
configuration for console flow control. Add getter/setter wrappers
to allow for adding more policies later and/or locking constraint
validation.
Mark UPF_CONS_FLOW as deprecated.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
include/linux/serial_core.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 666430b478997..4f7bbdd900176 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -533,6 +533,7 @@ struct uart_port {
#define UPF_HARD_FLOW ((__force upf_t) (UPF_AUTO_CTS | UPF_AUTO_RTS))
/* Port has hardware-assisted s/w flow control */
#define UPF_SOFT_FLOW ((__force upf_t) BIT_ULL(22))
+/* Deprecated: use uart_set_cons_flow_enabled()/uart_cons_flow_enabled() instead. */
#define UPF_CONS_FLOW ((__force upf_t) BIT_ULL(23))
#define UPF_SHARE_IRQ ((__force upf_t) BIT_ULL(24))
#define UPF_EXAR_EFR ((__force upf_t) BIT_ULL(25))
@@ -567,6 +568,7 @@ struct uart_port {
#define UPSTAT_SYNC_FIFO ((__force upstat_t) (1 << 5))
bool hw_stopped; /* sw-assisted CTS flow state */
+ bool cons_flow; /* user specified console flow control */
unsigned int mctrl; /* current modem ctrl settings */
unsigned int frame_time; /* frame timing in ns */
unsigned int type; /* port type */
@@ -1163,6 +1165,16 @@ static inline bool uart_softcts_mode(struct uart_port *uport)
return ((uport->status & mask) == UPSTAT_CTS_ENABLE);
}
+static inline void uart_set_cons_flow_enabled(struct uart_port *uport, bool enabled)
+{
+ uport->cons_flow = enabled;
+}
+
+static inline bool uart_cons_flow_enabled(const struct uart_port *uport)
+{
+ return uport->cons_flow;
+}
+
/*
* The following are helper functions for the low level drivers.
*/
--
2.47.3
^ permalink raw reply related
* [PATCH tty v4 2/6] serial: Replace driver usage of UPF_CONS_FLOW
From: John Ogness @ 2026-05-06 12:15 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: Andy Shevchenko, linux-kernel, Krzysztof Kozlowski, Alim Akhtar,
David S. Miller, Ilpo Järvinen, Andy Shevchenko,
Thomas Fourier, Kees Cook, linux-serial, linux-arm-kernel,
linux-samsung-soc, sparclinux
In-Reply-To: <20260506121606.5805-1-john.ogness@linutronix.de>
Rather than using the UPF_CONS_FLOW bit of uart_port.flags to track
the user configuration of console flow control, use the newly added
uart_port.cons_flow (via its getter/setter functions).
A coccinelle script was used to perform the search/replace.
Note1: The sh-sci driver is blindly copying platform data configuration
flags to uart_port.flags. Thus UPF_CONS_FLOW could get set for
uart_port.flags. A follow-up commit will address this.
Note2: The samsung_tty driver is using UPF_CONS_FLOW as a platform data
configuration flag. However, the driver explicitly checks for
this configuration flag and thus setting UPF_CONS_FLOW in
uart_port.flags is avoided.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
drivers/tty/serial/8250/8250_port.c | 4 ++--
drivers/tty/serial/bcm63xx_uart.c | 2 +-
drivers/tty/serial/omap-serial.c | 2 +-
drivers/tty/serial/pch_uart.c | 2 +-
drivers/tty/serial/pxa.c | 2 +-
drivers/tty/serial/samsung_tty.c | 8 ++++----
drivers/tty/serial/serial_txx9.c | 4 ++--
drivers/tty/serial/sunsu.c | 2 +-
8 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index af78cc02f38e7..dbed5e5767541 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1988,7 +1988,7 @@ static void wait_for_xmitr(struct uart_8250_port *up, int bits)
wait_for_lsr(up, bits);
/* Wait up to 1s for flow control if necessary */
- if (up->port.flags & UPF_CONS_FLOW) {
+ if (uart_cons_flow_enabled(&up->port)) {
for (tmout = 1000000; tmout; tmout--) {
unsigned int msr = serial_in(up, UART_MSR);
up->msr_saved_flags |= msr & MSR_SAVE_FLAGS;
@@ -3351,7 +3351,7 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s,
* it regardless of the CTS state. Therefore, only use fifo
* if we don't use control flow.
*/
- !(up->port.flags & UPF_CONS_FLOW);
+ !uart_cons_flow_enabled(&up->port);
if (likely(use_fifo))
serial8250_console_fifo_write(up, s, count);
diff --git a/drivers/tty/serial/bcm63xx_uart.c b/drivers/tty/serial/bcm63xx_uart.c
index 51df9d2d8bfc5..544695cb184c3 100644
--- a/drivers/tty/serial/bcm63xx_uart.c
+++ b/drivers/tty/serial/bcm63xx_uart.c
@@ -675,7 +675,7 @@ static void wait_for_xmitr(struct uart_port *port)
}
/* Wait up to 1s for flow control if necessary */
- if (port->flags & UPF_CONS_FLOW) {
+ if (uart_cons_flow_enabled(port)) {
tmout = 1000000;
while (--tmout) {
unsigned int val;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 0b85f47ff19e0..a689d190940cf 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1092,7 +1092,7 @@ static void __maybe_unused wait_for_xmitr(struct uart_omap_port *up)
} while (!uart_lsr_tx_empty(status));
/* Wait up to 1s for flow control if necessary */
- if (up->port.flags & UPF_CONS_FLOW) {
+ if (uart_cons_flow_enabled(&up->port)) {
for (tmout = 1000000; tmout; tmout--) {
unsigned int msr = serial_in(up, UART_MSR);
diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
index 6729d8e83c3c5..2f72cd62e2488 100644
--- a/drivers/tty/serial/pch_uart.c
+++ b/drivers/tty/serial/pch_uart.c
@@ -1444,7 +1444,7 @@ static void wait_for_xmitr(struct eg20t_port *up, int bits)
}
/* Wait up to 1s for flow control if necessary */
- if (up->port.flags & UPF_CONS_FLOW) {
+ if (uart_cons_flow_enabled(&up->port)) {
unsigned int tmout;
for (tmout = 1000000; tmout; tmout--) {
unsigned int msr = ioread8(up->membase + UART_MSR);
diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c
index fea0255067ccd..10fc8990579b5 100644
--- a/drivers/tty/serial/pxa.c
+++ b/drivers/tty/serial/pxa.c
@@ -573,7 +573,7 @@ static void wait_for_xmitr(struct uart_pxa_port *up)
} while (!uart_lsr_tx_empty(status));
/* Wait up to 1s for flow control if necessary */
- if (up->port.flags & UPF_CONS_FLOW) {
+ if (uart_cons_flow_enabled(&up->port)) {
tmout = 1000000;
while (--tmout &&
((serial_in(up, UART_MSR) & UART_MSR_CTS) == 0))
diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index e27806bf2cf3e..2f94fc798cffb 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -319,7 +319,7 @@ static void s3c24xx_serial_stop_tx(struct uart_port *port)
ourport->tx_enabled = 0;
ourport->tx_in_progress = 0;
- if (port->flags & UPF_CONS_FLOW)
+ if (uart_cons_flow_enabled(port))
s3c24xx_serial_rx_enable(port);
ourport->tx_mode = 0;
@@ -493,7 +493,7 @@ static void s3c24xx_serial_start_tx(struct uart_port *port)
struct tty_port *tport = &port->state->port;
if (!ourport->tx_enabled) {
- if (port->flags & UPF_CONS_FLOW)
+ if (uart_cons_flow_enabled(port))
s3c24xx_serial_rx_disable(port);
ourport->tx_enabled = 1;
@@ -781,7 +781,7 @@ static void s3c24xx_serial_rx_drain_fifo(struct s3c24xx_uart_port *ourport)
uerstat = rd_regl(port, S3C2410_UERSTAT);
ch = rd_reg(port, S3C2410_URXH);
- if (port->flags & UPF_CONS_FLOW) {
+ if (uart_cons_flow_enabled(port)) {
bool txe = s3c24xx_serial_txempty_nofifo(port);
if (ourport->rx_enabled) {
@@ -1830,7 +1830,7 @@ static int s3c24xx_serial_init_port(struct s3c24xx_uart_port *ourport,
if (cfg->uart_flags & UPF_CONS_FLOW) {
dev_dbg(port->dev, "enabling flow control\n");
- port->flags |= UPF_CONS_FLOW;
+ uart_set_cons_flow_enabled(port, true);
}
/* sort our the physical and virtual addresses for each UART */
diff --git a/drivers/tty/serial/serial_txx9.c b/drivers/tty/serial/serial_txx9.c
index 436a559234dfe..4ae9a45c8e3a3 100644
--- a/drivers/tty/serial/serial_txx9.c
+++ b/drivers/tty/serial/serial_txx9.c
@@ -422,7 +422,7 @@ static void wait_for_xmitr(struct uart_port *up)
udelay(1);
/* Wait up to 1s for flow control if necessary */
- if (up->flags & UPF_CONS_FLOW) {
+ if (uart_cons_flow_enabled(up)) {
tmout = 1000000;
while (--tmout &&
(sio_in(up, TXX9_SICISR) & TXX9_SICISR_CTSS))
@@ -857,7 +857,7 @@ serial_txx9_console_write(struct console *co, const char *s, unsigned int count)
* Disable flow-control if enabled (and unnecessary)
*/
flcr = sio_in(up, TXX9_SIFLCR);
- if (!(up->flags & UPF_CONS_FLOW) && (flcr & TXX9_SIFLCR_TES))
+ if (!uart_cons_flow_enabled(up) && (flcr & TXX9_SIFLCR_TES))
sio_out(up, TXX9_SIFLCR, flcr & ~TXX9_SIFLCR_TES);
uart_console_write(up, s, count, serial_txx9_console_putchar);
diff --git a/drivers/tty/serial/sunsu.c b/drivers/tty/serial/sunsu.c
index 6505a1930da9a..4ff3e5c41dab9 100644
--- a/drivers/tty/serial/sunsu.c
+++ b/drivers/tty/serial/sunsu.c
@@ -1245,7 +1245,7 @@ static void wait_for_xmitr(struct uart_sunsu_port *up)
} while (!uart_lsr_tx_empty(status));
/* Wait up to 1s for flow control if necessary */
- if (up->port.flags & UPF_CONS_FLOW) {
+ if (uart_cons_flow_enabled(&up->port)) {
tmout = 1000000;
while (--tmout &&
((serial_in(up, UART_MSR) & UART_MSR_CTS) == 0))
--
2.47.3
^ permalink raw reply related
* [PATCH tty v4 3/6] serial: sh-sci: Avoid deprecated UPF_CONS_FLOW
From: John Ogness @ 2026-05-06 12:15 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: Andy Shevchenko, linux-kernel, Biju Das, Geert Uytterhoeven,
Lad Prabhakar, Thierry Bultel, linux-serial
In-Reply-To: <20260506121606.5805-1-john.ogness@linutronix.de>
Avoid setting the uart_port.flags deprecated UPF_CONS_FLOW bit if it
has been configured in the platform data. Use the new cons_flow
wrappers instead.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
drivers/tty/serial/sh-sci.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 6c819b6b24258..a1328a3b6638d 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -3369,9 +3369,12 @@ static int sci_init_single(struct platform_device *dev,
}
port->type = SCI_PUBLIC_PORT_ID(p->type);
- port->flags = UPF_FIXED_PORT | UPF_BOOT_AUTOCONF | p->flags;
+ port->flags = UPF_FIXED_PORT | UPF_BOOT_AUTOCONF |
+ (p->flags & ~UPF_CONS_FLOW);
port->fifosize = sci_port->params->fifosize;
+ uart_set_cons_flow_enabled(port, p->flags & UPF_CONS_FLOW);
+
if (p->type == PORT_SCI && !dev->dev.of_node) {
if (sci_port->reg_size >= 0x20)
port->regshift = 2;
--
2.47.3
^ permalink raw reply related
* [PATCH tty v4 4/6] serial: 8250: Set cons_flow on port registration
From: John Ogness @ 2026-05-06 12:15 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: Andy Shevchenko, linux-kernel, Ilpo Järvinen,
Osama Abdelkader, Kees Cook, Ingo Molnar, linux-serial
In-Reply-To: <20260506121606.5805-1-john.ogness@linutronix.de>
Since console flow control policy is no longer part of uart_port.flags,
explicitly set the policy for the port.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
drivers/tty/serial/8250/8250_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index a428e88938eb7..b0275204e1167 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -746,6 +746,8 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
uart->lsr_save_mask = up->lsr_save_mask;
uart->dma = up->dma;
+ uart_set_cons_flow_enabled(&uart->port, uart_cons_flow_enabled(&up->port));
+
/* Take tx_loadsz from fifosize if it wasn't set separately */
if (uart->port.fifosize && !uart->tx_loadsz)
uart->tx_loadsz = uart->port.fifosize;
--
2.47.3
^ permalink raw reply related
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