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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2b132133-9c03-4b7a-b59a-e0f701dfbd01@quicinc.com>
Date: Tue, 15 Apr 2025 16:38:44 +0530
From: Sricharan Ramabadhran <quic_srichara@...cinc.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
CC: <jassisinghbrar@...il.com>, <robh@...nel.org>, <krzk+dt@...nel.org>,
        <conor+dt@...nel.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <andersson@...nel.org>, <konradybcio@...nel.org>,
        <manivannan.sadhasivam@...aro.org>, <dmitry.baryshkov@...aro.org>
Subject: Re: [PATCH V4 1/2] dt-bindings: mailbox: Document qcom,ipq5424-tmel



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@...cinc.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