netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <JBottomley@Novell.com>
To: Michael Chan <mchan@broadcom.com>
Cc: 'Mike Frysinger' <vapier@gentoo.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
Date: Wed, 16 Jun 2010 23:20:38 -0500	[thread overview]
Message-ID: <1276748438.2847.1190.camel@mulgrave.site> (raw)
In-Reply-To: <C27F8246C663564A84BB7AB3439772421B79CBCA1C@IRVEXCHCCR01.corp.ad.broadcom.com>

On Wed, 2010-06-16 at 20:53 -0700, Michael Chan wrote:
> Mike Frysinger wrote:
> 
> > On Wed, Jun 16, 2010 at 9:13 PM, James Bottomley wrote:
> > > I'm not quite sure whose fault this one is.
> > >
> > > However, this code in bnx2.c:
> > >
> > >                if (!get_dma_ops(&pdev->dev)->sync_single_for_cpu) {
> > >                        next_rx_buf =
> > >                                &rxr->rx_buf_ring[
> > >                                        RX_RING_IDX(NEXT_RX_BD(sw_cons))];
> > >                        prefetch(next_rx_buf->desc);
> > >                }
> > >
> > > Looks remarkably fragile: what exactly is it trying to do?
> 
> If sync_single is not defined, that means the CPU has a consistent
> view of next_rx_buf and so it makes sense to prefetch it.

That's not entirely a correct statement.  Many architectures make a DMA
area coherent by turning off the CPU cache over it.  In that case,
prefetching makes absolutely no sense (although it usually works but is
a nop).

> > > The commit that causes the problem:
> > >
> > > commit a33fa66bcf365ffe5b79d1ae1d3582cc261ae56e
> > > Author: Michael Chan <mchan@broadcom.com>
> > > Date:   Thu May 6 08:58:13 2010 +0000
> > >
> > >    bnx2: Add prefetches to rx path.
> > >
> > > Looks fairly innocuous by the description.
> > >
> > > Should parisc have a get_dma_ops()?  We don't need one
> > because our dma
> > > ops are per platform not per bus.
> >
> > looks like it'll be broken on more than just parisc:
> > $ grep get_dma_ops arch/*/include/asm/ -rl | cut -d/ -f 2
> > alpha
> > ia64
> > microblaze
> > powerpc
> > sh
> > sparc
> > x86
> 
> Most of these archs use the dma functions in:
> 
> <asm-genric/dma-mapping-common.h>
> 
> so it's not a problem.

Parisc begs to differ.

Plus you're making assumptions about the contents of the ops structure
which is an internal architecture object ... that's bound to run into
portability problems even if we make it compile on all platform.

> I think I'll send in a patch to remove that part of the code
> from bnx2.c for now.

I think that's the best solution.

James



  parent reply	other threads:[~2010-06-17  4:20 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-17  1:13 bnx2 fails to compile on parisc because of missing get_dma_ops() James Bottomley
2010-06-17  1:16 ` David Miller
2010-06-17 12:13   ` FUJITA Tomonori
2010-06-17  1:17 ` Mike Frysinger
2010-06-17  3:53   ` Michael Chan
2010-06-17  4:00     ` Mike Frysinger
2010-06-17  4:03     ` Paul Mundt
2010-06-17  4:10       ` Michael Chan
2010-06-17  6:24         ` Michael Chan
2010-06-17 12:21           ` FUJITA Tomonori
2010-06-17 14:36             ` David Miller
2010-06-17 14:50               ` FUJITA Tomonori
2010-06-17 15:30                 ` Paul Mundt
2010-06-22  6:30                   ` FUJITA Tomonori
2010-06-22 17:14                     ` Grant Grundler
2010-06-22 17:26                     ` James Bottomley
2010-06-23  0:38                       ` FUJITA Tomonori
2010-06-17  4:20     ` James Bottomley [this message]
2010-06-17 12:13     ` FUJITA Tomonori
2010-06-17 12:54       ` Michael Chan
2010-06-17 13:12         ` James Bottomley
2010-06-17 13:30           ` Michael Chan
2010-06-17 13:36             ` James Bottomley
2010-06-17 14:05             ` FUJITA Tomonori
2010-06-17 14:42               ` Michael Chan
2010-06-17 14:50               ` FUJITA Tomonori
2010-06-17 15:52                 ` David Miller
2010-06-17 12:13 ` FUJITA Tomonori

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=1276748438.2847.1190.camel@mulgrave.site \
    --to=jbottomley@novell.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=mchan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=vapier@gentoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).