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