答复: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment

[杨勇 <yangyong@neusoft.com>]

Hello,
Motioned to the memory aligned, now there is such requirement:
When the driver send an packet to hardware, the skb's address passed by
stack do a dma map into hardware, the skb's dma address must be 64-byte
aligned.
My method:
 Allocate a new skb which is 64-byte aligned, then copy the passed skb to
new one
After test, the driver can work and overcome this issue.
But I eager to get a perfect solution about that, could you offer me a nice
one? Thanks so much~~

Code：
static struct sk_buff * skb_align_copy(const struct sk_buff *skb, gfp_t
gfp_mask)
{
    if((skb->len + LEN_INFO_BYTES) > 2000 ){
        atomic_inc(&proc_stat[PROC_STAT_JUMBO_CNT]);
        return NULL;
    }    

    struct sk_buff *n;
    n = alloc_skb(2048, gfp_mask);  //0 headroom
    if(!n)
        return NULL;

    atomic_inc(&proc_stat[PROC_STAT_SKB_ALLOC]);
    skb_put(n, skb->len + LEN_INFO_BYTES);

    if((skb->data - LEN_INFO_BYTES) == NULL){
        c_err("skb->data - LEN_INFO_BYTES is NULL!\n");
        return NULL;
    }    
    memcpy(n->data, skb->data - LEN_INFO_BYTES, skb->len + LEN_INFO_BYTES);
    return n;
}
static int ne_pcie_tx_map(struct ne_pcie_ring* tx_ring, struct sk_buff* skb)
{
    struct ne_pcie_buff* buff;
    struct sk_buff* align_skb;
    int i = tx_ring->next_to_use;
    int len = skb->len;
    int count = 0;

    align_skb = skb_align_copy(skb, GFP_ATOMIC);
    if(!align_skb){
        goto dma_map_error;
    }

    buff = &tx_ring->buffer[i];
    buff->length = len+LEN_INFO_BYTES;
    buff->dma = pci_map_single(tx_ring->pci_dev, align_skb->data,
            len+LEN_INFO_BYTES, PCI_DMA_TODEVICE);
    if (pci_dma_mapping_error(tx_ring->pci_dev, buff->dma)) {
        goto dma_map_error;
    }



-----邮件原件-----
发件人: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
代表 Holger Brunck
发送时间: 2011年6月17日 16:31
收件人: linuxppc-dev@lists.ozlabs.org
抄送: Clive Stubbings; Holger Brunck; Pantelis Antoniou; Vitaly Bordug;
netdev@vger.kernel.org
主题: [PATCH] fs_enet: fix freescale FCC ethernet dp buffer alignment

From: Clive Stubbings <clive.stubbings@xentech.co.uk>

The RIPTR and TIPTR  (receive/transmit internal temporary data pointer),
used by microcode as a temporary buffer for data, must be 32-byte aligned
according to the RM for MPC8247.

Tested on mgcoge.

Signed-off-by: Clive Stubbings <clive.stubbings@xentech.co.uk>
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
cc: Vitaly Bordug <vbordug@ru.mvista.com>
cc: netdev@vger.kernel.org
---
This fixes a kernel crash on mgcoge when using SPI on CPM2 and
ethernet over FCC. Now fixed because the fcc driver now allocates
the space he really needs.

 drivers/net/fs_enet/mac-fcc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/fs_enet/mac-fcc.c b/drivers/net/fs_enet/mac-fcc.c
index 7a84e45..7583a95 100644
--- a/drivers/net/fs_enet/mac-fcc.c
+++ b/drivers/net/fs_enet/mac-fcc.c
@@ -105,7 +105,7 @@ static int do_pd_setup(struct fs_enet_private *fep)
 		goto out_ep;
 
 	fep->fcc.mem = (void __iomem *)cpm2_immr;
-	fpi->dpram_offset = cpm_dpalloc(128, 8);
+	fpi->dpram_offset = cpm_dpalloc(128, 32);
 	if (IS_ERR_VALUE(fpi->dpram_offset)) {
 		ret = fpi->dpram_offset;
 		goto out_fcccp;
-- 
1.7.1

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

---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) 
is intended only for the use of the intended recipient and may be confidential and/or privileged of 
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is 
not the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying 
is strictly prohibited, and may be unlawful.If you have received this communication in error,please 
immediately notify the sender by return e-mail, and delete the original message and all copies from 
your system. Thank you. 
---------------------------------------------------------------------------------------------------
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev