Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <1652692810-31148-1-git-send-email-quic_vnivarth@quicinc.com>
 <bf7eec57-6ad6-2c1a-ea61-0e1d06fc77f5@samsung.com> <CGME20220524115408eucas1p1ddda7aae4db0a65a7d67d6f8c59d404b@eucas1p1.samsung.com>
 <3866c083-0064-ac9a-4587-91a83946525d@samsung.com> <ff029402-f90c-096a-7366-b58f53555ace@quicinc.com>
 <fb44af37-daf7-974d-95fe-1a6c2cdab676@samsung.com> <cb802fb1-d0b8-68af-1c04-f73bc1beca77@quicinc.com>
 <f525c352-d995-0589-584f-0e9acf419f80@quicinc.com>
In-Reply-To: <f525c352-d995-0589-584f-0e9acf419f80@quicinc.com>
From:   Doug Anderson <dianders@chromium.org>
Date:   Fri, 3 Jun 2022 12:28:38 -0700
Message-ID: <CAD=FV=UyNgfYe2Xh3uuYYHB4yPajZKO+i8nCngFn7TedbF-piA@mail.gmail.com>
Subject: Re: [V4] serial: core: Do stop_rx in suspend path for console if
 console_suspend is disabled
To:     Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com>
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>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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.

-Doug