On Friday 09 January 2009, Aguirre Rodriguez, Sergio Alberto wrote: > > comment "OMAP Board Type" > > depends on ARCH_OMAP2 || ARCH_OMAP3 > > > > @@ -107,7 +155,7 @@ config MACH_OMAP_2430SDP > > > > config MACH_OMAP_LDP > > bool "OMAP3 LDP board" > > - depends on ARCH_OMAP3 && ARCH_OMAP34XX > > + depends on ARCH_OMAP3 && ARCH_OMAP34XX && !ARCH_OMAP35XX > > > > config MACH_OMAP2EVM > > bool "OMAP 2530 EVM board" > > @@ -115,11 +163,11 @@ config MACH_OMAP2EVM > > > > config MACH_OMAP_3430SDP > > bool "OMAP 3430 SDP board" > > - depends on ARCH_OMAP3 && ARCH_OMAP34XX > > + depends on ARCH_OMAP3 && ARCH_OMAP34XX && !ARCH_OMAP35XX > > > > config MACH_OMAP3EVM > > bool "OMAP 3530 EVM board" > > - depends on ARCH_OMAP3 && ARCH_OMAP34XX > > + depends on ARCH_OMAP35XX > > > > config MACH_OMAP3_BEAGLE > > bool "OMAP3 BEAGLE board" > > Question to all, > > Why don't making above options as choice.. endchoice. Because that completely breaks "multi-OMAP" builds. Having kernels build (and work!) with multiple boards has been a goal for some time now. Switching that stuff to choice...endchoice would be a major regression. I wouldn't merge such a patch. > Or is there any case that multiple boards are compiled at once? Yes, it's routine to build kernels that work with multiple boards. Example, mine work on Beagle, Overo, and SDP. Why do this? Several reasons, all of which boil down to better quality code. The most obvious ones are being able to build-test more systems in the same amount of time ... and then being able to run-test them without needing to waste any time worrying if the behavioral change was due to some odd Kconfig glitch, or is just a bug to fix in the code. The more subtle issues have to do with the various changes that happen to make that work well. Example, board specific #ifdefs in code start to vanish ... which is good, since they hide lits of problems, and are nasty coding style regardless. Sometimes getting rid of such #ifdeffery highlights a much better code structure. Ditto CPU-specific #ifdeffery, of the type which these patches add. Fix them so they don't add #ifdeffery like that, and they will be a lot better accepted... - Dave -- 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
