linux-kernel - Re: [PATCH v2 0/4] iommu: Remove iommu

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] [day] [month] [year] [list]

Date: Tue, 2 Jul 2024 13:23:56 +0100
From: Robin Murphy <robin.murphy@....com>
To: Saravana Kannan <saravanak@...gle.com>
Cc: Will Deacon <will@...nel.org>, Joerg Roedel <joro@...tes.org>,
 linux-acpi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, iommu@...ts.linux.dev,
 devicetree@...r.kernel.org, Rob Herring <robh@...nel.org>,
 Lorenzo Pieralisi <lpieralisi@...nel.org>, Hanjun Guo
 <guohanjun@...wei.com>, Sudeep Holla <sudeep.holla@....com>,
 "Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>,
 Jean-Philippe Brucker <jean-philippe@...aro.org>,
 Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [PATCH v2 0/4] iommu: Remove iommu_fwspec ops

On 21/06/2024 9:51 pm, Saravana Kannan wrote:
> On Fri, Jun 21, 2024 at 8:46 PM Robin Murphy <robin.murphy@....com> wrote:
>>
>> v1: https://lore.kernel.org/linux-iommu/cover.1713523251.git.robin.murphy@arm.com
>>
>> Hi all,
>>
>> Here's v2 of this little cleanup, with acks and the additional cosmetic
>> tweak suggested by Andy. There were some slightly non-trivial changes in
>> the rebase so I've left off Jean-Philippe's tested-by from v1, but I've
>> given it a quick spin on arm64 ACPI and DT and all seems well still.
> 
> Hi Robin,
> 
> I see in this series you talk about figuring out if a device has a
> driver that could match. There has been a "can_match" flag in every
> device that's set if a driver that match it is present, but hasn't
> probed the device yet (for whatever reason). Just pointing that out in
> case that makes things a lot easier for you. As of now, we don't
> handle clearing it when the driver is unregistered, but if that really
> needs to be handled, that shouldn't be too difficult.

Thanks, that's interesting to know. I'm not sure it's directly 
applicable here since we have the more general case where the IOMMU 
driver may also be a module that's not even loaded yet. What ultimately 
matters is whether someone has called iommu_device_register() for a 
matching IOMMU instance, or may do within a reasonable timeframe, so as 
long as we can keep relying on fw_devlink and deferred_probe_timeout to 
do most of the heavy lifting then I'd actually hope we can avoid getting 
into the low-level details here.

Cheers,
Robin.