All of lore.kernel.org
 help / color / mirror / Atom feed
From: Murali Karicheri <m-karicheri2@ti.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "open list:TI NETCP ETHERNET DRIVER" <netdev@vger.kernel.org>
Subject: net: netcp: regarding commit 899077: netcp: try to reduce type confusion in descriptors
Date: Mon, 22 Feb 2016 16:48:14 -0500	[thread overview]
Message-ID: <56CB821E.7040809@ti.com> (raw)

Arnd,

As promised, here is what I found wrong with the commit 899077 that introduced a 
regression. With these changes, I am able to boot kernel without issues on K2 platforms.

>From the commit description, it appears that you are trying to make the driver do the right
thing if compiled for a 64 bit systems. Is it mandatory for all kernel drivers to be
64bit compliant? Similar question on supporting mixed endian in all kernel drivers.
Keystone can have SoC configured to be in big endian mode for peripherals and DSP. so that is
something we need to support if there is customer interest. Wondering why do one run BE kernel
binary on these platforms? Any reason? I saw some reference to that in past discussion on this
regression issue.

Murali


diff --git a/drivers/net/ethernet/ti/netcp_core.c b/drivers/net/ethernet/ti/netcp_core.c
index c61d66d..ac35161 100644
--- a/drivers/net/ethernet/ti/netcp_core.c
+++ b/drivers/net/ethernet/ti/netcp_core.c
@@ -167,7 +167,7 @@ static void set_pad_info(u32 pad0, u32 pad1, u32 pad2, struct knav_dma_desc *des
 {
        desc->pad[0] = cpu_to_le32(pad0);
        desc->pad[1] = cpu_to_le32(pad1);
-       desc->pad[2] = cpu_to_le32(pad1);
+       desc->pad[2] = cpu_to_le32(pad2);
 }
 
 static void set_org_pkt_info(dma_addr_t buff, u32 buff_len,
@@ -870,8 +870,8 @@ static int netcp_allocate_rx_buf(struct netcp_intf *netcp, int fdq)
                }
                buf_len = PAGE_SIZE;
                dma = dma_map_page(netcp->dev, page, 0, buf_len, DMA_TO_DEVICE);
-               pad[0] = lower_32_bits(dma);
-               pad[1] = upper_32_bits(dma);
+               pad[0] = lower_32_bits((uintptr_t)page);
+               pad[1] = upper_32_bits((uintptr_t)page);
                pad[2] = 0;
        }
 
@@ -1194,9 +1194,9 @@ static int netcp_tx_submit_skb(struct netcp_intf *netcp,
        }
 
        set_words(&tmp, 1, &desc->packet_info);
-       tmp = lower_32_bits((uintptr_t)&skb);
+       tmp = lower_32_bits((uintptr_t)skb);
        set_words(&tmp, 1, &desc->pad[0]);
-       tmp = upper_32_bits((uintptr_t)&skb);
+       tmp = upper_32_bits((uintptr_t)skb);
        set_words(&tmp, 1, &desc->pad[1]);
 
        if (tx_pipe->flags & SWITCH_TO_PORT_IN_TAGINFO) {

-- 
Murali Karicheri
Linux Kernel, Keystone

             reply	other threads:[~2016-02-22 21:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-22 21:48 Murali Karicheri [this message]
2016-02-22 22:13 ` net: netcp: regarding commit 899077: netcp: try to reduce type confusion in descriptors Arnd Bergmann
2016-02-22 23:09   ` Murali Karicheri
2016-02-24 12:47     ` Arnd Bergmann

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=56CB821E.7040809@ti.com \
    --to=m-karicheri2@ti.com \
    --cc=arnd@arndb.de \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.