date:20180412

Re: [PATCH v2] ath10k: Implement get_expected_throughput callback

2018-04-12 Thread 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

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

Re: [PATCH 2/2] ath10k: support MAC address randomization in scan

2018-04-12 Thread Brian Norris

Hi Carl,

On Fri, Mar 30, 2018 at 11:14:00AM +0800, Carl Huang wrote:
> The ath10k reports the random_mac_addr capability to upper layer
> based on the service bit firmware reported. Driver sets the
> spoofed flag in scan_ctrl_flag to firmware if upper layer has
> enabled this feature in scan request.
> 
> Test with QCA6174 hw3.0 and firmware-6.bin_WLAN.RM.4.4.1-00102-QCARMSWP-1,
> but QCA9377 is also affected.
> 
> Signed-off-by: Carl Huang 
> ---
>  drivers/net/wireless/ath/ath10k/mac.c | 17 +
>  drivers/net/wireless/ath/ath10k/wmi-ops.h | 22 ++
>  drivers/net/wireless/ath/ath10k/wmi-tlv.c | 25 +
>  drivers/net/wireless/ath/ath10k/wmi-tlv.h | 11 +++
>  drivers/net/wireless/ath/ath10k/wmi.c |  5 +
>  drivers/net/wireless/ath/ath10k/wmi.h |  9 +
>  6 files changed, 89 insertions(+)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> b/drivers/net/wireless/ath/ath10k/mac.c
> index ebb3f1b..c5cd5e5 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -5699,6 +5699,12 @@ static int ath10k_hw_scan(struct ieee80211_hw *hw,
>   arg.scan_ctrl_flags |= WMI_SCAN_FLAG_PASSIVE;
>   }
>  
> + if (req->flags & NL80211_SCAN_FLAG_RANDOM_ADDR) {
> + arg.scan_ctrl_flags |=  WMI_SCAN_ADD_SPOOFED_MAC_IN_PROBE_REQ;
> + ether_addr_copy(arg.mac_addr.addr, req->mac_addr);
> + ether_addr_copy(arg.mac_mask.addr, req->mac_addr_mask);
> + }
> +
>   if (req->n_channels) {
>   arg.n_channels = req->n_channels;
>   for (i = 0; i < arg.n_channels; i++)
> @@ -8397,6 +8403,17 @@ int ath10k_mac_register(struct ath10k *ar)
>   goto err_dfs_detector_exit;
>   }
>  
> + if (test_bit(WMI_SERVICE_SPOOF_MAC_SUPPORT, ar->wmi.svc_map)) {
> + ret = ath10k_wmi_scan_prob_req_oui(ar, ar->mac_addr);
> + if (ret) {
> + ath10k_err(ar, "failed to set prob req oui: %i\n", ret);
> + goto err_dfs_detector_exit;
> + }
> +
> + ar->hw->wiphy->features |=
> + NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR;

Do you support NL80211_FEATURE_SCHED_SCAN_RANDOM_MAC_ADDR too?

> + }
> +


Brian

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

Re: Please add new board files for WLE1216V5-20 and another Compex NIC.

2018-04-12 Thread Ben Greear


On 04/12/2018 12:27 AM, Sven Eckelmann wrote:

On Mittwoch, 11. April 2018 08:18:15 CEST Tim Harvey wrote:

It's not clear what the process is for getting new board id's
supported in the board.bin files.


The reaction of QCA when asking for new IDs was mostly "please go away, we
will not talk to you about it". But with the help of Kalle Valo, a new
mechanism called "qcom,ath10k-calibration-variant" was added (for embedded
boards which include QCA 11ac wave2 radios). There are a couple of mails
about it on this list - a general overview about BDFs, variant strings and
why we need them can be found at
http://lists.infradead.org/pipermail/ath10k/2018-March/011066.html.

But it looks like you really got the IDs 30+31 (maybe because you are selling
the, as separate PCIe modules?). Then I would guess that you can still use the
same process as we use for the accesspoint specific BDFs (just without the
variant= part).


These are Compex NICs, and they do have their own IDs.  These are general
purpose NICs that fit into most any system, so it would be good if the board
files were in the upstream board-2.bin file.


The description of the general upstreaming process can be found at
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles - but it
seems like Kalle Valo doesn't have much time for it at the moment for it (or
there might be other problems which we don't see from our perspective - for
example legal departments).

Maybe you or Ben Greear can enhance the submission for the BDFs to better
answer the questions from the "Submitting board files" guide.


Considering all of the not-accepted below, maybe we should just build
our own board file(s) for OpenWRT and let upstream catch up when someone
has time to deal with it?

For platform specific files, maybe better to just ignore the board-2.bin
entirely and use the specific board.bin file for that platform?

Thanks,
Ben




Examples for such submission


* OpenMesh A42

  - applied
  - http://lists.infradead.org/pipermail/ath10k/2017-November/010470.html
  - http://lists.infradead.org/pipermail/ath10k/2017-December/010543.html

* Asus RT-AC58U

  - not yet accepted
  - submitted before the guide was published
  - http://lists.infradead.org/pipermail/ath10k/2017-March/009454.html

* Netgear EX6100v2/EX6150v2

  - not yet accepted
  - http://lists.infradead.org/pipermail/ath10k/2018-February/010845.html

* 8devices Jalapeno

  - not yet accepted
  - http://lists.infradead.org/pipermail/ath10k/2018-March/010916.html

* GL.iNet GL-B1300

  - not yet accepted
  - http://lists.infradead.org/pipermail/ath10k/2018-March/011058.html

* OpenMesh A62

  - not yet accepted
  - http://lists.infradead.org/pipermail/ath10k/2018-March/011081.html



Still waiting for send BDFs to upstream
===

* Meraki MR33

  - Chris Blake?
  - 
https://github.com/openwrt/openwrt/blob/master/package/firmware/ipq-wifi/board-meraki_mr33.bin

* Fritzbox 4040

  - Christian Lamparter?
  - 
https://github.com/openwrt/openwrt/blob/master/package/firmware/ipq-wifi/board-avm_fritzbox-4040.bin

* maybe more which I missed


Kind regards,
Sven




--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


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

[PATCH] ath10k: correct target assert problem due to CE5 stuck

2018-04-12 Thread mpubbise

From: Manikanta Pubbisetty 

Correct a minor bug in the commit 0628467f97b5 ("ath10k: fix
copy engine 5 destination ring stuck") which introduced a change to fix
firmware assert that happens when ring indices of copy engine 5 are stuck
for a specific duration, problem with this fix is that it did not use
ring arithmatic. As a result,firmware asserts did not go away entirely
athough the frequency of occurrence has reduced. Using ring arithmatic
to fix the issue.

Tested on QCA9984(fw version-10.4-3.4-00082).

Fixes: 0628467f97b5 ("ath10k: fix copy engine 5 destination ring stuck)
Signed-off-by: Manikanta Pubbisetty 
---
 drivers/net/wireless/ath/ath10k/ce.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/ce.c 
b/drivers/net/wireless/ath/ath10k/ce.c
index b9def7b..6efa69e 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -615,7 +615,7 @@ void ath10k_ce_rx_update_write_idx(struct ath10k_ce_pipe 
*pipe, u32 nentries)
/* Prevent CE ring stuck issue that will occur when ring is full.
 * Make sure that write index is 1 less than read index.
 */
-   if ((cur_write_idx + nentries)  == dest_ring->sw_index)
+   if (((cur_write_idx + nentries) & nentries_mask) == dest_ring->sw_index)
nentries -= 1;
 
write_index = CE_RING_IDX_ADD(nentries_mask, write_index, nentries);
-- 
2.7.4


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

[PATCH] ath10k: correct target assert problem due to CE5 stuck

2018-04-12 Thread mpubbise

From: Manikanta Pubbisetty 

Correct a minor bug in the commit 0628467f97b5 ("ath10k: fix
copy engine 5 destination ring stuck") which introduced a change to fix
firmware assert that happens when ring indices of copy engine 5 are stuck
for a specific duration, problem with this fix is that it did not use
ring arithmatic. As a result,firmware asserts did not go away entirely
athough the frequency of occurrence has reduced. Using ring arithmatic
to fix the issue.

Tested on QCA9984(fw version-10.4-3.4-00082).

Fixes: 0628467f97b5 ("ath10k: fix copy engine 5 destination ring stuck)
Signed-off-by: Manikanta Pubbisetty 
---
 drivers/net/wireless/ath/ath10k/ce.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/ce.c 
b/drivers/net/wireless/ath/ath10k/ce.c
index b9def7b..6efa69e 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -615,7 +615,7 @@ void ath10k_ce_rx_update_write_idx(struct ath10k_ce_pipe 
*pipe, u32 nentries)
/* Prevent CE ring stuck issue that will occur when ring is full.
 * Make sure that write index is 1 less than read index.
 */
-   if ((cur_write_idx + nentries)  == dest_ring->sw_index)
+   if (((cur_write_idx + nentries) & nentries_mask) == dest_ring->sw_index)
nentries -= 1;
 
write_index = CE_RING_IDX_ADD(nentries_mask, write_index, nentries);
-- 
2.7.4


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

Re: [PATCH] ath10k:add support for multicast rate control

2018-04-12 Thread Sven Eckelmann

On Mittwoch, 11. April 2018 21:04:46 CEST Pradeep Kumar Chitrapu wrote:
> Issues wmi command to firmware when multicast rate change is received
> with the new BSS_CHANGED_MCAST_RATE flag.
[...]
>  
> + if (changed & BSS_CHANGED_MCAST_RATE &&
> + !WARN_ON(ath10k_mac_vif_chan(arvif->vif, ))) {
> + band = def.chan->band;
> + sband = >mac.sbands[band];
> + vdev_param = ar->wmi.vdev_param->mcast_data_rate;
> + rate_index = vif->bss_conf.mcast_rate[band] - 1;
> + rate = ATH10K_HW_MCS_RATE(sband->bitrates[rate_index].hw_value);
> + ath10k_dbg(ar, ATH10K_DBG_MAC,
> +"mac vdev %d mcast_rate %d\n",
> +arvif->vdev_id, rate);
> +
> + ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
> + vdev_param, rate);
> + if (ret)
> + ath10k_warn(ar,
> + "failed to set mcast rate on vdev"
> + " %i: %d\n", arvif->vdev_id,  ret);
> + }
> +
>   mutex_unlock(>conf_mutex);
>  }
>  
> 

I see two major problems here without checking the actual implementation 
details:

* hw_value is incorrect for a couple of devices. Some devices use a different 
  mapping when they receive rates inforamtion (hw_value) then the ones you use
  for the mcast/bcast/beacon rate setting. I've handled in my POC patch like
  this:

+   if (ath10k_mac_bitrate_is_cck(sband->bitrates[i].bitrate)) {
+   preamble = WMI_RATE_PREAMBLE_CCK;
+
+   /* QCA didn't use the correct rate values for CA99x0
+* and above (ath10k_g_rates_rev2)
+*/
+   switch (sband->bitrates[i].bitrate) {
+   case 10:
+   hw_value = ATH10K_HW_RATE_CCK_LP_1M;
+   break;
+   case 20:
+   hw_value = ATH10K_HW_RATE_CCK_LP_2M;
+   break;
+   case 55:
+   hw_value = ATH10K_HW_RATE_CCK_LP_5_5M;
+   break;
+   case 110:
+   hw_value = ATH10K_HW_RATE_CCK_LP_11M;
+   break;
+   }
+   } else {
+   preamble = WMI_RATE_PREAMBLE_OFDM;
+   }

* bcast + mcast (+ mgmt) have to be set separately

I have attached my POC patch (which I was using for packet loss based mesh 
metrics) and to work around (using debugfs) the silly mgmt vs. mcast/bcast 
settings of the QCA fw for APs.

Many of the information came from Ben Greears ath10k-ct driver 
https://github.com/greearb/ath10k-ct 

Kind regards,   
SvenFrom: Sven Eckelmann 
Date: Fri, 16 Feb 2018 13:49:51 +0100
Subject: [PATCH] ath10k: Allow to configure bcast/mcast rate

TODO:

 * find better way to get mcast_rate
 * better get the lowest configured basic rate for APs
 * remove netifd WAR

Signed-off-by: Sven Eckelmann 

Forwarded: no
 not yet in the correct shape
---
 drivers/net/wireless/ath/ath10k/core.h  |   1 +
 drivers/net/wireless/ath/ath10k/debug.c |  78 ++
 drivers/net/wireless/ath/ath10k/debug.h |  11 
 drivers/net/wireless/ath/ath10k/mac.c   | 113 
 drivers/net/wireless/ath/ath10k/mac.h   |   1 +
 5 files changed, 204 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 3ff4a423c4d873d322deebd3c498ef0688e84e05..a53f7b2042f4a80bbd358b00d4d26d6fabe5df6e 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -423,6 +423,7 @@ struct ath10k_vif {
 	bool nohwcrypt;
 	int num_legacy_stations;
 	int txpower;
+	u16 mcast_rate;
 	struct wmi_wmm_params_all_arg wmm_params;
 	struct work_struct ap_csa_work;
 	struct delayed_work connection_loss_work;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index fa72ef54605e74f501ab655a6afd0a50b89b6b7e..fc59f214d2a5288f2ac41824e584def787b4799c 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -23,6 +23,7 @@
 #include 
 
 #include "core.h"
+#include "mac.h"
 #include "debug.h"
 #include "hif.h"
 #include "wmi-ops.h"
@@ -2454,6 +2455,83 @@ void ath10k_debug_unregister(struct ath10k *ar)
 	cancel_delayed_work_sync(>debug.htt_stats_dwork);
 }
 
+
+
+static ssize_t ath10k_write_mcast_rate(struct file *file,
+   const char __user *ubuf,
+   size_t count, loff_t *ppos)
+{
+	struct ath10k_vif *arvif = file->private_data;
+	struct ath10k *ar = arvif->ar;
+	ssize_t ret = 0;
+	u32 mcast_rate;
+
+	ret = kstrtou32_from_user(ubuf, count, 0, _rate);

Re: Please add new board files for WLE1216V5-20 and another Compex NIC.

2018-04-12 Thread Sven Eckelmann

On Mittwoch, 11. April 2018 08:18:15 CEST Tim Harvey wrote:
> It's not clear what the process is for getting new board id's
> supported in the board.bin files.

The reaction of QCA when asking for new IDs was mostly "please go away, we 
will not talk to you about it". But with the help of Kalle Valo, a new 
mechanism called "qcom,ath10k-calibration-variant" was added (for embedded 
boards which include QCA 11ac wave2 radios). There are a couple of mails 
about it on this list - a general overview about BDFs, variant strings and 
why we need them can be found at 
http://lists.infradead.org/pipermail/ath10k/2018-March/011066.html.

But it looks like you really got the IDs 30+31 (maybe because you are selling 
the, as separate PCIe modules?). Then I would guess that you can still use the 
same process as we use for the accesspoint specific BDFs (just without the 
variant= part).

The description of the general upstreaming process can be found at 
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/boardfiles - but it 
seems like Kalle Valo doesn't have much time for it at the moment for it (or
there might be other problems which we don't see from our perspective - for 
example legal departments).

Maybe you or Ben Greear can enhance the submission for the BDFs to better 
answer the questions from the "Submitting board files" guide. 

Examples for such submission

* OpenMesh A42

  - applied
  - http://lists.infradead.org/pipermail/ath10k/2017-November/010470.html
  - http://lists.infradead.org/pipermail/ath10k/2017-December/010543.html

* Asus RT-AC58U

  - not yet accepted
  - submitted before the guide was published
  - http://lists.infradead.org/pipermail/ath10k/2017-March/009454.html

* Netgear EX6100v2/EX6150v2

  - not yet accepted
  - http://lists.infradead.org/pipermail/ath10k/2018-February/010845.html

* 8devices Jalapeno

  - not yet accepted
  - http://lists.infradead.org/pipermail/ath10k/2018-March/010916.html

* GL.iNet GL-B1300

  - not yet accepted
  - http://lists.infradead.org/pipermail/ath10k/2018-March/011058.html

* OpenMesh A62

  - not yet accepted
  - http://lists.infradead.org/pipermail/ath10k/2018-March/011081.html

Still waiting for send BDFs to upstream
===

* Meraki MR33

  - Chris Blake?
  - 
https://github.com/openwrt/openwrt/blob/master/package/firmware/ipq-wifi/board-meraki_mr33.bin

* Fritzbox 4040

  - Christian Lamparter?
  - 
https://github.com/openwrt/openwrt/blob/master/package/firmware/ipq-wifi/board-avm_fritzbox-4040.bin

* maybe more which I missed

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] ath10k: Implement get_expected_throughput callback

Re: [PATCH 2/2] ath10k: support MAC address randomization in scan

Re: Please add new board files for WLE1216V5-20 and another Compex NIC.

[PATCH] ath10k: correct target assert problem due to CE5 stuck

[PATCH] ath10k: correct target assert problem due to CE5 stuck

Re: [PATCH] ath10k:add support for multicast rate control

Re: Please add new board files for WLE1216V5-20 and another Compex NIC.

7 matches

Site Navigation

Mail list logo

Footer information