From: Luciano Coelho <coelho@ti.com>
To: Arik Nemtsov <arik@wizery.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH 10/10] wl12xx: export driver state to debugfs
Date: Fri, 29 Apr 2011 10:42:43 +0300 [thread overview]
Message-ID: <1304062963.12586.127.camel@cumari> (raw)
In-Reply-To: <BANLkTinyjnfvsag1=P72yQnrZARR5Pi37w@mail.gmail.com>
On Fri, 2011-04-29 at 08:03 +0300, Arik Nemtsov wrote:
> On Thu, Apr 28, 2011 at 16:21, Luciano Coelho <coelho@ti.com> wrote:
> > On Mon, 2011-04-18 at 14:15 +0300, Arik Nemtsov wrote:
> >> By reading the "driver_state" debugfs value we get all the important
> >> state information from the wl12xx driver. This helps testing and
> >> debugging, particularly in situations where the driver seems "stuck".
> >>
> >> Signed-off-by: Arik Nemtsov <arik@wizery.com>
> >> ---
> >> drivers/net/wireless/wl12xx/debugfs.c | 87 +++++++++++++++++++++++++++++++++
> >> 1 files changed, 87 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/net/wireless/wl12xx/debugfs.c b/drivers/net/wireless/wl12xx/debugfs.c
> >> index 6eb48b7..6970455 100644
> >> --- a/drivers/net/wireless/wl12xx/debugfs.c
> >> +++ b/drivers/net/wireless/wl12xx/debugfs.c
> >> @@ -310,6 +310,92 @@ static const struct file_operations start_recovery_ops = {
> >> .llseek = default_llseek,
> >> };
> >>
> >> +static ssize_t driver_state_read(struct file *file, char __user *user_buf,
> >> + size_t count, loff_t *ppos)
> >> +{
> >> + struct wl1271 *wl = file->private_data;
> >> + int res = 0;
> >> + char buf[1024];
> >> +
> >> + mutex_lock(&wl->mutex);
> >> +
> >> +#define DRIVER_STATE_PRINT(x, fmt) \
> >> + (res += scnprintf(buf + res, sizeof(buf) - res,\
> >> + #x " = " fmt "\n", wl->x))
> >> +
> >> +#define DRIVER_STATE_PRINT_LONG(x) DRIVER_STATE_PRINT(x, "%ld")
> >> +#define DRIVER_STATE_PRINT_INT(x) DRIVER_STATE_PRINT(x, "%d")
> >> +#define DRIVER_STATE_PRINT_STR(x) DRIVER_STATE_PRINT(x, "%s")
> >> +#define DRIVER_STATE_PRINT_LHEX(x) DRIVER_STATE_PRINT(x, "0x%lx")
> >> +#define DRIVER_STATE_PRINT_HEX(x) DRIVER_STATE_PRINT(x, "0x%x")
> >> +
> >> + DRIVER_STATE_PRINT_INT(tx_blocks_available);
> >> + DRIVER_STATE_PRINT_INT(tx_allocated_blocks);
> >> + DRIVER_STATE_PRINT_INT(tx_frames_cnt);
> >> + DRIVER_STATE_PRINT_LHEX(tx_frames_map[0]);
> >> + DRIVER_STATE_PRINT_INT(tx_queue_count);
> >> + DRIVER_STATE_PRINT_INT(tx_packets_count);
> >> + DRIVER_STATE_PRINT_INT(tx_results_count);
> >> + DRIVER_STATE_PRINT_LHEX(flags);
> >> + DRIVER_STATE_PRINT_INT(tx_blocks_freed[0]);
> >> + DRIVER_STATE_PRINT_INT(tx_blocks_freed[1]);
> >> + DRIVER_STATE_PRINT_INT(tx_blocks_freed[2]);
> >> + DRIVER_STATE_PRINT_INT(tx_blocks_freed[3]);
> >> + DRIVER_STATE_PRINT_INT(tx_security_last_seq);
> >> + DRIVER_STATE_PRINT_INT(rx_counter);
> >> + DRIVER_STATE_PRINT_INT(session_counter);
> >> + DRIVER_STATE_PRINT_INT(state);
> >> + DRIVER_STATE_PRINT_INT(bss_type);
> >> + DRIVER_STATE_PRINT_INT(channel);
> >> + DRIVER_STATE_PRINT_HEX(rate_set);
> >> + DRIVER_STATE_PRINT_HEX(basic_rate_set);
> >> + DRIVER_STATE_PRINT_HEX(basic_rate);
> >> + DRIVER_STATE_PRINT_INT(band);
> >> + DRIVER_STATE_PRINT_INT(beacon_int);
> >> + DRIVER_STATE_PRINT_INT(psm_entry_retry);
> >> + DRIVER_STATE_PRINT_INT(ps_poll_failures);
> >> + DRIVER_STATE_PRINT_HEX(filters);
> >> + DRIVER_STATE_PRINT_HEX(rx_config);
> >> + DRIVER_STATE_PRINT_HEX(rx_filter);
> >> + DRIVER_STATE_PRINT_INT(power_level);
> >> + DRIVER_STATE_PRINT_INT(rssi_thold);
> >> + DRIVER_STATE_PRINT_INT(last_rssi_event);
> >> + DRIVER_STATE_PRINT_INT(sg_enabled);
> >> + DRIVER_STATE_PRINT_INT(enable_11a);
> >> + DRIVER_STATE_PRINT_INT(noise);
> >> + DRIVER_STATE_PRINT_LHEX(ap_hlid_map[0]);
> >> + DRIVER_STATE_PRINT_INT(last_tx_hlid);
> >> + DRIVER_STATE_PRINT_INT(ba_support);
> >> + DRIVER_STATE_PRINT_HEX(ba_rx_bitmap);
> >> + DRIVER_STATE_PRINT_HEX(ap_fw_ps_map);
> >> + DRIVER_STATE_PRINT_LHEX(ap_ps_map);
> >> + DRIVER_STATE_PRINT_HEX(quirks);
> >> + DRIVER_STATE_PRINT_HEX(irq);
> >> + DRIVER_STATE_PRINT_HEX(ref_clock);
> >> + DRIVER_STATE_PRINT_HEX(tcxo_clock);
> >> + DRIVER_STATE_PRINT_HEX(hw_pg_ver);
> >> + DRIVER_STATE_PRINT_HEX(platform_quirks);
> >> + DRIVER_STATE_PRINT_HEX(chip.id);
> >> + DRIVER_STATE_PRINT_STR(chip.fw_ver_str);
> >
> > I'd prefer to have each of these values in separate files, like the FW
> > stats. If you print this all out in one file, it's hard to know which
> > value means what. With separate files it's easy to know and you can
> > achieve the same thing as having in one file by doing something like
> > this:
> >
> > cat driver_state/*
> >
>
> I think it's pretty easy to understand what means what. The print
> looks like this:
>
> power_level = 0
> rssi_thold = 0
> last_rssi_event = 0
> sg_enabled = 1
> enable_11a = 1
> noise = 31
True, I missed the part where you print the var names too.
> As for making separate files - I think its preferable if people don't
> have an option to print only parts of the state. This can help bug
> reports by non-developers by giving a fuller picture.
> Perhaps we can add separate files in another patch later on?
Yeah, it's okay for now. This just came to my mind, because IIRC when
we added the fw stats, there was some recommendation somewhere saying
that debugfs entries should contain only values (not name-value pairs)
and should be done as a single value per file.
But I guess this is true for sysfs and not for debugfs. At least
according to Documentation/filesystems/debugfs.txt:
"[...]Unlike /proc, which is only meant for information about a process,
or sysfs, which has strict one-value-per-file rules, debugfs has no
rules at all. Developers can put any information they want there."
So, fine, I'll take this patch. ;)
--
Cheers,
Luca.
next prev parent reply other threads:[~2011-04-29 7:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-18 11:15 [PATCH 01/10] wl12xx: add BT-coexistance for AP Arik Nemtsov
2011-04-18 11:15 ` [PATCH 02/10] wl12xx: use wiphy values for setting rts, frag thresholds on init Arik Nemtsov
2011-04-18 11:15 ` [PATCH 03/10] wl12xx: AP-mode - disable beacon filtering on start up Arik Nemtsov
2011-04-18 11:15 ` [PATCH 04/10] wl12xx: schedule recovery on command timeout Arik Nemtsov
2011-04-18 11:15 ` [PATCH 05/10] wl12xx: print firmware program counter during recovery Arik Nemtsov
2011-04-18 11:15 ` [PATCH 06/10] wl12xx: AP-mode - overhaul rate policy configuration Arik Nemtsov
2011-04-18 11:15 ` [PATCH 07/10] wl12xx: AP-mode - reconfigure templates after basic rates change Arik Nemtsov
2011-04-18 11:15 ` [PATCH 08/10] wl12xx: add debugfs entry for starting recovery Arik Nemtsov
2011-04-18 11:15 ` [PATCH 09/10] wl12xx: fix race condition during recovery in AP mode Arik Nemtsov
2011-04-18 11:15 ` [PATCH 10/10] wl12xx: export driver state to debugfs Arik Nemtsov
2011-04-28 13:21 ` Luciano Coelho
2011-04-29 5:03 ` Arik Nemtsov
2011-04-29 7:42 ` Luciano Coelho [this message]
2011-04-29 20:02 ` [PATCH 01/10] wl12xx: add BT-coexistance for AP Luciano Coelho
2011-04-29 21:17 ` Luciano Coelho
2011-05-02 8:18 ` Luciano Coelho
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=1304062963.12586.127.camel@cumari \
--to=coelho@ti.com \
--cc=arik@wizery.com \
--cc=linux-wireless@vger.kernel.org \
/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