Re: [GIT PULL] dma-mapping fix for 4.20

2018-12-19 Thread pr-tracker-bot
The pull request you sent on Wed, 19 Dec 2018 15:24:19 +0100: > git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-4.20-4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2dd516ff7d852c2cda8c5b883d6625d1c812714e Thank you! -- Deet-doot-dot, I am a bot.

Re: [PATCH v6 0/7] Add virtio-iommu driver

2018-12-19 Thread Michael S. Tsirkin
On Thu, Dec 13, 2018 at 12:50:29PM +, Jean-Philippe Brucker wrote: > >> [3] git://linux-arm.org/linux-jpb.git virtio-iommu/v0.9.1 > >> git://linux-arm.org/kvmtool-jpb.git virtio-iommu/v0.9 > > > > Unfortunatly gitweb seems to be broken on linux-arm.org. What is missing > > in this patch-se

RE: [PATCH v3 2/6] iommu/arm-smmu: Add support to program multiple ARM SMMU's identically

2018-12-19 Thread Krishna Reddy
Hi Robin, Thanks for the feedback :) >The whole point of the library idea was to factor out the code in such a way >that all the details >specific to a particular implementation can be kept together. But what this >patch does is insert >Tegra194-specific handling all through the 'common' code, w

Re: [PATCH v3 2/6] iommu/arm-smmu: Add support to program multiple ARM SMMU's identically

2018-12-19 Thread Robin Murphy
Hi Krishna, On 04/12/2018 01:36, Krishna Reddy wrote: Add support to program multiple ARM SMMU's identically as one SMMU device. Tegra194 uses Two ARM SMMU's as one SMMU device and both ARM SMMU's need to be programmed identically. The whole point of the library idea was to factor out the code

Re: [PATCH dma-mapping tree] arm64: default to the direct mapping in get_arch_dma_ops

2018-12-19 Thread Christoph Hellwig
On Wed, Dec 19, 2018 at 04:59:03PM +, Robin Murphy wrote: > On 14/12/2018 15:02, Christoph Hellwig wrote: >> Otherwise the direct mapping won't work at all given that a NULL >> dev->dma_ops causes a fallback. Note that we already explicitly set >> dev->dma_ops to dma_dummy_ops for dma-incapabl

Re: ensure dma_alloc_coherent always returns zeroed memory

2018-12-19 Thread Christoph Hellwig
FYI, I've picked this up for dma-mapping for-next now. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH dma-mapping tree] arm64: default to the direct mapping in get_arch_dma_ops

2018-12-19 Thread Robin Murphy
On 14/12/2018 15:02, Christoph Hellwig wrote: Otherwise the direct mapping won't work at all given that a NULL dev->dma_ops causes a fallback. Note that we already explicitly set dev->dma_ops to dma_dummy_ops for dma-incapable devices, so this fallback should not be needed anyway. Sorry, I'd s

Re: [PATCH dma-mapping tree] arm64: default to the direct mapping in get_arch_dma_ops

2018-12-19 Thread Christoph Hellwig
As all maintainers seem to be off to their holidays already I've applied this now given that I don't want to leave arm64 in broken state in linux-next any longer. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/ma

Re: [PATCH 3/4] iommu/of: Don't call iommu_ops->add_device directly

2018-12-19 Thread Marek Szyprowski
Hi Joerg, On 2018-12-19 15:34, Joerg Roedel wrote: > Hi Marek, > > thanks for the report! > > On Wed, Dec 19, 2018 at 10:54:18AM +0100, Marek Szyprowski wrote: >> On 2018-12-11 16:05, Joerg Roedel wrote: >>> From: Joerg Roedel >>> >>> Make sure to invoke this call-back through the proper >>> func

Re: [PATCH 3/4] iommu/of: Don't call iommu_ops->add_device directly

2018-12-19 Thread Joerg Roedel
Hi Marek, thanks for the report! On Wed, Dec 19, 2018 at 10:54:18AM +0100, Marek Szyprowski wrote: > On 2018-12-11 16:05, Joerg Roedel wrote: > > From: Joerg Roedel > > > > Make sure to invoke this call-back through the proper > > function of the IOMMU-API. > > > > Signed-off-by: Joerg Roedel >

[GIT PULL] dma-mapping fix for 4.20

2018-12-19 Thread Christoph Hellwig
The following changes since commit 6531e115b7ab84f563fcd7f0d2d05ccf971aaaf9: Merge branch 'akpm' (patches from Andrew) (2018-12-14 15:35:30 -0800) are available in the Git repository at: git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-4.20-4 for you to fetch changes up to

Re: [PATCH 1/2] ACPI/IORT: Handle potential overflow in iort_dma_setup

2018-12-19 Thread Andrew Jones
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 will be U64_MAX. > > Only if the firmware is broken in the first place, though. It would be

Re: [PATCH 2/2] iommu/dma: Handle potential overflow in iommu_dma_init_domain

2018-12-19 Thread Robin Murphy
On 18/12/2018 18:48, Andrew Jones wrote: The sum of base and size may overflow, particularly considering there are cases where size will be U64_MAX. Also, end_pfn is unused, so we remove it. Finally, as size doesn't actually need to be IOMMU page aligned we remove it from the comment stating both

Re: [PATCH 1/2] ACPI/IORT: Handle potential overflow in iort_dma_setup

2018-12-19 Thread Robin Murphy
On 18/12/2018 18:48, Andrew Jones wrote: The sum of dmaaddr and size may overflow, particularly considering there are cases where size will be U64_MAX. Only if the firmware is broken in the first place, though. It would be weird to describe an explicit _DMA range of base=0 and size=U64_MAX, b

Re: [PATCH 3/4] iommu/of: Don't call iommu_ops->add_device directly

2018-12-19 Thread Marek Szyprowski
Hi Joerg, This patch landed in today's linux-next and causes a regression. On 2018-12-11 16:05, Joerg Roedel wrote: > From: Joerg Roedel > > Make sure to invoke this call-back through the proper > function of the IOMMU-API. > > Signed-off-by: Joerg Roedel > --- > drivers/iommu/of_iommu.c | 6 +