[PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m

Uwe Kleine-König u.kleine-koenig at pengutronix.de
Tue Mar 25 05:16:25 EDT 2014


On Mon, Mar 24, 2014 at 01:04:57PM +0100, Arnd Bergmann wrote:
> On Monday 24 March 2014 10:35:56 Simon Horman wrote:
> > On Fri, Mar 21, 2014 at 04:43:24PM +0100, Arnd Bergmann wrote:
> > > On Thursday 20 March 2014, Simon Horman wrote:
> > > > I wonder if Kconfig for koelsch should be tightened up somehow to
> > > > ensure that PHYLIB is either unselected or builtin.
> > > > 
> > > > Also, a minor nit, I would prefer changes for different boards
> > > > in different patches. But I can split the patch myself if its
> > > > not going to be changed otherwise.
> > > 
> > > I would prefer to take the entire series directly into arm-soc
> > > this time, if you don't mind.
> > 
> > That I'm happy to go along with though I don't understand the motivation
> > for it. And regardless of how the patches go in I'd prefer if they were
> > split as I suggested above.
> 
> Sorry, I misunderstood you at first. I thought you meant you only split
> them up when you apply them yourself. It's no problem for me to split
> up this patch as well and then apply it here.
> 
> > What I'm not so happy about is us potentially moving a problem from being a
> > compile time error, which is easy to observe, to a run-time behavioural
> > problem, which may be much less obvious to the beholder.
> 
> I agree that it's not nice, but I couldn't come with a better approach,
> and we are doing the same thing on other platforms as well.
> 
> The problems are:
> 
> * leaving the code as it is today prevents me from running all
>   'make randconfig' kernels successfully. I use this as an important
>   test case for verifying stuff we pull into the arm-soc tree.
>   At the moment, I have a 160-patch series that I want to get merged
>   upstream over time.
> 
> * Using 'select PHYLIB' from the platform is nasty because we want
>   to be able to turn off whole subsystems (BLOCK, NET, I2C, ...)
>   in Kconfig independent of the board selection. PHYLIB requires
>   the network code.
> 
> * Using 'depends on' to disable the board option if PHYLIB is
>   a module is counterintuitive.
> 
> * Makeing PHYLIB always built-in when NETDEVICE is would be a
>   bit wasteful.
maybe let the board

	select PHYLIB if NETDEVICE

is a nice compromise?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |



More information about the linux-arm-kernel mailing list