Message-ID: <053851d9-49e3-46f7-86ae-59dcee6ddaa9@arm.com>
Date: Tue, 11 Mar 2025 17:29:13 +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 10/03/2025 8:15 pm, Aaron Kling wrote:
> On Mon, Mar 10, 2025 at 2:52 PM Robin Murphy <robin.murphy@....com> wrote:
>>
>> 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" :/
> 
> I'm not sure this is entirely true. Google's GKI mandates a fixed core
> kernel Image. This has the minimal configs that can't be built as
> modules. Then each device build is supposed to build independent sets
> of modules via defconfig snippets that support the rest of the
> hardware. Then what gets booted on a device is a prebuilt core kernel
> image provided by Google, plus the modules built by the vendor. In
> this setup, qcom-scm and ARM_SMMU_QCOM are modules and not part of the
> core kernel. For a qcom target, arm_smmu_v3 would be built with
> ARM_SMMU_QCOM. But then any non-qcom target that needs arm_smmu_v3
> currently builds and deps qcom-scm. But there's no technical reason
> they need that dep.

There *is* a dependency, because when ARM_SMMU_QCOM is enabled and both 
ARM_SMMU=m and QCOM_SCM=m, arm-smmu.ko references symbols from 
qcom-scm.ko, so the module loader literally cannot load and dynamically 
link one without the other. As I said, you are welcome to do the work to 
try to relax that dependency somehow. What you cannot do is turn off 
ARM_SMMU_QCOM and functionally break ARCH_QCOM while still claiming to 
support ARCH_QCOM, because there is only one arm-smmu.ko - the fact that 
it's not built-in is immaterial, it's still effectively a "core" driver 
because it is shared by many different platforms.

Thanks,
Robin.

Powered by blists - more mailing lists