Re: [PATCH 2/9] Move dma_ops from archdata into struct device

2017-01-11 Thread gre...@linuxfoundation.org 
On Wed, Jan 11, 2017 at 10:28:05PM +, Bart Van Assche wrote:
> On Wed, 2017-01-11 at 21:31 +0100, gre...@linuxfoundation.org wrote:
> > That's a big sign that your patch series needs work.  Break it up into
> > smaller pieces, it should be possible, which will make merges easier
> > (well, different in a way.)
> 
> Hello Greg,
> 
> Can you have a look at the attached patches? These three patches are a
> splitup of the single patch at the start of this e-mail thread.

Please send them in the proper format (i.e. one patch per email), and I
will be glad to review them.  Otherwise it's really hard to do so, would
you want to review attachments?

thanks,

greg k-h

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

2017-01-11 Thread Bart Van Assche 
On Wed, 2017-01-11 at 21:31 +0100, gre...@linuxfoundation.org wrote:
> That's a big sign that your patch series needs work.  Break it up into
> smaller pieces, it should be possible, which will make merges easier
> (well, different in a way.)

Hello Greg,

Can you have a look at the attached patches? These three patches are a
splitup of the single patch at the start of this e-mail thread.

Thanks,

Bart.From a6fe3a6db80f2bc359e049b72e13aa171fff6ffa Mon Sep 17 00:00:00 2001
From: Bart Van Assche 
Date: Wed, 11 Jan 2017 13:31:42 -0800
Subject: [PATCH 1/3] treewide: Move dma_ops from struct dev_archdata into
 struct device

This change is necessary to make the dma_ops pointer configurable
per device on architectures that do not yet implement set_dma_ops().

Signed-off-by: Bart Van Assche 
---
 arch/arm/include/asm/device.h| 1 -
 arch/arm/include/asm/dma-mapping.h   | 6 +++---
 arch/arm64/include/asm/device.h  | 1 -
 arch/arm64/include/asm/dma-mapping.h | 4 ++--
 arch/arm64/mm/dma-mapping.c  | 8 
 arch/m32r/include/asm/device.h   | 1 -
 arch/m32r/include/asm/dma-mapping.h  | 4 ++--
 arch/mips/include/asm/device.h   | 5 -
 arch/mips/include/asm/dma-mapping.h  | 4 ++--
 arch/mips/pci/pci-octeon.c   | 2 +-
 arch/powerpc/include/asm/device.h| 4 
 arch/powerpc/include/asm/dma-mapping.h   | 4 ++--
 arch/powerpc/kernel/dma.c| 2 +-
 arch/powerpc/platforms/cell/iommu.c  | 2 +-
 arch/powerpc/platforms/pasemi/iommu.c| 2 +-
 arch/powerpc/platforms/pasemi/setup.c| 2 +-
 arch/powerpc/platforms/ps3/system-bus.c  | 4 ++--
 arch/powerpc/platforms/pseries/ibmebus.c | 2 +-
 arch/s390/include/asm/device.h   | 1 -
 arch/s390/include/asm/dma-mapping.h  | 4 ++--
 arch/s390/pci/pci.c  | 2 +-
 arch/tile/include/asm/device.h   | 3 ---
 arch/tile/include/asm/dma-mapping.h  | 6 +++---
 arch/x86/include/asm/device.h| 3 ---
 arch/x86/include/asm/dma-mapping.h   | 4 ++--
 arch/x86/kernel/pci-calgary_64.c | 4 ++--
 arch/x86/pci/common.c| 2 +-
 arch/x86/pci/sta2x11-fixup.c | 8 
 arch/xtensa/include/asm/device.h | 4 
 arch/xtensa/include/asm/dma-mapping.h| 4 ++--
 drivers/infiniband/ulp/srpt/ib_srpt.c| 2 +-
 drivers/iommu/amd_iommu.c| 6 +++---
 drivers/misc/mic/bus/mic_bus.c   | 2 +-
 drivers/misc/mic/bus/scif_bus.c  | 2 +-
 include/linux/device.h   | 1 +
 35 files changed, 47 insertions(+), 69 deletions(-)

diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index d8a572f9c187..220ba207be91 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -7,7 +7,6 @@
 #define ASMARM_DEVICE_H
 
 struct dev_archdata {
-	const struct dma_map_ops	*dma_ops;
 #ifdef CONFIG_DMABOUNCE
 	struct dmabounce_device_info *dmabounce;
 #endif
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 1aabd781306f..312f4d0564d6 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -18,8 +18,8 @@ extern const struct dma_map_ops arm_coherent_dma_ops;
 
 static inline const struct dma_map_ops *__generic_dma_ops(struct device *dev)
 {
-	if (dev && dev->archdata.dma_ops)
-		return dev->archdata.dma_ops;
+	if (dev && dev->dma_ops)
+		return dev->dma_ops;
 	return _dma_ops;
 }
 
@@ -34,7 +34,7 @@ static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
 static inline void set_dma_ops(struct device *dev, const struct dma_map_ops *ops)
 {
 	BUG_ON(!dev);
-	dev->archdata.dma_ops = ops;
+	dev->dma_ops = ops;
 }
 
 #define HAVE_ARCH_DMA_SUPPORTED 1
diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index 00c678cc31e1..73d5bab015eb 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -17,7 +17,6 @@
 #define __ASM_DEVICE_H
 
 struct dev_archdata {
-	const struct dma_map_ops *dma_ops;
 #ifdef CONFIG_IOMMU_API
 	void *iommu;			/* private IOMMU data */
 #endif
diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index 1fedb43be712..58ae36cc3b60 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -29,8 +29,8 @@ extern const struct dma_map_ops dummy_dma_ops;
 
 static inline const struct dma_map_ops *__generic_dma_ops(struct device *dev)
 {
-	if (dev && dev->archdata.dma_ops)
-		return dev->archdata.dma_ops;
+	if (dev && dev->dma_ops)
+		return dev->dma_ops;
 
 	/*
 	 * We expect no ISA devices, and all other DMA masters are expected to
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index bcef6368d48f..dbab4c6c084b 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -837,7 +837,7 @@ static bool

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

2017-01-11 Thread gre...@linuxfoundation.org 
On Wed, Jan 11, 2017 at 06:17:03PM +, Bart Van Assche wrote:
> On Wed, 2017-01-11 at 07:48 +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> > > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> > > transfer data between memory and PCIe adapter. Because of performance
> > > reasons it is important that the CPU cache is not flushed when such
> > > drivers transfer data. Make this possible by allowing these drivers to
> > > override the dma_map_ops pointer. Additionally, introduce the function
> > > set_dma_ops() that will be used by a later patch in this series.
> > 
> > When you say things like "additionally", that's a huge flag that this
> > needs to be split up into multiple patches.  No need to add
> > set_dma_ops() here in this patch.
> 
> Hello Greg,
> 
> Some architectures already define a set_dma_ops() function. So what this
> patch does is to move both the dma_ops pointer and the set_dma_ops()
> function from architecture-specific to architecture independent code. I
> don't think that it is possible to separate these two changes. But I
> understand that how I formulated the patch description caused confusion. I
> will rewrite the patch description to make it more clear before I repost
> this patch series.

I think you should separate it out into multiple patches, this is a
mess, as you say below:

> > And I'd argue that it should be dma_ops_set(), and dma_ops_get(), just
> > to keep the namespace sane, but that's probably a different set of
> > patches...
> 
> Every time I rebase and retest this patch series on top of a new kernel
> version I have to modify some of the patches to compensate for changes in
> the architecture code. So I expect that once Linus merges these patches that
> he will have to resolve one or more merge conflicts. Including a rename of
> the functions that query and set the dma_ops pointer in this patch series
> would increase the number of merge conflicts triggered by this patch series
> and would make Linus' job harder. So I hope that you will allow me to
> postpone that rename until a later time ...

That's a big sign that your patch series needs work.  Break it up into
smaller pieces, it should be possible, which will make merges easier
(well, different in a way.)

Good luck, tree-wide changes are not simple.

greg k-h

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

2017-01-11 Thread gre...@linuxfoundation.org 
On Wed, Jan 11, 2017 at 06:03:15PM +, Bart Van Assche wrote:
> On Wed, 2017-01-11 at 07:46 +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> > > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> > > transfer data between memory and PCIe adapter. Because of performance
> > > reasons it is important that the CPU cache is not flushed when such
> > > drivers transfer data. Make this possible by allowing these drivers to
> > > override the dma_map_ops pointer. Additionally, introduce the function
> > > set_dma_ops() that will be used by a later patch in this series.
> > > 
> > > Signed-off-by: Bart Van Assche 
> > > Cc: [ ... ]
> > 
> > That's a crazy cc: list, you should break this up into smaller pieces,
> > otherwise it's going to bounce...
> 
> That's a subset of what scripts/get_maintainer.pl came up with. Suggestions
> for a more appropriate cc-list for a patch like this that touches all
> architectures would be welcome.

You need to break this patch up into a series that can be applied in
sequence, don't change everything all at once.  That's a mess to merge,
as you are finding out.

> > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > index 491b4c0ca633..c7cb225d36b0 100644
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -885,6 +885,8 @@ struct dev_links_info {
> > >   * a higher-level representation of the device.
> > >   */
> > >  struct device {
> > > + const struct dma_map_ops *dma_ops; /* See also get_dma_ops() */
> > > +
> > >   struct device   *parent;
> > >  
> > >   struct device_private   *p;
> > 
> > Why not put this new pointer down with the other dma fields in this
> > structure?  Any specific reason it needs to be first?
> 
> Are there CPU architectures for which access to the first member of a
> structure can be encoded and/or executed more efficiently than access to
> other members of a structure? If not, I'm fine with moving the new pointer
> further down.

Why do you think that your pointer is the one that gets to be "most
efficient"?  :)

Seriously, no, it doesn't matter at all, it's all just pointer math
which is very fast.  Put it with the other stuff please, don't try to
optimize something without ever measuring it.

thanks,

greg k-h

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

2017-01-11 Thread Bart Van Assche 
On Wed, 2017-01-11 at 07:48 +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> > transfer data between memory and PCIe adapter. Because of performance
> > reasons it is important that the CPU cache is not flushed when such
> > drivers transfer data. Make this possible by allowing these drivers to
> > override the dma_map_ops pointer. Additionally, introduce the function
> > set_dma_ops() that will be used by a later patch in this series.
> 
> When you say things like "additionally", that's a huge flag that this
> needs to be split up into multiple patches.  No need to add
> set_dma_ops() here in this patch.

Hello Greg,

Some architectures already define a set_dma_ops() function. So what this
patch does is to move both the dma_ops pointer and the set_dma_ops()
function from architecture-specific to architecture independent code. I
don't think that it is possible to separate these two changes. But I
understand that how I formulated the patch description caused confusion. I
will rewrite the patch description to make it more clear before I repost
this patch series.

> And I'd argue that it should be dma_ops_set(), and dma_ops_get(), just
> to keep the namespace sane, but that's probably a different set of
> patches...

Every time I rebase and retest this patch series on top of a new kernel
version I have to modify some of the patches to compensate for changes in
the architecture code. So I expect that once Linus merges these patches that
he will have to resolve one or more merge conflicts. Including a rename of
the functions that query and set the dma_ops pointer in this patch series
would increase the number of merge conflicts triggered by this patch series
and would make Linus' job harder. So I hope that you will allow me to
postpone that rename until a later time ...

Bart.

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

2017-01-11 Thread Bart Van Assche 
On Wed, 2017-01-11 at 07:46 +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> > transfer data between memory and PCIe adapter. Because of performance
> > reasons it is important that the CPU cache is not flushed when such
> > drivers transfer data. Make this possible by allowing these drivers to
> > override the dma_map_ops pointer. Additionally, introduce the function
> > set_dma_ops() that will be used by a later patch in this series.
> > 
> > Signed-off-by: Bart Van Assche 
> > Cc: [ ... ]
> 
> That's a crazy cc: list, you should break this up into smaller pieces,
> otherwise it's going to bounce...

That's a subset of what scripts/get_maintainer.pl came up with. Suggestions
for a more appropriate cc-list for a patch like this that touches all
architectures would be welcome.

> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 491b4c0ca633..c7cb225d36b0 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -885,6 +885,8 @@ struct dev_links_info {
> >   * a higher-level representation of the device.
> >   */
> >  struct device {
> > +   const struct dma_map_ops *dma_ops; /* See also get_dma_ops() */
> > +
> >     struct device   *parent;
> >  
> >     struct device_private   *p;
> 
> Why not put this new pointer down with the other dma fields in this
> structure?  Any specific reason it needs to be first?

Are there CPU architectures for which access to the first member of a
structure can be encoded and/or executed more efficiently than access to
other members of a structure? If not, I'm fine with moving the new pointer
further down.

Bart.

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

2017-01-10 Thread Greg Kroah-Hartman 
On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> transfer data between memory and PCIe adapter. Because of performance
> reasons it is important that the CPU cache is not flushed when such
> drivers transfer data. Make this possible by allowing these drivers to
> override the dma_map_ops pointer. Additionally, introduce the function
> set_dma_ops() that will be used by a later patch in this series.

When you say things like "additionally", that's a huge flag that this
needs to be split up into multiple patches.  No need to add
set_dma_ops() here in this patch.

And I'd argue that it should be dma_ops_set(), and dma_ops_get(), just
to keep the namespace sane, but that's probably a different set of
patches...

thanks,

greg k-h

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

2017-01-10 Thread Greg Kroah-Hartman 
On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote:
> Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
> transfer data between memory and PCIe adapter. Because of performance
> reasons it is important that the CPU cache is not flushed when such
> drivers transfer data. Make this possible by allowing these drivers to
> override the dma_map_ops pointer. Additionally, introduce the function
> set_dma_ops() that will be used by a later patch in this series.
> 
> Signed-off-by: Bart Van Assche 
> Cc: Greg Kroah-Hartman 
> Cc: Aurelien Jacquiot 
> Cc: Catalin Marinas 
> Cc: Chris Zankel 
> Cc: David Howells 
> Cc: David S. Miller 
> Cc: Fenghua Yu 
> Cc: Geert Uytterhoeven 
> Cc: Geoff Levand 
> Cc: H. Peter Anvin 
> Cc: Haavard Skinnemoen 
> Cc: Hans-Christian Egtvedt 
> Cc: Helge Deller 
> Cc: Ingo Molnar 
> Cc: James E.J. Bottomley 
> Cc: Jesper Nilsson 
> Cc: Joerg Roedel 
> Cc: Jon Mason 
> Cc: Jonas Bonn 
> Cc: Ley Foon Tan 
> Cc: Mark Salter 
> Cc: Max Filippov 
> Cc: Mikael Starvik 
> Cc: Muli Ben-Yehuda 
> Cc: Rich Felker 
> Cc: Russell King 
> Cc: Stafford Horne 
> Cc: Stefan Kristiansson 
> Cc: Thomas Gleixner 
> Cc: Tony Luck 
> Cc: Will Deacon 
> Cc: x...@kernel.org
> Cc: Yoshinori Sato 
> Cc: adi-buildroot-de...@lists.sourceforge.net
> Cc: io...@lists.linux-foundation.org
> Cc: linux-al...@vger.kernel.org
> Cc: linux-am33-l...@redhat.com
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-c6x-...@linux-c6x.org
> Cc: linux-cris-ker...@axis.com
> Cc: linux-hexa...@vger.kernel.org
> Cc: linux-i...@vger.kernel.org
> Cc: linux-m...@lists.linux-m68k.org
> Cc: linux-me...@vger.kernel.org
> Cc: linux-m...@linux-mips.org
> Cc: linux-par...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-r...@vger.kernel.org
> Cc: linux-s...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: linux-snps-...@lists.infradead.org
> Cc: linux-xte...@linux-xtensa.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: nios2-...@lists.rocketboards.org
> Cc: openr...@lists.librecores.org
> Cc: sparcli...@vger.kernel.org
> Cc: uclinux-h8-de...@lists.sourceforge.jp

That's a crazy cc: list, you should break this up into smaller pieces,
otherwise it's going to bounce...

> diff --git a/include/linux/device.h b/include/linux/device.h
> index 491b4c0ca633..c7cb225d36b0 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -885,6 +885,8 @@ struct dev_links_info {
>   * a higher-level representation of the device.
>   */
>  struct device {
> + const struct dma_map_ops *dma_ops; /* See also get_dma_ops() */
> +
>   struct device   *parent;
>  
>   struct device_private   *p;

Why not put this new pointer down with the other dma fields in this
structure?  Any specific reason it needs to be first?

thanks,

greg k-h

[PATCH 2/9] Move dma_ops from archdata into struct device

2017-01-10 Thread Bart Van Assche 
Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to
transfer data between memory and PCIe adapter. Because of performance
reasons it is important that the CPU cache is not flushed when such
drivers transfer data. Make this possible by allowing these drivers to
override the dma_map_ops pointer. Additionally, introduce the function
set_dma_ops() that will be used by a later patch in this series.

Signed-off-by: Bart Van Assche 
Cc: Greg Kroah-Hartman 
Cc: Aurelien Jacquiot 
Cc: Catalin Marinas 
Cc: Chris Zankel 
Cc: David Howells 
Cc: David S. Miller 
Cc: Fenghua Yu 
Cc: Geert Uytterhoeven 
Cc: Geoff Levand 
Cc: H. Peter Anvin 
Cc: Haavard Skinnemoen 
Cc: Hans-Christian Egtvedt 
Cc: Helge Deller 
Cc: Ingo Molnar 
Cc: James E.J. Bottomley 
Cc: Jesper Nilsson 
Cc: Joerg Roedel 
Cc: Jon Mason 
Cc: Jonas Bonn 
Cc: Ley Foon Tan 
Cc: Mark Salter 
Cc: Max Filippov 
Cc: Mikael Starvik 
Cc: Muli Ben-Yehuda 
Cc: Rich Felker 
Cc: Russell King 
Cc: Stafford Horne 
Cc: Stefan Kristiansson 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: Will Deacon 
Cc: x...@kernel.org
Cc: Yoshinori Sato 
Cc: adi-buildroot-de...@lists.sourceforge.net
Cc: io...@lists.linux-foundation.org
Cc: linux-al...@vger.kernel.org
Cc: linux-am33-l...@redhat.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-c6x-...@linux-c6x.org
Cc: linux-cris-ker...@axis.com
Cc: linux-hexa...@vger.kernel.org
Cc: linux-i...@vger.kernel.org
Cc: linux-m...@lists.linux-m68k.org
Cc: linux-me...@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: linux-par...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org
Cc: linux-xte...@linux-xtensa.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: nios2-...@lists.rocketboards.org
Cc: openr...@lists.librecores.org
Cc: sparcli...@vger.kernel.org
Cc: uclinux-h8-de...@lists.sourceforge.jp
---
 arch/alpha/include/asm/dma-mapping.h  |  2 +-
 arch/arc/include/asm/dma-mapping.h|  2 +-
 arch/arm/include/asm/device.h |  1 -
 arch/arm/include/asm/dma-mapping.h| 17 -
 arch/arm64/include/asm/device.h   |  1 -
 arch/arm64/include/asm/dma-mapping.h  |  8 
 arch/arm64/mm/dma-mapping.c   |  8 
 arch/avr32/include/asm/dma-mapping.h  |  2 +-
 arch/blackfin/include/asm/dma-mapping.h   |  2 +-
 arch/c6x/include/asm/dma-mapping.h|  2 +-
 arch/cris/include/asm/dma-mapping.h   |  4 ++--
 arch/frv/include/asm/dma-mapping.h|  2 +-
 arch/h8300/include/asm/dma-mapping.h  |  2 +-
 arch/hexagon/include/asm/dma-mapping.h|  5 +
 arch/ia64/include/asm/dma-mapping.h   |  5 -
 arch/m32r/include/asm/dma-mapping.h   |  4 +---
 arch/m68k/include/asm/dma-mapping.h   |  2 +-
 arch/metag/include/asm/dma-mapping.h  |  2 +-
 arch/microblaze/include/asm/dma-mapping.h |  2 +-
 arch/mips/include/asm/device.h|  5 -
 arch/mips/include/asm/dma-mapping.h   |  7 ++-
 arch/mips/pci/pci-octeon.c|  2 +-
 arch/mn10300/include/asm/dma-mapping.h|  2 +-
 arch/nios2/include/asm/dma-mapping.h  |  2 +-
 arch/openrisc/include/asm/dma-mapping.h   |  2 +-
 arch/parisc/include/asm/dma-mapping.h |  2 +-
 arch/powerpc/include/asm/device.h |  4 
 arch/powerpc/include/asm/dma-mapping.h| 17 ++---
 arch/powerpc/include/asm/ps3.h|  2 +-
 arch/powerpc/kernel/dma.c |  2 +-
 arch/powerpc/platforms/cell/iommu.c   |  2 +-
 arch/powerpc/platforms/pasemi/iommu.c |  2 +-
 arch/powerpc/platforms/pasemi/setup.c |  2 +-
 arch/powerpc/platforms/ps3/system-bus.c   |  4 ++--
 arch/powerpc/platforms/pseries/ibmebus.c  |  2 +-
 arch/s390/include/asm/device.h|  1 -
 arch/s390/include/asm/dma-mapping.h   |  4 +---
 arch/s390/pci/pci.c   |  2 +-
 arch/sh/include/asm/dma-mapping.h |  2 +-
 arch/sparc/include/asm/dma-mapping.h  |  4 ++--
 arch/tile/include/asm/device.h|  3 ---
 arch/tile/include/asm/dma-mapping.h   | 12 ++--
 arch/x86/include/asm/device.h |  3 ---
 arch/x86/include/asm/dma-mapping.h|  9 +
 arch/x86/kernel/pci-calgary_64.c  |  4