This patch will be dropped.
Uploaded this change as v4 of an earlier patch.
Apologies for trouble.
On 5/2/2022 3:17 PM, Vijaya Krishna Nivarthi wrote:
For the case of console_suspend disabled, if back to back suspend/resume
test is executed, at the end of test, sometimes console would appear to
be frozen not responding to input. This would happen because, during
resume, rx transactions can come in before system is ready, malfunction
of rx happens in turn resulting in console appearing to be stuck.
Do a stop_rx in suspend sequence to prevent this.
Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@xxxxxxxxxxx>
---
drivers/tty/serial/serial_core.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 82a1770..e8c6875 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2211,9 +2211,16 @@ int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport)
}
put_device(tty_dev);
- /* Nothing to do if the console is not suspending */
- if (!console_suspend_enabled && uart_console(uport))
+ /*
+ * Nothing to do if the console is not suspending
+ * except stop_rx to prevent any asynchronous data
+ * over RX line. Re start_rx, when required, is
+ * done by set_termios in resume sequence
+ */
+ if (!console_suspend_enabled && uart_console(uport)) {
+ uport->ops->stop_rx(uport);
goto unlock;
+ }
uport->suspended = 1;
