All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Joe Perches <joe@perches.com>
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Francois Romieu <romieu@fr.zoreil.com>,
	Vineet Gupta <Vineet.Gupta1@synopsys.com>,
	Mischa Jonker <Mischa.Jonker@synopsys.com>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <rob.herring@calxeda.com>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	"David S. Miller" <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	Florian Fainelli <florian@openwrt.org>
Subject: Re: [PATCH v7] ethernet/arc/arc_emac - Add new driver
Date: Fri, 21 Jun 2013 17:58:25 +0200	[thread overview]
Message-ID: <201306211758.26094.arnd@arndb.de> (raw)
In-Reply-To: <1371825813.19215.34.camel@joe-AO722>

On Friday 21 June 2013, Joe Perches wrote:
> On Fri, 2013-06-21 at 10:53 +0000, Alexey Brodkin wrote:
> > On 06/21/2013 02:32 PM, Joe Perches wrote:
> > > On Fri, 2013-06-21 at 11:20 +0400, Alexey Brodkin wrote:
> > >> Driver for non-standard on-chip ethernet device ARC EMAC 10/100,
> > >> instantiated in some legacy ARC (Synopsys) FPGA Boards such as
> > >> ARCAngel4/ML50x.
> []
> > >> +          rxbd->data = (unsigned char *)cpu_to_le32(rx_buff->skb->data);
> > >
> > > 32 bit only.  Should the Kconfig block have some arch_arc dependency
> > > so it can't get compiled for 64 bit systems?
> []
> > So for now I may easily add dependency on ARC if it makes acceptance of 
> > driver easier.
> 
> I don't think it's a big problem.
> 
> Maybe add a Kconfig "depends on !64BIT".
> 
> Another thing to do would be to run it through sparse
> with make C=1

No, I think the driver should just be made 64-bit clean. Not because
anyone is going to need that of course, but to avoid having
to add silly dependencies.

The problem is that rxbd->data is the wrong type. It is declared
as a void*, but it is not a kernel pointer at all, it is a DMA
pointer. Look at this code in context:


+               addr = dma_map_single(&ndev->dev, (void *)rx_buff->skb->data,
+                                     buflen, DMA_FROM_DEVICE);
+               if (dma_mapping_error(&ndev->dev, addr)) {
+                       if (net_ratelimit())
+                               netdev_err(ndev, "cannot dma map\n");
+                       dev_kfree_skb(rx_buff->skb);
+                       stats->rx_errors++;
+                       continue;
+               }
+               dma_unmap_addr_set(&rx_buff, mapping, addr);
+               dma_unmap_len_set(&rx_buff, len, buflen);
+
+               rxbd->data = (unsigned char *)cpu_to_le32(rx_buff->skb->data);

the 'addr' returned by dma_map_single is what the device really
needs, although it is the same as rx_buff->skb->data with the
trivial definition of dma_map_single.

The last line here needs to be

		rxbd->data = cpu_to_le32(addr);

which fixes the bug, and has no dependency on a 32 bit CPU.

	Arnd

  reply	other threads:[~2013-06-21 15:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-21  7:20 [PATCH v7] ethernet/arc/arc_emac - Add new driver Alexey Brodkin
2013-06-21  7:20 ` Alexey Brodkin
2013-06-21 10:32 ` Joe Perches
2013-06-21 10:53   ` Alexey Brodkin
2013-06-21 12:15     ` Andy Shevchenko
2013-06-21 12:25       ` Alexey Brodkin
2013-06-21 12:40         ` Andy Shevchenko
2013-06-21 14:43     ` Joe Perches
2013-06-21 15:58       ` Arnd Bergmann [this message]
2013-06-21 16:05         ` Joe Perches
2013-06-21 16:22           ` David Laight
2013-06-21 16:22             ` David Laight
2013-06-21 18:27       ` David Miller

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=201306211758.26094.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=Alexey.Brodkin@synopsys.com \
    --cc=Mischa.Jonker@synopsys.com \
    --cc=Vineet.Gupta1@synopsys.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=davem@davemloft.net \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=florian@openwrt.org \
    --cc=grant.likely@linaro.org \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=rob.herring@calxeda.com \
    --cc=romieu@fr.zoreil.com \
    /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.