* [PATCH] iommu/rockchip: fix zap cache during device attach
@ 2016-05-10 15:50 John Keeping
2016-05-14 20:19 ` Heiko Stuebner
0 siblings, 1 reply; 3+ messages in thread
From: John Keeping @ 2016-05-10 15:50 UTC (permalink / raw)
To: iommu
Cc: Joerg Roedel, Heiko Stuebner, linux-arm-kernel, linux-rockchip,
linux-kernel, ZhengShunQian, John Keeping
rk_iommu_command() takes a struct rk_iommu and iterates over the slave
MMUs, so this is doubly wrong in that we're passing in the wrong pointer
and talking to MMUs that we shouldn't be.
Fixes: cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi slaves")
Signed-off-by: John Keeping <john@metanate.com>
---
drivers/iommu/rockchip-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 5710a06c3049..0ea8d9a24de0 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -815,7 +815,7 @@ static int rk_iommu_attach_device(struct iommu_domain *domain,
dte_addr = virt_to_phys(rk_domain->dt);
for (i = 0; i < iommu->num_mmu; i++) {
rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR, dte_addr);
- rk_iommu_command(iommu->bases[i], RK_MMU_CMD_ZAP_CACHE);
+ rk_iommu_base_command(iommu->bases[i], RK_MMU_CMD_ZAP_CACHE);
rk_iommu_write(iommu->bases[i], RK_MMU_INT_MASK, RK_MMU_IRQ_MASK);
}
--
2.8.2.565.gdb84f68.dirty
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] iommu/rockchip: fix zap cache during device attach
2016-05-10 15:50 [PATCH] iommu/rockchip: fix zap cache during device attach John Keeping
@ 2016-05-14 20:19 ` Heiko Stuebner
2016-05-15 11:16 ` John Keeping
0 siblings, 1 reply; 3+ messages in thread
From: Heiko Stuebner @ 2016-05-14 20:19 UTC (permalink / raw)
To: John Keeping
Cc: iommu, Joerg Roedel, linux-arm-kernel, linux-rockchip,
linux-kernel, ZhengShunQian
Am Dienstag, 10. Mai 2016, 16:50:46 schrieb John Keeping:
> rk_iommu_command() takes a struct rk_iommu and iterates over the slave
> MMUs, so this is doubly wrong in that we're passing in the wrong pointer
> and talking to MMUs that we shouldn't be.
>
> Fixes: cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi
> slaves") Signed-off-by: John Keeping <john@metanate.com>
on a rk3288-veyron
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
I was wondering for a short time why this didn't spew warnings until I
realized that the iommu->bases[i] is of course a void* .
Heiko
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] iommu/rockchip: fix zap cache during device attach
2016-05-14 20:19 ` Heiko Stuebner
@ 2016-05-15 11:16 ` John Keeping
0 siblings, 0 replies; 3+ messages in thread
From: John Keeping @ 2016-05-15 11:16 UTC (permalink / raw)
To: Heiko Stuebner
Cc: iommu, Joerg Roedel, linux-arm-kernel, linux-rockchip,
linux-kernel, ZhengShunQian
On Sat, May 14, 2016 at 10:19:43PM +0200, Heiko Stuebner wrote:
> Am Dienstag, 10. Mai 2016, 16:50:46 schrieb John Keeping:
> > rk_iommu_command() takes a struct rk_iommu and iterates over the slave
> > MMUs, so this is doubly wrong in that we're passing in the wrong pointer
> > and talking to MMUs that we shouldn't be.
> >
> > Fixes: cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi
> > slaves") Signed-off-by: John Keeping <john@metanate.com>
>
> on a rk3288-veyron
> Tested-by: Heiko Stuebner <heiko@sntech.de>
> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
>
> I was wondering for a short time why this didn't spew warnings until I
> realized that the iommu->bases[i] is of course a void* .
Yes, although sparse catches it because iommu->bases[i] is __iomem so it
shows up as a namespace warning.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-05-15 11:16 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-10 15:50 [PATCH] iommu/rockchip: fix zap cache during device attach John Keeping
2016-05-14 20:19 ` Heiko Stuebner
2016-05-15 11:16 ` John Keeping
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).