Hi Joerg, On Wed, Oct 30, 2019 at 08:31:48PM +0100, Joerg Roedel wrote: > On Wed, Oct 30, 2019 at 02:51:10PM +0000, Will Deacon wrote: > > By removing the redundant call to 'pci_request_acs()' we can allow the > > ARM SMMUv3 driver to be built as a module. > > > > Signed-off-by: Will Deacon <w...@kernel.org> > > --- > > drivers/iommu/Kconfig | 2 +- > > drivers/iommu/arm-smmu-v3.c | 1 - > > 2 files changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > > index e3842eabcfdd..7583d47fc4d5 100644 > > --- a/drivers/iommu/Kconfig > > +++ b/drivers/iommu/Kconfig > > @@ -388,7 +388,7 @@ config ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT > > config. > > > > config ARM_SMMU_V3 > > - bool "ARM Ltd. System MMU Version 3 (SMMUv3) Support" > > + tristate "ARM Ltd. System MMU Version 3 (SMMUv3) Support" > > depends on ARM64 > > select IOMMU_API > > select IOMMU_IO_PGTABLE_LPAEa > > Sorry for the stupid question, but what prevents the iommu module from > being unloaded when there are active users? There are no symbol > dependencies to endpoint device drivers, because the interface is only > exposed through the iommu-api, right? Is some sort of manual module > reference counting needed?
Generally, I think unloading the IOMMU driver module while there are active users is a pretty bad idea, much like unbinding the driver via /sys in the same situation would also be fairly daft. However, I *think* the code in __device_release_driver() tries to deal with this by iterating over the active consumers and ->remove()ing them first. I'm without hardware access at the moment, so I haven't been able to test this myself. We could nobble the module_exit() hook, but there's still the "force unload" option depending on the .config. Will _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
