linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).