Re: [PATCH] iommu: Avoid NULL group dereference

already attached to an existing domain or not, for which the previous behaviour of iommu_get_domain_for_dev() was ideal, and who now crash if their device does not have an IOMMU. It works, thanks! Tested-by: Shawn Lin With IOMMU groups now serving as a reliable indicator of whether a device has an

Re: [PATCH] irqchip/gic-{v2m, v3-its}: check iommu capable before doing iommu map

Hi Marc On 2017/8/17 16:52, Marc Zyngier wrote: On 17/08/17 09:28, Shawn Lin wrote: If a PCIe RC use gic-v2m or gic-v3-its as a msi domain but doesn't have iommu support, we don't need to do iommu_dma_map_msi_msg to get mapped iommu address as all we need is the physical address. Ot

Re: PCIe oops for NULL pointer dereference during next-20170807 and next-20170815

On 2017/8/17 15:58, Joerg Roedel wrote: On Thu, Aug 17, 2017 at 03:02:31PM +0800, Shawn Lin wrote: So should we revert this commit or maybe we could add some checking into gic-v2m and gic-v3-its to see if the dev is iommu-capable? If not, we should create another routine to map MSI msg. Yes

[PATCH] irqchip/gic-{v2m, v3-its}: check iommu capable before doing iommu map

ommit mentioned below. Before this commit, iommu has a work around method to fix this but now it doesn't. So we could fix this in gic code but maybe still need a fixes tag here. Fixes: 05f80300dc8b ("iommu: Finish making iommu_group support mandatory") Signed-off-by: Shawn Lin --- dr

Re: PCIe oops for NULL pointer dereference during next-20170807 and next-20170815

+ Marc On 2017/8/17 11:34, Shawn Lin wrote: Hi all, I see this NULL pointer dereference into linux-next these day which break PCIe for my system, but not for linux-next-20170807. Is it that commit causing this problem? 05f80300dc8bc ("iommu: Finish making iommu_group support mand

PCIe oops for NULL pointer dereference during next-20170807 and next-20170815

Hi all, I see this NULL pointer dereference into linux-next these day which break PCIe for my system, but not for linux-next-20170807. Is it that commit causing this problem? 05f80300dc8bc ("iommu: Finish making iommu_group support mandatory") As I check the oops dump and asm code, which shows

Re: [PATCH 1/2] iommu/rockchip: add multi irqs support

Hi Simon, On 2017/7/21 9:35, Simon Xue wrote: From: Simon RK3368 vpu mmu have two irqs, this patch support multi irqs Signed-off-by: Simon --- drivers/iommu/rockchip-iommu.c | 34 -- 1 file changed, 24 insertions(+), 10 deletions(-) diff --git a/drivers/io

Re: [PATCH 2/2] iommu/rockchip: ignore isp mmu reset operation

Hi Simon, On 2017/7/21 9:35, Simon Xue wrote: From: Simon ISP mmu can't support reset operation, it won't get the expected result when reset, but rest functions work normally. Add this patch as a WA for this issue. Signed-off-by: Simon --- drivers/iommu/rockchip-iommu.c | 7 +++ 1 fil

[PATCH v2] iommu/ipmmu-vmsa: Fix wrong error handle of ipmmu_add_device

Let's fix the error handle of ipmmu_add_device when failing to find utlbs, otherwise we take a risk of pontential memleak. Signed-off-by: Shawn Lin --- Changes in v2: - use error-out path drivers/iommu/ipmmu-vmsa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dr

[PATCH] iommu/ipmmu-vmsa: Fix potential memleak

Let's free utlbs for the error routine. Signed-off-by: Shawn Lin --- drivers/iommu/ipmmu-vmsa.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c index 2fdbac6..2458208 100644 --- a/drivers/iommu/ipmmu-vmsa.c