All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Ben Greear <greearb@candelatech.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
	Michal Kazior <michal.kazior@tieto.com>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: [RFC 1/4] ath10k: provide firmware crash info via debugfs.
Date: Fri, 6 Jun 2014 09:13:09 +0300	[thread overview]
Message-ID: <87sinimuq2.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <53909175.30009@candelatech.com> (Ben Greear's message of "Thu, 5 Jun 2014 08:49:09 -0700")

Ben Greear <greearb@candelatech.com> writes:

>>>>> +/* This will store at least the last 128 entries. */
>>>>> +#define ATH10K_DBGLOG_DATA_LEN (128 * 7 * 4)
>>>>
>>>> Where does the 7 and 4 come from? Can't we use sizeof() to compute this?
>>>
>>> It is from the guts of how the firmware does debug logs.
>>>
>>> Each entry is a max of 7 32-bit integers in length.
>>>
>>>> The 128 should probably be a separate #define?
>>>
>>> I don't see why...
>> 
>> To make the code more readable.
>> 
>>> dbglog messages are variable number of 32-bit integers in length, so
>>> the 128 is fairly arbitrary.
>> 
>> A person should immeaditely understand where the numbers are coming from
>> and not start googling about it. The minimum is to put your description
>> above to the comment. And it would be clearer to replace 4 with
>> sizeof(u32).
>
> Would the comments I put in the PATCH 1/4 combined with the sizeof(4)
> be sufficient, or do you want actual defines?

What you wrote about should be enough, I think you can skip the defines
for now. Something like:

        /* Each entry is a max of 7 32-bit integers in length, let's choose
         * arbitrarily 128 entries */

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Ben Greear <greearb@candelatech.com>
Cc: Michal Kazior <michal.kazior@tieto.com>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: [RFC 1/4] ath10k: provide firmware crash info via debugfs.
Date: Fri, 6 Jun 2014 09:13:09 +0300	[thread overview]
Message-ID: <87sinimuq2.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <53909175.30009@candelatech.com> (Ben Greear's message of "Thu, 5 Jun 2014 08:49:09 -0700")

Ben Greear <greearb@candelatech.com> writes:

>>>>> +/* This will store at least the last 128 entries. */
>>>>> +#define ATH10K_DBGLOG_DATA_LEN (128 * 7 * 4)
>>>>
>>>> Where does the 7 and 4 come from? Can't we use sizeof() to compute this?
>>>
>>> It is from the guts of how the firmware does debug logs.
>>>
>>> Each entry is a max of 7 32-bit integers in length.
>>>
>>>> The 128 should probably be a separate #define?
>>>
>>> I don't see why...
>> 
>> To make the code more readable.
>> 
>>> dbglog messages are variable number of 32-bit integers in length, so
>>> the 128 is fairly arbitrary.
>> 
>> A person should immeaditely understand where the numbers are coming from
>> and not start googling about it. The minimum is to put your description
>> above to the comment. And it would be clearer to replace 4 with
>> sizeof(u32).
>
> Would the comments I put in the PATCH 1/4 combined with the sizeof(4)
> be sufficient, or do you want actual defines?

What you wrote about should be enough, I think you can skip the defines
for now. Something like:

        /* Each entry is a max of 7 32-bit integers in length, let's choose
         * arbitrarily 128 entries */

-- 
Kalle Valo

  reply	other threads:[~2014-06-06  6:19 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-03 16:25 [RFC 1/4] ath10k: provide firmware crash info via debugfs greearb
2014-06-03 16:25 ` greearb
2014-06-03 16:25 ` [RFC 2/4] ath10k: save firmware debug log messages greearb
2014-06-03 16:25   ` greearb
2014-06-03 16:45   ` Joe Perches
2014-06-03 16:45     ` Joe Perches
2014-06-03 16:49     ` Ben Greear
2014-06-03 16:49       ` Ben Greear
2014-06-03 16:25 ` [RFC 3/4] ath10k: save firmware stack upon firmware crash greearb
2014-06-03 16:25   ` greearb
2014-06-03 16:25 ` [RFC 4/4] ath10k: Dump exception stack contents on " greearb
2014-06-03 16:25   ` greearb
2014-06-04  9:04 ` [RFC 1/4] ath10k: provide firmware crash info via debugfs Michal Kazior
2014-06-04  9:04   ` Michal Kazior
2014-06-04 16:48   ` Ben Greear
2014-06-04 16:48     ` Ben Greear
2014-06-05 11:29     ` Kalle Valo
2014-06-05 11:29       ` Kalle Valo
2014-06-05 15:49       ` Ben Greear
2014-06-05 15:49         ` Ben Greear
2014-06-06  6:13         ` Kalle Valo [this message]
2014-06-06  6:13           ` Kalle Valo
2014-06-04 17:11   ` Ben Greear
2014-06-04 17:11     ` Ben Greear
2014-06-05 11:33   ` Kalle Valo
2014-06-05 11:33     ` Kalle Valo

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=87sinimuq2.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@qca.qualcomm.com \
    --cc=ath10k@lists.infradead.org \
    --cc=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=michal.kazior@tieto.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.