Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1681522 > unrolled thread

[PATCH v2 1/6] serial: imx: only set DMA rx-ing when DMA starts

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v2 1/6] serial: imx: only set DMA rx-ing when DMA starts Romain Perier <romain.perier@collabora.com> - 2017-07-05 15:10 +0200
    Re: [PATCH v2 1/6] serial: imx: only set DMA rx-ing when DMA starts Uwe Kleine-König          <u.kleine-koenig@pengutronix.de> - 2017-07-05 15:30 +0200
      Re: [PATCH v2 1/6] serial: imx: only set DMA rx-ing when DMA starts Romain Perier <romain.perier@collabora.com> - 2017-07-06 10:40 +0200
        Re: [PATCH v2 1/6] serial: imx: only set DMA rx-ing when DMA starts Uwe Kleine-König          <u.kleine-koenig@pengutronix.de> - 2017-07-06 12:10 +0200

#1681522 — [PATCH v2 1/6] serial: imx: only set DMA rx-ing when DMA starts

From: Nandor Han <nandor.han@ge.com>

Avoid the situation when `dma_is_rxing` could incorrectly signal that
DMA RX channel is receiving data in case DMA preparation or sg mapping
fails.

This commit fixes the issues by moving the assignment of dma_is_rxing
out of imx_disable_rx_int(), then the variable is set to 1 from
start_rx_dma() only when the preparation is correctly done.

Signed-off-by: Nandor Han <nandor.han@ge.com>
Signed-off-by: Romain Perier <romain.perier@collabora.com>
---
 drivers/tty/serial/imx.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 3bae4ea..01df430 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -729,8 +729,6 @@ static void imx_disable_rx_int(struct imx_port *sport)
 {
 	unsigned long temp;
 
-	sport->dma_is_rxing = 1;
-
 	/* disable the receiver ready and aging timer interrupts */
 	temp = readl(sport->port.membase + UCR1);
 	temp &= ~(UCR1_RRDYEN);
@@ -1083,6 +1081,7 @@ static int start_rx_dma(struct imx_port *sport)
 	desc->callback_param = sport;
 
 	dev_dbg(dev, "RX: prepare for the DMA.\n");
+	sport->dma_is_rxing = 1;
 	sport->rx_cookie = dmaengine_submit(desc);
 	dma_async_issue_pending(chan);
 	return 0;
-- 
1.8.3.1

[toc] | [next] | [standalone]

#1681537

Hello,

On Wed, Jul 05, 2017 at 03:07:01PM +0200, Romain Perier wrote:
> From: Nandor Han <nandor.han@ge.com>
> 
> Avoid the situation when `dma_is_rxing` could incorrectly signal that
> DMA RX channel is receiving data in case DMA preparation or sg mapping
> fails.
> 
> This commit fixes the issues by moving the assignment of dma_is_rxing
> out of imx_disable_rx_int(), then the variable is set to 1 from
> start_rx_dma() only when the preparation is correctly done.

I'd write:

	There are a few issues with setting dma_is_rxing to 1 in
	imx_disable_rx_int:

	 - Currently always after imx_disable_rx_int() the function
	   start_rx_dma() is called. This dependency isn't obvious though.
	 - start_rx_dma() does error checking and might exit without enabling
	   DMA but keeping dma_is_rxing 1.

	So the more natural place for setting dma_is_rxing to 1 is in
	start_rx_dma after all errors are checked.

If you use this, there is nothing left of Nandor Han's patch and you can
drop his authorship.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[toc] | [prev] | [next] | [standalone]

#1682193

Hello,


Le 05/07/2017 à 15:29, Uwe Kleine-König a écrit :
> Hello,
>
> On Wed, Jul 05, 2017 at 03:07:01PM +0200, Romain Perier wrote:
>> From: Nandor Han <nandor.han@ge.com>
>>
>> Avoid the situation when `dma_is_rxing` could incorrectly signal that
>> DMA RX channel is receiving data in case DMA preparation or sg mapping
>> fails.
>>
>> This commit fixes the issues by moving the assignment of dma_is_rxing
>> out of imx_disable_rx_int(), then the variable is set to 1 from
>> start_rx_dma() only when the preparation is correctly done.
> I'd write:
>
> 	There are a few issues with setting dma_is_rxing to 1 in
> 	imx_disable_rx_int:
>
> 	 - Currently always after imx_disable_rx_int() the function
> 	   start_rx_dma() is called. This dependency isn't obvious though.
> 	 - start_rx_dma() does error checking and might exit without enabling
> 	   DMA but keeping dma_is_rxing 1.
>
> 	So the more natural place for setting dma_is_rxing to 1 is in
> 	start_rx_dma after all errors are checked.
>
> If you use this, there is nothing left of Nandor Han's patch and you can
> drop his authorship.
>
> Best regards
> Uwe
>
Ok, will do. No other feedback for the rest of the series ? (just to
know if I send a v3 or If I wait a bit...)

Thanks,
Romain

[toc] | [prev] | [next] | [standalone]

#1682306

On Thu, Jul 06, 2017 at 10:31:38AM +0200, Romain Perier wrote:
> Hello,
> 
> 
> Le 05/07/2017 à 15:29, Uwe Kleine-König a écrit :
> > Hello,
> >
> > On Wed, Jul 05, 2017 at 03:07:01PM +0200, Romain Perier wrote:
> >> From: Nandor Han <nandor.han@ge.com>
> >>
> >> Avoid the situation when `dma_is_rxing` could incorrectly signal that
> >> DMA RX channel is receiving data in case DMA preparation or sg mapping
> >> fails.
> >>
> >> This commit fixes the issues by moving the assignment of dma_is_rxing
> >> out of imx_disable_rx_int(), then the variable is set to 1 from
> >> start_rx_dma() only when the preparation is correctly done.
> > I'd write:
> >
> > 	There are a few issues with setting dma_is_rxing to 1 in
> > 	imx_disable_rx_int:
> >
> > 	 - Currently always after imx_disable_rx_int() the function
> > 	   start_rx_dma() is called. This dependency isn't obvious though.
> > 	 - start_rx_dma() does error checking and might exit without enabling
> > 	   DMA but keeping dma_is_rxing 1.
> >
> > 	So the more natural place for setting dma_is_rxing to 1 is in
> > 	start_rx_dma after all errors are checked.
> >
> > If you use this, there is nothing left of Nandor Han's patch and you can
> > drop his authorship.
> >
> > Best regards
> > Uwe
> >
> Ok, will do. No other feedback for the rest of the series ? (just to
> know if I send a v3 or If I wait a bit...)

I didn't come around looking in the patches I didn't comment yet.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web