Re: [V4] serial: core: Do stop_rx in suspend path for console if console_suspend is disabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,


On 6/4/2022 12:58 AM, Doug Anderson wrote:
Hi,

On Fri, Jun 3, 2022 at 11:54 AM Vijaya Krishna Nivarthi
<quic_vnivarth@xxxxxxxxxxx> wrote:
Add a start_rx in uart_resume_port after call to set_termios to handle
this scenario for other drivers.
Since start_rx is not exposed it doesn't seem like we will be able to
handle it in core.

In your drivers, Can we add a call to stop_rx at begin of set_termios
and then undo it at end?

That would ensure that set_termios functionality is unaffected while
fixing the broken cases?

If that's not an option we will have to go back to a previous version of
limiting the change to qcom driver.
How about this: add an optional start_rx() callback to "struct
uart_ops" and then only do your stop_rx() logic in uart_suspend_port()
if you'll be able to start it again (AKA if the start_rx() callback is
not NULL). That keeps the logic in the core.

This seems good. Thank you.

And also conditionally call start_rx in uart_resume_port after call to set_termios?
I have tested such patch and it is working fine, will upload it.

-Vijay/

-Doug



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux