All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Rob Herring <robherring2@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Rob Herring <rob.herring@linaro.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	"arm@kernel.org" <arm@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM: omap: rework platform selection
Date: Tue, 17 Jun 2014 08:25:42 -0700	[thread overview]
Message-ID: <20140617152542.GU17845@atomide.com> (raw)
In-Reply-To: <CAL_Jsq+MK+HMqE3k8p06bzzohzS0qu84N12C=VgF9_dMcSGGOQ@mail.gmail.com>

* Rob Herring <robherring2@gmail.com> [140617 08:05]:
> On Tue, Jun 17, 2014 at 8:57 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 16 June 2014, Rob Herring wrote:
> >> > So far I have not come up with no great ideas on fixing this
> >> > properly short of requiring all omap .config files to add
> >> > CONFIG_ARCH_OMAP=y manually. Anybody got good ideas for that?
> >>
> >> I've failed to come up with anything...
> >>
> >
> > I have two ideas, but neither is great:
> >
> > a) we leave the individual per-soc options in the top-level menu
> >    and move the sub-options under those. This is a bit or a problem
> >    for options concerning all of OMAP, but I'm not sure how many of
> >    those are actually required.
> >
> > b) We go back to Rob's version and make CONFIG_ARCH_OMAP the
> >    user-selectable option, and then find another solution for
> >    building a kernel with ARCH_OMAP set but none of individual
> >    options. This will work for anybody who has a full .config
> >    file, but still break the 'make savedefconfig' generated ones.
> 
> After playing with this more yesterday, I think ARCH_OMAP2PLUS instead
> of ARCH_OMAP is actually a better choice to make the menuconfig item.
> It still has the same defconfig issues, but doesn't affect OMAP1.

Well eventually we'll have the same problem for both ARCH_OMAP1
and ARCH_OMAP2PLUS so from that point of view it might make sense
to use ARCH_OMAP to start with.

> Doing your trick of a default selection with "select ARCH_OMAP2 if
> !(ARCH_OMAP3 || ARCH_OMAP4 || ...)" in the menuconfig option can fix
> the build issues. We'd actually need 2 selects for v6 and v7 only
> builds.

Yes that or the options in mach-omap2/Makefile can be fixed up
further for building things only when a SoC is selected.

So really the issue is how to deal with make oldconfig for
existing .config files. I don't know if there's any solution to
that short of doing make CONFIG_ARCH_OMAP=y oldconfig.

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: omap: rework platform selection
Date: Tue, 17 Jun 2014 08:25:42 -0700	[thread overview]
Message-ID: <20140617152542.GU17845@atomide.com> (raw)
In-Reply-To: <CAL_Jsq+MK+HMqE3k8p06bzzohzS0qu84N12C=VgF9_dMcSGGOQ@mail.gmail.com>

* Rob Herring <robherring2@gmail.com> [140617 08:05]:
> On Tue, Jun 17, 2014 at 8:57 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 16 June 2014, Rob Herring wrote:
> >> > So far I have not come up with no great ideas on fixing this
> >> > properly short of requiring all omap .config files to add
> >> > CONFIG_ARCH_OMAP=y manually. Anybody got good ideas for that?
> >>
> >> I've failed to come up with anything...
> >>
> >
> > I have two ideas, but neither is great:
> >
> > a) we leave the individual per-soc options in the top-level menu
> >    and move the sub-options under those. This is a bit or a problem
> >    for options concerning all of OMAP, but I'm not sure how many of
> >    those are actually required.
> >
> > b) We go back to Rob's version and make CONFIG_ARCH_OMAP the
> >    user-selectable option, and then find another solution for
> >    building a kernel with ARCH_OMAP set but none of individual
> >    options. This will work for anybody who has a full .config
> >    file, but still break the 'make savedefconfig' generated ones.
> 
> After playing with this more yesterday, I think ARCH_OMAP2PLUS instead
> of ARCH_OMAP is actually a better choice to make the menuconfig item.
> It still has the same defconfig issues, but doesn't affect OMAP1.

Well eventually we'll have the same problem for both ARCH_OMAP1
and ARCH_OMAP2PLUS so from that point of view it might make sense
to use ARCH_OMAP to start with.

> Doing your trick of a default selection with "select ARCH_OMAP2 if
> !(ARCH_OMAP3 || ARCH_OMAP4 || ...)" in the menuconfig option can fix
> the build issues. We'd actually need 2 selects for v6 and v7 only
> builds.

Yes that or the options in mach-omap2/Makefile can be fixed up
further for building things only when a SoC is selected.

So really the issue is how to deal with make oldconfig for
existing .config files. I don't know if there's any solution to
that short of doing make CONFIG_ARCH_OMAP=y oldconfig.

Regards,

Tony

  reply	other threads:[~2014-06-17 15:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-16 10:04 [PATCH] ARM: omap: rework platform selection Arnd Bergmann
2014-06-16 10:04 ` Arnd Bergmann
2014-06-16 11:00 ` Tony Lindgren
2014-06-16 11:00   ` Tony Lindgren
2014-06-16 11:16   ` Arnd Bergmann
2014-06-16 11:16     ` Arnd Bergmann
2014-06-16 11:26     ` Tony Lindgren
2014-06-16 11:26       ` Tony Lindgren
2014-06-16 14:17       ` Tony Lindgren
2014-06-16 14:17         ` Tony Lindgren
2014-06-16 15:53         ` Rob Herring
2014-06-16 15:53           ` Rob Herring
2014-06-17 13:57           ` Arnd Bergmann
2014-06-17 13:57             ` Arnd Bergmann
2014-06-17 15:03             ` Rob Herring
2014-06-17 15:03               ` Rob Herring
2014-06-17 15:25               ` Tony Lindgren [this message]
2014-06-17 15:25                 ` Tony Lindgren
2014-06-17 16:40                 ` Rob Herring
2014-06-17 16:40                   ` Rob Herring
2014-06-18  6:53                   ` Tony Lindgren
2014-06-18  6:53                     ` Tony Lindgren

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=20140617152542.GU17845@atomide.com \
    --to=tony@atomide.com \
    --cc=arm@kernel.org \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=rob.herring@linaro.org \
    --cc=robherring2@gmail.com \
    /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.