SUPERH platform development
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m
Date: Mon, 24 Mar 2014 12:04:57 +0000	[thread overview]
Message-ID: <14100654.IXZcGSFRJS@wuerfel> (raw)
In-Reply-To: <20140324013556.GF23924@verge.net.au>

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.

I don't have any other ideas for solving this.

	Arnd

  reply	other threads:[~2014-03-24 12:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1395257399-359545-1-git-send-email-arnd@arndb.de>
2014-03-19 19:29 ` [PATCH 59/62] ARM: shmobile: ak4642 needs i2c support Arnd Bergmann
2014-03-19 19:50   ` Sergei Shtylyov
2014-03-19 20:24     ` Arnd Bergmann
2014-03-19 19:29 ` [PATCH 60/62] ARM: shmobile: work around CONFIG_PHYLIB=m Arnd Bergmann
2014-03-20  3:55   ` Simon Horman
2014-03-21 15:43     ` Arnd Bergmann
2014-03-24  1:35       ` Simon Horman
2014-03-24 12:04         ` Arnd Bergmann [this message]
2014-03-25  9:16           ` Uwe Kleine-König

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=14100654.IXZcGSFRJS@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox