summaryrefslogtreecommitdiff
path: root/drivers/tty/serial
AgeCommit message (Collapse)AuthorFilesLines
2023-12-13serial: 8250_omap: Add earlycon support for the AM654 UART controllerRonald Wahl1-0/+1
commit 8e42c301ce64e0dcca547626eb486877d502d336 upstream. Currently there is no support for earlycon on the AM654 UART controller. This commit adds it. Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20231031131242.15516-1-rwahl@gmx.de Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-13serial: 8250: 8250_omap: Do not start RX DMA on THRI interruptRonald Wahl1-4/+6
commit c6bb057418876cdfdd29a6f7b8cef54539ee8811 upstream. Starting RX DMA on THRI interrupt is too early because TX may not have finished yet. This change is inspired by commit 90b8596ac460 ("serial: 8250: Prevent starting up DMA Rx on THRI interrupt") and fixes DMA issues I had with an AM62 SoC that is using the 8250 OMAP variant. Cc: stable@vger.kernel.org Fixes: c26389f998a8 ("serial: 8250: 8250_omap: Add DMA support for UARTs on K3 SoCs") Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20231101171431.16495-1-rwahl@gmx.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-13serial: 8250: 8250_omap: Clear UART_HAS_RHR_IT_DIS bitRonald Wahl1-2/+2
commit 8973ab7a2441b286218f4a5c4c33680e2f139996 upstream. This fixes commit 439c7183e5b9 ("serial: 8250: 8250_omap: Disable RX interrupt after DMA enable") which unfortunately set the UART_HAS_RHR_IT_DIS bit in the UART_OMAP_IER2 register and never cleared it. Cc: stable@vger.kernel.org Fixes: 439c7183e5b9 ("serial: 8250: 8250_omap: Disable RX interrupt after DMA enable") Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20231031110909.11695-1-rwahl@gmx.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-13serial: sc16is7xx: address RX timeout interrupt errataDaniel Mack1-0/+12
commit 08ce9a1b72e38cf44c300a44ac5858533eb3c860 upstream. This device has a silicon bug that makes it report a timeout interrupt but no data in the FIFO. The datasheet states the following in the errata section 18.1.4: "If the host reads the receive FIFO at the same time as a time-out interrupt condition happens, the host might read 0xCC (time-out) in the Interrupt Indication Register (IIR), but bit 0 of the Line Status Register (LSR) is not set (means there is no data in the receive FIFO)." The errata description seems to indicate it concerns only polled mode of operation when reading bit 0 of the LSR register. However, tests have shown and NXP has confirmed that the RXLVL register also yields 0 when the bug is triggered, and hence the IRQ driven implementation in this driver is equally affected. This bug has hit us on production units and when it does, sc16is7xx_irq() would spin forever because sc16is7xx_port_irq() keeps seeing an interrupt in the IIR register that is not cleared because the driver does not call into sc16is7xx_handle_rx() unless the RXLVL register reports at least one byte in the FIFO. Fix this by always reading one byte from the FIFO when this condition is detected in order to clear the interrupt. This approach was confirmed to be correct by NXP through their support channels. Tested by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Signed-off-by: Daniel Mack <daniel@zonque.org> Co-Developed-by: Maxim Popov <maxim.snafu@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20231123072818.1394539-1-daniel@zonque.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-13ARM: PL011: Fix DMA supportArnd Bergmann1-58/+54
commit 58ac1b3799799069d53f5bf95c093f2fe8dd3cc5 upstream. Since there is no guarantee that the memory returned by dma_alloc_coherent() is associated with a 'struct page', using the architecture specific phys_to_page() is wrong, but using virt_to_page() would be as well. Stop using sg lists altogether and just use the *_single() functions instead. This also simplifies the code a bit since the scatterlists in this driver always have only one entry anyway. https://lore.kernel.org/lkml/86db0fe5-930d-4cbb-bd7d-03367da38951@app.fastmail.com/ Use consistent names for dma buffers gc: Add a commit log from the initial thread: https://lore.kernel.org/lkml/86db0fe5-930d-4cbb-bd7d-03367da38951@app.fastmail.com/ Use consistent names for dma buffers Fixes: cb06ff102e2d7 ("ARM: PL011: Add support for Rx DMA buffer polling.") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20231122171503.235649-1-gregory.clement@bootlin.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-13serial: 8250_dw: Add ACPI ID for Granite Rapids-D UARTAndy Shevchenko1-0/+1
commit e92fad024929c79460403acf946bc9c09ce5c3a9 upstream. Granite Rapids-D has an additional UART that is enumerated via ACPI. Add ACPI ID for it. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20231205195524.2705965-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-08serial: sc16is7xx: add missing support for rs485 devicetree propertiesHugo Villeneuve1-0/+4
commit b4a778303ea0fcabcaff974721477a5743e1f8ec upstream. Retrieve rs485 devicetree properties on registration of sc16is7xx ports in case they are attached to an rs485 transceiver. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Lech Perczak <lech.perczak@camlingroup.com> Tested-by: Lech Perczak <lech.perczak@camlingroup.com> Link: https://lore.kernel.org/r/20230807214556.540627-7-hugo@hugovil.com Cc: Hugo Villeneuve <hugo@hugovil.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-08serial: sc16is7xx: Put IOControl register into regmap_volatileHui Wang1-0/+1
commit 77a82cebf0eb023203b4cb2235cab75afc77cccf upstream. According to the IOControl register bits description in the page 31 of the product datasheet, we know the bit 3 of IOControl register is softreset, this bit will self-clearing once the reset finish. In the probe, the softreset bit is set, and when we read this register from debugfs/regmap interface, we found the softreset bit is still setting, this confused us for a while. Finally we found this register is cached, to read the real value from register, we could put it into the regmap_volatile(). Signed-off-by: Hui Wang <hui.wang@canonical.com> Link: https://lore.kernel.org/r/20230724034727.17335-1-hui.wang@canonical.com Cc: Hugo Villeneuve <hugo@hugovil.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-28tty: serial: meson: fix hard LOCKUP on crtscts modePavel Krasavin1-3/+11
commit 2a1d728f20edeee7f26dc307ed9df4e0d23947ab upstream. There might be hard lockup if we set crtscts mode on port without RTS/CTS configured: # stty -F /dev/ttyAML6 crtscts; echo 1 > /dev/ttyAML6; echo 2 > /dev/ttyAML6 [ 95.890386] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [ 95.890857] rcu: 3-...0: (201 ticks this GP) idle=e33c/1/0x4000000000000000 softirq=5844/5846 fqs=4984 [ 95.900212] rcu: (detected by 2, t=21016 jiffies, g=7753, q=296 ncpus=4) [ 95.906972] Task dump for CPU 3: [ 95.910178] task:bash state:R running task stack:0 pid:205 ppid:1 flags:0x00000202 [ 95.920059] Call trace: [ 95.922485] __switch_to+0xe4/0x168 [ 95.925951] 0xffffff8003477508 [ 95.974379] watchdog: Watchdog detected hard LOCKUP on cpu 3 [ 95.974424] Modules linked in: 88x2cs(O) rtc_meson_vrtc Possible solution would be to not allow to setup crtscts on such port. Tested on S905X3 based board. Fixes: ff7693d079e5 ("ARM: meson: serial: add MesonX SoC on-chip uart driver") Cc: stable@vger.kernel.org Signed-off-by: Pavel Krasavin <pkrasavin@imaqliq.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Dmitry Rokosov <ddrokosov@salutedevices.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-08tty: 8250: Add Brainboxes Oxford Semiconductor-based quirksCameron Williams1-0/+147
commit e4876dacaca46a1b09f9b417480924ab12019a5b upstream. Some of the later revisions of the Brainboxes PX cards are based on the Oxford Semiconductor chipset. Due to the chip's unique setup these cards need to be initialised. Previously these were tested against a reference card with the same broken baudrate on another PC, cancelling out the effect. With this patch they work and can transfer/receive find against an FTDI-based device. Add all of the cards which require this setup to the quirks table. Thanks to Maciej W. Rozycki for clarification on this chip. Fixes: ef5a03a26c87 ("tty: 8250: Add support for Brainboxes PX cards.") Cc: stable@vger.kernel.org Signed-off-by: Cameron Williams <cang1@live.co.uk> Link: https://lore.kernel.org/r/DU0PR02MB7899D222A4AB2A4E8C57108FC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-08tty: 8250: Add support for Intashield IX cardsCameron Williams1-0/+21
commit 62d2ec2ded278c7512d91ca7bf8eb9bac46baf90 upstream. Add support for the IX-100, IX-200 and IX-400 serial cards. Cc: stable@vger.kernel.org Signed-off-by: Cameron Williams <cang1@live.co.uk> Link: https://lore.kernel.org/r/DU0PR02MB7899614E5837E82A03272A4BC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-08tty: 8250: Add support for additional Brainboxes PX cardsCameron Williams1-0/+29
commit 9604884e592cd04ead024c9737c67a77f175cab9 upstream. Add support for some more of the Brainboxes PX (PCIe) range of serial cards, namely PX-275/PX-279, PX-475 (serial port, not LPT), PX-820, PX-803/PX-857 (additional ID). Cc: stable@vger.kernel.org Signed-off-by: Cameron Williams <cang1@live.co.uk> Link: https://lore.kernel.org/r/DU0PR02MB78996BEC353FB346FC35444BC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-08tty: 8250: Fix up PX-803/PX-857Cameron Williams1-3/+3
commit ee61337b934c99c2611e0a945d592019b2e00c82 upstream. The PX-803/PX-857 are variants of each other, add a note. Additionally fix up the port counts for the card (2, not 1). Fixes: ef5a03a26c87 ("tty: 8250: Add support for Brainboxes PX cards.") Cc: stable@vger.kernel.org Signed-off-by: Cameron Williams <cang1@live.co.uk> Link: https://lore.kernel.org/r/DU0PR02MB789978C8ED872FB4B014E132C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-08tty: 8250: Fix port count of PX-257Cameron Williams1-1/+1
commit d0ff5b24c2f112f29dea4c38b3bac9597b1be9ba upstream. The port count of the PX-257 Rev3 is actually 2, not 4. Fixes: ef5a03a26c87 ("tty: 8250: Add support for Brainboxes PX cards.") Cc: stable@vger.kernel.org Signed-off-by: Cameron Williams <cang1@live.co.uk> Link: https://lore.kernel.org/r/DU0PR02MB7899C804D9F04E727B5A0E8FC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-08tty: 8250: Add support for Intashield IS-100Cameron Williams1-0/+6
commit 4d994e3cf1b541ff32dfb03fbbc60eea68f9645b upstream. Add support for the Intashield IS-100 1 port serial card. Cc: stable@vger.kernel.org Signed-off-by: Cameron Williams <cang1@live.co.uk> Link: https://lore.kernel.org/r/DU0PR02MB7899A0E0CDAA505AF5A874CDC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-08tty: 8250: Add support for Brainboxes UP cardsCameron Williams1-0/+60
commit 2c6fec1e1532f15350be7e14ba6b88a39d289fe4 upstream. Add support for the Brainboxes UP (powered PCI) range of cards, namely UP-189, UP-200, UP-869 and UP-880. Cc: stable@vger.kernel.org Signed-off-by: Cameron Williams <cang1@live.co.uk> Link: https://lore.kernel.org/r/DU0PR02MB7899B5B59FF3D8587E88C117C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-08tty: 8250: Add support for additional Brainboxes UC cardsCameron Williams1-0/+57
commit c563db486db7d245c0e2f319443417ae8e692f7f upstream. Add device IDs for some more Brainboxes UC cards, namely UC-235/UC-246, UC-253/UC-734, UC-302, UC-313, UC-346, UC-357, UC-607 and UC-836. Cc: stable@vger.kernel.org Signed-off-by: Cameron Williams <cang1@live.co.uk> Link: https://lore.kernel.org/r/DU0PR02MB789969998A6C3FAFCD95C85DC4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-08tty: 8250: Remove UC-257 and UC-431Cameron Williams1-8/+1
commit 33092fb3af51deb80849e90a17bada44bbcde6b3 upstream. The UC-257 is a serial + LPT card, so remove it from this driver. A patch has been submitted to add it to parport_serial instead. Additionaly, the UC-431 does not use this card ID, only the UC-420 does. The 431 is a 3-port card and there is no generic 3-port configuration available, so remove reference to it from this driver. Fixes: 152d1afa834c ("tty: Add support for Brainboxes UC cards.") Cc: stable@vger.kernel.org Signed-off-by: Cameron Williams <cang1@live.co.uk> Link: https://lore.kernel.org/r/DU0PR02MB78995ADF7394C74AD4CF3357C4DBA@DU0PR02MB7899.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-25serial: 8250: omap: convert to modern PM opsArnd Bergmann1-12/+5
commit ae62c49c0ceff20dc7c1fad4a5b8f91d64b4f628 upstream. The new uart_write() function is only called from suspend/resume code, causing a build warning when those are left out: drivers/tty/serial/8250/8250_omap.c:169:13: error: 'uart_write' defined but not used [-Werror=unused-function] Remove the #ifdefs and use the modern pm_ops/pm_sleep_ops and their wrappers to let the compiler see where it's used but still drop the dead code. Fixes: 398cecc24846 ("serial: 8250: omap: Fix imprecise external abort for omap_8250_pm()") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230517202012.634386-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-25serial: 8250: omap: Move uart_write() inside PM sectionGeert Uytterhoeven1-5/+5
commit c53aab20762255ee03e65dd66b3cba3887ad39d1 upstream. If CONFIG_PM is not set (e.g. m68k/allmodconfig): drivers/tty/serial/8250/8250_omap.c:169:13: error: ‘uart_write’ defined but not used [-Werror=unused-function] 169 | static void uart_write(struct omap8250_priv *priv, u32 reg, u32 val) | ^~~~~~~~~~ Fix tis by moving uart_write() inside the existing section protected by #ifdef CONFIG_PM. Reported-by: noreply@ellerman.id.au Link: http://kisskb.ellerman.id.au/kisskb/buildresult/14925095/ Fixes: 398cecc24846e867 ("serial: 8250: omap: Fix imprecise external abort for omap_8250_pm()") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230515065706.1723477-1-geert@linux-m68k.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-25serial: 8250_omap: Fix errors with no_console_suspendTony Lindgren1-15/+10
[ Upstream commit 560706eff7c8e5621b0d63afe0866e0e1906e87e ] We now get errors on system suspend if no_console_suspend is set as reported by Thomas. The errors started with commit 20a41a62618d ("serial: 8250_omap: Use force_suspend and resume for system suspend"). Let's fix the issue by checking for console_suspend_enabled in the system suspend and resume path. Note that with this fix the checks for console_suspend_enabled in omap8250_runtime_suspend() become useless. We now keep runtime PM usage count for an attached kernel console starting with commit bedb404e91bb ("serial: 8250_port: Don't use power management for kernel console"). Fixes: 20a41a62618d ("serial: 8250_omap: Use force_suspend and resume for system suspend") Cc: stable <stable@kernel.org> Cc: Udit Kumar <u-kumar1@ti.com> Reported-by: Thomas Richard <thomas.richard@bootlin.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Thomas Richard <thomas.richard@bootlin.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20230926061319.15140-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-25serial: 8250: omap: Fix imprecise external abort for omap_8250_pm()Tony Lindgren1-32/+38
[ Upstream commit 398cecc24846e867b9f90a0bd22730e3df6b05be ] We must idle the uart only after serial8250_unregister_port(). Otherwise unbinding the uart via sysfs while doing cat on the port produces an imprecise external abort: mem_serial_in from omap_8250_pm+0x44/0xf4 omap_8250_pm from uart_hangup+0xe0/0x194 uart_hangup from __tty_hangup.part.0+0x37c/0x3a8 __tty_hangup.part.0 from uart_remove_one_port+0x9c/0x22c uart_remove_one_port from serial8250_unregister_port+0x60/0xe8 serial8250_unregister_port from omap8250_remove+0x6c/0xd0 omap8250_remove from platform_remove+0x28/0x54 Turns out the driver needs to have runtime PM functional before the driver probe calls serial8250_register_8250_port(). And it needs runtime PM after driver remove calls serial8250_unregister_port(). On probe, we need to read registers before registering the port in omap_serial_fill_features_erratas(). We do that with custom uart_read() already. On remove, after serial8250_unregister_port(), we need to write to the uart registers to idle the device. Let's add a custom uart_write() for that. Currently the uart register access depends on port->membase to be initialized, which won't work after serial8250_unregister_port(). Let's use priv->membase instead, and use it for runtime PM related functions to remove the dependency to port->membase for early and late register access. Note that during use, we need to check for a valid port in the runtime PM related functions. This is needed for the optional wakeup configuration. We now need to set the drvdata a bit earlier so it's available for the runtime PM functions. With the port checks in runtime PM functions, the old checks for priv in omap8250_runtime_suspend() and omap8250_runtime_resume() functions are no longer needed and are removed. Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230508082014.23083-3-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 560706eff7c8 ("serial: 8250_omap: Fix errors with no_console_suspend") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-25serial: Reduce spinlocked portion of uart_rs485_config()Lukas Wunner1-4/+9
[ Upstream commit 8679328eb859d06a1984ab48d90ac35d11bbcaf1 ] Commit 44b27aec9d96 ("serial: core, 8250: set RS485 termination GPIO in serial core") enabled support for RS485 termination GPIOs behind i2c expanders by setting the GPIO outside of the critical section protected by the port spinlock. Access to the i2c expander may sleep, which caused a splat with the port spinlock held. Commit 7c7f9bc986e6 ("serial: Deassert Transmit Enable on probe in driver-specific way") erroneously regressed that by spinlocking the GPIO manipulation again. Fix by moving uart_rs485_config() (the function manipulating the GPIO) outside of the spinlocked section and acquiring the spinlock inside of uart_rs485_config() for the invocation of ->rs485_config() only. This gets us one step closer to pushing the spinlock down into the ->rs485_config() callbacks which actually need it. (Some callbacks do not want to be spinlocked because they perform sleepable register accesses, see e.g. sc16is7xx_config_rs485().) Stack trace for posterity: Voluntary context switch within RCU read-side critical section! WARNING: CPU: 0 PID: 56 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch Call trace: rcu_note_context_switch __schedule schedule schedule_timeout wait_for_completion_timeout bcm2835_i2c_xfer __i2c_transfer i2c_transfer i2c_transfer_buffer_flags regmap_i2c_write _regmap_raw_write_impl _regmap_bus_raw_write _regmap_write _regmap_update_bits regmap_update_bits_base pca953x_gpio_set_value gpiod_set_raw_value_commit gpiod_set_value_nocheck gpiod_set_value_cansleep uart_rs485_config uart_add_one_port pl011_register_port pl011_probe Fixes: 7c7f9bc986e6 ("serial: Deassert Transmit Enable on probe in driver-specific way") Suggested-by: Lino Sanfilippo <LinoSanfilippo@gmx.de> Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v6.1+ Link: https://lore.kernel.org/r/f3a35967c28b32f3c6432d0aa5936e6a9908282d.1695307688.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-25serial: Rename uart_change_speed() to uart_change_line_settings()Ilpo Järvinen1-6/+6
[ Upstream commit 826736a6c7c8c3185bfb10e03c10d03d53d6cf94 ] uart_change_speed() changes more than just speed so rename it to more generic uart_change_line_settings(). Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20230309080923.11778-6-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 8679328eb859 ("serial: Reduce spinlocked portion of uart_rs485_config()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-25serial: Move uart_change_speed() earlierIlpo Järvinen1-48/+46
[ Upstream commit 8e90cf29aef77b59ed6a6f6466add2af79621f26 ] Move uart_change_speed() earlier to get rid of its forward declaration. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20230309080923.11778-5-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 8679328eb859 ("serial: Reduce spinlocked portion of uart_rs485_config()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06serial: 8250_port: Check IRQ data before useAndy Shevchenko1-1/+4
commit cce7fc8b29961b64fadb1ce398dc5ff32a79643b upstream. In case the leaf driver wants to use IRQ polling (irq = 0) and IIR register shows that an interrupt happened in the 8250 hardware the IRQ data can be NULL. In such a case we need to skip the wake event as we came to this path from the timer interrupt and quite likely system is already awake. Without this fix we have got an Oops: serial8250: ttyS0 at I/O 0x3f8 (irq = 0, base_baud = 115200) is a 16550A ... BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:serial8250_handle_irq+0x7c/0x240 Call Trace: ? serial8250_handle_irq+0x7c/0x240 ? __pfx_serial8250_timeout+0x10/0x10 Fixes: 0ba9e3a13c6a ("serial: 8250: Add missing wakeup event reporting") Cc: stable <stable@kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20230831222555.614426-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-23serial: cpm_uart: Avoid suspicious lockingChristophe Leroy1-9/+4
[ Upstream commit 36ef11d311f405e55ad8e848c19b212ff71ef536 ] CHECK drivers/tty/serial/cpm_uart/cpm_uart_core.c drivers/tty/serial/cpm_uart/cpm_uart_core.c:1271:39: warning: context imbalance in 'cpm_uart_console_write' - unexpected unlock Allthough 'nolock' is not expected to change, sparse find the following form suspicious: if (unlikely(nolock)) { local_irq_save(flags); } else { spin_lock_irqsave(&pinfo->port.lock, flags); } cpm_uart_early_write(pinfo, s, count, true); if (unlikely(nolock)) { local_irq_restore(flags); } else { spin_unlock_irqrestore(&pinfo->port.lock, flags); } Rewrite it a more obvious form: if (unlikely(oops_in_progress)) { local_irq_save(flags); cpm_uart_early_write(pinfo, s, count, true); local_irq_restore(flags); } else { spin_lock_irqsave(&pinfo->port.lock, flags); cpm_uart_early_write(pinfo, s, count, true); spin_unlock_irqrestore(&pinfo->port.lock, flags); } Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Link: https://lore.kernel.org/r/f7da5cdc9287960185829cfef681a7d8614efa1f.1691068700.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13serial: sc16is7xx: fix regression with GPIO configurationHugo Villeneuve1-35/+108
[ Upstream commit 0499942928341d572a42199580433c2b0725211e ] Commit 679875d1d880 ("sc16is7xx: Separate GPIOs from modem control lines") and commit 21144bab4f11 ("sc16is7xx: Handle modem status lines") changed the function of the GPIOs pins to act as modem control lines without any possibility of selecting GPIO function. As a consequence, applications that depends on GPIO lines configured by default as GPIO pins no longer work as expected. Also, the change to select modem control lines function was done only for channel A of dual UART variants (752/762). This was not documented in the log message. Allow to specify GPIO or modem control line function in the device tree, and for each of the ports (A or B). Do so by using the new device-tree property named "nxp,modem-control-line-ports" (property added in separate patch). When registering GPIO chip controller, mask-out GPIO pins declared as modem control lines according to this new DT property. Fixes: 679875d1d880 ("sc16is7xx: Separate GPIOs from modem control lines") Fixes: 21144bab4f11 ("sc16is7xx: Handle modem status lines") Cc: stable@vger.kernel.org Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Lech Perczak <lech.perczak@camlingroup.com> Tested-by: Lech Perczak <lech.perczak@camlingroup.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230807214556.540627-5-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13serial: sc16is7xx: remove obsolete out_thread labelHugo Villeneuve1-3/+1
[ Upstream commit dabc54a45711fe77674a6c0348231e00e66bd567 ] Commit c8f71b49ee4d ("serial: sc16is7xx: setup GPIO controller later in probe") moved GPIO setup code later in probe function. Doing so also required to move ports cleanup code (out_ports label) after the GPIO cleanup code. After these moves, the out_thread label becomes misplaced and makes part of the cleanup code illogical. This patch remove the now obsolete out_thread label and make GPIO setup code jump to out_ports label if it fails. Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Reviewed-by: Lech Perczak <lech.perczak@camlingroup.com> Tested-by: Lech Perczak <lech.perczak@camlingroup.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20230807214556.540627-3-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 049994292834 ("serial: sc16is7xx: fix regression with GPIO configuration") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13serial: tegra: handle clk prepare error in tegra_uart_hw_init()Yi Yang1-1/+5
[ Upstream commit 5abd01145d0cc6cd1b7c2fe6ee0b9ea0fa13671e ] In tegra_uart_hw_init(), the return value of clk_prepare_enable() should be checked since it might fail. Fixes: e9ea096dd225 ("serial: tegra: add serial driver") Signed-off-by: Yi Yang <yiyang13@huawei.com> Link: https://lore.kernel.org/r/20230817105406.228674-1-yiyang13@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13serial: sprd: Fix DMA buffer leak issueChunyan Zhang1-2/+3
[ Upstream commit cd119fdc3ee1450fbf7f78862b5de44c42b6e47f ] Release DMA buffer when _probe() returns failure to avoid memory leak. Fixes: f4487db58eb7 ("serial: sprd: Add DMA mode support") Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Link: https://lore.kernel.org/r/20230725064053.235448-2-chunyan.zhang@unisoc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13serial: sprd: Assign sprd_port after initialized to avoid wrong accessChunyan Zhang1-8/+17
[ Upstream commit f9608f1887568b728839d006024585ab02ef29e5 ] The global pointer 'sprd_port' may not zero when sprd_probe returns failure, that is a risk for sprd_port to be accessed afterward, and may lead to unexpected errors. For example: There are two UART ports, UART1 is used for console and configured in kernel command line, i.e. "console="; The UART1 probe failed and the memory allocated to sprd_port[1] was released, but sprd_port[1] was not set to NULL; In UART2 probe, the same virtual address was allocated to sprd_port[2], and UART2 probe process finally will go into sprd_console_setup() to register UART1 as console since it is configured as preferred console (filled to console_cmdline[]), but the console parameters (sprd_port[1]) belong to UART2. So move the sprd_port[] assignment to where the port already initialized can avoid the above issue. Fixes: b7396a38fb28 ("tty/serial: Add Spreadtrum sc9836-uart driver support") Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Link: https://lore.kernel.org/r/20230725064053.235448-1-chunyan.zhang@unisoc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-06serial: sc16is7xx: fix bug when first setting GPIO directionHugo Villeneuve1-1/+10
commit 9baeea723c0fb9c3ba9a336369f758ed9bc6831d upstream. When configuring a pin as an output pin with a value of logic 0, we end up as having a value of logic 1 on the output pin. Setting a logic 0 a second time (or more) after that will correctly output a logic 0 on the output pin. By default, all GPIO pins are configured as inputs. When we enter sc16is7xx_gpio_direction_output() for the first time, we first set the desired value in IOSTATE, and then we configure the pin as an output. The datasheet states that writing to IOSTATE register will trigger a transfer of the value to the I/O pin configured as output, so if the pin is configured as an input, nothing will be transferred. Therefore, set the direction first in IODIR, and then set the desired value in IOSTATE. This is what is done in NXP application note AN10587. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable@vger.kernel.org Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Reviewed-by: Lech Perczak <lech.perczak@camlingroup.com> Tested-by: Lech Perczak <lech.perczak@camlingroup.com> Link: https://lore.kernel.org/r/20230807214556.540627-6-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-06serial: sc16is7xx: fix broken port 0 uart initHugo Villeneuve1-0/+6
commit 2861ed4d6e6d1a2c9de9bf5b0abd996c2dc673d0 upstream. The sc16is7xx_config_rs485() function is called only for the second port (index 1, channel B), causing initialization problems for the first port. For the sc16is7xx driver, port->membase and port->mapbase are not set, and their default values are 0. And we set port->iobase to the device index. This means that when the first device is registered using the uart_add_one_port() function, the following values will be in the port structure: port->membase = 0 port->mapbase = 0 port->iobase = 0 Therefore, the function uart_configure_port() in serial_core.c will exit early because of the following check: /* * If there isn't a port here, don't do anything further. */ if (!port->iobase && !port->mapbase && !port->membase) return; Typically, I2C and SPI drivers do not set port->membase and port->mapbase. The max310x driver sets port->membase to ~0 (all ones). By implementing the same change in this driver, uart_configure_port() is now correctly executed for all ports. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable@vger.kernel.org Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Lech Perczak <lech.perczak@camlingroup.com> Tested-by: Lech Perczak <lech.perczak@camlingroup.com> Link: https://lore.kernel.org/r/20230807214556.540627-2-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-06serial: qcom-geni: fix opp vote on shutdownJohan Hovold1-0/+5
commit 8ece7b754bc34ffd7fcc8269ccb9128e72ca76d8 upstream. The operating-performance-point vote needs to be dropped when shutting down the port to avoid wasting power by keeping resources like power domains in an unnecessarily high performance state (e.g. when a UART connected Bluetooth controller is not in use). Fixes: a5819b548af0 ("tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state") Cc: stable@vger.kernel.org # 5.9 Cc: Rajendra Nayak <quic_rjendra@quicinc.com> Cc: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230714130214.14552-2-johan+linaro@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-23serial: 8250: Fix oops for port->pm on uart_change_pm()Tony Lindgren1-0/+1
[ Upstream commit dfe2aeb226fd5e19b0ee795f4f6ed8bc494c1534 ] Unloading a hardware specific 8250 driver can produce error "Unable to handle kernel paging request at virtual address" about ten seconds after unloading the driver. This happens on uart_hangup() calling uart_change_pm(). Turns out commit 04e82793f068 ("serial: 8250: Reinit port->pm on port specific driver unbind") was only a partial fix. If the hardware specific driver has initialized port->pm function, we need to clear port->pm too. Just reinitializing port->ops does not do this. Otherwise serial8250_pm() will call port->pm() instead of serial8250_do_pm(). Fixes: 04e82793f068 ("serial: 8250: Reinit port->pm on port specific driver unbind") Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230804131553.52927-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-08-23tty: serial: fsl_lpuart: Clear the error flags by writing 1 for lpuart32 ↵Sherry Sun1-2/+2
platforms commit 282069845af388b08d622ad192b831dcd0549c62 upstream. Do not read the data register to clear the error flags for lpuart32 platforms, the additional read may cause the receive FIFO underflow since the DMA has already read the data register. Actually all lpuart32 platforms support write 1 to clear those error bits, let's use this method to better clear the error flags. Fixes: 42b68768e51b ("serial: fsl_lpuart: DMA support for 32-bit variant") Cc: stable <stable@kernel.org> Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Link: https://lore.kernel.org/r/20230801022304.24251-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-23serial: stm32: Ignore return value of uart_remove_one_port() in .remove()Uwe Kleine-König1-4/+1
[ Upstream commit 6bd6cd29c92401a101993290051fa55078238a52 ] Returning early from stm32_usart_serial_remove() results in a resource leak as several cleanup functions are not called. The driver core ignores the return value and there is no possibility to clean up later. uart_remove_one_port() only returns non-zero if there is some inconsistency (i.e. stm32_usart_driver.state[port->line].uart_port == NULL). This should never happen, and even if it does it's a bad idea to exit early in the remove callback without cleaning up. This prepares changing the prototype of struct platform_driver::remove to return void. See commit 5c5a7680e67b ("platform: Provide a remove callback that returns no value") for further details about this quest. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512173810.131447-2-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-08-03serial: sifive: Fix sifive_serial_console_setup() sectionSamuel Holland1-1/+1
commit 9b8fef6345d5487137d4193bb0a0eae2203c284e upstream. This function is called indirectly from the platform driver probe function. Even if the driver is built in, it may be probed after free_initmem() due to deferral or unbinding/binding via sysfs. Thus the function cannot be marked as __init. Fixes: 45c054d0815b ("tty: serial: add driver for the SiFive UART") Cc: stable <stable@kernel.org> Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Link: https://lore.kernel.org/r/20230624060159.3401369-1-samuel.holland@sifive.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-03serial: 8250_dw: Preserve original value of DLF registerRuihong Luo1-2/+4
commit 748c5ea8b8796ae8ee80b8d3a3d940570b588d59 upstream. Preserve the original value of the Divisor Latch Fraction (DLF) register. When the DLF register is modified without preservation, it can disrupt the baudrate settings established by firmware or bootloader, leading to data corruption and the generation of unreadable or distorted characters. Fixes: 701c5e73b296 ("serial: 8250_dw: add fractional divisor support") Cc: stable <stable@kernel.org> Signed-off-by: Ruihong Luo <colorsu1922@gmail.com> Link: https://lore.kernel.org/stable/20230713004235.35904-1-colorsu1922%40gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230713004235.35904-1-colorsu1922@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-03serial: qcom-geni: drop bogus runtime pm state updateJohan Hovold1-7/+0
commit 4dd8752a14ca0303fbdf0a6c68ff65f0a50bd2fa upstream. The runtime PM state should not be changed by drivers that do not implement runtime PM even if it happens to work around a bug in PM core. With the wake irq arming now fixed, drop the bogus runtime PM state update which left the device in active state (and could potentially prevent a parent device from suspending). Fixes: f3974413cf02 ("tty: serial: qcom_geni_serial: Wakeup IRQ cleanup") Cc: 5.6+ <stable@vger.kernel.org> # 5.6+ Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-23Revert "8250: add support for ASIX devices with a FIFO bug"Jiaqing Zhao3-28/+3
commit a82d62f708545d22859584e0e0620da8e3759bbc upstream. This reverts commit eb26dfe8aa7eeb5a5aa0b7574550125f8aa4c3b3. Commit eb26dfe8aa7e ("8250: add support for ASIX devices with a FIFO bug") merged on Jul 13, 2012 adds a quirk for PCI_VENDOR_ID_ASIX (0x9710). But that ID is the same as PCI_VENDOR_ID_NETMOS defined in 1f8b061050c7 ("[PATCH] Netmos parallel/serial/combo support") merged on Mar 28, 2005. In pci_serial_quirks array, the NetMos entry always takes precedence over the ASIX entry even since it was initially merged, code in that commit is always unreachable. In my tests, adding the FIFO workaround to pci_netmos_init() makes no difference, and the vendor driver also does not have such workaround. Given that the code was never used for over a decade, it's safe to revert it. Also, the real PCI_VENDOR_ID_ASIX should be 0x125b, which is used on their newer AX99100 PCIe serial controllers released on 2016. The FIFO workaround should not be intended for these newer controllers, and it was never implemented in vendor driver. Fixes: eb26dfe8aa7e ("8250: add support for ASIX devices with a FIFO bug") Cc: stable <stable@kernel.org> Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230619155743.827859-1-jiaqing.zhao@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-23tty: serial: imx: fix rs485 rx after txMartin Fuzzey1-5/+13
commit 639949a7031e04c59ec91614eceb9543e9120f43 upstream. Since commit 79d0224f6bf2 ("tty: serial: imx: Handle RS485 DE signal active high") RS485 reception no longer works after a transmission. The following scenario shows the problem: 1) Open a port in RS485 mode 2) Receive data from remote (OK) 3) Transmit data to remote (OK) 4) Receive data from remote (Nothing received) In RS485 mode, imx_uart_start_tx() calls imx_uart_stop_rx() and, when the transmission is complete, imx_uart_stop_tx() calls imx_uart_start_rx(). Since the above commit imx_uart_stop_rx() now sets the loopback bit but imx_uart_start_rx() does not clear it causing the hardware to remain in loopback mode and not receive external data. Fix this by moving the existing loopback disable code to a helper function and calling it from imx_uart_start_rx() too. Fixes: 79d0224f6bf2 ("tty: serial: imx: Handle RS485 DE signal active high") Cc: stable@vger.kernel.org Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20230616104838.2729694-1-martin.fuzzey@flowbird.group Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-23tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() when ↵Christophe JAILLET1-0/+8
iterating clk commit 832e231cff476102e8204a9e7bddfe5c6154a375 upstream. When the best clk is searched, we iterate over all possible clk. If we find a better match, the previous one, if any, needs to be freed. If a better match has already been found, we still need to free the new one, otherwise it leaks. Cc: <stable@vger.kernel.org> # v3.3+ Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Fixes: 5f5a7a5578c5 ("serial: samsung: switch to clkdev based clock lookup") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Message-ID: <cf3e0053d2fc7391b2d906a86cd01a5ef15fb9dc.1686412569.git.christophe.jaillet@wanadoo.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-23tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() in ↵Christophe JAILLET1-1/+5
case of error commit a9c09546e903f1068acfa38e1ee18bded7114b37 upstream. If clk_get_rate() fails, the clk that has just been allocated needs to be freed. Cc: <stable@vger.kernel.org> # v3.3+ Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Fixes: 5f5a7a5578c5 ("serial: samsung: switch to clkdev based clock lookup") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Message-ID: <e4baf6039368f52e5a5453982ddcb9a330fc689e.1686412569.git.christophe.jaillet@wanadoo.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-23serial: atmel: don't enable IRQs prematurelyDan Carpenter1-2/+2
commit 27a826837ec9a3e94cc44bd9328b8289b0fcecd7 upstream. The atmel_complete_tx_dma() function disables IRQs at the start of the function by calling spin_lock_irqsave(&port->lock, flags); There is no need to disable them a second time using the spin_lock_irq() function and, in fact, doing so is a bug because it will enable IRQs prematurely when we call spin_unlock_irq(). Just use spin_lock/unlock() instead without disabling or enabling IRQs. Fixes: 08f738be88bb ("serial: at91: add tx dma support") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Acked-by: Richard Genoud <richard.genoud@gmail.com> Link: https://lore.kernel.org/r/cb7c39a9-c004-4673-92e1-be4e34b85368@moroto.mountain Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19tty: serial: fsl_lpuart: add earlycon for imx8ulp platformSherry Sun1-0/+1
commit e0edfdc15863ec80a1d9ac6e174dbccc00206dd0 upstream. Add earlycon support for imx8ulp platform. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20230619080613.16522-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19serial: 8250_omap: Use force_suspend and resume for system suspendTony Lindgren1-5/+15
[ Upstream commit 20a41a62618df85f3a2981008edec5cadd785e0a ] We should not rely on autosuspend timeout for system suspend. Instead, let's use force_suspend and force_resume functions. Otherwise the serial port controller device may not be idled on suspend. As we are doing a register write on suspend to configure the serial port, we still need to runtime PM resume the port on suspend. While at it, let's switch to pm_runtime_resume_and_get() and check for errors returned. And let's add the missing line break before return to the suspend function while at it. Fixes: 09d8b2bdbc5c ("serial: 8250: omap: Provide ability to enable/disable UART as wakeup source") Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Dhruva Gole <d-gole@ti.com> Message-ID: <20230614045922.4798-1-tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19serial: 8250: lock port for UART_IER access in omap8250_irq()John Ogness1-2/+3
[ Upstream commit 25614735a647693c1260f253dc3ab32127697806 ] omap8250_irq() accesses UART_IER. This register is modified twice by each console write (serial8250_console_write()) under the port lock. omap8250_irq() must also take the port lock to guanentee synchronized access to UART_IER. Since the port lock is already being taken for the stop_rx() callback and since it is safe to call cancel_delayed_work() while holding the port lock, simply extend the port lock region to include UART_IER access. Fixes: 1fe0e1fa3209 ("serial: 8250_omap: Handle optional overrun-throttle-ms property") Signed-off-by: John Ogness <john.ogness@linutronix.de> Reviewed-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20230525093159.223817-8-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19serial: core: lock port for start_rx() in uart_resume_port()John Ogness1-1/+4
[ Upstream commit 51e45fba14bf08b66bca764a083c7f2e2ff62f01 ] The only user of the start_rx() callback (qcom_geni) directly calls its own stop_rx() callback. Since stop_rx() requires that the port->lock is taken and interrupts are disabled, the start_rx() callback has the same requirement. Fixes: cfab87c2c271 ("serial: core: Introduce callback for start_rx and do stop_rx in suspend only if this callback implementation is present.") Signed-off-by: John Ogness <john.ogness@linutronix.de> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230525093159.223817-5-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-01-23 12:57:41 +0300