Re: [PATCH 28/28] mac80211: Don't wake up from PS for offchannel TX

[Peter Oh]

On 08/31/2018 01:31 AM, Luca Coelho wrote:

)

From: Andrei Otcheretianski 

Otherwise the offchannel frame might be queued due to
IEEE80211_QUEUE_STOP_REASON_PS and later dropped (in
ieee80211_tx_frags()).  Anyway, it doesn't make much sense to wake up
the device during ROC.

Signed-off-by: Andrei Otcheretianski 
Signed-off-by: Luca Coelho 

Please write a cover letter that explains what this patch series is 
trying to do.

28 patches are too many to catch the purpose at once.

Thanks,
Peter

[PATCH] cfg80211: inspect off channel operation only when off channel given

[peter . oh]

From: Peter Oh 

NL80211_ATTR_OFFCHANNEL_TX_OK does not mean given channel is always
off channel, but it means the channel given could be off channel.
Hence it should not block the given channel to be used if given
channel does not require off channel mgmt tx although regulatory
domain is non-ETSI.

Signed-off-by: Peter Oh 
---
 net/wireless/nl80211.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 4eece06..991042b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -9915,7 +9915,9 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct 
genl_info *info)
return -EINVAL;
 
wdev_lock(wdev);
-   if (params.offchan && !cfg80211_off_channel_oper_allowed(wdev)) {
+   if (params.offchan &&
+   !cfg80211_chandef_identical(, >chandef) &&
+   !cfg80211_off_channel_oper_allowed(wdev)) {
wdev_unlock(wdev);
return -EBUSY;
}
-- 
2.7.4

Fwd: Re: [PATCHv2 2/2] ath10k: DFS Host Confirmation

[Peter Oh]

+   /* Even in case of radar detection failure we follow the same
+* behaviour as if radar is detected i.e to switch to a different
+* channel.
+*/
+   if (status_arg.status == WMI_HW_RADAR_DETECTED ||
+   status_arg.status == WMI_RADAR_DETECTION_FAIL)
+   ath10k_radar_detected(ar);


This behavior is different from what Kalle explained.
Failing verification of radar type by FW does not enforce stop DFS
channels from using.
Kalle?

Re: [PATCH 2/2] ath10k: DFS Host Confirmation

[Peter Oh]

Sure, every software change can cause regressions. But the thing is that
this isn't an optional, ath10k has to have this to be able to continue
using DFS channels.

Kalle, you said you don't know which exact FCC requirement this is for 
in another email thread.
Then how come you're sure this is not an optional and this approach is 
right one?


Peter

Re: [PATCH 2/2] ath10k: DFS Host Confirmation

[Peter Oh]

Which regulatory enforcement are you talking to? Are you talking about
such "prevent users from changing regulatory domain" or "don't provide
a manner to change regulatory domain or channel list" ? If not, can
you share the section of document?

Sorry, I don't have any references about that.

This question is for "what the patch is trying to solve" and "to comply 
FCC regulatory rule" is not the right answer. It should be answered by 
"FCC regulatory rule section xx.xx.xx".
So we all can double check if this patch addresses "the root cause of 
the requirement" and "if it's the best approach or not"


Thanks,
Peter

Re: [PATCH] mesh: don't process mesh channel switch unless csa ie provided

[Peter Oh]

On 05/07/2018 01:06 PM, Johannes Berg wrote:

On Mon, 2018-05-07 at 13:04 -0700, Peter Oh wrote:

On 05/07/2018 12:44 PM, Johannes Berg wrote:

On Fri, 2018-04-27 at 12:26 -0700, peter...@bowerswilkins.com wrote:

From: Peter Oh <peter...@bowerswilkins.com>

There is no meaning to call ieee80211_mesh_process_chnswitch
without CSA IE provided, since the function will always return error.

I'm not convinced, an extended channel switch element might be present
instead?

I expected the comment. Yes, extended channel switch element could be
present instead of channel switch element which I missed to take care
of. So you can ignore the patch for now and I'll get back with right
patch for it.

Heh. Well, but then why bother at all? I mean, the inner function will
do the check and fail, and nothing will happen, so why bother?

My real concern is that ieee80211_mesh_process_chnswitch function could 
process at certain level of channel switch procedure although mesh 
channel switch parameter element is not given which is mandatory of CSA 
for mesh.
However the reason I didn't use mesh_chansw_params_ie to check is 
because even though it is correct for standard, I'm not sure if it's 
practically right. IMPO, sending CSA means devices (ap or mesh) detected 
radar, so the ultimate goal to achieve is to evacuate the channel 
although there is something missed in frames.


Peter

Re: [PATCH] mesh: don't process mesh channel switch unless csa ie provided

[Peter Oh]

On 05/07/2018 12:44 PM, Johannes Berg wrote:

On Fri, 2018-04-27 at 12:26 -0700, peter...@bowerswilkins.com wrote:

From: Peter Oh <peter...@bowerswilkins.com>

There is no meaning to call ieee80211_mesh_process_chnswitch
without CSA IE provided, since the function will always return error.

I'm not convinced, an extended channel switch element might be present
instead?
I expected the comment. Yes, extended channel switch element could be 
present instead of channel switch element which I missed to take care 
of. So you can ignore the patch for now and I'll get back with right 
patch for it.


Thanks,
Peter

Re: [PATCH 2/2] ath10k: DFS Host Confirmation

[Peter Oh]

On 05/02/2018 04:27 AM, Kalle Valo wrote:

Peter Oh <peter...@bowerswilkins.com> writes:


On 04/30/2018 10:45 AM, Sriram R wrote:

In the 10.4-3.6 firmware branch there's a new DFS Host confirmation
feature which is advertised using WMI_SERVICE_HOST_DFS_CHECK_SUPPORT flag.

This new features enables the ath10k host to send information to the
firmware on the specifications of detected radar type. This allows the
firmware to validate if the host's radar pattern detector unit is
operational and check if the radar information shared by host matches
the radar pulses sent as phy error events from firmware. If the check
fails the firmware won't allow use of DFS channels on AP mode when using
FCC regulatory region.

What's the main reason you introduce this feature?
What are you trying to solve with this change?

Otherwise one cannot use DFS channels on FCC regions with a firmware
from 10.4-3.6 branch.


It's a big change and none of us knows until I asked and you answered.

@@ -3765,25 +3834,46 @@ static void ath10k_dfs_radar_report(struct ath10k *ar,
ATH10K_DFS_STAT_INC(ar, pulses_detected);
   -if (!ar->dfs_detector->add_pulse(ar->dfs_detector, , NULL))
{
+   if (!ar->dfs_detector->add_pulse(ar->dfs_detector, , )) {
ath10k_dbg(ar, ATH10K_DBG_REGULATORY,
   "dfs no pulse pattern detected, yet\n");
return;
}
   -radar_detected:
-   ath10k_dbg(ar, ATH10K_DBG_REGULATORY, "dfs radar detected\n");
-   ATH10K_DFS_STAT_INC(ar, radar_detected);
+   if ((test_bit(WMI_SERVICE_HOST_DFS_CHECK_SUPPORT, ar->wmi.svc_map)) &&
+   ar->dfs_detector->region == NL80211_DFS_FCC) {

I feel risky that host drivers have no way to control this new feature
and totally rely on FW feature mask. We should have a host drivers'
feature mask such as module param and set it false (don't use) by
default until it proves safe to use.

This is for regulatory enforcement so it's not possible to disable the
feature from host.

Which regulatory enforcement are you talking to?
Are you talking about such "prevent users from changing regulatory 
domain" or "don't provide a manner to change regulatory domain or 
channel list" ?

If not, can you share the section of document?

In addition to that, How do you make sure if FW side DFS radar detection 
algorithm has no defects and it always categorizes phy errors to correct 
radar type?
I'm asking it, because it's known that DFS detector in ath module does 
sometimes detect radar patterns as wrong radar type in both of ath10k 
and ath9k.

I couldn't think FW side detector has no such defects at all.
It's like blind patch to open source community, since no one can review 
the implementation in FW even though no one can guarantee its level of 
integrity.


Peter

Re: [PATCH 2/2] ath10k: DFS Host Confirmation

[Peter Oh]

On 04/30/2018 10:45 AM, Sriram R wrote:

In the 10.4-3.6 firmware branch there's a new DFS Host confirmation
feature which is advertised using WMI_SERVICE_HOST_DFS_CHECK_SUPPORT flag.

This new features enables the ath10k host to send information to the
firmware on the specifications of detected radar type. This allows the
firmware to validate if the host's radar pattern detector unit is
operational and check if the radar information shared by host matches
the radar pulses sent as phy error events from firmware. If the check
fails the firmware won't allow use of DFS channels on AP mode when using
FCC regulatory region.

What's the main reason you introduce this feature?
What are you trying to solve with this change?

+#define ATH10K_WMI_DFS_CONF_TIMEOUT_HZ (HZ / 2)
  
+static void ath10k_radar_confirmation_work(struct work_struct *work)

+{
+   struct ath10k *ar = container_of(work, struct ath10k,
+radar_confirmation_work);
+   struct ath10k_radar_found_info radar_info;
+   int ret, time_left;
+
+   reinit_completion(>wmi.radar_confirm);
+
+   spin_lock_bh(>data_lock);
+   memcpy(_info, >last_radar_info, sizeof(radar_info));
+   spin_unlock_bh(>data_lock);
+
+   ret = ath10k_wmi_report_radar_found(ar, _info);
+   if (ret) {
+   ath10k_warn(ar, "failed to send radar found %d\n", ret);
+   goto wait_complete;
+   }
+
+   time_left = wait_for_completion_timeout(>wmi.radar_confirm,
+   ATH10K_WMI_DFS_CONF_TIMEOUT_HZ);

It looks wrong to me in terms of timeout value.
Typical channel closing time in FCC domain is 200ms (excluding control 
signals), but you're waiting for 500ms for response from FW.

@@ -3765,25 +3834,46 @@ static void ath10k_dfs_radar_report(struct ath10k *ar,
  
  	ATH10K_DFS_STAT_INC(ar, pulses_detected);
  
-	if (!ar->dfs_detector->add_pulse(ar->dfs_detector, , NULL)) {

+   if (!ar->dfs_detector->add_pulse(ar->dfs_detector, , )) {
ath10k_dbg(ar, ATH10K_DBG_REGULATORY,
   "dfs no pulse pattern detected, yet\n");
return;
}
  
-radar_detected:

-   ath10k_dbg(ar, ATH10K_DBG_REGULATORY, "dfs radar detected\n");
-   ATH10K_DFS_STAT_INC(ar, radar_detected);
+   if ((test_bit(WMI_SERVICE_HOST_DFS_CHECK_SUPPORT, ar->wmi.svc_map)) &&
+   ar->dfs_detector->region == NL80211_DFS_FCC) {
I feel risky that host drivers have no way to control this new feature 
and totally rely on FW feature mask. We should have a host drivers' 
feature mask such as module param and set it false (don't use) by 
default until it proves safe to use.

+static void
+ath10k_wmi_event_dfs_status_check(struct ath10k *ar, struct sk_buff *skb)
+{
+   struct wmi_dfs_status_ev_arg status_arg = {};
+   int ret;
+
+   ret = ath10k_wmi_pull_dfs_status(ar, skb, _arg);
+
+   if (ret) {
+   ath10k_warn(ar, "failed to parse dfs status event: %d\n", ret);
+   return;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_REGULATORY,
+  "dfs status event received from fw: %d\n",
+  status_arg.status);
+
+   /* Even in case of radar detection failure we follow the same
+* behaviour as if radar is detected i.e to switch to a different
+* channel.
+*/
+   if (status_arg.status == WMI_HW_RADAR_DETECTED ||
+   status_arg.status == WMI_RADAR_DETECTION_FAIL)
+   ath10k_radar_detected(ar);
+   complete(>wmi.radar_confirm);
+}
What is typical average duration from 
wait_for_completion_timeout(>wmi.radar_confirm) to this completion 
called ?


Thanks,
Peter

Re: [PATCH 1/2] ath: Add support to get the detected radar specifications

[Peter Oh]

On 04/30/2018 10:45 AM, Sriram R wrote:

This enables ath10k/ath9k drivers to collect the specifications of the
radar type once it is detected by the dfs pattern detector unit.
Usage of the collected info is specific to driver implementation.
For example, collected radar info could be used by the host driver
to send to co-processors for additional processing/validation.

What kind of additional processing/validation does it do?
Please give us more details for that.

Thanks,
Peter

[PATCH] mesh: don't process mesh channel switch unless csa ie provided

[peter . oh]

From: Peter Oh <peter...@bowerswilkins.com>

There is no meaning to call ieee80211_mesh_process_chnswitch
without CSA IE provided, since the function will always return error.

Signed-off-by: Peter Oh <peter...@bowerswilkins.com>
---
 net/mac80211/mesh.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index d51da26e9c18..8ced757dff8d 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1196,7 +1196,7 @@ static void ieee80211_mesh_rx_bcn_presp(struct 
ieee80211_sub_if_data *sdata,
stype, mgmt, , rx_status);
 
if (ifmsh->csa_role != IEEE80211_MESH_CSA_ROLE_INIT &&
-   !sdata->vif.csa_active)
+   !sdata->vif.csa_active && elems.ch_switch_ie)
ieee80211_mesh_process_chnswitch(sdata, , true);
 }
 
-- 
2.11.0 (Apple Git-81)

Re: [PATCH 8/9] mac80211: Support adding duration for prepare_tx() callback

[Peter Oh]

where is the 9th patch gone?


On 04/20/2018 03:49 AM, Luca Coelho wrote:

From: Ilan Peer 

There are specific cases, such as SAE authentication exchange, that
might require long duration to complete. For such cases, add support
for indicating to the driver the required duration of the prepare_tx()
operation, so the driver would still be able to complete the frame
exchange.

Currently, indicate the duration only for SAE authentication exchange,
as SAE authentication can take up to 2000 msec (as defined in IEEE
P802.11-REVmd D1.0 p. 3504).

As the patch modified the prepare_tx() callback API, also modify
the relevant code in iwlwifi.

Signed-off-by: Ilan Peer 
Signed-off-by: Luca Coelho 
---
  drivers/net/wireless/ath/ath9k/main.c |  3 ++-
  .../net/wireless/intel/iwlwifi/mvm/mac80211.c |  6 -
  include/net/mac80211.h|  5 +++-
  net/mac80211/driver-ops.h |  8 +++---
  net/mac80211/mlme.c   | 17 -
  net/mac80211/trace.h  | 25 ---
  6 files changed, 49 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/main.c 
b/drivers/net/wireless/ath/ath9k/main.c
index a3be8add56e1..b6663c80e7dd 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -2544,7 +2544,8 @@ static void ath9k_unassign_vif_chanctx(struct 
ieee80211_hw *hw,
  }
  
  static void ath9k_mgd_prepare_tx(struct ieee80211_hw *hw,

-struct ieee80211_vif *vif)
+struct ieee80211_vif *vif,
+u16 duration)
  {
struct ath_softc *sc = hw->priv;
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 51b30424575b..4e428427d1ba 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -2810,7 +2810,8 @@ static int iwl_mvm_mac_conf_tx(struct ieee80211_hw *hw,
  }
  
  static void iwl_mvm_mac_mgd_prepare_tx(struct ieee80211_hw *hw,

- struct ieee80211_vif *vif)
+  struct ieee80211_vif *vif,
+  u16 req_duration)
  {
struct iwl_mvm *mvm = IWL_MAC80211_GET_MVM(hw);
u32 duration = IWL_MVM_TE_SESSION_PROTECTION_MAX_TIME_MS;
@@ -2823,6 +2824,9 @@ static void iwl_mvm_mac_mgd_prepare_tx(struct 
ieee80211_hw *hw,
if (iwl_mvm_ref_sync(mvm, IWL_MVM_REF_PREPARE_TX))
return;
  
+	if (req_duration > duration)

+   duration = req_duration;
+
mutex_lock(>mutex);
/* Try really hard to protect the session and hear a beacon */
iwl_mvm_protect_session(mvm, vif, duration, min_duration, 500, false);
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 52f36c43f35f..cde1db0f6573 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -3378,6 +3378,8 @@ enum ieee80211_reconfig_type {
   *frame in case that no beacon was heard from the AP/P2P GO.
   *The callback will be called before each transmission and upon return
   *mac80211 will transmit the frame right away.
+ *  If duration is greater than zero, mac80211 hints to the driver the
+ *  duration for which the operation is requested.
   *The callback is optional and can (should!) sleep.
   *
   * @mgd_protect_tdls_discover: Protect a TDLS discovery session. After sending
@@ -3697,7 +3699,8 @@ struct ieee80211_ops {
  u32 sset, u8 *data);
  
  	void	(*mgd_prepare_tx)(struct ieee80211_hw *hw,

- struct ieee80211_vif *vif);
+ struct ieee80211_vif *vif,
+ u16 duration);
  
  	void	(*mgd_protect_tdls_discover)(struct ieee80211_hw *hw,

 struct ieee80211_vif *vif);
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 4d82fe7d627c..8f6998091d26 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -2,6 +2,7 @@
  /*
  * Portions of this file
  * Copyright(c) 2016 Intel Deutschland GmbH
+* Copyright (C) 2018 Intel Corporation
  */
  
  #ifndef __MAC80211_DRIVER_OPS

@@ -813,7 +814,8 @@ drv_allow_buffered_frames(struct ieee80211_local *local,
  }
  
  static inline void drv_mgd_prepare_tx(struct ieee80211_local *local,

- struct ieee80211_sub_if_data *sdata)
+ struct ieee80211_sub_if_data *sdata,
+ u16 duration)
  {
might_sleep();
  
@@ -821,9 +823,9 @@ static inline void drv_mgd_prepare_tx(struct ieee80211_local *local,

Re: [PATCH v2] ath10k: Implement get_expected_throughput callback

[Peter Oh]

On 04/13/2018 06:48 AM, Kalle Valo wrote:

Sven Eckelmann  writes:


But of course, I cannot say much about how the rate control from QCA works and
in which form these information are already available.

If you want to know the average PHY rate then wouldn't it be better to report
the rates to one of the upper layers and let them to the averaging? Similar to
what there already is for NL80211_STA_INFO_CHAIN_SIGNAL
(NL80211_STA_INFO_CHAIN_SIGNAL_AVG) just for NL80211_STA_INFO_TX_BITRATE/
NL80211_STA_INFO_RX_BITRATE. Not sure whether this makes sense or whether
someone has an use-case for it.

Sounds like a good idea, but I don't see it preventing to apply this
patch. We can always change the implementation later as this is just
communication between ath10k and mac80211, right?

I agree with Sven on the usage or expectation of get_expected_throughput 
cabllback.

It's not really ab expected throughput implementation.
However I'm with Kalle about approving this patch as Sven also mentioned 
"here sounds a little bit like in "Our medical doctor would ideally not 
decapitate each patient but we have at least an MD"".
I could improve it once merged since there are more members in 
ath10k_per_peer_tx_stats useful such as succ_bytes, failed_bytes, 
duration, and etc.

Re: [PATCH v2] ath10k: Implement get_expected_throughput callback

[Peter Oh]

Hi Anilkumar,


On 03/27/2018 11:37 PM, Sven Eckelmann wrote:

On Mittwoch, 28. März 2018 11:41:51 CEST ako...@codeaurora.org wrote:
[...]

The rate average and throughput are relative. no?

Can you share the output number from your new function?
It may help us to understand a little bit more how well the new function 
works.


Thanks,
Peter

Re: [PATCH v3 2/3] mac80211: limit wmm params to comply with ETSI requirements

[Peter Oh]

+   if (sdata->vif.type == NL80211_IFTYPE_AP)
+   wmm_ac = >wmm_rule->ap[ac];
+   else
+   wmm_ac = >wmm_rule->client[ac];
+   qparam->cw_min = max_t(u16, qparam->cw_min, wmm_ac->cw_min);
+   qparam->cw_max = max_t(u16, qparam->cw_max, wmm_ac->cw_max);

not min_t() for cw_max?

Thanks,
Peter

Re: [PATCH v3 00/12] *** Add support for wifi QMI client driver ***

[Peter Oh]

Add QMI client driver for Q6 integrated WLAN connectivity subsystem.

Can you give an example which chipset series is Q6 integrated WLAN ?

Thanks,
Peter

Re: [PATCH 1/2] ath10k: Add WMI FWTEST command support

[Peter Oh]

From: Sathishkumar Muruganandam 

This patch adds support for WMI_FWTEST_CMD.
This command is used for setting the wifi parameters.


It's too lack of information in commit message.
You should add such what values are acceptable for which purpose by each 
param_id and param_value to make this changes meaningful to community.


Thanks,
Peter

Re: [PATCH] Revert "ath10k: send (re)assoc peer command when NSS changed"

[Peter Oh]

This reverts commit 55884c045d31a29cf69db8332d1064a1b61dd159.

When Ath10k is in AP mode and an unassociated STA sends a VHT action frame
(Operating Mode Notification for the NSS change) periodically to AP this causes
ath10k to call ath10k_station_assoc() which sends WMI_PEER_ASSOC_CMDID during
NSS update. Over the time (with a certain client it can happen within 15 mins
when there are over 500 of these VHT action frames) continuous calls of
WMI_PEER_ASSOC_CMDID cause firmware to assert due to resource exhaust.

Can you include the FW assert message in this commit?

Thanks,
Peter

Re: [PATCH v3] mac80211: mesh: fix wrong mesh TTL offset calculation

[Peter Oh]

I have patch v4 which fixes the warning, so we can ignore this warning I 
believe.


Thanks,
Peter
On 01/27/2018 01:00 PM, kbuild test robot wrote:

Hi Peter,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on mac80211-next/master]
[also build test ERROR on v4.15-rc9 next-20180126]
[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/peter-oh-bowerswilkins-com/mac80211-mesh-fix-wrong-mesh-TTL-offset-calculation/20180128-042444
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git 
master
config: i386-randconfig-x070-201804 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
 # save the attached .config to linux build tree
 make ARCH=i386

All errors (new ones prefixed by >>):

net//mac80211/mesh.c: In function 'mesh_fwd_csa_frame':

net//mac80211/mesh.c:1271:40: error: decrement of member 'mesh_ttl' in 
read-only object

  elems->mesh_chansw_params_ie->mesh_ttl--;
^~

net//mac80211/mesh.c:1272:43: error: assignment of member 'mesh_flags' in 
read-only object

  elems->mesh_chansw_params_ie->mesh_flags &=
   ^~

vim +/mesh_ttl +1271 net//mac80211/mesh.c

   1256 
   1257 static int mesh_fwd_csa_frame(struct ieee80211_sub_if_data *sdata,
   1258struct ieee80211_mgmt *mgmt, size_t len,
   1259struct ieee802_11_elems *elems)
   1260 {
   1261 struct ieee80211_mgmt *mgmt_fwd;
   1262 struct sk_buff *skb;
   1263 struct ieee80211_local *local = sdata->local;
   1264 
   1265 skb = dev_alloc_skb(local->tx_headroom + len);
   1266 if (!skb)
   1267 return -ENOMEM;
   1268 skb_reserve(skb, local->tx_headroom);
   1269 mgmt_fwd = skb_put(skb, len);
   1270 

1271elems->mesh_chansw_params_ie->mesh_ttl--;
1272elems->mesh_chansw_params_ie->mesh_flags &=

   1273 ~WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR;
   1274 
   1275 memcpy(mgmt_fwd, mgmt, len);
   1276 eth_broadcast_addr(mgmt_fwd->da);
   1277 memcpy(mgmt_fwd->sa, sdata->vif.addr, ETH_ALEN);
   1278 memcpy(mgmt_fwd->bssid, sdata->vif.addr, ETH_ALEN);
   1279 
   1280 ieee80211_tx_skb(sdata, skb);
   1281 return 0;
   1282 }
   1283 

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

[PATCH v4] mac80211: mesh: fix wrong mesh TTL offset calculation

[peter . oh]

From: Peter Oh <peter...@bowerswilkins.com>

mesh TTL offset in Mesh Channel Switch Parameters element depends on
not only Secondary Channel Offset element, but also affected by
HT Control field and Wide Bandwidth Channel Switch element.
So use element structure to manipulate mesh channel swich param IE
after removing its constant attribution to correct the miscalculation.

Signed-off-by: Peter Oh <peter...@bowerswilkins.com>
---
 net/mac80211/ieee80211_i.h |  2 +-
 net/mac80211/mesh.c| 17 ++---
 2 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 2690002..ae9c33c 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1467,7 +1467,7 @@ struct ieee802_11_elems {
const struct ieee80211_timeout_interval_ie *timeout_int;
const u8 *opmode_notif;
const struct ieee80211_sec_chan_offs_ie *sec_chan_offs;
-   const struct ieee80211_mesh_chansw_params_ie *mesh_chansw_params_ie;
+   struct ieee80211_mesh_chansw_params_ie *mesh_chansw_params_ie;
const struct ieee80211_bss_max_idle_period_ie *max_idle_period_ie;
 
/* length of them, respectively */
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 73ac607..6a381cb 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1255,13 +1255,12 @@ int ieee80211_mesh_csa_beacon(struct 
ieee80211_sub_if_data *sdata,
 }
 
 static int mesh_fwd_csa_frame(struct ieee80211_sub_if_data *sdata,
-  struct ieee80211_mgmt *mgmt, size_t len)
+  struct ieee80211_mgmt *mgmt, size_t len,
+  struct ieee802_11_elems *elems)
 {
struct ieee80211_mgmt *mgmt_fwd;
struct sk_buff *skb;
struct ieee80211_local *local = sdata->local;
-   u8 *pos = mgmt->u.action.u.chan_switch.variable;
-   size_t offset_ttl;
 
skb = dev_alloc_skb(local->tx_headroom + len);
if (!skb)
@@ -1269,13 +1268,9 @@ static int mesh_fwd_csa_frame(struct 
ieee80211_sub_if_data *sdata,
skb_reserve(skb, local->tx_headroom);
mgmt_fwd = skb_put(skb, len);
 
-   /* offset_ttl is based on whether the secondary channel
-* offset is available or not. Subtract 1 from the mesh TTL
-* and disable the initiator flag before forwarding.
-*/
-   offset_ttl = (len < 42) ? 7 : 10;
-   *(pos + offset_ttl) -= 1;
-   *(pos + offset_ttl + 1) &= ~WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR;
+   elems->mesh_chansw_params_ie->mesh_ttl--;
+   elems->mesh_chansw_params_ie->mesh_flags &=
+   ~WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR;
 
memcpy(mgmt_fwd, mgmt, len);
eth_broadcast_addr(mgmt_fwd->da);
@@ -1323,7 +1318,7 @@ static void mesh_rx_csa_frame(struct 
ieee80211_sub_if_data *sdata,
 
/* forward or re-broadcast the CSA frame */
if (fwd_csa) {
-   if (mesh_fwd_csa_frame(sdata, mgmt, len) < 0)
+   if (mesh_fwd_csa_frame(sdata, mgmt, len, ) < 0)
mcsa_dbg(sdata, "Failed to forward the CSA frame");
}
 }
-- 
2.7.4

Re: [PATCH v3] mac80211: mesh: fix wrong mesh TTL offset calculation

[Peter Oh]

Ignore the patch below for now. Just noticed mesh_chansw_params_ie is 
constance.


will come up with new approach.


Thanks,

Peter


On 01/24/2018 05:16 PM, peter...@bowerswilkins.com wrote:

From: Peter Oh <peter...@bowerswilkins.com>

mesh TTL offset in Mesh Channel Switch Parameters element depends on
not only Secondary Channel Offset element, but also affected by
HT Control field and Wide Bandwidth Channel Switch element.
Use element structure to correct the miscalculation.

Signed-off-by: Peter Oh <peter...@bowerswilkins.com>
---
  net/mac80211/mesh.c | 17 ++---
  1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 73ac607..6a381cb 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1255,13 +1255,12 @@ int ieee80211_mesh_csa_beacon(struct 
ieee80211_sub_if_data *sdata,
  }
  
  static int mesh_fwd_csa_frame(struct ieee80211_sub_if_data *sdata,

-  struct ieee80211_mgmt *mgmt, size_t len)
+  struct ieee80211_mgmt *mgmt, size_t len,
+  struct ieee802_11_elems *elems)
  {
struct ieee80211_mgmt *mgmt_fwd;
struct sk_buff *skb;
struct ieee80211_local *local = sdata->local;
-   u8 *pos = mgmt->u.action.u.chan_switch.variable;
-   size_t offset_ttl;
  
  	skb = dev_alloc_skb(local->tx_headroom + len);

if (!skb)
@@ -1269,13 +1268,9 @@ static int mesh_fwd_csa_frame(struct 
ieee80211_sub_if_data *sdata,
skb_reserve(skb, local->tx_headroom);
mgmt_fwd = skb_put(skb, len);
  
-	/* offset_ttl is based on whether the secondary channel

-* offset is available or not. Subtract 1 from the mesh TTL
-* and disable the initiator flag before forwarding.
-*/
-   offset_ttl = (len < 42) ? 7 : 10;
-   *(pos + offset_ttl) -= 1;
-   *(pos + offset_ttl + 1) &= ~WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR;
+   elems->mesh_chansw_params_ie->mesh_ttl--;
+   elems->mesh_chansw_params_ie->mesh_flags &=
+   ~WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR;
  
  	memcpy(mgmt_fwd, mgmt, len);

eth_broadcast_addr(mgmt_fwd->da);
@@ -1323,7 +1318,7 @@ static void mesh_rx_csa_frame(struct 
ieee80211_sub_if_data *sdata,
  
  	/* forward or re-broadcast the CSA frame */

if (fwd_csa) {
-   if (mesh_fwd_csa_frame(sdata, mgmt, len) < 0)
+   if (mesh_fwd_csa_frame(sdata, mgmt, len, ) < 0)
mcsa_dbg(sdata, "Failed to forward the CSA frame");
}
  }

[PATCH v3] mac80211: mesh: fix wrong mesh TTL offset calculation

[peter . oh]

From: Peter Oh <peter...@bowerswilkins.com>

mesh TTL offset in Mesh Channel Switch Parameters element depends on
not only Secondary Channel Offset element, but also affected by
HT Control field and Wide Bandwidth Channel Switch element.
Use element structure to correct the miscalculation.

Signed-off-by: Peter Oh <peter...@bowerswilkins.com>
---
 net/mac80211/mesh.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 73ac607..6a381cb 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1255,13 +1255,12 @@ int ieee80211_mesh_csa_beacon(struct 
ieee80211_sub_if_data *sdata,
 }
 
 static int mesh_fwd_csa_frame(struct ieee80211_sub_if_data *sdata,
-  struct ieee80211_mgmt *mgmt, size_t len)
+  struct ieee80211_mgmt *mgmt, size_t len,
+  struct ieee802_11_elems *elems)
 {
struct ieee80211_mgmt *mgmt_fwd;
struct sk_buff *skb;
struct ieee80211_local *local = sdata->local;
-   u8 *pos = mgmt->u.action.u.chan_switch.variable;
-   size_t offset_ttl;
 
skb = dev_alloc_skb(local->tx_headroom + len);
if (!skb)
@@ -1269,13 +1268,9 @@ static int mesh_fwd_csa_frame(struct 
ieee80211_sub_if_data *sdata,
skb_reserve(skb, local->tx_headroom);
mgmt_fwd = skb_put(skb, len);
 
-   /* offset_ttl is based on whether the secondary channel
-* offset is available or not. Subtract 1 from the mesh TTL
-* and disable the initiator flag before forwarding.
-*/
-   offset_ttl = (len < 42) ? 7 : 10;
-   *(pos + offset_ttl) -= 1;
-   *(pos + offset_ttl + 1) &= ~WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR;
+   elems->mesh_chansw_params_ie->mesh_ttl--;
+   elems->mesh_chansw_params_ie->mesh_flags &=
+   ~WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR;
 
memcpy(mgmt_fwd, mgmt, len);
eth_broadcast_addr(mgmt_fwd->da);
@@ -1323,7 +1318,7 @@ static void mesh_rx_csa_frame(struct 
ieee80211_sub_if_data *sdata,
 
/* forward or re-broadcast the CSA frame */
if (fwd_csa) {
-   if (mesh_fwd_csa_frame(sdata, mgmt, len) < 0)
+   if (mesh_fwd_csa_frame(sdata, mgmt, len, ) < 0)
mcsa_dbg(sdata, "Failed to forward the CSA frame");
}
 }
-- 
2.7.4

[PATCH v2] mac80211: mesh: fix wrong mesh TTL offset calculation

[peter . oh]

From: Peter Oh <peter...@bowerswilkins.com>

mesh TTL offset in Mesh Channel Switch Parameters element depends on
not only Secondary Channel Offset element, but also affected by
HT Control field and Wide Bandwidth Channel Switch element.
Hence take those values place in.

Signed-off-by: Peter Oh <peter...@bowerswilkins.com>
---
 net/mac80211/mesh.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 73ac607..8c2aaf0 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1255,13 +1255,16 @@ int ieee80211_mesh_csa_beacon(struct 
ieee80211_sub_if_data *sdata,
 }
 
 static int mesh_fwd_csa_frame(struct ieee80211_sub_if_data *sdata,
-  struct ieee80211_mgmt *mgmt, size_t len)
+  struct ieee80211_mgmt *mgmt, size_t len,
+  struct ieee802_11_elems *elems)
 {
struct ieee80211_mgmt *mgmt_fwd;
struct sk_buff *skb;
struct ieee80211_local *local = sdata->local;
u8 *pos = mgmt->u.action.u.chan_switch.variable;
size_t offset_ttl;
+   /* mgmt hdr 24 + csa action 15 without sec offset and wide bw */
+   unsigned int basic_hdrlen = 39;
 
skb = dev_alloc_skb(local->tx_headroom + len);
if (!skb)
@@ -1269,11 +1272,17 @@ static int mesh_fwd_csa_frame(struct 
ieee80211_sub_if_data *sdata,
skb_reserve(skb, local->tx_headroom);
mgmt_fwd = skb_put(skb, len);
 
+   if (ieee80211_has_order(mgmt->frame_control))
+   basic_hdrlen += 4;
+
+   if (elems->wide_bw_chansw_ie)
+   basic_hdrlen += 5;
+
/* offset_ttl is based on whether the secondary channel
 * offset is available or not. Subtract 1 from the mesh TTL
 * and disable the initiator flag before forwarding.
 */
-   offset_ttl = (len < 42) ? 7 : 10;
+   offset_ttl = (len > basic_hdrlen) ? 10 : 7;
*(pos + offset_ttl) -= 1;
*(pos + offset_ttl + 1) &= ~WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR;
 
@@ -1323,7 +1332,7 @@ static void mesh_rx_csa_frame(struct 
ieee80211_sub_if_data *sdata,
 
/* forward or re-broadcast the CSA frame */
if (fwd_csa) {
-   if (mesh_fwd_csa_frame(sdata, mgmt, len) < 0)
+   if (mesh_fwd_csa_frame(sdata, mgmt, len, ) < 0)
mcsa_dbg(sdata, "Failed to forward the CSA frame");
}
 }
-- 
2.7.4

[PATCH] mac80211: mesh: fix wrong mesh TTL offset calculation

[peter . oh]

From: Peter Oh <peter...@bowerswilkins.com>

mesh TTL offset in Mesh Channel Switch Parameters element depends on
not only Secondary Channel Offset element, but also affected by
HT Control field and Wide Bandwidth Channel Switch element.
Hence take those values place in.

Signed-off-by: Peter Oh <peter...@bowerswilkins.com>
---
 net/mac80211/mesh.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 73ac607..887b676 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1255,13 +1255,16 @@ int ieee80211_mesh_csa_beacon(struct 
ieee80211_sub_if_data *sdata,
 }
 
 static int mesh_fwd_csa_frame(struct ieee80211_sub_if_data *sdata,
-  struct ieee80211_mgmt *mgmt, size_t len)
+  struct ieee80211_mgmt *mgmt, size_t len,
+  struct ieee802_11_elems *elems)
 {
struct ieee80211_mgmt *mgmt_fwd;
struct sk_buff *skb;
struct ieee80211_local *local = sdata->local;
u8 *pos = mgmt->u.action.u.chan_switch.variable;
size_t offset_ttl;
+   /* mgmt hdr 24 + csa action 15 without sec offset and wide bw */
+   unsigned int basic_hdrlen = 39;
 
skb = dev_alloc_skb(local->tx_headroom + len);
if (!skb)
@@ -1269,11 +1272,17 @@ static int mesh_fwd_csa_frame(struct 
ieee80211_sub_if_data *sdata,
skb_reserve(skb, local->tx_headroom);
mgmt_fwd = skb_put(skb, len);
 
+   if (ieee80211_has_order(mgmt->frame_control))
+   basic_hdrlen += 4;
+
+   if (elems->wide_bw_chansw_ie)
+   basic_hdrlen += 5;
+
/* offset_ttl is based on whether the secondary channel
 * offset is available or not. Subtract 1 from the mesh TTL
 * and disable the initiator flag before forwarding.
 */
-   offset_ttl = (len < 42) ? 7 : 10;
+   offset_ttl = (len < basic_hdrlen) ? 7 : 10;
*(pos + offset_ttl) -= 1;
*(pos + offset_ttl + 1) &= ~WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR;
 
@@ -1323,7 +1332,7 @@ static void mesh_rx_csa_frame(struct 
ieee80211_sub_if_data *sdata,
 
/* forward or re-broadcast the CSA frame */
if (fwd_csa) {
-   if (mesh_fwd_csa_frame(sdata, mgmt, len) < 0)
+   if (mesh_fwd_csa_frame(sdata, mgmt, len, ) < 0)
mcsa_dbg(sdata, "Failed to forward the CSA frame");
}
 }
-- 
2.7.4

Re: [PATCH] ath10k: unify rx processing in napi_poll

[Peter Oh]

Hi Rajkumar,

I'm wondering if this patch is related to kernel crash due to ath10k napi.

Do you think this patch helps the crash below?

This crash happened ath10k v4.14 (10/04/2017, commit id c09dbd7) + 
3.14.43 kernel backports.



[ 6866.655419] [ cut here ]
[ 6866.659029] kernel BUG at /net/core/dev.c:4301!
[ 6866.666404] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 6866.672206] Modules linked in: asix essedma qca_ssdk ath9k 
ath9k_common ath9k_hw ath10k_pci ath10k_core mac80211 qca_nss_drv 
qca_nss_gmac ath cfg80211 skcipher compat nvram
[ 6866.687576] CPU: 0 PID: 1228 Comm: kworker/0:0 Tainted: GW
3.14.43 #1

[ 6866.694962] Workqueue: events_power_efficient phy_state_machine
[ 6866.700853] task: d88252c0 ti: d8cd2000 task.ti: d8cd2000
[ 6866.706239] PC is at __napi_complete+0x10/0x50
[ 6866.710663] LR is at napi_complete+0x2c/0x34
[ 6866.714919] pc : []lr : []psr: 60050093
[ 6866.714919] sp : d8cd3d88  ip : dfbc5d10  fp : c09dd6e4
[ 6866.726374] r10: dfbc5e88  r9 : 000a04de  r8 : 0001
[ 6866.731582] r7 : 0040  r6 : 0001  r5 : 60050013  r4 : de7a5d60
[ 6866.738092] r3 :   r2 : 0100  r1 : de7a5d60  r0 : de7a5d60
[ 6866.744606] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  
Segment kernel

[ 6866.751982] Control: 10c5387d  Table: 9b4f406a  DAC: 0015
[ 6866.757708]
[ 6866.757708] PC: 0xc06359ec:
[ 6866.761960] 59ec  e8bd8010 e3a1 e8bd8010 e1a3 e8bd8010 
e3a0 e8bd8010 c08b1fb9
[ 6866.770119] 5a0c  c089e498 c0888b00 e5903120 e3130001 012fff1e 
e92d4037 e1a04000 e3a05000
[ 6866.778280] 5a2c  e1a0200d e1a01000 e3a4 e58d5004 ebfff5f2 
e3a030d0 e1a02005 e1a01004
[ 6866.786439] 5a4c  e3a00010 eb003b52 e28dd00c e8bd8030 e5903008 
e1a01000 e3130001 1a00
[ 6866.794599] 5a6c  e7f001f2 e590001c e350 0a00 e7f001f2 
e891000c e5823004 e5832000
[ 6866.802759] 5a8c  e59f2010 e59f3010 e881000c f57ff05b e2811008 
eaef51ef 00100100 00200200
[ 6866.810919] 5aac  e92d4070 e1a04000 e5903110 e5932020 e352 
0a13 e2803f4d e1d1c0b0
[ 6866.819078] 5acc  e1d330b0 e15c0003 1a10 e590302c e3130002 
0a0f e12fff32 e2505000

[ 6866.827239]
[ 6866.827239] LR: 0xc0636690:
[ 6866.831490] 6690  e59f7048 e1a04003 e350 0a0d e356 
e5804000 0a03 e5973000
[ 6866.839651] 66b0  e590202c e1520003 08bd81f0 e5908004 ebb4 
e5953010 e1a8 e2433001
[ 6866.847810] 66d0  e5853010 eaef e585001c e8bd81f0 c09ce0c0 
e5901008 e7e01151 e351
[ 6866.855970] 66f0  112fff1e e92d4070 e1a04000 ebd9 e10f5000 
f10c0080 e1a4 ebfffcd2
[ 6866.864130] 6710  e121f005 e8bd8070 e92d4ff0 e1a04001 e1d1b6b6 
e3a09000 e5911014 e24dd014
[ 6866.872289] 6730  e1c127d0 e2028901 e1983009 1a01 e3a05003 
eaa4 e59430a8 e1d320b2
[ 6866.880450] 6750  e352 1af9 e5937008 e357 1af6 
e3003136 e590501c e19180b3
[ 6866.888609] 6770  e1a06000 e5949078 e355 0a37 e5953078 
e1c572b4 e1590003 15c5702a

[ 6866.896771]
[ 6866.896771] SP: 0xd8cd3d08:
[ 6866.901023] 3d08  d8cd3d34 c024ed60 0001 de7fcb00 de7fc300 
de7a41a4  0004
[ 6866.909182] 3d28  d8cd2000 c0635a70  c0209858  
c02095ec de7a5d60 de7a5d60
[ 6866.917342] 3d48  0100  de7a5d60 60050013 0001 
0040 0001 000a04de
[ 6866.925501] 3d68  dfbc5e88 c09dd6e4 dfbc5d10 d8cd3d88 c0636710 
c0635a6c 60050093 
[ 6866.933661] 3d88  de7a15e0 de7a5d60 0001 bf1a38f8 de7a5d60 
dfbc5e80 0001 0040
[ 6866.941821] 3da8  012c c0637328 c09ce08c c09ce0c0 c0637280 
4003 d8cd2020 0008
[ 6866.949981] 3dc8  c0a34c80 000a c09ce08c d8cd2000 0100 
c022fcac 0080 0001
[ 6866.958141] 3de8  c09dd5f0 04208060 000a04dd  0004 
c09ce0c0 c09ce080 0003

[ 6866.966304]
[ 6866.966304] IP: 0xdfbc5c90:
[ 6866.970554] 5c90  c09ddbd0 df49a1c0 000a04e3  c50baadf 
063e acc26c21 05c9
[ 6866.978713] 5cb0   df40dc00 df484b80 03d3  
  0003
[ 6866.986872] 5cd0  dfbc5cd0 dfbc5cd0 c0254544 dfbc5840  
 0001 d882531c
[ 6866.995033] 5cf0  d882405c  01b8e867  bb4b1900 
063e  
[ 6867.003192] 5d10  000dbc97  0007a120  18493ebe 
0075 000a05e7 fef9
[ 6867.011353] 5d30     c024aef0 dfbc5840 
 dfbc5d48 
[ 6867.019512] 5d50       
 c024bee8 dfbc41f0
[ 6867.027672] 5d70    db651a54  2846 
b728 acc26c21 05c9

[ 6867.035833]
[ 6867.035833] FP: 0xc09dd664:
[ 6867.040084] d664       
  
[ 6867.048245] d684       
  
[ 6867.056404] d6a4       
  
[ 6867.064564] d6c4       
  
[ 6867.072723] 

Re: ath10k: Fix reported HT MCS rates with NSS > 1

[Peter Oh]

On 11/06/2017 01:02 AM, Sven Eckelmann wrote:

On Montag, 6. November 2017 09:28:42 CET Sebastian Gottschall wrote:

Am 06.11.2017 um 09:23 schrieb Sven Eckelmann:

On Sonntag, 5. November 2017 10:22:22 CET Sebastian Gottschall wrote:

the assumption made in this patch is obviously wrong (at least for more
recent firmwares and 9984)
my log is flooded with messages like
[208802.803537] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[208805.108515] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[208821.747621] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[208822.516599] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[208841.257780] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats

[...]

This patch only splits WMI_RATE_PREAMBLE_HT & WMI_RATE_PREAMBLE_VHT. And for
WMI_RATE_PREAMBLE_HT (*not VHT*), it uses a slightly different approach. But
the WMI_RATE_PREAMBLE_VHT part (which you see in your logs) is basically
untouched.

then a question follows up. is this check really neccessary?

Until we find out what the heck VHT MCS 15 should mean in this context - maybe.
But to the message - no, the message is most likely not necessary for each
received "invalid" peer tx stat.
This validation check expects peer tx stat packets from FW contain 
reasonable values and gives warning if values are different from 
expectation. The problem comes from the assumption that "it always 
contains reasonable stat value" which is wrong at least based on my 
results. For instance, the reason MCS == 15 is because all 4 bits of mcs 
potion set to 1, not because FW really sets it to 15 intentionally. when 
the mcs potion bits are set to all 1s, the other bits such as nss are 
also set to all 1s.

Hence it looks FW passed totally invalid stat info to me.
I don't have preference on whether it's better to split VHT and HT check 
or not, but it is more appropriate to change that warning level to debug 
level.

Re: [PATCH V6 0/5] Add TDLS feature for ath10k

[Peter Oh]

On 10/15/2017 11:00 PM, yint...@qti.qualcomm.com wrote:

From: Yingying Tang 

This patchset is for Rome PCIE chip, it will not affect other hardware

Please add your patchset history here until V6.
That's what cover letter is supposed to have.

Yingying Tang (5):
   mac80211: Enable TDLS peer buffer STA feature
   ath10k: Enable TDLS peer buffer STA feature
   ath10k: Enable TDLS peer inactivity detection
   ath10k: Avoid to set WEP key for TDLS peer
   ath10k: Fix TDLS peer TX data failure issue on encryped AP

  drivers/net/wireless/ath/ath10k/mac.c |9 -
  drivers/net/wireless/ath/ath10k/wmi-tlv.c |   55 +
  drivers/net/wireless/ath/ath10k/wmi-tlv.h |9 +
  drivers/net/wireless/ath/ath10k/wmi.h |1 +
  include/net/mac80211.h|4 +++
  net/mac80211/tdls.c   |5 ++-
  6 files changed, 81 insertions(+), 2 deletions(-)

Re: [PATCH] ieee80211: update public action codes

[Peter Oh]

On 06/28/2017 01:16 PM, Arend van Spriel wrote:

On 28-06-17 00:07, peter...@bowerswilkins.com wrote:

From: Peter Oh <peter...@bowerswilkins.com>

Update Public Action field values as updated in IEEE Std 802.11-2016,
so that modules/drivers can refer it.

Hi Peter,

I am pretty sure there are a lot of other definitions in the 802.11 spec
that are not in a linux header file. So are you planning on submitting
driver patches using the added definitions. Stuff is mostly added as needed.
I have extra patches that uses the new values, but doubt if it's fit to 
be upstream.

Regards,
Arend

[PATCH] ieee80211: update public action codes

[peter . oh]

From: Peter Oh <peter...@bowerswilkins.com>

Update Public Action field values as updated in IEEE Std 802.11-2016,
so that modules/drivers can refer it.

Signed-off-by: Peter Oh <peter...@bowerswilkins.com>
---
 include/linux/ieee80211.h | 35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 6903335..91a1145 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -2113,10 +2113,43 @@ enum ieee80211_key_len {
 
 #define PMK_MAX_LEN48
 
-/* Public action codes */
+/* Public action codes (IEEE Std 802.11-2016, 9.6.8.1, Table 9-307) */
 enum ieee80211_pub_actioncode {
+   WLAN_PUB_ACTION_20_40_BSS_COEX = 0,
+   WLAN_PUB_ACTION_DSE_ENABLEMENT = 1,
+   WLAN_PUB_ACTION_DSE_DEENABLEMENT = 2,
+   WLAN_PUB_ACTION_DSE_REG_LOC_ANN = 3,
WLAN_PUB_ACTION_EXT_CHANSW_ANN = 4,
+   WLAN_PUB_ACTION_DSE_MSMT_REQ = 5,
+   WLAN_PUB_ACTION_DSE_MSMT_RESP = 6,
+   WLAN_PUB_ACTION_MSMT_PILOT = 7,
+   WLAN_PUB_ACTION_DSE_PC = 8,
+   WLAN_PUB_ACTION_VENDOR_SPECIFIC = 9,
+   WLAN_PUB_ACTION_GAS_INITIAL_REQ = 10,
+   WLAN_PUB_ACTION_GAS_INITIAL_RESP = 11,
+   WLAN_PUB_ACTION_GAS_COMEBACK_REQ = 12,
+   WLAN_PUB_ACTION_GAS_COMEBACK_RESP = 13,
WLAN_PUB_ACTION_TDLS_DISCOVER_RES = 14,
+   WLAN_PUB_ACTION_LOC_TRACK_NOTI = 15,
+   WLAN_PUB_ACTION_QAB_REQUEST_FRAME = 16,
+   WLAN_PUB_ACTION_QAB_RESPONSE_FRAME = 17,
+   WLAN_PUB_ACTION_QMF_POLICY = 18,
+   WLAN_PUB_ACTION_QMF_POLICY_CHANGE = 19,
+   WLAN_PUB_ACTION_QLOAD_REQUEST = 20,
+   WLAN_PUB_ACTION_QLOAD_REPORT = 21,
+   WLAN_PUB_ACTION_HCCA_TXOP_ADVERT = 22,
+   WLAN_PUB_ACTION_HCCA_TXOP_RESPONSE = 23,
+   WLAN_PUB_ACTION_PUBLIC_KEY = 24,
+   WLAN_PUB_ACTION_CHANNEL_AVAIL_QUERY = 25,
+   WLAN_PUB_ACTION_CHANNEL_SCHEDULE_MGMT = 26,
+   WLAN_PUB_ACTION_CONTACT_VERI_SIGNAL = 27,
+   WLAN_PUB_ACTION_GDD_ENABLEMENT_REQ = 28,
+   WLAN_PUB_ACTION_GDD_ENABLEMENT_RESP = 29,
+   WLAN_PUB_ACTION_NETWORK_CHANNEL_CONTROL = 30,
+   WLAN_PUB_ACTION_WHITE_SPACE_MAP_ANN = 31,
+   WLAN_PUB_ACTION_FTM_REQUEST = 32,
+   WLAN_PUB_ACTION_FTM = 33,
+   WLAN_PUB_ACTION_FILS_DISCOVERY = 34,
 };
 
 /* TDLS action codes */
-- 
2.7.4

Re: [RFC v2 06/10] ath10k: htt: High latency RX support

[Peter Oh]

On 06/12/2017 08:03 AM, Erik Stromdahl wrote:

Special HTT RX handling for high latency interfaces.

Since no DMA physical addresses are used in the RX ring
config message (this is not supported by the high latency
devices), no RX ring is allocated.
All RX skb's are allocated by the driver and passed directly
to mac80211 in the HTT RX indication handler.

A nice side effect of this is that no huge buffer will be
allocated with dma_alloc_coherent. On embedded systems with
limited memory resources, the allocation of the RX ring is
prone to fail.

Some tweaks made to "make it work":

Removal of protected bit in 802.11 header frame control field.
The chipset seems to do hw decryption but the frame_control
protected bit is still set.

This is necessary for mac80211 not to drop the frame.

Signed-off-by: Erik Stromdahl 
---

+static void ath10k_htt_rx_proc_rx_ind_ll(struct ath10k_htt *htt,
+struct htt_rx_indication *rx)
  {
struct ath10k *ar = htt->ar;
struct htt_rx_indication_mpdu_range *mpdu_ranges;
@@ -2356,7 +2442,12 @@ bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, 
struct sk_buff *skb)
break;
}
case HTT_T2H_MSG_TYPE_RX_IND:
-   ath10k_htt_rx_proc_rx_ind(htt, >rx_ind);
+   if (ar->is_high_latency)
Can we use function pointers at initial time to avoid condition check at 
hot path?

I'm afraid adding more lines on hot path.

+   return ath10k_htt_rx_proc_rx_ind_hl(htt,
+   >rx_ind_hl,
+   skb);
+   else
+   ath10k_htt_rx_proc_rx_ind_ll(htt, >rx_ind);
break;
case HTT_T2H_MSG_TYPE_PEER_MAP: {
struct htt_peer_map_event ev = {

Re: [RFC v2 05/10] ath10k: htt: High latency TX support

[Peter Oh]

On 06/12/2017 08:03 AM, Erik Stromdahl wrote:

Add HTT TX function for HL interfaces.
Intended for SDIO and USB.

Signed-off-by: Erik Stromdahl 
---

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 48418f9..c5fd803 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3572,7 +3572,10 @@ static int ath10k_mac_tx_submit(struct ath10k *ar,
  
  	switch (txpath) {

case ATH10K_MAC_TX_HTT:
-   ret = ath10k_htt_tx(htt, txmode, skb);
+   if (ar->is_high_latency)
Can we use function pointers at initial time to avoid condition check at 
hot path?

I'm afraid adding more lines on hot path.

+   ret = ath10k_htt_tx_hl(htt, txmode, skb);
+   else
+   ret = ath10k_htt_tx_ll(htt, txmode, skb);
break;
case ATH10K_MAC_TX_HTT_MGMT:
ret = ath10k_htt_mgmt_tx(htt, skb);

Re: [PATCH 0/3] *** Mesh Path Selection Metric Calculation ***

[Peter Oh]

where is 2/3 ?
On 06/20/2016 06:00 AM, Maxim Altshul wrote:
> Hi All,
> This patch series focuses on metric calculation that
> occurs during the path selection phase of a mesh network.
>
> During the path selection phase, the mesh hwmp module
> performs metric calculations, that take as parameters
> the last TX rate that was used for a specific link,
> and the packet error rate.
>
> These parameters should be reported by the FW to the driver
> constantly for the mechanism to work properly.
>
> In case that a vendor offloads the rate control mechanism
> to the FW, these parameters will be rarely updated,
> or updated incorrectly.
>
> This situation causes the mesh hwmp module to calculate incorrect
> metrics and as a consequence, not to choose the best paths possible.
>
>
> This patch series is divided to three patches and does the following:
>
> 1. Modifies mesh hwmp module and allows vendors that offload the
> rate control mechanism to their FW, to report last TX rates and PER
> to the mesh hwmp module by using an existing op called
> get_expected_throughput.
> In case that a vendor does not implement the op, all previous
> functionality still applies.
>
> 2. Implements the opcode and the mechanism that reports the rates
> in TI driver.
>
> Maxim Altshul (3):
>   wlcore/wl18xx: Add functionality to accept TX rate per link
>   wlcore: Add support for get_expected_throughput opcode
>   mac80211: mesh: Add support for HW RC implementation
>
>  drivers/net/wireless/ti/wl18xx/main.c |  4 
>  drivers/net/wireless/ti/wl18xx/tx.c   | 22 ++
>  drivers/net/wireless/ti/wl18xx/wl18xx.h   |  6 +-
>  drivers/net/wireless/ti/wlcore/main.c | 16 
>  drivers/net/wireless/ti/wlcore/rx.c   |  7 +++
>  drivers/net/wireless/ti/wlcore/wlcore_i.h | 13 +
>  net/mac80211/mesh_hwmp.c  | 23 +++
>  7 files changed, 78 insertions(+), 13 deletions(-)
>

--
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/3] ath10k: add a support of set_tsf on vdev interface

[Peter Oh]

10.2.4 and 10.4 firmware has introduced new function to
set TSF via vdev parameter.
set_tsf function can be used to shift TBTT that will help
avoid its clockdrift which happens when beacons are collided.

Peter Oh (3):
  ath10k: add a support of set_tsf on vdev interface
  ath10k: update 10.4 WMI vdev parameters
  ath10k: enable set_tsf vdev command to WMI 10.4

 drivers/net/wireless/ath/ath10k/mac.c | 27 +++
 drivers/net/wireless/ath/ath10k/wmi-tlv.c |  1 +
 drivers/net/wireless/ath/ath10k/wmi.c |  4 
 drivers/net/wireless/ath/ath10k/wmi.h |  8 
 4 files changed, 40 insertions(+)

-- 
1.9.1

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

[PATCH 1/3] ath10k: add a support of set_tsf on vdev interface

[Peter Oh]

10.2.4.70.24 firmware introduces new feature to set TSF
via vdev parameter, hence implement relevant function.
set_tsf function can be used to shift TBTT that will
help avoid its clockdrift which happens when beacons
are collided.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 27 +++
 drivers/net/wireless/ath/ath10k/wmi-tlv.c |  1 +
 drivers/net/wireless/ath/ath10k/wmi.c |  4 
 drivers/net/wireless/ath/ath10k/wmi.h |  2 ++
 4 files changed, 34 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 20d72e2..595cd96 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6796,6 +6796,32 @@ static u64 ath10k_get_tsf(struct ieee80211_hw *hw, 
struct ieee80211_vif *vif)
return 0;
 }
 
+static void ath10k_set_tsf(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
+   u64 tsf)
+{
+   struct ath10k *ar = hw->priv;
+   struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+   u32 tsf_offset, vdev_param = ar->wmi.vdev_param->set_tsf;
+   int ret;
+
+   /* Workaround:
+*
+* Given tsf argument is entire TSF value, but firmware accepts
+* only TSF offset to current TSF.
+*
+* get_tsf function is used to get offset value, however since
+* ath10k_get_tsf is not implemented properly, it will return 0 always.
+* Luckily all the caller functions to set_tsf, as of now, also rely on
+* get_tsf function to get entire tsf value such get_tsf() + tsf_delta,
+* final tsf offset value to firmware will be arithmetically correct.
+*/
+   tsf_offset = tsf - ath10k_get_tsf(hw, vif);
+   ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
+   vdev_param, tsf_offset);
+   if (ret && ret != -EOPNOTSUPP)
+   ath10k_warn(ar, "failed to set tsf offset: %d\n", ret);
+}
+
 static int ath10k_ampdu_action(struct ieee80211_hw *hw,
   struct ieee80211_vif *vif,
   struct ieee80211_ampdu_params *params)
@@ -7252,6 +7278,7 @@ static const struct ieee80211_ops ath10k_ops = {
.set_bitrate_mask   = ath10k_mac_op_set_bitrate_mask,
.sta_rc_update  = ath10k_sta_rc_update,
.get_tsf= ath10k_get_tsf,
+   .set_tsf= ath10k_set_tsf,
.ampdu_action   = ath10k_ampdu_action,
.get_et_sset_count  = ath10k_debug_get_et_sset_count,
.get_et_stats   = ath10k_debug_get_et_stats,
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c 
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 1085932..e09337e 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -3409,6 +3409,7 @@ static struct wmi_vdev_param_map wmi_tlv_vdev_param_map = 
{
.meru_vc = WMI_VDEV_PARAM_UNSUPPORTED,
.rx_decap_type = WMI_VDEV_PARAM_UNSUPPORTED,
.bw_nss_ratemask = WMI_VDEV_PARAM_UNSUPPORTED,
+   .set_tsf = WMI_VDEV_PARAM_UNSUPPORTED,
 };
 
 static const struct wmi_ops wmi_tlv_ops = {
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index f7ec65f..db3e9a4 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -781,6 +781,7 @@ static struct wmi_vdev_param_map wmi_vdev_param_map = {
.meru_vc = WMI_VDEV_PARAM_UNSUPPORTED,
.rx_decap_type = WMI_VDEV_PARAM_UNSUPPORTED,
.bw_nss_ratemask = WMI_VDEV_PARAM_UNSUPPORTED,
+   .set_tsf = WMI_VDEV_PARAM_UNSUPPORTED,
 };
 
 /* 10.X WMI VDEV param map */
@@ -856,6 +857,7 @@ static struct wmi_vdev_param_map wmi_10x_vdev_param_map = {
.meru_vc = WMI_VDEV_PARAM_UNSUPPORTED,
.rx_decap_type = WMI_VDEV_PARAM_UNSUPPORTED,
.bw_nss_ratemask = WMI_VDEV_PARAM_UNSUPPORTED,
+   .set_tsf = WMI_VDEV_PARAM_UNSUPPORTED,
 };
 
 static struct wmi_vdev_param_map wmi_10_2_4_vdev_param_map = {
@@ -930,6 +932,7 @@ static struct wmi_vdev_param_map wmi_10_2_4_vdev_param_map 
= {
.meru_vc = WMI_VDEV_PARAM_UNSUPPORTED,
.rx_decap_type = WMI_VDEV_PARAM_UNSUPPORTED,
.bw_nss_ratemask = WMI_VDEV_PARAM_UNSUPPORTED,
+   .set_tsf = WMI_10X_VDEV_PARAM_TSF_INCREMENT,
 };
 
 static struct wmi_vdev_param_map wmi_10_4_vdev_param_map = {
@@ -1005,6 +1008,7 @@ static struct wmi_vdev_param_map wmi_10_4_vdev_param_map 
= {
.meru_vc = WMI_10_4_VDEV_PARAM_MERU_VC,
.rx_decap_type = WMI_10_4_VDEV_PARAM_RX_DECAP_TYPE,
.bw_nss_ratemask = WMI_10_4_VDEV_PARAM_BW_NSS_RATEMASK,
+   .set_tsf = WMI_VDEV_PARAM_UNSUPPORTED,
 };
 
 static struct wmi_pdev_param_map wmi_pdev_param_map = {
diff --git a/drivers/net/wireless/ath/ath1

[PATCH 2/3] ath10k: update 10.4 WMI vdev parameters

[Peter Oh]

Update 10.4 WMI vdev param to sync to current 10.4 firmware
as of 2/23/2016.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 8225d90..e10df2e 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4957,6 +4957,12 @@ enum wmi_10_4_vdev_param {
WMI_10_4_VDEV_PARAM_MERU_VC,
WMI_10_4_VDEV_PARAM_RX_DECAP_TYPE,
WMI_10_4_VDEV_PARAM_BW_NSS_RATEMASK,
+   WMI_10_4_VDEV_PARAM_SENSOR_AP,
+   WMI_10_4_VDEV_PARAM_BEACON_RATE,
+   WMI_10_4_VDEV_PARAM_DTIM_ENABLE_CTS,
+   WMI_10_4_VDEV_PARAM_STA_KICKOUT,
+   WMI_10_4_VDEV_PARAM_CAPABILITIES,
+   WMI_10_4_VDEV_PARAM_TSF_INCREMENT,
 };
 
 #define WMI_VDEV_PARAM_TXBF_SU_TX_BFEE BIT(0)
-- 
1.9.1

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

[PATCH 3/3] ath10k: enable set_tsf vdev command to WMI 10.4

[Peter Oh]

10.4 firmware has addeded set_tsf vdev parameter,
hence enable it.
set_tsf function can be used to shift TBTT that will
help avoid its clockdrift which happens when beacons
are collided.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index db3e9a4..e8d9a3e 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1008,7 +1008,7 @@ static struct wmi_vdev_param_map wmi_10_4_vdev_param_map 
= {
.meru_vc = WMI_10_4_VDEV_PARAM_MERU_VC,
.rx_decap_type = WMI_10_4_VDEV_PARAM_RX_DECAP_TYPE,
.bw_nss_ratemask = WMI_10_4_VDEV_PARAM_BW_NSS_RATEMASK,
-   .set_tsf = WMI_VDEV_PARAM_UNSUPPORTED,
+   .set_tsf = WMI_10_4_VDEV_PARAM_TSF_INCREMENT,
 };
 
 static struct wmi_pdev_param_map wmi_pdev_param_map = {
-- 
1.9.1

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

Re: [PATCH v2] ath10k: parse Rx MAC timestamp in mgmt frame for FW 10.4

[Peter Oh]

On 03/22/2016 04:14 PM, kbuild test robot wrote:

Hi Peter,

[auto build test WARNING on wireless-drivers-next/master]
[also build test WARNING on v4.5 next-20160322]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Peter-Oh/ath10k-parse-Rx-MAC-timestamp-in-mgmt-frame-for-FW-10-4/20160323-064843
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: x86_64-randconfig-x000-201612 (attached as .config)
reproduce:
 # save the attached .config to linux build tree
 make ARCH=x86_64

All warnings (new ones prefixed by >>):

In file included from include/linux/linkage.h:4:0,
 from include/linux/kernel.h:6,
 from include/linux/skbuff.h:17,
 from drivers/net/wireless/ath/ath10k/wmi.c:18:
drivers/net/wireless/ath/ath10k/wmi.c: In function 
'ath10k_wmi_10_4_op_pull_mgmt_rx_ev':
drivers/net/wireless/ath/ath10k/wmi.c:2236:33: error: 
'WMI_RX_STATUS_EXT_INFO' undeclared (first use in this function)
it seems the warning is false report. I could see WMI_RX_STATUS_EXT_INFO 
is defined in wmi.h.
Moreover this check command doesn't claim any warning/error make 
M=drivers/net/wireless/ath/ath10k C=2 CF="-D__CHECK_ENDIAN__"

  if (le32_to_cpu(arg->status) & WMI_RX_STATUS_EXT_INFO) {
 ^
include/linux/compiler.h:147:30: note: in definition of macro '__trace_if'
  if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
  ^

drivers/net/wireless/ath/ath10k/wmi.c:2236:2: note: in expansion of macro 'if'

  if (le32_to_cpu(arg->status) & WMI_RX_STATUS_EXT_INFO) {
  ^
drivers/net/wireless/ath/ath10k/wmi.c:2236:33: note: each undeclared 
identifier is reported only once for each function it appears in
  if (le32_to_cpu(arg->status) & WMI_RX_STATUS_EXT_INFO) {
 ^
include/linux/compiler.h:147:30: note: in definition of macro '__trace_if'
  if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
  ^

drivers/net/wireless/ath/ath10k/wmi.c:2236:2: note: in expansion of macro 'if'

  if (le32_to_cpu(arg->status) & WMI_RX_STATUS_EXT_INFO) {
  ^
drivers/net/wireless/ath/ath10k/wmi.c:2239:14: error: 'struct 
wmi_mgmt_rx_ev_arg' has no member named 'ext_info'
   memcpy(>ext_info, ext_info,
  ^
drivers/net/wireless/ath/ath10k/wmi.c:2240:17: error: invalid application 
of 'sizeof' to incomplete type 'struct wmi_mgmt_rx_ext_info'
  sizeof(struct wmi_mgmt_rx_ext_info));
 ^

vim +/if +2236 drivers/net/wireless/ath/ath10k/wmi.c

   2220 
   2221 if (skb->len < pull_len)
    return -EPROTO;
   2223 
   2224 skb_pull(skb, pull_len);
   2225 arg->channel = ev_hdr->channel;
   2226 arg->buf_len = ev_hdr->buf_len;
   2227 arg->status = ev_hdr->status;
   2228 arg->snr = ev_hdr->snr;
   2229 arg->phy_mode = ev_hdr->phy_mode;
   2230 arg->rate = ev_hdr->rate;
   2231 
   2232 msdu_len = __le32_to_cpu(arg->buf_len);
   2233 if (skb->len < msdu_len)
   2234 return -EPROTO;
   2235 

2236if (le32_to_cpu(arg->status) & WMI_RX_STATUS_EXT_INFO) {

   2237 len = ALIGN(le32_to_cpu(arg->buf_len), 4);
   2238 ext_info = (struct wmi_mgmt_rx_ext_info *)(skb->data + 
len);
   2239 memcpy(>ext_info, ext_info,
   2240sizeof(struct wmi_mgmt_rx_ext_info));
   2241 }
   2242 
   2243 /* Make sure bytes added for padding are removed. */
   2244 skb_trim(skb, msdu_len);

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


--
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] ath10k: parse Rx MAC timestamp in mgmt frame for FW 10.4

[Peter Oh]

Check and parse Rx MAC timestamp when firmware sets its flag
to status variable.
10.4 firmware adds it in Rx beacon frame only at this moment.
Drivers and mac80211 may utilize it to detect such clockdrift
or beacon collision and use the result for beacon collision
avoidance.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---

v2:
 * Rebased. no code changes.

 drivers/net/wireless/ath/ath10k/wmi.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 9137566..9977876 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2191,6 +2191,8 @@ static int ath10k_wmi_10_4_op_pull_mgmt_rx_ev(struct 
ath10k *ar,
struct wmi_10_4_mgmt_rx_hdr *ev_hdr;
size_t pull_len;
u32 msdu_len;
+   struct wmi_mgmt_rx_ext_info *ext_info;
+   u32 len;
 
ev = (struct wmi_10_4_mgmt_rx_event *)skb->data;
ev_hdr = >hdr;
@@ -2211,6 +2213,13 @@ static int ath10k_wmi_10_4_op_pull_mgmt_rx_ev(struct 
ath10k *ar,
if (skb->len < msdu_len)
return -EPROTO;
 
+   if (le32_to_cpu(arg->status) & WMI_RX_STATUS_EXT_INFO) {
+   len = ALIGN(le32_to_cpu(arg->buf_len), 4);
+   ext_info = (struct wmi_mgmt_rx_ext_info *)(skb->data + len);
+   memcpy(>ext_info, ext_info,
+  sizeof(struct wmi_mgmt_rx_ext_info));
+   }
+
/* Make sure bytes added for padding are removed. */
skb_trim(skb, msdu_len);
 
-- 
1.9.1

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

Re: [PATCH v5] ath10k: set MAC timestamp in management Rx frame

[Peter Oh]

On 02/29/2016 10:33 AM, Michal Kazior wrote:

On 26 February 2016 at 20:03, Peter Oh <p...@qca.qualcomm.com> wrote:

Check and set Rx MAC timestamp when firmware indicates it.
Firmware adds it in Rx beacon frame only at this moment.
Driver and mac80211 may utilize it to detect such clockdrift
or beacon collision and use the result for beacon collision
avoidance.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---

[...]

+   if (rx_status & WMI_RX_STATUS_EXT_INFO) {
+   status->mactime =
+   __le32_to_cpu(arg.ext_info.rx_mac_timestamp_l32) |
+
(u64)__le32_to_cpu(arg.ext_info.rx_mac_timestamp_u32)
+   << 32;
+   status->flag |= RX_FLAG_MACTIME_END;
+   }
 /* Hardware can Rx CCK rates on 5GHz. In that case phy_mode is set
to
  * MODE_11B. This means phy_mode is not a reliable source for the
band
  * of mgmt rx.
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
b/drivers/net/wireless/ath/ath10k/wmi.h
index 4d3cbc4..f209d51 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -3037,11 +3037,18 @@ struct wmi_10_4_mgmt_rx_event {
 u8 buf[0];
  } __packed;

+struct wmi_mgmt_rx_ext_info {
+   __le32 rx_mac_timestamp_l32;
+   __le32 rx_mac_timestamp_u32;

Oh.. I feel bad for noticing this so late.

review is always appreciated.

  I think this can be
represented with a mere __le64 and then accessed via le64_to_cpu().

sent new patch based on your comment.

Thanks,
Peter
--
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 v6] ath10k: set MAC timestamp in management Rx frame

[Peter Oh]

Check and set Rx MAC timestamp when firmware indicates it.
Firmware adds it in Rx beacon frame only at this moment.
Driver and mac80211 may utilize it to detect such clockdrift
or beacon collision and use the result for beacon collision
avoidance.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---

v2:
 - fix kbuild test robot warning, left shift count >= width of type,
   at __le32_to_cpu(arg.ext_info.rx_mac_timestamp_u32) << 32
v3:
 - correct ext_info to start 4-byte aligned
 - make struct wmi_mgmt_rx_ext_info 4-byte aligned to comply FW's intention
v4:
 - fix endianness warnings, restricted __le32 degrades to integer
v5:
 - use ALIGN for better read
v6:
 - use __le64 instead of 2 __le32 variables to simplify substitution

 drivers/net/wireless/ath/ath10k/wmi.c | 13 +
 drivers/net/wireless/ath/ath10k/wmi.h |  7 +++
 2 files changed, 20 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 1ce6742..20d5e35 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2167,8 +2167,10 @@ static int ath10k_wmi_op_pull_mgmt_rx_ev(struct ath10k 
*ar, struct sk_buff *skb,
struct wmi_mgmt_rx_event_v1 *ev_v1;
struct wmi_mgmt_rx_event_v2 *ev_v2;
struct wmi_mgmt_rx_hdr_v1 *ev_hdr;
+   struct wmi_mgmt_rx_ext_info *ext_info;
size_t pull_len;
u32 msdu_len;
+   u32 len;
 
if (test_bit(ATH10K_FW_FEATURE_EXT_WMI_MGMT_RX, ar->fw_features)) {
ev_v2 = (struct wmi_mgmt_rx_event_v2 *)skb->data;
@@ -2195,6 +2197,12 @@ static int ath10k_wmi_op_pull_mgmt_rx_ev(struct ath10k 
*ar, struct sk_buff *skb,
if (skb->len < msdu_len)
return -EPROTO;
 
+   if (le32_to_cpu(arg->status) & WMI_RX_STATUS_EXT_INFO) {
+   len = ALIGN(le32_to_cpu(arg->buf_len), 4);
+   ext_info = (struct wmi_mgmt_rx_ext_info *)(skb->data + len);
+   memcpy(>ext_info, ext_info,
+  sizeof(struct wmi_mgmt_rx_ext_info));
+   }
/* the WMI buffer might've ended up being padded to 4 bytes due to HTC
 * trailer with credit update. Trim the excess garbage.
 */
@@ -2281,6 +2289,11 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct 
sk_buff *skb)
if (rx_status & WMI_RX_STATUS_ERR_MIC)
status->flag |= RX_FLAG_MMIC_ERROR;
 
+   if (rx_status & WMI_RX_STATUS_EXT_INFO) {
+   status->mactime =
+   __le64_to_cpu(arg.ext_info.rx_mac_timestamp);
+   status->flag |= RX_FLAG_MACTIME_END;
+   }
/* Hardware can Rx CCK rates on 5GHz. In that case phy_mode is set to
 * MODE_11B. This means phy_mode is not a reliable source for the band
 * of mgmt rx.
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 4d3cbc4..bb42f7a 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -3037,11 +3037,17 @@ struct wmi_10_4_mgmt_rx_event {
u8 buf[0];
 } __packed;
 
+struct wmi_mgmt_rx_ext_info {
+   __le64 rx_mac_timestamp;
+} __packed __aligned(4);
+
 #define WMI_RX_STATUS_OK   0x00
 #define WMI_RX_STATUS_ERR_CRC  0x01
 #define WMI_RX_STATUS_ERR_DECRYPT  0x08
 #define WMI_RX_STATUS_ERR_MIC  0x10
 #define WMI_RX_STATUS_ERR_KEY_CACHE_MISS   0x20
+/* Extension data at the end of mgmt frame */
+#define WMI_RX_STATUS_EXT_INFO 0x40
 
 #define PHY_ERROR_GEN_SPECTRAL_SCAN0x26
 #define PHY_ERROR_GEN_FALSE_RADAR_EXT  0x24
@@ -6116,6 +6122,7 @@ struct wmi_mgmt_rx_ev_arg {
__le32 phy_mode;
__le32 buf_len;
__le32 status; /* %WMI_RX_STATUS_ */
+   struct wmi_mgmt_rx_ext_info ext_info;
 };
 
 struct wmi_ch_info_ev_arg {
-- 
1.9.1

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

[PATCH] ath10k: parse Rx MAC timestamp in mgmt frame for FW 10.4

[Peter Oh]

Check and parse Rx MAC timestamp when firmware sets its flag
to status variable.
10.4 firmware adds it in Rx beacon frame only at this moment.
Drivers and mac80211 may utilize it to detect such clockdrift
or beacon collision and use the result for beacon collision
avoidance.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 1ce6742..94968d6 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2211,6 +2211,8 @@ static int ath10k_wmi_10_4_op_pull_mgmt_rx_ev(struct 
ath10k *ar,
struct wmi_10_4_mgmt_rx_hdr *ev_hdr;
size_t pull_len;
u32 msdu_len;
+   struct wmi_mgmt_rx_ext_info *ext_info;
+   u32 len;
 
ev = (struct wmi_10_4_mgmt_rx_event *)skb->data;
ev_hdr = >hdr;
@@ -2231,6 +2233,13 @@ static int ath10k_wmi_10_4_op_pull_mgmt_rx_ev(struct 
ath10k *ar,
if (skb->len < msdu_len)
return -EPROTO;
 
+   if (le32_to_cpu(arg->status) & WMI_RX_STATUS_EXT_INFO) {
+   len = ALIGN(le32_to_cpu(arg->buf_len), 4);
+   ext_info = (struct wmi_mgmt_rx_ext_info *)(skb->data + len);
+   memcpy(>ext_info, ext_info,
+  sizeof(struct wmi_mgmt_rx_ext_info));
+   }
+
/* Make sure bytes added for padding are removed. */
skb_trim(skb, msdu_len);
 
-- 
1.9.1

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

[PATCH v5] ath10k: set MAC timestamp in management Rx frame

[Peter Oh]

Check and set Rx MAC timestamp when firmware indicates it.
Firmware adds it in Rx beacon frame only at this moment.
Driver and mac80211 may utilize it to detect such clockdrift
or beacon collision and use the result for beacon collision
avoidance.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---

v2:
 - fix kbuild test robot warning, left shift count >= width of type,
   at __le32_to_cpu(arg.ext_info.rx_mac_timestamp_u32) << 32
v3:
 - correct ext_info to start 4-byte aligned
 - make struct wmi_mgmt_rx_ext_info 4-byte aligned to comply FW's intention
v4:
 - fix endianness warnings, restricted __le32 degrades to integer
v5:
 - use ALIGN for better read

 drivers/net/wireless/ath/ath10k/wmi.c | 15 +++
 drivers/net/wireless/ath/ath10k/wmi.h |  8 
 2 files changed, 23 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 1ce6742..a343e74 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2167,8 +2167,10 @@ static int ath10k_wmi_op_pull_mgmt_rx_ev(struct ath10k 
*ar, struct sk_buff *skb,
struct wmi_mgmt_rx_event_v1 *ev_v1;
struct wmi_mgmt_rx_event_v2 *ev_v2;
struct wmi_mgmt_rx_hdr_v1 *ev_hdr;
+   struct wmi_mgmt_rx_ext_info *ext_info;
size_t pull_len;
u32 msdu_len;
+   u32 len;
 
if (test_bit(ATH10K_FW_FEATURE_EXT_WMI_MGMT_RX, ar->fw_features)) {
ev_v2 = (struct wmi_mgmt_rx_event_v2 *)skb->data;
@@ -2195,6 +2197,12 @@ static int ath10k_wmi_op_pull_mgmt_rx_ev(struct ath10k 
*ar, struct sk_buff *skb,
if (skb->len < msdu_len)
return -EPROTO;
 
+   if (le32_to_cpu(arg->status) & WMI_RX_STATUS_EXT_INFO) {
+   len = ALIGN(le32_to_cpu(arg->buf_len), 4);
+   ext_info = (struct wmi_mgmt_rx_ext_info *)(skb->data + len);
+   memcpy(>ext_info, ext_info,
+  sizeof(struct wmi_mgmt_rx_ext_info));
+   }
/* the WMI buffer might've ended up being padded to 4 bytes due to HTC
 * trailer with credit update. Trim the excess garbage.
 */
@@ -2281,6 +2289,13 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct 
sk_buff *skb)
if (rx_status & WMI_RX_STATUS_ERR_MIC)
status->flag |= RX_FLAG_MMIC_ERROR;
 
+   if (rx_status & WMI_RX_STATUS_EXT_INFO) {
+   status->mactime =
+   __le32_to_cpu(arg.ext_info.rx_mac_timestamp_l32) |
+   (u64)__le32_to_cpu(arg.ext_info.rx_mac_timestamp_u32)
+   << 32;
+   status->flag |= RX_FLAG_MACTIME_END;
+   }
/* Hardware can Rx CCK rates on 5GHz. In that case phy_mode is set to
 * MODE_11B. This means phy_mode is not a reliable source for the band
 * of mgmt rx.
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 4d3cbc4..f209d51 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -3037,11 +3037,18 @@ struct wmi_10_4_mgmt_rx_event {
u8 buf[0];
 } __packed;
 
+struct wmi_mgmt_rx_ext_info {
+   __le32 rx_mac_timestamp_l32;
+   __le32 rx_mac_timestamp_u32;
+} __packed __aligned(4);
+
 #define WMI_RX_STATUS_OK   0x00
 #define WMI_RX_STATUS_ERR_CRC  0x01
 #define WMI_RX_STATUS_ERR_DECRYPT  0x08
 #define WMI_RX_STATUS_ERR_MIC  0x10
 #define WMI_RX_STATUS_ERR_KEY_CACHE_MISS   0x20
+/* Extension data at the end of mgmt frame */
+#define WMI_RX_STATUS_EXT_INFO 0x40
 
 #define PHY_ERROR_GEN_SPECTRAL_SCAN0x26
 #define PHY_ERROR_GEN_FALSE_RADAR_EXT  0x24
@@ -6116,6 +6123,7 @@ struct wmi_mgmt_rx_ev_arg {
__le32 phy_mode;
__le32 buf_len;
__le32 status; /* %WMI_RX_STATUS_ */
+   struct wmi_mgmt_rx_ext_info ext_info;
 };
 
 struct wmi_ch_info_ev_arg {
-- 
1.9.1

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

Re: [PATCH v3] ath10k: set MAC timestamp in management Rx frame

[Peter Oh]

Thank you!

On 02/25/2016 11:32 AM, Sven Eckelmann wrote:

On Thursday 25 February 2016 10:53:23 Peter Oh wrote:

I see new warnings:

drivers/net/wireless/ath/ath10k/wmi.c:2199:16: warning: restricted

__le32

degrades to integer
drivers/net/wireless/ath/ath10k/wmi.c:2201:41: warning: restricted

__le32

degrades to integer
drivers/net/wireless/ath/ath10k/wmi.c:2201:41: warning: cast to

restricted

__le32
drivers/net/wireless/ath/ath10k/wmi.c:2201:41: warning: restricted

__le32

degrades to integer

Do I have a way to run this check before submitting a patch such as
checkpatch.pl?

Looks like sparse with -D__CHECK_ENDIAN__ [1]

You may also try smatch [2]

Kind regards,
Sven

[1] https://www.kernel.org/doc/Documentation/sparse.txt
[2] http://smatch.sourceforge.net/


--
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] ath10k: set MAC timestamp in management Rx frame

[Peter Oh]

Hi,

On 02/25/2016 08:34 AM, Valo, Kalle wrote:

Peter Oh <p...@qca.qualcomm.com> writes:


Check and set Rx MAC timestamp when firmware indicates it.
Firmware adds it in Rx beacon frame only at this moment.
Driver and mac80211 may utilize it to detect such clockdrift
or beacon collision and use the result for beacon collision
avoidance.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---

v2:
- fix kbuild test robot warning, left shift count >= width of

type,

at __le32_to_cpu(arg.ext_info.rx_mac_timestamp_u32) << 32
v3:
- correct ext_info to start 4-byte aligned
- make struct wmi_mgmt_rx_ext_info 4-byte aligned to comply FW's

intention.

I see new warnings:

drivers/net/wireless/ath/ath10k/wmi.c:2199:16: warning: restricted __le32
degrades to integer
drivers/net/wireless/ath/ath10k/wmi.c:2201:41: warning: restricted __le32
degrades to integer
drivers/net/wireless/ath/ath10k/wmi.c:2201:41: warning: cast to restricted
__le32
drivers/net/wireless/ath/ath10k/wmi.c:2201:41: warning: restricted __le32
degrades to integer

Do I have a way to run this check before submitting a patch such as 
checkpatch.pl?


Thanks,
Peter
--
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] ath10k: set MAC timestamp in management Rx frame

[Peter Oh]

On 02/24/2016 12:40 AM, Michal Kazior wrote:

On 23 February 2016 at 20:44, Peter Oh <p...@qca.qualcomm.com> wrote:

From: poh <p...@qca.qualcomm.com>

Check and set Rx MAC timestamp when firmware indicates it.
Firmware adds it in Rx beacon frame only at this moment.
Driver and mac80211 may utilize it to detect such clockdrift
or beacon collision and use the result for beacon collision
avoidance.

Signed-off-by: poh <p...@qca.qualcomm.com>

Your from/s-o-b doesn't seem right - just "poh"? Shouldn't it say
"Peter Oh" instead? :)




---

v2:
 - fix kbuild test robot warning, left shift count >= width of
type,
 at __le32_to_cpu(arg.ext_info.rx_mac_timestamp_u32) << 32

  drivers/net/wireless/ath/ath10k/wmi.c | 14 ++
  drivers/net/wireless/ath/ath10k/wmi.h |  8 
  2 files changed, 22 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 0f01a8d..b2a4cda 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2167,6 +2167,7 @@ static int ath10k_wmi_op_pull_mgmt_rx_ev(struct
ath10k *ar, struct sk_buff *skb,
 struct wmi_mgmt_rx_event_v1 *ev_v1;
 struct wmi_mgmt_rx_event_v2 *ev_v2;
 struct wmi_mgmt_rx_hdr_v1 *ev_hdr;
+   struct wmi_mgmt_rx_ext_info *ext_info;
 size_t pull_len;
 u32 msdu_len;

@@ -2195,6 +2196,12 @@ static int ath10k_wmi_op_pull_mgmt_rx_ev(struct
ath10k *ar, struct sk_buff *skb,
 if (skb->len < msdu_len)
 return -EPROTO;

+   if (arg->status & WMI_RX_STATUS_EXT_INFO) {
+   ext_info = (struct wmi_mgmt_rx_ext_info *)
+  (skb->data + arg->buf_len);

I would expect the ext_info structure to be aligned at 4 byte
boundaries (or is it?)

Yes.

but buf_len isn't guaranteed to be multiple of
4.

Correct.

  This could mean you grab garbage in some cases depending on the
mgmt frame size (i.e. whether its size is multiple of 4). It might be
coincidence it works for you?

I'll send out 3rd patch.



Michał

___
ath10k mailing list
ath...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k


--
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] ath10k: set MAC timestamp in management Rx frame

[Peter Oh]

From: poh 

Check and set Rx MAC timestamp when firmware indicates it.
Firmware adds it in Rx beacon frame only at this moment.
Driver and mac80211 may utilize it to detect such clockdrift
or beacon collision and use the result for beacon collision
avoidance.

Signed-off-by: poh 
---

v2:
- fix kbuild test robot warning, left shift count >= width of type,
at __le32_to_cpu(arg.ext_info.rx_mac_timestamp_u32) << 32

 drivers/net/wireless/ath/ath10k/wmi.c | 14 ++
 drivers/net/wireless/ath/ath10k/wmi.h |  8 
 2 files changed, 22 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 0f01a8d..b2a4cda 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2167,6 +2167,7 @@ static int ath10k_wmi_op_pull_mgmt_rx_ev(struct ath10k 
*ar, struct sk_buff *skb,
struct wmi_mgmt_rx_event_v1 *ev_v1;
struct wmi_mgmt_rx_event_v2 *ev_v2;
struct wmi_mgmt_rx_hdr_v1 *ev_hdr;
+   struct wmi_mgmt_rx_ext_info *ext_info;
size_t pull_len;
u32 msdu_len;
 
@@ -2195,6 +2196,12 @@ static int ath10k_wmi_op_pull_mgmt_rx_ev(struct ath10k 
*ar, struct sk_buff *skb,
if (skb->len < msdu_len)
return -EPROTO;
 
+   if (arg->status & WMI_RX_STATUS_EXT_INFO) {
+   ext_info = (struct wmi_mgmt_rx_ext_info *)
+  (skb->data + arg->buf_len);
+   memcpy(>ext_info, ext_info,
+  sizeof(struct wmi_mgmt_rx_ext_info));
+   }
/* the WMI buffer might've ended up being padded to 4 bytes due to HTC
 * trailer with credit update. Trim the excess garbage.
 */
@@ -2281,6 +2288,13 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct 
sk_buff *skb)
if (rx_status & WMI_RX_STATUS_ERR_MIC)
status->flag |= RX_FLAG_MMIC_ERROR;
 
+   if (rx_status & WMI_RX_STATUS_EXT_INFO) {
+   status->mactime =
+   __le32_to_cpu(arg.ext_info.rx_mac_timestamp_l32) |
+   (u64)__le32_to_cpu(arg.ext_info.rx_mac_timestamp_u32)
+   << 32;
+   status->flag |= RX_FLAG_MACTIME_END;
+   }
/* Hardware can Rx CCK rates on 5GHz. In that case phy_mode is set to
 * MODE_11B. This means phy_mode is not a reliable source for the band
 * of mgmt rx.
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 806d4bb..8667a6b 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -3025,11 +3025,18 @@ struct wmi_10_4_mgmt_rx_event {
u8 buf[0];
 } __packed;
 
+struct wmi_mgmt_rx_ext_info {
+   __le32 rx_mac_timestamp_l32;
+   __le32 rx_mac_timestamp_u32;
+} __packed;
+
 #define WMI_RX_STATUS_OK   0x00
 #define WMI_RX_STATUS_ERR_CRC  0x01
 #define WMI_RX_STATUS_ERR_DECRYPT  0x08
 #define WMI_RX_STATUS_ERR_MIC  0x10
 #define WMI_RX_STATUS_ERR_KEY_CACHE_MISS   0x20
+/* Extension data at the end of mgmt frame */
+#define WMI_RX_STATUS_EXT_INFO 0x40
 
 #define PHY_ERROR_GEN_SPECTRAL_SCAN0x26
 #define PHY_ERROR_GEN_FALSE_RADAR_EXT  0x24
@@ -6076,6 +6083,7 @@ struct wmi_mgmt_rx_ev_arg {
__le32 phy_mode;
__le32 buf_len;
__le32 status; /* %WMI_RX_STATUS_ */
+   struct wmi_mgmt_rx_ext_info ext_info;
 };
 
 struct wmi_ch_info_ev_arg {
-- 
1.9.1

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

[PATCH] ath10k: set MAC timestamp in management Rx frame

[Peter Oh]

From: poh 

Check and set Rx MAC timestamp when firmware indicates it.
Firmware adds it in Rx beacon frame only at this moment.
Driver and mac80211 may utilize it to detect such clockdrift
or beacon collision and use the result for beacon collision
avoidance.

Signed-off-by: poh 
---
 drivers/net/wireless/ath/ath10k/wmi.c | 13 +
 drivers/net/wireless/ath/ath10k/wmi.h |  8 
 2 files changed, 21 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 0f01a8d..fc7b468 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2167,6 +2167,7 @@ static int ath10k_wmi_op_pull_mgmt_rx_ev(struct ath10k 
*ar, struct sk_buff *skb,
struct wmi_mgmt_rx_event_v1 *ev_v1;
struct wmi_mgmt_rx_event_v2 *ev_v2;
struct wmi_mgmt_rx_hdr_v1 *ev_hdr;
+   struct wmi_mgmt_rx_ext_info *ext_info;
size_t pull_len;
u32 msdu_len;
 
@@ -2195,6 +2196,12 @@ static int ath10k_wmi_op_pull_mgmt_rx_ev(struct ath10k 
*ar, struct sk_buff *skb,
if (skb->len < msdu_len)
return -EPROTO;
 
+   if (arg->status & WMI_RX_STATUS_EXT_INFO) {
+   ext_info = (struct wmi_mgmt_rx_ext_info *)
+  (skb->data + arg->buf_len);
+   memcpy(>ext_info, ext_info,
+  sizeof(struct wmi_mgmt_rx_ext_info));
+   }
/* the WMI buffer might've ended up being padded to 4 bytes due to HTC
 * trailer with credit update. Trim the excess garbage.
 */
@@ -2281,6 +2288,12 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct 
sk_buff *skb)
if (rx_status & WMI_RX_STATUS_ERR_MIC)
status->flag |= RX_FLAG_MMIC_ERROR;
 
+   if (rx_status & WMI_RX_STATUS_EXT_INFO) {
+   status->mactime =
+   __le32_to_cpu(arg.ext_info.rx_mac_timestamp_u32) << 32 |
+   __le32_to_cpu(arg.ext_info.rx_mac_timestamp_l32);
+   status->flag |= RX_FLAG_MACTIME_END;
+   }
/* Hardware can Rx CCK rates on 5GHz. In that case phy_mode is set to
 * MODE_11B. This means phy_mode is not a reliable source for the band
 * of mgmt rx.
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 806d4bb..8667a6b 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -3025,11 +3025,18 @@ struct wmi_10_4_mgmt_rx_event {
u8 buf[0];
 } __packed;
 
+struct wmi_mgmt_rx_ext_info {
+   __le32 rx_mac_timestamp_l32;
+   __le32 rx_mac_timestamp_u32;
+} __packed;
+
 #define WMI_RX_STATUS_OK   0x00
 #define WMI_RX_STATUS_ERR_CRC  0x01
 #define WMI_RX_STATUS_ERR_DECRYPT  0x08
 #define WMI_RX_STATUS_ERR_MIC  0x10
 #define WMI_RX_STATUS_ERR_KEY_CACHE_MISS   0x20
+/* Extension data at the end of mgmt frame */
+#define WMI_RX_STATUS_EXT_INFO 0x40
 
 #define PHY_ERROR_GEN_SPECTRAL_SCAN0x26
 #define PHY_ERROR_GEN_FALSE_RADAR_EXT  0x24
@@ -6076,6 +6083,7 @@ struct wmi_mgmt_rx_ev_arg {
__le32 phy_mode;
__le32 buf_len;
__le32 status; /* %WMI_RX_STATUS_ */
+   struct wmi_mgmt_rx_ext_info ext_info;
 };
 
 struct wmi_ch_info_ev_arg {
-- 
1.9.1

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

Re: Adjusting_tbtt in mesh capability

[Peter Oh]

On 02/03/2016 12:18 PM, Neelansh Mittal wrote:

Currently, for a mesh node ,the mac80211
sync implementation sets the tbtt
adjustment bit , when it is adjusting it's
tsf as part of Neighbour offset
Synchronization(Function:mesh_sync_offset_
adjust_tbtt())
According to ieee80211s specification,
this bit should(only) be set when tbtt
adjustment procedure(as part of tbtt
selection/mbca) is ongoing.
So why does mac80211 set it as part of
Offset syncronization, ie , what is
advantage the when a mesh node announces
that "my tbtt will be delayed" to it's
peers?

I guess it's to prevent mesh peers from running TBTT adjustment?
Setting TBTT adjustment bit is good idea although the standard is 
addressing TBTT adjustment bit during MBCA/TBTT selection procedure,
since the key idea of setting the bit is to run TBTT adjustment by only 
one mesh point at a time IMO.



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


--
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/4] ath10k: update 10.4 WMI service map

[Peter Oh]

Update 10.4 WMI service map to sync to the latest 10.4 firmware
as of 1/20/2016.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 0458bf6..031018a 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -179,6 +179,7 @@ enum wmi_service {
WMI_SERVICE_MESH_11S,
WMI_SERVICE_MESH_NON_11S,
WMI_SERVICE_PEER_STATS,
+   WMI_SERVICE_RESTRT_CHNL_SUPPORT,
 
/* keep last */
WMI_SERVICE_MAX,
@@ -298,6 +299,9 @@ enum wmi_10_4_service {
WMI_10_4_SERVICE_BSS_CHANNEL_INFO_64,
WMI_10_4_SERVICE_EXT_RES_CFG_SUPPORT,
WMI_10_4_SERVICE_MESH_NON_11S,
+   WMI_10_4_SERVICE_RESTRT_CHNL_SUPPORT,
+   WMI_10_4_SERVICE_PEER_STATS,
+   WMI_10_4_SERVICE_MESH_11S,
 };
 
 static inline char *wmi_service_name(int service_id)
@@ -391,6 +395,7 @@ static inline char *wmi_service_name(int service_id)
SVCSTR(WMI_SERVICE_MESH_11S);
SVCSTR(WMI_SERVICE_MESH_NON_11S);
SVCSTR(WMI_SERVICE_PEER_STATS);
+   SVCSTR(WMI_SERVICE_RESTRT_CHNL_SUPPORT);
default:
return NULL;
}
@@ -632,6 +637,12 @@ static inline void wmi_10_4_svc_map(const __le32 *in, 
unsigned long *out,
   WMI_SERVICE_EXT_RES_CFG_SUPPORT, len);
SVCMAP(WMI_10_4_SERVICE_MESH_NON_11S,
   WMI_SERVICE_MESH_NON_11S, len);
+   SVCMAP(WMI_10_4_SERVICE_RESTRT_CHNL_SUPPORT,
+  WMI_SERVICE_RESTRT_CHNL_SUPPORT, len);
+   SVCMAP(WMI_10_4_SERVICE_PEER_STATS,
+  WMI_SERVICE_PEER_STATS, len);
+   SVCMAP(WMI_10_4_SERVICE_MESH_11S,
+  WMI_SERVICE_MESH_11S, len);
 }
 
 #undef SVCMAP
-- 
1.9.1

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

[PATCH v2 1/4] ath10k: rename Mesh related service names

[Peter Oh]

WMI_10_4_SERVICE_MESH bit is for non IEEE802.11s Mesh.
Hence rename it to WMI_10_4_SERVICE_MESH_NON_11S.
Also add _11S as post-fix to each of WMI_SERVICE_MESH and
WMI_VDEV_SUBTYPE_MESH specifying the service is for 11s Mesh.
This will help users to distinguish 11s Mesh from non 11s Mesh.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c |  4 ++--
 drivers/net/wireless/ath/ath10k/wmi.h | 16 +---
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index ef0438d..1406b0f 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4380,8 +4380,8 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
arvif->vdev_type = WMI_VDEV_TYPE_IBSS;
break;
case NL80211_IFTYPE_MESH_POINT:
-   if (test_bit(WMI_SERVICE_MESH, ar->wmi.svc_map)) {
-   arvif->vdev_subtype = WMI_VDEV_SUBTYPE_MESH;
+   if (test_bit(WMI_SERVICE_MESH_11S, ar->wmi.svc_map)) {
+   arvif->vdev_subtype = WMI_VDEV_SUBTYPE_MESH_11S;
} else if (!test_bit(ATH10K_FLAG_RAW_MODE, >dev_flags)) {
ret = -EINVAL;
ath10k_warn(ar, "must load driver with rawmode=1 to add 
mesh interfaces\n");
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 806d4bb..0458bf6 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -176,7 +176,8 @@ enum wmi_service {
WMI_SERVICE_AUX_CHAN_LOAD_INTF,
WMI_SERVICE_BSS_CHANNEL_INFO_64,
WMI_SERVICE_EXT_RES_CFG_SUPPORT,
-   WMI_SERVICE_MESH,
+   WMI_SERVICE_MESH_11S,
+   WMI_SERVICE_MESH_NON_11S,
WMI_SERVICE_PEER_STATS,
 
/* keep last */
@@ -296,7 +297,7 @@ enum wmi_10_4_service {
WMI_10_4_SERVICE_AUX_CHAN_LOAD_INTF,
WMI_10_4_SERVICE_BSS_CHANNEL_INFO_64,
WMI_10_4_SERVICE_EXT_RES_CFG_SUPPORT,
-   WMI_10_4_SERVICE_MESH,
+   WMI_10_4_SERVICE_MESH_NON_11S,
 };
 
 static inline char *wmi_service_name(int service_id)
@@ -387,7 +388,8 @@ static inline char *wmi_service_name(int service_id)
SVCSTR(WMI_SERVICE_AUX_CHAN_LOAD_INTF);
SVCSTR(WMI_SERVICE_BSS_CHANNEL_INFO_64);
SVCSTR(WMI_SERVICE_EXT_RES_CFG_SUPPORT);
-   SVCSTR(WMI_SERVICE_MESH);
+   SVCSTR(WMI_SERVICE_MESH_11S);
+   SVCSTR(WMI_SERVICE_MESH_NON_11S);
SVCSTR(WMI_SERVICE_PEER_STATS);
default:
return NULL;
@@ -463,7 +465,7 @@ static inline void wmi_10x_svc_map(const __le32 *in, 
unsigned long *out,
SVCMAP(WMI_10X_SERVICE_BSS_CHANNEL_INFO_64,
   WMI_SERVICE_BSS_CHANNEL_INFO_64, len);
SVCMAP(WMI_10X_SERVICE_MESH,
-  WMI_SERVICE_MESH, len);
+  WMI_SERVICE_MESH_11S, len);
SVCMAP(WMI_10X_SERVICE_EXT_RES_CFG_SUPPORT,
   WMI_SERVICE_EXT_RES_CFG_SUPPORT, len);
SVCMAP(WMI_10X_SERVICE_PEER_STATS,
@@ -628,8 +630,8 @@ static inline void wmi_10_4_svc_map(const __le32 *in, 
unsigned long *out,
   WMI_SERVICE_BSS_CHANNEL_INFO_64, len);
SVCMAP(WMI_10_4_SERVICE_EXT_RES_CFG_SUPPORT,
   WMI_SERVICE_EXT_RES_CFG_SUPPORT, len);
-   SVCMAP(WMI_10_4_SERVICE_MESH,
-  WMI_SERVICE_MESH, len);
+   SVCMAP(WMI_10_4_SERVICE_MESH_NON_11S,
+  WMI_SERVICE_MESH_NON_11S, len);
 }
 
 #undef SVCMAP
@@ -4287,7 +4289,7 @@ enum wmi_vdev_subtype {
WMI_VDEV_SUBTYPE_P2P_CLIENT = 2,
WMI_VDEV_SUBTYPE_P2P_GO = 3,
WMI_VDEV_SUBTYPE_PROXY_STA  = 4,
-   WMI_VDEV_SUBTYPE_MESH   = 5,
+   WMI_VDEV_SUBTYPE_MESH_11S   = 5,
 };
 
 /* values for vdev_subtype */
-- 
1.9.1

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

[PATCH v2 4/4] ath10k: add abstraction layer for vdev subtype

[Peter Oh]

Abstraction layer for vdev subtype is added to solve
subtype mismatch and to give flexible compatibility
among different firmware revisions.

For instance, 10.2 and 10.4 firmware has different
definition of their vdev subtypes for Mesh.
10.4 defined subtype 6 for 802.11s Mesh while 10.2 uses 5.
Hence use the abstraction API to get right subtype to use.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 15 ---
 drivers/net/wireless/ath/ath10k/wmi-ops.h | 11 +
 drivers/net/wireless/ath/ath10k/wmi-tlv.c |  1 +
 drivers/net/wireless/ath/ath10k/wmi.c | 70 +++
 drivers/net/wireless/ath/ath10k/wmi.h | 42 ---
 5 files changed, 128 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index addf3cb..96e2f8a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4359,25 +4359,29 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
   bit, ar->free_vdev_map);
 
arvif->vdev_id = bit;
-   arvif->vdev_subtype = WMI_VDEV_SUBTYPE_NONE;
+   arvif->vdev_subtype =
+   ath10k_wmi_get_vdev_subtype(ar, WMI_VDEV_SUBTYPE_NONE);
 
switch (vif->type) {
case NL80211_IFTYPE_P2P_DEVICE:
arvif->vdev_type = WMI_VDEV_TYPE_STA;
-   arvif->vdev_subtype = WMI_VDEV_SUBTYPE_P2P_DEVICE;
+   arvif->vdev_subtype = ath10k_wmi_get_vdev_subtype
+   (ar, WMI_VDEV_SUBTYPE_P2P_DEVICE);
break;
case NL80211_IFTYPE_UNSPECIFIED:
case NL80211_IFTYPE_STATION:
arvif->vdev_type = WMI_VDEV_TYPE_STA;
if (vif->p2p)
-   arvif->vdev_subtype = WMI_VDEV_SUBTYPE_P2P_CLIENT;
+   arvif->vdev_subtype = ath10k_wmi_get_vdev_subtype
+   (ar, WMI_VDEV_SUBTYPE_P2P_CLIENT);
break;
case NL80211_IFTYPE_ADHOC:
arvif->vdev_type = WMI_VDEV_TYPE_IBSS;
break;
case NL80211_IFTYPE_MESH_POINT:
if (test_bit(WMI_SERVICE_MESH_11S, ar->wmi.svc_map)) {
-   arvif->vdev_subtype = WMI_VDEV_SUBTYPE_MESH_11S;
+   arvif->vdev_subtype = ath10k_wmi_get_vdev_subtype
+   (ar, WMI_VDEV_SUBTYPE_MESH_11S);
} else if (!test_bit(ATH10K_FLAG_RAW_MODE, >dev_flags)) {
ret = -EINVAL;
ath10k_warn(ar, "must load driver with rawmode=1 to add 
mesh interfaces\n");
@@ -4389,7 +4393,8 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
arvif->vdev_type = WMI_VDEV_TYPE_AP;
 
if (vif->p2p)
-   arvif->vdev_subtype = WMI_VDEV_SUBTYPE_P2P_GO;
+   arvif->vdev_subtype = ath10k_wmi_get_vdev_subtype
+   (ar, WMI_VDEV_SUBTYPE_P2P_GO);
break;
case NL80211_IFTYPE_MONITOR:
arvif->vdev_type = WMI_VDEV_TYPE_MONITOR;
diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h 
b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index 8f4f6a8..32ab34e 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -186,6 +186,8 @@ struct wmi_ops {
u8 enable,
u32 detect_level,
u32 detect_margin);
+   int (*get_vdev_subtype)(struct ath10k *ar,
+   enum wmi_vdev_subtype subtype);
 };
 
 int ath10k_wmi_cmd_send(struct ath10k *ar, struct sk_buff *skb, u32 cmd_id);
@@ -1327,4 +1329,13 @@ ath10k_wmi_pdev_enable_adaptive_cca(struct ath10k *ar, 
u8 enable,
   ar->wmi.cmd->pdev_enable_adaptive_cca_cmdid);
 }
 
+static inline int
+ath10k_wmi_get_vdev_subtype(struct ath10k *ar, enum wmi_vdev_subtype subtype)
+{
+   if (!ar->wmi.ops->get_vdev_subtype)
+   return -EOPNOTSUPP;
+
+   return ar->wmi.ops->get_vdev_subtype(ar, subtype);
+}
+
 #endif
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c 
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 3b3a27b..1085932 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -3483,6 +3483,7 @@ static const struct wmi_ops wmi_tlv_ops = {
.gen_tdls_peer_update = ath10k_wmi_tlv_op_gen_tdls_peer_update,
.gen_adaptive_qcs = ath10k_wmi_tlv_op_gen_adaptive_qcs,
.fw_stats_fill = ath10k_wmi_main_op_fw_stats_fill,
+   .get_vdev_subtype = ath10k_wmi_op_get_vdev_subtype,
 };
 
 sta

[PATCH v2 3/4] ath10k: use vif->type and vif->p2p for P2P_GO check

[Peter Oh]

Interface type P2P_GO can be checked by either arvif->vdev_type
and arvif->vdev_subtype or vif->type and vif->p2p.
Use later one to avoid more cpu consumption that could happen
when subtype abstraction layer change is introduced.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 8 ++--
 drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 1406b0f..addf3cb 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1358,10 +1358,7 @@ static int ath10k_mac_setup_bcn_p2p_ie(struct ath10k_vif 
*arvif,
const u8 *p2p_ie;
int ret;
 
-   if (arvif->vdev_type != WMI_VDEV_TYPE_AP)
-   return 0;
-
-   if (arvif->vdev_subtype != WMI_VDEV_SUBTYPE_P2P_GO)
+   if (arvif->vif->type != NL80211_IFTYPE_AP || !arvif->vif->p2p)
return 0;
 
mgmt = (void *)bcn->data;
@@ -3259,8 +3256,7 @@ static void ath10k_tx_h_add_p2p_noa_ie(struct ath10k *ar,
struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
 
/* This is case only for P2P_GO */
-   if (arvif->vdev_type != WMI_VDEV_TYPE_AP ||
-   arvif->vdev_subtype != WMI_VDEV_SUBTYPE_P2P_GO)
+   if (vif->type != NL80211_IFTYPE_AP || !vif->p2p)
return;
 
if (unlikely(ieee80211_is_probe_resp(hdr->frame_control))) {
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 0f01a8d..5158716 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3196,7 +3196,7 @@ static void ath10k_wmi_update_noa(struct ath10k *ar, 
struct ath10k_vif *arvif,
  struct sk_buff *bcn,
  const struct wmi_p2p_noa_info *noa)
 {
-   if (arvif->vdev_subtype != WMI_VDEV_SUBTYPE_P2P_GO)
+   if (!arvif->vif->p2p)
return;
 
ath10k_dbg(ar, ATH10K_DBG_MGMT, "noa changed: %d\n", noa->changed);
-- 
1.9.1

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

Re: [PATCH 0/4] ath10k: rename mesh and add abstraction layer

[Peter Oh]

On 01/27/2016 06:04 PM, Yeoh Chun-Yeow wrote:

On Thu, Jan 28, 2016 at 5:53 AM, Peter Oh <p...@codeaurora.org> wrote:

On 01/27/2016 11:39 AM, Bob Copeland wrote:

On Wed, Jan 27, 2016 at 10:55:53AM -0800, Peter Oh wrote:

Split Mesh service to 11s Mesh and non-11s Mesh according to
firmware service bit to help users distinguish 11s Mesh from
non 11s Mesh.
And add abstraction layer for vdev subtype to solve subtype mismatch
and to give flexible compatibility among different firmware revisions.

Out of curiosity, which non-11s mesh, if you can share?

non-11s Mesh can be anything, but 11s Mesh such as meraki mesh.


I thought that non-11s mesh is for meraki mesh since it is not 802.11s
implementation.

WMI_10_4_SERVICE_MESH_NON_11S for non IEEE802.11s Mesh
WMI_SERVICE_MESH_11S and WMI_VDEV_SUBTYPE_MESH for IEEE 802.11s Mesh

Correct me if I am wrong.

You're correct.  WMI_VDEV_SUBTYPE_MESH -> WMI_VDEV_SUBTYPE_MESH_11S


Thanks


Chun-Yeow

___
ath10k mailing list
ath...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k


--
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 1/4] ath10k: rename Mesh related service names

[Peter Oh]

WMI_10_4_SERVICE_MESH bit is for non IEEE802.11s Mesh.
Hence rename it to WMI_10_4_SERVICE_MESH_NON_11S.
Also add _11S as post-fix to each of WMI_SERVICE_MESH and
WMI_VDEV_SUBTYPE_MESH specifying the service is for 11s Mesh.
This will help users to distinguish 11s Mesh from non 11s Mesh.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c |  4 ++--
 drivers/net/wireless/ath/ath10k/wmi.h | 16 +---
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 6146a29..6bf5c91 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4366,8 +4366,8 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
arvif->vdev_type = WMI_VDEV_TYPE_IBSS;
break;
case NL80211_IFTYPE_MESH_POINT:
-   if (test_bit(WMI_SERVICE_MESH, ar->wmi.svc_map)) {
-   arvif->vdev_subtype = WMI_VDEV_SUBTYPE_MESH;
+   if (test_bit(WMI_SERVICE_MESH_11S, ar->wmi.svc_map)) {
+   arvif->vdev_subtype = WMI_VDEV_SUBTYPE_MESH_11S;
} else if (!test_bit(ATH10K_FLAG_RAW_MODE, >dev_flags)) {
ret = -EINVAL;
ath10k_warn(ar, "must load driver with rawmode=1 to add 
mesh interfaces\n");
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index d85ad78..26a1bb9 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -176,7 +176,8 @@ enum wmi_service {
WMI_SERVICE_AUX_CHAN_LOAD_INTF,
WMI_SERVICE_BSS_CHANNEL_INFO_64,
WMI_SERVICE_EXT_RES_CFG_SUPPORT,
-   WMI_SERVICE_MESH,
+   WMI_SERVICE_MESH_11S,
+   WMI_SERVICE_MESH_NON_11S,
 
/* keep last */
WMI_SERVICE_MAX,
@@ -294,7 +295,7 @@ enum wmi_10_4_service {
WMI_10_4_SERVICE_AUX_CHAN_LOAD_INTF,
WMI_10_4_SERVICE_BSS_CHANNEL_INFO_64,
WMI_10_4_SERVICE_EXT_RES_CFG_SUPPORT,
-   WMI_10_4_SERVICE_MESH,
+   WMI_10_4_SERVICE_MESH_NON_11S,
 };
 
 static inline char *wmi_service_name(int service_id)
@@ -385,7 +386,8 @@ static inline char *wmi_service_name(int service_id)
SVCSTR(WMI_SERVICE_AUX_CHAN_LOAD_INTF);
SVCSTR(WMI_SERVICE_BSS_CHANNEL_INFO_64);
SVCSTR(WMI_SERVICE_EXT_RES_CFG_SUPPORT);
-   SVCSTR(WMI_SERVICE_MESH);
+   SVCSTR(WMI_SERVICE_MESH_11S);
+   SVCSTR(WMI_SERVICE_MESH_NON_11S);
default:
return NULL;
}
@@ -460,7 +462,7 @@ static inline void wmi_10x_svc_map(const __le32 *in, 
unsigned long *out,
SVCMAP(WMI_10X_SERVICE_BSS_CHANNEL_INFO_64,
   WMI_SERVICE_BSS_CHANNEL_INFO_64, len);
SVCMAP(WMI_10X_SERVICE_MESH,
-  WMI_SERVICE_MESH, len);
+  WMI_SERVICE_MESH_11S, len);
SVCMAP(WMI_10X_SERVICE_EXT_RES_CFG_SUPPORT,
   WMI_SERVICE_EXT_RES_CFG_SUPPORT, len);
 }
@@ -623,8 +625,8 @@ static inline void wmi_10_4_svc_map(const __le32 *in, 
unsigned long *out,
   WMI_SERVICE_BSS_CHANNEL_INFO_64, len);
SVCMAP(WMI_10_4_SERVICE_EXT_RES_CFG_SUPPORT,
   WMI_SERVICE_EXT_RES_CFG_SUPPORT, len);
-   SVCMAP(WMI_10_4_SERVICE_MESH,
-  WMI_SERVICE_MESH, len);
+   SVCMAP(WMI_10_4_SERVICE_MESH_NON_11S,
+  WMI_SERVICE_MESH_NON_11S, len);
 }
 
 #undef SVCMAP
@@ -4275,7 +4277,7 @@ enum wmi_vdev_subtype {
WMI_VDEV_SUBTYPE_P2P_CLIENT = 2,
WMI_VDEV_SUBTYPE_P2P_GO = 3,
WMI_VDEV_SUBTYPE_PROXY_STA  = 4,
-   WMI_VDEV_SUBTYPE_MESH   = 5,
+   WMI_VDEV_SUBTYPE_MESH_11S   = 5,
 };
 
 /* values for vdev_subtype */
-- 
1.9.1

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

[PATCH 0/4] ath10k: rename mesh and add abstraction layer

[Peter Oh]

Split Mesh service to 11s Mesh and non-11s Mesh according to
firmware service bit to help users distinguish 11s Mesh from
non 11s Mesh.
And add abstraction layer for vdev subtype to solve subtype mismatch
and to give flexible compatibility among different firmware revisions.

Peter Oh (4):
  ath10k: rename Mesh related service names
  ath10k: update 10.4 WMI service map
  ath10k: use vif->type and vif->p2p for P2P_GO check
  ath10k: add abstraction layer for vdev subtype

 drivers/net/wireless/ath/ath10k/mac.c | 25 +--
 drivers/net/wireless/ath/ath10k/wmi-ops.h | 11 +
 drivers/net/wireless/ath/ath10k/wmi-tlv.c |  1 +
 drivers/net/wireless/ath/ath10k/wmi.c | 72 ++-
 drivers/net/wireless/ath/ath10k/wmi.h | 69 +++--
 5 files changed, 153 insertions(+), 25 deletions(-)

-- 
1.9.1

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

[PATCH 2/4] ath10k: update 10.4 WMI service map

[Peter Oh]

Update 10.4 WMI service map to sync to the latest 10.4 firmware
as of 1/20/2016.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 26a1bb9..90b6581 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -178,6 +178,8 @@ enum wmi_service {
WMI_SERVICE_EXT_RES_CFG_SUPPORT,
WMI_SERVICE_MESH_11S,
WMI_SERVICE_MESH_NON_11S,
+   WMI_SERVICE_RESTRT_CHNL_SUPPORT,
+   WMI_SERVICE_PEER_STATS,
 
/* keep last */
WMI_SERVICE_MAX,
@@ -296,6 +298,9 @@ enum wmi_10_4_service {
WMI_10_4_SERVICE_BSS_CHANNEL_INFO_64,
WMI_10_4_SERVICE_EXT_RES_CFG_SUPPORT,
WMI_10_4_SERVICE_MESH_NON_11S,
+   WMI_10_4_SERVICE_RESTRT_CHNL_SUPPORT,
+   WMI_10_4_SERVICE_PEER_STATS,
+   WMI_10_4_SERVICE_MESH_11S,
 };
 
 static inline char *wmi_service_name(int service_id)
@@ -388,6 +393,8 @@ static inline char *wmi_service_name(int service_id)
SVCSTR(WMI_SERVICE_EXT_RES_CFG_SUPPORT);
SVCSTR(WMI_SERVICE_MESH_11S);
SVCSTR(WMI_SERVICE_MESH_NON_11S);
+   SVCSTR(WMI_SERVICE_RESTRT_CHNL_SUPPORT);
+   SVCSTR(WMI_SERVICE_PEER_STATS);
default:
return NULL;
}
@@ -627,6 +634,12 @@ static inline void wmi_10_4_svc_map(const __le32 *in, 
unsigned long *out,
   WMI_SERVICE_EXT_RES_CFG_SUPPORT, len);
SVCMAP(WMI_10_4_SERVICE_MESH_NON_11S,
   WMI_SERVICE_MESH_NON_11S, len);
+   SVCMAP(WMI_10_4_SERVICE_RESTRT_CHNL_SUPPORT,
+  WMI_SERVICE_RESTRT_CHNL_SUPPORT, len);
+   SVCMAP(WMI_10_4_SERVICE_PEER_STATS,
+  WMI_SERVICE_PEER_STATS, len);
+   SVCMAP(WMI_10_4_SERVICE_MESH_11S,
+  WMI_SERVICE_MESH_11S, len);
 }
 
 #undef SVCMAP
-- 
1.9.1

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

[PATCH 4/4] ath10k: add abstraction layer for vdev subtype

[Peter Oh]

Abstraction layer for vdev subtype is added to solve
subtype mismatch and to give flexible compatibility
among different firmware revisions.

For instance, 10.2 and 10.4 firmware has different
definition of their vdev subtypes for Mesh.
10.4 defined subtype 6 for 802.11s Mesh while 10.2 uses 5.
Hence use the abstraction API to get right subtype to use.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 15 ---
 drivers/net/wireless/ath/ath10k/wmi-ops.h | 11 +
 drivers/net/wireless/ath/ath10k/wmi-tlv.c |  1 +
 drivers/net/wireless/ath/ath10k/wmi.c | 70 +++
 drivers/net/wireless/ath/ath10k/wmi.h | 42 ---
 5 files changed, 128 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 2940b00..c9a39ab 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4345,25 +4345,29 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
   bit, ar->free_vdev_map);
 
arvif->vdev_id = bit;
-   arvif->vdev_subtype = WMI_VDEV_SUBTYPE_NONE;
+   arvif->vdev_subtype =
+   ath10k_wmi_get_vdev_subtype(ar, WMI_VDEV_SUBTYPE_NONE);
 
switch (vif->type) {
case NL80211_IFTYPE_P2P_DEVICE:
arvif->vdev_type = WMI_VDEV_TYPE_STA;
-   arvif->vdev_subtype = WMI_VDEV_SUBTYPE_P2P_DEVICE;
+   arvif->vdev_subtype = ath10k_wmi_get_vdev_subtype
+   (ar, WMI_VDEV_SUBTYPE_P2P_DEVICE);
break;
case NL80211_IFTYPE_UNSPECIFIED:
case NL80211_IFTYPE_STATION:
arvif->vdev_type = WMI_VDEV_TYPE_STA;
if (vif->p2p)
-   arvif->vdev_subtype = WMI_VDEV_SUBTYPE_P2P_CLIENT;
+   arvif->vdev_subtype = ath10k_wmi_get_vdev_subtype
+   (ar, WMI_VDEV_SUBTYPE_P2P_CLIENT);
break;
case NL80211_IFTYPE_ADHOC:
arvif->vdev_type = WMI_VDEV_TYPE_IBSS;
break;
case NL80211_IFTYPE_MESH_POINT:
if (test_bit(WMI_SERVICE_MESH_11S, ar->wmi.svc_map)) {
-   arvif->vdev_subtype = WMI_VDEV_SUBTYPE_MESH_11S;
+   arvif->vdev_subtype = ath10k_wmi_get_vdev_subtype
+   (ar, WMI_VDEV_SUBTYPE_MESH_11S);
} else if (!test_bit(ATH10K_FLAG_RAW_MODE, >dev_flags)) {
ret = -EINVAL;
ath10k_warn(ar, "must load driver with rawmode=1 to add 
mesh interfaces\n");
@@ -4375,7 +4379,8 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
arvif->vdev_type = WMI_VDEV_TYPE_AP;
 
if (vif->p2p)
-   arvif->vdev_subtype = WMI_VDEV_SUBTYPE_P2P_GO;
+   arvif->vdev_subtype = ath10k_wmi_get_vdev_subtype
+   (ar, WMI_VDEV_SUBTYPE_P2P_GO);
break;
case NL80211_IFTYPE_MONITOR:
arvif->vdev_type = WMI_VDEV_TYPE_MONITOR;
diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h 
b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index 8f4f6a8..32ab34e 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -186,6 +186,8 @@ struct wmi_ops {
u8 enable,
u32 detect_level,
u32 detect_margin);
+   int (*get_vdev_subtype)(struct ath10k *ar,
+   enum wmi_vdev_subtype subtype);
 };
 
 int ath10k_wmi_cmd_send(struct ath10k *ar, struct sk_buff *skb, u32 cmd_id);
@@ -1327,4 +1329,13 @@ ath10k_wmi_pdev_enable_adaptive_cca(struct ath10k *ar, 
u8 enable,
   ar->wmi.cmd->pdev_enable_adaptive_cca_cmdid);
 }
 
+static inline int
+ath10k_wmi_get_vdev_subtype(struct ath10k *ar, enum wmi_vdev_subtype subtype)
+{
+   if (!ar->wmi.ops->get_vdev_subtype)
+   return -EOPNOTSUPP;
+
+   return ar->wmi.ops->get_vdev_subtype(ar, subtype);
+}
+
 #endif
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c 
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 3b3a27b..1085932 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -3483,6 +3483,7 @@ static const struct wmi_ops wmi_tlv_ops = {
.gen_tdls_peer_update = ath10k_wmi_tlv_op_gen_tdls_peer_update,
.gen_adaptive_qcs = ath10k_wmi_tlv_op_gen_adaptive_qcs,
.fw_stats_fill = ath10k_wmi_main_op_fw_stats_fill,
+   .get_vdev_subtype = ath10k_wmi_op_get_vdev_subtype,
 };
 
 sta

[PATCH 3/4] ath10k: use vif->type and vif->p2p for P2P_GO check

[Peter Oh]

Interface type P2P_GO can be checked by either arvif->vdev_type
and arvif->vdev_subtype or vif->type and vif->p2p.
Use later one to avoid more cpu consumption that could happen
when subtype abstraction layer change is introduced.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 8 ++--
 drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 6bf5c91..2940b00 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1358,10 +1358,7 @@ static int ath10k_mac_setup_bcn_p2p_ie(struct ath10k_vif 
*arvif,
const u8 *p2p_ie;
int ret;
 
-   if (arvif->vdev_type != WMI_VDEV_TYPE_AP)
-   return 0;
-
-   if (arvif->vdev_subtype != WMI_VDEV_SUBTYPE_P2P_GO)
+   if (arvif->vif->type != NL80211_IFTYPE_AP || !arvif->vif->p2p)
return 0;
 
mgmt = (void *)bcn->data;
@@ -3259,8 +3256,7 @@ static void ath10k_tx_h_add_p2p_noa_ie(struct ath10k *ar,
struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
 
/* This is case only for P2P_GO */
-   if (arvif->vdev_type != WMI_VDEV_TYPE_AP ||
-   arvif->vdev_subtype != WMI_VDEV_SUBTYPE_P2P_GO)
+   if (vif->type != NL80211_IFTYPE_AP || !vif->p2p)
return;
 
if (unlikely(ieee80211_is_probe_resp(hdr->frame_control))) {
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index a7c3d29..723fb9bc 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3184,7 +3184,7 @@ static void ath10k_wmi_update_noa(struct ath10k *ar, 
struct ath10k_vif *arvif,
  struct sk_buff *bcn,
  const struct wmi_p2p_noa_info *noa)
 {
-   if (arvif->vdev_subtype != WMI_VDEV_SUBTYPE_P2P_GO)
+   if (!arvif->vif->p2p)
return;
 
ath10k_dbg(ar, ATH10K_DBG_MGMT, "noa changed: %d\n", noa->changed);
-- 
1.9.1

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

Re: [PATCH 4/4] ath10k: add abstraction layer for vdev subtype

[Peter Oh]

On 01/27/2016 11:11 AM, Ben Greear wrote:

On 01/27/2016 10:55 AM, Peter Oh wrote:

Abstraction layer for vdev subtype is added to solve
subtype mismatch and to give flexible compatibility
among different firmware revisions.

For instance, 10.2 and 10.4 firmware has different
definition of their vdev subtypes for Mesh.
10.4 defined subtype 6 for 802.11s Mesh while 10.2 uses 5.
Hence use the abstraction API to get right subtype to use.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
  drivers/net/wireless/ath/ath10k/mac.c | 15 ---
  drivers/net/wireless/ath/ath10k/wmi-ops.h | 11 +
  drivers/net/wireless/ath/ath10k/wmi-tlv.c |  1 +
  drivers/net/wireless/ath/ath10k/wmi.c | 70

+++

drivers/net/wireless/ath/ath10k/wmi.h | 42 ---
  5 files changed, 128 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c

b/drivers/net/wireless/ath/ath10k/mac.c

index 2940b00..c9a39ab 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4345,25 +4345,29 @@ static int ath10k_add_interface(struct

ieee80211_hw *hw,

 bit, ar->free_vdev_map);

  arvif->vdev_id = bit;
-arvif->vdev_subtype = WMI_VDEV_SUBTYPE_NONE;
+arvif->vdev_subtype =
+ath10k_wmi_get_vdev_subtype(ar, WMI_VDEV_SUBTYPE_NONE);

  switch (vif->type) {
  case NL80211_IFTYPE_P2P_DEVICE:
  arvif->vdev_type = WMI_VDEV_TYPE_STA;
-arvif->vdev_subtype = WMI_VDEV_SUBTYPE_P2P_DEVICE;
+arvif->vdev_subtype = ath10k_wmi_get_vdev_subtype
+(ar, WMI_VDEV_SUBTYPE_P2P_DEVICE);


Would it maybe be simpler code to just assign these types to the ar 
struct

at
firmware init time.  And then do something like:

arvif->vdev_subtype = ar->p2p_subtype;
Maintaining a variable per subtype doesn't look good since a variable 
can cover subtypes.


Or even maybe:

arvif->vdev_subtype = ar->subtype_for_viftype[vif->type];
if you take a look the abstraction layer, there is different index 
indicating the same subtype.
In that case, your suggestion also needs to maintaining different array 
per FW version which is the same amount of work as this patch.


I'm not sure how much it matters, but in general I find the 
abstraction in

ath10k makes it hard to read through the code.
It cannot help avoiding use it since ath10k supports different chipsets 
and firmware IMO.


Thanks,
Ben



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

Re: [PATCH 0/4] ath10k: rename mesh and add abstraction layer

[Peter Oh]

On 01/27/2016 11:39 AM, Bob Copeland wrote:

On Wed, Jan 27, 2016 at 10:55:53AM -0800, Peter Oh wrote:

Split Mesh service to 11s Mesh and non-11s Mesh according to
firmware service bit to help users distinguish 11s Mesh from
non 11s Mesh.
And add abstraction layer for vdev subtype to solve subtype mismatch
and to give flexible compatibility among different firmware revisions.

Out of curiosity, which non-11s mesh, if you can share?

non-11s Mesh can be anything, but 11s Mesh such as meraki mesh.




--
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 13/13] ath10k: implement push-pull tx

[Peter Oh]

On 01/26/2016 02:28 AM, Michal Kazior wrote:

On 22 January 2016 at 08:47, Michal Kazior <michal.kaz...@tieto.com> wrote:

On 21 January 2016 at 18:40, Peter Oh <p...@codeaurora.org> wrote:

On 01/21/2016 05:46 AM, Michal Kazior wrote:

[...]

   - /* TODO: apply configuration */
+   rcu_read_unlock();
+
+   spin_lock_bh(>htt.tx_lock);
+   ath10k_mac_tx_lock(ar, ATH10K_TX_PAUSE_Q_FLUSH_PENDING);
+   spin_unlock_bh(>htt.tx_lock);
+

Isn't it proved it break Mesh from working?

Yes, good point. I'm still working on this - I should've mentioned
that in the cover letter.

Nonetheless I wanted to get the review process going for this patchset.

I'll address the mesh problem in v2.

For the record - the problem turned out to be a bug in mac80211 mesh
fwding, see:

   https://patchwork.kernel.org/patch/8108711/

I've verified that the patch fixed the mesh issue.
Thank you Michal.



Michał


--
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 13/13] ath10k: implement push-pull tx

[Peter Oh]

On 01/21/2016 05:46 AM, Michal Kazior wrote:

The current/old tx path design was that host, at
its own leisure, pushed tx frames to the device.
For HTT there was ~1000-1400 msdu queue depth.

After reaching that limit the driver would request
mac80211 to stop queues. There was little control
over what packets got in there as far as
DA/RA was considered so it was rather easy to
starve per-station traffic flows.

With MU-MIMO this became a significant problem
because the queue depth was insufficient to buffer
frames from multiple clients (which could have
different signal quality and capabilities) in an
efficient fashion.

Hence the new tx path in 10.4 was introduced: a
pull-push mode.

Firmware and host can share tx queue state via
DMA. The state is logically a 2 dimensional array
addressed via peer_id+tid pair. Each entry is a
counter (either number of bytes or packets. Host
keeps it updated and firmware uses it for
scheduling Tx pull requests to host.

This allows MU-MIMO to become a lot more effective
with 10+ clients.

Signed-off-by: Michal Kazior 
---
  drivers/net/wireless/ath/ath10k/core.h   |   1 +
  drivers/net/wireless/ath/ath10k/htt.h|   6 ++
  drivers/net/wireless/ath/ath10k/htt_rx.c | 117
---
  drivers/net/wireless/ath/ath10k/htt_tx.c |  39 ---
  drivers/net/wireless/ath/ath10k/mac.c|  48 +++--
  drivers/net/wireless/ath/ath10k/mac.h|   5 ++
  6 files changed, 192 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index f51887c6be74..ab8cbccc0f4b 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -307,6 +307,7 @@ struct ath10k_peer {
  
  struct ath10k_txq {

unsigned long num_fw_queued;
+   unsigned long num_push_allowed;
  };
  
  struct ath10k_sta {

diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index b1e40f44e76b..02cf55d306e8 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1652,6 +1652,7 @@ struct ath10k_htt {
struct sk_buff_head tx_compl_q;
struct sk_buff_head rx_compl_q;
struct sk_buff_head rx_in_ord_compl_q;
+   struct sk_buff_head tx_fetch_ind_q;
  
  	/* rx_status template */

struct ieee80211_rx_status rx_status;
@@ -1670,8 +1671,10 @@ struct ath10k_htt {
bool enabled;
struct htt_q_state *vaddr;
dma_addr_t paddr;
+   u16 num_push_allowed;
u16 num_peers;
u16 num_tids;
+   enum htt_tx_mode_switch_mode mode;
enum htt_q_depth_type type;
} tx_q_state;
  };
@@ -1761,6 +1764,9 @@ int ath10k_htt_tx_fetch_resp(struct ath10k *ar,
  
  void ath10k_htt_tx_txq_update(struct ieee80211_hw *hw,

  struct ieee80211_txq *txq);
+void ath10k_htt_tx_txq_recalc(struct ieee80211_hw *hw,
+ struct ieee80211_txq *txq);
+void ath10k_htt_tx_txq_sync(struct ath10k *ar);
  void ath10k_htt_tx_dec_pending(struct ath10k_htt *htt,
   bool is_mgmt);
  int ath10k_htt_tx_inc_pending(struct ath10k_htt *htt,
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 6e3d95c95568..827c8369b589 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -229,6 +229,7 @@ void ath10k_htt_rx_free(struct ath10k_htt *htt)
skb_queue_purge(>tx_compl_q);
skb_queue_purge(>rx_compl_q);
skb_queue_purge(>rx_in_ord_compl_q);
+   skb_queue_purge(>tx_fetch_ind_q);
  
  	ath10k_htt_rx_ring_free(htt);
  
@@ -569,6 +570,7 @@ int ath10k_htt_rx_alloc(struct ath10k_htt *htt)

skb_queue_head_init(>tx_compl_q);
skb_queue_head_init(>rx_compl_q);
skb_queue_head_init(>rx_in_ord_compl_q);
+   skb_queue_head_init(>tx_fetch_ind_q);
  
  	tasklet_init(>txrx_compl_task, ath10k_htt_txrx_compl_task,

 (unsigned long)htt);
@@ -2004,16 +2006,21 @@ static void
ath10k_htt_rx_tx_fetch_resp_id_confirm(struct ath10k *ar,
  
  static void ath10k_htt_rx_tx_fetch_ind(struct ath10k *ar, struct sk_buff

*skb)
  {
+   struct ieee80211_hw *hw = ar->hw;
+   struct ieee80211_txq *txq;
struct htt_resp *resp = (struct htt_resp *)skb->data;
struct htt_tx_fetch_record *record;
size_t len;
size_t max_num_bytes;
size_t max_num_msdus;
+   size_t num_bytes;
+   size_t num_msdus;
const __le32 *resp_ids;
u16 num_records;
u16 num_resp_ids;
u16 peer_id;
u8 tid;
+   int ret;
int i;
  
  	ath10k_dbg(ar, ATH10K_DBG_HTT, "htt rx tx fetch ind\n");

@@ -2039,7 +2046,17 @@ static void ath10k_htt_rx_tx_fetch_ind(struct
ath10k *ar, struct sk_buff *skb)
   

[PATCH] ath10k: Set SM power save disabled to default value

[Peter Oh]

Use SMPS disabled as default because FW does not indicate
any support of SMPS.

This change will help STAs out that don’t support SMPS from
sticking on 1SS, since they don’t have method to change it
back to multiple chains.

This change also should not affect power consumption of STAs
supporting SMPS, because they are capable to switch the mode
to dynamic or static either at the end of frame sequence or
by using SMPS action frame.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index b4bdeb0..6146a29 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3860,7 +3860,8 @@ static struct ieee80211_sta_ht_cap 
ath10k_get_ht_cap(struct ath10k *ar)
ht_cap.ampdu_density = IEEE80211_HT_MPDU_DENSITY_8;
ht_cap.cap |= IEEE80211_HT_CAP_SUP_WIDTH_20_40;
ht_cap.cap |= IEEE80211_HT_CAP_DSSSCCK40;
-   ht_cap.cap |= WLAN_HT_CAP_SM_PS_STATIC << IEEE80211_HT_CAP_SM_PS_SHIFT;
+   ht_cap.cap |=
+   WLAN_HT_CAP_SM_PS_DISABLED << IEEE80211_HT_CAP_SM_PS_SHIFT;
 
if (ar->ht_cap_info & WMI_HT_CAP_HT20_SGI)
ht_cap.cap |= IEEE80211_HT_CAP_SGI_20;
-- 
1.9.1

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

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Peter Oh]

On 12/16/2015 11:29 PM, Michal Kazior wrote:

On 17 December 2015 at 00:50, Peter Oh <p...@codeaurora.org> wrote:

On 12/16/2015 01:54 PM, Felix Fietkau wrote:

On 2015-12-16 22:19, Peter Oh wrote:

[...]

If mentioned to use the function to mesh frame only without touching
mac80211, then how do you suggest it to apply it only to mesh frame
without interfere other data frames?
Can you share your example?

It's trivial - in ath10k_tx you do this:

if (vif->type == NL80211_IFTYPE_MESH_POINT &&
  skb->ip_summed == CHECKSUM_PARTIAL)
 skb_checksum_help(skb);



Thank you Felix for the quick response.
I agree on your user experience opinion,
but what do you think when ath10k has a new chip supporting HW checksum for
Mesh?

You can simply introduce a fw-feature flag saying
"supports_mesh_csum_offload" later and skip the skb_checksum_help() if
it's set.
If we rely on fw-feature flag, then we are not able to use HW checksum 
at all even for AP/STA interfaces.




Michał

Thanks,
Peter
--
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] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Peter Oh]

On 12/16/2015 03:59 PM, Felix Fietkau wrote:

On 2015-12-17 00:50, Peter Oh wrote:

On 12/16/2015 01:54 PM, Felix Fietkau wrote:

On 2015-12-16 22:19, Peter Oh wrote:

On 12/16/2015 12:53 PM, Felix Fietkau wrote:

On 2015-12-16 21:46, Peter Oh wrote:

On 12/16/2015 12:35 PM, Felix Fietkau wrote:

On 2015-12-16 21:29, Peter Oh wrote:

On 12/16/2015 10:27 AM, Felix Fietkau wrote:

On 2015-12-16 19:20, Peter Oh wrote:

Some hardwares such as QCA988X and QCA99X0 doesn't have
capability of checksum offload when frame formats are not
suitable for it such as Mesh frame.
Hence add a module parameter, hw_csum, to make checksum offload
configurable during module registration time.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>

How about instead of inventing yet another crappy module parameter, you
call skb_checksum_help() in the driver in cases where the hardware is
unable to offload the checksum calculation.

That way the user has to worry about less driver specific hackery ;)

That will be good option for hardware not supporting HW checksum, but I
mind that using the function will add more workload per every packet on
critical data path when HW supports checksum resulting in throughput down.

I didn't mean calling it for every single frame in the data path.
What I'm suggesting is calling it selectively only for mesh frames, or
any other frames that the hardware cannot offload, and leaving the rest
for the hardware to process.

There should be no performance difference between disabling checksum
offload and calling skb_checksum_help from the driver.

To call it selectively for Mesh frame or interface, we need to add it on
mac80211 layer such as ieee80211_build_hdr() since driver layer does not
care the interface type in data path.

No need to change mac80211 - it only touches the headers, and
skb_checksum_help does not care about that. The skb has enough
information for it to find the right range to calculate the checksum and
the place to store it.

If mentioned to use the function to mesh frame only without touching
mac80211, then how do you suggest it to apply it only to mesh frame
without interfere other data frames?
Can you share your example?

It's trivial - in ath10k_tx you do this:

if (vif->type == NL80211_IFTYPE_MESH_POINT &&
  skb->ip_summed == CHECKSUM_PARTIAL)
skb_checksum_help(skb);

Thank you Felix for the quick response.
I agree on your user experience opinion,
but what do you think when ath10k has a new chip supporting HW checksum
for Mesh?

Then you simply update the checks. What's the big deal?

keep adding condition to such data path is not a good option.
I also considered again about user experiences and reached to that this 
patch won't disturb user experience since the products will ship with 
proper module settings. for instance the parameter will be turned on if 
product support it other wise will be turned off as they shipped, so 
that users don't need to touch it.
In addition, for enterprise customers, they do care even a very small 
performance drop or enhancement especially when they are running BMT 
among vendors.

So we need to avoid adding extra codes in data path in my opinion.

- 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: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Peter Oh]

On 12/17/2015 02:57 PM, Felix Fietkau wrote:

On 2015-12-17 23:01, Peter Oh wrote:

On 12/16/2015 03:59 PM, Felix Fietkau wrote:

On 2015-12-17 00:50, Peter Oh wrote:

On 12/16/2015 01:54 PM, Felix Fietkau wrote:

On 2015-12-16 22:19, Peter Oh wrote:

On 12/16/2015 12:53 PM, Felix Fietkau wrote:

On 2015-12-16 21:46, Peter Oh wrote:

On 12/16/2015 12:35 PM, Felix Fietkau wrote:

On 2015-12-16 21:29, Peter Oh wrote:

On 12/16/2015 10:27 AM, Felix Fietkau wrote:

On 2015-12-16 19:20, Peter Oh wrote:

Some hardwares such as QCA988X and QCA99X0 doesn't have
capability of checksum offload when frame formats are not
suitable for it such as Mesh frame.
Hence add a module parameter, hw_csum, to make checksum offload
configurable during module registration time.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>

How about instead of inventing yet another crappy module parameter, you
call skb_checksum_help() in the driver in cases where the hardware is
unable to offload the checksum calculation.

That way the user has to worry about less driver specific hackery ;)

That will be good option for hardware not supporting HW checksum, but I
mind that using the function will add more workload per every packet on
critical data path when HW supports checksum resulting in throughput down.

I didn't mean calling it for every single frame in the data path.
What I'm suggesting is calling it selectively only for mesh frames, or
any other frames that the hardware cannot offload, and leaving the rest
for the hardware to process.

There should be no performance difference between disabling checksum
offload and calling skb_checksum_help from the driver.

To call it selectively for Mesh frame or interface, we need to add it on
mac80211 layer such as ieee80211_build_hdr() since driver layer does not
care the interface type in data path.

No need to change mac80211 - it only touches the headers, and
skb_checksum_help does not care about that. The skb has enough
information for it to find the right range to calculate the checksum and
the place to store it.

If mentioned to use the function to mesh frame only without touching
mac80211, then how do you suggest it to apply it only to mesh frame
without interfere other data frames?
Can you share your example?

It's trivial - in ath10k_tx you do this:

if (vif->type == NL80211_IFTYPE_MESH_POINT &&
   skb->ip_summed == CHECKSUM_PARTIAL)
skb_checksum_help(skb);

Thank you Felix for the quick response.
I agree on your user experience opinion,
but what do you think when ath10k has a new chip supporting HW checksum
for Mesh?

Then you simply update the checks. What's the big deal?

keep adding condition to such data path is not a good option.
I also considered again about user experiences and reached to that this
patch won't disturb user experience since the products will ship with
proper module settings. for instance the parameter will be turned on if
product support it other wise will be turned off as they shipped, so
that users don't need to touch it.

I think the point you were missing is the one that there is no such
thing as a proper setting for this module parameter, since it doesn't
really depend much on the hardware or the product, but on the wifi mode
that you are using.


In addition, for enterprise customers, they do care even a very small
performance drop or enhancement especially when they are running BMT
among vendors.
So we need to avoid adding extra codes in data path in my opinion.

The regular data tx path already checks ar->dev_flags to decide whether
to use raw mode or not. This means that this part of the data structure
is already cached. The vif type is also cached, since it's accessed in
the same part of the function.
Because of that, the impact of adding an extra check even for a hardware
capability will be so low, that I'm pretty sure you will not be able to
measure it. And even if it were measurable, it's probably quite easy to
find a few places to optimize

I find the tradeoff you are making very odd: For users that don't know
about the module parameter (depending on the default value) it either
just randomly doesn't work in mesh or always runs with degraded
performance. All this to save adding a check that will be completely
irrelevant for performance, since it won't result in any extra cache
stalls (which are the typical bottleneck in the data path).

Thank you for your comments and ideas.
I'll spend more time to lead better solution based on you & Michal's 
feedback.

- Felix

Peter
--
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] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Peter Oh]

On 12/16/2015 10:27 AM, Felix Fietkau wrote:

On 2015-12-16 19:20, Peter Oh wrote:

Some hardwares such as QCA988X and QCA99X0 doesn't have
capability of checksum offload when frame formats are not
suitable for it such as Mesh frame.
Hence add a module parameter, hw_csum, to make checksum offload
configurable during module registration time.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>

How about instead of inventing yet another crappy module parameter, you
call skb_checksum_help() in the driver in cases where the hardware is
unable to offload the checksum calculation.

That way the user has to worry about less driver specific hackery ;)
That will be good option for hardware not supporting HW checksum, but I 
mind that using the function will add more workload per every packet on 
critical data path when HW supports checksum resulting in throughput down.

- 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

Thanks,
Peter
--
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] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Peter Oh]

On 12/16/2015 12:35 PM, Felix Fietkau wrote:

On 2015-12-16 21:29, Peter Oh wrote:

On 12/16/2015 10:27 AM, Felix Fietkau wrote:

On 2015-12-16 19:20, Peter Oh wrote:

Some hardwares such as QCA988X and QCA99X0 doesn't have
capability of checksum offload when frame formats are not
suitable for it such as Mesh frame.
Hence add a module parameter, hw_csum, to make checksum offload
configurable during module registration time.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>

How about instead of inventing yet another crappy module parameter, you
call skb_checksum_help() in the driver in cases where the hardware is
unable to offload the checksum calculation.

That way the user has to worry about less driver specific hackery ;)

That will be good option for hardware not supporting HW checksum, but I
mind that using the function will add more workload per every packet on
critical data path when HW supports checksum resulting in throughput down.

I didn't mean calling it for every single frame in the data path.
What I'm suggesting is calling it selectively only for mesh frames, or
any other frames that the hardware cannot offload, and leaving the rest
for the hardware to process.

There should be no performance difference between disabling checksum
offload and calling skb_checksum_help from the driver.
To call it selectively for Mesh frame or interface, we need to add it on 
mac80211 layer such as ieee80211_build_hdr() since driver layer does not 
care the interface type in data path.
In that case it will also introduce throughput degrade to HW that 
supports HW checksum for Mesh.

- 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

Thanks,
Peter
--
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] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Peter Oh]

Some hardwares such as QCA988X and QCA99X0 doesn't have
capability of checksum offload when frame formats are not
suitable for it such as Mesh frame.
Hence add a module parameter, hw_csum, to make checksum offload
configurable during module registration time.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 6 ++
 drivers/net/wireless/ath/ath10k/core.h | 3 +++
 drivers/net/wireless/ath/ath10k/mac.c  | 3 ++-
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index fca702c..fcfccd8 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -35,18 +35,21 @@ static unsigned int ath10k_cryptmode_param;
 static bool uart_print;
 static bool skip_otp;
 static bool rawmode;
+static bool hw_csum = true;
 
 module_param_named(debug_mask, ath10k_debug_mask, uint, 0644);
 module_param_named(cryptmode, ath10k_cryptmode_param, uint, 0644);
 module_param(uart_print, bool, 0644);
 module_param(skip_otp, bool, 0644);
 module_param(rawmode, bool, 0644);
+module_param(hw_csum, bool, 0644);
 
 MODULE_PARM_DESC(debug_mask, "Debugging mask");
 MODULE_PARM_DESC(uart_print, "Uart target debugging");
 MODULE_PARM_DESC(skip_otp, "Skip otp failure for calibration in testmode");
 MODULE_PARM_DESC(cryptmode, "Crypto mode: 0-hardware, 1-software");
 MODULE_PARM_DESC(rawmode, "Use raw 802.11 frame datapath");
+MODULE_PARM_DESC(hw_csum, "Enable HW checksum offload (default: on)");
 
 static const struct ath10k_hw_params ath10k_hw_params_list[] = {
{
@@ -1405,6 +1408,9 @@ static int ath10k_core_init_firmware_features(struct 
ath10k *ar)
ar->htt.max_num_amsdu = 1;
}
 
+   if (!hw_csum)
+   set_bit(ATH10K_FLAG_HW_CSUM_DISABLED, >dev_flags);
+
/* Backwards compatibility for firmwares without
 * ATH10K_FW_IE_WMI_OP_VERSION.
 */
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 3c8a510..1972439 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -535,6 +535,9 @@ enum ath10k_dev_flags {
 
/* Bluetooth coexistance enabled */
ATH10K_FLAG_BTCOEX,
+
+   /* Do not use checksum offload */
+   ATH10K_FLAG_HW_CSUM_DISABLED,
 };
 
 enum ath10k_cal_mode {
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index a4c5c1d..f87f521 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7332,7 +7332,8 @@ int ath10k_mac_register(struct ath10k *ar)
goto err_free;
}
 
-   if (!test_bit(ATH10K_FLAG_RAW_MODE, >dev_flags))
+   if (!test_bit(ATH10K_FLAG_RAW_MODE, >dev_flags) &&
+   !test_bit(ATH10K_FLAG_HW_CSUM_DISABLED, >dev_flags))
ar->hw->netdev_features = NETIF_F_HW_CSUM;
 
if (config_enabled(CONFIG_ATH10K_DFS_CERTIFIED)) {
-- 
1.9.1

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

Re: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Peter Oh]

On 12/16/2015 12:53 PM, Felix Fietkau wrote:

On 2015-12-16 21:46, Peter Oh wrote:

On 12/16/2015 12:35 PM, Felix Fietkau wrote:

On 2015-12-16 21:29, Peter Oh wrote:

On 12/16/2015 10:27 AM, Felix Fietkau wrote:

On 2015-12-16 19:20, Peter Oh wrote:

Some hardwares such as QCA988X and QCA99X0 doesn't have
capability of checksum offload when frame formats are not
suitable for it such as Mesh frame.
Hence add a module parameter, hw_csum, to make checksum offload
configurable during module registration time.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>

How about instead of inventing yet another crappy module parameter, you
call skb_checksum_help() in the driver in cases where the hardware is
unable to offload the checksum calculation.

That way the user has to worry about less driver specific hackery ;)

That will be good option for hardware not supporting HW checksum, but I
mind that using the function will add more workload per every packet on
critical data path when HW supports checksum resulting in throughput down.

I didn't mean calling it for every single frame in the data path.
What I'm suggesting is calling it selectively only for mesh frames, or
any other frames that the hardware cannot offload, and leaving the rest
for the hardware to process.

There should be no performance difference between disabling checksum
offload and calling skb_checksum_help from the driver.

To call it selectively for Mesh frame or interface, we need to add it on
mac80211 layer such as ieee80211_build_hdr() since driver layer does not
care the interface type in data path.

No need to change mac80211 - it only touches the headers, and
skb_checksum_help does not care about that. The skb has enough
information for it to find the right range to calculate the checksum and
the place to store it.
If mentioned to use the function to mesh frame only without touching 
mac80211, then how do you suggest it to apply it only to mesh frame 
without interfere other data frames?

Can you share your example?



In that case it will also introduce throughput degrade to HW that
supports HW checksum for Mesh.

This doesn't make any sense to me. Are you saying that there's no way
for the driver to detect the cases where the hardware cannot do checksum
offloading?
I'm saying the case that HW supports checksum except for specific frame 
such as Mesh and to make driver support both case dynamically at code 
level, it requires extra codes which need to check if the frame is Mesh 
or not. Since this approach requires extra workload especially in data 
path, it will degrade driver's performance.

  How is the user supposed to know when to change that module
parameter? Trial and error?

- 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: [PATCH] ath10k: add modparam 'hw_csum' to make HW checksum configurable

[Peter Oh]

On 12/16/2015 01:54 PM, Felix Fietkau wrote:

On 2015-12-16 22:19, Peter Oh wrote:

On 12/16/2015 12:53 PM, Felix Fietkau wrote:

On 2015-12-16 21:46, Peter Oh wrote:

On 12/16/2015 12:35 PM, Felix Fietkau wrote:

On 2015-12-16 21:29, Peter Oh wrote:

On 12/16/2015 10:27 AM, Felix Fietkau wrote:

On 2015-12-16 19:20, Peter Oh wrote:

Some hardwares such as QCA988X and QCA99X0 doesn't have
capability of checksum offload when frame formats are not
suitable for it such as Mesh frame.
Hence add a module parameter, hw_csum, to make checksum offload
configurable during module registration time.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>

How about instead of inventing yet another crappy module parameter, you
call skb_checksum_help() in the driver in cases where the hardware is
unable to offload the checksum calculation.

That way the user has to worry about less driver specific hackery ;)

That will be good option for hardware not supporting HW checksum, but I
mind that using the function will add more workload per every packet on
critical data path when HW supports checksum resulting in throughput down.

I didn't mean calling it for every single frame in the data path.
What I'm suggesting is calling it selectively only for mesh frames, or
any other frames that the hardware cannot offload, and leaving the rest
for the hardware to process.

There should be no performance difference between disabling checksum
offload and calling skb_checksum_help from the driver.

To call it selectively for Mesh frame or interface, we need to add it on
mac80211 layer such as ieee80211_build_hdr() since driver layer does not
care the interface type in data path.

No need to change mac80211 - it only touches the headers, and
skb_checksum_help does not care about that. The skb has enough
information for it to find the right range to calculate the checksum and
the place to store it.

If mentioned to use the function to mesh frame only without touching
mac80211, then how do you suggest it to apply it only to mesh frame
without interfere other data frames?
Can you share your example?

It's trivial - in ath10k_tx you do this:

if (vif->type == NL80211_IFTYPE_MESH_POINT &&
 skb->ip_summed == CHECKSUM_PARTIAL)
skb_checksum_help(skb);

Thank you Felix for the quick response.
I agree on your user experience opinion,
but what do you think when ath10k has a new chip supporting HW checksum 
for Mesh?

In that case it will also introduce throughput degrade to HW that
supports HW checksum for Mesh.

This doesn't make any sense to me. Are you saying that there's no way
for the driver to detect the cases where the hardware cannot do checksum
offloading?

I'm saying the case that HW supports checksum except for specific frame
such as Mesh and to make driver support both case dynamically at code
level, it requires extra codes which need to check if the frame is Mesh
or not. Since this approach requires extra workload especially in data
path, it will degrade driver's performance.

The check is cheap enough that it will not have any visible impact. And
the improved user experience is certainly worth it ;)

- Felix

Thanks,
Peter
--
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] ath10k: allow Mesh Point to install peer security key

[Peter Oh]

Mesh Point requires peer security key install when running
in secured mode since it's a type of peer links, otherwise peer
link will be removed due to key install failure.

MFP feature set is required to run Mesh in secured mode and
QCA988X firmware, 10.2.4.70.14-2 and above, is the only one
supporting secured Mesh at this moment.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index bcb364d..b4bdeb0 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -250,7 +250,8 @@ static int ath10k_install_peer_wep_keys(struct ath10k_vif 
*arvif,
lockdep_assert_held(>conf_mutex);
 
if (WARN_ON(arvif->vif->type != NL80211_IFTYPE_AP &&
-   arvif->vif->type != NL80211_IFTYPE_ADHOC))
+   arvif->vif->type != NL80211_IFTYPE_ADHOC &&
+   arvif->vif->type != NL80211_IFTYPE_MESH_POINT))
return -EINVAL;
 
spin_lock_bh(>data_lock);
-- 
1.9.1

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

Re: [PATCH] ath10k: deliver mgmt frames from htt to monitor vifs only

[Peter Oh]

On 11/30/2015 04:56 AM, Grzegorz Bajorski wrote:

Until now only WMI originating mgmt frames were
reported to mac80211. Management frames on HTT
were basically dropped (except frames which looked
like management but had FCS error).

To allow sniffing all frames (including offloaded
frames) without interfering with mac80211
operation and states a new rx_flag was introduced
and is not being used to distinguish frames and
classify them for mac80211.

Does this change valid for all the firmware 10.1, 10.2, 10.4, and etc.?


Signed-off-by: Grzegorz Bajorski 
---
depends on:
mac80211: allow drivers to report (non-)monitor frames

  drivers/net/wireless/ath/ath10k/htt_rx.c | 70

  drivers/net/wireless/ath/ath10k/wmi.c|  6 +++
  2 files changed, 40 insertions(+), 36 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 396645b..898eff0 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1076,20 +1076,25 @@ static void ath10k_htt_rx_h_undecap_raw(struct
ath10k *ar,
hdr = (void *)msdu->data;
  
  	/* Tail */

-   skb_trim(msdu, msdu->len - ath10k_htt_rx_crypto_tail_len(ar,
enctype));
+   if (status->flag & RX_FLAG_IV_STRIPPED)
+   skb_trim(msdu, msdu->len -
+ath10k_htt_rx_crypto_tail_len(ar, enctype));
  
  	/* MMIC */

-   if (!ieee80211_has_morefrags(hdr->frame_control) &&
+   if ((status->flag & RX_FLAG_MMIC_STRIPPED) &&
+   !ieee80211_has_morefrags(hdr->frame_control) &&
enctype == HTT_RX_MPDU_ENCRYPT_TKIP_WPA)
skb_trim(msdu, msdu->len - 8);
  
  	/* Head */

-   hdr_len = ieee80211_hdrlen(hdr->frame_control);
-   crypto_len = ath10k_htt_rx_crypto_param_len(ar, enctype);
+   if (status->flag & RX_FLAG_IV_STRIPPED) {
+   hdr_len = ieee80211_hdrlen(hdr->frame_control);
+   crypto_len = ath10k_htt_rx_crypto_param_len(ar, enctype);
  
-	memmove((void *)msdu->data + crypto_len,

-   (void *)msdu->data, hdr_len);
-   skb_pull(msdu, crypto_len);
+   memmove((void *)msdu->data + crypto_len,
+   (void *)msdu->data, hdr_len);
+   skb_pull(msdu, crypto_len);
+   }
  }
  
  static void ath10k_htt_rx_h_undecap_nwifi(struct ath10k *ar,

@@ -1330,6 +1335,7 @@ static void ath10k_htt_rx_h_mpdu(struct ath10k *ar,
bool has_tkip_err;
bool has_peer_idx_invalid;
bool is_decrypted;
+   bool is_mgmt;
u32 attention;
  
  	if (skb_queue_empty(amsdu))

@@ -1338,6 +1344,9 @@ static void ath10k_htt_rx_h_mpdu(struct ath10k *ar,
first = skb_peek(amsdu);
rxd = (void *)first->data - sizeof(*rxd);
  
+	is_mgmt = !!(rxd->attention.flags &

+__cpu_to_le32(RX_ATTENTION_FLAGS_MGMT_TYPE));
+
enctype = MS(__le32_to_cpu(rxd->mpdu_start.info0),
 RX_MPDU_START_INFO0_ENCRYPT_TYPE);
  
@@ -1379,6 +1388,7 @@ static void ath10k_htt_rx_h_mpdu(struct ath10k *ar,

  RX_FLAG_MMIC_ERROR |
  RX_FLAG_DECRYPTED |
  RX_FLAG_IV_STRIPPED |
+ RX_FLAG_ONLY_MONITOR |
  RX_FLAG_MMIC_STRIPPED);
  
  	if (has_fcs_err)

@@ -1387,10 +1397,21 @@ static void ath10k_htt_rx_h_mpdu(struct ath10k
*ar,
if (has_tkip_err)
status->flag |= RX_FLAG_MMIC_ERROR;
  
-	if (is_decrypted)

-   status->flag |= RX_FLAG_DECRYPTED |
-   RX_FLAG_IV_STRIPPED |
-   RX_FLAG_MMIC_STRIPPED;
+   /* Firmware reports all necessary management frames via WMI
already.
+* They are not reported to monitor interfaces at all so pass the
ones
+* coming via HTT to monitor interfaces instead. This simplifies
+* matters a lot.
+*/
+   if (is_mgmt)
+   status->flag |= RX_FLAG_ONLY_MONITOR;
+
+   if (is_decrypted) {
+   status->flag |= RX_FLAG_DECRYPTED;
+
+   if (likely(!is_mgmt))
+   status->flag |= RX_FLAG_IV_STRIPPED |
+   RX_FLAG_MMIC_STRIPPED;

Management frames are encrypted in MFP condition.
This change seems breaking MFP frame from working.

+}
  
  	skb_queue_walk(amsdu, msdu) {

ath10k_htt_rx_h_csum_offload(msdu);
@@ -1403,6 +1424,8 @@ static void ath10k_htt_rx_h_mpdu(struct ath10k *ar,
 */
if (!is_decrypted)
continue;
+   if (is_mgmt)
+   continue;

Ditto.
Could you provide test results in MFP case?
  
  		hdr = (void *)msdu->data;

hdr->frame_control &=
~__cpu_to_le16(IEEE80211_FCTL_PROTECTED);
@@ -1503,14 +1526,6 @@ static bool ath10k_htt_rx_amsdu_allowed(struct
ath10k *ar,
   

Re: [PATCH 1/3] ath10k: update WMI 10.x service map

[Peter Oh]

I believe the robot report is false.
Am I right?

Thanks,
Peter
On 11/24/2015 01:19 PM, kbuild test robot wrote:

Hi Peter,

[auto build test WARNING on net-next/master]
[also build test WARNING on v4.4-rc2 next-20151124]

url:
https://github.com/0day-ci/linux/commits/Peter-Oh/ath10k-introduce-Mesh-su
pport-in-native-WiFi-mode-for-QCA988X/20151125-014059
config: m68k-allmodconfig (attached as .config)
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=m68k

All warnings (new ones prefixed by >>):

In file included from include/linux/bitops.h:36:0,
 from include/linux/kernel.h:10,
 from include/asm-generic/bug.h:13,
 from arch/m68k/include/asm/bug.h:28,
 from include/linux/bug.h:4,
 from include/net/mac80211.h:18,
 from drivers/net/wireless/ath/ath10k/mac.h:21,
 from drivers/net/wireless/ath/ath10k/mac.c:18:
drivers/net/wireless/ath/ath10k/wmi.h: In function 'wmi_10x_svc_map':
drivers/net/wireless/ath/ath10k/wmi.h:457:9: error: 'WMI_SERVICE_MESH'
undeclared (first use in this function)
 WMI_SERVICE_MESH, len);
 ^
arch/m68k/include/asm/bitops.h:63:50: note: in definition of macro
'set_bit'
 #define set_bit(nr, vaddr) (__builtin_constant_p(nr) ? \
  ^

drivers/net/wireless/ath/ath10k/wmi.h:398:4: note: in expansion of

macro '__set_bit'
__set_bit(y, out); \
^

drivers/net/wireless/ath/ath10k/wmi.h:456:2: note: in expansion of

macro 'SVCMAP'
  SVCMAP(WMI_10X_SERVICE_MESH,
  ^
drivers/net/wireless/ath/ath10k/wmi.h:457:9: note: each undeclared
identifier is reported only once for each function it appears in
 WMI_SERVICE_MESH, len);
 ^
arch/m68k/include/asm/bitops.h:63:50: note: in definition of macro
'set_bit'
 #define set_bit(nr, vaddr) (__builtin_constant_p(nr) ? \
  ^

drivers/net/wireless/ath/ath10k/wmi.h:398:4: note: in expansion of

macro '__set_bit'
__set_bit(y, out); \
^

drivers/net/wireless/ath/ath10k/wmi.h:456:2: note: in expansion of

macro 'SVCMAP'
  SVCMAP(WMI_10X_SERVICE_MESH,
  ^
drivers/net/wireless/ath/ath10k/wmi.h:459:9: error:
'WMI_SERVICE_EXT_RES_CFG_SUPPORT' undeclared (first use in this function)
 WMI_SERVICE_EXT_RES_CFG_SUPPORT, len);
 ^
arch/m68k/include/asm/bitops.h:63:50: note: in definition of macro
'set_bit'
 #define set_bit(nr, vaddr) (__builtin_constant_p(nr) ? \
  ^

drivers/net/wireless/ath/ath10k/wmi.h:398:4: note: in expansion of

macro '__set_bit'
__set_bit(y, out); \
^
drivers/net/wireless/ath/ath10k/wmi.h:458:2: note: in expansion of
macro 'SVCMAP'
  SVCMAP(WMI_10X_SERVICE_EXT_RES_CFG_SUPPORT,
  ^

vim +/__set_bit +398 drivers/net/wireless/ath/ath10k/wmi.h

37b9f933 Michal Kazior 2014-11-27  392
__le32_to_cpu((wmi_svc_bmap)[(svc_id)/(sizeof(u32))]) & \
cff990ce Michal Kazior 2014-08-04  393
BIT((svc_id)%(sizeof(u32
cff990ce Michal Kazior 2014-08-04  394
37b9f933 Michal Kazior 2014-11-27  395  #define SVCMAP(x, y, len) \
cff990ce Michal Kazior 2014-08-04  396  do { \
37b9f933 Michal Kazior 2014-11-27  397  if
(WMI_SERVICE_IS_ENABLED((in), (x), (len))) \
cff990ce Michal Kazior 2014-08-04 @398
__set_bit(y, out); \
cff990ce Michal Kazior 2014-08-04  399  } while (0)
cff990ce Michal Kazior 2014-08-04  400
37b9f933 Michal Kazior 2014-11-27  401  static inline void
wmi_10x_svc_map(const __le32 *in, unsigned long *out,
37b9f933 Michal Kazior 2014-11-27  402
size_t len)
cff990ce Michal Kazior 2014-08-04  403  {
cff990ce Michal Kazior 2014-08-04  404
SVCMAP(WMI_10X_SERVICE_BEACON_OFFLOAD,
37b9f933 Michal Kazior 2014-11-27  405
WMI_SERVICE_BEACON_OFFLOAD, len);
cff990ce Michal Kazior 2014-08-04  406
SVCMAP(WMI_10X_SERVICE_SCAN_OFFLOAD,
37b9f933 Michal Kazior 2014-11-27  407
WMI_SERVICE_SCAN_OFFLOAD, len);
cff990ce Michal Kazior 2014-08-04  408
SVCMAP(WMI_10X_SERVICE_ROAM_OFFLOAD,
37b9f933 Michal Kazior 2014-11-27  409
WMI_SERVICE_ROAM_OFFLOAD, len);
cff990ce Michal Kazior 2014-08-04  410
SVCMAP(WMI_10X_SERVICE_BCN_MISS_OFFLOAD,
37b9f933 Michal Kazior 2014-11-27  411
WMI_SERVICE_BCN_MISS_OFFLOAD, len);
cff990ce Michal Kazior 2014-08-04  412
SVCMAP(WMI_10X_SERVICE_STA_PWRSAVE,
37b9f933 Michal Kazior 2014-11-27  413
WMI_SERVICE_STA_PWRSAVE, len);
cff990ce Michal Kazior 2014-08-04  414
SVCMAP(WMI_10X_SERVICE_STA_ADVANCED_PWRSAVE,
37b9f933 Michal Kazior 2014-11-27  415
WMI_SERVICE_STA_ADVANCED_PWRSAVE, len);
cff990ce Michal Kazior 2014-08-04  416
SVCMAP(WMI_10X_SERVIC

[PATCH 2/3] ath10k: introduce new subtypes for proxy STA and Mesh

[Peter Oh]

QCA988X firmware starting from 10.2.4.70.12-2 supports new
vdev subtypes for proxy STA and Mesh, hence add them to be used
as needed.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 0747055..d85ad78 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4274,6 +4274,8 @@ enum wmi_vdev_subtype {
WMI_VDEV_SUBTYPE_P2P_DEVICE = 1,
WMI_VDEV_SUBTYPE_P2P_CLIENT = 2,
WMI_VDEV_SUBTYPE_P2P_GO = 3,
+   WMI_VDEV_SUBTYPE_PROXY_STA  = 4,
+   WMI_VDEV_SUBTYPE_MESH   = 5,
 };
 
 /* values for vdev_subtype */
-- 
1.9.1

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

[PATCH 3/3] ath10k: apply Mesh subtype when Mesh interface created.

[Peter Oh]

QCA988X firmware starting from 10.2.4.70.12-2 has capability to support
Mesh Control Field Present bit in QoS field in native Wi-Fi mode.
Hence apply Mesh subtype according to the WMI service map.

Firmware will allows unicast, broadcast, multicast, and WDS frame
(FromDS = 1 and ToDS = 1) to be received via the interface, once Mesh
subtype is used.

The firmware and this patch together make native Wi-Fi mode comply to
IEEE802.11s Mesh frame in open mode, but the firmware doesn't yet
support secured Mesh mode.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 6637854..6d151a2 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4361,7 +4361,9 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
arvif->vdev_type = WMI_VDEV_TYPE_IBSS;
break;
case NL80211_IFTYPE_MESH_POINT:
-   if (!test_bit(ATH10K_FLAG_RAW_MODE, >dev_flags)) {
+   if (test_bit(WMI_SERVICE_MESH, ar->wmi.svc_map)) {
+   arvif->vdev_subtype = WMI_VDEV_SUBTYPE_MESH;
+   } else if (!test_bit(ATH10K_FLAG_RAW_MODE, >dev_flags)) {
ret = -EINVAL;
ath10k_warn(ar, "must load driver with rawmode=1 to add 
mesh interfaces\n");
goto err;
-- 
1.9.1

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

[PATCH 1/3] ath10k: update WMI 10.x service map

[Peter Oh]

Update WMI 10.x service map to sync with firmware 10.2.4.70.12-2
released on 11/11/2015 which is the latest QCA988X firmware as of
11/18/2015.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 80d3f1c..0747055 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -208,6 +208,11 @@ enum wmi_10x_service {
WMI_10X_SERVICE_SMART_ANTENNA_HW_SUPPORT,
WMI_10X_SERVICE_ATF,
WMI_10X_SERVICE_COEX_GPIO,
+   WMI_10X_SERVICE_AUX_SPECTRAL_INTF,
+   WMI_10X_SERVICE_AUX_CHAN_LOAD_INTF,
+   WMI_10X_SERVICE_BSS_CHANNEL_INFO_64,
+   WMI_10X_SERVICE_MESH,
+   WMI_10X_SERVICE_EXT_RES_CFG_SUPPORT,
 };
 
 enum wmi_main_service {
@@ -448,6 +453,16 @@ static inline void wmi_10x_svc_map(const __le32 *in, 
unsigned long *out,
   WMI_SERVICE_ATF, len);
SVCMAP(WMI_10X_SERVICE_COEX_GPIO,
   WMI_SERVICE_COEX_GPIO, len);
+   SVCMAP(WMI_10X_SERVICE_AUX_SPECTRAL_INTF,
+  WMI_SERVICE_AUX_SPECTRAL_INTF, len);
+   SVCMAP(WMI_10X_SERVICE_AUX_CHAN_LOAD_INTF,
+  WMI_SERVICE_AUX_CHAN_LOAD_INTF, len);
+   SVCMAP(WMI_10X_SERVICE_BSS_CHANNEL_INFO_64,
+  WMI_SERVICE_BSS_CHANNEL_INFO_64, len);
+   SVCMAP(WMI_10X_SERVICE_MESH,
+  WMI_SERVICE_MESH, len);
+   SVCMAP(WMI_10X_SERVICE_EXT_RES_CFG_SUPPORT,
+  WMI_SERVICE_EXT_RES_CFG_SUPPORT, len);
 }
 
 static inline void wmi_main_svc_map(const __le32 *in, unsigned long *out,
-- 
1.9.1

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

[PATCH 0/3] ath10k: introduce Mesh support in native WiFi mode for QCA988X

[Peter Oh]

QCA988X firmware has started supporting Mesh frame in native Wi-Fi mode
by adding its subtype since 10.2.4.70.12-2.
Hence update its WMI service map and vdev subtypes to be used for Mesh in
native Wi-Fi mode.

Peter Oh (3):
  ath10k: update WMI 10.x service map
  ath10k: introduce new subtypes for proxy STA and Mesh
  ath10k: apply Mesh subtype when Mesh interface created.

 drivers/net/wireless/ath/ath10k/mac.c |  4 +++-
 drivers/net/wireless/ath/ath10k/wmi.h | 17 +
 2 files changed, 20 insertions(+), 1 deletion(-)

-- 
1.9.1

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

[PATCH] ath10k: fix board data fetch error message

[Peter Oh]

The error message order of board data fetch is board info,
directory, and then file name, hence place print arguments
in the order.

Fixes: 0a51b343abfe ("ath10k: add board 2 API support")
Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index dc4fc4e..6b5ece7 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -844,7 +844,7 @@ out:
if (!ar->board_data || !ar->board_len) {
ath10k_err(ar,
   "failed to fetch board data for %s from %s/%s\n",
-  ar->hw_params.fw.dir, boardname, filename);
+  boardname, ar->hw_params.fw.dir, filename);
ret = -ENODATA;
goto err;
}
-- 
1.9.1

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

Re: [PATCH v2] cfg80211: add VHT support for Mesh

[Peter Oh]

On 11/12/2015 11:37 PM, Johannes Berg wrote:

On Thu, 2015-11-12 at 15:05 -0800, Peter Oh wrote:

On 11/12/2015 02:32 PM, Johannes Berg wrote:

On Thu, 2015-11-12 at 14:28 -0800, Peter Oh wrote:
   
Exactly the same communication mechanism and purpose are used

with
NL80211_EXT_FEATURE_VHT_IBSS which is already a part of NL80211
feature
flag.
The new feature flag, NL80211_EXT_FEATURE_VHT_MESH, follows the
same
purpose and usage.

No, it doesn't. Check how the _IBSS one is used in the code to
actually
*do* something.

that's right. so take a look reset of explanation for this patch.


Still not making sense.

I *suspect* that you think that the existing code is broken, and can't
use VHT mesh and requires driver changes for it,
I'm saying, cannot use VHT Mesh by wpa_supplicant because a lack of 
communication method between driver and wpa_supplicant, hence extending 
NL80211 feature flag.

  but that's not what
your ath10k change shows since it also does nothing at all.
ath10k is advertising its VHT Mesh capability using NL80211 feature flag 
in the patch which wpa_supplicant can listen and catch up.


Right now, I see no reason whatsoever to apply either one of those two
patches. There are no functional changes, so wpa_supplicant could
enable VHT mesh by checking VHT capabilities or so instead of a special
feature flag.
You're asking wpa_supplicant enhancement which is not fair to engineers 
that did not involve the design implementation.
Also if you think Mesh should check VHT capabilities instead of a 
special feature flag, you had to ask the same thing to _VHT_IBSS.
_VHT_IBSS feature flag is also used to advertise driver's capability of 
VHT for IBSS instead of checking driver's information elements.
if IBSS had read VHT capability from driver's IE, _VHT_IBSS flag used at 
nl80211_join_ibss also shouldn't have existed.


I also suspect that perhaps mesh *should* be checking like IBSS does,
although I also would actually *prefer* that we can assume VHT mesh
works if the driver advertises VHT support and mesh support separately,
i.e. a new feature flag really isn't necessary.
Both IBSS and Mesh may support VHT without any feature flags. However 
this patch's approach is come from _VHT_IBSS feature flag which you 
already approved and so exists on upstream.
If you're asking not to use _VHT_MESH feature flag and look for another 
way, your request affects to wpa_supplicant design of ibss and mesh, 
since mesh and ibss frequency info are handled at the same function and 
the function is designed to use _VHT_IBSS feature flag. If Mesh cannot 
use the _VHT_MESH feature flag, the design of function cannot keep the 
consistency of capability check.


If you're saying _VHT_MESH feature flag is different from _VHT_IBSS 
because of what it is doing at nl80211_join_ibss function, I will add 
another patch to nl80211_join_mesh function to make _VHT_MESH feature 
flag the same as _VHT_IBSS. Will you be convinced then?




In any case, the arguments for this patch haven't convinced me. I'm not
going to apply this without much better ones.

johannes

___
ath10k mailing list
ath...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Thanks,
Peter
--
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] cfg80211: add VHT support for Mesh

[Peter Oh]

On 11/12/2015 12:03 PM, Johannes Berg wrote:

On Thu, 2015-11-12 at 09:59 -0800, Peter Oh wrote:

Add NL80211_EXT_FEATURE_VHT_MESH flag to allow drivers
to indicate support for VHT in Mesh mode.
This flag will be used by wireless drivers to indicate
the capability of VHT Mesh support and wpa_supplicant to inspect
wireless drivers' capability of VHT Mesh.
In addition to this patch, separate patches to ath10k driver and
wpa_supplicant are also sent out.


Sorry, still doesn't make sense. What does userspace even need to know
this *for*?
At this moment Mesh Point is not able to be brought up by userspace such 
as wap_supplicant at VHT data rates because there is no events/NL80211 
defined that userspace can check out if drivers can support Mesh Point 
(802.11s) at VHT data rates or not, hence only HT data rates can be used 
for

Mesh Point by userspace now.
This patch is introducing NL80211 event to cover the issue.

johannes

___
ath10k mailing list
ath...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Thanks,
Peter
--
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] ath10k: Enable VHT for Mesh

[Peter Oh]

Mesh until now has no framework for VHT support which
requires NL80211 and wpa_supplicant updates communicating
with wireless drivers for capabilities.
I've sent patches of NL80211 and wpa_supplicant separately
that can be used for Mesh VHT support.
Also enable ath10k Mesh VHT support in this patch.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index a53e213..d38e4d8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7266,6 +7266,7 @@ int ath10k_mac_register(struct ath10k *ar)
}
 
wiphy_ext_feature_set(ar->hw->wiphy, NL80211_EXT_FEATURE_VHT_IBSS);
+   wiphy_ext_feature_set(ar->hw->wiphy, NL80211_EXT_FEATURE_VHT_MESH);
 
/*
 * on LL hardware queues are managed entirely by the FW
-- 
1.9.1

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

Re: [PATCH v2] cfg80211: add VHT support for Mesh

[Peter Oh]

On 11/12/2015 01:40 PM, Johannes Berg wrote:

On Thu, 2015-11-12 at 13:33 -0800, Peter Oh wrote:

At this moment Mesh Point is not able to be brought up by userspace
such
as wap_supplicant at VHT data rates because there is no
events/NL80211
defined that userspace can check out if drivers can support Mesh
Point
(802.11s) at VHT data rates or not, hence only HT data rates can be
used
for
Mesh Point by userspace now.
This patch is introducing NL80211 event to cover the issue.

No... this patch doesn't introduce an nl80211 event. It introduces a
feature flag, but I'm arguing it's useless.

Look - what's the difference that userspace would do based on this
flag? Clearly, setting the flag in the driver has no effect on kernel
code whatsoever, so your "is not able to be brought up" makes no sense.

Yes directly but no indirectly.
Setting the flag in the driver will have effect to the driver eventually 
by userspace since the flag will be sent up to userspace and userspace 
will select data rates according to the flag.
setting NL80211_VHT_MESH flag in driver -> wpa_supplicant requests 
driver capabilities via NL80211 -> driver sends up its capabilities 
including VHT_MESH -> wpa_supplicant parses and check if VHT_MESH is set 
-> wpa_supplicant configures the driver with VHT data rates if the flag 
set or configure HT data rates.


Perhaps it'll become clearer once you post the wpa_supplicant code,

This is ath10k driver diff I sent out for upstream review.

@@ -7266,6 +7266,7 @@ int ath10k_mac_register(struct ath10k *ar)
}
 
 	wiphy_ext_feature_set(ar->hw->wiphy, NL80211_EXT_FEATURE_VHT_IBSS);

+   wiphy_ext_feature_set(ar->hw->wiphy, NL80211_EXT_FEATURE_VHT_MESH);

and a part of wpa_supplicant changes.
@@ -359,6 +359,9 @@ static void wiphy_info_ext_feature_flags(struct 
wiphy_info_d

if (ext_feature_isset(nla_data(tb), nla_len(tb),
  NL80211_EXT_FEATURE_VHT_IBSS))
capa->flags |= WPA_DRIVER_FLAGS_VHT_IBSS;
+   if (ext_feature_isset(nla_data(tb), nla_len(tb),
+   NL80211_EXT_FEATURE_VHT_MESH))
+   capa->flags |= WPA_DRIVER_FLAGS_VHT_MESH;

@@ -1885,12 +1885,13 @@ void ibss_mesh_setup_freq(struct wpa_supplicant 
*wpa_s,

-   /* Not sure if mesh is ready for VHT */
+   /* For IBSS/Mesh check VHT flag */
+   if (ssid->mode == WPAS_MODE_MESH &&
+   !(wpa_s->drv_flags & WPA_DRIVER_FLAGS_VHT_MESH))
return;

  but
you should still coherently explain in the commit message why this is
necessary.
The both of wpa_supplicant and ath10k patches have explanation in their 
commit message already.

  So far, I don't see it, since no kernel code ever depends on
this flag.

A ath10k driver patch in upstream review is using the flag.
Exactly the same communication mechanism and purpose are used with 
NL80211_EXT_FEATURE_VHT_IBSS which is already a part of NL80211 feature 
flag.
The new feature flag, NL80211_EXT_FEATURE_VHT_MESH, follows the same 
purpose and usage.


johannes

___
ath10k mailing list
ath...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

--
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] ath10k: Enable VHT for Mesh

[Peter Oh]

Mesh until now has no framework for VHT support which
requires NL80211 and wpa_supplicant updates communicating
with wireless drivers for capabilities.
I've sent patches of NL80211 and wpa_supplicant separately
that can be used for Mesh VHT support.
Also enable ath10k Mesh VHT support in this patch.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index a53e213..d38e4d8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7266,6 +7266,7 @@ int ath10k_mac_register(struct ath10k *ar)
}
 
wiphy_ext_feature_set(ar->hw->wiphy, NL80211_EXT_FEATURE_VHT_IBSS);
+   wiphy_ext_feature_set(ar->hw->wiphy, NL80211_EXT_FEATURE_VHT_MESH);
 
/*
 * on LL hardware queues are managed entirely by the FW
-- 
1.9.1

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

[PATCH v2] cfg80211: add VHT support for Mesh

[Peter Oh]

Add NL80211_EXT_FEATURE_VHT_MESH flag to allow drivers
to indicate support for VHT in Mesh mode.
This flag will be used by wireless drivers to indicate
the capability of VHT Mesh support and wpa_supplicant to inspect
wireless drivers' capability of VHT Mesh.
In addition to this patch, separate patches to ath10k driver and
wpa_supplicant are also sent out.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>

---
v2:
- updated commit message for details
---
 include/uapi/linux/nl80211.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 1f0b4cf..4a16ed5 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4389,12 +4389,14 @@ enum nl80211_feature_flags {
 /**
  * enum nl80211_ext_feature_index - bit index of extended features.
  * @NL80211_EXT_FEATURE_VHT_IBSS: This driver supports IBSS with VHT datarates.
+ * @NL80211_EXT_FEATURE_VHT_MESH: This driver supports Mesh with VHT datarates.
  *
  * @NUM_NL80211_EXT_FEATURES: number of extended features.
  * @MAX_NL80211_EXT_FEATURES: highest extended feature index.
  */
 enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_VHT_IBSS,
+   NL80211_EXT_FEATURE_VHT_MESH,
 
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
-- 
1.9.1

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

[PATCH] cfg80211: add VHT support for Mesh

[Peter Oh]

Add NL80211_EXT_FEATURE_VHT_MESH flag to allow drivers
to indicate support for VHT in Mesh mode.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 include/uapi/linux/nl80211.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 1f0b4cf..4a16ed5 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4389,12 +4389,14 @@ enum nl80211_feature_flags {
 /**
  * enum nl80211_ext_feature_index - bit index of extended features.
  * @NL80211_EXT_FEATURE_VHT_IBSS: This driver supports IBSS with VHT datarates.
+ * @NL80211_EXT_FEATURE_VHT_MESH: This driver supports Mesh with VHT datarates.
  *
  * @NUM_NL80211_EXT_FEATURES: number of extended features.
  * @MAX_NL80211_EXT_FEATURES: highest extended feature index.
  */
 enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_VHT_IBSS,
+   NL80211_EXT_FEATURE_VHT_MESH,
 
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
-- 
1.9.1

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

Re: [PATCH] ath10k: use pre-allocated DMA buffer in Tx

[Peter Oh]

Does it happen after you applied copy engine patchset or even without 
the patchset?
I saw ath10k_pci_htt_tx_cb in backtrace which is not merged to master 
branch yet.
If it only happens after the patchset, I'll apply them and look into it 
if any possibilities are there.


On 10/08/2015 04:49 AM, Kalle Valo wrote:

Peter Oh <p...@qca.qualcomm.com> writes:


ath10k driver is using dma_pool_alloc per packet and dma_pool_free
in coresponding at Tx completion.
Use of pre-allocated DMA buffer in Tx will improve saving CPU resource
by 5% while it consumes about 56KB memory more as trade off.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>

I see randomly the warning below with ath.git master branch commit
2e88ba7ebe8d1. Can this patch cause that?

[   53.637883] [ cut here ]
[   53.637999] WARNING: CPU: 2 PID: 0 at lib/dma-debug.c:1090
check_unmap+0x815/0x940()
[   53.638070] ath10k_pci :02:00.0: qca99x0 hw2.0 (0x0100,
0x003801ff bmi 1:1) fw 10.4.1.7 fwapi 5 bdapi 2 htt-ver 2.2 wmi-op 6
htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1 features no-p2p
[   53.638077] ath10k_pci :02:00.0: debug 1 debugfs 1 tracing 1 dfs 1
testmode 1
[   53.638205] ath10k_pci :02:00.0: DMA-API: device driver tries to
free an invalid DMA memory address
[   53.638270] Modules linked in: ath10k_pci ath10k_core ath mac80211
cfg80211 [last unloaded: cfg80211]
[   53.638800] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.3.0-rc3-wl-ath+
#1082
[   53.638880] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS
68CDD Ver. F.04 01/27/2010
[   53.638951]    f4445de4 c133dd94  f4445e14
c10562de c1b3e12c
[   53.639551]  f4445e40  c1b3d3b9 0442 c13693c5 c13693c5
f422e840 f4445eb4
[   53.640169]   f4445e2c c10563c3 0009 f4445e24 c1b3e12c
f4445e40 f4445ea4
[   53.640802] Call Trace:
[   53.640874]  [] dump_stack+0x48/0x64
[   53.640953]  [] warn_slowpath_common+0x8e/0xd0
[   53.641031]  [] ? check_unmap+0x815/0x940
[   53.641115]  [] ? check_unmap+0x815/0x940
[   53.641201]  [] warn_slowpath_fmt+0x33/0x40
[   53.641277]  [] check_unmap+0x815/0x940
[   53.641356]  [] ? local_clock+0x25/0x30
[   53.641432]  [] debug_dma_unmap_page+0x8c/0xa0
[   53.641511]  [] ath10k_pci_htt_tx_cb+0x8f/0xb0 [ath10k_pci]
[   53.641589]  [] ath10k_pci_htt_rx_cb+0x20/0x30 [ath10k_pci]
[   53.641668]  [] ath10k_ce_per_engine_service+0x5c/0xa0
[ath10k_pci]
[   53.641746]  [] ath10k_ce_per_engine_service_any+0x77/0x90
[ath10k_pci]
[   53.641825]  [] ath10k_pci_tasklet+0x1b/0x50 [ath10k_pci]
[   53.642064]  [] tasklet_action+0x9e/0xb0
[   53.642142]  [] __do_softirq+0xbb/0x3c0
[   53.64]  [] ?
trace_event_raw_event_irq_handler_entry+0xa0/0xa0
[   53.642300]  [] do_softirq_own_stack+0x29/0x40
[   53.642375][] irq_exit+0x86/0xb0
[   53.642526]  [] do_IRQ+0x60/0x120
[   53.642604]  [] ? trace_hardirqs_off+0xb/0x10
[   53.642680]  [] common_interrupt+0x31/0x38
[   53.642760]  [] ? cpuidle_enter_state+0xc9/0x350
[   53.642835]  [] ? menu_select+0x239/0x4b0
[   53.642925]  [] cpuidle_enter+0x14/0x20
[   53.643063]  [] call_cpuidle+0x3c/0x70
[   53.643140]  [] cpu_startup_entry+0x1a9/0x390
[   53.643218]  [] start_secondary+0x105/0x150
[   53.643294] ---[ end trace a5dc1d40148089eb ]---



--
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] ath10k: use pre-allocated DMA buffer in Tx

[Peter Oh]

I did quick glance on the warning.
The dma unmap warning is caused by dma_unmap_single called per every 
received packet in ath10k_pci_htt_tx_cb() <- ath10k_pci_htt_rx_cb().

The physical address is assigned by rx refill function for rx ring.
So it looks like copy engine patchset has a bug.
FYI, pre-allocated dma is coherent dma used in Tx only and only freed 
when ath10k driver stops.


On 10/08/2015 10:17 AM, Peter Oh wrote:
Does it happen after you applied copy engine patchset or even without 
the patchset?
I saw ath10k_pci_htt_tx_cb in backtrace which is not merged to master 
branch yet.
If it only happens after the patchset, I'll apply them and look into 
it if any possibilities are there.


On 10/08/2015 04:49 AM, Kalle Valo wrote:

Peter Oh <p...@qca.qualcomm.com> writes:


ath10k driver is using dma_pool_alloc per packet and dma_pool_free
in coresponding at Tx completion.
Use of pre-allocated DMA buffer in Tx will improve saving CPU resource
by 5% while it consumes about 56KB memory more as trade off.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>

I see randomly the warning below with ath.git master branch commit
2e88ba7ebe8d1. Can this patch cause that?

[   53.637883] [ cut here ]
[   53.637999] WARNING: CPU: 2 PID: 0 at lib/dma-debug.c:1090
check_unmap+0x815/0x940()
[   53.638070] ath10k_pci :02:00.0: qca99x0 hw2.0 (0x0100,
0x003801ff bmi 1:1) fw 10.4.1.7 fwapi 5 bdapi 2 htt-ver 2.2 wmi-op 6
htt-op 4 cal otp max-sta 512 raw 0 hwcrypto 1 features no-p2p
[   53.638077] ath10k_pci :02:00.0: debug 1 debugfs 1 tracing 1 dfs

1

testmode 1
[   53.638205] ath10k_pci :02:00.0: DMA-API: device driver tries to
free an invalid DMA memory address
[   53.638270] Modules linked in: ath10k_pci ath10k_core ath mac80211
cfg80211 [last unloaded: cfg80211]
[   53.638800] CPU: 2 PID: 0 Comm: swapper/2 Not tainted

4.3.0-rc3-wl-ath+

#1082
[   53.638880] Hardware name: Hewlett-Packard HP ProBook 6540b/1722,

BIOS

68CDD Ver. F.04 01/27/2010
[   53.638951]    f4445de4 c133dd94  f4445e14
c10562de c1b3e12c
[   53.639551]  f4445e40  c1b3d3b9 0442 c13693c5 c13693c5
f422e840 f4445eb4
[   53.640169]   f4445e2c c10563c3 0009 f4445e24 c1b3e12c
f4445e40 f4445ea4
[   53.640802] Call Trace:
[   53.640874]  [] dump_stack+0x48/0x64
[   53.640953]  [] warn_slowpath_common+0x8e/0xd0
[   53.641031]  [] ? check_unmap+0x815/0x940
[   53.641115]  [] ? check_unmap+0x815/0x940
[   53.641201]  [] warn_slowpath_fmt+0x33/0x40
[   53.641277]  [] check_unmap+0x815/0x940
[   53.641356]  [] ? local_clock+0x25/0x30
[   53.641432]  [] debug_dma_unmap_page+0x8c/0xa0
[   53.641511]  [] ath10k_pci_htt_tx_cb+0x8f/0xb0 [ath10k_pci]
[   53.641589]  [] ath10k_pci_htt_rx_cb+0x20/0x30 [ath10k_pci]
[   53.641668]  [] ath10k_ce_per_engine_service+0x5c/0xa0
[ath10k_pci]
[   53.641746]  [] ath10k_ce_per_engine_service_any+0x77/0x90
[ath10k_pci]
[   53.641825]  [] ath10k_pci_tasklet+0x1b/0x50 [ath10k_pci]
[   53.642064]  [] tasklet_action+0x9e/0xb0
[   53.642142]  [] __do_softirq+0xbb/0x3c0
[   53.64]  [] ?
trace_event_raw_event_irq_handler_entry+0xa0/0xa0
[   53.642300]  [] do_softirq_own_stack+0x29/0x40
[   53.642375][] irq_exit+0x86/0xb0
[   53.642526]  [] do_IRQ+0x60/0x120
[   53.642604]  [] ? trace_hardirqs_off+0xb/0x10
[   53.642680]  [] common_interrupt+0x31/0x38
[   53.642760]  [] ? cpuidle_enter_state+0xc9/0x350
[   53.642835]  [] ? menu_select+0x239/0x4b0
[   53.642925]  [] cpuidle_enter+0x14/0x20
[   53.643063]  [] call_cpuidle+0x3c/0x70
[   53.643140]  [] cpu_startup_entry+0x1a9/0x390
[   53.643218]  [] start_secondary+0x105/0x150
[   53.643294] ---[ end trace a5dc1d40148089eb ]---




___
ath10k mailing list
ath...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k


--
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] Revert "mac80211: remove exposing 'mfp' to drivers"

[Peter Oh]

On 10/06/2015 10:10 PM, c_tr...@qti.qualcomm.com wrote:

From: Tamizh chelvam 

This reverts commit 5c48f1201744233d4f235c7dd916d5196ed20716.

Some device drivers (ath10k) offload part of aggregation including
AddBA/DelBA
negotiations to firmware. In such scenario, the PMF

Is it typo of MFP or abbreviation of something else?

  configuration of
the station needs to be provided to driver to enable encryption of
AddBA/DelBA action frames.

Signed-off-by: Tamizh chelvam 
---
Notes:
> ath10k change using this mfp configuration will follow.

  include/net/mac80211.h |2 ++
  net/mac80211/cfg.c |1 +
  net/mac80211/mlme.c|6 +-
  3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 4ec6fed..1bb2a2b 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1683,6 +1683,7 @@ struct ieee80211_sta_rates {
   * @tdls: indicates whether the STA is a TDLS peer
   * @tdls_initiator: indicates the STA is an initiator of the TDLS link.
Only
   *valid if the STA is a TDLS peer in the first place.
+ * @mfp: indicates whether the STA uses management frame protection or
not.
   * @txq: per-TID data TX queues (if driver uses the TXQ abstraction)
   */
  struct ieee80211_sta {
@@ -1700,6 +1701,7 @@ struct ieee80211_sta {
struct ieee80211_sta_rates __rcu *rates;
bool tdls;
bool tdls_initiator;
+   bool mfp;
  
  	struct ieee80211_txq *txq[IEEE80211_NUM_TIDS];
  
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c

index 68e551e..63d03da 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1138,6 +1138,7 @@ static int sta_apply_parameters(struct
ieee80211_local *local,
}
  
  	if (mask & BIT(NL80211_STA_FLAG_MFP)) {

+   sta->sta.mfp = !!(set & BIT(NL80211_STA_FLAG_MFP));
if (set & BIT(NL80211_STA_FLAG_MFP))
set_sta_flag(sta, WLAN_STA_MFP);
else
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 56ef9a8..9c450ff 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3044,8 +3044,12 @@ static bool ieee80211_assoc_success(struct
ieee80211_sub_if_data *sdata,
  
  	rate_control_rate_init(sta);
  
-	if (ifmgd->flags & IEEE80211_STA_MFP_ENABLED)

+   if (ifmgd->flags & IEEE80211_STA_MFP_ENABLED) {
set_sta_flag(sta, WLAN_STA_MFP);
+   sta->sta.mfp = true;
+   } else {
+   sta->sta.mfp = false;
+   }
  
  	sta->sta.wme = elems.wmm_param && local->hw.queues >=

IEEE80211_NUM_ACS;
  


--
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] ath10k: only advertise mesh support in raw mode

[Peter Oh]

On 09/30/2015 07:54 PM, Bob Copeland wrote:

On Mon, Sep 28, 2015 at 10:27:30AM -0700, Peter Oh wrote:

I prefer the current design to this new approach because drivers already
know if it's mesh capable or not at build time, hence adding runtime
configuration is redundant.

I do think the proposed patch is a bit overboard, so I suppose my vote is
to
keep it the way it is, even if a little user-unfriendly.


One more thing we have to think about is enabling mesh in only raw mode.
In standard view point, mesh is only available in raw mode on ath10k,
however ath10k is also able to run mesh in native WiFi mode in current
mac80211 design since mac80211 handles packets per interface. So that
mac80211 knows that packets are for mesh without looking at mesh control
present bit when they come into mesh interface.

This is true, it'll work with mac80211, but it violates the standard
(802.11-2012 8.2.4.7.3).

I agree.


For the benefit of others, as I just retested non-rawmode -- the issue is
that QoS control in nwifi frames is missing the "Mesh Control Present"
bit.
However, it still includes the mesh control field, which is the part
that has the mesh sequence number and address extension fields.

As a result, a packet parser might misinterpret the mesh control field as
the LLC header -- the wireshark dissector at least gets confused like
this.

I would think a small change to ath10k firmware could fix this though,
vendor willing.
I'm working with firmware guy and there is possibility that firmware 
handles this issue properly.



Thanks,
Peter
--
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] ath10k: only advertise mesh support in raw mode

[Peter Oh]

Hi,

On 09/28/2015 05:59 AM, Bob Copeland wrote:

Rather than always advertising mesh support and then generating
an error when the user attempts to bring up the device without
rawmode, only advertise it when available: that is, if the module
is loaded with rawmode=1, the firmware supports it, and the
device/firmware supports an AP virtual interface internally.

Signed-off-by: Bob Copeland 
---
Actually, I think this is perhaps worse than just spitting out an
error on interface up, but I'm sending anyway because it was requested
a couple of times in review.

The reason this is so ugly is that the structures in question are
defined const in the API; when also declared const in the driver,
they go into the .rodata section and the interface limit types
cannot be changed without causing a fault.  So this patch removes
const in a bunch of places and adds casts to const where required.

Another approach might be changing cfg80211 to silently remove interface
types from advertised combinations when the given mode is not also
in interface_modes, instead of warning and failing registration as it
does today.  But this would make errors here harder to spot.

Or we can keep it the way it is with the driver failing and showing an
error on add interface.  I'm okay with any of these approaches really.
I prefer the current design to this new approach because drivers already 
know if it's mesh capable or not at build time, hence adding runtime 
configuration is redundant.

One more thing we have to think about is enabling mesh in only raw mode.
In standard view point, mesh is only available in raw mode on ath10k, 
however ath10k is also able to run mesh in native WiFi mode in current 
mac80211 design since mac80211 handles packets per interface. So that 
mac80211 knows that packets are for mesh without looking at mesh control 
present bit when they come into mesh interface.
Because of the reason allowing mesh in raw mode on ath10k is too much 
strict in my opinion.

  drivers/net/wireless/ath/ath10k/mac.c | 98
++-
  1 file changed, 63 insertions(+), 35 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 20d002c..c689613 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4209,11 +4209,6 @@ static int ath10k_add_interface(struct ieee80211_hw
*hw,
arvif->vdev_type = WMI_VDEV_TYPE_IBSS;
break;
case NL80211_IFTYPE_MESH_POINT:
-   if (!test_bit(ATH10K_FLAG_RAW_MODE, >dev_flags)) {
-   ret = -EINVAL;
-   ath10k_warn(ar, "must load driver with rawmode=1
to add mesh interfaces\n");
-   goto err;
-   }
arvif->vdev_type = WMI_VDEV_TYPE_AP;
break;
case NL80211_IFTYPE_AP:
@@ -6755,7 +6750,7 @@ void ath10k_mac_destroy(struct ath10k *ar)
ieee80211_free_hw(ar->hw);
  }
  
-static const struct ieee80211_iface_limit ath10k_if_limits[] = {

+static struct ieee80211_iface_limit ath10k_if_limits[] = {
{
.max= 8,
.types  = BIT(NL80211_IFTYPE_STATION)
@@ -6772,23 +6767,17 @@ static const struct ieee80211_iface_limit
ath10k_if_limits[] = {
{
.max= 7,
.types  = BIT(NL80211_IFTYPE_AP)
-#ifdef CONFIG_MAC80211_MESH
-   | BIT(NL80211_IFTYPE_MESH_POINT)
-#endif
},
  };
  
-static const struct ieee80211_iface_limit ath10k_10x_if_limits[] = {

+static struct ieee80211_iface_limit ath10k_10x_if_limits[] = {
{
.max= 8,
.types  = BIT(NL80211_IFTYPE_AP)
-#ifdef CONFIG_MAC80211_MESH
-   | BIT(NL80211_IFTYPE_MESH_POINT)
-#endif
},
  };
  
-static const struct ieee80211_iface_combination ath10k_if_comb[] = {

+static struct ieee80211_iface_combination ath10k_if_comb[] = {
{
.limits = ath10k_if_limits,
.n_limits = ARRAY_SIZE(ath10k_if_limits),
@@ -6798,7 +6787,7 @@ static const struct ieee80211_iface_combination
ath10k_if_comb[] = {
},
  };
  
-static const struct ieee80211_iface_combination ath10k_10x_if_comb[] = {

+static struct ieee80211_iface_combination ath10k_10x_if_comb[] = {
{
.limits = ath10k_10x_if_limits,
.n_limits = ARRAY_SIZE(ath10k_10x_if_limits),
@@ -6814,7 +6803,7 @@ static const struct ieee80211_iface_combination
ath10k_10x_if_comb[] = {
},
  };
  
-static const struct ieee80211_iface_limit ath10k_tlv_if_limit[] = {

+static struct ieee80211_iface_limit ath10k_tlv_if_limit[] = {
{
.max = 2,
.types = BIT(NL80211_IFTYPE_STATION),
@@ -6822,9 +6811,6 @@ static const struct ieee80211_iface_limit
ath10k_tlv_if_limit[] = {
{
.max = 2,
.types = BIT(NL80211_IFTYPE_AP) |
-#ifdef CONFIG_MAC80211_MESH
-

[PATCH] ath10k: use pre-allocated DMA buffer in Tx

[Peter Oh]

ath10k driver is using dma_pool_alloc per packet and dma_pool_free
in coresponding at Tx completion.
Use of pre-allocated DMA buffer in Tx will improve saving CPU resource
by 5% while it consumes about 56KB memory more as trade off.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/htt.h|  6 -
 drivers/net/wireless/ath/ath10k/htt_tx.c | 43 +---
 drivers/net/wireless/ath/ath10k/txrx.c   |  5 
 3 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt.h 
b/drivers/net/wireless/ath/ath10k/htt.h
index 5a8e4ea..db0a99b 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1488,7 +1488,6 @@ struct ath10k_htt {
int num_pending_mgmt_tx;
struct idr pending_tx;
wait_queue_head_t empty_tx_wq;
-   struct dma_pool *tx_pool;
 
/* set if host-fw communication goes haywire
 * used to avoid further failures */
@@ -1509,6 +1508,11 @@ struct ath10k_htt {
dma_addr_t paddr;
struct htt_msdu_ext_desc *vaddr;
} frag_desc;
+
+   struct {
+   dma_addr_t paddr;
+   struct ath10k_htt_txbuf *vaddr;
+   } txbuf;
 };
 
 #define RX_HTT_HDR_STATUS_LEN 64
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c 
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index eb5ba9b..5bed087 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -108,9 +108,12 @@ int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
spin_lock_init(>tx_lock);
idr_init(>pending_tx);
 
-   htt->tx_pool = dma_pool_create("ath10k htt tx pool", htt->ar->dev,
-  sizeof(struct ath10k_htt_txbuf), 4, 0);
-   if (!htt->tx_pool) {
+   size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
+   htt->txbuf.vaddr = dma_alloc_coherent(ar->dev, size,
+ >txbuf.paddr,
+ GFP_DMA);
+   if (!htt->txbuf.vaddr) {
+   ath10k_err(ar, "failed to alloc tx buffer\n");
ret = -ENOMEM;
goto free_idr_pending_tx;
}
@@ -125,14 +128,17 @@ int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
if (!htt->frag_desc.vaddr) {
ath10k_warn(ar, "failed to alloc fragment desc memory\n");
ret = -ENOMEM;
-   goto free_tx_pool;
+   goto free_txbuf;
}
 
 skip_frag_desc_alloc:
return 0;
 
-free_tx_pool:
-   dma_pool_destroy(htt->tx_pool);
+free_txbuf:
+   size = htt->max_num_pending_tx *
+ sizeof(struct ath10k_htt_txbuf);
+   dma_free_coherent(htt->ar->dev, size, htt->txbuf.vaddr,
+ htt->txbuf.paddr);
 free_idr_pending_tx:
idr_destroy(>pending_tx);
return ret;
@@ -160,7 +166,13 @@ void ath10k_htt_tx_free(struct ath10k_htt *htt)
 
idr_for_each(>pending_tx, ath10k_htt_tx_clean_up_pending, htt->ar);
idr_destroy(>pending_tx);
-   dma_pool_destroy(htt->tx_pool);
+
+   if (htt->txbuf.vaddr) {
+   size = htt->max_num_pending_tx *
+ sizeof(struct ath10k_htt_txbuf);
+   dma_free_coherent(htt->ar->dev, size, htt->txbuf.vaddr,
+ htt->txbuf.paddr);
+   }
 
if (htt->frag_desc.vaddr) {
size = htt->max_num_pending_tx *
@@ -521,7 +533,6 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff 
*msdu)
int res;
u8 flags0 = 0;
u16 msdu_id, flags1 = 0;
-   dma_addr_t paddr = 0;
u32 frags_paddr = 0;
struct htt_msdu_ext_desc *ext_desc = NULL;
bool limit_mgmt_desc = false;
@@ -550,13 +561,9 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff 
*msdu)
prefetch_len = min(htt->prefetch_len, msdu->len);
prefetch_len = roundup(prefetch_len, 4);
 
-   skb_cb->htt.txbuf = dma_pool_alloc(htt->tx_pool, GFP_ATOMIC,
-  );
-   if (!skb_cb->htt.txbuf) {
-   res = -ENOMEM;
-   goto err_free_msdu_id;
-   }
-   skb_cb->htt.txbuf_paddr = paddr;
+   skb_cb->htt.txbuf = >txbuf.vaddr[msdu_id];
+   skb_cb->htt.txbuf_paddr = htt->txbuf.paddr +
+   (sizeof(struct ath10k_htt_txbuf) * msdu_id);
 
if ((ieee80211_is_action(hdr->frame_control) ||
 ieee80211_is_deauth(hdr->frame_control) ||
@@ -574,7 +581,7 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff 
*msdu)
res = dma_mapping_error(dev, skb_cb->paddr);
if (res) {
res = -EIO;
-   goto er

[PATCH] ath10k: use Rx decap mode configured when driver registered

[Peter Oh]

ath10k is using Native WiFi mode as default mode for both of
Tx and Rx path, but it could be changed when driver registers
with a module parameter for specific purpose such as mesh.

The Rx decap mode sent to firmware during WMI initialization should
use the same mode that driver configured at its registration stage
in case of using raw mode, so that host driver receives MAC frame
header containing necessary fields such as QoS and Mesh Control
and uses them in right way to make data traffic work.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 87d9de2..78da56c 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5090,7 +5090,7 @@ static struct sk_buff *ath10k_wmi_10_4_op_gen_init(struct 
ath10k *ar)
config.rx_timeout_pri[2] = __cpu_to_le32(TARGET_10_4_RX_TIMEOUT_LO_PRI);
config.rx_timeout_pri[3] = __cpu_to_le32(TARGET_10_4_RX_TIMEOUT_HI_PRI);
 
-   config.rx_decap_mode= __cpu_to_le32(TARGET_10_4_RX_DECAP_MODE);
+   config.rx_decap_mode= __cpu_to_le32(ar->wmi.rx_decap_mode);
config.scan_max_pending_req = __cpu_to_le32(TARGET_10_4_SCAN_MAX_REQS);
config.bmiss_offload_max_vdev =
__cpu_to_le32(TARGET_10_4_BMISS_OFFLOAD_MAX_VDEV);
-- 
1.9.1

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

Re: [PATCH 3/3] ath10k: implement mesh support

[Peter Oh]

On 09/17/2015 10:48 AM, Yeoh Chun-Yeow wrote:

Hi, Bob

I have also tested with nwifi mode for non-secured mesh. It seems to
be worked for me with the following two test scenarios:

Node 1 [ath10k] <---> Node 2 [ath10k] <---> Node 3 [ath10k]
Node 1 [ath10k] <---> Node 2 [ath9k]

I am using the following:
compat-wireless-2015-07-21 from OpenWRT
firmware-5.bin_10.2.4.70.6-2

I just wondering whether using raw wifi is better for encrypted mesh
later?
nwifi mode will be in trouble when SNAP/LLC encapsulation used since 
firmware and hardware have no way to distinguish if it's SNAP header or 
Mesh Control field.


--
Peter



Chun-Yeow

On Wed, Sep 16, 2015 at 8:39 PM, Bob Copeland  wrote:

On Mon, Aug 31, 2015 at 01:43:28AM +0800, Chun-Yeow Yeoh wrote:

Hi, Bob


Yes: you don't want to enable raw mode TX / RX decap in the normal
case because it's fairly inefficient compared to "native" wifi mode,
according to my understanding.  The latter doesn't support mesh

framing

however.


The native WiFi mode doesn't support mesh framing. Can you elaborate
more on this?

Sorry, missed this before -- the 'nwifi' mode which is the normal
datapath for ath10k discards the QoS header and following mesh header
when transmitting, if I recall correctly.  I also had some issues with

the

received frames when using nwifi RX decap with raw mode TX, but I don't
recall exactly the problem.  I can retest with these modes if you really
want the details.

--
Bob Copeland %% http://bobcopeland.com/

___
ath10k mailing list
ath...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k


--
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] ath10k: implement mesh support

[Peter Oh]

On 09/10/2015 12:22 AM, Johannes Berg wrote:

On Wed, 2015-09-09 at 12:49 -0400, Bob Copeland wrote:

On Wed, Sep 09, 2015 at 12:10:38PM +0300, Kalle Valo wrote:

I did a quick smoke test and saw the splat below. It's this
warning from
cfg80211:

/*
 * Don't advertise an unsupported type
 * in a combination.
 */
if (WARN_ON((wiphy->interface_modes &
types) != types))
return -EINVAL;

OK, this happens when mesh is configured out (we mask off the mesh
interface_modes internally but not the types).  Sent an updated
version with appropriate ifdefs added.

Yeah this is an unfortunate quirk in the APIs ... I think adding the
ifdefs to the driver is the best thing to do.

johannes
Can we configure mesh point with hostapd or can we use mesh point 
without neither wpa_supplicant nor hostapd?
Currently I'm trying to bring up mesh point, but whenever I run hostpad 
after creating mesh point (iw phy0 interface add mesh type mp), hostapd 
change the interface mode to managed.

___
ath10k mailing list
ath...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Thanks,
Peter
--
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] ath: fix incorrect PPB on JAPAN chirp radar

[Peter Oh]

The number of pulses per burst on Japan chirp radar is
between 1 and 3. The previous value, 20, is representing
number of bursts, but since current DFS detector is using
pulse detection other than bursts, use the pulse number
for correct radar detection.
Also using the highest number helps to avoid false detection.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/dfs_pattern_detector.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c 
b/drivers/net/wireless/ath/dfs_pattern_detector.c
index 656ce42..5aa053a 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
@@ -121,7 +121,7 @@ static const struct radar_detector_specs 
jp_radar_ref_types[] = {
JP_PATTERN(4, 0, 5, 150, 230, 1, 23, 50, false),
JP_PATTERN(5, 6, 10, 200, 500, 1, 16, 50, false),
JP_PATTERN(6, 11, 20, 200, 500, 1, 12, 50, false),
-   JP_PATTERN(7, 50, 100, 1000, 2000, 1, 20, 50, false),
+   JP_PATTERN(7, 50, 100, 1000, 2000, 1, 3, 50, false),
JP_PATTERN(5, 0, 1, 333, 333, 1, 9, 50, false),
 };
 
-- 
1.9.1

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

[PATCH v2] ath: use PRI value given by spec for fixed PRI

[Peter Oh]

PRI value is used as divider when DFS detector analyzes candidate
radar pulses.
If PRI deviation is big from its origin PRI, DFS detector could miss
valid radar reports since HW often misses detecting radar pulses and
causes long interval value of pulses.

For instance from practical results, if runtime PRI is calculated as
1431 for fixed PRI value of 1428 and delta timestamp logs 15719,
the modular remainder will be 1409 and the delta between the remainder
and runtime PRI is 22 that is bigger than PRI tolerance which is 16.
As a result this radar report will be ignored even though it's valid.

By using spec defined PRI for fixed PRI, we can correct this error.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
v2:
 * replaced numeral 16 with PRI_TOLERANCE macro
---
 drivers/net/wireless/ath/dfs_pattern_detector.c | 6 --
 drivers/net/wireless/ath/dfs_pattern_detector.h | 5 +
 drivers/net/wireless/ath/dfs_pri_detector.c | 6 +-
 3 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c 
b/drivers/net/wireless/ath/dfs_pattern_detector.c
index 656ce42..0cc89fd 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
@@ -21,12 +21,6 @@
 #include "dfs_pri_detector.h"
 #include "ath.h"
 
-/*
- * tolerated deviation of radar time stamp in usecs on both sides
- * TODO: this might need to be HW-dependent
- */
-#define PRI_TOLERANCE  16
-
 /**
  * struct radar_types - contains array of patterns defined for one DFS domain
  * @domain: DFS regulatory domain
diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.h 
b/drivers/net/wireless/ath/dfs_pattern_detector.h
index 25a43d6..92be353 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.h
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.h
@@ -21,6 +21,11 @@
 #include 
 #include 
 
+/* tolerated deviation of radar time stamp in usecs on both sides
+ * TODO: this might need to be HW-dependent
+ */
+#define PRI_TOLERANCE  16
+
 /**
  * struct ath_dfs_pool_stats - DFS Statistics for global pools
  */
diff --git a/drivers/net/wireless/ath/dfs_pri_detector.c 
b/drivers/net/wireless/ath/dfs_pri_detector.c
index cc5c592..05b0464 100644
--- a/drivers/net/wireless/ath/dfs_pri_detector.c
+++ b/drivers/net/wireless/ath/dfs_pri_detector.c
@@ -25,6 +25,9 @@ struct ath_dfs_pool_stats global_dfs_pool_stats = {};
 
 #define DFS_POOL_STAT_INC(c) (global_dfs_pool_stats.c++)
 #define DFS_POOL_STAT_DEC(c) (global_dfs_pool_stats.c--)
+#define GET_PRI_TO_USE(MIN, MAX, RUNTIME) \
+   (MIN + PRI_TOLERANCE == MAX - PRI_TOLERANCE ? \
+   MIN + PRI_TOLERANCE : RUNTIME)
 
 /**
  * struct pulse_elem - elements in pulse queue
@@ -243,7 +246,8 @@ static bool pseq_handler_create_sequences(struct 
pri_detector *pde,
ps.count_falses = 0;
ps.first_ts = p->ts;
ps.last_ts = ts;
-   ps.pri = ts - p->ts;
+   ps.pri = GET_PRI_TO_USE(pde->rs->pri_min,
+   pde->rs->pri_max, ts - p->ts);
ps.dur = ps.pri * (pde->rs->ppb - 1)
+ 2 * pde->rs->max_pri_tolerance;
 
-- 
1.9.1

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

[PATCH v2] ath: use PRI value given by spec for fixed PRI

[Peter Oh]

PRI value is used as divider when DFS detector analyzes candidate
radar pulses.
If PRI deviation is big from its origin PRI, DFS detector could miss
valid radar reports since HW often misses detecting radar pulses and
causes long interval value of pulses.

For instance from practical results, if runtime PRI is calculated as
1431 for fixed PRI value of 1428 and delta timestamp logs 15719,
the modular remainder will be 1409 and the delta between the remainder
and runtime PRI is 22 that is bigger than PRI tolerance which is 16.
As a result this radar report will be ignored even though it's valid.

By using spec defined PRI for fixed PRI, we can correct this error.

Signed-off-by: Peter Oh <p...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/dfs_pattern_detector.c | 6 --
 drivers/net/wireless/ath/dfs_pattern_detector.h | 5 +
 drivers/net/wireless/ath/dfs_pri_detector.c | 6 +-
 3 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c 
b/drivers/net/wireless/ath/dfs_pattern_detector.c
index 656ce42..0cc89fd 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
@@ -21,12 +21,6 @@
 #include "dfs_pri_detector.h"
 #include "ath.h"
 
-/*
- * tolerated deviation of radar time stamp in usecs on both sides
- * TODO: this might need to be HW-dependent
- */
-#define PRI_TOLERANCE  16
-
 /**
  * struct radar_types - contains array of patterns defined for one DFS domain
  * @domain: DFS regulatory domain
diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.h 
b/drivers/net/wireless/ath/dfs_pattern_detector.h
index 25a43d6..92be353 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.h
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.h
@@ -21,6 +21,11 @@
 #include 
 #include 
 
+/* tolerated deviation of radar time stamp in usecs on both sides
+ * TODO: this might need to be HW-dependent
+ */
+#define PRI_TOLERANCE  16
+
 /**
  * struct ath_dfs_pool_stats - DFS Statistics for global pools
  */
diff --git a/drivers/net/wireless/ath/dfs_pri_detector.c 
b/drivers/net/wireless/ath/dfs_pri_detector.c
index cc5c592..05b0464 100644
--- a/drivers/net/wireless/ath/dfs_pri_detector.c
+++ b/drivers/net/wireless/ath/dfs_pri_detector.c
@@ -25,6 +25,9 @@ struct ath_dfs_pool_stats global_dfs_pool_stats = {};
 
 #define DFS_POOL_STAT_INC(c) (global_dfs_pool_stats.c++)
 #define DFS_POOL_STAT_DEC(c) (global_dfs_pool_stats.c--)
+#define GET_PRI_TO_USE(MIN, MAX, RUNTIME) \
+   (MIN + PRI_TOLERANCE == MAX - PRI_TOLERANCE ? \
+   MIN + PRI_TOLERANCE : RUNTIME)
 
 /**
  * struct pulse_elem - elements in pulse queue
@@ -243,7 +246,8 @@ static bool pseq_handler_create_sequences(struct 
pri_detector *pde,
ps.count_falses = 0;
ps.first_ts = p->ts;
ps.last_ts = ts;
-   ps.pri = ts - p->ts;
+   ps.pri = GET_PRI_TO_USE(pde->rs->pri_min,
+   pde->rs->pri_max, ts - p->ts);
ps.dur = ps.pri * (pde->rs->ppb - 1)
+ 2 * pde->rs->max_pri_tolerance;
 
-- 
1.9.1

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

Re: [PATCH] ath: use PRI value given by spec for fixed PRI

[Peter Oh]

Hi Zefir,

I believe the patch below is good to be checked in since you've already 
made change in DFS.

Can you confirm it?

Thanks,
Peter

On 04/01/2015 03:04 AM, Zefir Kurtisi wrote:

On 03/30/2015 07:57 PM, Peter Oh wrote:

On 03/30/2015 02:55 AM, Zefir Kurtisi wrote:

[...]
That's why I believe we need to
be very cautious when changing it to fix / improve minor issues.

This patch is not for minor fix.
Current DFS detector fails on Japan W53 band which requires at least 50%

of data

traffic during DFS certificate.
So this patch should apply to both of 9k and 10k.

That is the core of my concern: you add changes to fix FCC/JP, which at
the same
time also affects ETSI.

Our company (and maybe others) got ath9k certified for ETSI, and any
potential
change to the detector relevant for that domain would essentially require
to
re-certify.

There were several patches lately added to the detector that were isolated
to
specific domains (like the recent updates for FCC pattern 1) which I knew
won't
affect the ETSI detector performance, since they touched only the FCC
configuration but not the algorithm itself. This patch does, and that's
why I need
to point out that doing so might void certification efforts out there.

Unfortunately, I have no good idea how to cope with it. Freezing the
driver at the
certified state is no option, since we all want to evolve. Having multiple
copies
of the detector for each regulatory domain would be an option (and
essentially
will happen since FCC/JP can't be covered by PRI detectors only), but
gives
unacceptable code duplication. Ideally we would fully separate algorithm
from
configuration and leave the algorithm untouched ever after, not sure how
doable,
though.


As for your patch at hand, I tested it for ETSI and it does not change
detector
performance, therefore (please replace 16 with PRI_TOLERANCE in the macro)

Acked-by: Zefir Kurtisi <zefir.kurt...@neratec.com>

___
ath10k mailing list
ath...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k


--
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] ath10k: Add QCA99X0 to supported device list

[Peter Oh]

On 08/06/2015 12:59 AM, Felix Fietkau wrote:

On 2015-08-06 09:43, Vasanthakumar Thiagarajan wrote:

On Wednesday 05 August 2015 05:51 PM, Felix Fietkau wrote:

On 2015-07-21 13:36, Vasanthakumar Thiagarajan wrote:

Add vendor/device id of QCA99X0 V2.0 to pci id table and
QCA99X0_HW_2_0_CHIP_ID_REV to ath10k_pci_supp_chips[] for
QCA99X0 to get detected by the driver.

Signed-off-by: Vasanthakumar Thiagarajan vthia...@qti.qualcomm.com

I just tested a 99X0 card, and I'm getting this:

[8.742514] ath10k_pci :01:00.0: enabling device (0140 - 0142)
[8.747173] ath10k_pci :01:00.0: pci irq msi interrupts 1

irq_mode 0 reset_mode 0

[   11.793314] ath10k_pci :01:00.0: failed to receive initialized

event from target: 

[   11.793344] ath10k_pci :01:00.0: failed to wait for target after

cold reset: -110

[   11.800814] ath10k_pci :01:00.0: failed to reset chip: -110
[   11.809228] ath10k_pci: probe of :01:00.0 failed with error -110

This is on an AP148 board with Linux 3.18, backports generated from
latest wireless-testing (2015-08-03) + all patches from kvalo's ath
tree.

Any idea about the version of AP148 that you are using?. By any chance

did

you check if QCA988X is working on the same board?.

No idea about the version, but QCA988X is working in the same slot.

QCA99X0 uses a different version of firmware from QCA988X.
Could you verify which firmware version or file name is using?

- Felix

___
ath10k mailing list
ath...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Thanks,
Peter
--
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