From: Aaron Kling webgeek1234@gmail.com
If ARCH_QCOM is enabled when building arm_smmu_v3, a dependency on qcom-scm is added, which currently cannot be disabled. Add a prompt to ARM_SMMU_QCOM to allow disabling this dependency.
Fixes: 0f0f80d9d5db ("iommu/arm: fix ARM_SMMU_QCOM compilation") Cc: stable@vger.kernel.org Signed-off-by: Aaron Kling webgeek1234@gmail.com --- drivers/iommu/Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index ec1b5e32b9725bc1104d10e5d7a32af7b211b50a..cca0825551959e3f37cc2ea41aeae526fdb73312 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -381,6 +381,7 @@ config ARM_SMMU_MMU_500_CPRE_ERRATA
config ARM_SMMU_QCOM def_tristate y + prompt "Qualcomm SMMUv3 Support" depends on ARM_SMMU && ARCH_QCOM select QCOM_SCM help
--- base-commit: 1110ce6a1e34fe1fdc1bfe4ad52405f327d5083b change-id: 20250310-b4-qcom-smmu-d4ccaf66a1ce
Best regards,
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...
Thanks, Robin.
Fixes: 0f0f80d9d5db ("iommu/arm: fix ARM_SMMU_QCOM compilation") Cc: stable@vger.kernel.org Signed-off-by: Aaron Kling webgeek1234@gmail.com
drivers/iommu/Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index ec1b5e32b9725bc1104d10e5d7a32af7b211b50a..cca0825551959e3f37cc2ea41aeae526fdb73312 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -381,6 +381,7 @@ config ARM_SMMU_MMU_500_CPRE_ERRATA config ARM_SMMU_QCOM def_tristate y
- prompt "Qualcomm SMMUv3 Support" depends on ARM_SMMU && ARCH_QCOM select QCOM_SCM help
base-commit: 1110ce6a1e34fe1fdc1bfe4ad52405f327d5083b change-id: 20250310-b4-qcom-smmu-d4ccaf66a1ce
Best regards,
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.
Sincerely, Aaron
Thanks, Robin.
Fixes: 0f0f80d9d5db ("iommu/arm: fix ARM_SMMU_QCOM compilation") Cc: stable@vger.kernel.org Signed-off-by: Aaron Kling webgeek1234@gmail.com
drivers/iommu/Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index ec1b5e32b9725bc1104d10e5d7a32af7b211b50a..cca0825551959e3f37cc2ea41aeae526fdb73312 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -381,6 +381,7 @@ config ARM_SMMU_MMU_500_CPRE_ERRATA
config ARM_SMMU_QCOM def_tristate y
prompt "Qualcomm SMMUv3 Support" depends on ARM_SMMU && ARCH_QCOM select QCOM_SCM help
base-commit: 1110ce6a1e34fe1fdc1bfe4ad52405f327d5083b change-id: 20250310-b4-qcom-smmu-d4ccaf66a1ce
Best regards,
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.
On Mon, Mar 10, 2025 at 2:52 PM Robin Murphy robin.murphy@arm.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@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" :/
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.
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.
The cc stable could be dropped. But I'm working with android forks of 6.6 and 6.12 currently, so I was hoping to get this pushed back to stable, which would eventually filter its way over there.
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...
This is fair. But I've got to try at least to make the module spaghetti make sense. If no one tries, it just gets worse.
Thanks, Robin.
Sincerely, Aaron
On 10/03/2025 8:15 pm, Aaron Kling wrote:
On Mon, Mar 10, 2025 at 2:52 PM Robin Murphy robin.murphy@arm.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@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" :/
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.
On Mon, Mar 10, 2025 at 9:51 AM Aaron Kling webgeek1234@gmail.com wrote:
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.
If you want to build arm_smmu_v3.ko, you'd have
# CONFIG_ARM_SMMU is not set CONFIG_ARM_SMMU_V3=m
in your .config. I don't see how this would enable ARM_SMMU_QCOM or QCOM_SCM.
On Tue, Mar 11, 2025 at 12:55 PM Daniel Mentz danielmentz@google.com wrote:
On Mon, Mar 10, 2025 at 9:51 AM Aaron Kling webgeek1234@gmail.com wrote:
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.
If you want to build arm_smmu_v3.ko, you'd have
# CONFIG_ARM_SMMU is not set CONFIG_ARM_SMMU_V3=m
in your .config. I don't see how this would enable ARM_SMMU_QCOM or QCOM_SCM.
I went and double checked my defconfig snippet and I have to apologize. I put the wrong thing in the commit message and caused confusion to myself and the entire discussion. This is what I've got:
# MMU CONFIG_ARM_SMMU=m # CONFIG_ARM_SMMU_QCOM is not set
Tegra186, tegra194, and tegra234 are supported by arm-smmu, not by arm-smmu-v3. And these are the relevant archs I'm trying to work on.
Having the extra dep doesn't break anything, so worst case I continue to carry the extra dep or this as a downstream patch. But I had to at least try to decouple unnecessary dep.
Sincerely, Aaron
linux-stable-mirror@lists.linaro.org
-
Aaron Kling -
Aaron Kling via B4 Relay -
Daniel Mentz -
Robin Murphy