Hi Jeffy,

On 11/01/18 11:14, JeffyChen wrote:

Hi Marek,

Thanks for your reply.

On 01/11/2018 05:40 PM, Marek Szyprowski wrote:

quoted

Hi Jeffy,

On 2018-01-11 09:22, Jeffy Chen wrote:

quoted

With the probe-deferral mechanism, early initialisation hooks are no
longer needed.

Suggested-by: Robin Murphy <robin.murphy@arm.com>

In fact, shortly after I said that I had a "how hard can it be?" moment 
and took a crack at it myself - sorry, I should probably have cc'd you 
on that series[1].

quoted

quoted

Signed-off-by: Jeffy Chen <redacted>
---

  drivers/iommu/arm-smmu-v3.c  |  2 +-
  drivers/iommu/arm-smmu.c     | 12 ++++++------
  drivers/iommu/exynos-iommu.c |  2 +-

For Exynos IOMMU:
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>

IPMMU and MSM IOMMU are no longer multi-platform safe after this patch.
It breaks them in the same way as my commit 928055a01b3f ("iommu/exynos:
Remove custom platform device registration code") broke Exynos IOMMU.

You need a similar fix for them:
https://www.spinics.net/lists/arm-kernel/msg627648.html

hmmm, right, i did saw this fix in the rockchip iommu driver too.

and there're also some other iommu drivers put bus_set_iommu in their 
probe() to avoid that.

maybe we can do it in the iommu framework?

for example:
1/ add a bus type member to struct iommu_device
2/ and a iommu_device_set_bus()
3/ do the bus_set_iommu stuff in iommu_device_register()
4/ undo bus_set_iommu in iommu_device_unregister()

Ultimately we'd like to get rid of the bus relationship altogether, so I 
don't think it's really worth adding more infrastructure around it. 
Having of-iommu-based drivers set bus ops at probe time, and others 
conditionally from an initcall, is pretty clean and simple, so I'd 
rather stick with that approach for now.

Robin.

[1] 
https://lists.linuxfoundation.org/pipermail/iommu/2018-January/025395.html
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu