[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090709185505X.fujita.tomonori@lab.ntt.co.jp>
Date: Thu, 9 Jul 2009 18:55:30 +0900
From: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To: davem@...emloft.net
Cc: arnd@...db.de, fujita.tomonori@....ntt.co.jp,
sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org,
reif@...thlink.net
Subject: Re: [PATCH 2/5] sparc: use asm-generic/dma-mapping-common.h
On Mon, 06 Jul 2009 18:11:31 -0700 (PDT)
David Miller <davem@...emloft.net> wrote:
> From: Arnd Bergmann <arnd@...db.de>
> Date: Mon, 6 Jul 2009 10:26:28 +0200
>
> > On Monday 06 July 2009, FUJITA Tomonori wrote:
> >> +static inline struct dma_map_ops *get_dma_ops(struct device *dev)
> >> +{
> >> + return dma_ops;
> >> +}
> >> +
> >> +#define flush_write_buffers()
> >> +
> >> +#include <asm-generic/dma-mapping-common.h>
> >
> > I still think the flush_write_buffers() x86-ism should not be required
> > to use dma-mapping-common.h and only be used in arch/x86/kernel/pci-nommu.c
> > so you don't have to add dummy definitions to all architectures.
> >
> > See http://lkml.org/lkml/2009/6/30/134
> >
> > Otherwise, your series looks good!
>
> Since we have until the 2.6.32 merge window to merge this, why
> don't we take care of this flush_write_buffers() thing first?
>
> I'm completely fine with these changes otherwise, thanks!
The logic to move flush_write_buffers() from dma-mapping-common.h to
arch/x86/kernel/pci-nommu.c makes sense and it doesn't break anything.
However, I'd like to see the confirmation from a person who added
flush_write_buffers() long ago. I thought that we might overlook
something subtle.
I'll put Arnd's patch in the next submission if you like.
btw, Robert asked me about the dma-debug feature so I uploaded the new
version (I also found and fixed one bug wrt dma_{alloc|free}_coherent
for pci devices on SPARC32):
git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git sparc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists