[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <83ec99c3-ab34-4344-ac60-084a85e4fb2a@oss.qualcomm.com>
Date: Wed, 7 Jan 2026 11:50:33 +0530
From: Harshal Dev <harshal.dev@....qualcomm.com>
To: Bjorn Andersson <andersson@...nel.org>
Cc: Sumit Garg <sumit.garg@...nel.org>,
Bjorn Andersson <bjorn.andersson@....qualcomm.com>,
Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
Krzysztof Kozlowski <krzk@...nel.org>,
Konrad Dybcio
<konradybcio@...nel.org>,
Jens Wiklander <jens.wiklander@...aro.org>,
Amirreza Zarrabi <amirreza.zarrabi@....qualcomm.com>,
Arnd Bergmann <arnd@...db.de>,
Geert Uytterhoeven <geert+renesas@...der.be>,
op-tee@...ts.trustedfirmware.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] arm64: defconfig: Enable QCOMTEE on Qualcomm SM8650+
Hi,
On 1/2/2026 11:53 PM, Bjorn Andersson wrote:
> On Fri, Jan 02, 2026 at 02:21:57PM +0530, Harshal Dev wrote:
> [..]
>>
>>
>> I agree that the defconfig change effectively enables the driver for all arm64
>> boards, not just Qualcomm SoC based ones. To clarify this in the commit message,
>> let me explicitly state the following:
>> - Why we are enabling it for all arm64 boards.
>> - From which Qualcomm SoC onwards the driver is applicable to.
>> - What functionality the driver provides.
>> - How it's functionality has been tested and on which board.
>>
>> "
>> arm64: defconfig: Enable QCOMTEE module for QTEE-enabled Qualcomm SoCs
>>
>> 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.
>> "
>
> This commit message looks good to me.
>
> It also makes it clear that all platforms up to (not including) SM8650
> _only_ supports QSEECOM, and hence makes it clear that we have reason to
> support both mechanisms.
I agree, before QCOMTEE driver, QSEECOM was the only way to communicate with
QTEE.
I hope everyone else is aligned as well.
I will send a new patch version with the updated commit.
Thanks,
Harshal
>
> Thank you,
> Bjorn
Powered by blists - more mailing lists