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

[Amirreza Zarrabi]

Hi,

On 7/20/2026 3:55 PM, Harshal Dev wrote:
> 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.
> 

Thanks Arnd, and thanks Harshal.

The stubs and their no-op behavior were intentional. They were added so
callers could use the SHMBridge helpers without having to distinguish between
the TZMEM modes. When SHMBridge is not enabled by QTEE, creating or deleting
a bridge is expected to be a no-op and normal memory can still be used.

The problematic case is when SHMBridge support is compiled out while QTEE
has it enabled. The compile-time stubs still return success, even though the
memory was not registered as an SHMbridge. This is not a valid configuration
for qcomtee, or for other clients sharing memory with QTEE.

I agree that Arnd's second proposal is the cleaner approach.
QCOM_TZMEM_MODE_SHMBRIDGE can become a regular bool, while retaining the generic
allocation behavior as the runtime fallback. qcomtee can then select it,
ensuring that runtime detection is always available without making SHMBridge a
requirement on every platform.

With this user can not make wrong configuration choice using QCOM_TZMEM_MODE_GENERIC
and we can drop the stubs.

Regards,
Amir

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