date:20160713

Re: [PATCH 3/4 v1] Continue breaking down to smaller functions

2016-07-13 Thread kbuild test robot

Hi,

[auto build test WARNING on mac80211/master]
[also build test WARNING on v4.7-rc7]
[cannot apply to mac80211-next/master next-20160712]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Alex-Briskin/Refactoring-ieee80211_iface_work/20160714-042301
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
master
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All warnings (new ones prefixed by >>):

   net/mac80211/iface.c: In function 'ieee80211_iface_work':
>> net/mac80211/iface.c:1333:19: warning: unused variable 'sta' 
>> [-Wunused-variable]
 struct sta_info *sta;
  ^

vim +/sta +1333 net/mac80211/iface.c

  1317 
WLAN_REASON_QSTA_REQUIRE_SETUP,
  1318 true);
  1319  }
  1320  mutex_unlock(>sta_mtx);
  1321  } else {
  1322  return false;
  1323  }
  1324  return true;
  1325  }
  1326  
  1327  static void ieee80211_iface_work(struct work_struct *work)
  1328  {
  1329  struct ieee80211_sub_if_data *sdata =
  1330  container_of(work, struct ieee80211_sub_if_data, work);
  1331  struct ieee80211_local *local = sdata->local;
  1332  struct sk_buff *skb;
> 1333  struct sta_info *sta;
  1334  
  1335  if (!ieee80211_sdata_running(sdata))
  1336  return;
  1337  
  1338  if (test_bit(SCAN_SW_SCANNING, >scanning))
  1339  return;
  1340  
  1341  if (!ieee80211_can_run_worker(local))

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH 2/4 v1] even better readability

2016-07-13 Thread Alex Briskin

Further improve readability by replacing if else with switch case

Signed-off-by: Alex Briskin 
---
 net/mac80211/iface.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index a68cbac..1793ad2 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1207,13 +1207,16 @@ static bool ieee80211_is_skb_handled_by_pkt_type(struct 
sk_buff *skb,
struct ieee80211_local *local = sdata->local;
struct sta_info *sta;
 
-   if (skb->pkt_type == IEEE80211_SDATA_QUEUE_AGG_START) {
+   switch (skb->pkt_type) {
+   case IEEE80211_SDATA_QUEUE_AGG_START:
ra_tid = (void *)>cb;
ieee80211_start_tx_ba_cb(>vif, ra_tid->ra, ra_tid->tid);
-   } else if (skb->pkt_type == IEEE80211_SDATA_QUEUE_AGG_STOP) {
+   break;
+   case IEEE80211_SDATA_QUEUE_AGG_STOP:
ra_tid = (void *)>cb;
ieee80211_stop_tx_ba_cb(>vif, ra_tid->ra, ra_tid->tid);
-   } else if (skb->pkt_type == IEEE80211_SDATA_QUEUE_RX_AGG_START) {
+   break;
+   case IEEE80211_SDATA_QUEUE_RX_AGG_START:
rx_agg = (void *)>cb;
mutex_lock(>sta_mtx);
sta = sta_info_get_bss(sdata, rx_agg->addr);
@@ -1223,7 +1226,8 @@ static bool ieee80211_is_skb_handled_by_pkt_type(struct 
sk_buff *skb,
IEEE80211_MAX_AMPDU_BUF,
false, true);
mutex_unlock(>sta_mtx);
-   } else if (skb->pkt_type == IEEE80211_SDATA_QUEUE_RX_AGG_STOP) {
+   break;
+   case IEEE80211_SDATA_QUEUE_RX_AGG_STOP:
rx_agg = (void *)>cb;
mutex_lock(>sta_mtx);
sta = sta_info_get_bss(sdata, rx_agg->addr);
@@ -1233,7 +1237,8 @@ static bool ieee80211_is_skb_handled_by_pkt_type(struct 
sk_buff *skb,
   WLAN_BACK_RECIPIENT, 0,
   false);
mutex_unlock(>sta_mtx);
-   } else {
+   break;
+   default:
return false;
}
/*will return true if pkt_type found and handled */
-- 
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 0/4 v1] Refactoring ieee80211_iface_work

2016-07-13 Thread Alex Briskin

Hi All,
This is my first patch(s).

I've decided to refactor ieee80211_iface_work function and break it down
to smaller better defined function.

I think these changes make the code much more readable and do not impose
no overhead.

I've tested these patches with sparse and checkpatch.pl 

Function names might not be descriptive enough.
Hope you find this useful.

Alex Briskin (4):
  0) [28e464b19aaaba90c8946fb979b58709d55dffcf] 
Added new function ieee80211_is_skb_handled_by_pkt_type and moved
some code from ieee80211_iface_work to reduce complexity and 
improve readability

  1) [486e3d5abb4dc6361cdd923254a2b68d43dcdaba]
Refactored code in ieee80211_is_skb_handled_by_pkt_type.
"if () {} else if ()" replaced by switch case. 

  2) [9ef2eab8e831420bc6748a4466ffa6b7a99bf447]
Added new function ieee80211_is_handled_by_frame_control and moved
some code from ieee80211_iface_work to it.

  3) [1de8cdf9a0c05c6a21d9e43e5b55862f6efcf450] 
Added new function ieee80211_handle_by_vif_type with code from
ieee80211_iface_work.

At this point ieee80211_iface_work seems to me much more readable
and better understood. 

 net/mac80211/iface.c | 264 +--
 1 file changed, 150 insertions(+), 114 deletions(-)

-- 
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 4/4 v1] Simple and well understood logic

2016-07-13 Thread Alex Briskin

Now the logic is obvious - if skb not handled by pkt type and not handled
by frame control it is handled by vif type and then released

Signed-off-by: Alex Briskin 
---
 net/mac80211/iface.c | 44 
 1 file changed, 24 insertions(+), 20 deletions(-)

diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 41c3bd0..76e8c6a 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1324,6 +1324,27 @@ static bool ieee80211_is_handled_by_frame_control(struct 
sk_buff *skb,
return true;
 }
 
+static void ieee80211_handle_by_vif_type(struct sk_buff *skb,
+struct ieee80211_sub_if_data *sdata)
+{
+   switch (sdata->vif.type) {
+   case NL80211_IFTYPE_STATION:
+   ieee80211_sta_rx_queued_mgmt(sdata, skb);
+   break;
+   case NL80211_IFTYPE_ADHOC:
+   ieee80211_ibss_rx_queued_mgmt(sdata, skb);
+   break;
+   case NL80211_IFTYPE_MESH_POINT:
+   if (!ieee80211_vif_is_mesh(>vif))
+   break;
+   ieee80211_mesh_rx_queued_mgmt(sdata, skb);
+   break;
+   default:
+   WARN(1, "frame for unexpected interface type");
+   break;
+   }
+}
+
 static void ieee80211_iface_work(struct work_struct *work)
 {
struct ieee80211_sub_if_data *sdata =
@@ -1343,28 +1364,11 @@ static void ieee80211_iface_work(struct work_struct 
*work)
 
/* first process frames */
while ((skb = skb_dequeue(>skb_queue))) {
-   if (ieee80211_is_skb_handled_by_pkt_type(skb, sdata)) {
-   goto free_skb;
-   } else if (ieee80211_is_handled_by_frame_control(skb, sdata)) {
-   goto free_skb;
-   } else switch (sdata->vif.type) {
-   case NL80211_IFTYPE_STATION:
-   ieee80211_sta_rx_queued_mgmt(sdata, skb);
-   break;
-   case NL80211_IFTYPE_ADHOC:
-   ieee80211_ibss_rx_queued_mgmt(sdata, skb);
-   break;
-   case NL80211_IFTYPE_MESH_POINT:
-   if (!ieee80211_vif_is_mesh(>vif))
-   break;
-   ieee80211_mesh_rx_queued_mgmt(sdata, skb);
-   break;
-   default:
-   WARN(1, "frame for unexpected interface type");
-   break;
+   if (!ieee80211_is_skb_handled_by_pkt_type(skb, sdata) &&
+   !ieee80211_is_handled_by_frame_control(skb, sdata)) {
+   ieee80211_handle_by_vif_type(skb, sdata);
}
 
-free_skb:
kfree_skb(skb);
}
 
-- 
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 3/4 v1] Continue breaking down to smaller functions

2016-07-13 Thread Alex Briskin

This commit contains unhandled checkpatch warnings in code moved from
ieee80211_iface_work

Signed-off-by: Alex Briskin 
---
 net/mac80211/iface.c | 150 +++
 1 file changed, 81 insertions(+), 69 deletions(-)

diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 1793ad2..41c3bd0 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1245,6 +1245,85 @@ static bool ieee80211_is_skb_handled_by_pkt_type(struct 
sk_buff *skb,
return true;
 }
 
+static bool ieee80211_is_handled_by_frame_control(struct sk_buff *skb,
+ struct ieee80211_sub_if_data
+ *sdata)
+{
+   struct ieee80211_local *local = sdata->local;
+   struct sta_info *sta;
+   struct ieee80211_mgmt *mgmt = (void *)skb->data;
+
+   if (ieee80211_is_action(mgmt->frame_control) &&
+   mgmt->u.action.category == WLAN_CATEGORY_BACK) {
+   int len = skb->len;
+
+   mutex_lock(>sta_mtx);
+   sta = sta_info_get_bss(sdata, mgmt->sa);
+   if (sta) {
+   switch (mgmt->u.action.u.addba_req.action_code) {
+   case WLAN_ACTION_ADDBA_REQ:
+   ieee80211_process_addba_request(local, sta,
+   mgmt, len);
+   break;
+   case WLAN_ACTION_ADDBA_RESP:
+   ieee80211_process_addba_resp(local, sta,
+mgmt, len);
+   break;
+   case WLAN_ACTION_DELBA:
+   ieee80211_process_delba(sdata, sta, mgmt, len);
+   break;
+   default:
+   WARN_ON(1);
+   break;
+   }
+   }
+   mutex_unlock(>sta_mtx);
+   } else if (ieee80211_is_action(mgmt->frame_control) &&
+  mgmt->u.action.category == WLAN_CATEGORY_VHT) {
+   switch (mgmt->u.action.u.vht_group_notif.action_code) {
+   case WLAN_VHT_ACTION_GROUPID_MGMT:
+   ieee80211_process_mu_groups(sdata, mgmt);
+   break;
+   default:
+   WARN_ON(1);
+   break;
+   }
+   } else if (ieee80211_is_data_qos(mgmt->frame_control)) {
+   struct ieee80211_hdr *hdr = (void *)mgmt;
+   /*
+* So the frame isn't mgmt, but frame_control
+* is at the right place anyway, of course, so
+* the if statement is correct.
+*
+* Warn if we have other data frame types here,
+* they must not get here.
+*/
+   WARN_ON(hdr->frame_control &
+   cpu_to_le16(IEEE80211_STYPE_NULLFUNC));
+   WARN_ON(!(hdr->seq_ctrl & cpu_to_le16(IEEE80211_SCTL_FRAG)));
+   /*
+* This was a fragment of a frame, received while
+* a block-ack session was active. That cannot be
+* right, so terminate the session.
+*/
+   mutex_lock(>sta_mtx);
+   sta = sta_info_get_bss(sdata, mgmt->sa);
+   if (sta) {
+   u16 tid = *ieee80211_get_qos_ctl(hdr) &
+   IEEE80211_QOS_CTL_TID_MASK;
+
+   __ieee80211_stop_rx_ba_session(sta, tid,
+  WLAN_BACK_RECIPIENT,
+  
WLAN_REASON_QSTA_REQUIRE_SETUP,
+  true);
+   }
+   mutex_unlock(>sta_mtx);
+   } else {
+   return false;
+   }
+   return true;
+}
+
 static void ieee80211_iface_work(struct work_struct *work)
 {
struct ieee80211_sub_if_data *sdata =
@@ -1264,77 +1343,10 @@ static void ieee80211_iface_work(struct work_struct 
*work)
 
/* first process frames */
while ((skb = skb_dequeue(>skb_queue))) {
-   struct ieee80211_mgmt *mgmt = (void *)skb->data;
-
if (ieee80211_is_skb_handled_by_pkt_type(skb, sdata)) {
goto free_skb;
-   } else if (ieee80211_is_action(mgmt->frame_control) &&
-  mgmt->u.action.category == WLAN_CATEGORY_BACK) {
-   int len = skb->len;
-
-   mutex_lock(>sta_mtx);
-   sta = sta_info_get_bss(sdata, mgmt->sa);
-   if (sta) {
-   switch (mgmt->u.action.u.addba_req.action_code) 
{
-

[PATCH 1/4 v1] Refactoring ieee80211_iface_work to reduce complexity and improve readability.

2016-07-13 Thread Alex Briskin

No performance impact/overhead expected. The (gcc) compiler optimizes the
added function out.

Signed-off-by: Alex Briskin 
---
 net/mac80211/iface.c | 75 +++-
 1 file changed, 45 insertions(+), 30 deletions(-)

diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index c59af3e..a68cbac 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1198,6 +1198,48 @@ static void ieee80211_if_setup(struct net_device *dev)
dev->destructor = ieee80211_if_free;
 }
 
+static bool ieee80211_is_skb_handled_by_pkt_type(struct sk_buff *skb,
+struct ieee80211_sub_if_data
+*sdata)
+{
+   struct ieee80211_ra_tid *ra_tid;
+   struct ieee80211_rx_agg *rx_agg;
+   struct ieee80211_local *local = sdata->local;
+   struct sta_info *sta;
+
+   if (skb->pkt_type == IEEE80211_SDATA_QUEUE_AGG_START) {
+   ra_tid = (void *)>cb;
+   ieee80211_start_tx_ba_cb(>vif, ra_tid->ra, ra_tid->tid);
+   } else if (skb->pkt_type == IEEE80211_SDATA_QUEUE_AGG_STOP) {
+   ra_tid = (void *)>cb;
+   ieee80211_stop_tx_ba_cb(>vif, ra_tid->ra, ra_tid->tid);
+   } else if (skb->pkt_type == IEEE80211_SDATA_QUEUE_RX_AGG_START) {
+   rx_agg = (void *)>cb;
+   mutex_lock(>sta_mtx);
+   sta = sta_info_get_bss(sdata, rx_agg->addr);
+   if (sta)
+   __ieee80211_start_rx_ba_session(sta,
+   0, 0, 0, 1, rx_agg->tid,
+   IEEE80211_MAX_AMPDU_BUF,
+   false, true);
+   mutex_unlock(>sta_mtx);
+   } else if (skb->pkt_type == IEEE80211_SDATA_QUEUE_RX_AGG_STOP) {
+   rx_agg = (void *)>cb;
+   mutex_lock(>sta_mtx);
+   sta = sta_info_get_bss(sdata, rx_agg->addr);
+   if (sta)
+   __ieee80211_stop_rx_ba_session(sta,
+  rx_agg->tid,
+  WLAN_BACK_RECIPIENT, 0,
+  false);
+   mutex_unlock(>sta_mtx);
+   } else {
+   return false;
+   }
+   /*will return true if pkt_type found and handled */
+   return true;
+}
+
 static void ieee80211_iface_work(struct work_struct *work)
 {
struct ieee80211_sub_if_data *sdata =
@@ -1205,8 +1247,6 @@ static void ieee80211_iface_work(struct work_struct *work)
struct ieee80211_local *local = sdata->local;
struct sk_buff *skb;
struct sta_info *sta;
-   struct ieee80211_ra_tid *ra_tid;
-   struct ieee80211_rx_agg *rx_agg;
 
if (!ieee80211_sdata_running(sdata))
return;
@@ -1221,34 +1261,8 @@ static void ieee80211_iface_work(struct work_struct 
*work)
while ((skb = skb_dequeue(>skb_queue))) {
struct ieee80211_mgmt *mgmt = (void *)skb->data;
 
-   if (skb->pkt_type == IEEE80211_SDATA_QUEUE_AGG_START) {
-   ra_tid = (void *)>cb;
-   ieee80211_start_tx_ba_cb(>vif, ra_tid->ra,
-ra_tid->tid);
-   } else if (skb->pkt_type == IEEE80211_SDATA_QUEUE_AGG_STOP) {
-   ra_tid = (void *)>cb;
-   ieee80211_stop_tx_ba_cb(>vif, ra_tid->ra,
-   ra_tid->tid);
-   } else if (skb->pkt_type == IEEE80211_SDATA_QUEUE_RX_AGG_START) 
{
-   rx_agg = (void *)>cb;
-   mutex_lock(>sta_mtx);
-   sta = sta_info_get_bss(sdata, rx_agg->addr);
-   if (sta)
-   __ieee80211_start_rx_ba_session(sta,
-   0, 0, 0, 1, rx_agg->tid,
-   IEEE80211_MAX_AMPDU_BUF,
-   false, true);
-   mutex_unlock(>sta_mtx);
-   } else if (skb->pkt_type == IEEE80211_SDATA_QUEUE_RX_AGG_STOP) {
-   rx_agg = (void *)>cb;
-   mutex_lock(>sta_mtx);
-   sta = sta_info_get_bss(sdata, rx_agg->addr);
-   if (sta)
-   __ieee80211_stop_rx_ba_session(sta,
-   rx_agg->tid,
-   WLAN_BACK_RECIPIENT, 0,
-   false);
-   mutex_unlock(>sta_mtx);
+   if (ieee80211_is_skb_handled_by_pkt_type(skb, sdata)) {
+

[PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template

2016-07-13 Thread Yaniv Machani

The HT capab info field inside the HT capab IE of the mesh beacon
is incorrect (in the case of 20MHz channel width).
To fix this driver will check configuration from cfg and
will build it accordingly.

Signed-off-by: Meirav Kama 
Signed-off-by: Yaniv Machani 
---
V3 - Fixes redundant spaces,empty lines and added FALLTHROUGH note.

 net/mac80211/mesh.c | 33 -
 net/mac80211/util.c |  3 ---
 2 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 9214bc1..6a67049 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -422,6 +422,7 @@ int mesh_add_ht_cap_ie(struct ieee80211_sub_if_data *sdata,
enum nl80211_band band = ieee80211_get_sdata_band(sdata);
struct ieee80211_supported_band *sband;
u8 *pos;
+   u16 cap;
 
sband = local->hw.wiphy->bands[band];
if (!sband->ht_cap.ht_supported ||
@@ -430,11 +431,41 @@ int mesh_add_ht_cap_ie(struct ieee80211_sub_if_data 
*sdata,
sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_10)
return 0;
 
+   /* determine capability flags */
+   cap = sband->ht_cap.cap;
+
+   /* if channel width is 20MHz - configure HT capab accordingly*/
+   if (sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20) {
+   cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
+   cap &= ~IEEE80211_HT_CAP_DSSSCCK40;
+   }
+
+   /* set SM PS mode properly */
+   cap &= ~IEEE80211_HT_CAP_SM_PS;
+   switch (sdata->smps_mode) {
+   case IEEE80211_SMPS_AUTOMATIC:
+   case IEEE80211_SMPS_NUM_MODES:
+   WARN_ON(1);
+   /* FALLTHROUGH */
+   case IEEE80211_SMPS_OFF:
+   cap |= WLAN_HT_CAP_SM_PS_DISABLED <<
+   IEEE80211_HT_CAP_SM_PS_SHIFT;
+   break;
+   case IEEE80211_SMPS_STATIC:
+   cap |= WLAN_HT_CAP_SM_PS_STATIC <<
+   IEEE80211_HT_CAP_SM_PS_SHIFT;
+   break;
+   case IEEE80211_SMPS_DYNAMIC:
+   cap |= WLAN_HT_CAP_SM_PS_DYNAMIC <<
+   IEEE80211_HT_CAP_SM_PS_SHIFT;
+   break;
+   }
+
if (skb_tailroom(skb) < 2 + sizeof(struct ieee80211_ht_cap))
return -ENOMEM;
 
pos = skb_put(skb, 2 + sizeof(struct ieee80211_ht_cap));
-   ieee80211_ie_build_ht_cap(pos, >ht_cap, sband->ht_cap.cap);
+   ieee80211_ie_build_ht_cap(pos, >ht_cap, cap);
 
return 0;
 }
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 42bf0b6..5375a82 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2349,10 +2349,7 @@ u8 *ieee80211_ie_build_ht_oper(u8 *pos, struct 
ieee80211_sta_ht_cap *ht_cap,
ht_oper->operation_mode = cpu_to_le16(prot_mode);
ht_oper->stbc_param = 0x;
 
-   /* It seems that Basic MCS set and Supported MCS set
-  are identical for the first 10 bytes */
memset(_oper->basic_set, 0, 16);
-   memcpy(_oper->basic_set, _cap->mcs, 10);
 
return pos + sizeof(struct ieee80211_ht_operation);
 }
-- 
2.9.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

Fast Loans

2016-07-13 Thread Financial Service

Hae lainaa 3% vastaus tähän viestiin lisätietoja

Apply for a loan at 3% reply to this Email for more Info
--
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/4] mac80211: mesh: flush stations before beacons are stopped

2016-07-13 Thread Machani, Yaniv

On Wed, Jul 13, 2016 at 16:33:38, Bob Copeland wrote:
> linux- wirel...@vger.kernel.org; net...@vger.kernel.org; Hahn, Maital
> Subject: Re: [PATCH 1/4] mac80211: mesh: flush stations before beacons 
> are stopped
> 
> On Wed, Jul 13, 2016 at 10:11:25AM +, Machani, Yaniv wrote:
> > > > Some drivers (e.g. wl18xx) expect that the last stage in the 
> > > > de-initialization process will be stopping the beacons, similar to ap.
> > > > Update ieee80211_stop_mesh() flow accordingly.
> > > >
> > > How well have you tested that with other drivers?
> > >
> >
> > Sorry for the delayed response (I've been out) and thanks for your 
> > comments, I have tested it with RT3572 as well, and didn't see any issue.
> > I'll update the comment to reflect that.
> 
> I'll give this a test on ath10k and wcn36xx as they are the ones most 
> likely to care about ordering.
> 

Thank you,
Yaniv
> --
> Bob Copeland %% http://bobcopeland.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 v4] brcmfmac: Decrease 8021x_cnt for dropped packets

2016-07-13 Thread Per Förlin

2016-07-13 13:20 GMT+02:00 Arend Van Spriel :
> On 12-7-2016 12:23, Per Förlin wrote:
>> 2016-07-12 11:48 GMT+02:00 Arend Van Spriel :
>>>
>>>
>>> On 12-7-2016 10:35, Per Förlin wrote:
 2016-07-06 11:53 GMT+02:00 Per Förlin :
> I have now verified this patch on backports 4.4.
>
> 2016-04-12 23:55 GMT+02:00  :
>> From: Per Forlin 
>>
>> This patch resolves an issue where pend_8021x_cnt was not decreased
>> on txfinalize. This caused brcmf_netdev_wait_pend8021x to timeout
>> because the counter indicated pending packets.
>>
>> WARNING: at .../brcmfmac/core.c:1289 brcmf_netdev_wait_pend8021x
>>   (warn_slowpath_common)
>>   (warn_slowpath_null)
>>   (brcmf_netdev_wait_pend8021x [brcmfmac])
>>   (send_key_to_dongle [brcmfmac])
>>   (brcmf_cfg80211_del_key [brcmfmac])
>>   (nl80211_del_key [cfg80211])
>>   (genl_rcv_msg)
>>   (netlink_rcv_skb)
>>   (genl_rcv)
>>   (netlink_unicast)
>>   (netlink_sendmsg)
>>   (sock_sendmsg)
>>   (___sys_sendmsg)
>>   (__sys_sendmsg)
>>   (SyS_sendmsg)
>>
>> The solution is to pull back the header offset in case
>> of an error in txdata(), which may happen in case of
 Clarification:

 txdata=brcmf_proto_bcdc_txdata()
 brcmf_proto_bcdc_txdata(): Calls brcmf_proto_bcdc_hdrpush()

 The header needs to be pulled back in case of error otherwise
 the error handling and cleanup up will fail to decrease the counter
 of pending packets.
>>>
>>> Yes, this part of the patch is clear to me.
>>>
>> Thanks, I wasn't sure.
>>
>> packet overload in brcmf_sdio_bus_txdata.
>>
>> Overloading an WLAN interface is not an unlikely scenario.
>>>
>>> So here is where things start to look suspicious and I have mentioned
>>> this before. My thought here was "How the hell can you end up with a
>>> 2048 packets on the sdio queue", which I mentioned to you before. There
>>> is a high watermark on the queue upon which we do a netif_stop_queue()
>>> so network layer does not keep pushing tx packets our way. Looking
>>> further into this I found that we introduced a bug with commit
>>> 9cd18359d31e ("brcmfmac: Make FWS queueing configurable.") so we ended
>>> up doing nothing except increasing as statistics debug counter :-(
>>>
>> Is there a fix available for the high watermark issue or is it
>> something you will look into?
>>
>> To produce a load on the wlan interface I run
>> iperf -c 239.255.1.3 -u -b 10m -f m -i 60 -t 3000
>> and this is enough in my case to fill up the 2048 queue.
>>
>> In case of packet overload the error print "out of bus->txq"
>> is very verbose. To reduce SPAM degrade it to a debug print.
>>
>> Signed-off-by: Per Forlin 
>> ---
>> Change log:
>>  v2 - Add variable to know whether the counter is increased or not
>>  v3 - txfinalize should decrease the counter. Adjust skb header offset
>>  v4 - Fix build error
>>
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 4 
>>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c | 4 +++-
>>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
>>  3 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>> index ed9998b..f342f7c 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>> @@ -541,6 +541,9 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct 
>> sk_buff *txp, bool success)
>> struct ethhdr *eh;
>> u16 type;
>>
>> +   if (!ifp)
>> +   goto free;
>> +
>>>
>>> This may not be needed.
>>>
>> This is not strictly needed. I can remove it.
>>
>> eh = (struct ethhdr *)(txp->data);
>> type = ntohs(eh->h_proto);
>>
>> @@ -553,6 +556,7 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct 
>> sk_buff *txp, bool success)
>> if (!success)
>> ifp->stats.tx_errors++;
>>
>> +free:
>> brcmu_pkt_buf_free_skb(txp);
>>  }
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c 
>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>> index f82c9ab..98cb83f 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
>> @@ -1899,8 +1899,10 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, 
>> struct sk_buff *skb)
>>
>> if (fws->avoid_queueing) {
>> rc = brcmf_proto_txdata(drvr,

Re: iwlwifi + wpa2-leap + multiple AP's = call trace

2016-07-13 Thread Ismael Farfán

Hi

I'm using wicd, so changed from wext to nl80211 and I don't see the
trace anymore... it still refuses to connect though, so I'll check
what's wrong with my configuration.

Do you want me to collect some information regarding wpa_supplicant
and wext from my system?
If so, how?

Thanks for your help
-Farfan



2016-07-13 11:31 GMT-05:00 Emmanuel Grumbach :
> On Jul 13, 2016 9:23 AM, "Arend Van Spriel" 
> wrote:
>>
>>
>>
>> On 13-7-2016 2:29, Ismael Farfán wrote:
>> > Hello list
>> >
>> > I searched this error around and didn't find anything, so here it goes.
>> >
>> > Today I tried to connect to an enterprise network, which means,
>> > literally, tens of AP's sharing the same name... the network requieres
>> > user/password authentication (wpa2-leap).
>> >
>> > I'm using Arch
>> > $ uname -a
>> > Linux 4.6.3-1-ARCH #1 SMP PREEMPT Fri Jun 24 21:19:13 CEST 2016 x86_64
>> > GNU/Linux
>> >
>> > Since the thing just didn't connect, I checked dmesg and found this:
>> >
>> > Any ideas?
>>
>> From the stack trace it seems wpa_supplicant on Arch is using WEXT API.
>> You could try and change it to use NL80211 API. Personally, I have not
>> used Arch Linux so no idea where to change that.
>>
>> The warning is here [1]:
>>
>> 503 IWL_DEBUG_TE(mvm, "Add new TE, duration %d TU\n",
>> 504  le32_to_cpu(te_cmd->duration));
>> 505
>> 506 spin_lock_bh(>time_event_lock);
>> 507 if (WARN_ON(te_data->id != TE_MAX)) {
>> 508 spin_unlock_bh(>time_event_lock);
>> 509 return -EIO;
>> 510 }
>>
>> It seems this function is called with te_data that is already in use,
>> but that is my uneducated guess so I may be wrong.
>>
>
> This is right :)
>
> Can you please record tracing of this?
>
> Thank you.
>
>> Regards,
>> Arend
>>
>> [1]
>>
>> http://lxr.free-electrons.com/source/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c#L507
>> >
>> > [   83.030072] wifi0: aborting authentication with xx:xx:xx:xx:xx:xx
>> > by local choice (Reason: 3=DEAUTH_LEAVING)
>> > [   83.030073] [ cut here ]
>> > [   83.030082] WARNING: CPU: 2 PID: 1087 at
>> > drivers/net/wireless/intel/iwlwifi/mvm/time-event.c:507 iwl_mvm_tim
>> > e_event_send_add+0x1c6/0x200 [iwlmvm]
>> > [   83.030157] CPU: 2 PID: 1087 Comm: wpa_supplicant Tainted: G
>> >O4.6.3-1-ARCH #1
>> > [   83.030158] Hardware name: Notebook
>> > P65_P67SA   /P65_P67SA
>> > , BIOS 1.03.01 07/22/2015
>> > [   83.030160]  0286 09e998bc 880403a5b940
>> > 812e54c2
>> > [   83.030162]    880403a5b980
>> > 8107a6bb
>> > [   83.030164]  01fb81a8a180 88041b443580 88041c329548
>> > fffb
>> > [   83.030167] Call Trace:
>> > [   83.030172]  [] dump_stack+0x63/0x81
>> > [   83.030174]  [] __warn+0xcb/0xf0
>> > [   83.030176]  [] warn_slowpath_null+0x1d/0x20
>> > [   83.030181]  []
>> > iwl_mvm_time_event_send_add+0x1c6/0x200 [iwlmvm]
>> > [   83.030184]  [] ? up+0x32/0x50
>> > [   83.030187]  [] ? wake_up_klogd+0x3b/0x50
>> > [   83.030189]  [] ? console_unlock+0x4e9/0x590
>> > [   83.030193]  []
>> > iwl_mvm_protect_session+0x220/0x280 [iwlmvm]
>> > [   83.030196]  [] ? iwl_mvm_ref_sync+0x2e/0x140
>> > [iwlmvm]
>> > [   83.030199]  [] ? vprintk_default+0x1f/0x30
>> > [   83.030202]  []
>> > iwl_mvm_mac_mgd_prepare_tx+0x5a/0xa0 [iwlmvm]
>> > [   83.030216]  [] ieee80211_mgd_deauth+0x338/0x4d0
>> > [mac80211]
>> > [   83.030219]  [] ? enqueue_entity+0x323/0xd70
>> > [   83.030228]  [] ieee80211_deauth+0x18/0x20
>> > [mac80211]
>> > [   83.030237]  [] cfg80211_mlme_deauth+0x9f/0x1a0
>> > [cfg80211]
>> > [   83.030242]  [] cfg80211_disconnect+0x9a/0x200
>> > [cfg80211]
>> > [   83.030248]  []
>> > cfg80211_mgd_wext_siwessid+0xa9/0x170 [cfg80211]
>> > [   83.030255]  [] cfg80211_wext_siwessid+0x22/0x40
>> > [cfg80211]
>> > [   83.030258]  [] ioctl_standard_iw_point+0x133/0x350
>> > [   83.030264]  [] ?
>> > cfg80211_wext_giwessid+0x50/0x50 [cfg80211]
>> > [   83.030266]  [] ? wake_up_q+0x32/0x70
>> > [   83.030268]  [] ? iw_handler_get_private+0x60/0x60
>> > [   83.030271]  [] ioctl_standard_call+0x87/0xd0
>> > [   83.030273]  [] ?
>> > call_commit_handler.part.4+0x30/0x30
>> > [   83.030275]  [] wireless_process_ioctl+0x1f0/0x230
>> > [   83.030278]  [] ? dev_get_by_name_rcu+0x5e/0x80
>> > [   83.030280]  [] wext_handle_ioctl+0x78/0xd0
>> > [   83.030283]  [] dev_ioctl+0x2a7/0x5a0
>> > [   83.030285]  [] sock_ioctl+0x126/0x290
>> > [   83.030287]  [] do_vfs_ioctl+0xa3/0x5d0
>> > [   83.030290]  [] ? vfs_write+0x142/0x190
>> > [   83.030292]  [] SyS_ioctl+0x79/0x90
>> > [   83.030294]  [] entry_SYSCALL_64_fastpath+0x1a/0xa4
>> > [   83.030296] ---[ end trace 8247b235a66a1a21 ]---
>> >
>> >
>> >
>> >
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
>> in
>> the body of a

pull-request: wireless-drivers-next 2016-07-13

2016-07-13 Thread Kalle Valo

Hi Dave,

here's a pull request for net-next. This time there are few conflicts
due to the cfg80211 scan API changes, and one of them is easy to miss,
so please pay extra attention to them. Otherwise there's not nothing
really out of ordinary. Please note that I also pulled wireless-drivers
to wireless-drivers-next to reduce the amount of conflicts.

So about the conflicts, the obvious are notified by git:

CONFLICT (content): Merge conflict in 
drivers/net/wireless/marvell/mwifiex/cmdevt.c
CONFLICT (content): Merge conflict in 
drivers/net/wireless/intel/iwlwifi/mvm/scan.c

Basically the major change is that in iwlwifi del_timer() is changed to
cancel_delayed_work() and in mwifiex the code was refactored to use
mwifiex_cancel_scan(). But the tricky part comes here which is easy to
miss:

Auto-merging drivers/net/wireless/marvell/mwifiex/scan.c

You need to convert the scan code in mwifiex_cancel_scan():

cfg80211_scan_done(priv->scan_request, 1);

to use the new API:

struct cfg80211_scan_info info = {
.aborted = true,
};

[...]

cfg80211_scan_done(priv->scan_request, );

I have attached the output from git diff as an example how to resolve
this, hopefully that helps. Please let me know if there are any problems
or if you want to handle these differently.

Kalle


The following changes since commit 742fb20fd4c75bd08733b0ea232c7e0fa67a6f87:

  net: ethernet: ti: cpdma: switch to use genalloc (2016-06-29 04:16:11 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
tags/wireless-drivers-next-for-davem-2016-07-13

for you to fetch changes up to 25f700ef0653d7644ed273f8770230e734cae726:

  iwlwifi: add missing type declaration (2016-07-12 14:51:57 +0300)


wireless-drivers-next patches for 4.8

Major changes:

iwlwifi

* more work on the RX path for the 9000 device series
* some more dynamic queue allocation work
* SAR BIOS implementation
* some work on debugging capabilities
* added support for GCMP encryption
* data path rework in preparation for new HW
* some cleanup to remove transport dependency on mac80211
* support for MSIx in preparation for new HW
* lots of work in preparation for HW support (9000 and a000 series)

mwifiex

* implement get_tx_power and get_antenna cfg80211 operation callbacks

wl18xx

* add support for 64bit clock

rtl8xxxu

* aggregation support (optional for now)

Also wireless-drivers is merged to fix some conflicts.


Amitkumar Karwar (8):
  mwifiex: fix system hang problem after resume
  mwifiex: fix AP unable to start in VHT40 problem
  mwifiex: fix AP start problem for newly added interface
  mwifiex: code rearrangement in suspend handler
  mwifiex: clear scan_aborting flag
  mwifiex: fix NULL pointer dereference during suspend
  mwifiex: fix scan_block flag handling
  mwifiex: Change default firmware for PCIe8997 chipset

Andrei Otcheretianski (1):
  iwlwifi: mvm: Support CSA countdown offloading

Andy Shevchenko (1):
  rtl8xxxu: tuse %*ph to dump buffers

Arnd Bergmann (6):
  rtlwifi: use s8 instead of char
  wireless: airo: rename 'register' variable
  wireless: brcmsmac: fix old-style declaration
  wireless: ipw2200: fix old-style declaration
  iwlwifi: mvm: avoid harmless -Wmaybe-uninialized warning
  iwlwifi: add missing type declaration

Avraham Stern (1):
  iwlwifi: rename CAPA_P2P_STANDALONE_UAPSD to CAPA_P2P_SCM_UAPSD

Ayala Beker (2):
  iwlwifi: mvm: fix RX mpdu status enum
  iwlwifi: mvm: add support for GCMP encryption

Bhaktipriya Shridhar (1):
  libertas_tf: Remove create_workqueue

Brian Norris (1):
  mwifiex: mask PCIe interrupts before removal

Bruno Herrera (1):
  wlcore: sdio: Fix crash on wlcore_probe_of when failing to parse/map irq

Dan Carpenter (2):
  iwlwifi: mvm: remove an unused variable
  iwlwifi: mvm: silence uninitialized variable warning

Emmanuel Grumbach (7):
  iwlwifi: advertise maximal MPDU length when Rx MQ is supported
  iwlwifi: pcie: enable interrupts before releasing the NIC's CPU
  iwlwifi: mvm: cleanup the coex code
  iwlwifi: mvm: fix coex related comments
  iwlwifi: mvm: fix the channel inhibition table for Channel 14
  iwlwifi: mvm: unmap the paging memory before freeing it
  iwlwifi: pcie: fix a race in firmware loading flow

Ganapathi Bhat (1):
  mwifiex: Fix an issue spotted by KASAN

Golan Ben-Ami (2):
  iwlwifi: Reserve iwl_fw_error_dump_type enum
  iwlwifi: mvm: write the correct internal TXF index

Gregory Greenman (1):
  iwlwifi: mvm: rs: add rate scaling support for 160MHz channels

Guenter Roeck (1):
  iwlwifi: dvm: Remove unused array 'iwlagn_loose_lookup'

Guy Mishol (1):
  wlcore: reconfigure sta rates on

Re: [PATCH v3 1/2] mwifiex: add manufacturing mode support

2016-07-13 Thread Kalle Valo

Amitkumar Karwar  writes:

> Hi Kalle,
>
>> -Original Message-
>> From: Kalle Valo [mailto:kv...@codeaurora.org]
>> Sent: Wednesday, July 13, 2016 9:20 PM
>> To: Amitkumar Karwar
>> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam
>> Subject: Re: [PATCH v3 1/2] mwifiex: add manufacturing mode support
>> 
>> Amitkumar Karwar  writes:
>> 
>> > By default normal mode is chosen when driver is loaded. This patch
>> > adds a provision to choose manufacturing mode via module parameters.
>> >
>> > Command to load driver in manufacturing mode insmod mwifiex.ko
>> > mfg_mode=1 and mfg_firmware=mrvl/firmware.
>> >
>> > Tested-by: chunfan chen 
>> > Signed-off-by: Amitkumar Karwar 
>> 
>> Why the mfg_firmware module parameter?
>
> It's to specify a firmware name.

Yeah, I got that. But why do you need that? Why not just hardcode the
firmware name in the driver, which is the normal thing to do?

-- 
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 v3 1/2] mwifiex: add manufacturing mode support

2016-07-13 Thread Amitkumar Karwar

Hi Kalle,

> -Original Message-
> From: Kalle Valo [mailto:kv...@codeaurora.org]
> Sent: Wednesday, July 13, 2016 10:01 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam
> Subject: Re: [PATCH v3 1/2] mwifiex: add manufacturing mode support
> 
> Amitkumar Karwar  writes:
> 
> > Hi Kalle,
> >
> >> -Original Message-
> >> From: Kalle Valo [mailto:kv...@codeaurora.org]
> >> Sent: Wednesday, July 13, 2016 9:20 PM
> >> To: Amitkumar Karwar
> >> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam
> >> Subject: Re: [PATCH v3 1/2] mwifiex: add manufacturing mode support
> >>
> >> Amitkumar Karwar  writes:
> >>
> >> > By default normal mode is chosen when driver is loaded. This patch
> >> > adds a provision to choose manufacturing mode via module
> parameters.
> >> >
> >> > Command to load driver in manufacturing mode insmod mwifiex.ko
> >> > mfg_mode=1 and mfg_firmware=mrvl/firmware.
> >> >
> >> > Tested-by: chunfan chen 
> >> > Signed-off-by: Amitkumar Karwar 
> >>
> >> Why the mfg_firmware module parameter?
> >
> > It's to specify a firmware name.
> 
> Yeah, I got that. But why do you need that? Why not just hardcode the
> firmware name in the driver, which is the normal thing to do?

Ok. I will do this in updated version.

Regards,
Amitkumar
--
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 v3 1/2] mwifiex: add manufacturing mode support

2016-07-13 Thread Amitkumar Karwar

Hi Kalle,

> -Original Message-
> From: Kalle Valo [mailto:kv...@codeaurora.org]
> Sent: Wednesday, July 13, 2016 9:20 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam
> Subject: Re: [PATCH v3 1/2] mwifiex: add manufacturing mode support
> 
> Amitkumar Karwar  writes:
> 
> > By default normal mode is chosen when driver is loaded. This patch
> > adds a provision to choose manufacturing mode via module parameters.
> >
> > Command to load driver in manufacturing mode insmod mwifiex.ko
> > mfg_mode=1 and mfg_firmware=mrvl/firmware.
> >
> > Tested-by: chunfan chen 
> > Signed-off-by: Amitkumar Karwar 
> 
> Why the mfg_firmware module parameter?

It's to specify a firmware name.

Regards,
Amitkumar Karwar
--
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 v3 2/2] mwifiex: add hostcmd wext ioctl support

2016-07-13 Thread Amitkumar Karwar

Hi Kalle,

> -Original Message-
> From: Kalle Valo [mailto:kv...@codeaurora.org]
> Sent: Wednesday, July 13, 2016 9:18 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> Xinming Hu
> Subject: Re: [PATCH v3 2/2] mwifiex: add hostcmd wext ioctl support
> 
> Amitkumar Karwar  writes:
> 
> > Hi Kalle,
> >
> >> -Original Message-
> >> From: Kalle Valo [mailto:kv...@codeaurora.org]
> >> Sent: Wednesday, July 13, 2016 8:44 PM
> >> To: Amitkumar Karwar
> >> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> >> Xinming Hu
> >> Subject: Re: [PATCH v3 2/2] mwifiex: add hostcmd wext ioctl support
> >>
> >> Amitkumar Karwar  writes:
> >>
> >> > From: Xinming Hu 
> >> >
> >> > This patch adds ndo_ioctl support to mwifiex netdev handlers.
> >> > This will be used to download hostcmds to firmware from userspace.
> >> > This is needed for manufacturing mode support in mwifiex. ndo_ioctl
> >> > is allowed only when mfg mode is enabled via module load
> parameters.
> >> >
> >> > Signed-off-by: Xinming Hu 
> >> > Signed-off-by: Amitkumar Karwar 
> >> > ---
> >> > v3: Add "select WIRELESS_EXT" in Kconfig to resolve kbuild test
> >> > robot
> >> errors.
> >> > WEXT_PRIV seems to have a dependency with WIRELESS_EXT.
> >> > v2: 1) Sequence of these two patches are changed to resolve
> >> compilation
> >> > error seen if only 1/2 is applied.
> >> > 2) Add "select WEXT_PRIV" in Kconfig to resolve warnings
> >> > reported
> >> by
> >> > kbuild test robot.
> >>
> >> Why can't you use nl80211 testmode interface?
> >
> > These two patches facilitates user to configure manufacturing mode. We
> > have a separate firmware for this mode. It's needed to run special
> > WiFi conductive and radiated tests at factory.
> 
> This is exactly what nl80211 testmode is for.
> 
> > The userspace tools used for this purpose expects WEXT interface.
> 
> So convert them to use nl80211. I have done that myself, multiple times
> actually.
> 
> And for wireless extensions, from my point of view it's dead and buried.
> I'm not going to take any new wireless extension related code.

Thanks for your feedback. We will change the tools and prepare driver patch 
using nl80211 testmode.

Regards,
Amitkumar
--
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 v3 1/2] mwifiex: add manufacturing mode support

2016-07-13 Thread Kalle Valo

Amitkumar Karwar  writes:

> By default normal mode is chosen when driver is loaded. This patch adds
> a provision to choose manufacturing mode via module parameters.
>
> Command to load driver in manufacturing mode
> insmod mwifiex.ko mfg_mode=1 and mfg_firmware=mrvl/firmware.
>
> Tested-by: chunfan chen 
> Signed-off-by: Amitkumar Karwar 

Why the mfg_firmware module parameter?

-- 
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: building brcmfmac driver for iMX6 Ultralite platform

2016-07-13 Thread Michael Eskowitz

>> Arend,
>
>What about my reply? ;)

Sorry.  No offense intended.  I clearly need to not treat this as email.  I'll 
figure out the protocol soon enough.

>
>
>> That is news to me.  I was under the impression that bcmdhd was 
>> Broadcom's proprietary (closed source) Linux driver and brcmfmac was 
>> the open source Linux driver.
>
>Don't top post. It's hard to say what you're replying to. bcmdhd is also open 
>source (not sure what license), just not mainline.
>
>
>> Either way, I am now running
>>
>> insmod  brcmutil.ko
>> insmod  brcmfmac.ko
>>
>> I receive no errors and no kernel messages.
>>
>> When I insert the 43341 module into the SDIO slot nothing happens.  
>> I'm guessing that the version of the brcmfmac driver that I built does 
>> not support that chip.
>
>Is is detected by the system? If so, what ID does it use?
>

The system recognizes that an mmc card has been inserted.  The driver doesn't 
see the module, however.  Looking at the page

https://wireless.wiki.kernel.org/en/users/drivers/brcm80211

suggests that I simply need to move to a newer Linux kernel as I am using 
3.14.38.  NXP recently posted a 4.1.15 install so I will try getting the 43341 
module up and running with that.

>
>> When I insert the 43362 module into the SDIO slot I receive the 
>> following errors
>>
>> mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
>> mmc0: new high speed SDIO card at address 0001
>> brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jun  
>> 7 2012
>> 18:27:16 version 5.90.225 FWID 01-d8fe14bd
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
>> brcmfmac: brcmf_add_if: ignore IF event
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> brcmfmac: brcmf_construct_reginfo: channel 1: f=2412 bw=0
>> sb=-1998840228
>> brcmfmac: brcmf_construct_reginfo: channel 2: f=2417 bw=0
>> sb=-1998840228
>>
>> and suddenly ifconfig shows the interface wlan0.  The interface looks 
>> to be valid as it is displaying a MAC from our address range.
>>
>> Although the interface wlan0 is present I am not able to use wl 
>> commands to scan for networks.  wl reports "wl driver adapter not 
>> found" for all command arguments.  If I run the command
>>
>> iwlist  wlan0  scan
>>
>> I'm told that the interface does not support scanning.  If I run 
>> wpa_cli and then the commands scan and scanresults I don't see any networks. 
>
>"wl" user space tool uses wlioctl, proprietary protocol, brcmfmac doesn't 
>support it.
>
>iwlist uses wext protocol, legacy one.
>
>Please use nl80211 based tools, e.g. "iw".

I was able to scan with iw and join a WPA2 protected network using 
wpa_supplicant.  It would appear that I have the 43362 up and running with the 
brcmfmac driver.  I will try the other Linux install for the 43341.

Thank you all for all your help.  It is much appreciated.  :-)

-Mike



--
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 v3 2/2] mwifiex: add hostcmd wext ioctl support

2016-07-13 Thread Kalle Valo

Amitkumar Karwar  writes:

> Hi Kalle,
>
>> -Original Message-
>> From: Kalle Valo [mailto:kv...@codeaurora.org]
>> Sent: Wednesday, July 13, 2016 8:44 PM
>> To: Amitkumar Karwar
>> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
>> Xinming Hu
>> Subject: Re: [PATCH v3 2/2] mwifiex: add hostcmd wext ioctl support
>> 
>> Amitkumar Karwar  writes:
>> 
>> > From: Xinming Hu 
>> >
>> > This patch adds ndo_ioctl support to mwifiex netdev handlers.
>> > This will be used to download hostcmds to firmware from userspace.
>> > This is needed for manufacturing mode support in mwifiex. ndo_ioctl is
>> > allowed only when mfg mode is enabled via module load parameters.
>> >
>> > Signed-off-by: Xinming Hu 
>> > Signed-off-by: Amitkumar Karwar 
>> > ---
>> > v3: Add "select WIRELESS_EXT" in Kconfig to resolve kbuild test robot
>> errors.
>> > WEXT_PRIV seems to have a dependency with WIRELESS_EXT.
>> > v2: 1) Sequence of these two patches are changed to resolve
>> compilation
>> > error seen if only 1/2 is applied.
>> > 2) Add "select WEXT_PRIV" in Kconfig to resolve warnings reported
>> by
>> > kbuild test robot.
>> 
>> Why can't you use nl80211 testmode interface?
>
> These two patches facilitates user to configure manufacturing mode. We
> have a separate firmware for this mode. It's needed to run special
> WiFi conductive and radiated tests at factory.

This is exactly what nl80211 testmode is for.

> The userspace tools used for this purpose expects WEXT interface.

So convert them to use nl80211. I have done that myself, multiple times
actually.

And for wireless extensions, from my point of view it's dead and buried.
I'm not going to take any new wireless extension related code.

-- 
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 v3 2/2] mwifiex: add hostcmd wext ioctl support

2016-07-13 Thread Amitkumar Karwar

Hi Kalle,

> -Original Message-
> From: Kalle Valo [mailto:kv...@codeaurora.org]
> Sent: Wednesday, July 13, 2016 8:44 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> Xinming Hu
> Subject: Re: [PATCH v3 2/2] mwifiex: add hostcmd wext ioctl support
> 
> Amitkumar Karwar  writes:
> 
> > From: Xinming Hu 
> >
> > This patch adds ndo_ioctl support to mwifiex netdev handlers.
> > This will be used to download hostcmds to firmware from userspace.
> > This is needed for manufacturing mode support in mwifiex. ndo_ioctl is
> > allowed only when mfg mode is enabled via module load parameters.
> >
> > Signed-off-by: Xinming Hu 
> > Signed-off-by: Amitkumar Karwar 
> > ---
> > v3: Add "select WIRELESS_EXT" in Kconfig to resolve kbuild test robot
> errors.
> > WEXT_PRIV seems to have a dependency with WIRELESS_EXT.
> > v2: 1) Sequence of these two patches are changed to resolve
> compilation
> > error seen if only 1/2 is applied.
> > 2) Add "select WEXT_PRIV" in Kconfig to resolve warnings reported
> by
> > kbuild test robot.
> 
> Why can't you use nl80211 testmode interface?

These two patches facilitates user to configure manufacturing mode. We have a 
separate firmware for this mode. 
It's needed to run special WiFi conductive and radiated tests at factory. The 
userspace tools used for this purpose expects WEXT interface.

Regards,
Amitkumar
--
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 v3 2/2] mwifiex: add hostcmd wext ioctl support

2016-07-13 Thread Kalle Valo

Amitkumar Karwar  writes:

> From: Xinming Hu 
>
> This patch adds ndo_ioctl support to mwifiex netdev handlers.
> This will be used to download hostcmds to firmware from userspace.
> This is needed for manufacturing mode support in mwifiex. ndo_ioctl
> is allowed only when mfg mode is enabled via module load parameters.
>
> Signed-off-by: Xinming Hu 
> Signed-off-by: Amitkumar Karwar 
> ---
> v3: Add "select WIRELESS_EXT" in Kconfig to resolve kbuild test robot errors.
> WEXT_PRIV seems to have a dependency with WIRELESS_EXT.
> v2: 1) Sequence of these two patches are changed to resolve compilation
> error seen if only 1/2 is applied.
> 2) Add "select WEXT_PRIV" in Kconfig to resolve warnings reported by
> kbuild test robot.

Why can't you use nl80211 testmode interface?

-- 
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] mac80211: End the MPSP even if EOSP frame was not received

2016-07-13 Thread Bob Copeland

On Wed, Jul 13, 2016 at 04:04:35PM +0900, Masashi Honma wrote:
> The mesh STA sends QoS frame with EOSP (end of service period)
> subfiled=1 to end the MPSP(mesh peer service period). Previously, if
> the frame was not acked by peer, the mesh STA did not end the MPSP.
> This patch ends the MPSP even if the QoS frame was no acked.

Hmm, my recollection on this stuff is a little fuzzy.  So we only get
here if the peer sta is in doze state, but it shouldn't do that if we
are in an MPSP.  So, is the real problem that we don't wait for an ack
from the peer before marking ourselves in a MPSP?

-- 
Bob Copeland %% http://bobcopeland.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

[PATCH v3 2/2] mwifiex: add hostcmd wext ioctl support

2016-07-13 Thread Amitkumar Karwar

From: Xinming Hu 

This patch adds ndo_ioctl support to mwifiex netdev handlers.
This will be used to download hostcmds to firmware from userspace.
This is needed for manufacturing mode support in mwifiex. ndo_ioctl
is allowed only when mfg mode is enabled via module load parameters.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
v3: Add "select WIRELESS_EXT" in Kconfig to resolve kbuild test robot errors.
WEXT_PRIV seems to have a dependency with WIRELESS_EXT.
v2: 1) Sequence of these two patches are changed to resolve compilation
error seen if only 1/2 is applied.
2) Add "select WEXT_PRIV" in Kconfig to resolve warnings reported by
kbuild test robot.
---
 drivers/net/wireless/marvell/mwifiex/Kconfig  |  6 +++
 drivers/net/wireless/marvell/mwifiex/cmdevt.c | 59 +++
 drivers/net/wireless/marvell/mwifiex/main.c   | 38 +
 drivers/net/wireless/marvell/mwifiex/main.h   |  9 +++-
 4 files changed, 111 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/Kconfig 
b/drivers/net/wireless/marvell/mwifiex/Kconfig
index 279167d..aed32ce 100644
--- a/drivers/net/wireless/marvell/mwifiex/Kconfig
+++ b/drivers/net/wireless/marvell/mwifiex/Kconfig
@@ -13,6 +13,8 @@ config MWIFIEX_SDIO
depends on MWIFIEX && MMC
select FW_LOADER
select WANT_DEV_COREDUMP
+   select WIRELESS_EXT
+   select WEXT_PRIV
---help---
  This adds support for wireless adapters based on Marvell
  8786/8787/8797/8887/8897/8997 chipsets with SDIO interface.
@@ -25,6 +27,8 @@ config MWIFIEX_PCIE
depends on MWIFIEX && PCI
select FW_LOADER
select WANT_DEV_COREDUMP
+   select WIRELESS_EXT
+   select WEXT_PRIV
---help---
  This adds support for wireless adapters based on Marvell
  8766/8897/8997 chipsets with PCIe interface.
@@ -36,6 +40,8 @@ config MWIFIEX_USB
tristate "Marvell WiFi-Ex Driver for USB8766/8797/8997"
depends on MWIFIEX && USB
select FW_LOADER
+   select WIRELESS_EXT
+   select WEXT_PRIV
---help---
  This adds support for wireless adapters based on Marvell
  8797/8997 chipset with USB interface.
diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c 
b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 8d57493..d961305 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -826,6 +826,8 @@ int mwifiex_process_cmdresp(struct mwifiex_adapter *adapter)
hostcmd = adapter->curr_cmd->data_buf;
hostcmd->len = size;
memcpy(hostcmd->cmd, resp, size);
+   adapter->hostcmd_resp_data.len = size;
+   memcpy(adapter->hostcmd_resp_data.cmd, resp, size);
}
}
orig_cmdresp_no = le16_to_cpu(resp->command);
@@ -1208,6 +1210,63 @@ mwifiex_process_hs_config(struct mwifiex_adapter 
*adapter)
   false);
 }
 EXPORT_SYMBOL_GPL(mwifiex_process_hs_config);
+/* This function get hostcmd data from userspace and construct a cmd
+   * to be download to FW.
+  */
+int mwifiex_process_host_command(struct mwifiex_private *priv,
+struct iwreq *wrq)
+{
+   struct mwifiex_ds_misc_cmd *hostcmd_buf;
+   struct host_cmd_ds_command *cmd;
+   struct mwifiex_adapter *adapter = priv->adapter;
+   int ret;
+
+   hostcmd_buf = kzalloc(sizeof(*hostcmd_buf), GFP_KERNEL);
+   if (!hostcmd_buf)
+   return -ENOMEM;
+
+   cmd = (void *)hostcmd_buf->cmd;
+
+   if (copy_from_user(cmd, wrq->u.data.pointer,
+  sizeof(cmd->command) + sizeof(cmd->size))) {
+   ret = -EFAULT;
+   goto done;
+   }
+
+   hostcmd_buf->len = le16_to_cpu(cmd->size);
+   if (hostcmd_buf->len > MWIFIEX_SIZE_OF_CMD_BUFFER) {
+   ret = -EINVAL;
+   goto done;
+   }
+
+   if (copy_from_user(cmd, wrq->u.data.pointer, hostcmd_buf->len)) {
+   ret = -EFAULT;
+   goto done;
+   }
+
+   if (mwifiex_send_cmd(priv, 0, 0, 0, hostcmd_buf, true)) {
+   dev_err(priv->adapter->dev, "Failed to process hostcmd\n");
+   ret = -EFAULT;
+   goto done;
+   }
+
+   if (adapter->hostcmd_resp_data.len > hostcmd_buf->len) {
+   ret = -EFBIG;
+   goto done;
+   }
+
+   if (copy_to_user(wrq->u.data.pointer, adapter->hostcmd_resp_data.cmd,
+adapter->hostcmd_resp_data.len)) {
+   ret = -EFAULT;
+   goto done;
+   }
+   wrq->u.data.length = adapter->hostcmd_resp_data.len;
+
+   ret = 0;
+done:
+   kfree(hostcmd_buf);
+   return ret;
+}
 
 /*
  * This function

[PATCH v3 1/2] mwifiex: add manufacturing mode support

2016-07-13 Thread Amitkumar Karwar

By default normal mode is chosen when driver is loaded. This patch adds
a provision to choose manufacturing mode via module parameters.

Command to load driver in manufacturing mode
insmod mwifiex.ko mfg_mode=1 and mfg_firmware=mrvl/firmware.

Tested-by: chunfan chen 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cmdevt.c |  8 ++
 drivers/net/wireless/marvell/mwifiex/init.c   | 22 +++--
 drivers/net/wireless/marvell/mwifiex/main.c   | 35 ---
 drivers/net/wireless/marvell/mwifiex/main.h   |  4 +++
 drivers/net/wireless/marvell/mwifiex/pcie.c   |  2 +-
 drivers/net/wireless/marvell/mwifiex/sdio.c   |  2 +-
 drivers/net/wireless/marvell/mwifiex/usb.c|  2 +-
 7 files changed, 61 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c 
b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index c29f26d..8d57493 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -581,6 +581,14 @@ int mwifiex_send_cmd(struct mwifiex_private *priv, u16 
cmd_no,
return -1;
}
}
+   /* We don't expect commands in manufacturing mode. They are cooked
+* in application and ready to download buffer is passed to the driver
+   */
+   if (adapter->mfg_mode && cmd_no) {
+   dev_dbg(adapter->dev, "Ignoring commands in manufacturing 
mode\n");
+   return -1;
+   }
+
 
/* Get a new command node */
cmd_node = mwifiex_get_cmd_node(adapter);
diff --git a/drivers/net/wireless/marvell/mwifiex/init.c 
b/drivers/net/wireless/marvell/mwifiex/init.c
index 1489c90..82839d9 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -298,6 +298,7 @@ static void mwifiex_init_adapter(struct mwifiex_adapter 
*adapter)
memset(>arp_filter, 0, sizeof(adapter->arp_filter));
adapter->arp_filter_size = 0;
adapter->max_mgmt_ie_index = MAX_MGMT_IE_INDEX;
+   adapter->mfg_mode = mfg_mode;
adapter->key_api_major_ver = 0;
adapter->key_api_minor_ver = 0;
eth_broadcast_addr(adapter->perm_addr);
@@ -553,15 +554,22 @@ int mwifiex_init_fw(struct mwifiex_adapter *adapter)
return -1;
}
}
+   if (adapter->mfg_mode) {
+   adapter->hw_status = MWIFIEX_HW_STATUS_READY;
+   ret = -EINPROGRESS;
+   } else {
+   for (i = 0; i < adapter->priv_num; i++) {
+   if (adapter->priv[i]) {
+   ret = mwifiex_sta_init_cmd(adapter->priv[i],
+  first_sta, true);
+   if (ret == -1)
+   return -1;
+
+   first_sta = false;
+   }
+
 
-   for (i = 0; i < adapter->priv_num; i++) {
-   if (adapter->priv[i]) {
-   ret = mwifiex_sta_init_cmd(adapter->priv[i], first_sta,
-  true);
-   if (ret == -1)
-   return -1;
 
-   first_sta = false;
}
}
 
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 0e280f8..b54edf4 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -36,6 +36,14 @@ static unsigned short driver_mode;
 module_param(driver_mode, ushort, 0);
 MODULE_PARM_DESC(driver_mode,
 "station=0x1(default), ap-sta=0x3, station-p2p=0x5, 
ap-sta-p2p=0x7");
+bool mfg_mode;
+module_param(mfg_mode, bool, 0);
+MODULE_PARM_DESC(mfg_mode, "0:disable 1:enable (bool)");
+
+char *mfg_firmware = "";
+module_param(mfg_firmware, charp, 0);
+MODULE_PARM_DESC(mfg_firmware, "firmware path");
+
 
 /*
  * This function registers the device and performs all the necessary
@@ -559,10 +567,12 @@ static void mwifiex_fw_dpc(const struct firmware 
*firmware, void *context)
goto done;
}
/* Wait for mwifiex_init to complete */
-   wait_event_interruptible(adapter->init_wait_q,
-adapter->init_wait_q_woken);
-   if (adapter->hw_status != MWIFIEX_HW_STATUS_READY)
-   goto err_init_fw;
+   if (!adapter->mfg_mode) {
+   wait_event_interruptible(adapter->init_wait_q,
+adapter->init_wait_q_woken);
+   if (adapter->hw_status != MWIFIEX_HW_STATUS_READY)
+   goto err_init_fw;
+   }
 
priv = adapter->priv[MWIFIEX_BSS_ROLE_STA];
if (mwifiex_register_cfg80211(adapter)) {
@@ -666,6 +676,23 @@ static int mwifiex_init_hw_fw(struct

Re: [PATCH 1/4] mac80211: mesh: flush stations before beacons are stopped

2016-07-13 Thread Bob Copeland

On Wed, Jul 13, 2016 at 10:11:25AM +, Machani, Yaniv wrote:
> > > Some drivers (e.g. wl18xx) expect that the last stage in the 
> > > de-initialization process will be stopping the beacons, similar to ap.
> > > Update ieee80211_stop_mesh() flow accordingly.
> > >
> > How well have you tested that with other drivers?
> > 
> 
> Sorry for the delayed response (I've been out) and thanks for your comments,
> I have tested it with RT3572 as well, and didn't see any issue.
> I'll update the comment to reflect that.

I'll give this a test on ath10k and wcn36xx as they are the ones most
likely to care about ordering.

-- 
Bob Copeland %% http://bobcopeland.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 v2 2/2] mwifiex: add hostcmd wext ioctl support

2016-07-13 Thread kbuild test robot

Hi,

[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.7-rc7 next-20160712]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Amitkumar-Karwar/mwifiex-add-manufacturing-mode-support/20160713-192928
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: arm-exynos_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   net/wireless/wext-core.c: In function 'wireless_process_ioctl':
>> net/wireless/wext-core.c:942:31: error: 'struct net_device' has no member 
>> named 'wireless_handlers'
 if (cmd == SIOCGIWPRIV && dev->wireless_handlers)
  ^
--
   net/wireless/wext-priv.c: In function 'iw_handler_get_private':
>> net/wireless/wext-priv.c:22:10: error: 'struct net_device' has no member 
>> named 'wireless_handlers'
 if ((dev->wireless_handlers->num_private_args == 0) ||
 ^
   net/wireless/wext-priv.c:23:9: error: 'struct net_device' has no member 
named 'wireless_handlers'
(dev->wireless_handlers->private_args == NULL))
^
   net/wireless/wext-priv.c:27:29: error: 'struct net_device' has no member 
named 'wireless_handlers'
 if (wrqu->data.length < dev->wireless_handlers->num_private_args) {
^
   net/wireless/wext-priv.c:31:26: error: 'struct net_device' has no member 
named 'wireless_handlers'
  wrqu->data.length = dev->wireless_handlers->num_private_args;
 ^
   net/wireless/wext-priv.c:36:25: error: 'struct net_device' has no member 
named 'wireless_handlers'
 wrqu->data.length = dev->wireless_handlers->num_private_args;
^
   net/wireless/wext-priv.c:39:19: error: 'struct net_device' has no member 
named 'wireless_handlers'
 memcpy(extra, dev->wireless_handlers->private_args,
  ^
   net/wireless/wext-priv.c: In function 'get_priv_descr_and_size':
   net/wireless/wext-priv.c:100:21: error: 'struct net_device' has no member 
named 'wireless_handlers'
 for (i = 0; i < dev->wireless_handlers->num_private_args; i++) {
^
   net/wireless/wext-priv.c:101:17: error: 'struct net_device' has no member 
named 'wireless_handlers'
  if (cmd == dev->wireless_handlers->private_args[i].cmd) {
^
   net/wireless/wext-priv.c:102:16: error: 'struct net_device' has no member 
named 'wireless_handlers'
   descr = >wireless_handlers->private_args[i];
   ^

vim +942 net/wireless/wext-core.c

3d23e349 net/wireless/wext-core.c Johannes Berg   2009-09-29  936* (cmd 
>= SIOCIWFIRST && cmd <= SIOCIWLAST) */
3d23e349 net/wireless/wext-core.c Johannes Berg   2009-09-29  937   if (cmd 
== SIOCGIWSTATS)
3d23e349 net/wireless/wext-core.c Johannes Berg   2009-09-29  938   
return standard(dev, iwr, cmd, info,
3d23e349 net/wireless/wext-core.c Johannes Berg   2009-09-29  939   
_handler_get_iwstats);
^1da177e net/core/wireless.c  Linus Torvalds  2005-04-16  940  
3d23e349 net/wireless/wext-core.c Johannes Berg   2009-09-29  941  #ifdef 
CONFIG_WEXT_PRIV
dd8ceabc net/wireless/wext.c  Johannes Berg   2007-04-26 @942   if (cmd 
== SIOCGIWPRIV && dev->wireless_handlers)
0f5cabba net/wireless/wext.c  David S. Miller 2008-06-03  943   
return standard(dev, iwr, cmd, info,
3d23e349 net/wireless/wext-core.c Johannes Berg   2009-09-29  944   
iw_handler_get_private);
3d23e349 net/wireless/wext-core.c Johannes Berg   2009-09-29  945  #endif

:: The code at line 942 was first introduced by commit
:: dd8ceabcd10d47f6f28ecfaf2eac7beffca11b3c [WEXT]: Cleanup early ioctl 
call path.

:: TO: Johannes Berg <johan...@sipsolutions.net>
:: CC: David S. Miller <da...@davemloft.net>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH] drivers: misc: ti-st: Use int instead of fuzzy char for callback status

2016-07-13 Thread Marcel Holtmann

Hi Geert,

> On mips and parisc:
> 
>drivers/bluetooth/btwilink.c: In function 'ti_st_open':
>drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit 
> constant conversion [-Woverflow]
>   hst->reg_status = -EINPROGRESS;
> 
>drivers/nfc/nfcwilink.c: In function 'nfcwilink_open':
>drivers/nfc/nfcwilink.c:396:31: warning: overflow in implicit constant 
> conversion [-Woverflow]
>  drv->st_register_cb_status = -EINPROGRESS;
> 
> There are actually two issues:
>  1. Whether "char" is signed or unsigned depends on the architecture.
> As the completion callback data is used to pass a (negative) error
> code, it should always be signed.
>  2. EINPROGRESS is 150 on mips, 245 on parisc.
> Hence -EINPROGRESS doesn't fit in a signed 8-bit number.
> 
> Change the callback status from "char" to "int" to fix these.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> Compile-tested only.
> ---
> drivers/bluetooth/btwilink.c  | 4 ++--
> drivers/media/radio/wl128x/fmdrv_common.c | 2 +-
> drivers/misc/ti-st/st_core.c  | 2 +-
> drivers/nfc/nfcwilink.c   | 4 ++--
> include/linux/ti_wilink_st.h  | 2 +-
> 5 files changed, 7 insertions(+), 7 deletions(-)

patch has been applied to bluetooth-next tree.

Regards

Marcel

--
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 3/3] mac80211: mesh: fixed HT ies in beacon template

2016-07-13 Thread Sergei Shtylyov


Hello.

On 7/13/2016 2:45 PM, Yaniv Machani wrote:


The HT capab info field inside the HT capab IE of the mesh beacon
is incorrect (in the case of 20MHz channel width).
To fix this driver will check configuration from cfg and
will build it accordingly.

Signed-off-by: Meirav Kama 
Signed-off-by: Yaniv Machani 
---
V3 - Updated comment
   - Removed CFG changes, as they are not correct.

 net/mac80211/mesh.c | 33 -
 net/mac80211/util.c |  3 ---
 2 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 9214bc1..275131d 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -422,6 +422,8 @@ int mesh_add_ht_cap_ie(struct ieee80211_sub_if_data *sdata,
enum nl80211_band band = ieee80211_get_sdata_band(sdata);
struct ieee80211_supported_band *sband;
u8 *pos;
+   u16 cap;
+


   Why add more empty lines where you already one?



sband = local->hw.wiphy->bands[band];
if (!sband->ht_cap.ht_supported ||
@@ -430,11 +432,40 @@ int mesh_add_ht_cap_ie(struct ieee80211_sub_if_data 
*sdata,
sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_10)
return 0;

+/* determine capability flags */


   Please use tab, not spaces.


+   cap = sband->ht_cap.cap;
+
+/* if channel width is 20MHz - configure HT capab accordingly*/


   Likewise.


+   if (sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20) {
+   cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
+   cap &= ~IEEE80211_HT_CAP_DSSSCCK40;
+   }
+
+   /* set SM PS mode properly */
+   cap &= ~IEEE80211_HT_CAP_SM_PS;
+   switch (sdata->smps_mode) {
+   case IEEE80211_SMPS_AUTOMATIC:
+   case IEEE80211_SMPS_NUM_MODES:
+   WARN_ON(1);


   No *break*? You need a comment like /* FALL THRU */ then...


+   case IEEE80211_SMPS_OFF:
+   cap |= WLAN_HT_CAP_SM_PS_DISABLED <<
+   IEEE80211_HT_CAP_SM_PS_SHIFT;
+   break;
+   case IEEE80211_SMPS_STATIC:
+   cap |= WLAN_HT_CAP_SM_PS_STATIC <<
+   IEEE80211_HT_CAP_SM_PS_SHIFT;
+   break;
+   case IEEE80211_SMPS_DYNAMIC:
+   cap |= WLAN_HT_CAP_SM_PS_DYNAMIC <<
+   IEEE80211_HT_CAP_SM_PS_SHIFT;
+   break;
+   }
+
if (skb_tailroom(skb) < 2 + sizeof(struct ieee80211_ht_cap))
return -ENOMEM;

pos = skb_put(skb, 2 + sizeof(struct ieee80211_ht_cap));
-   ieee80211_ie_build_ht_cap(pos, >ht_cap, sband->ht_cap.cap);
+   ieee80211_ie_build_ht_cap(pos, >ht_cap, cap);

return 0;
 }

[...]

MBR, Sergei

--
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 v2] mac80211: rx: frames received out of order

2016-07-13 Thread Yaniv Machani

From: Meirav Kama 

Upon forwarding frames from Rx to Tx in mesh, driver clones the skb.
It zeros the tx_info and doesn't set hw_queue correctly. It then enqueues
the frame in queue 0 (VOICE) instead of the correct queue.
Upon re-queue of this frame, driver inserts it to the correct queue (e.g. BE).
After that, driver dequeue frames from 2 different queues and sends them out of 
order.
To fix this, driver will set the tx_info->hw_queue to the correct queue when 
cloning the skb.

Signed-off-by: Meirav Kama 
Signed-off-by: Yaniv Machani 
---
V2 - Revised comment

 net/mac80211/rx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 9a1eb70..88dc744 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2392,6 +2392,7 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
info->control.vif = >sdata->vif;
info->control.jiffies = jiffies;
+   info->hw_queue = q;
if (is_multicast_ether_addr(fwd_hdr->addr1)) {
IEEE80211_IFSTA_MESH_CTR_INC(ifmsh, fwded_mcast);
memcpy(fwd_hdr->addr2, sdata->vif.addr, ETH_ALEN);
-- 
2.9.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] mac80211: rx: frames received out of order

2016-07-13 Thread Yaniv Machani

From: Meirav Kama 

MP received data frames from another MP. Frames are forwarded
from Rx to Tx to be transmitted to a third MP.
Upon cloning the skb, the tx_info was zeroed, and the
hw_queue wasn't set correctly, causing frames to be
inserted to queue 0 (VOICE). If re-queue occurred for some
reason, frame will be inserted to correct queue 2 (BE).
In this case frames are now dequeued from 2 different queues and
sent out of order.

Signed-off-by: Meirav Kama 
Signed-off-by: Yaniv Machani 
---
 net/mac80211/rx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 9a1eb70..88dc744 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2392,6 +2392,7 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
info->control.vif = >sdata->vif;
info->control.jiffies = jiffies;
+   info->hw_queue = q;
if (is_multicast_ether_addr(fwd_hdr->addr1)) {
IEEE80211_IFSTA_MESH_CTR_INC(ifmsh, fwded_mcast);
memcpy(fwd_hdr->addr2, sdata->vif.addr, ETH_ALEN);
-- 
2.9.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 v2 2/3] mac80211: mesh: improve path resolving time

2016-07-13 Thread Yaniv Machani

When a packet is received for transmission,
a PREQ frame is sent to resolve the appropriate path to the desired destination.
After path was established, any sequential PREQ will be sent only after
dot11MeshHWMPpreqMinInterval, which usually set to few seconds.

This implementation has an impact in cases where we would like to
resolve the path quickly.
A clear example is when a peer was disconnected from us,
while he acted as a hop to our destination.
Although the path table will be cleared, the next PREQ frame will be sent only 
after reaching the MinInterval.
This will cause unwanted delay, possibly of few seconds until the traffic will 
resume.

To improve that, added an 'immediate' flag to be used when the path needs to be 
resolved.
Once set, a PREQ frame will be send w/o considering the MinInterval parameter.

Signed-off-by: Maital Hahn 
Signed-off-by: Yaniv Machani 
---
v2 - Updated comment to explain the scenario better.
   - Removed unnccesary changes that was alreay upstreamed.
   
 net/mac80211/mesh_hwmp.c | 42 +-
 1 file changed, 25 insertions(+), 17 deletions(-)

diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 8f9c3bd..9783d49 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -19,7 +19,7 @@
 
 #define MAX_PREQ_QUEUE_LEN 64
 
-static void mesh_queue_preq(struct mesh_path *, u8);
+static void mesh_queue_preq(struct mesh_path *, u8, bool);
 
 static inline u32 u32_field_get(const u8 *preq_elem, int offset, bool ae)
 {
@@ -830,7 +830,8 @@ static void hwmp_rann_frame_process(struct 
ieee80211_sub_if_data *sdata,
mhwmp_dbg(sdata,
  "time to refresh root mpath %pM\n",
  orig_addr);
-   mesh_queue_preq(mpath, PREQ_Q_F_START | PREQ_Q_F_REFRESH);
+   mesh_queue_preq(mpath, PREQ_Q_F_START | PREQ_Q_F_REFRESH,
+   false);
mpath->last_preq_to_root = jiffies;
}
 
@@ -925,7 +926,7 @@ void mesh_rx_path_sel_frame(struct ieee80211_sub_if_data 
*sdata,
  * Locking: the function must be called from within a rcu read lock block.
  *
  */
-static void mesh_queue_preq(struct mesh_path *mpath, u8 flags)
+static void mesh_queue_preq(struct mesh_path *mpath, u8 flags, bool immediate)
 {
struct ieee80211_sub_if_data *sdata = mpath->sdata;
struct ieee80211_if_mesh *ifmsh = >u.mesh;
@@ -964,18 +965,24 @@ static void mesh_queue_preq(struct mesh_path *mpath, u8 
flags)
++ifmsh->preq_queue_len;
spin_unlock_bh(>mesh_preq_queue_lock);
 
-   if (time_after(jiffies, ifmsh->last_preq + min_preq_int_jiff(sdata)))
+   if (immediate) {
ieee80211_queue_work(>local->hw, >work);
+   } else {
+   if (time_after(jiffies,
+  ifmsh->last_preq + min_preq_int_jiff(sdata))) {
+   ieee80211_queue_work(>local->hw, >work);
 
-   else if (time_before(jiffies, ifmsh->last_preq)) {
-   /* avoid long wait if did not send preqs for a long time
-* and jiffies wrapped around
-*/
-   ifmsh->last_preq = jiffies - min_preq_int_jiff(sdata) - 1;
-   ieee80211_queue_work(>local->hw, >work);
-   } else
-   mod_timer(>mesh_path_timer, ifmsh->last_preq +
-   min_preq_int_jiff(sdata));
+   } else if (time_before(jiffies, ifmsh->last_preq)) {
+   /* avoid long wait if did not send preqs for a long time
+* and jiffies wrapped around
+*/
+   ifmsh->last_preq = jiffies -
+  min_preq_int_jiff(sdata) - 1;
+   ieee80211_queue_work(>local->hw, >work);
+   } else
+   mod_timer(>mesh_path_timer, ifmsh->last_preq +
+ min_preq_int_jiff(sdata));
+   }
 }
 
 /**
@@ -1110,7 +1117,7 @@ int mesh_nexthop_resolve(struct ieee80211_sub_if_data 
*sdata,
}
 
if (!(mpath->flags & MESH_PATH_RESOLVING))
-   mesh_queue_preq(mpath, PREQ_Q_F_START);
+   mesh_queue_preq(mpath, PREQ_Q_F_START, true);
 
if (skb_queue_len(>frame_queue) >= MESH_FRAME_QUEUE_LEN)
skb_to_free = skb_dequeue(>frame_queue);
@@ -1157,8 +1164,9 @@ int mesh_nexthop_lookup(struct ieee80211_sub_if_data 
*sdata,
   
msecs_to_jiffies(sdata->u.mesh.mshcfg.path_refresh_time)) &&
ether_addr_equal(sdata->vif.addr, hdr->addr4) &&
!(mpath->flags & MESH_PATH_RESOLVING) &&
-   !(mpath->flags & MESH_PATH_FIXED))
-   mesh_queue_preq(mpath, PREQ_Q_F_START | PREQ_Q_F_REFRESH);
+   !(mpath->flags & MESH_PATH_FIXED)) {
+   mesh_queue_preq(mpath, PREQ_Q_F_START |

[PATCH v2 1/3] mac80211: mesh: flush stations before beacons are stopped

2016-07-13 Thread Yaniv Machani

From: Maital Hahn 

Some drivers (e.g. wl18xx) expect that the last stage in the
de-initialization process will be stopping the beacons, similar to AP flow.
Update ieee80211_stop_mesh() flow accordingly.
As peers can be removed dynamically, this would not impact other drivers.

Tested also on Ralink RT3572 chipset.

Signed-off-by: Maital Hahn 
Signed-off-by: Yaniv Machani 
---
V2- updated comment, patch was tested with RT3572

 net/mac80211/mesh.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 21b1fdf..9214bc1 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -896,20 +896,22 @@ void ieee80211_stop_mesh(struct ieee80211_sub_if_data 
*sdata)
 
netif_carrier_off(sdata->dev);
 
+   /* flush STAs and mpaths on this iface */
+   sta_info_flush(sdata);
+   mesh_path_flush_by_iface(sdata);
+
/* stop the beacon */
ifmsh->mesh_id_len = 0;
sdata->vif.bss_conf.enable_beacon = false;
clear_bit(SDATA_STATE_OFFCHANNEL_BEACON_STOPPED, >state);
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED);
+
+   /* remove beacon */
bcn = rcu_dereference_protected(ifmsh->beacon,
lockdep_is_held(>wdev.mtx));
RCU_INIT_POINTER(ifmsh->beacon, NULL);
kfree_rcu(bcn, rcu_head);
 
-   /* flush STAs and mpaths on this iface */
-   sta_info_flush(sdata);
-   mesh_path_flush_by_iface(sdata);
-
/* free all potentially still buffered group-addressed frames */
local->total_ps_buffered -= skb_queue_len(>ps.bc_buf);
skb_queue_purge(>ps.bc_buf);
-- 
2.9.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 v2 0/3] Mesh mpm fixes and enhancements

2016-07-13 Thread Yaniv Machani

This patch set is addressing some issues found in the current 802.11s 
implementation, specifically when using hostap mpm. 
It's aligning the beacon format and handling some corner cases.

V2 - Updated patches following review comments.
   - Remove unneccary patches (already upsteamed)

Maital Hahn (1):
  mac80211: mesh: flush stations before beacons are stopped

Yaniv Machani (2):
  mac80211: mesh: improve path resolving time
  mac80211: mesh: fixed HT ies in beacon template

 net/mac80211/mesh.c  | 43 ++-
 net/mac80211/mesh_hwmp.c | 42 +-
 net/mac80211/util.c  |  3 ---
 3 files changed, 63 insertions(+), 25 deletions(-)

-- 
2.9.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 3/3] mac80211: mesh: fixed HT ies in beacon template

2016-07-13 Thread Yaniv Machani

The HT capab info field inside the HT capab IE of the mesh beacon
is incorrect (in the case of 20MHz channel width).
To fix this driver will check configuration from cfg and
will build it accordingly.

Signed-off-by: Meirav Kama 
Signed-off-by: Yaniv Machani 
---
V3 - Updated comment
   - Removed CFG changes, as they are not correct.
   
 net/mac80211/mesh.c | 33 -
 net/mac80211/util.c |  3 ---
 2 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 9214bc1..275131d 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -422,6 +422,8 @@ int mesh_add_ht_cap_ie(struct ieee80211_sub_if_data *sdata,
enum nl80211_band band = ieee80211_get_sdata_band(sdata);
struct ieee80211_supported_band *sband;
u8 *pos;
+   u16 cap;
+
 
sband = local->hw.wiphy->bands[band];
if (!sband->ht_cap.ht_supported ||
@@ -430,11 +432,40 @@ int mesh_add_ht_cap_ie(struct ieee80211_sub_if_data 
*sdata,
sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_10)
return 0;
 
+/* determine capability flags */
+   cap = sband->ht_cap.cap;
+
+/* if channel width is 20MHz - configure HT capab accordingly*/
+   if (sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20) {
+   cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
+   cap &= ~IEEE80211_HT_CAP_DSSSCCK40;
+   }
+
+   /* set SM PS mode properly */
+   cap &= ~IEEE80211_HT_CAP_SM_PS;
+   switch (sdata->smps_mode) {
+   case IEEE80211_SMPS_AUTOMATIC:
+   case IEEE80211_SMPS_NUM_MODES:
+   WARN_ON(1);
+   case IEEE80211_SMPS_OFF:
+   cap |= WLAN_HT_CAP_SM_PS_DISABLED <<
+   IEEE80211_HT_CAP_SM_PS_SHIFT;
+   break;
+   case IEEE80211_SMPS_STATIC:
+   cap |= WLAN_HT_CAP_SM_PS_STATIC <<
+   IEEE80211_HT_CAP_SM_PS_SHIFT;
+   break;
+   case IEEE80211_SMPS_DYNAMIC:
+   cap |= WLAN_HT_CAP_SM_PS_DYNAMIC <<
+   IEEE80211_HT_CAP_SM_PS_SHIFT;
+   break;
+   }
+
if (skb_tailroom(skb) < 2 + sizeof(struct ieee80211_ht_cap))
return -ENOMEM;
 
pos = skb_put(skb, 2 + sizeof(struct ieee80211_ht_cap));
-   ieee80211_ie_build_ht_cap(pos, >ht_cap, sband->ht_cap.cap);
+   ieee80211_ie_build_ht_cap(pos, >ht_cap, cap);
 
return 0;
 }
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 42bf0b6..5375a82 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2349,10 +2349,7 @@ u8 *ieee80211_ie_build_ht_oper(u8 *pos, struct 
ieee80211_sta_ht_cap *ht_cap,
ht_oper->operation_mode = cpu_to_le16(prot_mode);
ht_oper->stbc_param = 0x;
 
-   /* It seems that Basic MCS set and Supported MCS set
-  are identical for the first 10 bytes */
memset(_oper->basic_set, 0, 16);
-   memcpy(_oper->basic_set, _cap->mcs, 10);
 
return pos + sizeof(struct ieee80211_ht_operation);
 }
-- 
2.9.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 v2 2/2] mwifiex: add hostcmd wext ioctl support

2016-07-13 Thread Amitkumar Karwar

From: Xinming Hu 

This patch adds ndo_ioctl support to mwifiex netdev handlers.
This will be used to download hostcmds to firmware from userspace.
This is needed for manufacturing mode support in mwifiex. ndo_ioctl
is allowed only when mfg mode is enabled via module load parameters.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
Changes in v2:
 1) Sequence of these two patches are changed to resolve compilation
error seen if only 1/2 is applied.
 2) Add "select WEXT_PRIV" in Kconfig to resolve warnings reported by
kbuild test robot.
---
 drivers/net/wireless/marvell/mwifiex/Kconfig  |  3 ++
 drivers/net/wireless/marvell/mwifiex/cmdevt.c | 59 +++
 drivers/net/wireless/marvell/mwifiex/main.c   | 38 +
 drivers/net/wireless/marvell/mwifiex/main.h   |  9 +++-
 4 files changed, 108 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/Kconfig 
b/drivers/net/wireless/marvell/mwifiex/Kconfig
index 279167d..5b1d52a 100644
--- a/drivers/net/wireless/marvell/mwifiex/Kconfig
+++ b/drivers/net/wireless/marvell/mwifiex/Kconfig
@@ -13,6 +13,7 @@ config MWIFIEX_SDIO
depends on MWIFIEX && MMC
select FW_LOADER
select WANT_DEV_COREDUMP
+   select WEXT_PRIV
---help---
  This adds support for wireless adapters based on Marvell
  8786/8787/8797/8887/8897/8997 chipsets with SDIO interface.
@@ -25,6 +26,7 @@ config MWIFIEX_PCIE
depends on MWIFIEX && PCI
select FW_LOADER
select WANT_DEV_COREDUMP
+   select WEXT_PRIV
---help---
  This adds support for wireless adapters based on Marvell
  8766/8897/8997 chipsets with PCIe interface.
@@ -36,6 +38,7 @@ config MWIFIEX_USB
tristate "Marvell WiFi-Ex Driver for USB8766/8797/8997"
depends on MWIFIEX && USB
select FW_LOADER
+   select WEXT_PRIV
---help---
  This adds support for wireless adapters based on Marvell
  8797/8997 chipset with USB interface.
diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c 
b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 8d57493..d961305 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -826,6 +826,8 @@ int mwifiex_process_cmdresp(struct mwifiex_adapter *adapter)
hostcmd = adapter->curr_cmd->data_buf;
hostcmd->len = size;
memcpy(hostcmd->cmd, resp, size);
+   adapter->hostcmd_resp_data.len = size;
+   memcpy(adapter->hostcmd_resp_data.cmd, resp, size);
}
}
orig_cmdresp_no = le16_to_cpu(resp->command);
@@ -1208,6 +1210,63 @@ mwifiex_process_hs_config(struct mwifiex_adapter 
*adapter)
   false);
 }
 EXPORT_SYMBOL_GPL(mwifiex_process_hs_config);
+/* This function get hostcmd data from userspace and construct a cmd
+   * to be download to FW.
+  */
+int mwifiex_process_host_command(struct mwifiex_private *priv,
+struct iwreq *wrq)
+{
+   struct mwifiex_ds_misc_cmd *hostcmd_buf;
+   struct host_cmd_ds_command *cmd;
+   struct mwifiex_adapter *adapter = priv->adapter;
+   int ret;
+
+   hostcmd_buf = kzalloc(sizeof(*hostcmd_buf), GFP_KERNEL);
+   if (!hostcmd_buf)
+   return -ENOMEM;
+
+   cmd = (void *)hostcmd_buf->cmd;
+
+   if (copy_from_user(cmd, wrq->u.data.pointer,
+  sizeof(cmd->command) + sizeof(cmd->size))) {
+   ret = -EFAULT;
+   goto done;
+   }
+
+   hostcmd_buf->len = le16_to_cpu(cmd->size);
+   if (hostcmd_buf->len > MWIFIEX_SIZE_OF_CMD_BUFFER) {
+   ret = -EINVAL;
+   goto done;
+   }
+
+   if (copy_from_user(cmd, wrq->u.data.pointer, hostcmd_buf->len)) {
+   ret = -EFAULT;
+   goto done;
+   }
+
+   if (mwifiex_send_cmd(priv, 0, 0, 0, hostcmd_buf, true)) {
+   dev_err(priv->adapter->dev, "Failed to process hostcmd\n");
+   ret = -EFAULT;
+   goto done;
+   }
+
+   if (adapter->hostcmd_resp_data.len > hostcmd_buf->len) {
+   ret = -EFBIG;
+   goto done;
+   }
+
+   if (copy_to_user(wrq->u.data.pointer, adapter->hostcmd_resp_data.cmd,
+adapter->hostcmd_resp_data.len)) {
+   ret = -EFAULT;
+   goto done;
+   }
+   wrq->u.data.length = adapter->hostcmd_resp_data.len;
+
+   ret = 0;
+done:
+   kfree(hostcmd_buf);
+   return ret;
+}
 
 /*
  * This function handles the command response of a sleep confirm command.
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index b54edf4..e3e1fe9 100644
---

Re: [PATCH v4] brcmfmac: Decrease 8021x_cnt for dropped packets

2016-07-13 Thread Arend Van Spriel

On 12-7-2016 12:23, Per Förlin wrote:
> 2016-07-12 11:48 GMT+02:00 Arend Van Spriel :
>>
>>
>> On 12-7-2016 10:35, Per Förlin wrote:
>>> 2016-07-06 11:53 GMT+02:00 Per Förlin :
 I have now verified this patch on backports 4.4.

 2016-04-12 23:55 GMT+02:00  :
> From: Per Forlin 
>
> This patch resolves an issue where pend_8021x_cnt was not decreased
> on txfinalize. This caused brcmf_netdev_wait_pend8021x to timeout
> because the counter indicated pending packets.
>
> WARNING: at .../brcmfmac/core.c:1289 brcmf_netdev_wait_pend8021x
>   (warn_slowpath_common)
>   (warn_slowpath_null)
>   (brcmf_netdev_wait_pend8021x [brcmfmac])
>   (send_key_to_dongle [brcmfmac])
>   (brcmf_cfg80211_del_key [brcmfmac])
>   (nl80211_del_key [cfg80211])
>   (genl_rcv_msg)
>   (netlink_rcv_skb)
>   (genl_rcv)
>   (netlink_unicast)
>   (netlink_sendmsg)
>   (sock_sendmsg)
>   (___sys_sendmsg)
>   (__sys_sendmsg)
>   (SyS_sendmsg)
>
> The solution is to pull back the header offset in case
> of an error in txdata(), which may happen in case of
>>> Clarification:
>>>
>>> txdata=brcmf_proto_bcdc_txdata()
>>> brcmf_proto_bcdc_txdata(): Calls brcmf_proto_bcdc_hdrpush()
>>>
>>> The header needs to be pulled back in case of error otherwise
>>> the error handling and cleanup up will fail to decrease the counter
>>> of pending packets.
>>
>> Yes, this part of the patch is clear to me.
>>
> Thanks, I wasn't sure.
> 
> packet overload in brcmf_sdio_bus_txdata.
>
> Overloading an WLAN interface is not an unlikely scenario.
>>
>> So here is where things start to look suspicious and I have mentioned
>> this before. My thought here was "How the hell can you end up with a
>> 2048 packets on the sdio queue", which I mentioned to you before. There
>> is a high watermark on the queue upon which we do a netif_stop_queue()
>> so network layer does not keep pushing tx packets our way. Looking
>> further into this I found that we introduced a bug with commit
>> 9cd18359d31e ("brcmfmac: Make FWS queueing configurable.") so we ended
>> up doing nothing except increasing as statistics debug counter :-(
>>
> Is there a fix available for the high watermark issue or is it
> something you will look into?
> 
> To produce a load on the wlan interface I run
> iperf -c 239.255.1.3 -u -b 10m -f m -i 60 -t 3000
> and this is enough in my case to fill up the 2048 queue.
> 
> In case of packet overload the error print "out of bus->txq"
> is very verbose. To reduce SPAM degrade it to a debug print.
>
> Signed-off-by: Per Forlin 
> ---
> Change log:
>  v2 - Add variable to know whether the counter is increased or not
>  v3 - txfinalize should decrease the counter. Adjust skb header offset
>  v4 - Fix build error
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 4 
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c | 4 +++-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
>  3 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> index ed9998b..f342f7c 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> @@ -541,6 +541,9 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct 
> sk_buff *txp, bool success)
> struct ethhdr *eh;
> u16 type;
>
> +   if (!ifp)
> +   goto free;
> +
>>
>> This may not be needed.
>>
> This is not strictly needed. I can remove it.
> 
> eh = (struct ethhdr *)(txp->data);
> type = ntohs(eh->h_proto);
>
> @@ -553,6 +556,7 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct 
> sk_buff *txp, bool success)
> if (!success)
> ifp->stats.tx_errors++;
>
> +free:
> brcmu_pkt_buf_free_skb(txp);
>  }
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
> index f82c9ab..98cb83f 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
> @@ -1899,8 +1899,10 @@ int brcmf_fws_process_skb(struct brcmf_if *ifp, 
> struct sk_buff *skb)
>
> if (fws->avoid_queueing) {
> rc = brcmf_proto_txdata(drvr, ifp->ifidx, 0, skb);
> -   if (rc < 0)
> +   if (rc < 0) {
> +   (void)brcmf_proto_hdrpull(drvr, false, skb, );
>>
>> Could it be that the ifp is

[PATCH v2 1/2] mwifiex: add manufacturing mode support

2016-07-13 Thread Amitkumar Karwar

By default normal mode is chosen when driver is loaded. This patch adds
a provision to choose manufacturing mode via module parameters.

Command to load driver in manufacturing mode
insmod mwifiex.ko mfg_mode=1 and mfg_firmware=mrvl/firmware.

Tested-by: chunfan chen 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cmdevt.c |  8 ++
 drivers/net/wireless/marvell/mwifiex/init.c   | 22 +++--
 drivers/net/wireless/marvell/mwifiex/main.c   | 35 ---
 drivers/net/wireless/marvell/mwifiex/main.h   |  4 +++
 drivers/net/wireless/marvell/mwifiex/pcie.c   |  2 +-
 drivers/net/wireless/marvell/mwifiex/sdio.c   |  2 +-
 drivers/net/wireless/marvell/mwifiex/usb.c|  2 +-
 7 files changed, 61 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c 
b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index c29f26d..8d57493 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -581,6 +581,14 @@ int mwifiex_send_cmd(struct mwifiex_private *priv, u16 
cmd_no,
return -1;
}
}
+   /* We don't expect commands in manufacturing mode. They are cooked
+* in application and ready to download buffer is passed to the driver
+   */
+   if (adapter->mfg_mode && cmd_no) {
+   dev_dbg(adapter->dev, "Ignoring commands in manufacturing 
mode\n");
+   return -1;
+   }
+
 
/* Get a new command node */
cmd_node = mwifiex_get_cmd_node(adapter);
diff --git a/drivers/net/wireless/marvell/mwifiex/init.c 
b/drivers/net/wireless/marvell/mwifiex/init.c
index 1489c90..82839d9 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -298,6 +298,7 @@ static void mwifiex_init_adapter(struct mwifiex_adapter 
*adapter)
memset(>arp_filter, 0, sizeof(adapter->arp_filter));
adapter->arp_filter_size = 0;
adapter->max_mgmt_ie_index = MAX_MGMT_IE_INDEX;
+   adapter->mfg_mode = mfg_mode;
adapter->key_api_major_ver = 0;
adapter->key_api_minor_ver = 0;
eth_broadcast_addr(adapter->perm_addr);
@@ -553,15 +554,22 @@ int mwifiex_init_fw(struct mwifiex_adapter *adapter)
return -1;
}
}
+   if (adapter->mfg_mode) {
+   adapter->hw_status = MWIFIEX_HW_STATUS_READY;
+   ret = -EINPROGRESS;
+   } else {
+   for (i = 0; i < adapter->priv_num; i++) {
+   if (adapter->priv[i]) {
+   ret = mwifiex_sta_init_cmd(adapter->priv[i],
+  first_sta, true);
+   if (ret == -1)
+   return -1;
+
+   first_sta = false;
+   }
+
 
-   for (i = 0; i < adapter->priv_num; i++) {
-   if (adapter->priv[i]) {
-   ret = mwifiex_sta_init_cmd(adapter->priv[i], first_sta,
-  true);
-   if (ret == -1)
-   return -1;
 
-   first_sta = false;
}
}
 
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 0e280f8..b54edf4 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -36,6 +36,14 @@ static unsigned short driver_mode;
 module_param(driver_mode, ushort, 0);
 MODULE_PARM_DESC(driver_mode,
 "station=0x1(default), ap-sta=0x3, station-p2p=0x5, 
ap-sta-p2p=0x7");
+bool mfg_mode;
+module_param(mfg_mode, bool, 0);
+MODULE_PARM_DESC(mfg_mode, "0:disable 1:enable (bool)");
+
+char *mfg_firmware = "";
+module_param(mfg_firmware, charp, 0);
+MODULE_PARM_DESC(mfg_firmware, "firmware path");
+
 
 /*
  * This function registers the device and performs all the necessary
@@ -559,10 +567,12 @@ static void mwifiex_fw_dpc(const struct firmware 
*firmware, void *context)
goto done;
}
/* Wait for mwifiex_init to complete */
-   wait_event_interruptible(adapter->init_wait_q,
-adapter->init_wait_q_woken);
-   if (adapter->hw_status != MWIFIEX_HW_STATUS_READY)
-   goto err_init_fw;
+   if (!adapter->mfg_mode) {
+   wait_event_interruptible(adapter->init_wait_q,
+adapter->init_wait_q_woken);
+   if (adapter->hw_status != MWIFIEX_HW_STATUS_READY)
+   goto err_init_fw;
+   }
 
priv = adapter->priv[MWIFIEX_BSS_ROLE_STA];
if (mwifiex_register_cfg80211(adapter)) {
@@ -666,6 +676,23 @@ static int mwifiex_init_hw_fw(struct

RE: [PATCH 3/4] mac80211: mesh: fixed HT ies in beacon template

2016-07-13 Thread Machani, Yaniv

On Wed, Jun 29, 2016 at 10:17:35, Johannes Berg wrote:
> Cc: Kama, Meirav
> Subject: Re: [PATCH 3/4] mac80211: mesh: fixed HT ies in beacon 
> template
> 
> On Tue, 2016-06-28 at 14:13 +0300, Yaniv Machani wrote:
> >
> >  net/mac80211/mesh.c | 33 -
> >  net/mac80211/util.c |  3 ---
> >  net/wireless/mesh.c |  2 +-
> 
> That's not a good patch - one change is mac80211 and the other cfg80211.
> 
> > -   .ht_opmode =
> IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED,
> > +   .ht_opmode = IEEE80211_HT_OP_MODE_PROTECTION_NONE,
> >
> How are you planning to comply with 802.11 now?

Good point, this changed should be removed.
The reason for this change was that we've noticed a difference between mesh 
beacon (built by the mac80211) and mesh actions (built by the supplicant) in 
the HT information IE.
In beacons the HT operational mode is Mixed Mode (0x11)  while in actions it is 
None (0x00). 
After a second look, it seems that it's the Supplicant that doesn't set the 
default value correctly.

We'll send an updated patch for it.
Thanks,
Yaniv

> 
> The HT Protection field in a mesh STA may be set to no protection mode 
> only if — All STAs detected in the primary or the secondary channel 
> are HT
>   STAs, and
> — All mesh STA members of this MBSS that are one-hop neighbors of the
>   transmitting mesh STA are either:
>   — 20/40 MHz HT mesh STAs in a 20/40 MHz MBSS, or
>   — 20 MHz HT mesh STAs in a 20 MHz MBSS.
> 
> johannes

Re: [PATCH] drivers: misc: ti-st: Use int instead of fuzzy char for callback status

2016-07-13 Thread Samuel Ortiz

Hi Marcel,

On Wed, Jul 13, 2016 at 11:56:02AM +0100, Marcel Holtmann wrote:
> Hi Mauro,
> 
> >> On mips and parisc:
> >> 
> >>drivers/bluetooth/btwilink.c: In function 'ti_st_open':
> >>drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit 
> >> constant conversion [-Woverflow]
> >>   hst->reg_status = -EINPROGRESS;
> >> 
> >>drivers/nfc/nfcwilink.c: In function 'nfcwilink_open':
> >>drivers/nfc/nfcwilink.c:396:31: warning: overflow in implicit constant 
> >> conversion [-Woverflow]
> >>  drv->st_register_cb_status = -EINPROGRESS;
> >> 
> >> There are actually two issues:
> >>  1. Whether "char" is signed or unsigned depends on the architecture.
> >> As the completion callback data is used to pass a (negative) error
> >> code, it should always be signed.
> >>  2. EINPROGRESS is 150 on mips, 245 on parisc.
> >> Hence -EINPROGRESS doesn't fit in a signed 8-bit number.
> >> 
> >> Change the callback status from "char" to "int" to fix these.
> >> 
> >> Signed-off-by: Geert Uytterhoeven 
> > 
> > Patch looks sane to me, but who will apply it?
> > 
> > Anyway:
> > 
> > Acked-by: Mauro Carvalho Chehab 
> 
> I can take it through bluetooth-next if there is no objection.
> 
> Samuel, are you fine with that?
Yes, please go ahead.

Cheers,
Samuel.
--
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] drivers: misc: ti-st: Use int instead of fuzzy char for callback status

2016-07-13 Thread Marcel Holtmann

Hi Mauro,

>> On mips and parisc:
>> 
>>drivers/bluetooth/btwilink.c: In function 'ti_st_open':
>>drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit 
>> constant conversion [-Woverflow]
>>   hst->reg_status = -EINPROGRESS;
>> 
>>drivers/nfc/nfcwilink.c: In function 'nfcwilink_open':
>>drivers/nfc/nfcwilink.c:396:31: warning: overflow in implicit constant 
>> conversion [-Woverflow]
>>  drv->st_register_cb_status = -EINPROGRESS;
>> 
>> There are actually two issues:
>>  1. Whether "char" is signed or unsigned depends on the architecture.
>> As the completion callback data is used to pass a (negative) error
>> code, it should always be signed.
>>  2. EINPROGRESS is 150 on mips, 245 on parisc.
>> Hence -EINPROGRESS doesn't fit in a signed 8-bit number.
>> 
>> Change the callback status from "char" to "int" to fix these.
>> 
>> Signed-off-by: Geert Uytterhoeven 
> 
> Patch looks sane to me, but who will apply it?
> 
> Anyway:
> 
> Acked-by: Mauro Carvalho Chehab 

I can take it through bluetooth-next if there is no objection.

Samuel, are you fine with that?

Regards

Marcel

--
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] drivers: misc: ti-st: Use int instead of fuzzy char for callback status

2016-07-13 Thread Mauro Carvalho Chehab

Em Mon,  6 Jun 2016 11:02:03 +0200
Geert Uytterhoeven  escreveu:

> On mips and parisc:
> 
> drivers/bluetooth/btwilink.c: In function 'ti_st_open':
> drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit 
> constant conversion [-Woverflow]
>hst->reg_status = -EINPROGRESS;
> 
> drivers/nfc/nfcwilink.c: In function 'nfcwilink_open':
> drivers/nfc/nfcwilink.c:396:31: warning: overflow in implicit constant 
> conversion [-Woverflow]
>   drv->st_register_cb_status = -EINPROGRESS;
> 
> There are actually two issues:
>   1. Whether "char" is signed or unsigned depends on the architecture.
>  As the completion callback data is used to pass a (negative) error
>  code, it should always be signed.
>   2. EINPROGRESS is 150 on mips, 245 on parisc.
>  Hence -EINPROGRESS doesn't fit in a signed 8-bit number.
> 
> Change the callback status from "char" to "int" to fix these.
> 
> Signed-off-by: Geert Uytterhoeven 

Patch looks sane to me, but who will apply it?

Anyway:

Acked-by: Mauro Carvalho Chehab 


> ---
> Compile-tested only.
> ---
>  drivers/bluetooth/btwilink.c  | 4 ++--
>  drivers/media/radio/wl128x/fmdrv_common.c | 2 +-
>  drivers/misc/ti-st/st_core.c  | 2 +-
>  drivers/nfc/nfcwilink.c   | 4 ++--
>  include/linux/ti_wilink_st.h  | 2 +-
>  5 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/bluetooth/btwilink.c b/drivers/bluetooth/btwilink.c
> index 24a652f9252be899..485281b3f1677678 100644
> --- a/drivers/bluetooth/btwilink.c
> +++ b/drivers/bluetooth/btwilink.c
> @@ -51,7 +51,7 @@
>   */
>  struct ti_st {
>   struct hci_dev *hdev;
> - char reg_status;
> + int reg_status;
>   long (*st_write) (struct sk_buff *);
>   struct completion wait_reg_completion;
>  };
> @@ -83,7 +83,7 @@ static inline void ti_st_tx_complete(struct ti_st *hst, int 
> pkt_type)
>   * status.ti_st_open() function will wait for signal from this
>   * API when st_register() function returns ST_PENDING.
>   */
> -static void st_reg_completion_cb(void *priv_data, char data)
> +static void st_reg_completion_cb(void *priv_data, int data)
>  {
>   struct ti_st *lhst = priv_data;
>  
> diff --git a/drivers/media/radio/wl128x/fmdrv_common.c 
> b/drivers/media/radio/wl128x/fmdrv_common.c
> index 3f9e6df7d837ac27..642b89c66bcb99eb 100644
> --- a/drivers/media/radio/wl128x/fmdrv_common.c
> +++ b/drivers/media/radio/wl128x/fmdrv_common.c
> @@ -1472,7 +1472,7 @@ static long fm_st_receive(void *arg, struct sk_buff 
> *skb)
>   * Called by ST layer to indicate protocol registration completion
>   * status.
>   */
> -static void fm_st_reg_comp_cb(void *arg, char data)
> +static void fm_st_reg_comp_cb(void *arg, int data)
>  {
>   struct fmdev *fmdev;
>  
> diff --git a/drivers/misc/ti-st/st_core.c b/drivers/misc/ti-st/st_core.c
> index dcdbd58672ccc6d2..00051590e00f9647 100644
> --- a/drivers/misc/ti-st/st_core.c
> +++ b/drivers/misc/ti-st/st_core.c
> @@ -141,7 +141,7 @@ static void st_send_frame(unsigned char chnl_id, struct 
> st_data_s *st_gdata)
>   * This function is being called with spin lock held, protocol drivers are
>   * only expected to complete their waits and do nothing more than that.
>   */
> -static void st_reg_complete(struct st_data_s *st_gdata, char err)
> +static void st_reg_complete(struct st_data_s *st_gdata, int err)
>  {
>   unsigned char i = 0;
>   pr_info(" %s ", __func__);
> diff --git a/drivers/nfc/nfcwilink.c b/drivers/nfc/nfcwilink.c
> index f81e500e765061fd..3fbd18b8e473f696 100644
> --- a/drivers/nfc/nfcwilink.c
> +++ b/drivers/nfc/nfcwilink.c
> @@ -94,7 +94,7 @@ struct nfcwilink {
>   struct nci_dev  *ndev;
>   unsigned long   flags;
>  
> - charst_register_cb_status;
> + int st_register_cb_status;
>   long(*st_write) (struct sk_buff *);
>  
>   struct completion   completed;
> @@ -320,7 +320,7 @@ exit:
>  }
>  
>  /* Called by ST when registration is complete */
> -static void nfcwilink_register_complete(void *priv_data, char data)
> +static void nfcwilink_register_complete(void *priv_data, int data)
>  {
>   struct nfcwilink *drv = priv_data;
>  
> diff --git a/include/linux/ti_wilink_st.h b/include/linux/ti_wilink_st.h
> index 0a0d56834c8eb412..f2293028ab9d65e6 100644
> --- a/include/linux/ti_wilink_st.h
> +++ b/include/linux/ti_wilink_st.h
> @@ -71,7 +71,7 @@ struct st_proto_s {
>   enum proto_type type;
>   long (*recv) (void *, struct sk_buff *);
>   unsigned char (*match_packet) (const unsigned char *data);
> - void (*reg_complete_cb) (void *, char data);
> + void (*reg_complete_cb) (void *, int data);
>   long (*write) (struct sk_buff *skb);
>   void *priv_data;
>  


-- 
Thanks,
Mauro
--
To

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

2016-07-13 Thread Prarit Bhargava

On 07/13/2016 03:24 AM, Luca Coelho wrote:
> On Wed, 2016-07-13 at 09:50 +0300, Kalle Valo wrote:
>> Prarit Bhargava  writes:
>>
 We implement thermal zone because we do support it, but the
 problem is
 that we need the firmware to be loaded for that. So you can argue
 that
 we should register *later* when the firmware is loaded. But this
 is
 really not helping all that much because the firmware can also be
 stopped at any time. So you'd want us to register / unregister
 the
 thermal zone anytime the firmware is loaded / unloaded?
>>>
>>> You might have to do that.  I think that if the firmware enables a
>>> feature then
>>> the act of loading the firmware should run the code that enables
>>> the feature.
>>> IMO of course.
>>
>> But I suspect that the iwlwifi firmware is loaded during interface up
>> (and unloaded during interface down) and in that case
>> register/unregister would be happening all the time. That doesn't
>> sound
>> like a good idea. I would rather try to fix the thermal interface to
>> handle the cases when the measurement is not available.
> 
> I totally agree with Emmanuel and Kalle.  We should not change this.
>  It is a design decision to return an error when the interface is down,
> this is very common with other subsystems as well.  

Please show me another subsystem or driver that does this.  I've looked around
the kernel but cannot find one that updates the firmware and implements new
features on the fly like this.  I have come across several drivers that allow
for an update, but they do not implement new features based on the firmware.

Additionally, what happens when someone back revs firmware versions (which
happens far more than you and I would expect)?  Does that mean I now go from a
functional system to a non-functional system wrt to userspace?

The userspace
> should be able to handle errors and report something like "unavailable"
> when this kind of error is returned.
> 

I myself have made the same arguments wrt to cpufreq code & bad userspace
choices.  I just went through this a few months back with what went from a
simple patch and turned out to be a hideous patch in cpufreq.  You cannot break
userspace like this.

See commit 51443fbf3d2c ("cpufreq: intel_pstate: Fix intel_pstate powersave
min_perf_pct value").  What should have been a trivial change resulted in a
massive change because of broken userspace.

> I'm not sure EIO is the best we can have, but for me that's exactly
> what it is.  The thermal zone *is* there, but cannot be accessed
> because the firmware is not available.  I'm okay to change it to EBUSY,
> if that would help userspace, but I think that's a bit misleading.  The
> device is not busy, on the contrary, it's not even running at all.
> 

I understand that, but by returning -EIO we end up with an error.

> Furthermore, I don't think this is "breaking userspace" in the sense of
> being a regression.  

I run (let's say 4.5 kernel).  sensors works.  I update to 4.7.  sensors doesn't
work.  How is that not a regression?  That's _exactly_ what it should be
reported as.

The userspace API has always been implemented with
> the possibility of returning errors.  It's not a good design if a
> single device returning an error causes all the other devices to also
> fail.
> 

If that were the case we would never have to worry about "breaking userspace"?
For any kernel change I could just say that the userspace design was bad and be
done with it.  Why fix anything then?

I don't see any harm in waiting to register the sysfs files for hwmon until the
firmware has been validated.  IIUC, the up/down'ing of the device doesn't happen
that often (during initial boot, and suspend/resume, switching wifi connections,
shutdown?).  This would make the iwlwifi community happy (IMO) and sensors would
still work.  At the same time I could write a patch for lm-sensors to fix this
issue if it comes up in future versions.  [Aside: I'm going to have the
reproducing system available today and will test this out.  It looks like just
moving some code around.]

The bottom line is that lm-sensors is currently broken with this change in
iwlwifi.  AFAICT, no other thermal device returns an error this way, and IMO
that means the iwlwifi driver is doing something new and unexpected wrt to
userspace.

P.

> --
> Cheers,
> Luca.
> 
--
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/4] mac80211: mesh: flush stations before beacons are stopped

2016-07-13 Thread Machani, Yaniv

On Wed, Jun 29, 2016 at 10:14:19, Johannes Berg wrote:
> Cc: Hahn, Maital
> Subject: Re: [PATCH 1/4] mac80211: mesh: flush stations before beacons 
> are stopped
> 
> On Tue, 2016-06-28 at 14:13 +0300, Yaniv Machani wrote:
> > From: Maital Hahn 
> >
> > Some drivers (e.g. wl18xx) expect that the last stage in the 
> > de-initialization process will be stopping the beacons, similar to ap.
> > Update ieee80211_stop_mesh() flow accordingly.
> >
> How well have you tested that with other drivers?
> 

Sorry for the delayed response (I've been out) and thanks for your comments,
I have tested it with RT3572 as well, and didn't see any issue.
I'll update the comment to reflect that.

Thanks,
Yaniv

> Changing behaviour to something a single driver desires isn't 
> necessarily the best thing to do, since there always are multiple drivers.
> 
> If you're able to demonstrate that it works with the other drivers I'm 
> willing to take that - the change makes sense after all, and it seems 
> drivers must support this ordering since peers are also removed 
> dynamically... But still. Don't just make a change like that without 
> even giving any indication why you think it's fine for other drivers!
> 
> johannes


N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

2016-07-13 Thread Prarit Bhargava



On 07/13/2016 02:50 AM, Kalle Valo wrote:
> Prarit Bhargava  writes:
> 
>>> We implement thermal zone because we do support it, but the problem is
>>> that we need the firmware to be loaded for that. So you can argue that
>>> we should register *later* when the firmware is loaded. But this is
>>> really not helping all that much because the firmware can also be
>>> stopped at any time. So you'd want us to register / unregister the
>>> thermal zone anytime the firmware is loaded / unloaded?
>>
>> You might have to do that.  I think that if the firmware enables a feature 
>> then
>> the act of loading the firmware should run the code that enables the feature.
>> IMO of course.
> 
> But I suspect that the iwlwifi firmware is loaded during interface up
> (and unloaded during interface down) and in that case
> register/unregister would be happening all the time. 

You make it sound like the interface is coming and going a 1000 times a second.
 Maybe this happens once during runtime & during suspend/resume cycles?  What
about the cases when the firmware isn't present (and that's what lead me to this
bug)?

That doesn't sound
> like a good idea. I would rather try to fix the thermal interface to
> handle the cases when the measurement is not available.
> 

Userspace is broken because of this change.  I've had to make another horrible
change to cpufreq for a similar change so I don't see the argument here to just
blame userspace and ignore the outcome of the patch.

P.
--
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] wlcore/wl18xx: mesh: added initial mesh support for wl8

2016-07-13 Thread Machani, Yaniv

On Tue, Jun 28, 2016 at 13:41:35, Machani, Yaniv wrote:
> Guy; Johannes Berg; Arik Nemtsov; linux-wireless@vger.kernel.org; 
> net...@vger.kernel.org
> Subject: [PATCH] wlcore/wl18xx: mesh: added initial mesh support for 
> wl8
> 
> From: Maital Hahn 
> 
> 1. Added support for interface and role of mesh type.
> 2. Enabled enable/start of mesh-point role,
>and opening and closing a connection with a mesh peer.
> 3. Added multirole combination of mesh and ap
>under the same limits of dual ap mode.
> 4. Add support for 'sta_rc_update' opcode for mesh IF.
>The 'sta_rc_update' opcode is being used in mesh_plink.c.
> Add support in wlcore to handle this opcode correctly for mesh (as 
> opposed to current implementation that handles STA only).
> 5. Bumped the firmware version to support new Mesh functionality
> 
> Signed-off-by: Maital Hahn 
> Signed-off-by: Yaniv Machani 
> ---

Any comments on this patch ?
Can this be pulled ?

Thanks,
Yaniv
--
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: TCP performance regression in mac80211 triggered by the fq code

2016-07-13 Thread Dave Taht

On Wed, Jul 13, 2016 at 10:53 AM, Felix Fietkau  wrote:

>> To me this implies a contending lock issue, too much work in the irq
>> handler or too delayed work in the softirq handler
>>
>> I thought you were very brave to try and backport this.
> I don't think this has anything to do with contending locks, CPU
> utilization, etc. The code does something to the packets that TCP really
> doesn't like.

With your 70% idle figure, I am inclined to agree... could you get an aircap
of the two different tests?  - as well as a regular packetcap taken at
the client or server?
And put somewhere I can get at them?

What version of OSX are you running?

I will setup an ath9k box shortly...

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
--
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: remove skb header offset mangling in ieee80211_build_hdr

2016-07-13 Thread Felix Fietkau

Since the code only touches the MAC headers, the offsets to the
network/transport headers remain the same throughout this function.
Remove pointless pieces of code that try to 'preserve' them.

Signed-off-by: Felix Fietkau 
---
 net/mac80211/tx.c | 28 ++--
 1 file changed, 2 insertions(+), 26 deletions(-)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 24ec38a..cc2ca09 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2325,7 +2325,6 @@ static struct sk_buff *ieee80211_build_hdr(struct 
ieee80211_sub_if_data *sdata,
struct mesh_path __maybe_unused *mppath = NULL, *mpath = NULL;
const u8 *encaps_data;
int encaps_len, skip_header_bytes;
-   int nh_pos, h_pos;
bool wme_sta = false, authorized = false;
bool tdls_peer;
bool multicast;
@@ -2634,13 +2633,7 @@ static struct sk_buff *ieee80211_build_hdr(struct 
ieee80211_sub_if_data *sdata,
encaps_len = 0;
}
 
-   nh_pos = skb_network_header(skb) - skb->data;
-   h_pos = skb_transport_header(skb) - skb->data;
-
skb_pull(skb, skip_header_bytes);
-   nh_pos -= skip_header_bytes;
-   h_pos -= skip_header_bytes;
-
head_need = hdrlen + encaps_len + meshhdrlen - skb_headroom(skb);
head_need += padsize;
 
@@ -2667,18 +2660,12 @@ static struct sk_buff *ieee80211_build_hdr(struct 
ieee80211_sub_if_data *sdata,
}
}
 
-   if (encaps_data) {
+   if (encaps_data)
memcpy(skb_push(skb, encaps_len), encaps_data, encaps_len);
-   nh_pos += encaps_len;
-   h_pos += encaps_len;
-   }
 
 #ifdef CONFIG_MAC80211_MESH
-   if (meshhdrlen > 0) {
+   if (meshhdrlen > 0)
memcpy(skb_push(skb, meshhdrlen), _hdr, meshhdrlen);
-   nh_pos += meshhdrlen;
-   h_pos += meshhdrlen;
-   }
 #endif
 
if (padsize)
@@ -2697,15 +2684,7 @@ static struct sk_buff *ieee80211_build_hdr(struct 
ieee80211_sub_if_data *sdata,
} else
memcpy(skb_push(skb, hdrlen), , hdrlen);
 
-   nh_pos += hdrlen + padsize;
-   h_pos += hdrlen + padsize;
-
-   /* Update skb pointers to various headers since this modified frame
-* is going to go through Linux networking code that may potentially
-* need things like pointer to IP header. */
skb_reset_mac_header(skb);
-   skb_set_network_header(skb, nh_pos);
-   skb_set_transport_header(skb, h_pos);
 
info = IEEE80211_SKB_CB(skb);
memset(info, 0, sizeof(*info));
@@ -4391,9 +4370,6 @@ void __ieee80211_tx_skb_tid_band(struct 
ieee80211_sub_if_data *sdata,
int ac = ieee802_1d_to_ac[tid & 7];
 
skb_reset_mac_header(skb);
-   skb_reset_network_header(skb);
-   skb_reset_transport_header(skb);
-
skb_set_queue_mapping(skb, ac);
skb->priority = tid;
 
-- 
2.8.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: TCP performance regression in mac80211 triggered by the fq code

2016-07-13 Thread Felix Fietkau

On 2016-07-13 09:57, Dave Taht wrote:
> On Tue, Jul 12, 2016 at 4:02 PM, Dave Taht  wrote:
>> On Tue, Jul 12, 2016 at 3:21 PM, Felix Fietkau  wrote:
>>> On 2016-07-12 14:13, Dave Taht wrote:
 On Tue, Jul 12, 2016 at 12:09 PM, Felix Fietkau  wrote:
> Hi,
>
> With Toke's ath9k txq patch I've noticed a pretty nasty performance
> regression when running local iperf on an AP (running the txq stuff) to
> a wireless client.

 Your kernel? cpu architecture?
>>> QCA9558, 720 MHz, running Linux 4.4.14
> 
> So this is a single core at the near-bottom end of the range. I guess
> we also should find a MIPS 24c derivative that runs at 400Mhz or so.
> 
> What HZ? (I no longer know how much higher HZ settings make any
> difference, but I'm usually at NOHZ and 250, rather than 100.)
> 
> And all the testing to date was on much higher end multi-cores.
> 
 What happens when going through the AP to a server from the wireless 
 client?
>>> Will test that next.
> 
> And?
Single stream: 130 Mbit/s, 70% idle
Two streams: 50-80 Mbit/s (wildly fluctuating), 73% idle.

 Which direction?
>>> AP->STA, iperf running on the AP. Client is a regular MacBook Pro
>>> (Broadcom).
>>
>> There are always 2 wifi chips in play. Like the Sith.
>>
> Here's some things that I found:
> - when I use only one TCP stream I get around 90-110 Mbit/s

 with how much cpu left over?
>>> ~20%
>>>
> - when running multiple TCP streams, I get only 35-40 Mbit/s total
 with how much cpu left over?
>>> ~30%
> 
> To me this implies a contending lock issue, too much work in the irq
> handler or too delayed work in the softirq handler
> 
> I thought you were very brave to try and backport this.
I don't think this has anything to do with contending locks, CPU
utilization, etc. The code does something to the packets that TCP really
doesn't like.

- 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

Re: TCP performance regression in mac80211 triggered by the fq code

2016-07-13 Thread Dave Taht

On Tue, Jul 12, 2016 at 4:02 PM, Dave Taht  wrote:
> On Tue, Jul 12, 2016 at 3:21 PM, Felix Fietkau  wrote:
>> On 2016-07-12 14:13, Dave Taht wrote:
>>> On Tue, Jul 12, 2016 at 12:09 PM, Felix Fietkau  wrote:
 Hi,

 With Toke's ath9k txq patch I've noticed a pretty nasty performance
 regression when running local iperf on an AP (running the txq stuff) to
 a wireless client.
>>>
>>> Your kernel? cpu architecture?
>> QCA9558, 720 MHz, running Linux 4.4.14

So this is a single core at the near-bottom end of the range. I guess
we also should find a MIPS 24c derivative that runs at 400Mhz or so.

What HZ? (I no longer know how much higher HZ settings make any
difference, but I'm usually at NOHZ and 250, rather than 100.)

And all the testing to date was on much higher end multi-cores.

>>> What happens when going through the AP to a server from the wireless client?
>> Will test that next.

And?

>>
>>> Which direction?
>> AP->STA, iperf running on the AP. Client is a regular MacBook Pro
>> (Broadcom).
>
> There are always 2 wifi chips in play. Like the Sith.
>
 Here's some things that I found:
 - when I use only one TCP stream I get around 90-110 Mbit/s
>>>
>>> with how much cpu left over?
>> ~20%
>>
 - when running multiple TCP streams, I get only 35-40 Mbit/s total
>>> with how much cpu left over?
>> ~30%

To me this implies a contending lock issue, too much work in the irq
handler or too delayed work in the softirq handler

I thought you were very brave to try and backport this.

>
> Hmm.
>
> Care to try netperf?
>
>>
>>> context switch difference between the two tests?
>> What's the easiest way to track that?
>
> if you have gnu "time" time -v the_process
>
> or:
>
> perf record -e context-switches -ag
>
> or: process /proc/$PID/status for cntx
>
>>> tcp_limit_output_bytes is?
>> 262144
>
> I keep hoping to be able to reduce this to something saner like 4096
> one day. It got bumped to 64k based on bad wifi performance once, and
> then to it's current size to make the Xen folk happier.
>
> The other param I'd like to see fiddled with is tcp_notsent_lowat.
>
> In both cases reductions will increase your context switches but
> reduce memory pressure and lead to a more reactive tcp.
>
> And in neither case I think this is the real cause of this problem.
>
>
>>> got perf?
>> Need to make a new build for that.
>>
 - fairness between TCP streams looks completely fine
>>>
>>> A codel will get to long term fairness pretty fast. Packet captures
>>> from a fq will show much more regular interleaving of packets,
>>> regardless.
>>>
 - there's no big queue buildup, the code never actually drops any packets
>>>
>>> A "trick" I have been using to observe codel behavior has been to
>>> enable ecn on server and client, then checking in wireshark for ect(3)
>>> marked packets.
>> I verified this with printk. The same issue already appears if I have
>> just the fq patch (with the codel patch reverted).
>
> OK. A four flow test "should" trigger codel
>
> Running out of cpu (or hitting some other bottleneck), without
> loss/marking "should" result in a tcptrace -G and xplot.org of the
> packet capture showing the window continuing to increase
>
>
 - if I put a hack in the fq code to force the hash to a constant value
>>>
>>> You could also set "flows" to 1 to keep the hash being generated, but
>>> not actually use it.
>>>
 (effectively disabling fq without disabling codel), the problem
 disappears and even multiple streams get proper performance.
>>>
>>> Meaning you get 90-110Mbits ?
>> Right.
>>
>>> Do you have a "before toke" figure for this platform?
>> It's quite similar.
>>
 Please let me know if you have any ideas.
>>>
>>> I am in berlin, packing hardware...
>> Nice!
>>
>> - Felix
>>
>
>
>
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
--
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 2016-07-11

2016-07-13 Thread Kalle Valo

Luca Coelho  writes:

> This is a fix for a warning that was spotted by Linus.  We already have
> this patch queued in -next, but it should have gone to -fixes.  I hope
> it is still possible to send it for 4.7.  And it shouldn't be a problem
> to have it in both, right? I guess git merge would take care of that.

Like we discussed privately, even if iwlwifi was printing warnings the
connection was still working for Linus so this is not critical enough
for 4.7 so late in the cycle. So let's drop this and the fix can go to
4.8 as planned.

-- 
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 v4 1/3] Documentation: dt: net: add ath9k wireless device binding

2016-07-13 Thread Arnd Bergmann

On Wednesday, July 13, 2016 10:02:39 AM CEST Kalle Valo wrote:
> Martin Blumenstingl  writes:
> 
> > Add documentation how devicetree can be used to configure ath9k based
> > devices.
> >
> > Signed-off-by: Martin Blumenstingl 
> > ---
> >  .../devicetree/bindings/net/wireless/qca,ath9k.txt | 59 
> > ++
> >  1 file changed, 59 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt 
> > b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> > new file mode 100644
> > index 000..7c62c59
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> > @@ -0,0 +1,59 @@
> > +* Qualcomm Atheros ath9k wireless devices
> > +
> > +This node provides properties for configuring the ath9k wireless device. 
> > The
> > +node is expected to be specified as a child node of the PCI controller to
> > +which the wireless chip is connected.
> > +
> > +Required properties:
> > +- compatible: Should be "qca,ath9k"
> 
> Isn't this supposed to use the chipset name? ath9k is the driver name
> and something like ar9462 is the chip name. I know in ath10k we used
> "qca,ath10k" but I'm starting to suspect that was a mistake.
> 

You are right, but it's actually more complicated than that. For PCI
devices, the format of the compatible strings is defined in
http://www.o3one.org/hwdocs/openfirmware/pci_supplement_2_1.pdf
and it doesn't use the "vendor,device" syntax at all but instead
uses pci, where  and  are the hexadecimal (without
leading 0x) vendor and device ID numbers. The document also specifies
seven other formats and in theory you should list them all, but
that really only makes sense for Open Firmware that programatically
creates those strings.

For a hand-written DTS source, I'd just use the shortest one of those.
Linux actually doesn't care at all, as PCI drivers don't use the
compatible string but instead look at the config register values
that were read by the PCI core.

For USB, we do basically the same thing, but have very few examples
of that as Linux only recently started supporting this.

For SDIO devices we should have done the same thing but screwed up
when we made the generic binding and we have no policy, the example
even lists one that makes no sense at all ("brcm,bcm43xx-fmac")
as it is neither a specific device nor something derived from the IDs.

For on-chip devices, we should follow the common policy for on-chip
devices and use the "vendor,chip-funcion" with fallbacks for
compatible devices such as:

compatible = "tplink,tp9343-wifi", "qca,qca9561-wifi", 
"atheros,ar9001-wifi";

For a chip that is branded by TP-Link and derived from a Qualcomm Atheros
chip it is 100% compatible with, and in turn derived from an older
implementation (just guessing which one was the original ath9k).

Arnd
--
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 RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

2016-07-13 Thread Luca Coelho

On Wed, 2016-07-13 at 09:50 +0300, Kalle Valo wrote:
> Prarit Bhargava  writes:
> 
> > > We implement thermal zone because we do support it, but the
> > > problem is
> > > that we need the firmware to be loaded for that. So you can argue
> > > that
> > > we should register *later* when the firmware is loaded. But this
> > > is
> > > really not helping all that much because the firmware can also be
> > > stopped at any time. So you'd want us to register / unregister
> > > the
> > > thermal zone anytime the firmware is loaded / unloaded?
> > 
> > You might have to do that.  I think that if the firmware enables a
> > feature then
> > the act of loading the firmware should run the code that enables
> > the feature.
> > IMO of course.
> 
> But I suspect that the iwlwifi firmware is loaded during interface up
> (and unloaded during interface down) and in that case
> register/unregister would be happening all the time. That doesn't
> sound
> like a good idea. I would rather try to fix the thermal interface to
> handle the cases when the measurement is not available.

I totally agree with Emmanuel and Kalle.  We should not change this.
 It is a design decision to return an error when the interface is down,
this is very common with other subsystems as well.  The userspace
should be able to handle errors and report something like "unavailable"
when this kind of error is returned.

I'm not sure EIO is the best we can have, but for me that's exactly
what it is.  The thermal zone *is* there, but cannot be accessed
because the firmware is not available.  I'm okay to change it to EBUSY,
if that would help userspace, but I think that's a bit misleading.  The
device is not busy, on the contrary, it's not even running at all.

Furthermore, I don't think this is "breaking userspace" in the sense of
being a regression.  The userspace API has always been implemented with
the possibility of returning errors.  It's not a good design if a
single device returning an error causes all the other devices to also
fail.

--
Cheers,
Luca.
--
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: 4.8 merge window closing

2016-07-13 Thread Kalle Valo

Kalle Valo  writes:

> Linus released 4.7-rc6 last Sunday but didn't give any hints how close
> the real release is, but nevertheless the merge window for 4.8 is
> getting quite close so if there's anything you want to have in
> wireless-drivers-next for 4.8 better send them NOW. Especially as I
> won't have that much time to apply patches the next two weeks.

Due to travelling Linus gave us one more week so the deadline for
wireless-drivers patches is now next Sunday (or so). As I'm taking it
easy this week still I will start actively applying patches only next
week, but better to have the patches reviewed and ready by then.

-- 
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] mac80211: End the MPSP even if EOSP frame was not received

2016-07-13 Thread Masashi Honma

The mesh STA sends QoS frame with EOSP (end of service period)
subfiled=1 to end the MPSP(mesh peer service period). Previously, if
the frame was not acked by peer, the mesh STA did not end the MPSP.
This patch ends the MPSP even if the QoS frame was no acked.

Signed-off-by: Masashi Honma 
---
 net/mac80211/status.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index c6d5c72..a2a6826 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -771,6 +771,13 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct 
sk_buff *skb)
clear_sta_flag(sta, WLAN_STA_SP);
 
acked = !!(info->flags & IEEE80211_TX_STAT_ACK);
+
+   /* mesh Peer Service Period support */
+   if (ieee80211_vif_is_mesh(>sdata->vif) &&
+   ieee80211_is_data_qos(fc))
+   ieee80211_mpsp_trigger_process(
+   ieee80211_get_qos_ctl(hdr), sta, true, acked);
+
if (!acked && test_sta_flag(sta, WLAN_STA_PS_STA)) {
/*
 * The STA is in power save mode, so assume
@@ -781,13 +788,6 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct 
sk_buff *skb)
return;
}
 
-   /* mesh Peer Service Period support */
-   if (ieee80211_vif_is_mesh(>sdata->vif) &&
-   ieee80211_is_data_qos(fc))
-   ieee80211_mpsp_trigger_process(
-   ieee80211_get_qos_ctl(hdr),
-   sta, true, acked);
-
if (ieee80211_hw_check(>hw, HAS_RATE_CONTROL) &&
(ieee80211_is_data(hdr->frame_control)) &&
(rates_idx != -1))
-- 
2.7.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 v4 1/3] Documentation: dt: net: add ath9k wireless device binding

2016-07-13 Thread Kalle Valo

Martin Blumenstingl  writes:

> Add documentation how devicetree can be used to configure ath9k based
> devices.
>
> Signed-off-by: Martin Blumenstingl 
> ---
>  .../devicetree/bindings/net/wireless/qca,ath9k.txt | 59 
> ++
>  1 file changed, 59 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> new file mode 100644
> index 000..7c62c59
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> @@ -0,0 +1,59 @@
> +* Qualcomm Atheros ath9k wireless devices
> +
> +This node provides properties for configuring the ath9k wireless device. The
> +node is expected to be specified as a child node of the PCI controller to
> +which the wireless chip is connected.
> +
> +Required properties:
> +- compatible: Should be "qca,ath9k"

Isn't this supposed to use the chipset name? ath9k is the driver name
and something like ar9462 is the chip name. I know in ath10k we used
"qca,ath10k" but I'm starting to suspect that was a mistake.

-- 
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 RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

2016-07-13 Thread Kalle Valo

Prarit Bhargava  writes:

>> We implement thermal zone because we do support it, but the problem is
>> that we need the firmware to be loaded for that. So you can argue that
>> we should register *later* when the firmware is loaded. But this is
>> really not helping all that much because the firmware can also be
>> stopped at any time. So you'd want us to register / unregister the
>> thermal zone anytime the firmware is loaded / unloaded?
>
> You might have to do that.  I think that if the firmware enables a feature 
> then
> the act of loading the firmware should run the code that enables the feature.
> IMO of course.

But I suspect that the iwlwifi firmware is loaded during interface up
(and unloaded during interface down) and in that case
register/unregister would be happening all the time. That doesn't sound
like a good idea. I would rather try to fix the thermal interface to
handle the cases when the measurement is not available.

-- 
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: iwlwifi + wpa2-leap + multiple AP's = call trace

2016-07-13 Thread Arend Van Spriel



On 13-7-2016 2:29, Ismael Farfán wrote:
> Hello list
> 
> I searched this error around and didn't find anything, so here it goes.
> 
> Today I tried to connect to an enterprise network, which means,
> literally, tens of AP's sharing the same name... the network requieres
> user/password authentication (wpa2-leap).
> 
> I'm using Arch
> $ uname -a
> Linux 4.6.3-1-ARCH #1 SMP PREEMPT Fri Jun 24 21:19:13 CEST 2016 x86_64 
> GNU/Linux
> 
> Since the thing just didn't connect, I checked dmesg and found this:
> 
> Any ideas?

>From the stack trace it seems wpa_supplicant on Arch is using WEXT API.
You could try and change it to use NL80211 API. Personally, I have not
used Arch Linux so no idea where to change that.

The warning is here [1]:

503 IWL_DEBUG_TE(mvm, "Add new TE, duration %d TU\n",
504  le32_to_cpu(te_cmd->duration));
505
506 spin_lock_bh(>time_event_lock);
507 if (WARN_ON(te_data->id != TE_MAX)) {
508 spin_unlock_bh(>time_event_lock);
509 return -EIO;
510 }

It seems this function is called with te_data that is already in use,
but that is my uneducated guess so I may be wrong.

Regards,
Arend

[1]
http://lxr.free-electrons.com/source/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c#L507
> 
> [   83.030072] wifi0: aborting authentication with xx:xx:xx:xx:xx:xx
> by local choice (Reason: 3=DEAUTH_LEAVING)
> [   83.030073] [ cut here ]
> [   83.030082] WARNING: CPU: 2 PID: 1087 at
> drivers/net/wireless/intel/iwlwifi/mvm/time-event.c:507 iwl_mvm_tim
> e_event_send_add+0x1c6/0x200 [iwlmvm]
> [   83.030157] CPU: 2 PID: 1087 Comm: wpa_supplicant Tainted: G
>O4.6.3-1-ARCH #1
> [   83.030158] Hardware name: Notebook
> P65_P67SA   /P65_P67SA
> , BIOS 1.03.01 07/22/2015
> [   83.030160]  0286 09e998bc 880403a5b940
> 812e54c2
> [   83.030162]    880403a5b980
> 8107a6bb
> [   83.030164]  01fb81a8a180 88041b443580 88041c329548
> fffb
> [   83.030167] Call Trace:
> [   83.030172]  [] dump_stack+0x63/0x81
> [   83.030174]  [] __warn+0xcb/0xf0
> [   83.030176]  [] warn_slowpath_null+0x1d/0x20
> [   83.030181]  []
> iwl_mvm_time_event_send_add+0x1c6/0x200 [iwlmvm]
> [   83.030184]  [] ? up+0x32/0x50
> [   83.030187]  [] ? wake_up_klogd+0x3b/0x50
> [   83.030189]  [] ? console_unlock+0x4e9/0x590
> [   83.030193]  []
> iwl_mvm_protect_session+0x220/0x280 [iwlmvm]
> [   83.030196]  [] ? iwl_mvm_ref_sync+0x2e/0x140 [iwlmvm]
> [   83.030199]  [] ? vprintk_default+0x1f/0x30
> [   83.030202]  []
> iwl_mvm_mac_mgd_prepare_tx+0x5a/0xa0 [iwlmvm]
> [   83.030216]  [] ieee80211_mgd_deauth+0x338/0x4d0 
> [mac80211]
> [   83.030219]  [] ? enqueue_entity+0x323/0xd70
> [   83.030228]  [] ieee80211_deauth+0x18/0x20 [mac80211]
> [   83.030237]  [] cfg80211_mlme_deauth+0x9f/0x1a0 
> [cfg80211]
> [   83.030242]  [] cfg80211_disconnect+0x9a/0x200 [cfg80211]
> [   83.030248]  []
> cfg80211_mgd_wext_siwessid+0xa9/0x170 [cfg80211]
> [   83.030255]  [] cfg80211_wext_siwessid+0x22/0x40 
> [cfg80211]
> [   83.030258]  [] ioctl_standard_iw_point+0x133/0x350
> [   83.030264]  [] ?
> cfg80211_wext_giwessid+0x50/0x50 [cfg80211]
> [   83.030266]  [] ? wake_up_q+0x32/0x70
> [   83.030268]  [] ? iw_handler_get_private+0x60/0x60
> [   83.030271]  [] ioctl_standard_call+0x87/0xd0
> [   83.030273]  [] ? call_commit_handler.part.4+0x30/0x30
> [   83.030275]  [] wireless_process_ioctl+0x1f0/0x230
> [   83.030278]  [] ? dev_get_by_name_rcu+0x5e/0x80
> [   83.030280]  [] wext_handle_ioctl+0x78/0xd0
> [   83.030283]  [] dev_ioctl+0x2a7/0x5a0
> [   83.030285]  [] sock_ioctl+0x126/0x290
> [   83.030287]  [] do_vfs_ioctl+0xa3/0x5d0
> [   83.030290]  [] ? vfs_write+0x142/0x190
> [   83.030292]  [] SyS_ioctl+0x79/0x90
> [   83.030294]  [] entry_SYSCALL_64_fastpath+0x1a/0xa4
> [   83.030296] ---[ end trace 8247b235a66a1a21 ]---
> 
> 
> 
> 
> 
--
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

57 matches

Mail list logo