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
next prev parent 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.