With the TX trigger set to 8 free spaces, THRI is generated roughly once
per 8 transmitted bytes. At 115200 baud 8N1, this corresponds to
approximately 0.7 ms between TX refill events.
Set the TX trigger to 32 free spaces via TLR[3:0]. This makes each refill
larger and reduces the refill rate by about 4x. At 115200 baud 8N1, the
refill cadence becomes approximately 2.8 ms.
The trade-off is that the time-to-empty after THRI asserts is reduced
from 56 to 32 byte times. The fresh-TXLVL refill loop fills the hardware
TX FIFO strictly below whichever trigger is selected. This patch changes
only the refill frequency and the associated latency trade-off.
With the two TX gap fixes applied in both configurations, changing the
trigger from 8 to 32 free spaces produced the following median values
from repeated top snapshots under the same continuous Modbus RTU load.
Each transaction used an 8-byte RX request and a 255-byte TX response,
so the workload was dominated by TX traffic:
trigger=8 trigger=32
SPI IRQ thread CPU 15% 5%
system CPU 44% 29%
idle CPU 40% 52%
one-minute load 2.02 0.99
The datasets contain 547 snapshots with trigger=8 and 535 snapshots with
trigger=32.
Only TLR[3:0] is changed. TLR[7:4] remains zero so the RX trigger retains
its FCR setting. RX trigger tuning may also be useful, but generic RX/TX
trigger configuration is left for follow-up work.
SC16IS7XX_TX_TRIGGER_LEVEL is used for both the programmed TLR value and
the TXLVL refill-loop threshold, keeping the hardware trigger and the
software refill condition synchronized.
TCR/TLR access requires EFR[4] and MCR[2], which are already enabled by
the TCR setup immediately preceding the TLR write.
Reviewed-by: Joachim Knorr <[email protected]>
Link: https://lore.kernel.org/linux-serial/[email protected]/
Signed-off-by: Paul Mbewe <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
sc16is7xx_handle_tx() reads TXLVL once and sizes the hardware TX FIFO
write from that value. TXLVL reports free space in the hardware TX FIFO.
On this SPI-backed path, hardirq/softirq activity, RT scheduling, and
waiting for synchronous SPI transfers can delay the refill while the UART
continues draining. The TXLVL value can therefore become stale before the
hardware TX FIFO write completes.
One failing ftrace with the default 8-free-space trigger showed:
tx_start txlvl=9 txlvl_read_us=580
tx_pre_write sent=9 pre_write_us=16
tx_segment sent=9 seg_us=364
tx_post_write txlvl_before=9 sent=9 txlvl_after=12 pending_after=29
post_gap_us=12 post_txlvl_us=130
The driver read 9 free spaces and wrote 9 bytes to the hardware TX FIFO,
but the post-write TXLVL read still reported 12 free spaces while 29 bytes
remained queued in the xmit kfifo. Even allowing for the post-write read
window, the hardware TX FIFO had not been filled below the 8-free-space
trigger, so no new threshold crossing was expected.
The captured failing samples had the same pattern: data remained queued
in the xmit kfifo while post-write TXLVL remained above the hardware
trigger. The hardware TX FIFO then drained empty before another refill
was requested, producing an unintended gap on the wire.
Fix this by re-reading TXLVL after each hardware TX FIFO write while data
remains queued in the xmit kfifo. If TXLVL is still at or above the
trigger, top up the hardware TX FIFO again. Stop when the xmit kfifo is
empty or a TXLVL read confirms that hardware TX FIFO free space is
strictly below the trigger.
Stopping when TXLVL was equal to the trigger still allowed TX gaps in the
tested workload. Continuing until TXLVL was strictly below the trigger
eliminated the observed gaps caused by stale-TXLVL under-fill.
Program the hardware TX trigger explicitly through TLR using the same
constant as the refill-loop threshold. This prevents the software refill
condition from diverging from the programmed hardware trigger.
Tested on SC16IS752 over 1 MHz SPI on an i.MX6ULL single-core
PREEMPT_RT system, transmitting RS-485 at 115200 baud 8N1 under
continuous Modbus RTU load.
Fixes: dfeae619d7 ("serial: sc16is7xx")
Cc: [email protected]
Reported-by: Tobias Gannert <[email protected]>
Link: https://lore.kernel.org/linux-serial/[email protected]/
Signed-off-by: Paul Mbewe <[email protected]>
Reviewed-by: David Laight <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
tegra_uart_fifo_reset() applies the Tegra30 workaround for
"cannot clear the Tx FIFO while FIFO mode is enabled"
unconditionally: it leaves FIFO mode, writes the requested FCR
clear bits, and re-enters FIFO mode. Leaving FIFO mode empties
both FIFOs, so an Rx-only reset discards queued Tx data as well.
The break handler in tegra_uart_decode_rx_error() calls it with
UART_FCR_CLEAR_RCVR only. On a half-duplex RS485 board whose Rx
line is pulled low while the transceiver drives the bus, every
transmission raises a spurious break, and all but the first
character of the frame is lost.
Only take the FIFO-mode path when the caller actually asked for
CLEAR_XMIT. Likewise only wait for TEMT in that case: with the Tx
FIFO deliberately left intact, that loop would otherwise spin for
a full frame time in hard IRQ context with the port lock held.
Tested on a Colibri T30 (Tegra30) with Rx DMA:
- Break during transmission: the reset still fires from
tegra_uart_decode_rx_error(), and the complete frame now
reaches the peer. Before this change only the character in
the shift register was sent.
- Internal loopback with a generated break: the Rx FIFO is
correctly cleared by the plain FCR write, and subsequent
receive works with no frame, parity or overrun errors.
Fixes: e9ea096dd2 ("serial: tegra: add serial driver")
Cc: [email protected]
Signed-off-by: Simon Gassner <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
kfifo_out_linear_ptr() returns only one contiguous linear segment of the
xmit kfifo. When transmit data wraps around the end of the kfifo, only
the first segment up to the buffer end is sent. The remaining data at
the start of the kfifo is not sent until the next TX interrupt fires,
resulting in a visible mid-frame TX gap on the wire.
The resulting gap is unintended: data remains queued in the xmit kfifo,
but the hardware TX FIFO drains empty before the remaining segment is
sent. Such gaps can break timing-sensitive serial protocols such as
Modbus RTU.
Modbus RTU requires a message to be transmitted as a continuous stream.
For baud rates above 19200, the Modbus Serial Line guide recommends a
fixed 750 us inter-character timeout. On the tested 115200-baud system,
oscilloscope measurements showed mid-frame gaps exceeding that value.
Receivers using the recommended timeout may therefore discard the
incomplete message.
The incomplete transfer also causes unnecessary TX interrupts: instead
of using all available hardware TX FIFO space in one go, the driver
requires an extra interrupt to send the remaining segment after the
wrap.
After the tty xmit buffer was converted to a kfifo, the driver used
uart_fifo_out() to copy data into a linear staging buffer, allowing a
transfer to span the kfifo wrap-around boundary. Commit 133f4c00b8
("serial: sc16is7xx: fix TX fifo corruption") replaced uart_fifo_out()
with a single kfifo_out_linear_ptr() call to remove the shared TX/RX
buffer. Since kfifo_out_linear_ptr() exposes only one contiguous
segment, that change lost the wrap-around handling.
Fix this by calling kfifo_out_linear_ptr() in a loop, advancing through
all contiguous segments until the available hardware TX FIFO space is
exhausted or the xmit kfifo is empty.
This fixes the kfifo wrap-around gap independently of the stale-TXLVL
refill issue.
Tested on SC16IS752 over SPI driving RS-485 at 115200 baud 8N1 on an
i.MX6ULL-based board. Oscilloscope measurements confirmed mid-frame
breaks at the kfifo wrap-around boundary before the fix; no such breaks
were observed afterward.
Fixes: 133f4c00b8 ("serial: sc16is7xx: fix TX fifo corruption")
Cc: [email protected]
Reported-by: Tobias Gannert <[email protected]>
Reviewed-by: Joachim Knorr <[email protected]>
Link: https://lore.kernel.org/linux-serial/[email protected]/
Signed-off-by: Paul Mbewe <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
max3100_shutdown() stops the polling timer but returns early during
system suspend. If the SPI device is unbound before resume, the serial
core does not call max3100_shutdown() again, so max3100_remove() frees
the port while the timer remains armed. max3100_timeout() may then
access the freed port and re-arm the timer.
Add final timer teardown to max3100_remove() and use
timer_shutdown_sync() to prevent a racing callback from re-arming it.
Also free the IRQ and destroy the workqueue there before freeing the
port. Keep timer_delete_sync() in max3100_shutdown() so that a
subsequent open() can re-arm the timer.
The workqueue is created before request_irq() and destroyed on both
request_irq() failure and normal shutdown. Its presence at remove thus
identifies the IRQ left registered when suspend bypasses shutdown.
Free the IRQ before destroying the workqueue, in both
max3100_shutdown() and max3100_remove(), and cancel the pending work
in between. free_irq() waits for a running interrupt handler to
finish and no new handler can start afterwards, so a racing handler
cannot queue work on a workqueue that is being destroyed; the
force_end_work check in max3100_dowork() only narrows that window, as
a handler delayed between the check and queue_work() could still run
after the teardown has cleared the workqueue pointer. Cancelling the
work also keeps destroy_workqueue() from waiting on a queued work item
in case remove() ever runs while the freezable workqueue is still
frozen, e.g. device removal during the resume window, before
workqueues are thawed.
This issue was found by an in-house static analysis tool.
Fixes: 7831d56b0a ("tty: MAX3100")
Cc: [email protected] # 6.2+
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Commit aee1f94dab ("serial: qcom-geni: remove .pm callback, use
runtime PM in startup/shutdown") moved runtime PM references from the
serial-core PM callback to the port startup and shutdown callbacks.
The serial core used to leave the console port powered after
registration, but after the callback was removed the temporary probe
reference is always released. Console writes are not tied to an open TTY
and can run from contexts which cannot resume the device, so a
runtime-suspended console can stall. This was observed on a Qualcomm
X1E80100 CRD device, as the boot console became flakey across boots.
Acquire a runtime PM reference when the console is set up and release it
through the console exit callback. This keeps the device active only
while the console is registered and balances the reference when the
console is disabled or re-enabled through sysfs.
Fixes: aee1f94dab ("serial: qcom-geni: remove .pm callback, use runtime PM in startup/shutdown")
Assisted-by: LLM
Signed-off-by: Konrad Dybcio <[email protected]>
Reviewed-by: Abel Vesa <[email protected]>
Tested-by: David Heidelberg <[email protected]> # OnePlus 6T (sdm845)
Link: https://patch.msgid.link/20260819-topic-geni_console_poweredoff-v1-1-7f7bb3aad8da@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <[email protected]>
When no_console_suspend is set for the serial console, the system
suspend callback skips pm_runtime_force_suspend() to keep the console
active. The resume callback still unconditionally calls
pm_runtime_force_resume(), which triggers an "Unbalanced
pm_runtime_enable!" warning.
Only force resume when the suspend callback force suspended the device.
Fixes: d0cd9c8d0f ("serial: qcom-geni: add force suspend/resume to system sleep callbacks")
Signed-off-by: Abel Vesa <[email protected]>
Reviewed-by: Praveen Talari <[email protected]>
Tested-by: David Heidelberg <[email protected]> # OnePlus 6T (sdm845)
Link: https://patch.msgid.link/20260828-serial-qcom-geni-fix-unbalanced-rpm-resume-v1-1-af3e5aef17a6@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The qcom_geni_serial_poll_rx_fifo_locked() function is only
used for console support, but defined outside of the #ifdef block:
drivers/tty/serial/qcom_geni_serial.c:918:13: error: 'qcom_geni_serial_poll_rx_fifo_locked' defined but not used [-Werror=unused-function]
918 | static void qcom_geni_serial_poll_rx_fifo_locked(struct uart_port *uport)
Move the function definition to a more appropriate place that
avoids the warning.
Fixes: 8200871327 ("serial: qcom-geni: Keep FIFO RX active during console TX")
Signed-off-by: Arnd Bergmann <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
At baud rates up to 115200, the serial console uses only a 1 kBps keepalive
vote for the GENI_TO_CORE ("qup-core") ICC path. This vote keeps the path
active but does not request a QUP Core 2X clock rate.
When the CPU enters a deeper idle state, the missing Core clock vote can
leave the console RX path unresponsive.
Use the 19.2 MHz Core 2X vote at low baud rates, while retaining the 50 MHz
vote at higher baud rates, so that console RX remains functional after deep
idle transitions.
Fixes: 7cf563b2c8 ("tty: serial: qcom_geni_serial: Add interconnect support")
Cc: [email protected]
Reviewed-by: Konrad Dybcio <[email protected]>
Signed-off-by: Viken Dadhaniya <[email protected]>
Link: https://patch.msgid.link/20260915-correct-icc-bandwidth-vote-constants-v2-2-f78eb611204e@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <[email protected]>
brcmuart_handle_irq() starts priv->hrt to work around a receive-timeout
quirk of the 8250 core when hardware flow control is enabled; the timer
callback brcmuart_hrtimer_func() dereferences priv.
brcmuart_remove() cancels the hrtimer before it unregisters the port, so
a receive-timeout interrupt that arrives in between re-arms the timer.
After devm frees priv, the callback runs on freed memory.
Unregister the port before cancelling the hrtimer.
serial8250_unregister_port() shuts the port down and frees its IRQ, so
brcmuart_handle_irq() can no longer restart the timer, and the final
hrtimer_cancel() drains any timer that was armed before or during the
unregister.
This issue was found by an in-house static analysis tool.
Fixes: 41a469482d ("serial: 8250: Add new 8250-core based Broadcom STB driver")
Cc: [email protected]
Assisted-by: Codex:gpt-5.6
Co-developed-by: Song Li <[email protected]>
Signed-off-by: Song Li <[email protected]>
Signed-off-by: Fan Wu <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
of_clk_get() returns a clock with a reference that has to be released
with clk_put(). If clk_prepare_enable() fails the function returns
without doing so, leaking the reference.
Add the missing clk_put() on that error path.
Fixes: 12faa35ae5 ("serial: vt8500: UART uses gated clock rather than 24Mhz reference")
Cc: [email protected]
Signed-off-by: Wentao Liang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
tty_find_polling_driver() returns the tty driver with an extra
reference taken by tty_driver_kref_get(). configure_kgdboc() stores it
in kgdb_tty_driver but the reference is never dropped: it is leaked when
kgdb_register_io_module() fails, when the configuration is cleared, and
on every reconfigure.
Release the reference both when unconfiguring and on the error path.
Fixes: 7d7b93c145 ("tty: kref the tty driver object")
Cc: [email protected]
Signed-off-by: Wentao Liang <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
of_clk_get() returns a clock with a reference that has to be released
with clk_put(). ma35d1serial_probe() never does that, so the reference
is leaked on the probe error paths and also when the port is removed.
Release it on the error paths and in ma35d1serial_remove().
Fixes: 930cbf92db ("tty: serial: Add Nuvoton ma35d1 serial driver support")
Cc: [email protected]
Signed-off-by: Wentao Liang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
port->port_dev is NULL when no port device is installed: it is cleared
on teardown, and never set if registration failed before
serial_core_port_device_add(). serial_core_unregister_port() passes it
straight to serial_core_get_ctrl_dev(), which dereferences it:
KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047]
RIP: serial_core_unregister_port
Call Trace:
serial8250_unregister_port
serial8250_remove
unbind_store
Return early when there is no port device, and read port->port_dev
under port_mutex.
Also clear port->port_dev on the serial_core_register_port() error
path, where the port device has already been removed.
Fixes: 84a9582fd2 ("serial: core: Start managing serial controllers to enable runtime PM")
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=9f57c1b2792029198fcf
Cc: [email protected]
Assisted-by: Claude:claude-opus-5
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Ruslan Valiyev <[email protected]>
Link: https://syzkaller.appspot.com/bug?extid=9f57c1b2792029198fcf
Link: https://lore.kernel.org/all/[email protected]/
Reviewed-by: Tony Lindgren <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The wake irq was cleared in shutdown(), which runs during the suspend
sequence, making it impossible to wake the system via UART.
Move wake irq setup to probe() and teardown to remove() so the irq
remains armed during suspend when the UART is a wakeup source.
Cc: [email protected]
Fixes: 61929cf016 ("tty: serial: Add 8250-core based omap driver")
Signed-off-by: Kendall Willis <[email protected]>
Reviewed-by: Tony Lindgren <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The tty ioctls can race with hangup and end up calling into a tty
driver for a device that is already gone or powered down.
Add the missing checks to make sure the port has not been hung up before
accessing the hardware to avoid issues like kernel panic due to
unclocked accesses.
Note that TIOCGSERIAL, TIOCGICOUNT do not access hardware and are
therefore not affected by the race.
Also note that the initialised check in uart_set_ldisc() added by commit
2f70e49ed8 ("serial_core: Check for port state when tty is in error
state") should have been done under the port lock to avoid racing with
uart_do_autoconfig().
Fixes: 04f378b198 ("tty: BKL pushdown")
Cc: [email protected] # 2.6.26
Signed-off-by: Johan Hovold <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Mixing scope-based and regular cleanup is discouraged and
uart_port_deref() used by uart_wait_modem_status() falls in the latter
category.
Revert the guard conversion in preparation for fixing a hangup race.
Fixes: 56609c0500 ("serial: serial_core: use guard()s")
Cc: [email protected] # 6.18
Cc: Jiri Slaby (SUSE) <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Change console_msr_work (defers MSR handling) to be IRQ_WORK_LAZY,
thus not raising an IRQ upon irq_work queueing. The irq_work is then
handled on the next kernel tick. This additional delay is acceptable
because any pending MSR handling is also performed in the interrupt
handler, if mctrl is queried, and during console resume. Using
IRQ_WORK_LAZY has the benefit of not needing to raise an IRQ for
each line of atomic console printing when modem control is active.
On a side note, the Tegra20 and Tegra30 platforms can hang if an
irq_work IRQ is raised while entering cpuidle states. This problem
was reproducible by performing atomic printing while entering cpuidle.
So this change also provides a workaround for these platforms (as
long as they are not running tickless). The discussion on this topic
is linked below.
Link: https://lore.kernel.org/lkml/[email protected]
Fixes: d353934702 ("serial: 8250: Switch to nbcon console, take 2")
Signed-off-by: John Ogness <[email protected]>
Reviewed-by: Petr Mladek <[email protected]>
Tested-by: Jon Hunter <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Pull TTY / serial driver updates from Greg KH:
"Here is the "big" set of tty and serial driver updates for 7.3-rc1.
Not really all that much happened this development cycle for this
subsystem, changes in here are:
- removal of the ipwireless driver as it's no longer used or needed
- new 8250_mxpcie driver added
- qcom serial driver updates and additions
- vt mode validation addition
- lots of other small serial driver updates and additions
All of these have been in linux-next for weeks with no reported issues"
* tag 'tty-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (97 commits)
serial: imx: serialize imx_uart_ports[] lifetime
tty: clear cdev pointer after cdev_add() failure
tty: skip cdev_del() when no cdev is registered
serial: core: clear freed pointers on uart_register_driver() failure
serial: core: do fallible allocations before the console can be registered
serial: 8250_mxpcie: implement rx_trig_bytes callbacks via MUEx50 RTL
serial: 8250_mxpcie: introduce per-port private data structure
serial: 8250: allow UART drivers to override rx_trig_bytes handling
serial: 8250_mxpcie: add break support for RS485 using MUEx50 features
serial: 8250: allow low-level drivers to override break control
serial: 8250_mxpcie: support serial interface mode switching
serial: 8250_mxpcie: speed up TX using memory-mapped FIFO window
serial: 8250_mxpcie: speed up RX using memory-mapped FIFO window
serial: 8250_mxpcie: add custom handle_irq callback
serial: 8250_mxpcie: offload XON/XOFF flow control to MUEx50 hardware
serial: 8250_mxpcie: enable automatic RTS/CTS flow control
serial: 8250_mxpcie: enable enhanced mode and program FIFO trigger levels
serial: 8250: add Moxa MUEx50 UART port type
serial: 8250: split Moxa PCIe serial board support out of 8250_pci
serial: qcom-geni: Use geni_se_set_perf_level() for baud rate perf level
...
imx_uart_probe() publishes its devm-allocated port in imx_uart_ports[]
before uart_add_one_port() because console setup uses the table. The entry
is not cleared when adding the port fails or after removal, leaving a
dangling pointer.
A sibling probe can register the shared console through that stale entry.
This was reproduced under KASAN on QEMU mcimx6ul-evk by unbinding a
sibling UART, unbinding the console UART and rebinding the sibling.
Keep the entry valid through uart_remove_one_port(), then clear it. Protect
port addition and removal together with their table updates so sibling
operations cannot interleave. Reject an occupied slot rather than
clobbering an active port during a duplicate-line probe.
Fixes: dbff4e9ea2 ("IMX UART: remove statically initialized tables")
Fixes: 9f322ad064 ("imx: serial: handle initialisation failure correctly")
Reported-by: Sashiko <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Link: https://lore.kernel.org/all/[email protected]
Cc: [email protected]
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <[email protected]>
Reviewed-by: Frank Li <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
uart_register_driver() leaves drv->state pointing to freed memory when
tty_alloc_driver() fails. If tty_register_driver() fails, drv->tty_driver
also retains a pointer after its reference is dropped.
Drivers that use drv->state as an "already registered" flag can then skip
registration on the next probe and pass the freed state to
uart_add_one_port().
This issue was found with failslab on QEMU's raspi1ap board by
failing registration and binding the PL011 port again.
Clear both pointers on their failure paths, as uart_unregister_driver()
already does.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Fixes: 9e845abfc8 ("serial: fix NULL pointer dereference")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
serial_core_add_one_port() allocates uport->tty_groups after
uart_configure_port(), which may register the console. If the allocation
fails, the driver unwinds the port while its console remains registered.
The earlier uport->name allocation has a related failure path that leaves
state->uart_port linked to a port being freed.
Failslab reproduced a NULL dereference in PL011 console output and a KASAN
use-after-free in i.MX console output after failed binds.
Allocate the name and tty_groups before linking the port and configuring
it. Reserve space for the optional driver attribute group because
config_port() may populate uport->attr_group during configuration.
Fixes: 266dcff03e ("Serial: allow port drivers to have a default attribute group")
Fixes: f7048b1590 ("tty: serial_core: Add name field to uart_port struct")
Reported-by: Sashiko <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
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.
Signed-off-by: Crescent Hsieh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Introduce a private per-port data structure for the mxpcie driver and
replace the shared flexible array of registered lines with an array of
per-port objects.
This prepares the driver for storing per-port state needed by subsequent
features.
No functional change intended.
Signed-off-by: Crescent Hsieh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
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 <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
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.
Signed-off-by: Crescent Hsieh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
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 <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Moxa PCIe multiport serial boards support switching the serial interface
mode between RS232, RS422, RS485-2W, and RS485-4W via on-board control
registers.
Implement an rs485_config() callback and map TIOCSRS485 requests to the
corresponding hardware modes using serial_rs485 flags:
- RS232 = (no flags set)
- RS422 = SER_RS485_ENABLED | SER_RS485_MODE_RS422
- RS485_2W (half-duplex) = SER_RS485_ENABLED
- RS485_4W (full-duplex) = SER_RS485_ENABLED | SER_RS485_RX_DURING_TX
This allows users to reconfigure the serial mode at runtime via ioctl().
Signed-off-by: Crescent Hsieh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The MUEx50 UART provides a memory-mapped TX FIFO data window along with
a TX FIFO level counter.
Fill the TX FIFO in bulk via the MMIO FIFO window based on available
FIFO space, using uart_port_tx_limited() for the common serial-core TX
handling.
Signed-off-by: Crescent Hsieh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The MUEx50 UART provides a memory-mapped RX FIFO data window along with
an RX FIFO byte counter.
When no break or error conditions are present, read received data in
bulk via the MMIO FIFO window and push it to the tty layer in one
operation. Fall back to the generic 8250 RX path for break and error
handling.
Signed-off-by: Crescent Hsieh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Add a mxpcie-specific handle_irq() implementation for Moxa PCIe serial
ports.
This keeps the interrupt handling self-contained in the driver and
provides a hook point for MUEx50-specific RX/TX paths added in subsequent
patches. The handler processes RX, updates modem status, and handles TX
when THRE is asserted.
Signed-off-by: Crescent Hsieh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The MUEx50 UART can handle in-band software flow control (XON/XOFF)
directly in hardware.
Program the on-chip XON/XOFF characters from termios settings and enable
the corresponding MUEx50 flow control modes when IXON or IXOFF is
requested. Provide throttle and unthrottle callbacks so RX can be
stopped and resumed cleanly.
Signed-off-by: Crescent Hsieh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The MUEx50 UART supports automatic RTS/CTS flow control via the enhanced
feature register.
Implement a mxpcie-specific set_termios() callback that enables MUEx50
auto-RTS/auto-CTS when CRTSCTS is requested and disables it otherwise.
Keep the 8250 port status flags in sync with the hardware configuration.
Signed-off-by: Crescent Hsieh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The MUEx50 UART provides an enhanced register set and programmable FIFO
trigger levels for RX, TX, and flow control.
Enable enhanced mode during port startup and program the MUEx50 FIFO
trigger registers according to the configured port settings. Clear the
programmed state again during shutdown to restore the default UART
configuration.
The TX FIFO write pointer and read pointer are driven by different
clocks. Clear the FIFOs repeatedly during startup so both pointers are
reset before programming the trigger levels.
Signed-off-by: Crescent Hsieh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Add a new 8250 port type for the Moxa MUEx50 UART and describe its basic
FIFO size and trigger characteristics in the 8250 port configuration
table.
The 8250_mxpcie driver sets UPF_FIXED_TYPE and uses PORT_MUEX50 so that
the generic 8250 core applies the correct defaults.
Signed-off-by: Crescent Hsieh <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The driver implements its own helper to select the performance level
corresponding to a requested baud rate. The helper duplicates
functionality already provided by geni_se_set_perf_level() in the GENI
core.
Replace the local implementation with the common helper and remove the
associated duplicate definitions and code. This consolidates
performance-level management in the GENI framework and reduces driver
specific code.
Signed-off-by: Praveen Talari <[email protected]>
Link: https://patch.msgid.link/20260801-reuse_common_geni_framework_helpers-v2-3-13753256ef71@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <[email protected]>
To manage GENI serial engine resources during runtime power
management, drivers currently need to call functions for ICC, clock,
and SE resource operations in both suspend and resume paths, resulting
in code duplication across drivers.
The new geni_se_resources_activate() and geni_se_resources_deactivate()
helper APIs addresses this issue by providing a streamlined method to
enable or disable all resources based, thereby eliminating redundancy
across drivers.
Signed-off-by: Praveen Talari <[email protected]>
Link: https://patch.msgid.link/20260801-reuse_common_geni_framework_helpers-v2-2-13753256ef71@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The UART driver maintains local helpers for resource and power-domain
initialisation that duplicate functionality already provided by the common
GENI framework.
Replace the driver-specific implementations with geni_se_resources_init()
and geni_se_domain_attach(), and use the power-domain list stored in
struct geni_se. This reduces code duplication and centralises GENI resource
management without functional changes.
Signed-off-by: Praveen Talari <[email protected]>
Link: https://patch.msgid.link/20260801-reuse_common_geni_framework_helpers-v2-1-13753256ef71@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <[email protected]>
pl011_console_write_atomic() runs from nbcon atomic context, where
sleeping is not allowed. It calls clk_enable(), which takes the common-clk
enable_lock. Under PREEMPT_RT that is a sleeping lock:
clk_enable_lock() first tries spin_trylock_irqsave(), but on contention
falls back to spin_lock_irqsave(). Therefore, an atomic-context printk on
an RT kernel with a clk-backed pl011 can trip:
BUG: sleeping function called from invalid context at spinlock_rt.c:48
__might_resched from rt_spin_lock
rt_spin_lock from clk_enable_lock
clk_enable_lock from clk_enable
clk_enable from pl011_console_write_atomic
... from vprintk_emit
This was found and reproduced on PREEMPT_RT. Arm32 and arm64 DT SoCs are
affected; arm64 SBSA/ACPI has no clk, so clk_enable(NULL) short-circuits
before the lock. In addition, write_atomic() may be invoked from NMI
context and is documented to avoid locking. Removing clk_enable() from
the callback also avoids a potentially unsafe NMI acquisition of the
common-clock enable_lock.
An nbcon atomic-capable console must be printable from any context, so
the clock cannot be gated between writes. Enable the clock while the
console is available for output: use clk_prepare_enable() in
pl011_console_setup(), release it via clk_disable_unprepare() in the
console .exit() callback, and drop the per-write clk_enable()/clk_disable()
pairs from write_atomic() and write_thread().
When printk suspends consoles, drop the reference after
uart_suspend_port() stops console access and restore it before
uart_resume_port() -- but only if suspend actually marked the port
suspended (a wake-capable tty stays running and must keep its clock), and
keep it when console_suspend_enabled is false so no_console_suspend works.
The active power cost of keeping the clock enabled is platform-dependent:
none where the UART clock is a fixed always-on oscillator, real where it
is a gateable clock branch, which then cannot be gated (nor possibly can
its parent clocks) while the console is available for output. When serial
core actually suspends the port, the reference is released so the clock
provider can gate the clock tree.
Fixes: 2eb2608618 ("serial: amba-pl011: Implement nbcon console")
Suggested-by: John Ogness <[email protected]>
Link: https://lore.kernel.org/all/[email protected]/
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
pl011_console_setup() calls clk_prepare() on the UART clock, but the
console provides no matching teardown, so the clock is never unprepared
when the console is unregistered -- via the sysfs "console" attribute or
a driver unbind. Each re-registration prepares the clock again, leaking
one prepare reference per cycle.
Even where preparing the clock has no hardware effect, the stale
reference leaves the clock framework's prepare count unbalanced. For
providers with prepare/unprepare operations or runtime-PM integration,
it may also retain resources after the console is unregistered.
Add a console .exit() callback that clk_unprepare()s the clock,
balancing the clk_prepare() in pl011_console_setup().
Fixes: 4b4851c65d ("clk: amba-pl011: convert to clk_prepare()/clk_unprepare()")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The Genio board DTs provide serial aliases for all enabled UARTs, but
the MTK 8250 driver still registered every port with the default line
number. If uart0 deferred and another UART probed first, the 8250 core
could still assign ttyS0 to the wrong port despite the DT aliases.
Read the serial alias during OF probe and seed uart.port.line before
registering the port so the 8250 core reserves the requested ttyS slot.
Signed-off-by: Carlo Caione <[email protected]>
Reviewed-by: Chen-Yu Tsai <[email protected]>
Link: https://patch.msgid.link/20260727-ccaione-genio-serial-aliases-v2-2-0f2ae41a8e89@baylibre.com
Signed-off-by: Greg Kroah-Hartman <[email protected]>
dmaengine_terminate_all() does not wait for a running callback, so the TX
callback can still touch the TX buffer after it is freed. The RX poll
timer reads the RX buffers without the port lock.
Switch to dmaengine_terminate_sync() and delete the RX timer before
freeing the buffers.
Fixes: ead76f329f ("ARM: 6763/1: pl011: add optional RX DMA to PL011 v2")
Cc: stable <[email protected]>
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The RS485 trigger hrtimers are embedded in the devm-managed port and can
fire after it is freed. The IRQ handler can arm a timer, so free the IRQ
first and then cancel both timers.
Complete the RS485 stop without arming a timer, and cancel the timers
in remove() for the suspend-then-unbind path, where shutdown is not
called.
This issue was found by an in-house static analysis tool.
Fixes: 2c1fd53af2 ("serial: amba-pl011: Fix RTS handling in RS485 mode")
Cc: stable <[email protected]>
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The RS485 stop hrtimer is used both to drain the transmitter and to wait
out delay_rts_after_send. The callback cannot tell the two apart, so it
restarts the post-send delay on every expiry and the timer never stops.
Add a WAIT_AFTER_SEND_DELAY state so its expiry ends the stop sequence
instead of restarting the delay.
Fixes: 2c1fd53af2 ("serial: amba-pl011: Fix RTS handling in RS485 mode")
Cc: stable <[email protected]>
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The NXP LPC32xx UART (PORT_LPC3220) can latch an RX character-timeout
interrupt while the RX FIFO is empty: IIR reports UART_IIR_RX_TIMEOUT
(0x0c) but LSR.DR is clear. A character timeout is only cleared by
reading RHR, but serial8250_rx_chars() reads RHR only when LSR.DR is
set, so nothing ever clears the condition. The interrupt is
level-triggered and re-fires immediately, so on a single-core ARM926
the resulting interrupt storm livelocks the CPU.
It is reproducible when userspace repeatedly opens the front-panel port
(ttyS1): serial8250_do_set_termios() re-enables interrupts on unlock and
the handler then spins forever with iir=0xcc lsr=0x60 ier=0x05, tripping
the soft-lockup detector in serial8250_handle_irq_locked().
LPC32xx has no dedicated 8250 glue driver, it's driven by the generic
8250_of. Add a hardware specific handle_irq for PORT_LPC3220, wired up
in of_platform_serial_setup() the same way fsl8250_handle_irq is
installed. The handler follows dw8250_handle_irq(): on an RX timeout
with an empty FIFO (LSR.DR and LSR.BI clear) it does one throwaway RHR
read to clear the condition, then calls serial8250_handle_irq_locked().
No real received data is ever discarded, and it is a no-op on healthy
UARTs which never report a timeout with DR clear.
This is the same class of bug already worked around in other 8250 drivers;
see commit 424d79183a ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt")
which reports the identical iir=0xcc/lsr=0x60. See also
UART_RX_TIMEOUT_QUIRK in 8250_omap, and the note in 8250_bcm7271.
Cc: stable <[email protected]>
Assisted-by: Claude:Opus4.8
Signed-off-by: Ryan Wilbur <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
The GENI main sequencer handles console TX while the secondary sequencer
handles FIFO RX. Before nbcon, the legacy console writer disabled both
interrupt domains while it performed a long polled M-side transfer. This
left the small S-side FIFO unserviced, allowing console input to overrun
and be lost.
The nbcon conversion replaces IRQ masking with the UART port lock, but a
threaded console write still prevents the RX handler from draining the
FIFO. Keep S-side RX enabled independently of M-side TX and drain it
while refilling each bounded console command. This preserves interactive
input during console output.
Atomic output masks only M-side TX state, leaving FIFO RX handling
independent. The threaded writer can also detect a SysRq character while
it drains RX, so defer delivery until device_unlock() drops the UART port
lock, as the existing IRQ path does with uart_unlock_and_check_sysrq().
Assisted-by: OpenCode:GPT-5.5
Signed-off-by: Bjorn Andersson <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Paul Mbewe