* [PATCH 11/21] mwifiex: move del_timer_sync(scan_delay_timer) call to fix memleak
From: Bing Zhao @ 2013-07-23 2:17 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao
In-Reply-To: <1374545878-15683-1-git-send-email-bzhao@marvell.com>
From: Amitkumar Karwar <akarwar@marvell.com>
Currently it is in mwifiex_adapter_cleanup() which doesn't get
called if driver initialization is failed causing memory leak.
scan_delay_timer is initialized in mwifiex_register(), so it
should be deleted in mwifiex_unregister(). Hence it has been
moved to appropriate place.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/init.c | 7 -------
drivers/net/wireless/mwifiex/main.c | 1 +
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/init.c b/drivers/net/wireless/mwifiex/init.c
index 09c4b76..787cff8 100644
--- a/drivers/net/wireless/mwifiex/init.c
+++ b/drivers/net/wireless/mwifiex/init.c
@@ -378,18 +378,11 @@ static void mwifiex_free_lock_list(struct mwifiex_adapter *adapter)
static void
mwifiex_adapter_cleanup(struct mwifiex_adapter *adapter)
{
- int i;
-
if (!adapter) {
pr_err("%s: adapter is NULL\n", __func__);
return;
}
- for (i = 0; i < adapter->priv_num; i++) {
- if (adapter->priv[i])
- del_timer_sync(&adapter->priv[i]->scan_delay_timer);
- }
-
mwifiex_cancel_all_pending_cmd(adapter);
/* Free lock variables */
diff --git a/drivers/net/wireless/mwifiex/main.c b/drivers/net/wireless/mwifiex/main.c
index 1753431..8217368 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -197,6 +197,7 @@ static int mwifiex_unregister(struct mwifiex_adapter *adapter)
for (i = 0; i < adapter->priv_num; i++) {
if (adapter->priv[i]) {
mwifiex_free_curr_bcn(adapter->priv[i]);
+ del_timer_sync(&adapter->priv[i]->scan_delay_timer);
kfree(adapter->priv[i]);
}
}
--
1.8.2.3
^ permalink raw reply related
* [PATCH 12/21] mwifiex: remove unnecessary del_timer(cmd_timer)
From: Bing Zhao @ 2013-07-23 2:17 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao
In-Reply-To: <1374545878-15683-1-git-send-email-bzhao@marvell.com>
From: Amitkumar Karwar <akarwar@marvell.com>
It is already there in mwifiex_unregister(). So unnecessary
call in mwifiex_adapter_cleanup() is removed in this patch.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/init.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/init.c b/drivers/net/wireless/mwifiex/init.c
index 787cff8..8ff5d7b 100644
--- a/drivers/net/wireless/mwifiex/init.c
+++ b/drivers/net/wireless/mwifiex/init.c
@@ -392,8 +392,6 @@ mwifiex_adapter_cleanup(struct mwifiex_adapter *adapter)
dev_dbg(adapter->dev, "info: free cmd buffer\n");
mwifiex_free_cmd_buffer(adapter);
- del_timer(&adapter->cmd_timer);
-
dev_dbg(adapter->dev, "info: free scan table\n");
if (adapter->if_ops.cleanup_if)
--
1.8.2.3
^ permalink raw reply related
* [PATCH 09/21] mwifiex: correct max IE length check for WPS IE
From: Bing Zhao @ 2013-07-23 2:17 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao
In-Reply-To: <1374545878-15683-1-git-send-email-bzhao@marvell.com>
From: Avinash Patil <patila@marvell.com>
This patch is bug fix for an invalid boundry check for WPS IE.
We should check max IE length against defined macro; instead we were
checking it against size of pointer. Fix it.
Also move IE length check before allocation of memory.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/sta_ioctl.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/sta_ioctl.c b/drivers/net/wireless/mwifiex/sta_ioctl.c
index 206c3e0..c071ce9 100644
--- a/drivers/net/wireless/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/mwifiex/sta_ioctl.c
@@ -797,15 +797,16 @@ static int mwifiex_set_wps_ie(struct mwifiex_private *priv,
u8 *ie_data_ptr, u16 ie_len)
{
if (ie_len) {
- priv->wps_ie = kzalloc(MWIFIEX_MAX_VSIE_LEN, GFP_KERNEL);
- if (!priv->wps_ie)
- return -ENOMEM;
- if (ie_len > sizeof(priv->wps_ie)) {
+ if (ie_len > MWIFIEX_MAX_VSIE_LEN) {
dev_dbg(priv->adapter->dev,
"info: failed to copy WPS IE, too big\n");
- kfree(priv->wps_ie);
return -1;
}
+
+ priv->wps_ie = kzalloc(MWIFIEX_MAX_VSIE_LEN, GFP_KERNEL);
+ if (!priv->wps_ie)
+ return -ENOMEM;
+
memcpy(priv->wps_ie, ie_data_ptr, ie_len);
priv->wps_ie_len = ie_len;
dev_dbg(priv->adapter->dev, "cmd: Set wps_ie_len=%d IE=%#x\n",
--
1.8.2.3
^ permalink raw reply related
* [PATCH 08/21] mwifiex: support to send deauth for P2P client
From: Bing Zhao @ 2013-07-23 2:17 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao,
Stone Piao
In-Reply-To: <1374545878-15683-1-git-send-email-bzhao@marvell.com>
From: Stone Piao <piaoyun@marvell.com>
During P2P handshake, P2P client needs to send deauth after EAPOL
FAILURE to GO. We need add bss mode for P2P client when handle deauth
request.
Without this change, deauth can not be sent out from P2P client side.
Signed-off-by: Stone Piao <piaoyun@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/join.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/mwifiex/join.c b/drivers/net/wireless/mwifiex/join.c
index 1c8a771..ba043ca 100644
--- a/drivers/net/wireless/mwifiex/join.c
+++ b/drivers/net/wireless/mwifiex/join.c
@@ -1425,6 +1425,7 @@ int mwifiex_deauthenticate(struct mwifiex_private *priv, u8 *mac)
switch (priv->bss_mode) {
case NL80211_IFTYPE_STATION:
+ case NL80211_IFTYPE_P2P_CLIENT:
return mwifiex_deauthenticate_infra(priv, mac);
case NL80211_IFTYPE_ADHOC:
return mwifiex_send_cmd_sync(priv,
--
1.8.2.3
^ permalink raw reply related
* [PATCH 06/21] mwifiex: discard deauth and disassoc event during WPS session
From: Bing Zhao @ 2013-07-23 2:17 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao,
Stone Piao
In-Reply-To: <1374545878-15683-1-git-send-email-bzhao@marvell.com>
From: Stone Piao <piaoyun@marvell.com>
Some GO will send deauth or disassoc packet at the end of WPS
handshake, which causes P2P connecion failure due to the race
condition between event path and data path.
Signed-off-by: Stone Piao <piaoyun@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/sta_event.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/wireless/mwifiex/sta_event.c b/drivers/net/wireless/mwifiex/sta_event.c
index ea265ec..8b05752 100644
--- a/drivers/net/wireless/mwifiex/sta_event.c
+++ b/drivers/net/wireless/mwifiex/sta_event.c
@@ -201,6 +201,11 @@ int mwifiex_process_sta_event(struct mwifiex_private *priv)
case EVENT_DEAUTHENTICATED:
dev_dbg(adapter->dev, "event: Deauthenticated\n");
+ if (priv->wps.session_enable) {
+ dev_dbg(adapter->dev,
+ "info: receive deauth event in wps session\n");
+ break;
+ }
adapter->dbg.num_event_deauth++;
if (priv->media_connected) {
reason_code =
@@ -211,6 +216,11 @@ int mwifiex_process_sta_event(struct mwifiex_private *priv)
case EVENT_DISASSOCIATED:
dev_dbg(adapter->dev, "event: Disassociated\n");
+ if (priv->wps.session_enable) {
+ dev_dbg(adapter->dev,
+ "info: receive disassoc event in wps session\n");
+ break;
+ }
adapter->dbg.num_event_disassoc++;
if (priv->media_connected) {
reason_code =
--
1.8.2.3
^ permalink raw reply related
* [PATCH 04/21] mwifiex: delete AP TX queues when bridged packets reach threshold
From: Bing Zhao @ 2013-07-23 2:17 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao
In-Reply-To: <1374545878-15683-1-git-send-email-bzhao@marvell.com>
From: Avinash Patil <patila@marvell.com>
Delete packets from TX queues for this mwifiex_private structure
when bridged packet count reaches maximum threshold. Bridged packets
from each RA List are deleted till they fall to low threshold of 128.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/decl.h | 3 +-
drivers/net/wireless/mwifiex/init.c | 1 +
drivers/net/wireless/mwifiex/main.h | 1 +
drivers/net/wireless/mwifiex/uap_txrx.c | 66 ++++++++++++++++++++++++++++++++-
4 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/decl.h b/drivers/net/wireless/mwifiex/decl.h
index 94cc09d..a599347 100644
--- a/drivers/net/wireless/mwifiex/decl.h
+++ b/drivers/net/wireless/mwifiex/decl.h
@@ -75,7 +75,8 @@
#define MWIFIEX_BUF_FLAG_REQUEUED_PKT BIT(0)
#define MWIFIEX_BUF_FLAG_BRIDGED_PKT BIT(1)
-#define MWIFIEX_BRIDGED_PKTS_THRESHOLD 1024
+#define MWIFIEX_BRIDGED_PKTS_THR_HIGH 1024
+#define MWIFIEX_BRIDGED_PKTS_THR_LOW 128
enum mwifiex_bss_type {
MWIFIEX_BSS_TYPE_STA = 0,
diff --git a/drivers/net/wireless/mwifiex/init.c b/drivers/net/wireless/mwifiex/init.c
index 2cf8b96..09c4b76 100644
--- a/drivers/net/wireless/mwifiex/init.c
+++ b/drivers/net/wireless/mwifiex/init.c
@@ -135,6 +135,7 @@ int mwifiex_init_priv(struct mwifiex_private *priv)
priv->csa_chan = 0;
priv->csa_expire_time = 0;
+ priv->del_list_idx = 0;
return mwifiex_add_bss_prio_tbl(priv);
}
diff --git a/drivers/net/wireless/mwifiex/main.h b/drivers/net/wireless/mwifiex/main.h
index a3036d1..bb28d3d 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -515,6 +515,7 @@ struct mwifiex_private {
bool scan_aborting;
u8 csa_chan;
unsigned long csa_expire_time;
+ u8 del_list_idx;
};
enum mwifiex_ba_status {
diff --git a/drivers/net/wireless/mwifiex/uap_txrx.c b/drivers/net/wireless/mwifiex/uap_txrx.c
index 11df2b2..1cfe5a7 100644
--- a/drivers/net/wireless/mwifiex/uap_txrx.c
+++ b/drivers/net/wireless/mwifiex/uap_txrx.c
@@ -24,6 +24,69 @@
#include "11n_aggr.h"
#include "11n_rxreorder.h"
+/* This function checks if particular RA list has packets more than low bridge
+ * packet threshold and then deletes packet from this RA list.
+ * Function deletes packets from such RA list and returns true. If no such list
+ * is found, false is returned.
+ */
+static bool
+mwifiex_uap_del_tx_pkts_in_ralist(struct mwifiex_private *priv,
+ struct list_head *ra_list_head)
+{
+ struct mwifiex_ra_list_tbl *ra_list;
+ struct sk_buff *skb, *tmp;
+ bool pkt_deleted = false;
+ struct mwifiex_txinfo *tx_info;
+ struct mwifiex_adapter *adapter = priv->adapter;
+
+ list_for_each_entry(ra_list, ra_list_head, list) {
+ if (skb_queue_empty(&ra_list->skb_head))
+ continue;
+
+ skb_queue_walk_safe(&ra_list->skb_head, skb, tmp) {
+ tx_info = MWIFIEX_SKB_TXCB(skb);
+ if (tx_info->flags & MWIFIEX_BUF_FLAG_BRIDGED_PKT) {
+ __skb_unlink(skb, &ra_list->skb_head);
+ mwifiex_write_data_complete(adapter, skb, 0,
+ -1);
+ atomic_dec(&priv->wmm.tx_pkts_queued);
+ pkt_deleted = true;
+ }
+ if ((atomic_read(&adapter->pending_bridged_pkts) <=
+ MWIFIEX_BRIDGED_PKTS_THR_LOW))
+ break;
+ }
+ }
+
+ return pkt_deleted;
+}
+
+/* This function deletes packets from particular RA List. RA list index
+ * from which packets are deleted is preserved so that packets from next RA
+ * list are deleted upon subsequent call thus maintaining fairness.
+ */
+static void mwifiex_uap_cleanup_tx_queues(struct mwifiex_private *priv)
+{
+ unsigned long flags;
+ struct list_head *ra_list;
+ int i;
+
+ spin_lock_irqsave(&priv->wmm.ra_list_spinlock, flags);
+
+ for (i = 0; i < MAX_NUM_TID; i++, priv->del_list_idx++) {
+ if (priv->del_list_idx == MAX_NUM_TID)
+ priv->del_list_idx = 0;
+ ra_list = &priv->wmm.tid_tbl_ptr[priv->del_list_idx].ra_list;
+ if (mwifiex_uap_del_tx_pkts_in_ralist(priv, ra_list)) {
+ priv->del_list_idx++;
+ break;
+ }
+ }
+
+ spin_unlock_irqrestore(&priv->wmm.ra_list_spinlock, flags);
+}
+
+
static void mwifiex_uap_queue_bridged_pkt(struct mwifiex_private *priv,
struct sk_buff *skb)
{
@@ -40,10 +103,11 @@ static void mwifiex_uap_queue_bridged_pkt(struct mwifiex_private *priv,
rx_pkt_hdr = (void *)uap_rx_pd + le16_to_cpu(uap_rx_pd->rx_pkt_offset);
if ((atomic_read(&adapter->pending_bridged_pkts) >=
- MWIFIEX_BRIDGED_PKTS_THRESHOLD)) {
+ MWIFIEX_BRIDGED_PKTS_THR_HIGH)) {
dev_err(priv->adapter->dev,
"Tx: Bridge packet limit reached. Drop packet!\n");
kfree_skb(skb);
+ mwifiex_uap_cleanup_tx_queues(priv);
return;
}
--
1.8.2.3
^ permalink raw reply related
* [PATCH 03/21] mwifiex: maintain outstanding packet count for RA list instead of packet size
From: Bing Zhao @ 2013-07-23 2:17 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao
In-Reply-To: <1374545878-15683-1-git-send-email-bzhao@marvell.com>
From: Avinash Patil <patila@marvell.com>
Maintain total outstanding packet count for RA list instead of total
outstanding size as packet count metric seems more reasonable for
checking threshold etc.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/11n_aggr.c | 4 ++--
drivers/net/wireless/mwifiex/main.h | 2 +-
drivers/net/wireless/mwifiex/wmm.c | 8 ++++----
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/11n_aggr.c b/drivers/net/wireless/mwifiex/11n_aggr.c
index a78e065..8f9f542 100644
--- a/drivers/net/wireless/mwifiex/11n_aggr.c
+++ b/drivers/net/wireless/mwifiex/11n_aggr.c
@@ -189,7 +189,7 @@ mwifiex_11n_aggregate_pkt(struct mwifiex_private *priv,
skb_src = skb_dequeue(&pra_list->skb_head);
- pra_list->total_pkts_size -= skb_src->len;
+ pra_list->total_pkt_count--;
atomic_dec(&priv->wmm.tx_pkts_queued);
@@ -268,7 +268,7 @@ mwifiex_11n_aggregate_pkt(struct mwifiex_private *priv,
skb_queue_tail(&pra_list->skb_head, skb_aggr);
- pra_list->total_pkts_size += skb_aggr->len;
+ pra_list->total_pkt_count++;
atomic_inc(&priv->wmm.tx_pkts_queued);
diff --git a/drivers/net/wireless/mwifiex/main.h b/drivers/net/wireless/mwifiex/main.h
index 884b42b..a3036d1 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -204,11 +204,11 @@ struct mwifiex_ra_list_tbl {
struct list_head list;
struct sk_buff_head skb_head;
u8 ra[ETH_ALEN];
- u32 total_pkts_size;
u32 is_11n_enabled;
u16 max_amsdu;
u16 ba_pkt_count;
u8 ba_packet_thr;
+ u16 total_pkt_count;
};
struct mwifiex_tid_tbl {
diff --git a/drivers/net/wireless/mwifiex/wmm.c b/drivers/net/wireless/mwifiex/wmm.c
index 9c1eeee..2e8f9cd 100644
--- a/drivers/net/wireless/mwifiex/wmm.c
+++ b/drivers/net/wireless/mwifiex/wmm.c
@@ -120,7 +120,7 @@ mwifiex_wmm_allocate_ralist_node(struct mwifiex_adapter *adapter, u8 *ra)
memcpy(ra_list->ra, ra, ETH_ALEN);
- ra_list->total_pkts_size = 0;
+ ra_list->total_pkt_count = 0;
dev_dbg(adapter->dev, "info: allocated ra_list %p\n", ra_list);
@@ -679,8 +679,8 @@ mwifiex_wmm_add_buf_txqueue(struct mwifiex_private *priv,
skb_queue_tail(&ra_list->skb_head, skb);
- ra_list->total_pkts_size += skb->len;
ra_list->ba_pkt_count++;
+ ra_list->total_pkt_count++;
if (atomic_read(&priv->wmm.highest_queued_prio) <
tos_to_tid_inv[tid_down])
@@ -1037,7 +1037,7 @@ mwifiex_send_single_packet(struct mwifiex_private *priv,
tx_info = MWIFIEX_SKB_TXCB(skb);
dev_dbg(adapter->dev, "data: dequeuing the packet %p %p\n", ptr, skb);
- ptr->total_pkts_size -= skb->len;
+ ptr->total_pkt_count--;
if (!skb_queue_empty(&ptr->skb_head))
skb_next = skb_peek(&ptr->skb_head);
@@ -1062,7 +1062,7 @@ mwifiex_send_single_packet(struct mwifiex_private *priv,
skb_queue_tail(&ptr->skb_head, skb);
- ptr->total_pkts_size += skb->len;
+ ptr->total_pkt_count++;
ptr->ba_pkt_count++;
tx_info->flags |= MWIFIEX_BUF_FLAG_REQUEUED_PKT;
spin_unlock_irqrestore(&priv->wmm.ra_list_spinlock,
--
1.8.2.3
^ permalink raw reply related
* [PATCH 00/21] mwifiex updates for 3.12
From: Bing Zhao @ 2013-07-23 2:17 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao
This series includes error case handling, bridged packet handling
in AP mode, p2p updates, random cleanups, etc.
Amitkumar Karwar (11):
mwifiex: add PCIe shutdown handler to avoid system hang on reboot
mwifiex: move del_timer_sync(scan_delay_timer) call to fix memleak
mwifiex: remove unnecessary del_timer(cmd_timer)
mwifiex: move if_ops.cleanup_if() call
mwifiex: add unregister_dev handler for usb interface
mwifiex: reduce firmware poll retries
mwifiex: replace mdelay with msleep
mwifiex: correction in mwifiex_check_fw_status() return status
mwifiex: handle driver initialization error paths
mwifiex: code rearrangement in sdio.c
mwifiex: remove duplicate structure host_cmd_tlv
Avinash Patil (5):
mwifiex: rename pkt_count to ba_pkt_count in mwifiex_ra_list_tbl
struct
mwifiex: maintain outstanding packet count for RA list instead of
packet size
mwifiex: delete AP TX queues when bridged packets reach threshold
mwifiex: correct max IE length check for WPS IE
mwifiex: modify mwifiex_ap_sta_limits to advertise support for P2P
Huawei Yang (2):
mwifiex: remove stop_net_dev_queue operation in AP forwarding
mwifiex: add tx info to skb when forming mgmt frame
Stone Piao (3):
mwifiex: discard deauth and disassoc event during WPS session
mwifiex: skip registering mgmt frame that has already registered
mwifiex: support to send deauth for P2P client
drivers/net/wireless/mwifiex/11n_aggr.c | 4 +-
drivers/net/wireless/mwifiex/cfg80211.c | 25 +++-
drivers/net/wireless/mwifiex/decl.h | 3 +-
drivers/net/wireless/mwifiex/fw.h | 44 +++----
drivers/net/wireless/mwifiex/ie.c | 2 +-
drivers/net/wireless/mwifiex/init.c | 14 +-
drivers/net/wireless/mwifiex/join.c | 1 +
drivers/net/wireless/mwifiex/main.c | 87 +++++++++----
drivers/net/wireless/mwifiex/main.h | 6 +-
drivers/net/wireless/mwifiex/pcie.c | 13 +-
drivers/net/wireless/mwifiex/sdio.c | 213 +++++++++++++++----------------
drivers/net/wireless/mwifiex/sta_cmd.c | 5 +-
drivers/net/wireless/mwifiex/sta_event.c | 10 ++
drivers/net/wireless/mwifiex/sta_ioctl.c | 11 +-
drivers/net/wireless/mwifiex/uap_cmd.c | 130 ++++++++++---------
drivers/net/wireless/mwifiex/uap_txrx.c | 70 +++++++++-
drivers/net/wireless/mwifiex/usb.c | 8 ++
drivers/net/wireless/mwifiex/wmm.c | 16 +--
18 files changed, 390 insertions(+), 272 deletions(-)
--
1.8.2.3
^ permalink raw reply
* [PATCH 01/21] mwifiex: remove stop_net_dev_queue operation in AP forwarding
From: Bing Zhao @ 2013-07-23 2:17 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao,
Huawei Yang
In-Reply-To: <1374545878-15683-1-git-send-email-bzhao@marvell.com>
From: Huawei Yang <harvey.huawei.yang@gmail.com>
Under uAP mode mwifiex may stop all net tx queues on forwarding
packets. This may stop some tx queues and they never have chance
to be waked up. There is also no need to check tx_pending and
stop queues here. Because local host has such kind of check when
transmitting packets and it's not proper to have forwarding affect
local transmitting.
Signed-off-by: Huawei Yang <harvey.huawei.yang@gmail.com>
Reviewed-by: Avinash Patil <patila@marvell.com>
Acked-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/uap_txrx.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/uap_txrx.c b/drivers/net/wireless/mwifiex/uap_txrx.c
index a018e42..11df2b2 100644
--- a/drivers/net/wireless/mwifiex/uap_txrx.c
+++ b/drivers/net/wireless/mwifiex/uap_txrx.c
@@ -95,10 +95,6 @@ static void mwifiex_uap_queue_bridged_pkt(struct mwifiex_private *priv,
atomic_inc(&adapter->tx_pending);
atomic_inc(&adapter->pending_bridged_pkts);
- if ((atomic_read(&adapter->tx_pending) >= MAX_TX_PENDING)) {
- mwifiex_set_trans_start(priv->netdev);
- mwifiex_stop_net_dev_queue(priv->netdev, priv->adapter);
- }
return;
}
--
1.8.2.3
^ permalink raw reply related
* [PATCH 05/21] mwifiex: add tx info to skb when forming mgmt frame
From: Bing Zhao @ 2013-07-23 2:17 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao,
Huawei Yang, Stone Piao
In-Reply-To: <1374545878-15683-1-git-send-email-bzhao@marvell.com>
From: Huawei Yang <harvey.huawei.yang@gmail.com>
In function 'mwifiex_write_data_complete' it need tx info to find
the mwifiex_private to updates statistics and wake up tx queues.
Or we may trigger tx queues timeout when transmitting lots of mgmt
frames.
Signed-off-by: Huawei Yang <harvey.huawei.yang@gmail.com>
Signed-off-by: Stone Piao <piaoyun@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/cfg80211.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c b/drivers/net/wireless/mwifiex/cfg80211.c
index ef5fa89..d824fee 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -189,6 +189,7 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
struct sk_buff *skb;
u16 pkt_len;
const struct ieee80211_mgmt *mgmt;
+ struct mwifiex_txinfo *tx_info;
struct mwifiex_private *priv = mwifiex_netdev_get_priv(wdev->netdev);
if (!buf || !len) {
@@ -216,6 +217,10 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
return -ENOMEM;
}
+ tx_info = MWIFIEX_SKB_TXCB(skb);
+ tx_info->bss_num = priv->bss_num;
+ tx_info->bss_type = priv->bss_type;
+
mwifiex_form_mgmt_frame(skb, buf, len);
mwifiex_queue_tx_pkt(priv, skb);
--
1.8.2.3
^ permalink raw reply related
* [PATCH 02/21] mwifiex: rename pkt_count to ba_pkt_count in mwifiex_ra_list_tbl struct
From: Bing Zhao @ 2013-07-23 2:17 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Bing Zhao
In-Reply-To: <1374545878-15683-1-git-send-email-bzhao@marvell.com>
From: Avinash Patil <patila@marvell.com>
pkt_count is used to determine if BA can be formed on this RA list
by comparing it with randomly generated BA threshold. The pkt_count
variable name here is ambiguous and does not reflect its usage
correctly. Rename it to ba_pkt_count.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/main.h | 2 +-
drivers/net/wireless/mwifiex/wmm.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/main.h b/drivers/net/wireless/mwifiex/main.h
index 253e0bd..884b42b 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -207,7 +207,7 @@ struct mwifiex_ra_list_tbl {
u32 total_pkts_size;
u32 is_11n_enabled;
u16 max_amsdu;
- u16 pkt_count;
+ u16 ba_pkt_count;
u8 ba_packet_thr;
};
diff --git a/drivers/net/wireless/mwifiex/wmm.c b/drivers/net/wireless/mwifiex/wmm.c
index 944e884..9c1eeee 100644
--- a/drivers/net/wireless/mwifiex/wmm.c
+++ b/drivers/net/wireless/mwifiex/wmm.c
@@ -188,7 +188,7 @@ mwifiex_ralist_add(struct mwifiex_private *priv, u8 *ra)
ra_list, ra_list->is_11n_enabled);
if (ra_list->is_11n_enabled) {
- ra_list->pkt_count = 0;
+ ra_list->ba_pkt_count = 0;
ra_list->ba_packet_thr =
mwifiex_get_random_ba_threshold();
}
@@ -680,7 +680,7 @@ mwifiex_wmm_add_buf_txqueue(struct mwifiex_private *priv,
skb_queue_tail(&ra_list->skb_head, skb);
ra_list->total_pkts_size += skb->len;
- ra_list->pkt_count++;
+ ra_list->ba_pkt_count++;
if (atomic_read(&priv->wmm.highest_queued_prio) <
tos_to_tid_inv[tid_down])
@@ -1063,7 +1063,7 @@ mwifiex_send_single_packet(struct mwifiex_private *priv,
skb_queue_tail(&ptr->skb_head, skb);
ptr->total_pkts_size += skb->len;
- ptr->pkt_count++;
+ ptr->ba_pkt_count++;
tx_info->flags |= MWIFIEX_BUF_FLAG_REQUEUED_PKT;
spin_unlock_irqrestore(&priv->wmm.ra_list_spinlock,
ra_list_flags);
@@ -1224,7 +1224,7 @@ mwifiex_dequeue_tx_packet(struct mwifiex_adapter *adapter)
mwifiex_send_single_packet() */
} else {
if (mwifiex_is_ampdu_allowed(priv, tid) &&
- ptr->pkt_count > ptr->ba_packet_thr) {
+ ptr->ba_pkt_count > ptr->ba_packet_thr) {
if (mwifiex_space_avail_for_new_ba_stream(adapter)) {
mwifiex_create_ba_tbl(priv, ptr->ra, tid,
BA_SETUP_INPROGRESS);
--
1.8.2.3
^ permalink raw reply related
* Re: IEEE VHT80 802.11 channels
From: Luis R. Rodriguez @ 2013-07-22 22:04 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Bitterli, wireless-regdb@lists.infradead.org
In-Reply-To: <CAB=NE6X0vJ4Ts6p8M3i9GyZPCY6Gf6ztCdWvhdsVySO+4CL7pg@mail.gmail.com>
On Wed, Jul 3, 2013 at 12:05 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> We reviewed a while ago how we'd enable VHT80 channels and decided to
> go with a scaping of the regulatory data even though IEEE defined very
> specific channels. I hadn't seen a list with these center of freq IEEE
> channels so I figured I'd post them. As far as I can tell I see these
> defined. Whether or not you can use them will vary depending on your
> country's regulatory rules.
>
> 5210, 5290, 5530, 5610, 5610, 5690, 5775
The below extended map may help and could also be used to help
understand the corner case of VHT80 support on VHT80 center of freq
5690 MHz.
IEEE VHT80 center of freqs possible:
Center 20 MHz channels ath10k capable
__________ __________ __________ __________
/ \/ \/ \/ \
5210 5180 (36) 5200 (40) 5220 (44) 5240 (48) OK
5290 5260 (52) 5280 (56) 5300 (60) 5320 (64) OK
5530 5500 (100) 5520 (104) 5540 (108) 5560 (112) OK
5610 5580 (116) 5600 (120) 5620 (124) 5640 (128) OK
5690 5660 (132) 5680 (136) 5700 (140) 5720 (144)* Nope
5775 5745 (149) 5765 (153) 5785 (157) 5805 (161) OK
Other vendor should consider reviewing their own implementation /
support / regulatory considerations / preferences for collateral of
not having a 20 MHz IEEE channel at center of freq 5720 (144) before.
I'll be pushing out how we address this next.
Luis
^ permalink raw reply
* Re: FUSB200 xhci issue
From: Christian Lamparter @ 2013-07-22 21:23 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: linux-wireless, Sarah Sharp, Seth Forshee
In-Reply-To: <51ED9A6D.4070900@rempel-privat.de>
On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote:
> Am 22.07.2013 21:54, schrieb Christian Lamparter:
> > Hello!
> >
> > On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
> >> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of
> >> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i
> >> accidentally discovered that 9170 have it too. Are there any issue with
> >> usb-suspend + xhci controllers by you? Did you some how specially
> >> handled it?
> >
> > No, I haven't heard any complains about xhci + suspend. In fact,
> > it's working fine with the NEC xhci I have. I also have a AR9271
> > and AR7010, so if you want I could try if they survive a suspend
> > +resume cycle when attached.
> >
> > But, I do have a bug-report from someone else who has/had? problems
> > with carl9170 and xhci. If you want, you can get the details from:
> > "carl9170 A-MPDU transmit problem":
> > <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>
> >
> > The likely cause is related to Intel's xhci silicon (Ivy Bridge is
> > affected, but I don't know about Haswell):
> > <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>
>
> Same situation is here - i have problem on Ivy Bridge.
(Note: I don't have any Ivy Bridge system. Just Sandy Bridge
and AMD's new A6-1450 Temash and both xhci work. So I can't
do any proper comparisons like you.)
> Steps to reproduce:
> - plug adapter. Module and firmware will be loaded
> - make sure usb autosupend is enabled. By default it is not! Use
> powertop or directly sysfs to enable autosuspend for this device
> - rmmod .... and wait some seconds until adapter is suspended and then
> modprobe ath9k_htc
>
> first packet which is bigger as 64Byte will kill EP4 FIFO. Size register
> will report wrong size.. bigger as FIFO can handle. And only first ~40
> readet bytes will be actually OK.. all the rest of packet will be trashed.
This is what happens with a WN721 (ar9271):
[17619.597905] usbcore: deregistering interface driver ath9k_htc
[17619.679549] usb 2-2: ath9k_htc: USB layer deinitialized
[17619.679602] ath9k_htc: Driver unloaded
<suspend>
<resume>
[17667.543024] usb 2-2: reset high-speed USB device number 3 using xhci_hcd <----
[17667.572168] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77600
[17667.572174] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77640
[17667.572177] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77680
[17667.572180] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa776c0
[17667.572183] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77700
[17667.572185] xhci_hcd 0000:19:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88031aa77740
[17667.573826] usb 2-2: ath9k_htc: Firmware htc_9271.fw requested
[17667.573873] usbcore: registered new interface driver ath9k_htc
[17668.038200] usb 2-2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
[17668.273249] ath9k_htc 2-2:1.0: ath9k_htc: HTC initialized with 33 credits
The driver loads, but there's no "wlanX" interface, no phyX interface
and the driver can't be unloaded due to "Error: Module ath9k_htc is in use".
Regards
Christian
^ permalink raw reply
* Re: FUSB200 xhci issue
From: Oleksij Rempel @ 2013-07-22 20:47 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Sarah Sharp, Seth Forshee
In-Reply-To: <1559414.LIxku4Z5O8@blech>
Am 22.07.2013 21:54, schrieb Christian Lamparter:
> Hello!
>
> On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
>> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of
>> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i
>> accidentally discovered that 9170 have it too. Are there any issue with
>> usb-suspend + xhci controllers by you? Did you some how specially
>> handled it?
>
> No, I haven't heard any complains about xhci + suspend. In fact,
> it's working fine with the NEC xhci I have. I also have a AR9271
> and AR7010, so if you want I could try if they survive a suspend
> +resume cycle when attached.
>
> But, I do have a bug-report from someone else who has/had? problems
> with carl9170 and xhci. If you want, you can get the details from:
> "carl9170 A-MPDU transmit problem":
> <http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>
>
> The likely cause is related to Intel's xhci silicon (Ivy Bridge is
> affected, but I don't know about Haswell):
> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>
Same situation is here - i have problem on Ivy Bridge.
Steps to reproduce:
- plug adapter. Module and firmware will be loaded
- make sure usb autosupend is enabled. By default it is not! Use
powertop or directly sysfs to enable autosuspend for this device
- rmmod .... and wait some seconds until adapter is suspended and then
modprobe ath9k_htc
first packet which is bigger as 64Byte will kill EP4 FIFO. Size register
will report wrong size.. bigger as FIFO can handle. And only first ~40
readet bytes will be actually OK.. all the rest of packet will be trashed.
But... i'm not 100% sure, if the FIFO as actually over filled, or host
controller sending brocken data, or wrong timing...
There are flawing workarounds:
- reload xhci_hcd module.
- do USB_PHY reset, from firmware.
- use other host controller
It will be good if you can test it on you NEX xhci.
>
> However, I haven't heard back from Sarah or Seth about this matter
> (Added them to the CC. so "PLEASE" join if either of you think to
> have something to add about carl9170 transmit problem or ath9k_htc's
> suspend issue... of course, if it was fixed, then it would be really
> great to know which commit "fixed it"...)
>
> Regards
>
> Christian
--
Regards,
Oleksij
^ permalink raw reply
* Re: Dokumentation Athros Chips
From: Christian Lamparter @ 2013-07-22 20:25 UTC (permalink / raw)
To: Maximilian Kürth; +Cc: linux-wireless
In-Reply-To: <2515287.MZDuQ7LknB@w0rk0n>
Hello,
On Monday, July 22, 2013 10:02:33 PM Maximilian Kürth wrote:
> i need documentation about AR9104 and AR9170 for a work on TL-WN822N (v1).
> If anyone got hands on them and could pass it to me, i would be very pleased.
You should be able to get the documentations directly from Qualcomm Atheros (QCA).
Yup, QCA provides access to documentation, source code and hardware for
developers who wish to work with them on improving their open source
support through "Qualcomm Atheros' open source NDA" program.
I don't know who handles new applications, but <mcgrof@qca.qualcomm.com>
should be able to point you into the right direction with this.
Of course, if you have any specific questions about the driver
(and the hardware) you can always ask them on this ML and we tell
you what we know (no NDA necessary here ;-) ).
Regards
Christian
^ permalink raw reply
* Re: pull-request: iwlwifi-fixes 2013-07-22
From: John W. Linville @ 2013-07-22 20:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1374494473.14517.8.camel@jlt4.sipsolutions.net>
On Mon, Jul 22, 2013 at 02:01:13PM +0200, Johannes Berg wrote:
> John,
>
> And another one for iwlwifi.
>
> Here I have a fix for debugfs directory creation (causing a spurious
> error message), two scanning fixes from David Spinadel, an LED fix and
> two patches related to a BA session problem that eventually caused
> firmware crashes from Emmanuel and a small BT fix for older devices as
> well as a workaround for a firmware problem with APs with very small
> beacon intervals from myself.
>
> Let me know if there's any problem.
>
> johannes
>
> The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:
>
> Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git for-john
>
> for you to fetch changes up to a590ad411891de551e6de1b51ea635c0484148d6:
>
> iwlwifi: mvm: remove extra SSID from probe request (2013-07-16 13:55:15 +0300)
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
* Re: pull-request: 2013-07-22
From: John W. Linville @ 2013-07-22 20:01 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1374494325.14517.4.camel@jlt4.sipsolutions.net>
On Mon, Jul 22, 2013 at 01:58:45PM +0200, Johannes Berg wrote:
> John,
>
> Here's a pull request for 3.11 (and some fixes with cc stable), sorry
> for the delay - I was travelling.
>
> Here I have a fix for RSSI thresholds in mesh, two minstrel fixes from
> Felix, an nl80211 fix from Michal and four various fixes I did myself.
>
> Let me know if there's any problem.
>
> johannes
>
>
>
> The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092:
>
> Linux 3.11-rc1 (2013-07-14 15:18:27 -0700)
>
> 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 5c9fc93bc9bc417418fc1b6366833ae6a07b804d:
>
> mac80211/minstrel: fix NULL pointer dereference issue (2013-07-16 17:48:14 +0300)
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
* Dokumentation Athros Chips
From: Maximilian Kürth @ 2013-07-22 20:02 UTC (permalink / raw)
To: linux-wireless
Hello guys,
i need documentation about AR9104 and AR9170 for a work on TL-WN822N (v1).
If anyone got hands on them and could pass it to me, i would be very pleased.
Best regards
^ permalink raw reply
* Re: FUSB200 xhci issue
From: Christian Lamparter @ 2013-07-22 19:54 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: linux-wireless, Sarah Sharp, Seth Forshee
In-Reply-To: <51ED4E12.8030006@rempel-privat.de>
Hello!
On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote:
> i'm one of ath9k_htc devs. Currently i'm working on usb_suspend issue of
> this adapters. Looks like ar9271 and ar7010 have FUSB200, and i
> accidentally discovered that 9170 have it too. Are there any issue with
> usb-suspend + xhci controllers by you? Did you some how specially
> handled it?
No, I haven't heard any complains about xhci + suspend. In fact,
it's working fine with the NEC xhci I have. I also have a AR9271
and AR7010, so if you want I could try if they survive a suspend
+resume cycle when attached.
But, I do have a bug-report from someone else who has/had? problems
with carl9170 and xhci. If you want, you can get the details from:
"carl9170 A-MPDU transmit problem":
<http://comments.gmane.org/gmane.linux.kernel.wireless.general/104597>
The likely cause is related to Intel's xhci silicon (Ivy Bridge is
affected, but I don't know about Haswell):
<http://permalink.gmane.org/gmane.linux.kernel.wireless.general/104602>
However, I haven't heard back from Sarah or Seth about this matter
(Added them to the CC. so "PLEASE" join if either of you think to
have something to add about carl9170 transmit problem or ath9k_htc's
suspend issue... of course, if it was fixed, then it would be really
great to know which commit "fixed it"...)
Regards
Christian
^ permalink raw reply
* Re: [BUG] 3.10 regression: hang on suspend
From: Ortwin Glück @ 2013-07-22 19:05 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Arend van Spriel, linux-kernel, linux-wireless
In-Reply-To: <20130722112236.GA7364@redhat.com>
On 07/22/2013 01:22 PM, Stanislaw Gruszka wrote:
> We remove interface that we do not add in the driver. I think I found
> reason of that - I removed below code in bad commit:
>
> list_for_each_entry(sdata, &local->interfaces, list) {
> [snip]
> - switch (sdata->vif.type) {
> - case NL80211_IFTYPE_AP_VLAN:
> - case NL80211_IFTYPE_MONITOR:
> - /* skip these */
> - continue;
Oh yes, that makes a lot of sense! I have an extra monitoring interface
configured. If I remove that before suspend, the crash does not occur.
And your patch does fix the problem. Very nice!
Thank you,
Ortwin
^ permalink raw reply
* [PATCH V2 for-3.11 1/2] brcmfmac: decrement pending 8021x count upon tx failure
From: Arend van Spriel @ 2013-07-22 18:31 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1374489984-18250-2-git-send-email-arend@broadcom.com>
If the transmit fails because there are no hanger slots or
any other reason and the packet was an EAPOL packet the
pending counter should be decreased although it was not
transmitted so the driver does not end up in a dead-lock.
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
---
Fixed typo in commit message: coutner -> counter.
Replaces patch with:
Message-ID: <1374489984-18250-2-git-send-email-arend@broadcom.com>
Regards,
Arend
---
drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c b/drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c
index f0d9f7f..29b1f24 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c
@@ -1744,13 +1744,14 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, struct sk_buff *skb)
ulong flags;
int fifo = BRCMF_FWS_FIFO_BCMC;
bool multicast = is_multicast_ether_addr(eh->h_dest);
+ bool pae = eh->h_proto == htons(ETH_P_PAE);
/* determine the priority */
if (!skb->priority)
skb->priority = cfg80211_classify8021d(skb);
drvr->tx_multicast += !!multicast;
- if (ntohs(eh->h_proto) == ETH_P_PAE)
+ if (pae)
atomic_inc(&ifp->pend_8021x_cnt);
if (!brcmf_fws_fc_active(fws)) {
@@ -1781,6 +1782,11 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, struct sk_buff *skb)
brcmf_fws_schedule_deq(fws);
} else {
brcmf_err("drop skb: no hanger slot\n");
+ if (pae) {
+ atomic_dec(&ifp->pend_8021x_cnt);
+ if (waitqueue_active(&ifp->pend_8021x_wait))
+ wake_up(&ifp->pend_8021x_wait);
+ }
brcmu_pkt_buf_free_skb(skb);
}
brcmf_fws_unlock(drvr, flags);
--
1.7.10.4
^ permalink raw reply related
* Re: So, which IEEE<->Frequency mappings should we be all using?
From: Adrian Chadd @ 2013-07-22 17:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: freebsd-wireless, linux-wireless
In-Reply-To: <1374504059.14517.12.camel@jlt4.sipsolutions.net>
Well, the UHF stuff is available now and vendors are making cards for
them. I'm happy just mapping them to 2.4GHz channels for now but it
severely restricts the channels (ie, spacing/width) we can use in that
range.
adrian
On 22 July 2013 07:40, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Wed, 2013-07-17 at 10:42 -0700, Adrian Chadd wrote:
>
>> * 420MHz
>> * 700MHz
>> * 900MHz (which we already have, due to history);
>> * 3.6GHz
>> * 4.9GHz
>
> 3.6 should have been defined in the spec recently, 4.9 surely is defined
> already (though the whole stack will have to support the
> dot11ChannelStartingFactor)
>
> The others are kinda non-standard extensions, and you probably won't
> even be able to properly support them since they're kinda
> pretend-handled like 2.4 GHz.
>
> johannes
>
^ permalink raw reply
* Re: [PATCH 1/2] MAINTAINERS: add ath10k
From: Joe Perches @ 2013-07-22 17:04 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, ath10k
In-Reply-To: <87zjtewmzg.fsf@kamboji.qca.qualcomm.com>
On Mon, 2013-07-22 at 19:58 +0300, Kalle Valo wrote:
> Joe Perches <joe@perches.com> writes:
>
> > On Mon, 2013-07-22 at 12:32 +0300, Kalle Valo wrote:
> >> I forgot to add an entry to MAINTAINERS when submitting the driver.
> > []
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> > []
> >> +QUALCOMM ATHEROS ATH10K WIRELESS DRIVER
> >
> > It's odd to not find ATH6KL next to ATH10K.
>
> I was wondering the same, but decided to put the entries in alphabetical
> order still.
>
> > Maybe it's time to rename all the ATH sections
> > to make them QUALCOMM?
>
> Maybe, but does it really matter?
Only to those that actually read the MAINTAINERS
file instead of using tools to search it.
> Changing the MAINTAINERS file just
> creates unnecessary conficts for git merges.
Those are always trivially resolved if they
ever really occur.
It's not a big deal, just wanted to note it.
^ permalink raw reply
* Re: [PATCH 1/2] MAINTAINERS: add ath10k
From: Kalle Valo @ 2013-07-22 16:58 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-wireless, ath10k
In-Reply-To: <1374504278.2061.35.camel@joe-AO722>
Joe Perches <joe@perches.com> writes:
> On Mon, 2013-07-22 at 12:32 +0300, Kalle Valo wrote:
>> I forgot to add an entry to MAINTAINERS when submitting the driver.
> []
>> diff --git a/MAINTAINERS b/MAINTAINERS
> []
>> +QUALCOMM ATHEROS ATH10K WIRELESS DRIVER
>
> It's odd to not find ATH6KL next to ATH10K.
I was wondering the same, but decided to put the entries in alphabetical
order still.
> Maybe it's time to rename all the ATH sections
> to make them QUALCOMM?
Maybe, but does it really matter? Changing the MAINTAINERS file just
creates unnecessary conficts for git merges.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath: wil6210: Fix build error
From: Luis R. Rodriguez @ 2013-07-22 16:17 UTC (permalink / raw)
To: Vladimir Kondratiev
Cc: Larry Finger, linville, linux-wireless, netdev, wil6210, Stable,
Thomas Fjellstrom
In-Reply-To: <1958736.oRuXAUfNGd@lx-vladimir>
On Sun, Jul 21, 2013 at 10:06:31AM +0300, Vladimir Kondratiev wrote:
> Hmm, I have no warning for this with neither 3.10 nor 3.11 kernel version; but
> patch is correct, and here is my
> Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
If you agree with a patch you don't say you Sign-off-by it as well,
you say Acked-by. The Signed-off-by tag has a very specific meaning
from development to a maintainer's hands, and its definition is on
the Developer Certificate or Origin.
So in this case Acked-by is better.
Luis
^ 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