All of lore.kernel.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] [net-next] ARM: orion: fix PHYLIB dependency
Date: Thu, 09 Feb 2017 18:14:07 +0100	[thread overview]
Message-ID: <1967873.WpTcGj2Cy4@wuerfel> (raw)
In-Reply-To: <20170209155751.GB29882@lunn.ch>

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

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Andrew Lunn <andrew@lunn.ch>,
	"David S . Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
	Gregory Clement <gregory.clement@free-electrons.com>,
	Russell King <linux@armlinux.org.uk>,
	Florian Fainelli <f.fainelli@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [net-next] ARM: orion: fix PHYLIB dependency
Date: Thu, 09 Feb 2017 18:14:07 +0100	[thread overview]
Message-ID: <1967873.WpTcGj2Cy4@wuerfel> (raw)
In-Reply-To: <20170209155751.GB29882@lunn.ch>

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

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Jason Cooper <jason@lakedaemon.net>,
	netdev@vger.kernel.org, Russell King <linux@armlinux.org.uk>,
	linux-kernel@vger.kernel.org,
	Gregory Clement <gregory.clement@free-electrons.com>,
	"David S . Miller" <davem@davemloft.net>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCH] [net-next] ARM: orion: fix PHYLIB dependency
Date: Thu, 09 Feb 2017 18:14:07 +0100	[thread overview]
Message-ID: <1967873.WpTcGj2Cy4@wuerfel> (raw)
In-Reply-To: <20170209155751.GB29882@lunn.ch>

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

  reply	other threads:[~2017-02-09 17:14 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-09 15:08 [PATCH] [net-next] ARM: orion: fix PHYLIB dependency Arnd Bergmann
2017-02-09 15:08 ` Arnd Bergmann
2017-02-09 15:08 ` Arnd Bergmann
2017-02-09 15:57 ` Andrew Lunn
2017-02-09 15:57   ` Andrew Lunn
2017-02-09 15:57   ` Andrew Lunn
2017-02-09 17:14   ` Arnd Bergmann [this message]
2017-02-09 17:14     ` Arnd Bergmann
2017-02-09 17:14     ` Arnd Bergmann
2017-02-09 17:20     ` Andrew Lunn
2017-02-09 17:20       ` Andrew Lunn
2017-02-09 17:20       ` Andrew Lunn
2017-02-09 18:14       ` Florian Fainelli
2017-02-09 18:14         ` Florian Fainelli
2017-02-09 18:14         ` Florian Fainelli
2017-02-09 17:22 ` Andrew Lunn
2017-02-09 17:22   ` Andrew Lunn
2017-02-09 17:22   ` Andrew Lunn
2017-02-09 18:22 ` Florian Fainelli
2017-02-09 18:22   ` Florian Fainelli
2017-02-09 18:22   ` Florian Fainelli
2017-02-10  8:20   ` Arnd Bergmann
2017-02-10  8:20     ` Arnd Bergmann
2017-02-10  8:20     ` Arnd Bergmann
2017-02-10 17:42     ` Florian Fainelli
2017-02-10 17:42       ` Florian Fainelli
2017-02-10 17:42       ` Florian Fainelli
2017-02-10 20:05       ` Arnd Bergmann
2017-02-10 20:05         ` Arnd Bergmann
2017-02-10 20:05         ` Arnd Bergmann
2017-02-10 20:57         ` Florian Fainelli
2017-02-10 20:57           ` Florian Fainelli
2017-02-10 21:32           ` Arnd Bergmann
2017-02-10 21:32             ` Arnd Bergmann
2017-02-10 21:32             ` Arnd Bergmann
2017-02-13 14:31             ` Arnd Bergmann
2017-02-13 14:31               ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1967873.WpTcGj2Cy4@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.