[PATCH] ARM: omap: rework platform selection
Tony Lindgren
tony at atomide.com
Tue Jun 17 08:25:42 PDT 2014
* Rob Herring <robherring2 at gmail.com> [140617 08:05]:
> On Tue, Jun 17, 2014 at 8:57 AM, Arnd Bergmann <arnd at 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
More information about the linux-arm-kernel
mailing list