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: Thu, 5 Jun 2014 14:29:29 +0300 [thread overview]
Message-ID: <8738fjppba.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <538F4DEE.6040405@candelatech.com> (Ben Greear's message of "Wed, 04 Jun 2014 09:48:46 -0700")
Ben Greear <greearb@candelatech.com> writes:
> On 06/04/2014 02:04 AM, Michal Kazior wrote:
>> On 3 June 2014 18:25, <greearb@candelatech.com> wrote:
>>
>>> --- a/drivers/net/wireless/ath/ath10k/core.h
>>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>>> @@ -41,6 +41,8 @@
>>> #define ATH10K_FLUSH_TIMEOUT_HZ (5*HZ)
>>> #define ATH10K_NUM_CHANS 38
>>>
>>> +#define REG_DUMP_COUNT_QCA988X 60 /* from pci.h */
>>
>> I don't like this.
Me neither.
> You want me to make a different define for this that duplicates
> the '60' value? At least with my method above, we should get compile
> errors if the values ever diverge in the two files.
There should be only one define. Somewhere (forgot where) Michal
suggested hw.h, I think this define would be a good candidate to move
there too.
>>> +struct ath10k_tlv_dump_data {
>>> + u32 type; /* see ath10k_fw_error_dump_type above */
>>> + u32 tlv_len; /* in bytes */
>>> + u8 tlv_data[]; /* Pad to 32-bit boundaries as needed. */
>>> +} __packed;
>>> +
>>> +struct ath10k_dump_file_data {
>>> + u32 len;
>>> + u32 magic; /* 0x01020304, tells us byte-order of host if we care */
>>> + struct ath10k_tlv_dump_data data; /* more may follow */
>>> +} __packed;
>>> +
>>> +/* 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).
--
Kalle Valo
next prev parent reply other threads:[~2014-06-05 11:29 UTC|newest]
Thread overview: 13+ 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 ` [RFC 2/4] ath10k: save firmware debug log messages greearb
2014-06-03 16:45 ` Joe Perches
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 ` [RFC 4/4] ath10k: Dump exception stack contents on " greearb
2014-06-04 9:04 ` [RFC 1/4] ath10k: provide firmware crash info via debugfs Michal Kazior
2014-06-04 16:48 ` Ben Greear
2014-06-05 11:29 ` Kalle Valo [this message]
2014-06-05 15:49 ` Ben Greear
2014-06-06 6:13 ` Kalle Valo
2014-06-04 17:11 ` Ben Greear
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=8738fjppba.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 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).