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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171101221217.GA28761@minitux>
Date:   Wed, 1 Nov 2017 15:12:17 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Jassi Brar <jassisinghbrar@...il.com>
Cc:     Sudeep Holla <sudeep.holla@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH] mailbox: add support for doorbell/signal mode controllers

On Wed 01 Nov 11:03 PDT 2017, Jassi Brar wrote:
> On Wed, Nov 1, 2017 at 10:02 PM, Sudeep Holla <sudeep.holla@....com> wrote:
[..]
> >
> > This is rough idea I have on extending mailbox interface to support
> > the doorbell requirements.
> >
> What doorbell requirements does the api not support?
> QComm's APCS IPC is what you call a "doorbell" controller and is
> already supported by the API. It could run SCMI even easier than MHU
> (your controller).
> 

I agree; from a mbox consumer perspective a doorbell should be a mailbox
channel that when signalled will ring the bell, i.e. the message is not
significant and should not be provided by the client.

If the message is significant and is not derived from the mailbox
channel (e.g. channel id -> bit in register) it is not a mailbox
doorbell, it's s regular mailbox used as a doorbell.


The potential improvement I see in the Qualcomm case is to wrap the
mbox_send_message(chan, NULL); mbox_client_txdone(chan, 0); calls in one
simple "mbox_ring_door_bell(chan)" - but I haven't investigated the
validity of this as a generic function.

Regards,
Bjorn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ