blaster4385/linux-IllusionX/drivers/tty, branch v6.12.10

serial: stm32: use port lock wrappers for break control

2025-01-17T12:40:53Z

commit 0cfc36ea51684b5932cd3951ded523777d807af2 upstream. Commit 30e945861f3b ("serial: stm32: add support for break control") added another usage of the port lock, but was merged on the same day as c5d06662551c ("serial: stm32: Use port lock wrappers"), therefore the latter did not update this usage to use the port lock wrappers. Fixes: c5d06662551c ("serial: stm32: Use port lock wrappers") Cc: stable Signed-off-by: Ben Wolsieffer Reviewed-by: John Ogness Link: https://lore.kernel.org/r/20241216145323.111612-1-ben.wolsieffer@hefring.com Signed-off-by: Greg Kroah-Hartman

tty: serial: 8250: Fix another runtime PM usage counter underflow

2025-01-17T12:40:53Z

commit ed2761958ad77e54791802b07095786150eab844 upstream. The commit f9b11229b79c ("serial: 8250: Fix PM usage_count for console handover") fixed one runtime PM usage counter balance problem that occurs because .dev is not set during univ8250 setup preventing call to pm_runtime_get_sync(). Later, univ8250_console_exit() will trigger the runtime PM usage counter underflow as .dev is already set at that time. Call pm_runtime_get_sync() to balance the RPM usage counter also in serial8250_register_8250_port() before trying to add the port. Reported-by: Borislav Petkov (AMD) Fixes: bedb404e91bb ("serial: 8250_port: Don't use power management for kernel console") Cc: stable Tested-by: Borislav Petkov (AMD) Signed-off-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20241210170120.2231-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Check if TX data was written to device in .tx_empty()

2024-12-19T17:12:58Z

commit 7cc0e0a43a91052477c2921f924a37d9c3891f0c upstream. On the Renesas RZ/G3S, when doing suspend to RAM, the uart_suspend_port() is called. The uart_suspend_port() calls 3 times the struct uart_port::ops::tx_empty() before shutting down the port. According to the documentation, the struct uart_port::ops::tx_empty() API tests whether the transmitter FIFO and shifter for the port is empty. The Renesas RZ/G3S SCIFA IP reports the number of data units stored in the transmit FIFO through the FDR (FIFO Data Count Register). The data units in the FIFOs are written in the shift register and transmitted from there. The TEND bit in the Serial Status Register reports if the data was transmitted from the shift register. In the previous code, in the tx_empty() API implemented by the sh-sci driver, it is considered that the TX is empty if the hardware reports the TEND bit set and the number of data units in the FIFO is zero. According to the HW manual, the TEND bit has the following meaning: 0: Transmission is in the waiting state or in progress. 1: Transmission is completed. It has been noticed that when opening the serial device w/o using it and then switch to a power saving mode, the tx_empty() call in the uart_port_suspend() function fails, leading to the "Unable to drain transmitter" message being printed on the console. This is because the TEND=0 if nothing has been transmitted and the FIFOs are empty. As the TEND=0 has double meaning (waiting state, in progress) we can't determined the scenario described above. Add a software workaround for this. This sets a variable if any data has been sent on the serial console (when using PIO) or if the DMA callback has been called (meaning something has been transmitted). In the tx_empty() API the status of the DMA transaction is also checked and if it is completed or in progress the code falls back in checking the hardware registers instead of relying on the software variable. Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20241125115856.513642-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman

serial: 8250_dw: Add Sophgo SG2044 quirk

2024-12-14T19:04:09Z

[ 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 build regression

2024-12-05T13:02:54Z

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 Signed-off-by: Greg Kroah-Hartman

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

2024-12-05T13:02:54Z

commit 2bcacc1c87acf9a8ebc17de18cb2b3cfeca547cf upstream. 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: Greg Kroah-Hartman

serial: 8250: omap: Move pm_runtime_get_sync

2024-12-05T13:02:54Z

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-05T13:02:53Z

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-05T13:02:50Z

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-05T13:02:50Z

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