On 29/02/16 18:09, Sricharan wrote:
Hi Robin,
-----Original Message-----
[...]
+static int __init arm_smmu_of_init(struct device_node *np) {
+ struct arm_smmu_device *smmu;
+ struct platform_device *pdev;
+ int ret = arm_smmu_init();
+
+ if (ret)
+ return ret;
+
+ pdev = of_platform_device_create(np, NULL,
platform_bus_type.dev_root);
+ if (!pdev)
+ return -ENODEV;
+
+ smmu = platform_get_drvdata(pdev);
+ of_iommu_set_ops(np, &arm_smmu_ops);
+
+ return 0;
+}
+IOMMU_OF_DECLARE(arm_smmuv1, "arm,smmu-v1",
arm_smmu_of_init);
+IOMMU_OF_DECLARE(arm_smmuv2, "arm,smmu-v2",
arm_smmu_of_init);
+IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400",
arm_smmu_of_init);
+IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401",
arm_smmu_of_init);
+IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500",
arm_smmu_of_init);
+
Thanks for this series. I am going to use and test this. Also I wanted to
ask about the iommu probe deferral series [1] to avoid early device
registration and wanted know the direction on that ?
It's certainly on my near-term to-do list to revisit. I recall running
into problems with that series if the IOMMU was ready but the device
itself then requested probe deferral, and I have vague memories of
thinking more needed to be done generally around the failure/device
teardown path too. I also had high hopes for the on-demand device
probing series from around the same time[2], which would have helped
simplify things quite a bit, but that also seems to have died after a
brief stint breaking things in -next.
Anyway, Marc reckons that we also have the exact same probe-dependency
problem for things like IRQ-MSI bridges, so I'll be looking into a more
general solution at some point unless anyone wants to beat me to it ;)
Thanks,
Robin.
[2]:http://thread.gmane.org/gmane.linux.acpi.devel/78833
[1] http://lkml.iu.edu/hypermail/linux/kernel/1505.3/03280.html
Regards,
Sricharan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
