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

From: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com>
To: Doug Anderson <dianders@chromium.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jirislaby@kernel.org>, <linux-serial@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>, <quic_msavaliy@quicinc.com>,
	Matthias Kaehlcke <mka@chromium.org>,
	"Stephen Boyd" <swboyd@chromium.org>
Subject: Re: [V4] serial: core: Do stop_rx in suspend path for console if console_suspend is disabled
Date: Mon, 6 Jun 2022 18:00:39 +0530	[thread overview]
Message-ID: <a7e8b822-a33d-ff50-e740-4884c44813e7@quicinc.com> (raw)
In-Reply-To: <CAD=FV=UyNgfYe2Xh3uuYYHB4yPajZKO+i8nCngFn7TedbF-piA@mail.gmail.com>

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