Hi,
On 1/7/2026 8:34 PM, Bjorn Andersson wrote:
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.
Yes, I understood that Bjorn, I meant to say that I will send a new patch-set version 4 with this updated commit message that you just approved. :)
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.
I believe this the earlier statement from me that you're referring to,
"Based on all this, I am thinking perhaps it would be better to say that the patch enables QCOMTEE driver for Qualcomm SoCs with arm64 CPUs? We could drop mentions of specific SM8x50 models with HDK/MTP boards since the feature is agnostic to those?"
I would like to correct this and make it clear. Not all Qualcomm SoCs would work with the QCOMTEE driver. This was also demonstrated by Sumit earlier, when he tried to test the driver on db845c and failed: https://lore.kernel.org/all/aCRkRTMFi65zBODh@sumit-X1/#t
This was because the QTEE firmware OS version on older Qualcomm SoCs does not support the SMCInvoke protocol, and so QSEECOM is the only way to talk to QTEE on these platforms.
The SCM driver dynamically checks for SMCInvoke protocol support during probe and does not register the 'QCOMTEE' device if it fails to detect that support from QTEE firmware OS side: https://elixir.bootlin.com/linux/v6.18.3/source/drivers/firmware/qcom/qcom_s...
So yes, for targets prior to SM8650, there is no guarantee that QCOMTEE would work for them.
Thanks, Harshal
Regards, Bjorn
Thanks, Harshal
Thank you, Bjorn