On 7/7/22 10:58 AM, Robin Murphy wrote:

On 2022-07-07 13:54, Matthew Rosato wrote:

quoted

On 7/7/22 8:49 AM, Matthew Rosato wrote:

quoted

On 7/5/22 1:08 PM, Robin Murphy wrote:

quoted

Clean up the remaining trivial bus_set_iommu() callsites along
with the implementation. Now drivers only have to know and care
about iommu_device instances, phew!

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

v3: Also catch Intel's cheeky open-coded assignment

...

quoted

diff --git a/drivers/iommu/s390-iommu.c b/drivers/iommu/s390-iommu.c
index c898bcbbce11..dd957145fb81 100644
--- a/drivers/iommu/s390-iommu.c
+++ b/drivers/iommu/s390-iommu.c

@@ -385,9 +385,3 @@ static const struct iommu_ops s390_iommu_ops = {

          .free        = s390_domain_free,
      }
  };
-
-static int __init s390_iommu_init(void)
-{
-    return bus_set_iommu(&pci_bus_type, &s390_iommu_ops);
-}
-subsys_initcall(s390_iommu_init);

Previously s390_iommu_ops was only being set for pci_bus_type, but 
with this series it will now also be set for platform_bus_type.

Ah, indeed I hadn't got as far as fully appreciating that to_zpci_dev() 
isn't robust enough on its own. Thanks for the patch, I've pulled it in 
and will include it in v4. Do I take it that all else works OK with this 
fixed?

Yes, with that patch included this looks OK so for s390 you can also take a

Tested-by: Matthew Rosato <mjrosato@linux.ibm.com>


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel