* [PATCH v2 01/10] ath10k: use 64-bit vdev map.
@ 2014-09-23 21:17 ` greearb
0 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear, ath10k
From: Ben Greear <greearb@candelatech.com>
This can allow more than 32 stations to be supported
without over-running the bitmap.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v2: Change debug message.
drivers/net/wireless/ath/ath10k/core.c | 4 ++--
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath10k/mac.c | 21 ++++++++++++---------
3 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index cee18c8..37e3166 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -846,9 +846,9 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode)
goto err_hif_stop;
if (test_bit(ATH10K_FW_FEATURE_WMI_10X, ar->fw_features))
- ar->free_vdev_map = (1 << TARGET_10X_NUM_VDEVS) - 1;
+ ar->free_vdev_map = (1LL << TARGET_10X_NUM_VDEVS) - 1;
else
- ar->free_vdev_map = (1 << TARGET_NUM_VDEVS) - 1;
+ ar->free_vdev_map = (1LL << TARGET_NUM_VDEVS) - 1;
INIT_LIST_HEAD(&ar->arvifs);
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 8a997b6..2f1d509 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -482,7 +482,7 @@ struct ath10k {
/* current operating channel definition */
struct cfg80211_chan_def chandef;
- int free_vdev_map;
+ unsigned long long free_vdev_map;
bool monitor;
int monitor_vdev_id;
bool monitor_started;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index a99d919..02e0a45 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -624,9 +624,9 @@ static int ath10k_monitor_vdev_create(struct ath10k *ar)
return -ENOMEM;
}
- bit = ffs(ar->free_vdev_map);
+ bit = __ffs64(ar->free_vdev_map);
- ar->monitor_vdev_id = bit - 1;
+ ar->monitor_vdev_id = bit;
ret = ath10k_wmi_vdev_create(ar, ar->monitor_vdev_id,
WMI_VDEV_TYPE_MONITOR,
@@ -637,7 +637,7 @@ static int ath10k_monitor_vdev_create(struct ath10k *ar)
return ret;
}
- ar->free_vdev_map &= ~(1 << ar->monitor_vdev_id);
+ ar->free_vdev_map &= ~(1LL << ar->monitor_vdev_id);
ath10k_dbg(ar, ATH10K_DBG_MAC, "mac monitor vdev %d created\n",
ar->monitor_vdev_id);
@@ -657,7 +657,7 @@ static int ath10k_monitor_vdev_delete(struct ath10k *ar)
return ret;
}
- ar->free_vdev_map |= 1 << ar->monitor_vdev_id;
+ ar->free_vdev_map |= 1LL << ar->monitor_vdev_id;
ath10k_dbg(ar, ATH10K_DBG_MAC, "mac monitor vdev %d deleted\n",
ar->monitor_vdev_id);
@@ -2791,9 +2791,12 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
ret = -EBUSY;
goto err;
}
- bit = ffs(ar->free_vdev_map);
+ bit = __ffs64(ar->free_vdev_map);
- arvif->vdev_id = bit - 1;
+ ath10k_dbg(ar, ATH10K_DBG_MAC, "mac create vdev %i map %llx\n",
+ bit, ar->free_vdev_map);
+
+ arvif->vdev_id = bit;
arvif->vdev_subtype = WMI_VDEV_SUBTYPE_NONE;
if (ar->p2p)
@@ -2865,7 +2868,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
goto err;
}
- ar->free_vdev_map &= ~(1 << arvif->vdev_id);
+ ar->free_vdev_map &= ~(1LL << arvif->vdev_id);
list_add(&arvif->list, &ar->arvifs);
vdev_param = ar->wmi.vdev_param->def_keyid;
@@ -2958,7 +2961,7 @@ err_peer_delete:
err_vdev_delete:
ath10k_wmi_vdev_delete(ar, arvif->vdev_id);
- ar->free_vdev_map |= 1 << arvif->vdev_id;
+ ar->free_vdev_map |= 1LL << arvif->vdev_id;
list_del(&arvif->list);
err:
@@ -2993,7 +2996,7 @@ static void ath10k_remove_interface(struct ieee80211_hw *hw,
ath10k_warn(ar, "failed to stop spectral for vdev %i: %d\n",
arvif->vdev_id, ret);
- ar->free_vdev_map |= 1 << arvif->vdev_id;
+ ar->free_vdev_map |= 1LL << arvif->vdev_id;
list_del(&arvif->list);
if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
--
1.7.11.7
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH v2 02/10] ath10k: add helper method to grab debug stats.
2014-09-23 21:17 ` greearb
@ 2014-09-23 21:17 ` greearb
-1 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k, Ben Greear
From: Ben Greear <greearb@candelatech.com>
It can be nice to update the firmware's stats while
debugging other bits of the driver, so add helper method
to do this.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v2: No changes.
drivers/net/wireless/ath/ath10k/debug.c | 26 +++++++++++++++++---------
drivers/net/wireless/ath/ath10k/debug.h | 3 +++
2 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 101c6f9..c2c02ce 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -371,6 +371,21 @@ void ath10k_debug_read_target_stats(struct ath10k *ar,
complete(&ar->debug.event_stats_compl);
}
+int ath10k_refresh_peer_stats(struct ath10k *ar)
+{
+ int ret = ath10k_wmi_request_stats(ar, WMI_REQUEST_PEER_STAT);
+ if (ret) {
+ ath10k_warn(ar, "could not request stats (%d)\n", ret);
+ return ret;
+ }
+
+ ret = wait_for_completion_timeout(&ar->debug.event_stats_compl, 1*HZ);
+ if (ret <= 0)
+ return ret;
+
+ return 0;
+}
+
static ssize_t ath10k_read_fw_stats(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
@@ -379,7 +394,6 @@ static ssize_t ath10k_read_fw_stats(struct file *file, char __user *user_buf,
char *buf = NULL;
unsigned int len = 0, buf_len = 8000;
ssize_t ret_cnt = 0;
- long left;
int i;
int ret;
@@ -394,14 +408,8 @@ static ssize_t ath10k_read_fw_stats(struct file *file, char __user *user_buf,
if (!buf)
goto exit;
- ret = ath10k_wmi_request_stats(ar, WMI_REQUEST_PEER_STAT);
- if (ret) {
- ath10k_warn(ar, "could not request stats (%d)\n", ret);
- goto exit;
- }
-
- left = wait_for_completion_timeout(&ar->debug.event_stats_compl, 1*HZ);
- if (left <= 0)
+ ret = ath10k_refresh_peer_stats(ar);
+ if (ret)
goto exit;
spin_lock_bh(&ar->data_lock);
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index d6276fe..ba6d280 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -142,4 +142,7 @@ static inline void ath10k_dbg_dump(struct ath10k *ar,
{
}
#endif /* CONFIG_ATH10K_DEBUG */
+
+int ath10k_refresh_peer_stats(struct ath10k *ar);
+
#endif /* _DEBUG_H_ */
--
1.7.11.7
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH v2 02/10] ath10k: add helper method to grab debug stats.
@ 2014-09-23 21:17 ` greearb
0 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear, ath10k
From: Ben Greear <greearb@candelatech.com>
It can be nice to update the firmware's stats while
debugging other bits of the driver, so add helper method
to do this.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v2: No changes.
drivers/net/wireless/ath/ath10k/debug.c | 26 +++++++++++++++++---------
drivers/net/wireless/ath/ath10k/debug.h | 3 +++
2 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 101c6f9..c2c02ce 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -371,6 +371,21 @@ void ath10k_debug_read_target_stats(struct ath10k *ar,
complete(&ar->debug.event_stats_compl);
}
+int ath10k_refresh_peer_stats(struct ath10k *ar)
+{
+ int ret = ath10k_wmi_request_stats(ar, WMI_REQUEST_PEER_STAT);
+ if (ret) {
+ ath10k_warn(ar, "could not request stats (%d)\n", ret);
+ return ret;
+ }
+
+ ret = wait_for_completion_timeout(&ar->debug.event_stats_compl, 1*HZ);
+ if (ret <= 0)
+ return ret;
+
+ return 0;
+}
+
static ssize_t ath10k_read_fw_stats(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
@@ -379,7 +394,6 @@ static ssize_t ath10k_read_fw_stats(struct file *file, char __user *user_buf,
char *buf = NULL;
unsigned int len = 0, buf_len = 8000;
ssize_t ret_cnt = 0;
- long left;
int i;
int ret;
@@ -394,14 +408,8 @@ static ssize_t ath10k_read_fw_stats(struct file *file, char __user *user_buf,
if (!buf)
goto exit;
- ret = ath10k_wmi_request_stats(ar, WMI_REQUEST_PEER_STAT);
- if (ret) {
- ath10k_warn(ar, "could not request stats (%d)\n", ret);
- goto exit;
- }
-
- left = wait_for_completion_timeout(&ar->debug.event_stats_compl, 1*HZ);
- if (left <= 0)
+ ret = ath10k_refresh_peer_stats(ar);
+ if (ret)
goto exit;
spin_lock_bh(&ar->data_lock);
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index d6276fe..ba6d280 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -142,4 +142,7 @@ static inline void ath10k_dbg_dump(struct ath10k *ar,
{
}
#endif /* CONFIG_ATH10K_DEBUG */
+
+int ath10k_refresh_peer_stats(struct ath10k *ar);
+
#endif /* _DEBUG_H_ */
--
1.7.11.7
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 03/10] ath10k: support ethtool stats.
2014-09-23 21:17 ` greearb
@ 2014-09-23 21:17 ` greearb
-1 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k, Ben Greear
From: Ben Greear <greearb@candelatech.com>
Add support for reading firmware stats through the ethtool
API. This may be easier for applications to manipulate
compared to parsing a text based debugfs file.
This patch also adds and reports firmware reset and
crash counters.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v2: Add data-lock around assignment of the stats.
Update changelog to mention firmware reset/crash
counters.
drivers/net/wireless/ath/ath10k/core.h | 4 +
drivers/net/wireless/ath/ath10k/debug.c | 146 ++++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/debug.h | 9 ++
drivers/net/wireless/ath/ath10k/mac.c | 5 ++
drivers/net/wireless/ath/ath10k/pci.c | 4 +
5 files changed, 168 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 2f1d509..7b220b1 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -541,6 +541,10 @@ struct ath10k {
struct dfs_pattern_detector *dfs_detector;
+ u32 fw_crash_counter;
+ u32 fw_warm_reset_counter;
+ u32 fw_cold_reset_counter;
+
#ifdef CONFIG_ATH10K_DEBUGFS
struct ath10k_debug debug;
#endif
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index c2c02ce..af1ca3e 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1037,6 +1037,152 @@ exit:
return ret;
}
+#ifdef CONFIG_ATH10K_DEBUGFS
+/* TODO: Would be nice to always support ethtool stats, would need to
+ * move the stats storage out of ath10k_debug, or always have ath10k_debug
+ * struct available..
+ */
+
+/* This generally cooresponds to the debugfs fw_stats file */
+static const char ath10k_gstrings_stats[][ETH_GSTRING_LEN] = {
+ "tx_pkts_nic",
+ "tx_bytes_nic",
+ "rx_pkts_nic",
+ "rx_bytes_nic",
+ "d_noise_floor",
+ "d_cycle_count",
+ "d_phy_error",
+ "d_rts_bad",
+ "d_rts_good",
+ "d_tx_power", /* in .5 dbM I think */
+ "d_rx_crc_err", /* fcs_bad */
+ "d_no_beacon",
+ "d_tx_mpdus_queued",
+ "d_tx_msdu_queued",
+ "d_tx_msdu_dropped",
+ "d_local_enqued",
+ "d_local_freed",
+ "d_tx_ppdu_hw_queued",
+ "d_tx_ppdu_reaped",
+ "d_tx_fifo_underrun",
+ "d_tx_ppdu_abort",
+ "d_tx_mpdu_requed",
+ "d_tx_excessive_retries",
+ "d_tx_hw_rate",
+ "d_tx_dropped_sw_retries",
+ "d_tx_illegal_rate",
+ "d_tx_continuous_xretries",
+ "d_tx_timeout",
+ "d_tx_mpdu_txop_limit",
+ "d_pdev_resets",
+ "d_rx_mid_ppdu_route_change",
+ "d_rx_status",
+ "d_rx_extra_frags_ring0",
+ "d_rx_extra_frags_ring1",
+ "d_rx_extra_frags_ring2",
+ "d_rx_extra_frags_ring3",
+ "d_rx_msdu_htt",
+ "d_rx_mpdu_htt",
+ "d_rx_msdu_stack",
+ "d_rx_mpdu_stack",
+ "d_rx_phy_err",
+ "d_rx_phy_err_drops",
+ "d_rx_mpdu_errors", /* FCS, MIC, ENC */
+ "d_fw_crash_count",
+ "d_fw_warm_reset_count",
+ "d_fw_cold_reset_count",
+};
+#define ATH10K_SSTATS_LEN ARRAY_SIZE(ath10k_gstrings_stats)
+
+void ath10k_get_et_strings(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ u32 sset, u8 *data)
+{
+ if (sset == ETH_SS_STATS)
+ memcpy(data, *ath10k_gstrings_stats,
+ sizeof(ath10k_gstrings_stats));
+}
+
+int ath10k_get_et_sset_count(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif, int sset)
+{
+ if (sset == ETH_SS_STATS)
+ return ATH10K_SSTATS_LEN;
+ return 0;
+}
+
+void ath10k_get_et_stats(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ethtool_stats *stats, u64 *data)
+{
+ struct ath10k *ar = hw->priv;
+ int i = 0;
+ struct ath10k_target_stats *fw_stats;
+
+ fw_stats = &ar->debug.target_stats;
+
+ mutex_lock(&ar->conf_mutex);
+
+ if (ar->state == ATH10K_STATE_ON)
+ ath10k_refresh_peer_stats(ar);
+
+ mutex_unlock(&ar->conf_mutex);
+
+ spin_lock_bh(&ar->data_lock);
+ data[i++] = fw_stats->hw_reaped; /* ppdu reaped */
+ data[i++] = 0; /* tx bytes */
+ data[i++] = fw_stats->htt_mpdus;
+ data[i++] = 0; /* rx bytes */
+ data[i++] = fw_stats->ch_noise_floor;
+ data[i++] = fw_stats->cycle_count;
+ data[i++] = fw_stats->phy_err_count;
+ data[i++] = fw_stats->rts_bad;
+ data[i++] = fw_stats->rts_good;
+ data[i++] = fw_stats->chan_tx_power;
+ data[i++] = fw_stats->fcs_bad;
+ data[i++] = fw_stats->no_beacons;
+ data[i++] = fw_stats->mpdu_enqued;
+ data[i++] = fw_stats->msdu_enqued;
+ data[i++] = fw_stats->wmm_drop;
+ data[i++] = fw_stats->local_enqued;
+ data[i++] = fw_stats->local_freed;
+ data[i++] = fw_stats->hw_queued;
+ data[i++] = fw_stats->hw_reaped;
+ data[i++] = fw_stats->underrun;
+ data[i++] = fw_stats->tx_abort;
+ data[i++] = fw_stats->mpdus_requed;
+ data[i++] = fw_stats->tx_ko;
+ data[i++] = fw_stats->data_rc;
+ data[i++] = fw_stats->sw_retry_failure;
+ data[i++] = fw_stats->illgl_rate_phy_err;
+ data[i++] = fw_stats->pdev_cont_xretry;
+ data[i++] = fw_stats->pdev_tx_timeout;
+ data[i++] = fw_stats->txop_ovf;
+ data[i++] = fw_stats->pdev_resets;
+ data[i++] = fw_stats->mid_ppdu_route_change;
+ data[i++] = fw_stats->status_rcvd;
+ data[i++] = fw_stats->r0_frags;
+ data[i++] = fw_stats->r1_frags;
+ data[i++] = fw_stats->r2_frags;
+ data[i++] = fw_stats->r3_frags;
+ data[i++] = fw_stats->htt_msdus;
+ data[i++] = fw_stats->htt_mpdus;
+ data[i++] = fw_stats->loc_msdus;
+ data[i++] = fw_stats->loc_mpdus;
+ data[i++] = fw_stats->phy_errs;
+ data[i++] = fw_stats->phy_err_drop;
+ data[i++] = fw_stats->mpdu_errs;
+ data[i++] = ar->fw_crash_counter;
+ data[i++] = ar->fw_warm_reset_counter;
+ data[i++] = ar->fw_cold_reset_counter;
+
+ spin_unlock_bh(&ar->data_lock);
+
+ WARN_ON(i != ATH10K_SSTATS_LEN);
+}
+
+#endif
+
static const struct file_operations fops_fw_dbglog = {
.read = ath10k_read_fw_dbglog,
.write = ath10k_write_fw_dbglog,
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index ba6d280..39032e9 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -64,6 +64,15 @@ void ath10k_debug_dbglog_add(struct ath10k *ar, u8 *buffer, int len);
#define ATH10K_DFS_STAT_INC(ar, c) (ar->debug.dfs_stats.c++)
+void ath10k_get_et_strings(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ u32 sset, u8 *data);
+int ath10k_get_et_sset_count(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif, int sset);
+void ath10k_get_et_stats(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ethtool_stats *stats, u64 *data);
+
#else
static inline int ath10k_debug_start(struct ath10k *ar)
{
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 02e0a45..4bb3ef6 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4515,6 +4515,11 @@ static const struct ieee80211_ops ath10k_ops = {
.suspend = ath10k_suspend,
.resume = ath10k_resume,
#endif
+#ifdef CONFIG_ATH10K_DEBUGFS
+ .get_et_sset_count = ath10k_get_et_sset_count,
+ .get_et_stats = ath10k_get_et_stats,
+ .get_et_strings = ath10k_get_et_strings,
+#endif
};
#define RATETAB_ENT(_rate, _rateid, _flags) { \
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 59e0ea8..38f7386 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -986,6 +986,8 @@ static void ath10k_pci_fw_crashed_dump(struct ath10k *ar)
spin_lock_bh(&ar->data_lock);
+ ar->fw_crash_counter++;
+
crash_data = ath10k_debug_get_new_fw_crash_data(ar);
if (crash_data)
@@ -1671,6 +1673,7 @@ static int ath10k_pci_warm_reset(struct ath10k *ar)
u32 val;
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot warm reset\n");
+ ar->fw_warm_reset_counter++;
/* debug */
val = ath10k_pci_read32(ar, SOC_CORE_BASE_ADDRESS +
@@ -2286,6 +2289,7 @@ static int ath10k_pci_cold_reset(struct ath10k *ar)
u32 val;
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot cold reset\n");
+ ar->fw_cold_reset_counter++;
/* Put Target, including PCIe, into RESET. */
val = ath10k_pci_reg_read32(ar, SOC_GLOBAL_RESET_ADDRESS);
--
1.7.11.7
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH v2 03/10] ath10k: support ethtool stats.
@ 2014-09-23 21:17 ` greearb
0 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear, ath10k
From: Ben Greear <greearb@candelatech.com>
Add support for reading firmware stats through the ethtool
API. This may be easier for applications to manipulate
compared to parsing a text based debugfs file.
This patch also adds and reports firmware reset and
crash counters.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v2: Add data-lock around assignment of the stats.
Update changelog to mention firmware reset/crash
counters.
drivers/net/wireless/ath/ath10k/core.h | 4 +
drivers/net/wireless/ath/ath10k/debug.c | 146 ++++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/debug.h | 9 ++
drivers/net/wireless/ath/ath10k/mac.c | 5 ++
drivers/net/wireless/ath/ath10k/pci.c | 4 +
5 files changed, 168 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 2f1d509..7b220b1 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -541,6 +541,10 @@ struct ath10k {
struct dfs_pattern_detector *dfs_detector;
+ u32 fw_crash_counter;
+ u32 fw_warm_reset_counter;
+ u32 fw_cold_reset_counter;
+
#ifdef CONFIG_ATH10K_DEBUGFS
struct ath10k_debug debug;
#endif
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index c2c02ce..af1ca3e 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1037,6 +1037,152 @@ exit:
return ret;
}
+#ifdef CONFIG_ATH10K_DEBUGFS
+/* TODO: Would be nice to always support ethtool stats, would need to
+ * move the stats storage out of ath10k_debug, or always have ath10k_debug
+ * struct available..
+ */
+
+/* This generally cooresponds to the debugfs fw_stats file */
+static const char ath10k_gstrings_stats[][ETH_GSTRING_LEN] = {
+ "tx_pkts_nic",
+ "tx_bytes_nic",
+ "rx_pkts_nic",
+ "rx_bytes_nic",
+ "d_noise_floor",
+ "d_cycle_count",
+ "d_phy_error",
+ "d_rts_bad",
+ "d_rts_good",
+ "d_tx_power", /* in .5 dbM I think */
+ "d_rx_crc_err", /* fcs_bad */
+ "d_no_beacon",
+ "d_tx_mpdus_queued",
+ "d_tx_msdu_queued",
+ "d_tx_msdu_dropped",
+ "d_local_enqued",
+ "d_local_freed",
+ "d_tx_ppdu_hw_queued",
+ "d_tx_ppdu_reaped",
+ "d_tx_fifo_underrun",
+ "d_tx_ppdu_abort",
+ "d_tx_mpdu_requed",
+ "d_tx_excessive_retries",
+ "d_tx_hw_rate",
+ "d_tx_dropped_sw_retries",
+ "d_tx_illegal_rate",
+ "d_tx_continuous_xretries",
+ "d_tx_timeout",
+ "d_tx_mpdu_txop_limit",
+ "d_pdev_resets",
+ "d_rx_mid_ppdu_route_change",
+ "d_rx_status",
+ "d_rx_extra_frags_ring0",
+ "d_rx_extra_frags_ring1",
+ "d_rx_extra_frags_ring2",
+ "d_rx_extra_frags_ring3",
+ "d_rx_msdu_htt",
+ "d_rx_mpdu_htt",
+ "d_rx_msdu_stack",
+ "d_rx_mpdu_stack",
+ "d_rx_phy_err",
+ "d_rx_phy_err_drops",
+ "d_rx_mpdu_errors", /* FCS, MIC, ENC */
+ "d_fw_crash_count",
+ "d_fw_warm_reset_count",
+ "d_fw_cold_reset_count",
+};
+#define ATH10K_SSTATS_LEN ARRAY_SIZE(ath10k_gstrings_stats)
+
+void ath10k_get_et_strings(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ u32 sset, u8 *data)
+{
+ if (sset == ETH_SS_STATS)
+ memcpy(data, *ath10k_gstrings_stats,
+ sizeof(ath10k_gstrings_stats));
+}
+
+int ath10k_get_et_sset_count(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif, int sset)
+{
+ if (sset == ETH_SS_STATS)
+ return ATH10K_SSTATS_LEN;
+ return 0;
+}
+
+void ath10k_get_et_stats(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ethtool_stats *stats, u64 *data)
+{
+ struct ath10k *ar = hw->priv;
+ int i = 0;
+ struct ath10k_target_stats *fw_stats;
+
+ fw_stats = &ar->debug.target_stats;
+
+ mutex_lock(&ar->conf_mutex);
+
+ if (ar->state == ATH10K_STATE_ON)
+ ath10k_refresh_peer_stats(ar);
+
+ mutex_unlock(&ar->conf_mutex);
+
+ spin_lock_bh(&ar->data_lock);
+ data[i++] = fw_stats->hw_reaped; /* ppdu reaped */
+ data[i++] = 0; /* tx bytes */
+ data[i++] = fw_stats->htt_mpdus;
+ data[i++] = 0; /* rx bytes */
+ data[i++] = fw_stats->ch_noise_floor;
+ data[i++] = fw_stats->cycle_count;
+ data[i++] = fw_stats->phy_err_count;
+ data[i++] = fw_stats->rts_bad;
+ data[i++] = fw_stats->rts_good;
+ data[i++] = fw_stats->chan_tx_power;
+ data[i++] = fw_stats->fcs_bad;
+ data[i++] = fw_stats->no_beacons;
+ data[i++] = fw_stats->mpdu_enqued;
+ data[i++] = fw_stats->msdu_enqued;
+ data[i++] = fw_stats->wmm_drop;
+ data[i++] = fw_stats->local_enqued;
+ data[i++] = fw_stats->local_freed;
+ data[i++] = fw_stats->hw_queued;
+ data[i++] = fw_stats->hw_reaped;
+ data[i++] = fw_stats->underrun;
+ data[i++] = fw_stats->tx_abort;
+ data[i++] = fw_stats->mpdus_requed;
+ data[i++] = fw_stats->tx_ko;
+ data[i++] = fw_stats->data_rc;
+ data[i++] = fw_stats->sw_retry_failure;
+ data[i++] = fw_stats->illgl_rate_phy_err;
+ data[i++] = fw_stats->pdev_cont_xretry;
+ data[i++] = fw_stats->pdev_tx_timeout;
+ data[i++] = fw_stats->txop_ovf;
+ data[i++] = fw_stats->pdev_resets;
+ data[i++] = fw_stats->mid_ppdu_route_change;
+ data[i++] = fw_stats->status_rcvd;
+ data[i++] = fw_stats->r0_frags;
+ data[i++] = fw_stats->r1_frags;
+ data[i++] = fw_stats->r2_frags;
+ data[i++] = fw_stats->r3_frags;
+ data[i++] = fw_stats->htt_msdus;
+ data[i++] = fw_stats->htt_mpdus;
+ data[i++] = fw_stats->loc_msdus;
+ data[i++] = fw_stats->loc_mpdus;
+ data[i++] = fw_stats->phy_errs;
+ data[i++] = fw_stats->phy_err_drop;
+ data[i++] = fw_stats->mpdu_errs;
+ data[i++] = ar->fw_crash_counter;
+ data[i++] = ar->fw_warm_reset_counter;
+ data[i++] = ar->fw_cold_reset_counter;
+
+ spin_unlock_bh(&ar->data_lock);
+
+ WARN_ON(i != ATH10K_SSTATS_LEN);
+}
+
+#endif
+
static const struct file_operations fops_fw_dbglog = {
.read = ath10k_read_fw_dbglog,
.write = ath10k_write_fw_dbglog,
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index ba6d280..39032e9 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -64,6 +64,15 @@ void ath10k_debug_dbglog_add(struct ath10k *ar, u8 *buffer, int len);
#define ATH10K_DFS_STAT_INC(ar, c) (ar->debug.dfs_stats.c++)
+void ath10k_get_et_strings(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ u32 sset, u8 *data);
+int ath10k_get_et_sset_count(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif, int sset);
+void ath10k_get_et_stats(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ethtool_stats *stats, u64 *data);
+
#else
static inline int ath10k_debug_start(struct ath10k *ar)
{
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 02e0a45..4bb3ef6 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4515,6 +4515,11 @@ static const struct ieee80211_ops ath10k_ops = {
.suspend = ath10k_suspend,
.resume = ath10k_resume,
#endif
+#ifdef CONFIG_ATH10K_DEBUGFS
+ .get_et_sset_count = ath10k_get_et_sset_count,
+ .get_et_stats = ath10k_get_et_stats,
+ .get_et_strings = ath10k_get_et_strings,
+#endif
};
#define RATETAB_ENT(_rate, _rateid, _flags) { \
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 59e0ea8..38f7386 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -986,6 +986,8 @@ static void ath10k_pci_fw_crashed_dump(struct ath10k *ar)
spin_lock_bh(&ar->data_lock);
+ ar->fw_crash_counter++;
+
crash_data = ath10k_debug_get_new_fw_crash_data(ar);
if (crash_data)
@@ -1671,6 +1673,7 @@ static int ath10k_pci_warm_reset(struct ath10k *ar)
u32 val;
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot warm reset\n");
+ ar->fw_warm_reset_counter++;
/* debug */
val = ath10k_pci_read32(ar, SOC_CORE_BASE_ADDRESS +
@@ -2286,6 +2289,7 @@ static int ath10k_pci_cold_reset(struct ath10k *ar)
u32 val;
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot cold reset\n");
+ ar->fw_cold_reset_counter++;
/* Put Target, including PCIe, into RESET. */
val = ath10k_pci_reg_read32(ar, SOC_GLOBAL_RESET_ADDRESS);
--
1.7.11.7
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [PATCH v2 03/10] ath10k: support ethtool stats.
2014-09-23 21:17 ` greearb
@ 2014-09-24 7:44 ` Michal Kazior
-1 siblings, 0 replies; 54+ messages in thread
From: Michal Kazior @ 2014-09-24 7:44 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k
On 23 September 2014 23:17, <greearb@candelatech.com> wrote:
[...]
> +void ath10k_get_et_stats(struct ieee80211_hw *hw,
> + struct ieee80211_vif *vif,
> + struct ethtool_stats *stats, u64 *data)
> +{
> + struct ath10k *ar = hw->priv;
> + int i = 0;
> + struct ath10k_target_stats *fw_stats;
> +
> + fw_stats = &ar->debug.target_stats;
> +
> + mutex_lock(&ar->conf_mutex);
> +
> + if (ar->state == ATH10K_STATE_ON)
> + ath10k_refresh_peer_stats(ar);
> +
> + mutex_unlock(&ar->conf_mutex);
Just for correctness sake - it's probably a good idea to
mutex_unlock() at the end (i.e. after spin_unlock_bh()) to make sure
the stats are for this particular request. With your patch there's a
very slight chance that, e.g. fw_stats debug file is being read at the
same time and it updates fw stats between the above mutex_unlock() and
following spin_lock_bh().
> + spin_lock_bh(&ar->data_lock);
> + data[i++] = fw_stats->hw_reaped; /* ppdu reaped */
[...]
> + spin_unlock_bh(&ar->data_lock);
> +
> + WARN_ON(i != ATH10K_SSTATS_LEN);
> +}
Michał
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 03/10] ath10k: support ethtool stats.
@ 2014-09-24 7:44 ` Michal Kazior
0 siblings, 0 replies; 54+ messages in thread
From: Michal Kazior @ 2014-09-24 7:44 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k
On 23 September 2014 23:17, <greearb@candelatech.com> wrote:
[...]
> +void ath10k_get_et_stats(struct ieee80211_hw *hw,
> + struct ieee80211_vif *vif,
> + struct ethtool_stats *stats, u64 *data)
> +{
> + struct ath10k *ar = hw->priv;
> + int i = 0;
> + struct ath10k_target_stats *fw_stats;
> +
> + fw_stats = &ar->debug.target_stats;
> +
> + mutex_lock(&ar->conf_mutex);
> +
> + if (ar->state == ATH10K_STATE_ON)
> + ath10k_refresh_peer_stats(ar);
> +
> + mutex_unlock(&ar->conf_mutex);
Just for correctness sake - it's probably a good idea to
mutex_unlock() at the end (i.e. after spin_unlock_bh()) to make sure
the stats are for this particular request. With your patch there's a
very slight chance that, e.g. fw_stats debug file is being read at the
same time and it updates fw stats between the above mutex_unlock() and
following spin_lock_bh().
> + spin_lock_bh(&ar->data_lock);
> + data[i++] = fw_stats->hw_reaped; /* ppdu reaped */
[...]
> + spin_unlock_bh(&ar->data_lock);
> +
> + WARN_ON(i != ATH10K_SSTATS_LEN);
> +}
Michał
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 03/10] ath10k: support ethtool stats.
2014-09-24 7:44 ` Michal Kazior
@ 2014-09-24 14:37 ` Ben Greear
-1 siblings, 0 replies; 54+ messages in thread
From: Ben Greear @ 2014-09-24 14:37 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless, ath10k
On 09/24/2014 12:44 AM, Michal Kazior wrote:
> On 23 September 2014 23:17, <greearb@candelatech.com> wrote:
> [...]
>> +void ath10k_get_et_stats(struct ieee80211_hw *hw,
>> + struct ieee80211_vif *vif,
>> + struct ethtool_stats *stats, u64 *data)
>> +{
>> + struct ath10k *ar = hw->priv;
>> + int i = 0;
>> + struct ath10k_target_stats *fw_stats;
>> +
>> + fw_stats = &ar->debug.target_stats;
>> +
>> + mutex_lock(&ar->conf_mutex);
>> +
>> + if (ar->state == ATH10K_STATE_ON)
>> + ath10k_refresh_peer_stats(ar);
>> +
>> + mutex_unlock(&ar->conf_mutex);
>
> Just for correctness sake - it's probably a good idea to
> mutex_unlock() at the end (i.e. after spin_unlock_bh()) to make sure
> the stats are for this particular request. With your patch there's a
> very slight chance that, e.g. fw_stats debug file is being read at the
> same time and it updates fw stats between the above mutex_unlock() and
> following spin_lock_bh().
That makes no difference at all to the user though, and it is one less
set of nested locks to worry about.
I'd prefer to leave it as is.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 03/10] ath10k: support ethtool stats.
@ 2014-09-24 14:37 ` Ben Greear
0 siblings, 0 replies; 54+ messages in thread
From: Ben Greear @ 2014-09-24 14:37 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless, ath10k
On 09/24/2014 12:44 AM, Michal Kazior wrote:
> On 23 September 2014 23:17, <greearb@candelatech.com> wrote:
> [...]
>> +void ath10k_get_et_stats(struct ieee80211_hw *hw,
>> + struct ieee80211_vif *vif,
>> + struct ethtool_stats *stats, u64 *data)
>> +{
>> + struct ath10k *ar = hw->priv;
>> + int i = 0;
>> + struct ath10k_target_stats *fw_stats;
>> +
>> + fw_stats = &ar->debug.target_stats;
>> +
>> + mutex_lock(&ar->conf_mutex);
>> +
>> + if (ar->state == ATH10K_STATE_ON)
>> + ath10k_refresh_peer_stats(ar);
>> +
>> + mutex_unlock(&ar->conf_mutex);
>
> Just for correctness sake - it's probably a good idea to
> mutex_unlock() at the end (i.e. after spin_unlock_bh()) to make sure
> the stats are for this particular request. With your patch there's a
> very slight chance that, e.g. fw_stats debug file is being read at the
> same time and it updates fw stats between the above mutex_unlock() and
> following spin_lock_bh().
That makes no difference at all to the user though, and it is one less
set of nested locks to worry about.
I'd prefer to leave it as is.
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] 54+ messages in thread* Re: [PATCH v2 03/10] ath10k: support ethtool stats.
2014-09-24 14:37 ` Ben Greear
@ 2014-09-29 8:21 ` Kalle Valo
-1 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-09-29 8:21 UTC (permalink / raw)
To: Ben Greear; +Cc: Michal Kazior, linux-wireless, ath10k
Ben Greear <greearb@candelatech.com> writes:
> On 09/24/2014 12:44 AM, Michal Kazior wrote:
>> On 23 September 2014 23:17, <greearb@candelatech.com> wrote:
>> [...]
>>> +void ath10k_get_et_stats(struct ieee80211_hw *hw,
>>> + struct ieee80211_vif *vif,
>>> + struct ethtool_stats *stats, u64 *data)
>>> +{
>>> + struct ath10k *ar = hw->priv;
>>> + int i = 0;
>>> + struct ath10k_target_stats *fw_stats;
>>> +
>>> + fw_stats = &ar->debug.target_stats;
>>> +
>>> + mutex_lock(&ar->conf_mutex);
>>> +
>>> + if (ar->state == ATH10K_STATE_ON)
>>> + ath10k_refresh_peer_stats(ar);
>>> +
>>> + mutex_unlock(&ar->conf_mutex);
>>
>> Just for correctness sake - it's probably a good idea to
>> mutex_unlock() at the end (i.e. after spin_unlock_bh()) to make sure
>> the stats are for this particular request. With your patch there's a
>> very slight chance that, e.g. fw_stats debug file is being read at the
>> same time and it updates fw stats between the above mutex_unlock() and
>> following spin_lock_bh().
>
> That makes no difference at all to the user though, and it is one less
> set of nested locks to worry about.
I still do not want to have known races, especially when it's so easy to
fix. The ethtool patches patches conflict with Michal's fw_stats fixes.
Let me take the ethtool patches so that I can rebase them, fix this race
and do some other small changes as well. I'll send v2 soon.
--
Kalle Valo
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 03/10] ath10k: support ethtool stats.
@ 2014-09-29 8:21 ` Kalle Valo
0 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-09-29 8:21 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, Michal Kazior, ath10k
Ben Greear <greearb@candelatech.com> writes:
> On 09/24/2014 12:44 AM, Michal Kazior wrote:
>> On 23 September 2014 23:17, <greearb@candelatech.com> wrote:
>> [...]
>>> +void ath10k_get_et_stats(struct ieee80211_hw *hw,
>>> + struct ieee80211_vif *vif,
>>> + struct ethtool_stats *stats, u64 *data)
>>> +{
>>> + struct ath10k *ar = hw->priv;
>>> + int i = 0;
>>> + struct ath10k_target_stats *fw_stats;
>>> +
>>> + fw_stats = &ar->debug.target_stats;
>>> +
>>> + mutex_lock(&ar->conf_mutex);
>>> +
>>> + if (ar->state == ATH10K_STATE_ON)
>>> + ath10k_refresh_peer_stats(ar);
>>> +
>>> + mutex_unlock(&ar->conf_mutex);
>>
>> Just for correctness sake - it's probably a good idea to
>> mutex_unlock() at the end (i.e. after spin_unlock_bh()) to make sure
>> the stats are for this particular request. With your patch there's a
>> very slight chance that, e.g. fw_stats debug file is being read at the
>> same time and it updates fw stats between the above mutex_unlock() and
>> following spin_lock_bh().
>
> That makes no difference at all to the user though, and it is one less
> set of nested locks to worry about.
I still do not want to have known races, especially when it's so easy to
fix. The ethtool patches patches conflict with Michal's fw_stats fixes.
Let me take the ethtool patches so that I can rebase them, fix this race
and do some other small changes as well. I'll send v2 soon.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 03/10] ath10k: support ethtool stats.
2014-09-29 8:21 ` Kalle Valo
@ 2014-09-29 16:07 ` Ben Greear
-1 siblings, 0 replies; 54+ messages in thread
From: Ben Greear @ 2014-09-29 16:07 UTC (permalink / raw)
To: Kalle Valo; +Cc: Michal Kazior, linux-wireless, ath10k
On 09/29/2014 01:21 AM, Kalle Valo wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/24/2014 12:44 AM, Michal Kazior wrote:
>>> On 23 September 2014 23:17, <greearb@candelatech.com> wrote:
>>> [...]
>>>> +void ath10k_get_et_stats(struct ieee80211_hw *hw,
>>>> + struct ieee80211_vif *vif,
>>>> + struct ethtool_stats *stats, u64 *data)
>>>> +{
>>>> + struct ath10k *ar = hw->priv;
>>>> + int i = 0;
>>>> + struct ath10k_target_stats *fw_stats;
>>>> +
>>>> + fw_stats = &ar->debug.target_stats;
>>>> +
>>>> + mutex_lock(&ar->conf_mutex);
>>>> +
>>>> + if (ar->state == ATH10K_STATE_ON)
>>>> + ath10k_refresh_peer_stats(ar);
>>>> +
>>>> + mutex_unlock(&ar->conf_mutex);
>>>
>>> Just for correctness sake - it's probably a good idea to
>>> mutex_unlock() at the end (i.e. after spin_unlock_bh()) to make sure
>>> the stats are for this particular request. With your patch there's a
>>> very slight chance that, e.g. fw_stats debug file is being read at the
>>> same time and it updates fw stats between the above mutex_unlock() and
>>> following spin_lock_bh().
>>
>> That makes no difference at all to the user though, and it is one less
>> set of nested locks to worry about.
>
> I still do not want to have known races, especially when it's so easy to
> fix. The ethtool patches patches conflict with Michal's fw_stats fixes.
> Let me take the ethtool patches so that I can rebase them, fix this race
> and do some other small changes as well. I'll send v2 soon.
Your v2 patches are fine with me.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 03/10] ath10k: support ethtool stats.
@ 2014-09-29 16:07 ` Ben Greear
0 siblings, 0 replies; 54+ messages in thread
From: Ben Greear @ 2014-09-29 16:07 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Michal Kazior, ath10k
On 09/29/2014 01:21 AM, Kalle Valo wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/24/2014 12:44 AM, Michal Kazior wrote:
>>> On 23 September 2014 23:17, <greearb@candelatech.com> wrote:
>>> [...]
>>>> +void ath10k_get_et_stats(struct ieee80211_hw *hw,
>>>> + struct ieee80211_vif *vif,
>>>> + struct ethtool_stats *stats, u64 *data)
>>>> +{
>>>> + struct ath10k *ar = hw->priv;
>>>> + int i = 0;
>>>> + struct ath10k_target_stats *fw_stats;
>>>> +
>>>> + fw_stats = &ar->debug.target_stats;
>>>> +
>>>> + mutex_lock(&ar->conf_mutex);
>>>> +
>>>> + if (ar->state == ATH10K_STATE_ON)
>>>> + ath10k_refresh_peer_stats(ar);
>>>> +
>>>> + mutex_unlock(&ar->conf_mutex);
>>>
>>> Just for correctness sake - it's probably a good idea to
>>> mutex_unlock() at the end (i.e. after spin_unlock_bh()) to make sure
>>> the stats are for this particular request. With your patch there's a
>>> very slight chance that, e.g. fw_stats debug file is being read at the
>>> same time and it updates fw stats between the above mutex_unlock() and
>>> following spin_lock_bh().
>>
>> That makes no difference at all to the user though, and it is one less
>> set of nested locks to worry about.
>
> I still do not want to have known races, especially when it's so easy to
> fix. The ethtool patches patches conflict with Michal's fw_stats fixes.
> Let me take the ethtool patches so that I can rebase them, fix this race
> and do some other small changes as well. I'll send v2 soon.
Your v2 patches are fine with me.
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] 54+ messages in thread
* [PATCH v2 04/10] ath10k: make firmware text debug messages more verbose.
2014-09-23 21:17 ` greearb
@ 2014-09-23 21:17 ` greearb
-1 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k, 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>
---
v2: Add and use a new debug-msg flag, change message
preamble slightly.
drivers/net/wireless/ath/ath10k/debug.h | 1 +
drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 39032e9..8c3b898 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -35,6 +35,7 @@ enum ath10k_debug_mask {
ATH10K_DBG_BMI = 0x00000400,
ATH10K_DBG_REGULATORY = 0x00000800,
ATH10K_DBG_TESTMODE = 0x00001000,
+ ATH10K_DBG_FW_MSG = 0x00002000,
ATH10K_DBG_ANY = 0xffffffff,
};
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index bfc1fb3..f1515c0 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2070,7 +2070,7 @@ static void ath10k_wmi_event_debug_print(struct ath10k *ar,
/* the last byte is always reserved for the null character */
buf[i] = '\0';
- ath10k_dbg(ar, ATH10K_DBG_WMI, "wmi event debug print '%s'\n", buf);
+ ath10k_dbg(ar, ATH10K_DBG_FW_MSG, "wmi firmware message '%s'\n", buf);
}
static void ath10k_wmi_event_pdev_qvit(struct ath10k *ar, struct sk_buff *skb)
--
1.7.11.7
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH v2 04/10] ath10k: make firmware text debug messages more verbose.
@ 2014-09-23 21:17 ` greearb
0 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear, ath10k
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>
---
v2: Add and use a new debug-msg flag, change message
preamble slightly.
drivers/net/wireless/ath/ath10k/debug.h | 1 +
drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 39032e9..8c3b898 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -35,6 +35,7 @@ enum ath10k_debug_mask {
ATH10K_DBG_BMI = 0x00000400,
ATH10K_DBG_REGULATORY = 0x00000800,
ATH10K_DBG_TESTMODE = 0x00001000,
+ ATH10K_DBG_FW_MSG = 0x00002000,
ATH10K_DBG_ANY = 0xffffffff,
};
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index bfc1fb3..f1515c0 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2070,7 +2070,7 @@ static void ath10k_wmi_event_debug_print(struct ath10k *ar,
/* the last byte is always reserved for the null character */
buf[i] = '\0';
- ath10k_dbg(ar, ATH10K_DBG_WMI, "wmi event debug print '%s'\n", buf);
+ ath10k_dbg(ar, ATH10K_DBG_FW_MSG, "wmi firmware message '%s'\n", buf);
}
static void ath10k_wmi_event_pdev_qvit(struct ath10k *ar, struct sk_buff *skb)
--
1.7.11.7
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [PATCH v2 04/10] ath10k: make firmware text debug messages more verbose.
2014-09-23 21:17 ` greearb
@ 2014-11-22 15:28 ` Kalle Valo
-1 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-11-22 15:28 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>
[...]
> --- a/drivers/net/wireless/ath/ath10k/debug.h
> +++ b/drivers/net/wireless/ath/ath10k/debug.h
> @@ -35,6 +35,7 @@ enum ath10k_debug_mask {
> ATH10K_DBG_BMI = 0x00000400,
> ATH10K_DBG_REGULATORY = 0x00000800,
> ATH10K_DBG_TESTMODE = 0x00001000,
> + ATH10K_DBG_FW_MSG = 0x00002000,
I think FW_MSG is a bit too ambiguous, so I changed this to WMI_PRINT so
that it's closer the real event name.
Full patch: https://github.com/kvalo/ath/commit/ce4269787f4b5e538731f34cb3a7358343efaa00
--
Kalle Valo
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 04/10] ath10k: make firmware text debug messages more verbose.
@ 2014-11-22 15:28 ` Kalle Valo
0 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-11-22 15:28 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>
[...]
> --- a/drivers/net/wireless/ath/ath10k/debug.h
> +++ b/drivers/net/wireless/ath/ath10k/debug.h
> @@ -35,6 +35,7 @@ enum ath10k_debug_mask {
> ATH10K_DBG_BMI = 0x00000400,
> ATH10K_DBG_REGULATORY = 0x00000800,
> ATH10K_DBG_TESTMODE = 0x00001000,
> + ATH10K_DBG_FW_MSG = 0x00002000,
I think FW_MSG is a bit too ambiguous, so I changed this to WMI_PRINT so
that it's closer the real event name.
Full patch: https://github.com/kvalo/ath/commit/ce4269787f4b5e538731f34cb3a7358343efaa00
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 04/10] ath10k: make firmware text debug messages more verbose.
2014-11-22 15:28 ` Kalle Valo
@ 2014-11-22 16:07 ` Ben Greear
-1 siblings, 0 replies; 54+ messages in thread
From: Ben Greear @ 2014-11-22 16:07 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, ath10k
On 11/22/2014 07:28 AM, Kalle Valo 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>
>
> [...]
>
>> --- a/drivers/net/wireless/ath/ath10k/debug.h
>> +++ b/drivers/net/wireless/ath/ath10k/debug.h
>> @@ -35,6 +35,7 @@ enum ath10k_debug_mask {
>> ATH10K_DBG_BMI = 0x00000400,
>> ATH10K_DBG_REGULATORY = 0x00000800,
>> ATH10K_DBG_TESTMODE = 0x00001000,
>> + ATH10K_DBG_FW_MSG = 0x00002000,
>
> I think FW_MSG is a bit too ambiguous, so I changed this to WMI_PRINT so
> that it's closer the real event name.
Better than nothing, but my idea was that this flag would be able to affect
more than one thing related to firmware debugging. Calling it something about
WMI does not indicate to me that it is really about firmware debugging.
Thanks,
Ben
> Full patch: https://github.com/kvalo/ath/commit/ce4269787f4b5e538731f34cb3a7358343efaa00
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 04/10] ath10k: make firmware text debug messages more verbose.
@ 2014-11-22 16:07 ` Ben Greear
0 siblings, 0 replies; 54+ messages in thread
From: Ben Greear @ 2014-11-22 16:07 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, ath10k
On 11/22/2014 07:28 AM, Kalle Valo 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>
>
> [...]
>
>> --- a/drivers/net/wireless/ath/ath10k/debug.h
>> +++ b/drivers/net/wireless/ath/ath10k/debug.h
>> @@ -35,6 +35,7 @@ enum ath10k_debug_mask {
>> ATH10K_DBG_BMI = 0x00000400,
>> ATH10K_DBG_REGULATORY = 0x00000800,
>> ATH10K_DBG_TESTMODE = 0x00001000,
>> + ATH10K_DBG_FW_MSG = 0x00002000,
>
> I think FW_MSG is a bit too ambiguous, so I changed this to WMI_PRINT so
> that it's closer the real event name.
Better than nothing, but my idea was that this flag would be able to affect
more than one thing related to firmware debugging. Calling it something about
WMI does not indicate to me that it is really about firmware debugging.
Thanks,
Ben
> Full patch: https://github.com/kvalo/ath/commit/ce4269787f4b5e538731f34cb3a7358343efaa00
>
--
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] 54+ messages in thread* Re: [PATCH v2 04/10] ath10k: make firmware text debug messages more verbose.
2014-11-22 16:07 ` Ben Greear
@ 2014-11-24 15:18 ` Kalle Valo
-1 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-11-24 15:18 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k
Ben Greear <greearb@candelatech.com> writes:
> On 11/22/2014 07:28 AM, Kalle Valo 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>
>>
>> [...]
>>
>>> --- a/drivers/net/wireless/ath/ath10k/debug.h
>>> +++ b/drivers/net/wireless/ath/ath10k/debug.h
>>> @@ -35,6 +35,7 @@ enum ath10k_debug_mask {
>>> ATH10K_DBG_BMI = 0x00000400,
>>> ATH10K_DBG_REGULATORY = 0x00000800,
>>> ATH10K_DBG_TESTMODE = 0x00001000,
>>> + ATH10K_DBG_FW_MSG = 0x00002000,
>>
>> I think FW_MSG is a bit too ambiguous, so I changed this to WMI_PRINT so
>> that it's closer the real event name.
>
> Better than nothing, but my idea was that this flag would be able to affect
> more than one thing related to firmware debugging. Calling it something about
> WMI does not indicate to me that it is really about firmware debugging.
For other debug methods we can always add a new debug level, or rename
this one.
--
Kalle Valo
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 04/10] ath10k: make firmware text debug messages more verbose.
@ 2014-11-24 15:18 ` Kalle Valo
0 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-11-24 15:18 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k
Ben Greear <greearb@candelatech.com> writes:
> On 11/22/2014 07:28 AM, Kalle Valo 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>
>>
>> [...]
>>
>>> --- a/drivers/net/wireless/ath/ath10k/debug.h
>>> +++ b/drivers/net/wireless/ath/ath10k/debug.h
>>> @@ -35,6 +35,7 @@ enum ath10k_debug_mask {
>>> ATH10K_DBG_BMI = 0x00000400,
>>> ATH10K_DBG_REGULATORY = 0x00000800,
>>> ATH10K_DBG_TESTMODE = 0x00001000,
>>> + ATH10K_DBG_FW_MSG = 0x00002000,
>>
>> I think FW_MSG is a bit too ambiguous, so I changed this to WMI_PRINT so
>> that it's closer the real event name.
>
> Better than nothing, but my idea was that this flag would be able to affect
> more than one thing related to firmware debugging. Calling it something about
> WMI does not indicate to me that it is really about firmware debugging.
For other debug methods we can always add a new debug level, or rename
this one.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 04/10] ath10k: make firmware text debug messages more verbose.
2014-09-23 21:17 ` greearb
@ 2014-11-24 14:19 ` Kalle Valo
-1 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-11-24 14:19 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>
Thanks, applied. Though I did change the commit log:
commit 3be004c3aa4341c7c2461b37612a3a7a3323579d
Author: Ben Greear <greearb@candelatech.com>
Date: Tue Sep 23 14:17:19 2014 -0700
ath10k: add ATH10K_DBG_WMI_PRINT debug level
There are not many of these messages producted by the
firmware, but they are generally fairly useful, so make it easy to print them
with a separate debug level.
kvalo: fix commit log, rename debug level
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
--
Kalle Valo
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 04/10] ath10k: make firmware text debug messages more verbose.
@ 2014-11-24 14:19 ` Kalle Valo
0 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-11-24 14:19 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>
Thanks, applied. Though I did change the commit log:
commit 3be004c3aa4341c7c2461b37612a3a7a3323579d
Author: Ben Greear <greearb@candelatech.com>
Date: Tue Sep 23 14:17:19 2014 -0700
ath10k: add ATH10K_DBG_WMI_PRINT debug level
There are not many of these messages producted by the
firmware, but they are generally fairly useful, so make it easy to print them
with a separate debug level.
kvalo: fix commit log, rename debug level
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH v2 05/10] ath10k: apply chainmask settings to vdev on creation.
2014-09-23 21:17 ` greearb
@ 2014-09-23 21:17 ` greearb
-1 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k, Ben Greear
From: Ben Greear <greearb@candelatech.com>
It appears it takes more than just setting the
hardware's chainmask to make things work well. Without
this patch, a vdev would only use 1x1 rates when chainmask
was set to 0x3.
Setting the 'nss' (number of spatial streams) on the vdev
helps the firmware's rate-control algorithm work properly.
Tested on CT firmware, but probably this works (and
is required) on normal firmware.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v2: Add warning if chainmask is set to probably-invalid configuration.
Also, from a quick test, it appears you cannot even set the chainmask
using 'iw' when vdevs are active.
drivers/net/wireless/ath/ath10k/mac.c | 40 +++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 4bb3ef6..e75607d 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2427,12 +2427,27 @@ static int ath10k_get_antenna(struct ieee80211_hw *hw, u32 *tx_ant, u32 *rx_ant)
return 0;
}
+static void ath10k_check_chain_mask(struct ath10k *ar, u32 cm, const char* dbg)
+{
+ /* It is not clear that allowing gaps in chainmask
+ * is helpful. Probably it will not do what user
+ * is hoping for, so warn in that case.
+ */
+ if (cm == 15 || cm == 7 || cm == 3 || cm == 1 || cm == 0)
+ return;
+ ath10k_warn(ar, "mac %s antenna chainmask may be invalid: 0x%x. Suggested values: 15, 7, 3, 1 or 0.\n",
+ dbg, cm);
+}
+
static int __ath10k_set_antenna(struct ath10k *ar, u32 tx_ant, u32 rx_ant)
{
int ret;
lockdep_assert_held(&ar->conf_mutex);
+ ath10k_check_chain_mask(ar, tx_ant, "tx");
+ ath10k_check_chain_mask(ar, rx_ant, "rx");
+
ar->cfg_tx_chainmask = tx_ant;
ar->cfg_rx_chainmask = rx_ant;
@@ -2758,6 +2773,17 @@ static int ath10k_config(struct ieee80211_hw *hw, u32 changed)
return ret;
}
+static u32 get_nss_from_chainmask(u16 chain_mask)
+{
+ if ((chain_mask & 0x15) == 0x15)
+ return 4;
+ else if ((chain_mask & 0x7) == 0x7)
+ return 3;
+ else if ((chain_mask & 0x3) == 0x3)
+ return 2;
+ return 1;
+}
+
/*
* TODO:
* Figure out how to handle WMI_VDEV_SUBTYPE_P2P_DEVICE,
@@ -2890,6 +2916,20 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
goto err_vdev_delete;
}
+ if (ar->cfg_tx_chainmask) {
+ u16 nss = get_nss_from_chainmask(ar->cfg_tx_chainmask);
+
+ vdev_param = ar->wmi.vdev_param->nss;
+ ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
+ nss);
+ if (ret) {
+ ath10k_warn(ar, "failed to set vdev %i chainmask 0x%x, nss %i: %d\n",
+ arvif->vdev_id, ar->cfg_tx_chainmask, nss,
+ ret);
+ goto err_vdev_delete;
+ }
+ }
+
if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
ret = ath10k_peer_create(ar, arvif->vdev_id, vif->addr);
if (ret) {
--
1.7.11.7
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH v2 05/10] ath10k: apply chainmask settings to vdev on creation.
@ 2014-09-23 21:17 ` greearb
0 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear, ath10k
From: Ben Greear <greearb@candelatech.com>
It appears it takes more than just setting the
hardware's chainmask to make things work well. Without
this patch, a vdev would only use 1x1 rates when chainmask
was set to 0x3.
Setting the 'nss' (number of spatial streams) on the vdev
helps the firmware's rate-control algorithm work properly.
Tested on CT firmware, but probably this works (and
is required) on normal firmware.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v2: Add warning if chainmask is set to probably-invalid configuration.
Also, from a quick test, it appears you cannot even set the chainmask
using 'iw' when vdevs are active.
drivers/net/wireless/ath/ath10k/mac.c | 40 +++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 4bb3ef6..e75607d 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2427,12 +2427,27 @@ static int ath10k_get_antenna(struct ieee80211_hw *hw, u32 *tx_ant, u32 *rx_ant)
return 0;
}
+static void ath10k_check_chain_mask(struct ath10k *ar, u32 cm, const char* dbg)
+{
+ /* It is not clear that allowing gaps in chainmask
+ * is helpful. Probably it will not do what user
+ * is hoping for, so warn in that case.
+ */
+ if (cm == 15 || cm == 7 || cm == 3 || cm == 1 || cm == 0)
+ return;
+ ath10k_warn(ar, "mac %s antenna chainmask may be invalid: 0x%x. Suggested values: 15, 7, 3, 1 or 0.\n",
+ dbg, cm);
+}
+
static int __ath10k_set_antenna(struct ath10k *ar, u32 tx_ant, u32 rx_ant)
{
int ret;
lockdep_assert_held(&ar->conf_mutex);
+ ath10k_check_chain_mask(ar, tx_ant, "tx");
+ ath10k_check_chain_mask(ar, rx_ant, "rx");
+
ar->cfg_tx_chainmask = tx_ant;
ar->cfg_rx_chainmask = rx_ant;
@@ -2758,6 +2773,17 @@ static int ath10k_config(struct ieee80211_hw *hw, u32 changed)
return ret;
}
+static u32 get_nss_from_chainmask(u16 chain_mask)
+{
+ if ((chain_mask & 0x15) == 0x15)
+ return 4;
+ else if ((chain_mask & 0x7) == 0x7)
+ return 3;
+ else if ((chain_mask & 0x3) == 0x3)
+ return 2;
+ return 1;
+}
+
/*
* TODO:
* Figure out how to handle WMI_VDEV_SUBTYPE_P2P_DEVICE,
@@ -2890,6 +2916,20 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
goto err_vdev_delete;
}
+ if (ar->cfg_tx_chainmask) {
+ u16 nss = get_nss_from_chainmask(ar->cfg_tx_chainmask);
+
+ vdev_param = ar->wmi.vdev_param->nss;
+ ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
+ nss);
+ if (ret) {
+ ath10k_warn(ar, "failed to set vdev %i chainmask 0x%x, nss %i: %d\n",
+ arvif->vdev_id, ar->cfg_tx_chainmask, nss,
+ ret);
+ goto err_vdev_delete;
+ }
+ }
+
if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
ret = ath10k_peer_create(ar, arvif->vdev_id, vif->addr);
if (ret) {
--
1.7.11.7
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [PATCH v2 05/10] ath10k: apply chainmask settings to vdev on creation.
2014-09-23 21:17 ` greearb
@ 2014-11-26 6:25 ` Kalle Valo
-1 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-11-26 6:25 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath10k
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> It appears it takes more than just setting the
> hardware's chainmask to make things work well. Without
> this patch, a vdev would only use 1x1 rates when chainmask
> was set to 0x3.
>
> Setting the 'nss' (number of spatial streams) on the vdev
> helps the firmware's rate-control algorithm work properly.
>
> Tested on CT firmware, but probably this works (and
> is required) on normal firmware.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
>
> v2: Add warning if chainmask is set to probably-invalid configuration.
> Also, from a quick test, it appears you cannot even set the chainmask
> using 'iw' when vdevs are active.
Thanks, applied.
--
Kalle Valo
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 05/10] ath10k: apply chainmask settings to vdev on creation.
@ 2014-11-26 6:25 ` Kalle Valo
0 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-11-26 6:25 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath10k
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> It appears it takes more than just setting the
> hardware's chainmask to make things work well. Without
> this patch, a vdev would only use 1x1 rates when chainmask
> was set to 0x3.
>
> Setting the 'nss' (number of spatial streams) on the vdev
> helps the firmware's rate-control algorithm work properly.
>
> Tested on CT firmware, but probably this works (and
> is required) on normal firmware.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
>
> v2: Add warning if chainmask is set to probably-invalid configuration.
> Also, from a quick test, it appears you cannot even set the chainmask
> using 'iw' when vdevs are active.
Thanks, applied.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH v2 06/10] ath10k: use configured nss instead of max nss.
2014-09-23 21:17 ` greearb
@ 2014-09-23 21:17 ` greearb
-1 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k, Ben Greear
From: Ben Greear <greearb@candelatech.com>
When re-associating a station, the nss was set back to
maximum value even if user had configured small number
of tx chains. So, pay attention to user's config in
this case as well.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v2: No changes from v1.
drivers/net/wireless/ath/ath10k/mac.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index e75607d..34ec992 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4114,6 +4114,10 @@ ath10k_default_bitrate_mask(struct ath10k *ar,
u32 legacy = 0x00ff;
u8 ht = 0xff, i;
u16 vht = 0x3ff;
+ u16 nrf = ar->num_rf_chains;
+
+ if (ar->cfg_tx_chainmask)
+ nrf = get_nss_from_chainmask(ar->cfg_tx_chainmask);
switch (band) {
case IEEE80211_BAND_2GHZ:
@@ -4129,11 +4133,11 @@ ath10k_default_bitrate_mask(struct ath10k *ar,
if (mask->control[band].legacy != legacy)
return false;
- for (i = 0; i < ar->num_rf_chains; i++)
+ for (i = 0; i < nrf; i++)
if (mask->control[band].ht_mcs[i] != ht)
return false;
- for (i = 0; i < ar->num_rf_chains; i++)
+ for (i = 0; i < nrf; i++)
if (mask->control[band].vht_mcs[i] != vht)
return false;
@@ -4384,6 +4388,9 @@ static int ath10k_set_bitrate_mask(struct ieee80211_hw *hw,
u8 fixed_nss = ar->num_rf_chains;
u8 force_sgi;
+ if (ar->cfg_tx_chainmask)
+ fixed_nss = get_nss_from_chainmask(ar->cfg_tx_chainmask);
+
force_sgi = mask->control[band].gi;
if (force_sgi == NL80211_TXRATE_FORCE_LGI)
return -EINVAL;
--
1.7.11.7
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH v2 06/10] ath10k: use configured nss instead of max nss.
@ 2014-09-23 21:17 ` greearb
0 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear, ath10k
From: Ben Greear <greearb@candelatech.com>
When re-associating a station, the nss was set back to
maximum value even if user had configured small number
of tx chains. So, pay attention to user's config in
this case as well.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v2: No changes from v1.
drivers/net/wireless/ath/ath10k/mac.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index e75607d..34ec992 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4114,6 +4114,10 @@ ath10k_default_bitrate_mask(struct ath10k *ar,
u32 legacy = 0x00ff;
u8 ht = 0xff, i;
u16 vht = 0x3ff;
+ u16 nrf = ar->num_rf_chains;
+
+ if (ar->cfg_tx_chainmask)
+ nrf = get_nss_from_chainmask(ar->cfg_tx_chainmask);
switch (band) {
case IEEE80211_BAND_2GHZ:
@@ -4129,11 +4133,11 @@ ath10k_default_bitrate_mask(struct ath10k *ar,
if (mask->control[band].legacy != legacy)
return false;
- for (i = 0; i < ar->num_rf_chains; i++)
+ for (i = 0; i < nrf; i++)
if (mask->control[band].ht_mcs[i] != ht)
return false;
- for (i = 0; i < ar->num_rf_chains; i++)
+ for (i = 0; i < nrf; i++)
if (mask->control[band].vht_mcs[i] != vht)
return false;
@@ -4384,6 +4388,9 @@ static int ath10k_set_bitrate_mask(struct ieee80211_hw *hw,
u8 fixed_nss = ar->num_rf_chains;
u8 force_sgi;
+ if (ar->cfg_tx_chainmask)
+ fixed_nss = get_nss_from_chainmask(ar->cfg_tx_chainmask);
+
force_sgi = mask->control[band].gi;
if (force_sgi == NL80211_TXRATE_FORCE_LGI)
return -EINVAL;
--
1.7.11.7
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [PATCH v2 06/10] ath10k: use configured nss instead of max nss.
2014-09-23 21:17 ` greearb
@ 2014-11-04 19:55 ` Ben Greear
-1 siblings, 0 replies; 54+ messages in thread
From: Ben Greear @ 2014-11-04 19:55 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
On 09/23/2014 02:17 PM, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> When re-associating a station, the nss was set back to
> maximum value even if user had configured small number
> of tx chains. So, pay attention to user's config in
> this case as well.
Looks like this (and probably the related patch) did not make
it upstream yet.
Is someone waiting for more changes from me or did this just
get lost?
Thanks,
Ben
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
>
> v2: No changes from v1.
>
> drivers/net/wireless/ath/ath10k/mac.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index e75607d..34ec992 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -4114,6 +4114,10 @@ ath10k_default_bitrate_mask(struct ath10k *ar,
> u32 legacy = 0x00ff;
> u8 ht = 0xff, i;
> u16 vht = 0x3ff;
> + u16 nrf = ar->num_rf_chains;
> +
> + if (ar->cfg_tx_chainmask)
> + nrf = get_nss_from_chainmask(ar->cfg_tx_chainmask);
>
> switch (band) {
> case IEEE80211_BAND_2GHZ:
> @@ -4129,11 +4133,11 @@ ath10k_default_bitrate_mask(struct ath10k *ar,
> if (mask->control[band].legacy != legacy)
> return false;
>
> - for (i = 0; i < ar->num_rf_chains; i++)
> + for (i = 0; i < nrf; i++)
> if (mask->control[band].ht_mcs[i] != ht)
> return false;
>
> - for (i = 0; i < ar->num_rf_chains; i++)
> + for (i = 0; i < nrf; i++)
> if (mask->control[band].vht_mcs[i] != vht)
> return false;
>
> @@ -4384,6 +4388,9 @@ static int ath10k_set_bitrate_mask(struct ieee80211_hw *hw,
> u8 fixed_nss = ar->num_rf_chains;
> u8 force_sgi;
>
> + if (ar->cfg_tx_chainmask)
> + fixed_nss = get_nss_from_chainmask(ar->cfg_tx_chainmask);
> +
> force_sgi = mask->control[band].gi;
> if (force_sgi == NL80211_TXRATE_FORCE_LGI)
> return -EINVAL;
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 06/10] ath10k: use configured nss instead of max nss.
@ 2014-11-04 19:55 ` Ben Greear
0 siblings, 0 replies; 54+ messages in thread
From: Ben Greear @ 2014-11-04 19:55 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
On 09/23/2014 02:17 PM, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> When re-associating a station, the nss was set back to
> maximum value even if user had configured small number
> of tx chains. So, pay attention to user's config in
> this case as well.
Looks like this (and probably the related patch) did not make
it upstream yet.
Is someone waiting for more changes from me or did this just
get lost?
Thanks,
Ben
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
>
> v2: No changes from v1.
>
> drivers/net/wireless/ath/ath10k/mac.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index e75607d..34ec992 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -4114,6 +4114,10 @@ ath10k_default_bitrate_mask(struct ath10k *ar,
> u32 legacy = 0x00ff;
> u8 ht = 0xff, i;
> u16 vht = 0x3ff;
> + u16 nrf = ar->num_rf_chains;
> +
> + if (ar->cfg_tx_chainmask)
> + nrf = get_nss_from_chainmask(ar->cfg_tx_chainmask);
>
> switch (band) {
> case IEEE80211_BAND_2GHZ:
> @@ -4129,11 +4133,11 @@ ath10k_default_bitrate_mask(struct ath10k *ar,
> if (mask->control[band].legacy != legacy)
> return false;
>
> - for (i = 0; i < ar->num_rf_chains; i++)
> + for (i = 0; i < nrf; i++)
> if (mask->control[band].ht_mcs[i] != ht)
> return false;
>
> - for (i = 0; i < ar->num_rf_chains; i++)
> + for (i = 0; i < nrf; i++)
> if (mask->control[band].vht_mcs[i] != vht)
> return false;
>
> @@ -4384,6 +4388,9 @@ static int ath10k_set_bitrate_mask(struct ieee80211_hw *hw,
> u8 fixed_nss = ar->num_rf_chains;
> u8 force_sgi;
>
> + if (ar->cfg_tx_chainmask)
> + fixed_nss = get_nss_from_chainmask(ar->cfg_tx_chainmask);
> +
> force_sgi = mask->control[band].gi;
> if (force_sgi == NL80211_TXRATE_FORCE_LGI)
> return -EINVAL;
>
--
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] 54+ messages in thread* Re: [PATCH v2 06/10] ath10k: use configured nss instead of max nss.
2014-11-04 19:55 ` Ben Greear
@ 2014-11-13 13:22 ` Kalle Valo
-1 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-11-13 13:22 UTC (permalink / raw)
To: Ben Greear; +Cc: ath10k, linux-wireless
Ben Greear <greearb@candelatech.com> writes:
> On 09/23/2014 02:17 PM, greearb@candelatech.com wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> When re-associating a station, the nss was set back to
>> maximum value even if user had configured small number
>> of tx chains. So, pay attention to user's config in
>> this case as well.
>
> Looks like this (and probably the related patch) did not make
> it upstream yet.
>
> Is someone waiting for more changes from me or did this just
> get lost?
Sorry, it fell through the cracks. I'll take a look at them soon.
--
Kalle Valo
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 06/10] ath10k: use configured nss instead of max nss.
@ 2014-11-13 13:22 ` Kalle Valo
0 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-11-13 13:22 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, ath10k
Ben Greear <greearb@candelatech.com> writes:
> On 09/23/2014 02:17 PM, greearb@candelatech.com wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> When re-associating a station, the nss was set back to
>> maximum value even if user had configured small number
>> of tx chains. So, pay attention to user's config in
>> this case as well.
>
> Looks like this (and probably the related patch) did not make
> it upstream yet.
>
> Is someone waiting for more changes from me or did this just
> get lost?
Sorry, it fell through the cracks. I'll take a look at them soon.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 06/10] ath10k: use configured nss instead of max nss.
2014-09-23 21:17 ` greearb
@ 2014-11-26 6:26 ` Kalle Valo
-1 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-11-26 6:26 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath10k
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> When re-associating a station, the nss was set back to
> maximum value even if user had configured small number
> of tx chains. So, pay attention to user's config in
> this case as well.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
Thanks, applied.
--
Kalle Valo
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 06/10] ath10k: use configured nss instead of max nss.
@ 2014-11-26 6:26 ` Kalle Valo
0 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-11-26 6:26 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath10k
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> When re-associating a station, the nss was set back to
> maximum value even if user had configured small number
> of tx chains. So, pay attention to user's config in
> this case as well.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
Thanks, applied.
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH v2 07/10] ath10k: add fw-powerup-fail to ethtool stats.
2014-09-23 21:17 ` greearb
@ 2014-09-23 21:17 ` greearb
-1 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k, 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>
---
v2: New patch for this series, goes well with the other
ethtool patch.
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath10k/debug.c | 2 ++
drivers/net/wireless/ath/ath10k/pci.c | 12 +++++++++---
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 7b220b1..601d573 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -399,7 +399,7 @@ struct ath10k {
struct ieee80211_hw *hw;
struct device *dev;
u8 mac_addr[ETH_ALEN];
-
+ 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 af1ca3e..77b60f4 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1091,6 +1091,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)
@@ -1175,6 +1176,7 @@ void ath10k_get_et_stats(struct ieee80211_hw *hw,
data[i++] = ar->fw_crash_counter;
data[i++] = ar->fw_warm_reset_counter;
data[i++] = ar->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 38f7386..ebe2ee1 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1851,7 +1851,7 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
ret);
if (ath10k_pci_reset_mode == ATH10K_PCI_RESET_WARM_ONLY)
- return ret;
+ goto out;
ath10k_warn(ar, "trying cold reset\n");
@@ -1859,11 +1859,17 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
if (ret) {
ath10k_err(ar, "failed to power up target using cold reset too (%d)\n",
ret);
- return ret;
+ goto out;
}
}
- return 0;
+out:
+ /* If we have failed to power-up, it may take a reboot to
+ * get the NIC back online.
+ * Set flag accordinly so that user-space can know.
+ */
+ ar->fw_powerup_failed = !!ret;
+ return ret;
}
static void ath10k_pci_hif_power_down(struct ath10k *ar)
--
1.7.11.7
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH v2 07/10] ath10k: add fw-powerup-fail to ethtool stats.
@ 2014-09-23 21:17 ` greearb
0 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear, ath10k
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>
---
v2: New patch for this series, goes well with the other
ethtool patch.
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath10k/debug.c | 2 ++
drivers/net/wireless/ath/ath10k/pci.c | 12 +++++++++---
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 7b220b1..601d573 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -399,7 +399,7 @@ struct ath10k {
struct ieee80211_hw *hw;
struct device *dev;
u8 mac_addr[ETH_ALEN];
-
+ 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 af1ca3e..77b60f4 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1091,6 +1091,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)
@@ -1175,6 +1176,7 @@ void ath10k_get_et_stats(struct ieee80211_hw *hw,
data[i++] = ar->fw_crash_counter;
data[i++] = ar->fw_warm_reset_counter;
data[i++] = ar->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 38f7386..ebe2ee1 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1851,7 +1851,7 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
ret);
if (ath10k_pci_reset_mode == ATH10K_PCI_RESET_WARM_ONLY)
- return ret;
+ goto out;
ath10k_warn(ar, "trying cold reset\n");
@@ -1859,11 +1859,17 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
if (ret) {
ath10k_err(ar, "failed to power up target using cold reset too (%d)\n",
ret);
- return ret;
+ goto out;
}
}
- return 0;
+out:
+ /* If we have failed to power-up, it may take a reboot to
+ * get the NIC back online.
+ * Set flag accordinly so that user-space can know.
+ */
+ ar->fw_powerup_failed = !!ret;
+ return ret;
}
static void ath10k_pci_hif_power_down(struct ath10k *ar)
--
1.7.11.7
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 54+ messages in thread* Re: [PATCH v2 07/10] ath10k: add fw-powerup-fail to ethtool stats.
2014-09-23 21:17 ` greearb
@ 2014-09-29 8:24 ` Kalle Valo
-1 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-09-29 8:24 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>
[...]
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -1851,7 +1851,7 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
> ret);
>
> if (ath10k_pci_reset_mode == ATH10K_PCI_RESET_WARM_ONLY)
> - return ret;
> + goto out;
>
> ath10k_warn(ar, "trying cold reset\n");
>
> @@ -1859,11 +1859,17 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
> if (ret) {
> ath10k_err(ar, "failed to power up target using cold reset too (%d)\n",
> ret);
> - return ret;
> + goto out;
> }
> }
>
> - return 0;
> +out:
> + /* If we have failed to power-up, it may take a reboot to
> + * get the NIC back online.
> + * Set flag accordinly so that user-space can know.
> + */
> + ar->fw_powerup_failed = !!ret;
> + return ret;
> }
Would it be better to use ATH10K_STATE_WEDGED for this and then just
export the state value to user space? Or should we have two different
states, like FW_WEDGED and HW_WEDGED?
--
Kalle Valo
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 07/10] ath10k: add fw-powerup-fail to ethtool stats.
@ 2014-09-29 8:24 ` Kalle Valo
0 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-09-29 8:24 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>
[...]
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -1851,7 +1851,7 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
> ret);
>
> if (ath10k_pci_reset_mode == ATH10K_PCI_RESET_WARM_ONLY)
> - return ret;
> + goto out;
>
> ath10k_warn(ar, "trying cold reset\n");
>
> @@ -1859,11 +1859,17 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
> if (ret) {
> ath10k_err(ar, "failed to power up target using cold reset too (%d)\n",
> ret);
> - return ret;
> + goto out;
> }
> }
>
> - return 0;
> +out:
> + /* If we have failed to power-up, it may take a reboot to
> + * get the NIC back online.
> + * Set flag accordinly so that user-space can know.
> + */
> + ar->fw_powerup_failed = !!ret;
> + return ret;
> }
Would it be better to use ATH10K_STATE_WEDGED for this and then just
export the state value to user space? Or should we have two different
states, like FW_WEDGED and HW_WEDGED?
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 07/10] ath10k: add fw-powerup-fail to ethtool stats.
2014-09-29 8:24 ` Kalle Valo
@ 2014-09-29 16:05 ` Ben Greear
-1 siblings, 0 replies; 54+ messages in thread
From: Ben Greear @ 2014-09-29 16:05 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, ath10k
On 09/29/2014 01:24 AM, Kalle Valo 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>
>
> [...]
>
>> --- a/drivers/net/wireless/ath/ath10k/pci.c
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c
>> @@ -1851,7 +1851,7 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
>> ret);
>>
>> if (ath10k_pci_reset_mode == ATH10K_PCI_RESET_WARM_ONLY)
>> - return ret;
>> + goto out;
>>
>> ath10k_warn(ar, "trying cold reset\n");
>>
>> @@ -1859,11 +1859,17 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
>> if (ret) {
>> ath10k_err(ar, "failed to power up target using cold reset too (%d)\n",
>> ret);
>> - return ret;
>> + goto out;
>> }
>> }
>>
>> - return 0;
>> +out:
>> + /* If we have failed to power-up, it may take a reboot to
>> + * get the NIC back online.
>> + * Set flag accordinly so that user-space can know.
>> + */
>> + ar->fw_powerup_failed = !!ret;
>> + return ret;
>> }
>
> Would it be better to use ATH10K_STATE_WEDGED for this and then just
> export the state value to user space? Or should we have two different
> states, like FW_WEDGED and HW_WEDGED?
I didn't want to mess with the state machine. This counter
is just a clue to users that things might be badly wrong. Some systems
might recover with another hard reset, some will hang the entire
system hard, and some will just stick in this state unable to
recover. Some of my systems exhibit this last behaviour, so at
least with this patch I can warn the user that they need to
reboot to regain wifi functionality.
If you want to tie it to a state machine, that is OK with me, but
I don't want to mess with it because that code is already tricky
enough.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 54+ messages in thread* Re: [PATCH v2 07/10] ath10k: add fw-powerup-fail to ethtool stats.
@ 2014-09-29 16:05 ` Ben Greear
0 siblings, 0 replies; 54+ messages in thread
From: Ben Greear @ 2014-09-29 16:05 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, ath10k
On 09/29/2014 01:24 AM, Kalle Valo 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>
>
> [...]
>
>> --- a/drivers/net/wireless/ath/ath10k/pci.c
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c
>> @@ -1851,7 +1851,7 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
>> ret);
>>
>> if (ath10k_pci_reset_mode == ATH10K_PCI_RESET_WARM_ONLY)
>> - return ret;
>> + goto out;
>>
>> ath10k_warn(ar, "trying cold reset\n");
>>
>> @@ -1859,11 +1859,17 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
>> if (ret) {
>> ath10k_err(ar, "failed to power up target using cold reset too (%d)\n",
>> ret);
>> - return ret;
>> + goto out;
>> }
>> }
>>
>> - return 0;
>> +out:
>> + /* If we have failed to power-up, it may take a reboot to
>> + * get the NIC back online.
>> + * Set flag accordinly so that user-space can know.
>> + */
>> + ar->fw_powerup_failed = !!ret;
>> + return ret;
>> }
>
> Would it be better to use ATH10K_STATE_WEDGED for this and then just
> export the state value to user space? Or should we have two different
> states, like FW_WEDGED and HW_WEDGED?
I didn't want to mess with the state machine. This counter
is just a clue to users that things might be badly wrong. Some systems
might recover with another hard reset, some will hang the entire
system hard, and some will just stick in this state unable to
recover. Some of my systems exhibit this last behaviour, so at
least with this patch I can warn the user that they need to
reboot to regain wifi functionality.
If you want to tie it to a state machine, that is OK with me, but
I don't want to mess with it because that code is already tricky
enough.
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] 54+ messages in thread* Re: [PATCH v2 07/10] ath10k: add fw-powerup-fail to ethtool stats.
2014-09-29 16:05 ` Ben Greear
@ 2014-09-30 12:27 ` Michal Kazior
-1 siblings, 0 replies; 54+ messages in thread
From: Michal Kazior @ 2014-09-30 12:27 UTC (permalink / raw)
To: Ben Greear; +Cc: Kalle Valo, linux-wireless, ath10k
On 29 September 2014 18:05, Ben Greear <greearb@candelatech.com> wrote:
> On 09/29/2014 01:24 AM, Kalle Valo 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>
[...]
>>> - return 0;
>>> +out:
>>> + /* If we have failed to power-up, it may take a reboot to
>>> + * get the NIC back online.
>>> + * Set flag accordinly so that user-space can know.
>>> + */
>>> + ar->fw_powerup_failed = !!ret;
>>> + return ret;
>>> }
>>
>> Would it be better to use ATH10K_STATE_WEDGED for this and then just
>> export the state value to user space? Or should we have two different
>> states, like FW_WEDGED and HW_WEDGED?
Current WEDGED state is more like ON. It assumes mac80211 will call
ath10k_stop().
Adding another state just for the sake of handling power up / reset
issues seems like an overkill to me.
> I didn't want to mess with the state machine. This counter
> is just a clue to users that things might be badly wrong. Some systems
> might recover with another hard reset, some will hang the entire
> system hard, and some will just stick in this state unable to
> recover. Some of my systems exhibit this last behaviour, so at
> least with this patch I can warn the user that they need to
> reboot to regain wifi functionality.
If power up fails the error should propagate to `ifconfig wlanX up`
(or whatever calling drv_start) eventually so I don't see the point in
having this counter.
Michał
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 07/10] ath10k: add fw-powerup-fail to ethtool stats.
@ 2014-09-30 12:27 ` Michal Kazior
0 siblings, 0 replies; 54+ messages in thread
From: Michal Kazior @ 2014-09-30 12:27 UTC (permalink / raw)
To: Ben Greear; +Cc: Kalle Valo, linux-wireless, ath10k
On 29 September 2014 18:05, Ben Greear <greearb@candelatech.com> wrote:
> On 09/29/2014 01:24 AM, Kalle Valo 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>
[...]
>>> - return 0;
>>> +out:
>>> + /* If we have failed to power-up, it may take a reboot to
>>> + * get the NIC back online.
>>> + * Set flag accordinly so that user-space can know.
>>> + */
>>> + ar->fw_powerup_failed = !!ret;
>>> + return ret;
>>> }
>>
>> Would it be better to use ATH10K_STATE_WEDGED for this and then just
>> export the state value to user space? Or should we have two different
>> states, like FW_WEDGED and HW_WEDGED?
Current WEDGED state is more like ON. It assumes mac80211 will call
ath10k_stop().
Adding another state just for the sake of handling power up / reset
issues seems like an overkill to me.
> I didn't want to mess with the state machine. This counter
> is just a clue to users that things might be badly wrong. Some systems
> might recover with another hard reset, some will hang the entire
> system hard, and some will just stick in this state unable to
> recover. Some of my systems exhibit this last behaviour, so at
> least with this patch I can warn the user that they need to
> reboot to regain wifi functionality.
If power up fails the error should propagate to `ifconfig wlanX up`
(or whatever calling drv_start) eventually so I don't see the point in
having this counter.
Michał
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 07/10] ath10k: add fw-powerup-fail to ethtool stats.
2014-09-30 12:27 ` Michal Kazior
@ 2014-09-30 15:53 ` Ben Greear
-1 siblings, 0 replies; 54+ messages in thread
From: Ben Greear @ 2014-09-30 15:53 UTC (permalink / raw)
To: Michal Kazior; +Cc: Kalle Valo, linux-wireless, ath10k
On 09/30/2014 05:27 AM, Michal Kazior wrote:
> On 29 September 2014 18:05, Ben Greear <greearb@candelatech.com> wrote:
>> On 09/29/2014 01:24 AM, Kalle Valo 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>
> [...]
>>>> - return 0;
>>>> +out:
>>>> + /* If we have failed to power-up, it may take a reboot to
>>>> + * get the NIC back online.
>>>> + * Set flag accordinly so that user-space can know.
>>>> + */
>>>> + ar->fw_powerup_failed = !!ret;
>>>> + return ret;
>>>> }
>>>
>>> Would it be better to use ATH10K_STATE_WEDGED for this and then just
>>> export the state value to user space? Or should we have two different
>>> states, like FW_WEDGED and HW_WEDGED?
>
> Current WEDGED state is more like ON. It assumes mac80211 will call
> ath10k_stop().
>
> Adding another state just for the sake of handling power up / reset
> issues seems like an overkill to me.
>
>
>> I didn't want to mess with the state machine. This counter
>> is just a clue to users that things might be badly wrong. Some systems
>> might recover with another hard reset, some will hang the entire
>> system hard, and some will just stick in this state unable to
>> recover. Some of my systems exhibit this last behaviour, so at
>> least with this patch I can warn the user that they need to
>> reboot to regain wifi functionality.
>
> If power up fails the error should propagate to `ifconfig wlanX up`
> (or whatever calling drv_start) eventually so I don't see the point in
> having this counter.
Supplicant manages this, and programatically it is not at all easy to
figure out that the network is failing to come up because the firmware
is broken-and-can't-be-fixed-without-reboot.
The counter I added can be queried by a management tool and propagate a
clear error to the end user.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v2 07/10] ath10k: add fw-powerup-fail to ethtool stats.
@ 2014-09-30 15:53 ` Ben Greear
0 siblings, 0 replies; 54+ messages in thread
From: Ben Greear @ 2014-09-30 15:53 UTC (permalink / raw)
To: Michal Kazior; +Cc: Kalle Valo, linux-wireless, ath10k
On 09/30/2014 05:27 AM, Michal Kazior wrote:
> On 29 September 2014 18:05, Ben Greear <greearb@candelatech.com> wrote:
>> On 09/29/2014 01:24 AM, Kalle Valo 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>
> [...]
>>>> - return 0;
>>>> +out:
>>>> + /* If we have failed to power-up, it may take a reboot to
>>>> + * get the NIC back online.
>>>> + * Set flag accordinly so that user-space can know.
>>>> + */
>>>> + ar->fw_powerup_failed = !!ret;
>>>> + return ret;
>>>> }
>>>
>>> Would it be better to use ATH10K_STATE_WEDGED for this and then just
>>> export the state value to user space? Or should we have two different
>>> states, like FW_WEDGED and HW_WEDGED?
>
> Current WEDGED state is more like ON. It assumes mac80211 will call
> ath10k_stop().
>
> Adding another state just for the sake of handling power up / reset
> issues seems like an overkill to me.
>
>
>> I didn't want to mess with the state machine. This counter
>> is just a clue to users that things might be badly wrong. Some systems
>> might recover with another hard reset, some will hang the entire
>> system hard, and some will just stick in this state unable to
>> recover. Some of my systems exhibit this last behaviour, so at
>> least with this patch I can warn the user that they need to
>> reboot to regain wifi functionality.
>
> If power up fails the error should propagate to `ifconfig wlanX up`
> (or whatever calling drv_start) eventually so I don't see the point in
> having this counter.
Supplicant manages this, and programatically it is not at all easy to
figure out that the network is failing to come up because the firmware
is broken-and-can't-be-fixed-without-reboot.
The counter I added can be queried by a management tool and propagate a
clear error to the end user.
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] 54+ messages in thread
* [PATCH v2 08/10] ath10k: support CT firmware flag.
2014-09-23 21:17 ` greearb
@ 2014-09-23 21:17 ` greearb
-1 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k, Ben Greear
From: Ben Greear <greearb@candelatech.com>
Add placeholder so CT firmware can more easily co-exist with upstream
kernel.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v2: Patch is same as last time, different subsequent patch added
in case that justifies this better. I have more, such as
tx-status (ie, tx rate) reporting, but those are on top of
the 32-stations patch logic, so have to get that sorted out
before I can post those.
If nothing else, can we add a 'do-no-use = 5' feature flag so at least
I can keep some backward/forward compatability with existing
CT firwmare and kernels patchs to utilize it?
drivers/net/wireless/ath/ath10k/core.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 601d573..0d1813c 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -361,6 +361,9 @@ enum ath10k_fw_features {
*/
ATH10K_FW_FEATURE_WMI_10_2 = 4,
+ /* Firmware from Candela Technologies, enables more VIFs, etc */
+ ATH10K_FW_FEATURE_WMI_10X_CT = 5,
+
/* keep last */
ATH10K_FW_FEATURE_COUNT,
};
--
1.7.11.7
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH v2 08/10] ath10k: support CT firmware flag.
@ 2014-09-23 21:17 ` greearb
0 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear, ath10k
From: Ben Greear <greearb@candelatech.com>
Add placeholder so CT firmware can more easily co-exist with upstream
kernel.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v2: Patch is same as last time, different subsequent patch added
in case that justifies this better. I have more, such as
tx-status (ie, tx rate) reporting, but those are on top of
the 32-stations patch logic, so have to get that sorted out
before I can post those.
If nothing else, can we add a 'do-no-use = 5' feature flag so at least
I can keep some backward/forward compatability with existing
CT firwmare and kernels patchs to utilize it?
drivers/net/wireless/ath/ath10k/core.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 601d573..0d1813c 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -361,6 +361,9 @@ enum ath10k_fw_features {
*/
ATH10K_FW_FEATURE_WMI_10_2 = 4,
+ /* Firmware from Candela Technologies, enables more VIFs, etc */
+ ATH10K_FW_FEATURE_WMI_10X_CT = 5,
+
/* keep last */
ATH10K_FW_FEATURE_COUNT,
};
--
1.7.11.7
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 09/10] ath10k: always request htc tx replenishment
2014-09-23 21:17 ` greearb
@ 2014-09-23 21:17 ` greearb
-1 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k, Michal Kazior
From: Michal Kazior <michal.kazior@tieto.com>
This simplifies tx credit management and tries to
address a problem where driver runs out of credits
and is unable to recover when firmware stalls.
This also makes it a little more easy to track and
debug htc tx credit flow since there should be no
laziness involved.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Tested-by: Ben Greear <greearb@candelatech.com>
---
v2: This is Michal's patch originally. I think only CT firmware
actually supports this properly, but should not hurt existing
firmware.
drivers/net/wireless/ath/ath10k/htc.c | 17 +----------------
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index 676bd4e..7a6b9b0 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -86,21 +86,6 @@ static void ath10k_htc_notify_tx_completion(struct ath10k_htc_ep *ep,
ep->ep_ops.ep_tx_complete(ep->htc->ar, skb);
}
-/* assumes tx_lock is held */
-static bool ath10k_htc_ep_need_credit_update(struct ath10k_htc_ep *ep)
-{
- struct ath10k *ar = ep->htc->ar;
-
- if (!ep->tx_credit_flow_enabled)
- return false;
- if (ep->tx_credits >= ep->tx_credits_per_max_message)
- return false;
-
- ath10k_dbg(ar, ATH10K_DBG_HTC, "HTC: endpoint %d needs credit update\n",
- ep->eid);
- return true;
-}
-
static void ath10k_htc_prepare_tx_skb(struct ath10k_htc_ep *ep,
struct sk_buff *skb)
{
@@ -115,7 +100,7 @@ static void ath10k_htc_prepare_tx_skb(struct ath10k_htc_ep *ep,
spin_lock_bh(&ep->htc->tx_lock);
hdr->seq_no = ep->seq_no++;
- if (ath10k_htc_ep_need_credit_update(ep))
+ if (ep->tx_credit_flow_enabled)
hdr->flags |= ATH10K_HTC_FLAG_NEED_CREDIT_UPDATE;
spin_unlock_bh(&ep->htc->tx_lock);
--
1.7.11.7
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH v2 09/10] ath10k: always request htc tx replenishment
@ 2014-09-23 21:17 ` greearb
0 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Michal Kazior, ath10k
From: Michal Kazior <michal.kazior@tieto.com>
This simplifies tx credit management and tries to
address a problem where driver runs out of credits
and is unable to recover when firmware stalls.
This also makes it a little more easy to track and
debug htc tx credit flow since there should be no
laziness involved.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Tested-by: Ben Greear <greearb@candelatech.com>
---
v2: This is Michal's patch originally. I think only CT firmware
actually supports this properly, but should not hurt existing
firmware.
drivers/net/wireless/ath/ath10k/htc.c | 17 +----------------
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index 676bd4e..7a6b9b0 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -86,21 +86,6 @@ static void ath10k_htc_notify_tx_completion(struct ath10k_htc_ep *ep,
ep->ep_ops.ep_tx_complete(ep->htc->ar, skb);
}
-/* assumes tx_lock is held */
-static bool ath10k_htc_ep_need_credit_update(struct ath10k_htc_ep *ep)
-{
- struct ath10k *ar = ep->htc->ar;
-
- if (!ep->tx_credit_flow_enabled)
- return false;
- if (ep->tx_credits >= ep->tx_credits_per_max_message)
- return false;
-
- ath10k_dbg(ar, ATH10K_DBG_HTC, "HTC: endpoint %d needs credit update\n",
- ep->eid);
- return true;
-}
-
static void ath10k_htc_prepare_tx_skb(struct ath10k_htc_ep *ep,
struct sk_buff *skb)
{
@@ -115,7 +100,7 @@ static void ath10k_htc_prepare_tx_skb(struct ath10k_htc_ep *ep,
spin_lock_bh(&ep->htc->tx_lock);
hdr->seq_no = ep->seq_no++;
- if (ath10k_htc_ep_need_credit_update(ep))
+ if (ep->tx_credit_flow_enabled)
hdr->flags |= ATH10K_HTC_FLAG_NEED_CREDIT_UPDATE;
spin_unlock_bh(&ep->htc->tx_lock);
--
1.7.11.7
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v2 10/10] ath10k: request firmware flush in ath10k_flush.
2014-09-23 21:17 ` greearb
@ 2014-09-23 21:17 ` greearb
-1 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k, Ben Greear
From: Ben Greear <greearb@candelatech.com>
CT firmware now supports flushing all tids for all
peers for all vdevs. This appears to help the ath10k_flush
logic work faster and not cause timeouts.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v2: No changes, just added it to the series in case it
helps justify adding the CT feature flag.
drivers/net/wireless/ath/ath10k/mac.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 34ec992..bde3a2f 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3917,6 +3917,7 @@ static void ath10k_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct ath10k *ar = hw->priv;
bool skip;
int ret;
+ u8 peer_addr[ETH_ALEN] = {0};
/* mac80211 doesn't care if we really xmit queued frames or not
* we'll collect those frames either way if we stop/delete vdevs */
@@ -3928,6 +3929,12 @@ static void ath10k_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
if (ar->state == ATH10K_STATE_WEDGED)
goto skip;
+ /* If we are CT firmware, ask it to flush all tids on all peers on
+ * all vdevs. Normal firmware will just crash if you do this.
+ */
+ if (test_bit(ATH10K_FW_FEATURE_WMI_10X_CT, ar->fw_features))
+ ath10k_wmi_peer_flush(ar, 0xFFFFFFFF, peer_addr, 0xFFFFFFFF);
+
ret = wait_event_timeout(ar->htt.empty_tx_wq, ({
bool empty;
--
1.7.11.7
^ permalink raw reply related [flat|nested] 54+ messages in thread* [PATCH v2 10/10] ath10k: request firmware flush in ath10k_flush.
@ 2014-09-23 21:17 ` greearb
0 siblings, 0 replies; 54+ messages in thread
From: greearb @ 2014-09-23 21:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear, ath10k
From: Ben Greear <greearb@candelatech.com>
CT firmware now supports flushing all tids for all
peers for all vdevs. This appears to help the ath10k_flush
logic work faster and not cause timeouts.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v2: No changes, just added it to the series in case it
helps justify adding the CT feature flag.
drivers/net/wireless/ath/ath10k/mac.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 34ec992..bde3a2f 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3917,6 +3917,7 @@ static void ath10k_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct ath10k *ar = hw->priv;
bool skip;
int ret;
+ u8 peer_addr[ETH_ALEN] = {0};
/* mac80211 doesn't care if we really xmit queued frames or not
* we'll collect those frames either way if we stop/delete vdevs */
@@ -3928,6 +3929,12 @@ static void ath10k_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
if (ar->state == ATH10K_STATE_WEDGED)
goto skip;
+ /* If we are CT firmware, ask it to flush all tids on all peers on
+ * all vdevs. Normal firmware will just crash if you do this.
+ */
+ if (test_bit(ATH10K_FW_FEATURE_WMI_10X_CT, ar->fw_features))
+ ath10k_wmi_peer_flush(ar, 0xFFFFFFFF, peer_addr, 0xFFFFFFFF);
+
ret = wait_event_timeout(ar->htt.empty_tx_wq, ({
bool empty;
--
1.7.11.7
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 54+ messages in thread
* Re: [PATCH v2 01/10] ath10k: use 64-bit vdev map.
2014-09-23 21:17 ` greearb
@ 2014-10-01 8:22 ` Kalle Valo
-1 siblings, 0 replies; 54+ messages in thread
From: Kalle Valo @ 2014-10-01 8:22 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath10k
greearb@candelatech.com writes:
> From: Ben Greear <greearb@candelatech.com>
>
> This can allow more than 32 stations to be supported
> without over-running the bitmap.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
Thanks, I have applied this patch.
--
Kalle Valo
^ permalink raw reply [flat|nested] 54+ messages in thread