On Sat, Mar 05, 2011 at 02:11:29PM +0530, Santosh Shilimkar wrote: > + Russell, > > > -----Original Message----- > > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > > owner@xxxxxxxxxxxxxxx] On Behalf Of Menon, Nishanth > > Sent: Saturday, March 05, 2011 1:51 PM > > To: linux-omap > > Subject: pm-core: recursive dependency on config > > > > Folks, > > Dumb question: > > Some one seen this one? is there a patch in the pipe for the fix? > > > > scripts/kconfig/conf --silentoldconfig Kconfig > > arch/arm/Kconfig:1277:error: recursive dependency detected! > > arch/arm/Kconfig:1277: symbol SMP depends on CPU_V6K > > arch/arm/mm/Kconfig:407: symbol CPU_V6K depends on SMP > > > I saw this one too. This is because of resent changes to > ensure that CPU_32v6K is always enabled with SMP builds. > > This is tricky dependency. May be RMK has better way to deal > with this. > > Two relevant commit on this are '85a11f52' and '15490ef8' What is 85a11f52 ? 15490ef8 (in mainline) is: config CPU_32v6K bool "Support ARM V6K processor extensions" if !SMP depends on CPU_V6 || CPU_V7 - default y if SMP && !(ARCH_MX3 || ARCH_OMAP2) + default y if SMP fbb4ddac (ARM: v6k: only allow SMP if we have v6k or v7 CPU) does this: config SMP bool "Symmetric Multi-Processing (EXPERIMENTAL)" depends on EXPERIMENTAL + depends on CPU_V6K || CPU_V7 which I assume is 85a11f52 in Tony's tree. However, e399b1a4e (ARM: v6k: introduce CPU_V6K option) does this: -config CPU_32v6K - bool "Support ARM V6K processor extensions" if !SMP - depends on CPU_V6 || CPU_V7 - default y if SMP && !(ARCH_MX3 || ARCH_OMAP2) - help - Say Y here if your ARMv6 processor supports the 'K' extension. - This enables the kernel to use some instructions not present - on previous processors, and as such a kernel build with this - enabled will not boot on processors with do not support these - instructions. +config CPU_V6K + bool "Support ARM V6K processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB + select CPU_32v6 + select CPU_32v6K if !ARCH_OMAP2 + select CPU_ABRT_EV6 + select CPU_PABRT_V6 + select CPU_CACHE_V6 + select CPU_CACHE_VIPT + select CPU_CP15_MMU + select CPU_HAS_ASID if MMU + select CPU_COPY_V6 if MMU + select CPU_TLB_V6 if MMU which conflicts with 15490ef8. So I suspect that a merge conflict hasn't been resolved correctly. I'm not going to worry about that because I have the merge conflict resolution here already as part of my tree. -- 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