[PATCH] ARM: omap: rework platform selection

[Rob Herring]

On Tue, Jun 17, 2014 at 10:25 AM, Tony Lindgren <tony at atomide.com> wrote:
> * 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.

But OMAP1 and OMAP2PLUS are mutually exclusive being v5 and v6+. So
there would not be any user visible difference having 2 visible
options. Do you expect any of these kconfig symbols to become
obsolete?

>> 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.

.config files are the full config, so wouldn't they be okay? It is
only the reduced savedefconfig that would break.

Rob

>
> Regards,
>
> Tony