From: Greg KH <gregkh@linuxfoundation.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
Sergei Shtylyov <sergei.shtylyov@gmail.com>,
Jiri Slaby <jirislaby@kernel.org>,
"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH v3] serial: sh-sci: Stop dmaengine transfer in sci_stop_tx()
Date: Thu, 10 Jun 2021 09:01:52 +0200 [thread overview]
Message-ID: <YMG44NgJVTB5tbfI@kroah.com> (raw)
In-Reply-To: <CAMuHMdU23gB8Bap3qoypXkJhu=jwS-MQ=mu-CdzqijoWzc4rOg@mail.gmail.com>
On Thu, Jun 10, 2021 at 08:58:04AM +0200, Geert Uytterhoeven wrote:
> Hi Shimoda-san,
>
> On Thu, Jun 10, 2021 at 2:50 AM Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com> wrote:
> > > From: Geert Uytterhoeven, Sent: Thursday, June 10, 2021 12:30 AM
> > > On Wed, Jun 9, 2021 at 5:09 PM Sergei Shtylyov
> > > <sergei.shtylyov@gmail.com> wrote:
> > > > On 6/9/21 4:49 AM, Yoshihiro Shimoda wrote:
> > > > > Stop dmaengine transfer in sci_stop_tx(). Otherwise, the following
> > > > > message is possible output when system enters suspend and while
> > > > > transferring data, because clearing TIE bit in SCSCR is not able to
> > > > > stop any dmaengine transfer.
> > > > >
> > > > > sh-sci e6550000.serial: ttySC1: Unable to drain transmitter
> > > > >
> > > > > Note that this patch uses dmaengine_terminate_async() so that
> > > > > we can apply this patch into longterm kernel v4.9.x or later.
> > > > >
> > > > > Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.")
> > > > > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > > > > ---
> > > > >
> > > > > drivers/tty/serial/sh-sci.c | 8 ++++++++
> > > > > 1 file changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> > > > > index 4baf1316ea72..2d5487bf6855 100644
> > > > > --- a/drivers/tty/serial/sh-sci.c
> > > > > +++ b/drivers/tty/serial/sh-sci.c
> > > > > @@ -610,6 +610,14 @@ static void sci_stop_tx(struct uart_port *port)
> > > > > ctrl &= ~SCSCR_TIE;
> > > > >
> > > > > serial_port_out(port, SCSCR, ctrl);
> > > > > +
> > > > > +#ifdef CONFIG_SERIAL_SH_SCI_DMA
> > > >
> > > > Why not use IS_ENABLED() instead? Gets rid of #ifdef. :-)
> > > >
> > > > > + if (to_sci_port(port)->chan_tx &&
> > > > > + !dma_submit_error(to_sci_port(port)->cookie_tx)) {
> > > > > + dmaengine_terminate_async(to_sci_port(port)->chan_tx);
> > > > > + to_sci_port(port)->cookie_tx = -EINVAL;
> > >
> > > Because chan_tx and cookie_tx do not exist if CONFIG_SERIAL_SH_SCI_DMA
> > > is disabled.
> >
> > This is a nit though, chan_tx always exists.
>
> I stand corrected, only cookie_tx depends on CONFIG_SERIAL_SH_SCI_DMA.
>
> > > Yes, that's why all the DMA code in this driver (.c file) is protected by
> > > #ifdef CONFIG_SERIAL_SH_SCI_DMA.
> >
> > I'm thinking we have to remove #ifdef from sh-sci.c file at first...
>
> While I don't disagree that would be worthwhile, do we really need
> to refactor a driver first, before a fix that follows the existing
> driver style can be applied (and backported)?
No we do not. Sorry if this usage is already in the driver, might as
well keep it there, I thought this was an exception and was being added
for the first time here.
thanks,
greg k-h
next prev parent reply other threads:[~2021-06-10 7:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-09 1:49 [PATCH v3] serial: sh-sci: Stop dmaengine transfer in sci_stop_tx() Yoshihiro Shimoda
2021-06-09 12:29 ` Sergei Shtylyov
2021-06-09 15:30 ` Geert Uytterhoeven
2021-06-10 0:50 ` Yoshihiro Shimoda
2021-06-10 6:58 ` Geert Uytterhoeven
2021-06-10 7:01 ` Greg KH [this message]
2021-06-10 7:28 ` Yoshihiro Shimoda
2021-06-09 12:37 ` Greg KH
2021-06-10 0:44 ` Yoshihiro Shimoda
2021-06-09 12:37 ` Greg KH
2021-06-10 0:45 ` Yoshihiro Shimoda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YMG44NgJVTB5tbfI@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=geert@linux-m68k.org \
--cc=jirislaby@kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=sergei.shtylyov@gmail.com \
--cc=yoshihiro.shimoda.uh@renesas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox