On 10/03/2025 8:15 pm, Aaron Kling wrote:
On Mon, Mar 10, 2025 at 2:52 PM Robin Murphy <robin.murphy@xxxxxxx> wrote:
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" :/
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.
