On Fri, May 5, 2017 at 3:50 PM, Rob Herring <r...@kernel.org> wrote: > On Fri, May 5, 2017 at 2:37 PM, Rob Clark <robdcl...@gmail.com> wrote: >> On Fri, May 5, 2017 at 3:04 PM, Rob Herring <r...@kernel.org> wrote: >>> On Fri, May 5, 2017 at 1:21 PM, Rob Clark <robdcl...@gmail.com> wrote: >>>> An iommu driver for Qualcomm "B" family devices which do not completely >>>> implement the ARM SMMU spec. These devices have context-bank register >>>> layout that is similar to ARM SMMU, but no global register space (or at >>>> least not one that is accessible). >>>> >>>> Signed-off-by: Rob Clark <robdcl...@gmail.com> >>>> --- >>>> v1: original >>>> v2: bindings cleanups and kconfig issues that kbuild robot pointed out >>>> v4: fix issues pointed out by Rob H. and actually make device removal >>>> work >>>> v3: fix WARN_ON() splats reported by Archit >>>> >>>> drivers/iommu/Kconfig | 9 + >>>> drivers/iommu/Makefile | 1 + >>>> drivers/iommu/qcom_iommu.c | 833 >>>> +++++++++++++++++++++++++++++++++++++++++++++ >>>> 3 files changed, 843 insertions(+) >>>> create mode 100644 drivers/iommu/qcom_iommu.c >>>> >>>> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig >>>> index 37e204f..f8f79a4 100644 >>>> --- a/drivers/iommu/Kconfig >>>> +++ b/drivers/iommu/Kconfig >>>> @@ -359,4 +359,13 @@ config MTK_IOMMU_V1 >>>> >>>> if unsure, say N here. >>>> >>>> +config QCOM_IOMMU >>>> + bool "Qualcomm IOMMU Support" >>> >>> Either this needs to be tristate or... >>> >>> [...] >>>> +#include <linux/module.h> >>> >>> this include and the things that need it should go. Or some >>> explanation like "once X happens, then we can enable as module" and >>> leave it all for now. >> >> tbh, I'm not sure what the issue is for modules (other than >> potentially that you'd want the iommu driver fairly early in boot if >> you didn't have an initrd). I just saw that the other iommu drivers >> are all bool. (Sorry, I don't really follow iommu-devel so not >> familiar with the history.) With my distro hat on, I would prefer >> them to be modules eventually. > > For starters, does it even build as a module if you allow that? It > might not work because of some run-time ordering, but that's good > enough for this discussion.
It does in fact build as a module.. I suppose I need to figure out a more convenient way to re-pack modules in an initrd to actually test it and see what does or does not explode.. BR, -R >> >>> See this[1] for some background. >> >> it mentions there are some downsides, but I can't see where those >> downsides are listed ;-) >> >> I would kinda prefer to leave the MODULE_*() stuff in place unless >> modular iommu drivers are never going to happen. > > Maybe a note, so the module police don't fix it. > > Rob _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
