'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.

Signed-off-by: Julian Braha <julianbraha@gmail.com>
---
 drivers/tee/qcomtee/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/tee/qcomtee/Kconfig b/drivers/tee/qcomtee/Kconfig
index 9f19dee08db4..00e07ed80138 100644
--- a/drivers/tee/qcomtee/Kconfig
+++ b/drivers/tee/qcomtee/Kconfig
@@ -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
 	  This option enables the Qualcomm Trusted Execution Environment (QTEE)
 	  driver. It provides an API to access services offered by QTEE and
-- 
2.54.0

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").

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.

I've added a few more people to Cc that may know the correct
answer here.

     Arnd

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

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
>