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

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 <[email protected]>
>>>
>>> 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 <[email protected]>
>>> Tested-by: Kuldeep Singh <[email protected]>
>>
>> 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.
> 

I do not see at all how you address/respond to my comment.

Best regards,
Krzysztof