linux-kernel - Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 5 Jun 2020 09:58:30 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Jassi Brar <jassisinghbrar@...il.com>
Cc:     Viresh Kumar <viresh.kumar@...aro.org>,
        Rob Herring <robh@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Frank Rowand <frowand.list@...il.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Sudeep Holla <sudeep.holla@....com>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Devicetree List <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU

On Fri, Jun 05, 2020 at 01:30:54AM -0500, Jassi Brar wrote:
> On Thu, Jun 4, 2020 at 11:56 PM Sudeep Holla <sudeep.holla@....com> wrote:
>
> >
> > > >>     bash-1526  [000]  1149.472553: scmi_xfer_begin:      transfer_id=1538 msg_id=6 protocol_id=21 seq=0 poll=0
> > > >>      <idle>-0     [001]  1149.472733: scmi_xfer_begin:      transfer_id=1539 msg_id=7 protocol_id=19 seq=1 poll=1
> > > >
> > > Here another request is started before the first is finished.
> >
> > Ah, the prints are when the client requested. It is not when the mailbox
> > started it. So this just indicates the beginning of the transfer from the
> > client.
> >
> There maybe condition on a sensor read to finish within 1ms, but there
> is no condition for the read to _start_ at this very moment (usually
> there are sleeps in the path to sensor requests).
>

Again I wasn't clear. The trace logs are at the point just before calling
mbox_send_messages. So any delay in sensor drivers won't get include. It
is after the point sensor driver request to read the value and before we
send the request via mailbox.

> > > If you want this to work you have to serialise access to the single
> > > physical channel and/or run the remote firmware in asynchronous mode -
> > > that is, the firmware ack the bit as soon as it sees and starts
> > > working in the background, so that we return in ~3usec always, while
> > > the data returns whenever it is ready.
> >
> > Yes it does that for few requests like DVFS while it uses synchronous
> > mode for few others. While ideally I agree everything in asynchronous
> > most is better, I don't know there may be reasons for such design.
> >
> The reason is that, if the firmware works asynchronously, every call
> would return in ~3usec and you won't think you need virtual channels.
>

I really wish that was the case. Life would have been much simpler. I
did remember one reason after my earlier email. For DVFS, OSPM need
not rely on response. It operates in fire and forget mode. While sensors
we need the value back. And one main reason for not making the call
async in the specification is that it needs to support platforms without
Rx interrupts or even transport like SMC which may not have reverse path
without as real mailbox.

> You have shared only 'bad' log without serialising access. Please
> share log after serialising access to the channel and the 'good' log
> with virtual channels.  That should put the topic to rest.
>

I didn't realise that, sorry for missing that earlier. Attached both
now, thanks for asking.

--
Regards,
Sudeep

View attachment "good_trace.txt" of type "text/plain" (72000 bytes)

View attachment "bad_trace.txt" of type "text/plain" (72013 bytes)