Silesh C V <sailes...@gmail.com> writes: > On Mon, Sep 27, 2010 at 1:00 PM, Govindraj <govindraj...@gmail.com> wrote: >> On Mon, Sep 27, 2010 at 11:49 AM, Silesh C V <sil...@ti.com> wrote: >>> On Fri, Sep 24, 2010 at 8:36 PM, Kevin Hilman >>> <khil...@deeprootsystems.com> wrote: >>>> Silesh C V <sil...@ti.com> writes: >>>> >>>>> Fix conditional compilation. >>>> >>>> What excatly was the compile error? and with which compiler? >>> >>> There is no compiler error.But what we need after an #elif is a >>> conditional expression. >>> The correct usage is #elif defined(CONFIG_XXX) rather than #elif CONFIG_XXX. >>> >>> Further, if the kernel is configured for a non-omap3 arch (eg.OMAP4), >>> you get a compiler warning: >>> arch/arm/plat-omap/cpu-omap.c:47:7: warning: "CONFIG_ARCH_OMAP3" is not >>> defined >>> which goes away with this patch. >>> >> >> Silesh, >> >> which defconfig are you using with multi omap-build >> defconfig(omap3_defconfig) >> >> CONFIG_ARCH_OMAP3 will be enabled. So this compilation error will not occur. >> >> --- >> Regards, >> Govindraj.R >> >> > > As I said before there is no compilation error. But what we have to > check for is whether CONFIG_ARCH_OMAP3 is defined or not. > Not for the value of CONFIG_ARCH_OMAP3. We have to check for value of > defined (CONFIG_ARCH_OMAP3). Otherwise compiler searches for the value > of the macro and hence the warning(comes with a omap4 config).See how > #elif + CONFIG_XXX is used elsewhere in kernel.
I see what you're saying now. The current #elif clause will *always* be true. You'll notice that all of this confusion would not have happened if the original changelog described the problem in detail, showing that that #elif clause will always be true, and especially not calling it a compliation fix. Please re-post with a better changelog and I will incoporate into the pm-cpufreq sub-branch of the PM branch. Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
