On Wed, Jan 07, 2026 at 11:50:33AM +0530, Harshal Dev wrote:
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.
I said the commit message looks good, not sure why you will send a new version.
What I wanted to put in writing is what you're saying - that all targets prior to SM8650 will only use QSEECOM - something that was contended in the previous discussions.
Regards, Bjorn
Thanks, Harshal
Thank you, Bjorn