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