ARM: omap: rework platform selection

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 <[email protected]>

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

Quoted 2 lines · Arnd Bergmann

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.

Quoted 4 lines

* 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 :(

Quoted 2 lines

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

Quoted 8 lines

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.

Quoted 4 lines

Signed-off-by Arnd Bergmann <[email protected]>

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

arch/arm/plat-omap/Kconfig line 8

Quoted 13 lines

arch/arm/plat-omap/Kconfig +7 -2

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

Quoted 7 lines · On Monday 16 June 2014 04:00:42 Tony Lindgren wrote:

Quoted 2 lines · Arnd Bergmann

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.

Quoted 6 lines

Quoted 4 lines

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

Quoted 5 lines

Quoted 2 lines

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

Quoted 13 lines

Quoted 12 lines

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 <[email protected]>

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

Quoted 2 lines

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.

Quoted 21 lines

arch/arm/plat-omap/Kconfig line 8

Quoted 13 lines

arch/arm/plat-omap/Kconfig +7 -2

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

Quoted 2 lines

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?

Quoted 6 lines · Arnd Bergmann

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.

Quoted 6 lines · Tony Lindgren

Quoted 5 lines · Arnd Bergmann

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.

Quoted 5 lines

Quoted 1 line

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

arch/arm/mach-omap2/Kconfig +4 -0

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

Quoted 3 lines

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

Quoted 6 lines · Rob Herring

Quoted 3 lines

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.

Quoted 15 lines · Arnd Bergmann

Quoted 6 lines · Rob Herring

Quoted 3 lines

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.

Quoted 5 lines

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.

Quoted 22 lines · Rob Herring

Quoted 20 lines · Arnd Bergmann

Quoted 6 lines · Rob Herring

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 4 lines

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

Quoted 27 lines · Tony Lindgren

Quoted 25 lines · Rob Herring

Quoted 15 lines · Arnd Bergmann

Quoted 6 lines · Rob Herring

Quoted 3 lines

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.

Quoted 5 lines

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.

Quoted 3 lines

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?

Quoted 8 lines

Quoted 4 lines

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.

Quoted 3 lines

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.