'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
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
op-tee@lists.trustedfirmware.org
-
Amirreza Zarrabi -
Arnd Bergmann -
Harshal Dev -
Julian Braha