linux-kernel - Re: Using the mailbox subsystem for plain doorbells?

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: <573204CA.8080808@wwwdotorg.org>
Date:	Tue, 10 May 2016 09:56:58 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Jassi Brar <jassisinghbrar@...il.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Joseph Lo <josephl@...dia.com>
Subject: Re: Using the mailbox subsystem for plain doorbells?

On 05/09/2016 09:29 PM, Jassi Brar wrote:
> On Tue, May 10, 2016 at 5:15 AM, Stephen Warren <swarren@...dotorg.org> wrote:
>> Jassi,
>>
>> Does the HW described below sound like something that should be represented
>> using the Linux kernel's mailbox subsystem, and related DT bindings? I think
>> the existing drivers/mailbox/pcc.c is similar, but wanted to double-check.
>>
>> We have some HW that literally just allows a SW-generated interrupt to be
>> generated by our main CPU complex to an auxiliary CPU, and likewise a
>> different interrupt can be generated in the opposite direction. There's no
>> ability to transfer any data; just an IRQ is generated. Our current mailbox
>> implementation just handles IRQ generation/reception so struct
>> mbox_chan_ops.send_data completely ignores the data parameter, and our IRQ
>> handler "receives" hard-coded NULL messages when the IRQ fires. Higher level
>> protocol code (using shared memory along with the plain-IRQ mbox channels)
>> is outside the mailbox driver.
>>
>> Does that fit the mailbox subsystem?
>>
>  From the sound of it, yes.

Good to know, thanks.

> Some controllers need a mask/list of destination cpus, to which the
> irq is raised, written to some 'data' register. You too probably need
> to program the destination "id" in the controller? Maybe that should
> be done in send_data().

In this case, each mailbox communicates with a different remote CPU, and 
there's a separate register to communicate with each remote CPU. So, 
send_data() completely ignores the data parameter since everything is 
derived from the mailbox's identity.