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]

Message-ID: <20200529062709.tjmlguu5ovhk4t7o@vireshk-i7>
Date:   Fri, 29 May 2020 11:57:09 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Jassi Brar <jassisinghbrar@...il.com>
Cc:     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>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Sudeep Holla <sudeep.holla@....com>,
        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 29-05-20, 00:20, Jassi Brar wrote:
> The fact that all these bits are backed by one physical signal makes

I believe that within the IP itself, there must be 32 signals, just
that only one comes out of it all OR'd together. Maybe that can be
verified by writing 0x01 to it multiple times and it should generate
the interrupt only once on the first instance. i.e. writing 1 to any
big again won't raise the interrupt.

> the firmware implement its own mux-demux'ing scheme.

Similar to how the interrupt controllers do it in the kernel, they
receive a single interrupt and then go check its registers/bits to see
which peripheral raised it.

> So the choice was
> between demux and single signal at a time.

Well, the demux is on the firmware side and the kernel may not need to
worry about that, let the platform do it ?

> Had there been one signal
> per bit, the implementation would have definitely been 'efficient'.

I will say 'More efficient', it will still be 'efficient' if we
implement doorbell.

> And the first platform the driver was developed on, required message
> passing over the registers.

I think it was correctly done at that point of time. No doubt about
that.

> So now my approach is to make do with what
> we have...unless it shows in numbers.

ARM's office is closed (lock-down) and he doesn't have remote access
to the board and so was unable to do it until now.

Numbers or no numbers, I don't think there is a question here about
what is the most efficient way of doing it. Doing it in parallel (when
the hardware allows) is surely going to be more efficient. Sending a
signal, getting it processed by the firmware, doing something with it
and then sending an Ack and that being received by kernel will take
time. Why make a queue on the kernel side when we don't have to. :)

> Anyways, if it comes to that, I'd rather a separate "doorbell' driver
> than a driver working in two s/w modes.

I think that would be fine with everyone, if you are fine with that
now (based on plain logic and no numbers), maybe we can get that done
now?

-- 
viresh