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 --- Changes in v4: - Updated the commit message as per discussion to clarify the following: - Why we are enabling QCOMTEE for all arm64 boards. - From which Qualcomm SoC onwards the driver is applicable. - What functionality the driver provides. - How the functionality has been tested and on which board. - Link to v3: https://lore.kernel.org/r/20251208-qcom_qcomtee_defconfig-v3-1-b50dcf8ab45e@...
Changes in v3: - Updated the commit message to reflect the supported Qualcomm platforms. - Link to v2: https://lore.kernel.org/r/20251205-qcom_qcomtee_defconfig-v2-1-c92560b0346e@...
Changes in v2: - Updated CONFIG_QCOMTEE flag to 'm' since QCOMTEE can be built as a module. - Link to v1: https://lore.kernel.org/r/20251202-qcom_qcomtee_defconfig-v1-1-11bfe40a8ea4@... --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index cdb7d69e3b24..e952d24bef77 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -1789,6 +1789,7 @@ CONFIG_FPGA_MGR_ZYNQMP_FPGA=m CONFIG_FPGA_MGR_VERSAL_FPGA=m CONFIG_TEE=y CONFIG_OPTEE=y +CONFIG_QCOMTEE=m CONFIG_MUX_GPIO=m CONFIG_MUX_MMIO=y CONFIG_SLIMBUS=m
--- base-commit: 47b7b5e32bb7264b51b89186043e1ada4090b558 change-id: 20251202-qcom_qcomtee_defconfig-8dc0fed1411b
Best regards,
On Wed, Jan 14, 2026 at 01:49:14PM +0530, Harshal Dev 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
Changes in v4:
- Updated the commit message as per discussion to clarify the following:
- Why we are enabling QCOMTEE for all arm64 boards.
- From which Qualcomm SoC onwards the driver is applicable.
- What functionality the driver provides.
- How the functionality has been tested and on which board.
- Link to v3: https://lore.kernel.org/r/20251208-qcom_qcomtee_defconfig-v3-1-b50dcf8ab45e@...
Reviewed-by: Sumit Garg sumit.garg@oss.qualcomm.com
-Sumit
Changes in v3:
- Updated the commit message to reflect the supported Qualcomm platforms.
- Link to v2: https://lore.kernel.org/r/20251205-qcom_qcomtee_defconfig-v2-1-c92560b0346e@...
Changes in v2:
- Updated CONFIG_QCOMTEE flag to 'm' since QCOMTEE can be built as a module.
- Link to v1: https://lore.kernel.org/r/20251202-qcom_qcomtee_defconfig-v1-1-11bfe40a8ea4@...
arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index cdb7d69e3b24..e952d24bef77 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -1789,6 +1789,7 @@ CONFIG_FPGA_MGR_ZYNQMP_FPGA=m CONFIG_FPGA_MGR_VERSAL_FPGA=m CONFIG_TEE=y CONFIG_OPTEE=y +CONFIG_QCOMTEE=m CONFIG_MUX_GPIO=m CONFIG_MUX_MMIO=y CONFIG_SLIMBUS=m
base-commit: 47b7b5e32bb7264b51b89186043e1ada4090b558 change-id: 20251202-qcom_qcomtee_defconfig-8dc0fed1411b
Best regards,
Harshal Dev harshal.dev@oss.qualcomm.com
On 1/16/2026 9:06 PM, Sumit Garg wrote:
On Wed, Jan 14, 2026 at 01:49:14PM +0530, Harshal Dev 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
Changes in v4:
- Updated the commit message as per discussion to clarify the following:
- Why we are enabling QCOMTEE for all arm64 boards.
- From which Qualcomm SoC onwards the driver is applicable.
- What functionality the driver provides.
- How the functionality has been tested and on which board.
- Link to v3: https://lore.kernel.org/r/20251208-qcom_qcomtee_defconfig-v3-1-b50dcf8ab45e@...
Reviewed-by: Sumit Garg sumit.garg@oss.qualcomm.com
-Sumit
Reviewed-by: Amirreza Zarrabi amirreza.zarrabi@oss.qualcomm.com
- Amir
Changes in v3:
- Updated the commit message to reflect the supported Qualcomm platforms.
- Link to v2: https://lore.kernel.org/r/20251205-qcom_qcomtee_defconfig-v2-1-c92560b0346e@...
Changes in v2:
- Updated CONFIG_QCOMTEE flag to 'm' since QCOMTEE can be built as a module.
- Link to v1: https://lore.kernel.org/r/20251202-qcom_qcomtee_defconfig-v1-1-11bfe40a8ea4@...
arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index cdb7d69e3b24..e952d24bef77 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -1789,6 +1789,7 @@ CONFIG_FPGA_MGR_ZYNQMP_FPGA=m CONFIG_FPGA_MGR_VERSAL_FPGA=m CONFIG_TEE=y CONFIG_OPTEE=y +CONFIG_QCOMTEE=m CONFIG_MUX_GPIO=m CONFIG_MUX_MMIO=y CONFIG_SLIMBUS=m
base-commit: 47b7b5e32bb7264b51b89186043e1ada4090b558 change-id: 20251202-qcom_qcomtee_defconfig-8dc0fed1411b
Best regards,
Harshal Dev harshal.dev@oss.qualcomm.com
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.
root@qcom-armv8a:~# lsmod | grep qcomtee qcomtee 32768 0 root@qcom-armv8a:~# rmmod qcomtee root@qcom-armv8a:~# insmod /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
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.
Best regards, Krzysztof
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...
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.
Thanks, Harshal
Best regards, Krzysztof
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...
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
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.
Yes, did a basic testing only.
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.
Sure, we can drop tested-by tag. Maybe patch author once send next rev can just add Reviewed-by tag only. Hope this is fine.
On 16/02/2026 06:18, Kuldeep Singh wrote:
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.
Yes, did a basic testing only.
Basic of BUILDING. How kernel is build. This has nothing to do with testing. This is not even basic testing.
Best regards, Krzysztof
On 2/16/2026 10:48 AM, Kuldeep Singh wrote:
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.
Yes, did a basic testing only.
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.
Sure, we can drop tested-by tag. Maybe patch author once send next rev can just add Reviewed-by tag only. Hope this is fine.
I am fine with us dropping this Tested-by tag. I thought it made sense to test that the driver being built as a module is removed without encountering any issues. I will not send another patch revision just to collect/drop tags.
Thanks, Harshal
On 16/02/2026 11:36, Harshal Dev wrote:
On 2/16/2026 10:48 AM, Kuldeep Singh wrote:
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.
Yes, did a basic testing only.
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.
Sure, we can drop tested-by tag. Maybe patch author once send next rev can just add Reviewed-by tag only. Hope this is fine.
I am fine with us dropping this Tested-by tag. I thought it made sense to test that the driver being built as a module is removed without encountering any issues.
We do not talk about this. No one claimed that this test is good or not. Read again discussion - there was no test of this defconfig change. It did not happen as it cannot happen or is completely pointless. The tag applies to THE COMMIT not to something else. I explained this way too many times.
I will not send another patch revision just to collect/drop tags.
Thanks, Harshal
Best regards, Krzysztof
On 2/16/2026 4:09 PM, Krzysztof Kozlowski wrote:
On 16/02/2026 11:36, Harshal Dev wrote:
On 2/16/2026 10:48 AM, Kuldeep Singh wrote:
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.
Yes, did a basic testing only.
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.
Sure, we can drop tested-by tag. Maybe patch author once send next rev can just add Reviewed-by tag only. Hope this is fine.
I am fine with us dropping this Tested-by tag. I thought it made sense to test that the driver being built as a module is removed without encountering any issues.
We do not talk about this. No one claimed that this test is good or not. Read again discussion - there was no test of this defconfig change. It did not happen as it cannot happen or is completely pointless. The tag applies to THE COMMIT not to something else. I explained this way too many times.
Understood. Thank you for clarifying once again Krzysztof.
Regards, Harshal
I will not send another patch revision just to collect/drop tags.
Thanks, Harshal
Best regards, Krzysztof
On Wed, 14 Jan 2026 13:49:14 +0530, Harshal Dev 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.
[...]
Applied, thanks!
[1/1] arm64: defconfig: Enable QCOMTEE module for QTEE-enabled Qualcomm SoCs commit: dccccbb739510a63cc62eb3cc1261392cc6045f7
Best regards,
op-tee@lists.trustedfirmware.org
-
Amirreza Zarrabi -
Bjorn Andersson -
Harshal Dev -
Krzysztof Kozlowski -
Kuldeep Singh -
Sumit Garg