* [PATCH v2 00/21] ath10k patches, generic and CT firmware related.
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
These are against wireless-testing from a few days ago.
Here are a bunch of ath10k patches. First one is a crash
fix. Next few are at least somewhat useful for generic
firmware, and more useful for CT firmware. Much of it is related
to better debugging of firmware crashes. If this can go in, then
I can much better handle random bug reports from prople using
stock kernels and CT firmware. With some small tweaks to how they
package firmware, QCA could benefit as well.
The last bit is some initial support for CT firmware. I figure it
is a long-shot, but it would surely be nice to get this (and more!)
upstream. If nothing else, these can be a basis for potential
inclusion in openwrt or similar.
These patches are not overly dependent on each other for the most
part, so even if a few are not acceptable, maybe others can be
applied upstream.
Changes from v1:
Replace debug-mask patch to be one that allows changing mask using
debugfs.
Add some comments to the CT firmware placeholder patch as requested.
Add and tweak comments related to cycle counters.
Ben Greear (21):
ath10k: Fix crash related to printing features.
ath10k: fix typo in logging message
ath10k: Allow changing ath10k debug mask at runtime.
ath10k: rate-limit packet tx errors
ath10k: save firmware debug log messages.
ath10k: save firmware stacks upon firmware crash
ath10k: save firmware RAM and ROM BSS sections on crash
ath10k: make firmware text debug messages more verbose.
ath10k: print fw debug messages in hex.
ath10k: support logging ath10k_info as KERN_DEBUG
ath10k: add fw-powerup-fail to ethtool stats.
ath10k: Support up to 64 vdevs.
ath10k: Document cycle count related counters.
ath10k: Add tx/rx bytes, cycle counters to ethtool stats.
ath10k: support CT firmware flag.
ath10k: Support 32+ stations.
ath10k: Enable detecting failure to install key in firmware (CT).
ath10k: Note limitation on beaconing vdevs.
ath10k: Enable adhoc mode for CT firmware.
ath10k: read firmware crash over ioread32 if CE fails.
ath10k: Read dbglog buffers over register ping-pong.
drivers/net/wireless/ath/ath10k/core.c | 70 ++++++-
drivers/net/wireless/ath/ath10k/core.h | 52 ++++-
drivers/net/wireless/ath/ath10k/debug.c | 325 ++++++++++++++++++++++++++++++-
drivers/net/wireless/ath/ath10k/debug.h | 17 ++
drivers/net/wireless/ath/ath10k/htt.h | 7 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 23 ++-
drivers/net/wireless/ath/ath10k/htt_tx.c | 22 ++-
drivers/net/wireless/ath/ath10k/hw.h | 36 ++++
drivers/net/wireless/ath/ath10k/mac.c | 74 ++++++-
drivers/net/wireless/ath/ath10k/pci.c | 310 ++++++++++++++++++++++++++++-
drivers/net/wireless/ath/ath10k/wmi.c | 43 +++-
drivers/net/wireless/ath/ath10k/wmi.h | 14 +-
12 files changed, 956 insertions(+), 37 deletions(-)
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* [PATCH v2 01/21] ath10k: Fix crash related to printing features.
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
This looks like a regression from
c4cdf753 (move fw_features to struct ath10k_fw_file)
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index e94cb87..b7318b8 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1078,7 +1078,7 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, const char *name,
}
ath10k_dbg_dump(ar, ATH10K_DBG_BOOT, "features", "",
- ar->running_fw->fw_file.fw_features,
+ fw_file->fw_features,
sizeof(fw_file->fw_features));
break;
case ATH10K_FW_IE_FW_IMAGE:
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread
* [PATCH v2 01/21] ath10k: Fix crash related to printing features.
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
This looks like a regression from
c4cdf753 (move fw_features to struct ath10k_fw_file)
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index e94cb87..b7318b8 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1078,7 +1078,7 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, const char *name,
}
ath10k_dbg_dump(ar, ATH10K_DBG_BOOT, "features", "",
- ar->running_fw->fw_file.fw_features,
+ fw_file->fw_features,
sizeof(fw_file->fw_features));
break;
case ATH10K_FW_IE_FW_IMAGE:
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread
* Re: [v2,01/21] ath10k: Fix crash related to printing features.
2016-05-11 17:02 ` greearb
@ 2016-06-07 11:38 ` Kalle Valo
-1 siblings, 0 replies; 118+ messages in thread
From: Kalle Valo @ 2016-06-07 11:38 UTC (permalink / raw)
To: Ben Greear; +Cc: ath10k, Ben Greear, linux-wireless
Ben Greear <greearb@candelatech.com> wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> This looks like a regression from
> c4cdf753 (move fw_features to struct ath10k_fw_file)
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
Thanks, 1 patch applied to ath-current branch of ath.git:
8d0a0710ea0d ath10k: fix crash related to printing features
--
Sent by pwcli
https://patchwork.kernel.org/patch/9073471/
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 01/21] ath10k: Fix crash related to printing features.
2016-05-11 17:02 ` greearb
@ 2016-06-20 20:49 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-06-20 20:49 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
On 05/11/2016 10:02 AM, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> This looks like a regression from
> c4cdf753 (move fw_features to struct ath10k_fw_file)
Just FYI, this patch does not appear to be in 4.7-rc4 as of today, and so kernel crashes on
startup when loading ath10k, at least when DBG_BOOT logging is enabled....
Thanks,
Ben
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> index e94cb87..b7318b8 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -1078,7 +1078,7 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, const char *name,
> }
>
> ath10k_dbg_dump(ar, ATH10K_DBG_BOOT, "features", "",
> - ar->running_fw->fw_file.fw_features,
> + fw_file->fw_features,
> sizeof(fw_file->fw_features));
> break;
> case ATH10K_FW_IE_FW_IMAGE:
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 01/21] ath10k: Fix crash related to printing features.
@ 2016-06-20 20:49 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-06-20 20:49 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
On 05/11/2016 10:02 AM, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> This looks like a regression from
> c4cdf753 (move fw_features to struct ath10k_fw_file)
Just FYI, this patch does not appear to be in 4.7-rc4 as of today, and so kernel crashes on
startup when loading ath10k, at least when DBG_BOOT logging is enabled....
Thanks,
Ben
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> index e94cb87..b7318b8 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -1078,7 +1078,7 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, const char *name,
> }
>
> ath10k_dbg_dump(ar, ATH10K_DBG_BOOT, "features", "",
> - ar->running_fw->fw_file.fw_features,
> + fw_file->fw_features,
> sizeof(fw_file->fw_features));
> break;
> case ATH10K_FW_IE_FW_IMAGE:
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 01/21] ath10k: Fix crash related to printing features.
2016-06-20 20:49 ` Ben Greear
@ 2016-06-20 21:56 ` Valo, Kalle
-1 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-06-20 21:56 UTC (permalink / raw)
To: Ben Greear; +Cc: ath10k, linux-wireless
Ben Greear <greearb@candelatech.com> writes:
> On 05/11/2016 10:02 AM, greearb@candelatech.com wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> This looks like a regression from
>> c4cdf753 (move fw_features to struct ath10k_fw_file)
>
> Just FYI, this patch does not appear to be in 4.7-rc4 as of today, and
> so kernel crashes on startup when loading ath10k, at least when
> DBG_BOOT logging is enabled....
The fix is wireless-drivers.git now, I'm planning to send a pull request
to Dave tomorrow.
--
Kalle Valo
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 01/21] ath10k: Fix crash related to printing features.
@ 2016-06-20 21:56 ` Valo, Kalle
0 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-06-20 21:56 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k
Ben Greear <greearb@candelatech.com> writes:
> On 05/11/2016 10:02 AM, greearb@candelatech.com wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> This looks like a regression from
>> c4cdf753 (move fw_features to struct ath10k_fw_file)
>
> Just FYI, this patch does not appear to be in 4.7-rc4 as of today, and
> so kernel crashes on startup when loading ath10k, at least when
> DBG_BOOT logging is enabled....
The fix is wireless-drivers.git now, I'm planning to send a pull request
to Dave tomorrow.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* [PATCH v2 02/21] ath10k: fix typo in logging message
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 0e24f9e..cd3016d 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2747,7 +2747,7 @@ static void ath10k_bss_disassoc(struct ieee80211_hw *hw,
ret = ath10k_wmi_vdev_down(ar, arvif->vdev_id);
if (ret)
- ath10k_warn(ar, "faield to down vdev %i: %d\n",
+ ath10k_warn(ar, "failed to down vdev %i: %d\n",
arvif->vdev_id, ret);
arvif->def_wep_key_idx = -1;
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread
* [PATCH v2 02/21] ath10k: fix typo in logging message
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 0e24f9e..cd3016d 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2747,7 +2747,7 @@ static void ath10k_bss_disassoc(struct ieee80211_hw *hw,
ret = ath10k_wmi_vdev_down(ar, arvif->vdev_id);
if (ret)
- ath10k_warn(ar, "faield to down vdev %i: %d\n",
+ ath10k_warn(ar, "failed to down vdev %i: %d\n",
arvif->vdev_id, ret);
arvif->def_wep_key_idx = -1;
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread
* Re: [v2,02/21] ath10k: fix typo in logging message
2016-05-11 17:02 ` greearb
@ 2016-09-27 12:19 ` Kalle Valo
-1 siblings, 0 replies; 118+ messages in thread
From: Kalle Valo @ 2016-09-27 12:19 UTC (permalink / raw)
To: Ben Greear; +Cc: ath10k, Ben Greear, linux-wireless
Ben Greear <greearb@candelatech.com> wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
3 patches applied to ath-next branch of ath.git, thanks.
aa66ba0c31c6 ath10k: fix typo in logging message
15138fdf327d ath10k: document cycle count related counters
30d2049b3277 ath10k: support up to 64 vdevs
--
https://patchwork.kernel.org/patch/9073591/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 118+ messages in thread
* [PATCH v2 03/21] ath10k: Allow changing ath10k debug mask at runtime.
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
Using debugfs. More convenient than module options
in some cases.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/debug.c | 62 +++++++++++++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index e251155..d552a4a 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -870,6 +870,65 @@ static const struct file_operations fops_reg_addr = {
.llseek = default_llseek,
};
+static ssize_t ath10k_read_debug_level(struct file *file,
+ char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ int sz;
+ const char buf[] =
+ "To change debug level, set value adding up desired flags:\n"
+ "PCI: 0x1\n"
+ "WMI: 0x2\n"
+ "HTC: 0x4\n"
+ "HTT: 0x8\n"
+ "MAC: 0x10\n"
+ "BOOT: 0x20\n"
+ "PCI-DUMP: 0x40\n"
+ "HTT-DUMP: 0x80\n"
+ "MGMT: 0x100\n"
+ "DATA: 0x200\n"
+ "BMI: 0x400\n"
+ "REGULATORY: 0x800\n"
+ "TESTMODE: 0x1000\n"
+ "INFO-AS-DBG: 0x40000000\n"
+ "FW: 0x80000000\n"
+ "ALL: 0xFFFFFFFF\n";
+ char wbuf[sizeof(buf) + 60];
+ sz = snprintf(wbuf, sizeof(wbuf), "Current debug level: 0x%x\n\n%s",
+ ath10k_debug_mask, buf);
+ wbuf[sizeof(wbuf) - 1] = 0;
+
+ return simple_read_from_buffer(user_buf, count, ppos, wbuf, sz);
+}
+
+/* Set logging level.
+ */
+static ssize_t ath10k_write_debug_level(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ int ret;
+ unsigned long mask;
+
+ ret = kstrtoul_from_user(user_buf, count, 0, &mask);
+ if (ret)
+ return ret;
+
+ ath10k_warn(ar, "Setting debug-mask to: 0x%lx old: 0x%x\n",
+ mask, ath10k_debug_mask);
+ ath10k_debug_mask = mask;
+ return count;
+}
+
+static const struct file_operations fops_debug_level = {
+ .read = ath10k_read_debug_level,
+ .write = ath10k_write_debug_level,
+ .open = simple_open,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
+
static ssize_t ath10k_reg_value_read(struct file *file,
char __user *user_buf,
size_t count, loff_t *ppos)
@@ -2375,6 +2434,9 @@ int ath10k_debug_register(struct ath10k *ar)
debugfs_create_file("mem_value", S_IRUSR | S_IWUSR,
ar->debug.debugfs_phy, ar, &fops_mem_value);
+ debugfs_create_file("debug_level", S_IRUSR, ar->debug.debugfs_phy,
+ ar, &fops_debug_level);
+
debugfs_create_file("chip_id", S_IRUSR, ar->debug.debugfs_phy,
ar, &fops_chip_id);
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 03/21] ath10k: Allow changing ath10k debug mask at runtime.
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
Using debugfs. More convenient than module options
in some cases.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/debug.c | 62 +++++++++++++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index e251155..d552a4a 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -870,6 +870,65 @@ static const struct file_operations fops_reg_addr = {
.llseek = default_llseek,
};
+static ssize_t ath10k_read_debug_level(struct file *file,
+ char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ int sz;
+ const char buf[] =
+ "To change debug level, set value adding up desired flags:\n"
+ "PCI: 0x1\n"
+ "WMI: 0x2\n"
+ "HTC: 0x4\n"
+ "HTT: 0x8\n"
+ "MAC: 0x10\n"
+ "BOOT: 0x20\n"
+ "PCI-DUMP: 0x40\n"
+ "HTT-DUMP: 0x80\n"
+ "MGMT: 0x100\n"
+ "DATA: 0x200\n"
+ "BMI: 0x400\n"
+ "REGULATORY: 0x800\n"
+ "TESTMODE: 0x1000\n"
+ "INFO-AS-DBG: 0x40000000\n"
+ "FW: 0x80000000\n"
+ "ALL: 0xFFFFFFFF\n";
+ char wbuf[sizeof(buf) + 60];
+ sz = snprintf(wbuf, sizeof(wbuf), "Current debug level: 0x%x\n\n%s",
+ ath10k_debug_mask, buf);
+ wbuf[sizeof(wbuf) - 1] = 0;
+
+ return simple_read_from_buffer(user_buf, count, ppos, wbuf, sz);
+}
+
+/* Set logging level.
+ */
+static ssize_t ath10k_write_debug_level(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ int ret;
+ unsigned long mask;
+
+ ret = kstrtoul_from_user(user_buf, count, 0, &mask);
+ if (ret)
+ return ret;
+
+ ath10k_warn(ar, "Setting debug-mask to: 0x%lx old: 0x%x\n",
+ mask, ath10k_debug_mask);
+ ath10k_debug_mask = mask;
+ return count;
+}
+
+static const struct file_operations fops_debug_level = {
+ .read = ath10k_read_debug_level,
+ .write = ath10k_write_debug_level,
+ .open = simple_open,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
+
static ssize_t ath10k_reg_value_read(struct file *file,
char __user *user_buf,
size_t count, loff_t *ppos)
@@ -2375,6 +2434,9 @@ int ath10k_debug_register(struct ath10k *ar)
debugfs_create_file("mem_value", S_IRUSR | S_IWUSR,
ar->debug.debugfs_phy, ar, &fops_mem_value);
+ debugfs_create_file("debug_level", S_IRUSR, ar->debug.debugfs_phy,
+ ar, &fops_debug_level);
+
debugfs_create_file("chip_id", S_IRUSR, ar->debug.debugfs_phy,
ar, &fops_chip_id);
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread* Re: [PATCH v2 03/21] ath10k: Allow changing ath10k debug mask at runtime.
2016-05-11 17:02 ` greearb
@ 2016-09-14 14:06 ` Valo, Kalle
-1 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 14:06 UTC (permalink / raw)
To: greearb; +Cc: ath10k, linux-wireless
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> Using debugfs. More convenient than module options
> in some cases.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/debug.c | 62 +++++++++++++++++++++++++++=
++++++
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wirele=
ss/ath/ath10k/debug.c
> index e251155..d552a4a 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -870,6 +870,65 @@ static const struct file_operations fops_reg_addr =
=3D {
> .llseek =3D default_llseek,
> };
> =20
> +static ssize_t ath10k_read_debug_level(struct file *file,
> + char __user *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + int sz;
> + const char buf[] =3D
> + "To change debug level, set value adding up desired flags:\n"
> + "PCI: 0x1\n"
> + "WMI: 0x2\n"
> + "HTC: 0x4\n"
> + "HTT: 0x8\n"
> + "MAC: 0x10\n"
> + "BOOT: 0x20\n"
> + "PCI-DUMP: 0x40\n"
> + "HTT-DUMP: 0x80\n"
> + "MGMT: 0x100\n"
> + "DATA: 0x200\n"
> + "BMI: 0x400\n"
> + "REGULATORY: 0x800\n"
> + "TESTMODE: 0x1000\n"
> + "INFO-AS-DBG: 0x40000000\n"
> + "FW: 0x80000000\n"
> + "ALL: 0xFFFFFFFF\n";
> + char wbuf[sizeof(buf) + 60];
> + sz =3D snprintf(wbuf, sizeof(wbuf), "Current debug level: 0x%x\n\n%s",
> + ath10k_debug_mask, buf);
> + wbuf[sizeof(wbuf) - 1] =3D 0;
> +
> + return simple_read_from_buffer(user_buf, count, ppos, wbuf, sz);
> +}
> +
> +/* Set logging level.
> + */
> +static ssize_t ath10k_write_debug_level(struct file *file,
> + const char __user *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + struct ath10k *ar =3D file->private_data;
> + int ret;
> + unsigned long mask;
> +
> + ret =3D kstrtoul_from_user(user_buf, count, 0, &mask);
> + if (ret)
> + return ret;
> +
> + ath10k_warn(ar, "Setting debug-mask to: 0x%lx old: 0x%x\n",
> + mask, ath10k_debug_mask);
> + ath10k_debug_mask =3D mask;
> + return count;
> +}
There are already sysfs files for module parameters which seems to work
just fine for this case:
# echo 0xffffffff > /sys/module/ath10k_core/parameters/debug_mask
--=20
Kalle Valo=
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 03/21] ath10k: Allow changing ath10k debug mask at runtime.
@ 2016-09-14 14:06 ` Valo, Kalle
0 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 14:06 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath10k
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> Using debugfs. More convenient than module options
> in some cases.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/debug.c | 62 +++++++++++++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> index e251155..d552a4a 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -870,6 +870,65 @@ static const struct file_operations fops_reg_addr = {
> .llseek = default_llseek,
> };
>
> +static ssize_t ath10k_read_debug_level(struct file *file,
> + char __user *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + int sz;
> + const char buf[] =
> + "To change debug level, set value adding up desired flags:\n"
> + "PCI: 0x1\n"
> + "WMI: 0x2\n"
> + "HTC: 0x4\n"
> + "HTT: 0x8\n"
> + "MAC: 0x10\n"
> + "BOOT: 0x20\n"
> + "PCI-DUMP: 0x40\n"
> + "HTT-DUMP: 0x80\n"
> + "MGMT: 0x100\n"
> + "DATA: 0x200\n"
> + "BMI: 0x400\n"
> + "REGULATORY: 0x800\n"
> + "TESTMODE: 0x1000\n"
> + "INFO-AS-DBG: 0x40000000\n"
> + "FW: 0x80000000\n"
> + "ALL: 0xFFFFFFFF\n";
> + char wbuf[sizeof(buf) + 60];
> + sz = snprintf(wbuf, sizeof(wbuf), "Current debug level: 0x%x\n\n%s",
> + ath10k_debug_mask, buf);
> + wbuf[sizeof(wbuf) - 1] = 0;
> +
> + return simple_read_from_buffer(user_buf, count, ppos, wbuf, sz);
> +}
> +
> +/* Set logging level.
> + */
> +static ssize_t ath10k_write_debug_level(struct file *file,
> + const char __user *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + struct ath10k *ar = file->private_data;
> + int ret;
> + unsigned long mask;
> +
> + ret = kstrtoul_from_user(user_buf, count, 0, &mask);
> + if (ret)
> + return ret;
> +
> + ath10k_warn(ar, "Setting debug-mask to: 0x%lx old: 0x%x\n",
> + mask, ath10k_debug_mask);
> + ath10k_debug_mask = mask;
> + return count;
> +}
There are already sysfs files for module parameters which seems to work
just fine for this case:
# echo 0xffffffff > /sys/module/ath10k_core/parameters/debug_mask
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 03/21] ath10k: Allow changing ath10k debug mask at runtime.
2016-09-14 14:06 ` Valo, Kalle
@ 2016-09-14 15:33 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-14 15:33 UTC (permalink / raw)
To: Valo, Kalle; +Cc: ath10k, linux-wireless
On 09/14/2016 07:06 AM, Valo, Kalle wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> Using debugfs. More convenient than module options
>> in some cases.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>> ---
>> drivers/net/wireless/ath/ath10k/debug.c | 62 +++++++++++++++++++++++++++++++++
>> 1 file changed, 62 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
>> index e251155..d552a4a 100644
>> --- a/drivers/net/wireless/ath/ath10k/debug.c
>> +++ b/drivers/net/wireless/ath/ath10k/debug.c
>> @@ -870,6 +870,65 @@ static const struct file_operations fops_reg_addr = {
>> .llseek = default_llseek,
>> };
>>
>> +static ssize_t ath10k_read_debug_level(struct file *file,
>> + char __user *user_buf,
>> + size_t count, loff_t *ppos)
>> +{
>> + int sz;
>> + const char buf[] =
>> + "To change debug level, set value adding up desired flags:\n"
>> + "PCI: 0x1\n"
>> + "WMI: 0x2\n"
>> + "HTC: 0x4\n"
>> + "HTT: 0x8\n"
>> + "MAC: 0x10\n"
>> + "BOOT: 0x20\n"
>> + "PCI-DUMP: 0x40\n"
>> + "HTT-DUMP: 0x80\n"
>> + "MGMT: 0x100\n"
>> + "DATA: 0x200\n"
>> + "BMI: 0x400\n"
>> + "REGULATORY: 0x800\n"
>> + "TESTMODE: 0x1000\n"
>> + "INFO-AS-DBG: 0x40000000\n"
>> + "FW: 0x80000000\n"
>> + "ALL: 0xFFFFFFFF\n";
>> + char wbuf[sizeof(buf) + 60];
>> + sz = snprintf(wbuf, sizeof(wbuf), "Current debug level: 0x%x\n\n%s",
>> + ath10k_debug_mask, buf);
>> + wbuf[sizeof(wbuf) - 1] = 0;
>> +
>> + return simple_read_from_buffer(user_buf, count, ppos, wbuf, sz);
>> +}
>> +
>> +/* Set logging level.
>> + */
>> +static ssize_t ath10k_write_debug_level(struct file *file,
>> + const char __user *user_buf,
>> + size_t count, loff_t *ppos)
>> +{
>> + struct ath10k *ar = file->private_data;
>> + int ret;
>> + unsigned long mask;
>> +
>> + ret = kstrtoul_from_user(user_buf, count, 0, &mask);
>> + if (ret)
>> + return ret;
>> +
>> + ath10k_warn(ar, "Setting debug-mask to: 0x%lx old: 0x%x\n",
>> + mask, ath10k_debug_mask);
>> + ath10k_debug_mask = mask;
>> + return count;
>> +}
>
> There are already sysfs files for module parameters which seems to work
> just fine for this case:
>
> # echo 0xffffffff > /sys/module/ath10k_core/parameters/debug_mask
Ok, but it is still nice to have the printout info of what log levels
means. Otherwise, you have to go look at firmware source to even know how
to enable the proper flags. And as these flags are internal and might change,
we could change the printout text to match the specific kernel that is running.
In my opinion, this is a 'nice-to-have', not required, if sysfs works,
so I will also test the sysfs suggestion above.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 03/21] ath10k: Allow changing ath10k debug mask at runtime.
@ 2016-09-14 15:33 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-14 15:33 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/14/2016 07:06 AM, Valo, Kalle wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> Using debugfs. More convenient than module options
>> in some cases.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>> ---
>> drivers/net/wireless/ath/ath10k/debug.c | 62 +++++++++++++++++++++++++++++++++
>> 1 file changed, 62 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
>> index e251155..d552a4a 100644
>> --- a/drivers/net/wireless/ath/ath10k/debug.c
>> +++ b/drivers/net/wireless/ath/ath10k/debug.c
>> @@ -870,6 +870,65 @@ static const struct file_operations fops_reg_addr = {
>> .llseek = default_llseek,
>> };
>>
>> +static ssize_t ath10k_read_debug_level(struct file *file,
>> + char __user *user_buf,
>> + size_t count, loff_t *ppos)
>> +{
>> + int sz;
>> + const char buf[] =
>> + "To change debug level, set value adding up desired flags:\n"
>> + "PCI: 0x1\n"
>> + "WMI: 0x2\n"
>> + "HTC: 0x4\n"
>> + "HTT: 0x8\n"
>> + "MAC: 0x10\n"
>> + "BOOT: 0x20\n"
>> + "PCI-DUMP: 0x40\n"
>> + "HTT-DUMP: 0x80\n"
>> + "MGMT: 0x100\n"
>> + "DATA: 0x200\n"
>> + "BMI: 0x400\n"
>> + "REGULATORY: 0x800\n"
>> + "TESTMODE: 0x1000\n"
>> + "INFO-AS-DBG: 0x40000000\n"
>> + "FW: 0x80000000\n"
>> + "ALL: 0xFFFFFFFF\n";
>> + char wbuf[sizeof(buf) + 60];
>> + sz = snprintf(wbuf, sizeof(wbuf), "Current debug level: 0x%x\n\n%s",
>> + ath10k_debug_mask, buf);
>> + wbuf[sizeof(wbuf) - 1] = 0;
>> +
>> + return simple_read_from_buffer(user_buf, count, ppos, wbuf, sz);
>> +}
>> +
>> +/* Set logging level.
>> + */
>> +static ssize_t ath10k_write_debug_level(struct file *file,
>> + const char __user *user_buf,
>> + size_t count, loff_t *ppos)
>> +{
>> + struct ath10k *ar = file->private_data;
>> + int ret;
>> + unsigned long mask;
>> +
>> + ret = kstrtoul_from_user(user_buf, count, 0, &mask);
>> + if (ret)
>> + return ret;
>> +
>> + ath10k_warn(ar, "Setting debug-mask to: 0x%lx old: 0x%x\n",
>> + mask, ath10k_debug_mask);
>> + ath10k_debug_mask = mask;
>> + return count;
>> +}
>
> There are already sysfs files for module parameters which seems to work
> just fine for this case:
>
> # echo 0xffffffff > /sys/module/ath10k_core/parameters/debug_mask
Ok, but it is still nice to have the printout info of what log levels
means. Otherwise, you have to go look at firmware source to even know how
to enable the proper flags. And as these flags are internal and might change,
we could change the printout text to match the specific kernel that is running.
In my opinion, this is a 'nice-to-have', not required, if sysfs works,
so I will also test the sysfs suggestion above.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 03/21] ath10k: Allow changing ath10k debug mask at runtime.
2016-09-14 15:33 ` Ben Greear
@ 2016-09-15 14:19 ` Valo, Kalle
-1 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-15 14:19 UTC (permalink / raw)
To: Ben Greear; +Cc: ath10k, linux-wireless
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:06 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> Using debugfs. More convenient than module options
>>> in some cases.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/debug.c | 62 ++++++++++++++++++++++++=
+++++++++
>>> 1 file changed, 62 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wire=
less/ath/ath10k/debug.c
>>> index e251155..d552a4a 100644
>>> --- a/drivers/net/wireless/ath/ath10k/debug.c
>>> +++ b/drivers/net/wireless/ath/ath10k/debug.c
>>> @@ -870,6 +870,65 @@ static const struct file_operations fops_reg_addr =
=3D {
>>> .llseek =3D default_llseek,
>>> };
>>>
>>> +static ssize_t ath10k_read_debug_level(struct file *file,
>>> + char __user *user_buf,
>>> + size_t count, loff_t *ppos)
>>> +{
>>> + int sz;
>>> + const char buf[] =3D
>>> + "To change debug level, set value adding up desired flags:\n"
>>> + "PCI: 0x1\n"
>>> + "WMI: 0x2\n"
>>> + "HTC: 0x4\n"
>>> + "HTT: 0x8\n"
>>> + "MAC: 0x10\n"
>>> + "BOOT: 0x20\n"
>>> + "PCI-DUMP: 0x40\n"
>>> + "HTT-DUMP: 0x80\n"
>>> + "MGMT: 0x100\n"
>>> + "DATA: 0x200\n"
>>> + "BMI: 0x400\n"
>>> + "REGULATORY: 0x800\n"
>>> + "TESTMODE: 0x1000\n"
>>> + "INFO-AS-DBG: 0x40000000\n"
>>> + "FW: 0x80000000\n"
>>> + "ALL: 0xFFFFFFFF\n";
>>> + char wbuf[sizeof(buf) + 60];
>>> + sz =3D snprintf(wbuf, sizeof(wbuf), "Current debug level: 0x%x\n\n%s"=
,
>>> + ath10k_debug_mask, buf);
>>> + wbuf[sizeof(wbuf) - 1] =3D 0;
>>> +
>>> + return simple_read_from_buffer(user_buf, count, ppos, wbuf, sz);
>>> +}
>>> +
>>> +/* Set logging level.
>>> + */
>>> +static ssize_t ath10k_write_debug_level(struct file *file,
>>> + const char __user *user_buf,
>>> + size_t count, loff_t *ppos)
>>> +{
>>> + struct ath10k *ar =3D file->private_data;
>>> + int ret;
>>> + unsigned long mask;
>>> +
>>> + ret =3D kstrtoul_from_user(user_buf, count, 0, &mask);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ath10k_warn(ar, "Setting debug-mask to: 0x%lx old: 0x%x\n",
>>> + mask, ath10k_debug_mask);
>>> + ath10k_debug_mask =3D mask;
>>> + return count;
>>> +}
>>
>> There are already sysfs files for module parameters which seems to work
>> just fine for this case:
>>
>> # echo 0xffffffff > /sys/module/ath10k_core/parameters/debug_mask
>
>
> Ok, but it is still nice to have the printout info of what log levels
> means. Otherwise, you have to go look at firmware source to even know ho=
w
> to enable the proper flags. And as these flags are internal and might ch=
ange,
> we could change the printout text to match the specific kernel that is ru=
nning.
The debug log levels are documented in the wiki:
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug#debug_log_me=
ssages
And they are not supposed to change, there should be only additions.
--=20
Kalle Valo=
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 03/21] ath10k: Allow changing ath10k debug mask at runtime.
@ 2016-09-15 14:19 ` Valo, Kalle
0 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-15 14:19 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:06 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> Using debugfs. More convenient than module options
>>> in some cases.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/debug.c | 62 +++++++++++++++++++++++++++++++++
>>> 1 file changed, 62 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
>>> index e251155..d552a4a 100644
>>> --- a/drivers/net/wireless/ath/ath10k/debug.c
>>> +++ b/drivers/net/wireless/ath/ath10k/debug.c
>>> @@ -870,6 +870,65 @@ static const struct file_operations fops_reg_addr = {
>>> .llseek = default_llseek,
>>> };
>>>
>>> +static ssize_t ath10k_read_debug_level(struct file *file,
>>> + char __user *user_buf,
>>> + size_t count, loff_t *ppos)
>>> +{
>>> + int sz;
>>> + const char buf[] =
>>> + "To change debug level, set value adding up desired flags:\n"
>>> + "PCI: 0x1\n"
>>> + "WMI: 0x2\n"
>>> + "HTC: 0x4\n"
>>> + "HTT: 0x8\n"
>>> + "MAC: 0x10\n"
>>> + "BOOT: 0x20\n"
>>> + "PCI-DUMP: 0x40\n"
>>> + "HTT-DUMP: 0x80\n"
>>> + "MGMT: 0x100\n"
>>> + "DATA: 0x200\n"
>>> + "BMI: 0x400\n"
>>> + "REGULATORY: 0x800\n"
>>> + "TESTMODE: 0x1000\n"
>>> + "INFO-AS-DBG: 0x40000000\n"
>>> + "FW: 0x80000000\n"
>>> + "ALL: 0xFFFFFFFF\n";
>>> + char wbuf[sizeof(buf) + 60];
>>> + sz = snprintf(wbuf, sizeof(wbuf), "Current debug level: 0x%x\n\n%s",
>>> + ath10k_debug_mask, buf);
>>> + wbuf[sizeof(wbuf) - 1] = 0;
>>> +
>>> + return simple_read_from_buffer(user_buf, count, ppos, wbuf, sz);
>>> +}
>>> +
>>> +/* Set logging level.
>>> + */
>>> +static ssize_t ath10k_write_debug_level(struct file *file,
>>> + const char __user *user_buf,
>>> + size_t count, loff_t *ppos)
>>> +{
>>> + struct ath10k *ar = file->private_data;
>>> + int ret;
>>> + unsigned long mask;
>>> +
>>> + ret = kstrtoul_from_user(user_buf, count, 0, &mask);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ath10k_warn(ar, "Setting debug-mask to: 0x%lx old: 0x%x\n",
>>> + mask, ath10k_debug_mask);
>>> + ath10k_debug_mask = mask;
>>> + return count;
>>> +}
>>
>> There are already sysfs files for module parameters which seems to work
>> just fine for this case:
>>
>> # echo 0xffffffff > /sys/module/ath10k_core/parameters/debug_mask
>
>
> Ok, but it is still nice to have the printout info of what log levels
> means. Otherwise, you have to go look at firmware source to even know how
> to enable the proper flags. And as these flags are internal and might change,
> we could change the printout text to match the specific kernel that is running.
The debug log levels are documented in the wiki:
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug#debug_log_messages
And they are not supposed to change, there should be only additions.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 03/21] ath10k: Allow changing ath10k debug mask at runtime.
2016-09-15 14:19 ` Valo, Kalle
@ 2016-09-15 15:07 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-15 15:07 UTC (permalink / raw)
To: Valo, Kalle; +Cc: ath10k, linux-wireless
On 09/15/2016 07:19 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:06 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> Using debugfs. More convenient than module options
>>>> in some cases.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>> ---
>>>> drivers/net/wireless/ath/ath10k/debug.c | 62 +++++++++++++++++++++++++++++++++
>>>> 1 file changed, 62 insertions(+)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
>>>> index e251155..d552a4a 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/debug.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/debug.c
>>>> @@ -870,6 +870,65 @@ static const struct file_operations fops_reg_addr = {
>>>> .llseek = default_llseek,
>>>> };
>>>>
>>>> +static ssize_t ath10k_read_debug_level(struct file *file,
>>>> + char __user *user_buf,
>>>> + size_t count, loff_t *ppos)
>>>> +{
>>>> + int sz;
>>>> + const char buf[] =
>>>> + "To change debug level, set value adding up desired flags:\n"
>>>> + "PCI: 0x1\n"
>>>> + "WMI: 0x2\n"
>>>> + "HTC: 0x4\n"
>>>> + "HTT: 0x8\n"
>>>> + "MAC: 0x10\n"
>>>> + "BOOT: 0x20\n"
>>>> + "PCI-DUMP: 0x40\n"
>>>> + "HTT-DUMP: 0x80\n"
>>>> + "MGMT: 0x100\n"
>>>> + "DATA: 0x200\n"
>>>> + "BMI: 0x400\n"
>>>> + "REGULATORY: 0x800\n"
>>>> + "TESTMODE: 0x1000\n"
>>>> + "INFO-AS-DBG: 0x40000000\n"
>>>> + "FW: 0x80000000\n"
>>>> + "ALL: 0xFFFFFFFF\n";
>>>> + char wbuf[sizeof(buf) + 60];
>>>> + sz = snprintf(wbuf, sizeof(wbuf), "Current debug level: 0x%x\n\n%s",
>>>> + ath10k_debug_mask, buf);
>>>> + wbuf[sizeof(wbuf) - 1] = 0;
>>>> +
>>>> + return simple_read_from_buffer(user_buf, count, ppos, wbuf, sz);
>>>> +}
>>>> +
>>>> +/* Set logging level.
>>>> + */
>>>> +static ssize_t ath10k_write_debug_level(struct file *file,
>>>> + const char __user *user_buf,
>>>> + size_t count, loff_t *ppos)
>>>> +{
>>>> + struct ath10k *ar = file->private_data;
>>>> + int ret;
>>>> + unsigned long mask;
>>>> +
>>>> + ret = kstrtoul_from_user(user_buf, count, 0, &mask);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + ath10k_warn(ar, "Setting debug-mask to: 0x%lx old: 0x%x\n",
>>>> + mask, ath10k_debug_mask);
>>>> + ath10k_debug_mask = mask;
>>>> + return count;
>>>> +}
>>>
>>> There are already sysfs files for module parameters which seems to work
>>> just fine for this case:
>>>
>>> # echo 0xffffffff > /sys/module/ath10k_core/parameters/debug_mask
>>
>>
>> Ok, but it is still nice to have the printout info of what log levels
>> means. Otherwise, you have to go look at firmware source to even know how
>> to enable the proper flags. And as these flags are internal and might change,
>> we could change the printout text to match the specific kernel that is running.
>
> The debug log levels are documented in the wiki:
>
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug#debug_log_messages
>
> And they are not supposed to change, there should be only additions.
Ahh, I remember the best part of this patch. It pre-positions for another patch
that makes the debug-mask per NIC instance instead of per driver.
This can be quite useful for testing with multiple radios, maybe only one of
which you want to see logging for.
And regardless of what is in a wiki somewhere, having a debugfs file to cat out is
more user friendly.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 03/21] ath10k: Allow changing ath10k debug mask at runtime.
@ 2016-09-15 15:07 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-15 15:07 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/15/2016 07:19 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:06 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> Using debugfs. More convenient than module options
>>>> in some cases.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>> ---
>>>> drivers/net/wireless/ath/ath10k/debug.c | 62 +++++++++++++++++++++++++++++++++
>>>> 1 file changed, 62 insertions(+)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
>>>> index e251155..d552a4a 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/debug.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/debug.c
>>>> @@ -870,6 +870,65 @@ static const struct file_operations fops_reg_addr = {
>>>> .llseek = default_llseek,
>>>> };
>>>>
>>>> +static ssize_t ath10k_read_debug_level(struct file *file,
>>>> + char __user *user_buf,
>>>> + size_t count, loff_t *ppos)
>>>> +{
>>>> + int sz;
>>>> + const char buf[] =
>>>> + "To change debug level, set value adding up desired flags:\n"
>>>> + "PCI: 0x1\n"
>>>> + "WMI: 0x2\n"
>>>> + "HTC: 0x4\n"
>>>> + "HTT: 0x8\n"
>>>> + "MAC: 0x10\n"
>>>> + "BOOT: 0x20\n"
>>>> + "PCI-DUMP: 0x40\n"
>>>> + "HTT-DUMP: 0x80\n"
>>>> + "MGMT: 0x100\n"
>>>> + "DATA: 0x200\n"
>>>> + "BMI: 0x400\n"
>>>> + "REGULATORY: 0x800\n"
>>>> + "TESTMODE: 0x1000\n"
>>>> + "INFO-AS-DBG: 0x40000000\n"
>>>> + "FW: 0x80000000\n"
>>>> + "ALL: 0xFFFFFFFF\n";
>>>> + char wbuf[sizeof(buf) + 60];
>>>> + sz = snprintf(wbuf, sizeof(wbuf), "Current debug level: 0x%x\n\n%s",
>>>> + ath10k_debug_mask, buf);
>>>> + wbuf[sizeof(wbuf) - 1] = 0;
>>>> +
>>>> + return simple_read_from_buffer(user_buf, count, ppos, wbuf, sz);
>>>> +}
>>>> +
>>>> +/* Set logging level.
>>>> + */
>>>> +static ssize_t ath10k_write_debug_level(struct file *file,
>>>> + const char __user *user_buf,
>>>> + size_t count, loff_t *ppos)
>>>> +{
>>>> + struct ath10k *ar = file->private_data;
>>>> + int ret;
>>>> + unsigned long mask;
>>>> +
>>>> + ret = kstrtoul_from_user(user_buf, count, 0, &mask);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + ath10k_warn(ar, "Setting debug-mask to: 0x%lx old: 0x%x\n",
>>>> + mask, ath10k_debug_mask);
>>>> + ath10k_debug_mask = mask;
>>>> + return count;
>>>> +}
>>>
>>> There are already sysfs files for module parameters which seems to work
>>> just fine for this case:
>>>
>>> # echo 0xffffffff > /sys/module/ath10k_core/parameters/debug_mask
>>
>>
>> Ok, but it is still nice to have the printout info of what log levels
>> means. Otherwise, you have to go look at firmware source to even know how
>> to enable the proper flags. And as these flags are internal and might change,
>> we could change the printout text to match the specific kernel that is running.
>
> The debug log levels are documented in the wiki:
>
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug#debug_log_messages
>
> And they are not supposed to change, there should be only additions.
Ahh, I remember the best part of this patch. It pre-positions for another patch
that makes the debug-mask per NIC instance instead of per driver.
This can be quite useful for testing with multiple radios, maybe only one of
which you want to see logging for.
And regardless of what is in a wiki somewhere, having a debugfs file to cat out is
more user friendly.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* [PATCH v2 04/21] ath10k: rate-limit packet tx errors
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
When firmware crashes, stack can continue to send packets
for a bit, and existing code was spamming logs.
So, rate-limit the error message for tx failures.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index cd3016d..42cac32 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3432,8 +3432,9 @@ static int ath10k_mac_tx_submit(struct ath10k *ar,
}
if (ret) {
- ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
- ret);
+ if (net_ratelimit())
+ ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
+ ret);
ieee80211_free_txskb(ar->hw, skb);
}
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 04/21] ath10k: rate-limit packet tx errors
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
When firmware crashes, stack can continue to send packets
for a bit, and existing code was spamming logs.
So, rate-limit the error message for tx failures.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index cd3016d..42cac32 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3432,8 +3432,9 @@ static int ath10k_mac_tx_submit(struct ath10k *ar,
}
if (ret) {
- ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
- ret);
+ if (net_ratelimit())
+ ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
+ ret);
ieee80211_free_txskb(ar->hw, skb);
}
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread* Re: [PATCH v2 04/21] ath10k: rate-limit packet tx errors
2016-05-11 17:02 ` greearb
@ 2016-09-14 14:07 ` Valo, Kalle
-1 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 14:07 UTC (permalink / raw)
To: greearb; +Cc: ath10k, linux-wireless
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> When firmware crashes, stack can continue to send packets
> for a bit, and existing code was spamming logs.
>
> So, rate-limit the error message for tx failures.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless=
/ath/ath10k/mac.c
> index cd3016d..42cac32 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -3432,8 +3432,9 @@ static int ath10k_mac_tx_submit(struct ath10k *ar,
> }
> =20
> if (ret) {
> - ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
> - ret);
> + if (net_ratelimit())
> + ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
> + ret);
> ieee80211_free_txskb(ar->hw, skb);
> }
ath10k_warn() is already rate limited. If there's something wrong then
that function should be fixed, not the callers.
void ath10k_warn(struct ath10k *ar, const char *fmt, ...)
{
struct va_format vaf =3D {
.fmt =3D fmt,
};
va_list args;
va_start(args, fmt);
vaf.va =3D &args;
dev_warn_ratelimited(ar->dev, "%pV", &vaf);
trace_ath10k_log_warn(ar, &vaf);
va_end(args);
}
--=20
Kalle Valo=
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 04/21] ath10k: rate-limit packet tx errors
@ 2016-09-14 14:07 ` Valo, Kalle
0 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 14:07 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath10k
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> When firmware crashes, stack can continue to send packets
> for a bit, and existing code was spamming logs.
>
> So, rate-limit the error message for tx failures.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index cd3016d..42cac32 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -3432,8 +3432,9 @@ static int ath10k_mac_tx_submit(struct ath10k *ar,
> }
>
> if (ret) {
> - ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
> - ret);
> + if (net_ratelimit())
> + ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
> + ret);
> ieee80211_free_txskb(ar->hw, skb);
> }
ath10k_warn() is already rate limited. If there's something wrong then
that function should be fixed, not the callers.
void ath10k_warn(struct ath10k *ar, const char *fmt, ...)
{
struct va_format vaf = {
.fmt = fmt,
};
va_list args;
va_start(args, fmt);
vaf.va = &args;
dev_warn_ratelimited(ar->dev, "%pV", &vaf);
trace_ath10k_log_warn(ar, &vaf);
va_end(args);
}
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 04/21] ath10k: rate-limit packet tx errors
2016-09-14 14:07 ` Valo, Kalle
@ 2016-09-14 15:02 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-14 15:02 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/14/2016 07:07 AM, Valo, Kalle wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> When firmware crashes, stack can continue to send packets
>> for a bit, and existing code was spamming logs.
>>
>> So, rate-limit the error message for tx failures.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>> ---
>> drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>> index cd3016d..42cac32 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -3432,8 +3432,9 @@ static int ath10k_mac_tx_submit(struct ath10k *ar,
>> }
>>
>> if (ret) {
>> - ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>> - ret);
>> + if (net_ratelimit())
>> + ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>> + ret);
>> ieee80211_free_txskb(ar->hw, skb);
>> }
>
> ath10k_warn() is already rate limited. If there's something wrong then
> that function should be fixed, not the callers.
>
> void ath10k_warn(struct ath10k *ar, const char *fmt, ...)
> {
> struct va_format vaf = {
> .fmt = fmt,
> };
> va_list args;
>
> va_start(args, fmt);
> vaf.va = &args;
> dev_warn_ratelimited(ar->dev, "%pV", &vaf);
> trace_ath10k_log_warn(ar, &vaf);
>
> va_end(args);
> }
The problem with having the ratelimit here is that you may miss
rare warnings due to a flood of common warnings.
That is why it is still useful to ratelimit potential floods
of warnings.
I would like to remove the ratelimit from ath10k_warn eventually.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 04/21] ath10k: rate-limit packet tx errors
@ 2016-09-14 15:02 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-14 15:02 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/14/2016 07:07 AM, Valo, Kalle wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> When firmware crashes, stack can continue to send packets
>> for a bit, and existing code was spamming logs.
>>
>> So, rate-limit the error message for tx failures.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>> ---
>> drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>> index cd3016d..42cac32 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -3432,8 +3432,9 @@ static int ath10k_mac_tx_submit(struct ath10k *ar,
>> }
>>
>> if (ret) {
>> - ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>> - ret);
>> + if (net_ratelimit())
>> + ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>> + ret);
>> ieee80211_free_txskb(ar->hw, skb);
>> }
>
> ath10k_warn() is already rate limited. If there's something wrong then
> that function should be fixed, not the callers.
>
> void ath10k_warn(struct ath10k *ar, const char *fmt, ...)
> {
> struct va_format vaf = {
> .fmt = fmt,
> };
> va_list args;
>
> va_start(args, fmt);
> vaf.va = &args;
> dev_warn_ratelimited(ar->dev, "%pV", &vaf);
> trace_ath10k_log_warn(ar, &vaf);
>
> va_end(args);
> }
The problem with having the ratelimit here is that you may miss
rare warnings due to a flood of common warnings.
That is why it is still useful to ratelimit potential floods
of warnings.
I would like to remove the ratelimit from ath10k_warn eventually.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 04/21] ath10k: rate-limit packet tx errors
2016-09-14 15:02 ` Ben Greear
@ 2016-09-15 13:59 ` Valo, Kalle
-1 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-15 13:59 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:07 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> When firmware crashes, stack can continue to send packets
>>> for a bit, and existing code was spamming logs.
>>>
>>> So, rate-limit the error message for tx failures.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wirele=
ss/ath/ath10k/mac.c
>>> index cd3016d..42cac32 100644
>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>> @@ -3432,8 +3432,9 @@ static int ath10k_mac_tx_submit(struct ath10k *ar=
,
>>> }
>>>
>>> if (ret) {
>>> - ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>>> - ret);
>>> + if (net_ratelimit())
>>> + ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>>> + ret);
>>> ieee80211_free_txskb(ar->hw, skb);
>>> }
>>
>> ath10k_warn() is already rate limited. If there's something wrong then
>> that function should be fixed, not the callers.
>>
>> void ath10k_warn(struct ath10k *ar, const char *fmt, ...)
>> {
>> struct va_format vaf =3D {
>> .fmt =3D fmt,
>> };
>> va_list args;
>>
>> va_start(args, fmt);
>> vaf.va =3D &args;
>> dev_warn_ratelimited(ar->dev, "%pV", &vaf);
>> trace_ath10k_log_warn(ar, &vaf);
>>
>> va_end(args);
>> }
>
> The problem with having the ratelimit here is that you may miss
> rare warnings due to a flood of common warnings.
>
> That is why it is still useful to ratelimit potential floods
> of warnings.
I think this is a common problem in kernel, not specific to ath10k. For
starters you could configure the limits dev_warn_ratelimited() has, not
trying to workaround it in the driver.
> I would like to remove the ratelimit from ath10k_warn eventually.
I think that's not a good idea, it might cause unnecessary host reboots
in problem cases. Rate limitting the messages is much better option.
--=20
Kalle Valo=
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 04/21] ath10k: rate-limit packet tx errors
@ 2016-09-15 13:59 ` Valo, Kalle
0 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-15 13:59 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:07 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> When firmware crashes, stack can continue to send packets
>>> for a bit, and existing code was spamming logs.
>>>
>>> So, rate-limit the error message for tx failures.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>>> index cd3016d..42cac32 100644
>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>> @@ -3432,8 +3432,9 @@ static int ath10k_mac_tx_submit(struct ath10k *ar,
>>> }
>>>
>>> if (ret) {
>>> - ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>>> - ret);
>>> + if (net_ratelimit())
>>> + ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>>> + ret);
>>> ieee80211_free_txskb(ar->hw, skb);
>>> }
>>
>> ath10k_warn() is already rate limited. If there's something wrong then
>> that function should be fixed, not the callers.
>>
>> void ath10k_warn(struct ath10k *ar, const char *fmt, ...)
>> {
>> struct va_format vaf = {
>> .fmt = fmt,
>> };
>> va_list args;
>>
>> va_start(args, fmt);
>> vaf.va = &args;
>> dev_warn_ratelimited(ar->dev, "%pV", &vaf);
>> trace_ath10k_log_warn(ar, &vaf);
>>
>> va_end(args);
>> }
>
> The problem with having the ratelimit here is that you may miss
> rare warnings due to a flood of common warnings.
>
> That is why it is still useful to ratelimit potential floods
> of warnings.
I think this is a common problem in kernel, not specific to ath10k. For
starters you could configure the limits dev_warn_ratelimited() has, not
trying to workaround it in the driver.
> I would like to remove the ratelimit from ath10k_warn eventually.
I think that's not a good idea, it might cause unnecessary host reboots
in problem cases. Rate limitting the messages is much better option.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 04/21] ath10k: rate-limit packet tx errors
2016-09-15 13:59 ` Valo, Kalle
@ 2016-09-15 15:22 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-15 15:22 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/15/2016 06:59 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:07 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> When firmware crashes, stack can continue to send packets
>>>> for a bit, and existing code was spamming logs.
>>>>
>>>> So, rate-limit the error message for tx failures.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>> ---
>>>> drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
>>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>>>> index cd3016d..42cac32 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>>> @@ -3432,8 +3432,9 @@ static int ath10k_mac_tx_submit(struct ath10k *ar,
>>>> }
>>>>
>>>> if (ret) {
>>>> - ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>>>> - ret);
>>>> + if (net_ratelimit())
>>>> + ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>>>> + ret);
>>>> ieee80211_free_txskb(ar->hw, skb);
>>>> }
>>>
>>> ath10k_warn() is already rate limited. If there's something wrong then
>>> that function should be fixed, not the callers.
>>>
>>> void ath10k_warn(struct ath10k *ar, const char *fmt, ...)
>>> {
>>> struct va_format vaf = {
>>> .fmt = fmt,
>>> };
>>> va_list args;
>>>
>>> va_start(args, fmt);
>>> vaf.va = &args;
>>> dev_warn_ratelimited(ar->dev, "%pV", &vaf);
>>> trace_ath10k_log_warn(ar, &vaf);
>>>
>>> va_end(args);
>>> }
>>
>> The problem with having the ratelimit here is that you may miss
>> rare warnings due to a flood of common warnings.
>>
>> That is why it is still useful to ratelimit potential floods
>> of warnings.
>
> I think this is a common problem in kernel, not specific to ath10k. For
> starters you could configure the limits dev_warn_ratelimited() has, not
> trying to workaround it in the driver.
I will try to explain this once more.
If you have the ratelimit in a centralized place, then all code that calls it
is rate-limitted with same counter and each call site gets the same priority.
One verbose caller can thus disable logs for the much more rare callers.
My patch pre-filters one of the verbose callers, which lets other more
rare and interesting callers be more likely to print logging messages
that are useful for debugging.
>> I would like to remove the ratelimit from ath10k_warn eventually.
>
> I think that's not a good idea, it might cause unnecessary host reboots
> in problem cases. Rate limitting the messages is much better option.
Ok, but even so, that would be a later patch and that is not a reason
to reject the one I posted.
For what it is worth, I and my users have been running such a patch for years
in various embedded and other systems and it works fine.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 04/21] ath10k: rate-limit packet tx errors
@ 2016-09-15 15:22 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-15 15:22 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/15/2016 06:59 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:07 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> When firmware crashes, stack can continue to send packets
>>>> for a bit, and existing code was spamming logs.
>>>>
>>>> So, rate-limit the error message for tx failures.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>> ---
>>>> drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
>>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>>>> index cd3016d..42cac32 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>>> @@ -3432,8 +3432,9 @@ static int ath10k_mac_tx_submit(struct ath10k *ar,
>>>> }
>>>>
>>>> if (ret) {
>>>> - ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>>>> - ret);
>>>> + if (net_ratelimit())
>>>> + ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>>>> + ret);
>>>> ieee80211_free_txskb(ar->hw, skb);
>>>> }
>>>
>>> ath10k_warn() is already rate limited. If there's something wrong then
>>> that function should be fixed, not the callers.
>>>
>>> void ath10k_warn(struct ath10k *ar, const char *fmt, ...)
>>> {
>>> struct va_format vaf = {
>>> .fmt = fmt,
>>> };
>>> va_list args;
>>>
>>> va_start(args, fmt);
>>> vaf.va = &args;
>>> dev_warn_ratelimited(ar->dev, "%pV", &vaf);
>>> trace_ath10k_log_warn(ar, &vaf);
>>>
>>> va_end(args);
>>> }
>>
>> The problem with having the ratelimit here is that you may miss
>> rare warnings due to a flood of common warnings.
>>
>> That is why it is still useful to ratelimit potential floods
>> of warnings.
>
> I think this is a common problem in kernel, not specific to ath10k. For
> starters you could configure the limits dev_warn_ratelimited() has, not
> trying to workaround it in the driver.
I will try to explain this once more.
If you have the ratelimit in a centralized place, then all code that calls it
is rate-limitted with same counter and each call site gets the same priority.
One verbose caller can thus disable logs for the much more rare callers.
My patch pre-filters one of the verbose callers, which lets other more
rare and interesting callers be more likely to print logging messages
that are useful for debugging.
>> I would like to remove the ratelimit from ath10k_warn eventually.
>
> I think that's not a good idea, it might cause unnecessary host reboots
> in problem cases. Rate limitting the messages is much better option.
Ok, but even so, that would be a later patch and that is not a reason
to reject the one I posted.
For what it is worth, I and my users have been running such a patch for years
in various embedded and other systems and it works fine.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* [PATCH v2 05/21] ath10k: save firmware debug log messages.
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
They may be dumped through the firmware dump debugfs
file.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.h | 18 ++++++
drivers/net/wireless/ath/ath10k/debug.c | 97 +++++++++++++++++++++++++++++++-
drivers/net/wireless/ath/ath10k/debug.h | 6 ++
drivers/net/wireless/ath/ath10k/hw.h | 21 +++++++
drivers/net/wireless/ath/ath10k/pci.c | 99 +++++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.c | 13 +++++
drivers/net/wireless/ath/ath10k/wmi.h | 6 ++
7 files changed, 258 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 1379054..7f9f460 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -404,6 +404,22 @@ struct ath10k_vif_iter {
struct ath10k_vif *arvif;
};
+/* This will store at least the last 128 entries. Each dbglog message
+ * is a max of 7 32-bit integers in length, but the length can be less
+ * than that as well.
+ */
+#define ATH10K_DBGLOG_DATA_LEN (128 * 7)
+struct ath10k_dbglog_entry_storage {
+ u32 head_idx; /* Where to write next chunk of data */
+ u32 tail_idx; /* Index of first msg */
+ __le32 data[ATH10K_DBGLOG_DATA_LEN];
+};
+
+/* Just enough info to decode firmware debug-log argument length */
+#define DBGLOG_NUM_ARGS_OFFSET 26
+#define DBGLOG_NUM_ARGS_MASK 0xFC000000 /* Bit 26-31 */
+#define DBGLOG_NUM_ARGS_MAX 5 /* firmware tool chain limit */
+
/* used for crash-dump storage, protected by data-lock */
struct ath10k_fw_crash_data {
bool crashed_since_read;
@@ -437,6 +453,8 @@ struct ath10k_debug {
u32 reg_addr;
u32 nf_cal_period;
+ struct ath10k_dbglog_entry_storage dbglog_entry_data;
+
struct ath10k_fw_crash_data *fw_crash_data;
};
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index d552a4a..1739687 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -35,10 +35,11 @@
/**
* enum ath10k_fw_crash_dump_type - types of data in the dump file
* @ATH10K_FW_CRASH_DUMP_REGDUMP: Register crash dump in binary format
+ * @ATH10K_FW_ERROR_DUMP_DBGLOG: Recent firmware debug log entries
*/
enum ath10k_fw_crash_dump_type {
ATH10K_FW_CRASH_DUMP_REGISTERS = 0,
-
+ ATH10K_FW_CRASH_DUMP_DBGLOG = 1,
ATH10K_FW_CRASH_DUMP_MAX,
};
@@ -109,6 +110,12 @@ struct ath10k_dump_file_data {
u8 data[0];
} __packed;
+struct ath10k_dbglog_entry_storage_user {
+ __le32 head_idx; /* Where to write next chunk of data */
+ __le32 tail_idx; /* Index of first msg */
+ __le32 data[ATH10K_DBGLOG_DATA_LEN];
+} __packed;
+
void ath10k_info(struct ath10k *ar, const char *fmt, ...)
{
struct va_format vaf = {
@@ -697,7 +704,6 @@ ath10k_debug_get_new_fw_crash_data(struct ath10k *ar)
lockdep_assert_held(&ar->data_lock);
- crash_data->crashed_since_read = true;
uuid_le_gen(&crash_data->uuid);
getnstimeofday(&crash_data->timestamp);
@@ -705,17 +711,87 @@ ath10k_debug_get_new_fw_crash_data(struct ath10k *ar)
}
EXPORT_SYMBOL(ath10k_debug_get_new_fw_crash_data);
+static void ath10k_dbg_drop_dbg_buffer(struct ath10k *ar)
+{
+ /* Find next message boundary */
+ u32 lg_hdr;
+ int acnt;
+ int tail_idx = ar->debug.dbglog_entry_data.tail_idx;
+ int h_idx = (tail_idx + 1) % ATH10K_DBGLOG_DATA_LEN;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ /* Log header is second 32-bit word */
+ lg_hdr = le32_to_cpu(ar->debug.dbglog_entry_data.data[h_idx]);
+
+ acnt = (lg_hdr & DBGLOG_NUM_ARGS_MASK) >> DBGLOG_NUM_ARGS_OFFSET;
+
+ if (acnt > DBGLOG_NUM_ARGS_MAX) {
+ /* Some sort of corruption it seems, recover as best we can. */
+ ath10k_err(ar, "invalid dbglog arg-count: %i %i %i\n",
+ acnt, ar->debug.dbglog_entry_data.tail_idx,
+ ar->debug.dbglog_entry_data.head_idx);
+ ar->debug.dbglog_entry_data.tail_idx =
+ ar->debug.dbglog_entry_data.head_idx;
+ return;
+ }
+
+ /* Move forward over the args and the two header fields */
+ ar->debug.dbglog_entry_data.tail_idx =
+ (tail_idx + acnt + 2) % ATH10K_DBGLOG_DATA_LEN;
+}
+
+void ath10k_dbg_save_fw_dbg_buffer(struct ath10k *ar, __le32 *buffer, int len)
+{
+ int i;
+ int z;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ z = ar->debug.dbglog_entry_data.head_idx;
+
+ /* Don't save any new logs until user-space reads this. */
+ if (ar->debug.fw_crash_data &&
+ ar->debug.fw_crash_data->crashed_since_read) {
+ ath10k_warn(ar, "dropping dbg buffer due to crash since read\n");
+ return;
+ }
+
+ for (i = 0; i < len; i++) {
+ ar->debug.dbglog_entry_data.data[z] = buffer[i];
+ z++;
+ if (z >= ATH10K_DBGLOG_DATA_LEN)
+ z = 0;
+
+ /* If we are about to over-write an old message, move the
+ * tail_idx to the next message. If idx's are same, we
+ * are empty.
+ */
+ if (z == ar->debug.dbglog_entry_data.tail_idx)
+ ath10k_dbg_drop_dbg_buffer(ar);
+
+ ar->debug.dbglog_entry_data.head_idx = z;
+ }
+}
+EXPORT_SYMBOL(ath10k_dbg_save_fw_dbg_buffer);
+
static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
{
struct ath10k_fw_crash_data *crash_data = ar->debug.fw_crash_data;
struct ath10k_dump_file_data *dump_data;
struct ath10k_tlv_dump_data *dump_tlv;
+ struct ath10k_dbglog_entry_storage_user *dbglog_storage;
int hdr_len = sizeof(*dump_data);
unsigned int len, sofar = 0;
unsigned char *buf;
+ int tmp;
+
+ BUILD_BUG_ON(sizeof(struct ath10k_dbglog_entry_storage) !=
+ sizeof(struct ath10k_dbglog_entry_storage_user));
len = hdr_len;
len += sizeof(*dump_tlv) + sizeof(crash_data->registers);
+ len += sizeof(*dump_tlv) + sizeof(ar->debug.dbglog_entry_data);
sofar += hdr_len;
@@ -774,8 +850,25 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
sizeof(crash_data->registers));
sofar += sizeof(*dump_tlv) + sizeof(crash_data->registers);
+ /* Gather dbg-log */
+ tmp = sizeof(ar->debug.dbglog_entry_data);
+ dump_tlv = (struct ath10k_tlv_dump_data *)(buf + sofar);
+ dump_tlv->type = cpu_to_le32(ATH10K_FW_CRASH_DUMP_DBGLOG);
+ dump_tlv->tlv_len = cpu_to_le32(tmp);
+ dbglog_storage =
+ (struct ath10k_dbglog_entry_storage_user *)(dump_tlv->tlv_data);
+ memcpy(dbglog_storage->data, ar->debug.dbglog_entry_data.data,
+ sizeof(dbglog_storage->data));
+ dbglog_storage->head_idx =
+ cpu_to_le32(ar->debug.dbglog_entry_data.head_idx);
+ dbglog_storage->tail_idx =
+ cpu_to_le32(ar->debug.dbglog_entry_data.tail_idx);
+
+ sofar += sizeof(*dump_tlv) + tmp;
+
ar->debug.fw_crash_data->crashed_since_read = false;
+ WARN_ON(sofar != len);
spin_unlock_bh(&ar->data_lock);
return dump_data;
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 75c89e3..3062948 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -94,7 +94,13 @@ int ath10k_debug_get_et_sset_count(struct ieee80211_hw *hw,
void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ethtool_stats *stats, u64 *data);
+
+void ath10k_dbg_save_fw_dbg_buffer(struct ath10k *ar, __le32 *buffer, int len);
#else
+static inline void ath10k_dbg_save_fw_dbg_buffer(struct ath10k *ar,
+ __le32 *buffer, int len)
+{
+}
static inline int ath10k_debug_start(struct ath10k *ar)
{
return 0;
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index aedd898..5bbef4b 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -681,4 +681,25 @@ enum ath10k_hw_4addr_pad {
#define RTC_STATE_V_GET(x) (((x) & RTC_STATE_V_MASK) >> RTC_STATE_V_LSB)
+/* Target debug log related defines and structs */
+
+/* Target is 32-bit CPU, so we just use u32 for
+ * the pointers. The memory space is relative to the
+ * target, not the host. Values are converted to host
+ * byte order when reading from firmware.
+ */
+struct ath10k_fw_dbglog_buf {
+ __le32 next; /* pointer to ath10k_fw_dbglog_buf. */
+ __le32 buffer; /* pointer to u8 buffer */
+ __le32 bufsize;
+ __le32 length;
+ __le32 count;
+ __le32 free;
+} __packed;
+
+struct ath10k_fw_dbglog_hdr {
+ __le32 dbuf; /* pointer to ath10k_fw_dbglog_buf */
+ __le32 dropped;
+} __packed;
+
#endif /* _HW_H_ */
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 8133d7b..16e32d0 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1439,6 +1439,102 @@ static void ath10k_pci_dump_registers(struct ath10k *ar,
crash_data->registers[i] = reg_dump_values[i];
}
+/**
+ * Read any not-yet-delivered debug-log buffers on the target
+ * and save them to storage in the host driver. Typically
+ * only done on crash, as firmware will normally deliver
+ * logs periodically on its own if it is functioning
+ * properly.
+ */
+static void ath10k_pci_dump_dbglog(struct ath10k *ar)
+{
+ struct ath10k_fw_dbglog_hdr dbg_hdr;
+ u32 dbufp; /* pointer in target memory space */
+ struct ath10k_fw_dbglog_buf dbuf;
+ u8 *buffer;
+ int ret;
+ int i;
+ int len;
+
+ ret = ath10k_pci_diag_read_hi(ar, &dbg_hdr, hi_dbglog_hdr,
+ sizeof(dbg_hdr));
+ if (ret != 0) {
+ ath10k_err(ar, "failed to dump debug log area: %d\n", ret);
+ return;
+ }
+
+ ath10k_dbg(ar, ATH10K_DBG_PCI,
+ "debug log header, dbuf: 0x%x dropped: %i\n",
+ le32_to_cpu(dbg_hdr.dbuf), le32_to_cpu(dbg_hdr.dropped));
+ dbufp = le32_to_cpu(dbg_hdr.dbuf);
+
+ /* i is for logging purposes and sanity check in case firmware buffers
+ * are corrupted and will not properly terminate the list.
+ * In standard firmware, it appears there are no more than 2
+ * buffers, so 10 should be safe upper limit even if firmware
+ * changes quite a bit.
+ */
+ i = 0;
+ while (dbufp && i < 10) {
+ ret = ath10k_pci_diag_read_mem(ar, dbufp, &dbuf, sizeof(dbuf));
+ if (ret != 0) {
+ ath10k_err(ar, "failed to read debug log area: %d (addr 0x%x)\n",
+ ret, dbufp);
+ return;
+ }
+
+ len = le32_to_cpu(dbuf.length);
+
+ ath10k_dbg(ar, ATH10K_DBG_PCI,
+ "[%i] next: 0x%x buf: 0x%x sz: %i len: %i count: %i free: %i\n",
+ i, le32_to_cpu(dbuf.next), le32_to_cpu(dbuf.buffer),
+ le32_to_cpu(dbuf.bufsize), len,
+ le32_to_cpu(dbuf.count), le32_to_cpu(dbuf.free));
+ if (dbuf.buffer == 0 || len == 0)
+ goto next;
+
+ /* Pick arbitrary upper bound in case firmware is corrupted for
+ * whatever reason.
+ */
+ if (len > 4096) {
+ ath10k_err(ar,
+ "debuglog buf length is out of bounds: %d\n",
+ len);
+ /* Do not trust the next pointer either... */
+ return;
+ }
+
+ buffer = kmalloc(len, GFP_ATOMIC);
+
+ if (!buffer)
+ goto next;
+
+ ret = ath10k_pci_diag_read_mem(ar, le32_to_cpu(dbuf.buffer),
+ buffer, len);
+ if (ret != 0) {
+ ath10k_err(ar, "failed to read debug log buffer: %d (addr 0x%x)\n",
+ ret, le32_to_cpu(dbuf.buffer));
+ kfree(buffer);
+ return;
+ }
+
+ WARN_ON(len & 0x3);
+
+ ath10k_dbg_save_fw_dbg_buffer(ar, (__le32 *)(buffer), len >> 2);
+ kfree(buffer);
+
+next:
+ dbufp = le32_to_cpu(dbuf.next);
+ if (dbufp == le32_to_cpu(dbg_hdr.dbuf)) {
+ /* It is a circular buffer it seems, bail if next
+ * is head
+ */
+ break;
+ }
+ i++;
+ } /* While we have a debug buffer to read */
+}
+
static void ath10k_pci_fw_crashed_dump(struct ath10k *ar)
{
struct ath10k_fw_crash_data *crash_data;
@@ -1458,6 +1554,9 @@ static void ath10k_pci_fw_crashed_dump(struct ath10k *ar)
ath10k_err(ar, "firmware crashed! (uuid %s)\n", uuid);
ath10k_print_driver_info(ar);
ath10k_pci_dump_registers(ar, crash_data);
+ ath10k_pci_dump_dbglog(ar);
+ if (crash_data)
+ crash_data->crashed_since_read = true;
spin_unlock_bh(&ar->data_lock);
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 621019f..1758b4a 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2492,10 +2492,23 @@ void ath10k_wmi_event_echo(struct ath10k *ar, struct sk_buff *skb)
int ath10k_wmi_event_debug_mesg(struct ath10k *ar, struct sk_buff *skb)
{
+ struct ath10k_fw_dbglog_report *ev;
+
ath10k_dbg(ar, ATH10K_DBG_WMI, "wmi event debug mesg len %d\n",
skb->len);
trace_ath10k_wmi_dbglog(ar, skb->data, skb->len);
+ ev = (struct ath10k_fw_dbglog_report *)skb->data;
+
+ spin_lock_bh(&ar->data_lock);
+ /* First 4 bytes are a messages-dropped-due-to-overflow counter,
+ * and should not be recorded in the dbglog buffer, so we skip
+ * them.
+ */
+ WARN_ON(skb->len & 0x3);
+ ath10k_dbg_save_fw_dbg_buffer(ar, ev->messages,
+ (skb->len - 4)/sizeof(__le32));
+ spin_unlock_bh(&ar->data_lock);
return 0;
}
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index db25535..8d9b5b3 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6262,6 +6262,12 @@ struct wmi_svc_rdy_ev_arg {
const struct wlan_host_mem_req *mem_reqs[WMI_MAX_MEM_REQS];
};
+struct ath10k_fw_dbglog_report {
+ __le32 dropped_count;
+ __le32 messages[];
+} __packed;
+
+
struct wmi_rdy_ev_arg {
__le32 sw_version;
__le32 abi_version;
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 05/21] ath10k: save firmware debug log messages.
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
They may be dumped through the firmware dump debugfs
file.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.h | 18 ++++++
drivers/net/wireless/ath/ath10k/debug.c | 97 +++++++++++++++++++++++++++++++-
drivers/net/wireless/ath/ath10k/debug.h | 6 ++
drivers/net/wireless/ath/ath10k/hw.h | 21 +++++++
drivers/net/wireless/ath/ath10k/pci.c | 99 +++++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.c | 13 +++++
drivers/net/wireless/ath/ath10k/wmi.h | 6 ++
7 files changed, 258 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 1379054..7f9f460 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -404,6 +404,22 @@ struct ath10k_vif_iter {
struct ath10k_vif *arvif;
};
+/* This will store at least the last 128 entries. Each dbglog message
+ * is a max of 7 32-bit integers in length, but the length can be less
+ * than that as well.
+ */
+#define ATH10K_DBGLOG_DATA_LEN (128 * 7)
+struct ath10k_dbglog_entry_storage {
+ u32 head_idx; /* Where to write next chunk of data */
+ u32 tail_idx; /* Index of first msg */
+ __le32 data[ATH10K_DBGLOG_DATA_LEN];
+};
+
+/* Just enough info to decode firmware debug-log argument length */
+#define DBGLOG_NUM_ARGS_OFFSET 26
+#define DBGLOG_NUM_ARGS_MASK 0xFC000000 /* Bit 26-31 */
+#define DBGLOG_NUM_ARGS_MAX 5 /* firmware tool chain limit */
+
/* used for crash-dump storage, protected by data-lock */
struct ath10k_fw_crash_data {
bool crashed_since_read;
@@ -437,6 +453,8 @@ struct ath10k_debug {
u32 reg_addr;
u32 nf_cal_period;
+ struct ath10k_dbglog_entry_storage dbglog_entry_data;
+
struct ath10k_fw_crash_data *fw_crash_data;
};
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index d552a4a..1739687 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -35,10 +35,11 @@
/**
* enum ath10k_fw_crash_dump_type - types of data in the dump file
* @ATH10K_FW_CRASH_DUMP_REGDUMP: Register crash dump in binary format
+ * @ATH10K_FW_ERROR_DUMP_DBGLOG: Recent firmware debug log entries
*/
enum ath10k_fw_crash_dump_type {
ATH10K_FW_CRASH_DUMP_REGISTERS = 0,
-
+ ATH10K_FW_CRASH_DUMP_DBGLOG = 1,
ATH10K_FW_CRASH_DUMP_MAX,
};
@@ -109,6 +110,12 @@ struct ath10k_dump_file_data {
u8 data[0];
} __packed;
+struct ath10k_dbglog_entry_storage_user {
+ __le32 head_idx; /* Where to write next chunk of data */
+ __le32 tail_idx; /* Index of first msg */
+ __le32 data[ATH10K_DBGLOG_DATA_LEN];
+} __packed;
+
void ath10k_info(struct ath10k *ar, const char *fmt, ...)
{
struct va_format vaf = {
@@ -697,7 +704,6 @@ ath10k_debug_get_new_fw_crash_data(struct ath10k *ar)
lockdep_assert_held(&ar->data_lock);
- crash_data->crashed_since_read = true;
uuid_le_gen(&crash_data->uuid);
getnstimeofday(&crash_data->timestamp);
@@ -705,17 +711,87 @@ ath10k_debug_get_new_fw_crash_data(struct ath10k *ar)
}
EXPORT_SYMBOL(ath10k_debug_get_new_fw_crash_data);
+static void ath10k_dbg_drop_dbg_buffer(struct ath10k *ar)
+{
+ /* Find next message boundary */
+ u32 lg_hdr;
+ int acnt;
+ int tail_idx = ar->debug.dbglog_entry_data.tail_idx;
+ int h_idx = (tail_idx + 1) % ATH10K_DBGLOG_DATA_LEN;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ /* Log header is second 32-bit word */
+ lg_hdr = le32_to_cpu(ar->debug.dbglog_entry_data.data[h_idx]);
+
+ acnt = (lg_hdr & DBGLOG_NUM_ARGS_MASK) >> DBGLOG_NUM_ARGS_OFFSET;
+
+ if (acnt > DBGLOG_NUM_ARGS_MAX) {
+ /* Some sort of corruption it seems, recover as best we can. */
+ ath10k_err(ar, "invalid dbglog arg-count: %i %i %i\n",
+ acnt, ar->debug.dbglog_entry_data.tail_idx,
+ ar->debug.dbglog_entry_data.head_idx);
+ ar->debug.dbglog_entry_data.tail_idx =
+ ar->debug.dbglog_entry_data.head_idx;
+ return;
+ }
+
+ /* Move forward over the args and the two header fields */
+ ar->debug.dbglog_entry_data.tail_idx =
+ (tail_idx + acnt + 2) % ATH10K_DBGLOG_DATA_LEN;
+}
+
+void ath10k_dbg_save_fw_dbg_buffer(struct ath10k *ar, __le32 *buffer, int len)
+{
+ int i;
+ int z;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ z = ar->debug.dbglog_entry_data.head_idx;
+
+ /* Don't save any new logs until user-space reads this. */
+ if (ar->debug.fw_crash_data &&
+ ar->debug.fw_crash_data->crashed_since_read) {
+ ath10k_warn(ar, "dropping dbg buffer due to crash since read\n");
+ return;
+ }
+
+ for (i = 0; i < len; i++) {
+ ar->debug.dbglog_entry_data.data[z] = buffer[i];
+ z++;
+ if (z >= ATH10K_DBGLOG_DATA_LEN)
+ z = 0;
+
+ /* If we are about to over-write an old message, move the
+ * tail_idx to the next message. If idx's are same, we
+ * are empty.
+ */
+ if (z == ar->debug.dbglog_entry_data.tail_idx)
+ ath10k_dbg_drop_dbg_buffer(ar);
+
+ ar->debug.dbglog_entry_data.head_idx = z;
+ }
+}
+EXPORT_SYMBOL(ath10k_dbg_save_fw_dbg_buffer);
+
static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
{
struct ath10k_fw_crash_data *crash_data = ar->debug.fw_crash_data;
struct ath10k_dump_file_data *dump_data;
struct ath10k_tlv_dump_data *dump_tlv;
+ struct ath10k_dbglog_entry_storage_user *dbglog_storage;
int hdr_len = sizeof(*dump_data);
unsigned int len, sofar = 0;
unsigned char *buf;
+ int tmp;
+
+ BUILD_BUG_ON(sizeof(struct ath10k_dbglog_entry_storage) !=
+ sizeof(struct ath10k_dbglog_entry_storage_user));
len = hdr_len;
len += sizeof(*dump_tlv) + sizeof(crash_data->registers);
+ len += sizeof(*dump_tlv) + sizeof(ar->debug.dbglog_entry_data);
sofar += hdr_len;
@@ -774,8 +850,25 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
sizeof(crash_data->registers));
sofar += sizeof(*dump_tlv) + sizeof(crash_data->registers);
+ /* Gather dbg-log */
+ tmp = sizeof(ar->debug.dbglog_entry_data);
+ dump_tlv = (struct ath10k_tlv_dump_data *)(buf + sofar);
+ dump_tlv->type = cpu_to_le32(ATH10K_FW_CRASH_DUMP_DBGLOG);
+ dump_tlv->tlv_len = cpu_to_le32(tmp);
+ dbglog_storage =
+ (struct ath10k_dbglog_entry_storage_user *)(dump_tlv->tlv_data);
+ memcpy(dbglog_storage->data, ar->debug.dbglog_entry_data.data,
+ sizeof(dbglog_storage->data));
+ dbglog_storage->head_idx =
+ cpu_to_le32(ar->debug.dbglog_entry_data.head_idx);
+ dbglog_storage->tail_idx =
+ cpu_to_le32(ar->debug.dbglog_entry_data.tail_idx);
+
+ sofar += sizeof(*dump_tlv) + tmp;
+
ar->debug.fw_crash_data->crashed_since_read = false;
+ WARN_ON(sofar != len);
spin_unlock_bh(&ar->data_lock);
return dump_data;
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 75c89e3..3062948 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -94,7 +94,13 @@ int ath10k_debug_get_et_sset_count(struct ieee80211_hw *hw,
void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ethtool_stats *stats, u64 *data);
+
+void ath10k_dbg_save_fw_dbg_buffer(struct ath10k *ar, __le32 *buffer, int len);
#else
+static inline void ath10k_dbg_save_fw_dbg_buffer(struct ath10k *ar,
+ __le32 *buffer, int len)
+{
+}
static inline int ath10k_debug_start(struct ath10k *ar)
{
return 0;
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index aedd898..5bbef4b 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -681,4 +681,25 @@ enum ath10k_hw_4addr_pad {
#define RTC_STATE_V_GET(x) (((x) & RTC_STATE_V_MASK) >> RTC_STATE_V_LSB)
+/* Target debug log related defines and structs */
+
+/* Target is 32-bit CPU, so we just use u32 for
+ * the pointers. The memory space is relative to the
+ * target, not the host. Values are converted to host
+ * byte order when reading from firmware.
+ */
+struct ath10k_fw_dbglog_buf {
+ __le32 next; /* pointer to ath10k_fw_dbglog_buf. */
+ __le32 buffer; /* pointer to u8 buffer */
+ __le32 bufsize;
+ __le32 length;
+ __le32 count;
+ __le32 free;
+} __packed;
+
+struct ath10k_fw_dbglog_hdr {
+ __le32 dbuf; /* pointer to ath10k_fw_dbglog_buf */
+ __le32 dropped;
+} __packed;
+
#endif /* _HW_H_ */
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 8133d7b..16e32d0 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1439,6 +1439,102 @@ static void ath10k_pci_dump_registers(struct ath10k *ar,
crash_data->registers[i] = reg_dump_values[i];
}
+/**
+ * Read any not-yet-delivered debug-log buffers on the target
+ * and save them to storage in the host driver. Typically
+ * only done on crash, as firmware will normally deliver
+ * logs periodically on its own if it is functioning
+ * properly.
+ */
+static void ath10k_pci_dump_dbglog(struct ath10k *ar)
+{
+ struct ath10k_fw_dbglog_hdr dbg_hdr;
+ u32 dbufp; /* pointer in target memory space */
+ struct ath10k_fw_dbglog_buf dbuf;
+ u8 *buffer;
+ int ret;
+ int i;
+ int len;
+
+ ret = ath10k_pci_diag_read_hi(ar, &dbg_hdr, hi_dbglog_hdr,
+ sizeof(dbg_hdr));
+ if (ret != 0) {
+ ath10k_err(ar, "failed to dump debug log area: %d\n", ret);
+ return;
+ }
+
+ ath10k_dbg(ar, ATH10K_DBG_PCI,
+ "debug log header, dbuf: 0x%x dropped: %i\n",
+ le32_to_cpu(dbg_hdr.dbuf), le32_to_cpu(dbg_hdr.dropped));
+ dbufp = le32_to_cpu(dbg_hdr.dbuf);
+
+ /* i is for logging purposes and sanity check in case firmware buffers
+ * are corrupted and will not properly terminate the list.
+ * In standard firmware, it appears there are no more than 2
+ * buffers, so 10 should be safe upper limit even if firmware
+ * changes quite a bit.
+ */
+ i = 0;
+ while (dbufp && i < 10) {
+ ret = ath10k_pci_diag_read_mem(ar, dbufp, &dbuf, sizeof(dbuf));
+ if (ret != 0) {
+ ath10k_err(ar, "failed to read debug log area: %d (addr 0x%x)\n",
+ ret, dbufp);
+ return;
+ }
+
+ len = le32_to_cpu(dbuf.length);
+
+ ath10k_dbg(ar, ATH10K_DBG_PCI,
+ "[%i] next: 0x%x buf: 0x%x sz: %i len: %i count: %i free: %i\n",
+ i, le32_to_cpu(dbuf.next), le32_to_cpu(dbuf.buffer),
+ le32_to_cpu(dbuf.bufsize), len,
+ le32_to_cpu(dbuf.count), le32_to_cpu(dbuf.free));
+ if (dbuf.buffer == 0 || len == 0)
+ goto next;
+
+ /* Pick arbitrary upper bound in case firmware is corrupted for
+ * whatever reason.
+ */
+ if (len > 4096) {
+ ath10k_err(ar,
+ "debuglog buf length is out of bounds: %d\n",
+ len);
+ /* Do not trust the next pointer either... */
+ return;
+ }
+
+ buffer = kmalloc(len, GFP_ATOMIC);
+
+ if (!buffer)
+ goto next;
+
+ ret = ath10k_pci_diag_read_mem(ar, le32_to_cpu(dbuf.buffer),
+ buffer, len);
+ if (ret != 0) {
+ ath10k_err(ar, "failed to read debug log buffer: %d (addr 0x%x)\n",
+ ret, le32_to_cpu(dbuf.buffer));
+ kfree(buffer);
+ return;
+ }
+
+ WARN_ON(len & 0x3);
+
+ ath10k_dbg_save_fw_dbg_buffer(ar, (__le32 *)(buffer), len >> 2);
+ kfree(buffer);
+
+next:
+ dbufp = le32_to_cpu(dbuf.next);
+ if (dbufp == le32_to_cpu(dbg_hdr.dbuf)) {
+ /* It is a circular buffer it seems, bail if next
+ * is head
+ */
+ break;
+ }
+ i++;
+ } /* While we have a debug buffer to read */
+}
+
static void ath10k_pci_fw_crashed_dump(struct ath10k *ar)
{
struct ath10k_fw_crash_data *crash_data;
@@ -1458,6 +1554,9 @@ static void ath10k_pci_fw_crashed_dump(struct ath10k *ar)
ath10k_err(ar, "firmware crashed! (uuid %s)\n", uuid);
ath10k_print_driver_info(ar);
ath10k_pci_dump_registers(ar, crash_data);
+ ath10k_pci_dump_dbglog(ar);
+ if (crash_data)
+ crash_data->crashed_since_read = true;
spin_unlock_bh(&ar->data_lock);
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 621019f..1758b4a 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2492,10 +2492,23 @@ void ath10k_wmi_event_echo(struct ath10k *ar, struct sk_buff *skb)
int ath10k_wmi_event_debug_mesg(struct ath10k *ar, struct sk_buff *skb)
{
+ struct ath10k_fw_dbglog_report *ev;
+
ath10k_dbg(ar, ATH10K_DBG_WMI, "wmi event debug mesg len %d\n",
skb->len);
trace_ath10k_wmi_dbglog(ar, skb->data, skb->len);
+ ev = (struct ath10k_fw_dbglog_report *)skb->data;
+
+ spin_lock_bh(&ar->data_lock);
+ /* First 4 bytes are a messages-dropped-due-to-overflow counter,
+ * and should not be recorded in the dbglog buffer, so we skip
+ * them.
+ */
+ WARN_ON(skb->len & 0x3);
+ ath10k_dbg_save_fw_dbg_buffer(ar, ev->messages,
+ (skb->len - 4)/sizeof(__le32));
+ spin_unlock_bh(&ar->data_lock);
return 0;
}
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index db25535..8d9b5b3 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6262,6 +6262,12 @@ struct wmi_svc_rdy_ev_arg {
const struct wlan_host_mem_req *mem_reqs[WMI_MAX_MEM_REQS];
};
+struct ath10k_fw_dbglog_report {
+ __le32 dropped_count;
+ __le32 messages[];
+} __packed;
+
+
struct wmi_rdy_ev_arg {
__le32 sw_version;
__le32 abi_version;
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread
* [PATCH v2 06/21] ath10k: save firmware stacks upon firmware crash
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear, Kalle Valo
From: Ben Greear <greearb@candelatech.com>
Should help debug firmware crashes, and give users a way
to provide some useful debug reports to firmware developers.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.h | 4 +++
drivers/net/wireless/ath/ath10k/debug.c | 29 +++++++++++++++++-
drivers/net/wireless/ath/ath10k/hw.h | 2 ++
drivers/net/wireless/ath/ath10k/pci.c | 52 +++++++++++++++++++++++++++++++++
4 files changed, 86 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 7f9f460..644d077 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -427,6 +427,10 @@ struct ath10k_fw_crash_data {
uuid_le uuid;
struct timespec timestamp;
__le32 registers[REG_DUMP_COUNT_QCA988X];
+ __le32 stack_buf[ATH10K_FW_STACK_SIZE / sizeof(__le32)];
+ __le32 exc_stack_buf[ATH10K_FW_STACK_SIZE / sizeof(__le32)];
+ __le32 stack_addr;
+ __le32 exc_stack_addr;
};
struct ath10k_debug {
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 1739687..ec6db04 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -36,10 +36,15 @@
* enum ath10k_fw_crash_dump_type - types of data in the dump file
* @ATH10K_FW_CRASH_DUMP_REGDUMP: Register crash dump in binary format
* @ATH10K_FW_ERROR_DUMP_DBGLOG: Recent firmware debug log entries
+ * @ATH10K_FW_CRASH_DUMP_STACK: Stack memory contents.
+ * @ATH10K_FW_CRASH_DUMP_EXC_STACK: Exception stack memory contents.
*/
enum ath10k_fw_crash_dump_type {
ATH10K_FW_CRASH_DUMP_REGISTERS = 0,
ATH10K_FW_CRASH_DUMP_DBGLOG = 1,
+ ATH10K_FW_CRASH_DUMP_STACK = 2,
+ ATH10K_FW_CRASH_DUMP_EXC_STACK = 3,
+
ATH10K_FW_CRASH_DUMP_MAX,
};
@@ -103,8 +108,11 @@ struct ath10k_dump_file_data {
/* VERMAGIC_STRING */
char kernel_ver[64];
+ __le32 stack_addr;
+ __le32 exc_stack_addr;
+
/* room for growth w/out changing binary format */
- u8 unused[128];
+ u8 unused[120];
/* struct ath10k_tlv_dump_data + more */
u8 data[0];
@@ -792,6 +800,8 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
len = hdr_len;
len += sizeof(*dump_tlv) + sizeof(crash_data->registers);
len += sizeof(*dump_tlv) + sizeof(ar->debug.dbglog_entry_data);
+ len += sizeof(*dump_tlv) + sizeof(crash_data->stack_buf);
+ len += sizeof(*dump_tlv) + sizeof(crash_data->exc_stack_buf);
sofar += hdr_len;
@@ -831,6 +841,8 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
dump_data->ht_cap_info = cpu_to_le32(ar->ht_cap_info);
dump_data->vht_cap_info = cpu_to_le32(ar->vht_cap_info);
dump_data->num_rf_chains = cpu_to_le32(ar->num_rf_chains);
+ dump_data->stack_addr = cpu_to_le32(crash_data->stack_addr);
+ dump_data->exc_stack_addr = cpu_to_le32(crash_data->exc_stack_addr);
strlcpy(dump_data->fw_ver, ar->hw->wiphy->fw_version,
sizeof(dump_data->fw_ver));
@@ -863,7 +875,22 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
cpu_to_le32(ar->debug.dbglog_entry_data.head_idx);
dbglog_storage->tail_idx =
cpu_to_le32(ar->debug.dbglog_entry_data.tail_idx);
+ sofar += sizeof(*dump_tlv) + tmp;
+ /* Gather firmware stack dump */
+ tmp = sizeof(crash_data->stack_buf);
+ dump_tlv = (struct ath10k_tlv_dump_data *)(buf + sofar);
+ dump_tlv->type = cpu_to_le32(ATH10K_FW_CRASH_DUMP_STACK);
+ dump_tlv->tlv_len = cpu_to_le32(tmp);
+ memcpy(dump_tlv->tlv_data, crash_data->stack_buf, tmp);
+ sofar += sizeof(*dump_tlv) + tmp;
+
+ /* Gather firmware exception stack dump */
+ tmp = sizeof(crash_data->exc_stack_buf);
+ dump_tlv = (struct ath10k_tlv_dump_data *)(buf + sofar);
+ dump_tlv->type = cpu_to_le32(ATH10K_FW_CRASH_DUMP_EXC_STACK);
+ dump_tlv->tlv_len = cpu_to_le32(tmp);
+ memcpy(dump_tlv->tlv_data, crash_data->exc_stack_buf, tmp);
sofar += sizeof(*dump_tlv) + tmp;
ar->debug.fw_crash_data->crashed_since_read = false;
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 5bbef4b..e86ebf0 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -122,6 +122,8 @@ enum qca9377_chip_id_rev {
#define REG_DUMP_COUNT_QCA988X 60
+#define ATH10K_FW_STACK_SIZE 4096
+
struct ath10k_fw_ie {
__le32 id;
__le32 len;
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 16e32d0..62dd167 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -985,6 +985,22 @@ static int ath10k_pci_diag_read32(struct ath10k *ar, u32 address, u32 *value)
return ret;
}
+static int __ath10k_pci_diag_read_hi_addr(struct ath10k *ar, __le32 *dest,
+ u32 src)
+{
+ u32 host_addr;
+ int ret;
+
+ host_addr = host_interest_item_address(src);
+
+ ret = ath10k_pci_diag_read32(ar, host_addr, dest);
+ if (ret != 0) {
+ ath10k_warn(ar, "failed to get memcpy hi address for firmware address %d: %d\n",
+ src, ret);
+ }
+ return ret;
+}
+
static int __ath10k_pci_diag_read_hi(struct ath10k *ar, void *dest,
u32 src, u32 len)
{
@@ -1013,6 +1029,9 @@ static int __ath10k_pci_diag_read_hi(struct ath10k *ar, void *dest,
#define ath10k_pci_diag_read_hi(ar, dest, src, len) \
__ath10k_pci_diag_read_hi(ar, dest, HI_ITEM(src), len)
+#define ath10k_pci_diag_read_hi_addr(ar, dest, src) \
+ __ath10k_pci_diag_read_hi_addr(ar, dest, HI_ITEM(src))
+
int ath10k_pci_diag_write_mem(struct ath10k *ar, u32 address,
const void *data, int nbytes)
{
@@ -1405,6 +1424,37 @@ u16 ath10k_pci_hif_get_free_queue_number(struct ath10k *ar, u8 pipe)
return ath10k_ce_num_free_src_entries(ar_pci->pipe_info[pipe].ce_hdl);
}
+/* Save the main firmware stack */
+static void ath10k_pci_dump_stack(struct ath10k *ar,
+ struct ath10k_fw_crash_data *crash_data)
+{
+ if (!crash_data)
+ return;
+
+ lockdep_assert_held(&ar->data_lock);
+ BUILD_BUG_ON(ATH10K_FW_STACK_SIZE % 4);
+
+ ath10k_pci_diag_read_hi(ar, crash_data->stack_buf,
+ hi_stack, ATH10K_FW_STACK_SIZE);
+ ath10k_pci_diag_read_hi_addr(ar, &crash_data->stack_addr, hi_stack);
+}
+
+/* Save the exception firmware stack */
+static void ath10k_pci_dump_exc_stack(struct ath10k *ar,
+ struct ath10k_fw_crash_data *crash_data)
+{
+ if (!crash_data)
+ return;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ ath10k_pci_diag_read_hi(ar, crash_data->exc_stack_buf,
+ hi_err_stack, ATH10K_FW_STACK_SIZE);
+
+ ath10k_pci_diag_read_hi_addr(ar, &crash_data->exc_stack_addr,
+ hi_err_stack);
+}
+
static void ath10k_pci_dump_registers(struct ath10k *ar,
struct ath10k_fw_crash_data *crash_data)
{
@@ -1555,6 +1605,8 @@ static void ath10k_pci_fw_crashed_dump(struct ath10k *ar)
ath10k_print_driver_info(ar);
ath10k_pci_dump_registers(ar, crash_data);
ath10k_pci_dump_dbglog(ar);
+ ath10k_pci_dump_stack(ar, crash_data);
+ ath10k_pci_dump_exc_stack(ar, crash_data);
if (crash_data)
crash_data->crashed_since_read = true;
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 06/21] ath10k: save firmware stacks upon firmware crash
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless, Kalle Valo
From: Ben Greear <greearb@candelatech.com>
Should help debug firmware crashes, and give users a way
to provide some useful debug reports to firmware developers.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.h | 4 +++
drivers/net/wireless/ath/ath10k/debug.c | 29 +++++++++++++++++-
drivers/net/wireless/ath/ath10k/hw.h | 2 ++
drivers/net/wireless/ath/ath10k/pci.c | 52 +++++++++++++++++++++++++++++++++
4 files changed, 86 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 7f9f460..644d077 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -427,6 +427,10 @@ struct ath10k_fw_crash_data {
uuid_le uuid;
struct timespec timestamp;
__le32 registers[REG_DUMP_COUNT_QCA988X];
+ __le32 stack_buf[ATH10K_FW_STACK_SIZE / sizeof(__le32)];
+ __le32 exc_stack_buf[ATH10K_FW_STACK_SIZE / sizeof(__le32)];
+ __le32 stack_addr;
+ __le32 exc_stack_addr;
};
struct ath10k_debug {
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 1739687..ec6db04 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -36,10 +36,15 @@
* enum ath10k_fw_crash_dump_type - types of data in the dump file
* @ATH10K_FW_CRASH_DUMP_REGDUMP: Register crash dump in binary format
* @ATH10K_FW_ERROR_DUMP_DBGLOG: Recent firmware debug log entries
+ * @ATH10K_FW_CRASH_DUMP_STACK: Stack memory contents.
+ * @ATH10K_FW_CRASH_DUMP_EXC_STACK: Exception stack memory contents.
*/
enum ath10k_fw_crash_dump_type {
ATH10K_FW_CRASH_DUMP_REGISTERS = 0,
ATH10K_FW_CRASH_DUMP_DBGLOG = 1,
+ ATH10K_FW_CRASH_DUMP_STACK = 2,
+ ATH10K_FW_CRASH_DUMP_EXC_STACK = 3,
+
ATH10K_FW_CRASH_DUMP_MAX,
};
@@ -103,8 +108,11 @@ struct ath10k_dump_file_data {
/* VERMAGIC_STRING */
char kernel_ver[64];
+ __le32 stack_addr;
+ __le32 exc_stack_addr;
+
/* room for growth w/out changing binary format */
- u8 unused[128];
+ u8 unused[120];
/* struct ath10k_tlv_dump_data + more */
u8 data[0];
@@ -792,6 +800,8 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
len = hdr_len;
len += sizeof(*dump_tlv) + sizeof(crash_data->registers);
len += sizeof(*dump_tlv) + sizeof(ar->debug.dbglog_entry_data);
+ len += sizeof(*dump_tlv) + sizeof(crash_data->stack_buf);
+ len += sizeof(*dump_tlv) + sizeof(crash_data->exc_stack_buf);
sofar += hdr_len;
@@ -831,6 +841,8 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
dump_data->ht_cap_info = cpu_to_le32(ar->ht_cap_info);
dump_data->vht_cap_info = cpu_to_le32(ar->vht_cap_info);
dump_data->num_rf_chains = cpu_to_le32(ar->num_rf_chains);
+ dump_data->stack_addr = cpu_to_le32(crash_data->stack_addr);
+ dump_data->exc_stack_addr = cpu_to_le32(crash_data->exc_stack_addr);
strlcpy(dump_data->fw_ver, ar->hw->wiphy->fw_version,
sizeof(dump_data->fw_ver));
@@ -863,7 +875,22 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
cpu_to_le32(ar->debug.dbglog_entry_data.head_idx);
dbglog_storage->tail_idx =
cpu_to_le32(ar->debug.dbglog_entry_data.tail_idx);
+ sofar += sizeof(*dump_tlv) + tmp;
+ /* Gather firmware stack dump */
+ tmp = sizeof(crash_data->stack_buf);
+ dump_tlv = (struct ath10k_tlv_dump_data *)(buf + sofar);
+ dump_tlv->type = cpu_to_le32(ATH10K_FW_CRASH_DUMP_STACK);
+ dump_tlv->tlv_len = cpu_to_le32(tmp);
+ memcpy(dump_tlv->tlv_data, crash_data->stack_buf, tmp);
+ sofar += sizeof(*dump_tlv) + tmp;
+
+ /* Gather firmware exception stack dump */
+ tmp = sizeof(crash_data->exc_stack_buf);
+ dump_tlv = (struct ath10k_tlv_dump_data *)(buf + sofar);
+ dump_tlv->type = cpu_to_le32(ATH10K_FW_CRASH_DUMP_EXC_STACK);
+ dump_tlv->tlv_len = cpu_to_le32(tmp);
+ memcpy(dump_tlv->tlv_data, crash_data->exc_stack_buf, tmp);
sofar += sizeof(*dump_tlv) + tmp;
ar->debug.fw_crash_data->crashed_since_read = false;
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 5bbef4b..e86ebf0 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -122,6 +122,8 @@ enum qca9377_chip_id_rev {
#define REG_DUMP_COUNT_QCA988X 60
+#define ATH10K_FW_STACK_SIZE 4096
+
struct ath10k_fw_ie {
__le32 id;
__le32 len;
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 16e32d0..62dd167 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -985,6 +985,22 @@ static int ath10k_pci_diag_read32(struct ath10k *ar, u32 address, u32 *value)
return ret;
}
+static int __ath10k_pci_diag_read_hi_addr(struct ath10k *ar, __le32 *dest,
+ u32 src)
+{
+ u32 host_addr;
+ int ret;
+
+ host_addr = host_interest_item_address(src);
+
+ ret = ath10k_pci_diag_read32(ar, host_addr, dest);
+ if (ret != 0) {
+ ath10k_warn(ar, "failed to get memcpy hi address for firmware address %d: %d\n",
+ src, ret);
+ }
+ return ret;
+}
+
static int __ath10k_pci_diag_read_hi(struct ath10k *ar, void *dest,
u32 src, u32 len)
{
@@ -1013,6 +1029,9 @@ static int __ath10k_pci_diag_read_hi(struct ath10k *ar, void *dest,
#define ath10k_pci_diag_read_hi(ar, dest, src, len) \
__ath10k_pci_diag_read_hi(ar, dest, HI_ITEM(src), len)
+#define ath10k_pci_diag_read_hi_addr(ar, dest, src) \
+ __ath10k_pci_diag_read_hi_addr(ar, dest, HI_ITEM(src))
+
int ath10k_pci_diag_write_mem(struct ath10k *ar, u32 address,
const void *data, int nbytes)
{
@@ -1405,6 +1424,37 @@ u16 ath10k_pci_hif_get_free_queue_number(struct ath10k *ar, u8 pipe)
return ath10k_ce_num_free_src_entries(ar_pci->pipe_info[pipe].ce_hdl);
}
+/* Save the main firmware stack */
+static void ath10k_pci_dump_stack(struct ath10k *ar,
+ struct ath10k_fw_crash_data *crash_data)
+{
+ if (!crash_data)
+ return;
+
+ lockdep_assert_held(&ar->data_lock);
+ BUILD_BUG_ON(ATH10K_FW_STACK_SIZE % 4);
+
+ ath10k_pci_diag_read_hi(ar, crash_data->stack_buf,
+ hi_stack, ATH10K_FW_STACK_SIZE);
+ ath10k_pci_diag_read_hi_addr(ar, &crash_data->stack_addr, hi_stack);
+}
+
+/* Save the exception firmware stack */
+static void ath10k_pci_dump_exc_stack(struct ath10k *ar,
+ struct ath10k_fw_crash_data *crash_data)
+{
+ if (!crash_data)
+ return;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ ath10k_pci_diag_read_hi(ar, crash_data->exc_stack_buf,
+ hi_err_stack, ATH10K_FW_STACK_SIZE);
+
+ ath10k_pci_diag_read_hi_addr(ar, &crash_data->exc_stack_addr,
+ hi_err_stack);
+}
+
static void ath10k_pci_dump_registers(struct ath10k *ar,
struct ath10k_fw_crash_data *crash_data)
{
@@ -1555,6 +1605,8 @@ static void ath10k_pci_fw_crashed_dump(struct ath10k *ar)
ath10k_print_driver_info(ar);
ath10k_pci_dump_registers(ar, crash_data);
ath10k_pci_dump_dbglog(ar);
+ ath10k_pci_dump_stack(ar, crash_data);
+ ath10k_pci_dump_exc_stack(ar, crash_data);
if (crash_data)
crash_data->crashed_since_read = true;
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread
* [PATCH v2 07/21] ath10k: save firmware RAM and ROM BSS sections on crash
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear, Kalle Valo
From: Ben Greear <greearb@candelatech.com>
This can be used to get a useful back trace out of a firmware
crash that involves an interrupt handler. For instance, a
null-pointer-exception would be this kind of trace. A user-space
tool can read the debugfs file and decode things as wished.
This requires a packaged firmware with a new IE to describe the
BSS section starts and length.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.c | 48 +++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/core.h | 14 +++++++++
drivers/net/wireless/ath/ath10k/debug.c | 40 +++++++++++++++++++++++-
drivers/net/wireless/ath/ath10k/hw.h | 2 ++
drivers/net/wireless/ath/ath10k/pci.c | 54 +++++++++++++++++++++++++++++++++
5 files changed, 157 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index b7318b8..3f1786c 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -922,6 +922,13 @@ err:
return ret;
}
+struct ath10k_bss_rom_ie {
+ __le32 ram_addr;
+ __le32 ram_len;
+ __le32 rom_addr;
+ __le32 rom_len;
+} __packed;
+
static int ath10k_core_create_board_name(struct ath10k *ar, char *name,
size_t name_len)
{
@@ -983,6 +990,7 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, const char *name,
struct ath10k_fw_ie *hdr;
const u8 *data;
__le32 *timestamp, *version;
+ struct ath10k_bss_rom_ie *bss;
/* first fetch the firmware file (firmware-*.bin) */
fw_file->firmware = ath10k_fetch_fw_file(ar, ar->hw_params.fw.dir,
@@ -1100,6 +1108,12 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, const char *name,
break;
case ATH10K_FW_IE_WMI_OP_VERSION:
+ /* Upstream stole the ID CT firmware was using, so add
+ * hack-around to deal with backwards-compat. --Ben
+ */
+ if (ie_len >= sizeof(*bss))
+ goto fw_ie_bss_info_ct;
+
if (ie_len != sizeof(u32))
break;
@@ -1128,6 +1142,40 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, const char *name,
fw_file->codeswap_data = data;
fw_file->codeswap_len = ie_len;
break;
+ case ATH10K_FW_IE_BSS_INFO_CT:
+fw_ie_bss_info_ct:
+ if (ie_len < sizeof(*bss)) {
+ ath10k_warn(ar, "invalid ie len for bss-info (%zd)\n",
+ ie_len);
+ break;
+ }
+ bss = (struct ath10k_bss_rom_ie *)(data);
+
+ fw_file->ram_bss_addr = le32_to_cpu(bss->ram_addr);
+ fw_file->ram_bss_len = le32_to_cpu(bss->ram_len);
+ ath10k_dbg(ar, ATH10K_DBG_BOOT,
+ "found RAM BSS addr 0x%x length %d\n",
+ fw_file->ram_bss_addr, fw_file->ram_bss_len);
+
+ if (fw_file->ram_bss_len > ATH10K_RAM_BSS_BUF_LEN) {
+ ath10k_warn(ar, "too long firmware RAM BSS length: %d\n",
+ fw_file->ram_bss_len);
+ fw_file->ram_bss_len = 0;
+ }
+
+ fw_file->rom_bss_addr = le32_to_cpu(bss->rom_addr);
+ fw_file->rom_bss_len = le32_to_cpu(bss->rom_len);
+ ath10k_dbg(ar, ATH10K_DBG_BOOT,
+ "found ROM BSS addr 0x%x length %d\n",
+ fw_file->rom_bss_addr, fw_file->rom_bss_len);
+
+ if (fw_file->rom_bss_len > ATH10K_ROM_BSS_BUF_LEN) {
+ ath10k_warn(ar, "too long firmware ROM BSS length: %d\n",
+ fw_file->rom_bss_len);
+ fw_file->rom_bss_len = 0;
+ }
+
+ break;
default:
ath10k_warn(ar, "Unknown FW IE: %u\n",
le32_to_cpu(hdr->id));
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 644d077..6aa7a14 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -420,6 +420,10 @@ struct ath10k_dbglog_entry_storage {
#define DBGLOG_NUM_ARGS_MASK 0xFC000000 /* Bit 26-31 */
#define DBGLOG_NUM_ARGS_MAX 5 /* firmware tool chain limit */
+/* estimated values, hopefully these are enough */
+#define ATH10K_ROM_BSS_BUF_LEN 30000
+#define ATH10K_RAM_BSS_BUF_LEN 10000
+
/* used for crash-dump storage, protected by data-lock */
struct ath10k_fw_crash_data {
bool crashed_since_read;
@@ -431,6 +435,8 @@ struct ath10k_fw_crash_data {
__le32 exc_stack_buf[ATH10K_FW_STACK_SIZE / sizeof(__le32)];
__le32 stack_addr;
__le32 exc_stack_addr;
+ __le32 rom_bss_buf[ATH10K_ROM_BSS_BUF_LEN / sizeof(__le32)];
+ __le32 ram_bss_buf[ATH10K_RAM_BSS_BUF_LEN / sizeof(__le32)];
};
struct ath10k_debug {
@@ -666,6 +672,14 @@ struct ath10k_fw_file {
const void *codeswap_data;
size_t codeswap_len;
+
+ /* These are written to only during first firmware load from user
+ * space so no need for any locking.
+ */
+ u32 ram_bss_addr;
+ u32 ram_bss_len;
+ u32 rom_bss_addr;
+ u32 rom_bss_len;
};
struct ath10k_fw_components {
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index ec6db04..c7bff1e 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -38,12 +38,16 @@
* @ATH10K_FW_ERROR_DUMP_DBGLOG: Recent firmware debug log entries
* @ATH10K_FW_CRASH_DUMP_STACK: Stack memory contents.
* @ATH10K_FW_CRASH_DUMP_EXC_STACK: Exception stack memory contents.
+ * @ATH10K_FW_CRASH_DUMP_RAM_BSS: BSS area for RAM code
+ * @ATH10K_FW_CRASH_DUMP_ROM_BSS: BSS area for ROM code
*/
enum ath10k_fw_crash_dump_type {
ATH10K_FW_CRASH_DUMP_REGISTERS = 0,
ATH10K_FW_CRASH_DUMP_DBGLOG = 1,
ATH10K_FW_CRASH_DUMP_STACK = 2,
ATH10K_FW_CRASH_DUMP_EXC_STACK = 3,
+ ATH10K_FW_CRASH_DUMP_RAM_BSS = 4,
+ ATH10K_FW_CRASH_DUMP_ROM_BSS = 5,
ATH10K_FW_CRASH_DUMP_MAX,
};
@@ -110,9 +114,11 @@ struct ath10k_dump_file_data {
__le32 stack_addr;
__le32 exc_stack_addr;
+ __le32 rom_bss_addr;
+ __le32 ram_bss_addr;
/* room for growth w/out changing binary format */
- u8 unused[120];
+ u8 unused[112];
/* struct ath10k_tlv_dump_data + more */
u8 data[0];
@@ -803,6 +809,14 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
len += sizeof(*dump_tlv) + sizeof(crash_data->stack_buf);
len += sizeof(*dump_tlv) + sizeof(crash_data->exc_stack_buf);
+ if (ar->running_fw->fw_file.ram_bss_addr &&
+ ar->running_fw->fw_file.ram_bss_len)
+ len += sizeof(*dump_tlv) + ar->running_fw->fw_file.ram_bss_len;
+
+ if (ar->running_fw->fw_file.rom_bss_addr &&
+ ar->running_fw->fw_file.rom_bss_len)
+ len += sizeof(*dump_tlv) + ar->running_fw->fw_file.rom_bss_len;
+
sofar += hdr_len;
/* This is going to get big when we start dumping FW RAM and such,
@@ -843,6 +857,10 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
dump_data->num_rf_chains = cpu_to_le32(ar->num_rf_chains);
dump_data->stack_addr = cpu_to_le32(crash_data->stack_addr);
dump_data->exc_stack_addr = cpu_to_le32(crash_data->exc_stack_addr);
+ dump_data->rom_bss_addr =
+ cpu_to_le32(ar->running_fw->fw_file.rom_bss_addr);
+ dump_data->ram_bss_addr =
+ cpu_to_le32(ar->running_fw->fw_file.ram_bss_addr);
strlcpy(dump_data->fw_ver, ar->hw->wiphy->fw_version,
sizeof(dump_data->fw_ver));
@@ -893,6 +911,26 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
memcpy(dump_tlv->tlv_data, crash_data->exc_stack_buf, tmp);
sofar += sizeof(*dump_tlv) + tmp;
+ if (ar->running_fw->fw_file.ram_bss_addr &&
+ ar->running_fw->fw_file.ram_bss_len) {
+ tmp = ar->running_fw->fw_file.ram_bss_len;
+ dump_tlv = (struct ath10k_tlv_dump_data *)(buf + sofar);
+ dump_tlv->type = cpu_to_le32(ATH10K_FW_CRASH_DUMP_RAM_BSS);
+ dump_tlv->tlv_len = cpu_to_le32(tmp);
+ memcpy(dump_tlv->tlv_data, crash_data->ram_bss_buf, tmp);
+ sofar += sizeof(*dump_tlv) + tmp;
+ }
+
+ if (ar->running_fw->fw_file.rom_bss_addr &&
+ ar->running_fw->fw_file.rom_bss_len) {
+ tmp = ar->running_fw->fw_file.rom_bss_len;
+ dump_tlv = (struct ath10k_tlv_dump_data *)(buf + sofar);
+ dump_tlv->type = cpu_to_le32(ATH10K_FW_CRASH_DUMP_ROM_BSS);
+ dump_tlv->tlv_len = cpu_to_le32(tmp);
+ memcpy(dump_tlv->tlv_data, crash_data->rom_bss_buf, tmp);
+ sofar += sizeof(*dump_tlv) + tmp;
+ }
+
ar->debug.fw_crash_data->crashed_since_read = false;
WARN_ON(sofar != len);
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index e86ebf0..7b80e29 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -149,6 +149,8 @@ enum ath10k_fw_ie_type {
/* Code swap image for firmware binary */
ATH10K_FW_IE_FW_CODE_SWAP_IMAGE = 7,
+
+ ATH10K_FW_IE_BSS_INFO_CT = 30,
};
enum ath10k_fw_wmi_op_version {
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 62dd167..e6315ec 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1424,6 +1424,58 @@ u16 ath10k_pci_hif_get_free_queue_number(struct ath10k *ar, u8 pipe)
return ath10k_ce_num_free_src_entries(ar_pci->pipe_info[pipe].ce_hdl);
}
+static void ath10k_pci_dump_bss_ram(struct ath10k *ar,
+ struct ath10k_fw_crash_data *crash_data)
+{
+ int ret;
+
+ if (!crash_data)
+ return;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ if (!ar->running_fw->fw_file.ram_bss_addr)
+ return;
+
+ if (!ar->running_fw->fw_file.ram_bss_len)
+ return;
+
+ ret = ath10k_pci_diag_read_mem(ar, ar->running_fw->fw_file.ram_bss_addr,
+ crash_data->ram_bss_buf,
+ ar->running_fw->fw_file.ram_bss_len);
+ if (ret)
+ ath10k_warn(ar,
+ "failed to read firmware RAM BSS memory from %d (%d B): %d\n",
+ ar->running_fw->fw_file.ram_bss_addr,
+ ar->running_fw->fw_file.ram_bss_len, ret);
+}
+
+static void ath10k_pci_dump_bss_rom(struct ath10k *ar,
+ struct ath10k_fw_crash_data *crash_data)
+{
+ int ret;
+
+ if (!crash_data)
+ return;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ if (!ar->running_fw->fw_file.rom_bss_addr)
+ return;
+
+ if (!ar->running_fw->fw_file.rom_bss_len)
+ return;
+
+ ret = ath10k_pci_diag_read_mem(ar, ar->running_fw->fw_file.rom_bss_addr,
+ crash_data->rom_bss_buf,
+ ar->running_fw->fw_file.rom_bss_len);
+ if (ret)
+ ath10k_warn(ar,
+ "failed to read firmware ROM BSS memory from %d (%d B): %d\n",
+ ar->running_fw->fw_file.rom_bss_addr,
+ ar->running_fw->fw_file.rom_bss_len, ret);
+}
+
/* Save the main firmware stack */
static void ath10k_pci_dump_stack(struct ath10k *ar,
struct ath10k_fw_crash_data *crash_data)
@@ -1607,6 +1659,8 @@ static void ath10k_pci_fw_crashed_dump(struct ath10k *ar)
ath10k_pci_dump_dbglog(ar);
ath10k_pci_dump_stack(ar, crash_data);
ath10k_pci_dump_exc_stack(ar, crash_data);
+ ath10k_pci_dump_bss_ram(ar, crash_data);
+ ath10k_pci_dump_bss_rom(ar, crash_data);
if (crash_data)
crash_data->crashed_since_read = true;
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 07/21] ath10k: save firmware RAM and ROM BSS sections on crash
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless, Kalle Valo
From: Ben Greear <greearb@candelatech.com>
This can be used to get a useful back trace out of a firmware
crash that involves an interrupt handler. For instance, a
null-pointer-exception would be this kind of trace. A user-space
tool can read the debugfs file and decode things as wished.
This requires a packaged firmware with a new IE to describe the
BSS section starts and length.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.c | 48 +++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/core.h | 14 +++++++++
drivers/net/wireless/ath/ath10k/debug.c | 40 +++++++++++++++++++++++-
drivers/net/wireless/ath/ath10k/hw.h | 2 ++
drivers/net/wireless/ath/ath10k/pci.c | 54 +++++++++++++++++++++++++++++++++
5 files changed, 157 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index b7318b8..3f1786c 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -922,6 +922,13 @@ err:
return ret;
}
+struct ath10k_bss_rom_ie {
+ __le32 ram_addr;
+ __le32 ram_len;
+ __le32 rom_addr;
+ __le32 rom_len;
+} __packed;
+
static int ath10k_core_create_board_name(struct ath10k *ar, char *name,
size_t name_len)
{
@@ -983,6 +990,7 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, const char *name,
struct ath10k_fw_ie *hdr;
const u8 *data;
__le32 *timestamp, *version;
+ struct ath10k_bss_rom_ie *bss;
/* first fetch the firmware file (firmware-*.bin) */
fw_file->firmware = ath10k_fetch_fw_file(ar, ar->hw_params.fw.dir,
@@ -1100,6 +1108,12 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, const char *name,
break;
case ATH10K_FW_IE_WMI_OP_VERSION:
+ /* Upstream stole the ID CT firmware was using, so add
+ * hack-around to deal with backwards-compat. --Ben
+ */
+ if (ie_len >= sizeof(*bss))
+ goto fw_ie_bss_info_ct;
+
if (ie_len != sizeof(u32))
break;
@@ -1128,6 +1142,40 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, const char *name,
fw_file->codeswap_data = data;
fw_file->codeswap_len = ie_len;
break;
+ case ATH10K_FW_IE_BSS_INFO_CT:
+fw_ie_bss_info_ct:
+ if (ie_len < sizeof(*bss)) {
+ ath10k_warn(ar, "invalid ie len for bss-info (%zd)\n",
+ ie_len);
+ break;
+ }
+ bss = (struct ath10k_bss_rom_ie *)(data);
+
+ fw_file->ram_bss_addr = le32_to_cpu(bss->ram_addr);
+ fw_file->ram_bss_len = le32_to_cpu(bss->ram_len);
+ ath10k_dbg(ar, ATH10K_DBG_BOOT,
+ "found RAM BSS addr 0x%x length %d\n",
+ fw_file->ram_bss_addr, fw_file->ram_bss_len);
+
+ if (fw_file->ram_bss_len > ATH10K_RAM_BSS_BUF_LEN) {
+ ath10k_warn(ar, "too long firmware RAM BSS length: %d\n",
+ fw_file->ram_bss_len);
+ fw_file->ram_bss_len = 0;
+ }
+
+ fw_file->rom_bss_addr = le32_to_cpu(bss->rom_addr);
+ fw_file->rom_bss_len = le32_to_cpu(bss->rom_len);
+ ath10k_dbg(ar, ATH10K_DBG_BOOT,
+ "found ROM BSS addr 0x%x length %d\n",
+ fw_file->rom_bss_addr, fw_file->rom_bss_len);
+
+ if (fw_file->rom_bss_len > ATH10K_ROM_BSS_BUF_LEN) {
+ ath10k_warn(ar, "too long firmware ROM BSS length: %d\n",
+ fw_file->rom_bss_len);
+ fw_file->rom_bss_len = 0;
+ }
+
+ break;
default:
ath10k_warn(ar, "Unknown FW IE: %u\n",
le32_to_cpu(hdr->id));
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 644d077..6aa7a14 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -420,6 +420,10 @@ struct ath10k_dbglog_entry_storage {
#define DBGLOG_NUM_ARGS_MASK 0xFC000000 /* Bit 26-31 */
#define DBGLOG_NUM_ARGS_MAX 5 /* firmware tool chain limit */
+/* estimated values, hopefully these are enough */
+#define ATH10K_ROM_BSS_BUF_LEN 30000
+#define ATH10K_RAM_BSS_BUF_LEN 10000
+
/* used for crash-dump storage, protected by data-lock */
struct ath10k_fw_crash_data {
bool crashed_since_read;
@@ -431,6 +435,8 @@ struct ath10k_fw_crash_data {
__le32 exc_stack_buf[ATH10K_FW_STACK_SIZE / sizeof(__le32)];
__le32 stack_addr;
__le32 exc_stack_addr;
+ __le32 rom_bss_buf[ATH10K_ROM_BSS_BUF_LEN / sizeof(__le32)];
+ __le32 ram_bss_buf[ATH10K_RAM_BSS_BUF_LEN / sizeof(__le32)];
};
struct ath10k_debug {
@@ -666,6 +672,14 @@ struct ath10k_fw_file {
const void *codeswap_data;
size_t codeswap_len;
+
+ /* These are written to only during first firmware load from user
+ * space so no need for any locking.
+ */
+ u32 ram_bss_addr;
+ u32 ram_bss_len;
+ u32 rom_bss_addr;
+ u32 rom_bss_len;
};
struct ath10k_fw_components {
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index ec6db04..c7bff1e 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -38,12 +38,16 @@
* @ATH10K_FW_ERROR_DUMP_DBGLOG: Recent firmware debug log entries
* @ATH10K_FW_CRASH_DUMP_STACK: Stack memory contents.
* @ATH10K_FW_CRASH_DUMP_EXC_STACK: Exception stack memory contents.
+ * @ATH10K_FW_CRASH_DUMP_RAM_BSS: BSS area for RAM code
+ * @ATH10K_FW_CRASH_DUMP_ROM_BSS: BSS area for ROM code
*/
enum ath10k_fw_crash_dump_type {
ATH10K_FW_CRASH_DUMP_REGISTERS = 0,
ATH10K_FW_CRASH_DUMP_DBGLOG = 1,
ATH10K_FW_CRASH_DUMP_STACK = 2,
ATH10K_FW_CRASH_DUMP_EXC_STACK = 3,
+ ATH10K_FW_CRASH_DUMP_RAM_BSS = 4,
+ ATH10K_FW_CRASH_DUMP_ROM_BSS = 5,
ATH10K_FW_CRASH_DUMP_MAX,
};
@@ -110,9 +114,11 @@ struct ath10k_dump_file_data {
__le32 stack_addr;
__le32 exc_stack_addr;
+ __le32 rom_bss_addr;
+ __le32 ram_bss_addr;
/* room for growth w/out changing binary format */
- u8 unused[120];
+ u8 unused[112];
/* struct ath10k_tlv_dump_data + more */
u8 data[0];
@@ -803,6 +809,14 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
len += sizeof(*dump_tlv) + sizeof(crash_data->stack_buf);
len += sizeof(*dump_tlv) + sizeof(crash_data->exc_stack_buf);
+ if (ar->running_fw->fw_file.ram_bss_addr &&
+ ar->running_fw->fw_file.ram_bss_len)
+ len += sizeof(*dump_tlv) + ar->running_fw->fw_file.ram_bss_len;
+
+ if (ar->running_fw->fw_file.rom_bss_addr &&
+ ar->running_fw->fw_file.rom_bss_len)
+ len += sizeof(*dump_tlv) + ar->running_fw->fw_file.rom_bss_len;
+
sofar += hdr_len;
/* This is going to get big when we start dumping FW RAM and such,
@@ -843,6 +857,10 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
dump_data->num_rf_chains = cpu_to_le32(ar->num_rf_chains);
dump_data->stack_addr = cpu_to_le32(crash_data->stack_addr);
dump_data->exc_stack_addr = cpu_to_le32(crash_data->exc_stack_addr);
+ dump_data->rom_bss_addr =
+ cpu_to_le32(ar->running_fw->fw_file.rom_bss_addr);
+ dump_data->ram_bss_addr =
+ cpu_to_le32(ar->running_fw->fw_file.ram_bss_addr);
strlcpy(dump_data->fw_ver, ar->hw->wiphy->fw_version,
sizeof(dump_data->fw_ver));
@@ -893,6 +911,26 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
memcpy(dump_tlv->tlv_data, crash_data->exc_stack_buf, tmp);
sofar += sizeof(*dump_tlv) + tmp;
+ if (ar->running_fw->fw_file.ram_bss_addr &&
+ ar->running_fw->fw_file.ram_bss_len) {
+ tmp = ar->running_fw->fw_file.ram_bss_len;
+ dump_tlv = (struct ath10k_tlv_dump_data *)(buf + sofar);
+ dump_tlv->type = cpu_to_le32(ATH10K_FW_CRASH_DUMP_RAM_BSS);
+ dump_tlv->tlv_len = cpu_to_le32(tmp);
+ memcpy(dump_tlv->tlv_data, crash_data->ram_bss_buf, tmp);
+ sofar += sizeof(*dump_tlv) + tmp;
+ }
+
+ if (ar->running_fw->fw_file.rom_bss_addr &&
+ ar->running_fw->fw_file.rom_bss_len) {
+ tmp = ar->running_fw->fw_file.rom_bss_len;
+ dump_tlv = (struct ath10k_tlv_dump_data *)(buf + sofar);
+ dump_tlv->type = cpu_to_le32(ATH10K_FW_CRASH_DUMP_ROM_BSS);
+ dump_tlv->tlv_len = cpu_to_le32(tmp);
+ memcpy(dump_tlv->tlv_data, crash_data->rom_bss_buf, tmp);
+ sofar += sizeof(*dump_tlv) + tmp;
+ }
+
ar->debug.fw_crash_data->crashed_since_read = false;
WARN_ON(sofar != len);
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index e86ebf0..7b80e29 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -149,6 +149,8 @@ enum ath10k_fw_ie_type {
/* Code swap image for firmware binary */
ATH10K_FW_IE_FW_CODE_SWAP_IMAGE = 7,
+
+ ATH10K_FW_IE_BSS_INFO_CT = 30,
};
enum ath10k_fw_wmi_op_version {
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 62dd167..e6315ec 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1424,6 +1424,58 @@ u16 ath10k_pci_hif_get_free_queue_number(struct ath10k *ar, u8 pipe)
return ath10k_ce_num_free_src_entries(ar_pci->pipe_info[pipe].ce_hdl);
}
+static void ath10k_pci_dump_bss_ram(struct ath10k *ar,
+ struct ath10k_fw_crash_data *crash_data)
+{
+ int ret;
+
+ if (!crash_data)
+ return;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ if (!ar->running_fw->fw_file.ram_bss_addr)
+ return;
+
+ if (!ar->running_fw->fw_file.ram_bss_len)
+ return;
+
+ ret = ath10k_pci_diag_read_mem(ar, ar->running_fw->fw_file.ram_bss_addr,
+ crash_data->ram_bss_buf,
+ ar->running_fw->fw_file.ram_bss_len);
+ if (ret)
+ ath10k_warn(ar,
+ "failed to read firmware RAM BSS memory from %d (%d B): %d\n",
+ ar->running_fw->fw_file.ram_bss_addr,
+ ar->running_fw->fw_file.ram_bss_len, ret);
+}
+
+static void ath10k_pci_dump_bss_rom(struct ath10k *ar,
+ struct ath10k_fw_crash_data *crash_data)
+{
+ int ret;
+
+ if (!crash_data)
+ return;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ if (!ar->running_fw->fw_file.rom_bss_addr)
+ return;
+
+ if (!ar->running_fw->fw_file.rom_bss_len)
+ return;
+
+ ret = ath10k_pci_diag_read_mem(ar, ar->running_fw->fw_file.rom_bss_addr,
+ crash_data->rom_bss_buf,
+ ar->running_fw->fw_file.rom_bss_len);
+ if (ret)
+ ath10k_warn(ar,
+ "failed to read firmware ROM BSS memory from %d (%d B): %d\n",
+ ar->running_fw->fw_file.rom_bss_addr,
+ ar->running_fw->fw_file.rom_bss_len, ret);
+}
+
/* Save the main firmware stack */
static void ath10k_pci_dump_stack(struct ath10k *ar,
struct ath10k_fw_crash_data *crash_data)
@@ -1607,6 +1659,8 @@ static void ath10k_pci_fw_crashed_dump(struct ath10k *ar)
ath10k_pci_dump_dbglog(ar);
ath10k_pci_dump_stack(ar, crash_data);
ath10k_pci_dump_exc_stack(ar, crash_data);
+ ath10k_pci_dump_bss_ram(ar, crash_data);
+ ath10k_pci_dump_bss_rom(ar, crash_data);
if (crash_data)
crash_data->crashed_since_read = true;
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread
* [PATCH v2 08/21] ath10k: make firmware text debug messages more verbose.
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
There are not many of these messages producted by the
firmware, but they are generally fairly useful, so print
them at info level.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 1758b4a..d9e4b77 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -4050,7 +4050,7 @@ void ath10k_wmi_event_debug_print(struct ath10k *ar, struct sk_buff *skb)
/* the last byte is always reserved for the null character */
buf[i] = '\0';
- ath10k_dbg(ar, ATH10K_DBG_WMI_PRINT, "wmi print '%s'\n", buf);
+ ath10k_info(ar, "wmi print '%s'\n", buf);
}
void ath10k_wmi_event_pdev_qvit(struct ath10k *ar, struct sk_buff *skb)
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread
* [PATCH v2 08/21] ath10k: make firmware text debug messages more verbose.
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
There are not many of these messages producted by the
firmware, but they are generally fairly useful, so print
them at info level.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 1758b4a..d9e4b77 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -4050,7 +4050,7 @@ void ath10k_wmi_event_debug_print(struct ath10k *ar, struct sk_buff *skb)
/* the last byte is always reserved for the null character */
buf[i] = '\0';
- ath10k_dbg(ar, ATH10K_DBG_WMI_PRINT, "wmi print '%s'\n", buf);
+ ath10k_info(ar, "wmi print '%s'\n", buf);
}
void ath10k_wmi_event_pdev_qvit(struct ath10k *ar, struct sk_buff *skb)
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread
* Re: [PATCH v2 08/21] ath10k: make firmware text debug messages more verbose.
2016-05-11 17:02 ` greearb
@ 2016-09-14 14:12 ` Valo, Kalle
-1 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 14:12 UTC (permalink / raw)
To: greearb; +Cc: ath10k, linux-wireless
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> There are not many of these messages producted by the
> firmware, but they are generally fairly useful, so print
> them at info level.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless=
/ath/ath10k/wmi.c
> index 1758b4a..d9e4b77 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -4050,7 +4050,7 @@ void ath10k_wmi_event_debug_print(struct ath10k *ar=
, struct sk_buff *skb)
> /* the last byte is always reserved for the null character */
> buf[i] =3D '\0';
> =20
> - ath10k_dbg(ar, ATH10K_DBG_WMI_PRINT, "wmi print '%s'\n", buf);
> + ath10k_info(ar, "wmi print '%s'\n", buf);
Useful to whom and how? I understand that for firmware developers this
is very valuable information and that's why we have a special debug
level for it. But I suspect that for normal users these are just
confusing and unnecessarily spam the log.
--=20
Kalle Valo=
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 08/21] ath10k: make firmware text debug messages more verbose.
@ 2016-09-14 14:12 ` Valo, Kalle
0 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 14:12 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath10k
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> There are not many of these messages producted by the
> firmware, but they are generally fairly useful, so print
> them at info level.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> index 1758b4a..d9e4b77 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -4050,7 +4050,7 @@ void ath10k_wmi_event_debug_print(struct ath10k *ar, struct sk_buff *skb)
> /* the last byte is always reserved for the null character */
> buf[i] = '\0';
>
> - ath10k_dbg(ar, ATH10K_DBG_WMI_PRINT, "wmi print '%s'\n", buf);
> + ath10k_info(ar, "wmi print '%s'\n", buf);
Useful to whom and how? I understand that for firmware developers this
is very valuable information and that's why we have a special debug
level for it. But I suspect that for normal users these are just
confusing and unnecessarily spam the log.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 08/21] ath10k: make firmware text debug messages more verbose.
2016-09-14 14:12 ` Valo, Kalle
@ 2016-09-14 15:06 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-14 15:06 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/14/2016 07:12 AM, Valo, Kalle wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> There are not many of these messages producted by the
>> firmware, but they are generally fairly useful, so print
>> them at info level.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>> ---
>> drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
>> index 1758b4a..d9e4b77 100644
>> --- a/drivers/net/wireless/ath/ath10k/wmi.c
>> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
>> @@ -4050,7 +4050,7 @@ void ath10k_wmi_event_debug_print(struct ath10k *ar, struct sk_buff *skb)
>> /* the last byte is always reserved for the null character */
>> buf[i] = '\0';
>>
>> - ath10k_dbg(ar, ATH10K_DBG_WMI_PRINT, "wmi print '%s'\n", buf);
>> + ath10k_info(ar, "wmi print '%s'\n", buf);
>
> Useful to whom and how? I understand that for firmware developers this
> is very valuable information and that's why we have a special debug
> level for it. But I suspect that for normal users these are just
> confusing and unnecessarily spam the log.
CT firmare will print out some memory usage info on firmware boot, and that can
allow a discerning individual to tune their vdev, peer, rate-ctrl, and other
object usage in order to make best use of resources in the firmware.
These few lines can greatly aid debugging certain types of crashes and performance
loss in the firmware, so having them readily available in 'dmesg' or similar
for bug reports from the field helps me.
Stock firmware will also print out some resource usage info. It is just
a few lines on firmware boot, but it is quite useful in my experience.
Thank,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 08/21] ath10k: make firmware text debug messages more verbose.
@ 2016-09-14 15:06 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-14 15:06 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/14/2016 07:12 AM, Valo, Kalle wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> There are not many of these messages producted by the
>> firmware, but they are generally fairly useful, so print
>> them at info level.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>> ---
>> drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
>> index 1758b4a..d9e4b77 100644
>> --- a/drivers/net/wireless/ath/ath10k/wmi.c
>> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
>> @@ -4050,7 +4050,7 @@ void ath10k_wmi_event_debug_print(struct ath10k *ar, struct sk_buff *skb)
>> /* the last byte is always reserved for the null character */
>> buf[i] = '\0';
>>
>> - ath10k_dbg(ar, ATH10K_DBG_WMI_PRINT, "wmi print '%s'\n", buf);
>> + ath10k_info(ar, "wmi print '%s'\n", buf);
>
> Useful to whom and how? I understand that for firmware developers this
> is very valuable information and that's why we have a special debug
> level for it. But I suspect that for normal users these are just
> confusing and unnecessarily spam the log.
CT firmare will print out some memory usage info on firmware boot, and that can
allow a discerning individual to tune their vdev, peer, rate-ctrl, and other
object usage in order to make best use of resources in the firmware.
These few lines can greatly aid debugging certain types of crashes and performance
loss in the firmware, so having them readily available in 'dmesg' or similar
for bug reports from the field helps me.
Stock firmware will also print out some resource usage info. It is just
a few lines on firmware boot, but it is quite useful in my experience.
Thank,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 08/21] ath10k: make firmware text debug messages more verbose.
2016-09-14 15:06 ` Ben Greear
@ 2016-09-15 14:02 ` Valo, Kalle
-1 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-15 14:02 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:12 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> There are not many of these messages producted by the
>>> firmware, but they are generally fairly useful, so print
>>> them at info level.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wirele=
ss/ath/ath10k/wmi.c
>>> index 1758b4a..d9e4b77 100644
>>> --- a/drivers/net/wireless/ath/ath10k/wmi.c
>>> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
>>> @@ -4050,7 +4050,7 @@ void ath10k_wmi_event_debug_print(struct ath10k *=
ar, struct sk_buff *skb)
>>> /* the last byte is always reserved for the null character */
>>> buf[i] =3D '\0';
>>>
>>> - ath10k_dbg(ar, ATH10K_DBG_WMI_PRINT, "wmi print '%s'\n", buf);
>>> + ath10k_info(ar, "wmi print '%s'\n", buf);
>>
>> Useful to whom and how? I understand that for firmware developers this
>> is very valuable information and that's why we have a special debug
>> level for it. But I suspect that for normal users these are just
>> confusing and unnecessarily spam the log.
>
> CT firmare will print out some memory usage info on firmware boot, and th=
at can
> allow a discerning individual to tune their vdev, peer, rate-ctrl, and ot=
her
> object usage in order to make best use of resources in the firmware.
>
> These few lines can greatly aid debugging certain types of crashes and pe=
rformance
> loss in the firmware, so having them readily available in 'dmesg' or simi=
lar
> for bug reports from the field helps me.
>
> Stock firmware will also print out some resource usage info. It is just
> a few lines on firmware boot, but it is quite useful in my experience.
I'm sure it's useful for you, but we have quite a few firmware versions
to support. We do not know what kind of messages they print.
--=20
Kalle Valo=
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 08/21] ath10k: make firmware text debug messages more verbose.
@ 2016-09-15 14:02 ` Valo, Kalle
0 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-15 14:02 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:12 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> There are not many of these messages producted by the
>>> firmware, but they are generally fairly useful, so print
>>> them at info level.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
>>> index 1758b4a..d9e4b77 100644
>>> --- a/drivers/net/wireless/ath/ath10k/wmi.c
>>> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
>>> @@ -4050,7 +4050,7 @@ void ath10k_wmi_event_debug_print(struct ath10k *ar, struct sk_buff *skb)
>>> /* the last byte is always reserved for the null character */
>>> buf[i] = '\0';
>>>
>>> - ath10k_dbg(ar, ATH10K_DBG_WMI_PRINT, "wmi print '%s'\n", buf);
>>> + ath10k_info(ar, "wmi print '%s'\n", buf);
>>
>> Useful to whom and how? I understand that for firmware developers this
>> is very valuable information and that's why we have a special debug
>> level for it. But I suspect that for normal users these are just
>> confusing and unnecessarily spam the log.
>
> CT firmare will print out some memory usage info on firmware boot, and that can
> allow a discerning individual to tune their vdev, peer, rate-ctrl, and other
> object usage in order to make best use of resources in the firmware.
>
> These few lines can greatly aid debugging certain types of crashes and performance
> loss in the firmware, so having them readily available in 'dmesg' or similar
> for bug reports from the field helps me.
>
> Stock firmware will also print out some resource usage info. It is just
> a few lines on firmware boot, but it is quite useful in my experience.
I'm sure it's useful for you, but we have quite a few firmware versions
to support. We do not know what kind of messages they print.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 08/21] ath10k: make firmware text debug messages more verbose.
2016-09-15 14:02 ` Valo, Kalle
@ 2016-09-15 15:17 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-15 15:17 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/15/2016 07:02 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:12 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> There are not many of these messages producted by the
>>>> firmware, but they are generally fairly useful, so print
>>>> them at info level.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>> ---
>>>> drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
>>>> index 1758b4a..d9e4b77 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/wmi.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
>>>> @@ -4050,7 +4050,7 @@ void ath10k_wmi_event_debug_print(struct ath10k *ar, struct sk_buff *skb)
>>>> /* the last byte is always reserved for the null character */
>>>> buf[i] = '\0';
>>>>
>>>> - ath10k_dbg(ar, ATH10K_DBG_WMI_PRINT, "wmi print '%s'\n", buf);
>>>> + ath10k_info(ar, "wmi print '%s'\n", buf);
>>>
>>> Useful to whom and how? I understand that for firmware developers this
>>> is very valuable information and that's why we have a special debug
>>> level for it. But I suspect that for normal users these are just
>>> confusing and unnecessarily spam the log.
>>
>> CT firmare will print out some memory usage info on firmware boot, and that can
>> allow a discerning individual to tune their vdev, peer, rate-ctrl, and other
>> object usage in order to make best use of resources in the firmware.
>>
>> These few lines can greatly aid debugging certain types of crashes and performance
>> loss in the firmware, so having them readily available in 'dmesg' or similar
>> for bug reports from the field helps me.
>>
>> Stock firmware will also print out some resource usage info. It is just
>> a few lines on firmware boot, but it is quite useful in my experience.
>
> I'm sure it's useful for you, but we have quite a few firmware versions
> to support. We do not know what kind of messages they print.
And how does that matter? You think you can break something by printing
a string the logs?
Even if you do see problems, you can hide the logging messages again.
It's not like it is even 'secret', it is trivial for someone to print out
this info with a patch like mine.
I have tested this on 10.1, 10.2, 10.4.3 firmware. Mine are similar to those
usptreams with regard to what they print out in this manner.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 08/21] ath10k: make firmware text debug messages more verbose.
@ 2016-09-15 15:17 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-15 15:17 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/15/2016 07:02 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:12 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> There are not many of these messages producted by the
>>>> firmware, but they are generally fairly useful, so print
>>>> them at info level.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>> ---
>>>> drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
>>>> index 1758b4a..d9e4b77 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/wmi.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
>>>> @@ -4050,7 +4050,7 @@ void ath10k_wmi_event_debug_print(struct ath10k *ar, struct sk_buff *skb)
>>>> /* the last byte is always reserved for the null character */
>>>> buf[i] = '\0';
>>>>
>>>> - ath10k_dbg(ar, ATH10K_DBG_WMI_PRINT, "wmi print '%s'\n", buf);
>>>> + ath10k_info(ar, "wmi print '%s'\n", buf);
>>>
>>> Useful to whom and how? I understand that for firmware developers this
>>> is very valuable information and that's why we have a special debug
>>> level for it. But I suspect that for normal users these are just
>>> confusing and unnecessarily spam the log.
>>
>> CT firmare will print out some memory usage info on firmware boot, and that can
>> allow a discerning individual to tune their vdev, peer, rate-ctrl, and other
>> object usage in order to make best use of resources in the firmware.
>>
>> These few lines can greatly aid debugging certain types of crashes and performance
>> loss in the firmware, so having them readily available in 'dmesg' or similar
>> for bug reports from the field helps me.
>>
>> Stock firmware will also print out some resource usage info. It is just
>> a few lines on firmware boot, but it is quite useful in my experience.
>
> I'm sure it's useful for you, but we have quite a few firmware versions
> to support. We do not know what kind of messages they print.
And how does that matter? You think you can break something by printing
a string the logs?
Even if you do see problems, you can hide the logging messages again.
It's not like it is even 'secret', it is trivial for someone to print out
this info with a patch like mine.
I have tested this on 10.1, 10.2, 10.4.3 firmware. Mine are similar to those
usptreams with regard to what they print out in this manner.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* [PATCH v2 09/21] ath10k: print fw debug messages in hex.
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
This allows user-space tools to decode debug-log
messages by parsing dmesg or /var/log/messages.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/debug.c | 72 +++++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/debug.h | 5 +++
drivers/net/wireless/ath/ath10k/pci.c | 3 ++
drivers/net/wireless/ath/ath10k/wmi.c | 12 ++++++
4 files changed, 92 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index c7bff1e..97de9f37 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2717,3 +2717,75 @@ void ath10k_dbg_dump(struct ath10k *ar,
EXPORT_SYMBOL(ath10k_dbg_dump);
#endif /* CONFIG_ATH10K_DEBUG */
+
+void ath10k_dbg_print_fw_dbg_buffer(struct ath10k *ar, __le32 *ibuf, int len,
+ const char* lvl)
+{
+ /* Print out raw hex, external tools can decode if
+ * they care.
+ * TODO: Add ar identifier to messages.
+ */
+ int q = 0;
+
+ dev_printk(lvl, ar->dev, "ath10k_pci ATH10K_DBG_BUFFER:\n");
+ while (q < len) {
+ if (q + 8 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
+ ibuf[q+4], ibuf[q+5], ibuf[q+6], ibuf[q+7]);
+ q += 8;
+ }
+ else if (q + 7 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
+ ibuf[q+4], ibuf[q+5], ibuf[q+6]);
+ q += 7;
+ }
+ else if (q + 6 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
+ ibuf[q+4], ibuf[q+5]);
+ q += 6;
+ }
+ else if (q + 5 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
+ ibuf[q+4]);
+ q += 5;
+ }
+ else if (q + 4 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3]);
+ q += 4;
+ }
+ else if (q + 3 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2]);
+ q += 3;
+ }
+ else if (q + 2 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1]);
+ q += 2;
+ }
+ else if (q + 1 <= len) {
+ printk("%sath10k: [%04d]: %08X\n",
+ lvl, q,
+ ibuf[q]);
+ q += 1;
+ }
+ else {
+ break;
+ }
+ }/* while */
+
+ dev_printk(lvl, ar->dev, "ATH10K_END\n");
+}
+EXPORT_SYMBOL(ath10k_dbg_print_fw_dbg_buffer);
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 3062948..641fce1 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -38,6 +38,7 @@ enum ath10k_debug_mask {
ATH10K_DBG_WMI_PRINT = 0x00002000,
ATH10K_DBG_PCI_PS = 0x00004000,
ATH10K_DBG_AHB = 0x00008000,
+ ATH10K_DBG_FW = 0x80000000,
ATH10K_DBG_ANY = 0xffffffff,
};
@@ -192,4 +193,8 @@ static inline void ath10k_dbg_dump(struct ath10k *ar,
{
}
#endif /* CONFIG_ATH10K_DEBUG */
+
+void ath10k_dbg_print_fw_dbg_buffer(struct ath10k *ar, __le32 *buffer,
+ int len, const char* lvl);
+
#endif /* _DEBUG_H_ */
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index e6315ec..dbf0db8 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1623,6 +1623,9 @@ static void ath10k_pci_dump_dbglog(struct ath10k *ar)
WARN_ON(len & 0x3);
ath10k_dbg_save_fw_dbg_buffer(ar, (__le32 *)(buffer), len >> 2);
+ ath10k_dbg_print_fw_dbg_buffer(ar, (__le32 *)(buffer),
+ dbuf.length/sizeof(__le32),
+ KERN_ERR);
kfree(buffer);
next:
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index d9e4b77..6cfba41 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2510,6 +2510,18 @@ int ath10k_wmi_event_debug_mesg(struct ath10k *ar, struct sk_buff *skb)
(skb->len - 4)/sizeof(__le32));
spin_unlock_bh(&ar->data_lock);
+ if (ev->dropped_count)
+ ath10k_warn(ar, "WARNING: Dropped dbglog buffers: %d\n", __le32_to_cpu(ev->dropped_count));
+
+ if (ath10k_debug_mask & ATH10K_DBG_FW)
+ ath10k_dbg_print_fw_dbg_buffer(ar, ev->messages,
+ (skb->len - 4)/sizeof(__le32),
+ KERN_INFO);
+ else
+ ath10k_dbg_print_fw_dbg_buffer(ar, ev->messages,
+ (skb->len - 4)/sizeof(__le32),
+ KERN_DEBUG);
+
return 0;
}
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 09/21] ath10k: print fw debug messages in hex.
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
This allows user-space tools to decode debug-log
messages by parsing dmesg or /var/log/messages.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/debug.c | 72 +++++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/debug.h | 5 +++
drivers/net/wireless/ath/ath10k/pci.c | 3 ++
drivers/net/wireless/ath/ath10k/wmi.c | 12 ++++++
4 files changed, 92 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index c7bff1e..97de9f37 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2717,3 +2717,75 @@ void ath10k_dbg_dump(struct ath10k *ar,
EXPORT_SYMBOL(ath10k_dbg_dump);
#endif /* CONFIG_ATH10K_DEBUG */
+
+void ath10k_dbg_print_fw_dbg_buffer(struct ath10k *ar, __le32 *ibuf, int len,
+ const char* lvl)
+{
+ /* Print out raw hex, external tools can decode if
+ * they care.
+ * TODO: Add ar identifier to messages.
+ */
+ int q = 0;
+
+ dev_printk(lvl, ar->dev, "ath10k_pci ATH10K_DBG_BUFFER:\n");
+ while (q < len) {
+ if (q + 8 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
+ ibuf[q+4], ibuf[q+5], ibuf[q+6], ibuf[q+7]);
+ q += 8;
+ }
+ else if (q + 7 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
+ ibuf[q+4], ibuf[q+5], ibuf[q+6]);
+ q += 7;
+ }
+ else if (q + 6 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
+ ibuf[q+4], ibuf[q+5]);
+ q += 6;
+ }
+ else if (q + 5 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
+ ibuf[q+4]);
+ q += 5;
+ }
+ else if (q + 4 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3]);
+ q += 4;
+ }
+ else if (q + 3 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1], ibuf[q+2]);
+ q += 3;
+ }
+ else if (q + 2 <= len) {
+ printk("%sath10k: [%04d]: %08X %08X\n",
+ lvl, q,
+ ibuf[q], ibuf[q+1]);
+ q += 2;
+ }
+ else if (q + 1 <= len) {
+ printk("%sath10k: [%04d]: %08X\n",
+ lvl, q,
+ ibuf[q]);
+ q += 1;
+ }
+ else {
+ break;
+ }
+ }/* while */
+
+ dev_printk(lvl, ar->dev, "ATH10K_END\n");
+}
+EXPORT_SYMBOL(ath10k_dbg_print_fw_dbg_buffer);
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 3062948..641fce1 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -38,6 +38,7 @@ enum ath10k_debug_mask {
ATH10K_DBG_WMI_PRINT = 0x00002000,
ATH10K_DBG_PCI_PS = 0x00004000,
ATH10K_DBG_AHB = 0x00008000,
+ ATH10K_DBG_FW = 0x80000000,
ATH10K_DBG_ANY = 0xffffffff,
};
@@ -192,4 +193,8 @@ static inline void ath10k_dbg_dump(struct ath10k *ar,
{
}
#endif /* CONFIG_ATH10K_DEBUG */
+
+void ath10k_dbg_print_fw_dbg_buffer(struct ath10k *ar, __le32 *buffer,
+ int len, const char* lvl);
+
#endif /* _DEBUG_H_ */
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index e6315ec..dbf0db8 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1623,6 +1623,9 @@ static void ath10k_pci_dump_dbglog(struct ath10k *ar)
WARN_ON(len & 0x3);
ath10k_dbg_save_fw_dbg_buffer(ar, (__le32 *)(buffer), len >> 2);
+ ath10k_dbg_print_fw_dbg_buffer(ar, (__le32 *)(buffer),
+ dbuf.length/sizeof(__le32),
+ KERN_ERR);
kfree(buffer);
next:
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index d9e4b77..6cfba41 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2510,6 +2510,18 @@ int ath10k_wmi_event_debug_mesg(struct ath10k *ar, struct sk_buff *skb)
(skb->len - 4)/sizeof(__le32));
spin_unlock_bh(&ar->data_lock);
+ if (ev->dropped_count)
+ ath10k_warn(ar, "WARNING: Dropped dbglog buffers: %d\n", __le32_to_cpu(ev->dropped_count));
+
+ if (ath10k_debug_mask & ATH10K_DBG_FW)
+ ath10k_dbg_print_fw_dbg_buffer(ar, ev->messages,
+ (skb->len - 4)/sizeof(__le32),
+ KERN_INFO);
+ else
+ ath10k_dbg_print_fw_dbg_buffer(ar, ev->messages,
+ (skb->len - 4)/sizeof(__le32),
+ KERN_DEBUG);
+
return 0;
}
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
2016-05-11 17:02 ` greearb
@ 2016-09-14 14:18 ` Valo, Kalle
-1 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 14:18 UTC (permalink / raw)
To: greearb; +Cc: ath10k, linux-wireless
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> This allows user-space tools to decode debug-log
> messages by parsing dmesg or /var/log/messages.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
Don't tracing points already provide the same information?
> +void ath10k_dbg_print_fw_dbg_buffer(struct ath10k *ar, __le32 *ibuf, int=
len,
> + const char* lvl)
> +{
> + /* Print out raw hex, external tools can decode if
> + * they care.
> + * TODO: Add ar identifier to messages.
> + */
> + int q =3D 0;
> +
> + dev_printk(lvl, ar->dev, "ath10k_pci ATH10K_DBG_BUFFER:\n");
> + while (q < len) {
> + if (q + 8 <=3D len) {
> + printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X %08X %08X\n",
> + lvl, q,
> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
> + ibuf[q+4], ibuf[q+5], ibuf[q+6], ibuf[q+7]);
> + q +=3D 8;
> + }
> + else if (q + 7 <=3D len) {
> + printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X %08X\n",
> + lvl, q,
> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
> + ibuf[q+4], ibuf[q+5], ibuf[q+6]);
> + q +=3D 7;
> + }
> + else if (q + 6 <=3D len) {
> + printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X\n",
> + lvl, q,
> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
> + ibuf[q+4], ibuf[q+5]);
> + q +=3D 6;
> + }
> + else if (q + 5 <=3D len) {
> + printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X\n",
> + lvl, q,
> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
> + ibuf[q+4]);
> + q +=3D 5;
> + }
> + else if (q + 4 <=3D len) {
> + printk("%sath10k: [%04d]: %08X %08X %08X %08X\n",
> + lvl, q,
> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3]);
> + q +=3D 4;
> + }
> + else if (q + 3 <=3D len) {
> + printk("%sath10k: [%04d]: %08X %08X %08X\n",
> + lvl, q,
> + ibuf[q], ibuf[q+1], ibuf[q+2]);
> + q +=3D 3;
> + }
> + else if (q + 2 <=3D len) {
> + printk("%sath10k: [%04d]: %08X %08X\n",
> + lvl, q,
> + ibuf[q], ibuf[q+1]);
> + q +=3D 2;
> + }
> + else if (q + 1 <=3D len) {
> + printk("%sath10k: [%04d]: %08X\n",
> + lvl, q,
> + ibuf[q]);
> + q +=3D 1;
> + }
> + else {
> + break;
> + }
> + }/* while */
> +
> + dev_printk(lvl, ar->dev, "ATH10K_END\n");
> +}
Isn't this almost the same as what ath10k_dbg_dump() does?
--=20
Kalle Valo=
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
@ 2016-09-14 14:18 ` Valo, Kalle
0 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 14:18 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath10k
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> This allows user-space tools to decode debug-log
> messages by parsing dmesg or /var/log/messages.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
Don't tracing points already provide the same information?
> +void ath10k_dbg_print_fw_dbg_buffer(struct ath10k *ar, __le32 *ibuf, int len,
> + const char* lvl)
> +{
> + /* Print out raw hex, external tools can decode if
> + * they care.
> + * TODO: Add ar identifier to messages.
> + */
> + int q = 0;
> +
> + dev_printk(lvl, ar->dev, "ath10k_pci ATH10K_DBG_BUFFER:\n");
> + while (q < len) {
> + if (q + 8 <= len) {
> + printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X %08X %08X\n",
> + lvl, q,
> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
> + ibuf[q+4], ibuf[q+5], ibuf[q+6], ibuf[q+7]);
> + q += 8;
> + }
> + else if (q + 7 <= len) {
> + printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X %08X\n",
> + lvl, q,
> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
> + ibuf[q+4], ibuf[q+5], ibuf[q+6]);
> + q += 7;
> + }
> + else if (q + 6 <= len) {
> + printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X\n",
> + lvl, q,
> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
> + ibuf[q+4], ibuf[q+5]);
> + q += 6;
> + }
> + else if (q + 5 <= len) {
> + printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X\n",
> + lvl, q,
> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
> + ibuf[q+4]);
> + q += 5;
> + }
> + else if (q + 4 <= len) {
> + printk("%sath10k: [%04d]: %08X %08X %08X %08X\n",
> + lvl, q,
> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3]);
> + q += 4;
> + }
> + else if (q + 3 <= len) {
> + printk("%sath10k: [%04d]: %08X %08X %08X\n",
> + lvl, q,
> + ibuf[q], ibuf[q+1], ibuf[q+2]);
> + q += 3;
> + }
> + else if (q + 2 <= len) {
> + printk("%sath10k: [%04d]: %08X %08X\n",
> + lvl, q,
> + ibuf[q], ibuf[q+1]);
> + q += 2;
> + }
> + else if (q + 1 <= len) {
> + printk("%sath10k: [%04d]: %08X\n",
> + lvl, q,
> + ibuf[q]);
> + q += 1;
> + }
> + else {
> + break;
> + }
> + }/* while */
> +
> + dev_printk(lvl, ar->dev, "ATH10K_END\n");
> +}
Isn't this almost the same as what ath10k_dbg_dump() does?
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
2016-09-14 14:18 ` Valo, Kalle
@ 2016-09-14 15:13 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-14 15:13 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/14/2016 07:18 AM, Valo, Kalle wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> This allows user-space tools to decode debug-log
>> messages by parsing dmesg or /var/log/messages.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>
> Don't tracing points already provide the same information?
Tracing tools are difficult to set up and may not be available on
random embedded devices. And if we are dealing with bug reports from
the field, most users will not be able to set it up regardless.
There are similar ways to print out hex, but the logic below creates
specific and parseable logs in the 'dmesg' output and similar.
I have written a tool that can decode these messages into useful human-readable
text so that I can debug firmware issues both locally and from field reports.
Stock firmware generates similar logs and QCA could write their own decode logic
for their firmware versions.
Thanks,
Ben
>
>> +void ath10k_dbg_print_fw_dbg_buffer(struct ath10k *ar, __le32 *ibuf, int len,
>> + const char* lvl)
>> +{
>> + /* Print out raw hex, external tools can decode if
>> + * they care.
>> + * TODO: Add ar identifier to messages.
>> + */
>> + int q = 0;
>> +
>> + dev_printk(lvl, ar->dev, "ath10k_pci ATH10K_DBG_BUFFER:\n");
>> + while (q < len) {
>> + if (q + 8 <= len) {
>> + printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X %08X %08X\n",
>> + lvl, q,
>> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
>> + ibuf[q+4], ibuf[q+5], ibuf[q+6], ibuf[q+7]);
>> + q += 8;
>> + }
>> + else if (q + 7 <= len) {
>> + printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X %08X\n",
>> + lvl, q,
>> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
>> + ibuf[q+4], ibuf[q+5], ibuf[q+6]);
>> + q += 7;
>> + }
>> + else if (q + 6 <= len) {
>> + printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X\n",
>> + lvl, q,
>> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
>> + ibuf[q+4], ibuf[q+5]);
>> + q += 6;
>> + }
>> + else if (q + 5 <= len) {
>> + printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X\n",
>> + lvl, q,
>> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
>> + ibuf[q+4]);
>> + q += 5;
>> + }
>> + else if (q + 4 <= len) {
>> + printk("%sath10k: [%04d]: %08X %08X %08X %08X\n",
>> + lvl, q,
>> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3]);
>> + q += 4;
>> + }
>> + else if (q + 3 <= len) {
>> + printk("%sath10k: [%04d]: %08X %08X %08X\n",
>> + lvl, q,
>> + ibuf[q], ibuf[q+1], ibuf[q+2]);
>> + q += 3;
>> + }
>> + else if (q + 2 <= len) {
>> + printk("%sath10k: [%04d]: %08X %08X\n",
>> + lvl, q,
>> + ibuf[q], ibuf[q+1]);
>> + q += 2;
>> + }
>> + else if (q + 1 <= len) {
>> + printk("%sath10k: [%04d]: %08X\n",
>> + lvl, q,
>> + ibuf[q]);
>> + q += 1;
>> + }
>> + else {
>> + break;
>> + }
>> + }/* while */
>> +
>> + dev_printk(lvl, ar->dev, "ATH10K_END\n");
>> +}
>
> Isn't this almost the same as what ath10k_dbg_dump() does?
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
@ 2016-09-14 15:13 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-14 15:13 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/14/2016 07:18 AM, Valo, Kalle wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> This allows user-space tools to decode debug-log
>> messages by parsing dmesg or /var/log/messages.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>
> Don't tracing points already provide the same information?
Tracing tools are difficult to set up and may not be available on
random embedded devices. And if we are dealing with bug reports from
the field, most users will not be able to set it up regardless.
There are similar ways to print out hex, but the logic below creates
specific and parseable logs in the 'dmesg' output and similar.
I have written a tool that can decode these messages into useful human-readable
text so that I can debug firmware issues both locally and from field reports.
Stock firmware generates similar logs and QCA could write their own decode logic
for their firmware versions.
Thanks,
Ben
>
>> +void ath10k_dbg_print_fw_dbg_buffer(struct ath10k *ar, __le32 *ibuf, int len,
>> + const char* lvl)
>> +{
>> + /* Print out raw hex, external tools can decode if
>> + * they care.
>> + * TODO: Add ar identifier to messages.
>> + */
>> + int q = 0;
>> +
>> + dev_printk(lvl, ar->dev, "ath10k_pci ATH10K_DBG_BUFFER:\n");
>> + while (q < len) {
>> + if (q + 8 <= len) {
>> + printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X %08X %08X\n",
>> + lvl, q,
>> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
>> + ibuf[q+4], ibuf[q+5], ibuf[q+6], ibuf[q+7]);
>> + q += 8;
>> + }
>> + else if (q + 7 <= len) {
>> + printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X %08X\n",
>> + lvl, q,
>> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
>> + ibuf[q+4], ibuf[q+5], ibuf[q+6]);
>> + q += 7;
>> + }
>> + else if (q + 6 <= len) {
>> + printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X %08X\n",
>> + lvl, q,
>> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
>> + ibuf[q+4], ibuf[q+5]);
>> + q += 6;
>> + }
>> + else if (q + 5 <= len) {
>> + printk("%sath10k: [%04d]: %08X %08X %08X %08X %08X\n",
>> + lvl, q,
>> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3],
>> + ibuf[q+4]);
>> + q += 5;
>> + }
>> + else if (q + 4 <= len) {
>> + printk("%sath10k: [%04d]: %08X %08X %08X %08X\n",
>> + lvl, q,
>> + ibuf[q], ibuf[q+1], ibuf[q+2], ibuf[q+3]);
>> + q += 4;
>> + }
>> + else if (q + 3 <= len) {
>> + printk("%sath10k: [%04d]: %08X %08X %08X\n",
>> + lvl, q,
>> + ibuf[q], ibuf[q+1], ibuf[q+2]);
>> + q += 3;
>> + }
>> + else if (q + 2 <= len) {
>> + printk("%sath10k: [%04d]: %08X %08X\n",
>> + lvl, q,
>> + ibuf[q], ibuf[q+1]);
>> + q += 2;
>> + }
>> + else if (q + 1 <= len) {
>> + printk("%sath10k: [%04d]: %08X\n",
>> + lvl, q,
>> + ibuf[q]);
>> + q += 1;
>> + }
>> + else {
>> + break;
>> + }
>> + }/* while */
>> +
>> + dev_printk(lvl, ar->dev, "ATH10K_END\n");
>> +}
>
> Isn't this almost the same as what ath10k_dbg_dump() does?
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
2016-09-14 15:13 ` Ben Greear
@ 2016-09-15 14:06 ` Valo, Kalle
-1 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-15 14:06 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k, emmanuel.grumbach
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:18 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> This allows user-space tools to decode debug-log
>>> messages by parsing dmesg or /var/log/messages.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>
>> Don't tracing points already provide the same information?
>
> Tracing tools are difficult to set up and may not be available on
> random embedded devices. And if we are dealing with bug reports from
> the field, most users will not be able to set it up regardless.
>
> There are similar ways to print out hex, but the logic below creates
> specific and parseable logs in the 'dmesg' output and similar.
>
> I have written a tool that can decode these messages into useful human-re=
adable
> text so that I can debug firmware issues both locally and from field repo=
rts.
>
> Stock firmware generates similar logs and QCA could write their own decod=
e logic
> for their firmware versions.
Reinventing the wheel by using printk as the delivery mechanism doesn't
sound like a good idea. IIRC Emmanuel talked about some kind of firmware
debugging framework, he might have some ideas.
--=20
Kalle Valo=
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
@ 2016-09-15 14:06 ` Valo, Kalle
0 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-15 14:06 UTC (permalink / raw)
To: Ben Greear; +Cc: emmanuel.grumbach, linux-wireless, ath10k
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:18 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> This allows user-space tools to decode debug-log
>>> messages by parsing dmesg or /var/log/messages.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>
>> Don't tracing points already provide the same information?
>
> Tracing tools are difficult to set up and may not be available on
> random embedded devices. And if we are dealing with bug reports from
> the field, most users will not be able to set it up regardless.
>
> There are similar ways to print out hex, but the logic below creates
> specific and parseable logs in the 'dmesg' output and similar.
>
> I have written a tool that can decode these messages into useful human-readable
> text so that I can debug firmware issues both locally and from field reports.
>
> Stock firmware generates similar logs and QCA could write their own decode logic
> for their firmware versions.
Reinventing the wheel by using printk as the delivery mechanism doesn't
sound like a good idea. IIRC Emmanuel talked about some kind of firmware
debugging framework, he might have some ideas.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
2016-09-15 14:06 ` Valo, Kalle
@ 2016-09-15 15:14 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-15 15:14 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k, emmanuel.grumbach
On 09/15/2016 07:06 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:18 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> This allows user-space tools to decode debug-log
>>>> messages by parsing dmesg or /var/log/messages.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>
>>> Don't tracing points already provide the same information?
>>
>> Tracing tools are difficult to set up and may not be available on
>> random embedded devices. And if we are dealing with bug reports from
>> the field, most users will not be able to set it up regardless.
>>
>> There are similar ways to print out hex, but the logic below creates
>> specific and parseable logs in the 'dmesg' output and similar.
>>
>> I have written a tool that can decode these messages into useful human-readable
>> text so that I can debug firmware issues both locally and from field reports.
>>
>> Stock firmware generates similar logs and QCA could write their own decode logic
>> for their firmware versions.
>
> Reinventing the wheel by using printk as the delivery mechanism doesn't
> sound like a good idea. IIRC Emmanuel talked about some kind of firmware
> debugging framework, he might have some ideas.
Waiting for magical frameworks to fix problems is even worse.
It has been years since ath10k has been in the kernel. There is basically
still no way to debug what the firmware is doing.
My patch gives you something that can work right now, with the standard 'dmesg'
framework found in virtually all kernels new and old, and it has been proven
to be useful in the field. The messages are also nicely interleaved with the
rest of the mac80211 stack messages and any other driver messages, so you have
context.
If someone wants to add support for a framework later, then by all means, post
the patches when it is ready.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
@ 2016-09-15 15:14 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-15 15:14 UTC (permalink / raw)
To: Valo, Kalle; +Cc: emmanuel.grumbach, linux-wireless, ath10k
On 09/15/2016 07:06 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:18 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> This allows user-space tools to decode debug-log
>>>> messages by parsing dmesg or /var/log/messages.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>
>>> Don't tracing points already provide the same information?
>>
>> Tracing tools are difficult to set up and may not be available on
>> random embedded devices. And if we are dealing with bug reports from
>> the field, most users will not be able to set it up regardless.
>>
>> There are similar ways to print out hex, but the logic below creates
>> specific and parseable logs in the 'dmesg' output and similar.
>>
>> I have written a tool that can decode these messages into useful human-readable
>> text so that I can debug firmware issues both locally and from field reports.
>>
>> Stock firmware generates similar logs and QCA could write their own decode logic
>> for their firmware versions.
>
> Reinventing the wheel by using printk as the delivery mechanism doesn't
> sound like a good idea. IIRC Emmanuel talked about some kind of firmware
> debugging framework, he might have some ideas.
Waiting for magical frameworks to fix problems is even worse.
It has been years since ath10k has been in the kernel. There is basically
still no way to debug what the firmware is doing.
My patch gives you something that can work right now, with the standard 'dmesg'
framework found in virtually all kernels new and old, and it has been proven
to be useful in the field. The messages are also nicely interleaved with the
rest of the mac80211 stack messages and any other driver messages, so you have
context.
If someone wants to add support for a framework later, then by all means, post
the patches when it is ready.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
2016-09-15 15:14 ` Ben Greear
@ 2016-09-15 17:34 ` Grumbach, Emmanuel
-1 siblings, 0 replies; 118+ messages in thread
From: Grumbach, Emmanuel @ 2016-09-15 17:34 UTC (permalink / raw)
To: greearb, kvalo; +Cc: linux-wireless, ath10k
T24gVGh1LCAyMDE2LTA5LTE1IGF0IDA4OjE0IC0wNzAwLCBCZW4gR3JlZWFyIHdyb3RlOg0KPiBP
biAwOS8xNS8yMDE2IDA3OjA2IEFNLCBWYWxvLCBLYWxsZSB3cm90ZToNCj4gPiBCZW4gR3JlZWFy
IDxncmVlYXJiQGNhbmRlbGF0ZWNoLmNvbT4gd3JpdGVzOg0KPiA+IA0KPiA+ID4gT24gMDkvMTQv
MjAxNiAwNzoxOCBBTSwgVmFsbywgS2FsbGUgd3JvdGU6DQo+ID4gPiA+IGdyZWVhcmJAY2FuZGVs
YXRlY2guY29tIHdyaXRlczoNCj4gPiA+ID4gDQo+ID4gPiA+ID4gRnJvbTogQmVuIEdyZWVhciA8
Z3JlZWFyYkBjYW5kZWxhdGVjaC5jb20+DQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gVGhpcyBhbGxv
d3MgdXNlci1zcGFjZSB0b29scyB0byBkZWNvZGUgZGVidWctbG9nDQo+ID4gPiA+ID4gbWVzc2Fn
ZXMgYnkgcGFyc2luZyBkbWVzZyBvciAvdmFyL2xvZy9tZXNzYWdlcy4NCj4gPiA+ID4gPiANCj4g
PiA+ID4gPiBTaWduZWQtb2ZmLWJ5OiBCZW4gR3JlZWFyIDxncmVlYXJiQGNhbmRlbGF0ZWNoLmNv
bT4NCj4gPiA+ID4gDQo+ID4gPiA+IERvbid0IHRyYWNpbmcgcG9pbnRzIGFscmVhZHkgcHJvdmlk
ZSB0aGUgc2FtZSBpbmZvcm1hdGlvbj8NCj4gPiA+IA0KPiA+ID4gVHJhY2luZyB0b29scyBhcmUg
ZGlmZmljdWx0IHRvIHNldCB1cCBhbmQgbWF5IG5vdCBiZSBhdmFpbGFibGUgb24NCj4gPiA+IHJh
bmRvbSBlbWJlZGRlZCBkZXZpY2VzLiAgQW5kIGlmIHdlIGFyZSBkZWFsaW5nIHdpdGggYnVnIHJl
cG9ydHMNCj4gPiA+IGZyb20NCj4gPiA+IHRoZSBmaWVsZCwgbW9zdCB1c2VycyB3aWxsIG5vdCBi
ZSBhYmxlIHRvIHNldCBpdCB1cCByZWdhcmRsZXNzLg0KPiA+ID4gDQo+ID4gPiBUaGVyZSBhcmUg
c2ltaWxhciB3YXlzIHRvIHByaW50IG91dCBoZXgsIGJ1dCB0aGUgbG9naWMgYmVsb3cNCj4gPiA+
IGNyZWF0ZXMNCj4gPiA+IHNwZWNpZmljIGFuZCBwYXJzZWFibGUgbG9ncyBpbiB0aGUgJ2RtZXNn
JyBvdXRwdXQgYW5kIHNpbWlsYXIuDQo+ID4gPiANCj4gPiA+IEkgaGF2ZSB3cml0dGVuIGEgdG9v
bCB0aGF0IGNhbiBkZWNvZGUgdGhlc2UgbWVzc2FnZXMgaW50byB1c2VmdWwNCj4gPiA+IGh1bWFu
LXJlYWRhYmxlDQo+ID4gPiB0ZXh0IHNvIHRoYXQgSSBjYW4gZGVidWcgZmlybXdhcmUgaXNzdWVz
IGJvdGggbG9jYWxseSBhbmQgZnJvbQ0KPiA+ID4gZmllbGQgcmVwb3J0cy4NCj4gPiA+IA0KPiA+
ID4gU3RvY2sgZmlybXdhcmUgZ2VuZXJhdGVzIHNpbWlsYXIgbG9ncyBhbmQgUUNBIGNvdWxkIHdy
aXRlIHRoZWlyDQo+ID4gPiBvd24gZGVjb2RlIGxvZ2ljDQo+ID4gPiBmb3IgdGhlaXIgZmlybXdh
cmUgdmVyc2lvbnMuDQo+ID4gDQo+ID4gUmVpbnZlbnRpbmcgdGhlIHdoZWVsIGJ5IHVzaW5nIHBy
aW50ayBhcyB0aGUgZGVsaXZlcnkgbWVjaGFuaXNtDQo+ID4gZG9lc24ndA0KPiA+IHNvdW5kIGxp
a2UgYSBnb29kIGlkZWEuIElJUkMgRW1tYW51ZWwgdGFsa2VkIGFib3V0IHNvbWUga2luZCBvZg0K
PiA+IGZpcm13YXJlDQo+ID4gZGVidWdnaW5nIGZyYW1ld29yaywgaGUgbWlnaHQgaGF2ZSBzb21l
IGlkZWFzLg0KPiANCj4gV2FpdGluZyBmb3IgbWFnaWNhbCBmcmFtZXdvcmtzIHRvIGZpeCBwcm9i
bGVtcyBpcyBldmVuIHdvcnNlLg0KPiANCkl0IGhhcyBiZWVuIHllYXJzIHNpbmNlIGF0aDEwayBo
YXMgYmVlbiBpbiB0aGUga2VybmVsLiAgVGhlcmUgaXMNCj4gYmFzaWNhbGx5DQo+IHN0aWxsIG5v
IHdheSB0byBkZWJ1ZyB3aGF0IHRoZSBmaXJtd2FyZSBpcyBkb2luZy4NCj4gDQoNCkkga25vdyB0
aGUgZmVlbGluZyA6KSBJIHdhcyBpbiB0aGUgc2FtZSBzaXR1YXRpb24gYmVmb3JlIEkgYWRkZWQg
c3R1ZmYNCmZvciBpd2x3aWZpLg0KDQo+IE15IHBhdGNoIGdpdmVzIHlvdSBzb21ldGhpbmcgdGhh
dCBjYW4gd29yayByaWdodCBub3csIHdpdGggdGhlDQo+IHN0YW5kYXJkICdkbWVzZycNCj4gZnJh
bWV3b3JrIGZvdW5kIGluIHZpcnR1YWxseSBhbGwga2VybmVscyBuZXcgYW5kIG9sZCwgYW5kIGl0
IGhhcyBiZWVuDQo+IHByb3Zlbg0KPiB0byBiZSB1c2VmdWwgaW4gdGhlIGZpZWxkLiAgVGhlIG1l
c3NhZ2VzIGFyZSBhbHNvIG5pY2VseSBpbnRlcmxlYXZlZA0KPiB3aXRoIHRoZQ0KPiByZXN0IG9m
IHRoZSBtYWM4MDIxMSBzdGFjayBtZXNzYWdlcyBhbmQgYW55IG90aGVyIGRyaXZlciBtZXNzYWdl
cywgc28NCj4geW91IGhhdmUNCj4gY29udGV4dC4NCj4gDQo+IElmIHNvbWVvbmUgd2FudHMgdG8g
YWRkIHN1cHBvcnQgZm9yIGEgZnJhbWV3b3JrIGxhdGVyLCB0aGVuIGJ5IGFsbA0KPiBtZWFucywg
cG9zdA0KPiB0aGUgcGF0Y2hlcyB3aGVuIGl0IGlzIHJlYWR5Lg0KDQpGcm9tIG15IGV4cGVyaWVu
Y2UsIGEgc3Ryb25nIGFuZCBlYXN5LXRvLXVzZSBmaXJtd2FyZSBkZWJ1Zw0KaW5mcmFzdHJ1Y3R1
cmUgaXMgaW1wb3J0YW50IGJlY2F1c2UgdHlwaWNhbGx5LCB0aGUgZmlybXdhcmUgaXMgd3JpdHRl
bg0KYnkgb3RoZXIgcGVvcGxlIHdobyBoYXZlIGRpZmZlcmVudCBwcmlvcml0aWVzIChhbmQgYXJl
IG5vdCBhbHdheXMgTGludXgNCndpemFyZHMpIGV0Yy4uLiBCZWluZyBhYmxlIHRvIGdpdmUgdGhl
bSBnb29kIGRhdGEgaXMgdGhlIG9ubHkgd2F5IHRvDQpoYXZlIHRoZW0gZml4IHRoZWlyIGJ1Z3Mg
OikgRm9yIHVzLCBpdCB3YXMgcmVhbGx5IGEgZ2FtZSBjaGFuZ2VyLiBXaGVuDQp5b3Ugd29yayBm
b3IgYSBiaWcgY29ycG9yYXRlLCBoYXZpbmcgMiBncm91cHMgd29yayBiZXR0ZXIgdG9nZXRoZXIN
CmFsd2F5cyBoYXMgYSBiaWcgaW1wYWN0LiBUaGF0J3MgZm9yIHRoZSBwaGlsb3NvcGhpY2FsIHBh
cnQgOikNCg0KRldJVzogd2hhdCBJIGRpZCBoYXMgbm90aGluZyB0byBkbyB3aXRoIEZXICdsaXZl
IHRyYWNpbmcnLCBidXQgd2l0aA0KZmlybXdhcmUgZHVtcHMuIE9uZSBwYXJ0IG9mIG91ciBmaXJt
d2FyZSBkdW1wcyBpbmNsdWRlIHRyYWNpbmcuIFdlIGFsc28NCmhhdmUgImZpcm13YXJlIHByaW50
cyIsIGJ1dCB3ZSBkb24ndCBwcmludCB0aGVtIGluIHRoZSBrZXJuZWwgbG9nIGFuZA0KdGhleSBh
cmUgbm90IHBhcnQgb2YgdGhlIGZpcm13YXJlIGR1bXAgdGhpbmcuIFdlIHJhdGhlciByZWNvcmQg
dGhlbSBpbg0KdHJhY2Vwb2ludHMganVzdCBsaWtlIHJlYWxseSAqYW55dGhpbmcqIHRoYXQgY29t
ZXMgZnJvbSB0aGUgZmlybXdhcmUuDQpCYXNpY2FsbHksIHdlIGhhdmUgMiBsYXllcnMsIHRoZSB0
cmFuc3BvcnQgbGF5ZXIgKFBDSWUpIGFuZCB0aGUNCm9wZXJhdGlvbl9tb2RlIGxheWVyLiBUaGUg
Zmlyc3QganVzdCBicmluZ3MgdGhlIGRhdGEgZnJvbSB0aGUgZmlybXdhcmUNCmFuZCBpbiB0aGF0
IGxheWVyIHdlICpibGluZGx5KiByZWNvcmQgZXZlcnl0aGluZyBpbiB0cmFjZXBvaW50cy4gSW4g
dGhlDQpvcGVyYXRpb25fbW9kZSBsYXllciwgd2UgbG9vayBhdCB0aGUgZGF0YSBpdHNlbGYuIElu
IGNhc2Ugb2YgZGVidWcNCnByaW50cyBmcm9tIHRoZSBmaXJtd2FyZSwgd2Ugc2ltcGx5IGRpc2Nh
cmQgdGhlbSwgYmVjYXVzZSB3ZSBkb24ndA0KcmVhbGx5IGNhcmUgb2YgdGhlIG1lYW5pbmcuIEFs
bCB3ZSB3YW50IGlzIHRvIGhhdmUgdGhlbSBnbyB0aHJvdWdoIHRoZQ0KUENJZSBsYXllciBzbyB0
aGF0IHRoZXkgYXJlIHJlY29yZGVkIGluIHRoZSB0cmFjZXBvaW50cy4NCldoZW4gd2UgZmluaXNo
IHJlY29yZGluZyB0aGUgc2VxdWVuY2Ugd2Ugd2FudGVkIHdpdGggdHJhY2luZyAodHJhY2UNCi1j
bWQpLCB3ZSBwYXJzZSB0aGUgb3V0cHV0IGFuZCB0aGVuLCB3ZSBwYXJzZSB0aGUgZmlybXdhcmUg
cHJpbnRzLg0KSU1ITywgdGhpcyBpcyBtb3JlIHJlbGlhYmxlIHRoYW4ga2VybmVsIGxvZ3MgYW5k
IHlvdSBkb24ndCBsb3NlIHRoZQ0KYWxpZ25tZW50IHdpdGggdGhlIGRyaXZlciB0cmFjZXMgYXMg
bG9uZyBhcyB5b3UgaGF2ZSBkcml2ZXIgZGF0YSBpbg0KdHJhY2Vwb2ludHMgYXMgd2VsbC4NCg0K
PiANCj4gVGhhbmtzLA0KPiBCZW4NCj4gDQo+IA==
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
@ 2016-09-15 17:34 ` Grumbach, Emmanuel
0 siblings, 0 replies; 118+ messages in thread
From: Grumbach, Emmanuel @ 2016-09-15 17:34 UTC (permalink / raw)
To: greearb, kvalo; +Cc: linux-wireless, ath10k
On Thu, 2016-09-15 at 08:14 -0700, Ben Greear wrote:
> On 09/15/2016 07:06 AM, Valo, Kalle wrote:
> > Ben Greear <greearb@candelatech.com> writes:
> >
> > > On 09/14/2016 07:18 AM, Valo, Kalle wrote:
> > > > greearb@candelatech.com writes:
> > > >
> > > > > From: Ben Greear <greearb@candelatech.com>
> > > > >
> > > > > This allows user-space tools to decode debug-log
> > > > > messages by parsing dmesg or /var/log/messages.
> > > > >
> > > > > Signed-off-by: Ben Greear <greearb@candelatech.com>
> > > >
> > > > Don't tracing points already provide the same information?
> > >
> > > Tracing tools are difficult to set up and may not be available on
> > > random embedded devices. And if we are dealing with bug reports
> > > from
> > > the field, most users will not be able to set it up regardless.
> > >
> > > There are similar ways to print out hex, but the logic below
> > > creates
> > > specific and parseable logs in the 'dmesg' output and similar.
> > >
> > > I have written a tool that can decode these messages into useful
> > > human-readable
> > > text so that I can debug firmware issues both locally and from
> > > field reports.
> > >
> > > Stock firmware generates similar logs and QCA could write their
> > > own decode logic
> > > for their firmware versions.
> >
> > Reinventing the wheel by using printk as the delivery mechanism
> > doesn't
> > sound like a good idea. IIRC Emmanuel talked about some kind of
> > firmware
> > debugging framework, he might have some ideas.
>
> Waiting for magical frameworks to fix problems is even worse.
>
It has been years since ath10k has been in the kernel. There is
> basically
> still no way to debug what the firmware is doing.
>
I know the feeling :) I was in the same situation before I added stuff
for iwlwifi.
> My patch gives you something that can work right now, with the
> standard 'dmesg'
> framework found in virtually all kernels new and old, and it has been
> proven
> to be useful in the field. The messages are also nicely interleaved
> with the
> rest of the mac80211 stack messages and any other driver messages, so
> you have
> context.
>
> If someone wants to add support for a framework later, then by all
> means, post
> the patches when it is ready.
From my experience, a strong and easy-to-use firmware debug
infrastructure is important because typically, the firmware is written
by other people who have different priorities (and are not always Linux
wizards) etc... Being able to give them good data is the only way to
have them fix their bugs :) For us, it was really a game changer. When
you work for a big corporate, having 2 groups work better together
always has a big impact. That's for the philosophical part :)
FWIW: what I did has nothing to do with FW 'live tracing', but with
firmware dumps. One part of our firmware dumps include tracing. We also
have "firmware prints", but we don't print them in the kernel log and
they are not part of the firmware dump thing. We rather record them in
tracepoints just like really *anything* that comes from the firmware.
Basically, we have 2 layers, the transport layer (PCIe) and the
operation_mode layer. The first just brings the data from the firmware
and in that layer we *blindly* record everything in tracepoints. In the
operation_mode layer, we look at the data itself. In case of debug
prints from the firmware, we simply discard them, because we don't
really care of the meaning. All we want is to have them go through the
PCIe layer so that they are recorded in the tracepoints.
When we finish recording the sequence we wanted with tracing (trace
-cmd), we parse the output and then, we parse the firmware prints.
IMHO, this is more reliable than kernel logs and you don't lose the
alignment with the driver traces as long as you have driver data in
tracepoints as well.
>
> Thanks,
> Ben
>
>
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
2016-09-15 17:34 ` Grumbach, Emmanuel
@ 2016-09-15 17:59 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-15 17:59 UTC (permalink / raw)
To: Grumbach, Emmanuel, kvalo; +Cc: linux-wireless, ath10k
On 09/15/2016 10:34 AM, Grumbach, Emmanuel wrote:
> On Thu, 2016-09-15 at 08:14 -0700, Ben Greear wrote:
>> On 09/15/2016 07:06 AM, Valo, Kalle wrote:
>>> Ben Greear <greearb@candelatech.com> writes:
>>>
>>>> On 09/14/2016 07:18 AM, Valo, Kalle wrote:
>>>>> greearb@candelatech.com writes:
>>>>>
>>>>>> From: Ben Greear <greearb@candelatech.com>
>>>>>>
>>>>>> This allows user-space tools to decode debug-log
>>>>>> messages by parsing dmesg or /var/log/messages.
>>>>>>
>>>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>>>
>>>>> Don't tracing points already provide the same information?
>>>>
>>>> Tracing tools are difficult to set up and may not be available on
>>>> random embedded devices. And if we are dealing with bug reports
>>>> from
>>>> the field, most users will not be able to set it up regardless.
>>>>
>>>> There are similar ways to print out hex, but the logic below
>>>> creates
>>>> specific and parseable logs in the 'dmesg' output and similar.
>>>>
>>>> I have written a tool that can decode these messages into useful
>>>> human-readable
>>>> text so that I can debug firmware issues both locally and from
>>>> field reports.
>>>>
>>>> Stock firmware generates similar logs and QCA could write their
>>>> own decode logic
>>>> for their firmware versions.
>>>
>>> Reinventing the wheel by using printk as the delivery mechanism
>>> doesn't
>>> sound like a good idea. IIRC Emmanuel talked about some kind of
>>> firmware
>>> debugging framework, he might have some ideas.
>>
>> Waiting for magical frameworks to fix problems is even worse.
>>
> It has been years since ath10k has been in the kernel. There is
>> basically
>> still no way to debug what the firmware is doing.
>>
>
> I know the feeling :) I was in the same situation before I added stuff
> for iwlwifi.
>
>> My patch gives you something that can work right now, with the
>> standard 'dmesg'
>> framework found in virtually all kernels new and old, and it has been
>> proven
>> to be useful in the field. The messages are also nicely interleaved
>> with the
>> rest of the mac80211 stack messages and any other driver messages, so
>> you have
>> context.
>>
>> If someone wants to add support for a framework later, then by all
>> means, post
>> the patches when it is ready.
>
> From my experience, a strong and easy-to-use firmware debug
> infrastructure is important because typically, the firmware is written
> by other people who have different priorities (and are not always Linux
> wizards) etc... Being able to give them good data is the only way to
> have them fix their bugs :) For us, it was really a game changer. When
> you work for a big corporate, having 2 groups work better together
> always has a big impact. That's for the philosophical part :)
>
> FWIW: what I did has nothing to do with FW 'live tracing', but with
> firmware dumps. One part of our firmware dumps include tracing. We also
> have "firmware prints", but we don't print them in the kernel log and
> they are not part of the firmware dump thing. We rather record them in
> tracepoints just like really *anything* that comes from the firmware.
> Basically, we have 2 layers, the transport layer (PCIe) and the
> operation_mode layer. The first just brings the data from the firmware
> and in that layer we *blindly* record everything in tracepoints. In the
> operation_mode layer, we look at the data itself. In case of debug
> prints from the firmware, we simply discard them, because we don't
> really care of the meaning. All we want is to have them go through the
> PCIe layer so that they are recorded in the tracepoints.
> When we finish recording the sequence we wanted with tracing (trace
> -cmd), we parse the output and then, we parse the firmware prints.
> IMHO, this is more reliable than kernel logs and you don't lose the
> alignment with the driver traces as long as you have driver data in
> tracepoints as well.
I have other patches that remember the last 100 or so firmware log messages from
the kernel and provide that in a binary dump image when firmware crashes.
This is indeed very useful.
But, when debugging non-crash occasions, it is still useful to see what
the firmware is doing.
For instance, maybe it is reporting lots of tx-hangs and/or low-level
resets. This gives you a clue as to why a user might report 'my wifi sucks'.
Since I am both FW and driver team for my firmware variant,
and my approach has been working for me, then I feel it is certainly better than
the current state. And just maybe the official upstream FW team could start
using something similar as well. Currently, I don't see how they can ever make
much progress on firmware crashes reported in stock kernels.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
@ 2016-09-15 17:59 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-15 17:59 UTC (permalink / raw)
To: Grumbach, Emmanuel, kvalo; +Cc: linux-wireless, ath10k
On 09/15/2016 10:34 AM, Grumbach, Emmanuel wrote:
> On Thu, 2016-09-15 at 08:14 -0700, Ben Greear wrote:
>> On 09/15/2016 07:06 AM, Valo, Kalle wrote:
>>> Ben Greear <greearb@candelatech.com> writes:
>>>
>>>> On 09/14/2016 07:18 AM, Valo, Kalle wrote:
>>>>> greearb@candelatech.com writes:
>>>>>
>>>>>> From: Ben Greear <greearb@candelatech.com>
>>>>>>
>>>>>> This allows user-space tools to decode debug-log
>>>>>> messages by parsing dmesg or /var/log/messages.
>>>>>>
>>>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>>>
>>>>> Don't tracing points already provide the same information?
>>>>
>>>> Tracing tools are difficult to set up and may not be available on
>>>> random embedded devices. And if we are dealing with bug reports
>>>> from
>>>> the field, most users will not be able to set it up regardless.
>>>>
>>>> There are similar ways to print out hex, but the logic below
>>>> creates
>>>> specific and parseable logs in the 'dmesg' output and similar.
>>>>
>>>> I have written a tool that can decode these messages into useful
>>>> human-readable
>>>> text so that I can debug firmware issues both locally and from
>>>> field reports.
>>>>
>>>> Stock firmware generates similar logs and QCA could write their
>>>> own decode logic
>>>> for their firmware versions.
>>>
>>> Reinventing the wheel by using printk as the delivery mechanism
>>> doesn't
>>> sound like a good idea. IIRC Emmanuel talked about some kind of
>>> firmware
>>> debugging framework, he might have some ideas.
>>
>> Waiting for magical frameworks to fix problems is even worse.
>>
> It has been years since ath10k has been in the kernel. There is
>> basically
>> still no way to debug what the firmware is doing.
>>
>
> I know the feeling :) I was in the same situation before I added stuff
> for iwlwifi.
>
>> My patch gives you something that can work right now, with the
>> standard 'dmesg'
>> framework found in virtually all kernels new and old, and it has been
>> proven
>> to be useful in the field. The messages are also nicely interleaved
>> with the
>> rest of the mac80211 stack messages and any other driver messages, so
>> you have
>> context.
>>
>> If someone wants to add support for a framework later, then by all
>> means, post
>> the patches when it is ready.
>
> From my experience, a strong and easy-to-use firmware debug
> infrastructure is important because typically, the firmware is written
> by other people who have different priorities (and are not always Linux
> wizards) etc... Being able to give them good data is the only way to
> have them fix their bugs :) For us, it was really a game changer. When
> you work for a big corporate, having 2 groups work better together
> always has a big impact. That's for the philosophical part :)
>
> FWIW: what I did has nothing to do with FW 'live tracing', but with
> firmware dumps. One part of our firmware dumps include tracing. We also
> have "firmware prints", but we don't print them in the kernel log and
> they are not part of the firmware dump thing. We rather record them in
> tracepoints just like really *anything* that comes from the firmware.
> Basically, we have 2 layers, the transport layer (PCIe) and the
> operation_mode layer. The first just brings the data from the firmware
> and in that layer we *blindly* record everything in tracepoints. In the
> operation_mode layer, we look at the data itself. In case of debug
> prints from the firmware, we simply discard them, because we don't
> really care of the meaning. All we want is to have them go through the
> PCIe layer so that they are recorded in the tracepoints.
> When we finish recording the sequence we wanted with tracing (trace
> -cmd), we parse the output and then, we parse the firmware prints.
> IMHO, this is more reliable than kernel logs and you don't lose the
> alignment with the driver traces as long as you have driver data in
> tracepoints as well.
I have other patches that remember the last 100 or so firmware log messages from
the kernel and provide that in a binary dump image when firmware crashes.
This is indeed very useful.
But, when debugging non-crash occasions, it is still useful to see what
the firmware is doing.
For instance, maybe it is reporting lots of tx-hangs and/or low-level
resets. This gives you a clue as to why a user might report 'my wifi sucks'.
Since I am both FW and driver team for my firmware variant,
and my approach has been working for me, then I feel it is certainly better than
the current state. And just maybe the official upstream FW team could start
using something similar as well. Currently, I don't see how they can ever make
much progress on firmware crashes reported in stock kernels.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
2016-09-15 17:59 ` Ben Greear
@ 2016-09-15 18:08 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-15 18:08 UTC (permalink / raw)
To: Grumbach, Emmanuel, kvalo; +Cc: linux-wireless, ath10k
On 09/15/2016 10:59 AM, Ben Greear wrote:
> On 09/15/2016 10:34 AM, Grumbach, Emmanuel wrote:
> I have other patches that remember the last 100 or so firmware log messages from
> the kernel and provide that in a binary dump image when firmware crashes.
>
> This is indeed very useful.
>
> But, when debugging non-crash occasions, it is still useful to see what
> the firmware is doing.
>
> For instance, maybe it is reporting lots of tx-hangs and/or low-level
> resets. This gives you a clue as to why a user might report 'my wifi sucks'.
>
> Since I am both FW and driver team for my firmware variant,
> and my approach has been working for me, then I feel it is certainly better than
> the current state. And just maybe the official upstream FW team could start
> using something similar as well. Currently, I don't see how they can ever make
> much progress on firmware crashes reported in stock kernels.
I forgot the other good reason about console logging this:
Sometimes ath10k firmware crash causes the entire kernel to crash, so there is no time to
grab the binary dump from a file system...but a serial console can help you
make progress...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
@ 2016-09-15 18:08 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-15 18:08 UTC (permalink / raw)
To: Grumbach, Emmanuel, kvalo; +Cc: linux-wireless, ath10k
On 09/15/2016 10:59 AM, Ben Greear wrote:
> On 09/15/2016 10:34 AM, Grumbach, Emmanuel wrote:
> I have other patches that remember the last 100 or so firmware log messages from
> the kernel and provide that in a binary dump image when firmware crashes.
>
> This is indeed very useful.
>
> But, when debugging non-crash occasions, it is still useful to see what
> the firmware is doing.
>
> For instance, maybe it is reporting lots of tx-hangs and/or low-level
> resets. This gives you a clue as to why a user might report 'my wifi sucks'.
>
> Since I am both FW and driver team for my firmware variant,
> and my approach has been working for me, then I feel it is certainly better than
> the current state. And just maybe the official upstream FW team could start
> using something similar as well. Currently, I don't see how they can ever make
> much progress on firmware crashes reported in stock kernels.
I forgot the other good reason about console logging this:
Sometimes ath10k firmware crash causes the entire kernel to crash, so there is no time to
grab the binary dump from a file system...but a serial console can help you
make progress...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
2016-09-15 17:59 ` Ben Greear
@ 2016-09-15 20:22 ` Grumbach, Emmanuel
-1 siblings, 0 replies; 118+ messages in thread
From: Grumbach, Emmanuel @ 2016-09-15 20:22 UTC (permalink / raw)
To: greearb, kvalo; +Cc: linux-wireless, ath10k
T24gVGh1LCAyMDE2LTA5LTE1IGF0IDEwOjU5IC0wNzAwLCBCZW4gR3JlZWFyIHdyb3RlOg0KPiBP
biAwOS8xNS8yMDE2IDEwOjM0IEFNLCBHcnVtYmFjaCwgRW1tYW51ZWwgd3JvdGU6DQo+ID4gT24g
VGh1LCAyMDE2LTA5LTE1IGF0IDA4OjE0IC0wNzAwLCBCZW4gR3JlZWFyIHdyb3RlOg0KPiA+ID4g
T24gMDkvMTUvMjAxNiAwNzowNiBBTSwgVmFsbywgS2FsbGUgd3JvdGU6DQo+ID4gPiA+IEJlbiBH
cmVlYXIgPGdyZWVhcmJAY2FuZGVsYXRlY2guY29tPiB3cml0ZXM6DQo+ID4gPiA+IA0KPiA+ID4g
PiA+IE9uIDA5LzE0LzIwMTYgMDc6MTggQU0sIFZhbG8sIEthbGxlIHdyb3RlOg0KPiA+ID4gPiA+
ID4gZ3JlZWFyYkBjYW5kZWxhdGVjaC5jb20gd3JpdGVzOg0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+
ID4gPiA+IEZyb206IEJlbiBHcmVlYXIgPGdyZWVhcmJAY2FuZGVsYXRlY2guY29tPg0KPiA+ID4g
PiA+ID4gPiANCj4gPiA+ID4gPiA+ID4gVGhpcyBhbGxvd3MgdXNlci1zcGFjZSB0b29scyB0byBk
ZWNvZGUgZGVidWctbG9nDQo+ID4gPiA+ID4gPiA+IG1lc3NhZ2VzIGJ5IHBhcnNpbmcgZG1lc2cg
b3IgL3Zhci9sb2cvbWVzc2FnZXMuDQo+ID4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gPiBTaWdu
ZWQtb2ZmLWJ5OiBCZW4gR3JlZWFyIDxncmVlYXJiQGNhbmRlbGF0ZWNoLmNvbT4NCj4gPiA+ID4g
PiA+IA0KPiA+ID4gPiA+ID4gRG9uJ3QgdHJhY2luZyBwb2ludHMgYWxyZWFkeSBwcm92aWRlIHRo
ZSBzYW1lIGluZm9ybWF0aW9uPw0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IFRyYWNpbmcgdG9vbHMg
YXJlIGRpZmZpY3VsdCB0byBzZXQgdXAgYW5kIG1heSBub3QgYmUNCj4gPiA+ID4gPiBhdmFpbGFi
bGUgb24NCj4gPiA+ID4gPiByYW5kb20gZW1iZWRkZWQgZGV2aWNlcy4gIEFuZCBpZiB3ZSBhcmUg
ZGVhbGluZyB3aXRoIGJ1Zw0KPiA+ID4gPiA+IHJlcG9ydHMNCj4gPiA+ID4gPiBmcm9tDQo+ID4g
PiA+ID4gdGhlIGZpZWxkLCBtb3N0IHVzZXJzIHdpbGwgbm90IGJlIGFibGUgdG8gc2V0IGl0IHVw
DQo+ID4gPiA+ID4gcmVnYXJkbGVzcy4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBUaGVyZSBhcmUg
c2ltaWxhciB3YXlzIHRvIHByaW50IG91dCBoZXgsIGJ1dCB0aGUgbG9naWMgYmVsb3cNCj4gPiA+
ID4gPiBjcmVhdGVzDQo+ID4gPiA+ID4gc3BlY2lmaWMgYW5kIHBhcnNlYWJsZSBsb2dzIGluIHRo
ZSAnZG1lc2cnIG91dHB1dCBhbmQNCj4gPiA+ID4gPiBzaW1pbGFyLg0KPiA+ID4gPiA+IA0KPiA+
ID4gPiA+IEkgaGF2ZSB3cml0dGVuIGEgdG9vbCB0aGF0IGNhbiBkZWNvZGUgdGhlc2UgbWVzc2Fn
ZXMgaW50bw0KPiA+ID4gPiA+IHVzZWZ1bA0KPiA+ID4gPiA+IGh1bWFuLXJlYWRhYmxlDQo+ID4g
PiA+ID4gdGV4dCBzbyB0aGF0IEkgY2FuIGRlYnVnIGZpcm13YXJlIGlzc3VlcyBib3RoIGxvY2Fs
bHkgYW5kDQo+ID4gPiA+ID4gZnJvbQ0KPiA+ID4gPiA+IGZpZWxkIHJlcG9ydHMuDQo+ID4gPiA+
ID4gDQo+ID4gPiA+ID4gU3RvY2sgZmlybXdhcmUgZ2VuZXJhdGVzIHNpbWlsYXIgbG9ncyBhbmQg
UUNBIGNvdWxkIHdyaXRlDQo+ID4gPiA+ID4gdGhlaXINCj4gPiA+ID4gPiBvd24gZGVjb2RlIGxv
Z2ljDQo+ID4gPiA+ID4gZm9yIHRoZWlyIGZpcm13YXJlIHZlcnNpb25zLg0KPiA+ID4gPiANCj4g
PiA+ID4gUmVpbnZlbnRpbmcgdGhlIHdoZWVsIGJ5IHVzaW5nIHByaW50ayBhcyB0aGUgZGVsaXZl
cnkgbWVjaGFuaXNtDQo+ID4gPiA+IGRvZXNuJ3QNCj4gPiA+ID4gc291bmQgbGlrZSBhIGdvb2Qg
aWRlYS4gSUlSQyBFbW1hbnVlbCB0YWxrZWQgYWJvdXQgc29tZSBraW5kIG9mDQo+ID4gPiA+IGZp
cm13YXJlDQo+ID4gPiA+IGRlYnVnZ2luZyBmcmFtZXdvcmssIGhlIG1pZ2h0IGhhdmUgc29tZSBp
ZGVhcy4NCj4gPiA+IA0KPiA+ID4gV2FpdGluZyBmb3IgbWFnaWNhbCBmcmFtZXdvcmtzIHRvIGZp
eCBwcm9ibGVtcyBpcyBldmVuIHdvcnNlLg0KPiA+ID4gDQo+ID4gSXQgaGFzIGJlZW4geWVhcnMg
c2luY2UgYXRoMTBrIGhhcyBiZWVuIGluIHRoZSBrZXJuZWwuICBUaGVyZSBpcw0KPiA+ID4gYmFz
aWNhbGx5DQo+ID4gPiBzdGlsbCBubyB3YXkgdG8gZGVidWcgd2hhdCB0aGUgZmlybXdhcmUgaXMg
ZG9pbmcuDQo+ID4gPiANCj4gPiANCj4gPiBJIGtub3cgdGhlIGZlZWxpbmcgOikgSSB3YXMgaW4g
dGhlIHNhbWUgc2l0dWF0aW9uIGJlZm9yZSBJIGFkZGVkDQo+ID4gc3R1ZmYNCj4gPiBmb3IgaXds
d2lmaS4NCj4gPiANCj4gPiA+IE15IHBhdGNoIGdpdmVzIHlvdSBzb21ldGhpbmcgdGhhdCBjYW4g
d29yayByaWdodCBub3csIHdpdGggdGhlDQo+ID4gPiBzdGFuZGFyZCAnZG1lc2cnDQo+ID4gPiBm
cmFtZXdvcmsgZm91bmQgaW4gdmlydHVhbGx5IGFsbCBrZXJuZWxzIG5ldyBhbmQgb2xkLCBhbmQg
aXQgaGFzDQo+ID4gPiBiZWVuDQo+ID4gPiBwcm92ZW4NCj4gPiA+IHRvIGJlIHVzZWZ1bCBpbiB0
aGUgZmllbGQuICBUaGUgbWVzc2FnZXMgYXJlIGFsc28gbmljZWx5DQo+ID4gPiBpbnRlcmxlYXZl
ZA0KPiA+ID4gd2l0aCB0aGUNCj4gPiA+IHJlc3Qgb2YgdGhlIG1hYzgwMjExIHN0YWNrIG1lc3Nh
Z2VzIGFuZCBhbnkgb3RoZXIgZHJpdmVyDQo+ID4gPiBtZXNzYWdlcywgc28NCj4gPiA+IHlvdSBo
YXZlDQo+ID4gPiBjb250ZXh0Lg0KPiA+ID4gDQo+ID4gPiBJZiBzb21lb25lIHdhbnRzIHRvIGFk
ZCBzdXBwb3J0IGZvciBhIGZyYW1ld29yayBsYXRlciwgdGhlbiBieQ0KPiA+ID4gYWxsDQo+ID4g
PiBtZWFucywgcG9zdA0KPiA+ID4gdGhlIHBhdGNoZXMgd2hlbiBpdCBpcyByZWFkeS4NCj4gPiAN
Cj4gPiBGcm9tIG15IGV4cGVyaWVuY2UsIGEgc3Ryb25nIGFuZCBlYXN5LXRvLXVzZSBmaXJtd2Fy
ZSBkZWJ1Zw0KPiA+IGluZnJhc3RydWN0dXJlIGlzIGltcG9ydGFudCBiZWNhdXNlIHR5cGljYWxs
eSwgdGhlIGZpcm13YXJlIGlzDQo+ID4gd3JpdHRlbg0KPiA+IGJ5IG90aGVyIHBlb3BsZSB3aG8g
aGF2ZSBkaWZmZXJlbnQgcHJpb3JpdGllcyAoYW5kIGFyZSBub3QgYWx3YXlzDQo+ID4gTGludXgN
Cj4gPiB3aXphcmRzKSBldGMuLi4gQmVpbmcgYWJsZSB0byBnaXZlIHRoZW0gZ29vZCBkYXRhIGlz
IHRoZSBvbmx5IHdheQ0KPiA+IHRvDQo+ID4gaGF2ZSB0aGVtIGZpeCB0aGVpciBidWdzIDopIEZv
ciB1cywgaXQgd2FzIHJlYWxseSBhIGdhbWUgY2hhbmdlci4NCj4gPiBXaGVuDQo+ID4geW91IHdv
cmsgZm9yIGEgYmlnIGNvcnBvcmF0ZSwgaGF2aW5nIDIgZ3JvdXBzIHdvcmsgYmV0dGVyIHRvZ2V0
aGVyDQo+ID4gYWx3YXlzIGhhcyBhIGJpZyBpbXBhY3QuIFRoYXQncyBmb3IgdGhlIHBoaWxvc29w
aGljYWwgcGFydCA6KQ0KPiA+IA0KPiA+IEZXSVc6IHdoYXQgSSBkaWQgaGFzIG5vdGhpbmcgdG8g
ZG8gd2l0aCBGVyAnbGl2ZSB0cmFjaW5nJywgYnV0IHdpdGgNCj4gPiBmaXJtd2FyZSBkdW1wcy4g
T25lIHBhcnQgb2Ygb3VyIGZpcm13YXJlIGR1bXBzIGluY2x1ZGUgdHJhY2luZy4gV2UNCj4gPiBh
bHNvDQo+ID4gaGF2ZSAiZmlybXdhcmUgcHJpbnRzIiwgYnV0IHdlIGRvbid0IHByaW50IHRoZW0g
aW4gdGhlIGtlcm5lbCBsb2cNCj4gPiBhbmQNCj4gPiB0aGV5IGFyZSBub3QgcGFydCBvZiB0aGUg
ZmlybXdhcmUgZHVtcCB0aGluZy4gV2UgcmF0aGVyIHJlY29yZCB0aGVtDQo+ID4gaW4NCj4gPiB0
cmFjZXBvaW50cyBqdXN0IGxpa2UgcmVhbGx5ICphbnl0aGluZyogdGhhdCBjb21lcyBmcm9tIHRo
ZQ0KPiA+IGZpcm13YXJlLg0KPiA+IEJhc2ljYWxseSwgd2UgaGF2ZSAyIGxheWVycywgdGhlIHRy
YW5zcG9ydCBsYXllciAoUENJZSkgYW5kIHRoZQ0KPiA+IG9wZXJhdGlvbl9tb2RlIGxheWVyLiBU
aGUgZmlyc3QganVzdCBicmluZ3MgdGhlIGRhdGEgZnJvbSB0aGUNCj4gPiBmaXJtd2FyZQ0KPiA+
IGFuZCBpbiB0aGF0IGxheWVyIHdlICpibGluZGx5KiByZWNvcmQgZXZlcnl0aGluZyBpbiB0cmFj
ZXBvaW50cy4gSW4NCj4gPiB0aGUNCj4gPiBvcGVyYXRpb25fbW9kZSBsYXllciwgd2UgbG9vayBh
dCB0aGUgZGF0YSBpdHNlbGYuIEluIGNhc2Ugb2YgZGVidWcNCj4gPiBwcmludHMgZnJvbSB0aGUg
ZmlybXdhcmUsIHdlIHNpbXBseSBkaXNjYXJkIHRoZW0sIGJlY2F1c2Ugd2UgZG9uJ3QNCj4gPiBy
ZWFsbHkgY2FyZSBvZiB0aGUgbWVhbmluZy4gQWxsIHdlIHdhbnQgaXMgdG8gaGF2ZSB0aGVtIGdv
IHRocm91Z2gNCj4gPiB0aGUNCj4gPiBQQ0llIGxheWVyIHNvIHRoYXQgdGhleSBhcmUgcmVjb3Jk
ZWQgaW4gdGhlIHRyYWNlcG9pbnRzLg0KPiA+IFdoZW4gd2UgZmluaXNoIHJlY29yZGluZyB0aGUg
c2VxdWVuY2Ugd2Ugd2FudGVkIHdpdGggdHJhY2luZyAodHJhY2UNCj4gPiAtY21kKSwgd2UgcGFy
c2UgdGhlIG91dHB1dCBhbmQgdGhlbiwgd2UgcGFyc2UgdGhlIGZpcm13YXJlIHByaW50cy4NCj4g
PiBJTUhPLCB0aGlzIGlzIG1vcmUgcmVsaWFibGUgdGhhbiBrZXJuZWwgbG9ncyBhbmQgeW91IGRv
bid0IGxvc2UgdGhlDQo+ID4gYWxpZ25tZW50IHdpdGggdGhlIGRyaXZlciB0cmFjZXMgYXMgbG9u
ZyBhcyB5b3UgaGF2ZSBkcml2ZXIgZGF0YSBpbg0KPiA+IHRyYWNlcG9pbnRzIGFzIHdlbGwuDQo+
IA0KPiBJIGhhdmUgb3RoZXIgcGF0Y2hlcyB0aGF0IHJlbWVtYmVyIHRoZSBsYXN0IDEwMCBvciBz
byBmaXJtd2FyZSBsb2cNCj4gbWVzc2FnZXMgZnJvbQ0KPiB0aGUga2VybmVsIGFuZCBwcm92aWRl
IHRoYXQgaW4gYSBiaW5hcnkgZHVtcCBpbWFnZSB3aGVuIGZpcm13YXJlDQo+IGNyYXNoZXMuDQo+
IA0KPiBUaGlzIGlzIGluZGVlZCB2ZXJ5IHVzZWZ1bC4NCj4gDQo+IEJ1dCwgd2hlbiBkZWJ1Z2dp
bmcgbm9uLWNyYXNoIG9jY2FzaW9ucywgaXQgaXMgc3RpbGwgdXNlZnVsIHRvIHNlZQ0KPiB3aGF0
DQo+IHRoZSBmaXJtd2FyZSBpcyBkb2luZy4NCj4gDQoNCkZvciB0aGF0LCBJIGhhdmUgY29tZSB1
cCB3aXRoIHRoZSAidHJpZ2dlcnMiLiBUcmlnZ2VycyBhcmUgY29uZGl0aW9ucw0KdGhhdCBjYW4g
YmUgZGV0ZWN0ZWQgYnkgdGhlIGRyaXZlciBhbmQgZW5hYmxlZCBieSB0aGUgdXNlci4gU28NCmJh
c2ljYWxseSwgd2UgY2FuIHNheTogIlBsZWFzZSBkdW1wIHRoZSBsb2dzIHdoZW4geW91IGFyZSBk
ZWF1dGgnZWQgYnkNCnRoZSBBUCIuIE9yIHdoZW4geW91IGdldCBkZWxCQSwgb3Igd2hlbiB0aGUg
c3RhdHMgdGhhdCBjb21lIHVwIGZyb20gdGhlDQpmaXJtd2FyZSBzYXkgc3VjaCBhbmQgc3VjaCBl
dGMuLi4gVGhlcmUgYXJlIGhvb2tzIHRoYXQgSSBhZGRlZCBpbg0KbWFjODAyMTEgdG8gbGV0IHRo
ZSBkcml2ZXIga25vdyBhYm91dCBldmVudHMgdGhhdCBhcmUgaGFuZGxlZCB0aGVyZQ0KKE1MTUUg
YW5kIGZyaWVuZHMpLiBUaGVuLCBldmVuIGlmIHlvdXIgbG9ncyBhcmUgc3RvcmVkIGluIGEgY3lj
bGljDQpidWZmZXIsIHlvdSBkb24ndCBtaXNzIHRoZW0gYW5kIHlvdSBjYXRjaCB0aGVtIGF0IHRo
ZSByaWdodCBzcG90Lg0KT25lIG9mIHRoZSBtb3N0IHVzZWZ1bCB0cmlnZ2VyIHdlIGhhdmUgaXMg
d2hlbiBhIFR4IHBhY2tldCBpcyBkcm9wcGVkLg0KWW91IGNhbiB0YWtlIGEgbG9vayBhdCBzdHJ1
Y3QgaXdsX2Z3X2RiZ190cmlnZ2VyX3RsdiBpbiBpd2x3aWZpIGlmIHlvdQ0Kd2FudC4NCg0KPiBG
b3IgaW5zdGFuY2UsIG1heWJlIGl0IGlzIHJlcG9ydGluZyBsb3RzIG9mIHR4LWhhbmdzIGFuZC9v
ciBsb3ctbGV2ZWwNCj4gcmVzZXRzLiAgVGhpcyBnaXZlcyB5b3UgYSBjbHVlIGFzIHRvIHdoeSBh
IHVzZXIgbWlnaHQgcmVwb3J0ICdteSB3aWZpDQo+IHN1Y2tzJy4NCj4gPiBTaW5jZSBJIGFtIGJv
dGggRlcgYW5kIGRyaXZlciB0ZWFtIGZvciBteSBmaXJtd2FyZSB2YXJpYW50LA0KPiBhbmQgbXkg
YXBwcm9hY2ggaGFzIGJlZW4gd29ya2luZyBmb3IgbWUsIHRoZW4gSSBmZWVsIGl0IGlzIGNlcnRh
aW5seQ0KPiBiZXR0ZXIgdGhhbg0KPiB0aGUgY3VycmVudCBzdGF0ZS4gIEFuZCBqdXN0IG1heWJl
IHRoZSBvZmZpY2lhbCB1cHN0cmVhbSBGVyB0ZWFtDQo+IGNvdWxkIHN0YXJ0DQo+IHVzaW5nIHNv
bWV0aGluZyBzaW1pbGFyIGFzIHdlbGwuICBDdXJyZW50bHksIEkgZG9uJ3Qgc2VlIGhvdyB0aGV5
IGNhbg0KPiBldmVyIG1ha2UNCj4gbXVjaCBwcm9ncmVzcyBvbiBmaXJtd2FyZSBjcmFzaGVzIHJl
cG9ydGVkIGluIHN0b2NrIGtlcm5lbHMuDQo+ID4gVGhhbmtzLA0KPiBCZW4NCg==
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
@ 2016-09-15 20:22 ` Grumbach, Emmanuel
0 siblings, 0 replies; 118+ messages in thread
From: Grumbach, Emmanuel @ 2016-09-15 20:22 UTC (permalink / raw)
To: greearb, kvalo; +Cc: linux-wireless, ath10k
On Thu, 2016-09-15 at 10:59 -0700, Ben Greear wrote:
> On 09/15/2016 10:34 AM, Grumbach, Emmanuel wrote:
> > On Thu, 2016-09-15 at 08:14 -0700, Ben Greear wrote:
> > > On 09/15/2016 07:06 AM, Valo, Kalle wrote:
> > > > Ben Greear <greearb@candelatech.com> writes:
> > > >
> > > > > On 09/14/2016 07:18 AM, Valo, Kalle wrote:
> > > > > > greearb@candelatech.com writes:
> > > > > >
> > > > > > > From: Ben Greear <greearb@candelatech.com>
> > > > > > >
> > > > > > > This allows user-space tools to decode debug-log
> > > > > > > messages by parsing dmesg or /var/log/messages.
> > > > > > >
> > > > > > > Signed-off-by: Ben Greear <greearb@candelatech.com>
> > > > > >
> > > > > > Don't tracing points already provide the same information?
> > > > >
> > > > > Tracing tools are difficult to set up and may not be
> > > > > available on
> > > > > random embedded devices. And if we are dealing with bug
> > > > > reports
> > > > > from
> > > > > the field, most users will not be able to set it up
> > > > > regardless.
> > > > >
> > > > > There are similar ways to print out hex, but the logic below
> > > > > creates
> > > > > specific and parseable logs in the 'dmesg' output and
> > > > > similar.
> > > > >
> > > > > I have written a tool that can decode these messages into
> > > > > useful
> > > > > human-readable
> > > > > text so that I can debug firmware issues both locally and
> > > > > from
> > > > > field reports.
> > > > >
> > > > > Stock firmware generates similar logs and QCA could write
> > > > > their
> > > > > own decode logic
> > > > > for their firmware versions.
> > > >
> > > > Reinventing the wheel by using printk as the delivery mechanism
> > > > doesn't
> > > > sound like a good idea. IIRC Emmanuel talked about some kind of
> > > > firmware
> > > > debugging framework, he might have some ideas.
> > >
> > > Waiting for magical frameworks to fix problems is even worse.
> > >
> > It has been years since ath10k has been in the kernel. There is
> > > basically
> > > still no way to debug what the firmware is doing.
> > >
> >
> > I know the feeling :) I was in the same situation before I added
> > stuff
> > for iwlwifi.
> >
> > > My patch gives you something that can work right now, with the
> > > standard 'dmesg'
> > > framework found in virtually all kernels new and old, and it has
> > > been
> > > proven
> > > to be useful in the field. The messages are also nicely
> > > interleaved
> > > with the
> > > rest of the mac80211 stack messages and any other driver
> > > messages, so
> > > you have
> > > context.
> > >
> > > If someone wants to add support for a framework later, then by
> > > all
> > > means, post
> > > the patches when it is ready.
> >
> > From my experience, a strong and easy-to-use firmware debug
> > infrastructure is important because typically, the firmware is
> > written
> > by other people who have different priorities (and are not always
> > Linux
> > wizards) etc... Being able to give them good data is the only way
> > to
> > have them fix their bugs :) For us, it was really a game changer.
> > When
> > you work for a big corporate, having 2 groups work better together
> > always has a big impact. That's for the philosophical part :)
> >
> > FWIW: what I did has nothing to do with FW 'live tracing', but with
> > firmware dumps. One part of our firmware dumps include tracing. We
> > also
> > have "firmware prints", but we don't print them in the kernel log
> > and
> > they are not part of the firmware dump thing. We rather record them
> > in
> > tracepoints just like really *anything* that comes from the
> > firmware.
> > Basically, we have 2 layers, the transport layer (PCIe) and the
> > operation_mode layer. The first just brings the data from the
> > firmware
> > and in that layer we *blindly* record everything in tracepoints. In
> > the
> > operation_mode layer, we look at the data itself. In case of debug
> > prints from the firmware, we simply discard them, because we don't
> > really care of the meaning. All we want is to have them go through
> > the
> > PCIe layer so that they are recorded in the tracepoints.
> > When we finish recording the sequence we wanted with tracing (trace
> > -cmd), we parse the output and then, we parse the firmware prints.
> > IMHO, this is more reliable than kernel logs and you don't lose the
> > alignment with the driver traces as long as you have driver data in
> > tracepoints as well.
>
> I have other patches that remember the last 100 or so firmware log
> messages from
> the kernel and provide that in a binary dump image when firmware
> crashes.
>
> This is indeed very useful.
>
> But, when debugging non-crash occasions, it is still useful to see
> what
> the firmware is doing.
>
For that, I have come up with the "triggers". Triggers are conditions
that can be detected by the driver and enabled by the user. So
basically, we can say: "Please dump the logs when you are deauth'ed by
the AP". Or when you get delBA, or when the stats that come up from the
firmware say such and such etc... There are hooks that I added in
mac80211 to let the driver know about events that are handled there
(MLME and friends). Then, even if your logs are stored in a cyclic
buffer, you don't miss them and you catch them at the right spot.
One of the most useful trigger we have is when a Tx packet is dropped.
You can take a look at struct iwl_fw_dbg_trigger_tlv in iwlwifi if you
want.
> For instance, maybe it is reporting lots of tx-hangs and/or low-level
> resets. This gives you a clue as to why a user might report 'my wifi
> sucks'.
> > Since I am both FW and driver team for my firmware variant,
> and my approach has been working for me, then I feel it is certainly
> better than
> the current state. And just maybe the official upstream FW team
> could start
> using something similar as well. Currently, I don't see how they can
> ever make
> much progress on firmware crashes reported in stock kernels.
> > Thanks,
> Ben
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* [PATCH v2 10/21] ath10k: support logging ath10k_info as KERN_DEBUG
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
Helps keep messages off of (serial) console when
that is desired.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/debug.c | 5 ++++-
drivers/net/wireless/ath/ath10k/debug.h | 6 ++++++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 97de9f37..76b5163 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -139,7 +139,10 @@ void ath10k_info(struct ath10k *ar, const char *fmt, ...)
va_start(args, fmt);
vaf.va = &args;
- dev_info(ar->dev, "%pV", &vaf);
+ if (ath10k_debug_mask & ATH10K_DBG_INFO_AS_DBG)
+ dev_printk(KERN_DEBUG, ar->dev, "%pV", &vaf);
+ else
+ dev_info(ar->dev, "%pV", &vaf);
trace_ath10k_log_info(ar, &vaf);
va_end(args);
}
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 641fce1..070f1c6 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -21,6 +21,10 @@
#include <linux/types.h>
#include "trace.h"
+/**
+ * ATH10K_DBG_INFO_AS_DBG: use dev_dbg instead of dev_info
+ * for ath10k_info messages
+ */
enum ath10k_debug_mask {
ATH10K_DBG_PCI = 0x00000001,
ATH10K_DBG_WMI = 0x00000002,
@@ -38,6 +42,8 @@ enum ath10k_debug_mask {
ATH10K_DBG_WMI_PRINT = 0x00002000,
ATH10K_DBG_PCI_PS = 0x00004000,
ATH10K_DBG_AHB = 0x00008000,
+
+ ATH10K_DBG_INFO_AS_DBG = 0x40000000,
ATH10K_DBG_FW = 0x80000000,
ATH10K_DBG_ANY = 0xffffffff,
};
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 10/21] ath10k: support logging ath10k_info as KERN_DEBUG
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
Helps keep messages off of (serial) console when
that is desired.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/debug.c | 5 ++++-
drivers/net/wireless/ath/ath10k/debug.h | 6 ++++++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 97de9f37..76b5163 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -139,7 +139,10 @@ void ath10k_info(struct ath10k *ar, const char *fmt, ...)
va_start(args, fmt);
vaf.va = &args;
- dev_info(ar->dev, "%pV", &vaf);
+ if (ath10k_debug_mask & ATH10K_DBG_INFO_AS_DBG)
+ dev_printk(KERN_DEBUG, ar->dev, "%pV", &vaf);
+ else
+ dev_info(ar->dev, "%pV", &vaf);
trace_ath10k_log_info(ar, &vaf);
va_end(args);
}
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 641fce1..070f1c6 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -21,6 +21,10 @@
#include <linux/types.h>
#include "trace.h"
+/**
+ * ATH10K_DBG_INFO_AS_DBG: use dev_dbg instead of dev_info
+ * for ath10k_info messages
+ */
enum ath10k_debug_mask {
ATH10K_DBG_PCI = 0x00000001,
ATH10K_DBG_WMI = 0x00000002,
@@ -38,6 +42,8 @@ enum ath10k_debug_mask {
ATH10K_DBG_WMI_PRINT = 0x00002000,
ATH10K_DBG_PCI_PS = 0x00004000,
ATH10K_DBG_AHB = 0x00008000,
+
+ ATH10K_DBG_INFO_AS_DBG = 0x40000000,
ATH10K_DBG_FW = 0x80000000,
ATH10K_DBG_ANY = 0xffffffff,
};
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread* Re: [PATCH v2 10/21] ath10k: support logging ath10k_info as KERN_DEBUG
2016-05-11 17:02 ` greearb
@ 2016-09-14 14:19 ` Valo, Kalle
-1 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 14:19 UTC (permalink / raw)
To: greearb; +Cc: ath10k, linux-wireless
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> Helps keep messages off of (serial) console when
> that is desired.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
Isn't /proc/sys/kernel/print exactly for this purpose? At least I recall
using it.
--=20
Kalle Valo=
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 10/21] ath10k: support logging ath10k_info as KERN_DEBUG
@ 2016-09-14 14:19 ` Valo, Kalle
0 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 14:19 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath10k
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> Helps keep messages off of (serial) console when
> that is desired.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
Isn't /proc/sys/kernel/print exactly for this purpose? At least I recall
using it.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 10/21] ath10k: support logging ath10k_info as KERN_DEBUG
2016-09-14 14:19 ` Valo, Kalle
@ 2016-09-14 15:14 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-14 15:14 UTC (permalink / raw)
To: Valo, Kalle; +Cc: ath10k, linux-wireless
On 09/14/2016 07:19 AM, Valo, Kalle wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> Helps keep messages off of (serial) console when
>> that is desired.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>
> Isn't /proc/sys/kernel/print exactly for this purpose? At least I recall
> using it.
I just wanted to hide some ath10k logs from the console, not all system logs. I don't think
that /proc/sys/kernel/print has any granularity?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 10/21] ath10k: support logging ath10k_info as KERN_DEBUG
@ 2016-09-14 15:14 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-14 15:14 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/14/2016 07:19 AM, Valo, Kalle wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> Helps keep messages off of (serial) console when
>> that is desired.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>
> Isn't /proc/sys/kernel/print exactly for this purpose? At least I recall
> using it.
I just wanted to hide some ath10k logs from the console, not all system logs. I don't think
that /proc/sys/kernel/print has any granularity?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 10/21] ath10k: support logging ath10k_info as KERN_DEBUG
2016-09-14 15:14 ` Ben Greear
@ 2016-09-15 14:12 ` Valo, Kalle
-1 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-15 14:12 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:19 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> Helps keep messages off of (serial) console when
>>> that is desired.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>
>> Isn't /proc/sys/kernel/print exactly for this purpose? At least I recall
>> using it.
>
> I just wanted to hide some ath10k logs from the console, not all
> system logs. I don't think that /proc/sys/kernel/print has any
> granularity?
It should be based on KERN_ log levels. I don't know what your kernel
does, but ath10k should be printing only very few messages with level
KERN_INFO or above, all of of the debug messages. So you should be
easily able to filter out all ath10k debug messages as they are sent
with KERN_DEBUG.
--=20
Kalle Valo=
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 10/21] ath10k: support logging ath10k_info as KERN_DEBUG
@ 2016-09-15 14:12 ` Valo, Kalle
0 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-15 14:12 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:19 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> Helps keep messages off of (serial) console when
>>> that is desired.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>
>> Isn't /proc/sys/kernel/print exactly for this purpose? At least I recall
>> using it.
>
> I just wanted to hide some ath10k logs from the console, not all
> system logs. I don't think that /proc/sys/kernel/print has any
> granularity?
It should be based on KERN_ log levels. I don't know what your kernel
does, but ath10k should be printing only very few messages with level
KERN_INFO or above, all of of the debug messages. So you should be
easily able to filter out all ath10k debug messages as they are sent
with KERN_DEBUG.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 10/21] ath10k: support logging ath10k_info as KERN_DEBUG
2016-09-15 14:12 ` Valo, Kalle
@ 2016-09-15 15:11 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-15 15:11 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/15/2016 07:12 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:19 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> Helps keep messages off of (serial) console when
>>>> that is desired.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>
>>> Isn't /proc/sys/kernel/print exactly for this purpose? At least I recall
>>> using it.
>>
>> I just wanted to hide some ath10k logs from the console, not all
>> system logs. I don't think that /proc/sys/kernel/print has any
>> granularity?
>
> It should be based on KERN_ log levels. I don't know what your kernel
> does, but ath10k should be printing only very few messages with level
> KERN_INFO or above, all of of the debug messages. So you should be
> easily able to filter out all ath10k debug messages as they are sent
> with KERN_DEBUG.
I originally added this when I was testing .11r associating timing. Just
having a few lines of ath10k printk on the serial console added several 10s
of milliseconds to the time it took to associate, and that was throwing off my
results. I still wanted to see the messges in 'dmesg', just not on the console.
I did not want to hide other WARN level logs from the console, just the ath10k
ones.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 10/21] ath10k: support logging ath10k_info as KERN_DEBUG
@ 2016-09-15 15:11 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-15 15:11 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/15/2016 07:12 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:19 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> Helps keep messages off of (serial) console when
>>>> that is desired.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>
>>> Isn't /proc/sys/kernel/print exactly for this purpose? At least I recall
>>> using it.
>>
>> I just wanted to hide some ath10k logs from the console, not all
>> system logs. I don't think that /proc/sys/kernel/print has any
>> granularity?
>
> It should be based on KERN_ log levels. I don't know what your kernel
> does, but ath10k should be printing only very few messages with level
> KERN_INFO or above, all of of the debug messages. So you should be
> easily able to filter out all ath10k debug messages as they are sent
> with KERN_DEBUG.
I originally added this when I was testing .11r associating timing. Just
having a few lines of ath10k printk on the serial console added several 10s
of milliseconds to the time it took to associate, and that was throwing off my
results. I still wanted to see the messges in 'dmesg', just not on the console.
I did not want to hide other WARN level logs from the console, just the ath10k
ones.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* [PATCH v2 11/21] ath10k: add fw-powerup-fail to ethtool stats.
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
This gives user-space a normal-ish way to detect that
firmware has failed to start and that a reboot is
probably required.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/debug.c | 2 ++
drivers/net/wireless/ath/ath10k/pci.c | 2 ++
3 files changed, 5 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 6aa7a14..e7c228a 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -698,6 +698,7 @@ struct ath10k {
enum ath10k_hw_rev hw_rev;
u16 dev_id;
+ bool fw_powerup_failed; /* If true, might take reboot to recover. */
u32 chip_id;
u32 target_version;
u8 fw_version_major;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 76b5163..05b5ea4 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1541,6 +1541,7 @@ static const char ath10k_gstrings_stats[][ETH_GSTRING_LEN] = {
"d_fw_crash_count",
"d_fw_warm_reset_count",
"d_fw_cold_reset_count",
+ "d_fw_powerup_failed", /* boolean */
};
#define ATH10K_SSTATS_LEN ARRAY_SIZE(ath10k_gstrings_stats)
@@ -1640,6 +1641,7 @@ void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
data[i++] = ar->stats.fw_crash_counter;
data[i++] = ar->stats.fw_warm_reset_counter;
data[i++] = ar->stats.fw_cold_reset_counter;
+ data[i++] = ar->fw_powerup_failed;
spin_unlock_bh(&ar->data_lock);
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index dbf0db8..2adc459 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2709,10 +2709,12 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
goto err_ce;
}
+ ar->fw_powerup_failed = false;
return 0;
err_ce:
ath10k_pci_ce_deinit(ar);
+ ar->fw_powerup_failed = true;
err_sleep:
return ret;
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 11/21] ath10k: add fw-powerup-fail to ethtool stats.
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
This gives user-space a normal-ish way to detect that
firmware has failed to start and that a reboot is
probably required.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/debug.c | 2 ++
drivers/net/wireless/ath/ath10k/pci.c | 2 ++
3 files changed, 5 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 6aa7a14..e7c228a 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -698,6 +698,7 @@ struct ath10k {
enum ath10k_hw_rev hw_rev;
u16 dev_id;
+ bool fw_powerup_failed; /* If true, might take reboot to recover. */
u32 chip_id;
u32 target_version;
u8 fw_version_major;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 76b5163..05b5ea4 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1541,6 +1541,7 @@ static const char ath10k_gstrings_stats[][ETH_GSTRING_LEN] = {
"d_fw_crash_count",
"d_fw_warm_reset_count",
"d_fw_cold_reset_count",
+ "d_fw_powerup_failed", /* boolean */
};
#define ATH10K_SSTATS_LEN ARRAY_SIZE(ath10k_gstrings_stats)
@@ -1640,6 +1641,7 @@ void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
data[i++] = ar->stats.fw_crash_counter;
data[i++] = ar->stats.fw_warm_reset_counter;
data[i++] = ar->stats.fw_cold_reset_counter;
+ data[i++] = ar->fw_powerup_failed;
spin_unlock_bh(&ar->data_lock);
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index dbf0db8..2adc459 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2709,10 +2709,12 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
goto err_ce;
}
+ ar->fw_powerup_failed = false;
return 0;
err_ce:
ath10k_pci_ce_deinit(ar);
+ ar->fw_powerup_failed = true;
err_sleep:
return ret;
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread* Re: [PATCH v2 11/21] ath10k: add fw-powerup-fail to ethtool stats.
2016-05-11 17:02 ` greearb
@ 2016-09-14 14:25 ` Valo, Kalle
-1 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 14:25 UTC (permalink / raw)
To: greearb; +Cc: ath10k, linux-wireless
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> This gives user-space a normal-ish way to detect that
> firmware has failed to start and that a reboot is
> probably required.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/core.h | 1 +
> drivers/net/wireless/ath/ath10k/debug.c | 2 ++
> drivers/net/wireless/ath/ath10k/pci.c | 2 ++
> 3 files changed, 5 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireles=
s/ath/ath10k/core.h
> index 6aa7a14..e7c228a 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -698,6 +698,7 @@ struct ath10k {
> =20
> enum ath10k_hw_rev hw_rev;
> u16 dev_id;
> + bool fw_powerup_failed; /* If true, might take reboot to recover. */
> u32 chip_id;
> u32 target_version;
> u8 fw_version_major;
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wirele=
ss/ath/ath10k/debug.c
> index 76b5163..05b5ea4 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -1541,6 +1541,7 @@ static const char ath10k_gstrings_stats[][ETH_GSTRI=
NG_LEN] =3D {
> "d_fw_crash_count",
> "d_fw_warm_reset_count",
> "d_fw_cold_reset_count",
> + "d_fw_powerup_failed", /* boolean */
> };
> =20
> #define ATH10K_SSTATS_LEN ARRAY_SIZE(ath10k_gstrings_stats)
> @@ -1640,6 +1641,7 @@ void ath10k_debug_get_et_stats(struct ieee80211_hw =
*hw,
> data[i++] =3D ar->stats.fw_crash_counter;
> data[i++] =3D ar->stats.fw_warm_reset_counter;
> data[i++] =3D ar->stats.fw_cold_reset_counter;
> + data[i++] =3D ar->fw_powerup_failed;
> =20
> spin_unlock_bh(&ar->data_lock);
> =20
> diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless=
/ath/ath10k/pci.c
> index dbf0db8..2adc459 100644
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -2709,10 +2709,12 @@ static int ath10k_pci_hif_power_up(struct ath10k =
*ar)
> goto err_ce;
> }
> =20
> + ar->fw_powerup_failed =3D false;
> return 0;
> =20
> err_ce:
> ath10k_pci_ce_deinit(ar);
> + ar->fw_powerup_failed =3D true;
> =20
> err_sleep:
> return ret;
I didn't test myself, but if the firmware boot fails during module load
we should return an error and the module would fail to load (and hence
no network interface available). And if the firmware boot fails during
the interface up call (mac80211 calling ath10k_start()) we should return
an error and the interface would stay down. IMHO that's enough of
indications to the user space, I don't see how providing this boolean
via ethtool stats is really needed.
--=20
Kalle Valo=
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 11/21] ath10k: add fw-powerup-fail to ethtool stats.
@ 2016-09-14 14:25 ` Valo, Kalle
0 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 14:25 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath10k
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> This gives user-space a normal-ish way to detect that
> firmware has failed to start and that a reboot is
> probably required.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/core.h | 1 +
> drivers/net/wireless/ath/ath10k/debug.c | 2 ++
> drivers/net/wireless/ath/ath10k/pci.c | 2 ++
> 3 files changed, 5 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> index 6aa7a14..e7c228a 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -698,6 +698,7 @@ struct ath10k {
>
> enum ath10k_hw_rev hw_rev;
> u16 dev_id;
> + bool fw_powerup_failed; /* If true, might take reboot to recover. */
> u32 chip_id;
> u32 target_version;
> u8 fw_version_major;
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> index 76b5163..05b5ea4 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -1541,6 +1541,7 @@ static const char ath10k_gstrings_stats[][ETH_GSTRING_LEN] = {
> "d_fw_crash_count",
> "d_fw_warm_reset_count",
> "d_fw_cold_reset_count",
> + "d_fw_powerup_failed", /* boolean */
> };
>
> #define ATH10K_SSTATS_LEN ARRAY_SIZE(ath10k_gstrings_stats)
> @@ -1640,6 +1641,7 @@ void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
> data[i++] = ar->stats.fw_crash_counter;
> data[i++] = ar->stats.fw_warm_reset_counter;
> data[i++] = ar->stats.fw_cold_reset_counter;
> + data[i++] = ar->fw_powerup_failed;
>
> spin_unlock_bh(&ar->data_lock);
>
> diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
> index dbf0db8..2adc459 100644
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -2709,10 +2709,12 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
> goto err_ce;
> }
>
> + ar->fw_powerup_failed = false;
> return 0;
>
> err_ce:
> ath10k_pci_ce_deinit(ar);
> + ar->fw_powerup_failed = true;
>
> err_sleep:
> return ret;
I didn't test myself, but if the firmware boot fails during module load
we should return an error and the module would fail to load (and hence
no network interface available). And if the firmware boot fails during
the interface up call (mac80211 calling ath10k_start()) we should return
an error and the interface would stay down. IMHO that's enough of
indications to the user space, I don't see how providing this boolean
via ethtool stats is really needed.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 11/21] ath10k: add fw-powerup-fail to ethtool stats.
2016-09-14 14:25 ` Valo, Kalle
@ 2016-09-14 15:19 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-14 15:19 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/14/2016 07:25 AM, Valo, Kalle wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> This gives user-space a normal-ish way to detect that
>> firmware has failed to start and that a reboot is
>> probably required.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>> ---
>> drivers/net/wireless/ath/ath10k/core.h | 1 +
>> drivers/net/wireless/ath/ath10k/debug.c | 2 ++
>> drivers/net/wireless/ath/ath10k/pci.c | 2 ++
>> 3 files changed, 5 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
>> index 6aa7a14..e7c228a 100644
>> --- a/drivers/net/wireless/ath/ath10k/core.h
>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>> @@ -698,6 +698,7 @@ struct ath10k {
>>
>> enum ath10k_hw_rev hw_rev;
>> u16 dev_id;
>> + bool fw_powerup_failed; /* If true, might take reboot to recover. */
>> u32 chip_id;
>> u32 target_version;
>> u8 fw_version_major;
>> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
>> index 76b5163..05b5ea4 100644
>> --- a/drivers/net/wireless/ath/ath10k/debug.c
>> +++ b/drivers/net/wireless/ath/ath10k/debug.c
>> @@ -1541,6 +1541,7 @@ static const char ath10k_gstrings_stats[][ETH_GSTRING_LEN] = {
>> "d_fw_crash_count",
>> "d_fw_warm_reset_count",
>> "d_fw_cold_reset_count",
>> + "d_fw_powerup_failed", /* boolean */
>> };
>>
>> #define ATH10K_SSTATS_LEN ARRAY_SIZE(ath10k_gstrings_stats)
>> @@ -1640,6 +1641,7 @@ void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
>> data[i++] = ar->stats.fw_crash_counter;
>> data[i++] = ar->stats.fw_warm_reset_counter;
>> data[i++] = ar->stats.fw_cold_reset_counter;
>> + data[i++] = ar->fw_powerup_failed;
>>
>> spin_unlock_bh(&ar->data_lock);
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
>> index dbf0db8..2adc459 100644
>> --- a/drivers/net/wireless/ath/ath10k/pci.c
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c
>> @@ -2709,10 +2709,12 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
>> goto err_ce;
>> }
>>
>> + ar->fw_powerup_failed = false;
>> return 0;
>>
>> err_ce:
>> ath10k_pci_ce_deinit(ar);
>> + ar->fw_powerup_failed = true;
>>
>> err_sleep:
>> return ret;
>
> I didn't test myself, but if the firmware boot fails during module load
> we should return an error and the module would fail to load (and hence
> no network interface available). And if the firmware boot fails during
> the interface up call (mac80211 calling ath10k_start()) we should return
> an error and the interface would stay down. IMHO that's enough of
> indications to the user space, I don't see how providing this boolean
> via ethtool stats is really needed.
There are lots of reasons that interfaces can fail to come up or exist.
The work-around for the power-up fail is a system reboot, so I wanted to
know for certain when this case existed so that I could warn users
that they needed a reboot.
That said, I haven't seen this problem in a while, so maybe this patch is
no longer to useful.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 11/21] ath10k: add fw-powerup-fail to ethtool stats.
@ 2016-09-14 15:19 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-14 15:19 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/14/2016 07:25 AM, Valo, Kalle wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> This gives user-space a normal-ish way to detect that
>> firmware has failed to start and that a reboot is
>> probably required.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>> ---
>> drivers/net/wireless/ath/ath10k/core.h | 1 +
>> drivers/net/wireless/ath/ath10k/debug.c | 2 ++
>> drivers/net/wireless/ath/ath10k/pci.c | 2 ++
>> 3 files changed, 5 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
>> index 6aa7a14..e7c228a 100644
>> --- a/drivers/net/wireless/ath/ath10k/core.h
>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>> @@ -698,6 +698,7 @@ struct ath10k {
>>
>> enum ath10k_hw_rev hw_rev;
>> u16 dev_id;
>> + bool fw_powerup_failed; /* If true, might take reboot to recover. */
>> u32 chip_id;
>> u32 target_version;
>> u8 fw_version_major;
>> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
>> index 76b5163..05b5ea4 100644
>> --- a/drivers/net/wireless/ath/ath10k/debug.c
>> +++ b/drivers/net/wireless/ath/ath10k/debug.c
>> @@ -1541,6 +1541,7 @@ static const char ath10k_gstrings_stats[][ETH_GSTRING_LEN] = {
>> "d_fw_crash_count",
>> "d_fw_warm_reset_count",
>> "d_fw_cold_reset_count",
>> + "d_fw_powerup_failed", /* boolean */
>> };
>>
>> #define ATH10K_SSTATS_LEN ARRAY_SIZE(ath10k_gstrings_stats)
>> @@ -1640,6 +1641,7 @@ void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
>> data[i++] = ar->stats.fw_crash_counter;
>> data[i++] = ar->stats.fw_warm_reset_counter;
>> data[i++] = ar->stats.fw_cold_reset_counter;
>> + data[i++] = ar->fw_powerup_failed;
>>
>> spin_unlock_bh(&ar->data_lock);
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
>> index dbf0db8..2adc459 100644
>> --- a/drivers/net/wireless/ath/ath10k/pci.c
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c
>> @@ -2709,10 +2709,12 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
>> goto err_ce;
>> }
>>
>> + ar->fw_powerup_failed = false;
>> return 0;
>>
>> err_ce:
>> ath10k_pci_ce_deinit(ar);
>> + ar->fw_powerup_failed = true;
>>
>> err_sleep:
>> return ret;
>
> I didn't test myself, but if the firmware boot fails during module load
> we should return an error and the module would fail to load (and hence
> no network interface available). And if the firmware boot fails during
> the interface up call (mac80211 calling ath10k_start()) we should return
> an error and the interface would stay down. IMHO that's enough of
> indications to the user space, I don't see how providing this boolean
> via ethtool stats is really needed.
There are lots of reasons that interfaces can fail to come up or exist.
The work-around for the power-up fail is a system reboot, so I wanted to
know for certain when this case existed so that I could warn users
that they needed a reboot.
That said, I haven't seen this problem in a while, so maybe this patch is
no longer to useful.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* [PATCH v2 12/21] ath10k: Support up to 64 vdevs.
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
The (1 << x) - 1 trick won't work when you
are trying to fill up all 64 bits, so add special
case for that.
And, move the limits to the per-nic structure instead
of per-driver to allow better dynamic use of the limits.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 3f1786c..fa71d57 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1819,7 +1819,10 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
if (status)
goto err_hif_stop;
- ar->free_vdev_map = (1LL << ar->max_num_vdevs) - 1;
+ if (ar->max_num_vdevs >= 64)
+ ar->free_vdev_map = 0xFFFFFFFFFFFFFFFFLL;
+ else
+ ar->free_vdev_map = (1LL << ar->max_num_vdevs) - 1;
INIT_LIST_HEAD(&ar->arvifs);
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread
* [PATCH v2 12/21] ath10k: Support up to 64 vdevs.
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
The (1 << x) - 1 trick won't work when you
are trying to fill up all 64 bits, so add special
case for that.
And, move the limits to the per-nic structure instead
of per-driver to allow better dynamic use of the limits.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 3f1786c..fa71d57 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1819,7 +1819,10 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
if (status)
goto err_hif_stop;
- ar->free_vdev_map = (1LL << ar->max_num_vdevs) - 1;
+ if (ar->max_num_vdevs >= 64)
+ ar->free_vdev_map = 0xFFFFFFFFFFFFFFFFLL;
+ else
+ ar->free_vdev_map = (1LL << ar->max_num_vdevs) - 1;
INIT_LIST_HEAD(&ar->arvifs);
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread
* Re: [PATCH v2 12/21] ath10k: Support up to 64 vdevs.
2016-05-11 17:02 ` greearb
@ 2016-09-14 15:01 ` Valo, Kalle
-1 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 15:01 UTC (permalink / raw)
To: greearb; +Cc: ath10k, linux-wireless
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> The (1 << x) - 1 trick won't work when you
> are trying to fill up all 64 bits, so add special
> case for that.
>
> And, move the limits to the per-nic structure instead
> of per-driver to allow better dynamic use of the limits.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/core.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireles=
s/ath/ath10k/core.c
> index 3f1786c..fa71d57 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -1819,7 +1819,10 @@ int ath10k_core_start(struct ath10k *ar, enum ath1=
0k_firmware_mode mode,
> if (status)
> goto err_hif_stop;
> =20
> - ar->free_vdev_map =3D (1LL << ar->max_num_vdevs) - 1;
> + if (ar->max_num_vdevs >=3D 64)
> + ar->free_vdev_map =3D 0xFFFFFFFFFFFFFFFFLL;
> + else
> + ar->free_vdev_map =3D (1LL << ar->max_num_vdevs) - 1;
The last sentence in the commit log doesn't match the code, I removed
that in the pending branch.
--=20
Kalle Valo=
^ permalink raw reply [flat|nested] 118+ messages in thread
* Re: [PATCH v2 12/21] ath10k: Support up to 64 vdevs.
@ 2016-09-14 15:01 ` Valo, Kalle
0 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 15:01 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath10k
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> The (1 << x) - 1 trick won't work when you
> are trying to fill up all 64 bits, so add special
> case for that.
>
> And, move the limits to the per-nic structure instead
> of per-driver to allow better dynamic use of the limits.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/core.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> index 3f1786c..fa71d57 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -1819,7 +1819,10 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
> if (status)
> goto err_hif_stop;
>
> - ar->free_vdev_map = (1LL << ar->max_num_vdevs) - 1;
> + if (ar->max_num_vdevs >= 64)
> + ar->free_vdev_map = 0xFFFFFFFFFFFFFFFFLL;
> + else
> + ar->free_vdev_map = (1LL << ar->max_num_vdevs) - 1;
The last sentence in the commit log doesn't match the code, I removed
that in the pending branch.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* [PATCH v2 13/21] ath10k: Document cycle count related counters.
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
They are not necessarily named in an intuitive manner,
so at least add some comments to help the next person.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.h | 8 ++++----
drivers/net/wireless/ath/ath10k/wmi.h | 8 ++++----
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index e7c228a..91b1f95 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -189,10 +189,10 @@ struct ath10k_fw_stats_pdev {
/* PDEV stats */
s32 ch_noise_floor;
- u32 tx_frame_count;
- u32 rx_frame_count;
- u32 rx_clear_count;
- u32 cycle_count;
+ u32 tx_frame_count; /* Cycles spent transmitting frames */
+ u32 rx_frame_count; /* Cycles spent receiving frames */
+ u32 rx_clear_count; /* Total channel busy time, evidently */
+ u32 cycle_count; /* Total on-channel time */
u32 phy_err_count;
u32 chan_tx_power;
u32 ack_rx_bad;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 8d9b5b3..91c7df5 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4208,10 +4208,10 @@ struct wmi_10_2_stats_event {
*/
struct wmi_pdev_stats_base {
__le32 chan_nf;
- __le32 tx_frame_count;
- __le32 rx_frame_count;
- __le32 rx_clear_count;
- __le32 cycle_count;
+ __le32 tx_frame_count; /* Cycles spent transmitting frames */
+ __le32 rx_frame_count; /* Cycles spent receiving frames */
+ __le32 rx_clear_count; /* Total channel busy time, evidently */
+ __le32 cycle_count; /* Total on-channel time */
__le32 phy_err_count;
__le32 chan_tx_pwr;
} __packed;
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 13/21] ath10k: Document cycle count related counters.
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
They are not necessarily named in an intuitive manner,
so at least add some comments to help the next person.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.h | 8 ++++----
drivers/net/wireless/ath/ath10k/wmi.h | 8 ++++----
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index e7c228a..91b1f95 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -189,10 +189,10 @@ struct ath10k_fw_stats_pdev {
/* PDEV stats */
s32 ch_noise_floor;
- u32 tx_frame_count;
- u32 rx_frame_count;
- u32 rx_clear_count;
- u32 cycle_count;
+ u32 tx_frame_count; /* Cycles spent transmitting frames */
+ u32 rx_frame_count; /* Cycles spent receiving frames */
+ u32 rx_clear_count; /* Total channel busy time, evidently */
+ u32 cycle_count; /* Total on-channel time */
u32 phy_err_count;
u32 chan_tx_power;
u32 ack_rx_bad;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 8d9b5b3..91c7df5 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4208,10 +4208,10 @@ struct wmi_10_2_stats_event {
*/
struct wmi_pdev_stats_base {
__le32 chan_nf;
- __le32 tx_frame_count;
- __le32 rx_frame_count;
- __le32 rx_clear_count;
- __le32 cycle_count;
+ __le32 tx_frame_count; /* Cycles spent transmitting frames */
+ __le32 rx_frame_count; /* Cycles spent receiving frames */
+ __le32 rx_clear_count; /* Total channel busy time, evidently */
+ __le32 cycle_count; /* Total on-channel time */
__le32 phy_err_count;
__le32 chan_tx_pwr;
} __packed;
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread
* [PATCH v2 14/21] ath10k: Add tx/rx bytes, cycle counters to ethtool stats.
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
The firmware does not offer tx/rx bytes counters, so just keep track of
it in the driver.
For the cycle counters:
Note these counters are since the chip reset, though the counters
wrap often. When cycle-counters counter overflows on
certain hardware, it will right shift all 4 of the
related registers to the right by one bit (basically,
divide by two). Since you have no idea what the others
were at when cycle-counter wrapped, you must simply
ignore any sample where cycle-counter wraps, and set
new baseline values to calculate diffs against next
time.
Hardware with this funny wrap logic will cause the
d_flags 'counter' to have bit 0x1 set, so that is how
user-space can know how to deal with this.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.h | 3 +++
drivers/net/wireless/ath/ath10k/debug.c | 22 +++++++++++++++++-----
drivers/net/wireless/ath/ath10k/htt_rx.c | 3 +++
drivers/net/wireless/ath/ath10k/htt_tx.c | 22 +++++++++++++++++-----
4 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 91b1f95..cb6aa8c 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -466,6 +466,9 @@ struct ath10k_debug {
struct ath10k_dbglog_entry_storage dbglog_entry_data;
struct ath10k_fw_crash_data *fw_crash_data;
+
+ u64 tx_bytes; /* counter, firmware does not offer this stat */
+ u64 rx_bytes; /* counter, firmware does not offer this stat */
};
enum ath10k_state {
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 05b5ea4..a3da6ab 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1496,11 +1496,15 @@ exit:
/* This generally cooresponds to the debugfs fw_stats file */
static const char ath10k_gstrings_stats[][ETH_GSTRING_LEN] = {
"tx_pkts_nic",
- "tx_bytes_nic",
+ "tx_bytes_nic", /* from driver, firmware does not keep this stat. */
"rx_pkts_nic",
- "rx_bytes_nic",
+ "rx_bytes_nic", /* from driver, firmware does not keep this stat. */
"d_noise_floor",
- "d_cycle_count",
+ "d_cycle_count", /* this is duty cycle counter, basically channel-time. 88MHz clock */
+ "d_tx_cycle_count", /* tx cycle count */
+ "d_rx_cycle_count", /* rx cycle count */
+ "d_busy_count", /* Total channel busy time cycles (called 'clear' by firmware) */
+ "d_flags", /* 0x1: hw has shifted cycle-count wrap, see ath10k_hw_fill_survey_time */
"d_phy_error",
"d_rts_bad",
"d_rts_good",
@@ -1572,6 +1576,7 @@ void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
static const struct ath10k_fw_stats_pdev zero_stats = {};
const struct ath10k_fw_stats_pdev *pdev_stats;
int i = 0, ret;
+ u64 d_flags = 0;
mutex_lock(&ar->conf_mutex);
@@ -1595,12 +1600,19 @@ void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
spin_lock_bh(&ar->data_lock);
+ if (ar->hw_params.has_shifted_cc_wraparound)
+ d_flags |= 0x1;
+
data[i++] = pdev_stats->hw_reaped; /* ppdu reaped */
- data[i++] = 0; /* tx bytes */
+ data[i++] = ar->debug.tx_bytes;
data[i++] = pdev_stats->htt_mpdus;
- data[i++] = 0; /* rx bytes */
+ data[i++] = ar->debug.rx_bytes;
data[i++] = pdev_stats->ch_noise_floor;
data[i++] = pdev_stats->cycle_count;
+ data[i++] = pdev_stats->tx_frame_count;
+ data[i++] = pdev_stats->rx_frame_count;
+ data[i++] = pdev_stats->rx_clear_count; /* yes, this appears to actually be 'busy' count */
+ data[i++] = d_flags; /* give user-space a chance to decode cycle counters */
data[i++] = pdev_stats->phy_err_count;
data[i++] = pdev_stats->rts_bad;
data[i++] = pdev_stats->rts_good;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index cc979a4..47da904 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1379,6 +1379,9 @@ static void ath10k_htt_rx_h_mpdu(struct ath10k *ar,
}
skb_queue_walk(amsdu, msdu) {
+#ifdef CONFIG_ATH10K_DEBUGFS
+ ar->debug.rx_bytes += msdu->len;
+#endif
ath10k_htt_rx_h_csum_offload(msdu);
ath10k_htt_rx_h_undecap(ar, msdu, status, first_hdr, enctype,
is_decrypted);
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 6269c61..06ec995 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -769,6 +769,7 @@ int ath10k_htt_mgmt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
int len = 0;
int msdu_id = -1;
int res;
+ int skb_len;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)msdu->data;
len += sizeof(cmd->hdr);
@@ -795,7 +796,8 @@ int ath10k_htt_mgmt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
goto err_free_msdu_id;
}
- skb_cb->paddr = dma_map_single(dev, msdu->data, msdu->len,
+ skb_len = msdu->len;
+ skb_cb->paddr = dma_map_single(dev, msdu->data, skb_len,
DMA_TO_DEVICE);
res = dma_mapping_error(dev, skb_cb->paddr);
if (res) {
@@ -809,16 +811,20 @@ int ath10k_htt_mgmt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
cmd->hdr.msg_type = HTT_H2T_MSG_TYPE_MGMT_TX;
cmd->mgmt_tx.msdu_paddr = __cpu_to_le32(ATH10K_SKB_CB(msdu)->paddr);
- cmd->mgmt_tx.len = __cpu_to_le32(msdu->len);
+ cmd->mgmt_tx.len = __cpu_to_le32(skb_len);
cmd->mgmt_tx.desc_id = __cpu_to_le32(msdu_id);
cmd->mgmt_tx.vdev_id = __cpu_to_le32(vdev_id);
memcpy(cmd->mgmt_tx.hdr, msdu->data,
- min_t(int, msdu->len, HTT_MGMT_FRM_HDR_DOWNLOAD_LEN));
+ min_t(int, skb_len, HTT_MGMT_FRM_HDR_DOWNLOAD_LEN));
res = ath10k_htc_send(&htt->ar->htc, htt->eid, txdesc);
if (res)
goto err_unmap_msdu;
+#ifdef CONFIG_ATH10K_DEBUGFS
+ ar->debug.tx_bytes += skb_len;
+#endif
+
return 0;
err_unmap_msdu:
@@ -852,6 +858,7 @@ int ath10k_htt_tx(struct ath10k_htt *htt, enum ath10k_hw_txrx_mode txmode,
u8 flags0 = 0;
u16 msdu_id, flags1 = 0;
u16 freq = 0;
+ int skb_len;
u32 frags_paddr = 0;
u32 txbuf_paddr;
struct htt_msdu_ext_desc *ext_desc = NULL;
@@ -990,13 +997,14 @@ int ath10k_htt_tx(struct ath10k_htt *htt, enum ath10k_hw_txrx_mode txmode,
__cpu_to_le32(HTT_INVALID_PEERID);
}
+ skb_len = msdu->len;
trace_ath10k_htt_tx(ar, msdu_id, msdu->len, vdev_id, tid);
ath10k_dbg(ar, ATH10K_DBG_HTT,
"htt tx flags0 %hhu flags1 %hu len %d id %hu frags_paddr %08x, msdu_paddr %08x vdev %hhu tid %hhu freq %hu\n",
- flags0, flags1, msdu->len, msdu_id, frags_paddr,
+ flags0, flags1, skb_len, msdu_id, frags_paddr,
(u32)skb_cb->paddr, vdev_id, tid, freq);
ath10k_dbg_dump(ar, ATH10K_DBG_HTT_DUMP, NULL, "htt tx msdu: ",
- msdu->data, msdu->len);
+ msdu->data, skb_len);
trace_ath10k_tx_hdr(ar, msdu->data, msdu->len);
trace_ath10k_tx_payload(ar, msdu->data, msdu->len);
@@ -1021,6 +1029,10 @@ int ath10k_htt_tx(struct ath10k_htt *htt, enum ath10k_hw_txrx_mode txmode,
if (res)
goto err_unmap_msdu;
+#ifdef CONFIG_ATH10K_DEBUGFS
+ ar->debug.tx_bytes += skb_len;
+#endif
+
return 0;
err_unmap_msdu:
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 14/21] ath10k: Add tx/rx bytes, cycle counters to ethtool stats.
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
The firmware does not offer tx/rx bytes counters, so just keep track of
it in the driver.
For the cycle counters:
Note these counters are since the chip reset, though the counters
wrap often. When cycle-counters counter overflows on
certain hardware, it will right shift all 4 of the
related registers to the right by one bit (basically,
divide by two). Since you have no idea what the others
were at when cycle-counter wrapped, you must simply
ignore any sample where cycle-counter wraps, and set
new baseline values to calculate diffs against next
time.
Hardware with this funny wrap logic will cause the
d_flags 'counter' to have bit 0x1 set, so that is how
user-space can know how to deal with this.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.h | 3 +++
drivers/net/wireless/ath/ath10k/debug.c | 22 +++++++++++++++++-----
drivers/net/wireless/ath/ath10k/htt_rx.c | 3 +++
drivers/net/wireless/ath/ath10k/htt_tx.c | 22 +++++++++++++++++-----
4 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 91b1f95..cb6aa8c 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -466,6 +466,9 @@ struct ath10k_debug {
struct ath10k_dbglog_entry_storage dbglog_entry_data;
struct ath10k_fw_crash_data *fw_crash_data;
+
+ u64 tx_bytes; /* counter, firmware does not offer this stat */
+ u64 rx_bytes; /* counter, firmware does not offer this stat */
};
enum ath10k_state {
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 05b5ea4..a3da6ab 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1496,11 +1496,15 @@ exit:
/* This generally cooresponds to the debugfs fw_stats file */
static const char ath10k_gstrings_stats[][ETH_GSTRING_LEN] = {
"tx_pkts_nic",
- "tx_bytes_nic",
+ "tx_bytes_nic", /* from driver, firmware does not keep this stat. */
"rx_pkts_nic",
- "rx_bytes_nic",
+ "rx_bytes_nic", /* from driver, firmware does not keep this stat. */
"d_noise_floor",
- "d_cycle_count",
+ "d_cycle_count", /* this is duty cycle counter, basically channel-time. 88MHz clock */
+ "d_tx_cycle_count", /* tx cycle count */
+ "d_rx_cycle_count", /* rx cycle count */
+ "d_busy_count", /* Total channel busy time cycles (called 'clear' by firmware) */
+ "d_flags", /* 0x1: hw has shifted cycle-count wrap, see ath10k_hw_fill_survey_time */
"d_phy_error",
"d_rts_bad",
"d_rts_good",
@@ -1572,6 +1576,7 @@ void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
static const struct ath10k_fw_stats_pdev zero_stats = {};
const struct ath10k_fw_stats_pdev *pdev_stats;
int i = 0, ret;
+ u64 d_flags = 0;
mutex_lock(&ar->conf_mutex);
@@ -1595,12 +1600,19 @@ void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
spin_lock_bh(&ar->data_lock);
+ if (ar->hw_params.has_shifted_cc_wraparound)
+ d_flags |= 0x1;
+
data[i++] = pdev_stats->hw_reaped; /* ppdu reaped */
- data[i++] = 0; /* tx bytes */
+ data[i++] = ar->debug.tx_bytes;
data[i++] = pdev_stats->htt_mpdus;
- data[i++] = 0; /* rx bytes */
+ data[i++] = ar->debug.rx_bytes;
data[i++] = pdev_stats->ch_noise_floor;
data[i++] = pdev_stats->cycle_count;
+ data[i++] = pdev_stats->tx_frame_count;
+ data[i++] = pdev_stats->rx_frame_count;
+ data[i++] = pdev_stats->rx_clear_count; /* yes, this appears to actually be 'busy' count */
+ data[i++] = d_flags; /* give user-space a chance to decode cycle counters */
data[i++] = pdev_stats->phy_err_count;
data[i++] = pdev_stats->rts_bad;
data[i++] = pdev_stats->rts_good;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index cc979a4..47da904 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1379,6 +1379,9 @@ static void ath10k_htt_rx_h_mpdu(struct ath10k *ar,
}
skb_queue_walk(amsdu, msdu) {
+#ifdef CONFIG_ATH10K_DEBUGFS
+ ar->debug.rx_bytes += msdu->len;
+#endif
ath10k_htt_rx_h_csum_offload(msdu);
ath10k_htt_rx_h_undecap(ar, msdu, status, first_hdr, enctype,
is_decrypted);
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 6269c61..06ec995 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -769,6 +769,7 @@ int ath10k_htt_mgmt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
int len = 0;
int msdu_id = -1;
int res;
+ int skb_len;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)msdu->data;
len += sizeof(cmd->hdr);
@@ -795,7 +796,8 @@ int ath10k_htt_mgmt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
goto err_free_msdu_id;
}
- skb_cb->paddr = dma_map_single(dev, msdu->data, msdu->len,
+ skb_len = msdu->len;
+ skb_cb->paddr = dma_map_single(dev, msdu->data, skb_len,
DMA_TO_DEVICE);
res = dma_mapping_error(dev, skb_cb->paddr);
if (res) {
@@ -809,16 +811,20 @@ int ath10k_htt_mgmt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
cmd->hdr.msg_type = HTT_H2T_MSG_TYPE_MGMT_TX;
cmd->mgmt_tx.msdu_paddr = __cpu_to_le32(ATH10K_SKB_CB(msdu)->paddr);
- cmd->mgmt_tx.len = __cpu_to_le32(msdu->len);
+ cmd->mgmt_tx.len = __cpu_to_le32(skb_len);
cmd->mgmt_tx.desc_id = __cpu_to_le32(msdu_id);
cmd->mgmt_tx.vdev_id = __cpu_to_le32(vdev_id);
memcpy(cmd->mgmt_tx.hdr, msdu->data,
- min_t(int, msdu->len, HTT_MGMT_FRM_HDR_DOWNLOAD_LEN));
+ min_t(int, skb_len, HTT_MGMT_FRM_HDR_DOWNLOAD_LEN));
res = ath10k_htc_send(&htt->ar->htc, htt->eid, txdesc);
if (res)
goto err_unmap_msdu;
+#ifdef CONFIG_ATH10K_DEBUGFS
+ ar->debug.tx_bytes += skb_len;
+#endif
+
return 0;
err_unmap_msdu:
@@ -852,6 +858,7 @@ int ath10k_htt_tx(struct ath10k_htt *htt, enum ath10k_hw_txrx_mode txmode,
u8 flags0 = 0;
u16 msdu_id, flags1 = 0;
u16 freq = 0;
+ int skb_len;
u32 frags_paddr = 0;
u32 txbuf_paddr;
struct htt_msdu_ext_desc *ext_desc = NULL;
@@ -990,13 +997,14 @@ int ath10k_htt_tx(struct ath10k_htt *htt, enum ath10k_hw_txrx_mode txmode,
__cpu_to_le32(HTT_INVALID_PEERID);
}
+ skb_len = msdu->len;
trace_ath10k_htt_tx(ar, msdu_id, msdu->len, vdev_id, tid);
ath10k_dbg(ar, ATH10K_DBG_HTT,
"htt tx flags0 %hhu flags1 %hu len %d id %hu frags_paddr %08x, msdu_paddr %08x vdev %hhu tid %hhu freq %hu\n",
- flags0, flags1, msdu->len, msdu_id, frags_paddr,
+ flags0, flags1, skb_len, msdu_id, frags_paddr,
(u32)skb_cb->paddr, vdev_id, tid, freq);
ath10k_dbg_dump(ar, ATH10K_DBG_HTT_DUMP, NULL, "htt tx msdu: ",
- msdu->data, msdu->len);
+ msdu->data, skb_len);
trace_ath10k_tx_hdr(ar, msdu->data, msdu->len);
trace_ath10k_tx_payload(ar, msdu->data, msdu->len);
@@ -1021,6 +1029,10 @@ int ath10k_htt_tx(struct ath10k_htt *htt, enum ath10k_hw_txrx_mode txmode,
if (res)
goto err_unmap_msdu;
+#ifdef CONFIG_ATH10K_DEBUGFS
+ ar->debug.tx_bytes += skb_len;
+#endif
+
return 0;
err_unmap_msdu:
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread
* [PATCH v2 15/21] ath10k: support CT firmware flag.
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
Add placeholder so CT firmware can more easily co-exist with upstream
kernel. CT firmware should be backwards compatible with existing kernels,
but it also has many new features. Subsequent patches, if acceptable for
upstream, can enable and further describe those features.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.c | 1 +
drivers/net/wireless/ath/ath10k/core.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index fa71d57..49c85c3 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -235,6 +235,7 @@ static const char *const ath10k_core_fw_feature_str[] = {
[ATH10K_FW_FEATURE_SUPPORTS_ADAPTIVE_CCA] = "adaptive-cca",
[ATH10K_FW_FEATURE_MFP_SUPPORT] = "mfp",
[ATH10K_FW_FEATURE_PEER_FLOW_CONTROL] = "peer-flow-ctrl",
+ [ATH10K_FW_FEATURE_WMI_10X_CT] = "wmi-10.x-CT",
};
static unsigned int ath10k_core_get_fw_feature_str(char *buf,
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index cb6aa8c..f9e3b20 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -566,6 +566,9 @@ enum ath10k_fw_features {
*/
ATH10K_FW_FEATURE_PEER_FLOW_CONTROL = 13,
+ /* Firmware from Candela Technologies, enables more VIFs, etc */
+ ATH10K_FW_FEATURE_WMI_10X_CT = 31,
+
/* keep last */
ATH10K_FW_FEATURE_COUNT,
};
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 15/21] ath10k: support CT firmware flag.
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
Add placeholder so CT firmware can more easily co-exist with upstream
kernel. CT firmware should be backwards compatible with existing kernels,
but it also has many new features. Subsequent patches, if acceptable for
upstream, can enable and further describe those features.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.c | 1 +
drivers/net/wireless/ath/ath10k/core.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index fa71d57..49c85c3 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -235,6 +235,7 @@ static const char *const ath10k_core_fw_feature_str[] = {
[ATH10K_FW_FEATURE_SUPPORTS_ADAPTIVE_CCA] = "adaptive-cca",
[ATH10K_FW_FEATURE_MFP_SUPPORT] = "mfp",
[ATH10K_FW_FEATURE_PEER_FLOW_CONTROL] = "peer-flow-ctrl",
+ [ATH10K_FW_FEATURE_WMI_10X_CT] = "wmi-10.x-CT",
};
static unsigned int ath10k_core_get_fw_feature_str(char *buf,
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index cb6aa8c..f9e3b20 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -566,6 +566,9 @@ enum ath10k_fw_features {
*/
ATH10K_FW_FEATURE_PEER_FLOW_CONTROL = 13,
+ /* Firmware from Candela Technologies, enables more VIFs, etc */
+ ATH10K_FW_FEATURE_WMI_10X_CT = 31,
+
/* keep last */
ATH10K_FW_FEATURE_COUNT,
};
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread* Re: [PATCH v2 15/21] ath10k: support CT firmware flag.
2016-05-11 17:02 ` greearb
@ 2016-09-14 14:30 ` Valo, Kalle
-1 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 14:30 UTC (permalink / raw)
To: greearb; +Cc: ath10k, linux-wireless
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> Add placeholder so CT firmware can more easily co-exist with upstream
> kernel. CT firmware should be backwards compatible with existing kernels=
,
> but it also has many new features. Subsequent patches, if acceptable for
> upstream, can enable and further describe those features.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/core.c | 1 +
> drivers/net/wireless/ath/ath10k/core.h | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireles=
s/ath/ath10k/core.c
> index fa71d57..49c85c3 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -235,6 +235,7 @@ static const char *const ath10k_core_fw_feature_str[]=
=3D {
> [ATH10K_FW_FEATURE_SUPPORTS_ADAPTIVE_CCA] =3D "adaptive-cca",
> [ATH10K_FW_FEATURE_MFP_SUPPORT] =3D "mfp",
> [ATH10K_FW_FEATURE_PEER_FLOW_CONTROL] =3D "peer-flow-ctrl",
> + [ATH10K_FW_FEATURE_WMI_10X_CT] =3D "wmi-10.x-CT",
> };
> =20
> static unsigned int ath10k_core_get_fw_feature_str(char *buf,
> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireles=
s/ath/ath10k/core.h
> index cb6aa8c..f9e3b20 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -566,6 +566,9 @@ enum ath10k_fw_features {
> */
> ATH10K_FW_FEATURE_PEER_FLOW_CONTROL =3D 13,
> =20
> + /* Firmware from Candela Technologies, enables more VIFs, etc */
> + ATH10K_FW_FEATURE_WMI_10X_CT =3D 31,
The idea of firmware feature flags to enable (or disable) one particular
feature, not a group of features. This way it's easy to enable certain
features on different firmware branches. It also makes the maintenance
easier as you don't need to remember all the different features one flag
enables.
--=20
Kalle Valo=
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 15/21] ath10k: support CT firmware flag.
@ 2016-09-14 14:30 ` Valo, Kalle
0 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 14:30 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath10k
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> Add placeholder so CT firmware can more easily co-exist with upstream
> kernel. CT firmware should be backwards compatible with existing kernels,
> but it also has many new features. Subsequent patches, if acceptable for
> upstream, can enable and further describe those features.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/core.c | 1 +
> drivers/net/wireless/ath/ath10k/core.h | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> index fa71d57..49c85c3 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -235,6 +235,7 @@ static const char *const ath10k_core_fw_feature_str[] = {
> [ATH10K_FW_FEATURE_SUPPORTS_ADAPTIVE_CCA] = "adaptive-cca",
> [ATH10K_FW_FEATURE_MFP_SUPPORT] = "mfp",
> [ATH10K_FW_FEATURE_PEER_FLOW_CONTROL] = "peer-flow-ctrl",
> + [ATH10K_FW_FEATURE_WMI_10X_CT] = "wmi-10.x-CT",
> };
>
> static unsigned int ath10k_core_get_fw_feature_str(char *buf,
> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> index cb6aa8c..f9e3b20 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -566,6 +566,9 @@ enum ath10k_fw_features {
> */
> ATH10K_FW_FEATURE_PEER_FLOW_CONTROL = 13,
>
> + /* Firmware from Candela Technologies, enables more VIFs, etc */
> + ATH10K_FW_FEATURE_WMI_10X_CT = 31,
The idea of firmware feature flags to enable (or disable) one particular
feature, not a group of features. This way it's easy to enable certain
features on different firmware branches. It also makes the maintenance
easier as you don't need to remember all the different features one flag
enables.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 15/21] ath10k: support CT firmware flag.
2016-09-14 14:30 ` Valo, Kalle
@ 2016-09-14 15:24 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-14 15:24 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/14/2016 07:30 AM, Valo, Kalle wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> Add placeholder so CT firmware can more easily co-exist with upstream
>> kernel. CT firmware should be backwards compatible with existing kernels,
>> but it also has many new features. Subsequent patches, if acceptable for
>> upstream, can enable and further describe those features.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>> ---
>> drivers/net/wireless/ath/ath10k/core.c | 1 +
>> drivers/net/wireless/ath/ath10k/core.h | 3 +++
>> 2 files changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
>> index fa71d57..49c85c3 100644
>> --- a/drivers/net/wireless/ath/ath10k/core.c
>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>> @@ -235,6 +235,7 @@ static const char *const ath10k_core_fw_feature_str[] = {
>> [ATH10K_FW_FEATURE_SUPPORTS_ADAPTIVE_CCA] = "adaptive-cca",
>> [ATH10K_FW_FEATURE_MFP_SUPPORT] = "mfp",
>> [ATH10K_FW_FEATURE_PEER_FLOW_CONTROL] = "peer-flow-ctrl",
>> + [ATH10K_FW_FEATURE_WMI_10X_CT] = "wmi-10.x-CT",
>> };
>>
>> static unsigned int ath10k_core_get_fw_feature_str(char *buf,
>> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
>> index cb6aa8c..f9e3b20 100644
>> --- a/drivers/net/wireless/ath/ath10k/core.h
>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>> @@ -566,6 +566,9 @@ enum ath10k_fw_features {
>> */
>> ATH10K_FW_FEATURE_PEER_FLOW_CONTROL = 13,
>>
>> + /* Firmware from Candela Technologies, enables more VIFs, etc */
>> + ATH10K_FW_FEATURE_WMI_10X_CT = 31,
>
> The idea of firmware feature flags to enable (or disable) one particular
> feature, not a group of features. This way it's easy to enable certain
> features on different firmware branches. It also makes the maintenance
> easier as you don't need to remember all the different features one flag
> enables.
One potential use for this flag: Bug reports could be automatically directed to me instead
of QCA.
I have actually re-written much of my earlier logic so that it uses specific
feature flags now. I still like the idea of having the driver (and user)
know it is using CT firmware, but I can live without this flag if needed.
Even if I change generation of my new firmware, all of my older firmware
will have this flag set though, so I would still prefer the flag exist
in the driver, even if it is not used for any serious decisions.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 15/21] ath10k: support CT firmware flag.
@ 2016-09-14 15:24 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-14 15:24 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/14/2016 07:30 AM, Valo, Kalle wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> Add placeholder so CT firmware can more easily co-exist with upstream
>> kernel. CT firmware should be backwards compatible with existing kernels,
>> but it also has many new features. Subsequent patches, if acceptable for
>> upstream, can enable and further describe those features.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>> ---
>> drivers/net/wireless/ath/ath10k/core.c | 1 +
>> drivers/net/wireless/ath/ath10k/core.h | 3 +++
>> 2 files changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
>> index fa71d57..49c85c3 100644
>> --- a/drivers/net/wireless/ath/ath10k/core.c
>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>> @@ -235,6 +235,7 @@ static const char *const ath10k_core_fw_feature_str[] = {
>> [ATH10K_FW_FEATURE_SUPPORTS_ADAPTIVE_CCA] = "adaptive-cca",
>> [ATH10K_FW_FEATURE_MFP_SUPPORT] = "mfp",
>> [ATH10K_FW_FEATURE_PEER_FLOW_CONTROL] = "peer-flow-ctrl",
>> + [ATH10K_FW_FEATURE_WMI_10X_CT] = "wmi-10.x-CT",
>> };
>>
>> static unsigned int ath10k_core_get_fw_feature_str(char *buf,
>> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
>> index cb6aa8c..f9e3b20 100644
>> --- a/drivers/net/wireless/ath/ath10k/core.h
>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>> @@ -566,6 +566,9 @@ enum ath10k_fw_features {
>> */
>> ATH10K_FW_FEATURE_PEER_FLOW_CONTROL = 13,
>>
>> + /* Firmware from Candela Technologies, enables more VIFs, etc */
>> + ATH10K_FW_FEATURE_WMI_10X_CT = 31,
>
> The idea of firmware feature flags to enable (or disable) one particular
> feature, not a group of features. This way it's easy to enable certain
> features on different firmware branches. It also makes the maintenance
> easier as you don't need to remember all the different features one flag
> enables.
One potential use for this flag: Bug reports could be automatically directed to me instead
of QCA.
I have actually re-written much of my earlier logic so that it uses specific
feature flags now. I still like the idea of having the driver (and user)
know it is using CT firmware, but I can live without this flag if needed.
Even if I change generation of my new firmware, all of my older firmware
will have this flag set though, so I would still prefer the flag exist
in the driver, even if it is not used for any serious decisions.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 15/21] ath10k: support CT firmware flag.
2016-09-14 15:24 ` Ben Greear
@ 2016-09-15 14:15 ` Valo, Kalle
-1 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-15 14:15 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:30 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> Add placeholder so CT firmware can more easily co-exist with upstream
>>> kernel. CT firmware should be backwards compatible with existing kerne=
ls,
>>> but it also has many new features. Subsequent patches, if acceptable f=
or
>>> upstream, can enable and further describe those features.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/core.c | 1 +
>>> drivers/net/wireless/ath/ath10k/core.h | 3 +++
>>> 2 files changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wirel=
ess/ath/ath10k/core.c
>>> index fa71d57..49c85c3 100644
>>> --- a/drivers/net/wireless/ath/ath10k/core.c
>>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>>> @@ -235,6 +235,7 @@ static const char *const ath10k_core_fw_feature_str=
[] =3D {
>>> [ATH10K_FW_FEATURE_SUPPORTS_ADAPTIVE_CCA] =3D "adaptive-cca",
>>> [ATH10K_FW_FEATURE_MFP_SUPPORT] =3D "mfp",
>>> [ATH10K_FW_FEATURE_PEER_FLOW_CONTROL] =3D "peer-flow-ctrl",
>>> + [ATH10K_FW_FEATURE_WMI_10X_CT] =3D "wmi-10.x-CT",
>>> };
>>>
>>> static unsigned int ath10k_core_get_fw_feature_str(char *buf,
>>> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wirel=
ess/ath/ath10k/core.h
>>> index cb6aa8c..f9e3b20 100644
>>> --- a/drivers/net/wireless/ath/ath10k/core.h
>>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>>> @@ -566,6 +566,9 @@ enum ath10k_fw_features {
>>> */
>>> ATH10K_FW_FEATURE_PEER_FLOW_CONTROL =3D 13,
>>>
>>> + /* Firmware from Candela Technologies, enables more VIFs, etc */
>>> + ATH10K_FW_FEATURE_WMI_10X_CT =3D 31,
>>
>> The idea of firmware feature flags to enable (or disable) one particular
>> feature, not a group of features. This way it's easy to enable certain
>> features on different firmware branches. It also makes the maintenance
>> easier as you don't need to remember all the different features one flag
>> enables.
>
> One potential use for this flag: Bug reports could be automatically dire=
cted to me instead
> of QCA.
>
> I have actually re-written much of my earlier logic so that it uses speci=
fic
> feature flags now. I still like the idea of having the driver (and user)
> know it is using CT firmware, but I can live without this flag if needed.
You can do with firmware version string, add something like "-CT" (maybe
you already have?) and it's clearly visible in boot logs and also when
firmware crashes.
--=20
Kalle Valo=
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 15/21] ath10k: support CT firmware flag.
@ 2016-09-15 14:15 ` Valo, Kalle
0 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-15 14:15 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:30 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> Add placeholder so CT firmware can more easily co-exist with upstream
>>> kernel. CT firmware should be backwards compatible with existing kernels,
>>> but it also has many new features. Subsequent patches, if acceptable for
>>> upstream, can enable and further describe those features.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/core.c | 1 +
>>> drivers/net/wireless/ath/ath10k/core.h | 3 +++
>>> 2 files changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
>>> index fa71d57..49c85c3 100644
>>> --- a/drivers/net/wireless/ath/ath10k/core.c
>>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>>> @@ -235,6 +235,7 @@ static const char *const ath10k_core_fw_feature_str[] = {
>>> [ATH10K_FW_FEATURE_SUPPORTS_ADAPTIVE_CCA] = "adaptive-cca",
>>> [ATH10K_FW_FEATURE_MFP_SUPPORT] = "mfp",
>>> [ATH10K_FW_FEATURE_PEER_FLOW_CONTROL] = "peer-flow-ctrl",
>>> + [ATH10K_FW_FEATURE_WMI_10X_CT] = "wmi-10.x-CT",
>>> };
>>>
>>> static unsigned int ath10k_core_get_fw_feature_str(char *buf,
>>> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
>>> index cb6aa8c..f9e3b20 100644
>>> --- a/drivers/net/wireless/ath/ath10k/core.h
>>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>>> @@ -566,6 +566,9 @@ enum ath10k_fw_features {
>>> */
>>> ATH10K_FW_FEATURE_PEER_FLOW_CONTROL = 13,
>>>
>>> + /* Firmware from Candela Technologies, enables more VIFs, etc */
>>> + ATH10K_FW_FEATURE_WMI_10X_CT = 31,
>>
>> The idea of firmware feature flags to enable (or disable) one particular
>> feature, not a group of features. This way it's easy to enable certain
>> features on different firmware branches. It also makes the maintenance
>> easier as you don't need to remember all the different features one flag
>> enables.
>
> One potential use for this flag: Bug reports could be automatically directed to me instead
> of QCA.
>
> I have actually re-written much of my earlier logic so that it uses specific
> feature flags now. I still like the idea of having the driver (and user)
> know it is using CT firmware, but I can live without this flag if needed.
You can do with firmware version string, add something like "-CT" (maybe
you already have?) and it's clearly visible in boot logs and also when
firmware crashes.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 15/21] ath10k: support CT firmware flag.
2016-09-15 14:15 ` Valo, Kalle
@ 2016-09-15 14:43 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-15 14:43 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/15/2016 07:15 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:30 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> Add placeholder so CT firmware can more easily co-exist with upstream
>>>> kernel. CT firmware should be backwards compatible with existing kernels,
>>>> but it also has many new features. Subsequent patches, if acceptable for
>>>> upstream, can enable and further describe those features.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>> ---
>>>> drivers/net/wireless/ath/ath10k/core.c | 1 +
>>>> drivers/net/wireless/ath/ath10k/core.h | 3 +++
>>>> 2 files changed, 4 insertions(+)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
>>>> index fa71d57..49c85c3 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/core.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>>>> @@ -235,6 +235,7 @@ static const char *const ath10k_core_fw_feature_str[] = {
>>>> [ATH10K_FW_FEATURE_SUPPORTS_ADAPTIVE_CCA] = "adaptive-cca",
>>>> [ATH10K_FW_FEATURE_MFP_SUPPORT] = "mfp",
>>>> [ATH10K_FW_FEATURE_PEER_FLOW_CONTROL] = "peer-flow-ctrl",
>>>> + [ATH10K_FW_FEATURE_WMI_10X_CT] = "wmi-10.x-CT",
>>>> };
>>>>
>>>> static unsigned int ath10k_core_get_fw_feature_str(char *buf,
>>>> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
>>>> index cb6aa8c..f9e3b20 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/core.h
>>>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>>>> @@ -566,6 +566,9 @@ enum ath10k_fw_features {
>>>> */
>>>> ATH10K_FW_FEATURE_PEER_FLOW_CONTROL = 13,
>>>>
>>>> + /* Firmware from Candela Technologies, enables more VIFs, etc */
>>>> + ATH10K_FW_FEATURE_WMI_10X_CT = 31,
>>>
>>> The idea of firmware feature flags to enable (or disable) one particular
>>> feature, not a group of features. This way it's easy to enable certain
>>> features on different firmware branches. It also makes the maintenance
>>> easier as you don't need to remember all the different features one flag
>>> enables.
>>
>> One potential use for this flag: Bug reports could be automatically directed to me instead
>> of QCA.
>>
>> I have actually re-written much of my earlier logic so that it uses specific
>> feature flags now. I still like the idea of having the driver (and user)
>> know it is using CT firmware, but I can live without this flag if needed.
>
> You can do with firmware version string, add something like "-CT" (maybe
> you already have?) and it's clearly visible in boot logs and also when
> firmware crashes.
Yes, that is a worse hack, but it works.
Thing is, I have years of older, tested firmware around, with this feature flag
set. So, it is going to warn when booting in a kernel that does not understand
this flag.
So, if you want CT firmware support at all in the upstream kernel, then I wish
you would let me add the enum and string to make it work as expected. That will also
let these old firmware do IBSS with one of the other patches I posted. Yes, it would
be nice to have an IBSS feature flag, but we have not for years, and again, this would
let my older firmware work.
It feels a bit like pulling teeth to get patches upstream. You are basically
waving through this huge hack to set registers for ack-timing and stuff, but
then you are arguing about a simple feature flag enum?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 15/21] ath10k: support CT firmware flag.
@ 2016-09-15 14:43 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-15 14:43 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/15/2016 07:15 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:30 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> Add placeholder so CT firmware can more easily co-exist with upstream
>>>> kernel. CT firmware should be backwards compatible with existing kernels,
>>>> but it also has many new features. Subsequent patches, if acceptable for
>>>> upstream, can enable and further describe those features.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>> ---
>>>> drivers/net/wireless/ath/ath10k/core.c | 1 +
>>>> drivers/net/wireless/ath/ath10k/core.h | 3 +++
>>>> 2 files changed, 4 insertions(+)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
>>>> index fa71d57..49c85c3 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/core.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>>>> @@ -235,6 +235,7 @@ static const char *const ath10k_core_fw_feature_str[] = {
>>>> [ATH10K_FW_FEATURE_SUPPORTS_ADAPTIVE_CCA] = "adaptive-cca",
>>>> [ATH10K_FW_FEATURE_MFP_SUPPORT] = "mfp",
>>>> [ATH10K_FW_FEATURE_PEER_FLOW_CONTROL] = "peer-flow-ctrl",
>>>> + [ATH10K_FW_FEATURE_WMI_10X_CT] = "wmi-10.x-CT",
>>>> };
>>>>
>>>> static unsigned int ath10k_core_get_fw_feature_str(char *buf,
>>>> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
>>>> index cb6aa8c..f9e3b20 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/core.h
>>>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>>>> @@ -566,6 +566,9 @@ enum ath10k_fw_features {
>>>> */
>>>> ATH10K_FW_FEATURE_PEER_FLOW_CONTROL = 13,
>>>>
>>>> + /* Firmware from Candela Technologies, enables more VIFs, etc */
>>>> + ATH10K_FW_FEATURE_WMI_10X_CT = 31,
>>>
>>> The idea of firmware feature flags to enable (or disable) one particular
>>> feature, not a group of features. This way it's easy to enable certain
>>> features on different firmware branches. It also makes the maintenance
>>> easier as you don't need to remember all the different features one flag
>>> enables.
>>
>> One potential use for this flag: Bug reports could be automatically directed to me instead
>> of QCA.
>>
>> I have actually re-written much of my earlier logic so that it uses specific
>> feature flags now. I still like the idea of having the driver (and user)
>> know it is using CT firmware, but I can live without this flag if needed.
>
> You can do with firmware version string, add something like "-CT" (maybe
> you already have?) and it's clearly visible in boot logs and also when
> firmware crashes.
Yes, that is a worse hack, but it works.
Thing is, I have years of older, tested firmware around, with this feature flag
set. So, it is going to warn when booting in a kernel that does not understand
this flag.
So, if you want CT firmware support at all in the upstream kernel, then I wish
you would let me add the enum and string to make it work as expected. That will also
let these old firmware do IBSS with one of the other patches I posted. Yes, it would
be nice to have an IBSS feature flag, but we have not for years, and again, this would
let my older firmware work.
It feels a bit like pulling teeth to get patches upstream. You are basically
waving through this huge hack to set registers for ack-timing and stuff, but
then you are arguing about a simple feature flag enum?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* [PATCH v2 16/21] ath10k: Support 32+ stations.
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
Support up to 32 stations when using CT firmware.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.c | 14 +++++++++++
drivers/net/wireless/ath/ath10k/hw.h | 6 +++++
drivers/net/wireless/ath/ath10k/mac.c | 43 ++++++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.c | 16 ++++++++++---
4 files changed, 76 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 49c85c3..3869edd 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1567,6 +1567,20 @@ static int ath10k_core_init_firmware_features(struct ath10k *ar)
ar->max_spatial_stream = WMI_MAX_SPATIAL_STREAM;
break;
case ATH10K_FW_WMI_OP_VERSION_10_1:
+ if (test_bit(ATH10K_FW_FEATURE_WMI_10X_CT,
+ fw_file->fw_features)) {
+ ar->max_num_peers = TARGET_10X_NUM_PEERS_CT;
+ ar->max_num_stations = TARGET_10X_NUM_STATIONS;
+ ar->max_num_vdevs = TARGET_10X_NUM_VDEVS_CT;
+ } else {
+ ar->max_num_peers = TARGET_10X_NUM_PEERS;
+ ar->max_num_stations = TARGET_10X_NUM_STATIONS;
+ ar->max_num_vdevs = TARGET_10X_NUM_VDEVS;
+ }
+ ar->htt.max_num_pending_tx = TARGET_10X_NUM_MSDU_DESC;
+ ar->fw_stats_req_mask = WMI_STAT_PEER;
+ ar->max_spatial_stream = WMI_MAX_SPATIAL_STREAM;
+ break;
case ATH10K_FW_WMI_OP_VERSION_10_2:
case ATH10K_FW_WMI_OP_VERSION_10_2_4:
if (ath10k_peer_stats_enabled(ar)) {
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 7b80e29..d3f37d5 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -370,6 +370,12 @@ enum ath10k_hw_4addr_pad {
(TARGET_10X_NUM_VDEVS))
#define TARGET_10X_TX_STATS_NUM_PEERS ((TARGET_10X_TX_STATS_NUM_STATIONS) + \
(TARGET_10X_NUM_VDEVS))
+
+/* Over-rides for Candela Technologies firmware */
+#define TARGET_10X_NUM_VDEVS_CT 32
+#define TARGET_10X_NUM_PEERS_CT (32 + (TARGET_10X_NUM_VDEVS_CT))
+#define TARGET_10X_AST_SKID_LIMIT_CT (TARGET_10X_NUM_PEERS_CT * TARGET_10X_NUM_PEER_AST)
+
#define TARGET_10X_NUM_OFFLOAD_PEERS 0
#define TARGET_10X_NUM_OFFLOAD_REORDER_BUFS 0
#define TARGET_10X_NUM_PEER_KEYS 2
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 42cac32..2169337 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7451,6 +7451,22 @@ static const struct ieee80211_iface_limit ath10k_10x_if_limits[] = {
},
};
+static const struct ieee80211_iface_limit ath10k_10x_ct_if_limits[] = {
+ {
+ .max = TARGET_10X_NUM_VDEVS_CT,
+ .types = BIT(NL80211_IFTYPE_STATION)
+ | BIT(NL80211_IFTYPE_P2P_CLIENT)
+ },
+ {
+ .max = 3,
+ .types = BIT(NL80211_IFTYPE_P2P_GO)
+ },
+ {
+ .max = 7,
+ .types = BIT(NL80211_IFTYPE_AP)
+ },
+};
+
static const struct ieee80211_iface_combination ath10k_if_comb[] = {
{
.limits = ath10k_if_limits,
@@ -7531,6 +7547,22 @@ static const struct ieee80211_iface_limit ath10k_tlv_if_limit_ibss[] = {
},
};
+static const struct ieee80211_iface_combination ath10k_10x_ct_if_comb[] = {
+ {
+ .limits = ath10k_10x_ct_if_limits,
+ .n_limits = ARRAY_SIZE(ath10k_10x_ct_if_limits),
+ .max_interfaces = TARGET_10X_NUM_VDEVS_CT,
+ .num_different_channels = 1,
+ .beacon_int_infra_match = true,
+#ifdef CONFIG_ATH10K_DFS_CERTIFIED
+ .radar_detect_widths = BIT(NL80211_CHAN_WIDTH_20_NOHT) |
+ BIT(NL80211_CHAN_WIDTH_20) |
+ BIT(NL80211_CHAN_WIDTH_40) |
+ BIT(NL80211_CHAN_WIDTH_80),
+#endif
+ },
+};
+
/* FIXME: This is not thouroughly tested. These combinations may over- or
* underestimate hw/fw capabilities.
*/
@@ -7808,6 +7840,17 @@ int ath10k_mac_register(struct ath10k *ar)
ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_ADHOC);
break;
case ATH10K_FW_WMI_OP_VERSION_10_1:
+ if (test_bit(ATH10K_FW_FEATURE_WMI_10X_CT,
+ ar->normal_mode_fw.fw_file.fw_features)) {
+ ar->hw->wiphy->iface_combinations = ath10k_10x_ct_if_comb;
+ ar->hw->wiphy->n_iface_combinations =
+ ARRAY_SIZE(ath10k_10x_ct_if_comb);
+ } else {
+ ar->hw->wiphy->iface_combinations = ath10k_10x_if_comb;
+ ar->hw->wiphy->n_iface_combinations =
+ ARRAY_SIZE(ath10k_10x_if_comb);
+ }
+ break;
case ATH10K_FW_WMI_OP_VERSION_10_2:
case ATH10K_FW_WMI_OP_VERSION_10_2_4:
ar->hw->wiphy->iface_combinations = ath10k_10x_if_comb;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 6cfba41..9ee2648 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5497,12 +5497,22 @@ static struct sk_buff *ath10k_wmi_10_1_op_gen_init(struct ath10k *ar)
struct sk_buff *buf;
struct wmi_resource_config_10x config = {};
u32 len, val;
+ u32 skid_limit;
+
+ if (test_bit(ATH10K_FW_FEATURE_WMI_10X_CT,
+ ar->running_fw->fw_file.fw_features)) {
+ config.num_vdevs = __cpu_to_le32(TARGET_10X_NUM_VDEVS_CT);
+ config.num_peers = __cpu_to_le32(TARGET_10X_NUM_PEERS_CT);
+ skid_limit = TARGET_10X_AST_SKID_LIMIT_CT;
+ } else {
+ config.num_vdevs = __cpu_to_le32(TARGET_10X_NUM_VDEVS);
+ config.num_peers = __cpu_to_le32(TARGET_10X_NUM_PEERS);
+ skid_limit = TARGET_10X_AST_SKID_LIMIT;
+ }
+ config.ast_skid_limit = __cpu_to_le32(skid_limit);
- config.num_vdevs = __cpu_to_le32(TARGET_10X_NUM_VDEVS);
- config.num_peers = __cpu_to_le32(TARGET_10X_NUM_PEERS);
config.num_peer_keys = __cpu_to_le32(TARGET_10X_NUM_PEER_KEYS);
config.num_tids = __cpu_to_le32(TARGET_10X_NUM_TIDS);
- config.ast_skid_limit = __cpu_to_le32(TARGET_10X_AST_SKID_LIMIT);
config.tx_chain_mask = __cpu_to_le32(TARGET_10X_TX_CHAIN_MASK);
config.rx_chain_mask = __cpu_to_le32(TARGET_10X_RX_CHAIN_MASK);
config.rx_timeout_pri_vo = __cpu_to_le32(TARGET_10X_RX_TIMEOUT_LO_PRI);
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 16/21] ath10k: Support 32+ stations.
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
Support up to 32 stations when using CT firmware.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.c | 14 +++++++++++
drivers/net/wireless/ath/ath10k/hw.h | 6 +++++
drivers/net/wireless/ath/ath10k/mac.c | 43 ++++++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.c | 16 ++++++++++---
4 files changed, 76 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 49c85c3..3869edd 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1567,6 +1567,20 @@ static int ath10k_core_init_firmware_features(struct ath10k *ar)
ar->max_spatial_stream = WMI_MAX_SPATIAL_STREAM;
break;
case ATH10K_FW_WMI_OP_VERSION_10_1:
+ if (test_bit(ATH10K_FW_FEATURE_WMI_10X_CT,
+ fw_file->fw_features)) {
+ ar->max_num_peers = TARGET_10X_NUM_PEERS_CT;
+ ar->max_num_stations = TARGET_10X_NUM_STATIONS;
+ ar->max_num_vdevs = TARGET_10X_NUM_VDEVS_CT;
+ } else {
+ ar->max_num_peers = TARGET_10X_NUM_PEERS;
+ ar->max_num_stations = TARGET_10X_NUM_STATIONS;
+ ar->max_num_vdevs = TARGET_10X_NUM_VDEVS;
+ }
+ ar->htt.max_num_pending_tx = TARGET_10X_NUM_MSDU_DESC;
+ ar->fw_stats_req_mask = WMI_STAT_PEER;
+ ar->max_spatial_stream = WMI_MAX_SPATIAL_STREAM;
+ break;
case ATH10K_FW_WMI_OP_VERSION_10_2:
case ATH10K_FW_WMI_OP_VERSION_10_2_4:
if (ath10k_peer_stats_enabled(ar)) {
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 7b80e29..d3f37d5 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -370,6 +370,12 @@ enum ath10k_hw_4addr_pad {
(TARGET_10X_NUM_VDEVS))
#define TARGET_10X_TX_STATS_NUM_PEERS ((TARGET_10X_TX_STATS_NUM_STATIONS) + \
(TARGET_10X_NUM_VDEVS))
+
+/* Over-rides for Candela Technologies firmware */
+#define TARGET_10X_NUM_VDEVS_CT 32
+#define TARGET_10X_NUM_PEERS_CT (32 + (TARGET_10X_NUM_VDEVS_CT))
+#define TARGET_10X_AST_SKID_LIMIT_CT (TARGET_10X_NUM_PEERS_CT * TARGET_10X_NUM_PEER_AST)
+
#define TARGET_10X_NUM_OFFLOAD_PEERS 0
#define TARGET_10X_NUM_OFFLOAD_REORDER_BUFS 0
#define TARGET_10X_NUM_PEER_KEYS 2
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 42cac32..2169337 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7451,6 +7451,22 @@ static const struct ieee80211_iface_limit ath10k_10x_if_limits[] = {
},
};
+static const struct ieee80211_iface_limit ath10k_10x_ct_if_limits[] = {
+ {
+ .max = TARGET_10X_NUM_VDEVS_CT,
+ .types = BIT(NL80211_IFTYPE_STATION)
+ | BIT(NL80211_IFTYPE_P2P_CLIENT)
+ },
+ {
+ .max = 3,
+ .types = BIT(NL80211_IFTYPE_P2P_GO)
+ },
+ {
+ .max = 7,
+ .types = BIT(NL80211_IFTYPE_AP)
+ },
+};
+
static const struct ieee80211_iface_combination ath10k_if_comb[] = {
{
.limits = ath10k_if_limits,
@@ -7531,6 +7547,22 @@ static const struct ieee80211_iface_limit ath10k_tlv_if_limit_ibss[] = {
},
};
+static const struct ieee80211_iface_combination ath10k_10x_ct_if_comb[] = {
+ {
+ .limits = ath10k_10x_ct_if_limits,
+ .n_limits = ARRAY_SIZE(ath10k_10x_ct_if_limits),
+ .max_interfaces = TARGET_10X_NUM_VDEVS_CT,
+ .num_different_channels = 1,
+ .beacon_int_infra_match = true,
+#ifdef CONFIG_ATH10K_DFS_CERTIFIED
+ .radar_detect_widths = BIT(NL80211_CHAN_WIDTH_20_NOHT) |
+ BIT(NL80211_CHAN_WIDTH_20) |
+ BIT(NL80211_CHAN_WIDTH_40) |
+ BIT(NL80211_CHAN_WIDTH_80),
+#endif
+ },
+};
+
/* FIXME: This is not thouroughly tested. These combinations may over- or
* underestimate hw/fw capabilities.
*/
@@ -7808,6 +7840,17 @@ int ath10k_mac_register(struct ath10k *ar)
ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_ADHOC);
break;
case ATH10K_FW_WMI_OP_VERSION_10_1:
+ if (test_bit(ATH10K_FW_FEATURE_WMI_10X_CT,
+ ar->normal_mode_fw.fw_file.fw_features)) {
+ ar->hw->wiphy->iface_combinations = ath10k_10x_ct_if_comb;
+ ar->hw->wiphy->n_iface_combinations =
+ ARRAY_SIZE(ath10k_10x_ct_if_comb);
+ } else {
+ ar->hw->wiphy->iface_combinations = ath10k_10x_if_comb;
+ ar->hw->wiphy->n_iface_combinations =
+ ARRAY_SIZE(ath10k_10x_if_comb);
+ }
+ break;
case ATH10K_FW_WMI_OP_VERSION_10_2:
case ATH10K_FW_WMI_OP_VERSION_10_2_4:
ar->hw->wiphy->iface_combinations = ath10k_10x_if_comb;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 6cfba41..9ee2648 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5497,12 +5497,22 @@ static struct sk_buff *ath10k_wmi_10_1_op_gen_init(struct ath10k *ar)
struct sk_buff *buf;
struct wmi_resource_config_10x config = {};
u32 len, val;
+ u32 skid_limit;
+
+ if (test_bit(ATH10K_FW_FEATURE_WMI_10X_CT,
+ ar->running_fw->fw_file.fw_features)) {
+ config.num_vdevs = __cpu_to_le32(TARGET_10X_NUM_VDEVS_CT);
+ config.num_peers = __cpu_to_le32(TARGET_10X_NUM_PEERS_CT);
+ skid_limit = TARGET_10X_AST_SKID_LIMIT_CT;
+ } else {
+ config.num_vdevs = __cpu_to_le32(TARGET_10X_NUM_VDEVS);
+ config.num_peers = __cpu_to_le32(TARGET_10X_NUM_PEERS);
+ skid_limit = TARGET_10X_AST_SKID_LIMIT;
+ }
+ config.ast_skid_limit = __cpu_to_le32(skid_limit);
- config.num_vdevs = __cpu_to_le32(TARGET_10X_NUM_VDEVS);
- config.num_peers = __cpu_to_le32(TARGET_10X_NUM_PEERS);
config.num_peer_keys = __cpu_to_le32(TARGET_10X_NUM_PEER_KEYS);
config.num_tids = __cpu_to_le32(TARGET_10X_NUM_TIDS);
- config.ast_skid_limit = __cpu_to_le32(TARGET_10X_AST_SKID_LIMIT);
config.tx_chain_mask = __cpu_to_le32(TARGET_10X_TX_CHAIN_MASK);
config.rx_chain_mask = __cpu_to_le32(TARGET_10X_RX_CHAIN_MASK);
config.rx_timeout_pri_vo = __cpu_to_le32(TARGET_10X_RX_TIMEOUT_LO_PRI);
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread
* [PATCH v2 17/21] ath10k: Enable detecting failure to install key in firmware (CT).
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
CT firmware has been modified so that it will always return
a response message when user requests to add a key, even if
the key could not actually be added. Upstream firmware may
assert or just not respond in a failure case.
This change should be compatible with non CT firmware.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/htt.h | 7 +++++--
drivers/net/wireless/ath/ath10k/htt_rx.c | 20 +++++++++++++++++---
drivers/net/wireless/ath/ath10k/mac.c | 3 ++-
4 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index f9e3b20..fda66bf 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -848,6 +848,7 @@ struct ath10k {
unsigned int filter_flags;
unsigned long dev_flags;
bool dfs_block_radar_events;
+ int install_key_rv; /* Store error code from key-install */
/* protected by conf_mutex */
bool radar_enabled;
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 911c535..c50b343 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -702,8 +702,9 @@ enum htt_security_types {
};
enum htt_security_flags {
-#define HTT_SECURITY_TYPE_MASK 0x7F
+#define HTT_SECURITY_TYPE_MASK 0x3F
#define HTT_SECURITY_TYPE_LSB 0
+ HTT_SECURITY_IS_FAILURE = 1 << 6, /* CT firmware only */
HTT_SECURITY_IS_UNICAST = 1 << 7
};
@@ -712,7 +713,9 @@ struct htt_security_indication {
/* dont use bitfields; undefined behaviour */
u8 flags; /* %htt_security_flags */
struct {
- u8 security_type:7, /* %htt_security_types */
+ u8 security_type:6, /* %htt_security_types */
+ is_failure:1, /* does this response indicate failure
+ (CT Firmware) */
is_unicast:1;
} __packed;
} __packed;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 47da904..02b5417 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2307,9 +2307,23 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
ath10k_dbg(ar, ATH10K_DBG_HTT,
"sec ind peer_id %d unicast %d type %d\n",
- __le16_to_cpu(ev->peer_id),
- !!(ev->flags & HTT_SECURITY_IS_UNICAST),
- MS(ev->flags, HTT_SECURITY_TYPE));
+ __le16_to_cpu(ev->peer_id),
+ !!(ev->flags & HTT_SECURITY_IS_UNICAST),
+ MS(ev->flags, HTT_SECURITY_TYPE));
+
+ /* CT firmware adds way to determine failure of key set, without
+ * just timing things out. Indication of failure is determined
+ * by the 6th bit of the security-type being set.
+ */
+ if (ev->flags & HTT_SECURITY_IS_FAILURE) {
+ ath10k_warn(ar, "Firmware failed to set security key, peer_id: %d unicast %d type %d\n",
+ __le16_to_cpu(ev->peer_id),
+ !!(ev->flags & HTT_SECURITY_IS_UNICAST),
+ MS(ev->flags, HTT_SECURITY_TYPE));
+ ar->install_key_rv = -EINVAL;
+ } else {
+ ar->install_key_rv = 0;
+ }
complete(&ar->install_key_done);
break;
}
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 2169337..373f2ee 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -255,7 +255,8 @@ static int ath10k_install_key(struct ath10k_vif *arvif,
if (time_left == 0)
return -ETIMEDOUT;
- return 0;
+ ret = ar->install_key_rv;
+ return ret;
}
static int ath10k_install_peer_wep_keys(struct ath10k_vif *arvif,
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 17/21] ath10k: Enable detecting failure to install key in firmware (CT).
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
CT firmware has been modified so that it will always return
a response message when user requests to add a key, even if
the key could not actually be added. Upstream firmware may
assert or just not respond in a failure case.
This change should be compatible with non CT firmware.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/core.h | 1 +
drivers/net/wireless/ath/ath10k/htt.h | 7 +++++--
drivers/net/wireless/ath/ath10k/htt_rx.c | 20 +++++++++++++++++---
drivers/net/wireless/ath/ath10k/mac.c | 3 ++-
4 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index f9e3b20..fda66bf 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -848,6 +848,7 @@ struct ath10k {
unsigned int filter_flags;
unsigned long dev_flags;
bool dfs_block_radar_events;
+ int install_key_rv; /* Store error code from key-install */
/* protected by conf_mutex */
bool radar_enabled;
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 911c535..c50b343 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -702,8 +702,9 @@ enum htt_security_types {
};
enum htt_security_flags {
-#define HTT_SECURITY_TYPE_MASK 0x7F
+#define HTT_SECURITY_TYPE_MASK 0x3F
#define HTT_SECURITY_TYPE_LSB 0
+ HTT_SECURITY_IS_FAILURE = 1 << 6, /* CT firmware only */
HTT_SECURITY_IS_UNICAST = 1 << 7
};
@@ -712,7 +713,9 @@ struct htt_security_indication {
/* dont use bitfields; undefined behaviour */
u8 flags; /* %htt_security_flags */
struct {
- u8 security_type:7, /* %htt_security_types */
+ u8 security_type:6, /* %htt_security_types */
+ is_failure:1, /* does this response indicate failure
+ (CT Firmware) */
is_unicast:1;
} __packed;
} __packed;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 47da904..02b5417 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2307,9 +2307,23 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
ath10k_dbg(ar, ATH10K_DBG_HTT,
"sec ind peer_id %d unicast %d type %d\n",
- __le16_to_cpu(ev->peer_id),
- !!(ev->flags & HTT_SECURITY_IS_UNICAST),
- MS(ev->flags, HTT_SECURITY_TYPE));
+ __le16_to_cpu(ev->peer_id),
+ !!(ev->flags & HTT_SECURITY_IS_UNICAST),
+ MS(ev->flags, HTT_SECURITY_TYPE));
+
+ /* CT firmware adds way to determine failure of key set, without
+ * just timing things out. Indication of failure is determined
+ * by the 6th bit of the security-type being set.
+ */
+ if (ev->flags & HTT_SECURITY_IS_FAILURE) {
+ ath10k_warn(ar, "Firmware failed to set security key, peer_id: %d unicast %d type %d\n",
+ __le16_to_cpu(ev->peer_id),
+ !!(ev->flags & HTT_SECURITY_IS_UNICAST),
+ MS(ev->flags, HTT_SECURITY_TYPE));
+ ar->install_key_rv = -EINVAL;
+ } else {
+ ar->install_key_rv = 0;
+ }
complete(&ar->install_key_done);
break;
}
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 2169337..373f2ee 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -255,7 +255,8 @@ static int ath10k_install_key(struct ath10k_vif *arvif,
if (time_left == 0)
return -ETIMEDOUT;
- return 0;
+ ret = ar->install_key_rv;
+ return ret;
}
static int ath10k_install_peer_wep_keys(struct ath10k_vif *arvif,
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread
* [PATCH v2 18/21] ath10k: Note limitation on beaconing vdevs.
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
This only pertains to CT firmware, as standard firmware
can't do anywhere near this many vdevs anyway.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 373f2ee..f1bfb3a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1343,6 +1343,22 @@ static int ath10k_vdev_start_restart(struct ath10k_vif *arvif,
arg.channel.max_reg_power = chandef->chan->max_reg_power * 2;
arg.channel.max_antenna_gain = chandef->chan->max_antenna_gain * 2;
+ /* CT Firmware can support 32+ VDEVS, but can only support
+ * beacon-ing devs with dev ids 0 - 31 due to firmware limitations.
+ * Create VAPs first and all should be well...likely most people
+ * won't ever hit this anyway, but some day the vdev ID allocation
+ * could be made smarter to make it more likely to work no matter the
+ * order the vdevs are created. --Ben
+ */
+ if ((arvif->vdev_type == WMI_VDEV_TYPE_AP) ||
+ (arvif->vdev_type == WMI_VDEV_TYPE_IBSS)) {
+ if (arg.vdev_id > 31) {
+ ath10k_warn(ar, "failed to start vdev %i Beaconing VIFS must have IDs <= 31 to work-around firmware limitations.\n",
+ arg.vdev_id);
+ return -EINVAL;
+ }
+ }
+
if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
arg.ssid = arvif->u.ap.ssid;
arg.ssid_len = arvif->u.ap.ssid_len;
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 18/21] ath10k: Note limitation on beaconing vdevs.
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
This only pertains to CT firmware, as standard firmware
can't do anywhere near this many vdevs anyway.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 373f2ee..f1bfb3a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1343,6 +1343,22 @@ static int ath10k_vdev_start_restart(struct ath10k_vif *arvif,
arg.channel.max_reg_power = chandef->chan->max_reg_power * 2;
arg.channel.max_antenna_gain = chandef->chan->max_antenna_gain * 2;
+ /* CT Firmware can support 32+ VDEVS, but can only support
+ * beacon-ing devs with dev ids 0 - 31 due to firmware limitations.
+ * Create VAPs first and all should be well...likely most people
+ * won't ever hit this anyway, but some day the vdev ID allocation
+ * could be made smarter to make it more likely to work no matter the
+ * order the vdevs are created. --Ben
+ */
+ if ((arvif->vdev_type == WMI_VDEV_TYPE_AP) ||
+ (arvif->vdev_type == WMI_VDEV_TYPE_IBSS)) {
+ if (arg.vdev_id > 31) {
+ ath10k_warn(ar, "failed to start vdev %i Beaconing VIFS must have IDs <= 31 to work-around firmware limitations.\n",
+ arg.vdev_id);
+ return -EINVAL;
+ }
+ }
+
if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
arg.ssid = arvif->u.ap.ssid;
arg.ssid_len = arvif->u.ap.ssid_len;
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread
* [PATCH v2 19/21] ath10k: Enable adhoc mode for CT firmware.
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
CT firmware can support IBSS mode, so allow users to configure this.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index f1bfb3a..3fc9006 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7482,6 +7482,10 @@ static const struct ieee80211_iface_limit ath10k_10x_ct_if_limits[] = {
.max = 7,
.types = BIT(NL80211_IFTYPE_AP)
},
+ {
+ .max = 1,
+ .types = BIT(NL80211_IFTYPE_ADHOC)
+ },
};
static const struct ieee80211_iface_combination ath10k_if_comb[] = {
@@ -7862,6 +7866,7 @@ int ath10k_mac_register(struct ath10k *ar)
ar->hw->wiphy->iface_combinations = ath10k_10x_ct_if_comb;
ar->hw->wiphy->n_iface_combinations =
ARRAY_SIZE(ath10k_10x_ct_if_comb);
+ ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_ADHOC);
} else {
ar->hw->wiphy->iface_combinations = ath10k_10x_if_comb;
ar->hw->wiphy->n_iface_combinations =
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 19/21] ath10k: Enable adhoc mode for CT firmware.
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
CT firmware can support IBSS mode, so allow users to configure this.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index f1bfb3a..3fc9006 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7482,6 +7482,10 @@ static const struct ieee80211_iface_limit ath10k_10x_ct_if_limits[] = {
.max = 7,
.types = BIT(NL80211_IFTYPE_AP)
},
+ {
+ .max = 1,
+ .types = BIT(NL80211_IFTYPE_ADHOC)
+ },
};
static const struct ieee80211_iface_combination ath10k_if_comb[] = {
@@ -7862,6 +7866,7 @@ int ath10k_mac_register(struct ath10k *ar)
ar->hw->wiphy->iface_combinations = ath10k_10x_ct_if_comb;
ar->hw->wiphy->n_iface_combinations =
ARRAY_SIZE(ath10k_10x_ct_if_comb);
+ ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_ADHOC);
} else {
ar->hw->wiphy->iface_combinations = ath10k_10x_if_comb;
ar->hw->wiphy->n_iface_combinations =
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread* Re: [PATCH v2 19/21] ath10k: Enable adhoc mode for CT firmware.
2016-05-11 17:02 ` greearb
@ 2016-09-14 14:37 ` Valo, Kalle
-1 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 14:37 UTC (permalink / raw)
To: greearb; +Cc: ath10k, linux-wireless
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> CT firmware can support IBSS mode, so allow users to configure this.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/mac.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless=
/ath/ath10k/mac.c
> index f1bfb3a..3fc9006 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -7482,6 +7482,10 @@ static const struct ieee80211_iface_limit ath10k_1=
0x_ct_if_limits[] =3D {
> .max =3D 7,
> .types =3D BIT(NL80211_IFTYPE_AP)
> },
> + {
> + .max =3D 1,
> + .types =3D BIT(NL80211_IFTYPE_ADHOC)
> + },
> };
> =20
> static const struct ieee80211_iface_combination ath10k_if_comb[] =3D {
> @@ -7862,6 +7866,7 @@ int ath10k_mac_register(struct ath10k *ar)
> ar->hw->wiphy->iface_combinations =3D ath10k_10x_ct_if_comb;
> ar->hw->wiphy->n_iface_combinations =3D
> ARRAY_SIZE(ath10k_10x_ct_if_comb);
> + ar->hw->wiphy->interface_modes |=3D BIT(NL80211_IFTYPE_ADHOC);
> } else {
> ar->hw->wiphy->iface_combinations =3D ath10k_10x_if_comb;
> ar->hw->wiphy->n_iface_combinations =3D
There should a feature flag ATH10K_FW_FEATURE_SUPPORTS_ADHOC and we use
that flag as an indication to enable the mode. I wish we had done that
from the beginning, using wmi_op_version to guess that just creates
problems :(
--=20
Kalle Valo=
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 19/21] ath10k: Enable adhoc mode for CT firmware.
@ 2016-09-14 14:37 ` Valo, Kalle
0 siblings, 0 replies; 118+ messages in thread
From: Valo, Kalle @ 2016-09-14 14:37 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath10k
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> CT firmware can support IBSS mode, so allow users to configure this.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
> drivers/net/wireless/ath/ath10k/mac.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index f1bfb3a..3fc9006 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -7482,6 +7482,10 @@ static const struct ieee80211_iface_limit ath10k_10x_ct_if_limits[] = {
> .max = 7,
> .types = BIT(NL80211_IFTYPE_AP)
> },
> + {
> + .max = 1,
> + .types = BIT(NL80211_IFTYPE_ADHOC)
> + },
> };
>
> static const struct ieee80211_iface_combination ath10k_if_comb[] = {
> @@ -7862,6 +7866,7 @@ int ath10k_mac_register(struct ath10k *ar)
> ar->hw->wiphy->iface_combinations = ath10k_10x_ct_if_comb;
> ar->hw->wiphy->n_iface_combinations =
> ARRAY_SIZE(ath10k_10x_ct_if_comb);
> + ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_ADHOC);
> } else {
> ar->hw->wiphy->iface_combinations = ath10k_10x_if_comb;
> ar->hw->wiphy->n_iface_combinations =
There should a feature flag ATH10K_FW_FEATURE_SUPPORTS_ADHOC and we use
that flag as an indication to enable the mode. I wish we had done that
from the beginning, using wmi_op_version to guess that just creates
problems :(
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 19/21] ath10k: Enable adhoc mode for CT firmware.
2016-09-14 14:37 ` Valo, Kalle
@ 2016-09-14 15:28 ` Ben Greear
-1 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-14 15:28 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/14/2016 07:37 AM, Valo, Kalle wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> CT firmware can support IBSS mode, so allow users to configure this.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>> ---
>> drivers/net/wireless/ath/ath10k/mac.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>> index f1bfb3a..3fc9006 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -7482,6 +7482,10 @@ static const struct ieee80211_iface_limit ath10k_10x_ct_if_limits[] = {
>> .max = 7,
>> .types = BIT(NL80211_IFTYPE_AP)
>> },
>> + {
>> + .max = 1,
>> + .types = BIT(NL80211_IFTYPE_ADHOC)
>> + },
>> };
>>
>> static const struct ieee80211_iface_combination ath10k_if_comb[] = {
>> @@ -7862,6 +7866,7 @@ int ath10k_mac_register(struct ath10k *ar)
>> ar->hw->wiphy->iface_combinations = ath10k_10x_ct_if_comb;
>> ar->hw->wiphy->n_iface_combinations =
>> ARRAY_SIZE(ath10k_10x_ct_if_comb);
>> + ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_ADHOC);
>> } else {
>> ar->hw->wiphy->iface_combinations = ath10k_10x_if_comb;
>> ar->hw->wiphy->n_iface_combinations =
>
> There should a feature flag ATH10K_FW_FEATURE_SUPPORTS_ADHOC and we use
> that flag as an indication to enable the mode. I wish we had done that
> from the beginning, using wmi_op_version to guess that just creates
> problems :(
No argument there. If you want to add a feature flag I can start setting it in
my firmware.
But, the if-combinations crap is a bigger problem than that anyway. I have
some later patches to re-work it to make it dynamically created instead of static,
but that is a fairly big change and I figured I had a better chance of getting
smaller changes upstream first.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 118+ messages in thread* Re: [PATCH v2 19/21] ath10k: Enable adhoc mode for CT firmware.
@ 2016-09-14 15:28 ` Ben Greear
0 siblings, 0 replies; 118+ messages in thread
From: Ben Greear @ 2016-09-14 15:28 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless, ath10k
On 09/14/2016 07:37 AM, Valo, Kalle wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> CT firmware can support IBSS mode, so allow users to configure this.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>> ---
>> drivers/net/wireless/ath/ath10k/mac.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>> index f1bfb3a..3fc9006 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -7482,6 +7482,10 @@ static const struct ieee80211_iface_limit ath10k_10x_ct_if_limits[] = {
>> .max = 7,
>> .types = BIT(NL80211_IFTYPE_AP)
>> },
>> + {
>> + .max = 1,
>> + .types = BIT(NL80211_IFTYPE_ADHOC)
>> + },
>> };
>>
>> static const struct ieee80211_iface_combination ath10k_if_comb[] = {
>> @@ -7862,6 +7866,7 @@ int ath10k_mac_register(struct ath10k *ar)
>> ar->hw->wiphy->iface_combinations = ath10k_10x_ct_if_comb;
>> ar->hw->wiphy->n_iface_combinations =
>> ARRAY_SIZE(ath10k_10x_ct_if_comb);
>> + ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_ADHOC);
>> } else {
>> ar->hw->wiphy->iface_combinations = ath10k_10x_if_comb;
>> ar->hw->wiphy->n_iface_combinations =
>
> There should a feature flag ATH10K_FW_FEATURE_SUPPORTS_ADHOC and we use
> that flag as an indication to enable the mode. I wish we had done that
> from the beginning, using wmi_op_version to guess that just creates
> problems :(
No argument there. If you want to add a feature flag I can start setting it in
my firmware.
But, the if-combinations crap is a bigger problem than that anyway. I have
some later patches to re-work it to make it dynamically created instead of static,
but that is a fairly big change and I figured I had a better chance of getting
smaller changes upstream first.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 118+ messages in thread
* [PATCH v2 20/21] ath10k: read firmware crash over ioread32 if CE fails.
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
This might work around problem where sometimes host cannot
access firmware crash over normal CE transport.
Requires CT firmware with matching logic in it's assert
handler (-13 and higher releases).
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/hw.h | 5 ++++
drivers/net/wireless/ath/ath10k/pci.c | 56 ++++++++++++++++++++++++++++++++++-
2 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index d3f37d5..5ff1fac 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -603,6 +603,7 @@ enum ath10k_hw_4addr_pad {
#define PCIE_INTR_ENABLE_ADDRESS 0x0008
#define PCIE_INTR_CAUSE_ADDRESS 0x000c
#define PCIE_INTR_CLR_ADDRESS ar->regs->pcie_intr_clr_address
+#define SCRATCH_2_ADDRESS 0x002c
#define SCRATCH_3_ADDRESS ar->regs->scratch_3_address
#define CPU_INTR_ADDRESS 0x0010
@@ -614,6 +615,10 @@ enum ath10k_hw_4addr_pad {
#define FW_IND_INITIALIZED 2
#define FW_IND_HOST_READY 0x80000000
+/* CT firmware only */
+#define FW_IND_SCRATCH2_WR (1<<14) /* scratch2 has data written to it */
+#define FW_IND_SCRATCH2_RD (1<<15) /* scratch2 has been read (by host) */
+
/* HOST_REG interrupt from firmware */
#define PCIE_INTR_FIRMWARE_MASK ar->regs->pcie_intr_fw_mask
#define PCIE_INTR_CE_MASK_ALL ar->regs->pcie_intr_ce_mask_all
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 2adc459..330c150 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1507,6 +1507,54 @@ static void ath10k_pci_dump_exc_stack(struct ath10k *ar,
hi_err_stack);
}
+/* Only CT firmware can do this. Attempt to read crash dump over pci
+ * registers since normal CE transport is not working.
+ */
+static int ath10k_ct_fw_crash_regs_harder(struct ath10k *ar,
+ __le32 *reg_dump_values,
+ int len)
+{
+ u32 val;
+ int i;
+ int q;
+#define MAX_SPIN_TRIES 1000000
+
+ if (!test_bit(ATH10K_FW_FEATURE_WMI_10X_CT,
+ ar->running_fw->fw_file.fw_features)) {
+ return -EINVAL;
+ }
+
+ for (i = 0; i<MAX_SPIN_TRIES; i++) {
+ val = ath10k_pci_read32(ar, FW_INDICATOR_ADDRESS);
+ if (val & FW_IND_SCRATCH2_WR)
+ goto pingpong;
+ }
+ return -EBUSY;
+
+pingpong:
+ ath10k_warn(ar, "Trying to read crash dump over pingpong registers.\n");
+ /* Firmware is trying to send us info it seems. */
+ for (q = 0; q<len; q++) {
+ reg_dump_values[q] = ath10k_pci_read32(ar, SOC_CORE_BASE_ADDRESS + SCRATCH_2_ADDRESS);
+ val = ath10k_pci_read32(ar, FW_INDICATOR_ADDRESS);
+ val |= FW_IND_SCRATCH2_RD; /* tell firmware we read it */
+ val &= ~FW_IND_SCRATCH2_WR; /* clear firmware's write flag */
+ ath10k_pci_write32(ar, FW_INDICATOR_ADDRESS, val);
+
+ for (i = 0; i<MAX_SPIN_TRIES; i++) {
+ val = ath10k_pci_read32(ar, FW_INDICATOR_ADDRESS);
+ if (val & FW_IND_SCRATCH2_WR)
+ break;
+ }
+ if (!(val & FW_IND_SCRATCH2_WR)) {
+ ath10k_err(ar, "failed to read reg %i via pingpong method.\n",
+ q);
+ return 0; // partial read is better than nothing I guess
+ }
+ }
+ return 0;
+}
+
static void ath10k_pci_dump_registers(struct ath10k *ar,
struct ath10k_fw_crash_data *crash_data)
{
@@ -1520,7 +1568,13 @@ static void ath10k_pci_dump_registers(struct ath10k *ar,
REG_DUMP_COUNT_QCA988X * sizeof(__le32));
if (ret) {
ath10k_err(ar, "failed to read firmware dump area: %d\n", ret);
- return;
+
+ /* Try to read this directly over registers...only works on new
+ * CT firmware.
+ */
+ ret = ath10k_ct_fw_crash_regs_harder(ar, reg_dump_values, REG_DUMP_COUNT_QCA988X);
+ if (ret)
+ return;
}
BUILD_BUG_ON(REG_DUMP_COUNT_QCA988X % 4);
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 20/21] ath10k: read firmware crash over ioread32 if CE fails.
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
This might work around problem where sometimes host cannot
access firmware crash over normal CE transport.
Requires CT firmware with matching logic in it's assert
handler (-13 and higher releases).
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/hw.h | 5 ++++
drivers/net/wireless/ath/ath10k/pci.c | 56 ++++++++++++++++++++++++++++++++++-
2 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index d3f37d5..5ff1fac 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -603,6 +603,7 @@ enum ath10k_hw_4addr_pad {
#define PCIE_INTR_ENABLE_ADDRESS 0x0008
#define PCIE_INTR_CAUSE_ADDRESS 0x000c
#define PCIE_INTR_CLR_ADDRESS ar->regs->pcie_intr_clr_address
+#define SCRATCH_2_ADDRESS 0x002c
#define SCRATCH_3_ADDRESS ar->regs->scratch_3_address
#define CPU_INTR_ADDRESS 0x0010
@@ -614,6 +615,10 @@ enum ath10k_hw_4addr_pad {
#define FW_IND_INITIALIZED 2
#define FW_IND_HOST_READY 0x80000000
+/* CT firmware only */
+#define FW_IND_SCRATCH2_WR (1<<14) /* scratch2 has data written to it */
+#define FW_IND_SCRATCH2_RD (1<<15) /* scratch2 has been read (by host) */
+
/* HOST_REG interrupt from firmware */
#define PCIE_INTR_FIRMWARE_MASK ar->regs->pcie_intr_fw_mask
#define PCIE_INTR_CE_MASK_ALL ar->regs->pcie_intr_ce_mask_all
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 2adc459..330c150 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1507,6 +1507,54 @@ static void ath10k_pci_dump_exc_stack(struct ath10k *ar,
hi_err_stack);
}
+/* Only CT firmware can do this. Attempt to read crash dump over pci
+ * registers since normal CE transport is not working.
+ */
+static int ath10k_ct_fw_crash_regs_harder(struct ath10k *ar,
+ __le32 *reg_dump_values,
+ int len)
+{
+ u32 val;
+ int i;
+ int q;
+#define MAX_SPIN_TRIES 1000000
+
+ if (!test_bit(ATH10K_FW_FEATURE_WMI_10X_CT,
+ ar->running_fw->fw_file.fw_features)) {
+ return -EINVAL;
+ }
+
+ for (i = 0; i<MAX_SPIN_TRIES; i++) {
+ val = ath10k_pci_read32(ar, FW_INDICATOR_ADDRESS);
+ if (val & FW_IND_SCRATCH2_WR)
+ goto pingpong;
+ }
+ return -EBUSY;
+
+pingpong:
+ ath10k_warn(ar, "Trying to read crash dump over pingpong registers.\n");
+ /* Firmware is trying to send us info it seems. */
+ for (q = 0; q<len; q++) {
+ reg_dump_values[q] = ath10k_pci_read32(ar, SOC_CORE_BASE_ADDRESS + SCRATCH_2_ADDRESS);
+ val = ath10k_pci_read32(ar, FW_INDICATOR_ADDRESS);
+ val |= FW_IND_SCRATCH2_RD; /* tell firmware we read it */
+ val &= ~FW_IND_SCRATCH2_WR; /* clear firmware's write flag */
+ ath10k_pci_write32(ar, FW_INDICATOR_ADDRESS, val);
+
+ for (i = 0; i<MAX_SPIN_TRIES; i++) {
+ val = ath10k_pci_read32(ar, FW_INDICATOR_ADDRESS);
+ if (val & FW_IND_SCRATCH2_WR)
+ break;
+ }
+ if (!(val & FW_IND_SCRATCH2_WR)) {
+ ath10k_err(ar, "failed to read reg %i via pingpong method.\n",
+ q);
+ return 0; // partial read is better than nothing I guess
+ }
+ }
+ return 0;
+}
+
static void ath10k_pci_dump_registers(struct ath10k *ar,
struct ath10k_fw_crash_data *crash_data)
{
@@ -1520,7 +1568,13 @@ static void ath10k_pci_dump_registers(struct ath10k *ar,
REG_DUMP_COUNT_QCA988X * sizeof(__le32));
if (ret) {
ath10k_err(ar, "failed to read firmware dump area: %d\n", ret);
- return;
+
+ /* Try to read this directly over registers...only works on new
+ * CT firmware.
+ */
+ ret = ath10k_ct_fw_crash_regs_harder(ar, reg_dump_values, REG_DUMP_COUNT_QCA988X);
+ if (ret)
+ return;
}
BUILD_BUG_ON(REG_DUMP_COUNT_QCA988X % 4);
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread
* [PATCH v2 21/21] ath10k: Read dbglog buffers over register ping-pong.
2016-05-11 17:02 ` greearb
@ 2016-05-11 17:02 ` greearb
-1 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
From: Ben Greear <greearb@candelatech.com>
This gives much better debugging capability when debugging
crashes in the firmware that cause CE transport loss.
(Such as AXI errors).
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/pci.c | 46 ++++++++++++++++++++++++++++++++++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 330c150..286b12d 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1532,7 +1532,7 @@ static int ath10k_ct_fw_crash_regs_harder(struct ath10k *ar,
return -EBUSY;
pingpong:
- ath10k_warn(ar, "Trying to read crash dump over pingpong registers.\n");
+ ath10k_warn(ar, "Trying to read crash dump over pingpong registers, len %d\n", len);
/* Firmware is trying to send us info it seems. */
for (q = 0; q<len; q++) {
reg_dump_values[q] = ath10k_pci_read32(ar, SOC_CORE_BASE_ADDRESS + SCRATCH_2_ADDRESS);
@@ -1567,6 +1567,10 @@ static void ath10k_pci_dump_registers(struct ath10k *ar,
hi_failure_state,
REG_DUMP_COUNT_QCA988X * sizeof(__le32));
if (ret) {
+ __le32 *buffer;
+ int len = 1500; /* length in bytes for firmware dbglog buffer */
+ struct ath10k_fw_dbglog_buf dbuf;
+
ath10k_err(ar, "failed to read firmware dump area: %d\n", ret);
/* Try to read this directly over registers...only works on new
@@ -1575,6 +1579,46 @@ static void ath10k_pci_dump_registers(struct ath10k *ar,
ret = ath10k_ct_fw_crash_regs_harder(ar, reg_dump_values, REG_DUMP_COUNT_QCA988X);
if (ret)
return;
+
+ /* Try to read the debug-log buffers as well. */
+ buffer = kzalloc(len, GFP_ATOMIC);
+
+ if (!buffer)
+ goto free_and_cont;
+
+ if (ath10k_ct_fw_crash_regs_harder(ar, (__le32 *)(&dbuf), sizeof(dbuf)/4))
+ goto free_and_cont;
+
+ /* wow, it worked! */
+ len = le32_to_cpu(dbuf.length);
+ if (len > 1500) {
+ ath10k_err(ar, "dbuf length is greater than 1500: %d\n", len);
+ len = 1500;
+ }
+ if (ath10k_ct_fw_crash_regs_harder(ar, buffer, len/4))
+ goto free_and_cont;
+
+ ath10k_dbg_save_fw_dbg_buffer(ar, buffer, len/4);
+ ath10k_dbg_print_fw_dbg_buffer(ar, buffer, len/4, KERN_ERR);
+
+ /* See if the second one is available */
+ if (ath10k_ct_fw_crash_regs_harder(ar, (__le32 *)(&dbuf), sizeof(dbuf)/4))
+ goto free_and_cont;
+
+ len = le32_to_cpu(dbuf.length);
+ if (len > 1500) {
+ ath10k_err(ar, "dbuf[2] length is greater than 1500: %d\n", len);
+ len = 1500;
+ }
+
+ if (ath10k_ct_fw_crash_regs_harder(ar, buffer, len/4))
+ goto free_and_cont;
+
+ ath10k_dbg_save_fw_dbg_buffer(ar, buffer, len/4);
+ ath10k_dbg_print_fw_dbg_buffer(ar, buffer, len/4, KERN_ERR);
+
+ free_and_cont:
+ kfree(buffer);
}
BUILD_BUG_ON(REG_DUMP_COUNT_QCA988X % 4);
--
2.4.3
^ permalink raw reply related [flat|nested] 118+ messages in thread* [PATCH v2 21/21] ath10k: Read dbglog buffers over register ping-pong.
@ 2016-05-11 17:02 ` greearb
0 siblings, 0 replies; 118+ messages in thread
From: greearb @ 2016-05-11 17:02 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, linux-wireless
From: Ben Greear <greearb@candelatech.com>
This gives much better debugging capability when debugging
crashes in the firmware that cause CE transport loss.
(Such as AXI errors).
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath10k/pci.c | 46 ++++++++++++++++++++++++++++++++++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 330c150..286b12d 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1532,7 +1532,7 @@ static int ath10k_ct_fw_crash_regs_harder(struct ath10k *ar,
return -EBUSY;
pingpong:
- ath10k_warn(ar, "Trying to read crash dump over pingpong registers.\n");
+ ath10k_warn(ar, "Trying to read crash dump over pingpong registers, len %d\n", len);
/* Firmware is trying to send us info it seems. */
for (q = 0; q<len; q++) {
reg_dump_values[q] = ath10k_pci_read32(ar, SOC_CORE_BASE_ADDRESS + SCRATCH_2_ADDRESS);
@@ -1567,6 +1567,10 @@ static void ath10k_pci_dump_registers(struct ath10k *ar,
hi_failure_state,
REG_DUMP_COUNT_QCA988X * sizeof(__le32));
if (ret) {
+ __le32 *buffer;
+ int len = 1500; /* length in bytes for firmware dbglog buffer */
+ struct ath10k_fw_dbglog_buf dbuf;
+
ath10k_err(ar, "failed to read firmware dump area: %d\n", ret);
/* Try to read this directly over registers...only works on new
@@ -1575,6 +1579,46 @@ static void ath10k_pci_dump_registers(struct ath10k *ar,
ret = ath10k_ct_fw_crash_regs_harder(ar, reg_dump_values, REG_DUMP_COUNT_QCA988X);
if (ret)
return;
+
+ /* Try to read the debug-log buffers as well. */
+ buffer = kzalloc(len, GFP_ATOMIC);
+
+ if (!buffer)
+ goto free_and_cont;
+
+ if (ath10k_ct_fw_crash_regs_harder(ar, (__le32 *)(&dbuf), sizeof(dbuf)/4))
+ goto free_and_cont;
+
+ /* wow, it worked! */
+ len = le32_to_cpu(dbuf.length);
+ if (len > 1500) {
+ ath10k_err(ar, "dbuf length is greater than 1500: %d\n", len);
+ len = 1500;
+ }
+ if (ath10k_ct_fw_crash_regs_harder(ar, buffer, len/4))
+ goto free_and_cont;
+
+ ath10k_dbg_save_fw_dbg_buffer(ar, buffer, len/4);
+ ath10k_dbg_print_fw_dbg_buffer(ar, buffer, len/4, KERN_ERR);
+
+ /* See if the second one is available */
+ if (ath10k_ct_fw_crash_regs_harder(ar, (__le32 *)(&dbuf), sizeof(dbuf)/4))
+ goto free_and_cont;
+
+ len = le32_to_cpu(dbuf.length);
+ if (len > 1500) {
+ ath10k_err(ar, "dbuf[2] length is greater than 1500: %d\n", len);
+ len = 1500;
+ }
+
+ if (ath10k_ct_fw_crash_regs_harder(ar, buffer, len/4))
+ goto free_and_cont;
+
+ ath10k_dbg_save_fw_dbg_buffer(ar, buffer, len/4);
+ ath10k_dbg_print_fw_dbg_buffer(ar, buffer, len/4, KERN_ERR);
+
+ free_and_cont:
+ kfree(buffer);
}
BUILD_BUG_ON(REG_DUMP_COUNT_QCA988X % 4);
--
2.4.3
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 118+ messages in thread