From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752058AbdAYOOg (ORCPT ); Wed, 25 Jan 2017 09:14:36 -0500 Received: from mx2.suse.de ([195.135.220.15]:37741 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751994AbdAYOOe (ORCPT ); Wed, 25 Jan 2017 09:14:34 -0500 Date: Wed, 25 Jan 2017 15:14:28 +0100 From: Jean Delvare To: Sudeep Holla Cc: LKML , "Jon Medhurst (Tixy)" Subject: Re: [PATCH] firmware: arm_scpi: Add hardware dependencies Message-ID: <20170125151428.1a2a532f@endymion> In-Reply-To: <7561802d-e9d3-2b82-35dc-465c06d6d4eb@arm.com> References: <20170125143200.0554ad0f@endymion> <20170125145037.14a790c4@endymion> <7561802d-e9d3-2b82-35dc-465c06d6d4eb@arm.com> Organization: SUSE Linux X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.31; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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. In that sense my proposed patch is fixing a (user-friendliness) regression. But nothing serious. -- Jean Delvare SUSE L3 Support