From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Leonard Crestez <leonard.crestez@nxp.com>
Cc: Michael Walle <michael@walle.cc>,
"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jiri Slaby <jslaby@suse.com>, Andy Duan <fugang.duan@nxp.com>
Subject: Re: [PATCH v2 1/2] tty: serial: fsl_lpuart: move dma_request_chan()
Date: Thu, 26 Mar 2020 15:32:36 +0100 [thread overview]
Message-ID: <20200326143236.GA1372760@kroah.com> (raw)
In-Reply-To: <VI1PR04MB69417B19A6FFF0AA22585884EECE0@VI1PR04MB6941.eurprd04.prod.outlook.com>
On Wed, Mar 25, 2020 at 06:05:16PM +0000, Leonard Crestez wrote:
> On 2020-03-25 11:07 AM, Michael Walle wrote:
> > Move dma_request_chan() out of the atomic context. First this call
> > should not be in the atomic context at all and second the
> > dev_info_once() may cause a hang because because the console takes this
> > spinlock, too.
> >
> > Fixes: 159381df1442f ("tty: serial: fsl_lpuart: fix DMA operation when using IOMMU")
> > Reported-by: Leonard Crestez <leonard.crestez@nxp.com>
> > Signed-off-by: Michael Walle <michael@walle.cc>
> > ---
> > changes since v1:
> > - instead of just moving the dev_info_once() out of the spinlock protected
> > section, move the whole dma_request_chan(). Thanks Andy!
> >
> > I've tested this on my board. Andy, Leonard, can you double check it? For
> > all which are not aware, this deadlock happens only if you have the kernel
> > console output on the lpuart, so if someone wants to test it, make sure you
> > have something like console=ttyLP0,115200.
> >
> > drivers/tty/serial/fsl_lpuart.c | 36 +++++++++++++++++++++------------
> > 1 file changed, 23 insertions(+), 13 deletions(-)
>
> Tested-by: Leonard Crestez <leonard.crestez@nxp.com>
>
> Since the original commit only made it into next it might make sense to
> squash the commits in the tty tree.
>
> This way future bisections won't get stuck on a boot failure.
My tree does not rebase, sorry. And neither should any other public git
tree without really really good reasons.
thanks,
greg k-h
prev parent reply other threads:[~2020-03-26 14:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 9:06 [PATCH v2 1/2] tty: serial: fsl_lpuart: move dma_request_chan() Michael Walle
2020-03-25 9:06 ` [PATCH v2 2/2] tty: serial: fsl_lpuart: fix return value checking Michael Walle
2020-03-25 10:07 ` [EXT] " Andy Duan
2020-03-25 10:03 ` [EXT] [PATCH v2 1/2] tty: serial: fsl_lpuart: move dma_request_chan() Andy Duan
2020-03-25 18:05 ` Leonard Crestez
2020-03-26 14:32 ` Greg Kroah-Hartman [this message]
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=20200326143236.GA1372760@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=fugang.duan@nxp.com \
--cc=jslaby@suse.com \
--cc=leonard.crestez@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=michael@walle.cc \
/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