From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Tue, 17 Jun 2014 08:25:42 -0700 Subject: [PATCH] ARM: omap: rework platform selection In-Reply-To: References: <5701099.0P1SIXsHc1@wuerfel> <20140616141712.GL17845@atomide.com> <201406171557.15819.arnd@arndb.de> Message-ID: <20140617152542.GU17845@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Rob Herring [140617 08:05]: > On Tue, Jun 17, 2014 at 8:57 AM, Arnd Bergmann 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