[PATCH] ARM: omap: rework platform selection

[PATCH] ARM: omap: rework platform selection

[Arnd Bergmann]

Commit 9851b662f659 ("ARM: use menuconfig for sub-arch menus") did more
than expected, which led to two OMAP specific bugs:

* Turning CONFIG_ARCH_OMAP into a user-selectable option makes it possible
  to have a configuration with ARCH_OMAP enabled but none of the specific
  OMAP SoCs enabled, which triggers a couple of link errors due to the
  layout of the Makefile

* The plat-omap menu still appears mixed into the normal menuconfig list,
  which is confusing and inconsistent.

To make matters worse, the change did not enable CONFIG_ARCH_OMAP in the
defconfig files, which through some ripple effects disabled options that
were implicitly enabled from OMAP2, and that caused all machines to
fail booting with the unchanged config files.

This reorders the OMAP Kconfig files some more, to be consistent with
the others, and also changes the defconfig files.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Tony, can you have a look at this please? I'd like to send out the
fixes for 3.16, but this is needed on top of Rob's Kconfig changes.


diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 245058b..fcf6ddf 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -973,10 +973,6 @@ source "arch/arm/mach-nspire/Kconfig"
 
 source "arch/arm/plat-omap/Kconfig"
 
-source "arch/arm/mach-omap1/Kconfig"
-
-source "arch/arm/mach-omap2/Kconfig"
-
 source "arch/arm/mach-orion5x/Kconfig"
 
 source "arch/arm/mach-picoxcell/Kconfig"
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index e2d6204..d77bb9e 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -23,6 +23,7 @@ CONFIG_ARCH_BERLIN=y
 CONFIG_MACH_BERLIN_BG2=y
 CONFIG_MACH_BERLIN_BG2CD=y
 CONFIG_MACH_BERLIN_BG2Q=y
+CONFIG_ARCH_OMAP_ENABLE=y
 CONFIG_ARCH_HIGHBANK=y
 CONFIG_ARCH_HI3xxx=y
 CONFIG_ARCH_KEYSTONE=y
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 536a137..85de0a1 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -25,6 +25,7 @@ CONFIG_POWER_AVS_OMAP=y
 CONFIG_POWER_AVS_OMAP_CLASS3=y
 CONFIG_OMAP_RESET_CLOCKS=y
 CONFIG_OMAP_MUX_DEBUG=y
+CONFIG_ARCH_OMAP_ENABLE=y
 CONFIG_ARCH_OMAP2=y
 CONFIG_ARCH_OMAP3=y
 CONFIG_ARCH_OMAP4=y
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index cdd05f2..53a802c 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -1,8 +1,6 @@
 if ARCH_OMAP1
 
-menu "TI OMAP1 specific features"
-
-comment "OMAP Core Type"
+comment "OMAP1 Core Type"
 	depends on ARCH_OMAP1
 
 config ARCH_OMAP730
@@ -164,6 +162,4 @@ config MACH_OMAP_GENERIC
           custom OMAP boards. Say Y here if you have a custom
           board.
 
-endmenu
-
 endif
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4e81860..0006012 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -1,7 +1,5 @@
-menuconfig ARCH_OMAP
-	bool "TI OMAP/AM/DRA Based" if (ARCH_MULTI_V6 || ARCH_MULTI_V7)
-
-if ARCH_OMAP
+config ARCH_OMAP
+	bool
 
 config ARCH_OMAP2
 	bool "TI OMAP2"
@@ -82,6 +80,7 @@ config ARCH_OMAP2PLUS
 	bool
 	select ARCH_HAS_BANDGAP
 	select ARCH_HAS_HOLES_MEMORYMODEL
+	select ARCH_OMAP
 	select ARCH_REQUIRE_GPIOLIB
 	select CLKSRC_MMIO
 	select GENERIC_IRQ_CHIP
@@ -342,5 +341,3 @@ config OMAP4_ERRATA_I688
 endmenu
 
 endif
-
-endif
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 02fc10d..8aa2dd2 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -1,6 +1,11 @@
-if ARCH_OMAP
+menuconfig ARCH_OMAP_ENABLE
+	bool "TI OMAP platforms" if ARCH_MULTI_V6 || ARCH_MULTI_V7
+	default ARCH_OMAP1
 
-menu "TI OMAP Common Features"
+if ARCH_OMAP_ENABLE
+
+source "arch/arm/mach-omap1/Kconfig"
+source "arch/arm/mach-omap2/Kconfig"
 
 config ARCH_OMAP_OTG
 	bool
@@ -153,6 +158,4 @@ config OMAP_PM_NOOP
 
 endchoice
 
-endmenu
-
 endif

Re: [PATCH] ARM: omap: rework platform selection

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [140616 03:06]:
> Commit 9851b662f659 ("ARM: use menuconfig for sub-arch menus") did more
> than expected, which led to two OMAP specific bugs:

It seems the commit above is not -rc cycle material at least not without
proper testing. There's a good chance of breaking a lot of the existing
.config files which can create a big mess as we've seen before. 
 
> * Turning CONFIG_ARCH_OMAP into a user-selectable option makes it possible
>   to have a configuration with ARCH_OMAP enabled but none of the specific
>   OMAP SoCs enabled, which triggers a couple of link errors due to the
>   layout of the Makefile

And so we have a regression to this old problem again :(
 
> * The plat-omap menu still appears mixed into the normal menuconfig list,
>   which is confusing and inconsistent.

That we should be able to remove completely soon but that's a
separate patch..
 
> To make matters worse, the change did not enable CONFIG_ARCH_OMAP in the
> defconfig files, which through some ripple effects disabled options that
> were implicitly enabled from OMAP2, and that caused all machines to
> fail booting with the unchanged config files.
> 
> This reorders the OMAP Kconfig files some more, to be consistent with
> the others, and also changes the defconfig files.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Tony, can you have a look at this please? I'd like to send out the
> fixes for 3.16, but this is needed on top of Rob's Kconfig changes.

Hmm why is this patch already in linux next before getting posted
to the mailing lists?

> --- a/arch/arm/plat-omap/Kconfig
> +++ b/arch/arm/plat-omap/Kconfig
> @@ -1,6 +1,11 @@
> -if ARCH_OMAP
> +menuconfig ARCH_OMAP_ENABLE
> +	bool "TI OMAP platforms" if ARCH_MULTI_V6 || ARCH_MULTI_V7
> +	default ARCH_OMAP1
>  
> -menu "TI OMAP Common Features"
> +if ARCH_OMAP_ENABLE
> +
> +source "arch/arm/mach-omap1/Kconfig"
> +source "arch/arm/mach-omap2/Kconfig"

It seems to me this kind of change is going to break all the
existing .config files unless they are manually updated. This
includes all the distros and automated build systems. I'll look
more at it, but my initial take is that we should be able to do
this all with CONFIG_ARCH_OMAP + the selected OMAP SoC and should
not introduce any new Kconfig options.

For now I'd just leave out Rob's changed and this patch from fixes
until they have been properly tested.

Regards,

Tony

Re: [PATCH] ARM: omap: rework platform selection

[Arnd Bergmann]

On Monday 16 June 2014 04:00:42 Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [140616 03:06]:
> > Commit 9851b662f659 ("ARM: use menuconfig for sub-arch menus") did more
> > than expected, which led to two OMAP specific bugs:
> 
> It seems the commit above is not -rc cycle material at least not without
> proper testing. There's a good chance of breaking a lot of the existing
> .config files which can create a big mess as we've seen before. 

Well, Kconfig is a big mess without it at the moment. The OMAP change
was definitely wrong there, but for all other platforms I don't see any
risk in applying it, because there is no semantic change, only cosmetic.

> > * Turning CONFIG_ARCH_OMAP into a user-selectable option makes it possible
> >   to have a configuration with ARCH_OMAP enabled but none of the specific
> >   OMAP SoCs enabled, which triggers a couple of link errors due to the
> >   layout of the Makefile
> 
> And so we have a regression to this old problem again :(

Yes, I didn't actually see this happen but from looking at the patch, I
concluded that it would likely be the case.

> > * The plat-omap menu still appears mixed into the normal menuconfig list,
> >   which is confusing and inconsistent.
> 
> That we should be able to remove completely soon but that's a
> separate patch..

Ok.

> > To make matters worse, the change did not enable CONFIG_ARCH_OMAP in the
> > defconfig files, which through some ripple effects disabled options that
> > were implicitly enabled from OMAP2, and that caused all machines to
> > fail booting with the unchanged config files.
> > 
> > This reorders the OMAP Kconfig files some more, to be consistent with
> > the others, and also changes the defconfig files.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > Tony, can you have a look at this please? I'd like to send out the
> > fixes for 3.16, but this is needed on top of Rob's Kconfig changes.
> 
> Hmm why is this patch already in linux next before getting posted
> to the mailing lists?

I had applied Rob's patch to the fixes series but that broke all
multi_v7_defconfig runs on the boot test machines. I didn't want to
spend too much work on it over the weekend, but applied it so at least
today's linux-next wouldn't regress over last week's.

> > --- a/arch/arm/plat-omap/Kconfig
> > +++ b/arch/arm/plat-omap/Kconfig
> > @@ -1,6 +1,11 @@
> > -if ARCH_OMAP
> > +menuconfig ARCH_OMAP_ENABLE
> > +	bool "TI OMAP platforms" if ARCH_MULTI_V6 || ARCH_MULTI_V7
> > +	default ARCH_OMAP1
> >  
> > -menu "TI OMAP Common Features"
> > +if ARCH_OMAP_ENABLE
> > +
> > +source "arch/arm/mach-omap1/Kconfig"
> > +source "arch/arm/mach-omap2/Kconfig"
> 
> It seems to me this kind of change is going to break all the
> existing .config files unless they are manually updated. This
> includes all the distros and automated build systems. I'll look
> more at it, but my initial take is that we should be able to do
> this all with CONFIG_ARCH_OMAP + the selected OMAP SoC and should
> not introduce any new Kconfig options.
> 
> For now I'd just leave out Rob's changed and this patch from fixes
> until they have been properly tested.

Let's see if others have similar opinions Rob's patch as a whole.
I'd still like to keep all the parts aside from the OMAP change
and just back out the change that caused the problems.

Does that seem reasonable to you?

	Arnd

Re: [PATCH] ARM: omap: rework platform selection

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [140616 04:18]:
> On Monday 16 June 2014 04:00:42 Tony Lindgren wrote:
> > * Arnd Bergmann <arnd@arndb.de> [140616 03:06]:
> > > Commit 9851b662f659 ("ARM: use menuconfig for sub-arch menus") did more
> > > than expected, which led to two OMAP specific bugs:
> > 
> > It seems the commit above is not -rc cycle material at least not without
> > proper testing. There's a good chance of breaking a lot of the existing
> > .config files which can create a big mess as we've seen before. 
> 
> Well, Kconfig is a big mess without it at the moment. The OMAP change
> was definitely wrong there, but for all other platforms I don't see any
> risk in applying it, because there is no semantic change, only cosmetic.
> 
> > > * Turning CONFIG_ARCH_OMAP into a user-selectable option makes it possible
> > >   to have a configuration with ARCH_OMAP enabled but none of the specific
> > >   OMAP SoCs enabled, which triggers a couple of link errors due to the
> > >   layout of the Makefile
> > 
> > And so we have a regression to this old problem again :(
> 
> Yes, I didn't actually see this happen but from looking at the patch, I
> concluded that it would likely be the case.
> 
> > > * The plat-omap menu still appears mixed into the normal menuconfig list,
> > >   which is confusing and inconsistent.
> > 
> > That we should be able to remove completely soon but that's a
> > separate patch..
> 
> Ok.
> 
> > > To make matters worse, the change did not enable CONFIG_ARCH_OMAP in the
> > > defconfig files, which through some ripple effects disabled options that
> > > were implicitly enabled from OMAP2, and that caused all machines to
> > > fail booting with the unchanged config files.
> > > 
> > > This reorders the OMAP Kconfig files some more, to be consistent with
> > > the others, and also changes the defconfig files.
> > > 
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > Tony, can you have a look at this please? I'd like to send out the
> > > fixes for 3.16, but this is needed on top of Rob's Kconfig changes.
> > 
> > Hmm why is this patch already in linux next before getting posted
> > to the mailing lists?
> 
> I had applied Rob's patch to the fixes series but that broke all
> multi_v7_defconfig runs on the boot test machines. I didn't want to
> spend too much work on it over the weekend, but applied it so at least
> today's linux-next wouldn't regress over last week's.

Ah OK I see. Some quality time with duct tape in the basement
with the leaking pipes :)
 
> > > --- a/arch/arm/plat-omap/Kconfig
> > > +++ b/arch/arm/plat-omap/Kconfig
> > > @@ -1,6 +1,11 @@
> > > -if ARCH_OMAP
> > > +menuconfig ARCH_OMAP_ENABLE
> > > +	bool "TI OMAP platforms" if ARCH_MULTI_V6 || ARCH_MULTI_V7
> > > +	default ARCH_OMAP1
> > >  
> > > -menu "TI OMAP Common Features"
> > > +if ARCH_OMAP_ENABLE
> > > +
> > > +source "arch/arm/mach-omap1/Kconfig"
> > > +source "arch/arm/mach-omap2/Kconfig"
> > 
> > It seems to me this kind of change is going to break all the
> > existing .config files unless they are manually updated. This
> > includes all the distros and automated build systems. I'll look
> > more at it, but my initial take is that we should be able to do
> > this all with CONFIG_ARCH_OMAP + the selected OMAP SoC and should
> > not introduce any new Kconfig options.
> > 
> > For now I'd just leave out Rob's changed and this patch from fixes
> > until they have been properly tested.
> 
> Let's see if others have similar opinions Rob's patch as a whole.
> I'd still like to keep all the parts aside from the OMAP change
> and just back out the change that caused the problems.
> 
> Does that seem reasonable to you?

Yes makes sense to me if others don't have similar issues. I guess
it should be possible to verify that by diffing the generated
.config files compared to the old ones.

Regards,

Tony

Re: [PATCH] ARM: omap: rework platform selection

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [140616 04:31]:
> * Arnd Bergmann <arnd@arndb.de> [140616 04:18]:
> > 
> > Let's see if others have similar opinions Rob's patch as a whole.
> > I'd still like to keep all the parts aside from the OMAP change
> > and just back out the change that caused the problems.
> > 
> > Does that seem reasonable to you?
> 
> Yes makes sense to me if others don't have similar issues. I guess
> it should be possible to verify that by diffing the generated
> .config files compared to the old ones.

If you update Rob's patch and undo the omap2+ changes, you might
want to fold in something like the following to hide the omap
options behind a menu.

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?

Regards,

Tony

--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -1,3 +1,5 @@
+menu "TI OMAP/AM/DM/DRA Family"
+
 config ARCH_OMAP
 	bool
 
@@ -342,3 +344,5 @@ config OMAP4_ERRATA_I688
 endmenu
 
 endif
+
+endmenu

Re: [PATCH] ARM: omap: rework platform selection

[Rob Herring]

On Mon, Jun 16, 2014 at 9:17 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Tony Lindgren <tony@atomide.com> [140616 04:31]:
>> * Arnd Bergmann <arnd@arndb.de> [140616 04:18]:
>> >
>> > Let's see if others have similar opinions Rob's patch as a whole.
>> > I'd still like to keep all the parts aside from the OMAP change
>> > and just back out the change that caused the problems.
>> >
>> > Does that seem reasonable to you?
>>
>> Yes makes sense to me if others don't have similar issues. I guess
>> it should be possible to verify that by diffing the generated
>> .config files compared to the old ones.

Other than exynos (which is new to MP) and OMAP, the rest are
straightforward user config to menuconfig conversions.

> If you update Rob's patch and undo the omap2+ changes, you might
> want to fold in something like the following to hide the omap
> options behind a menu.

This or reverting the OMAP part seems like the best change for now.

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

Rob

>
> Regards,
>
> Tony
>
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -1,3 +1,5 @@
> +menu "TI OMAP/AM/DM/DRA Family"
> +
>  config ARCH_OMAP
>         bool
>
> @@ -342,3 +344,5 @@ config OMAP4_ERRATA_I688
>  endmenu
>
>  endif
> +
> +endmenu

Re: [PATCH] ARM: omap: rework platform selection

[Arnd Bergmann]

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.

	Arnd

Re: [PATCH] ARM: omap: rework platform selection

[Rob Herring]

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.

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.

Rob

Re: [PATCH] ARM: omap: rework platform selection

[Tony Lindgren]

* 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

Re: [PATCH] ARM: omap: rework platform selection

[Rob Herring]

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

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

Re: [PATCH] ARM: omap: rework platform selection

[Tony Lindgren]

* Rob Herring <robherring2@gmail.com> [140617 09:42]:
> On Tue, Jun 17, 2014 at 10:25 AM, Tony Lindgren <tony@atomide.com> wrote:
> > * 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.
> 
> 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?

Yes you're right. They would be mutually exclusive and will most
likely stay that way because of different compiler flags needed.
All three Kconfig options are needed. So if you prefer using
OMAP2PLUS there I'm fine with that.
 
> >> 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.

Right, so maybe that problem does not affect as many people as I
thought originally. But certainly not something to do during the
-rc cycle though :)

Regards,

Tony