Re: [PATCH v9 07/14] remoteproc: qcom: Select QCOM_PAS generic service

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] QCOM_WCNSS_PIL still implicitly depends on QCOM_SCM via QCOM_MDT_LOADER, defeating the attempted decoupling.
--

commit daedd535ea1eca89bbb7b28d89c346e3968988b4
Author: Sumit Garg <sumit.garg@oss.qualcomm.com>

remoteproc: qcom: Select QCOM_PAS generic service

This commit selects the PAS generic service driver to enable support for
multiple PAS backends like OP-TEE in addition to SCM.

> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index c521c744e7dbe..65befdbfa5f7d 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig

[ ... ]

> @@ -282,7 +284,7 @@ config QCOM_WCNSS_PIL
>  	select QCOM_MDT_LOADER
>  	select QCOM_PIL_INFO
>  	select QCOM_RPROC_COMMON
> -	select QCOM_SCM
> +	select QCOM_PAS

[Severity: Medium]
Does this change fully decouple the driver from QCOM_SCM as intended? 

Looking at drivers/soc/qcom/Kconfig, QCOM_MDT_LOADER still contains a
select QCOM_SCM directive. Since QCOM_WCNSS_PIL continues to select
QCOM_MDT_LOADER, it seems Kconfig will still unconditionally enable QCOM_SCM
through transitive dependency propagation. 

Will this prevent users from building the driver solely with the OP-TEE PAS
backend, as the kernel image would still pull in the SCM backend?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702115835.167602-1-sumit.garg@kernel.org?part=7