* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [120303 10:57]: > On Sat, Mar 03, 2012 at 11:01:40AM -0800, Tony Lindgren wrote: > > * Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [120303 10:00]: > > > On Sat, Mar 03, 2012 at 10:04:29AM -0800, Tony Lindgren wrote: > > > > Well 85631d2 builds fine, looks like now some more includes of > > > > plat/hardware.h are now needed.Have not yet tracked down which > > > > commit triggers the build errors. Eventually those should become > > > > local headers too.. > > > > > > It looks like this has happened because you've made stuff far too reliant > > > on DT. You rely on asm/irq.h in asm/prom.h. I've got rid of that, so > > > because you're missing lots of required includes in your .c files, > > > things are failing. > > > > OK, well that's easy to fix. > > > > > And... it seems my config has started to enable all SoCs and boards for > > > some idiotic reason... I guess this is because you're trying to make > > > 'randconfig' just work without seeding it properly? > > > > Hmm that sounds like a bug. A big chunk mach-omap2 randconfigs > > were failing because none of ARCH_OMAP2/3/4 were selected. > > No, it's a result of those changes. The result of adding those 'default y' > statements means that a previous config created by savedefconfig will > end up with those options enabled, as their default state has changed. Right.. > And really, having no ARCH_OMAP2/3/4 selected by a plain randconfig is > not the problem - what is the root cause is that no board type is selected, > and that should be done via a seeded configuration. > > Even with the full config, making oldconfig I get: > > OMAP2420 support (SOC_OMAP2420) [Y/n] (NEW) > OMAP2430 support (SOC_OMAP2430) [Y/n] (NEW) > OMAP3430 support (SOC_OMAP3430) [Y/n] (NEW) > TI81XX support (SOC_OMAPTI81XX) [Y/n] (NEW) > AM33XX support (SOC_OMAPAM33XX) [Y/n] (NEW) > OMAP44XX support (SOC_OMAP44XX) [Y/n] (NEW) > > May I remind you of this mail from Linus: > > https://lkml.org/lkml/2012/1/6/354 > > So really this is a rather horrid mess. Hmm yes. Sounds like we need to remove the defaults and instead add them to omap2plus_defconfig. I'll do a patch to fix that. 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
