On Fri, Jul 12, 2024 at 04:28:37PM +0100, Robin Murphy wrote:
On 12/07/2024 4:24 pm, Jon Hunter wrote:
On 12/07/2024 12:48, Robin Murphy wrote:
...
I am seeing some failures on -next with some of our devices.
Bisect is pointing to this commit. Looks like the host1x device
is no longer probing successfully. I see the following ...
��tegra-host1x 50000000.host1x: failed to initialize fwspec: -517
��nouveau 57000000.gpu: failed to initialize fwspec: -517
The probe seems to be deferred forever. The above is seen on
Tegra210 but Tegra30 and Tegra194 are also having the same
problem. Interestingly it is not all devices and so make me
wonder if we are missing something on these devices? Let me know
if you have any thoughts.
Ugh, tegra-smmu has been doing a complete nonsense this whole time -
on closer inspection, it's passing the fwnode of the *client device*
where it should be that of the IOMMU device :(
I *think* it should probably just be a case of:
-��� err = iommu_fwspec_init(dev, of_fwnode_handle(dev->of_node));
+��� err = iommu_fwspec_init(dev, of_fwnode_handle(smmu->dev->of_node));
since smmu->dev appears to be the same one initially passed to
iommu_device_register(), so it at least ought to match and work, but
the SMMU device vs. MC device thing leaves me mildly wary of how
correct it might be overall.
(Also now I'm wondering why I didn't just use dev_fwnode() there...)
Yes making that change in the tegra-smmu driver does fix it.
Ace, thanks for confirming! I was just writing a follow-up to say that I've
pretty much convinced myself that this (proper diff below) should in fact be
the right thing to do in general as well :)
Will, Joerg, would you prefer to have a standalone fix patch for the
nvidia/tegra branch to then re-merge fwspec-ops-removal and fix up the
conflict, or just a patch on top of fwspec-ops-removal as below?
I've just fixed it locally on the tegra branch, so I'll then just
resolve the conflict with fwspec-ops-removal the right way. That way, we
can backport the thing if we need to.