Messages in this thread | | | Date | Thu, 2 Jun 2022 21:12:31 +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 6/2/2022 3:55 AM, Marek Szyprowski wrote: > Hi, > > On 01.06.2022 13:24, Vijaya Krishna Nivarthi wrote: >> 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? > Sure, just point me what need to be added in amba-pl011.c and > samsung_tty.c. I've briefly compared the suspend/resume paths of those > drivers with other drivers and I don't see anything missing there. > >> 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. > IMHO this looks like an issue that affects lots of drivers and it should > be handled in the core.
Sure, we will look into both aspects and get back as soon as possible.
Thank you.
> > > ... > > Best regards
| |