Thread (35 messages) 35 messages, 6 authors, 2016-10-13

[PATCH v5 07/14] drivers: acpi: iort: add support for ARM SMMU platform devices creation

From: Hanjun Guo <hidden>
Date: 2016-09-13 08:48:29
Also in: linux-acpi, linux-iommu, linux-pci, lkml

On 2016/9/13 16:24, Lorenzo Pieralisi wrote:
On Tue, Sep 13, 2016 at 04:15:31PM +0800, Hanjun Guo wrote:

[...]
quoted
quoted
quoted
+static acpi_status __init iort_match_iommu_callback(struct
acpi_iort_node *node,
+                            void *context)
+{
+    int ret;
+    struct fwnode_handle *fwnode;
+
+    fwnode = iort_get_fwnode(node);
+
+    if (!fwnode)
+        return AE_NOT_FOUND;
+
+    ret = iort_add_smmu_platform_device(fwnode, node);
+    if (ret) {
+        pr_err("Error in platform device creation\n");
+        return AE_ERROR;
+    }
+
+    return AE_OK;
+}
+
+static void __init iort_smmu_init(void)
+{
+    iort_scan_node(ACPI_IORT_NODE_SMMU, iort_match_iommu_callback,
NULL);
+    iort_scan_node(ACPI_IORT_NODE_SMMU_V3, iort_match_iommu_callback,
NULL);
Since iort_scan_node() returns after the first successful match it finds,
only the first SMMU_V3 in my IORT is being enumerated. I think you need
to go back to the "iterator" like approach you had been using or make
iort_match_iommu_callback() always return a non-AE_OK value so the scan
continues and has a chance to visit all of the SMMU_V3 nodes.
Please use the updated version of IORT patch (aka Tomasz's v11)
then things will work fine.
Nate is right, I was too keen on using iort_scan_node(), it does
not really work here (unless as he said I return a value !AE_OK in
the callback, which is horrible), I reverted back to the iterator
approach and I can push out a fixed up branch if useful before next
posting.
Ah, sorry, I just noticed "the first SMMU_V3" which is pretty similar
with the second problem which is noticed by Nate...

Thanks
Hanjun
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help