Re: [PATCH] iommu/arm: Allow disabling Qualcomm support in arm_smmu_v3

[Robin Murphy]

On 2025-03-10 4:45 pm, Aaron Kling wrote:
> On Mon, Mar 10, 2025 at 7:42 AM Robin Murphy <robin.murphy@xxxxxxx> wrote:
> > On 2025-03-10 6:11 am, Aaron Kling via B4 Relay wrote:
> > > From: Aaron Kling <webgeek1234@xxxxxxxxx>
> > >
> > > If ARCH_QCOM is enabled when building arm_smmu_v3,
> >
> > This has nothing to do with SMMUv3, though?
> >
> > > a dependency on
> > > qcom-scm is added, which currently cannot be disabled. Add a prompt to
> > > ARM_SMMU_QCOM to allow disabling this dependency.
> >
> > Why is that an issue - what problem arises from having the SCM driver
> > enabled? AFAICS it's also selected by plenty of other drivers including
> > pretty fundamental ones like pinctrl. If it is somehow important to
> > exclude the SCM driver, then I can't really imagine what the use-case
> > would be for building a kernel which won't work on most Qualcomm
> > platforms but not simply disabling ARCH_QCOM...
>
> I am working with the android kernel. The more recent setup enables a
> minimal setup of configs in a core kernel that works across all
> supported arch's, then requires further support to all be modules. I
> specifically am working with tegra devices. But as ARCH_QCOM is
> enabled in the core defconfig, when I build smmuv3 as a module, I end
> up with a dependency on qcom-scm which gets built as an additional
> module. And it would be preferable to not require qcom modules to boot
> a tegra device.

That just proves my point though - if you disable ARM_SMMU_QCOM in that 
context then you've got a kernel which won't work properly on Qualcomm 
platforms, so you may as well have just disabled ARCH_QCOM anyway. In 
fact the latter is objectively better since it then would not break the 
fundamental premise of "a core kernel that works across all supported 
arch's" :/

Maybe if you can find a viable way to separate out all the arm-smmu-qcom 
stuff into its own sub-module which only loads when needed, or possibly 
make SCM a soft-dep (given that we already have to cope with it being 
loaded but not initialised yet) then that might be a reasonable change 
to make; as it stands, I don't think this patch is. And it's definitely 
not a stable "fix" either way.

But frankly, weird modules happen. Why the heck is parport_pc currently 
loaded on my AArch64 workstation!? I can't even begin to imagine, but 
I'll live...

Thanks,
Robin.