Patch "tty: serial: atmel: Preserve previous USART mode if RS485 disabled" has been added to the 5.10-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    tty: serial: atmel: Preserve previous USART mode if RS485 disabled

to the 5.10-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     tty-serial-atmel-preserve-previous-usart-mode-if-rs4.patch
and it can be found in the queue-5.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit f6ad96aaaa384194ca2db76e4b5864a21d64a9ff
Author: Sergiu Moga <sergiu.moga@xxxxxxxxxxxxx>
Date:   Wed Aug 24 17:29:03 2022 +0300

    tty: serial: atmel: Preserve previous USART mode if RS485 disabled
    
    [ Upstream commit 692a8ebcfc24f4a5bea0eb2967e450f584193da6 ]
    
    Whenever the atmel_rs485_config() driver method would be called,
    the USART mode is reset to normal mode before even checking if
    RS485 flag is set, thus resulting in losing the previous USART
    mode in the case where the checking fails.
    
    Some tools, such as `linux-serial-test`, lead to the driver calling
    this method when doing the setup of the serial port: after setting the
    port mode (Hardware Flow Control, Normal Mode, RS485 Mode, etc.),
    `linux-serial-test` tries to enable/disable RS485 depending on
    the commandline arguments that were passed.
    
    Example of how this issue could reveal itself:
    When doing a serial communication with Hardware Flow Control through
    `linux-serial-test`, the tool would lead to the driver roughly doing
    the following:
    - set the corresponding bit to 1 (ATMEL_US_USMODE_HWHS bit in the
    ATMEL_US_MR register) through the atmel_set_termios() to enable
    Hardware Flow Control
    - disable RS485 through the atmel_config_rs485() method
    Thus, when the latter is called, the mode will be reset and the
    previously set bit is unset, leaving USART in normal mode instead of
    the expected Hardware Flow Control mode.
    
    This fix ensures that this reset is only done if the checking for
    RS485 succeeds and that the previous mode is preserved otherwise.
    
    Fixes: e8faff7330a35 ("ARM: 6092/1: atmel_serial: support for RS485 communications")
    Cc: stable <stable@xxxxxxxxxx>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>
    Signed-off-by: Sergiu Moga <sergiu.moga@xxxxxxxxxxxxx>
    Link: https://lore.kernel.org/r/20220824142902.502596-1-sergiu.moga@xxxxxxxxxxxxx
    Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index e7526060926d..b7872ad3e762 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -295,9 +295,6 @@ static int atmel_config_rs485(struct uart_port *port,
 
 	mode = atmel_uart_readl(port, ATMEL_US_MR);
 
-	/* Resetting serial mode to RS232 (0x0) */
-	mode &= ~ATMEL_US_USMODE;
-
 	if (rs485conf->flags & SER_RS485_ENABLED) {
 		dev_dbg(port->dev, "Setting UART to RS485\n");
 		if (rs485conf->flags & SER_RS485_RX_DURING_TX)
@@ -307,6 +304,7 @@ static int atmel_config_rs485(struct uart_port *port,
 
 		atmel_uart_writel(port, ATMEL_US_TTGR,
 				  rs485conf->delay_rts_after_send);
+		mode &= ~ATMEL_US_USMODE;
 		mode |= ATMEL_US_USMODE_RS485;
 	} else {
 		dev_dbg(port->dev, "Setting UART to RS232\n");



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux