All consoles implement the new con_blank plus con_unblank. Remove
the old semantics from con_blank. Always pass a VESA blank mode to
the blank parameter.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Add struct consw.con_unblank as inverse operation to con_blank.
If implemented invoke con_blank to turn the console from blanked to
unblanked. Also update the semantics of con_blank in this case: The
blank parameter of con_blank receives a VESA blank mode from enum
vesa_blank_mode instead of the hybrid unblank/blank values it has
used so far.
With con_unblank not implemented, invoke con_blank for blanking and
unblanking as before.
The old semantics of con_blank will be removed when all consoles
implement con_unblank.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Fixes:
- core: initialize modelist in framebuffer_alloc()
- core: bitblit: fix glyph clipping when fbcon pans
- fbcon: restore font geometry if font rotation fails
- sh_mobile_lcdcfb: restore the per-overlay sysfs attributes
- udlfb: don't rebuild the mode list while the framebuffer is in use
- atmel_lcdfb: prevent FIFO work after removal
Cleanups:
- vt, fbcon, vgacon: cursor code rework & cleanups
- MAINTAINERS: name the deller/linux-fbdev for-next branch
- drop unused FB_IOMEM_HELPERS_DEFERRED Kconfig option
- acornfb: remove unused code
- atafb: fix sparse warnings and avoid casts
- sstfb: use managed PCI device enable
- gxt4500, kyro, nvidia: release write-combining handle on probe failure
- various drivers: typo fixes in comments
- various drivers: fix error path on fb_deferred_io_init() failure
- various drivers: use FB blanking constants instead of VESA constants
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCatp6agAKCRD3ErUQojoP
XxeEAQCwaTwk3BQIuOi+UAGANLrLKTPkgEoTluPAhgfBYRoObgD/QJPzhRMFts1h
Lxyrap4AJqTy3webD3PhYCqN8m2sYAE=
=qS61
-----END PGP SIGNATURE-----
Merge tag 'fbdev-for-7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev
Pull fbdev updates from Helge Deller:
"A whole lot of small fixes all over many drivers, but the majority of
changes are related to code cleanups regarding the cursor handling in
vt and fbcon.
Fixes:
- core: initialize modelist in framebuffer_alloc()
- core: bitblit: fix glyph clipping when fbcon pans
- fbcon: restore font geometry if font rotation fails
- sh_mobile_lcdcfb: restore the per-overlay sysfs attributes
- udlfb: don't rebuild the mode list while the framebuffer is in use
- atmel_lcdfb: prevent FIFO work after removal
Cleanups:
- vt, fbcon, vgacon: cursor code rework & cleanups
- MAINTAINERS: name the deller/linux-fbdev for-next branch
- drop unused FB_IOMEM_HELPERS_DEFERRED Kconfig option
- acornfb: remove unused code
- atafb: fix sparse warnings and avoid casts
- sstfb: use managed PCI device enable
- gxt4500, kyro, nvidia: release write-combining handle on probe failure
- various drivers: typo fixes in comments
- various drivers: fix error path on fb_deferred_io_init() failure
- various drivers: use FB blanking constants instead of VESA constants"
* tag 'fbdev-for-7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev: (53 commits)
fbdev: xilinxfb: Use FB blanking constants
fbdev: platinumfb: Use FB blanking constants
fbdev: sa1100fb: Remove comment on VESA DPMS modes
fbdev: i810fb: Use FB blanking constants
fbdev: au1100fb: Use FB blanking constants
fbcon: Retry rotated font allocation after failure
fbcon: Rebuild rotated font buffer on font change
fbcon: Include font geometry in the rotated font cache
fbdev: bitblit: Fix glyph clipping when fbcon pans
fbcon: Replace fbcon_fill_cursor_mask() with fbcon_cursor_glyph()
lib/fonts: Add font_glyph_cursor() helper
vgacon: Use vt_cursor_{start,end}()
vgacon: Remove trailing whitespaces
vt: Add cursor-size helpers
MAINTAINERS: name the deller/linux-fbdev for-next branch
fbdev: atafb: avoid cast when assigning buffer address pointer
fbdev: atafb: fix sparse warnings
fbdev: atyfb_base: fix typos in comments
fbdev: aty128fb: fix typos in comments
fbdev: mach64: fix typos in comments
...
Here is the "big" set of tty and serial driver updates for 7.4-rc1.
It's not really all that big, it's been kind of quiet in this area of
the tree this development cycle in relation to other parts of the tree.
But still, included in here are:
- 8250 port updates and fixes
- 8250 driver cleanups by Jiri
- deletion of the obsolete moxa driver (making this pull request
remove more lines than added!)
- different serial driver updates for dma and other reported issues
All of these have been in linux-next with no reported problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCatoTUg8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+yn+lQCgjA22FwJl7j2xM1aY8Vu80rsr5GwAoIJCzJRD
k1Y6LzXAZ/kqfJ3YT7w5
=w/aw
-----END PGP SIGNATURE-----
Merge tag 'tty-7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty / serial driver updates from Greg KH:
"Here is the "big" set of tty and serial driver updates for 7.4-rc1.
It's not really all that big, it's been kind of quiet in this area of
the tree this development cycle in relation to other parts of the
tree. But still, included in here are:
- 8250 port updates and fixes
- 8250 driver cleanups by Jiri
- deletion of the obsolete moxa driver (making this pull request
remove more lines than added!)
- different serial driver updates for dma and other reported issues
All of these have been in linux-next with no reported problems"
* tag 'tty-7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (91 commits)
tty: hvc: dcc: Detect JTAG connection only on CPU core 0
serial: earlycon: Use isdigit() in earlycon_init()
serial: core: Use isdigit() in uart_parse_options()
dt-bindings: serial: snps-dw-apb-uart: Add Synaptics sl2610 uart
serial: amba-pl011: drive the bus during break in RS485 mode
serial: mcf: update author email address
serial: pmac_zilog: report received breaks
serial: pmac_zilog: push received data to the port that received it
serial: amba-pl011: keep transmitter enabled when disabling RS485
serial: ma35d1: Do not force-enable an unselected console
serial: amba-pl011: honour delay_rts_before_send for every write
Revert "serial: 8250_port: Drop duplicate NULL check"
serial: 8250: make port operations work on struct uart_8250_port
serial: 8250_omap: set priv->line before enabling the IRQ
serial: 8250_lpss: do not touch uninitialized line in ehl_serial_exit()
serial: 8250_exar: store the GPIO platform device in struct exar8250
serial: 8250_exar: remove useless void * casts
serial: 8250: drop err label from serial8250_register_8250_port()
serial: core: fix TIOCSSERIAL and TIOCSERCONFIG on uninitialised ports
serial: max310x: don't transmit while an RS485 reconfigure is pending
...
- Ignore local labels and mapping symbols during module load
These symbols were already ignored during kallsyms address-to-symbol
lookups. Filter them out earlier during module loading to reduce lookup
overhead and prevent them from appearing in /proc/kallsyms.
- Fix potentially incorrect access of SetOnce<T> when setting Rust module
parameters.
- Fix a potential read of an uninitialized count when printing taint
information for unloaded modules.
- Allocate the kmod argument array using kmalloc_array() in preparation
for conversion to type-aware allocators.
- Clean up includes in linux/kmod.h
Add explicit includes of linux/umh.h to files that use usermode helpers.
Then clean up the #include list in linux/kmod.h, notably removing the
compatibility linux/umh.h include.
- Remove the error-injection.h include from linux/module.h
Add explicit includes of linux/error-injection.h to files that use the
ALLOW_ERROR_INJECTION() macro and currently rely on it being provided
indirectly via linux/module.h. Then remove the unnecessary
linux/error-injection.h include from linux/module.h.
- Replace __MODULE_STRING() with __stringify() in various drivers in
preparation for removing the former macro.
The changes to several #include lists have been reported to cause trivial
conflicts in linux-next with the drm, drm-xe, and usb trees.
-----BEGIN PGP SIGNATURE-----
iQFkBAABCABOFiEEIduBR9MnFA82q/jtumpXJwqY6poFAmrWJvAbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyFBxwZXRyLnBhdmx1QHN1c2UuY29tAAoJELpqVycK
mOqalOYH/RpwszqX+OuRhf3G9IDokSZFZyiAJLZan3H7jZNb9VBVLYmTTRYF/UE4
uXKeGAUXZOaUdhVjQi/1LqX3NbDO1NfUCM9sbk3EPal0L6ILbcmkBecXu9JXHxvB
6sfEAdTMdAn28613wcnbjmdGfEkgHuDZqZeld4dIAtZ+GvLzFz0D+o0zkigCnT4I
faKU9GLIHJe2Cn5FB40b1+M+IGY9t6bl2+WxVc1rd9oSZXfr8ptE7NPllhiOmOhD
/aMVpeSlXzo8DYxIhvtZGwDh5NrJglPFdFRXYuHUDLxkWCCFtXRt//LtWv3EpKqp
dgQUH5QAO5E/+OuycHFLaXOUiKVS0P4=
=bCLk
-----END PGP SIGNATURE-----
Merge tag 'modules-7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux
Pull module updates from Petr Pavlu:
- Ignore local labels and mapping symbols during module load
These symbols were already ignored during kallsyms address-to-symbol
lookups. Filter them out earlier during module loading to reduce
lookup overhead and prevent them from appearing in /proc/kallsyms.
- Fix potentially incorrect access of SetOnce<T> when setting Rust
module parameters.
- Fix a potential read of an uninitialized count when printing taint
information for unloaded modules.
- Allocate the kmod argument array using kmalloc_array() in preparation
for conversion to type-aware allocators.
- Clean up includes in linux/kmod.h
Add explicit includes of linux/umh.h to files that use usermode
helpers. Then clean up the #include list in linux/kmod.h, notably
removing the compatibility linux/umh.h include.
- Remove the error-injection.h include from linux/module.h
Add explicit includes of linux/error-injection.h to files that use
the ALLOW_ERROR_INJECTION() macro and currently rely on it being
provided indirectly via linux/module.h. Then remove the unnecessary
linux/error-injection.h include from linux/module.h.
- Replace __MODULE_STRING() with __stringify() in various drivers in
preparation for removing the former macro.
* tag 'modules-7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux:
drivers: Replace __MODULE_STRING() with __stringify()
module: Fix uninitialized count read of unloaded taint tracking record
rust: module_param: Fix potentially incorrect access of `SetOnce<T>`
module: Remove the error-injection.h include from linux/module.h
drm/xe: Include error-injection.h for ALLOW_ERROR_INJECTION()
drm/i915: Include error-injection.h for ALLOW_ERROR_INJECTION()
syscalls: Include error-injection.h for ALLOW_ERROR_INJECTION()
net: Include error-injection.h for ALLOW_ERROR_INJECTION()
block: Include error-injection.h for ALLOW_ERROR_INJECTION()
module: Bring includes in linux/kmod.h up to date
time/jiffies: Include linux/sysctl.h for proc_int_u2k_conv_uop(), ...
umh, treewide: Explicitly include linux/umh.h where needed
modules/kmod: Allocate argv with kmalloc_array()
module/kallsyms: Ignore local labels and mapping symbols during module load
module/kallsyms: Refactor current symbol filtering into is_core_symbol()
module/kallsyms: Rename is_mapping_symbol() to is_ignored_kernel_symbol()
Cursors in the VT subsystem are blocks within a character cell that are
filled with the foreground color. The new helpers vc_cursor_start() and
vc_cursor_end() return the scanlines in which the cursor block starts rsp.
ends. This is compatible with VGA hardware.
In terms of cursor design, the new cursor-size helpers follow established
styles in fbcon. The only exception is in underline cursors for fonts with
a size larger than 10. The underlining dash is now one pixel closer to
the font-glyph data, so that the cursor looks less detached. This follows
the style used by vgacon.
Users control the cursor size with the vt module's parameter cur_default
or with the ESC sequence \e[?Nc, where N is the cursor-size constant. In
case of an invalid setting, the new helpers fall back to cur_default and
then underline cursors; in this order.
Similar code in vgacon and fbcon ignores the cursor's default size stored
in vt.cur_default. The consoles default to full-block cursors, while vt
defaults to underline cursors. VGA BIOSes also tend to use underline by.
default. Upon initialization vt applies its default to the console, but
each console might fall back to it own default. For example, running the
ESC code from above with the invalid constant of 8 magically flips the
cursor from underline to block size on vgacon. Another call with N set
to 0 (i.e., default) magically flips it back to underlyine. Making
underline the new default everywhere harmonizes vt, fbcon and most VGA
BIOSes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Helge Deller <deller@gmx.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Helge Deller <deller@gmx.de>
On SMP, migration can occur inside hvc_dcc_check() during device_initcall,
so the CPU writing the probe character and the CPU reading the TXfull
status may not be the same, which can hang the system.
Commit 4419da5d5d ("tty: hvc: dcc: Bind driver to CPU core0
for reads and writes") cached the DCC availability detected on core 0
during console_initcall. However, this is not sufficient: if core 0
does not detect DCC as available and another CPU later calls
hvc_dcc_check(), the check is not actually performed on core 0.
Since JTAG is not expected to be plugged or unplugged during kernel
boot, especially between console_initcall and device_initcall, checking
DCC availability multiple times is unnecessary. Cache the return value
from hvc_dcc_console_init and reuse it in hvc_dcc_init. This avoids
complex SMP-related code and ensures the result is always from core 0.
Signed-off-by: Jiannan Du <shatyuka@qq.com>
Link: https://patch.msgid.link/tencent_77968AD30F111278CBAE934BCFD0AF00E807@qq.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In RS485 mode the transceiver is enabled only while data is sent. A
break set with TIOCSBRK therefore never reaches the bus, and protocols
that start each frame with a break, like DMX512, do not work.
Handle an active break like a transmission. Enable the transceiver
before setting the break, after delay_rts_before_send if one is
configured. When the break ends, stop transmitting unless the TX path
is still sending data.
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20261013-devel-pl011-rs485-break-v2-1-31c9f80d3e3d@tipi-net.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pmz_status_handle() sets PMACZILOG_FLAG_BREAK from RR0, and
pmz_receive_chars() clears it on the null character that ends the
break without marking that character, then tests BRK_ABRT in RR1,
where the SCC does not set it in asynchronous mode. Breaks therefore
arrive as plain NULs: brk is never counted and BRKINT, PARMRK and SysRq
never see them.
Set BRK_ABRT in r1 for that character, as sunzilog does.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Assisted-by: LLM
Signed-off-by: Tim Douglas <me@timdoug.com>
Link: https://patch.msgid.link/20261013013541.4535-3-me@timdoug.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pmz_interrupt() drains both channels but, since commit 2e124b4a39
("TTY: switch tty_flip_buffer_push"), pushes the flip buffer of the
port whose handler is running rather than the port that was drained.
With both ports open, data received on the other port can be left in
its flip buffer until something else pushes it, so its reader may not
see it.
Fixes: 2e124b4a39 ("TTY: switch tty_flip_buffer_push")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Tim Douglas <me@timdoug.com>
Link: https://patch.msgid.link/20261013013541.4535-2-me@timdoug.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Disabling RS485 on an open port calls pl011_rs485_tx_stop(), which
turns off the transmitter. Only the RS485 TX path turns it back on, so
any later output stays queued and tcdrain() hangs until the port is
closed.
pl011_rs485_tx_stop() also checks only the hardware FIFO. If a DMA
transfer has started but has not filled the FIFO yet, the transmitter
is turned off under the transfer and the DMA channel never recovers.
When leaving RS485 mode, cancel pending deferred starts and stops, leave
the transmitter enabled and start any TX that was still waiting for
delay_rts_before_send.
Fixes: 8d47923772 ("serial: amba-pl011: add RS485 support")
Cc: stable@kernel.org
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20261012-fix-pl011-rs485-txe-v2-1-e9bf7d218389@tipi-net.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When another console is selected and there is no matching ttyNVT console
argument, the core accepts the MA35D1 console without calling its setup
function because it has CON_ENABLED set before registration. Its index
remains -1 and printk repeatedly reports an invalid port, flooding the
console and preventing boot.
Let the console core enable it after successful setup.
Fixes: 930cbf92db ("tty: serial: Add Nuvoton ma35d1 serial driver support")
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://patch.msgid.link/20261012055340.16719-1-kmehltretter@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
While the driver waits out delay_rts_before_send, another write calls
pl011_start_tx() again. pl011_rs485_tx_start() then switches straight
to SEND, and the data goes out before the delay has passed.
Leave the start to the trigger_start_tx timer while it is pending.
Fixes: 2c1fd53af2 ("serial: amba-pl011: Fix RTS handling in RS485 mode")
Cc: stable@vger.kernel.org
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20261011-fix-pl011-rs485-rts-delay-v1-1-5078e61bc408@tipi-net.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 7885af04df.
Commit 7885af04df ("serial: 8250_port: Drop duplicate NULL check")
added `up->dma = NULL;` to serial8250_release_dma(), with the stated
intent of making sure DMA would not be used again after release.
However, up->dma is assigned once at probe time. serial8250_do_startup()
only calls serial8250_request_dma() when up->dma is non-NULL, so after
the first close the pointer stays NULL and DMA is never re-acquired.
On Intel Tangier (Edison) with HSU DMA this causes a regression: the
first port open uses TX DMA, the second and later opens transmit in PIO
mode, producing 64-byte FIFO bursts with ~50us gaps between them.
Fixes: 7885af04df ("serial: 8250_port: Drop duplicate NULL check")
Cc: stable@kernel.org
Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20261010193755.187706-2-ftoth@exalondelft.nl
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial8250_register_8250_port() returns a line number and the other
port operations (serial8250_unregister_port(), serial8250_suspend_port(),
serial8250_resume_port()) accept it. Many drivers then convert the line
back to the port using serial8250_get_port() anyway.
Switch the interface to struct uart_8250_port:
* serial8250_register_8250_port() now returns the registered port, or
an ERR_PTR() on failure.
* serial8250_unregister_port(), serial8250_suspend_port() and
serial8250_resume_port() accept the port.
Convert all users accordingly. Drivers store the port pointer instead
of the line number. Several drivers kept a private struct only to hold
the line (airoha, dfl, em, fsl, ioc3); these are dropped and the port
is stored as drvdata directly.
This also fixes two latent issues:
* For a CIR port, serial8250_register_8250_port() used to return 0.
Callers stored this as the line, so a later unregister/suspend/resume
operated on ttyS0. Now the CIR port itself is returned.
* 8250_acorn checked ports[i] > 0 on removal, so a port registered as
line 0 was never unregistered.
There are no more users of serial8250_get_port() outside of the 8250
core, so drop its EXPORT.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Assisted-by: LLM
Link: https://patch.msgid.link/c59fa203f325e0fe7601ea0fbc0d222c8b37f9eb.1791873876.git.jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
omap8250_irq() is requested in omap8250_probe() with IRQ_NOAUTOEN and
enabled only in omap_8250_startup(). The handler obtains the port by
serial8250_get_port(priv->line), but probe stores priv->line only after
serial8250_register_8250_port() returns.
The port becomes visible to userspace already inside
serial8250_register_8250_port() (uart_add_one_port()). So it can be
opened -- and the IRQ enabled -- before probe stores the line. An
interrupt in that window makes the handler call
serial8250_get_port(-ENODEV) and dereference a pointer outside of
serial8250_ports[].
Store the line in omap_8250_startup() before enable_irq(), so the
handler never runs with an unset line. Keep the assignment in probe
too, as remove and the system PM callbacks rely on it even when the
port was never opened.
Fixes: fef4f60031 ("serial: 8250: omap: Fix life cycle issues for interrupt handlers")
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Assisted-by: LLM
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/3b3a642f7df2285f49a7bbbe5d1c23fa442c7d94.1791873876.git.jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
lpss8250_probe() calls lpss->board->exit() on its error path. For the
EHL board, that is ehl_serial_exit() and it does:
serial8250_get_port(lpss->data.line)->dma = NULL;
But when lpss8250_dma_setup() or serial8250_register_8250_port() fails,
lpss->data.line was never assigned. As lpss is kzalloc()ed, line is 0
and ehl_serial_exit() clears the dma pointer of an unrelated port --
serial8250_ports[0], i.e. ttyS0, which is often the console.
Initialize lpss->data.line to -1 in probe and skip the clearing in
ehl_serial_exit() if no port was registered.
Fixes: 5318f70da7 ("serial: 8250_lpss: Balance reference count for PCI DMA device")
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Assisted-by: LLM
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: stable@kernel.org
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linux-serial@vger.kernel.org
Link: https://patch.msgid.link/f389df34aaa538270313ebd4cea75c2baaf46b95.1791873876.git.jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
__MODULE_STRING() has been an alias for __stringify() since "[PATCH]
MODULE_PARM support for older modules" [1] in 2002-12. That change also
moved it to the graveyard section at the end of linux/module.h
Replace the remaining uses of __MODULE_STRING() with __stringify() in
preparation for its removal.
Link: https://git.kernel.org/tglx/history/c/136839a1b4 [1]
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Acked-by: Ian Abbott <abbotti@mev.co.uk>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Mika Westerberg <westeri@kernel.org>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
The GPIO platform device is registered via platform->register_gpio()
when port 0 is being set up. It is stored to port->port.private_data of
the on-stack uart template (and from there it is copied into every
registered port). pci_xr17v35x_exit() then fetches it back by
serial8250_get_port(priv->line[0]).
But port 0 does not have to exist at that point. If
serial8250_register_8250_port() fails for port 0, priv->line[0] holds a
negative error code. The probe still succeeds (it only breaks the loop),
so on unbind, priv->line[0] (a negative value) is passed to
serial8250_get_port(). The GPIO device is never unregistered and a
bogus port is accessed.
The same problem would also occur after the planned conversion of
serial8250_register_8250_port() to return a uart port instead of a
line. As Sashiko pointed out in that case:
If board->setup() fails for the first port (i=0) in exar_pci_probe(),
priv->uport[0] remains NULL. If serial8250_register_8250_port() fails,
it returns an ERR_PTR. In either case, the loop breaks and probe
returns success. When the device is later unbound,
pci_xr17v35x_exit() unconditionally passes priv->uport[0] to
platform->unregister_gpio(), which will dereference it without
checking for validity.
The GPIO device belongs to the PCI device, not to any particular port.
So store it in a new struct exar8250::gpio member. Pass priv to both
->register_gpio() and ->unregister_gpio(), so that pci_xr17v35x_exit()
does not need to look up any port at all.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Fixes: d0aeaa83f0 ("serial: exar: split out the exar code from 8250_pci")
Link: https://lore.kernel.org/all/sashiko-outbox-166269@kernel.org/
Assisted-by: LLM
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/03a8b5c71614fc672fef1e55c083bda6c73b5bf3.1791873876.git.jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial8250_register_8250_port() holds serial_mutex using guard(), but
still uses goto-based error handling. Mixing the two is discouraged by
the cleanup guidelines.
Move the part of the function which configures the found port into a
new helper: __serial8250_register_8250_port(). It returns an int and
uses plain returns on failures. The caller now resets uart->port.dev on
failure at a single place, so the err label can go.
While at it, simplify the mctrl_gpio_init() error handling: return
PTR_ERR() directly and drop the else branch.
No functional change intended.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Assisted-by: LLM
Link: https://patch.msgid.link/baf799ad88f9ef43093ae96731f48a5e88d726dd.1791873876.git.jirislaby@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 8ca59f7bae ("serial: fix ioctl hangup race") made
uart_set_info() and uart_do_autoconfig() return -EIO when TTY_IO_ERROR
is set, so that they do not run on a port that has been hung up.
However, TTY_IO_ERROR is also set on a port that could not be started,
for example because its type is unknown, and by uart_shutdown(), which
both functions call. As of now, setserial cannot configure a port that
the kernel did not detect, and an autoconfig that follows a port, irq or
type change in the same setserial call fails on any port.
The issue can be reproduced with setserial (busybox) on a port without
a detected UART, for example ttyS3 of a QEMU guest:
setserial /dev/ttyS3 uart 16550A
setserial -g /dev/ttyS3
Before commit 8ca59f7bae ("serial: fix ioctl hangup race"), the
result is:
/dev/ttyS3, UART: 16550A, Port: 0x02e8, IRQ: 3
After that commit, the result is:
setserial: can't set serial info: Input/output error
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
This patch will check tty_port_active() in these two functions instead.
uart_hangup() clears it under the port mutex, and it stays set on an
open port that could not be started.
Fixes: 8ca59f7bae ("serial: fix ioctl hangup race")
Cc: stable@kernel.org
Signed-off-by: Hengyu Liang <hengyul@cs.unc.edu>
Tested-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20261010034616.3915864-1-hengyul@cs.unc.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
TIOCSRS485 applies its register changes asynchronously: rs485_config()
stores the new configuration and schedules rs_work, which programs
HDPIXDELAY, MODE1.TRNSCVCTRL and the RTS path. A write() issued right
after the ioctl therefore transmits against the old, half-switched
state. On a single core the ordering is even deterministic: start_tx()
picks the stale path first, then rs_work reprograms the chip, then
tx_work pumps the data - with the transceiver already released. A
TIOCSRS485 switching from the hardware to the software RTS path
followed immediately by a write puts the whole transfer on the wire
with the transceiver disabled: nothing reaches the bus and no error is
reported anywhere. The inverse direction is as old as the asynchronous
reconfigure itself: enabling RS485 and writing immediately shifts the
first bytes out before rs_work has enabled the chip's auto-RTS.
Defer instead: rs485_config() marks the reconfigure pending under
port->lock, start_tx() leaves the data in the kfifo while the mark is
set, and rs_work restarts the transmission itself once the new
configuration is fully applied. The rs485-disable path's direct
tx_work kick is replaced by the same mechanism, which also orders that
flush after the reconfigure instead of before it.
The restart kick also checks port->x_char: uart_send_xchar() reaches
start_tx() too, and a lone x_char deferred by the pending gate leaves
the kfifo empty, so the kick would otherwise skip it and nothing else
would ever send it - an idle chip FIFO raises no TXEMPTY interrupt.
And start_tx() re-checks the pending mark after the
hrtimer_try_to_cancel(-1) path retakes the dropped lock, mirroring the
tx_teardown re-check there: a TIOCSRS485 posted inside that window
would otherwise let the transmission proceed on the stale path.
rs_work takes port->lock for that restart through
uart_port_lock_irqsave(): start_tx() may drop and retake the lock
through the uart_port API on its hrtimer_try_to_cancel(-1) path, and a
raw spinlock guard around the call would unbalance the nbcon console
handling underneath.
The restart also rewinds a send state adopted for the deferred write
itself: set_rts_ctl_params() cannot tell data the pending gate
deferred apart from an in-flight transfer's refill by the xmit buffer
alone, and a deferred write pumped in the adopted send phase would
skip the configured before-send delay. With the chip FIFO empty the
adopted state can only be the deferred write: rewind it and let the
restart run the full envelope.
The chip-FIFO check for that rewind is deliberately lock-free, so a
TX-empty refill can land between the read and the lock and the rewind
can hit a live envelope. The consequence is bounded: the rewind runs
under port->lock in a state the RTS worker reads as asserted, so the
envelope pauses one before-send delay with the transceiver held - the
same pause the unconditional rewind produced before patch 8's guard.
Fixes: 5bdb48b501 ("serial: max310x: Fix RS485 handling")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
Link: https://patch.msgid.link/20261008-max310x-rs485-sw-delay-v8-9-6ba881f81e1f@vaisala.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The chip's auto-RTS path can express at most 15 bit-times of RTS setup
and hold delay - a fraction of a millisecond at typical baud rates -
while the uapi expresses the delays in milliseconds up to the UART
core's RS485_MAX_RTS_DELAY. Requests beyond the field were rejected
with -ERANGE, which makes the core silently wipe port->rs485 and
disable RS485; a device tree asking for a 20 ms setup delay ends up
with no RS485 at all and an unusable bus.
Add a software-driven RTS path that takes over whenever the hardware
cannot represent the requested timing, and clamp the delays to
RS485_MAX_RTS_DELAY instead of rejecting them.
max310x_set_rts_ctl_params() picks the path: software if either delay
exceeds what 15 bit-times encode at the current baud rate, or if the
requested RTS polarity combination cannot be produced by the auto-RTS
engine; hardware otherwise, as before.
On the software path the RTS envelope is driven by a single hrtimer,
re-used for the before- and after-send phases (tracked in tx_state),
plus a single rts_work that toggles RTS. start_tx() begins the
envelope; rts_work asserts RTS and only then arms the before-send
timer, so data is never shifted before RTS is on the wire. The timer
expiry kicks tx_work; once the chip FIFO drains, the same timer is
re-armed for one character (the byte still in the shift register)
plus the after-send delay, after which rts_work releases RTS. One
timer and one work keep the phases mutually exclusive and the RTS
toggles ordered. A start_tx() landing while the envelope is already in
its send phase only pumps the new data: rewinding it to the
before-send phase would insert a spurious setup delay mid-stream.
Teardown is interlocked: shutdown() and an RS485-disabling
TIOCSRS485 set tx_teardown under port->lock before cancelling the
timer and works, and start_tx() checks it on entry and again after
the hrtimer_try_to_cancel(-1) path retakes the dropped lock -
otherwise a write racing the teardown could re-arm the timer or
queue rts_work against a port being shut down, leaving the
transceiver driving the bus after close. The rs485-disable path
additionally kicks tx_work afterwards, since a racing write may have
queued data with no envelope left to pump it, and shutdown() now also
cancels tx_work, which was previously cancelled only in remove(). The
interlock also fences the adoption path below, so a reconfigure racing
a teardown cannot re-enable the cancelled timer, and an RS485 disable
flushes a queued rts_work before the pin is settled: one already past
its tx_state read would re-assert RTS after the settle.
set_rts_ctl_params() publishes sw_rts_during_tx with a single store
and settles the RTS idle level only while tx_state is off, because
serial_core calls set_termios() without port->lock and rs485_config()
schedules a reconfigure on every TIOCSRS485 - either could otherwise
release the transceiver mid-envelope. The settle also re-checks
tx_state after its write and requeues rts_work if an envelope started
meanwhile: the state read and the register write are not atomic, and
rts_work re-derives the level from tx_state, so this converges without
locking. shutdown() gates first - the
interlock is set and the interrupts are masked before any wait, so
nothing can start a new envelope or requeue tx_work behind the cancels
- then honours a running after-send hold, bounded by the after-send
delay plus two character times (the transmitter is already stopped by
this point), and cancels the timer and works unconditionally: a
TIOCSRS485 can clear sw_rts_during_tx while an envelope is still in
flight, and neither may outlive the port. A hold that did not complete
within the bound is settled by the final release below regardless.
break_ctl() on the software path applies the
configured RTS polarity itself.
A reconfigure can also move the port off the hardware path while the
chip's auto-RTS still owns a transmission in flight - a termios change
or TIOCSRS485 pushing a delay above what the hardware can time at the
new rate. Such transfers are invisible to tx_state, so the idle settle
would release RTS and the MODE1 write would disable auto-RTS
mid-transfer, shifting the rest of the data out with the transceiver
released and no error reported anywhere. Adopt the transfer instead
when the chip TX FIFO or the xmit buffer is not empty: enter
MAX310X_TX_SEND and drive RTS manually before auto-RTS is disabled, so
the pin is never released across the handover, and the normal drain
path arms the after-send hold - or the adoption arms it directly if
the FIFO drained while this raced the TX-empty worker. A transfer
whose last character has already left the FIFO for the transmit shift
register is still invisible and keeps the old behavior: at most one
character of early release.
The reverse move strands state instead: a reconfigure onto the
hardware path mid-envelope left tx_state set, because nothing reset it
in that direction and the TX-empty hold arming only ran while the
software path was selected. A later reconfigure back off the hardware
path then trusted the stale tx_state, skipped both the adoption and
the idle settle, and disabled auto-RTS with the RTS register released
- the rest of the transfer in flight shifted out with the transceiver
off, again with no error reported (hit twice in 79 in-flight
reconfigures under a multi-process stress test). The TX-empty unwind
now runs regardless of the selected path - it is a no-op outside an
envelope - and the reconfigure asserts RTS for any transfer it
believes exists, stale or live, before auto-RTS is disabled. The hold
is armed only once no transmittable data remains, so that assert
cannot cut a burst short when it lands in a FIFO refill window;
output that is stopped still releases through the hold.
rts_work also derives the level from tx_break: a break can begin while
the previous envelope's after-send hold is still armed - TIOCSBRK waits
for the output to drain, which lands the break exactly there - and the
expiring hold would otherwise release the transceiver mid-break. With
break ownership in the derivation the hold expiry becomes an idempotent
re-assert, and break-off restores the idle state as it already does.
shutdown() gives its final RTS release one bit time, and at
least 100 us, to reach the pin before powering the port down. The
power-off stops the UART channel clock, and the RTS output stage is
clocked by it: a release written immediately before the clock stops
reaches the register but never moves the pin, which stays asserted
until the next startup restarts the clock - a close racing the
after-send hold expiry left the transceiver driving the bus, with the
register reading released and the pin high. The measured propagation
is about one tick of the 16x oversampling clock - below 50 us at
1200 baud - so one bit time keeps a 16x margin and scales with the
clock the output stage runs on; the floor covers rates where a bit is
shorter than the measured bound. Handing the pin to the
chip's auto-RTS engine instead was tried and rejected on the wire:
the pin level is RTSINVERT xor the selected source, so for an
active-low RTS every single-register step of that handover drives the
pin to the asserted level, and the same clock stop can freeze it
there.
Fixes: 55367c620a ("serial: max310x: Add support for RS-485 mode")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
Link: https://patch.msgid.link/20261008-max310x-rs485-sw-delay-v8-8-6ba881f81e1f@vaisala.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The TXEMPTY interrupt asks for a FIFO refill, and start_tx() does
nothing beyond scheduling tx_work, so going through it makes no
functional difference. It does conflate two distinct events, though:
start_tx() is the serial core starting a new transmission, while
TXEMPTY can only fire for a transmission that is already running -
the bit latches on the FIFO's non-empty to empty transition, and the
IRQ handler's read of IRQSTS consumes the latch, so a stale TXEMPTY
cannot exist on an idle port (if the bit were level-triggered, the
handler's read-until-clear loop would never terminate).
Schedule tx_work directly, keeping the interrupt path a pure FIFO
refill. This is preparation for a following patch that adds
software-timed RS485 RTS control, where start_tx() also starts the
RTS envelope and a refill must not restart it.
No functional change.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
Link: https://patch.msgid.link/20261008-max310x-rs485-sw-delay-v8-7-6ba881f81e1f@vaisala.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The chip's auto-RTS engine asserts the RTS_ pin high while data is
shifting out, so a transceiver with an active-low driver-enable could
not use the hardware RS485 path at all: SER_RS485_RTS_AFTER_SEND is
not in the supported flags and the core normalizes it away with
"invalid RTS setting, using RTS_ON_SEND instead".
The output stage is invertible: program IRDA.RTSINVERT when the
requested polarity is active-low and advertise SER_RS485_RTS_AFTER_SEND
in rs485_supported. A break already drives break_state onto the RTS
bit unadjusted, which remains correct because RTSINVERT inverts the
output stage itself, not the register value.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
Link: https://patch.msgid.link/20261008-max310x-rs485-sw-delay-v8-6-6ba881f81e1f@vaisala.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
max310x_shutdown() powers the port down regardless of what the
transmitter is doing. The power-off stops the UART clock mid-character,
truncating the final frame, and on the auto-RTS path it freezes the
RTS output at its current level: a close() with data still queued
leaves the RS485 transceiver asserted until the next open, which also
emits the interrupted character corrupted.
Waiting for the data to drain is no better: the tty layer's
wait-until-sent is bounded by closing_wait, configurable to none, and
a hangup arrives with no wait at all, so draining a full FIFO blocks
close() in uninterruptible sleep for seconds at low baud rates - and
forever when CTS flow control blocks the FIFO.
Instead, set MODE1 TxDisabl: the character in flight completes and the
transmitter ceases with TX_ at idle. Give that character one character
time (the chip has no transmitter-idle status), then reset the FIFOs
so the auto-RTS engine sees the transmitter empty and releases RTS
within the configured after-send hold; wait that hold plus one bit
time before powering off. Abandoned data was explicitly not waited
for, and startup() resets the FIFOs and TxDisabl on open anyway.
Measured on a MAX14830: a truncating close() at 50 baud takes 0.23 s,
RTS releases one character plus the hold after the last stop bit on
both polarities, and the reopen corruption is gone.
Fixes: f65444187a ("serial: New serial driver MAX310X")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
Link: https://patch.msgid.link/20261008-max310x-rs485-sw-delay-v8-5-6ba881f81e1f@vaisala.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The HDPIXDELAY register counts the RTS setup and hold delays in
bit-times, four bits per direction, but the driver has been writing the
struct serial_rs485 delay_rts_before_send/delay_rts_after_send values
into it unconverted - and the uapi expresses those in milliseconds. A
requested 9 ms setup delay is programmed as 9 bit-times, which at 9600
baud is 0.94 ms, roughly a tenth of what userspace asked for; the error
grows with the baud rate.
Cache the baud rate in set_termios() and convert the delays to
bit-times at the current rate, rounding up so the delay on the wire is
never shorter than requested, and capping at the 15 bit-times the
4-bit field can hold. The conversion lives in
max310x_set_rts_ctl_params(); set_termios() now calls it as well,
since the conversion depends on the baud rate.
The delays a 4-bit bit-time field can represent still fall well short
of the milliseconds the uapi can express; requests beyond 15 bit-times
are capped, and the -ERANGE rejection of values above 15 ms remains in
place for now.
Fixes: 55367c620a ("serial: max310x: Add support for RS-485 mode")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
Link: https://patch.msgid.link/20261008-max310x-rs485-sw-delay-v8-4-6ba881f81e1f@vaisala.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The HDPIXDELAY RTS delays and the MODE1 auto-transceiver enable are
programmed in three places - the rs485-config worker, startup() and
break_ctl()'s break-off restore - each with its own copy of the
register sequence. Move the sequence into a helper,
max310x_set_rts_ctl_params(), together with the tx_break guard that
keeps the MODE1 write away from a break in progress; the break-off
restore reapplies the current configuration through the same helper.
No functional change intended. The copies differed only in that
startup() clamped the delays to the 4-bit field while the worker wrote
them unclamped; the helper clamps, and the difference is unreachable
while rs485_config() still rejects delays above 15 ms with -ERANGE.
Break-off additionally rewrites HDPIXDELAY with the values it already
holds, a no-op on the wire.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
Link: https://patch.msgid.link/20261008-max310x-rs485-sw-delay-v8-3-6ba881f81e1f@vaisala.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The chip's auto-RTS (MODE1.TRNSCVCTRL) asserts the RS485 transceiver
only while FIFO data is shifting out, and a break is not FIFO data: on
an RS485 port a requested break sets the TX break bit but the
transceiver is never enabled, so the break never reaches the wire.
Break-led protocols cannot work at all.
Disable auto-RTS for the break duration and drive RTS manually via the
LCR RTS bit, then restore auto-RTS when the break ends. Track the break
in tx_break and leave MODE1 alone in the rs485-config worker while it
is set - a TIOCSRS485 arriving mid-break would otherwise re-enable
auto-RTS on top of the manual RTS and release the transceiver before
the break ends; break_ctl() restores auto-RTS from the then-current
configuration when the break completes. The worker runs under
port->mutex - break_ctl() and set_termios() already do - so the
tx_break test and the MODE1 write cannot straddle a break starting or
ending, and startup() clears tx_break alongside the latched TXBREAK
bit, since a port can be closed with a break still asserted.
Only the break assertion is gated on RS485 being enabled; the restore
at break end runs unconditionally and derives MODE1 from the current
configuration. Returning early for a port whose RS485 was disabled
mid-break - that reconfigure is deferred like any other - would leak
the manually driven RTS and leave the transceiver holding the bus
indefinitely after the break ends. On a non-RS485 port the restore is
a no-op: nothing else writes the LCR RTS bit.
Fixes: 55367c620a ("serial: max310x: Add support for RS-485 mode")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
Link: https://patch.msgid.link/20261008-max310x-rs485-sw-delay-v8-2-6ba881f81e1f@vaisala.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A TX break asserted with TIOCSBRK ends early, with no error reported,
as soon as any termios change lands on the port: a break is a state
that must hold until TIOCCBRK, but max310x_set_termios() overwrites
the whole LCR register, and LCR also carries the TX break bit that
break_ctl() drives. No concurrency is required - a baud or parity
change from the same process ends the break just as well, and
break-led protocols lose their break with nothing in the logs.
Update only the LCR bits that are derived from termios and leave the
TX break and RTS pin control bits untouched. Since nothing clears a
break when a port is closed with the break still asserted - the tty
core sends no break-off on release, and the unconditional write here
was the accidental recovery - clear TXBREAK in startup(), the same way
8250 does.
Fixes: f65444187a ("serial: New serial driver MAX310X")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
Link: https://patch.msgid.link/20261008-max310x-rs485-sw-delay-v8-1-6ba881f81e1f@vaisala.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sdio_uart is an SDIO function driver, not part of the MMC/SDIO core.
Keeping it in drivers/mmc/core/ is misplaced: it registers to the SDIO
bus (sdio_register_driver) and only uses the public SDIO API from
include/linux/mmc/, with no dependency on any mmc core internals.
Other SDIO function drivers live under their respective functional
subsystem, e.g. the SDIO WiFi drivers are under drivers/net/wireless/.
sdio_uart should likewise be placed under its functional subsystem, tty,
just like the PCIe and I2C/SPI transport drivers (men_z135_uart,
sc16is7xx, max310x) that live under drivers/tty/serial/.
Historically almost all changes to this driver were tty API changes
(e.g. tty_operations adjustments, alloc_tty_driver removal), yet
scripts/get_maintainer.pl never listed the TTY maintainers while the
file lived under drivers/mmc/core/. Moving it under drivers/tty/serial/
makes get_maintainer.pl report the proper TTY/serial maintainers and
reviewers, which benefits future maintenance of this driver.
No functional change. The CONFIG_SDIO_UART symbol is intentionally kept
unchanged to avoid breaking existing configs; the dependency is updated
to 'TTY && MMC' accordingly.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://patch.msgid.link/1791626517-18161-1-git-send-email-shawn.lin@rock-chips.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
MCR register has the same address as XON1 register.
IER register has the same address as DLH register.
Which register is accessed depends on bits configuration in some
other registers.
To prevent potential access errors, declare MCR and IER as volatile
registers.
Fixes: dfeae619d7 ("serial: sc16is7xx")
Cc: stable@kernel.org
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Link: https://patch.msgid.link/20261006192540.234402-1-hugo@hugovil.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use platform_get_irq_optional() to be able to handle potential
-EPROBE_DEFER and other errors. Move it earlier to avoid having to call
kfree() on the global array.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20261003213148.137206-1-rosenp@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a serial port configured as a console is opened and subsequently
closed, tty_port_shutdown() skips invoking port->ops->shutdown() because
port->console is true. As a result, tty_port_initialized() remains true
and the port's interrupt handler stays registered in the irq subsystem.
If the underlying device is later unbound or removed (e.g. via sysfs
driver unbind or device hot-unplug), serial_core_remove_one_port()
unregisters the console, frees uport->name via kfree(), and tears down
the port without shutting it down or freeing its IRQ. Consequently, the
irqaction descriptor remains registered in genirq with action->name
pointing to freed memory.
This triggers a use-after-free read whenever genirq accesses action->name,
such as when reading /proc/interrupts:
BUG: KASAN: slab-use-after-free in string+0x476/0x570
Call Trace:
string+0x476/0x570
vsnprintf+0x422/0x1300
seq_printf+0x...
show_interrupts+...
Fix this by acquiring port->mutex in serial_core_remove_one_port() after
console unregistration, clearing port->console under the mutex to prevent
data races with concurrent tty_port_shutdown(), and invoking
uart_shutdown(NULL, state) if the port remains initialized. This ensures
that port->ops->shutdown() is called and the IRQ is freed before
kfree(uport->name).
Reported-by: syzbot+843bf2f48f4d12e6682e@syzkaller.appspotmail.com
Cc: stable <stable@kernel.org>
Closes: https://syzkaller.appspot.com/bug?extid=843bf2f48f4d12e6682e
Fixes: 761ed4a945 ("tty: serial_core: convert uart_close to use tty_port_close")
Fixes: f7048b1590 ("tty: serial_core: Add name field to uart_port struct")
Signed-off-by: Igor Putko <igorpetindev@gmail.com>
Link: https://patch.msgid.link/20261003163337.45577-1-igorpetindev@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace direct dma_async_tx_descriptor->tx_submit() calls with the
proper dmaengine_submit() API wrapper.
Assisted-by: LLM
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20261002200927.236033-1-Frank.Li@oss.nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The hardware supports automatically sending XON/OFF based on the
FIFO status and that is already implemented by the driver.
However that capability was not announced with the UPF_SOFT_FLOW bit.
When the port is opened with the default of XON enabled the driver
configures that in the hardware.
If userspace does not want XON/OFF (which is normally the case) it will
use TCSETS to disactivate it. However the serial core optimises this
to only notify the driver if someting imporant has changed, and for
XON/XOFF thit is only if the driver declares UPF_SOFT_FLOW.
So we end up with unwanted XON/XOFF in the data stream.
The problem only occurs if nothing else needed to be set by termios,
ie if the user space requested values are the same as the default values,
except for XON/XOFF.
Since the default speed is 9600 this means that the problem only occurs
when requesting 9600, otherwise the call to the driver will be made to
change the speed, and that will also clear the XON/XOFF.
As 9600 is quite rare these days that probably explains why this hasn't
already been seen.
It also only occurs on the first port open after boot since the subsequent
opens will use the "logical state" set by TCSETS but not communicated to
the driver the first time.
Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
Fixes: dfeae619d7 ("serial: sc16is7xx")
Cc: stable@kernel.org
Link: https://patch.msgid.link/20261001100534.1225894-1-martin.fuzzey@flowbird.group
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The bcm2835aux mini UART can automatically de-assert RTS based on the RX
FIFO fill level and gate the transmitter on CTS, but the driver never
made use of it. Wire it up:
- Enable AUTORTS/AUTOCTS (with the RTS4 threshold and inverted, i.e.
conventional active-low, polarity) whenever CRTSCTS is set on ports
declaring the "uart-has-rtscts" property, advertised via
UPF_HARD_FLOW.
- Gate the AUTORTS function on TIOCM_RTS in set_mctrl() so that clearing
RTS (port close, TIOCMBIC, B0) actually de-asserts the pin while auto
flow control is active.
- Implement throttle()/unthrottle() by disabling the RX interrupts and
letting the FIFO fill up, making the hardware de-assert RTS - the same
approach as in 8250_omap. Re-sync this state on termios and rs485
changes, as those paths may re-enable the RX interrupts (or leave them
disabled) behind the throttle's back.
- Never enable auto flow control together with rs485, which uses RTS as
the transceiver direction control. As the software CTS fallback of the
serial core cannot work without a modem status interrupt, strip
CRTSCTS whenever it cannot be handled in hardware. Keep it when a CTS
GPIO is present, as the serial core's mctrl_gpio handling then
delivers the interrupt and the software fallback keeps working.
- Restore RXEN when rs485 is disabled, as the emulation may be torn down
without the rs485_stop_tx() callback ever being called, which would
leave the receiver disabled.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jan Čermák <sairon@sairon.cz>
Link: https://patch.msgid.link/20261001090432.1045270-1-sairon@sairon.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The console holds a runtime PM reference on its port, which keeps the
port powered while the tty is closed. On system suspend
pm_runtime_force_suspend() powers the port down regardless, but a single
reference makes pm_runtime_need_not_resume() report the port as not in
use, so it is marked runtime suspended instead of being flagged for
pm_runtime_force_resume(). On system resume the port therefore stays
powered down while uart_resume_port() goes on to program the termios
settings and re-enable the console.
If the tty has been opened before, uart_resume_port() ends up in
startup(), whose runtime PM reference powers the port up again, and only
the register writes made before that are lost. If the tty has never been
opened (no getty on the port, /dev/console backed by another console),
nothing powers the port back up and the console stays dead after the
first suspend.
Resume the port explicitly before uart_resume_port() when the console
was force suspended.
Assisted-by: LLM
Fixes: aee1f94dab ("serial: qcom-geni: remove .pm callback, use runtime PM in startup/shutdown")
Signed-off-by: David Heidelberg <david@ixit.cz>
Link: https://patch.msgid.link/20260918-qcom-geni-pm-v1-1-cb587e215607@ixit.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEESH4wyp42V4tXvYsjUqAMR0iAlPIFAmrElacbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyAAoJEFKgDEdIgJTyEgwP/3SNJc5pKblEeXNjwHJK
ezaA9s8cGua0hHYWlrveqeWqiJ40pqhEzIxNDqrfq7eqK9sNSPB5sfFamcN6Kahx
KLd8sRpTe56z76mwg7Bj6zOjYl91EpcPAD5cKbMAaRyPziJ5CbYfNPMMD9UO37sS
KvYD3KnmZ8CvZDadHJkb051SVnvpNN+uX6JmQxBovZQtW/o7dl3BKFF1TZZsZ/E5
ekYVR/kGiZk5mCL8B192r0bssqrlbMvalVeO2dIZiEMdcJDWDPc1Qpw0Ry4nViCh
VF18bNmhIVCYWEZbc8YNqjk6U/MXxYWQUyCZkEGfwvMfOYb2nkfzCDGT6Qzl0WLc
jpEKaXBAJF3py2as+QGyDWH0oiYkDtyZLavjIHvAXJ9SwGYCyM7Nh3iU2bBRwysu
I/pqpahDaSZ6t5gh/Qp3VKl6WXEwng313Alyxxn/Fg3cYhPXyKt3wfzVThRouyfk
X3PJr2Qmksp8iDNIm/Nktgt/rppmPQcW70fQiy13WOha/7/klrJAy6i2UVtcGrqI
gmC3YkLcMmD0Ux2Siyi1y676oNx5Gp3ZOLVBDdmgDVQVNj28sCxeyydbPIz7421H
jG6eUldW1tHq0YMb/p5MJ6Evjofak8yPXOouHGyaZVI5REPcwdrMSXd2Qwk66FVJ
P5EPL9nIWEBYRrNuWNkYBUk0
=qEv0
-----END PGP SIGNATURE-----
Merge tag 'printk-for-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux
Pull printk fix from Petr Mladek:
- Allow using Braille console with a serial console driver converted
to NBCON API
* tag 'printk-for-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux:
braille: nbcon: Allow to use a serial console with NBCON API as Braille console
Resolves a bunch of merge conflicts with serial driver changes and we
need the fixes in here for testing and future patches.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Braille console is not registered in console_list. Instead, it is
integrated with the virtual terminal (VT) and shows what is displayed
on the terminal. It writes the data using con->write*() callback
of the associated serial console driver.
braille_write() is called from the VT code under console_lock().
The associated serial console driver can be converted to the NBCON API
though. The situation is similar to flushing nbcon consoles in the legacy
loop when some boot consoles are still registered, see
nbcon_legacy_emit_next_record().
But there is a big difference though. braille_write() is not directly
called from the code paths flushing registered consoles. The VT code
expects that braille_write() succeeds. It does not replay the message
when it can't acquire the ownership. As a result, braille_write():
+ must try harder to get the ownership.
+ has to be synchronized only against non-printk serial console
which depend nbcon_device_try_acquire() using NBCON_PRIO_NORMAL.
Let's look at it from another side and try to simulate the original
locking using the NBCON API:
1. Take con->device_lock(), aka the port->lock in the legacy serial
console driver.
2. Acquire nbcon context to provide some synchronization for a panic()
context. Use NBCON_PRIO_NORMAL because it contends only with
nbcon_device_try_acquire() users. Do it in a busy loop. It should
always succeed when con->device_lock() succeeded because all other
users do the same. The only exception is when the context get acquired
by a CPU handling panic.
3. In panic, disable interrupts and try to acquire the nbcon context.
Use NBCON_PRIO_PANIC. And try even an unsafe takeover because
otherwise the Braille console won't see the text shown during panic().
It is similar to the oops_in_progress/trylock handling in the legacy
serial console driver.
Finally, avoid the newline prepending logic in the existing serial console
drivers when they are used as a Braille console. As explained above,
the Braille console shows the last modified line on the terminal (VT).
braille_write() is called when single characters are added. Most
messages are not ended by newline. Anyway, the VT code does not have
logic to reply partially printed messages.
Fixes: 13189fa73a ("printk: nbcon: Rely on kthreads for normal operation")
Reviewed-by: John Ogness <john.ogness@linutronix.de>
[pmladek@suse.com: Remove white space changes in braille_register_console(). Typo fix.]
Link: https://patch.msgid.link/20261001140727.124398-2-pmladek@suse.com
Signed-off-by: Petr Mladek <pmladek@suse.com>
In paste_selection(), the loop copies min_t(unsigned int,
vc_sel.buf_len - pasted,tty->receive_room) bytes per iteration into
tty_ldisc_receive_buf() and increments pasted += count.
Because the selection mutex (vc_sel.lock) is dropped inside the loop
Whenever the line discipline buffer fills up and paste_selection()
sleeps on tty->write_wait, a concurrent TIOCLINUX (TIOCL_SETSEL) ioctl
can replace vc_sel.buffer with a shorter selection and reduce
vc_sel.buf_len below pasted.
When paste_selection() resumes, vc_sel.buf_len - pasted underflows as an
unsigned integer to a large positive value, causing
tty_ldisc_receive_buf(ld, vc_sel.buffer + pasted, NULL, count) to read
up to 4094 bytes out-of-bounds past the newly allocated vc_sel.buffer.
Fix this by terminating the loop when pasted >= vc_sel.buf_len.
Kernel stack trace (Linux 7.3.0-rc3):
==================================================================
BUG: KASAN: slab-out-of-bounds in n_tty_receive_buf_common+0xa01/0x1650
Read of size 4094 at addr ffff888101c58010 by task kworker/u17:1/65
Workqueue: events_unbound flush_to_ldisc
Call Trace:
<TASK>
dump_stack_lvl+0x70/0xa0
print_report+0x153/0x4c6
kasan_report+0xf1/0x120
kasan_check_range+0x11c/0x200
__asan_memcpy+0x29/0x70
n_tty_receive_buf_common+0xa01/0x1650
tty_ldisc_receive_buf+0x66/0x110
tty_port_default_receive_buf+0x6b/0xb0
flush_to_ldisc+0x1b4/0x410
process_one_work+0x6ff/0x1110
worker_thread+0x4a8/0xb70
kthread+0x307/0x3e0
ret_from_fork+0x3ed/0x680
</TASK>
==================================================================
Fixes: e8c75a30a2 ("vt: selection, push sel_lock up")
Cc: stable <stable@kernel.org>
Assisted-by: LLM
Signed-off-by: Hui Peng <benquike@gmail.com>
Link: https://patch.msgid.link/20260919110041.3763078-1-benquike@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[BUG]
Recently, we encountered a KASAN warning as follows:
BUG: KASAN: slab-out-of-bounds in fb_pad_aligned_buffer+0x11f/0x140
Read of size 1 at addr ff1100015fd9f6a4 by task tty_fbcon_oob/1239
CPU: 7 UID: 0 PID: 1239 Comm: tty_fbcon_oob Not tainted 7.3.0-rc1 #100 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
Call Trace:
<TASK>
...
kasan_report+0xf0/0x120
fb_pad_aligned_buffer+0x11f/0x140
ccw_putcs+0x86c/0xa80
fbcon_putcs+0x338/0x410
do_update_region+0x21d/0x450
do_con_write+0x1e0e/0x4880
con_write+0x13/0x80
n_tty_write+0x374/0x1010
file_tty_write.isra.0+0x404/0x7a0
...
reproduce:
1) open /dev/tty0, set a KDFONTOP ioctl with op.op = KD_FONT_OP_SET,
op.width = 8 and op.height = 16 (visible VC1)
2) open /dev/tty1, set a KDFONTOP ioctl with op.op = KD_FONT_OP_SET,
op.width = 28 and op.height = 24 (invisible VC2)
3) echo 3 > /sys/devices/virtual/graphics/fbcon/rotate_all
4) write EShash8(esc hash8) to tty1
[CAUSE]
All VCs render to the framebuffer. setfont only modifies the target VC's
font without resizing the framebuffer backing buffer (par->rotated.buf);
the buffer is only resized for the visible VC
(fbcon_do_set_font -> ... -> vc_do_resize -> update_screen). This relies on
the con_should_update() check performed before every update_region().
However, the ESC # 8 path (do_con_trol -> do_update_region) omits the
con_should_update() check. After changing the font size of an invisible VC,
do_update_region() fills using the new font size against a buffer that was
never resized, causing an out-of-bounds access.
[FIX]
Only push the update when the console is visible and not blanked, add
the con_should_update() check in the do_con_trol() like every other call
site of do_update_region() (update_region(), invert_screen(), ...).
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Cc: stable <stable@kernel.org>
Signed-off-by: Zizhi Wo <wozizhi@huawei.com>
Link: https://patch.msgid.link/20260905064337.3083103-1-wozizhi@huaweicloud.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The reload of 'vc' added by commit 8fb9ea65c9 ("vc_screen: reload load
of struct vc_data pointer in vcs_write() to avoid UAF") sits after the
'if (ret)' block, so the copy-failure break path exits the loop without
reloading vc. If the vc was kfree()'d via vc_port_destruct during the
unlocked copy_from_user() window, the post-loop
'if (written && vc) vcs_scr_updated(vc)' is reached with a stale
non-NULL vc. The '&& vc' guard from commit a287620312 ("vc_screen:
fix null-ptr-deref in vcs_notifier() during concurrent vcs_write") only
handles the NULL case, not this stale-non-NULL case; vcs_notifier() then
reads param->vc->vc_num from freed memory:
BUG: KASAN: slab-use-after-free in vcs_notifier+0x7c/0xd0
Read of size 2 at addr ffff888007149190
Call Trace:
vcs_notifier+0x7c/0xd0
atomic_notifier_call_chain+0x70/0xa0
vcs_scr_updated+0x77/0xa0
vcs_write+0x71b/0x7e0
Allocated by task: vc_allocate -> con_install -> tty_open
Freed by task: kfree <- vt_ioctl (VT_DISALLOCATE -> vc_port_destruct)
Move the reload to immediately after console_lock(), before 'if (ret)',
so every break path below passes a fresh vc to the post-loop
vcs_scr_updated().
Fixes: a287620312 ("vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write")
Cc: stable@kernel.org
Signed-off-by: Yi Yang <yiyang13@huawei.com>
Link: https://patch.msgid.link/20260901113131.2760010-1-yiyang13@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Without CONFIG_MODULES, __init_or_module means __init, so
serial8250_pnp_exit() and serial8250_hub6_exit() end up in .init.text.
They are also called from serial8250_exit(), which is __exit, and
modpost warns:
WARNING: modpost: vmlinux: section mismatch in reference: serial8250_exit+0x2a (section: .exit.text) -> serial8250_pnp_exit (section: .init.text)
The exit code never runs in such a kernel, so nothing breaks at runtime.
But a function that is called from both __init and __exit code can't
carry either annotation, so drop it.
Fixes: a300273c45 ("serial: 8250: hub6: Add cleanup code")
Fixes: 4cf187f9de ("serial: 8250: pnp: Annotate init and exit functions for conditional discarding")
Assisted-by: LLM
Signed-off-by: Danish Khateeb <danishkhateeb03@gmail.com>
Link: https://patch.msgid.link/20260926163506.487201-1-danishkhateeb03@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial8250_unregister_port() removes a port and then re-registers it
against the legacy serial8250 device when that device is still
present, ignoring the return value of uart_add_one_port(). When the
re-register fails, the error path of serial_core_register_port()
removes the port device but leaves port->port_dev dangling (or NULL
if the port device allocation itself failed). serial8250 matches
ports on ->dev, so such half-registered slots still reach
serial_core_unregister_port() on the next unbind:
KASAN: null-ptr-deref in range [0x40-0x47]
RIP: serial_core_unregister_port+0xe5/0xa00
serial8250_unregister_port+0x103
serial8250_remove+0x61
Fix the error path to clear port->port_dev, and bail out of
serial_core_unregister_port() when port_dev is NULL. Read
port->port_dev under port_mutex, like all of its writers.
Fixes: 84a9582fd2 ("serial: core: Start managing serial controllers to enable runtime PM")
Assisted-by: LLM
Signed-off-by: Cui GaoSheng <cuigaosheng1@huawei.com>
Link: https://patch.msgid.link/20260929023155.3259567-1-cuigaosheng1@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
