diff mbox

sh_eth: fix descriptor access endianness

Message ID 11070795.yxBPvlHg4n@wasted.cogentembedded.com (mailing list archive)
State Awaiting Upstream
Delegated to: Simon Horman
Headers show

Commit Message

Sergei Shtylyov Dec. 13, 2015, 8:05 p.m. UTC 
The driver never  calls cpu_to_edmac() when writing the descriptor address
and edmac_to_cpu() when reading it, although it should -- fix this.

Note that the frame/buffer length descriptor field accesses also need fixing
but since they are both 16-bit we can't  use {cpu|edmac}_to_{edmac|cpu}()...

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
The patch is against DaveM's 'net.git' repo plus the patch I've posted today.

 drivers/net/ethernet/renesas/sh_eth.c |   24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)


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

Comments

Sergei Shtylyov Dec. 14, 2015, 4:53 p.m. UTC | #1 
Hello.

On 12/13/2015 11:05 PM, Sergei Shtylyov wrote:

> The driver never  calls cpu_to_edmac() when writing the descriptor address
> and edmac_to_cpu() when reading it, although it should -- fix this.
>
> Note that the frame/buffer length descriptor field accesses also need fixing
> but since they are both 16-bit we can't  use {cpu|edmac}_to_{edmac|cpu}()...

    Changed my mind about this one: I'll add a new pair of functions to deal 
with 16-bit conversions as well.

> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

[...]

MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller Dec. 15, 2015, 5:25 a.m. UTC | #2 
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 13 Dec 2015 23:05:07 +0300

> The driver never  calls cpu_to_edmac() when writing the descriptor address
> and edmac_to_cpu() when reading it, although it should -- fix this.
> 
> Note that the frame/buffer length descriptor field accesses also need fixing
> but since they are both 16-bit we can't  use {cpu|edmac}_to_{edmac|cpu}()...
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sergei Shtylyov Dec. 15, 2015, 11:26 a.m. UTC | #3 
Hello.

On 12/15/2015 8:25 AM, David Miller wrote:

>> The driver never  calls cpu_to_edmac() when writing the descriptor address
>> and edmac_to_cpu() when reading it, although it should -- fix this.
>>
>> Note that the frame/buffer length descriptor field accesses also need fixing
>> but since they are both 16-bit we can't  use {cpu|edmac}_to_{edmac|cpu}()...
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Applied.

    I was going to rework this to fix _all_ cases, and sent follow-up email 
about that yesterday... Haven't you received it?

MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller Dec. 15, 2015, 5:53 p.m. UTC | #4 
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Tue, 15 Dec 2015 14:26:51 +0300

> Hello.
> 
> On 12/15/2015 8:25 AM, David Miller wrote:
> 
>>> The driver never calls cpu_to_edmac() when writing the descriptor
>>> address
>>> and edmac_to_cpu() when reading it, although it should -- fix this.
>>>
>>> Note that the frame/buffer length descriptor field accesses also need
>>> fixing
>>> but since they are both 16-bit we can't use
>>> {cpu|edmac}_to_{edmac|cpu}()...
>>>
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> Applied.
> 
>    I was going to rework this to fix _all_ cases, and sent follow-up
>    email about that yesterday... Haven't you received it?

I saw it but you were not entirely clear whether you were going to do
that work in a follow-on patch or not.

If you don't clearly say "Dave, please drop this patch." expect me to
do random things.
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sergei Shtylyov Dec. 15, 2015, 6:06 p.m. UTC | #5 
On 12/15/2015 08:53 PM, David Miller wrote:

>>>> The driver never calls cpu_to_edmac() when writing the descriptor
>>>> address
>>>> and edmac_to_cpu() when reading it, although it should -- fix this.
>>>>
>>>> Note that the frame/buffer length descriptor field accesses also need
>>>> fixing
>>>> but since they are both 16-bit we can't use
>>>> {cpu|edmac}_to_{edmac|cpu}()...
>>>>
>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>>
>>> Applied.
>>
>>     I was going to rework this to fix _all_ cases, and sent follow-up
>>     email about that yesterday... Haven't you received it?
>
> I saw it but you were not entirely clear whether you were going to do
> that work in a follow-on patch or not.
>
> If you don't clearly say "Dave, please drop this patch." expect me to
> do random things.

    Previously I had a plan to get rid of never used EDMAC_BIG_ENDIAN and then 
get rid of {edmac|cpu}_to_{cpu|edmac}() and fix 16-bit descriptor R/W by using 
{cpu|le32}_to_{le32|cpu}(). How's that plan to you?

MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller Dec. 15, 2015, 6:26 p.m. UTC | #6 
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Tue, 15 Dec 2015 21:06:16 +0300

> On 12/15/2015 08:53 PM, David Miller wrote:
> 
>>>>> The driver never calls cpu_to_edmac() when writing the descriptor
>>>>> address
>>>>> and edmac_to_cpu() when reading it, although it should -- fix this.
>>>>>
>>>>> Note that the frame/buffer length descriptor field accesses also need
>>>>> fixing
>>>>> but since they are both 16-bit we can't use
>>>>> {cpu|edmac}_to_{edmac|cpu}()...
>>>>>
>>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>>>
>>>> Applied.
>>>
>>>     I was going to rework this to fix _all_ cases, and sent follow-up
>>>     email about that yesterday... Haven't you received it?
>>
>> I saw it but you were not entirely clear whether you were going to do
>> that work in a follow-on patch or not.
>>
>> If you don't clearly say "Dave, please drop this patch." expect me to
>> do random things.
> 
>    Previously I had a plan to get rid of never used EDMAC_BIG_ENDIAN and
>    then get rid of {edmac|cpu}_to_{cpu|edmac}() and fix 16-bit descriptor
>    R/W by using {cpu|le32}_to_{le32|cpu}(). How's that plan to you?

I personally don't care what work you do on this driver.

All I care about is that people communicate clearly with me when they
want me to take, or not take, a given patch.

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sergei Shtylyov Dec. 15, 2015, 7:02 p.m. UTC | #7 
Hello.

On 12/15/2015 09:06 PM, Sergei Shtylyov wrote:

>>>>> The driver never calls cpu_to_edmac() when writing the descriptor
>>>>> address
>>>>> and edmac_to_cpu() when reading it, although it should -- fix this.
>>>>>
>>>>> Note that the frame/buffer length descriptor field accesses also need
>>>>> fixing
>>>>> but since they are both 16-bit we can't use
>>>>> {cpu|edmac}_to_{edmac|cpu}()...
>>>>>
>>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>>>
>>>> Applied.
>>>
>>>     I was going to rework this to fix _all_ cases, and sent follow-up
>>>     email about that yesterday... Haven't you received it?
>>
>> I saw it but you were not entirely clear whether you were going to do
>> that work in a follow-on patch or not.
>>
>> If you don't clearly say "Dave, please drop this patch." expect me to
>> do random things.
>
>     Previously I had a plan to get rid of never used EDMAC_BIG_ENDIAN and then
> get rid of {edmac|cpu}_to_{cpu|edmac}() and fix 16-bit descriptor R/W by using
> {cpu|le32}_to_{le32|cpu}(). How's that plan to you?

   le16, of course.

MBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

Index: net/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net/drivers/net/ethernet/renesas/sh_eth.c
@@ -1172,7 +1172,7 @@  static void sh_eth_ring_format(struct ne
 			break;
 		}
 		mdp->rx_skbuff[i] = skb;
-		rxdesc->addr = dma_addr;
+		rxdesc->addr = cpu_to_edmac(mdp, dma_addr);
 		rxdesc->status = cpu_to_edmac(mdp, RD_RACT | RD_RFP);
 
 		/* Rx descriptor address set */
@@ -1403,7 +1403,8 @@  static int sh_eth_txfree(struct net_devi
 			   entry, edmac_to_cpu(mdp, txdesc->status));
 		/* Free the original skb. */
 		if (mdp->tx_skbuff[entry]) {
-			dma_unmap_single(&ndev->dev, txdesc->addr,
+			dma_unmap_single(&ndev->dev,
+					 edmac_to_cpu(mdp, txdesc->addr),
 					 txdesc->buffer_length, DMA_TO_DEVICE);
 			dev_kfree_skb_irq(mdp->tx_skbuff[entry]);
 			mdp->tx_skbuff[entry] = NULL;
@@ -1479,14 +1480,15 @@  static int sh_eth_rx(struct net_device *
 			if (desc_status & RD_RFS10)
 				ndev->stats.rx_over_errors++;
 		} else	if (skb) {
+			dma_addr = edmac_to_cpu(mdp, rxdesc->addr);
 			if (!mdp->cd->hw_swap)
 				sh_eth_soft_swap(
-					phys_to_virt(ALIGN(rxdesc->addr, 4)),
+					phys_to_virt(ALIGN(dma_addr, 4)),
 					pkt_len + 2);
 			mdp->rx_skbuff[entry] = NULL;
 			if (mdp->cd->rpadir)
 				skb_reserve(skb, NET_IP_ALIGN);
-			dma_unmap_single(&ndev->dev, rxdesc->addr,
+			dma_unmap_single(&ndev->dev, dma_addr,
 					 ALIGN(mdp->rx_buf_sz, 32),
 					 DMA_FROM_DEVICE);
 			skb_put(skb, pkt_len);
@@ -1523,7 +1525,7 @@  static int sh_eth_rx(struct net_device *
 			mdp->rx_skbuff[entry] = skb;
 
 			skb_checksum_none_assert(skb);
-			rxdesc->addr = dma_addr;
+			rxdesc->addr = cpu_to_edmac(mdp, dma_addr);
 		}
 		dma_wmb(); /* RACT bit must be set after all the above writes */
 		if (entry >= mdp->num_rx_ring - 1)
@@ -2331,8 +2333,8 @@  static void sh_eth_tx_timeout(struct net
 	/* Free all the skbuffs in the Rx queue. */
 	for (i = 0; i < mdp->num_rx_ring; i++) {
 		rxdesc = &mdp->rx_ring[i];
-		rxdesc->status = 0;
-		rxdesc->addr = 0xBADF00D0;
+		rxdesc->status = cpu_to_edmac(mdp, 0);
+		rxdesc->addr = cpu_to_edmac(mdp, 0xBADF00D0);
 		dev_kfree_skb(mdp->rx_skbuff[i]);
 		mdp->rx_skbuff[i] = NULL;
 	}
@@ -2350,6 +2352,7 @@  static int sh_eth_start_xmit(struct sk_b
 {
 	struct sh_eth_private *mdp = netdev_priv(ndev);
 	struct sh_eth_txdesc *txdesc;
+	dma_addr_t dma_addr;
 	u32 entry;
 	unsigned long flags;
 
@@ -2373,12 +2376,13 @@  static int sh_eth_start_xmit(struct sk_b
 	/* soft swap. */
 	if (!mdp->cd->hw_swap)
 		sh_eth_soft_swap(PTR_ALIGN(skb->data, 4), skb->len + 2);
-	txdesc->addr = dma_map_single(&ndev->dev, skb->data, skb->len,
-				      DMA_TO_DEVICE);
-	if (dma_mapping_error(&ndev->dev, txdesc->addr)) {
+	dma_addr = dma_map_single(&ndev->dev, skb->data, skb->len,
+				  DMA_TO_DEVICE);
+	if (dma_mapping_error(&ndev->dev, dma_addr)) {
 		kfree_skb(skb);
 		return NETDEV_TX_OK;
 	}
+	txdesc->addr = cpu_to_edmac(mdp, dma_addr);
 	txdesc->buffer_length = skb->len;
 
 	dma_wmb(); /* TACT bit must be set after all the above writes */