All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.