Hi, > Am 07.04.2022 um 07:39 schrieb Tony Lindgren <t...@atomide.com>: > > Hi, > > * Tony Lindgren <t...@atomide.com> [220331 09:21]: >> Commit 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") started >> triggering a NULL pointer dereference for some omap variants: >> >> __iommu_probe_device from probe_iommu_group+0x2c/0x38 >> probe_iommu_group from bus_for_each_dev+0x74/0xbc >> bus_for_each_dev from bus_iommu_probe+0x34/0x2e8 >> bus_iommu_probe from bus_set_iommu+0x80/0xc8 >> bus_set_iommu from omap_iommu_init+0x88/0xcc >> omap_iommu_init from do_one_initcall+0x44/0x24 >> >> This is caused by omap iommu probe returning 0 instead of ERR_PTR(-ENODEV) >> as noted by Jason Gunthorpe <j...@ziepe.ca>. >> >> Looks like the regression already happened with an earlier commit >> 6785eb9105e3 ("iommu/omap: Convert to probe/release_device() call-backs") >> that changed the function return type and missed converting one place. > > Can you guys please get this fix into the -rc series? Or ack it so > I can pick it up into my fixes branch? > > Without this fix booting is failing for a bunch of devices.
Yes, I can confirm that v5.18-rc1 does not even boot the GTA04 (omap3) and OMAP5UEVM to any activity without this patch. Seems to be an urgent fix. BR and thanks, Nikolaus _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu