[PATCH v10] FlexRM support in VFIO platform

This patchset primarily adds Broadcom FlexRM reset module for VFIO platform driver. The patches are based on Linux-4.14-rc3 and can also be found at flexrm-vfio-v10 branch of https://github.com/Broadcom/arm64-linux.git Changes since v9: - Make GPL comment header similar to other Broadcom

[PATCH v10] vfio: platform: reset: Add Broadcom FlexRM reset module

This patch adds Broadcom FlexRM low-level reset for VFIO platform. It will do the following: 1. Disable/Deactivate each FlexRM ring 2. Flush each FlexRM ring The cleanup sequence for FlexRM rings is adapted from Broadcom FlexRM mailbox driver. Signed-off-by: Anup Patel

Re: road blocks for using dma-iommu on more than arm64

On 02/10/17 17:31, Christoph Hellwig wrote: > On Mon, Oct 02, 2017 at 03:56:14PM +0100, Robin Murphy wrote: >> IIRC, dmabounce has to stay because it handles non-contiguous DMA masks, >> thanks to a StrongARM hardware erratum where the DMA controller could >> only access every other megabyte of

Re: road blocks for using dma-iommu on more than arm64

On Mon, Oct 02, 2017 at 03:56:14PM +0100, Robin Murphy wrote: > IIRC, dmabounce has to stay because it handles non-contiguous DMA masks, > thanks to a StrongARM hardware erratum where the DMA controller could > only access every other megabyte of memory (or something like that). Isn't that

Re: road blocks for using dma-iommu on more than arm64

On 02/10/17 15:50, Christoph Hellwig wrote: > On Mon, Oct 02, 2017 at 03:47:06PM +0100, Robin Murphy wrote: >> dma-iommu does require that the IOMMU driver allows iommu_{un,}map() to >> be called in atomic context, but last time I looked I think it was only >> the AMD driver that needs attention

Re: road blocks for using dma-iommu on more than arm64

On Mon, Oct 02, 2017 at 03:47:06PM +0100, Robin Murphy wrote: > dma-iommu does require that the IOMMU driver allows iommu_{un,}map() to > be called in atomic context, but last time I looked I think it was only > the AMD driver that needs attention there. The main other concern, for > x86 at least,

Re: road blocks for using dma-iommu on more than arm64

On 01/10/17 10:02, Christoph Hellwig wrote: > Hi all, > > are there any road blocks for using drivers/iommu/dma-iommu.c for more > than just arm64, e.g. also for the Intel/AMD iommus? I've been trying > to consolidate the giant amounts of duplicate code in the dma ops > implementations for a

Re: [PATCH v2 1/2] iommu/io-pgtable-arm: Convert to IOMMU API TLB sync

On Thu, Sep 28, 2017 at 03:55:01PM +0100, Robin Murphy wrote: > Now that the core API issues its own post-unmap TLB sync call, push that > operation out from the io-pgtable-arm internals into the users. For now, > we leave the invalidation implicit in the unmap operation, since none of > the

Re: [PATCH] iommu/iova: Don't try to copy anchor nodes

On Mon, Oct 02, 2017 at 11:53:31AM +0100, Robin Murphy wrote: > Anchor nodes are not reserved IOVAs in the way that copy_reserved_iova() > cares about - while the failure from reserve_iova() is benign since the > target domain will already have its own anchor, we still don't want to > be

[PATCH] iommu/iova: Don't try to copy anchor nodes

Anchor nodes are not reserved IOVAs in the way that copy_reserved_iova() cares about - while the failure from reserve_iova() is benign since the target domain will already have its own anchor, we still don't want to be triggering spurious warnings. Reported-by: kernel test robot

Re: [PATCH v3] dma-debug: fix incorrect pfn calculation

On Sun, 2017-10-01 at 10:04 +0200, Christoph Hellwig wrote: > On Wed, Sep 27, 2017 at 11:23:52AM +0100, Robin Murphy wrote: > > > I found that debug_dma_alloc_coherent() and debug_dma_free_coherent() > > > assume that dma_alloc_coherent() always returns a linear address. > > > However it's