Re: mwifiex: fix a reversed condition

[Kalle Valo]

> The NULL test here is reversed.
> 
> Fixes: 7d7f07d8c5d3 ('mwifiex: add wowlan net-detect support')
> Signed-off-by: Dan Carpenter 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v3,1/6] libertas: fix pointer bugs for PS_MODE commands

[Kalle Valo]

> struct cmd_ds_802_11_ps_mode
> contains the command header and a pointer to it was
> initialized with data points to the body which leads to
> mis-interpretation of the cmd_ds_802_11_ps_mode.action member.
> cmd[0] contains the header, [1] points beyond that.
> cmdnode->cmdbuf is a pointer to the command buffer
> This piece of code was unused since power saving was
> not enabled.
> 
> Signed-off-by: Andreas Kemnade 

Thanks, 6 patches applied to wireless-drivers-next.git:

0a7701b4defc libertas: fix pointer bugs for PS_MODE commands
fae4f9f78ab1 libertas: check whether bus can do more than polling
57954b94cad7 libertas: do not confirm sleep if commands are pending
fada24a54770 libertas: go back to ps mode without commands pending
0b8802dc5f59 libertas: fix ps-mode related removal problems
143e49458424 libertas: add an cfg80211 interface for powersaving

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [1/3] net: wireless: rt2x00: Space issue

[Kalle Valo]

> Removed empty spaces before/after parenthesis
> 
> Signed-off-by: Paul McQuade 
> Acked-by: Helmut Schaa 

Thanks, 2 patches applied to wireless-drivers-next.git:

b2cc2dd8ebb8 net: wireless: rt2x00: Space issue
5b451715e94d net: wireless: rt2x00: Space Required

1 patches skipped:

[2/3] net: wireless: rt2x00: Pointer issue

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [2/3] net: wireless: rt2x00: Pointer issue

[Kalle Valo]

> Code Style: pointer is declared wrong
> 
> Signed-off-by: Paul McQuade 
> Acked-by: Helmut Schaa 

This patch didn't apply, so please resend.

Kalle

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v2] mac80211: add A-MSDU tx support

[Emmanuel Grumbach]

On Fri, Feb 5, 2016 at 12:41 PM, Felix Fietkau  wrote:
> Requires software tx queueing support. frag_list support (for zero-copy)
> is optional.
>
> Signed-off-by: Felix Fietkau 

Looks nice!
This would allow us to create aggregates of TCP Acks, the problem is
that when you are mostly receiving data, the hardware queues are
pretty much empty (nothing besides the TCP Acks which should go out
quickly) so that packets don't pile up in the software queues and
hence you don't have enough material to build an A-MSDU.
I guess that for AP oriented devices, this is ideal solution since you
can't rely on TSO (packets are not locally generated) and this allows
to build an A-MSDU without adding more latency since you build an
A-MSDU with packets that are already in the queue waiting instead of
delaying transmission of the first packet.
IIRC, the latter was the approach chose by the new Marvell driver
posted a few weeks ago. This approach is better in my eyes.
For iwlwifi which is much more station oriented (of GO which is
basically an AP with locally generated traffic), I took the TSO
approach. I guess we could try to change iwlwifi to use your tx
queues, and check how that works. This would allow us to have A-MSDU
on bridged traffic as well, although this use case is much less common
for Intel devices.

One small question below.

[snip]

> +
> +static bool ieee80211_amsdu_aggregate(struct ieee80211_sub_if_data *sdata,
> + struct sta_info *sta,
> + struct ieee80211_fast_tx *fast_tx,
> + struct sk_buff *skb)
> +{
> +   struct ieee80211_local *local = sdata->local;
> +   u8 tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
> +   struct ieee80211_txq *txq = sta->sta.txq[tid];
> +   struct txq_info *txqi;
> +   struct sk_buff **frag_tail, *head;
> +   int subframe_len = skb->len - ETH_ALEN;
> +   int max_amsdu_len;
> +   __be16 len;
> +   void *data;
> +   bool ret = false;
> +   int n = 1;
> +
> +   if (!ieee80211_hw_check(>hw, TX_AMSDU))
> +   return false;
> +
> +   if (!txq)
> +   return false;
> +
> +   txqi = to_txq_info(txq);
> +   if (test_bit(IEEE80211_TXQ_NO_AMSDU, >flags))
> +   return false;
> +
> +   /*
> +* A-MPDU limits maximum MPDU size to 4095 bytes. Since aggregation
> +* sessions are started/stopped without txq flush, use the limit here
> +* to avoid having to de-aggregate later.
> +*/
> +   max_amsdu_len = min_t(int, sta->sta.max_amsdu_len, 4095);

So you can't get 10K A-MSDUs? I don't see where you check that you
have an A-MPDU session here. You seem to be applying the 4095 limit
also for streams that are not an A-MPDU?
I guess you could check if the sta is a VHT peer, in that case, no
limit applies.

> +
> +   spin_lock_bh(>queue.lock);
> +
> +   head = skb_peek_tail(>queue);
> +   if (!head)
> +   goto out;
> +
> +   if (skb->len + head->len > max_amsdu_len)
> +   goto out;
> +
> +   if (!ieee80211_amsdu_prepare_head(sdata, fast_tx, head))
> +   goto out;
> +
> +   frag_tail = _shinfo(head)->frag_list;
> +   while (*frag_tail) {
> +frag_tail = &(*frag_tail)->next;
> +n++;
> +   }
> +
> +   if (local->hw.max_tx_amsdu_subframes &&
> +   n > local->hw.max_tx_amsdu_subframes)
> +   goto out;
> +
> +   if (skb_headroom(skb) < 8 || skb_tailroom(skb) < 3) {
> +   I802_DEBUG_INC(local->tx_expand_skb_head);
> +
> +   if (pskb_expand_head(skb, 8, 3, GFP_ATOMIC)) {
> +   wiphy_debug(local->hw.wiphy,
> +   "failed to reallocate TX buffer\n");
> +   goto out;
> +   }
> +   }
> +
> +   subframe_len += ieee80211_amsdu_pad(skb, subframe_len);
> +
> +   ret = true;
> +   data = skb_push(skb, ETH_ALEN + 2);
> +   memmove(data, data + ETH_ALEN + 2, 2 * ETH_ALEN);
> +
> +   data += 2 * ETH_ALEN;
> +   len = cpu_to_be16(subframe_len);
> +   memcpy(data, , 2);
> +   memcpy(data + 2, rfc1042_header, ETH_ALEN);
> +
> +   head->len += skb->len;
> +   head->data_len += skb->len;
> +   *frag_tail = skb;
> +
> +out:
> +   spin_unlock_bh(>queue.lock);
> +
> +   return ret;
> +}
> +
>  static bool ieee80211_xmit_fast(struct ieee80211_sub_if_data *sdata,
> struct net_device *dev, struct sta_info *sta,
> struct ieee80211_fast_tx *fast_tx,
> @@ -2817,6 +2964,10 @@ static bool ieee80211_xmit_fast(struct 
> ieee80211_sub_if_data *sdata,
>
> ieee80211_tx_stats(dev, skb->len + extra_head);
>
> +   if ((hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_QOS_DATA)) &&
> +   

[PATCH v3 1/3] staging: rtl8723au: use list_for_each_entry*()

[Geliang Tang]

Use list_for_each_entry*() instead of list_for_each*() to simplify
the code.

Signed-off-by: Geliang Tang 
---
Changes in v3:
 - split it into three patches.
Changes in v2:
 - drop the coding style fixing in v1.
---
 drivers/staging/rtl8723au/core/rtw_ap.c   | 55 ---
 drivers/staging/rtl8723au/core/rtw_mlme.c | 26 -
 drivers/staging/rtl8723au/core/rtw_mlme_ext.c | 10 ++--
 drivers/staging/rtl8723au/core/rtw_recv.c | 22 
 drivers/staging/rtl8723au/core/rtw_sta_mgt.c  | 25 -
 drivers/staging/rtl8723au/core/rtw_xmit.c | 64 ++-
 drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c | 14 +++--
 drivers/staging/rtl8723au/os_dep/usb_ops_linux.c  |  9 ++--
 8 files changed, 96 insertions(+), 129 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_ap.c 
b/drivers/staging/rtl8723au/core/rtw_ap.c
index 1aa9b26..4bcd617 100644
--- a/drivers/staging/rtl8723au/core/rtw_ap.c
+++ b/drivers/staging/rtl8723au/core/rtw_ap.c
@@ -173,9 +173,9 @@ static u8 chk_sta_is_alive(struct sta_info *psta)
 
 void   expire_timeout_chk23a(struct rtw_adapter *padapter)
 {
-   struct list_head *phead, *plist, *ptmp;
+   struct list_head *phead;
u8 updated = 0;
-   struct sta_info *psta;
+   struct sta_info *psta, *ptmp;
struct sta_priv *pstapriv = >stapriv;
u8 chk_alive_num = 0;
struct sta_info *chk_alive_list[NUM_STA];
@@ -186,8 +186,7 @@ voidexpire_timeout_chk23a(struct rtw_adapter 
*padapter)
phead = >auth_list;
 
/* check auth_queue */
-   list_for_each_safe(plist, ptmp, phead) {
-   psta = container_of(plist, struct sta_info, auth_list);
+   list_for_each_entry_safe(psta, ptmp, phead, auth_list) {
 
if (psta->expire_to > 0) {
psta->expire_to--;
@@ -216,8 +215,7 @@ voidexpire_timeout_chk23a(struct rtw_adapter 
*padapter)
phead = >asoc_list;
 
/* check asoc_queue */
-   list_for_each_safe(plist, ptmp, phead) {
-   psta = container_of(plist, struct sta_info, asoc_list);
+   list_for_each_entry_safe(psta, ptmp, phead, asoc_list) {
 
if (chk_sta_is_alive(psta) || !psta->expire_to) {
psta->expire_to = pstapriv->expire_to;
@@ -1059,7 +1057,7 @@ void rtw_set_macaddr_acl23a(struct rtw_adapter *padapter, 
int mode)
 
 int rtw_acl_add_sta23a(struct rtw_adapter *padapter, u8 *addr)
 {
-   struct list_head *plist, *phead;
+   struct list_head *phead;
u8 added = false;
int i, ret = 0;
struct rtw_wlan_acl_node *paclnode;
@@ -1076,8 +1074,7 @@ int rtw_acl_add_sta23a(struct rtw_adapter *padapter, u8 
*addr)
 
phead = get_list_head(pacl_node_q);
 
-   list_for_each(plist, phead) {
-   paclnode = container_of(plist, struct rtw_wlan_acl_node, list);
+   list_for_each_entry(paclnode, phead, list) {
 
if (!memcmp(paclnode->addr, addr, ETH_ALEN)) {
if (paclnode->valid == true) {
@@ -1121,8 +1118,8 @@ int rtw_acl_add_sta23a(struct rtw_adapter *padapter, u8 
*addr)
 
 int rtw_acl_remove_sta23a(struct rtw_adapter *padapter, u8 *addr)
 {
-   struct list_head *plist, *phead, *ptmp;
-   struct rtw_wlan_acl_node *paclnode;
+   struct list_head *phead;
+   struct rtw_wlan_acl_node *paclnode, *ptmp;
struct sta_priv *pstapriv = >stapriv;
struct wlan_acl_pool *pacl_list = >acl_list;
struct rtw_queue *pacl_node_q = _list->acl_node_q;
@@ -1133,8 +1130,7 @@ int rtw_acl_remove_sta23a(struct rtw_adapter *padapter, 
u8 *addr)
 
phead = get_list_head(pacl_node_q);
 
-   list_for_each_safe(plist, ptmp, phead) {
-   paclnode = container_of(plist, struct rtw_wlan_acl_node, list);
+   list_for_each_entry_safe(paclnode, ptmp, phead, list) {
 
if (!memcmp(paclnode->addr, addr, ETH_ALEN)) {
if (paclnode->valid) {
@@ -1354,16 +1350,15 @@ void associated_clients_update23a(struct rtw_adapter 
*padapter, u8 updated)
 {
/* update associated stations cap. */
if (updated == true) {
-   struct list_head *phead, *plist, *ptmp;
-   struct sta_info *psta;
+   struct list_head *phead;
+   struct sta_info *psta, *ptmp;
struct sta_priv *pstapriv = >stapriv;
 
spin_lock_bh(>asoc_list_lock);
 
phead = >asoc_list;
 
-   list_for_each_safe(plist, ptmp, phead) {
-   psta = container_of(plist, struct sta_info, asoc_list);
+   list_for_each_entry_safe(psta, ptmp, phead, asoc_list) {
 
VCS_update23a(padapter, psta);
}
@@ -1627,7 +1622,7 @@ u8 ap_free_sta23a(struct rtw_adapter *padapter, struct 
sta_info *psta, bool acti
 
 int rtw_ap_inform_ch_switch23a(struct rtw_adapter 

Re: [1/8] mwifiex: display right transmit packet delay

[Kalle Valo]

> From: Xinming Hu 
> 
> drv_pkt_delay_max should be assigned non-zero value, so that
> packet delay can be accumulate in the right way.
> 
> Signed-off-by: Xinming Hu 
> Signed-off-by: Amitkumar Karwar 

Thanks, 8 patches applied to wireless-drivers-next.git:

6970cd446c25 mwifiex: display right transmit packet delay
af05148392f5 mwifiex: process pcie io memory read failure case
0172404d79ec mwifiex: skip firmware dump when read_regs() fails
9a86232213b9 mwifiex: keep original structure in decl header file
50632092dfda mwifiex: use an extensible framework for firmware dump solution
56486026c282 mwifiex: dynamically increase preallocated firmware dump memory 
size
03f0f7cdebeb mwifiex: increase the priority of firmware dump message
11e70824e75f mwifiex: firmware dump support for w8997 chipset

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/3] staging: rtl8723au: core: rtw_recv: remove useless codes

[Geliang Tang]

There are some useless codes in rtw_free_recvframe23a_queue() and
recvframe_defrag(), so remove them.

Signed-off-by: Geliang Tang 
---
Changes in v3:
 - split it into three patches.
Changes in v2:
 - drop the coding style fixing in v1.
---
 drivers/staging/rtl8723au/core/rtw_recv.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_recv.c 
b/drivers/staging/rtl8723au/core/rtw_recv.c
index 18b7d03..b36bc6b 100644
--- a/drivers/staging/rtl8723au/core/rtw_recv.c
+++ b/drivers/staging/rtl8723au/core/rtw_recv.c
@@ -201,7 +201,6 @@ static void rtw_free_recvframe23a_queue(struct rtw_queue 
*pframequeue)
spin_lock(>lock);
 
phead = get_list_head(pframequeue);
-   plist = phead->next;
 
list_for_each_entry_safe(hdr, ptmp, phead, list) {
rtw_free_recvframe23a(hdr);
@@ -1567,7 +1566,7 @@ struct recv_frame *recvframe_defrag(struct rtw_adapter 
*adapter,
struct rtw_queue *defrag_q)
 {
struct list_head *plist, *phead;
-   u8  *data, wlanhdr_offset;
+   u8  wlanhdr_offset;
u8  curfragnum;
struct recv_frame *pnfhdr, *ptmp;
struct recv_frame *prframe, *pnextrframe;
@@ -1596,10 +1595,6 @@ struct recv_frame *recvframe_defrag(struct rtw_adapter 
*adapter,
 
curfragnum++;
 
-   phead = get_list_head(defrag_q);
-
-   data = prframe->pkt->data;
-
list_for_each_entry_safe(pnfhdr, ptmp, phead, list) {
pnextrframe = (struct recv_frame *)pnfhdr;
/* check the fragment sequence  (2nd ~n fragment frame) */
-- 
2.5.0


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/3] staging: rtl8723au: whitespace and blank line cleaning

[Geliang Tang]

This patch cleans whitespaces and blank lines surrounding
list_for_each_entry*().

Signed-off-by: Geliang Tang 
---
Changes in v3:
 - split it into three patches.
Changes in v2:
 - drop the coding style fixing in v1.
---
 drivers/staging/rtl8723au/core/rtw_ap.c   | 41 ++-
 drivers/staging/rtl8723au/core/rtw_mlme.c | 14 +---
 drivers/staging/rtl8723au/core/rtw_mlme_ext.c |  3 +-
 drivers/staging/rtl8723au/core/rtw_recv.c | 18 +++---
 drivers/staging/rtl8723au/core/rtw_sta_mgt.c  | 11 +-
 drivers/staging/rtl8723au/core/rtw_xmit.c | 30 -
 drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c |  8 -
 7 files changed, 17 insertions(+), 108 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_ap.c 
b/drivers/staging/rtl8723au/core/rtw_ap.c
index 4bcd617..ce4b589 100644
--- a/drivers/staging/rtl8723au/core/rtw_ap.c
+++ b/drivers/staging/rtl8723au/core/rtw_ap.c
@@ -171,7 +171,7 @@ static u8 chk_sta_is_alive(struct sta_info *psta)
return ret;
 }
 
-void   expire_timeout_chk23a(struct rtw_adapter *padapter)
+void expire_timeout_chk23a(struct rtw_adapter *padapter)
 {
struct list_head *phead;
u8 updated = 0;
@@ -182,12 +182,9 @@ void   expire_timeout_chk23a(struct rtw_adapter 
*padapter)
int i;
 
spin_lock_bh(>auth_list_lock);
-
phead = >auth_list;
-
/* check auth_queue */
list_for_each_entry_safe(psta, ptmp, phead, auth_list) {
-
if (psta->expire_to > 0) {
psta->expire_to--;
if (psta->expire_to == 0) {
@@ -205,18 +202,13 @@ void  expire_timeout_chk23a(struct rtw_adapter 
*padapter)
spin_lock_bh(>auth_list_lock);
}
}
-
}
-
spin_unlock_bh(>auth_list_lock);
 
spin_lock_bh(>asoc_list_lock);
-
phead = >asoc_list;
-
/* check asoc_queue */
list_for_each_entry_safe(psta, ptmp, phead, asoc_list) {
-
if (chk_sta_is_alive(psta) || !psta->expire_to) {
psta->expire_to = pstapriv->expire_to;
psta->keep_alive_trycnt = 0;
@@ -281,7 +273,6 @@ voidexpire_timeout_chk23a(struct rtw_adapter 
*padapter)
}
}
}
-
spin_unlock_bh(>asoc_list_lock);
 
if (chk_alive_num) {
@@ -1071,11 +1062,8 @@ int rtw_acl_add_sta23a(struct rtw_adapter *padapter, u8 
*addr)
return -1;
 
spin_lock_bh(_node_q->lock);
-
phead = get_list_head(pacl_node_q);
-
list_for_each_entry(paclnode, phead, list) {
-
if (!memcmp(paclnode->addr, addr, ETH_ALEN)) {
if (paclnode->valid == true) {
added = true;
@@ -1084,7 +1072,6 @@ int rtw_acl_add_sta23a(struct rtw_adapter *padapter, u8 
*addr)
}
}
}
-
spin_unlock_bh(_node_q->lock);
 
if (added)
@@ -1127,11 +1114,8 @@ int rtw_acl_remove_sta23a(struct rtw_adapter *padapter, 
u8 *addr)
DBG_8723A("%s(acl_num =%d) = %pM\n", __func__, pacl_list->num, addr);
 
spin_lock_bh(_node_q->lock);
-
phead = get_list_head(pacl_node_q);
-
list_for_each_entry_safe(paclnode, ptmp, phead, list) {
-
if (!memcmp(paclnode->addr, addr, ETH_ALEN)) {
if (paclnode->valid) {
paclnode->valid = false;
@@ -1142,7 +1126,6 @@ int rtw_acl_remove_sta23a(struct rtw_adapter *padapter, 
u8 *addr)
}
}
}
-
spin_unlock_bh(_node_q->lock);
 
DBG_8723A("%s, acl_num =%d\n", __func__, pacl_list->num);
@@ -1355,14 +1338,9 @@ void associated_clients_update23a(struct rtw_adapter 
*padapter, u8 updated)
struct sta_priv *pstapriv = >stapriv;
 
spin_lock_bh(>asoc_list_lock);
-
phead = >asoc_list;
-
-   list_for_each_entry_safe(psta, ptmp, phead, asoc_list) {
-
+   list_for_each_entry_safe(psta, ptmp, phead, asoc_list)
VCS_update23a(padapter, psta);
-   }
-
spin_unlock_bh(>asoc_list_lock);
}
 }
@@ -1637,9 +1615,7 @@ int rtw_ap_inform_ch_switch23a(struct rtw_adapter 
*padapter, u8 new_ch, u8 ch_of
 
spin_lock_bh(>asoc_list_lock);
phead = >asoc_list;
-
list_for_each_entry(psta, phead, asoc_list) {
-
issue_action_spct_ch_switch23a(padapter, psta->hwaddr, new_ch, 
ch_offset);
psta->expire_to = ((pstapriv->expire_to * 2) > 5) ? 5 : 
(pstapriv->expire_to * 2);
}
@@ -1669,9 +1645,7 @@ int rtw_sta_flush23a(struct rtw_adapter *padapter)
 
spin_lock_bh(>asoc_list_lock);
phead = >asoc_list;
-
list_for_each_entry_safe(psta, ptmp, phead, 

Monitor interface TX performance boost

[Nikolay Martynov]

Hi.

  I'm seeing strange behavior on my intel 6300 card.

  If I measure TX performance just after boot (iperf in tcp mode), I get this:

[  3]  0.0-10.1 sec  11.2 MBytes  9.32 Mbits/sec

  But if create and enable monitor interface (with command like 'sudo
iw phy phy0 interface add moni0 type monitor && sudo ifconfig moni0
up') I get this:

[  3]  0.0-10.1 sec  34.8 MBytes  29.0 Mbits/sec

That's about three times boost in throughput by just creating an
interface (without even using it).
Doing 'ifconfig moni0 down' bring performance back to 10Mbits range.

Experiments are done with laptop being ~5m from router and not moving.
These results are repeatable, i.e. not caused by random things like
other stations transmitting, or channel being busy.

Is this something expected? Is there any reason performance can be as
good without monitor interface existing?

Thanks!

-- 
Martynov Nikolay.
Email: mar.ko...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: wilc1000: Fix compilation error when CONFIG_PM disabled

[Greg KH]

On Fri, Feb 05, 2016 at 02:40:27PM +0900, Glen Lee wrote:
> Commit 73584a40d748 ("staging: wilc1000: add ops resuem/suspend/wakeup in
> cfg80211") causes following compilation error. This patch fixes this by
> using suspend/resume under CONFIG_PM.
> 
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c: In function
> 'wilc_create_wiphy':
> >> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2833:13: error:
> 'struct wiphy' has no member named 'wowlan'
>  wdev->wiphy->wowlan = _support;
> 
> Fixes: 73584a40d748 ("staging: wilc1000: add ops resuem/suspend/wakeup in 
> cfg80211")
> Reported-by: kbuild test robot 
> Signed-off-by: Glen Lee 
> ---
>  drivers/staging/wilc1000/wilc_sdio.c  | 4 
>  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 9 -
>  drivers/staging/wilc1000/wilc_wfi_netdevice.h | 2 ++
>  3 files changed, 14 insertions(+), 1 deletion(-)

Patch doesn't apply :(

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Monitor interface TX performance boost

[Emmanuel Grumbach]

On Sun, Feb 7, 2016 at 9:09 AM, Kalle Valo  wrote:
> Nikolay Martynov  writes:
>
>>   I'm seeing strange behavior on my intel 6300 card.
>>
>>   If I measure TX performance just after boot (iperf in tcp mode), I get 
>> this:
>>
>> [  3]  0.0-10.1 sec  11.2 MBytes  9.32 Mbits/sec
>>
>>   But if create and enable monitor interface (with command like 'sudo
>> iw phy phy0 interface add moni0 type monitor && sudo ifconfig moni0
>> up') I get this:
>>
>> [  3]  0.0-10.1 sec  34.8 MBytes  29.0 Mbits/sec
>>
>> That's about three times boost in throughput by just creating an
>> interface (without even using it).
>> Doing 'ifconfig moni0 down' bring performance back to 10Mbits range.
>>
>> Experiments are done with laptop being ~5m from router and not moving.
>> These results are repeatable, i.e. not caused by random things like
>> other stations transmitting, or channel being busy.
>>
>> Is this something expected? Is there any reason performance can be as
>> good without monitor interface existing?
>
> Maybe the monitor mode disables power save automatically?
>

That could be an option although I remember to have disabled power
save by default (cough..).
That happened in 3.17 IIRC.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: net: wireless: rt2x00: Fixed Spacing issues

[Kalle Valo]

> Removed empty spaces before/after parenthesis
> 
> Signed-off-by: Paul McQuade 
> Acked-by: Helmut Schaa 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] bcma: use _PMU_ in all names of PMU registers

[Kalle Valo]

Rafał Miłecki  writes:

> PMU (Power Management Unit) seems to be a separated piece of hardware,
> just accessed using ChipCommon core registers. In recent Broadcom
> chipsets PMU is not bounded to CC but available as separated core.
>
> To make code cleaner & easier to review (for a correct R/W access) use
> clearer names.
>
> Signed-off-by: Rafał Miłecki 

Manually applied both patches to wireless-drivers-next.git, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rtlwifi: fix broken VHT support

[Kalle Valo]

> When using a 5G-capable device with VHT (802.11ac) rates enabled was not
> working (packets were not delivered) and the following mac80211 warning
> was printed:
> 
> WARNING: CPU: 3 PID: 2253 at net/mac80211/rate.c:625 
> ieee80211_get_tx_rates+0x22e/0x620 [mac80211]()
> Modules linked in: rtl8821ae btcoexist rtl_pci rtlwifi fuse drbg ansi_cprng 
> ctr ccm bnep bluetooth af_packet nfs fscache vboxpci(O) vboxnetadp(O) vboxne
> tflt(O) vboxdrv(O) arc4 snd_hda_codec_generic x86_pkg_temp_thermal 
> rtsx_pci_sdmmc mmc_core rtsx_pci_ms kvm_intel memstick iwlmvm kvm mac80211 
> snd_hda_intel snd_hda_cod
> ec snd_hwdep snd_hda_core irqbypass snd_pcm iwlwifi crct10dif_pclmul 
> crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 
> snd_timer lrw gf128mul glue_h
> elper ablk_helper cryptd snd cfg80211 pcspkr serio_raw e1000e rtsx_pci 
> lpc_ich ptp xhci_pci mfd_core pps_core xhci_hcd soundcore toshiba_acpi 
> thermal sparse_keymap wmi
>  toshiba_bluetooth rfkill acpi_cpufreq battery ac processor dm_mod i915 
> i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops
> drm sr_mod cdrom video button sg autofs4 [last unloaded: rtlwifi]
> CPU: 3 PID: 2253 Comm: Timer Tainted: GW  O4.5.0-rc1-wl+ #79
> Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.20   04/17/2014
>   a05c4be6 8802262036d8 813d7912 
>   880226203710 8106bcb6 8800c6831300 8800c6831330
>    8800c683133c 880065923638 880226203720
> Call Trace:
> [] dump_stack+0x4b/0x79
>   [] warn_slowpath_common+0x86/0xc0
>   [] warn_slowpath_null+0x1a/0x20
>   [] ieee80211_get_tx_rates+0x22e/0x620 [mac80211]
>   [] ? rtl_is_special_data+0x32/0x240 [rtlwifi]
>   [] ? rate_control_get_rate+0xce/0x150 [mac80211]
>   [] ? trace_hardirqs_on+0xd/0x10
>   [] ? __local_bh_enable_ip+0x65/0xd0
> --- traceback terminated here ---
> 
> The problem is that IEEE80211_TX_RC_VHT_MCS is not set in the rate flags.
> 
> Reported-by: Linus Torvalds 
> Tested-by: Linus Torvalds 
> Signed-off-by: Johannes Berg 
> Signed-off-by: Larry Finger 
> Cc: Stable 

Thanks, applied to wireless-drivers.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex: fix bandwidth display problem

[Kalle Valo]

> From: Nachiket Kukade 
> 
> Instead of using HT info from beacon IEs, use HT info from
> association response frame to update bandwidth in
> cfg80211_get_channel handler.
> 
> Signed-off-by: Nachiket Kukade 
> Signed-off-by: Amitkumar Karwar 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2] hostap: avoid uninitialized variable use in hfa384x_get_rid

[Kalle Valo]

> The driver reads a value from hfa384x_from_bap(), which may fail,
> and then assigns the value to a local variable. gcc detects that
> in in the failure case, the 'rlen' variable now contains
> uninitialized data:
> 
> In file included from 
> ../drivers/net/wireless/intersil/hostap/hostap_pci.c:220:0:
> drivers/net/wireless/intersil/hostap/hostap_hw.c: In function 
> 'hfa384x_get_rid':
> drivers/net/wireless/intersil/hostap/hostap_hw.c:842:5: warning: 'rec' may be 
> used uninitialized in this function [-Wmaybe-uninitialized]
>   if (le16_to_cpu(rec.len) == 0) {
> 
> This restructures the function as suggested by Russell King, to
> make it more readable and get more reliable error handling, by
> handling each failure mode using a goto.
> 
> Signed-off-by: Arnd Bergmann 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: iwlwifi-next 2016-01-31

[Kalle Valo]

"Grumbach, Emmanuel"  writes:

> Hi Kalle,
>
> This is a pull request for 4.6. Please pull. Thanks!
>
> The following changes since commit aee3bfa3307cd0da2126bdc0ea359dabea5ee8f7:
>
>   Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next 
> (2016-01-12 18:57:02 -0800)
>
> are available in the git repository at:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
> tags/iwlwifi-next-for-kalle-2016-01-31

Pulled iwlwifi-next-for-kalle-2016-01-31_2 as discussed in patch 4,
thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcmfmac: treat NULL character in NVRAM as separator

[Kalle Valo]

Rafał Miłecki  writes:

> Platform NVRAM (stored on a flash partition) has entries separated by a
> NULL (\0) char. Our parsing code switches from VALUE state to IDLE
> whenever it meets a NULL (\0). When that happens our IDLE handler should
> simply consume it and analyze whatever is placed ahead.
>
> This fixes harmless warnings spamming debugging output:
> [  155.165624] brcmfmac: brcmf_nvram_handle_idle warning: ln=1:col=20: 
> ignoring invalid character
> [  155.180806] brcmfmac: brcmf_nvram_handle_idle warning: ln=1:col=44: 
> ignoring invalid character
> [  155.195971] brcmfmac: brcmf_nvram_handle_idle warning: ln=1:col=63: 
> ignoring invalid character
>
> Signed-off-by: Rafał Miłecki 

Manually applied to wireless-drivers-next.git, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: brcmfmac: sdio: Increase the default timeouts a bit

[Kalle Valo]

> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems
> the card responds very quickly most of the time, unfortunately during
> initialisation it sometimes seems to take just a bit over 2 seconds to
> respond.
> 
> This results intialization failing with message like:
>   brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -52
>   brcmf_bus_start: failed: -52
>   brcmf_sdio_firmware_callback: dongle is not responding
> 
> Increasing the timeout to allow for a bit more headroom allows the
> card to initialize reliably.
> 
> A quick search online after diagnosing/fixing this showed that Google
> has a similar patch in their ChromeOS tree, so this doesn't seem
> specific to the board I'm using.
> 
> Signed-off-by: Sjoerd Simons 
> Reviewed-by: Julian Calaby 
> Acked-by: Arend van Spriel 
> Reviewed-by: Douglas Anderson 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] bcma: identify bus cores (devices) found on BCM47189

[Kalle Valo]

Rafał Miłecki  writes:

> Add missing defines and print proper names.
>
> Signed-off-by: Rafał Miłecki 

Manually applied both patches to wireless-drivers-next.git, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcma: support identifying MX25L25635F serial flash

[Kalle Valo]

Rafał Miłecki  writes:

> It's a Macronix 32 MiB flash found on board with BCM47189 SoC.
>
> Signed-off-by: Rafał Miłecki 

Manually applied to wireless-drivers-next.git, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] brcmfmac: support for new 14e43:4365 card with BCM4366

[Kalle Valo]

Rafał Miłecki  writes:

> I got D-Link DIR-885L with two 14e4:4365 PCI cards both using BCM4366 chipset.
> It seems to have newer ChipCommon and separated PMU core so I needed these
> patches on top of recent Broadcom's work.
>
> Please note this patchset depends on:
> [PATCH 2/2] bcma: support PMU present as separated bus core
> as I had to use BCMA_CC_CAP_EXT_AOB_PRESENT.
>
> Rafał Miłecki (5):
>   brcmfmac: analyze descriptors of current component only
>   brcmfmac: allow storing PMU core without wrapper address
>   brcmfmac: read extended capabilities of ChipCommon core
>   brcmfmac: access PMU registers using standalone PMU core if available
>   brcmfmac: add support for 14e4:4365 PCI ID with BCM4366 chipset

Manually applied all five to wireless-drivers-next.git, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] brcmfmac: fix setting primary channel for 80 MHz width

[Kalle Valo]

Rafał Miłecki  writes:

> First of all it changes the way we calculate primary channel offset. If
> we use e.g. 80 MHz channel with primary frequency 5180 MHz (which means
> center frequency is 5210 MHz) it makes sense to calculate primary offset
> as -30 MHz.
> Then it fixes values we compare primary_offset with. We were comparing
> offset in MHz against -2 or 2 which was resulting in picking a wrong
> primary channel.
>
> Signed-off-by: Rafał Miłecki 

Manually applied to wireless-drivers-next.git, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcma: add support for BCM47094

[Kalle Valo]

Rafał Miłecki  writes:

> It's another SoC with 32 GPIOs and simplified watchdog handling. It was
> tested on D-Link DIR-885L.
>
> Signed-off-by: Rafał Miłecki 

Manually applied to wireless-drivers-next.git, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcma: claim only 14e4:4365 PCI Dell card with SoftMAC BCM43142

[Kalle Valo]

Rafał Miłecki  writes:

> It seems 14e4:4365 pattern is too generic as there are two devices:
> 1) 14e4:4365 1028:0016 with SoftMAC BCM43142 chipset
> 2) 14e4:4365 14e4:4365 with FullMAC BCM4366 chipset
> The later one was found in D-Link DIR-885L router and we want to let
> brcmfmac handle it.
>
> Signed-off-by: Rafał Miłecki 

Manually applied to wireless-drivers-next.git, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bcma: init serial console directly from ChipCommon code

[Kalle Valo]

Rafał Miłecki  writes:

> UART is connected to and controlled over ChipCommon core. It doesn't
> have much to do with MIPS core (where we initialize it currently)
> except just existing on embedded systemms. There isn't point of such
> cross-core initialization (and we needed #ifdef anyway) so just handle
> it in ChipCommon.
>
> Signed-off-by: Rafał Miłecki 

Manually applied to wireless-drivers-next.git, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html