[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=UyNgfYe2Xh3uuYYHB4yPajZKO+i8nCngFn7TedbF-piA@mail.gmail.com>
Date: Fri, 3 Jun 2022 12:28:38 -0700
From: Doug Anderson <dianders@...omium.org>
To: Vijaya Krishna Nivarthi <quic_vnivarth@...cinc.com>
Cc: Marek Szyprowski <m.szyprowski@...sung.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jirislaby@...nel.org>,
linux-serial@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
quic_msavaliy@...cinc.com, Matthias Kaehlcke <mka@...omium.org>,
Stephen Boyd <swboyd@...omium.org>
Subject: Re: [V4] serial: core: Do stop_rx in suspend path for console if
console_suspend is disabled
Hi,
On Fri, Jun 3, 2022 at 11:54 AM Vijaya Krishna Nivarthi
<quic_vnivarth@...cinc.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.
-Doug
Powered by blists - more mailing lists