kernel/linux.git/drivers/tty/serial, branch v6.1.124

serial: amba-pl011: fix build regression

2024-12-14T18:54:55+00:00

commit b5a23a60e8ab5711f4952912424347bf3864ce8d upstream. When CONFIG_DMA_ENGINE is disabled, the driver now fails to build: drivers/tty/serial/amba-pl011.c: In function 'pl011_unthrottle_rx': drivers/tty/serial/amba-pl011.c:1822:16: error: 'struct uart_amba_port' has no member named 'using_rx_dma' 1822 | if (uap->using_rx_dma) { | ^~ drivers/tty/serial/amba-pl011.c:1823:20: error: 'struct uart_amba_port' has no member named 'dmacr' 1823 | uap->dmacr |= UART011_RXDMAE; | ^~ drivers/tty/serial/amba-pl011.c:1824:32: error: 'struct uart_amba_port' has no member named 'dmacr' 1824 | pl011_write(uap->dmacr, uap, REG_DMACR); | ^~ Add the missing #ifdef check around these field accesses, matching what other parts of this driver do. Fixes: 2bcacc1c87ac ("serial: amba-pl011: Fix RX stall when DMA is used") Cc: stable Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202411140617.nkjeHhsK-lkp@intel.com/ Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20241115110021.744332-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Add Sophgo SG2044 quirk

2024-12-14T18:54:49+00:00

[ Upstream commit cad4dda82c7eedcfc22597267e710ccbcf39d572 ] SG2044 relys on an internal divisor when calculating bitrate, which means a wrong clock for the most common bitrates. So add a quirk for this uart device to skip the set rate call and only relys on the internal UART divisor. Reviewed-by: Andy Shevchenko Reviewed-by: Ilpo Järvinen Signed-off-by: Inochi Amaoto Link: https://lore.kernel.org/r/20241024062105.782330-4-inochiama@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: amba-pl011: Fix RX stall when DMA is used

2024-12-14T18:54:24+00:00

[ Upstream commit 2bcacc1c87acf9a8ebc17de18cb2b3cfeca547cf ] Function pl011_throttle_rx() calls pl011_stop_rx() to disable RX, which also disables the RX DMA by clearing the RXDMAE bit of the DMACR register. However, to properly unthrottle RX when DMA is used, the function pl011_unthrottle_rx() is expected to set the RXDMAE bit of the DMACR register, which it currently lacks. This causes RX to stall after the throttle API is called. Set RXDMAE bit in the DMACR register while unthrottling RX if RX DMA is used. Fixes: 211565b10099 ("serial: pl011: UPSTAT_AUTORTS requires .throttle/unthrottle") Cc: stable@vger.kernel.org Signed-off-by: Kartik Rajput Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20241113092629.60226-1-kkartik@nvidia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

serial: amba-pl011: Use port lock wrappers

2024-12-14T18:54:24+00:00

[ Upstream commit 68ca3e72d7463d79d29b6e4961d6028df2a88e25 ] When a serial port is used for kernel console output, then all modifications to the UART registers which are done from other contexts, e.g. getty, termios, are interference points for the kernel console. So far this has been ignored and the printk output is based on the principle of hope. The rework of the console infrastructure which aims to support threaded and atomic consoles, requires to mark sections which modify the UART registers as unsafe. This allows the atomic write function to make informed decisions and eventually to restore operational state. It also allows to prevent the regular UART code from modifying UART registers while printk output is in progress. All modifications of UART registers are guarded by the UART port lock, which provides an obvious synchronization point with the console infrastructure. To avoid adding this functionality to all UART drivers, wrap the spin_[un]lock*() invocations for uart_port::lock into helper functions which just contain the spin_[un]lock*() invocations for now. In a subsequent step these helpers will gain the console synchronization mechanisms. Converted with coccinelle. No functional change. Signed-off-by: Thomas Gleixner Signed-off-by: John Ogness Link: https://lore.kernel.org/r/20230914183831.587273-18-john.ogness@linutronix.de Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 2bcacc1c87ac ("serial: amba-pl011: Fix RX stall when DMA is used") Signed-off-by: Sasha Levin

serial: 8250: omap: Move pm_runtime_get_sync

2024-12-14T18:54:03+00:00

commit bcc7ba668818dcadd2f1db66b39ed860a63ecf97 upstream. Currently in omap_8250_shutdown, the dma->rx_running flag is set to zero in omap_8250_rx_dma_flush. Next pm_runtime_get_sync is called, which is a runtime resume call stack which can re-set the flag. When the call omap_8250_shutdown returns, the flag is expected to be UN-SET, but this is not the case. This is causing issues the next time UART is re-opened and omap_8250_rx_dma is called. Fix by moving pm_runtime_get_sync before the omap_8250_rx_dma_flush. cc: stable@vger.kernel.org Fixes: 0e31c8d173ab ("tty: serial: 8250_omap: add custom DMA-RX callback") Signed-off-by: Bin Liu [Judith: Add commit message] Signed-off-by: Judith Mendez Reviewed-by: Kevin Hilman Tested-by: Kevin Hilman Link: https://lore.kernel.org/r/20241031172315.453750-1-jm@ti.com Signed-off-by: Greg Kroah-Hartman

serial: 8250_fintek: Add support for F81216E

2024-12-14T18:54:03+00:00

commit 166105c9030a30ba08574a9998afc7b60bc72dd7 upstream. The F81216E is a LPC/eSPI to 4 UART Super I/O and is mostly compatible with the F81216H, but does not support RS-485 auto-direction delays on any port. Signed-off-by: Filip Brozovic Cc: stable Link: https://lore.kernel.org/r/20241110111703.15494-1-fbrozovic@gmail.com Signed-off-by: Greg Kroah-Hartman

Revert "serial: sh-sci: Clean sci_ports[0] after at earlycon exit"

2024-12-14T18:54:01+00:00

commit 718632467d88e98816fa01ab12681ef1c2aa56f8 upstream. This reverts commit 3791ea69a4858b81e0277f695ca40f5aae40f312. It was reported to cause boot-time issues, so revert it for now. Reported-by: Geert Uytterhoeven Fixes: 3791ea69a485 ("serial: sh-sci: Clean sci_ports[0] after at earlycon exit") Cc: stable Cc: Claudiu Beznea Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Clean sci_ports[0] after at earlycon exit

2024-12-14T18:54:01+00:00

commit 3791ea69a4858b81e0277f695ca40f5aae40f312 upstream. The early_console_setup() function initializes the sci_ports[0].port with an object of type struct uart_port obtained from the object of type struct earlycon_device received as argument by the early_console_setup(). It may happen that later, when the rest of the serial ports are probed, the serial port that was used as earlycon (e.g., port A) to be mapped to a different position in sci_ports[] and the slot 0 to be used by a different serial port (e.g., port B), as follows: sci_ports[0] = port A sci_ports[X] = port B In this case, the new port mapped at index zero will have associated data that was used for earlycon. In case this happens, after Linux boot, any access to the serial port that maps on sci_ports[0] (port A) will block the serial port that was used as earlycon (port B). To fix this, add early_console_exit() that clean the sci_ports[0] at earlycon exit time. Fixes: 0b0cced19ab1 ("serial: sh-sci: Add CONFIG_SERIAL_EARLYCON support") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20241106120118.1719888-4-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman

serial: sc16is7xx: fix invalid FIFO access with special register set

2024-12-14T18:53:11+00:00

[ Upstream commit 7d3b793faaab1305994ce568b59d61927235f57b ] When enabling access to the special register set, Receiver time-out and RHR interrupts can happen. In this case, the IRQ handler will try to read from the FIFO thru the RHR register at address 0x00, but address 0x00 is mapped to DLL register, resulting in erroneous FIFO reading. Call graph example: sc16is7xx_startup(): entry sc16is7xx_ms_proc(): entry sc16is7xx_set_termios(): entry sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set sc16is7xx_port_irq() entry --> IIR is 0x0C sc16is7xx_handle_rx() entry sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is mapped to DLL (LCR=LCR_CONF_MODE_A) sc16is7xx_set_baud(): exit --> Restore access to general register set Fix the problem by claiming the efr_lock mutex when accessing the Special register set. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable@vger.kernel.org Signed-off-by: Hugo Villeneuve Link: https://lore.kernel.org/r/20240723125302.1305372-3-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman [ Resolve minor conflicts ] Signed-off-by: Bin Lan Signed-off-by: Sasha Levin

serial: protect uart_port_dtr_rts() in uart_shutdown() too

2024-11-01T00:56:07+00:00

[ Upstream commit 602babaa84d627923713acaf5f7e9a4369e77473 ] Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected "uart_port_dtr_rts(uport, false);" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks. Signed-off-by: Jiri Slaby (SUSE) Cc: Peter Hurley Cc: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20240805102046.307511-3-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman [Adapted over commit 5701cb8bf50e ("tty: Call ->dtr_rts() parameter active consistently") not in the tree] Signed-off-by: Tomas Krcka Signed-off-by: Sasha Levin