linux-kernel - Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Support mailboxes unidirectional channels

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: <ZCKWt0FpSguUgUel@e120937-lin>
Date:   Tue, 28 Mar 2023 08:26:47 +0100
From:   Cristian Marussi <cristian.marussi@....com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        devicetree@...r.kernel.org, sudeep.holla@....com,
        vincent.guittot@...aro.org, souvik.chakravarty@....com,
        nicola.mazzucato@....com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org
Subject: Re: [PATCH 1/2] dt-bindings: firmware: arm,scmi: Support mailboxes
 unidirectional channels

On Tue, Mar 28, 2023 at 08:36:51AM +0200, Krzysztof Kozlowski wrote:
> On 27/03/2023 17:27, Cristian Marussi wrote:
> >>> +  - |
> >>> +    firmware {
> >>> +        scmi {
> >>> +            compatible = "arm,scmi";
> >>> +            mboxes = <&mhu_U_tx 0 0>, <&mhu_U_rx 0 0>;
> >>> +            shmem = <&cpu_scp_lpri0>;
> >>> +
> >>> +            #address-cells = <1>;
> >>> +            #size-cells = <0>;
> >>
> >> I don't think adding one more example with difference in only one piece
> >> is needed here.
> >>
> > 
> > Mmm, I thought was sensible to add this example, given that a mailbox
> > transport configuration for a mailbox exposing unidrectional channels is
> > quite different from the usual bidirectional channel config already
> > present in the pre-existent example.
> > 
> > I'll add mbox-names into this example and see if I can change your
> > mind...or I can then finally drop it.
> 
> And what exactly this one more example changes? Does not validate
> different parts of the binding if only one property differs...

Well it showcases how the extended new mboxes/shmem prop can be used in
to support such unidirectional channels (which is pretty much different
from the usual existing biridrectional synatx) ... anyway I never really
thought as the examples in terms of validation really (and I am not saying
that this is right eh) ... but more as an aid to help the unfortunate
human being that has finally to write some DT based on this.

Anyway since it does not seem appropriate, I'll just drop the whole
example in V3, after waiting for some more (if any) feedback on the
binding in general. Are the mbox-names fixes I added in V2 fine ?

Thanks,
Cristian