From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754175AbdBIRP0 (ORCPT ); Thu, 9 Feb 2017 12:15:26 -0500 Received: from mout.kundenserver.de ([212.227.17.10]:55848 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752753AbdBIRPX (ORCPT ); Thu, 9 Feb 2017 12:15:23 -0500 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Andrew Lunn , "David S . Miller" , netdev@vger.kernel.org, Jason Cooper , Sebastian Hesselbarth , Gregory Clement , Russell King , Florian Fainelli , linux-kernel@vger.kernel.org Subject: Re: [PATCH] [net-next] ARM: orion: fix PHYLIB dependency Date: Thu, 09 Feb 2017 18:14:07 +0100 Message-ID: <1967873.WpTcGj2Cy4@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.8.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20170209155751.GB29882@lunn.ch> References: <20170209150834.1158193-1-arnd@arndb.de> <20170209155751.GB29882@lunn.ch> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:vM/w4IEdVQoaQVVB6QZlpMLFJQGKwhEivvKu29IfLDv+6pL/iY0 sMj9s7FbG4rUtv9SaglhwB1vvUID0v/zZD65cG84JQhUahxW0/iQtKZzkyvKEr14gTLCgtj 2hR/CsdSHByi6Y5fMXrnSiHEpHKSqis+ygMTnCfHvmmfoSCSlyvM7WrhuVJFo6/iyLEEyeW O3iGIS6dqB2FN5NkaeW4w== X-UI-Out-Filterresults: notjunk:1;V01:K0:S4GtFpU4I+A=:xNp/cQuzCFjREcf2aLQc85 wBfzW5h/dtAN2ZqehddbBRinvP2Zpg8O8Oa1UIgBJ142z7O5/V9zgUyBHh6H/Wu0O9ctsPvvS Qo8h1fvQA3KCRbJpHAJGDYwZlu2EzLFWzFsjy4OggmscQEdNWpCXRozZbzDqqLdxR1GHMBfLs pZwSdTpZaRded3PdBU2Bj/dtWsKNDemAiuRmjJSwHX2dgkVqBXzV2/W83gw2wYtfiioDT1lHV zWF/4tbjL73WYLg6UZom0nC/nVAs9/8F9RBROVHnYoDXTucbt58P5UnmCwuMAK3pfQPwpKkP3 2OhY5nR/KVQB2UxIkTSNBTasEjdEiZAuXXgaPHmJBm+rQJdkJ1d6nw5j5RjjC2jiNml2msflV Uf3BNL90n9I+RuA1zanPJI4c3K5UZAy39EkTKDLBVdctt8J2PKtZLz0GUuTfdGTFvRhELKaCx sp+PehmsSdkrU+bLWJFVQ8XPVr/K8gPX0xQo5myhkXrKSPs5ofDwdAu+9gFdXb3JVWkLgMyjq dG0IC5YyPvsEH5ZWtKI1oLXgJFEzQ4ixUebroiHHED8IdMRwHbd1X+yNk7sb4i2Pmq4jdFKFK HUooCEQnFEHT3sBH5vNGzn2g131T+yjFgNSBp5WwcR+KnJiR6asSkrMsboChYQO4ynF7i4KBF iLybFEDn+Id90z1t+wdopOMYzFcEgd1KfhYb8HoitZVaOl8CdLOQztfJL32PeGkrCzzkzpeKq G24kGTqDSD8e4D70 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, February 9, 2017 4:57:51 PM CET Andrew Lunn wrote: > On Thu, Feb 09, 2017 at 04:08:11PM +0100, Arnd Bergmann wrote: > > The newly introduced mdiobus_register_board_info() function is only available > > as part of PHYLIB, so we get a link error when we call that from a board while > > phylib is disabled: > > > > arch/arm/plat-orion/common.o: In function `orion_ge00_switch_init': > > common.c:(.init.text+0x6a4): undefined reference to `mdiobus_register_board_info' > > > > This adds a workaround that is made up of three parts: > > > > - in plat-orion, the function for declaring the switch is hidden without > > PHYLIB. > > - in mach-orion5x, the caller conditionally stubs out the call to > > the removed function, so we can still build other orion5x boards > > without PHYLIB > > - For the boards that actually declare the switch, we select PHYLIB > > explicitly from Kconfig if NETDEVICES is set. Without NETDEVICES, > > we cannot enable PHYLIB, but we also wouldn't need it. > > Hi Arnd > > Although all correct, would it not be simpler to just select PHYLIB > and NETDEVICES? These devices are all NAS boxes and WiFi access > points. What sense does it make to build a kernel without working > networking for these classes of devices? Adding a 'select' statement to something as broad as NETDEVICES sounds really bad, it has a significant risk of introducing dependency loops and may be confusing if you want to build a multiplatform config without networking support (note that NETDEVICES in turn depends on NET, which can also be disabled). One possibility would be to have a special Kconfig symbol that controls mdiobus_register_board_info() being present and have that symbol force PHYLIB to never be "=m". Then we can either have no networking support and no phylib, turning mdiobus_register_board_info() into a stub, or we have the function built-in and reachable from the board code. Arnd