From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Kim Kyuwon <chammoru@gmail.com>
Cc: Kim Kyuwon <q1.kim@samsung.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-input@vger.kernel.org,
Kyungmin Park <kyungmin.park@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: Input: add MAX7359 key switch controller driver
Date: Fri, 8 May 2009 20:36:25 -0700 [thread overview]
Message-ID: <200905082036.26204.dmitry.torokhov@gmail.com> (raw)
In-Reply-To: <4d34a0a70905081858y56dacf34of004301f93daf3e3@mail.gmail.com>
Hi Kim,
On Friday 08 May 2009 18:58:45 Kim Kyuwon wrote:
> By the way, can I ask the same question which I ask to Trilok.
> Even though I guard suspend/resume with #ifdef CONFIG_PM in the new
> patch, Could I know the good reason for this protection? Because
> '/Documentation/SubmittingPatches' says "ifdefs are ugly"
If kernel is compiled without CONFIG_PM then these functions would
be just dead weight. Generally speaking, #ifdefs are considered ugly
if they are in the middle of function code, affecting logic. But to
to compile out unneeded functionality they are OK. That's why you
often see in the kernel
#ifdef CONFIG_BAZ
void do_baz()
{
.. real code ..
}
#else
void do_baz()
{
}
#endif
and then...
int foo()
{
bar1();
bar2();
do_baz();
bar3();
}
As you can see, foo()'s logic stays the same, there are no #ifdefs
cluttering it, but baz code either executed or not.
Hope this helps.
--
Dmitry
next prev parent reply other threads:[~2009-05-09 3:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-06 6:21 Input: add MAX7359 key switch controller driver Kim Kyuwon
2009-05-06 13:38 ` Trilok Soni
2009-05-06 17:57 ` H Hartley Sweeten
2009-05-07 10:03 ` Kim Kyuwon
[not found] ` <4d34a0a70905070303r55c2c681yf58680de2f3d4a9f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-05-07 10:17 ` Trilok Soni
2009-05-08 3:19 ` Dmitry Torokhov
2009-05-09 1:58 ` Kim Kyuwon
2009-05-09 3:36 ` Dmitry Torokhov [this message]
2009-05-09 3:56 ` Kim Kyuwon
2009-05-09 17:22 ` Trilok Soni
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=200905082036.26204.dmitry.torokhov@gmail.com \
--to=dmitry.torokhov@gmail.com \
--cc=chammoru@gmail.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=q1.kim@samsung.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).