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:Sure, just point me what need to be added in amba-pl011.c and
On 23.05.2022 23:32, Marek Szyprowski wrote:Ideally, as comments indicate, the set_termios should have done
Hi,One more information. This issue can be easily reproduced with QEMU. It
On 16.05.2022 11:20, Vijaya Krishna Nivarthi wrote:
For the case of console_suspend disabled, if back to backThis patch landed recently in linux-next as commit c9d2325cdb92
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>
---
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
---
("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.
happens both on ARM 32bit and ARM 64bit QEMU's 'virt' machines when
'no_console_suspend' is added to kernel's cmdline.
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?
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.
IMHO this looks like an issue that affects lots of drivers and it should
Please let me know if there are any concerns for this options.
be handled in the core.
Sure, we will look into both aspects and get back as soon as possible.
Thank you.
> ...
Best regards