From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754337AbbCINyJ (ORCPT ); Mon, 9 Mar 2015 09:54:09 -0400 Received: from cantor2.suse.de ([195.135.220.15]:50386 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753554AbbCINyG (ORCPT ); Mon, 9 Mar 2015 09:54:06 -0400 Subject: Re: [PATCH] net: can: Enable xilinx driver for all ARCHs From: Jean Delvare To: Marc Kleine-Budde Cc: Michal Simek , linux-kernel@vger.kernel.org, monstr@monstr.eu, Wolfgang Grandegger , linux-can@vger.kernel.org, netdev@vger.kernel.org In-Reply-To: <54FD6E42.6070206@pengutronix.de> References: <4096fa4ceae72817d8e64d9a1da738038a5c864a.1425890926.git.michal.simek@xilinx.com> <54FD5EE1.6050402@pengutronix.de> <54FD641C.7090607@pengutronix.de> <54FD6E42.6070206@pengutronix.de> Content-Type: text/plain; charset="UTF-8" Organization: Suse Linux Date: Mon, 09 Mar 2015 14:53:59 +0100 Message-ID: <1425909239.23920.60.camel@chaos.site> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le Monday 09 March 2015 à 10:56 +0100, Marc Kleine-Budde a écrit : > On 03/09/2015 10:52 AM, Michal Simek wrote: > > On 03/09/2015 10:13 AM, Marc Kleine-Budde wrote: > >> On 03/09/2015 09:58 AM, Michal Simek wrote: > >>> On 03/09/2015 09:50 AM, Marc Kleine-Budde wrote: > >>>> On 03/09/2015 09:48 AM, Michal Simek wrote: > >>>>> Remove Kconfig dependency and enable driver for > >>>>> all ARCHs. > >>>>> > >>>>> Signed-off-by: Michal Simek > >>>>> Acked-by: Sören Brinkmann > >>>>> --- > >>>>> > >>>>> Test for all archs done by Kbuild test robot without any problem. > >>>>> --- > >>>>> drivers/net/can/Kconfig | 1 - > >>>>> 1 file changed, 1 deletion(-) > >>>>> > >>>>> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig > >>>>> index 98d73aab52fe..f690c3fb3088 100644 > >>>>> --- a/drivers/net/can/Kconfig > >>>>> +++ b/drivers/net/can/Kconfig > >>>>> @@ -131,7 +131,6 @@ config CAN_RCAR > >>>>> > >>>>> config CAN_XILINXCAN > >>>>> tristate "Xilinx CAN" > >>>>> - depends on ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST > >>>> > >>>> I think that's what COMPILE_TEST ist for? > >>> > >>> For compilation yes but not for enabling. Currently this driver > >>> can be also used on ARM64 that's why people suggesting directly > >>> to remove dependency on arch and then COMPILE_TEST can be removed > >>> too. > >> > >> In the past (May 2014) I had people complaining that certain ARM SoC > >> specific drivers are enabled on ARM in general, not just on that SoC. As > >> I'm not following arm64 in detail, has the notion of using depends on > >> ARCH changes since then? > >> > >>> Or do you want me to change description to mention that this is for > >>> ARM64 enabling? > >> > >> Given this is consensus, a remark to ARM64 would be appreciated. :) > > > > David has applied this patch which is in general just the same as this one. > > > > (linux-next) Remove architecture dependency > > 28811a8c00fe0d899b8a544421f3b4947425d5e8 > > > > Mark Brown has suggested to do so for spi and don't check architecture at > > all. > > I have also sent similar patch for watchdog driver too. > > > > I think it is up to you if you want to add ARM64 to Kconfig or just remove > > that arch dependencies. > > To be honest my goal is to enable this driver for ARM64. > > Please tell me what way you prefer. > > I like the idea of removing the depends on ARCH completely. Jean, what > do you think? Removing the dependency completely will let the option be displayed on systems where the driver is useless. I am in favor of having hardware dependencies on as many drivers as possible to avoid bothering the user with irrelevant questions. The list of Kconfig entries has grown a lot over time! If the current dependency is too strict then I would suggest to extend it or to make it broader (depends on ARM || ARM64 || COMPILE_TEST would be acceptable IMHO.) Dropping it completely only makes sense if the part is used on so many systems that the dependency becomes too long or is a pain to maintain. Thanks, -- Jean Delvare SUSE L3 Support