summaryrefslogtreecommitdiff
path: root/drivers/tty/serial
AgeCommit message (Collapse)Author
10 daysMerge tag 'tty-7.2-rc1' of ↵Linus Torvalds
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.2-rc1. Overall we end up removing more code than added, due to an obsolete synclink_gt driver being removed from the tree, always a nice thing to see happen. Other than that driver removal, major things included in here are: - max310x serial driver updates and fixes - 8250 driver updates and rework in places to make it more "modern" - dts file updates - serial driver core tweaks and updates - vt code cleanups - vc_screen crash fixes - other minor driver updates and cleanups All of these have been in linux-next for well over a week with no reported issues" * tag 'tty-7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (49 commits) serial: 8250_pci: Don't specify conflicting values to pci_device_id members vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write serial: qcom_geni: Fix RX DMA stall when SE_DMA_RX_LEN_IN is zero vt: merge ucs_is_zero_width()/ucs_is_double_width() into ucs_get_width() serial: 8250: fix possible ISR soft lockup dt-bindings: serial: rs485: remove deprecated .txt binding stub serial: qcom-geni: trace: Add tracepoint support for Qualcomm GENI serial tty: serial: Use named initializers for arrays of i2c_device_data serial: 8250_dw: remove clock-notifier infrastructure serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails amba/serial: amba-pl011: Bring back zx29 UART support serial: 8250: Add support for console flow control serial: 8250: Check LSR timeout on console flow control serial: 8250: Set cons_flow on port registration tty: serial: 8250: protect against NULL uart->port.dev in register arm64: dts: add support for A9 based Amlogic BY401 dt-bindings: arm: amlogic: add A311Y3 support serial: max310x: fix compile errors if CONFIG_SPI_MASTER is disabled serial: qcom-geni: Avoid probing debug console UART without console support serial: max310x: add comments for PLL limits ...
2026-06-15Merge tag 'driver-core-7.2-rc1' of ↵Linus Torvalds
gitolite.kernel.org:pub/scm/linux/kernel/git/driver-core/driver-core Pull driver core updates from Danilo Krummrich: "Deferred probe: - Fix race where deferred probe timeout work could be permanently canceled by using mod_delayed_work() - Fix missing jiffies conversion in deferred_probe_extend_timeout() - Guard timeout extension with delayed_work_pending() to prevent premature firing - Use system_percpu_wq instead of the deprecated system_wq - Update deferred_probe_timeout documentation device: - Replace direct struct device bitfield access (can_match, dma_iommu, dma_skip_sync, dma_ops_bypass, state_synced, dma_coherent, of_node_reused, offline, offline_disabled) with flag-based accessors using bit operations - Reject devices with unregistered buses - Delete unused DEVICE_ATTR_PREALLOC() - Add low-level device attribute macros with const show/store callbacks, allowing device attributes to reside in read-only memory - Move core device attributes to read-only memory - Constify group array pointers in driver_add_groups() / driver_remove_groups(), struct bus_type, and struct device_driver device property: - Fix fwnode reference leak in fwnode_graph_get_endpoint_by_id() - Initialize all fields of fwnode_handle in fwnode_init() - Provide swnode_get()/swnode_put() wrappers around kobject_get/put() - Allow passing struct software_node_ref_args pointers directly to PROPERTY_ENTRY_REF() driver_override: - Migrate amba, cdx, vmbus, and rpmsg to the generic driver_override infrastructure, fixing a UAF from unsynchronized access to driver_override in bus match() callbacks - Remove the now-unused driver_set_override() firmware loader: - Fix recursive lock deadlock in device_cache_fw_images() when async work falls back to synchronous execution - Fix device reference leak in firmware_upload_register() platform: - Pass KBUILD_MODNAME through the platform driver registration macro to create module symlinks in sysfs for built-in drivers; move module_kset initialization to a pure_initcall and tegra cbb registration to core_initcall to ensure correct ordering - Pass THIS_MODULE implicitly through a coresight_init_driver() macro sysfs: - Upgrade OOB write detection in sysfs_kf_seq_show() from printk to WARN - Add return value clamping to sysfs_kf_read() Rust: - ACPI: Fix missing match data for PRP0001 by exporting acpi_of_match_device() - Auxiliary: Replace drvdata() with dedicated registration data on auxiliary_device. drvdata() exposed the driver's bus device private data beyond the driver's own scope, creating ordering constraints and forcing the data to outlive all registrations that access it. Registration data is instead scoped structurally to the Registration object, making lifecycle ordering enforced by construction rather than convention. - Rust-native device driver lifetimes (HRT): Allow Rust device drivers to carry a lifetime parameter on their bus device private data, tied to the device binding scope -- the interval during which a bus device is bound to a driver. Device resources like pci::Bar<'a> and IoMem<'a> can be stored directly in the driver's bus device private data with a lifetime bounded by the binding scope, so the compiler enforces at build time that they do not outlive the binding. This removes Devres indirection from every access site and eliminates try_access() failure paths in destructors. Bus driver traits use a Generic Associated Type (GAT) Data<'bound> to introduce the lifetime on the private data, rather than parameterizing the Driver trait itself. Auxiliary registration data, where the lifetime is not introduced by a trait callback but must be threaded through Registration, uses the ForLt trait (a type-level abstraction for types generic over a lifetime). Misc: - Fix DT overlayed devices not probing by reverting the broken treewide overlay fix and re-running fw_devlink consumer pickup when an overlay is applied to a bound device - Use root_device_register() for faux bus root device; add sanity check for failed bus init - Fix dev_has_sync_state() data race with READ_ONCE() and move it to base.h - Avoid spurious device_links warning when removing a device while its supplier is unbinding - Switch ISA bus to dynamic root device - Fix suspicious RCU usage in kernfs_put() - Remove devcoredump exit callback - Constify devfreq_event_class" * tag 'driver-core-7.2-rc1' of gitolite.kernel.org:pub/scm/linux/kernel/git/driver-core/driver-core: (81 commits) software node: allow passing reference args to PROPERTY_ENTRY_REF() driver core: platform: set mod_name in driver registration coresight: pass THIS_MODULE implicitly through a macro kernel: param: initialize module_kset in a pure_initcall soc/tegra: cbb: Move driver registration from pure_initcall to core_initcall firmware_loader: Fix recursive lock in device_cache_fw_images() driver core: Use system_percpu_wq instead of system_wq driver core: remove driver_set_override() rpmsg: use generic driver_override infrastructure Drivers: hv: vmbus: use generic driver_override infrastructure cdx: use generic driver_override infrastructure amba: use generic driver_override infrastructure rust: devres: add 'static bound to Devres<T> samples: rust: rust_driver_auxiliary: showcase lifetime-bound registration data rust: auxiliary: generalize Registration over ForLt rust: types: add `ForLt` trait for higher-ranked lifetime support gpu: nova-core: separate driver type from driver data samples: rust: rust_driver_pci: use HRT lifetime for Bar rust: io: make IoMem and ExclusiveIoMem lifetime-parameterized rust: pci: make Bar lifetime-parameterized ...
2026-06-12serial: 8250_pci: Don't specify conflicting values to pci_device_id membersUwe Kleine-König (The Capable Hub)
The PCI_VDEVICE macro assigns 0 to .class and .class_mask to allow the next value in the initializer to define the value for .driver_data. So the construct { PCI_VDEVICE(INTASHIELD, 0x0D21), .class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, .class_mask = 0xffff00, .driver_data = pbn_b2_4_115200, }, introduced in commit 44e55f1f3088 ("serial: 8250_pci: Consistently define pci_device_ids using named initializers") has conflicting assignments. In only some configurations (i.e. W=1 for me) that makes the compiler unhappy. So convert the two affected items to PCI_DEVICE which doesn't have that hidden assigment to .class and .class_mask. Fixes: 44e55f1f3088 ("serial: 8250_pci: Consistently define pci_device_ids using named initializers") Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Closes: https://lore.kernel.org/linux-serial/ah_5qVKOf8LXG1Xo@ashevche-desk.local/T/#ma6eab90ca801b4292639f5c255a89b4033b33d21 Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260603095616.937968-2-u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-12serial: qcom_geni: Fix RX DMA stall when SE_DMA_RX_LEN_IN is zeroViken Dadhaniya
In qcom_geni_serial_handle_rx_dma(), geni_se_rx_dma_unprep() clears port->rx_dma_addr before SE_DMA_RX_LEN_IN is read. If the register is zero, for example when the RX stale counter fires on an idle line, the handler returns without calling geni_se_rx_dma_prep(). The next RX DMA interrupt then hits the !port->rx_dma_addr guard and returns immediately, so the RX DMA buffer is never rearmed and later input is lost. Keep the handler on the rearm path when rx_in is zero. Warn about the unexpected zero-length DMA completion, skip received-data handling, and always call geni_se_rx_dma_prep(). Fixes: 2aaa43c70778 ("tty: serial: qcom-geni-serial: add support for serial engine DMA") Cc: stable@vger.kernel.org Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Link: https://patch.msgid.link/20260528-serial-rx-0-byte-fix-v2-1-b4195cfe342f@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-01Merge tag 'v7.1-rc6' into tty-nextGreg Kroah-Hartman
We need the tty/serial fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: dz: Enable modular buildMaciej W. Rozycki
Enable modular build since the driver now has a proper module_exit() handler. There's nothing specific to DZ hardware to prevent driver unloading and reloading from working. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://patch.msgid.link/alpine.DEB.2.21.2605062331420.46195@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: zs: Convert to use a platform deviceMaciej W. Rozycki
Prevent a crash from happening as the first serial port is initialised: Console: switching to mono frame buffer device 160x64 fb0: PMAG-AA frame buffer device at tc0 DECstation Z85C30 serial driver version 0.10 CPU 0 Unable to handle kernel paging request at virtual address 0000002c, epc == 803ab00c, ra == 803aafe0 Oops[#1]: CPU: 0 PID: 1 Comm: swapper Not tainted 6.4.0-rc3-00031-g84a9582fd203-dirty #57 $ 0 : 00000000 10012c00 803aaeb0 00000000 $ 4 : 80e12f60 80e12f50 80e12f58 81000030 $ 8 : 00000000 805ff37c 00000000 33433538 $12 : 65732030 00000006 80c2915d 6c616972 $16 : 80e12f00 807b7630 00000000 00000000 $20 : 00000004 00000348 000001a0 807623b8 $24 : 00000018 00000000 $28 : 80c24000 80c25d60 8078b148 803aafe0 Hi : 00000000 Lo : 00000000 epc : 803ab00c serial_base_ctrl_add+0x78/0xf4 ra : 803aafe0 serial_base_ctrl_add+0x4c/0xf4 Status: 10012c03 KERNEL EXL IE Cause : 00000008 (ExcCode 02) BadVA : 0000002c PrId : 00000440 (R4400SC) Modules linked in: Process swapper (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=00000000) Stack : 80760000 00000cc0 00400044 00400040 803aa02c 80d61ab8 00000000 807b7630 80760000 807623b8 807b7628 803aa644 80386998 00000000 80e17780 80220f68 80e17780 80d61ab8 80c17d80 80e17780 80e17780 8063c798 80e17780 80383fa0 00000010 80e17780 00000000 80386998 807a0000 00000000 00400040 8038f848 807623b8 80d61ab8 00000004 80e17780 00000000 803a68e4 80c25e2c 803bb884 ... Call Trace: [<803ab00c>] serial_base_ctrl_add+0x78/0xf4 [<803aa644>] serial_core_register_port+0x174/0x69c [<8077e9ac>] zs_init+0xc8/0xfc [<800404d4>] do_one_initcall+0x40/0x2ac [<8076cecc>] kernel_init_freeable+0x1e4/0x270 [<80605bec>] kernel_init+0x20/0x108 [<800431e8>] ret_from_kernel_thread+0x14/0x1c Code: 2442aeb0 ae120024 ae0200d0 <8c67002c> 50e00001 8c670000 3c06806e 3c05806e afb30010 ---[ end trace 0000000000000000 ]--- (report at the offending commit) -- where a pointer is dereferenced that has been derived from a null pointer to the port's parent device. Since no device is available with legacy probing and it's not anymore a preferable way to discover devices anyway, switch the driver to using a platform device and use it as the port's parent device. Update resource handling accordingly and only request the actual span of addresses used within the slot, which will have had its resource already requested by generic platform device code. Use platform_driver_probe() not just because SCC devices are fixed with solder on board and not straightforward to remove, but foremost because the associated TTY's major device number is the same as used by the dz driver and the first driver to claim it will prevent the other one from using it. Either one DZ device or some SCC devices will be present in a given system but never both at a time, and therefore we want the major device number to be claimed by the first driver to actually successfully bind to its device and platform_driver_probe() is a way to fulfil that. An unfortunate consequence of the switch to a platform device is we now hand the console over from the bootconsole much later in the bootstrap. The firmware console handler appears good enough though to work so late and in particular with interrupts enabled. Since there is one way only remaining to reach zs_reset() now, remove the port initialisation marker as no longer needed and go through the channel reset unconditionally. Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM") Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Cc: stable@vger.kernel.org # needs to use .remove_new for <= 6.10 Link: https://patch.msgid.link/alpine.DEB.2.21.2605062328480.46195@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: dz: Convert to use a platform deviceMaciej W. Rozycki
Prevent a crash from happening as the first serial port is initialised: Console: switching to colour frame buffer device 160x64 tgafb: SFB+ detected, rev=0x02 fb0: Digital ZLX-E1 frame buffer device at 0x1e000000 DECstation DZ serial driver version 1.04 CPU 0 Unable to handle kernel paging request at virtual address 000000bc, epc == 8048b3a4, ra == 80470a78 Oops[#1]: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0-dirty #35 NONE $ 0 : 00000000 1000ac00 00000004 804707ac $ 4 : 00000000 80e20850 80e20858 81000030 $ 8 : 00000000 8072c81c 00000008 fefefeff $12 : 6c616972 00000006 80c5917f 69726420 $16 : 80e20800 00000000 808f8968 80e20800 $20 : 00000000 807f5a90 808b0094 808d3bc8 $24 : 00000018 80479030 $28 : 80c2e000 80c2fd70 00000069 80470a78 Hi : 00000004 Lo : 00000000 epc : 8048b3a4 __dev_fwnode+0x0/0xc ra : 80470a78 serial_base_ctrl_add+0xa0/0x168 Status: 1000ac04 IEp Cause : 30000008 (ExcCode 02) BadVA : 000000bc PrId : 00000220 (R3000) Modules linked in: Process swapper/0 (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=00000000) Stack : 00400044 00400040 8046f4cc 00000000 808a6148 808a0000 808f8968 8086983c 808e0000 8046fc84 1000ac01 00000028 80e20700 802ba3f8 80e20700 80d34a94 80c1b900 80e20700 80e20700 80e20700 80e20700 80444650 00000000 00000000 00000000 807f5a90 808b0094 80447080 00400040 808e0000 80d34a94 808a6148 80d34a94 00000004 80e20700 00000000 8076974c 80469810 80c2fe3c 1000ac01 ... Call Trace: [<8048b3a4>] __dev_fwnode+0x0/0xc [<80470a78>] serial_base_ctrl_add+0xa0/0x168 [<8046fc84>] serial_core_register_port+0x1c8/0x974 [<808c6af0>] dz_init+0x74/0xc8 [<800470e0>] do_one_initcall+0x44/0x2d4 [<808b111c>] kernel_init_freeable+0x258/0x308 [<8072e434>] kernel_init+0x20/0x114 [<80049cd0>] ret_from_kernel_thread+0x14/0x1c Code: 27bd0018 03e00008 2402ffea <8c8200bc> 03e00008 00000000 27bdffc0 afbe0038 afb30024 ---[ end trace 0000000000000000 ]--- -- where a pointer is dereferenced that has been derived from a null pointer to the port's parent device. Since no device is available with legacy probing and it's not anymore a preferable way to discover devices anyway, switch the driver to using a platform device and use it as the port's parent device. Update resource handling accordingly and only request the actual span of addresses used within the slot, which will have had its resource already requested by generic platform device code. Use platform_driver_probe() not just because the DZ device is fixed with solder on board and not straightforward to remove, but foremost because the associated TTY's major device number is the same as used by the zs driver and the first driver to claim it will prevent the other one from using it. Either one DZ device or some SCC devices will be present in a given system but never both at a time, and therefore we want the major device number to be claimed by the first driver to actually successfully bind to its device and platform_driver_probe() is a way to fulfil that. An unfortunate consequence of the switch to a platform device is we now hand the console over from the bootconsole much later in the bootstrap. The firmware console handler appears good enough though to work so late and in particular with interrupts enabled. Conversely only starting the console port so late lets the reset code fully utilise our delay handlers, so switch from udelay() to fsleep() for transmitter draining so as to avoid busy-waiting for an excessive amount of time. Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM") Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Cc: stable@vger.kernel.org # needs to use .remove_new for <= 6.10 Link: https://patch.msgid.link/alpine.DEB.2.21.2605062326540.46195@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: zs: Switch to using channel resetMaciej W. Rozycki
Switch the driver to using the channel reset rather than hardware reset, simplifying handling by removing an interference between channels that causes the other channel to become uninitialised afterwards. There is little difference between the two kinds of reset in terms of register settings that result, and we initialise the whole register set right away anyway. However this prevents a hang from happening should the console output handler in the firmware try to access the other port whose transmitter has been disabled and line parameters messed up. For example this will happen if the keyboard port (port A) is chosen for the system console, unusually but not insanely for a headless system, as the port is wired to a standard DA-15 connector and an adapter can be easily made. Or with the next change in place this would happen for the regular console port (port B), since the keyboard port (port A) will be initialised first. Just remove the unnecessary complication then, a channel reset is good enough. We still need the initialisation marker, now per channel rather than per SCC, as for the console port zs_reset() will be called twice: once early on via zs_serial_console_init() for the console setup only, and then again via zs_config_port() as the port is associated with a TTY device. Fixes: 8b4a40809e53 ("zs: move to the serial subsystem") Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Cc: stable@vger.kernel.org # v2.6.23+ Link: https://patch.msgid.link/alpine.DEB.2.21.2605062323430.46195@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: zs: Fix bootconsole handover lockupMaciej W. Rozycki
Calling zs_reset() in the course of setting up the serial device causes line parameters to be reset and the transmitter disabled. We've been lucky in that no message is usually produced to the kernel log between this call and the later call to uart_set_options() in the course of console setup done by zs_serial_console_init(), or the system would hang as the console output handler in the firmware tried to access a port the transmitter of which has been disabled and line parameters messed up. This will change with the next change to the driver, so fix zs_reset() such that line parameters are set for 9600n8 console operation as with the system firmware and the transmitter re-enabled after reset. This also means zs_pm() serves no purpose anymore, so drop it. Fixes: 8b4a40809e53 ("zs: move to the serial subsystem") Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Cc: stable@vger.kernel.org # v2.6.23+ Link: https://patch.msgid.link/alpine.DEB.2.21.2605062308040.46195@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: dz: Fix bootconsole handover lockupMaciej W. Rozycki
Calling dz_reset() in the course of setting up the serial device causes line parameters to be reset and the transmitter disabled. We've been lucky in that no message is usually produced to the kernel log between this call and the later call to uart_set_options() in the course of console setup done by dz_serial_console_init(), or the system would hang as the console output handler in the firmware tried to access a port the transmitter of which has been disabled and line parameters messed up. This will change with the next change to the driver, so fix dz_reset() such that line parameters are set for 9600n8 console operation as with the system firmware and the transmitter re-enabled after reset. This also means dz_pm() serves no purpose anymore, so drop it. Fixes: e6ee512f5a77 ("dz.c: Resource management") Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Cc: stable@vger.kernel.org # v2.6.25+ Link: https://patch.msgid.link/alpine.DEB.2.21.2605062302010.46195@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: dz: Fix bootconsole message clobbering at chip resetMaciej W. Rozycki
In the DZ interface as implemented by the DC7085 gate array the serial transmitters are double buffered, meaning that at the time a transmitter is ready to accept the next character there is one in the transmit shift register still being sent to the line. Issuing a master clear at this time causes this character to be lost, so wait an extra amount of time sufficient for the transmit shift register to drain at 9600bps, which is the baud rate setting used by the firmware console. Mind the specified 1.4us TRDY recovery time in the course and continue using iob() as the completion barrier, since the platforms involved use a write buffer that can delay and combine writes, and reorder them with respect to reads regardless of the MMIO locations accessed and we still lack a platform-independent handler for that. When called from dz_serial_console_init() this is too early for fsleep() to work and even before lpj has been calculated and therefore the delay is actually not sufficient for the transmitter to drain and is merely a placeholder now. This will be addressed in a follow-up change. Fixes: e6ee512f5a77 ("dz.c: Resource management") Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Cc: stable@vger.kernel.org # v2.6.25+ Link: https://patch.msgid.link/alpine.DEB.2.21.2605062259080.46195@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: 8250_dw: dispatch SysRq character in dw8250_handle_irq()Jacques Nilo
dw8250_handle_irq() calls serial8250_handle_irq_locked() with the port lock held via guard(uart_port_lock_irqsave). The guard destructor is plain uart_port_unlock_irqrestore(), so a SysRq character captured into port->sysrq_ch by uart_prepare_sysrq_char() is dropped without ever being dispatched to handle_sysrq(). This is the same regression pattern as in serial8250_handle_irq(), introduced when 883c5a2bc934 ("serial: 8250_dw: Rework dw8250_handle_irq() locking and IIR handling") moved the function to the guard()-based locking scheme without using the sysrq-aware unlock helper. Switch to guard(uart_port_lock_check_sysrq_irqsave) so that captured sysrq_ch is dispatched on scope exit, matching the fix in serial8250_handle_irq(). Fixes: 883c5a2bc934 ("serial: 8250_dw: Rework dw8250_handle_irq() locking and IIR handling") Cc: stable@vger.kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Jacques Nilo <jnilo@free.fr> Link: https://patch.msgid.link/ed56fcaf4af24e4ed011a7bce206e0182acb761c.1778675349.git.jnilo@free.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: 8250: dispatch SysRq character in serial8250_handle_irq()Jacques Nilo
serial8250_handle_irq() captures a SysRq character into port->sysrq_ch inside serial8250_handle_irq_locked() via uart_prepare_sysrq_char() (reached from serial8250_read_char()). Dispatch of that captured character to handle_sysrq() is expected to happen at port-unlock time, through uart_unlock_and_check_sysrq[_irqrestore](). After commit 8324a54f604d ("serial: 8250: Add serial8250_handle_irq_locked()") the function was reduced to a wrapper that takes the port lock via guard(uart_port_lock_irqsave) whose destructor is plain uart_port_unlock_irqrestore(). The sysrq-aware unlock helper is no longer called, so port->sysrq_ch is captured but never dispatched: BREAK + SysRq key is consumed silently. This was the very condition Johan Hovold's 853a9ae29e978 ("serial: 8250: fix handle_irq locking", 2021) introduced uart_unlock_and_check_sysrq_irqrestore() to address. Switch to the new guard(uart_port_lock_check_sysrq_irqsave), whose destructor is the sysrq-aware unlock helper, restoring the pre-split behaviour. Update the Context: comment on serial8250_handle_irq_locked() so future HW-specific 8250 wrappers know to use the same guard or the explicit sysrq-aware unlock. Verified on RTL8196E with CONFIG_MAGIC_SYSRQ_SERIAL=y: BREAK + 'h' on the console UART produces the SysRq help dump in dmesg and the brk counter in /proc/tty/driver/serial increments correctly. Fixes: 8324a54f604d ("serial: 8250: Add serial8250_handle_irq_locked()") Cc: stable@vger.kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Jacques Nilo <jnilo@free.fr> Link: https://patch.msgid.link/52692ae6c3501f7940347cef364ad7fcacaab7e5.1778675349.git.jnilo@free.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22tty: serial: samsung: Remove redundant port lock acquisition in rx helpersTudor Ambarus
Sashiko identified a deadlock when the console flow is engaged [1]. When console flow control is enabled (UPF_CONS_FLOW), s3c24xx_serial_stop_tx() calls s3c24xx_serial_rx_enable() and s3c24xx_serial_start_tx() calls s3c24xx_serial_rx_disable(). The serial core framework invokes the .stop_tx() and .start_tx() callbacks with the port->lock spinlock already held. Furthermore, all internal driver paths that invoke stop_tx (such as the DMA TX completion handler s3c24xx_serial_tx_dma_complete() or the PIO TX IRQ handler s3c24xx_serial_tx_irq()) also acquire port->lock prior to calling it. (Note that s3c24xx_serial_start_tx() is only invoked by the serial core). However, s3c24xx_serial_rx_enable() and s3c24xx_serial_rx_disable() unconditionally attempt to acquire port->lock again using uart_port_lock_irqsave(). Since spinlocks are not recursive, this causes a deadlock on the same CPU when console flow control is engaged. Remove the redundant lock acquisition from both rx helper functions. Cc: stable <stable@kernel.org> Fixes: b497549a035c ("[ARM] S3C24XX: Split serial driver into core and per-cpu drivers") Reported-by: John Ogness <john.ogness@linutronix.de> Closes: https://sashiko.dev/#/patchset/20260506121606.5805-1-john.ogness%40linutronix.de [1] Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://patch.msgid.link/20260515-samsung-tty-flow-control-deadlock-v1-1-93255edbc9bc@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: altera_jtaguart: handle uart_add_one_port() failuresMyeonghun Pak
altera_jtaguart_probe() maps the register window before registering the UART port, but it ignores failures from uart_add_one_port(). If port registration fails, probe still returns success and the mapping remains live until a later remove path that is not part of probe failure cleanup. Return the uart_add_one_port() error and unmap the register window on that failure path. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 5bcd601049c6 ("serial: Add driver for the Altera JTAG UART") Cc: stable <stable@kernel.org> Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Link: https://patch.msgid.link/20260512065837.79528-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: 8250: fix possible ISR soft lockupMarco Felsch
There are rare cases in which the host gets stuck in the ISR because it is flooded with messages during the startup phase. The reason for the soft lockup in the ISR is the missing FIFO error IRQ (FIFOE) handling. Not handling it and reporting IRQ_HANDLED triggers the IRQ immediately again. Fix this by adding a check for the FIFOE status and clearing the FIFO if no data is ready (DR). This behavior was observed on an AM62L device which uses the OMAP 8250 driver. Fix it for all 8250 drivers, since the OMAP driver's special IRQ setup handling may trigger this behavior more frequently, but it is not ensured that other 8250 drivers aren't affected. Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Link: https://patch.msgid.link/20260519-v7-1-topic-serial-8250-v1-1-56b04293a246@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22dt-bindings: serial: rs485: remove deprecated .txt binding stubAkash Sukhavasi
The plain text binding file was superseded by the YAML schema in commit d50f974c4f7f ("dt-bindings: serial: Convert rs485 bindings to json-schema"). The file now contains only a redirect notice. Remove it, and update references in serial_core.c and serial-rs485.rst to point to the YAML schema. Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260521162137.6325-1-akash.sukhavasi@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22tty: serial: Use named initializers for arrays of i2c_device_dataUwe Kleine-König (The Capable Hub)
While being less compact, using named initializers allows to more easily see which members of the structs are assigned which value without having to lookup the declaration of the struct. And it's also more robust against changes to the struct definition. The mentioned robustness is relevant for a planned change to struct i2c_device_id that replaces .driver_data by an anonymous union. While touching all these arrays, unify usage of whitespace in the list terminator. This patch doesn't modify the compiled arrays, only their representation in source form benefits. The former was confirmed with x86 and arm64 builds. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/20260518101456.632410-2-u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: 8250_dw: remove clock-notifier infrastructureStepan Ionichev
The clock notifier and matching work_struct in dw8250_data were added in 2020 for the Baikal-T1 SoC, whose multiple UART ports share a single reference clock and need to be informed when another consumer re-rates that clock. Baikal SoC support has since been removed from the kernel (see e.g. commit 5d6c477687ae ("clk: baikal-t1: Remove not-going-to-be-supported code for Baikal SoC") and the matching removals across bus/, mtd/, PCI/, hwmon/, memory/). No remaining in-tree user needs the cross-device baudclk rate-change notification path: the only configuration that wired up the notifier was Baikal-T1's shared reference clock topology. Drop the now-unused clock-notifier and its deferred-update worker: - struct dw8250_data fields clk_notifier and clk_work, - the clk_to_dw8250_data() and work_to_dw8250_data() helpers, - the dw8250_clk_work_cb() and dw8250_clk_notifier_cb() callbacks, - the INIT_WORK / notifier_call setup in dw8250_probe(), - the clk_notifier_register() / queue_work() in dw8250_probe(), - the matching clk_notifier_unregister() / flush_work() in dw8250_remove(), - the stale comment in dw8250_set_termios() about the worker blocking, - the linux/notifier.h and linux/workqueue.h includes that are no longer used. dw8250_set_termios() keeps calling clk_set_rate() directly, which is all the remaining single-UART configurations require. Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260514143746.23671-3-sozdayvek@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: 8250_dw: unregister 8250 port if clk_notifier_register() failsStepan Ionichev
dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path. Fixes: cc816969d7b5 ("serial: 8250_dw: Fix common clocks usage race condition") Cc: stable@vger.kernel.org Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260514143746.23671-2-sozdayvek@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22amba/serial: amba-pl011: Bring back zx29 UART supportStefan Dösinger
This is based on code removed in commit 89d4f98ae90d ("ARM: remove zte zx platform"). I did not bring back the zx29-uart .compatible as the arm,primecell-periphid does the job. Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com> Link: https://patch.msgid.link/20260514-zx29uart-v1-2-68470ecc3977@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: 8250: Add support for console flow controlJohn Ogness
The kernel documentation specifies that the console option 'r' can be used to enable hardware flow control for console writes. The 8250 driver does include code for hardware flow control on the console if cons_flow is set, but there is no code path that actually sets this. However, that is not the only issue. The problems are: 1. Specifying the console option 'r' does not lead to cons_flow being set. 2. Even if cons_flow would be set, serial8250_register_8250_port() clears it. 3. When the console option 'r' is specified, uart_set_options() attempts to initialize the port for CRTSCTS. However, afterwards it does not set the UPSTAT_CTS_ENABLE status bit and therefore on boot, uart_cts_enabled() is always false. This policy bit is important for console drivers as a criteria if they may poll CTS. 4. Even though uart_set_options() attempts to initialize the port for CRTSCTS, the 8250 set_termios() callback does not enable the RTS signal (TIOCM_RTS) and thus the hardware is not properly initialized for CTS polling. 5. Even if modem control was properly setup for CTS polling (TIOCM_RTS), uart_configure_port() clears TIOCM_RTS, thus breaking CTS polling. 6. wait_for_xmitr() and serial8250_console_write() use cons_flow to decide if CTS polling should occur. However, the condition should also include a check that it is not in RS485 mode and CRTSCTS is actually enabled in the hardware. Address all these issues as conservatively as possible by gating them behind checks focussed on the user specifying console hardware flow control support and the hardware being configured for CTS polling at the time of the write to the UART. Since checking the UPSTAT_CTS_ENABLE status bit is a part of the new condition gate, these changes also support runtime termios updates to disable/enable CRTSCTS. Signed-off-by: John Ogness <john.ogness@linutronix.de> Link: https://patch.msgid.link/20260511152706.151498-4-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: 8250: Check LSR timeout on console flow controlJohn Ogness
wait_for_xmitr() calls wait_for_lsr() to wait for the transmission registers to be empty. wait_for_lsr() can timeout after a reasonable amount of time. When console flow control is active, wait_for_xmitr() additionally polls CTS, waiting for the peer to signal that it is ready to receive more data. If hardware flow control is enabled (auto CTS) and the peer deasserts CTS, wait_for_lsr() will timeout. If additionally console flow control is active and while polling CTS the peer asserts CTS, the console will assume it can immediately transmit, even though the transmission registers may not be empty. This can lead to data loss. Avoid this problem by performing an extra wait_for_lsr() upon CTS assertion if wait_for_lsr() previously timed out. Signed-off-by: John Ogness <john.ogness@linutronix.de> Link: https://patch.msgid.link/20260511152706.151498-3-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: 8250: Set cons_flow on port registrationJohn Ogness
Since console flow control policy is no longer part of uart_port.flags, explicitly set the policy for the port. Signed-off-by: John Ogness <john.ogness@linutronix.de> Link: https://patch.msgid.link/20260511152706.151498-2-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22tty: serial: 8250: protect against NULL uart->port.dev in registerStepan Ionichev
serial8250_register_8250_port() conditionally copies uart->port.dev from up->port.dev only when up->port.dev is non-NULL: if (up->port.dev) { uart->port.dev = up->port.dev; ... } So if both the existing uart slot and up have a NULL ->dev, uart->port.dev remains NULL. The very next ACPI companion check then dereferences it unconditionally: if (!has_acpi_companion(uart->port.dev)) { has_acpi_companion() reads dev->fwnode without a NULL guard (include/linux/acpi.h), so this NULL-derefs the kernel for the remaining no-dev case rather than just skipping the mctrl_gpio_init() initialisation as intended. smatch flags the inconsistency: drivers/tty/serial/8250/8250_core.c:767 serial8250_register_8250_port() error: 'uart->port.dev' could be null (see line 719) Guard the call with a NULL check so register continues to work for callers that legitimately have no parent device (legacy non-OF/non-ACPI registrations). No functional change for callers that pass a non-NULL ->dev. Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com> Link: https://patch.msgid.link/20260508181237.11146-1-sozdayvek@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-22serial: max310x: fix compile errors if CONFIG_SPI_MASTER is disabledHugo Villeneuve
Since commit 20ffe4b3330a8 ("serial: max310x: allow driver to be built with SPI or I2C"), if I2C is enabled and SPI_MASTER is disabled, we have these compile errors: drivers/tty/serial/max310x.c: In function 'max310x_uart_init': drivers/tty/serial/max310x.c: error: 'max310x_spi_driver' undeclared... drivers/tty/serial/max310x.c: In function ‘max310x_uart_init’: drivers/tty/serial/max310x.c: error: label ‘err_spi_register’ defined but not used... drivers/tty/serial/max310x.c: error: ‘regcfg’ defined but not used Fix by properly encapsulating i2c/spi code/variables in their respective context with IS_ENABLED() macros for CONFIG_I2C and CONFIG_SPI_MASTER. Also fix link failure with SERIAL_MAX310X=y and I2C=m by modifying Kconfig depends. Fixes: 20ffe4b3330a8 ("serial: max310x: allow driver to be built with SPI or I2C") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605121847.N9DVLNg2-lkp@intel.com/ Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260521153333.2336642-1-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: qcom-geni: Avoid probing debug console UART without console supportAniket Randive
When CONFIG_SERIAL_QCOM_GENI_CONSOLE is disabled, the driver still advertises the debug UART compatible strings ("qcom,geni-debug-uart" and "qcom,sa8255p-geni-debug-uart") in its of_match table. This lets the driver match and probe console UART DT nodes even though console support is not built. As a result, the console port is never registered with the UART core and uart_add_one_port() fails with -EINVAL. Fix this by only including the debug UART compatible entries in the match table when CONFIG_SERIAL_QCOM_GENI_CONSOLE is enabled, preventing the driver from probing console UART nodes when console support is absent. Reviewed-by: Praveen Talari <praveen.talari@oss.qualcomm.com> Signed-off-by: Aniket Randive <aniket.randive@oss.qualcomm.com> Link: https://patch.msgid.link/20260504101045.1084672-1-aniket.randive@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: max310x: add comments for PLL limitsHugo Villeneuve
Add comments to help clarify the provenance of the various hardcoded values used in computing the ref clk. Assisted-by: Gemini:Pro Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260417-max310x-2-v1-10-b424e105ecac@dimonoff.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: max310x: move variables to while() scopeHugo Villeneuve
txlen, to_send and tail variables are only used within the while() loop. Move them to that scope to keep them closer to their usage and improve readability. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260417-max310x-2-v1-9-b424e105ecac@dimonoff.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: max310x: allow driver to be built with SPI or I2CHugo Villeneuve
If SPI is disabled, the max310x driver cannot be selected. Allow driver to be selected if either I2C or SPI is set. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260417-max310x-2-v1-8-b424e105ecac@dimonoff.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: max310x: use FIELD_PREP macro to set PLL bitfieldsHugo Villeneuve
Use FIELD_PREP macros to improve code readability. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260417-max310x-2-v1-7-b424e105ecac@dimonoff.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: max310x: use regmap_read_poll_timeout() for busy waitHugo Villeneuve
Simplify busy wait stages by using regmap_read_poll_timeout(). Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260417-max310x-2-v1-6-b424e105ecac@dimonoff.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: max310x: improve max310x_set_ref_clk() efficiencyHugo Villeneuve
The same basic code is duplicated for each of the four PLL multiplier values, so simplify and streamline it. Doing so allows us to avoid some unnecessary (fdiv * factor) multiplications for some fdiv values and replace the second "if" statement with an "else if" and avoid a useless comparison. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260417-max310x-2-v1-5-b424e105ecac@dimonoff.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: max310x: update baudrate comments for err calculationHugo Villeneuve
The baudrate used to compute the best error was changed from 115200 to 460800 in commit 35240ba26a93 ("tty: max310x: Fix invalid baudrate divisors calculator"), but the comment was not updated, so fix it. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260417-max310x-2-v1-4-b424e105ecac@dimonoff.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: max310x: change return type of max310x_set_ref_clk()Hugo Villeneuve
Having max310x_set_ref_clk() return an s32 as both an error code and a frequency value is ambiguous. Fix by passing a pointer to the frequency value that will then be updated, and simply return a status. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260417-max310x-2-v1-3-b424e105ecac@dimonoff.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: max310x: simplify max310x_update_best_err()Hugo Villeneuve
besterr was defined as a signed type was to make sure that the first call to max310x_update_best_err() would always set besterr. Also there is no need for it to be a long. By changing its type to unsigned int and initial value to UINT_MAX, max310x_update_best_err() can be simplified and be more efficient while achieving the same initial result. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260417-max310x-2-v1-2-b424e105ecac@dimonoff.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: max310x: uniformize clock/freq typesHugo Villeneuve
max310x_set_ref_clk() returns a 32-bits clock value, so there is no need to have parameters and intermediate values defined as long. Change clock and freq types to int. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260417-max310x-2-v1-1-b424e105ecac@dimonoff.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: core: prevent division by zero by always returning non-zero baud rateHugo Villeneuve
If a device has a minimum baud rate > 9600 bauds, and a new termios baud rate of 0 (hang up) is requested, uart_get_baud_rate() will return 0. Most drivers do not check this return value and call uart_update_timeout() with this zero baud rate, which will trigger a "Division by zero in kernel" fault: stty -F /dev/ttySC0 0 Division by zero in kernel. ... Fix by returning the larger of 9600 or min for the B0 case. This now ensures that a non-zero baud rate is returned, and greatly simplifies the code. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260410152022.2146488-6-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: core: simplify clipping logic in uart_get_baud_rate()Hugo Villeneuve
Simplify the clipping logic in uart_get_baud_rate() to improve code readability. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260410152022.2146488-5-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: core: update uart_get_baud_rate() obsolete commentsHugo Villeneuve
Update obsolete comments to match the actual code. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260410152022.2146488-4-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: apbuart: remove check for zero baud rate from uart_get_baud_rate()Hugo Villeneuve
The minimum baud rate supported by this driver is 0, so even for the B0 case, uart_get_baud_rate() will return 9600, not zero. This check predates commit 16ae2a877bf4 ("serial: Fix crash if the minimum rate of the device is > 9600 baud") and is no longer necessary so remove it. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260410152022.2146488-3-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: icom: remove check for zero baud rate from uart_get_baud_rate()Hugo Villeneuve
The minimum baud rate supported by this driver is 300, so even for the B0 case, uart_get_baud_rate() will return 9600, not zero. This check predates commit 16ae2a877bf4 ("serial: Fix crash if the minimum rate of the device is > 9600 baud") and is no longer necessary so remove it. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://patch.msgid.link/20260410152022.2146488-2-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQViken Dadhaniya
When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush. Fixes: 2aaa43c70778 ("tty: serial: qcom-geni-serial: add support for serial engine DMA") Cc: stable <stable@kernel.org> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260506-serial-dma-stale-tx-buf-v1-1-e3ccb360d719@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: fsl_lpuart: fix rx buffer and DMA map leaks in start_rx_dmaShitalkumar Gandhi
lpuart_start_rx_dma() allocates sport->rx_ring.buf with kzalloc() and then maps a scatterlist via dma_map_sg(). On three subsequent error paths the function returns directly without releasing those resources: - when dma_map_sg() returns 0 (-EINVAL): ring->buf is leaked. - when dmaengine_slave_config() fails: ring->buf and the DMA mapping are leaked. - when dmaengine_prep_dma_cyclic() returns NULL: ring->buf and the DMA mapping are leaked. The sole cleanup path, lpuart_dma_rx_free(), is only reached when lpuart_dma_rx_use is set, and the caller lpuart_rx_dma_startup() clears that flag on failure of lpuart_start_rx_dma(). So these resources are permanently leaked on every failure in this function. Repeated port open/close or termios changes under error conditions will slowly consume memory and leave stale streaming DMA mappings behind. Fix it by introducing two error labels that unmap the scatterlist and free the ring buffer as appropriate. While here, replace the misleading -EFAULT (bad userspace pointer) returned when dmaengine_prep_dma_cyclic() fails with the more accurate -ENOMEM, matching how other dmaengine users in the tree treat this failure. No functional change on the success path. Fixes: 5887ad43ee02 ("tty: serial: fsl_lpuart: Use cyclic DMA for Rx") Cc: stable <stable@kernel.org> Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260420135903.2062024-1-shitalkumar.gandhi@cambiumnetworks.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: qcom-geni: fix UART_RX_PAR_EN bit positionPrasanna S
UART_RX_PAR_EN is incorrectly defined as bit 3, which triggers false framing errors (S_GP_IRQ_1_EN) and causes received data to be dropped when parity is enabled and the parity bit is 0. Define UART_RX_PAR_EN as bit 4 of the SE_UART_RX_TRANS_CFG register, as specified in the reference manual. Fixes: c4f528795d1a ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP") Cc: stable <stable@kernel.org> Signed-off-by: Prasanna S <prasanna.s@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260428-serial-bit-correct-v1-1-9131ad5b97d8@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: sh-sci: fix memory region release in error pathHongling Zeng
The sci_request_port() function uses request_mem_region() to reserve I/O memory, but in the error path when sci_remap_port() fails, it incorrectly calls release_resource() instead of release_mem_region(). This mismatch can cause resource accounting issues. Fix it by using the correct release function, consistent with sci_release_port(). Fixes: e2651647080930a1 ("serial: sh-sci: Handle port memory region reservations.") Cc: stable <stable@kernel.org> Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/r/202604032356.SzEjYkBC-lkp@intel.com/ Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260421065737.724187-1-zenghongling@kylinos.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11tty: serial: pch_uart: add check for dma_alloc_coherent()Zhaoyang Yu
Add a check for dma_alloc_coherent() failure to prevent a potential NULL pointer dereference in dma_handle_rx(). Properly release DMA channels and the PCI device reference using a goto ladder if the allocation fails. Fixes: 3c6a483275f4 ("Serial: EG20T: add PCH_UART driver") Cc: stable <stable@kernel.org> Signed-off-by: Zhaoyang Yu <2426767509@qq.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/tencent_E328416B7CFD436F6029F2DF02AD7ED89C08@qq.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: zs: Fix swapped RI/DSR modem line transition countingMaciej W. Rozycki
Fix a thinko in the status interrupt handler that has caused counters for the RI and DSR modem line transitions to be used for the other line each. Fixes: 8b4a40809e53 ("zs: move to the serial subsystem") Cc: stable <stable@kernel.org> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://patch.msgid.link/alpine.DEB.2.21.2604101747110.29980@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-05-11serial: 8250_dw: Use a fixed CPR value for UltraRISC DP1000 UARTJia Wang
The UltraRISC DP1000 UART does not provide the standard CPR register used by 8250_dw to discover port capabilities. Provide a fixed CPR value for the DP1000-specific compatible so the driver can configure the port correctly. Signed-off-by: Jia Wang <wangjia@ultrarisc.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20260429-ultrarisc-serial-v7-4-e475cce9e274@ultrarisc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-07-02 21:36:26 +0000