of: property: Add device link support for "iommu-map"

PATCH In review Will Deacon 4 participants 8 messages Nov 20, 2019 – Nov 25, 2019 Device tree

Share & tools

Will Deacon

author

2019-11-20 19:00 UTC #0 lore raw

PATCH 1/1 of: property: Add device link support for "iommu-map"

Commit 8e12257dead7 ("of: property: Add device link support for iommus, mboxes and io-channels") added device link support for IOMMU linkages described using the "iommus" property. For PCI devices, this property is not present and instead the "iommu-map" property is used on the host bridge node to map the endpoint RequesterIDs to their corresponding IOMMU instance.

Add support for "iommu-map" to the device link supplier bindings so that probing of PCI devices can be deferred until after the IOMMU is available.

Cc Greg Kroah-Hartman <[email protected]>

Cc Rob Herring <[email protected]>

Cc Saravana Kannan <[email protected]>

Cc Robin Murphy <[email protected]>

Signed-off-by Will Deacon <[email protected]>

---

Applies against driver-core/driver-core-next.
Tested on AMD Seattle (arm64).

 drivers/of/property.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

drivers/of/property.c +10 -0

index 0fa04692e3cc..37e0d408430d 100644
@@ -1190,10 +1190,20 @@ DEFINE_SIMPLE_PROP(mboxes, "mboxes", "#mbox-cells")
 DEFINE_SIMPLE_PROP(io_channels, "io-channel", "#io-channel-cells")
 DEFINE_SUFFIX_PROP(regulators, "-supply", NULL)
 
+static struct device_node *parse_iommu_maps(struct device_node *np,
+					    const char *prop_name, int index)
+{
+	if (strcmp(prop_name, "iommu-map"))
+		return NULL;
+
+	return of_parse_phandle(np, prop_name, (index * 4) + 1);
+}
+
 static const struct supplier_bindings of_supplier_bindings[] = {
 	{ .parse_prop = parse_clocks, },
 	{ .parse_prop = parse_interconnects, },
 	{ .parse_prop = parse_iommus, },
+	{ .parse_prop = parse_iommu_maps, },
 	{ .parse_prop = parse_mboxes, },
 	{ .parse_prop = parse_io_channels, },
 	{ .parse_prop = parse_regulators, },

Signature · 1 line

2.17.1

Saravana Kannan

Acked-by on v1 1/1

2019-11-20 21:30 UTC #1 lore raw

Quoted 40 lines · Will Deacon

Commit 8e12257dead7 ("of: property: Add device link support for iommus, mboxes and io-channels") added device link support for IOMMU linkages described using the "iommus" property. For PCI devices, this property is not present and instead the "iommu-map" property is used on the host bridge node to map the endpoint RequesterIDs to their corresponding IOMMU instance.
Add support for "iommu-map" to the device link supplier bindings so that probing of PCI devices can be deferred until after the IOMMU is available.
Cc Greg Kroah-Hartman <[email protected]>
Cc Rob Herring <[email protected]>
Cc Saravana Kannan <[email protected]>
Cc Robin Murphy <[email protected]>
Signed-off-by Will Deacon <[email protected]>
---
Applies against driver-core/driver-core-next.
Tested on AMD Seattle (arm64).
 drivers/of/property.c | 10 ++++++++++
 1 file changed, 10 insertions(+)
drivers/of/property.c +7 -0
index 0fa04692e3cc..37e0d408430d 100644
@@ -1190,10 +1190,20 @@ DEFINE_SIMPLE_PROP(mboxes, "mboxes", "#mbox-cells")
 DEFINE_SIMPLE_PROP(io_channels, "io-channel", "#io-channel-cells")
 DEFINE_SUFFIX_PROP(regulators, "-supply", NULL)
 
+static struct device_node *parse_iommu_maps(struct device_node *np,
+                                           const char *prop_name, int index)
+{
+       if (strcmp(prop_name, "iommu-map"))
+               return NULL;
+
+       return of_parse_phandle(np, prop_name, (index * 4) + 1);

drivers/of/property.c DEFINE_SIMPLE_PROP(mboxes, "mboxes", "#mbox-cells") · line 1209

Quoted 10 lines

drivers/of/property.c +3 -0

+}
+
 static const struct supplier_bindings of_supplier_bindings[] = {
        { .parse_prop = parse_clocks, },
        { .parse_prop = parse_interconnects, },
        { .parse_prop = parse_iommus, },
+       { .parse_prop = parse_iommu_maps, },
        { .parse_prop = parse_mboxes, },
        { .parse_prop = parse_io_channels, },
        { .parse_prop = parse_regulators, },

Heh... a lot smaller than I thought this would be.

Acked-by Saravana Kannan <[email protected]>

-Saravana

Rob Herring

maintainer

2019-11-22 14:47 UTC #2 lore raw

In reply to Will Deacon

Quoted 17 lines · Will Deacon

Commit 8e12257dead7 ("of: property: Add device link support for iommus, mboxes and io-channels") added device link support for IOMMU linkages described using the "iommus" property. For PCI devices, this property is not present and instead the "iommu-map" property is used on the host bridge node to map the endpoint RequesterIDs to their corresponding IOMMU instance.
Add support for "iommu-map" to the device link supplier bindings so that probing of PCI devices can be deferred until after the IOMMU is available.
Cc Greg Kroah-Hartman <[email protected]>
Cc Rob Herring <[email protected]>
Cc Saravana Kannan <[email protected]>
Cc Robin Murphy <[email protected]>
Signed-off-by Will Deacon <[email protected]>

Quoted 4 lines

---
Applies against driver-core/driver-core-next.
Tested on AMD Seattle (arm64).

Guess that answers my question whether anyone uses Seattle with DT. Seattle uses the old SMMU binding, and there's not even an IOMMU associated with the PCI host. I raise this mainly because the dts files for Seattle either need some love or perhaps should be removed.

No issues with the patch itself though. I'll queue it after rc1.

Rob

Will Deacon

author

2019-11-22 14:55 UTC #3 lore raw

[+Ard]

Hi Rob,

Quoted 20 lines · Rob Herring

Quoted 19 lines · Will Deacon
Commit 8e12257dead7 ("of: property: Add device link support for iommus, mboxes and io-channels") added device link support for IOMMU linkages described using the "iommus" property. For PCI devices, this property is not present and instead the "iommu-map" property is used on the host bridge node to map the endpoint RequesterIDs to their corresponding IOMMU instance.
Add support for "iommu-map" to the device link supplier bindings so that probing of PCI devices can be deferred until after the IOMMU is available.
Cc Greg Kroah-Hartman <[email protected]>
Cc Rob Herring <[email protected]>
Cc Saravana Kannan <[email protected]>
Cc Robin Murphy <[email protected]>
Signed-off-by Will Deacon <[email protected]>
---

Quoted 7 lines

Quoted 2 lines
Applies against driver-core/driver-core-next.
Tested on AMD Seattle (arm64).
Guess that answers my question whether anyone uses Seattle with DT. Seattle uses the old SMMU binding, and there's not even an IOMMU associated with the PCI host. I raise this mainly because the dts files for Seattle either need some love or perhaps should be removed.

I'm using the new DT bindings on my Seattle, thanks to the firmware fairy (Ard) visiting my flat with a dediprog. The patches I've posted to enable modular builds of the arm-smmu driver require that the old binding is disabled [1].

Quoted 1 line

No issues with the patch itself though. I'll queue it after rc1.

Thanks, although I think Greg has already queued it [2] due to the dependencies on other patches in his tree.

Will

[1] https://lore.kernel.org/lkml/[email protected]/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?h=driver-core-next&id=e149573b2f84d0517648dafc0db625afa681ed54

Rob Herring

maintainer

2019-11-22 16:01 UTC #4 lore raw

Quoted 34 lines · Will Deacon

[+Ard]
Hi Rob,
Quoted 20 lines · Rob Herring
Quoted 19 lines · Will Deacon
Commit 8e12257dead7 ("of: property: Add device link support for iommus, mboxes and io-channels") added device link support for IOMMU linkages described using the "iommus" property. For PCI devices, this property is not present and instead the "iommu-map" property is used on the host bridge node to map the endpoint RequesterIDs to their corresponding IOMMU instance.
Add support for "iommu-map" to the device link supplier bindings so that probing of PCI devices can be deferred until after the IOMMU is available.
Cc Greg Kroah-Hartman <[email protected]>
Cc Rob Herring <[email protected]>
Cc Saravana Kannan <[email protected]>
Cc Robin Murphy <[email protected]>
Signed-off-by Will Deacon <[email protected]>
---
Quoted 7 lines
Quoted 2 lines
Applies against driver-core/driver-core-next.
Tested on AMD Seattle (arm64).
Guess that answers my question whether anyone uses Seattle with DT. Seattle uses the old SMMU binding, and there's not even an IOMMU associated with the PCI host. I raise this mainly because the dts files for Seattle either need some love or perhaps should be removed.

Quoted 4 lines

I'm using the new DT bindings on my Seattle, thanks to the firmware fairy (Ard) visiting my flat with a dediprog. The patches I've posted to enable modular builds of the arm-smmu driver require that the old binding is disabled [1].

Going to post those dts changes?

Quoted 4 lines

Quoted 1 line
No issues with the patch itself though. I'll queue it after rc1.
Thanks, although I think Greg has already queued it [2] due to the dependencies on other patches in his tree.

Okay, forgot to check my spam from Greg folder and missed that.

Rob

Ard Biesheuvel

2019-11-22 16:13 UTC #5 lore raw

Quoted 36 lines · Rob Herring

Quoted 34 lines · Will Deacon
[+Ard]
Hi Rob,
Quoted 27 lines · Rob Herring
Quoted 17 lines · Will Deacon
Commit 8e12257dead7 ("of: property: Add device link support for iommus, mboxes and io-channels") added device link support for IOMMU linkages described using the "iommus" property. For PCI devices, this property is not present and instead the "iommu-map" property is used on the host bridge node to map the endpoint RequesterIDs to their corresponding IOMMU instance.
Add support for "iommu-map" to the device link supplier bindings so that probing of PCI devices can be deferred until after the IOMMU is available.
Cc Greg Kroah-Hartman <[email protected]>
Cc Rob Herring <[email protected]>
Cc Saravana Kannan <[email protected]>
Cc Robin Murphy <[email protected]>
Signed-off-by Will Deacon <[email protected]>
Quoted 4 lines
---
Applies against driver-core/driver-core-next.
Tested on AMD Seattle (arm64).
Guess that answers my question whether anyone uses Seattle with DT. Seattle uses the old SMMU binding, and there's not even an IOMMU associated with the PCI host. I raise this mainly because the dts files for Seattle either need some love or perhaps should be removed.

Quoted 7 lines

Quoted 4 lines
I'm using the new DT bindings on my Seattle, thanks to the firmware fairy (Ard) visiting my flat with a dediprog. The patches I've posted to enable modular builds of the arm-smmu driver require that the old binding is disabled [1].
Going to post those dts changes?

Last time I tried upstreaming seattle DT changes I got zero response, so I didn't bother since.

Quoted 8 lines

Quoted 4 lines
Quoted 1 line
No issues with the patch itself though. I'll queue it after rc1.
Thanks, although I think Greg has already queued it [2] due to the dependencies on other patches in his tree.
Okay, forgot to check my spam from Greg folder and missed that.
Rob

Rob Herring

maintainer

2019-11-22 20:16 UTC #6 lore raw

Quoted 43 lines · Ard Biesheuvel

Quoted 41 lines · Rob Herring
Quoted 38 lines · Will Deacon
[+Ard]
Hi Rob,
Quoted 20 lines · Rob Herring
Quoted 19 lines · Will Deacon
Commit 8e12257dead7 ("of: property: Add device link support for iommus, mboxes and io-channels") added device link support for IOMMU linkages described using the "iommus" property. For PCI devices, this property is not present and instead the "iommu-map" property is used on the host bridge node to map the endpoint RequesterIDs to their corresponding IOMMU instance.
Add support for "iommu-map" to the device link supplier bindings so that probing of PCI devices can be deferred until after the IOMMU is available.
Cc Greg Kroah-Hartman <[email protected]>
Cc Rob Herring <[email protected]>
Cc Saravana Kannan <[email protected]>
Cc Robin Murphy <[email protected]>
Signed-off-by Will Deacon <[email protected]>
---
Quoted 7 lines
Quoted 2 lines
Applies against driver-core/driver-core-next.
Tested on AMD Seattle (arm64).
Guess that answers my question whether anyone uses Seattle with DT. Seattle uses the old SMMU binding, and there's not even an IOMMU associated with the PCI host. I raise this mainly because the dts files for Seattle either need some love or perhaps should be removed.
I'm using the new DT bindings on my Seattle, thanks to the firmware fairy (Ard) visiting my flat with a dediprog. The patches I've posted to enable modular builds of the arm-smmu driver require that the old binding is disabled [1].

Quoted 5 lines

Quoted 2 lines
Going to post those dts changes?
Last time I tried upstreaming seattle DT changes I got zero response, so I didn't bother since.

I leave most dts reviews up to sub-arch maintainers and I'm pretty sure AMD doesn't care about it anymore, so we need a new maintainer or just send a pull request to Arnd/Olof.

Rob

Will Deacon

author Tested-by

2019-11-25 07:49 UTC #7 lore raw

Quoted 48 lines · Rob Herring

Quoted 46 lines · Ard Biesheuvel
Quoted 43 lines · Rob Herring
Quoted 34 lines · Will Deacon
[+Ard]
Hi Rob,
Quoted 20 lines · Rob Herring
Quoted 19 lines · Will Deacon
Commit 8e12257dead7 ("of: property: Add device link support for iommus, mboxes and io-channels") added device link support for IOMMU linkages described using the "iommus" property. For PCI devices, this property is not present and instead the "iommu-map" property is used on the host bridge node to map the endpoint RequesterIDs to their corresponding IOMMU instance.
Add support for "iommu-map" to the device link supplier bindings so that probing of PCI devices can be deferred until after the IOMMU is available.
Cc Greg Kroah-Hartman <[email protected]>
Cc Rob Herring <[email protected]>
Cc Saravana Kannan <[email protected]>
Cc Robin Murphy <[email protected]>
Signed-off-by Will Deacon <[email protected]>
---
Quoted 7 lines
Quoted 2 lines
Applies against driver-core/driver-core-next.
Tested on AMD Seattle (arm64).
Guess that answers my question whether anyone uses Seattle with DT. Seattle uses the old SMMU binding, and there's not even an IOMMU associated with the PCI host. I raise this mainly because the dts files for Seattle either need some love or perhaps should be removed.
Quoted 4 lines
I'm using the new DT bindings on my Seattle, thanks to the firmware fairy (Ard) visiting my flat with a dediprog. The patches I've posted to enable modular builds of the arm-smmu driver require that the old binding is disabled [1].
Going to post those dts changes?

Quoted 6 lines

Quoted 2 lines
Last time I tried upstreaming seattle DT changes I got zero response, so I didn't bother since.
I leave most dts reviews up to sub-arch maintainers and I'm pretty sure AMD doesn't care about it anymore, so we need a new maintainer or just send a pull request to Arnd/Olof.

Feel free to add my:

Tested-by Will Deacon <[email protected]>

If it's the same as the DT exposed by the firmware I have.

Will