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: <CALHNRZ87t7eXohTcpFnejFAPDsyE_1g0aPsASuQ7y5c_zxnLUw@mail.gmail.com>
Date: Mon, 10 Mar 2025 11:45:22 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Robin Murphy <robin.murphy@....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 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.

Sincerely,
Aaron

> Thanks,
> Robin.
>
> > Fixes: 0f0f80d9d5db ("iommu/arm: fix ARM_SMMU_QCOM compilation")
> > Cc: stable@...r.kernel.org
> > Signed-off-by: Aaron Kling <webgeek1234@...il.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,
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ