Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753757AbbDNSEl (ORCPT ); Tue, 14 Apr 2015 14:04:41 -0400 Received: from mail-gw3-out.broadcom.com ([216.31.210.64]:46279 "EHLO mail-gw3-out.broadcom.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752464AbbDNSEc (ORCPT ); Tue, 14 Apr 2015 14:04:32 -0400 X-IronPort-AV: E=Sophos;i="5.11,577,1422950400"; d="scan'208";a="61940822" Message-ID: <552D56EF.2020409@broadcom.com> Date: Tue, 14 Apr 2015 11:05:35 -0700 From: Arun Ramamurthy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kishon Vijay Abraham I , Greg Kroah-Hartman , Arnd Bergmann CC: , Srinivas Kandagatla , Laurent Pinchart , , Thomas Pugliese , Peter Griffin , Jonathan Richardson , Anatol Pomazau , Ray Jui , Alan Stern , Dmitry Torokhov , "David Mosberger" , Gregory CLEMENT , Kevin Hao , "Paul Bolle" , Mathias Nyman , Scott Branden , , , Felipe Balbi , Tony Prisk Subject: Re: [PATCHv2 2/3] usb: ehci-platform: Use devm_of_phy_get_by_index References: <1428963047-23666-1-git-send-email-arun.ramamurthy@broadcom.com> <6483716.157BQAaRqF@wuerfel> <20150414123737.GB18756@kroah.com> <2433709.D3gBAte9Iu@wuerfel> <20150414132745.GA5650@kroah.com> <552D2255.1050704@ti.com> In-Reply-To: <552D2255.1050704@ti.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2570 Lines: 60 On 15-04-14 07:21 AM, Kishon Vijay Abraham I wrote: > Hi, > > On Tuesday 14 April 2015 06:57 PM, Greg Kroah-Hartman wrote: >> On Tue, Apr 14, 2015 at 03:17:30PM +0200, Arnd Bergmann wrote: >>> On Tuesday 14 April 2015 14:37:37 Greg Kroah-Hartman wrote: >>>> On Tue, Apr 14, 2015 at 01:33:08PM +0200, Arnd Bergmann wrote: >>>>> This is true, but all other drivers do the same for GENERIC_PHY at the >>>>> moment. If this one gets changed, we should probably apply the same >>>>> solution to all current users and fix them consistently. >>>>> >>>>> We can do one of these two: >>>>> >>>>> a) make sure that the framework has 'static inline' stubs that let you >>>>> build all drivers using it when the framework itself is disabled. >>>> >>>> Yes, please do that. >>>> >>>>> b) change the drivers using it to 'depends on', and make GENERIC_PHY >>>>> itself a hidden option without a Kconfig prompt. >>>> >>>> Then how could GENERIC_PHY ever get set? >>> >>> Right now, every driver that provides a phy uses 'select GENERIC_PHY', >>> and they would have to keep doing that. This is not unlike what we >>> do for other silent symbols like MFD_CORE, REGMAP_I2C, or PINCTRL, >>> and it's not as problematic as 'select' on a user-visible option, >>> or (worst) mixing 'select' and 'depends on'. >> >> Ok, that would make more sense, but it would be good for the PHY >> maintainer to agree to it as well :) > > looking at [1], we should use select only for non-visible symbols and > for symbols with no dependencies. As such GENERIC_PHY is not dependent > on other symbols but for now it is "visible". > > phy-core has all the stubs already implemented in > include/linux/phy/phy.h. So removing select GENERIC_PHY shouldn't be a > problem. But then it might break a few platforms where GENERIC_PHY is > indirectly enabled by selecting the config of the driver (using default > defconfigs in arch/arm/configs). > > The simplest thing would be to make GENERIC_PHY an invisible option? > > [1] -> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kbuild/kconfig-language.txt#n111 > Kishon,removing select GENERIC_PHY also breaks the builds for certain architectures (i386 and x84_64). Is the consensus to leave the select but make GENERIC_PHY a invisible option? Thanks > > Thanks > Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/