Enable QCOMTEE driver on Qualcomm SM8650+ SoCs to facilitate communication with the Qualcomm Trusted Execution Environment (QTEE). (No enablement required in DTS files since QCOMTEE device is dynamically registered by the QCOM_SCM firmware driver)
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com --- 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 08/12/2025 13:18, Harshal Dev wrote:
Enable QCOMTEE driver on Qualcomm SM8650+ SoCs to facilitate communication with the Qualcomm Trusted Execution Environment (QTEE). (No enablement required in DTS files since QCOMTEE device is dynamically registered by the QCOM_SCM firmware driver)
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
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@...
I gave you the exact example to follow. Maybe it is not that important for others, so I will not object, but OTOH it is important for me, thus I will not give reviewed by. I damn asked VERY CLEARLY:
"Just mention which UPSTREAM boards (which you called Qualcomm platforms) use this driver."
Usage of something on SoC is not a proof that it actually is used by upstream platforms and we absolutely do not care at all about downstream users. I spent way too much time on this and even very specific instructions were not working, so I don't know how else I can help.
Best regards, Krzysztof
On Tue, 9 Dec 2025 at 07:58, Krzysztof Kozlowski krzk@kernel.org wrote:
On 08/12/2025 13:18, Harshal Dev wrote:
Enable QCOMTEE driver on Qualcomm SM8650+ SoCs to facilitate communication with the Qualcomm Trusted Execution Environment (QTEE). (No enablement required in DTS files since QCOMTEE device is dynamically registered by the QCOM_SCM firmware driver)
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
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@...
I gave you the exact example to follow. Maybe it is not that important for others, so I will not object, but OTOH it is important for me, thus I will not give reviewed by. I damn asked VERY CLEARLY:
"Just mention which UPSTREAM boards (which you called Qualcomm platforms) use this driver."
+1 Here. Defconfig changes mention devices, not SoC families.
Usage of something on SoC is not a proof that it actually is used by upstream platforms and we absolutely do not care at all about downstream users. I spent way too much time on this and even very specific instructions were not working, so I don't know how else I can help.
Best regards, Krzysztof
On Mon, Dec 8, 2025 at 10:14 PM Dmitry Baryshkov dmitry.baryshkov@oss.qualcomm.com wrote:
On Tue, 9 Dec 2025 at 07:58, Krzysztof Kozlowski krzk@kernel.org wrote:
On 08/12/2025 13:18, Harshal Dev wrote:
Enable QCOMTEE driver on Qualcomm SM8650+ SoCs to facilitate communication with the Qualcomm Trusted Execution Environment (QTEE). (No enablement required in DTS files since QCOMTEE device is dynamically registered by the QCOM_SCM firmware driver)
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
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@...
I gave you the exact example to follow. Maybe it is not that important for others, so I will not object, but OTOH it is important for me, thus I will not give reviewed by. I damn asked VERY CLEARLY:
"Just mention which UPSTREAM boards (which you called Qualcomm platforms) use this driver."
+1 Here. Defconfig changes mention devices, not SoC families.
I don't agree that you have to mention a specific board, if the feature is used by all boards. But I think the commit message should make _that_ clear.
On the contrary, the commit message says that we're enabling CONFIG_QCOMTEE because it's used on "SM8560+". What does the plus mean? Also, the driver isn't enabled "on Qualcomm SM8650+", it's enabled in the Am64 defconfig, i.e. it's enabled on all Arm64 boards - the question that should be answered by the commit message is "why?".
PS. When you then run "git log arch/arm64/config/defconfig", the information that enabling QCOMTEE doesn't require DeviceTree changes is not useful.
Regards, Bjorn
Usage of something on SoC is not a proof that it actually is used by upstream platforms and we absolutely do not care at all about downstream users. I spent way too much time on this and even very specific instructions were not working, so I don't know how else I can help.
Best regards, Krzysztof
-- With best wishes Dmitry
On 10/12/2025 04:51, Bjorn Andersson wrote:
On Mon, Dec 8, 2025 at 10:14 PM Dmitry Baryshkov dmitry.baryshkov@oss.qualcomm.com wrote:
On Tue, 9 Dec 2025 at 07:58, Krzysztof Kozlowski krzk@kernel.org wrote:
On 08/12/2025 13:18, Harshal Dev wrote:
Enable QCOMTEE driver on Qualcomm SM8650+ SoCs to facilitate communication with the Qualcomm Trusted Execution Environment (QTEE). (No enablement required in DTS files since QCOMTEE device is dynamically registered by the QCOM_SCM firmware driver)
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
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@...
I gave you the exact example to follow. Maybe it is not that important for others, so I will not object, but OTOH it is important for me, thus I will not give reviewed by. I damn asked VERY CLEARLY:
"Just mention which UPSTREAM boards (which you called Qualcomm platforms) use this driver."
+1 Here. Defconfig changes mention devices, not SoC families.
I don't agree that you have to mention a specific board, if the feature is used by all boards. But I think the commit message should make _that_ clear.
Yes, that would be enough and I would be fine with it as well, but I did not have that impression from the commit msg.
Best regards, Krzysztof
Hi Bjorn,
On 12/10/2025 9:21 AM, Bjorn Andersson wrote:
On Mon, Dec 8, 2025 at 10:14 PM Dmitry Baryshkov dmitry.baryshkov@oss.qualcomm.com wrote:
On Tue, 9 Dec 2025 at 07:58, Krzysztof Kozlowski krzk@kernel.org wrote:
On 08/12/2025 13:18, Harshal Dev wrote:
Enable QCOMTEE driver on Qualcomm SM8650+ SoCs to facilitate communication with the Qualcomm Trusted Execution Environment (QTEE). (No enablement required in DTS files since QCOMTEE device is dynamically registered by the QCOM_SCM firmware driver)
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
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@...
I gave you the exact example to follow. Maybe it is not that important for others, so I will not object, but OTOH it is important for me, thus I will not give reviewed by. I damn asked VERY CLEARLY:
"Just mention which UPSTREAM boards (which you called Qualcomm platforms) use this driver."
+1 Here. Defconfig changes mention devices, not SoC families.
I don't agree that you have to mention a specific board, if the feature is used by all boards. But I think the commit message should make _that_ clear.
Thanks for this input Bjorn. I gather we are now aligned that the board information is not required.
Then the other part to this is how to provide information on the particular SoCs using this.
On the contrary, the commit message says that we're enabling CONFIG_QCOMTEE because it's used on "SM8560+". What does the plus mean?
I took reference from similar commits merged earlier where the plus seemed to indicate that all Qualcomm SoCs from 'SM8650' on-wards, that is, SM8750, SM8850 and so on. It felt that the plus sign is self-explanatory since it has been used already. But sure, maybe we can be explicit from now on and say from 'Qualcomm SM8650 onwards'.
commit c5d02bbaa217b2454ba1ce7528113aa2ecf14f3c
Also, the driver isn't enabled "on Qualcomm SM8650+", it's enabled in the Am64 defconfig, i.e. it's enabled on all Arm64 boards - the question that should be answered by the commit message is "why?".
Even though we are enabling this via the arm64 defconfig, it is not true that the driver is applicable for all arm64 boards. The simple reason being that the QTEE firmware OS that the driver communicates with runs only on Qualcomm SoCs using arm64 CPUs with ARM TrustZone technology.
This is why I would try to avoid a commit message which claims the the driver is applicable to all arm64 boards.
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?
PS. When you then run "git log arch/arm64/config/defconfig", the information that enabling QCOMTEE doesn't require DeviceTree changes is not useful.
Sure, I will drop the info on DTS files I added in the commit message.
Thanks, Harshal
Regards, Bjorn
Usage of something on SoC is not a proof that it actually is used by upstream platforms and we absolutely do not care at all about downstream users. I spent way too much time on this and even very specific instructions were not working, so I don't know how else I can help.
Best regards, Krzysztof
-- With best wishes Dmitry
On Wed, Dec 10, 2025 at 02:35:19PM +0530, Harshal Dev wrote:
Hi Bjorn,
On 12/10/2025 9:21 AM, Bjorn Andersson wrote:
On Mon, Dec 8, 2025 at 10:14 PM Dmitry Baryshkov dmitry.baryshkov@oss.qualcomm.com wrote:
On Tue, 9 Dec 2025 at 07:58, Krzysztof Kozlowski krzk@kernel.org wrote:
On 08/12/2025 13:18, Harshal Dev wrote:
Enable QCOMTEE driver on Qualcomm SM8650+ SoCs to facilitate communication with the Qualcomm Trusted Execution Environment (QTEE). (No enablement required in DTS files since QCOMTEE device is dynamically registered by the QCOM_SCM firmware driver)
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
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@...
I gave you the exact example to follow. Maybe it is not that important for others, so I will not object, but OTOH it is important for me, thus I will not give reviewed by. I damn asked VERY CLEARLY:
"Just mention which UPSTREAM boards (which you called Qualcomm platforms) use this driver."
+1 Here. Defconfig changes mention devices, not SoC families.
I don't agree that you have to mention a specific board, if the feature is used by all boards. But I think the commit message should make _that_ clear.
Thanks for this input Bjorn. I gather we are now aligned that the board information is not required.
Then the other part to this is how to provide information on the particular SoCs using this.
On the contrary, the commit message says that we're enabling CONFIG_QCOMTEE because it's used on "SM8560+". What does the plus mean?
I took reference from similar commits merged earlier where the plus seemed to indicate that all Qualcomm SoCs from 'SM8650' on-wards, that is, SM8750, SM8850 and so on. It felt that the plus sign is self-explanatory since it has been used already. But sure, maybe we can be explicit from now on and say from 'Qualcomm SM8650 onwards'.
commit c5d02bbaa217b2454ba1ce7528113aa2ecf14f3c
Also, the driver isn't enabled "on Qualcomm SM8650+", it's enabled in the Am64 defconfig, i.e. it's enabled on all Arm64 boards - the question that should be answered by the commit message is "why?".
Even though we are enabling this via the arm64 defconfig, it is not true that the driver is applicable for all arm64 boards. The simple reason being that the QTEE firmware OS that the driver communicates with runs only on Qualcomm SoCs using arm64 CPUs with ARM TrustZone technology.
This is why I would try to avoid a commit message which claims the the driver is applicable to all arm64 boards.
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?
AFAIK, the QCOMTEE driver works on the Qcom SoCs based on arm64 which supports the SMCInvoke protocol. So we should be explicit about it. Regarding mention of reference publicly available boards, I can see how it can be useful for the community to test QTEE based apps. If you can mention say example RB3Gen2 supports QTEE driver at least then it will be helpful.
-Sumit
[...]
Hi Krzysztof,
On 12/9/2025 11:28 AM, Krzysztof Kozlowski wrote:
On 08/12/2025 13:18, Harshal Dev wrote:
Enable QCOMTEE driver on Qualcomm SM8650+ SoCs to facilitate communication with the Qualcomm Trusted Execution Environment (QTEE). (No enablement required in DTS files since QCOMTEE device is dynamically registered by the QCOM_SCM firmware driver)
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
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@...
I gave you the exact example to follow. Maybe it is not that important for others, so I will not object, but OTOH it is important for me, thus I will not give reviewed by. I damn asked VERY CLEARLY:
"Just mention which UPSTREAM boards (which you called Qualcomm platforms) use this driver."
I did highlight my reasons for wondering if a board needs to be mentioned, perhaps I should take some more time before sending the next patch to ensure we've actually concluded the discussion on the last one:
"since the driver is related to SoC firmware and not on the board, I will mention SM8650+ as the supported SoCs since we began enabling the driver from that chip on-wards. I hope this reasoning is fine."
Usage of something on SoC is not a proof that it actually is used by upstream platforms and we absolutely do not care at all about downstream users. I spent way too much time on this and even very specific instructions were not working, so I don't know how else I can help.
I understand the frustration. Let's take a breather, I will reflect and take a week off before I try again or ask someone else to.
Thanks, Harshal
Best regards, Krzysztof
On Tue, Dec 09, 2025 at 06:58:27AM +0100, Krzysztof Kozlowski wrote:
On 08/12/2025 13:18, Harshal Dev wrote:
Enable QCOMTEE driver on Qualcomm SM8650+ SoCs to facilitate communication with the Qualcomm Trusted Execution Environment (QTEE). (No enablement required in DTS files since QCOMTEE device is dynamically registered by the QCOM_SCM firmware driver)
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
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@...
I gave you the exact example to follow. Maybe it is not that important for others, so I will not object, but OTOH it is important for me, thus I will not give reviewed by. I damn asked VERY CLEARLY:
"Just mention which UPSTREAM boards (which you called Qualcomm platforms) use this driver."
Usage of something on SoC is not a proof that it actually is used by upstream platforms and we absolutely do not care at all about downstream users. I spent way too much time on this and even very specific instructions were not working, so I don't know how else I can help.
Harsal,
I remember myself following a list of instructions to run QTEE test application on RB5 which were part of QTEE patch-set. And I do know there are contributions going on in meta-qcom regarding those libraries here [1][2].
[1] https://github.com/qualcomm-linux/meta-qcom/pull/1167 [2] https://github.com/qualcomm-linux/meta-qcom/pull/1094
So, it would be nice if you could point people to a coherent documentation which can list instructions to reproduce setup preferably based on meta-qcom.
-Sumit
op-tee@lists.trustedfirmware.org
-
Bjorn Andersson -
Dmitry Baryshkov -
Harshal Dev -
Krzysztof Kozlowski -
Sumit Garg