On Thu, May 02, 2019 at 03:22:08PM +0200, Christoph Hellwig wrote:
> can you quickly look over the arm64 parts? I'd really like to still
> get this series in for this merge window as it would conflict with
> a lot of dma-mapping work for next merge window, and we also have
> the amd and possibly i
Sorry,
plese ignore this thread. This just resend the start of the
dma-mapping for-next branch instead of the actual series that
sits on top of it.
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
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
Any chance to get a review on this one?
On Mon, Jan 14, 2019 at 10:41:40AM +0100, Christoph Hellwig wrote:
> 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
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
6 matches
Mail list logo