Re: [PATCH] tee: remove dead select from kconfig

[Harshal Dev <harshal.dev@oss.qualcomm.com>]

Hi,

On 7/15/2026 3:38 PM, Arnd Bergmann wrote:
> On Wed, Jul 15, 2026, at 11:25, Julian Braha wrote:
>> 'select' does not work on config options in a 'choice', so currently it is
>> possible to enable QCOMTEE without QCOM_TZMEM_MODE_SHMBRIDGE.
>>
>> This patch removes the select.
>>
>> I've compile-tested this and found that it builds fine without
>> QCOM_TZMEM_MODE_SHMBRIDGE, but I don't have the hardware to runtime test.
>> Please advise if it would be better to make QCOM_TZMEM_MODE_SHMBRIDGE a
>> dependency.
>>
>> This dead select was found by kconfirm, a static analysis tool for Kconfig.
> 
> Right, clearly something is wrong here.
> 
>> @@ -5,7 +5,6 @@ config QCOMTEE
>>  	depends on ARCH_QCOM || COMPILE_TEST
>>  	depends on !CPU_BIG_ENDIAN
>>  	select QCOM_SCM
>> -	select QCOM_TZMEM_MODE_SHMBRIDGE
>>  	help
> 
> From the implementation, my guess would be that QCOMTEE actually
> requires QCOM_TZMEM_MODE_SHMBRIDGE and it only links successfully
> because of the stub helpers added in 8aa1e3a6f0ff ("firmware:
> qcom: tzmem: export shm_bridge create/delete").

This is correct. QCOMTEE can build without TZMEM_MODE_SHMBRIDGE, but will not
work without this config. TrustZone will just refuse the memory shared without
this config enabled. So it is a hard dependency.

> 
> If that is the case, we probably need a 'depends on
> QCOM_TZMEM_MODE_SHMBRIDGE' here, and can remove the stub
> functions.
> 
> It is also possible that the 'choice' itself is wrong, and
> this should be detected at runtime. It is a rather odd Kconfig
> option, as it sounds like only one of the two is correct on
> a given hardware. The CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE variant
> contains runtime hardware detection, so it should actually
> be safe to enable that anywhere. If this is true, we could
> just turn the choice into a 'bool' symbol and remove the
> generic case.
>

So when TZMEM_MODE_SHMBRIDGE isn't enabled, and instead TZMEM_MODE_GENERIC
is used, the driver just becomes a generic memory allocator, so the clients
cannot share this memory with QTEE. I couldn't find any existing clients
of TZMEM that aren't using it in MODE_SHMBRIDGE, in other words it seems that
we don't have any users for MODE_GENERIC.

In that case, it appears to be a better choice to make this a bool.
Either MODE_SHMBRIDGE or not.
But since @Bartoz is the maintainer, I would let him provide his comments
on this.

Regards,
Harshal 
> I've added a few more people to Cc that may know the correct
> answer here.
> 
>      Arnd