linux-kernel - Re: [PATCH] iommu/arm: Allow disabling Qualcomm support in arm_smmu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c99db1aa-8b3e-4a8d-8cee-b9574686cb7f@arm.com>
Date: Mon, 10 Mar 2025 19:52:37 +0000
From: Robin Murphy <robin.murphy@....com>
To: Aaron Kling <webgeek1234@...il.com>
Cc: Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
 Arnd Bergmann <arnd@...db.de>, iommu@...ts.linux.dev,
 linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] iommu/arm: Allow disabling Qualcomm support in
 arm_smmu_v3

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