On 08/10/2024 2:32 pm, H. Nikolaus Schaller wrote:
Hi Robin,
Am 08.10.2024 um 15:17 schrieb Robin Murphy <robin.murphy@xxxxxxx>:
The OMAP driver still has its own traditional firmware parsing and
instance handling in omap_iommu_probe_device(), rather than using the
generic fwnode-based paths. However, it also passes a hwdev to
iommu_device_register(), thus registering a fwnode for each ops
instance, wherein __iommu_probe_device() then fails to find matching ops
for a client device with no fwspec and thus a NULL iommu_fwnode.
Since omap-iommu is not known to coexist with any other IOMMU hardware
and shares the same ops between all instances, we can reasonably remove
the hwdev/fwnode registration to put it back into "legacy" mode where
the ops are effectively global and ->probe_device remains responsible
for filtering individual clients.
Reported-by: Beleswar Padhi <b-padhi@xxxxxx>
Reported-by: H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>
Fixes: 17de3f5fdd35 ("iommu: Retire bus ops")
Signed-off-by: Robin Murphy <robin.murphy@xxxxxxx>
---
drivers/iommu/omap-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index c9528065a59a..425ae8e551dc 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1230,7 +1230,7 @@ static int omap_iommu_probe(struct platform_device *pdev)
if (err)
return err;
- err = iommu_device_register(&obj->iommu, &omap_iommu_ops, &pdev->dev);
+ err = iommu_device_register(&obj->iommu, &omap_iommu_ops, NULL);
Thanks for this proposal, but this prevents my OMAP3 system completely
from booting (at least with v6.8-rc1):
## Booting kernel from Legacy Image at 82000000 ...
Image Name: Linux-6.8.0-rc1-letux+
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6491520 Bytes = 6.2 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 81c00000
Booting using the fdt blob at 0x81c00000
Loading Kernel Image ... OK
Using Device Tree in place at 81c00000, end 81c1fe8e
Starting kernel ...
--- no further reaction --
Urgh... is it possible to get earlycon/ealyprintk output on this platform?
As a stab in the dark by inspection, there might potentially be some
interaction with "iommu: Move bus setup to IOMMU device registration" as
well, for which the additional diff below might help...
Thanks,
Robin.
---->8----
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 425ae8e551dc..9112178e22d8 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1691,7 +1691,8 @@ static struct iommu_device
*omap_iommu_probe_device(struct device *dev)
if (!oiommu) {
of_node_put(np);
kfree(arch_data);
- return ERR_PTR(-EINVAL);
+ /* Not fatal, will re-probe once the right instance registers itself */
+ return ERR_PTR(-ENODEV);
}
tmp->iommu_dev = oiommu;
As far as I see, all relevant devices are in the iommu_device_list but
only omap3.isp is really using iommu. So some other devices may fail by
this change.
BR,
Nikolaus