From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751820AbdJFNwD (ORCPT ); Fri, 6 Oct 2017 09:52:03 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:34196 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750908AbdJFNwB (ORCPT ); Fri, 6 Oct 2017 09:52:01 -0400 Cc: Sudeep Holla , Arnd Bergmann , ALKML , LKML , DTML , Roy Franz , Harb Abdulhamid , Nishanth Menon , Loc Ho , Alexey Klimov , Ryan Harkin Subject: Re: [PATCH v3 16/22] firmware: arm_scmi: add arm_mhu specific mailbox interface To: Jassi Brar References: <1506604306-20739-1-git-send-email-sudeep.holla@arm.com> <1506604306-20739-17-git-send-email-sudeep.holla@arm.com> From: Sudeep Holla Organization: ARM Message-ID: <25023d1a-a221-b131-5a1e-7d909b006d1b@arm.com> Date: Fri, 6 Oct 2017 14:51:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/10/17 14:47, Jassi Brar wrote: > On Fri, Oct 6, 2017 at 7:02 PM, Sudeep Holla wrote: >> >> >> On 06/10/17 12:26, Jassi Brar wrote: >>> On Wed, Oct 4, 2017 at 5:06 PM, Arnd Bergmann wrote: >>>> On Thu, Sep 28, 2017 at 3:11 PM, Sudeep Holla wrote: >>>>> This patch adds ARM MHU specific mailbox interface for SCMI. >>>>> >>>>> Cc: Arnd Bergmann >>>>> Signed-off-by: Sudeep Holla >>>> >>>> This clearly needs an explanation why we need another driver. >>>> >>> Yes the patch needs explanation which is that we need a shim layer to >>> map SCMI requests onto what the underlying controller expects. The >>> alternative was to clone the controller driver (MHU now and others >>> later when their platforms support SCMI) and pretend SCMI is the only >>> client they are ever going to serve. >>> >> >> Again that's not the point, doorbell is more common feature and that can >> be supported. As SCMI expects doorbell feature in the specification, it >> just need to support that class of controllers. >> > NO. All SCMI expects is SHMEM and a signal reaching the other end. > The signal mechanism need not necessarily be "doorbell". > Agreed, but creating an abstraction ro do something as generic as doorbell and writing shim layer for each controller to use SCMI also sounds bad. -- Regards, Sudeep