Skip to contentSkip to conversation

serial: sh-sci: report CTS as active for get_mctrl

PATCH In review Yoshii Takashi 2 participants 4 messages Aug 23, 2011 – Aug 29, 2011

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 serial: sh-sci: report CTS as active for get_mctrl

Hi, anybody want to use RTS/CTS on sh-sci?

It does not seems to have been working for long time. Here is the one-line fix.

I'm not sure what is the optimal set of the "false" signal for get_mctrl. I guess it might be CD|DSR|CTS, but this patch does only minimum change.

Description follows...

sh-sci.c sets hardware up and then let the HW do all flow controls. There is no software code, nor needs to get/set real CTS signal.

But, when turning CRTSCTS on through termios, uart_set_termios() in serial_core.c checks CTS, and stops TX if it is inactive at the moment.

Because sci_get_mctrl() returns a fixed value DTR|RTS|DSR but CTS, the sequence
open -> set CRTSCTS -> write
hit the case and stop working, no more outputs.

This patch makes sci_get_mctrl() report CTS in addition.

---
 drivers/tty/serial/sh-sci.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/tty/serial/sh-sci.c +1 -1
index 7149a2c..e0229a4 100644
@@ -1076,7 +1076,7 @@ static unsigned int sci_get_mctrl(struct uart_port *port)
 	/* This routine is used for getting signals of: DTR, DCD, DSR, RI,
 	   and CTS/RTS */
 
-	return TIOCM_DTR | TIOCM_RTS | TIOCM_DSR;
+	return TIOCM_DTR | TIOCM_RTS | TIOCM_CTS | TIOCM_DSR;
 }
 
 #ifdef CONFIG_SERIAL_SH_SCI_DMA

-- 1.7.3.4

#1 lore raw
Quoted 16 lines · Yoshii Takashi

Hi, anybody want to use RTS/CTS on sh-sci?

It does not seems to have been working for long time. Here is the one-line fix.

I'm not sure what is the optimal set of the "false" signal for get_mctrl. I guess it might be CD|DSR|CTS, but this patch does only minimum change.

Description follows...

sh-sci.c sets hardware up and then let the HW do all flow controls. There is no software code, nor needs to get/set real CTS signal.

But, when turning CRTSCTS on through termios, uart_set_termios() in serial_core.c checks CTS, and stops TX if it is inactive at the moment.

Quoted 8 lines

Because sci_get_mctrl() returns a fixed value DTR|RTS|DSR but CTS, the sequence
open -> set CRTSCTS -> write
hit the case and stop working, no more outputs.

This patch makes sci_get_mctrl() report CTS in addition.

This looks reasonable, but what application specifically was hitting this? I'd like for this to hang around a bit before sending it off for -stable in any event. There are a lot of CPUs and port types to check..

#2 lore raw
In reply to Yoshii Takashi

Hi,

Quoted 2 lines

This looks reasonable, but what application specifically was hitting this? ...

Well, it was detected by pure test. So, actually, nobody is in trouble :) But I think it occurs on anything that use hardware flow control and write(TX). Even shell terminal session does. Try invoke "stty crtscts" on your shell. It will freeze your terminal session whatever its flow control setting is. Or, do like as followings on ssh session, is safer.

 $ stty -F /dev/ttySC1 clocal crtscts -echo
 $ echo x > /dev/ttySC1
Output 'x' on serial expected, but it stops and no output.

To make things clearer, I've made following test program and ran on sh7785lcr with free ttySC1 (not used for console, nor shell).

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <termios.h>

main(){
        struct termios t;
        int fd = open("/dev/ttySC1", O_RDWR);
        tcgetattr(fd, &t);
        t.c_cflag |= CRTSCTS;
        tcsetattr(fd, TCSANOW, &t);
        write(fd, "x", 1);
        close(fd);
}

Output 'x' and exit, is expected.
But no output and stops during "close" on last line.
More precisely, it is waiting for event on tty->write_wait at uart_close().

(In addition to close(), ioctl() will be also a case. It waits for outputs done)

/yoshii

#3 lore raw
In reply to Yoshii Takashi
Quoted 5 lines · On Wed, Aug 24, 2011 at 08:04:00PM +0900, [email protected] wrote:

Hi,

Quoted 2 lines

This looks reasonable, but what application specifically was hitting this? ...

Quoted 9 lines

Well, it was detected by pure test. So, actually, nobody is in trouble :) But I think it occurs on anything that use hardware flow control and write(TX). Even shell terminal session does. Try invoke "stty crtscts" on your shell. It will freeze your terminal session whatever its flow control setting is. Or, do like as followings on ssh session, is safer.

 $ stty -F /dev/ttySC1 clocal crtscts -echo
 $ echo x > /dev/ttySC1
Output 'x' on serial expected, but it stops and no output.

Ok, I've applied it as-is without a stable@ reference, as it's unlikely to be terribly critical going back. I'll let Greg decided whether to pick it up for stable or not.