Messages in this thread | | | Date | Fri, 1 Nov 2019 17:21:46 +0000 | From | Will Deacon <> | Subject | Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers |
| |
Hi Jean-Philippe,
Quick question while you figure out the devlink stuff with Saravana...
On Thu, Oct 31, 2019 at 08:37:58PM +0100, Jean-Philippe Brucker wrote: > On Wed, Oct 30, 2019 at 05:57:44PM -0700, Saravana Kannan via iommu wrote: > > > > > Obviously you need to be careful about using IOMMU drivers as modules, > > > > > since late loading of the driver for an IOMMU serving active DMA masters > > > > > is going to end badly in many cases. On Android, we're using device links > > > > > to ensure that the IOMMU probes first. > > > > > > > > Out of curiosity, which device links are those? Clearly not the RPM links > > > > created by the IOMMU drivers themselves... Is this some special Android > > > > magic, or is there actually a chance of replacing all the > > > > of_iommu_configure() machinery with something more generic? > > > > > > I'll admit that I haven't used them personally yet, but I'm referring to > > > this series from Saravana [CC'd]: > > > > > > https://lore.kernel.org/linux-acpi/20190904211126.47518-1-saravanak@google.com/ > > > > > > which is currently sitting in linux-next now that we're upstreaming the > > > "special Android magic" ;) > > Neat, I'm trying to do the same for virtio-iommu. It needs to be modular > because it depends on the virtio transport, which distributions usually > build as a module. So far I've been managing the device links in > virtio-iommu's add_device() and remove_device() callbacks [1]. Since it > relies on the existing probe deferral, I had to make a special case for > virtio-iommu to avoid giving up after initcalls_done [2].
As far as symbols exported from the IOMMU and PCI layers, did you find you needed anything on top of the stuff I'm exporting in patches 1 and 3?
Cheers,
Will
| |