[PATCH] firmware: QCOM interfaces should depend on ARCH_QCOM

Geert Uytterhoeven posted 1 patch 1 month, 3 weeks ago
drivers/firmware/qcom/Kconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
[PATCH] firmware: QCOM interfaces should depend on ARCH_QCOM
Posted by Geert Uytterhoeven 1 month, 3 weeks ago
The various Qualcomm firmware interfaces are only present on Qualcomm
systems.  Hence add dependencies on ARCH_QCOM, to prevent asking the
user about them when configuring a kernel without Qualcomm SoC support.
Make QCOM_PAS invisible instead, as it is already selected by its users
when needed.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
I wondered whether QCOM_SCM should be made invisible, too, as it seems
to be selected by its users? But apparently commit 5c1a2975d23c51c0
("firmware: qcom_scm: Migrate to generic PAS service") in net-next/main
and soc/for-next made it visible on purpose?
---
 drivers/firmware/qcom/Kconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig
index c7f8413ab996cf12..691db0ded8e8cf63 100644
--- a/drivers/firmware/qcom/Kconfig
+++ b/drivers/firmware/qcom/Kconfig
@@ -7,7 +7,7 @@
 menu "Qualcomm firmware drivers"
 
 config QCOM_PAS
-	tristate "Qualcomm generic PAS interface driver"
+	tristate "Qualcomm generic PAS interface driver" if COMPILE_TEST
 	help
 	  Enable the generic Peripheral Authentication Service (PAS) provided
 	  by the firmware. It acts as the common layer with different TZ
@@ -16,6 +16,7 @@ config QCOM_PAS
 
 config QCOM_PAS_TEE
 	tristate "Qualcomm PAS TEE interface driver"
+	depends on ARCH_QCOM || COMPILE_TEST
 	select QCOM_PAS
 	depends on TEE
 	depends on !CPU_BIG_ENDIAN
@@ -26,6 +27,7 @@ config QCOM_PAS_TEE
 
 config QCOM_SCM
 	tristate "Qualcomm PAS SCM interface driver"
+	depends on ARCH_QCOM || COMPILE_TEST
 	select QCOM_PAS
 	select QCOM_TZMEM
 	default y if ARCH_QCOM
-- 
2.43.0
Re: [PATCH] firmware: QCOM interfaces should depend on ARCH_QCOM
Posted by Bjorn Andersson 2 weeks, 6 days ago
On Thu, 06 Aug 2026 12:35:15 +0200, Geert Uytterhoeven wrote:
> The various Qualcomm firmware interfaces are only present on Qualcomm
> systems.  Hence add dependencies on ARCH_QCOM, to prevent asking the
> user about them when configuring a kernel without Qualcomm SoC support.
> Make QCOM_PAS invisible instead, as it is already selected by its users
> when needed.
> 
> 
> [...]

Applied, thanks!

[1/1] firmware: QCOM interfaces should depend on ARCH_QCOM
      commit: 8fecd3194de338bdc0c57597be61fdcf33e1832d

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>
Re: [PATCH] firmware: QCOM interfaces should depend on ARCH_QCOM
Posted by Sumit Garg 3 weeks ago
On Thu, Aug 6, 2026 at 4:05 PM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
>
> The various Qualcomm firmware interfaces are only present on Qualcomm
> systems.  Hence add dependencies on ARCH_QCOM, to prevent asking the
> user about them when configuring a kernel without Qualcomm SoC support.
> Make QCOM_PAS invisible instead, as it is already selected by its users
> when needed.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> I wondered whether QCOM_SCM should be made invisible, too, as it seems
> to be selected by its users? But apparently commit 5c1a2975d23c51c0
> ("firmware: qcom_scm: Migrate to generic PAS service") in net-next/main
> and soc/for-next made it visible on purpose?
> ---
>  drivers/firmware/qcom/Kconfig | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>

Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>

-Sumit

> diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig
> index c7f8413ab996cf12..691db0ded8e8cf63 100644
> --- a/drivers/firmware/qcom/Kconfig
> +++ b/drivers/firmware/qcom/Kconfig
> @@ -7,7 +7,7 @@
>  menu "Qualcomm firmware drivers"
>
>  config QCOM_PAS
> -       tristate "Qualcomm generic PAS interface driver"
> +       tristate "Qualcomm generic PAS interface driver" if COMPILE_TEST
>         help
>           Enable the generic Peripheral Authentication Service (PAS) provided
>           by the firmware. It acts as the common layer with different TZ
> @@ -16,6 +16,7 @@ config QCOM_PAS
>
>  config QCOM_PAS_TEE
>         tristate "Qualcomm PAS TEE interface driver"
> +       depends on ARCH_QCOM || COMPILE_TEST
>         select QCOM_PAS
>         depends on TEE
>         depends on !CPU_BIG_ENDIAN
> @@ -26,6 +27,7 @@ config QCOM_PAS_TEE
>
>  config QCOM_SCM
>         tristate "Qualcomm PAS SCM interface driver"
> +       depends on ARCH_QCOM || COMPILE_TEST
>         select QCOM_PAS
>         select QCOM_TZMEM
>         default y if ARCH_QCOM
> --
> 2.43.0
>
Re: [PATCH] firmware: QCOM interfaces should depend on ARCH_QCOM
Posted by Konrad Dybcio 1 month, 2 weeks ago
On 8/6/26 12:35 PM, Geert Uytterhoeven wrote:
> The various Qualcomm firmware interfaces are only present on Qualcomm
> systems.  Hence add dependencies on ARCH_QCOM, to prevent asking the
> user about them when configuring a kernel without Qualcomm SoC support.
> Make QCOM_PAS invisible instead, as it is already selected by its users
> when needed.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---

Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad
Re: [PATCH] firmware: QCOM interfaces should depend on ARCH_QCOM
Posted by Konrad Dybcio 1 month, 2 weeks ago
On 8/6/26 12:35 PM, Geert Uytterhoeven wrote:
> The various Qualcomm firmware interfaces are only present on Qualcomm
> systems.  Hence add dependencies on ARCH_QCOM, to prevent asking the
> user about them when configuring a kernel without Qualcomm SoC support.
> Make QCOM_PAS invisible instead, as it is already selected by its users
> when needed.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> I wondered whether QCOM_SCM should be made invisible, too, as it seems
> to be selected by its users? But apparently commit 5c1a2975d23c51c0
> ("firmware: qcom_scm: Migrate to generic PAS service") in net-next/main
> and soc/for-next made it visible on purpose?

For some context, that commit was part of a series that introduced a
second back-end to the functions that previously only the QCOM_SCM
driver provided ("qcom proprietary TZ interface" vs "what TF-A is
going to provide"), and the author's intention was to make the
former possible to disable

Konrad