From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753554AbcEIXpn (ORCPT ); Mon, 9 May 2016 19:45:43 -0400 Received: from avon.wwwdotorg.org ([70.85.31.133]:36358 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750955AbcEIXpm (ORCPT ); Mon, 9 May 2016 19:45:42 -0400 To: Jassi Brar Cc: "linux-kernel@vger.kernel.org" , Joseph Lo From: Stephen Warren Subject: Using the mailbox subsystem for plain doorbells? Message-ID: <5731210A.4000401@wwwdotorg.org> Date: Mon, 9 May 2016 17:45:14 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?