On 3/28/2025 1:32 PM, Krzysztof Kozlowski wrote:
On Thu, Mar 27, 2025 at 11:47:49PM +0530, Sricharan R wrote:ok
+properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,ipq5424-tmel
blank line
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
+ 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.
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@xxxxxxxxxxx/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)