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


Groups > linux.kernel > #1204067 > unrolled thread

[PATCH 3.2 047/110] stmmac: troubleshoot unexpected bits in des0 & des1

Started byBen Hutchings <ben@decadent.org.uk>
First post2015-08-10 12:20 +0200
Last post2015-08-11 22:30 +0200
Articles 3 — 2 participants

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 3.2 047/110] stmmac: troubleshoot unexpected bits in des0  & des1 Ben Hutchings <ben@decadent.org.uk> - 2015-08-10 12:20 +0200
    Re: [PATCH 3.2 047/110] stmmac: troubleshoot unexpected bits in  des0 & des1 Alexey Brodkin <Alexey.Brodkin@synopsys.com> - 2015-08-10 12:30 +0200
      Re: [PATCH 3.2 047/110] stmmac: troubleshoot unexpected bits in  des0 & des1 Ben Hutchings <ben@decadent.org.uk> - 2015-08-11 22:30 +0200

#1204067 — [PATCH 3.2 047/110] stmmac: troubleshoot unexpected bits in des0 & des1

FromBen Hutchings <ben@decadent.org.uk>
Date2015-08-10 12:20 +0200
Subject[PATCH 3.2 047/110] stmmac: troubleshoot unexpected bits in des0 & des1
Message-ID<pVSlu-3cZ-91@gated-at.bofh.it>
3.2.71-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>

commit f1590670ce069eefeb93916391a67643e6ad1630 upstream.

Current implementation of descriptor init procedure only takes
care about setting/clearing ownership flag in "des0"/"des1"
fields while it is perfectly possible to get unexpected bits
set because of the following factors:

 [1] On driver probe underlying memory allocated with
     dma_alloc_coherent() might not be zeroed and so
     it will be filled with garbage.

 [2] During driver operation some bits could be set by SD/MMC
     controller (for example error flags etc).

And unexpected and/or randomly set flags in "des0"/"des1"
fields may lead to unpredictable behavior of GMAC DMA block.

This change addresses both items above with:

 [1] Use of dma_zalloc_coherent() instead of simple
     dma_alloc_coherent() to make sure allocated memory is
     zeroed. That shouldn't affect performance because
     this allocation only happens once on driver probe.

 [2] Do explicit zeroing of both "des0" and "des1" fields
     of all buffer descriptors during initialization of
     DMA transfer.

And while at it fixed identation of dma_free_coherent()
counterpart as well.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: arc-linux-dev@synopsys.com
Cc: linux-kernel@vger.kernel.org
Cc: David Miller <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.2:
 - Adjust context, indentation
 - Normal and extended descriptors are allocated in the same place here]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
--- a/drivers/net/ethernet/stmicro/stmmac/descs.h
+++ b/drivers/net/ethernet/stmicro/stmmac/descs.h
@@ -153,6 +153,8 @@ struct dma_desc {
 			u32 buffer2_size:13;
 			u32 reserved4:3;
 		} etx;		/* -- enhanced -- */
+
+		u64 all_flags;
 	} des01;
 	unsigned int des2;
 	unsigned int des3;
--- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
@@ -232,6 +232,7 @@ static void enh_desc_init_rx_desc(struct
 {
 	int i;
 	for (i = 0; i < ring_size; i++) {
+		p->des01.all_flags = 0;
 		p->des01.erx.own = 1;
 		p->des01.erx.buffer1_size = BUF_SIZE_8KiB - 1;
 
@@ -248,7 +249,7 @@ static void enh_desc_init_tx_desc(struct
 	int i;
 
 	for (i = 0; i < ring_size; i++) {
-		p->des01.etx.own = 0;
+		p->des01.all_flags = 0;
 		ehn_desc_tx_set_on_ring_chain(p, (i == ring_size - 1));
 		p++;
 	}
--- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
@@ -126,6 +126,7 @@ static void ndesc_init_rx_desc(struct dm
 {
 	int i;
 	for (i = 0; i < ring_size; i++) {
+		p->des01.all_flags = 0;
 		p->des01.rx.own = 1;
 		p->des01.rx.buffer1_size = BUF_SIZE_2KiB - 1;
 
@@ -141,7 +142,7 @@ static void ndesc_init_tx_desc(struct dm
 {
 	int i;
 	for (i = 0; i < ring_size; i++) {
-		p->des01.tx.own = 0;
+		p->des01.all_flags = 0;
 		ndesc_tx_set_on_ring_chain(p, (i == (ring_size - 1)));
 		p++;
 	}
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -441,19 +441,17 @@ static void init_dma_desc_rings(struct n
 	priv->rx_skbuff =
 	    kmalloc(sizeof(struct sk_buff *) * rxsize, GFP_KERNEL);
 	priv->dma_rx =
-	    (struct dma_desc *)dma_alloc_coherent(priv->device,
-						  rxsize *
-						  sizeof(struct dma_desc),
-						  &priv->dma_rx_phy,
-						  GFP_KERNEL);
+	    (struct dma_desc *)dma_zalloc_coherent(priv->device, rxsize *
+						   sizeof(struct dma_desc),
+						   &priv->dma_rx_phy,
+						   GFP_KERNEL);
 	priv->tx_skbuff = kmalloc(sizeof(struct sk_buff *) * txsize,
 				       GFP_KERNEL);
 	priv->dma_tx =
-	    (struct dma_desc *)dma_alloc_coherent(priv->device,
-						  txsize *
-						  sizeof(struct dma_desc),
-						  &priv->dma_tx_phy,
-						  GFP_KERNEL);
+	    (struct dma_desc *)dma_zalloc_coherent(priv->device, txsize *
+						   sizeof(struct dma_desc),
+						   &priv->dma_tx_phy,
+						   GFP_KERNEL);
 
 	if ((priv->dma_rx == NULL) || (priv->dma_tx == NULL)) {
 		pr_err("%s:ERROR allocating the DMA Tx/Rx desc\n", __func__);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1204092 — Re: [PATCH 3.2 047/110] stmmac: troubleshoot unexpected bits in des0 & des1

FromAlexey Brodkin <Alexey.Brodkin@synopsys.com>
Date2015-08-10 12:30 +0200
SubjectRe: [PATCH 3.2 047/110] stmmac: troubleshoot unexpected bits in des0 & des1
Message-ID<pVSva-3oY-69@gated-at.bofh.it>
In reply to#1204067
Hi Ben,

On Mon, 2015-08-10 at 12:12 +-0200, Ben Hutchings wrote:
+AD4- 3.2.71-rc1 review patch.  If anyone has any objections, please let me know.
+AD4- 
+AD4- ------------------
+AD4- 
+AD4- From: Alexey Brodkin +ADw-Alexey.Brodkin+AEA-synopsys.com+AD4-
+AD4- 
+AD4- commit f1590670ce069eefeb93916391a67643e6ad1630 upstream.
+AD4- 
+AD4- Current implementation of descriptor init procedure only takes
+AD4- care about setting/clearing ownership flag in +ACI-des0+ACI-/+ACI-des1+ACI-
+AD4- fields while it is perfectly possible to get unexpected bits
+AD4- set because of the following factors:
+AD4- 
+AD4-  +AFs-1+AF0- On driver probe underlying memory allocated with
+AD4-      dma+AF8-alloc+AF8-coherent() might not be zeroed and so
+AD4-      it will be filled with garbage.
+AD4- 
+AD4-  +AFs-2+AF0- During driver operation some bits could be set by SD/MMC
+AD4-      controller (for example error flags etc).
+AD4- 
+AD4- And unexpected and/or randomly set flags in +ACI-des0+ACI-/+ACI-des1+ACI-
+AD4- fields may lead to unpredictable behavior of GMAC DMA block.
+AD4- 
+AD4- This change addresses both items above with:
+AD4- 
+AD4-  +AFs-1+AF0- Use of dma+AF8-zalloc+AF8-coherent() instead of simple
+AD4-      dma+AF8-alloc+AF8-coherent() to make sure allocated memory is
+AD4-      zeroed. That shouldn't affect performance because
+AD4-      this allocation only happens once on driver probe.
+AD4- 
+AD4-  +AFs-2+AF0- Do explicit zeroing of both +ACI-des0+ACI- and +ACI-des1+ACI- fields
+AD4-      of all buffer descriptors during initialization of
+AD4-      DMA transfer.
+AD4- 
+AD4- And while at it fixed identation of dma+AF8-free+AF8-coherent()
+AD4- counterpart as well.
+AD4- 
+AD4- Signed-off-by: Alexey Brodkin +ADw-abrodkin+AEA-synopsys.com+AD4-
+AD4- Cc: Giuseppe Cavallaro +ADw-peppe.cavallaro+AEA-st.com+AD4-
+AD4- Cc: arc-linux-dev+AEA-synopsys.com
+AD4- Cc: linux-kernel+AEA-vger.kernel.org
+AD4- Cc: David Miller +ADw-davem+AEA-davemloft.net+AD4-
+AD4- Signed-off-by: David S. Miller +ADw-davem+AEA-davemloft.net+AD4-
+AD4- +AFs-bwh: Backported to 3.2:
+AD4-  - Adjust context, indentation
+AD4-  - Normal and extended descriptors are allocated in the same place here+AF0-
+AD4- Signed-off-by: Ben Hutchings +ADw-ben+AEA-decadent.org.uk+AD4-

This patch looks good to me.

Moreover that was exactly what I initially done on top of 3.18, see
https://github.com/foss-for-synopsys-dwc-arc-processors/linux/commit/f2105b2ba9b3444568b32caca1ab253b88058fc2

So feel free to add Acked-by and/or Tested-by: Alexey Brodkin +ADw-abrodkin+AEA-synopsys.com+AD4-

-Alexey--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


#1205420 — Re: [PATCH 3.2 047/110] stmmac: troubleshoot unexpected bits in des0 & des1

FromBen Hutchings <ben@decadent.org.uk>
Date2015-08-11 22:30 +0200
SubjectRe: [PATCH 3.2 047/110] stmmac: troubleshoot unexpected bits in des0 & des1
Message-ID<pWoll-7xh-31@gated-at.bofh.it>
In reply to#1204092

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2015-08-10 at 10:23 +0000, Alexey Brodkin wrote:
> Hi Ben,
> 
> On Mon, 2015-08-10 at 12:12 +0200, Ben Hutchings wrote:
> > 3.2.71-rc1 review patch.  If anyone has any objections, please let 
> > me know.
> > 
> > ------------------
> > 
> > From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
> > 
> > commit f1590670ce069eefeb93916391a67643e6ad1630 upstream.
[...]
> This patch looks good to me.
> 
> Moreover that was exactly what I initially done on top of 3.18, see
> https://github.com/foss-for-synopsys-dwc-arc
> -processors/linux/commit/f2105b2ba9b3444568b32caca1ab253b88058fc2
> 
> So feel free to add Acked-by and/or Tested-by: Alexey Brodkin <
> abrodkin@synopsys.com>

You didn't say you tested 3.2.71-rc1, so I've added your Acked-by.
Thanks.

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
                                - John Levine, moderator of comp.compilers

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web