From: Kevin Hilman <khilman@deeprootsystems.com>
To: Silesh C V <saileshcv@gmail.com>
Cc: Govindraj <govindraj.ti@gmail.com>, linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP: PM: CPUFREQ: Fix conditional compilation
Date: Tue, 28 Sep 2010 12:17:36 -0700 [thread overview]
Message-ID: <87tyl9d6en.fsf@deeprootsystems.com> (raw)
In-Reply-To: <AANLkTi=kajdYN9rbdjH_9q6E5RLuy_oj-4Xsk-X6sFRg@mail.gmail.com> (Silesh C. V.'s message of "Mon, 27 Sep 2010 14:18:59 +0530")
Silesh C V <saileshcv@gmail.com> writes:
> On Mon, Sep 27, 2010 at 1:00 PM, Govindraj <govindraj.ti@gmail.com> wrote:
>> On Mon, Sep 27, 2010 at 11:49 AM, Silesh C V <silesh@ti.com> wrote:
>>> On Fri, Sep 24, 2010 at 8:36 PM, Kevin Hilman
>>> <khilman@deeprootsystems.com> wrote:
>>>> Silesh C V <silesh@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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-09-28 19:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-24 8:54 [PATCH] OMAP: PM: CPUFREQ: Fix conditional compilation Silesh C V
2010-09-24 15:06 ` Kevin Hilman
2010-09-27 6:19 ` Silesh C V
2010-09-27 7:30 ` Govindraj
2010-09-27 8:48 ` Silesh C V
2010-09-28 19:17 ` Kevin Hilman [this message]
2010-09-29 5:27 ` Silesh C V
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tyl9d6en.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=govindraj.ti@gmail.com \
--cc=linux-omap@vger.kernel.org \
--cc=saileshcv@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.