linux-kernel - Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGETcx-9M8vvHA2Lykcv0hHWoC2OAw5kfBrjcNJN2CYCwR4eWQ@mail.gmail.com>
Date:   Fri, 1 Nov 2019 14:13:41 -0700
From:   Saravana Kannan <saravanak@...gle.com>
To:     John Garry <john.garry@...wei.com>
Cc:     Jean-Philippe Brucker <jean-philippe@...aro.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Robin Murphy <robin.murphy@....com>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        Will Deacon <will@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers

On Fri, Nov 1, 2019 at 3:28 AM John Garry <john.garry@...wei.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. 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?

Thanks,
Saravana