From: Alan Ott <alan@signal11.us>
To: Varka Bhadram <varkabhadram@gmail.com>,
linux-wpan@vger.kernel.org, linux-bluetooth@vger.kernel.org
Cc: Varka Bhadram <varkab@cdac.in>
Subject: Re: [PATCH bluetooth-next 3/3] ieee802154: mrf24j40: use pr_* / dev_*
Date: Fri, 19 Sep 2014 00:25:23 -0400 [thread overview]
Message-ID: <541BB033.6030603@signal11.us> (raw)
In-Reply-To: <541BA2AB.2030503@gmail.com>
On 09/18/2014 11:27 PM, Varka Bhadram wrote:
>>> @@ -482,12 +482,10 @@ static int mrf24j40_filter(struct
>>> ieee802154_dev *dev,
>>> for (i = 0; i < 8; i++)
>>> write_short_reg(devrec, REG_EADR0 + i, addr[i]);
>>> -#ifdef DEBUG
>>> - printk(KERN_DEBUG "Set long addr to: ");
>>> + pr_debug("Set long addr to: ");
>>> for (i = 0; i < 8; i++)
>>> - printk("%02hhx ", addr[7 - i]);
>>> - printk(KERN_DEBUG "\n");
>>> -#endif
>>> + pr_debug("%02hhx ", addr[7 - i]);
>>> + pr_debug("\n");
>>
>> Hmm... You took out the #ifdef DEBUG, but there's still a loop in
>> there that will execute (optimizer aside). The pr_debug is ok, but
>> leave it all inside the #ifdef DEBUG.
>>
> I think if we use the pr_debug(), no need to need put*#ifdef DEBUG*...?
>
> I didn't get your point here...
>
What I mean is, even though pr_debug() is taken out by the preprocessor
when DEBUG is not defined, the for-loop is not. Most likely, the empty
loop gets optimized out by the compiler, but either way it's better to
have the code be representative of what's going to execute. Therefore, I
think we should keep the #ifdef DEBUG.
Alan.
prev parent reply other threads:[~2014-09-19 4:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-16 4:48 [PATCH bluetooth-next 0/3] ieee802154: cleanup for mrf24j40 Varka Bhadram
2014-09-16 4:48 ` [PATCH bluetooth-next 1/3] ieee802154: mrf24j40: fix Missing a blank line after declarations Varka Bhadram
2014-09-18 22:54 ` Alan Ott
2014-09-19 3:22 ` Varka Bhadram
2014-09-16 4:48 ` [PATCH bluetooth-next 2/3] ieee802154: mrf24j40: remove return statement Varka Bhadram
2014-09-18 22:55 ` Alan Ott
2014-09-19 3:21 ` Varka Bhadram
2014-09-16 4:48 ` [PATCH bluetooth-next 3/3] ieee802154: mrf24j40: use pr_* / dev_* Varka Bhadram
2014-09-18 23:01 ` Alan Ott
[not found] ` <541BA2AB.2030503@gmail.com>
2014-09-19 4:25 ` Alan Ott [this message]
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=541BB033.6030603@signal11.us \
--to=alan@signal11.us \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-wpan@vger.kernel.org \
--cc=varkab@cdac.in \
--cc=varkabhadram@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.