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 <[email protected]> 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/[email protected]?part=7
