Messages in this thread | | | Date | Mon, 6 Jun 2022 18:00:39 +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/4/2022 12:58 AM, Doug Anderson wrote: > Hi, > > On Fri, Jun 3, 2022 at 11:54 AM Vijaya Krishna Nivarthi > <quic_vnivarth@quicinc.com> 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
| |