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

[Harshal Dev]

On 2/16/2026 4:09 PM, Krzysztof Kozlowski wrote:
> On 16/02/2026 11:36, Harshal Dev wrote:
>>
>>
>> On 2/16/2026 10:48 AM, Kuldeep Singh wrote:
>>>
>>>
>>> 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@xxxxxxxxxxxxxxxx>
>>>>>
>>>>> 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.
>>>
>>> Yes, did a basic testing only.
>>>
>>>>
>>>>
>>>>> 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@xxxxxxxxxxxxxxxx>
>>>>> Tested-by: Kuldeep Singh <kuldeep.singh@xxxxxxxxxxxxxxxx>
>>>>
>>>> You cannot test a defconfig.
>>>
>>> Sure, we can drop tested-by tag.
>>> Maybe patch author once send next rev can just add Reviewed-by tag only.
>>> Hope this is fine.
>>>
>>
>> I am fine with us dropping this Tested-by tag. I thought it made sense to test that
>> the driver being built as a module is removed without encountering any issues.
> 
> We do not talk about this. No one claimed that this test is good or not.
> Read again discussion - there was no test of this defconfig change. It
> did not happen as it cannot happen or is completely pointless. The tag
> applies to THE COMMIT not to something else. I explained this way too
> many times.
> 

Understood. Thank you for clarifying once again Krzysztof.

Regards,
Harshal

>> I will not send another patch revision just to collect/drop tags.
>>
>> Thanks,
>> Harshal
> 
> 
> Best regards,
> Krzysztof