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

Harshal Dev via OP-TEE <[email protected]>
Newsgroups org.trustedfirmware.lists.op-tee,org.kernel.vger.linux-kernel
Message-ID <[email protected]>

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 <[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.
>>>
>>> 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 <[email protected]>
>>>>> Tested-by: Kuldeep Singh <[email protected]>
>>>>
>>>> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.