[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f0374374-1f3b-6beb-b7e9-f8071d48bf4d@arm.com>
Date: Fri, 15 Jul 2022 14:12:36 +0100
From: Robin Murphy <robin.murphy@....com>
To: joro@...tes.org
Cc: will@...nel.org, iommu@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, baolu.lu@...ux.intel.com,
suravee.suthikulpanit@....com, vasant.hegde@....com,
mjrosato@...ux.ibm.com, gerald.schaefer@...ux.ibm.com,
schnelle@...ux.ibm.com, linux-s390@...r.kernel.org,
linux-kernel@...r.kernel.org, Kevin Tian <kevin.tian@...el.com>
Subject: Re: [PATCH v3 00/15] iommu: Retire bus_set_iommu()
On 2022-07-05 18:08, Robin Murphy wrote:
> v2: https://lore.kernel.org/linux-iommu/cover.1650890638.git.robin.murphy@arm.com/
>
> Hi all,
>
> Here's v3, now with working x86! Having finally made sense of how I
> broke Intel, I've given AMD the same fix by inspection. I'm still not
> 100% sure about s390, but it looks like it should probably be OK since
> it seems to register an IOMMU instance for each PCI device (?!) before
> disappearing into PCI hotplug code, wherein I assume we should never see
> a PCI device appear without its IOMMU already registered.
>
> Otherwise, the only other updates are hooking up the new host1x context
> bus (noting that it now takes all of 4 lines to support a whole new bus,
> yay!), and a slight tweak to make sure we keep rejecting registration of
> conflicting iommu_ops rather than needlessly change that just yet.
FWIW I've prepared v4, including Matt's s390 patch and some nice extra
cleanups thanks to Kevin's suggestions, but have now decided to wait to
rebase and send it after the upcoming merge window. If anyone's
interested in the meantime, there's a preliminary branch here:
https://gitlab.arm.com/linux-arm/linux-rm/-/commits/bus-set-iommu-v4
(temporarily including the host1x patch from -next to avoid breakage on
arm64 as well)
Thanks,
Robin.
Powered by blists - more mailing lists