On 2022-04-19 00:37, Lu Baolu wrote:
On 2022/4/19 6:09, Robin Murphy wrote:
On 2022-04-16 01:04, Lu Baolu wrote:
On 2022/4/14 20:42, Robin Murphy wrote:
@@ -1883,27 +1900,12 @@ static int iommu_bus_init(struct bus_type *bus)
   */
  int bus_set_iommu(struct bus_type *bus, const struct iommu_ops *ops)
  {
-    int err;
-
-    if (ops == NULL) {
-        bus->iommu_ops = NULL;
-        return 0;
-    }
-
-    if (bus->iommu_ops != NULL)
+    if (bus->iommu_ops && ops && bus->iommu_ops != ops)
          return -EBUSY;
      bus->iommu_ops = ops;

Do we still need to keep above lines in bus_set_iommu()?

It preserves the existing behaviour until each callsite and its associated error handling are removed later on, which seems like as good a thing to do as any. Since I'm already relaxing iommu_device_register() to a warn-but-continue behaviour while it keeps the bus ops on life-support internally, I figured not changing too much at once would make it easier to bisect any potential issues arising from this first step.

Fair enough. Thank you for the explanation.

Do you have a public tree that I could pull these patches and try them
on an Intel hardware? Or perhaps you have done this? I like the whole
idea of this series, but it's better to try it with a real hardware.

I haven't bothered with separate branches since there's so many different pieces in-flight, but my complete (unstable) development branch can be found here:

https://gitlab.arm.com/linux-arm/linux-rm/-/commits/iommu/bus

For now I'd recommend winding the head back to "iommu: Clean up bus_set_iommu()" for testing - some of the patches above that have already been posted and picked up by their respective subsystems, but others are incomplete and barely compile-tested. I'll probably rearrange it later this week to better reflect what's happened so far.

Cheers,
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Reply via email to