linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: Saravana Kannan <saravanak@google.com>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Robin Murphy <robin.murphy@arm.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"Will Deacon" <will@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers
Date: Mon, 4 Nov 2019 12:16:03 +0000	[thread overview]
Message-ID: <47418554-e7a7-f9f3-8852-60cecef3d5c7@huawei.com> (raw)
In-Reply-To: <CAGETcx-9M8vvHA2Lykcv0hHWoC2OAw5kfBrjcNJN2CYCwR4eWQ@mail.gmail.com>

On 01/11/2019 21:13, Saravana Kannan wrote:
> On Fri, Nov 1, 2019 at 3:28 AM John Garry <john.garry@huawei.com> wrote:
>>
>> On 31/10/2019 23:34, Saravana Kannan via iommu wrote:
>>> I looked into the iommu-map property and it shouldn't be too hard to
>>> add support for it. Looks like we can simply hold off on probing the
>>> root bridge device till all the iommus in its iommu-map are probed and
>>> we should be fine.
>>>
>>>> I'm also unsure about distro vendors agreeing to a mandatory kernel
>>>> parameter (of_devlink). Do you plan to eventually enable it by default?
>>>>
>>>>> static const struct supplier_bindings of_supplier_bindings[] = {
>>>>>           { .parse_prop = parse_clocks, },
>>>>>           { .parse_prop = parse_interconnects, },
>>>>>           { .parse_prop = parse_regulators, },
>>>>> +        { .parse_prop = parse_iommus, },
>>>>>           {},
>>>>> };
>>>>>
>>>>> I plan to upstream this pretty soon, but I have other patches in
>>>>> flight that touch the same file and I'm waiting for those to get
>>>>> accepted. I also want to clean up the code a bit to reduce some
>>>>> repetition before I add support for more bindings.
>>>> I'm also wondering about ACPI support.
>>> I'd love to add ACPI support too, but I have zero knowledge of ACPI.
>>> I'd be happy to help anyone who wants to add ACPI support that allows
>>> ACPI to add device links.
>>
>> If possible to add, that may be useful for remedying this:
>>
>> https://lore.kernel.org/linux-iommu/9625faf4-48ef-2dd3-d82f-931d9cf26976@huawei.com/
> 
> I'm happy that this change might fix that problem, but isn't the
> problem reported in that thread more to do with child devices getting
> added before the parent probes successfully? That doesn't make sense
> to me. 

So the pcieport device and then the child device are added in the PCI 
scan, but only some time later do the device drivers probe for these 
devices; so it's not that the that pcieport driver creates the child device.

The problem then occurs in that the ordering the of device driver probe 
is such that we have this: pcieport probe + defer (as no IOMMU group 
registered), SMMU probe (registers the IOMMU group), child device probe, 
pcieport really probe.

Can't the piceport driver not add its child devices before it
> probes successfully? Or more specifically, who adds the child devices
> of the pcieport before the pcieport itself probes?

The devices are actually added in order pcieport, child device, but not 
really probed in that same order, as above.

I'll add you to that thread if you want to discuss further.

Thanks,
John


  reply	other threads:[~2019-11-04 12:16 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-30 14:51 [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers Will Deacon
2019-10-30 14:51 ` [PATCH 1/7] drivers/iommu: Export core IOMMU API symbols to permit modular drivers Will Deacon
2019-10-30 14:51 ` [PATCH 2/7] iommu/of: Request ACS from the PCI core when configuring IOMMU linkage Will Deacon
2019-10-30 14:51 ` [PATCH 3/7] PCI: Export pci_ats_disabled() as a GPL symbol to modules Will Deacon
2019-10-30 20:30   ` Bjorn Helgaas
2019-10-30 14:51 ` [PATCH 4/7] Revert "iommu/arm-smmu: Make arm-smmu-v3 explicitly non-modular" Will Deacon
2019-10-30 14:51 ` [PATCH 5/7] iommu/arm-smmu-v3: Allow building as a module Will Deacon
2019-10-30 19:31   ` Joerg Roedel
2019-10-31 15:42     ` Will Deacon
2019-11-04 19:15       ` Jean-Philippe Brucker
2019-11-08 14:54         ` Will Deacon
2019-11-05 12:15       ` Joerg Roedel
2019-11-08 11:03         ` Will Deacon
2019-10-30 14:51 ` [PATCH 6/7] Revert "iommu/arm-smmu: Make arm-smmu explicitly non-modular" Will Deacon
2019-10-30 23:09   ` Jordan Crouse
2019-10-31 12:03     ` Will Deacon
2019-10-31 15:32       ` Jordan Crouse
2019-10-30 14:51 ` [PATCH 7/7] iommu/arm-smmu: Allow building as a module Will Deacon
2019-10-30 15:22   ` Rob Herring
2019-10-30 15:26     ` Will Deacon
2019-10-30 15:33     ` Robin Murphy
2019-11-04 19:34   ` Isaac J. Manjarres
2019-11-07 12:48     ` Will Deacon
2019-10-30 15:35 ` [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers Robin Murphy
2019-10-30 15:54   ` Will Deacon
2019-10-31  0:57     ` Saravana Kannan
2019-10-31 19:37       ` Jean-Philippe Brucker
2019-10-31 23:34         ` Saravana Kannan
2019-11-01 10:27           ` John Garry
2019-11-01 21:13             ` Saravana Kannan
2019-11-04 12:16               ` John Garry [this message]
2019-11-04 13:29                 ` Robin Murphy
2019-11-07  6:11                   ` Saravana Kannan
2019-11-07  9:13                     ` Jean-Philippe Brucker
2019-11-07  6:02                 ` Saravana Kannan
2019-11-01 11:41           ` Jean-Philippe Brucker
2019-11-01 12:28             ` Lorenzo Pieralisi
2019-11-01 21:26               ` Saravana Kannan
2019-11-04 11:43                 ` Lorenzo Pieralisi
2019-11-07  5:55                   ` Saravana Kannan
2019-11-01 17:21         ` Will Deacon
2019-11-04  7:54           ` Jean-Philippe Brucker
2019-11-07  6:16       ` Saravana Kannan

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=47418554-e7a7-f9f3-8852-60cecef3d5c7@huawei.com \
    --to=john.garry@huawei.com \
    --cc=bhelgaas@google.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jean-philippe@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=saravanak@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).