Re: [PATCH V4 1/2] dt-bindings: mailbox: Document qcom,ipq5424-tmel

[Sricharan Ramabadhran]

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

Regards,
 Sricharan