linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sergiu Moga <sergiu.moga@microchip.com>
To: <richard.genoud@gmail.com>, <gregkh@linuxfoundation.org>,
	<jirislaby@kernel.org>, <nicolas.ferre@microchip.com>,
	<alexandre.belloni@bootlin.com>, <claudiu.beznea@microchip.com>,
	<rmk+kernel@arm.linux.org.uk>, <claudio@evidence.eu.com>,
	<rick@efn.org>, <michael@evidence.eu.com>,
	<ryan@bluewatersys.com>
Cc: <linux-serial@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>,
	Sergiu Moga <sergiu.moga@microchip.com>
Subject: [PATCH] tty: serial: atmel: Preserve previous USART mode if RS485 disabled
Date: Wed, 24 Aug 2022 14:42:57 +0300	[thread overview]
Message-ID: <20220824114255.444655-1-sergiu.moga@microchip.com> (raw)

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 passed. If we were to, for example, enable
Hardware Flow Control through `linux-serial-test`, the tool would
make the driver set the corresponding bit to 1 (ATMEL_US_USMODE_HWHS
bit in the ATMEL_US_MR register) through the atmel_set_termios method
and then proceed to disabling RS485. This, in turn, causes the
ATMEL_US_USMODE_HWHS bit of the ATMEL_US_MR mode register to be unset
and, if the checking for RS485 fails, leads to having the mode set
back to the ATMEL_US_USMODE_NORMAL normal mode. Since in hardware
flow control mode the meanings of the ATMEL_US_RTSDIS and
ATMEL_US_RTSEN bits are swapped, this leads to our endpoint leaving
the RTS line to high when wanting to receive, which is the opposite
of what the other endpoint is expecting in order to start transmitting.
This fix ensures that this reset is done only if the checking for RS485
succeeds.

Fixes: e8faff7330a35 ("ARM: 6092/1: atmel_serial: support for RS485 communications")
Signed-off-by: Sergiu Moga <sergiu.moga@microchip.com>
---
 drivers/tty/serial/atmel_serial.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 0a0b46ee0955..c29b1fb48694 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -298,9 +298,6 @@ static int atmel_config_rs485(struct uart_port *port, struct ktermios *termios,
 
 	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)
@@ -310,6 +307,7 @@ static int atmel_config_rs485(struct uart_port *port, struct ktermios *termios,
 
 		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");
-- 
2.25.1


             reply	other threads:[~2022-08-24 11:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-24 11:42 Sergiu Moga [this message]
2022-08-24 12:02 ` [PATCH] tty: serial: atmel: Preserve previous USART mode if RS485 disabled Ilpo Järvinen
2022-08-24 13:01   ` Sergiu.Moga

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220824114255.444655-1-sergiu.moga@microchip.com \
    --to=sergiu.moga@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=claudio@evidence.eu.com \
    --cc=claudiu.beznea@microchip.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=michael@evidence.eu.com \
    --cc=nicolas.ferre@microchip.com \
    --cc=richard.genoud@gmail.com \
    --cc=rick@efn.org \
    --cc=rmk+kernel@arm.linux.org.uk \
    --cc=ryan@bluewatersys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).