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: <CABb+yY1Oss376KOgDcpDAHauamECn9r4NA5x=KL3y3UWMh9C2A@mail.gmail.com>
Date:	Tue, 10 May 2016 08:59:23 +0530
From:	Jassi Brar <jassisinghbrar@...il.com>
To:	Stephen Warren <swarren@...dotorg.org>
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 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.

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().