On 13/02/2026 11:56, Harshal Dev wrote:
Hi Krzysztof,
On 2/13/2026 3:56 PM, Krzysztof Kozlowski wrote:
On 13/02/2026 11:24, Kuldeep Singh wrote:
On 1/14/2026 1:49 PM, Harshal Dev via OP-TEE wrote:
All Qualcomm SoCs starting from SM8650 provide access to the Qualcomm Trusted Execution Environment (QTEE) through the SMCInvoke interface, implemented by the QCOMTEE driver. QTEE runs in the Secure World domain on ARM64 CPUs and exposes secure services to Linux running in the Normal World domain.
This change enables the QCOMTEE driver as a module to support communication with QTEE.
QCOMTEE has been tested on a Qualcomm RB3Gen2 board by loading and executing a Trusted Application via tests hosted at github.com/qualcomm/minkipc.
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
Tested on rb3gen2 device and able to see driver load successfully.
What exactly did you test? That a module can be built?
root@qcom-armv8a:~# lsmod | grep qcomtee qcomtee 32768 0
Sorry, but that's basic of kbuild and module system.
root@qcom-armv8a:~# rmmod qcomtee root@qcom-armv8a:~# insmod
Not a defconfig testing.
/lib/modules/6.18.0-next-20251202-00002-ga8c3ce157925 -dirty/kernel/drivers/tee/qcomtee/qcomtee.ko [ 164.464598] qcomtee: QTEE version 5.2.0 root@qcom-armv8a:~# ls /dev/tee0 /dev/tee0 root@qcom-armv8a:~#
With that, Reviewed-by: Kuldeep Singh kuldeep.singh@oss.qualcomm.com Tested-by: Kuldeep Singh kuldeep.singh@oss.qualcomm.com
You cannot test a defconfig.
I think these logs didn't convey the full picture. QCOMTEE driver holds references to objects and callback requests received from QTEE during invocations.
Being able to remove the driver without the the user thread being stuck helps test that the close_context() callback which calls into QTEE to release all pending objects and callback requests held in qcomtee_context_data is correctly implemented by the driver. https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/tee/qcomtee/call.c...
Before this patch, I believe the driver was being compiled with CONFIG_QCOMTEE=y so the qcomtee_remove() function path wasn't being exercised.
Perhaps we can provide more logs (rmmod attempted after running direct invocation tests) to convey that this is what we are testing here on the RB3Gen2 board.
I do not see at all how you address/respond to my comment.
Best regards, Krzysztof