Hi Robin, On Wed, Oct 30, 2019 at 03:35:55PM +0000, Robin Murphy wrote: > On 30/10/2019 14:51, Will Deacon wrote: > > As part of the work to enable a "Generic Kernel Image" across multiple > > Android devices, there is a need to seperate shared, core kernel code > > from modular driver code that may not be needed by all SoCs. This means > > building IOMMU drivers as modules. > > > > It turns out that most of the groundwork has already been done to enable > > the ARM SMMU drivers to be 'tristate' options in drivers/iommu/Kconfig; > > with a few symbols exported from the IOMMU/PCI core, everything builds > > nicely out of the box. The one exception is support for the legacy SMMU > > DT binding, which is not in widespread use and has never worked with > > modules, so we can simply remove that when building as a module rather > > than try to paper over it with even more hacks. > > > > 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-sarava...@google.com/ which is currently sitting in linux-next now that we're upstreaming the "special Android magic" ;) Will _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu