kernel/linux.git/drivers/tty, 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

tty: ldsic: fix tty_ldisc_autoload sysctl's proc_handler

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

commit 635a9fca54f4f4148be1ae1c7c6bd37af80f5773 upstream. Commit 7c0cca7c847e ("tty: ldisc: add sysctl to prevent autoloading of ldiscs") introduces the tty_ldisc_autoload sysctl with the wrong proc_handler. .extra1 and .extra2 parameters are set to avoid other values thant SYSCTL_ZERO or SYSCTL_ONE to be set but proc_dointvec do not uses them. This commit fixes this by using proc_dointvec_minmax instead of proc_dointvec. Fixes: 7c0cca7c847e ("tty: ldisc: add sysctl to prevent autoloading of ldiscs") Cc: stable Signed-off-by: Nicolas Bouchinet Reviewed-by: Lin Feng Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/20241112131357.49582-4-nicolas.bouchinet@clip-os.org Signed-off-by: Greg Kroah-Hartman 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