From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752087AbdAYOU6 (ORCPT ); Wed, 25 Jan 2017 09:20:58 -0500 Received: from foss.arm.com ([217.140.101.70]:37482 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751420AbdAYOU5 (ORCPT ); Wed, 25 Jan 2017 09:20:57 -0500 Subject: Re: [PATCH] firmware: arm_scpi: Add hardware dependencies To: Jean Delvare References: <20170125143200.0554ad0f@endymion> <20170125145037.14a790c4@endymion> <7561802d-e9d3-2b82-35dc-465c06d6d4eb@arm.com> <20170125151428.1a2a532f@endymion> Cc: Sudeep Holla , LKML , "Jon Medhurst (Tixy)" From: Sudeep Holla Organization: ARM Message-ID: Date: Wed, 25 Jan 2017 14:20:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170125151428.1a2a532f@endymion> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25/01/17 14:14, Jean Delvare wrote: > On Wed, 25 Jan 2017 13:56:23 +0000, Sudeep Holla wrote: >> On 25/01/17 13:50, Jean Delvare wrote: >>> On Wed, 25 Jan 2017 13:38:47 +0000, Sudeep Holla wrote: >>>> On 25/01/17 13:32, Jean Delvare wrote: >>>>> With a name like that, I assume that the ARM SCPI protocol is only >>>>> useful on the ARM architectures. >>>>> >>>>> Signed-off-by: Jean Delvare >>>>> Fixes: 8f1498c03d15 ("firmware: arm_scpi: make it depend on MAILBOX instead of") >>>>> Cc: Sudeep Holla >>>>> Cc: Jon Medhurst (Tixy) >>>>> --- >>>>> Please correct me if I'm wrong. >>>> >>>> I won't say you are wrong but the reason why it's named arm_scpi is >>>> because the protocol was developed by ARM. It doesnn't mean only >>>> ARM/ARM64 needs to use it, it can be used on any architecture for >>>> inter-processor communication using any communication technique >>>> (currently mailbox is the only supported in the driver) >>> >>> OK, thanks for the clarification. In practice, what other architectures >>> are using it? >> >> None, hence I didn't say you are wrong ;). I am fine having the check if >> it breaks for any other architecture with COMPILE_TEST. > > Not sure what you mean here... The purpose of COMPILE_TEST is to allow > limiting the scope of a driver withing hurting the build test coverage. > No I agree with adding COMPILE_TEST just not ARM || ARM64 >> Also you have mentioned it fixes 8f1498c03d15, have you seen any >> regression with that commit ? If so, details in the commit would be >> good. > > Before 8f1498c03d15, the dependency on ARM_MHU made the driver only > visible on ARM kernels. Since 8f1498c03d15, the driver is proposed to > all, which I think isn't correct. I disagree here. It depends on mailbox as we use mailbox API. And it is now used on AmLogic Meson series of SoC. So it *is correct*. > In that sense my proposed patch is > fixing a (user-friendliness) regression. But nothing serious. > Can you elaborate ? What's that *user-friendliness regression* ? build/boot/... ? I just need more details. -- Regards, Sudeep