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