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@qti.qualcomm.com

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@oss.qualcomm.com
---
 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 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@qti.qualcomm.com
> 

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, 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@qti.qualcomm.com
> > 
> 
> 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

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@qti.qualcomm.com
>>
> 
> 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, 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@qti.qualcomm.com
> >
>
> 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



-- 
With best wishes
Dmitry

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@qti.qualcomm.com
> > >
> >
> > 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

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@qti.qualcomm.com
>>>>
>>>
>>> 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@qti.qualcomm.com
> >>>>
> >>>
> >>> 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 all,

On 12/12/2025 6:55 AM, Sumit Garg wrote:
> 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@qti.qualcomm.com
>>>>>>
>>>>>
>>>>> 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.
> 

Based on consolidated feedback on this thread, I am thinking of the following
commit message, let me know if this is a go from everyone's perspective:

"
arm64: defconfig: Enable QCOMTEE for Qualcomm SoCs using arm64 CPUs

Enable QCOMTEE driver as a module for Qualcomm SoCs based on arm64 CPUs and
supporting the SMCInvoke protocol for communication with the Qualcomm Trusted
Execution Environment (QTEE).

The driver is tested on a Qualcomm RB3Gen2 board by loading and executing a
Trusted Application via tests hosted at www.github.com/qualcomm/minkipc.
"

Regards,
Harshal

> -Sumit
> 
> [...]

On Mon, Dec 15, 2025 at 04:50:39PM +0530, Harshal Dev wrote:
> Hi all,
> 
> On 12/12/2025 6:55 AM, Sumit Garg wrote:
> > 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@qti.qualcomm.com
> >>>>>>
> >>>>>
> >>>>> 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.
> > 
> 
> Based on consolidated feedback on this thread, I am thinking of the following
> commit message, let me know if this is a go from everyone's perspective:
> 
> "
> arm64: defconfig: Enable QCOMTEE for Qualcomm SoCs using arm64 CPUs
> 
> Enable QCOMTEE driver as a module for Qualcomm SoCs based on arm64 CPUs and
> supporting the SMCInvoke protocol for communication with the Qualcomm Trusted
> Execution Environment (QTEE).
> 
> The driver is tested on a Qualcomm RB3Gen2 board by loading and executing a
> Trusted Application via tests hosted at www.github.com/qualcomm/minkipc.
> "

I don't think this answers Krzysztof's question, and it doesn't address
my concern.

You're saying that you're enabling the driver for Qualcomm-based Arm64
SoC which supports SMCInvoke. But as I said, that's not what you're
doing; you are enabling the driver for all Arm64 boards, from all
vendors, regardless of them having SMCInvoke or not.

The commit message should be in the form of:

"All QTEE-based Qualcomm targets, since SM1234, provides access to the
secure world through the SMCInvoke interface, which is implemented in
the qcomtee driver. Enable this driver in order to ..."

Regards,
Bjorn

> 
> Regards,
> Harshal
> 
> > -Sumit
> > 
> > [...]
> 

Hi Bjorn,

On 12/22/2025 10:26 PM, Bjorn Andersson wrote:
> On Mon, Dec 15, 2025 at 04:50:39PM +0530, Harshal Dev wrote:
>> Hi all,
>>
>> On 12/12/2025 6:55 AM, Sumit Garg wrote:
>>> 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@qti.qualcomm.com
>>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>
>>
>> Based on consolidated feedback on this thread, I am thinking of the following
>> commit message, let me know if this is a go from everyone's perspective:
>>
>> "
>> arm64: defconfig: Enable QCOMTEE for Qualcomm SoCs using arm64 CPUs
>>
>> Enable QCOMTEE driver as a module for Qualcomm SoCs based on arm64 CPUs and
>> supporting the SMCInvoke protocol for communication with the Qualcomm Trusted
>> Execution Environment (QTEE).
>>
>> The driver is tested on a Qualcomm RB3Gen2 board by loading and executing a
>> Trusted Application via tests hosted at www.github.com/qualcomm/minkipc.
>> "
> 
> I don't think this answers Krzysztof's question, and it doesn't address
> my concern.
> 
> You're saying that you're enabling the driver for Qualcomm-based Arm64
> SoC which supports SMCInvoke. But as I said, that's not what you're
> doing; you are enabling the driver for all Arm64 boards, from all
> vendors, regardless of them having SMCInvoke or not.
> 
> The commit message should be in the form of:
> 
> "All QTEE-based Qualcomm targets, since SM1234, provides access to the
> secure world through the SMCInvoke interface, which is implemented in
> the qcomtee driver. Enable this driver in order to ..."
> 

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 should make it clear to all arm64 board vendors that this change, although
being done for all arm64 boards, is only applicable to the ones with Qualcomm SoC
and QTEE support.

Thank you,
Harshal

> Regards,
> Bjorn
> 
>>
>> Regards,
>> Harshal
>>
>>> -Sumit
>>>
>>> [...]
>>

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.

Thank you,
Bjorn

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

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
>

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_scm.c#L2203

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
>>

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@qti.qualcomm.com
>>>>
>>>
>>> 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