From: Robin Murphy <robin.murphy@arm.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: joro@8bytes.org, will@kernel.org, iommu@lists.linux.dev,
linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH] iommu/ipmmu-vmsa: Register in a sensible order
Date: Tue, 1 Apr 2025 14:53:35 +0100 [thread overview]
Message-ID: <f72bcfb2-e2a1-4dd4-bedf-241b75178958@arm.com> (raw)
In-Reply-To: <CAMuHMdUtCqwzeWY8G+yHiu4biovymDVb_UtjfYPEQYyYr+dP4Q@mail.gmail.com>
On 2025-03-25 3:26 pm, Geert Uytterhoeven wrote:
> Hi Robin,
>
> On Thu, 20 Mar 2025 at 15:41, Robin Murphy <robin.murphy@arm.com> wrote:
>> IPMMU registers almost-initialised instances, but misses assigning the
>> drvdata to make them fully functional, so initial calls back into
>> ipmmu_probe_device() are likely to fail unnecessarily. Reorder this to
>> work as it should, also pruning the long-out-of-date comment and adding
>> the missing sysfs cleanup on error for good measure.
>>
>> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
>> Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path")
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>
> Thanks for your patch!
>
> This fixes the
>
> sata_rcar ee300000.sata: late IOMMU probe at driver bind,
> something fishy here!
> WARNING: CPU: 1 PID: 13 at drivers/iommu/iommu.c:571
> __iommu_probe_device+0x208/0x38c
>
> I saw on Salvator-XS with R-Car M3-N.
>
> It does not fix the second issue reported, so it is indeed too early for a
> "Closes: https://lore.kernel.org/CAMuHMdWPFnHTFeeWL2-BU8tKOL-E5K2ROOz=LLBLTJJLCK9NgA@mail.gmail.com"
> tag.
You mean .of_xlate being called multiple times? That's not an issue,
it's normal and expected. Every time an IOMMU instance registers, it
triggers a probe of all relevant devices which do not yet have an IOMMU
- this has never been selective, so if a device is associated with a
different already-registered IOMMU instance, but does not have a group
because that instance's .probe_device rejected it, that probe also gets
tried (and rejected) again.
The core code behaviour has been this way for a very long time, the only
new thing is that the .of_xlate calls are now in sync with their
corresponding .probe_device calls (and the latter are also now working
properly again for fwspec-based ops).
Was it just that, or is there still something functionally amiss?
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks!
Robin.
>> --- a/drivers/iommu/ipmmu-vmsa.c
>> +++ b/drivers/iommu/ipmmu-vmsa.c
>> @@ -1081,31 +1081,24 @@ static int ipmmu_probe(struct platform_device *pdev)
>> }
>> }
>>
>> + platform_set_drvdata(pdev, mmu);
>
> Nit: perhaps insert a blank line here, before the comment below?
>
>> /*
>> * Register the IPMMU to the IOMMU subsystem in the following cases:
>> * - R-Car Gen2 IPMMU (all devices registered)
>> * - R-Car Gen3 IPMMU (leaf devices only - skip root IPMMU-MM device)
>> */
>> - if (!mmu->features->has_cache_leaf_nodes || !ipmmu_is_root(mmu)) {
>> - ret = iommu_device_sysfs_add(&mmu->iommu, &pdev->dev, NULL,
>> - dev_name(&pdev->dev));
>> - if (ret)
>> - return ret;
>> + if (mmu->features->has_cache_leaf_nodes && ipmmu_is_root(mmu))
>> + return 0;
>>
>> - ret = iommu_device_register(&mmu->iommu, &ipmmu_ops, &pdev->dev);
>> - if (ret)
>> - return ret;
>> - }
>> + ret = iommu_device_sysfs_add(&mmu->iommu, &pdev->dev, NULL, dev_name(&pdev->dev));
>> + if (ret)
>> + return ret;
>>
>> - /*
>> - * We can't create the ARM mapping here as it requires the bus to have
>> - * an IOMMU, which only happens when bus_set_iommu() is called in
>> - * ipmmu_init() after the probe function returns.
>> - */
>> + ret = iommu_device_register(&mmu->iommu, &ipmmu_ops, &pdev->dev);
>> + if (ret)
>> + iommu_device_sysfs_remove(&mmu->iommu);
>>
>> - platform_set_drvdata(pdev, mmu);
>> -
>> - return 0;
>> + return ret;
>> }
>>
>> static void ipmmu_remove(struct platform_device *pdev)
>
> Gr{oetje,eeting}s,
>
> Geert
>
next prev parent reply other threads:[~2025-04-01 13:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 14:41 [PATCH] iommu/ipmmu-vmsa: Register in a sensible order Robin Murphy
2025-03-25 15:26 ` Geert Uytterhoeven
2025-04-01 13:53 ` Robin Murphy [this message]
2025-04-01 14:11 ` Geert Uytterhoeven
2025-04-03 16:37 ` Robin Murphy
2025-04-11 7:24 ` Joerg Roedel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f72bcfb2-e2a1-4dd4-bedf-241b75178958@arm.com \
--to=robin.murphy@arm.com \
--cc=geert@linux-m68k.org \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox