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

[Robin Murphy <robin.murphy@arm.com>]

On 2025-03-10 4:45 pm, Aaron Kling wrote:
> On Mon, Mar 10, 2025 at 7:42 AM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 2025-03-10 6:11 am, Aaron Kling via B4 Relay wrote:
>>> From: Aaron Kling <webgeek1234@gmail.com>
>>>
>>> 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.