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
