From: Krzysztof Kozlowski <krzk@kernel.org>
To: Harshal Dev <harshal.dev@oss.qualcomm.com>,
Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>,
Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>,
Konrad Dybcio <konradybcio@kernel.org>,
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
Sumit Garg <sumit.garg@kernel.org>,
Jens Wiklander <jens.wiklander@linaro.org>
Cc: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>,
Arnd Bergmann <arnd@arndb.de>,
Geert Uytterhoeven <geert+renesas@glider.be>,
op-tee@lists.trustedfirmware.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] arm64: defconfig: Enable QCOMTEE module for QTEE-enabled Qualcomm SoCs
Date: Fri, 13 Feb 2026 12:18:41 +0100 [thread overview]
Message-ID: <e52815b1-485d-4516-9448-1614f814981d@kernel.org> (raw)
In-Reply-To: <12582709-7dca-4f1a-99ab-8a21cd70f1c5@oss.qualcomm.com>
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 <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.
>
I do not see at all how you address/respond to my comment.
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-02-13 11:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-14 8:19 Harshal Dev
2026-01-16 10:06 ` Sumit Garg
2026-01-29 5:34 ` Amirreza Zarrabi
2026-02-13 10:24 ` Kuldeep Singh
2026-02-13 10:26 ` Krzysztof Kozlowski
2026-02-13 10:56 ` Harshal Dev
2026-02-13 11:18 ` Krzysztof Kozlowski [this message]
2026-02-16 5:18 ` Kuldeep Singh
2026-02-16 7:24 ` Krzysztof Kozlowski
2026-02-16 10:36 ` Harshal Dev
2026-02-16 10:39 ` Krzysztof Kozlowski
2026-02-16 12:08 ` Harshal Dev
2026-03-11 20:56 ` Bjorn Andersson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e52815b1-485d-4516-9448-1614f814981d@kernel.org \
--to=krzk@kernel.org \
--cc=amirreza.zarrabi@oss.qualcomm.com \
--cc=arnd@arndb.de \
--cc=bjorn.andersson@oss.qualcomm.com \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=geert+renesas@glider.be \
--cc=harshal.dev@oss.qualcomm.com \
--cc=jens.wiklander@linaro.org \
--cc=konradybcio@kernel.org \
--cc=kuldeep.singh@oss.qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=op-tee@lists.trustedfirmware.org \
--cc=sumit.garg@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®