On Sun, Feb 15, 2015 at 04:18:57PM +0800, Bob Liu wrote:
As Christoph suggested, remove the legacy support similar to most
drivers coverted (virtio, mtip, and nvme).
Please merge this into the previous patch.
___
Xen-devel mailing list
On Sun, Feb 15, 2015 at 04:18:55PM +0800, Bob Liu wrote:
History:
It's based on the result of Arianna's internship for GNOME's Outreach Program
for Women, in which she was mentored by Konrad Rzeszutek Wilk. I also worked
on
this patchset with her at that time, and now fully take over this
What happened to this patchset?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Fri, May 29, 2015 at 01:10:44AM +0200, Luis R. Rodriguez wrote:
Great, thanks. This seems to be in alignment with those who have all along
said
they've used EXPORT_SYMBOL() to mean what EXPORT_SYMBOL_GPL() users now use it
for. Nevertheless -- maintainers should know that some stubborn
Looks good,
Reviewed-by: Christoph Hellwig h...@lst.de
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
A little offtopic for this patch, but can some explain this whole
mess about bios in Xen blkfront? We can happily do partial completions
at the request later.
Also since the blk-mq conversion the call to blk_end_request_all is
completely broken, so it doesn't look like this code path is exactly
On Sat, Jul 11, 2015 at 07:17:18AM -0400, Konrad Rzeszutek Wilk wrote:
The 'locked' parameter can be used to tell the function to not take the lock.
But it would drop the lock in both cases.
Konrad,
no conditional locking please. Split the functionality up in multiple
functions if you may
On Wed, Jun 01, 2016 at 07:36:42AM +0200, Krzysztof Kozlowski wrote:
> > No really for this patch, but I would much prefer to document them next
> > to the code in the long run. Also I really think these BIT() macros
> > are a distraction compared to the (1 << N) notation.
>
> Not much
On Fri, Jan 29, 2016 at 11:01:00AM +, David Woodhouse wrote:
> Also, wasn't Christoph looking at making per-device DMA ops more
> generic instead of an 'archdata' thing on basically every platform? Or
> did I just imagine that part?
What I've done for 4.5 is to switch all architectures to use
I think this is moving into the wrong direction. The right fix here
is to get of all the dma_attrs boilerplate code and just replace it
with a simple enum dma_flags. This would simplify both the callers
and most importantly the wrappers for the flag-less versions a lot.
On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
> Regularly, when a new header is created in include/uapi/, the developer
> forgets to add it in the corresponding Kbuild file. This error is usually
> detected after the release is out.
>
> In fact, all headers under uapi
Btw, I really don't understand why this code even looks at bios over
just requeueing the request. Can someone explain that bit to me?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Fri, Jul 14, 2017 at 01:08:47PM -0400, Keith Busch wrote:
> > So LVM2 backed by md raid1 isn't compatible with newer hardware... Any
> > suggestions?
>
> It's not that LVM2 or RAID isn't compatible. Either the IOMMU isn't
> compatible if can use different page offsets for DMA addresses than
Looks good,
Reviewed-by: Christoph Hellwig <h...@lst.de>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Fri, Jun 16, 2017 at 08:10:15PM +0200, Christoph Hellwig wrote:
> I plan to create a new dma-mapping tree to collect all this work.
> Any volunteers for co-maintainers, especially from the iommu gang?
Ok, I've created the new tree:
git://git.infradead.org/users/hch/dma-mapping.git fo
On Tue, Jun 20, 2017 at 02:14:36PM +0100, Robin Murphy wrote:
> Hi Christoph,
>
> On 20/06/17 13:41, Christoph Hellwig wrote:
> > On Fri, Jun 16, 2017 at 08:10:15PM +0200, Christoph Hellwig wrote:
> >> I plan to create a new dma-mapping tree to collect all this work.
&g
On Tue, Jun 20, 2017 at 11:19:02AM +0200, Daniel Vetter wrote:
> Ack for the 2 drm patches, but I can also pick them up through drm-misc if
> you prefer that (but then it'll be 4.14).
Nah, I'll plan to set up a dma-mapping tree so that we'll have common
place for dma-mapping work.
On Tue, Jun 20, 2017 at 11:04:00PM +1000, Stephen Rothwell wrote:
> git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git#dma-mapping-next
>
> Contacts: Marek Szyprowski and Kyungmin Park (cc'd)
>
> I have called your tree dma-mapping-hch for now. The other tree has
> not been updated
On Wed, Jun 21, 2017 at 12:24:28PM -0700, tndave wrote:
> Thanks for doing this.
> So archs can still have their own definition for dma_set_mask() if
> HAVE_ARCH_DMA_SET_MASK is y?
> (and similarly for dma_set_coherent_mask() when
> CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK is y)
> Any plan to
On Wed, Jun 21, 2017 at 03:32:39PM +0200, Marek Szyprowski wrote:
> linux-next
> was a side effect of that. I think that for now it can be dropped in favor
> of
> Christoph's tree. I can also do some review and help in maintainers work if
> needed, although I was recently busy with other stuff.
>
On Sat, Jun 24, 2017 at 10:36:56AM -0500, Benjamin Herrenschmidt wrote:
> I think we still need to do it. For example we have a bunch new "funky"
> cases.
I have no plan to do away with the selection - I just want a better
interface than the current one.
Looks fine,
Reviewed-by: Christoph Hellwig <h...@lst.de>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/iommu/amd_iommu.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 63cacf
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/x86/kernel/pci-calgary_64.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kern
All dma_map_ops instances now handle their errors through
->mapping_error.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/x86/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/include/asm/dma-mapping.h
b/arch/x86/include/asm/dma-mappin
DMA_ERROR_CODE is going to go away, so don't rely on it. Instead
define a ->mapping_error method for all IOMMU based dma operation
instances. The direct ops don't ever return an error and don't
need a ->mapping_error method.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
ich means always supported.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/sparc/include/asm/dma-mapping.h | 3 ---
arch/sparc/kernel/iommu.c| 40 +++-
arch/sparc/kernel/ioport.c | 22 ++--
arch/sparc/kernel/pc
This implementation is simply bogus - hexagon only has a simple
direct mapped DMA implementation and thus doesn't care about the
address.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/hexagon/include/asm/dma-mapping.h | 2 --
arch/hexagon/kernel/dma.c | 9 --
And update the documentation - dma_mapping_error has been supported
everywhere for a long time.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
Documentation/DMA-API-HOWTO.txt | 31 +--
include/linux/dma-mapping.h | 5 -
2 files changed, 5 inse
And instead wire it up as method for all the dma_map_ops instances.
Note that this also means the arch specific check will be fully instead
of partially applied in the AMD iommu driver.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/x86/include/asm/dma-mapping.h | 3 ---
ar
This implementation is simply bogus - hexagon only has a simple
direct mapped DMA implementation and thus doesn't care about the
address.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/openrisc/include/asm/dma-mapping.h | 7 ---
1 file changed, 7 deletions(-)
diff --git
These just duplicate the default behavior if no method is provided.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
lib/dma-virt.c | 12
1 file changed, 12 deletions(-)
diff --git a/lib/dma-virt.c b/lib/dma-virt.c
index dcd4df1f7174..5c4f11329721 100644
--- a/lib/dma-
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/hexagon/include/asm/dma-mapping.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/hexagon/include/asm/dma-mapping.h
b/arch/hexagon/include/asm/dma-mapping.h
index 9c15cb5271a6..463dbc18f853 100644
--- a/arch/hexagon/include/a
These just duplicate the default behavior if no method is provided.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
lib/dma-noop.c | 12
1 file changed, 12 deletions(-)
diff --git a/lib/dma-noop.c b/lib/dma-noop.c
index de26c8b68f34..643a074f139d 100644
--- a/lib/dma-
And instead wire it up as method for all the dma_map_ops instances.
Note that the code seems a little fishy for dmabounce and iommu, but
for now I'd like to preserve the existing behavior 1:1.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/arm/common/dmabounce.c| 1 +
ar
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/arm/common/dmabounce.c| 16 ---
arch/arm/include/asm/dma-iommu.h | 2 ++
arch/arm/include/asm/dma-mapping.h | 1 -
arch/arm/mm/dma-mapping.c
We can just use pci32_dma_ops.
Btw, given that leon is 32-bit and appears to be PCI based, do even need
the special case for it in get_arch_dma_ops at all?
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/sparc/include/asm/dma-mapping.h | 3 +--
arch/sparc/kernel/ioport.c
The dma alloc interface returns an error by return NULL, and the
mapping interfaces rely on the mapping_error method, which the dummy
ops already implement correctly.
Thus remove the DMA_ERROR_CODE define.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/arm64/include/asm/dma-map
s390 can also use noop_dma_ops, and while that currently does not return
errors it will so in the future. Implementing the mapping_error method
is the proper way to have per-ops error conditions.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/s390/include/asm/dma-mapping.
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/sparc/include/asm/dma-mapping.h | 2 --
arch/sparc/kernel/iommu.c| 12 +---
arch/sparc/kernel/iommu_common.h | 2 ++
arch/sparc/kernel/pci_s
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/x86/kernel/pci-nommu.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c
index a88952
sh does not return errors for dma_map_page.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/sh/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/sh/include/asm/dma-mapping.h
b/arch/sh/include/asm/dma-mapping.h
index d99008af5f73..9b06be07db4d
xtensa already implements the mapping_error method for its only
dma_map_ops instance.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/xtensa/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/xtensa/include/asm/dma-mapping.h
b/arch/xtensa/include/a
microblaze does not return errors for dma_map_page.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/microblaze/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/microblaze/include/asm/dma-mapping.h
b/arch/microblaze/include/asm/dma-mapping.h
dma-noop is the only dma_mapping_ops instance for m32r and does not return
errors.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/m32r/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/m32r/include/asm/dma-mapping.h
b/arch/m32r/include/a
All ia64 dma_mapping_ops instances already have a mapping_error member.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/ia64/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/ia64/include/asm/dma-mapping.h
b/arch/ia64/include/asm/dma-mapping.h
openrisc does not return errors for dma_map_page.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/openrisc/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/openrisc/include/asm/dma-mapping.h
b/arch/openrisc/include/asm/dma-mapping.h
index 0c0075
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/c6x/include/asm/dma-mapping.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/c6x/include/asm/dma-mapping.h
b/arch/c6x/include/asm/dma-mapping.h
index aca9f755e4f8..05daf1038111 100644
--- a/arch/c6x/include/asm/dma-map
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/hexagon/include/asm/dma-mapping.h | 2 --
arch/hexagon/kernel/dma.c | 12 +---
arch/hexagon/kernel/hexagon_ksyms.c| 1 -
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/hexagon/include/a
return 0.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index c77a5aced81a..d48fd7c918f8
DMA_ERROR_CODE is not a public API and will go away. Instead properly
unwind based on the loop counter.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/dma/ioat/init.c | 24 +++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/dm
Hi all,
for a while we have a generic implementation of the dma mapping routines
that call into per-arch or per-device operations. But right now there
still are various bits in the interfaces where don't clearly operate
on these ops. This series tries to clean up a lot of those (but not all
That way the driver doesn't have to rely on DMA_ERROR_CODE, which
is not a public API and going away.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/net/ethernet/ibm/ibmveth.c | 159 +
1 file changed, 74 insertions(+), 85 deletions(-)
diff
DMA_ERROR_CODE is not a public API and will go away soon. dma dma-iommu
driver already implements a proper ->mapping_error method, so it's only
using the value internally. Add a new local define using the value
that arm64 which is the only current user of dma-iommu.
Signed-off-by: Christ
dev_addr isn't even a dma_addr_t, and DMA_ERROR_CODE has never been
a valid driver API. Add a bool mapped flag instead.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/gpu/drm/armada/armada_fb.c | 2 +-
drivers/gpu/drm/armada/armada_gem.c | 5 ++---
drivers/gpu/drm/
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/xen/swiotlb-xen.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index a0f006
This just duplicates the generic implementation.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/xen/swiotlb-xen.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index c3a04b2d7532..82fc54f8eb77
Same behavior, less code duplication.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/mips/loongson64/common/dma-swiotlb.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/arch/mips/loongson64/common/dma-swiotlb.c
b/arch/mips/loongson64/comm
Same behavior, less code duplication.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/arm/common/dmabounce.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c
index 4aabf117e136..d89a0b56b245
Besides removing the last instance of the set_dma_mask method this also
reduced the code duplication.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/powerpc/platforms/cell/iommu.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/arch/p
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/powerpc/kernel/dma.c | 4
include/linux/dma-mapping.h | 6 --
2 files changed, 10 deletions(-)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 41c749586bd2..466c9f07b288 100644
--- a/arch/powerpc/
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/powerpc/include/asm/dma-mapping.h | 1 -
arch/powerpc/kernel/dma.c | 13 -
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/a
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
include/linux/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index a57875309bfd..3e5908656226 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-map
These just duplicate the default behavior if no method is provided.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/tile/kernel/pci-dma.c | 30 --
1 file changed, 30 deletions(-)
diff --git a/arch/tile/kernel/pci-dma.c b/arch/tile/kernel/pci-dma.c
By the time cell_pci_dma_dev_setup calls cell_dma_dev_setup no device can
have the fixed map_ops set yet as it's only set by the set_dma_mask
method. So move the setup for the fixed case to be only called in that
place instead of indirecting through cell_dma_dev_setup.
Signed-off-by: Christoph
for xen_swiotlb_dma_ops can now be marked
static as well.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/arm/xen/mm.c | 17
arch/x86/xen/pci-swiotlb-xen.c | 14 ---
drivers/xen/swiotlb-xen.c | 93 ++
include/xen/swiotlb-xen.h
DMA_ERROR_CODE is not supposed to be used by drivers.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/firmware/tegra/ivc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/tegra/ivc.c b/drivers/firmware/tegra/ivc.c
index 29ecfd
Besides removing the last instance of the set_dma_mask method this also
reduced the code duplication.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/powerpc/platforms/cell/iommu.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/arch/p
This just duplicates the generic implementation.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/xen/swiotlb-xen.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index c3a04b2d7532..82fc54f8eb77
These just duplicate the default behavior if no method is provided.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/tile/kernel/pci-dma.c | 30 --
1 file changed, 30 deletions(-)
diff --git a/arch/tile/kernel/pci-dma.c b/arch/tile/kernel/pci-dma.c
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/powerpc/include/asm/dma-mapping.h | 1 -
arch/powerpc/kernel/dma.c | 13 -
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/a
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/powerpc/kernel/dma.c | 4
include/linux/dma-mapping.h | 6 --
2 files changed, 10 deletions(-)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 41c749586bd2..466c9f07b288 100644
--- a/arch/powerpc/
This implementation is simply bogus - openrisc only has a simple
direct mapped DMA implementation and thus doesn't care about the
address.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/openrisc/include/asm/dma-mapping.h | 7 ---
1 file changed, 7 deletions(-)
diff --git
Same behavior, less code duplication.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/arm/common/dmabounce.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c
index 6ecd5be5d37e..9a92de63426f
By the time cell_pci_dma_dev_setup calls cell_dma_dev_setup no device can
have the fixed map_ops set yet as it's only set by the set_dma_mask
method. So move the setup for the fixed case to be only called in that
place instead of indirecting through cell_dma_dev_setup.
Signed-off-by: Christoph
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/c6x/include/asm/dma-mapping.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/c6x/include/asm/dma-mapping.h
b/arch/c6x/include/asm/dma-mapping.h
index aca9f755e4f8..05daf1038111 100644
--- a/arch/c6x/include/asm/dma-map
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
drivers/xen/swiotlb-xen.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers
DMA_ERROR_CODE is not supposed to be used by drivers.
Signed-off-by: Christoph Hellwig <h...@lst.de>
Acked-by: Thierry Reding <tred...@nvidia.com>
---
drivers/firmware/tegra/ivc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/tegra/ivc
dev_addr isn't even a dma_addr_t, and DMA_ERROR_CODE has never been
a valid driver API. Add a bool mapped flag instead.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/gpu/drm/armada/armada_fb.c | 2 +-
drivers/gpu/drm/armada/armada_gem.c | 5 ++---
drivers/gpu/drm/
for xen_swiotlb_dma_ops can now be marked
static as well.
Signed-off-by: Christoph Hellwig <h...@lst.de>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
---
arch/arm/xen/mm.c | 17
arch/x86/xen/pci-swiotlb-xen.c | 14 ---
drivers/xen/swiotlb-xen
return 0.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index c77a5aced81a..d48fd7c918f8
That way the driver doesn't have to rely on DMA_ERROR_CODE, which
is not a public API and going away.
Signed-off-by: Christoph Hellwig <h...@lst.de>
Acked-by: David S. Miller <da...@davemloft.net>
---
drivers/net/ethernet/ibm/ibmveth.c | 159 +
1
DMA_ERROR_CODE is not a public API and will go away. Instead properly
unwind based on the loop counter.
Signed-off-by: Christoph Hellwig <h...@lst.de>
Acked-by: Dave Jiang <dave.ji...@intel.com>
Acked-By: Vinod Koul <vinod.k...@intel.com>
---
drivers/dm
Hi all,
for a while we have a generic implementation of the dma mapping routines
that call into per-arch or per-device operations. But right now there
still are various bits in the interfaces where don't clearly operate
on these ops. This series tries to clean up a lot of those (but not all
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/arm/common/dmabounce.c| 13 +---
arch/arm/include/asm/dma-iommu.h | 2 ++
arch/arm/include/asm/dma-mapping.h | 1 -
arch/arm/mm/dma-mapping.c
Signed-off-by: Christoph Hellwig <h...@lst.de>
Acked-by: Richard Kuo <r...@codeaurora.org>
---
arch/hexagon/include/asm/dma-mapping.h | 2 --
arch/hexagon/kernel/dma.c | 12 +---
arch/hexagon/kernel/hexagon_ksyms.c| 1 -
3 files changed, 9 insertions(+),
DMA_ERROR_CODE is not a public API and will go away soon. dma dma-iommu
driver already implements a proper ->mapping_error method, so it's only
using the value internally. Add a new local define using the value
that arm64 which is the only current user of dma-iommu.
Signed-off-by: Christ
microblaze does not return errors for dma_map_page.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/microblaze/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/microblaze/include/asm/dma-mapping.h
b/arch/microblaze/include/asm/dma-mapping.h
All ia64 dma_mapping_ops instances already have a mapping_error member.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/ia64/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/ia64/include/asm/dma-mapping.h
b/arch/ia64/include/asm/dma-mapping.h
sh does not return errors for dma_map_page.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/sh/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/sh/include/asm/dma-mapping.h
b/arch/sh/include/asm/dma-mapping.h
index d99008af5f73..9b06be07db4d
openrisc does not return errors for dma_map_page.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/openrisc/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/openrisc/include/asm/dma-mapping.h
b/arch/openrisc/include/asm/dma-mapping.h
index 0c0075
dma-noop is the only dma_mapping_ops instance for m32r and does not return
errors.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/m32r/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/m32r/include/asm/dma-mapping.h
b/arch/m32r/include/a
xtensa already implements the mapping_error method for its only
dma_map_ops instance.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/xtensa/include/asm/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/xtensa/include/asm/dma-mapping.h
b/arch/xtensa/include/a
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/iommu/amd_iommu.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 63cacf
And update the documentation - dma_mapping_error has been supported
everywhere for a long time.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
Documentation/DMA-API-HOWTO.txt | 31 +--
include/linux/dma-mapping.h | 5 -
2 files changed, 5 inse
The dma alloc interface returns an error by return NULL, and the
mapping interfaces rely on the mapping_error method, which the dummy
ops already implement correctly.
Thus remove the DMA_ERROR_CODE define.
Signed-off-by: Christoph Hellwig <h...@lst.de>
Reviewed-by: Robin Murphy <
s390 can also use noop_dma_ops, and while that currently does not return
errors it will so in the future. Implementing the mapping_error method
is the proper way to have per-ops error conditions.
Signed-off-by: Christoph Hellwig <h...@lst.de>
Acked-by: Gerald Schaefer <gerald.schae...@d
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
Acked-by: David S. Miller <da...@davemloft.net>
---
arch/sparc/include/asm/dma-mapping.h | 2 --
arch/sparc/kernel/iommu.c| 12 +---
arch/sparc/kernel/io
DMA_ERROR_CODE is going to go away, so don't rely on it.
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
arch/x86/kernel/pci-nommu.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c
index a88952
DMA_ERROR_CODE is going to go away, so don't rely on it. Instead
define a ->mapping_error method for all IOMMU based dma operation
instances. The direct ops don't ever return an error and don't
need a ->mapping_error method.
Signed-off-by: Christoph Hellwig <h...@lst.de>
Acked
1 - 100 of 120 matches
Mail list logo
