* [PATCH v3 2/2] ath10k: implement per-VDEV FW statistics
From: Bartosz Markowski @ 2013-08-29 12:07 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Bartosz Markowski
In-Reply-To: <1377778061-22331-1-git-send-email-bartosz.markowski@tieto.com>
The WMI_REQUEST_PEER_STAT command with latst (1.0.0.716) FW
can return per-VDEV statistics. Using debugfs we can fetch this info now.
This is a backward compatible change. In case of older FW the VDEV
statistics are simply not returned.
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
---
drivers/net/wireless/ath/ath10k/core.h | 27 ++++++++++
drivers/net/wireless/ath/ath10k/debug.c | 78 ++++++++++++++++++++++-----
drivers/net/wireless/ath/ath10k/wmi.c | 4 +-
drivers/net/wireless/ath/ath10k/wmi.h | 87 ++++++++++++++++++++++++++-----
4 files changed, 170 insertions(+), 26 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index ab05c4c..523c79d 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -119,10 +119,32 @@ struct ath10k_wmi {
struct work_struct wmi_event_work;
};
+struct ath10k_snr_info {
+ s32 beacon_snr;
+ s32 data_snr;
+};
+
+struct ath10k_vdev_stat {
+ u32 vdev_id;
+ struct ath10k_snr_info vdev_snr;
+ u32 tx_frames_count[MAX_AC];
+ u32 rx_frames_count;
+ u32 multiple_retry_cnt[MAX_AC];
+ u32 fail_count[MAX_AC];
+ u32 rts_fail_count;
+ u32 rts_success_count;
+ u32 rts_err_count;
+ u32 rx_discard_count;
+ u32 ack_fail_count;
+ u32 tx_rate_history[MAX_TX_RATE_VALUES];
+ u32 bcn_rssi_history[MAX_RSSI_VALUES];
+};
+
struct ath10k_peer_stat {
u8 peer_macaddr[ETH_ALEN];
u32 peer_rssi;
u32 peer_tx_rate;
+ u32 peer_rx_rate;
};
struct ath10k_target_stats {
@@ -176,6 +198,8 @@ struct ath10k_target_stats {
s32 mpdu_errs;
/* VDEV STATS */
+ struct ath10k_vdev_stat vdev_stat[TARGET_NUM_VDEVS];
+ u8 vdevs;
/* PEER STATS */
u8 peers;
@@ -274,6 +298,9 @@ enum ath10k_fw_features {
/* wmi_mgmt_rx_hdr contains extra RSSI information */
ATH10K_FW_FEATURE_EXT_WMI_MGMT_RX = 0,
+ /* firmware support per-VEDV statistics */
+ ATH10K_FW_FEATURE_VDEV_STATS = 1,
+
/* keep last */
ATH10K_FW_FEATURE_COUNT,
};
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index fcb40cc..0f2b169 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -228,34 +228,59 @@ void ath10k_debug_read_target_stats(struct ath10k *ar,
tmp += sizeof(struct wmi_pdev_stats);
}
- /* 0 or max vdevs */
- /* Currently firmware does not support VDEV stats */
if (num_vdev_stats) {
struct wmi_vdev_stats *vdev_stats;
+ struct ath10k_vdev_stat *s;
+
+ stats->vdevs = num_vdev_stats;
for (i = 0; i < num_vdev_stats; i++) {
vdev_stats = (struct wmi_vdev_stats *)tmp;
+ s = &stats->vdev_stat[i];
+
+ s->vdev_id = __le32_to_cpu(vdev_stats->vdev_id);
+ s->vdev_snr.beacon_snr =
+ __le32_to_cpu(vdev_stats->vdev_snr.beacon_snr);
+ s->vdev_snr.data_snr =
+ __le32_to_cpu(vdev_stats->vdev_snr.data_snr);
+
+ /* TODO:read remaining vdev stats */
+
tmp += sizeof(struct wmi_vdev_stats);
}
}
if (num_peer_stats) {
- struct wmi_peer_stats *peer_stats;
struct ath10k_peer_stat *s;
+ struct wmi_peer_stats_1 *peer_stats_1;
+ struct wmi_peer_stats_2 *peer_stats_2;
stats->peers = num_peer_stats;
for (i = 0; i < num_peer_stats; i++) {
- peer_stats = (struct wmi_peer_stats *)tmp;
+ peer_stats_1 = (struct wmi_peer_stats_1 *)tmp;
+
s = &stats->peer_stat[i];
- WMI_MAC_ADDR_TO_CHAR_ARRAY(&peer_stats->peer_macaddr,
- s->peer_macaddr);
- s->peer_rssi = __le32_to_cpu(peer_stats->peer_rssi);
+ WMI_MAC_ADDR_TO_CHAR_ARRAY(
+ &peer_stats_1->common.peer_macaddr,
+ s->peer_macaddr);
+ s->peer_rssi =
+ __le32_to_cpu(peer_stats_1->common.peer_rssi);
s->peer_tx_rate =
- __le32_to_cpu(peer_stats->peer_tx_rate);
-
- tmp += sizeof(struct wmi_peer_stats);
+ __le32_to_cpu(peer_stats_1->common.peer_tx_rate);
+
+ if (test_bit(ATH10K_FW_FEATURE_VDEV_STATS,
+ ar->fw_features)) {
+ peer_stats_2 = (struct wmi_peer_stats_2 *)tmp;
+ s->peer_rx_rate =
+ __le32_to_cpu(peer_stats_2->peer_rx_rate);
+
+ tmp += sizeof(struct wmi_peer_stats_2);
+ }
+ else {
+ tmp += sizeof(struct wmi_peer_stats_1);
+ }
}
}
@@ -269,7 +294,7 @@ static ssize_t ath10k_read_fw_stats(struct file *file, char __user *user_buf,
struct ath10k *ar = file->private_data;
struct ath10k_target_stats *fw_stats;
char *buf = NULL;
- unsigned int len = 0, buf_len = 2500;
+ unsigned int len = 0, buf_len = 3000;
ssize_t ret_cnt = 0;
long left;
int i;
@@ -407,6 +432,27 @@ static ssize_t ath10k_read_fw_stats(struct file *file, char __user *user_buf,
len += scnprintf(buf + len, buf_len - len, "%30s %10d\n",
"MPDU errors (FCS, MIC, ENC)", fw_stats->mpdu_errs);
+ if (fw_stats->vdevs) {
+ len += scnprintf(buf + len, buf_len - len, "\n");
+ len += scnprintf(buf + len, buf_len - len, "%30s\n",
+ "ath10k VDEV stats");
+ len += scnprintf(buf + len, buf_len - len, "%30s\n\n",
+ "=================");
+ }
+
+ for (i = 0; i < fw_stats->vdevs; i++) {
+ len += scnprintf(buf + len, buf_len - len, "%30s %10u\n",
+ "VDEV ID", fw_stats->vdev_stat[i].vdev_id);
+ len += scnprintf(buf + len, buf_len - len, "%30s %10u\n",
+ "Beacon SNR",
+ fw_stats->vdev_stat[i].vdev_snr.beacon_snr);
+ len += scnprintf(buf + len, buf_len - len, "%30s %10u\n",
+ "Data SNR",
+ fw_stats->vdev_stat[i].vdev_snr.data_snr);
+ len += scnprintf(buf + len, buf_len - len, "\n");
+ }
+
+
len += scnprintf(buf + len, buf_len - len, "\n");
len += scnprintf(buf + len, buf_len - len, "%30s\n",
"ath10k PEER stats");
@@ -417,11 +463,17 @@ static ssize_t ath10k_read_fw_stats(struct file *file, char __user *user_buf,
len += scnprintf(buf + len, buf_len - len, "%30s %pM\n",
"Peer MAC address",
fw_stats->peer_stat[i].peer_macaddr);
- len += scnprintf(buf + len, buf_len - len, "%30s %u\n",
+ len += scnprintf(buf + len, buf_len - len, "%30s %10u\n",
"Peer RSSI", fw_stats->peer_stat[i].peer_rssi);
- len += scnprintf(buf + len, buf_len - len, "%30s %u\n",
+ len += scnprintf(buf + len, buf_len - len, "%30s %10u\n",
"Peer TX rate",
fw_stats->peer_stat[i].peer_tx_rate);
+
+ if (test_bit(ATH10K_FW_FEATURE_VDEV_STATS, ar->fw_features))
+ len += scnprintf(buf + len, buf_len - len, "%30s %10u\n",
+ "Peer RX rate",
+ fw_stats->peer_stat[i].peer_rx_rate);
+
len += scnprintf(buf + len, buf_len - len, "\n");
}
spin_unlock_bh(&ar->data_lock);
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 32fd5e7..3ebab3d 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -957,8 +957,10 @@ static void ath10k_wmi_service_ready_event_rx(struct ath10k *ar,
ar->phy_capability = __le32_to_cpu(ev->phy_capability);
ar->num_rf_chains = __le32_to_cpu(ev->num_rf_chains);
- if (ar->fw_version_build > 636)
+ if (ar->fw_version_build > 636) {
set_bit(ATH10K_FW_FEATURE_EXT_WMI_MGMT_RX, ar->fw_features);
+ set_bit(ATH10K_FW_FEATURE_VDEV_STATS, ar->fw_features);
+ }
if (ar->num_rf_chains > WMI_MAX_SPATIAL_STREAM) {
ath10k_warn("hardware advertises support for more spatial streams than it should (%d > %d)\n",
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 5b94707..99c7ba1 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -60,6 +60,11 @@
*
*/
+#define MAX_AC 4 /* Maximum value of access category */
+
+#define MAX_TX_RATE_VALUES 10 /* Max Tx rates */
+#define MAX_RSSI_VALUES 10 /* Max RSSI values */
+
/* Control Path */
struct wmi_cmd_hdr {
__le32 cmd_id;
@@ -1828,11 +1833,10 @@ enum wmi_stats_id {
struct wmi_request_stats_cmd {
__le32 stats_id;
-
- /*
- * Space to add parameters like
- * peer mac addr
- */
+ /* unique id identifying the VDEV, generated by the caller */
+ __le32 vdev_id;
+ /* peer MAC address */
+ struct wmi_mac_addr peer_macaddr;
} __packed;
/* Suspend option */
@@ -1881,7 +1885,6 @@ struct wmi_stats_event {
/*
* PDEV statistics
- * TODO: add all PDEV stats here
*/
struct wmi_pdev_stats {
__le32 chan_nf; /* Channel noise floor */
@@ -1894,24 +1897,84 @@ struct wmi_pdev_stats {
struct wal_dbg_stats wal; /* WAL dbg stats */
} __packed;
-/*
- * VDEV statistics
- * TODO: add all VDEV stats here
- */
+struct wmi_snr_info {
+ __le32 beacon_snr;
+ __le32 data_snr;
+} __packed;
+
struct wmi_vdev_stats {
+ /* unique id identifying the VDEV, generated by the caller */
__le32 vdev_id;
+ struct wmi_snr_info vdev_snr;
+ /*
+ * Total number of packets(per AC) that were successfully transmitted
+ * (with and without retries, including multi-cast, broadcast)
+ */
+ __le32 tx_frm_cnt[MAX_AC];
+ /*
+ * Total number of packets that were successfully received
+ * (after appropriate filter rules including multi-cast, broadcast)
+ */
+ __le32 rx_frm_cnt;
+ /*
+ * The number of MSDU packets and MMPDU frames per AC that the 802.11
+ * station successfully transmitted after more than one retransmission
+ * attempt
+ */
+ __le32 multiple_retry_cnt[MAX_AC];
+ /* Total number packets(per AC) failed to transmit */
+ __le32 fail_cnt[MAX_AC];
+ /*
+ * Total number of RTS/CTS sequence failures for transmission of a
+ * packet
+ */
+ __le32 rts_fail_cnt;
+ /*
+ * Total number of RTS/CTS sequence success for transmission of a
+ * packet
+ */
+ __le32 rts_succ_cnt;
+ /*
+ * The receive error count.
+ * HAL will provide the RxP FCS error global
+ */
+ __le32 rx_err_cnt;
+ /*
+ * The sum of the receive error count and dropped-receive-buffer
+ * error count. (FCS error)
+ */
+ __le32 rx_discard_cnt;
+ /*
+ * Total number packets failed transmit because of no ACK
+ * from the remote entity
+ */
+ __le32 ack_fail_cnt;
+ /* History of last ten transmit rate, in units of 500 kbit/sec */
+ __le32 tx_rate_history[MAX_TX_RATE_VALUES];
+ /* History of last ten Beacon rssi of the connected Bss */
+ __le32 bcn_rssi_history[MAX_RSSI_VALUES];
} __packed;
/*
* peer statistics.
- * TODO: add more stats
*/
-struct wmi_peer_stats {
+struct wmi_peer_stats_common {
struct wmi_mac_addr peer_macaddr;
__le32 peer_rssi;
__le32 peer_tx_rate;
} __packed;
+struct wmi_peer_stats_1 {
+ struct wmi_peer_stats_common common;
+} __packed;
+
+
+struct wmi_peer_stats_2 {
+ struct wmi_peer_stats_common common;
+ __le32 peer_rx_rate;
+} __packed;
+
+
struct wmi_vdev_create_cmd {
__le32 vdev_id;
__le32 vdev_type;
--
1.7.10
^ permalink raw reply related
* [PATCH v3 0/2] add per-VDEV FW statistics
From: Bartosz Markowski @ 2013-08-29 12:07 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Bartosz Markowski
FW 1.0.0.716 brings per-VDEV statistics. This patch-set implements
debugfs mechanism to fetch those. There's still few more fileds we
can read from the FW stats event, which are not covered here.
Changes:
V2:
* introduce wmi_peer_stats_common struct
* fetch and print peer RX rates
* break up wmi_peer_stats_common update into separate patch
V3:
* rebase
* fix sparse endianness warnings
Bartosz Markowski (2):
ath10k: update wal_dbg_tx_stats structure with missing parameter.
ath10k: implement per-VDEV FW statistics
drivers/net/wireless/ath/ath10k/core.h | 27 ++++++++++
drivers/net/wireless/ath/ath10k/debug.c | 78 ++++++++++++++++++++++-----
drivers/net/wireless/ath/ath10k/wmi.c | 4 +-
drivers/net/wireless/ath/ath10k/wmi.h | 90 ++++++++++++++++++++++++++-----
4 files changed, 173 insertions(+), 26 deletions(-)
--
1.7.10
^ permalink raw reply
* [PATCH v3 1/2] ath10k: update wal_dbg_tx_stats structure with missing parameter.
From: Bartosz Markowski @ 2013-08-29 12:07 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Bartosz Markowski
In-Reply-To: <1377778061-22331-1-git-send-email-bartosz.markowski@tieto.com>
It's very imporatant to keep these structs up to date with FW abi,
due to the arithmetic we use while read the fw_stats.
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
---
drivers/net/wireless/ath/ath10k/wmi.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 08860c4..5b94707 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -1767,6 +1767,9 @@ struct wal_dbg_tx_stats {
/* wal pdev resets */
__le32 pdev_resets;
+ /* frames dropped due to non-availability of stateless TIDs */
+ __le32 stateless_tid_alloc_failure;
+
__le32 phy_underrun;
/* MPDU is more than txop limit */
--
1.7.10
^ permalink raw reply related
* [PATCH] cfg80211: use the correct macro to check for active monitor support
From: Luciano Coelho @ 2013-08-29 10:26 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless
Use MONITOR_FLAG_ACTIVE, which is a flag mask, instead of
NL80211_MNTR_FLAG_ACTIVE, which is a flag index, when checking if the
hardware supports active monitoring.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
---
net/wireless/nl80211.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index af8d84a..626dc3b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2421,7 +2421,7 @@ static int nl80211_set_interface(struct sk_buff *skb, struct genl_info *info)
change = true;
}
- if (flags && (*flags & NL80211_MNTR_FLAG_ACTIVE) &&
+ if (flags && (*flags & MONITOR_FLAG_ACTIVE) &&
!(rdev->wiphy.features & NL80211_FEATURE_ACTIVE_MONITOR))
return -EOPNOTSUPP;
@@ -2483,7 +2483,7 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
info->attrs[NL80211_ATTR_MNTR_FLAGS] : NULL,
&flags);
- if (!err && (flags & NL80211_MNTR_FLAG_ACTIVE) &&
+ if (!err && (flags & MONITOR_FLAG_ACTIVE) &&
!(rdev->wiphy.features & NL80211_FEATURE_ACTIVE_MONITOR))
return -EOPNOTSUPP;
--
1.7.10.4
^ permalink raw reply related
* Re: [BUG] iwlwifi Microcode SW error (firmware version: 18.168.6.1)
From: Luciano Coelho @ 2013-08-29 4:52 UTC (permalink / raw)
To: adam.gradzki; +Cc: linux-wireless
In-Reply-To: <2449090.W0ZgYRKzHN@nuclearreactor>
On Thu, 2013-08-29 at 00:38 -0400, adam.gradzki@gmail.com wrote:
> Hi Luca,
>
> I was browsing the web while in a large hall with many connected wireless
> clients. There were also several routers sharing a common SSID. I remember
> playing with various RTS and fragmentation thresholds so this may have been
> the trigger. The connection itself involved WPA2 Enterprise PEAP w/ MSCHAPv2
> authentication. I wish I could go into more detail but I was browsing the
> system log long after the fact so I'm having trouble remembering things off the
> top of my head.
>
> Linux laptop 3.10.9-1-ARCH #1 SMP PREEMPT Wed Aug 21 13:49:35 CEST 2013 x86_64
> GNU/Linux
Thanks again! I'll follow this up internally.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [BUG] iwlwifi Microcode SW error (firmware version: 18.168.6.1)
From: adam.gradzki @ 2013-08-29 4:38 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
In-Reply-To: <1377750599.4418.3.camel@porter.coelho.fi>
Hi Luca,
I was browsing the web while in a large hall with many connected wireless
clients. There were also several routers sharing a common SSID. I remember
playing with various RTS and fragmentation thresholds so this may have been
the trigger. The connection itself involved WPA2 Enterprise PEAP w/ MSCHAPv2
authentication. I wish I could go into more detail but I was browsing the
system log long after the fact so I'm having trouble remembering things off the
top of my head.
Linux laptop 3.10.9-1-ARCH #1 SMP PREEMPT Wed Aug 21 13:49:35 CEST 2013 x86_64
GNU/Linux
Regards,
Adam
On Thursday, August 29, 2013 07:29:59 AM you wrote:
> Hi Adam,
>
> On Thu, 2013-08-29 at 00:17 -0400, adam.gradzki@gmail.com wrote:
> > I would like to report a problem with the Intel iwlwifi driver
> > Here is what I found in my system log:
> >
> > http://pastebin.com/j5cVsqzz
>
> Thanks for reporting! Could you please give a bit more details on what
> you were doing when this happened? Just a simple connection to an AP?
> Heavy traffic?
>
> --
> Cheers,
> Luca.
^ permalink raw reply
* Re: [BUG] iwlwifi Microcode SW error (firmware version: 18.168.6.1)
From: Luciano Coelho @ 2013-08-29 4:29 UTC (permalink / raw)
To: adam.gradzki; +Cc: linux-wireless
In-Reply-To: <7144869.jC5clVvrrO@nuclearreactor>
Hi Adam,
On Thu, 2013-08-29 at 00:17 -0400, adam.gradzki@gmail.com wrote:
> I would like to report a problem with the Intel iwlwifi driver
> Here is what I found in my system log:
>
> http://pastebin.com/j5cVsqzz
Thanks for reporting! Could you please give a bit more details on what
you were doing when this happened? Just a simple connection to an AP?
Heavy traffic?
--
Cheers,
Luca.
^ permalink raw reply
* [BUG] iwlwifi Microcode SW error (firmware version: 18.168.6.1)
From: adam.gradzki @ 2013-08-29 4:17 UTC (permalink / raw)
To: linux-wireless
I would like to report a problem with the Intel iwlwifi driver
Here is what I found in my system log:
http://pastebin.com/j5cVsqzz
^ permalink raw reply
* Re: [PATCH] ath9k: ar9003_eeprom.c:3618 fix variable name typo
From: Sujith Manoharan @ 2013-08-29 2:22 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1377702550-11734-1-git-send-email-linville@tuxdriver.com>
John W. Linville wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
>
> drivers/net/wireless/ath/ath9k/ar9003_eeprom.c: In function 'ar9003_hw_ant_ctrl_apply':
> >> drivers/net/wireless/ath/ath9k/ar9003_eeprom.c:3618: warning: 'regval' is used uninitialized in this function
>
> It seems obvious that 'regval' should have been 'value'...
Good catch and thanks for the fix !
Sujith
^ permalink raw reply
* RE: sd8787 (mwifiex) on big endian system
From: Bing Zhao @ 2013-08-29 0:00 UTC (permalink / raw)
To: Tobias Waldekranz; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20130828115251.GA3504@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 491 bytes --]
Hi Tobias,
> mwifiex_sdio mmc0:0001:1: event: 1142011.264553: cause: 0x2e
> mwifiex_sdio mmc0:0001:1: AP EVENT: event id: 0x2e
> mwifiex_sdio mmc0:0001:1: cmd_wait_q terminated: -512
> mwifiex_sdio mmc0:0001:1: mwifiex_cmd_timeout_func: Timeout cmd id (1142021.275294) = 0xb1, act = 0x0
The SDIO_INT of the command response might have been missing for some reason.
Could you please apply the debug patch attached for checking the read_bitmap after a timeout?
Thanks,
Bing
[-- Attachment #2: int_missing.diff --]
[-- Type: application/octet-stream, Size: 2772 bytes --]
diff --git a/drivers/net/wireless/mwifiex/cmdevt.c b/drivers/net/wireless/mwifiex/cmdevt.c
index 2d76147..88fd41f 100644
--- a/drivers/net/wireless/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/mwifiex/cmdevt.c
@@ -25,6 +25,7 @@
#include "wmm.h"
#include "11n.h"
#include "11ac.h"
+#include "sdio.h"
/*
* This function initializes a command node.
@@ -902,8 +903,11 @@ mwifiex_cmd_timeout_func(unsigned long function_context)
{
struct mwifiex_adapter *adapter =
(struct mwifiex_adapter *) function_context;
+ struct sdio_mmc_card *card = adapter->card;
+ const struct mwifiex_sdio_card_reg *reg = card->reg;
struct cmd_ctrl_node *cmd_node;
struct timeval tstamp;
+ u32 bitmap;
adapter->num_cmd_timeout++;
adapter->dbg.num_cmd_timeout++;
@@ -961,6 +965,21 @@ mwifiex_cmd_timeout_func(unsigned long function_context)
dev_err(adapter->dev, "ps_mode=%d ps_state=%d\n",
adapter->ps_mode, adapter->ps_state);
+ bitmap = (u32) card->mp_regs[reg->rd_bitmap_l];
+ bitmap |= ((u32) card->mp_regs[reg->rd_bitmap_u]) << 8;
+ dev_err(adapter->dev, "DBG: old: rd_bitmap=0x%x 0x%x\n",
+ card->mp_rd_bitmap, bitmap);
+ if (adapter->if_ops.read_data_sync) {
+ if (adapter->if_ops.read_data_sync(adapter, card->mp_regs,
+ card->reg->max_mp_regs,
+ REG_PORT | MWIFIEX_SDIO_BYTE_MODE_MASK, 0))
+ dev_err(adapter->dev, "DBG: read mp_regs failed\n");
+ }
+ bitmap = (u32) card->mp_regs[reg->rd_bitmap_l];
+ bitmap |= ((u32) card->mp_regs[reg->rd_bitmap_u]) << 8;
+ dev_err(adapter->dev, "DBG: new: rd_bitmap=0x%x int=0x%x\n",
+ bitmap, card->mp_regs[HOST_INTSTATUS_REG]);
+
if (cmd_node->wait_q_enabled) {
adapter->cmd_wait_q.status = -ETIMEDOUT;
wake_up_interruptible(&adapter->cmd_wait_q.wait);
diff --git a/drivers/net/wireless/mwifiex/main.h b/drivers/net/wireless/mwifiex/main.h
index 1d72f13..a55d2fb 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -620,6 +620,8 @@ struct mwifiex_if_ops {
int (*dnld_fw) (struct mwifiex_adapter *, struct mwifiex_fw_image *);
void (*card_reset) (struct mwifiex_adapter *);
int (*clean_pcie_ring) (struct mwifiex_adapter *adapter);
+ int (*read_data_sync) (struct mwifiex_adapter *adapter, u8 *buffer,
+ u32 len, u32 port, u8 claim);
};
struct mwifiex_adapter {
diff --git a/drivers/net/wireless/mwifiex/sdio.c b/drivers/net/wireless/mwifiex/sdio.c
index 1576104..58c0641 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -1958,6 +1958,7 @@ static struct mwifiex_if_ops sdio_ops = {
.cmdrsp_complete = mwifiex_sdio_cmdrsp_complete,
.event_complete = mwifiex_sdio_event_complete,
.card_reset = mwifiex_sdio_card_reset,
+ .read_data_sync = mwifiex_read_data_sync,
};
/*
^ permalink raw reply related
* [PATCH v2 rebased] staging: vt6656: device.h Replace typedef struct _RCB
From: Malcolm Priestley @ 2013-08-28 20:12 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Replace with struct vnt_rcb
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/device.h | 20 +++++++++-----------
drivers/staging/vt6656/dpc.c | 10 +++++-----
drivers/staging/vt6656/dpc.h | 4 ++--
drivers/staging/vt6656/main_usb.c | 14 ++++++++------
drivers/staging/vt6656/usbpipe.c | 4 ++--
drivers/staging/vt6656/usbpipe.h | 2 +-
6 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/staging/vt6656/device.h b/drivers/staging/vt6656/device.h
index 3151c8f..8e39634 100644
--- a/drivers/staging/vt6656/device.h
+++ b/drivers/staging/vt6656/device.h
@@ -166,8 +166,7 @@ typedef enum _CONTEXT_TYPE {
} CONTEXT_TYPE;
/* RCB (Receive Control Block) */
-typedef struct _RCB
-{
+struct vnt_rcb {
void *Next;
signed long Ref;
void *pDevice;
@@ -175,8 +174,7 @@ typedef struct _RCB
struct vnt_rx_mgmt sMngPacket;
struct sk_buff *skb;
int bBoolInUse;
-
-} RCB, *PRCB;
+};
/* used to track bulk out irps */
struct vnt_usb_send_context {
@@ -416,14 +414,14 @@ struct vnt_private {
u32 int_interval;
/* Variables to track resources for the BULK In Pipe */
- PRCB pRCBMem;
- PRCB apRCB[CB_MAX_RX_DESC];
+ struct vnt_rcb *pRCBMem;
+ struct vnt_rcb *apRCB[CB_MAX_RX_DESC];
u32 cbRD;
- PRCB FirstRecvFreeList;
- PRCB LastRecvFreeList;
+ struct vnt_rcb *FirstRecvFreeList;
+ struct vnt_rcb *LastRecvFreeList;
u32 NumRecvFreeList;
- PRCB FirstRecvMngList;
- PRCB LastRecvMngList;
+ struct vnt_rcb *FirstRecvMngList;
+ struct vnt_rcb *LastRecvMngList;
u32 NumRecvMngList;
int bIsRxWorkItemQueued;
int bIsRxMngWorkItemQueued;
@@ -774,7 +772,7 @@ struct vnt_private {
#define DequeueRCB(Head, Tail) \
{ \
- PRCB RCB = Head; \
+ struct vnt_rcb *RCB = Head; \
if (!RCB->Next) { \
Tail = NULL; \
} \
diff --git a/drivers/staging/vt6656/dpc.c b/drivers/staging/vt6656/dpc.c
index 4bc362f..ea7d443 100644
--- a/drivers/staging/vt6656/dpc.c
+++ b/drivers/staging/vt6656/dpc.c
@@ -246,7 +246,7 @@ s_vGetDASA (
*pcbHeaderSize = cbHeaderSize;
}
-int RXbBulkInProcessData(struct vnt_private *pDevice, PRCB pRCB,
+int RXbBulkInProcessData(struct vnt_private *pDevice, struct vnt_rcb *pRCB,
unsigned long BytesToIndicate)
{
struct net_device_stats *pStats = &pDevice->stats;
@@ -271,7 +271,7 @@ int RXbBulkInProcessData(struct vnt_private *pDevice, PRCB pRCB,
/* signed long ldBm = 0; */
int bIsWEP = false; int bExtIV = false;
u32 dwWbkStatus;
- PRCB pRCBIndicate = pRCB;
+ struct vnt_rcb *pRCBIndicate = pRCB;
u8 *pbyDAddress;
u16 *pwPLCP_Length;
u8 abyVaildRate[MAX_RATE]
@@ -1336,7 +1336,7 @@ static int s_bAPModeRxData(struct vnt_private *pDevice, struct sk_buff *skb,
void RXvWorkItem(struct vnt_private *pDevice)
{
int ntStatus;
- PRCB pRCB = NULL;
+ struct vnt_rcb *pRCB = NULL;
DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO"---->Rx Polling Thread\n");
spin_lock_irq(&pDevice->lock);
@@ -1354,7 +1354,7 @@ void RXvWorkItem(struct vnt_private *pDevice)
}
-void RXvFreeRCB(PRCB pRCB, int bReAllocSkb)
+void RXvFreeRCB(struct vnt_rcb *pRCB, int bReAllocSkb)
{
struct vnt_private *pDevice = pRCB->pDevice;
@@ -1391,7 +1391,7 @@ void RXvFreeRCB(PRCB pRCB, int bReAllocSkb)
void RXvMngWorkItem(struct vnt_private *pDevice)
{
- PRCB pRCB = NULL;
+ struct vnt_rcb *pRCB = NULL;
struct vnt_rx_mgmt *pRxPacket;
int bReAllocSkb = false;
diff --git a/drivers/staging/vt6656/dpc.h b/drivers/staging/vt6656/dpc.h
index 876468f..95388dc 100644
--- a/drivers/staging/vt6656/dpc.h
+++ b/drivers/staging/vt6656/dpc.h
@@ -36,9 +36,9 @@ void RXvWorkItem(void *Context);
void RXvMngWorkItem(void *Context);
-void RXvFreeRCB(PRCB pRCB, int bReAllocSkb);
+void RXvFreeRCB(struct vnt_rcb *pRCB, int bReAllocSkb);
-int RXbBulkInProcessData(struct vnt_private *, PRCB pRCB,
+int RXbBulkInProcessData(struct vnt_private *, struct vnt_rcb *pRCB,
unsigned long BytesToIndicate);
#endif /* __RXTX_H__ */
diff --git a/drivers/staging/vt6656/main_usb.c b/drivers/staging/vt6656/main_usb.c
index 37d66a3..5369717 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -751,8 +751,8 @@ static void device_free_tx_bufs(struct vnt_private *pDevice)
static void device_free_rx_bufs(struct vnt_private *pDevice)
{
- PRCB pRCB;
- int ii;
+ struct vnt_rcb *pRCB;
+ int ii;
for (ii = 0; ii < pDevice->cbRD; ii++) {
@@ -789,8 +789,8 @@ static void device_free_int_bufs(struct vnt_private *pDevice)
static bool device_alloc_bufs(struct vnt_private *pDevice)
{
struct vnt_usb_send_context *pTxContext;
- PRCB pRCB;
- int ii;
+ struct vnt_rcb *pRCB;
+ int ii;
for (ii = 0; ii < pDevice->cbTD; ii++) {
@@ -811,7 +811,8 @@ static bool device_alloc_bufs(struct vnt_private *pDevice)
}
/* allocate RCB mem */
- pDevice->pRCBMem = kzalloc((sizeof(RCB) * pDevice->cbRD), GFP_KERNEL);
+ pDevice->pRCBMem = kzalloc((sizeof(struct vnt_rcb) * pDevice->cbRD),
+ GFP_KERNEL);
if (pDevice->pRCBMem == NULL) {
DBG_PRT(MSG_LEVEL_ERR,KERN_ERR "%s : alloc rx usb context failed\n", pDevice->dev->name);
goto free_tx;
@@ -822,7 +823,8 @@ static bool device_alloc_bufs(struct vnt_private *pDevice)
pDevice->FirstRecvMngList = NULL;
pDevice->LastRecvMngList = NULL;
pDevice->NumRecvFreeList = 0;
- pRCB = (PRCB) pDevice->pRCBMem;
+
+ pRCB = (struct vnt_rcb *)pDevice->pRCBMem;
for (ii = 0; ii < pDevice->cbRD; ii++) {
diff --git a/drivers/staging/vt6656/usbpipe.c b/drivers/staging/vt6656/usbpipe.c
index 78749ef..3a03f1d 100644
--- a/drivers/staging/vt6656/usbpipe.c
+++ b/drivers/staging/vt6656/usbpipe.c
@@ -421,7 +421,7 @@ static void s_nsInterruptUsbIoCompleteRead(struct urb *urb)
*
*/
-int PIPEnsBulkInUsbRead(struct vnt_private *pDevice, PRCB pRCB)
+int PIPEnsBulkInUsbRead(struct vnt_private *pDevice, struct vnt_rcb *pRCB)
{
int ntStatus = 0;
struct urb *pUrb;
@@ -479,7 +479,7 @@ int PIPEnsBulkInUsbRead(struct vnt_private *pDevice, PRCB pRCB)
static void s_nsBulkInUsbIoCompleteRead(struct urb *urb)
{
- PRCB pRCB = (PRCB)urb->context;
+ struct vnt_rcb *pRCB = (struct vnt_rcb *)urb->context;
struct vnt_private *pDevice = pRCB->pDevice;
unsigned long bytesRead;
int bIndicateReceive = false;
diff --git a/drivers/staging/vt6656/usbpipe.h b/drivers/staging/vt6656/usbpipe.h
index e2a2bce..f537703 100644
--- a/drivers/staging/vt6656/usbpipe.h
+++ b/drivers/staging/vt6656/usbpipe.h
@@ -40,7 +40,7 @@ int PIPEnsControlIn(struct vnt_private *, u8 byRequest, u16 wValue,
u16 wIndex, u16 wLength, u8 *pbyBuffer);
int PIPEnsInterruptRead(struct vnt_private *);
-int PIPEnsBulkInUsbRead(struct vnt_private *, PRCB pRCB);
+int PIPEnsBulkInUsbRead(struct vnt_private *, struct vnt_rcb *pRCB);
int PIPEnsSendBulkOut(struct vnt_private *,
struct vnt_usb_send_context *pContext);
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] cfg80211: fix potential deadlock regression
From: Maxime Bizon @ 2013-08-28 19:49 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <1370377370-23055-1-git-send-email-johannes@sipsolutions.net>
On Tue, 2013-06-04 at 22:22 +0200, Johannes Berg wrote:
> - rtnl_lock();
>
> res = device_add(&rdev->wiphy.dev);
> + if (res)
> + return res;
I just ran across a regression caused by this commit
I'm again getting uevent notifications for wireless devices that are not
yet properly registered (ENODEV on NL80211 when using sysfs phy id)
I originally fixed the bug by taking the cfg80211 mutex across the
whole registration:
commit 5a652052fedbd7869572c757dd2ffc2ed420c69d
Author: Maxime Bizon <mbizon@freebox.fr>
Date: Wed Jul 21 17:21:38 2010 +0200
cfg80211: fix race between sysfs and cfg80211
device_add() is called before adding the phy to the cfg80211 device
list.
So if a userspace program uses sysfs uevents to detect new phy
devices, and queries nl80211 to get phy info, it can get ENODEV even
though the phy exists in sysfs.
An easy workaround is to hold the cfg80211 mutex until the phy is
present in sysfs/cfg80211/debugfs.
It does not seem we can reverse the rfkill_register() and device_add()
because wiphy dev is a parent of rfkill dev.
any idea to fix this ?
Thanks,
--
Maxime
^ permalink raw reply
* [PATCH] staging: vt6656: baseband.h re: baseband.c:877:26: sparse: incorrect type in assignment (different base types)
From: Malcolm Priestley @ 2013-08-28 19:52 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: kbuild test robot, kbuild-all, linux-wireless
In-Reply-To: <20130828000913.GB22736@kroah.com>
sparse warnings: (new ones prefixed by >>)
...
>> drivers/staging/vt6656/baseband.c:877:26: sparse: incorrect type in assignment (different base types)
drivers/staging/vt6656/baseband.c:877:26: expected unsigned short [unsigned] [usertype] len
drivers/staging/vt6656/baseband.c:877:26: got restricted __le16 [usertype] <noident>
>> drivers/staging/vt6656/baseband.c:880:26: sparse: incorrect type in assignment (different base types)
drivers/staging/vt6656/baseband.c:880:26: expected unsigned short [unsigned] [usertype] len
drivers/staging/vt6656/baseband.c:880:26: got restricted __le16 [usertype] <noident>
vnt_phy_field member len should be __le16.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: kbuild-all@01.org
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/baseband.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6656/baseband.h b/drivers/staging/vt6656/baseband.h
index a8db17d..79faedf4 100644
--- a/drivers/staging/vt6656/baseband.h
+++ b/drivers/staging/vt6656/baseband.h
@@ -85,7 +85,7 @@
struct vnt_phy_field {
u8 signal;
u8 service;
- u16 len;
+ __le16 len;
} __packed;
unsigned int
--
1.8.1.2
^ permalink raw reply related
* Re: pull-request: mac80211-next 2013-08-27
From: John W. Linville @ 2013-08-28 19:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1377593792.20012.4.camel@jlt4.sipsolutions.net>
On Tue, Aug 27, 2013 at 10:56:32AM +0200, Johannes Berg wrote:
> John,
>
> And I also have some more changes for -next, just a few small fixes and
> improvements, nothing really stands out.
>
> johannes
>
>
>
> The following changes since commit 27b3eb9c06a7193bdc9800cd00764a130343bc8a:
>
> mac80211: add APIs to allow keeping connections after WoWLAN (2013-08-16 12:58:43 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git for-john
>
> for you to fetch changes up to a98655387762394371b88cdfb8215884757978ab:
>
> mac80211: fix change_interface queue assignments (2013-08-26 09:52:58 +0200)
Pulling now...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Looking for ath6kl device
From: Lorenzo Nava @ 2013-08-28 19:22 UTC (permalink / raw)
To: linux-wireless
Hi everybody,
I'm looking for a device which uses ath6kl driver. Anybody knows any
available devices with compatible chipset?
Thank you.
Cheers.
Lorenzo
^ permalink raw reply
* Re: pull-request: mac80211 2013-08-27
From: John W. Linville @ 2013-08-28 17:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1377593647.20012.2.camel@jlt4.sipsolutions.net>
On Tue, Aug 27, 2013 at 10:54:07AM +0200, Johannes Berg wrote:
> John,
>
> I know it's late, but I have one straggler for the current cycle. If you
> don't want to pull it any more, I guess it's not terribly important as
> it only affects some APs (though those are affected badly and no
> connection is possible.)
>
> This patch fixes a regression with associating to some broken APs that
> send an ECSA IE in their probe responses.
>
> johannes
>
> The following changes since commit 75a423f493ffdf741acae27bf179cd560f7813d7:
>
> mac80211: ibss: fix ignored channel parameter (2013-08-21 15:33:08 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git for-john
>
> for you to fetch changes up to d70b7616d9080ec9f868fbd31db5fd4341435d61:
>
> mac80211: ignore (E)CSA in probe response frames (2013-08-23 17:05:12 +0200)
>
> ----------------------------------------------------------------
> Johannes Berg (1):
> mac80211: ignore (E)CSA in probe response frames
>
> net/mac80211/mlme.c | 11 +++--------
> 1 file changed, 3 insertions(+), 8 deletions(-)
It looks nice to have, but not necessary for 3.11 -- I'll pull it
into wireless-next...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: 802.11p
From: Simon Wunderlich @ 2013-08-28 17:47 UTC (permalink / raw)
To: Marc Murphy; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <F690310232FDDF4AB457E8B3EF90DDE08D321AF2@MARCM-SBS2011.marcmltd.local>
[-- Attachment #1: Type: text/plain, Size: 509 bytes --]
On Wed, Aug 28, 2013 at 03:57:59PM +0000, Marc Murphy wrote:
> Yes I saw that post but no response, it was 6 weeks ago.
> I have had more success finding the source used for the GCDC and looking to see how different it is from the mainline kernel drivers.
>
> Next is to find an Atheros USB 802.11a stick to do some tests with.
If you want to use the GCDC patchset, use some Atheros Mini-PCI hardware. I'd doubt that these patches
will work with anything different from ath5k. :)
Cheers,
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: add ieee80211_iterate_active_interfaces_rtnl()
From: Johannes Berg @ 2013-08-28 17:00 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1377605145-21353-1-git-send-email-johannes@sipsolutions.net>
On Tue, 2013-08-27 at 14:05 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> If it is needed to disconnect multiple virtual interfaces after
> (WoWLAN-) suspend, the most obvious approach would be to iterate
> all interfaces by calling ieee80211_iterate_active_interfaces()
> and then call ieee80211_resume_disconnect() for each one. This
> is what the iwlmvm driver does.
Applied.
johannes
^ permalink raw reply
* RE: 802.11p
From: Marc Murphy @ 2013-08-28 15:57 UTC (permalink / raw)
To: sedat.dilek@gmail.com; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CA+icZUW4vbCfEq9-1ewe=O=fADq42y60T2P7YV4cgNBSntQ9gA@mail.gmail.com>
Yes I saw that post but no response, it was 6 weeks ago.
I have had more success finding the source used for the GCDC and looking to see how different it is from the mainline kernel drivers.
Next is to find an Atheros USB 802.11a stick to do some tests with.
Thanks
Marc
________________________________________
From: Sedat Dilek [sedat.dilek@gmail.com]
Sent: 28 August 2013 15:20
To: Marc Murphy
Cc: linux-wireless@vger.kernel.org
Subject: Re: 802.11p
On Wed, Aug 28, 2013 at 2:15 PM, Marc Murphy <marcmltd@marcm.co.uk> wrote:
> Doh ! updated now.
>
> I have had a read through the docs but there is no direct reference to 802.11p. I initially want to have a play with a couple of embedded units that I have to see if I cant send a message from one to the other but struggling to find any updated ath5 driver.
>
A few weeks ago someone asked about that constellation, check for
"802.11p and ath5k v3.10-rc1" thread on linux-wireless ML.
- Sedat -
> Thanks
> Marc
>
> ________________________________________
> From: Sedat Dilek [sedat.dilek@gmail.com]
> Sent: 28 August 2013 12:23
> To: Marc Murphy
> Cc: linux-wireless@vger.kernel.org
> Subject: Re:
>
> On Wed, Aug 28, 2013 at 1:07 PM, Marc Murphy <marcmltd@marcm.co.uk> wrote:
>> Hello,
>> I have been trawling the mailings and lots of people are asking about 802.11p and I have not managed to find a definitive push back to the mainline kernel.
>>
>
> Hi,
>
> first of all, you should set a "subject" to your email request :-).
>
> I cannot say much about 802.11p, but for first informations I
> recommend the wiki at <http://wireless.kernel.org> and have a look
> into docs section.
>
> For faster replies you can join #linux-wireless IRC channel (Freenode).
>
> - Sedat -
>
>> Is there anywhere in particular that I need to be looking to be able to get the patches so I can have a play ?
>>
>> Thanks
>> Marc--
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3.11 v2] rt2800: fix wrong TX power compensation
From: John W. Linville @ 2013-08-28 15:10 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Fabien ADAM, linux-wireless, users, Paul Menzel,
Gertjan van Wingerde
In-Reply-To: <20130827081340.GB2609@redhat.com>
I had already merged the first one, FWIW -- sorry...
On Tue, Aug 27, 2013 at 10:13:40AM +0200, Stanislaw Gruszka wrote:
> We should not do temperature compensation on devices without
> EXTERNAL_TX_ALC bit set (called DynamicTxAgcControl on vendor driver).
> Such devices can have totally bogus TSSI parameters on the EEPROM,
> but are still treated by us as valid and results in wrong TX power
> calculations.
>
> This fixes inability to connect to AP on slightly longer distance on
> some Ralink chips/devices without EXTERNAL_TX_ALC configured.
>
> Reference:
> http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/2263
>
> Reported-and-tested-by: Fabien ADAM <id2ndr@crocobox.org>
> Cc: stable@vger.kernel.org
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
> Acked-by: Paul Menzel <paulepanter@users.sourceforge.net>
> ---
> drivers/net/wireless/rt2x00/rt2800lib.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> v1 -> v2: fix changelog
>
> John,
>
> If possible this should go to 3.11, -next & cc -stable is also fine as
> usual.
>
> Note that in -next version of the patch rt2x00_eeprom_read() should
> be changed to rt2800_eeprom_read() do to commit
> 3e38d3daf881a78ac13e93504a8ac5777040797e
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> index 1f80ea5..a0119d3 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -2790,6 +2790,13 @@ static int rt2800_get_gain_calibration_delta(struct rt2x00_dev *rt2x00dev)
> int i;
>
> /*
> + * First check if temperature compensation is supported.
> + */
> + rt2x00_eeprom_read(rt2x00dev, EEPROM_NIC_CONF1, &eeprom);
> + if (!rt2x00_get_field16(eeprom, EEPROM_NIC_CONF1_EXTERNAL_TX_ALC))
> + return 0;
> +
> + /*
> * Read TSSI boundaries for temperature compensation from
> * the EEPROM.
> *
> --
> 1.7.11.7
>
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] ath9k: ar9003_eeprom.c:3618 fix variable name typo
From: John W. Linville @ 2013-08-28 15:09 UTC (permalink / raw)
To: linux-wireless; +Cc: Sujith Manoharan, John W. Linville
From: "John W. Linville" <linville@tuxdriver.com>
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c: In function 'ar9003_hw_ant_ctrl_apply':
>> drivers/net/wireless/ath/ath9k/ar9003_eeprom.c:3618: warning: 'regval' is used uninitialized in this function
It seems obvious that 'regval' should have been 'value'...
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index a6846ab..f486480 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -3615,8 +3615,8 @@ static void ar9003_hw_ant_ctrl_apply(struct ath_hw *ah, bool is2ghz)
value = ar9003_hw_ant_ctrl_common_2_get(ah, is2ghz);
if (AR_SREV_9485(ah) && common->bt_ant_diversity) {
- regval &= ~AR_SWITCH_TABLE_COM2_ALL;
- regval |= ah->config.ant_ctrl_comm2g_switch_enable;
+ value &= ~AR_SWITCH_TABLE_COM2_ALL;
+ value |= ah->config.ant_ctrl_comm2g_switch_enable;
}
REG_RMW_FIELD(ah, AR_PHY_SWITCH_COM_2, AR_SWITCH_TABLE_COM2_ALL, value);
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH] iw: Print Interworking IE details in scan results.
From: Ben Greear @ 2013-08-28 14:30 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1377678223.13797.7.camel@jlt4.sipsolutions.net>
On 08/28/2013 01:23 AM, Johannes Berg wrote:
> On Tue, 2013-08-27 at 09:07 -0700, greearb@candelatech.com wrote:
>
>> 802.11u Interworking:
>> Network Options: 0xf1
>> Network Type: 1 (Private with Guest)
>> Internet
>> ASRA
>> ESR
>> UESA
>> Venu Group: 2 (Business)
>> Venu Type: 1
>
> That should be "Venue", no?
Yes, I kept typo-ing that..I think I fixed up the code in the patch, but
will double-check.
>
>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>
> No need really, btw, this doesn't mean anything in the iw repository - I
> haven't bothered to add something (yet).
>
>> +++ b/scan.c
>> @@ -614,6 +614,69 @@ static void print_ht_capa(const uint8_t type, uint8_t len, const uint8_t *data)
>> print_ht_mcs(data + 3);
>> }
>>
>> +static const char* ntype_11u(uint8_t t) {
>
> I'd prefer kernel style with the opening brace on the next line :)
I'll fix that and re-submit the series.
Thanks,
Ben
>
> johannes
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: 802.11p
From: Sedat Dilek @ 2013-08-28 14:20 UTC (permalink / raw)
To: Marc Murphy; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <F690310232FDDF4AB457E8B3EF90DDE08D32184E@MARCM-SBS2011.marcmltd.local>
On Wed, Aug 28, 2013 at 2:15 PM, Marc Murphy <marcmltd@marcm.co.uk> wrote:
> Doh ! updated now.
>
> I have had a read through the docs but there is no direct reference to 802.11p. I initially want to have a play with a couple of embedded units that I have to see if I cant send a message from one to the other but struggling to find any updated ath5 driver.
>
A few weeks ago someone asked about that constellation, check for
"802.11p and ath5k v3.10-rc1" thread on linux-wireless ML.
- Sedat -
> Thanks
> Marc
>
> ________________________________________
> From: Sedat Dilek [sedat.dilek@gmail.com]
> Sent: 28 August 2013 12:23
> To: Marc Murphy
> Cc: linux-wireless@vger.kernel.org
> Subject: Re:
>
> On Wed, Aug 28, 2013 at 1:07 PM, Marc Murphy <marcmltd@marcm.co.uk> wrote:
>> Hello,
>> I have been trawling the mailings and lots of people are asking about 802.11p and I have not managed to find a definitive push back to the mainline kernel.
>>
>
> Hi,
>
> first of all, you should set a "subject" to your email request :-).
>
> I cannot say much about 802.11p, but for first informations I
> recommend the wiki at <http://wireless.kernel.org> and have a look
> into docs section.
>
> For faster replies you can join #linux-wireless IRC channel (Freenode).
>
> - Sedat -
>
>> Is there anywhere in particular that I need to be looking to be able to get the patches so I can have a play ?
>>
>> Thanks
>> Marc--
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 4/4] ath10k: fix issues on non-preemptible systems
From: Michal Kazior @ 2013-08-28 13:16 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <877gf6lay7.fsf@kamboji.qca.qualcomm.com>
On 28 August 2013 06:02, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>> There's another solution that I had in mind. Instead of:
>>
>> for (;;) { dequeue(z); process; }
>>
>> I did:
>>
>> q = dequeue_all(z); for (;;) { dequeue(q); process; }
>>
>> I.e. move all queued stuff at the worker entry and move it out of the
>> global queue, that can, and will be, having more stuff queued while
>> the worker does its job).
>>
>> This way workers would exit/restart more often, but from what I tested
>> it didn't really solve the problem. Given enough traffic HTC worker
>> responsible for HTT TX gets overwhelmed eventually. You could try
>> limit how many frames a worker can process during one execution, but
>> how do you guess that? This starvation depends on how fast your CPU
>> is.
>
> I think we should come up with better ways to handle this. To have a
> quota (like you mention above) would be one option. Other option would
> be to have multiple queues and some sort of priorisation or fair
> queueing.
Having quota will not help here in any way. You can re-queue a worker
after each single frame and avoid WMI starvation, however you can
still starve the rest of the system (and that can lead to system reset
via watchdog). I'm also unsure about the overhead queueing a work may
have (on a uP system without preemption in might be negligible, but
what about other systems?), so you'd have to guess the quota size or
else you'd get increased latency/overhead and perhaps slower
performance.
I believe cond_resched is a solution, not a workaround. Slow systems
without preemption need this. I wonder how other drivers got around
it? Or perhaps none of the other drivers had to deal with really
insufficient number of CPU cycles versus lots of work.
We could perhaps move workers out of HTC and have a single TX worker
in core.c for both WMI and HTT that would prioritize WMI, before
trying HTT. This could help guarantee that all beacons (which go
through WMI) are sent in a timely fashion in response to SWBA event.
But that won't fix the overall system starvation.
> And most importantly of all, we should minimise the lenght of queue we
> have inside ath10k. I'm worried that we queue way too many packets
> within ath10k right now.
Felix pointed that out quite some time ago. I would agree but I'm
affraid you'll hurt performance if you decrease the queue depth. There
seems to be some kind of latency thing going on (either on host, or on
firmware/hardware, or both combined). I tried decreasing HTT TX ring
buffer from 2048 to 256. In result on AP135 UDP TX got trimmed at
~330mbps max. Stuffing more throughput even left some idle CPU cycles.
If you consider 3x3 devices that are supposed to get you 1.3gbps, then
you apparently need that 2048 depth.
Michał.
^ permalink raw reply
* RE: 802.11p
From: Marc Murphy @ 2013-08-28 12:15 UTC (permalink / raw)
To: sedat.dilek@gmail.com; +Cc: linux-wireless@vger.kernel.org
Doh ! updated now.
I have had a read through the docs but there is no direct reference to 802.11p. I initially want to have a play with a couple of embedded units that I have to see if I cant send a message from one to the other but struggling to find any updated ath5 driver.
Thanks
Marc
________________________________________
From: Sedat Dilek [sedat.dilek@gmail.com]
Sent: 28 August 2013 12:23
To: Marc Murphy
Cc: linux-wireless@vger.kernel.org
Subject: Re:
On Wed, Aug 28, 2013 at 1:07 PM, Marc Murphy <marcmltd@marcm.co.uk> wrote:
> Hello,
> I have been trawling the mailings and lots of people are asking about 802.11p and I have not managed to find a definitive push back to the mainline kernel.
>
Hi,
first of all, you should set a "subject" to your email request :-).
I cannot say much about 802.11p, but for first informations I
recommend the wiki at <http://wireless.kernel.org> and have a look
into docs section.
For faster replies you can join #linux-wireless IRC channel (Freenode).
- Sedat -
> Is there anywhere in particular that I need to be looking to be able to get the patches so I can have a play ?
>
> Thanks
> Marc--
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox