* Rob Herring <robherring2@xxxxxxxxx> [140617 09:42]: > On Tue, Jun 17, 2014 at 10:25 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > * Rob Herring <robherring2@xxxxxxxxx> [140617 08:05]: > >> On Tue, Jun 17, 2014 at 8:57 AM, Arnd Bergmann <arnd@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
