Re: [PATCH RFC v2 1/8] tee: optee: allow RPMI transport builds on RISC-V

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] kconfig: referencing undefined symbol RISCV_RPMI_TEE_TRANSPORT prevents RISC-V builds
--

commit f52e668fa2e0c3cbca87392857f87a81c088348f
Author: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>

tee: optee: allow RPMI transport builds on RISC-V

This commit updates the Kconfig files to allow the TEE subsystem and OP-TEE
driver to be selected on RISC-V systems using the RPMI transport. It also
implements RISC-V specific memory type checking when registering shared
memory.

> diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
> index 98c3ad0839409..ad754b647a3c5 100644
> --- a/drivers/tee/Kconfig
> +++ b/drivers/tee/Kconfig
> @@ -2,7 +2,8 @@
>  # Generic Trusted Execution Environment Configuration
>  menuconfig TEE
>  	tristate "Trusted Execution Environment support"
> -	depends on HAVE_ARM_SMCCC || COMPILE_TEST || CPU_SUP_AMD
> +	depends on HAVE_ARM_SMCCC || COMPILE_TEST || CPU_SUP_AMD || \
> +		   RISCV_RPMI_TEE_TRANSPORT

[Severity: Medium]
Does the RISCV_RPMI_TEE_TRANSPORT config symbol exist? It appears this adds
a dependency on an undefined symbol, which evaluates to false and makes it
impossible to satisfy this dependency for the core TEE subsystem on RISC-V
platforms without SMCCC.

>  	select CRYPTO_LIB_SHA1
>  	select DMA_SHARED_BUFFER

[ ... ]

> diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
> index 891dac63cab85..cc057c76de622 100644
> --- a/drivers/tee/optee/Kconfig
> +++ b/drivers/tee/optee/Kconfig
> @@ -2,10 +2,11 @@
>  # OP-TEE Trusted Execution Environment Configuration
>  config OPTEE
>  	tristate "OP-TEE"
> -	depends on HAVE_ARM_SMCCC
> +	depends on HAVE_ARM_SMCCC || RISCV_RPMI_TEE_TRANSPORT

[Severity: Medium]
Since RISCV_RPMI_TEE_TRANSPORT does not appear to be defined anywhere in the
kernel tree, won't this silently disable the OP-TEE driver on RISC-V because
the unfulfilled dependency always evaluates to false?

>  	depends on MMU
>  	depends on RPMB || !RPMB
>  	depends on ARM_FFA_TRANSPORT || !ARM_FFA_TRANSPORT
> +	depends on RISCV_RPMI_TEE_TRANSPORT || !RISCV_RPMI_TEE_TRANSPORT

[Severity: Medium]
Similar to the above, this relies on the undefined RISCV_RPMI_TEE_TRANSPORT
symbol to enforce module compilation. Could this be a typo, or is there a
missing patch in the series that introduces this transport config?

>  	help
>  	  This implements the OP-TEE Trusted Execution Environment (TEE)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005-rpmi-tee-service-grp-dev-v2-0-72f222e23ec1@oss.qualcomm.com?part=1