All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zenghui Yu <yuzenghui@huawei.com>
To: richard clark <richard.xnu.clark@gmail.com>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
	<linux-arm-kernel@lists.infradead.org>, <mark.rutland@arm.com>,
	<will@kernel.org>
Subject: Re: Question: multiple SMMUv3 devices probe
Date: Wed, 14 Apr 2021 10:39:54 +0800	[thread overview]
Message-ID: <403674d3-1146-f893-f31a-8a8b26c8fa2d@huawei.com> (raw)
In-Reply-To: <CAJNi4rPo47c3GL9jDUuy4N=7aunKUgr3-oPxtVj=YZaNs=fvKQ@mail.gmail.com>

On 2021/4/14 9:45, richard clark wrote:
> Jean-Philippe Brucker <jean-philippe@linaro.org> 于2021年4月13日周二 下午8:58写道:
>>
>> On Tue, Apr 13, 2021 at 08:40:47PM +0800, richard clark wrote:

[...]

>>> Actually, my question is a if pci device driver probes its device
>>> before the SMMUv3 driver probing,
>>> how does that pci device using the DMA with SMMU translation?
>>
>> It doesn't - by looking at the dependencies described in device-tree
> (forget to reply all, so add the CC'ing...)
> I understand 'it doesn't' here means the pci driver will not probe its
> device before SMMU driver is on
>> (iommu-map property) or in ACPI IORT, we defer probe of the PCI device
>> until the SMMU is operational.
>>
> If that is correct, Jean, would you point me to the code snippet that
> a pci driver will defer
> its probe until the SMMU is functional? Some key points are enough...

I think it's correct. Take ACPI-based system as an example, we setup PCI
device's DMA configuration by pci_dma_configure()/acpi_dma_configure().
If as you said, the PCI device is probed before the SMMUv3 probing, we
will get *-EPROBE_DEFER* during the DMA configuration. Please have a
look at iort_pci_iommu_init()/iort_iommu_xlate(), which should have
provided the whole details for us.

The device we *are* probing is then put onto the "deferred list" (grep
it in the driver core code) and will be retried from the list by
deferred_probe_work.

Hope it helps.


Zenghui

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-04-14  2:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-07  9:37 Question: multiple SMMUv3 devices probe richard clark
2021-04-08  1:31 ` richard clark
2021-04-08  7:25 ` Jean-Philippe Brucker
     [not found]   ` <CAJNi4rPx=oh7iv=4=-5PV-7OAgkZzr5zLysgTjr3YVKzHsC44w@mail.gmail.com>
     [not found]     ` <YHWVWiQpS93lRNly@myrica>
2021-04-14  1:45       ` richard clark
2021-04-14  2:39         ` Zenghui Yu [this message]
2021-04-14  3:17           ` richard clark

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=403674d3-1146-f893-f31a-8a8b26c8fa2d@huawei.com \
    --to=yuzenghui@huawei.com \
    --cc=jean-philippe@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=richard.xnu.clark@gmail.com \
    --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.