All of lore.kernel.org
 help / color / mirror / Atom feed
From: merez@codeaurora.org
To: Kalle Valo <kvalo@codeaurora.org>
Cc: "Haim, Maya" <merez@qti.qualcomm.com>,
	Joe Perches <joe@perches.com>,
	qca_merez <qca_merez@qca.qualcomm.com>,
	linux-wireless@vger.kernel.org,
	wil6210 <wil6210@qca.qualcomm.com>,
	linux-wireless-owner@vger.kernel.org
Subject: Re: [PATCH 1/7] wil6210: add function name to wil log macros
Date: Mon, 25 Apr 2016 12:08:38 +0300	[thread overview]
Message-ID: <f30cd2af1235f2ec95bbefe22c7639f8@codeaurora.org> (raw)
In-Reply-To: <8760vjqco7.fsf@kamboji.qca.qualcomm.com>

:כתב Kalle Valo, 2016-04-15 15:28 בתאריך
> "Haim, Maya" <merez@qti.qualcomm.com> writes:
> 
>> On 4/7/2016 6:41 PM, Kalle Valo wrote:
>>> "Haim, Maya" <merez@qti.qualcomm.com> writes:
>>> 
>>>> On 4/6/2016 10:19 AM, Joe Perches wrote:
>>>>> On Tue, 2016-04-05 at 14:24 +0300, Maya Erez wrote:
>>>>>> Add __func__ to all wil log macros for easier debugging.
>>>>> I think this is unnecessary and merely bloats code size.
>>>>> For all the _dbg calls, dynamic debug can add function names if
>>>>> desired.
>>>>> 
>>>>> If really desired, I suggest changing the logging functions to use
>>>>> "%ps and __builtin_return_address(0)
>>>> I implemented it with __builtin_return_address(0) at first but found
>>>> its format less readable (e.g. wil_start_xmit+0x58/0x7e8).
>>> Will that work with inline functions and with functions which the
>>> compiler has optimised out?
>> 
>> That's a good point. I did a quick check and it doesn't work for
>> inline or static functions - for such functions, the name of the
>> calling function is printed.
> 
> Thanks for checking.
> 
>> We can either (1) use my initial implementation (2) add __func__ only
>> to the wil_dbg_... macros or (3) revert this patch completely. I find
>> the addition of the function names very useful and since most of the
>> code doesn't include it, it makes the analysis of issues less
>> efficient. Kalle - what is your say on that?
> 
> I don't have any preference, it's up to you what you like most.
> 
> One more possibility: in ath10k we have a kconfig option
> CONFIG_ATH10K_DEBUG to make it possible to disable all overhead from
> debug functionality, that would at least solve Joe's concern of extra
> memory usage.

I looked a bit more on the different options.
For the dbg functions, the function name can be added as part of the
dynamic debug options (as mentioned by Joe). Therefore I will remove
the addition of __func__ from those macros.
The dynamic debug also guarantees zero overhead so I don't see the need
for an additional debug config flag (such as CONFIG_ATH10K_DEBUG).
As for wil_err and wil_info, I believe we can add the __func__ to them,
as wil_info is not commonly used in our code.

  reply	other threads:[~2016-04-25  9:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-05 11:24 [PATCH 0/7] wil6210 patches Maya Erez
2016-04-05 11:24 ` [PATCH 1/7] wil6210: add function name to wil log macros Maya Erez
2016-04-06  7:19   ` Joe Perches
2016-04-07 15:04     ` Haim, Maya
2016-04-07 15:41       ` Kalle Valo
2016-04-12  7:45         ` Haim, Maya
2016-04-15 12:28           ` Kalle Valo
2016-04-25  9:08             ` merez [this message]
2016-04-07 16:05       ` Joe Perches
2016-04-05 11:24 ` [PATCH 2/7] wil6210: support regular scan on P2P_DEVICE interface Maya Erez
2016-04-05 11:24 ` [PATCH 3/7] wil6210: change RX_HTRSH interrupt print level to debug Maya Erez
2016-04-05 11:24 ` [PATCH 4/7] wil6210: print debug message when transmitting while disconnected Maya Erez
2016-04-06  7:22   ` Joe Perches
2016-04-10 19:17     ` qca_merez
2016-04-11  2:30       ` Joe Perches
2016-04-25 13:30         ` merez
2016-04-05 11:24 ` [PATCH 5/7] wil6210: unmask RX_HTRSH interrupt only when connected Maya Erez
2016-04-05 11:24 ` [PATCH 6/7] wil6210: prevent deep sleep of 60G device in critical paths Maya Erez
2016-04-05 11:24 ` [PATCH 7/7] wil6210: add support for device led configuration Maya Erez

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=f30cd2af1235f2ec95bbefe22c7639f8@codeaurora.org \
    --to=merez@codeaurora.org \
    --cc=joe@perches.com \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless-owner@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=merez@qti.qualcomm.com \
    --cc=qca_merez@qca.qualcomm.com \
    --cc=wil6210@qca.qualcomm.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.