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
| ||
|
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