Re: [PATCH] iommu/omap: Don't register ops by fwnode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux