linux.git/include/linux/serial_core.h, branch v7.3-rc2

serial: 8250: allow UART drivers to override rx_trig_bytes handling

2026-08-03T14:51:57+00:00

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.

Signed-off-by: Crescent Hsieh 
Link: https://patch.msgid.link/20260731074820.735619-13-crescentcy.hsieh@moxa.com
Signed-off-by: Greg Kroah-Hartman

serial: 8250: allow low-level drivers to override break control

2026-08-03T14:51:57+00:00

Some UARTs require driver-specific handling for break signaling, which
cannot be expressed by the generic 8250 break implementation alone.

Add an optional uart_port break_ctl callback and route
serial8250_break_ctl() through it when provided. Rename the existing
8250 implementation to serial8250_do_break_ctl() and export it so
low-level drivers can reuse the default 8250 behavior when appropriate.

Signed-off-by: Crescent Hsieh 
Link: https://patch.msgid.link/20260731074820.735619-11-crescentcy.hsieh@moxa.com
Signed-off-by: Greg Kroah-Hartman

serial: core: add new I/O type for SPI and I2C bus devices

2026-07-10T12:50:13+00:00

I2C/SPI serial drivers don't use the following struct uart_port variables:
    port->membase
    port->mapbase
    port->iobase

However, they are forced to set membase to a non-zero value so that
uart_configure_port() will succeed because of the following check:

    /* If there isn't a port here, don't do anything further. */
    if (!port->iobase && !port->mapbase && !port->membase)
        return;

Add a new I/O type for SPI and I2C bus devices to remove the need to
implement the kind of above-mentioned ambiguous workarounds to make them
work. Now that UART report functions are using uart_iotype_*() functions,
no more irrelevant I/O information are being printed for UPIO_BUS iotypes.

Signed-off-by: Hugo Villeneuve 
Link: https://patch.msgid.link/20260521-tty-upio-v3-7-bf74567994a0@dimonoff.com
Signed-off-by: Greg Kroah-Hartman

serial: uniformize serial port I/O infos display

2026-07-10T12:50:12+00:00

Uniformize serial port I/O infos display from three different functions
that display mostly the same information, but with some variations, by
adding a common function.

This make use of new functions uart_iotype_mmio() and
uart_iotype_legacy_io() to simplify and improve code readability.
This will prevent displaying irrelevant information for future IO types
(ex: UPIO_BUS), while also addressing the (eventually) invalid check for
"iotype >= UPIO_MEM".

This also allows us to remove the confusing cast to (unsigned long long)
for iobase which is defined as an unsigned long, and use %pa to display the
mapbase pointer, as it is done in earlycon_print_info().

Replace snprintf with more robust scnprintf so we could perhaps one day get
rid of snprintf() entirely.

Signed-off-by: Hugo Villeneuve 
Link: https://patch.msgid.link/20260521-tty-upio-v3-4-bf74567994a0@dimonoff.com
Signed-off-by: Greg Kroah-Hartman

serial: core: add uart_iotype_mmio/io helper functions

2026-07-10T12:50:12+00:00

To help simplify code that check on the io type mode of the port.

Signed-off-by: Hugo Villeneuve 
Link: https://patch.msgid.link/20260521-tty-upio-v3-2-bf74567994a0@dimonoff.com
Signed-off-by: Greg Kroah-Hartman

Merge tag 'v7.1-rc6' into tty-next

2026-06-01T16:08:02+00:00

We need the tty/serial fixes in here as well.

Signed-off-by: Greg Kroah-Hartman

serial: core: introduce guard(uart_port_lock_check_sysrq_irqsave)

2026-05-22T09:51:35+00:00

uart_handle_break() and uart_prepare_sysrq_char() (in
include/linux/serial_core.h) capture a SysRq character into
port->sysrq_ch while the port lock is held and rely on the unlock
helper -- uart_unlock_and_check_sysrq_irqrestore() -- to dispatch the
captured character to handle_sysrq() on scope exit.

The existing guard(uart_port_lock_irqsave) cannot be used by IRQ
handlers that process RX, because its destructor calls plain
uart_port_unlock_irqrestore() and silently drops port->sysrq_ch.

Add a dedicated guard(uart_port_lock_check_sysrq_irqsave) variant
whose destructor is the sysrq-aware unlock helper. The lock side is
identical to uart_port_lock_irqsave -- only the unlock-time behaviour
differs. Callers that may capture SysRq characters must use
guard(uart_port_lock_check_sysrq_irqsave); the existing
guard(uart_port_lock_irqsave) keeps its current plain-unlock semantics
for the many callers that do not process RX.

The new macro is placed after the CONFIG_MAGIC_SYSRQ_SERIAL block so
both definitions of uart_unlock_and_check_sysrq_irqrestore() (sysrq
enabled and disabled) are visible at expansion time. When
CONFIG_MAGIC_SYSRQ_SERIAL=n the destructor degenerates to plain
uart_port_unlock_irqrestore(), so there is no overhead.

No functional change on its own; users are converted in the following
patches.

Cc: stable@vger.kernel.org
Signed-off-by: Jacques Nilo 
Reviewed-by: Ilpo Järvinen 
Link: https://patch.msgid.link/3849af4bc55d5d2a424fa850844e94d641b2f8a6.1778675349.git.jnilo@free.fr
Signed-off-by: Greg Kroah-Hartman

serial: 8250: Add support for console flow control

2026-05-22T09:45:41+00:00

The kernel documentation specifies that the console option 'r' can
be used to enable hardware flow control for console writes. The 8250
driver does include code for hardware flow control on the console if
cons_flow is set, but there is no code path that actually sets this.
However, that is not the only issue. The problems are:

1. Specifying the console option 'r' does not lead to cons_flow being
   set.

2. Even if cons_flow would be set, serial8250_register_8250_port()
   clears it.

3. When the console option 'r' is specified, uart_set_options()
   attempts to initialize the port for CRTSCTS. However, afterwards
   it does not set the UPSTAT_CTS_ENABLE status bit and therefore on
   boot, uart_cts_enabled() is always false. This policy bit is
   important for console drivers as a criteria if they may poll CTS.

4. Even though uart_set_options() attempts to initialize the port
   for CRTSCTS, the 8250 set_termios() callback does not enable the
   RTS signal (TIOCM_RTS) and thus the hardware is not properly
   initialized for CTS polling.

5. Even if modem control was properly setup for CTS polling
   (TIOCM_RTS), uart_configure_port() clears TIOCM_RTS, thus
   breaking CTS polling.

6. wait_for_xmitr() and serial8250_console_write() use cons_flow
   to decide if CTS polling should occur. However, the condition
   should also include a check that it is not in RS485 mode and
   CRTSCTS is actually enabled in the hardware.

Address all these issues as conservatively as possible by gating them
behind checks focussed on the user specifying console hardware flow
control support and the hardware being configured for CTS polling
at the time of the write to the UART.

Since checking the UPSTAT_CTS_ENABLE status bit is a part of the new
condition gate, these changes also support runtime termios updates to
disable/enable CRTSCTS.

Signed-off-by: John Ogness 
Link: https://patch.msgid.link/20260511152706.151498-4-john.ogness@linutronix.de
Signed-off-by: Greg Kroah-Hartman

serial: core: Add dedicated uart_port field for console flow

2026-05-11T14:58:28+00:00

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 
Link: https://patch.msgid.link/20260506121606.5805-2-john.ogness@linutronix.de
Signed-off-by: Greg Kroah-Hartman

serial: introduce uart_port_lock() guard()s

2025-08-17T10:46:25+00:00

Having this, guards like these work:
  guard(uart_port_lock_irq)(&up->port);
or
  scoped_guard(uart_port_lock_irqsave, port) {
    ...
  }

See e.g. "serial: 8250: use guard()s" later in this series.

Signed-off-by: "Jiri Slaby (SUSE)" 
Link: https://lore.kernel.org/r/20250814072456.182853-4-jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman