date:20141216

[PATCH 1/2] ath10k: fix low TX rates when IBSS and HT

2014-12-16 Thread Janusz Dziedzic

This fix TX problem when IBSS used in HT mode.
Before we used 6Mbps all the time for TX direction.

Reported-by: Yeoh Chun-Yeow yeohchuny...@gmail.com
Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com
---
 drivers/net/wireless/ath/ath10k/mac.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 5475f0f..c9e7995 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1411,9 +1411,16 @@ static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
if (vif-bss_conf.qos)
arg-peer_flags |= WMI_PEER_QOS;
break;
+   case WMI_VDEV_TYPE_IBSS:
+   if (sta-wme)
+   arg-peer_flags |= WMI_PEER_QOS;
+   break;
default:
break;
}
+
+   ath10k_dbg(ar, ATH10K_DBG_MAC, mac peer %pM qos %d\n,
+  sta-addr, !!(arg-peer_flags  WMI_PEER_QOS));
 }
 
 static void ath10k_peer_assoc_h_phymode(struct ath10k *ar,
-- 
1.9.1

--
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 2/2] ath10k: send (re)assoc peer command when NSS changed

2014-12-16 Thread Janusz Dziedzic

Assoc peer command contain information about NSS.
When we will get IEEE80211_RC_NSS_CHANGED we should
also send (re) assoc peer command to be sure firmware
will know about it and RC will work correctly.

Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com
---
 drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index c9e7995..05fd620 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3592,8 +3592,9 @@ static void ath10k_sta_rc_update_wk(struct work_struct 
*wk)
sta-addr, smps, err);
}
 
-   if (changed  IEEE80211_RC_SUPP_RATES_CHANGED) {
-   ath10k_dbg(ar, ATH10K_DBG_MAC, mac update sta %pM supp 
rates\n,
+   if (changed  IEEE80211_RC_SUPP_RATES_CHANGED ||
+   changed  IEEE80211_RC_NSS_CHANGED) {
+   ath10k_dbg(ar, ATH10K_DBG_MAC, mac update sta %pM supp 
rates/nss\n,
   sta-addr);
 
err = ath10k_station_assoc(ar, arvif-vif, sta, true);
-- 
1.9.1

--
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] mac80211: notify NSS changed when IBSS and HT

2014-12-16 Thread Janusz Dziedzic

When using IBSS in HT mode, we always get NSS=1
in rc_update callback. Force NSS recalculation when
rates updated and notify driver that NSS changed.

Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com
---
 net/mac80211/ibss.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 509bc15..d95c2dd 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -1069,9 +1069,16 @@ static void ieee80211_rx_bss_info(struct 
ieee80211_sub_if_data *sdata,
}
 
if (sta  rates_updated) {
+   u8 rx_nss = sta-sta.rx_nss;
+
drv_sta_rc_update(local, sdata, sta-sta,
  IEEE80211_RC_SUPP_RATES_CHANGED);
+   /* Force rx_nss recalculation */
+   sta-sta.rx_nss = 0;
rate_control_rate_init(sta);
+   if (rx_nss != sta-sta.rx_nss)
+   drv_sta_rc_update(local, sdata, sta-sta,
+ IEEE80211_RC_NSS_CHANGED);
}
 
rcu_read_unlock();
-- 
1.9.1

--
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] mac80211: add an intermediate software queue implementation

2014-12-16 Thread Felix Fietkau

On 2014-12-16 00:25, Bartosz Szczepanek wrote:
 As for drv_wake_tx_queue and ieee80211_tx_dequeue - is it really
 necessary? There are ieee80211_tx_status and ieee80211_free_txskb
 already, which can be used to decide from mac80211 level when to
 dequeue packet. It could be used even in case of drivers that are not
 aware of new mechanism at all. We could compute difference between
 drv_tx and tx_status/free_txskb calls, therefore getting number of
 frames in HW. What could help us to keep queues short.
Keeping the driver queue short is a bad idea if the driver needs deeper
queues to do aggregation.

 I've already written some code. This http://pastebin.com/dSd1zWt7 is
 patch that implements counter of frames in hardware in the way
 described above. It was necessary to differentiate between free_txskb
 and free_txskb. Information about frames in HW is exported to debugfs.
 I thought I could submit it, but just now did I found this thread, so
 I hope that it's adequate place to propose that. I tested it on ath5k
 and brcmsmac.
For aggregation, different drivers need different kinds of scheduling.
Only packets belonging to the same sta/tid can be aggregated, and in AP
mode you can have concurrent traffic of multiple different sta/tid.
The only way to keep queues really short in that case without
sacrificing throughput is to let the aggregation code fetch packets
directly from sta/tid queues.
With ath5k there is no aggregation yet (we could add A-MSDU at some
point), and with brcmsmac, the driver has an internal layer of queueing
to create per-sta/tid queues.
What I'm proposing is having per-sta/tid queues that are shared between
mac80211 and the driver, which will significantly improve queue
management compared to having multiple competing layers of queueing.

 One more thing - why not to use local-pending for holding packets?
 There is tx_pending tasklet already. I'm not sure if I understand the
 idea of local-pending queues correctly, but it seems to be a bit
 incoherent to have both pending and proposed ieee80211_txq.
local-pending is useless for normal tx queueing purposes, because it's
not per-sta/tid.

- Felix
--
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] staging: rtl8723au: core: fixing foo * bar should be foo *bar

2014-12-16 Thread Asaf Vertz

Fixed a coding style error, foo * bar should be foo *bar

Signed-off-by: Asaf Vertz asaf.ve...@tandemg.com
---
 drivers/staging/rtl8723au/core/rtw_efuse.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_efuse.c 
b/drivers/staging/rtl8723au/core/rtw_efuse.c
index 81960e7..0e64d12 100644
--- a/drivers/staging/rtl8723au/core/rtw_efuse.c
+++ b/drivers/staging/rtl8723au/core/rtw_efuse.c
@@ -328,12 +328,12 @@ EFUSE_Read1Byte23a(struct rtw_adapter *Adapter, u16 
Address)
 
 void
 EFUSE_Write1Byte(
-   struct rtw_adapter *Adapter,
+   struct rtw_adapter *Adapter,
u16 Address,
u8  Value);
 void
 EFUSE_Write1Byte(
-   struct rtw_adapter *Adapter,
+   struct rtw_adapter *Adapter,
u16 Address,
u8  Value)
 {
@@ -636,7 +636,7 @@ Efuse_ReadAllMap(struct rtw_adapter *pAdapter, u8 
efuseType, u8 *Efuse)
  *---*/
 static void
 efuse_ShadowRead1Byte(
-   struct rtw_adapter *pAdapter,
+   struct rtw_adapter *pAdapter,
u16 Offset,
u8  *Value)
 {
@@ -648,7 +648,7 @@ efuse_ShadowRead1Byte(
 /* Read Two Bytes */
 static void
 efuse_ShadowRead2Byte(
-   struct rtw_adapter *pAdapter,
+   struct rtw_adapter *pAdapter,
u16 Offset,
u16 *Value)
 {
@@ -661,7 +661,7 @@ efuse_ShadowRead2Byte(
 /* Read Four Bytes */
 static void
 efuse_ShadowRead4Byte(
-   struct rtw_adapter *pAdapter,
+   struct rtw_adapter *pAdapter,
u16 Offset,
u32 *Value)
 {
@@ -723,7 +723,7 @@ void EFUSE_ShadowMapUpdate23a(struct rtw_adapter *pAdapter, 
u8 efuseType)
  *---*/
 void
 EFUSE_ShadowRead23a(
-   struct rtw_adapter *pAdapter,
+   struct rtw_adapter *pAdapter,
u8  Type,
u16 Offset,
u32 *Value)
-- 
1.7.0.4

--
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] ath10k: fix low TX rates when IBSS and HT

2014-12-16 Thread Yeoh Chun-Yeow

Hi, Janusz

I have applied the three patches and tested with firmware
999.999.0.636 but not working.

Any advice what's wrong?

---
ChunYeow

Some of my dmesg:
[  640.45] ath10k_pci :00:00.0: wmi pdev set param 3 value 34
[  640.45] ath10k_pci :00:00.0: wmi pdev set param 4 value 34
[  640.45] ath10k_pci :00:00.0: wmi pdev set wmm params
[  640.45] ath10k_pci :00:00.0: wmi pdev set wmm params
[  640.45] ath10k_pci :00:00.0: wmi pdev set wmm params
[  640.45] ath10k_pci :00:00.0: wmi pdev set wmm params
[  640.45] ath10k_pci :00:00.0: wmi peer create vdev_id 0
peer_addr 04:f0:21:0c:a5:1c
[  640.45] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 16 value 0
[  640.45] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 3 value 100
[  640.45] ath10k_pci :00:00.0: mac vdev 0 beacon_interval 100
[  640.45] ath10k_pci :00:00.0: vdev 0 set beacon tx mode to staggered
[  640.45] ath10k_pci :00:00.0: wmi pdev set param 7 value 0
[  640.45] ath10k_pci :00:00.0: mac vdev 0 start center_freq
5180 phymode 11na-ht20
[  640.45] ath10k_pci :00:00.0: wmi vdev start id 0x0 flags:
0x0, freq 5180, mode 4, ch_flags: 0x400, max_power: 34
[  640.46] ath10k_pci :00:00.0: WMI_VDEV_START_RESP_EVENTID
[  640.46] ath10k_pci :00:00.0: wmi mgmt vdev up id 0x0 assoc
id 0 bssid 52:8d:75:e5:00:52
[  640.46] ath10k_pci :00:00.0: mac vdev 0 up
[  640.46] ath10k_pci :00:00.0: mac vdev 0 cts_prot 0
[  640.46] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 44 value 0
[  640.46] ath10k_pci :00:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
[  640.46] ath10k_pci :00:00.0: mac vdev 0 slot_time 2
[  640.46] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 7 value 2
[  640.46] ath10k_pci :00:00.0: mac vdev 0 preamble 1n
[  640.46] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 8 value 1
[  640.46] ath10k_pci :00:00.0: mac vdev 0 peer create
04:f0:21:0c:a5:43 (new sta) sta 1 / 16 peer 2 / 24
[  640.46] ath10k_pci :00:00.0: wmi peer create vdev_id 0
peer_addr 04:f0:21:0c:a5:43
[  640.46] IPv6: ADDRCONF(NETDEV_CHANGE): mesh0: link becomes ready
[  640.47] ath10k_pci :00:00.0: mac sta 04:f0:21:0c:a5:43 associated
[  640.47] ath10k_pci :00:00.0: mac peer 04:f0:21:0c:a5:43 qos 0
[  640.47] ath10k_pci :00:00.0: mac peer 04:f0:21:0c:a5:43 phymode 11a
[  640.47] ath10k_pci :00:00.0: wmi peer assoc vdev 0 addr
04:f0:21:0c:a5:43 (new)
[  640.47] ath10k_pci :00:00.0: wmi vdev 0 peer
0x04:f0:21:0c:a5:43 set param 5 value 1
[  640.47] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 44 value 33
[  640.47] ath10k_pci :00:00.0: mac monitor recalc started? 0 should? 0
[  640.54] ath10k_pci :00:00.0: mac sta rc update for
04:f0:21:0c:a5:43 changed 0004 bw 0 nss 1 smps 2
[  640.54] ath10k_pci :00:00.0: mac sta rc update for
04:f0:21:0c:a5:43 changed 0008 bw 0 nss 3 smps 2
[  640.54] ath10k_pci :00:00.0: mac update sta 04:f0:21:0c:a5:43 nss 3
[  640.54] ath10k_pci :00:00.0: wmi vdev 0 peer
0x04:f0:21:0c:a5:43 set param 5 value 3
[  640.54] ath10k_pci :00:00.0: mac update sta
04:f0:21:0c:a5:43 supp rates/nss
[  640.54] ath10k_pci :00:00.0: mac ht peer 04:f0:21:0c:a5:43
mcs cnt 24 nss 3
[  640.54] ath10k_pci :00:00.0: mac peer 04:f0:21:0c:a5:43 qos 0
[  640.54] ath10k_pci :00:00.0: mac peer 04:f0:21:0c:a5:43
phymode 11na-ht20
[  640.54] ath10k_pci :00:00.0: wmi peer assoc vdev 0 addr
04:f0:21:0c:a5:43 (reassociate)
[  640.54] ath10k_pci :00:00.0: wmi vdev 0 peer
0x04:f0:21:0c:a5:43 set param 5 value 3
[  640.56] ath10k_pci :00:00.0: wmi event debug mesg len 460
[  641.40] ath10k_pci :00:00.0: rx skb 86be4b40 len 148 peer
04:f0:21:0c:a5:43  mcast sn 2  rate_idx 0 vht_nss 0 freq 5180 band 1
flag 0x20 fcs-err 0 mic-err 0 amsdu-more 0
[  642.17] ath10k_pci :00:00.0: mac monitor recalc started? 0 should? 0
[  642.40] ath10k_pci :00:00.0: rx skb 86b49b40 len 108 peer
04:f0:21:0c:a5:43  mcast sn 3  rate_idx 0 vht_nss 0 freq 5180 band 1
flag 0x20 fcs-err 0 mic-err 0 amsdu-more 0
[  651.56] ath10k_pci :00:00.0: wmi event debug mesg len 28
[ 1740.54] ath10k_pci :00:00.0: rx skb 86af8540 len 60 peer
04:f0:21:0c:a5:43  mcast sn 4  rate_idx 0 vht_nss 0 freq 5180 band 1
flag 0x20 fcs-err 0 mic-err 0 amsdu-more 0
[ 1740.54] ath10k_pci :00:00.0: rx skb 86967600 len 116 peer
04:f0:21:0c:a5:43  ucast sn 0  rate_idx 0 vht_nss 0 freq 5180 band 1
flag 0x20 fcs-err 0 mic-err 0 amsdu-more 0
[ 1741.55] ath10k_pci :00:00.0: rx skb 86967000 len 116 peer
04:f0:21:0c:a5:43  ucast sn 1  rate_idx 0 vht_nss 0 freq 5180 band 1
flag 0x20 fcs-err 0 mic-err 0 amsdu-more 0
[ 1742.55] ath10k_pci :00:00.0: rx skb 86b8acc0 len 116 peer
04:f0:21:0c:a5:43  ucast sn 2  rate_idx 0 vht_nss

Re: [PATCH 1/2] ath10k: fix low TX rates when IBSS and HT

2014-12-16 Thread Janusz Dziedzic

On 16 December 2014 at 12:22, Janusz Dziedzic janusz.dzied...@tieto.com wrote:
 On 16 December 2014 at 12:10, Yeoh Chun-Yeow yeohchuny...@gmail.com wrote:
 Hi, Janusz

 I have applied the three patches and tested with firmware
 999.999.0.636 but not working.

 Any advice what's wrong?

 mac peer 04:f0:21:0c:a5:43 qos 0 - this is suspect.
 What is your test procedure (I see some mesh ...)?
 Maybe additional patch for mesh is required?

 I tested this using ath9k + ath10k (636) +
 iw wlanx set type ibss
 iw ibss join  5180 HT [HT40+]
 or wpa_supplicant in ibss mode (HT20 limited in current version)

 Next in airlogs I saw we are using nss1 and higher mcs
 But for sure qos = 1 is required.

I am not sure why sta-wme is not set while we have HT rates (is it
allowed to have HT without WMM?)
But anyway as a quick workaroud you can try something like this:

@@ -1212,7 +1212,7 @@ static void ath10k_peer_assoc_h_ht(struct ath10k *ar,
if (!ht_cap-ht_supported)
return;

-   arg-peer_flags |= WMI_PEER_HT;
+   arg-peer_flags |= WMI_PEER_HT | WMI_PEER_QOS;
arg-peer_max_mpdu = (1  (IEEE80211_HT_MAX_AMPDU_FACTOR +
ht_cap-ampdu_factor)) - 1;

@@ -3464,6 +3464,13 @@ static int ath10k_set_key(struct ieee80211_hw
*hw, enum set_key_cmd cmd,
  key-cipher == WLAN_CIPHER_SUITE_WEP104;
int ret = 0;

 BR
 Janusz


 ---
 ChunYeow

 Some of my dmesg:
 [  640.45] ath10k_pci :00:00.0: wmi pdev set param 3 value 34
 [  640.45] ath10k_pci :00:00.0: wmi pdev set param 4 value 34
 [  640.45] ath10k_pci :00:00.0: wmi pdev set wmm params
 [  640.45] ath10k_pci :00:00.0: wmi pdev set wmm params
 [  640.45] ath10k_pci :00:00.0: wmi pdev set wmm params
 [  640.45] ath10k_pci :00:00.0: wmi pdev set wmm params
 [  640.45] ath10k_pci :00:00.0: wmi peer create vdev_id 0
 peer_addr 04:f0:21:0c:a5:1c
 [  640.45] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 16 value 0
 [  640.45] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 3 value 100
 [  640.45] ath10k_pci :00:00.0: mac vdev 0 beacon_interval 100
 [  640.45] ath10k_pci :00:00.0: vdev 0 set beacon tx mode to 
 staggered
 [  640.45] ath10k_pci :00:00.0: wmi pdev set param 7 value 0
 [  640.45] ath10k_pci :00:00.0: mac vdev 0 start center_freq
 5180 phymode 11na-ht20
 [  640.45] ath10k_pci :00:00.0: wmi vdev start id 0x0 flags:
 0x0, freq 5180, mode 4, ch_flags: 0x400, max_power: 34
 [  640.46] ath10k_pci :00:00.0: WMI_VDEV_START_RESP_EVENTID
 [  640.46] ath10k_pci :00:00.0: wmi mgmt vdev up id 0x0 assoc
 id 0 bssid 52:8d:75:e5:00:52
 [  640.46] ath10k_pci :00:00.0: mac vdev 0 up
 [  640.46] ath10k_pci :00:00.0: mac vdev 0 cts_prot 0
 [  640.46] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 44 value 0
 [  640.46] ath10k_pci :00:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
 [  640.46] ath10k_pci :00:00.0: mac vdev 0 slot_time 2
 [  640.46] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 7 value 2
 [  640.46] ath10k_pci :00:00.0: mac vdev 0 preamble 1n
 [  640.46] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 8 value 1
 [  640.46] ath10k_pci :00:00.0: mac vdev 0 peer create
 04:f0:21:0c:a5:43 (new sta) sta 1 / 16 peer 2 / 24
 [  640.46] ath10k_pci :00:00.0: wmi peer create vdev_id 0
 peer_addr 04:f0:21:0c:a5:43
 [  640.46] IPv6: ADDRCONF(NETDEV_CHANGE): mesh0: link becomes ready
 [  640.47] ath10k_pci :00:00.0: mac sta 04:f0:21:0c:a5:43 associated
 [  640.47] ath10k_pci :00:00.0: mac peer 04:f0:21:0c:a5:43 qos 0
 [  640.47] ath10k_pci :00:00.0: mac peer 04:f0:21:0c:a5:43 phymode 
 11a
 [  640.47] ath10k_pci :00:00.0: wmi peer assoc vdev 0 addr
 04:f0:21:0c:a5:43 (new)
 [  640.47] ath10k_pci :00:00.0: wmi vdev 0 peer
 0x04:f0:21:0c:a5:43 set param 5 value 1
 [  640.47] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 44 value 33
 [  640.47] ath10k_pci :00:00.0: mac monitor recalc started? 0 
 should? 0
 [  640.54] ath10k_pci :00:00.0: mac sta rc update for
 04:f0:21:0c:a5:43 changed 0004 bw 0 nss 1 smps 2
 [  640.54] ath10k_pci :00:00.0: mac sta rc update for
 04:f0:21:0c:a5:43 changed 0008 bw 0 nss 3 smps 2
 [  640.54] ath10k_pci :00:00.0: mac update sta 04:f0:21:0c:a5:43 nss 
 3
 [  640.54] ath10k_pci :00:00.0: wmi vdev 0 peer
 0x04:f0:21:0c:a5:43 set param 5 value 3
 [  640.54] ath10k_pci :00:00.0: mac update sta
 04:f0:21:0c:a5:43 supp rates/nss
 [  640.54] ath10k_pci :00:00.0: mac ht peer 04:f0:21:0c:a5:43
 mcs cnt 24 nss 3
 [  640.54] ath10k_pci :00:00.0: mac peer 04:f0:21:0c:a5:43 qos 0
 [  640.54] ath10k_pci :00:00.0: mac peer 04:f0:21:0c:a5:43
 phymode 11na-ht20
 [  640.54] ath10k_pci :00:00.0: wmi peer assoc vdev 0 addr
 04:f0:21:0c:a5:43 (reassociate)

Re: [PATCH] staging: rtl8723au: core: fixing foo * bar should be foo *bar

2014-12-16 Thread Jes Sorensen

Asaf Vertz asaf.ve...@tandemg.com writes:
 Fixed a coding style error, foo * bar should be foo *bar

 Signed-off-by: Asaf Vertz asaf.ve...@tandemg.com
 ---
  drivers/staging/rtl8723au/core/rtw_efuse.c |   12 ++--
  1 files changed, 6 insertions(+), 6 deletions(-)

If you want to fix the 'error' here, include it with a cleanup that also
fixes the ugly multiline arguments to the functions.

Jes

 diff --git a/drivers/staging/rtl8723au/core/rtw_efuse.c 
 b/drivers/staging/rtl8723au/core/rtw_efuse.c
 index 81960e7..0e64d12 100644
 --- a/drivers/staging/rtl8723au/core/rtw_efuse.c
 +++ b/drivers/staging/rtl8723au/core/rtw_efuse.c
 @@ -328,12 +328,12 @@ EFUSE_Read1Byte23a(struct rtw_adapter *Adapter, u16 
 Address)
  
  void
  EFUSE_Write1Byte(
 - struct rtw_adapter *Adapter,
 + struct rtw_adapter *Adapter,
   u16 Address,
   u8  Value);
  void
  EFUSE_Write1Byte(
 - struct rtw_adapter *Adapter,
 + struct rtw_adapter *Adapter,
   u16 Address,
   u8  Value)
  {
 @@ -636,7 +636,7 @@ Efuse_ReadAllMap(struct rtw_adapter *pAdapter, u8 
 efuseType, u8 *Efuse)
   
 *---*/
  static void
  efuse_ShadowRead1Byte(
 - struct rtw_adapter *pAdapter,
 + struct rtw_adapter *pAdapter,
   u16 Offset,
   u8  *Value)
  {
 @@ -648,7 +648,7 @@ efuse_ShadowRead1Byte(
  /* Read Two Bytes */
  static void
  efuse_ShadowRead2Byte(
 - struct rtw_adapter *pAdapter,
 + struct rtw_adapter *pAdapter,
   u16 Offset,
   u16 *Value)
  {
 @@ -661,7 +661,7 @@ efuse_ShadowRead2Byte(
  /* Read Four Bytes */
  static void
  efuse_ShadowRead4Byte(
 - struct rtw_adapter *pAdapter,
 + struct rtw_adapter *pAdapter,
   u16 Offset,
   u32 *Value)
  {
 @@ -723,7 +723,7 @@ void EFUSE_ShadowMapUpdate23a(struct rtw_adapter 
 *pAdapter, u8 efuseType)
   
 *---*/
  void
  EFUSE_ShadowRead23a(
 - struct rtw_adapter *pAdapter,
 + struct rtw_adapter *pAdapter,
   u8  Type,
   u16 Offset,
   u32 *Value)
--
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] ath10k: fix low TX rates when IBSS and HT

2014-12-16 Thread Yeoh Chun-Yeow

On Tue, Dec 16, 2014 at 7:22 PM, Janusz Dziedzic
janusz.dzied...@tieto.com wrote:
 On 16 December 2014 at 12:10, Yeoh Chun-Yeow yeohchuny...@gmail.com wrote:
 Hi, Janusz

 I have applied the three patches and tested with firmware
 999.999.0.636 but not working.

 Any advice what's wrong?

 mac peer 04:f0:21:0c:a5:43 qos 0 - this is suspect.

Not so sure.

 What is your test procedure (I see some mesh ...)?

I named the interface as mesh0 but it is ibss or adhoc mode. I use the
iw util to setup the adhoc interface.

---
ChunYeow
--
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] ath10k: fix low TX rates when IBSS and HT

2014-12-16 Thread Yeoh Chun-Yeow

Ok, I will try this and investigate further.

---
ChunYeow

On Tue, Dec 16, 2014 at 7:45 PM, Janusz Dziedzic
janusz.dzied...@tieto.com wrote:
 On 16 December 2014 at 12:22, Janusz Dziedzic janusz.dzied...@tieto.com 
 wrote:
 On 16 December 2014 at 12:10, Yeoh Chun-Yeow yeohchuny...@gmail.com wrote:
 Hi, Janusz

 I have applied the three patches and tested with firmware
 999.999.0.636 but not working.

 Any advice what's wrong?

 mac peer 04:f0:21:0c:a5:43 qos 0 - this is suspect.
 What is your test procedure (I see some mesh ...)?
 Maybe additional patch for mesh is required?

 I tested this using ath9k + ath10k (636) +
 iw wlanx set type ibss
 iw ibss join  5180 HT [HT40+]
 or wpa_supplicant in ibss mode (HT20 limited in current version)

 Next in airlogs I saw we are using nss1 and higher mcs
 But for sure qos = 1 is required.

 I am not sure why sta-wme is not set while we have HT rates (is it
 allowed to have HT without WMM?)
 But anyway as a quick workaroud you can try something like this:

 @@ -1212,7 +1212,7 @@ static void ath10k_peer_assoc_h_ht(struct ath10k *ar,
 if (!ht_cap-ht_supported)
 return;

 -   arg-peer_flags |= WMI_PEER_HT;
 +   arg-peer_flags |= WMI_PEER_HT | WMI_PEER_QOS;
 arg-peer_max_mpdu = (1  (IEEE80211_HT_MAX_AMPDU_FACTOR +
 ht_cap-ampdu_factor)) - 1;

 @@ -3464,6 +3464,13 @@ static int ath10k_set_key(struct ieee80211_hw
 *hw, enum set_key_cmd cmd,
   key-cipher == WLAN_CIPHER_SUITE_WEP104;
 int ret = 0;

 BR
 Janusz


 ---
 ChunYeow

 Some of my dmesg:
 [  640.45] ath10k_pci :00:00.0: wmi pdev set param 3 value 34
 [  640.45] ath10k_pci :00:00.0: wmi pdev set param 4 value 34
 [  640.45] ath10k_pci :00:00.0: wmi pdev set wmm params
 [  640.45] ath10k_pci :00:00.0: wmi pdev set wmm params
 [  640.45] ath10k_pci :00:00.0: wmi pdev set wmm params
 [  640.45] ath10k_pci :00:00.0: wmi pdev set wmm params
 [  640.45] ath10k_pci :00:00.0: wmi peer create vdev_id 0
 peer_addr 04:f0:21:0c:a5:1c
 [  640.45] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 16 value 0
 [  640.45] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 3 value 
 100
 [  640.45] ath10k_pci :00:00.0: mac vdev 0 beacon_interval 100
 [  640.45] ath10k_pci :00:00.0: vdev 0 set beacon tx mode to 
 staggered
 [  640.45] ath10k_pci :00:00.0: wmi pdev set param 7 value 0
 [  640.45] ath10k_pci :00:00.0: mac vdev 0 start center_freq
 5180 phymode 11na-ht20
 [  640.45] ath10k_pci :00:00.0: wmi vdev start id 0x0 flags:
 0x0, freq 5180, mode 4, ch_flags: 0x400, max_power: 34
 [  640.46] ath10k_pci :00:00.0: WMI_VDEV_START_RESP_EVENTID
 [  640.46] ath10k_pci :00:00.0: wmi mgmt vdev up id 0x0 assoc
 id 0 bssid 52:8d:75:e5:00:52
 [  640.46] ath10k_pci :00:00.0: mac vdev 0 up
 [  640.46] ath10k_pci :00:00.0: mac vdev 0 cts_prot 0
 [  640.46] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 44 value 0
 [  640.46] ath10k_pci :00:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
 [  640.46] ath10k_pci :00:00.0: mac vdev 0 slot_time 2
 [  640.46] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 7 value 2
 [  640.46] ath10k_pci :00:00.0: mac vdev 0 preamble 1n
 [  640.46] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 8 value 1
 [  640.46] ath10k_pci :00:00.0: mac vdev 0 peer create
 04:f0:21:0c:a5:43 (new sta) sta 1 / 16 peer 2 / 24
 [  640.46] ath10k_pci :00:00.0: wmi peer create vdev_id 0
 peer_addr 04:f0:21:0c:a5:43
 [  640.46] IPv6: ADDRCONF(NETDEV_CHANGE): mesh0: link becomes ready
 [  640.47] ath10k_pci :00:00.0: mac sta 04:f0:21:0c:a5:43 associated
 [  640.47] ath10k_pci :00:00.0: mac peer 04:f0:21:0c:a5:43 qos 0
 [  640.47] ath10k_pci :00:00.0: mac peer 04:f0:21:0c:a5:43 phymode 
 11a
 [  640.47] ath10k_pci :00:00.0: wmi peer assoc vdev 0 addr
 04:f0:21:0c:a5:43 (new)
 [  640.47] ath10k_pci :00:00.0: wmi vdev 0 peer
 0x04:f0:21:0c:a5:43 set param 5 value 1
 [  640.47] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 44 value 
 33
 [  640.47] ath10k_pci :00:00.0: mac monitor recalc started? 0 
 should? 0
 [  640.54] ath10k_pci :00:00.0: mac sta rc update for
 04:f0:21:0c:a5:43 changed 0004 bw 0 nss 1 smps 2
 [  640.54] ath10k_pci :00:00.0: mac sta rc update for
 04:f0:21:0c:a5:43 changed 0008 bw 0 nss 3 smps 2
 [  640.54] ath10k_pci :00:00.0: mac update sta 04:f0:21:0c:a5:43 
 nss 3
 [  640.54] ath10k_pci :00:00.0: wmi vdev 0 peer
 0x04:f0:21:0c:a5:43 set param 5 value 3
 [  640.54] ath10k_pci :00:00.0: mac update sta
 04:f0:21:0c:a5:43 supp rates/nss
 [  640.54] ath10k_pci :00:00.0: mac ht peer 04:f0:21:0c:a5:43
 mcs cnt 24 nss 3
 [  640.54] ath10k_pci :00:00.0: mac peer 04:f0:21:0c:a5:43 qos 0
 [  640.54]

Re: [PATCH v2] staging: rtl8723au: core: fixing foo * bar should be foo *bar

2014-12-16 Thread Jes Sorensen

Asaf Vertz asaf.ve...@tandemg.com writes:
 Fixed a coding style error, foo * bar should be foo *bar

 Signed-off-by: Asaf Vertz asaf.ve...@tandemg.com
 ---
 Changes in v2:
   - fix ugly multiline arguments to the functions

  drivers/staging/rtl8723au/core/rtw_efuse.c |   32 ++-
  1 files changed, 7 insertions(+), 25 deletions(-)

Signed-off-by: Jes Sorensen jes.soren...@redhat.com

 diff --git a/drivers/staging/rtl8723au/core/rtw_efuse.c 
 b/drivers/staging/rtl8723au/core/rtw_efuse.c
 index 81960e7..a6deddc 100644
 --- a/drivers/staging/rtl8723au/core/rtw_efuse.c
 +++ b/drivers/staging/rtl8723au/core/rtw_efuse.c
 @@ -327,15 +327,9 @@ EFUSE_Read1Byte23a(struct rtw_adapter *Adapter, u16 
 Address)
   
 *---*/
  
  void
 -EFUSE_Write1Byte(
 - struct rtw_adapter *Adapter,
 - u16 Address,
 - u8  Value);
 +EFUSE_Write1Byte(struct rtw_adapter *Adapter, u16 Address, u8 Value);
  void
 -EFUSE_Write1Byte(
 - struct rtw_adapter *Adapter,
 - u16 Address,
 - u8  Value)
 +EFUSE_Write1Byte(struct rtw_adapter *Adapter, u16 Address, u8 Value)
  {
   u8  Bytetemp = {0x00};
   u8  temp = {0x00};
 @@ -635,10 +629,7 @@ Efuse_ReadAllMap(struct rtw_adapter *pAdapter, u8 
 efuseType, u8 *Efuse)
   *
   
 *---*/
  static void
 -efuse_ShadowRead1Byte(
 - struct rtw_adapter *pAdapter,
 - u16 Offset,
 - u8  *Value)
 +efuse_ShadowRead1Byte(struct rtw_adapter *pAdapter, u16 Offset, u8 *Value)
  {
   struct eeprom_priv *pEEPROM = GET_EEPROM_EFUSE_PRIV(pAdapter);
  
 @@ -647,10 +638,7 @@ efuse_ShadowRead1Byte(
  
  /* Read Two Bytes */
  static void
 -efuse_ShadowRead2Byte(
 - struct rtw_adapter *pAdapter,
 - u16 Offset,
 - u16 *Value)
 +efuse_ShadowRead2Byte(struct rtw_adapter *pAdapter, u16 Offset, u16 *Value)
  {
   struct eeprom_priv *pEEPROM = GET_EEPROM_EFUSE_PRIV(pAdapter);
  
 @@ -660,10 +648,7 @@ efuse_ShadowRead2Byte(
  
  /* Read Four Bytes */
  static void
 -efuse_ShadowRead4Byte(
 - struct rtw_adapter *pAdapter,
 - u16 Offset,
 - u32 *Value)
 +efuse_ShadowRead4Byte(struct rtw_adapter *pAdapter, u16 Offset, u32 *Value)
  {
   struct eeprom_priv *pEEPROM = GET_EEPROM_EFUSE_PRIV(pAdapter);
  
 @@ -722,11 +707,8 @@ void EFUSE_ShadowMapUpdate23a(struct rtw_adapter 
 *pAdapter, u8 efuseType)
   *
   
 *---*/
  void
 -EFUSE_ShadowRead23a(
 - struct rtw_adapter *pAdapter,
 - u8  Type,
 - u16 Offset,
 - u32 *Value)
 +EFUSE_ShadowRead23a(struct rtw_adapter *pAdapter,
 + u8 Type, u16 Offset, u32 *Value)
  {
   if (Type == 1)
   efuse_ShadowRead1Byte(pAdapter, Offset, (u8 *)Value);
--
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] mac80211: notify channel switch at the end of ieee80211_chswitch_post_beacon()

2014-12-16 Thread Emmanuel Grumbach

From: Luciano Coelho luciano.coe...@intel.com

The call to cfg80211_ch_switch_notify() should be at the end of the
ieee80211_chswitch_post_beacon() function, because it should only be
sent if everything succeeded.

Fixes: d04b5ac9e70b (cfg80211/mac80211: allow any interface to send channel 
switch notifications)
Signed-off-by: Luciano Coelho luciano.coe...@intel.com
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
---
 net/mac80211/mlme.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 75a9bf5..0c6848e 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1053,8 +1053,6 @@ static void ieee80211_chswitch_post_beacon(struct 
ieee80211_sub_if_data *sdata)
sdata-csa_block_tx = false;
}
 
-   cfg80211_ch_switch_notify(sdata-dev, sdata-reserved_chandef);
-
sdata-vif.csa_active = false;
ifmgd-csa_waiting_bcn = false;
 
@@ -1066,6 +1064,8 @@ static void ieee80211_chswitch_post_beacon(struct 
ieee80211_sub_if_data *sdata)
 ifmgd-csa_connection_drop_work);
return;
}
+
+   cfg80211_ch_switch_notify(sdata-dev, sdata-reserved_chandef);
 }
 
 void ieee80211_chswitch_done(struct ieee80211_vif *vif, bool success)
-- 
1.9.1

--
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: BCM4313 brcmsmac 3.12: only semi-working?

2014-12-16 Thread Arend van Spriel


On 12/03/14 13:43, Arend van Spriel wrote:

On 12/02/14 22:40, Michael Tokarev wrote:

30.11.2014 15:04, Arend van Spriel wrote:


Thanks. Did not find what I was looking for, but I started working on
integrating btcoex related functionality. The attached patch will print
some info so I can focus on the required functionality for your device.
It is based on 3.18-rc5.


With this patch applied against 3.18-rc5, the machine instantly reboots
once brcmsmac module is loaded. I'm still debugging this.


Hmm. The function brcms_btc_ecicoex_enab() is calling itself. Please 
remove that call as it causes endless recursion and eventually reboot.


Regards,
Arend


Argh. Probably the register access I added end up in limbo land or some
other stupid mistake. I will double check my patch.

Regards,
Arend


Thanks,

/mjt




--
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

pull request: wireless 2014-12-16

2014-12-16 Thread John W. Linville

Dave,

Please pull this batch of fixes intended for the 3.19 stream!

For the Bluetooth bits, Johan says:

The patches consist of:

 - Coccinelle warning fix
 - hci_dev_lock/unlock fixes
 - Fixes for pending mgmt command handling
 - Fixes for properly following the force_lesc_support switch
 - Fix for a Microsoft branded Broadcom adapter
 - New device id for Atheros AR3012
 - Fix for BR/EDR Secure Connections enabling

Along with that...

Brian Norris avoids leaking some kernel memory contents via printk in brcmsmac.

Julia Lawall corrects some misspellings in a few drivers.

Larry Finger gives us one more rtlwifi fix to correct a porting oversight.

Wei Yongjun fixes a sparse warning in rtlwifi.

Please let me know if there are problems!

Thanks,

John

---

The following changes since commit 67e2c3883828b39548cee2091b36656787775d95:

  Merge branch 'next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security 
(2014-12-14 20:36:37 -0800)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git 
tags/master-2014-12-15

for you to fetch changes up to 9a1dce3a059111a7289680f4b8c0ec4f8736b6ee:

  rtlwifi: rtl8192ce: Set fw_ready flag (2014-12-15 13:46:20 -0500)


Brian Norris (1):
  brcmsmac: don't leak kernel memory via printk()

Fengguang Wu (1):
  Bluetooth: fix err_cast.cocci warnings

Jaganath Kanakkassery (2):
  Bluetooth: Fix missing hci_dev_lock/unlock in mgmt req_complete()
  Bluetooth: Fix missing hci_dev_lock/unlock in hci_event

Janne Heikkinen (1):
  Bluetooth: Add USB device 04ca:3010 as Atheros AR3012

Johan Hedberg (5):
  Bluetooth: Fix calling hci_conn_put too early
  Bluetooth: Fix incorrect pending cmd removal in pairing_complete()
  Bluetooth: Fix notifying mgmt power off before flushing connection list
  Bluetooth: Fix enabling BR/EDR SC when powering on
  Bluetooth: Fix mgmt response status when removing adapter

John W. Linville (1):
  Merge branch 'for-upstream' of 
git://git.kernel.org/.../bluetooth/bluetooth-next

Julia Lawall (3):
  zd1211rw: fix misspelling of current function in string
  hostap_cs: fix misspelling of current function in string
  rtlwifi: rtl8821ae: fix misspelling of current function in string

Larry Finger (1):
  rtlwifi: rtl8192ce: Set fw_ready flag

Marcel Holtmann (4):
  Bluetooth: Check for force_lesc_support when enabling SMP over BR/EDR
  Bluetooth: Check for force_lesc_support before rejecting SMP over BR/EDR
  Bluetooth: Fix generation of non-resolvable private addresses
  Bluetooth: Fix check for support for page scan related commands

Wei Yongjun (1):
  rtlwifi: rtl8192cu: Fix sparse non static symbol warning

 drivers/bluetooth/ath3k.c  |  2 +
 drivers/bluetooth/btusb.c  |  1 +
 drivers/net/wireless/brcm80211/brcmsmac/main.c |  2 +-
 drivers/net/wireless/hostap/hostap_cs.c| 15 ++---
 drivers/net/wireless/rtlwifi/rtl8192ce/hw.c|  2 +
 drivers/net/wireless/rtlwifi/rtl8192cu/hw.c|  2 +-
 drivers/net/wireless/rtlwifi/rtl8821ae/dm.c| 11 ++--
 drivers/net/wireless/zd1211rw/zd_chip.c|  6 +-
 net/bluetooth/hci_conn.c   |  2 +-
 net/bluetooth/hci_core.c   | 60 ++
 net/bluetooth/hci_event.c  | 20 ++
 net/bluetooth/l2cap_core.c |  5 +-
 net/bluetooth/mgmt.c   | 85 ++
 net/bluetooth/smp.c|  5 +-
 14 files changed, 143 insertions(+), 75 deletions(-)

diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index fce758896280..1ee27ac18de0 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -87,6 +87,7 @@ static const struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x04CA, 0x3007) },
{ USB_DEVICE(0x04CA, 0x3008) },
{ USB_DEVICE(0x04CA, 0x300b) },
+   { USB_DEVICE(0x04CA, 0x3010) },
{ USB_DEVICE(0x0930, 0x0219) },
{ USB_DEVICE(0x0930, 0x0220) },
{ USB_DEVICE(0x0930, 0x0227) },
@@ -140,6 +141,7 @@ static const struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x04ca, 0x3007), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x300b), .driver_info = BTUSB_ATH3012 },
+   { USB_DEVICE(0x04ca, 0x3010), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0220), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 31dd24ac9926..19cf2cf22e87 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -167,6 +167,7 @@ static

mac80211 USB adapters with 5GHz support and SMA antenna

2014-12-16 Thread Dani Camps

Dear all,

I am looking for a Wi-Fi adapter with the following specs:

a) Operates at 5GHz
b) Supports 802.11n and optionally 802.11ac
c) USB interface
d) SMA connector for external antenna(s)
e) It is supported by mac80211, and supports mesh mode

I have done a survey and found only two devices that meet the previous
requirements, and they are only 802.11n. Most of the 802.11ac adapters
that I can find use the RT8812AU chipset, which as far as I know is
not supported by mac80211. Are there any plans to support this
chipset?

I am pasting here a list of adapters, and I would appreciate if anyone
who has experimented with them could provide feedback on whether my
understanding is correct.

Best Regards

Daniel

LIST OF ADAPTERS:


1) ALFA AWUS051NH 2.4/ 5GHz Dual Band:

link: 
http://www.wifi-antennas.co.uk/alfa-awus051nh-2-4-5ghz-dual-band-300mbps-usb-wifi-dongle-with-rp-sma-antenna-4547.html
chipset: Ralink RT2870 A/B/G/N
mac80211 support: YES. rt2800usb.
http://wireless.kernel.org/en/users/Drivers/rt2800usb#external_links
mac80211s mesh support: YES. http://wireless.kernel.org/en/users/Drivers

2) Sveon SNT1022

link: 
http://sveon.com/tienda/adaptador-lan-wifi-usb-dual-band-doble-antena-rp-sma-snt1022/
chipset: Ralink 3572 A/B/G/N
mac80211 support: YES. rt2800usb.
http://wireless.kernel.org/en/users/Drivers/rt2800usb
mac80211s mesh support: YES. http://wireless.kernel.org/en/users/Drivers


3) EDIMAX EW-7811USC

link: 
http://www.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/global/wireless_adapters_ac600_dual-band/ew-7811usc/
chipset: Realtek RTL8812AU. AC/A/B/G/N
mac80211 support: NO. Not supported by rtlwifi.
http://wireless.kernel.org/en/users/Drivers/rtl819x
mac8011 mesh support: NO.

4) ALFA AWUS036HAC 1200

link: 
http://www.alfanetworkeurope.eu/en/alfa-awus036hac-ac1200-dual-band-ultra-fast-wifi-u.html
chipset: Realtek RTL8812AU. AC/A/B/G/N. link:
https://wikidevi.com/wiki/List_of_802.11ac_Hardware
mac80211 support: NO.
mac80211s support: NO.

5) ASUS USB-AC56

link: http://www.asus.com/de/Networking/USBAC56/
chipset: Realtek RTL8812AU. AC/B/G/N.
https://wikidevi.com/wiki/List_of_802.11ac_Hardware
mac80211 support: NO.
mac80211s support: NO.

6) ABOCOM AU7212

link: http://www.abocom.com.tw/product.aspx?id=180
chipset: Mediatek MT7610U. AC/A/B/G/N
mac80211 support: NO.
mac80211s support: NO.

7) D-LINK DWA-172

link: http://www.dlink-forum.info/showthread.php?tid=3006
chipset: Realtek RTL8812AU.
mac80211 support: NO.
mac80211s support: NO.

8) HAWKING HD65U

link: http://www.newegg.com/Product/Product.aspx?Item=N82E16833164060
chipset: Realtek RTL8812AU.
mac80211 support: NO.
mac80211s support: NO.
--
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: mac80211 USB adapters with 5GHz support and SMA antenna

2014-12-16 Thread Larry Finger


On 12/16/2014 01:09 PM, Dani Camps wrote:

Dear all,

I am looking for a Wi-Fi adapter with the following specs:

a) Operates at 5GHz
b) Supports 802.11n and optionally 802.11ac
c) USB interface
d) SMA connector for external antenna(s)
e) It is supported by mac80211, and supports mesh mode

I have done a survey and found only two devices that meet the previous
requirements, and they are only 802.11n. Most of the 802.11ac adapters
that I can find use the RT8812AU chipset, which as far as I know is
not supported by mac80211. Are there any plans to support this
chipset?

I am pasting here a list of adapters, and I would appreciate if anyone
who has experimented with them could provide feedback on whether my
understanding is correct.

Best Regards

Daniel

LIST OF ADAPTERS:


1) ALFA AWUS051NH 2.4/ 5GHz Dual Band:

link: 
http://www.wifi-antennas.co.uk/alfa-awus051nh-2-4-5ghz-dual-band-300mbps-usb-wifi-dongle-with-rp-sma-antenna-4547.html
chipset: Ralink RT2870 A/B/G/N
mac80211 support: YES. rt2800usb.
http://wireless.kernel.org/en/users/Drivers/rt2800usb#external_links
mac80211s mesh support: YES. http://wireless.kernel.org/en/users/Drivers

2) Sveon SNT1022

link: 
http://sveon.com/tienda/adaptador-lan-wifi-usb-dual-band-doble-antena-rp-sma-snt1022/
chipset: Ralink 3572 A/B/G/N
mac80211 support: YES. rt2800usb.
http://wireless.kernel.org/en/users/Drivers/rt2800usb
mac80211s mesh support: YES. http://wireless.kernel.org/en/users/Drivers


3) EDIMAX EW-7811USC

link: 
http://www.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/global/wireless_adapters_ac600_dual-band/ew-7811usc/
chipset: Realtek RTL8812AU. AC/A/B/G/N
mac80211 support: NO. Not supported by rtlwifi.
http://wireless.kernel.org/en/users/Drivers/rtl819x
mac8011 mesh support: NO.

4) ALFA AWUS036HAC 1200

link: 
http://www.alfanetworkeurope.eu/en/alfa-awus036hac-ac1200-dual-band-ultra-fast-wifi-u.html
chipset: Realtek RTL8812AU. AC/A/B/G/N. link:
https://wikidevi.com/wiki/List_of_802.11ac_Hardware
mac80211 support: NO.
mac80211s support: NO.

5) ASUS USB-AC56

link: http://www.asus.com/de/Networking/USBAC56/
chipset: Realtek RTL8812AU. AC/B/G/N.
https://wikidevi.com/wiki/List_of_802.11ac_Hardware
mac80211 support: NO.
mac80211s support: NO.

6) ABOCOM AU7212

link: http://www.abocom.com.tw/product.aspx?id=180
chipset: Mediatek MT7610U. AC/A/B/G/N
mac80211 support: NO.
mac80211s support: NO.

7) D-LINK DWA-172

link: http://www.dlink-forum.info/showthread.php?tid=3006
chipset: Realtek RTL8812AU.
mac80211 support: NO.
mac80211s support: NO.

8) HAWKING HD65U

link: http://www.newegg.com/Product/Product.aspx?Item=N82E16833164060
chipset: Realtek RTL8812AU.
mac80211 support: NO.
mac80211s support: NO.


In general, the USB group at Realtek does not support mac80211, the way the PCI 
group does. The only exception is driver rtl8192cu for the RTL81xxCU chips, and 
that driver has received little attention from them since the original release. 
I can fix problems in the interface between the hardware manipulation and Linux, 
but I have no knowledge of the internals of any of the Realtek chips.


As for the RTL8812AU, I have not seen any Linux driver for this chip, but I 
doubt that it supports mac80211; however, most of the drivers for the latest USB 
chips have supported cfg80211, and will work with the latest hostapd version.


It is unfortunate that the USB group at Realtek has taken this stance as I know 
of several users that have chosen not to use their chips because of the 
incomplete Linux drivers. I assume they have good reasons, but I do not know 
what they are.


Larry

--
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: mac80211 USB adapters with 5GHz support and SMA antenna

2014-12-16 Thread Dani Camps

Hi Larry,

Linux drivers for RTL8812AU can be downloaded from here:
http://www.edimax.com/edimax/download/download/data/edimax/global/download/for_home/wireless_adapters/wireless_adapters_ac600_dual-band/ew-7811usc

However, they are not compatible with mac80211, and in my case I need
that support.

Cheers

Daniel

On Tue, Dec 16, 2014 at 8:36 PM, Larry Finger larry.fin...@lwfinger.net wrote:
 On 12/16/2014 01:09 PM, Dani Camps wrote:

 Dear all,

 I am looking for a Wi-Fi adapter with the following specs:

 a) Operates at 5GHz
 b) Supports 802.11n and optionally 802.11ac
 c) USB interface
 d) SMA connector for external antenna(s)
 e) It is supported by mac80211, and supports mesh mode

 I have done a survey and found only two devices that meet the previous
 requirements, and they are only 802.11n. Most of the 802.11ac adapters
 that I can find use the RT8812AU chipset, which as far as I know is
 not supported by mac80211. Are there any plans to support this
 chipset?

 I am pasting here a list of adapters, and I would appreciate if anyone
 who has experimented with them could provide feedback on whether my
 understanding is correct.

 Best Regards

 Daniel

 LIST OF ADAPTERS:
 

 1) ALFA AWUS051NH 2.4/ 5GHz Dual Band:

 link:
 http://www.wifi-antennas.co.uk/alfa-awus051nh-2-4-5ghz-dual-band-300mbps-usb-wifi-dongle-with-rp-sma-antenna-4547.html
 chipset: Ralink RT2870 A/B/G/N
 mac80211 support: YES. rt2800usb.
 http://wireless.kernel.org/en/users/Drivers/rt2800usb#external_links
 mac80211s mesh support: YES. http://wireless.kernel.org/en/users/Drivers

 2) Sveon SNT1022

 link:
 http://sveon.com/tienda/adaptador-lan-wifi-usb-dual-band-doble-antena-rp-sma-snt1022/
 chipset: Ralink 3572 A/B/G/N
 mac80211 support: YES. rt2800usb.
 http://wireless.kernel.org/en/users/Drivers/rt2800usb
 mac80211s mesh support: YES. http://wireless.kernel.org/en/users/Drivers


 3) EDIMAX EW-7811USC

 link:
 http://www.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/global/wireless_adapters_ac600_dual-band/ew-7811usc/
 chipset: Realtek RTL8812AU. AC/A/B/G/N
 mac80211 support: NO. Not supported by rtlwifi.
 http://wireless.kernel.org/en/users/Drivers/rtl819x
 mac8011 mesh support: NO.

 4) ALFA AWUS036HAC 1200

 link:
 http://www.alfanetworkeurope.eu/en/alfa-awus036hac-ac1200-dual-band-ultra-fast-wifi-u.html
 chipset: Realtek RTL8812AU. AC/A/B/G/N. link:
 https://wikidevi.com/wiki/List_of_802.11ac_Hardware
 mac80211 support: NO.
 mac80211s support: NO.

 5) ASUS USB-AC56

 link: http://www.asus.com/de/Networking/USBAC56/
 chipset: Realtek RTL8812AU. AC/B/G/N.
 https://wikidevi.com/wiki/List_of_802.11ac_Hardware
 mac80211 support: NO.
 mac80211s support: NO.

 6) ABOCOM AU7212

 link: http://www.abocom.com.tw/product.aspx?id=180
 chipset: Mediatek MT7610U. AC/A/B/G/N
 mac80211 support: NO.
 mac80211s support: NO.

 7) D-LINK DWA-172

 link: http://www.dlink-forum.info/showthread.php?tid=3006
 chipset: Realtek RTL8812AU.
 mac80211 support: NO.
 mac80211s support: NO.

 8) HAWKING HD65U

 link: http://www.newegg.com/Product/Product.aspx?Item=N82E16833164060
 chipset: Realtek RTL8812AU.
 mac80211 support: NO.
 mac80211s support: NO.


 In general, the USB group at Realtek does not support mac80211, the way the
 PCI group does. The only exception is driver rtl8192cu for the RTL81xxCU
 chips, and that driver has received little attention from them since the
 original release. I can fix problems in the interface between the hardware
 manipulation and Linux, but I have no knowledge of the internals of any of
 the Realtek chips.

 As for the RTL8812AU, I have not seen any Linux driver for this chip, but I
 doubt that it supports mac80211; however, most of the drivers for the latest
 USB chips have supported cfg80211, and will work with the latest hostapd
 version.

 It is unfortunate that the USB group at Realtek has taken this stance as I
 know of several users that have chosen not to use their chips because of the
 incomplete Linux drivers. I assume they have good reasons, but I do not know
 what they are.

 Larry

--
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] mac80211: notify NSS changed when IBSS and HT

2014-12-16 Thread Johannes Berg

On Tue, 2014-12-16 at 09:56 +0100, Janusz Dziedzic wrote:

   drv_sta_rc_update(local, sdata, sta-sta,
 IEEE80211_RC_SUPP_RATES_CHANGED);
 + /* Force rx_nss recalculation */
 + sta-sta.rx_nss = 0;
   rate_control_rate_init(sta);
 + if (rx_nss != sta-sta.rx_nss)
 + drv_sta_rc_update(local, sdata, sta-sta,
 +   IEEE80211_RC_NSS_CHANGED);

Seems to me you should consolidate those two drv_sta_rc_update() calls
and just make the flags dependent on the NSS change?

johannes

--
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: wireless 2014-12-16

2014-12-16 Thread David Miller

From: John W. Linville linvi...@tuxdriver.com
Date: Tue, 16 Dec 2014 13:16:13 -0500

 Please pull this batch of fixes intended for the 3.19 stream!

Pulled, thanks a lot John.
--
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

Your email address

2014-12-16 Thread Email Prefix



Your email address has been added to our website www.emailprefix.com by third 
party or through internet crawling. If you do not want your email to be 
published on our website, you may go to our website to delete your email 
address. 

This is a one-time-communication. We will not send anything else to you in the 
future, nor we will use your email for any other purpose. If you have any 
question, please contact us at http://www.emailprefix.com/contact.php. 

Regards,
  
www.emailprefix.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 1/2] ath10k: fix low TX rates when IBSS and HT

2014-12-16 Thread Yeoh Chun-Yeow

Hi, Janusz

I have figured out the problem, need the following patch to make sure
the QoS is set which is not in my kernel.
http://www.spinics.net/lists/linux-wireless/msg125241.html

sta-sta.wme = true is needed in ibss.c.

So applying these patches and it works, you can add Tested-by if you want.

Thanks


Chun-Yeow

On Tue, Dec 16, 2014 at 9:32 PM, Yeoh Chun-Yeow yeohchuny...@gmail.com wrote:
 Ok, I will try this and investigate further.

 ---
 ChunYeow

 On Tue, Dec 16, 2014 at 7:45 PM, Janusz Dziedzic
 janusz.dzied...@tieto.com wrote:
 On 16 December 2014 at 12:22, Janusz Dziedzic janusz.dzied...@tieto.com 
 wrote:
 On 16 December 2014 at 12:10, Yeoh Chun-Yeow yeohchuny...@gmail.com wrote:
 Hi, Janusz

 I have applied the three patches and tested with firmware
 999.999.0.636 but not working.

 Any advice what's wrong?

 mac peer 04:f0:21:0c:a5:43 qos 0 - this is suspect.
 What is your test procedure (I see some mesh ...)?
 Maybe additional patch for mesh is required?

 I tested this using ath9k + ath10k (636) +
 iw wlanx set type ibss
 iw ibss join  5180 HT [HT40+]
 or wpa_supplicant in ibss mode (HT20 limited in current version)

 Next in airlogs I saw we are using nss1 and higher mcs
 But for sure qos = 1 is required.

 I am not sure why sta-wme is not set while we have HT rates (is it
 allowed to have HT without WMM?)
 But anyway as a quick workaroud you can try something like this:

 @@ -1212,7 +1212,7 @@ static void ath10k_peer_assoc_h_ht(struct ath10k *ar,
 if (!ht_cap-ht_supported)
 return;

 -   arg-peer_flags |= WMI_PEER_HT;
 +   arg-peer_flags |= WMI_PEER_HT | WMI_PEER_QOS;
 arg-peer_max_mpdu = (1  (IEEE80211_HT_MAX_AMPDU_FACTOR +
 ht_cap-ampdu_factor)) - 1;

 @@ -3464,6 +3464,13 @@ static int ath10k_set_key(struct ieee80211_hw
 *hw, enum set_key_cmd cmd,
   key-cipher == WLAN_CIPHER_SUITE_WEP104;
 int ret = 0;

 BR
 Janusz


 ---
 ChunYeow

 Some of my dmesg:
 [  640.45] ath10k_pci :00:00.0: wmi pdev set param 3 value 34
 [  640.45] ath10k_pci :00:00.0: wmi pdev set param 4 value 34
 [  640.45] ath10k_pci :00:00.0: wmi pdev set wmm params
 [  640.45] ath10k_pci :00:00.0: wmi pdev set wmm params
 [  640.45] ath10k_pci :00:00.0: wmi pdev set wmm params
 [  640.45] ath10k_pci :00:00.0: wmi pdev set wmm params
 [  640.45] ath10k_pci :00:00.0: wmi peer create vdev_id 0
 peer_addr 04:f0:21:0c:a5:1c
 [  640.45] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 16 value  0
 [  640.45] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 3 value 
 100
 [  640.45] ath10k_pci :00:00.0: mac vdev 0 beacon_interval 100
 [  640.45] ath10k_pci :00:00.0: vdev 0 set beacon tx mode to 
 staggered
 [  640.45] ath10k_pci :00:00.0: wmi pdev set param 7 value 0
 [  640.45] ath10k_pci :00:00.0: mac vdev 0 start center_freq
 5180 phymode 11na-ht20
 [  640.45] ath10k_pci :00:00.0: wmi vdev start id 0x0 flags:
 0x0, freq 5180, mode 4, ch_flags: 0x400, max_power: 34
 [  640.46] ath10k_pci :00:00.0: WMI_VDEV_START_RESP_EVENTID
 [  640.46] ath10k_pci :00:00.0: wmi mgmt vdev up id 0x0 assoc
 id 0 bssid 52:8d:75:e5:00:52
 [  640.46] ath10k_pci :00:00.0: mac vdev 0 up
 [  640.46] ath10k_pci :00:00.0: mac vdev 0 cts_prot 0
 [  640.46] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 44 value  0
 [  640.46] ath10k_pci :00:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
 [  640.46] ath10k_pci :00:00.0: mac vdev 0 slot_time 2
 [  640.46] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 7 value 2
 [  640.46] ath10k_pci :00:00.0: mac vdev 0 preamble 1n
 [  640.46] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 8 value 1
 [  640.46] ath10k_pci :00:00.0: mac vdev 0 peer create
 04:f0:21:0c:a5:43 (new sta) sta 1 / 16 peer 2 / 24
 [  640.46] ath10k_pci :00:00.0: wmi peer create vdev_id 0
 peer_addr 04:f0:21:0c:a5:43
 [  640.46] IPv6: ADDRCONF(NETDEV_CHANGE): mesh0: link becomes ready
 [  640.47] ath10k_pci :00:00.0: mac sta 04:f0:21:0c:a5:43 
 associated
 [  640.47] ath10k_pci :00:00.0: mac peer 04:f0:21:0c:a5:43 qos 0
 [  640.47] ath10k_pci :00:00.0: mac peer 04:f0:21:0c:a5:43 phymode 
 11a
 [  640.47] ath10k_pci :00:00.0: wmi peer assoc vdev 0 addr
 04:f0:21:0c:a5:43 (new)
 [  640.47] ath10k_pci :00:00.0: wmi vdev 0 peer
 0x04:f0:21:0c:a5:43 set param 5 value 1
 [  640.47] ath10k_pci :00:00.0: wmi vdev id 0x0 set param 44 value 
 33
 [  640.47] ath10k_pci :00:00.0: mac monitor recalc started? 0 
 should? 0
 [  640.54] ath10k_pci :00:00.0: mac sta rc update for
 04:f0:21:0c:a5:43 changed 0004 bw 0 nss 1 smps 2
 [  640.54] ath10k_pci :00:00.0: mac sta rc update for
 04:f0:21:0c:a5:43 changed 0008 bw 0 nss 3 smps 2
 [  640.54] ath10k_pci :00:00.0: mac

[PATCH 1/2] ath10k: fix low TX rates when IBSS and HT

[PATCH 2/2] ath10k: send (re)assoc peer command when NSS changed

[PATCH] mac80211: notify NSS changed when IBSS and HT

Re: [PATCH] mac80211: add an intermediate software queue implementation

[PATCH] staging: rtl8723au: core: fixing foo * bar should be foo *bar

Re: [PATCH 1/2] ath10k: fix low TX rates when IBSS and HT

Re: [PATCH 1/2] ath10k: fix low TX rates when IBSS and HT

Re: [PATCH] staging: rtl8723au: core: fixing foo * bar should be foo *bar

Re: [PATCH 1/2] ath10k: fix low TX rates when IBSS and HT

Re: [PATCH 1/2] ath10k: fix low TX rates when IBSS and HT

Re: [PATCH v2] staging: rtl8723au: core: fixing foo * bar should be foo *bar

[PATCH] mac80211: notify channel switch at the end of ieee80211_chswitch_post_beacon()

Re: BCM4313 brcmsmac 3.12: only semi-working?

pull request: wireless 2014-12-16

mac80211 USB adapters with 5GHz support and SMA antenna

Re: mac80211 USB adapters with 5GHz support and SMA antenna

Re: mac80211 USB adapters with 5GHz support and SMA antenna

Re: [PATCH] mac80211: notify NSS changed when IBSS and HT

Re: pull request: wireless 2014-12-16

Your email address

Re: [PATCH 1/2] ath10k: fix low TX rates when IBSS and HT

21 matches

Site Navigation

Mail list logo

Footer information