On Wed, Oct 30, 2019 at 5:57 PM Saravana Kannan <sarava...@google.com> wrote: > > On Wed, Oct 30, 2019 at 8:54 AM Will Deacon <w...@kernel.org> wrote: > > > > 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" ;) > > Hi Robin, > > Actually, none of this is special Android magic. Will is talking about > the of_devlink feature that's been merged into driver-core-next. > > A one line summary of of_devlink: the driver core + firmware (DT in > this case) automatically add the device links during device addition > based on the firmware properties of each device. The link that Will > gave has more details. > > Wrt IOMMUs, the only missing piece in upstream is a trivial change > that does something like this in drivers/of/property.c > > +static struct device_node *parse_iommus(struct device_node *np, > + const char *prop_name, int index) > +{ > + return parse_prop_cells(np, prop_name, index, "iommus", > + "#iommu-cells"); > +} > > 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.
As promised: https://lore.kernel.org/lkml/20191105065000.50407-1-sarava...@google.com/ -Saravana _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
