Hi,
On 1/14/19 8:26 PM, Jonathan Cameron wrote:
On Thu, 10 Jan 2019 11:00:23 +0800
Lu Baolu wrote:
When multiple domains per device has been enabled by the
device driver, the device will tag the default PASID for
the domain to all DMA traffics out of the subset of this
device; and the IOMMU s
Hi,
On 1/14/19 7:22 PM, Jonathan Cameron wrote:
On Thu, 10 Jan 2019 11:00:20 +0800
Lu Baolu wrote:
Sharing a physical PCI device in a finer-granularity way
is becoming a consensus in the industry. IOMMU vendors
are also engaging efforts to support such sharing as well
as possible. Among the e
On Mon, 14 Jan 2019 21:48:06 +0100
Auger Eric wrote:
> Hi Alex,
>
> On 1/12/19 12:58 AM, Alex Williamson wrote:
> > On Tue, 8 Jan 2019 11:26:30 +0100
> > Eric Auger wrote:
> >
> >> This patch adds a new 64kB region aiming to report nested mode
> >> translation faults.
> >>
> >> The region c
On Fri, 11 Jan 2019 11:06:29 +
Jean-Philippe Brucker wrote:
> On 10/01/2019 18:45, Jacob Pan wrote:
> > On Tue, 8 Jan 2019 11:26:26 +0100
> > Eric Auger wrote:
> >
> >> From: Jacob Pan
> >>
> >> Device faults detected by IOMMU can be reported outside IOMMU
> >> subsystem for further pro
On Mon, Jan 14, 2019 at 03:49:07PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 11, 2019 at 10:12:31AM +0100, Joerg Roedel wrote:
> > On Thu, Jan 10, 2019 at 12:02:05PM -0500, Konrad Rzeszutek Wilk wrote:
> > > Why not use swiotlb_nr_tbl ? That is how drivers/gpu/drm use to figure if
> > > th
On Mon, 14 Jan 2019, Christoph Hellwig wrote:
> Instead of setting up a kernel pointer to track the current PIO address,
> track the offset in the current page, and do an atomic kmap for the page
> while doing the actual PIO operations.
>
> Signed-off-by: Christoph Hellwig
Just a small suggesti
On Fri, Jan 11, 2019 at 10:12:31AM +0100, Joerg Roedel wrote:
> On Thu, Jan 10, 2019 at 12:02:05PM -0500, Konrad Rzeszutek Wilk wrote:
> > Why not use swiotlb_nr_tbl ? That is how drivers/gpu/drm use to figure if
> > they
> > need to limit the size of pages.
>
> That function just exports the ove
On Mon, Jan 14, 2019 at 09:19:35PM +0100, Christoph Hellwig wrote:
> > Christoph is saying that !IOMMU_PLATFORM devices should hide the
> > compatibility code in a special per-device DMA API implementation.
> > Which would be fine especially if we can manage not to introduce a bunch
> > of indirect
Hi Alex,
On 1/12/19 12:58 AM, Alex Williamson wrote:
> On Tue, 8 Jan 2019 11:26:30 +0100
> Eric Auger wrote:
>
>> This patch adds a new 64kB region aiming to report nested mode
>> translation faults.
>>
>> The region contains a header with the size of the queue,
>> the producer and consumer ind
On Mon, Jan 14, 2019 at 09:14:08PM +0100, Christoph Hellwig wrote:
> Otherwise is_swiotlb_buffer will return false positives when
> we first initialize a swiotlb buffer, but then free it because
> we have an IOMMU available.
>
> Fixes: 55897af63091 ("dma-direct: merge swiotlb_dma_ops into the dma_
On Mon, Jan 14, 2019 at 03:25:13PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 14, 2019 at 09:14:08PM +0100, Christoph Hellwig wrote:
> > Otherwise is_swiotlb_buffer will return false positives when
> > we first initialize a swiotlb buffer, but then free it because
> > we have an IOMMU availa
On Mon, Jan 14, 2019 at 07:12:08PM +, Robin Murphy wrote:
> On 14/01/2019 18:20, Michael S. Tsirkin wrote:
> > On Mon, Jan 14, 2019 at 08:41:37PM +0800, Jason Wang wrote:
> > >
> > > On 2019/1/14 下午5:50, Christoph Hellwig wrote:
> > > > On Mon, Jan 14, 2019 at 05:41:56PM +0800, Jason Wang wrot
Hello everyone,
first of all thanks to Marek for looking into this.
@Robin: This works for me. The drivers now probe and bind correctly again.
With best wishes,
Tobias
Robin Murphy wrote:
> On 14/01/2019 16:09, Thierry Reding wrote:
>> On Mon, Jan 14, 2019 at 02:22:40PM +0100, Marek Szyprowski
On Mon, Jan 14, 2019 at 07:12:08PM +, Robin Murphy wrote:
> Now, in theory, yes, the real issue at hand is not unique to virtio-blk nor
> SEV - any driver whose device has a sufficiently large DMA segment size and
> who manages to get sufficient physically-contiguous memory could
> technical
On Mon, Jan 14, 2019 at 01:20:45PM -0500, Michael S. Tsirkin wrote:
> I don't think so - the issue is really that DMA API does not yet handle
> the SEV case 100% correctly. I suspect passthrough devices would have
> the same issue.
The DMA API handles the SEV case perfectly. Its just that virtio_
Otherwise is_swiotlb_buffer will return false positives when
we first initialize a swiotlb buffer, but then free it because
we have an IOMMU available.
Fixes: 55897af63091 ("dma-direct: merge swiotlb_dma_ops into the dma_direct
code")
Reported-by: Sibren Vasse
Signed-off-by: Christoph Hellwig
T
On Mon, 14 Jan 2019 at 19:13, Christoph Hellwig wrote:
>
> Hmm, I wonder if we are not actually using swiotlb in the end,
> can you check if your dmesg contains this line or not?
>
> PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
This line does not appear in my dmesg.
>
> If not I gues
On 1/14/19 12:20 PM, Michael S. Tsirkin wrote:
> On Mon, Jan 14, 2019 at 08:41:37PM +0800, Jason Wang wrote:
>>
>> On 2019/1/14 下午5:50, Christoph Hellwig wrote:
>>> On Mon, Jan 14, 2019 at 05:41:56PM +0800, Jason Wang wrote:
On 2019/1/11 下午5:15, Joerg Roedel wrote:
> On Fri, Jan 11, 2019
On 14/01/2019 18:20, Michael S. Tsirkin wrote:
On Mon, Jan 14, 2019 at 08:41:37PM +0800, Jason Wang wrote:
On 2019/1/14 下午5:50, Christoph Hellwig wrote:
On Mon, Jan 14, 2019 at 05:41:56PM +0800, Jason Wang wrote:
On 2019/1/11 下午5:15, Joerg Roedel wrote:
On Fri, Jan 11, 2019 at 11:29:31AM +08
On Mon, 14 Jan 2019 at 19:10, Christoph Hellwig wrote:
>
> On Thu, Jan 10, 2019 at 06:52:26PM +0100, Sibren Vasse wrote:
> > On Thu, 10 Jan 2019 at 15:48, Christoph Hellwig wrote:
> > >
> > > On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote:
> > > >> From the trace it looks like w
On Mon, Jan 14, 2019 at 08:41:37PM +0800, Jason Wang wrote:
>
> On 2019/1/14 下午5:50, Christoph Hellwig wrote:
> > On Mon, Jan 14, 2019 at 05:41:56PM +0800, Jason Wang wrote:
> > > On 2019/1/11 下午5:15, Joerg Roedel wrote:
> > > > On Fri, Jan 11, 2019 at 11:29:31AM +0800, Jason Wang wrote:
> > > > >
Hmm, I wonder if we are not actually using swiotlb in the end,
can you check if your dmesg contains this line or not?
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
If not I guess we found a bug in swiotlb exit vs is_swiotlb_buffer,
and you can try this patch:
diff --git a/kernel/dma/
On Thu, Jan 10, 2019 at 06:52:26PM +0100, Sibren Vasse wrote:
> On Thu, 10 Jan 2019 at 15:48, Christoph Hellwig wrote:
> >
> > On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote:
> > >> From the trace it looks like we git the case where swiotlb tries
> > >> to copy back data from a b
On 2019-01-10 3:48 p.m., Christoph Hellwig wrote:
> On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote:
>>> From the trace it looks like we git the case where swiotlb tries
>>> to copy back data from a bounce buffer, but hits a dangling or NULL
>>> pointer. So a couple questions for
On Mon, Jan 14, 2019 at 01:12:33PM +, Robin Murphy wrote:
> Ignoring the offset was kind of intentional there, because at the time I
> was primarily thinking about it in terms of the Keystone 2 platform where
> the peripherals are all in the same place (0-2GB) in both the bus and CPU
> physi
On Mon, Jan 14, 2019 at 04:52:40PM +, Robin Murphy wrote:
> One general point for the kmap() conversions - it's not obvious (to me at
> least) whether or how that would work for a segment where sg->length >
> PAGE_SIZE. Or is there some cast-iron guarantee from the MMC mid-layer that
> it wi
On 14/01/2019 09:57, Christoph Hellwig wrote:
Hi everyone,
this series converts the remaining MMC host drivers to properly kmap the
scatterlist entries it does PIO operations on, and then goes on to
remove the usage of block layer bounce buffering (which I plan to remove
eventually) from the MMC
On 14/01/2019 16:09, Thierry Reding wrote:
On Mon, Jan 14, 2019 at 02:22:40PM +0100, Marek Szyprowski wrote:
This reverts commit 1874619a7df4b14b23b14877e705ae15325773e3.
That patch broke IOMMU support for devices, which fails to probe for the
first time and use deferred probe approach. When no
On Mon, Jan 14, 2019 at 02:22:40PM +0100, Marek Szyprowski wrote:
> This reverts commit 1874619a7df4b14b23b14877e705ae15325773e3.
>
> That patch broke IOMMU support for devices, which fails to probe for the
> first time and use deferred probe approach. When non-NULL dma_ops is set
> in arm_iommu_d
Hi Robin,
On 1/14/19 12:10 PM, Robin Murphy wrote:
> On 10/01/2019 10:44, Auger Eric wrote:
>> Hi Robin, Drew,
>>
>> On 12/19/18 2:18 PM, Andrew Jones wrote:
>>> On Wed, Dec 19, 2018 at 12:21:35PM +, Robin Murphy wrote:
On 18/12/2018 18:48, Andrew Jones wrote:
> The sum of dmaaddr and
On 11/01/2019 18:17, Christoph Hellwig wrote:
Use WARN_ON_ONCE to print a stack trace and return a proper error
code instead.
I was racking my brain to remember the reasoning behind BUG_ON() being
the only viable way to prevent errors getting through unhandled, but of
course that was before w
This reverts commit 1874619a7df4b14b23b14877e705ae15325773e3.
That patch broke IOMMU support for devices, which fails to probe for the
first time and use deferred probe approach. When non-NULL dma_ops is set
in arm_iommu_detach_device(), the given device later ignored by
arch_setup_dma_ops() and s
On 11/01/2019 18:17, Christoph Hellwig wrote:
Just returning the physical address when not map_resource method is
present is highly dangerous as it doesn't take any offset in the
direct mapping into account and does the completely wrong thing for
IOMMUs. Instead provide a proper implementation i
Hi Christoph,
On 2019-01-11 19:17, Christoph Hellwig wrote:
> vb2_dc_get_userptr pokes into arm direct mapping details to get the
> resemblance of a dma address for a a physical address that does is
> not backed by a page struct. Not only is this not portable to other
> architectures with dma dir
On 2019/1/14 下午5:50, Christoph Hellwig wrote:
On Mon, Jan 14, 2019 at 05:41:56PM +0800, Jason Wang wrote:
On 2019/1/11 下午5:15, Joerg Roedel wrote:
On Fri, Jan 11, 2019 at 11:29:31AM +0800, Jason Wang wrote:
Just wonder if my understanding is correct IOMMU_PLATFORM must be set for
all virtio d
On Thu, 10 Jan 2019 11:00:23 +0800
Lu Baolu wrote:
> When multiple domains per device has been enabled by the
> device driver, the device will tag the default PASID for
> the domain to all DMA traffics out of the subset of this
> device; and the IOMMU should translate the DMA requests
> in PASID
Hi Christoph,
On 2019-01-11 19:17, Christoph Hellwig wrote:
> Hi all,
>
> this series fixes a rather gross layering violation in videobuf2, which
> pokes into arm DMA mapping internals to get a DMA address for memory that
> does not have a page structure, and to do so fixes up the dma_map_resource
On Thu, 10 Jan 2019 11:00:22 +0800
Lu Baolu wrote:
> This part of code could be used by both normal and aux
> domain specific attach entries. Hence move them into a
> common function to avoid duplication.
>
> Cc: Ashok Raj
> Cc: Jacob Pan
> Cc: Kevin Tian
> Signed-off-by: Lu Baolu
Another tr
On Thu, 10 Jan 2019 11:00:20 +0800
Lu Baolu wrote:
> Sharing a physical PCI device in a finer-granularity way
> is becoming a consensus in the industry. IOMMU vendors
> are also engaging efforts to support such sharing as well
> as possible. Among the efforts, the capability of support
> finer-gr
On Mon, Jan 14, 2019 at 09:04:56AM -0200, Mauro Carvalho Chehab wrote:
> It would be good if you could later send us a stable branch where
> you merged, in order to allow us to run some tests with the new
> DMA mapping patchset and be sure that it won't cause regressions
> to videobuf2.
I can do t
On 10/01/2019 10:44, Auger Eric wrote:
Hi Robin, Drew,
On 12/19/18 2:18 PM, Andrew Jones wrote:
On Wed, Dec 19, 2018 at 12:21:35PM +, Robin Murphy wrote:
On 18/12/2018 18:48, Andrew Jones wrote:
The sum of dmaaddr and size may overflow, particularly considering
there are cases where size
Em Mon, 14 Jan 2019 11:31:39 +0100
Christoph Hellwig escreveu:
> On Fri, Jan 11, 2019 at 05:54:16PM -0200, Mauro Carvalho Chehab wrote:
> > Em Fri, 11 Jan 2019 19:17:31 +0100
> > Christoph Hellwig escreveu:
> >
> > > vb2_dc_get_userptr pokes into arm direct mapping details to get the
> > > re
+Linus Walleij (recently made a cleanup of the mmc bounce buffering code).
On Mon, 14 Jan 2019 at 10:58, Christoph Hellwig wrote:
>
> Hi everyone,
>
> this series converts the remaining MMC host drivers to properly kmap the
> scatterlist entries it does PIO operations on, and then goes on to
> re
On Fri, Jan 11, 2019 at 05:54:16PM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 11 Jan 2019 19:17:31 +0100
> Christoph Hellwig escreveu:
>
> > vb2_dc_get_userptr pokes into arm direct mapping details to get the
> > resemblance of a dma address for a a physical address that does is
> > not backed
All MMC and SD host drivers are highmem safe now, and bounce buffering
for addressing limitations is handled in the DMA layer now.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/core/queue.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/que
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/s3cmci.c | 107 +++---
dr
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do a kmap for the page while
doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/moxart-mmc.c | 19 +++
1 file changed, 11 inserti
These days the DMA mapping code must bounce buffer for any not supported
address, and if they driver needs to optimize for natively supported
ranged it should use dma_get_required_mask.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-mapping.h | 7 ---
include/linux/dma-mapping
Use the proper sg_next() helper to move to the next scatterlist element
to support chained scatterlists.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/sh_mmcif.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/ho
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/mvsdio.c | 48 +++
1
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/omap.c | 15 ++-
1 file changed, 10 insertion
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/sh_mmcif.c | 58 +++--
1
Use the proper sg_next() helper to move to the next scatterlist element
to support chained scatterlists.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/s3cmci.c | 19 +--
drivers/mmc/host/s3cmci.h | 2 +-
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/dr
Use the proper sg_next() helper to move to the next scatterlist element
to support chained scatterlists.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/omap.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/o
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/davinci_mmc.c | 43 --
1
Hi everyone,
this series converts the remaining MMC host drivers to properly kmap the
scatterlist entries it does PIO operations on, and then goes on to
remove the usage of block layer bounce buffering (which I plan to remove
eventually) from the MMC layer.
As a bonus I've converted various drive
On Mon, Jan 14, 2019 at 05:41:56PM +0800, Jason Wang wrote:
>
> On 2019/1/11 下午5:15, Joerg Roedel wrote:
>> On Fri, Jan 11, 2019 at 11:29:31AM +0800, Jason Wang wrote:
>>> Just wonder if my understanding is correct IOMMU_PLATFORM must be set for
>>> all virtio devices under AMD-SEV guests?
>> Yes,
With most of the previous functionality now elsewhere a lot of the
headers included in this file are not needed.
Signed-off-by: Christoph Hellwig
---
arch/arm64/mm/dma-mapping.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mappin
Split all functionality related to non-coherent devices into a
separate helper, and make the decision flow more obvious.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 51 +++
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/dr
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 13 +
include/linux/dma-iommu.h | 13 +
2 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index e27909771d55..1b76121df94e 100644
--- a/driv
For entirely dma coherent architectures there is no good reason to ever
remap dma coherent allocation. Move all the remap and pool code under
CONFIG_DMA_DIRECT_REMAP ifdefs, and drop the Kconfig dependency.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/Kconfig | 1 -
drivers/iommu/dma
Signed-off-by: Christoph Hellwig
---
arch/arm64/mm/dma-mapping.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index fffba9426ee4..bdfb4e985a69 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64
There is no need to remap for pte attributes, or for a virtually
contiguous address, so just don't do it.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iomm
Moving this function up to its unmap counterpart helps to keep related
code together for the following changes.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 46 +++
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/iom
Move the call to dma_common_pages_remap / dma_common_free_remap into
__iommu_dma_alloc / __iommu_dma_free and rename those functions to
better describe what they do. This keeps the functionality that
allocates and remaps a non-contigous array of pages nicely abstracted
out from the calling code.
The current iommu_dma_mmap code does not properly handle memory from the
page allocator that hasn't been remapped, which can happen in the rare
case of allocations for a coherent device that aren't allowed to block.
Fix this by replacing iommu_dma_mmap with a slightly tweaked copy of
dma_common_mm
This moves the last remaning non-dispatch code out of iommu_dma_alloc,
preparing to refactor the allocation method selection.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 48 +++
1 file changed, 29 insertions(+), 19 deletions(-)
diff --git
This keeps the code together and will simplify compiling the code
out on architectures that are always dma coherent.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 51 +--
1 file changed, 38 insertions(+), 13 deletions(-)
diff --git a/driver
Reorder the checks a bit so that a non-remapped allocation is the
fallthrough case, as this will ease making remapping conditional.
Also get rid of the confusing game with the size and iosize variables
and rename the handle argument to the more standard dma_handle.
Signed-off-by: Christoph Hellwig
This keeps the code together and will simplify using it in different
ways.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 110 --
1 file changed, 59 insertions(+), 51 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-io
The current iommu_dma_get_sgtable code does not properly handle memory
from the page allocator that hasn't been remapped, which can happen in
the rare case of allocations for a coherent device that aren't allowed
to block.
Fix this by replacing iommu_dma_get_sgtable with a slightly tweaked copy
of
Directly iterating over the pages makes the code a bit simpler and
prepares for the following changes.
Signed-off-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 40 +--
1 file changed, 17 insertions(+), 23 deletions(-)
diff --git a/drivers/iommu/dma-io
There is nothing really arm64 specific in the iommu_dma_ops
implementation, so move it to dma-iommu.c and keep a lot of symbols
self-contained. Note the implementation does depend on the
DMA_DIRECT_REMAP infrastructure for now, so we'll have to make the
DMA_IOMMU support depend on it, but this wil
Hi Robin,
please take a look at this series, which implements a completely generic
set of dma_map_ops for IOMMU drivers. This is done by taking the
existing arm64 code, moving it to drivers/iommu and then massaging it
so that it can also work for architectures with DMA remapping. This
should hel
On 2019/1/11 下午5:15, Joerg Roedel wrote:
On Fri, Jan 11, 2019 at 11:29:31AM +0800, Jason Wang wrote:
Just wonder if my understanding is correct IOMMU_PLATFORM must be set for
all virtio devices under AMD-SEV guests?
Yes, that is correct. Emulated DMA can only happen on the SWIOTLB
aperture, be
No need for a __KERNEL__ guard outside uapi, make sure we pull in the
includes unconditionally so users can rely on it, and add a missing
comment describing the #else cpp statement. Last but not least include
instead of the asm version, which is frowned upon.
Signed-off-by: Christoph Hellwig
--
Add a Kconfig symbol that indicates an architecture provides a
arch_dma_prep_coherent implementation, and provide a stub otherwise.
This will allow the generic dma-iommu code to it while still allowing
to be built for cache coherent architectures.
Signed-off-by: Christoph Hellwig
---
arch/arm64
We now have a arch_dma_prep_coherent architecture hook that is used
for the generic DMA remap allocator, and we should use the same
interface for the dma-iommu code.
Signed-off-by: Christoph Hellwig
---
arch/arm64/mm/dma-mapping.c | 8 +---
drivers/iommu/dma-iommu.c | 14 --
i
78 matches
Mail list logo