From: Sricharan Ramabadhran <quic_srichara@quicinc.com>
TMEL(Trust Management Engine Lite) subsystem provides different kinds of
services like secureboot, remote image authentication, key management,
crypto, OEM provisioning etc.
The QMP mailbox is the primary means of communication between TMEL SS and
other subsystem on the SoC. A dedicated pair of inbound and outbound
mailboxes is implemented for each subsystem/external execution environment
which needs to communicate with TMEL for security services. The inbound
mailboxes are used to send IPC requests to TMEL, which are then processed
by TMEL firmware and accordingly the responses are sent back via outbound
mailboxes.
It is an IPC transport protocol which is light weight and supports a subset
of API's. It handles link initialization, negotiation, establishment and
communication across client(CPU/BTSS/AUDIOSS) and server(TMEL SS).
----------------------------------------------- ---------------------------------------------------
| | | |
| SOC CLIENT | SOC | TMEL SS |
| | AHB | |
| ---------- --------- --------- | | ------ ------- -------- ------------ |
| | | | | | | | WO | | | R | | | | |SERVICES | |
| | CPU |<-->| TMEL |<->| |------------->| | IN |-->| | | TMEL | |-------- | |
| | | | COM | | QMP | | RO | | | W | QMP |<--->| COM |<-->| a) ATTEST | |
| | | | | | |<-------------| | OUT |<--| | | | | b) CRYPTO | |
| | | | | | | | | | | | | | | | .. more | |
| --------- --------- --------- | | ------ ------- ------- ------------ |
| | | |
----------------------------------------------- --------------------------------------------------
This binding describes the component responsible for communication between
the TMEL subsystem and the TMEL client (CPU/BTSS/AUDIOSS),
used for security services like secure image authentication, enable/disable
efuses, crypto services. Each client in the SoC has its own block of message
RAM and IRQ for communication with the TMEL SS.
Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
---
[v4]
Fixed TMEL naming and added expansion
Fixed wrappings for 80 columns
[V3]
Fixed wrappings.
Made mailbox-cells as a required property and changed value to '1'.
Fixed to use compatible as filename.
Renamed compatible as per Krzystof's comments.
Dropped unused label.
[V2]
Added HW description as per comments.
Removed the fallback compatible.
Fixed naming convention to TME-L in all places.
Fixed indendation for example.
Removed the 'description' for some items.
[V1]
RFC Post.
.../bindings/mailbox/qcom,ipq5424-tmel.yaml | 60 +++++++++++++++++++
1 file changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/qcom,ipq5424-tmel.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/qcom,ipq5424-tmel.yaml b/Documentation/devicetree/bindings/mailbox/qcom,ipq5424-tmel.yaml
new file mode 100644
index 000000000000..5bdeab166a1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/qcom,ipq5424-tmel.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/qcom,ipq5424-tmel.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm TMEL IPCC channel
+
+maintainers:
+ - Sricharan Ramabadhran <quic_srichara@quicinc.com>
+
+description:
+ TMEL(Trust Management Engine Lite) SS provides different kinds of services
+ like secureboot, remote image authentication, key management, crypto, OEM
+ provisioning etc.
+
+ The QMP mailbox is the primary means of communication between TMEL SS and
+ other subsystem on the SoC. A dedicated pair of inbound and outbound mailbox
+ is implemented for each subsystem/external execution environment which needs
+ to communicate with TMEL for security services. The inbound mailboxes are used
+ to send IPC requests to TMEL, which are then processed by TMEL firmware and
+ accordingly the responses are sent back via outbound mailboxes.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,ipq5424-tmel
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ mboxes:
+ maxItems: 1
+
+ "#mbox-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - mboxes
+ - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ mailbox@32090000 {
+ compatible = "qcom,ipq5424-tmel";
+ reg = <0x32090000 0x2000>;
+ interrupts = <GIC_SPI 126 IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&apcs_glb 20>;
+ #mbox-cells = <1>;
+ };
--
2.34.1On Thu, Mar 27, 2025 at 11:47:49PM +0530, Sricharan R wrote: > From: Sricharan Ramabadhran <quic_srichara@quicinc.com> > > TMEL(Trust Management Engine Lite) subsystem provides different kinds of Trust whatever SubSystem (TMEL SS) ... different to what? > services like secureboot, remote image authentication, key management, > crypto, OEM provisioning etc. > > The QMP mailbox is the primary means of communication between TMEL SS and What is QMP? > other subsystem on the SoC. A dedicated pair of inbound and outbound > mailboxes is implemented for each subsystem/external execution environment Is it implemented in the driver? Is it provided by the hardware? By the firmware? > which needs to communicate with TMEL for security services. The inbound > mailboxes are used to send IPC requests to TMEL, which are then processed > by TMEL firmware and accordingly the responses are sent back via outbound > mailboxes. -- With best wishes Dmitry
[Resending, since my previous response had some wrapping issue] >> TMEL(Trust Management Engine Lite) subsystem provides different kinds of > > Trust whatever SubSystem (TMEL SS) ... > > different to what? To the ARM TrustZone firmware(TZ). So these services (secureboot, authentication etc) were provided by the TZ in some SOCs. Here, TMEL provides those. Can add those details here. > >> services like secureboot, remote image authentication, key management, >> crypto, OEM provisioning etc. >> >> The QMP mailbox is the primary means of communication between TMEL SS and > > What is QMP? Qualcomm Messaging Protocol > >> other subsystem on the SoC. A dedicated pair of inbound and outbound >> mailboxes is implemented for each subsystem/external execution environment > > Is it implemented in the driver? Is it provided by the hardware? By the > firmware? > TMEL firmware provides and processes the inbound requests and responds back on the outbound channel. Can mention this explicitly in the above. Regards, Sricharan
On 01/04/2025 14:26, Sricharan Ramabadhran wrote: > > [Resending, since my previous response had some wrapping issue] > >>> TMEL(Trust Management Engine Lite) subsystem provides different kinds of >> >> Trust whatever SubSystem (TMEL SS) ... >> >> different to what? > > > To the ARM TrustZone firmware(TZ). So these services (secureboot, > authentication etc) were provided by the TZ in some SOCs. Here, > TMEL provides those. Can add those details here. Yes, please (and all other answers too). > >> >>> services like secureboot, remote image authentication, key management, >>> crypto, OEM provisioning etc. >>> >>> The QMP mailbox is the primary means of communication between TMEL SS >>> and >> >> What is QMP? > Qualcomm Messaging Protocol > >> >>> other subsystem on the SoC. A dedicated pair of inbound and outbound >>> mailboxes is implemented for each subsystem/external execution >>> environment >> >> Is it implemented in the driver? Is it provided by the hardware? By the >> firmware? >> > TMEL firmware provides and processes the inbound requests and responds > back on the outbound channel. Can mention this explicitly in the above. > > Regards, > Sricharan -- With best wishes Dmitry
On 3/28/2025 6:21 PM, Dmitry Baryshkov wrote: > On Thu, Mar 27, 2025 at 11:47:49PM +0530, Sricharan R wrote: >> From: Sricharan Ramabadhran <quic_srichara@quicinc.com> >> >> TMEL(Trust Management Engine Lite) subsystem provides different kinds of > > Trust whatever SubSystem (TMEL SS) ... > > different to what? > To the ARM TrustZone firmware(TZ). So these services (secureboot, image authentication etc) were provided by the TZ in some SOCs. Here, TMEL provides those. Can add those details here. >> services like secureboot, remote image authentication, key management, >> crypto, OEM provisioning etc. >> >> The QMP mailbox is the primary means of communication between TMEL SS and > > What is QMP? Qualcomm Messaging Protocol > >> other subsystem on the SoC. A dedicated pair of inbound and outbound >> mailboxes is implemented for each subsystem/external execution environment > > Is it implemented in the driver? Is it provided by the hardware? By the > firmware? > TMEL firmware provides and processes the inbound requests and responds back on the outbound channel. Can mention this explicitly in the above. Regards, Sricharan
On Thu, Mar 27, 2025 at 11:47:49PM +0530, Sricharan R wrote: > +properties: > + compatible: > + items: > + - enum: > + - qcom,ipq5424-tmel blank line > + reg: > + maxItems: 1 > + > + interrupts: > + maxItems: 1 > + > + mboxes: > + maxItems: 1 Why mbox is having an mbox? This does not look right and suggest the block is misrepresented. I read the diagram and description two times and still do not see how this fits there. > + > + "#mbox-cells": > + const: 1 Best regards, Krzysztof
On 3/28/2025 1:32 PM, Krzysztof Kozlowski wrote:
> On Thu, Mar 27, 2025 at 11:47:49PM +0530, Sricharan R wrote:
>> +properties:
>> + compatible:
>> + items:
>> + - enum:
>> + - qcom,ipq5424-tmel
>
> blank line
ok
>
>> + reg:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + mboxes:
>> + maxItems: 1
>
> Why mbox is having an mbox? This does not look right and suggest the
> block is misrepresented. I read the diagram and description two times
> and still do not see how this fits there.
TMEL/QMP secure functionalities are exposed to clients (like rproc) by
registering TMEL as mailbox controller. The IPC bit to communicate with
the TMEL/QMP controller itself is handled by the apcs mailbox. Hence
it looks like a mbox inside mbox.
Alternatively, would it be fine to fold the IPC bit handling in this
driver itself for doing the regmap_write (instead of connecting to
apcs mailbox separately) ?
Also, there are couple of other ways of designing this as well.
Earlier i mentioned this in the RFC post [1] for getting the design
sorted out.
[1]
https://lore.kernel.org/lkml/20241205080633.2623142-1-quic_srichara@quicinc.com/T/
-------------------------------------------------------------
Had the below mentioned in the RFC earlier.
The intention of posting this is to get the design reviewed/corrected
since there are also other possible ways of having this SS support like:
a) Make TMEL QMP as a 'rpmsg' driver and clients can connect using
rmpsg_send
b) Keep TMEL APIs seperately in drivers/firmware which would export APIs
and QMP mailbox seperately.
Clients can then call the exported APIS.
c) Combine both TMEL and QMP as mailbox (this is the approach used here)
Regards,
Sricharan
On 4/1/2025 12:59 PM, Sricharan Ramabadhran wrote: > > > On 3/28/2025 1:32 PM, Krzysztof Kozlowski wrote: >> On Thu, Mar 27, 2025 at 11:47:49PM +0530, Sricharan R wrote: >>> +properties: >>> + compatible: >>> + items: >>> + - enum: >>> + - qcom,ipq5424-tmel >> >> blank line > ok > >> >>> + reg: >>> + maxItems: 1 >>> + >>> + interrupts: >>> + maxItems: 1 >>> + >>> + mboxes: >>> + maxItems: 1 >> >> Why mbox is having an mbox? This does not look right and suggest the >> block is misrepresented. I read the diagram and description two times >> and still do not see how this fits there. > TMEL/QMP secure functionalities are exposed to clients (like rproc) by > registering TMEL as mailbox controller. The IPC bit to communicate with > the TMEL/QMP controller itself is handled by the apcs mailbox. Hence > it looks like a mbox inside mbox. > > Alternatively, would it be fine to fold the IPC bit handling in this > driver itself for doing the regmap_write (instead of connecting to > apcs mailbox separately) ? > > Also, there are couple of other ways of designing this as well. > Earlier i mentioned this in the RFC post [1] for getting the design > sorted out. > > [1] https://lore.kernel.org/lkml/20241205080633.2623142-1- > quic_srichara@quicinc.com/T/ > > ------------------------------------------------------------- > Had the below mentioned in the RFC earlier. > > The intention of posting this is to get the design reviewed/corrected > since there are also other possible ways of having this SS support like: > > a) Make TMEL QMP as a 'rpmsg' driver and clients can connect using > rmpsg_send > > b) Keep TMEL APIs seperately in drivers/firmware which would export APIs > and QMP mailbox seperately. > Clients can then call the exported APIS. > > c) Combine both TMEL and QMP as mailbox (this is the approach used here) > Hi Krysztof, Can you kindly provide your suggestion on how to proceed for the above ? Would want to align on the design approach before posting the next version. Regards, Sricharan
© 2016 - 2025 Red Hat, Inc.