mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®