Messages in this thread | | | Date | Wed, 1 Jun 2022 16:54:48 +0530 | Subject | Re: [V4] serial: core: Do stop_rx in suspend path for console if console_suspend is disabled | From | Vijaya Krishna Nivarthi <> |
| |
Hi,
On 5/24/2022 5:24 PM, Marek Szyprowski wrote: > On 23.05.2022 23:32, Marek Szyprowski wrote: >> Hi, >> >> On 16.05.2022 11:20, 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@quicinc.com> >>> --- >>> v4: moved the change to serial core to apply for all drivers >>> v3: swapped the order of conditions to be more human readable >>> v2: restricted patch to contain only stop_rx in suspend sequence >>> v1: intial patch contained 2 additional unrelated changes in vicinity >>> --- >> This patch landed recently in linux-next as commit c9d2325cdb92 >> ("serial: core: Do stop_rx in suspend path for console if >> console_suspend is disabled"). >> >> Unfortunately it breaks console operation on my test systems after >> system suspend/resume cycle if 'no_console_suspend' kernel parameter >> is present. System properly resumes from suspend, the console displays >> all the messages and even command line prompt, but then doesn't react >> on any input. If I remove the 'no_console_suspend' parameter, the >> console is again operational after system suspend/resume cycle. Before >> this patch it worked fine regardless the 'no_console_suspend' parameter. >> >> If this matters, the test system is ARM 32bit Samsung Exynos5422-based >> Odroid XU3lite board. > > One more information. This issue can be easily reproduced with QEMU. It > happens both on ARM 32bit and ARM 64bit QEMU's 'virt' machines when > 'no_console_suspend' is added to kernel's cmdline. > Ideally, as comments indicate, the set_termios should have done stop_rx at begin and start_rx at end to take care of this issue.
This is probably missing in your driver. Can we check if this can be fixed? OR other option is
Add a start_rx in uart_resume_port after call to set_termios to handle this scenario for other drivers.
Please let me know if there are any concerns for this options.
>>> 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..9a85b41 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; >> Best regards > Best regards Thank you.
| |