Re: [PATCH v4] arm64: defconfig: Enable QCOMTEE module for QTEE-enabled Qualcomm SoCs

[Harshal Dev <harshal.dev@oss.qualcomm.com>]

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#L600

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.

Thanks,
Harshal

> 
> 
> 
> Best regards,
> Krzysztof