[PATCH v2 2/2] wireless-regdb: Sync DE with ETSI EN 301 893 V2.1.1 (2017-05)

[Sven Eckelmann]

The documents
https://www.etsi.org/deliver/etsi_en/301800_301899/301893/02.01.01_60/en_301893v020101p.pdf
and
https://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/2010_07_WLAN_5GHz_pdf.pdf
show that the limits for the 5GHz bands are out of date:

* 5150 - 5250 MHz only usage is allowed to use up to 23 dBm (200 mW) even
  without TPC

Signed-off-by: Sven Eckelmann 
---
 db.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/db.txt b/db.txt
index 7f978e1..8f356f7 100644
--- a/db.txt
+++ b/db.txt
@@ -378,7 +378,7 @@ country CZ: DFS-ETSI
 
 country DE: DFS-ETSI
(2400 - 2483.5 @ 40), (100 mW)
-   (5150 - 5250 @ 80), (100 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+   (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
(5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
# short range devices (ETSI EN 300 440-1)
-- 
2.11.0

Re: [PATCH 2/2] wireless-regdb: Sync DE with ETSI EN 301 893 V2.1.1 (2017-05)

[Sven Eckelmann]

On Montag, 17. September 2018 09:42:12 CEST Sven Eckelmann wrote:
[...]
> diff --git a/db.txt b/db.txt
> index 7f978e1..f406ac0 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -379,7 +379,7 @@ country CZ: DFS-ETSI
>  country DE: DFS-ETSI
>   (2400 - 2483.5 @ 40), (100 mW)
>   (5150 - 5250 @ 80), (100 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
> - (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
> + (5250 - 5350 @ 80), (200 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
>   (5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
>   # short range devices (ETSI EN 300 440-1)
>   (5725 - 5875 @ 80), (25 mW)

Grml, I had only one task still copied it to the wrong line

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

[PATCH 2/2] wireless-regdb: Sync DE with ETSI EN 301 893 V2.1.1 (2017-05)

[Sven Eckelmann]

The documents
https://www.etsi.org/deliver/etsi_en/301800_301899/301893/02.01.01_60/en_301893v020101p.pdf
and
https://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/2010_07_WLAN_5GHz_pdf.pdf
show that the limits for the 5GHz bands are out of date:

* 5150 - 5250 MHz only usage is allowed to use up to 23 dBm (200 mW) even
  without TPC

Signed-off-by: Sven Eckelmann 
---
 db.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/db.txt b/db.txt
index 7f978e1..f406ac0 100644
--- a/db.txt
+++ b/db.txt
@@ -379,7 +379,7 @@ country CZ: DFS-ETSI
 country DE: DFS-ETSI
(2400 - 2483.5 @ 40), (100 mW)
(5150 - 5250 @ 80), (100 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
-   (5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+   (5250 - 5350 @ 80), (200 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
(5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
# short range devices (ETSI EN 300 440-1)
(5725 - 5875 @ 80), (25 mW)
-- 
2.11.0

[PATCH 1/2] wireless-regdb: Sync FR with ETSI EN 301 893 V2.1.1 (2017-05)

[Sven Eckelmann]

The documents
https://www.etsi.org/deliver/etsi_en/301800_301899/301893/02.01.01_60/en_301893v020101p.pdf
and
https://www.anfr.fr/fileadmin/mediatheque/documents/controle/20171127ANFR_-_ficheRLAN_5GHz.pdf
show that the limits for the 5GHz bands are out of date:

* frequencies don't match the official limits
* 5150 - 5350 MHz is not for outdoor usage
* 5150 - 5250 MHz only usage is allowed to use up to 23 dBm (200 mW) even
  without TPC

Signed-off-by: Sven Eckelmann 
---
 db.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/db.txt b/db.txt
index bc64628..7f978e1 100644
--- a/db.txt
+++ b/db.txt
@@ -475,9 +475,9 @@ country FM: DFS-FCC
 
 country FR: DFS-ETSI
(2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
-   (5250 - 5330 @ 80), (20), DFS, AUTO-BW, wmmrule=ETSI
-   (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
+   (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+   (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+   (5470 - 5725 @ 160), (27), DFS, wmmrule=ETSI
 # short range devices (ETSI EN 300 440)
(5725 - 5875 @ 80), (25 mW)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
-- 
2.11.0

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

[Sven Eckelmann]

On Dienstag, 4. September 2018 14:40:55 CEST Luca Coelho wrote:
> )
> Sender: linux-wireless-ow...@vger.kernel.org
> Precedence: bulk
> List-ID: 
> X-Mailing-List: linux-wireless@vger.kernel.org

Looks like the SMTP headers are broken in all your patches. Here the 
interesting part (as received by me):

[...]
X-SA-Exim-Scanned: Yes (on 

)
Sender: linux-wireless-ow...@vger.kernel.org
Precedence: bulk
List-ID: 
X-Mailing-List: linux-wireless@vger.kernel.org

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: mac80211: AQM and block_tx

[Sven Eckelmann]

On Dienstag, 10. Juli 2018 18:09:37 CEST Manikanta Pubbisetty wrote:
[...]
> I am working on a patch which takes care of stopping the iTXQs after 
> detecting a radar(covering other scenarios where stopping iTXQs is 
> important)
> and there by making sure packets are not transmitted.
[...]
> https://patchwork.kernel.org/patch/10516887/

Thanks for telling me about this patch. It indeed prevents the unwanted TX 
during CSA (and thanks for the explanation in the commit message about the 
underlying problem).

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: mac80211: AQM and block_tx

[Sven Eckelmann]

On Donnerstag, 5. Juli 2018 10:47:11 CEST Sven Eckelmann wrote:
> Hi Toke,
> 
> we are currently testing DFS with ath10k and noticed that AQM seems to ignore 
> cfg80211_csa_settings->block_tx. Problem is now that the channel switch is 
> started on a detected radar
> 
>   echo 1 >/sys/kernel/debug/ieee80211/phy1/ath10k/dfs_simulate_radar
> 
> NL80211_ATTR_CH_SWITCH_BLOCK_TX is set for the channel switch by hostapd but 
> the AP still sends QoS data to the client.
> 
> Was there a fix for such a problem which I might have missed? I've just 
> worked 
> around that by setting wake_tx_queue TO NULL in ath10k. This still must be 
> verified but at least I didn't see any packets anymore on a monitor interface.


Just as information, the ath10k Dakota devices went through DFS certification 
but the AQM had to be disabled. Otherwise we would have had problems with the 
FCC closing time.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

mac80211: AQM and block_tx

[Sven Eckelmann]

Hi Toke,

we are currently testing DFS with ath10k and noticed that AQM seems to ignore 
cfg80211_csa_settings->block_tx. Problem is now that the channel switch is 
started on a detected radar

  echo 1 >/sys/kernel/debug/ieee80211/phy1/ath10k/dfs_simulate_radar

NL80211_ATTR_CH_SWITCH_BLOCK_TX is set for the channel switch by hostapd but 
the AP still sends QoS data to the client.

Was there a fix for such a problem which I might have missed? I've just worked 
around that by setting wake_tx_queue TO NULL in ath10k. This still must be 
verified but at least I didn't see any packets anymore on a monitor interface.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

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

[Sven Eckelmann]

On Montag, 7. Mai 2018 18:34:51 CEST Pradeep Kumar Chitrapu wrote:
> Issues wmi command to firmwre when multicast rate change is received
> with the new BSS_CHANGED_MCAST_RATE flag.
> Also fixes the incorrect fixed_rate setting for CCK rates which got
> introduced with addition of ath10k_rates_rev2 enum.
> 
> Tested on QCA9984 with firmware ver 10.4-3.6-00104
> 
> Signed-off-by: Pradeep Kumar Chitrapu 
> ---
> v2:
>  - fixed the CCK rates setting for mcast_rate and fixed_rate paths.
>  - set broadcast rate along with multicast rate setting.

These things are only modified in ath10k_bss_info_changed and not saved/
restored. What happens when the HW needs to be reset (there are are couple of 
firmware crashes which can be seen in the wild and are handled by ath10k)? I 
would guess that not all of them automatically cause an .bss_info_changed.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

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

[Sven Eckelmann]

On Montag, 16. April 2018 22:10:50 CEST prade...@codeaurora.org wrote:
[...]
> > 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
[...]
> Isn't this already fixed in https://patchwork.kernel.org/patch/9150145/ 
> ?

No, this is exactly the patch which causes the problem for you. The parameter 
for these settings stayed the same but this patch changes the order in 
ieee80211_rate to make it easier for the driver to parse the (reordered) rx 
status information for CCK rates (maybe also tx - not sure about that right 
now).

> > * bcast + mcast (+ mgmt) have to be set separately
> 
> Can you please let me know why this would be necessary?
> Although I see minstrel rate control is currently seems using the 
> mcast_rate
> setting to set MGMT/BCAST/MCAST rates, will this not be misleading to 
> user
> passed value with 'iw set mcast_rate' for MGMT traffic as well?

What about broadcast? MGMT was only mentioned here because it is the third 
item which can be manipulated the same way. But yes, it would be good to get 
the mgmt rates in sync with the non-hw-rate-control drivers.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 2/2] ath9k: fix tx99 bus error

[Sven Eckelmann]

On Dienstag, 20. Juni 2017 09:13:40 CEST miaoq...@codeaurora.org wrote:
> From: Miaoqing Pan 
> 
> The hard coded register 0x9864 and 0x9924 are invalid
> for ar9300 chips.
[...]
> - REG_SET_BIT(ah, 0x9864, 0x7f000);
> - REG_SET_BIT(ah, 0x9924, 0x7f00fe);

Sorry that this messages comes so later after the patch was accepted. But what 
were these things expected to do? My guess is that 0x9864 is AR_PHY_CCA and 
the other one is something else (AR_PHY_TIMING5?). But yes, these would be 
ar9002
and not AR9003.

What are the problems that we would expect when the CCA threshold and the 
CYCPWR 
threshold are no longer be set to the highest possible value? Are we now 
expecting 
that the device is not transmitting at 99% when it sees other signals?

Btw. why are you writing that ar9300 chips don't have this? It looks to me 
like the original code was taken from QCA's 9300 code [1]. Was it always broken
in the AR9300 hal and how was it now fixed with with the newer HALs?

Could it be that newer chips just have it mapped to a different location? AGC 
on the 9300 seems to be at 0x9e00 and maybe the cca register should have been 
0x9e1c (AR_PHY_CCA_0) and should be set to AR_PHY_CCA_THRESH62? And there is 
also a AR_PHY_TIMING5 (0x9810) which might have to be set to 
AR_PHY_TIMING5_CYCPWR_THR1 | AR_PHY_TIMING5_CYCPWR_THR1A. Of course, I have 
absolutely no idea whether these registers actually control the 
same thing and whether the settings are correct.

Kind regards,
Sven

[1] 
https://github.com/freebsd/freebsd/blob/386ddae58459341ec567604707805814a2128a57/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_tx99_tgt.c#L502


signature.asc
Description: This is a digitally signed message part.

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

[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 <s...@narfation.org>
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 <s...@narfation.org>

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 __u

Re: [PATCH v2] ath10k: Implement get_expected_throughput callback

[Sven Eckelmann]

On Mittwoch, 28. März 2018 11:41:51 CEST ako...@codeaurora.org wrote:
[...]
> The rate average and throughput are relative. no?

In the sense that rate has a tendency to affect the expected throughput - yes. 
But it is not like the expected throughput perfectly correlates with the rate 
and you only have to multiply with a factor X (which seems to be missing in 
your code) to get from rate to expected throughput. The average packet loss 
for this selected rate, interframe spacing and the aggregation are important 
factors here too.

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.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v2] ath10k: Implement get_expected_throughput callback

[Sven Eckelmann]

On Freitag, 23. März 2018 19:37:14 CEST Anilkumar Kolli wrote:
> +static u32 ath10k_get_expected_throughput(struct ieee80211_hw *hw,
> + struct ieee80211_sta *sta)
> +{
> +   struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
> +
> +   return ewma_sta_txrate_read(>ave_sta_txrate);
> +}

On Freitag, 23. März 2018 19:11:48 CEST ako...@codeaurora.org wrote:
> > Antonio and Felix, please correct me when this statement is incorrect.
> >
> > The expected_throughput as initially implemented for minstrel(_ht) is 
> > not
> > about the raw physical bitrate but about the throughput which is 
> > expected for
> > things running on top of the wifi link. See
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cca674d47e59665630f3005291b61bb883015fc5
> > for more details
> >
> > when I interpret your change correctly then your it doesn't get the
> > information about packet loss or aggregation and doesn't do anything 
> > convert
> > from raw physical rate to something the user could get see. It will 
> > just
> > overestimate the throughput for ath10k links and thus give wrong 
> > information
> > to routing algorithms. This could for example cause them to prefer 
> > links over
> > ath10k based hw when mt76 would actually provide a significant better
> > throughput.
> >
> > Beside that - why is the ave_sta_txrate only filled when with new 
> > information
> > when someone requests the current expected_throughput via
> > get_expected_throughput. I would have expected that it is filled 
> > everytime you
> > get new information about the current rate from the firmware
> > (ath10k_sta_statistics).
> >
> Yes. ideally it should be doing the rate avg. of all the sent packets.

No, not the PHY rate average - but the "throughput avg". And the "ideally" 
here sounds a little bit like in "Our medical doctor would ideally not 
decapitate each patient but we have at least an MD".

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ath10k: Implement get_expected_throughput callback

[Sven Eckelmann]

On Freitag, 23. März 2018 13:07:00 CET Anilkumar Kolli wrote:
[...]
> +static u32 ath10k_get_expected_throughput(struct ieee80211_hw *hw,
> + struct ieee80211_sta *sta)
> +{
> +   struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
> +   u32 tx_bitrate;
> +
> +   tx_bitrate = cfg80211_calculate_bitrate(>txrate);
> +   ewma_sta_txrate_add(>ave_sta_txrate, tx_bitrate);
> +
> +   return ewma_sta_txrate_read(>ave_sta_txrate);
>  }

Antonio and Felix, please correct me when this statement is incorrect.

The expected_throughput as initially implemented for minstrel(_ht) is not 
about the raw physical bitrate but about the throughput which is expected for 
things running on top of the wifi link. See 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cca674d47e59665630f3005291b61bb883015fc5
 
for more details

when I interpret your change correctly then your it doesn't get the 
information about packet loss or aggregation and doesn't do anything convert
from raw physical rate to something the user could get see. It will just 
overestimate the throughput for ath10k links and thus give wrong information 
to routing algorithms. This could for example cause them to prefer links over 
ath10k based hw when mt76 would actually provide a significant better 
throughput.

Beside that - why is the ave_sta_txrate only filled when with new information 
when someone requests the current expected_throughput via 
get_expected_throughput. I would have expected that it is filled everytime you 
get new information about the current rate from the firmware 
(ath10k_sta_statistics).

> @@ -7686,6 +7686,22 @@ static void ath10k_sta_statistics(struct ieee80211_hw 
> *hw,
> }
> sinfo->txrate.flags = arsta->txrate.flags;
> sinfo->filled |= 1ULL << NL80211_STA_INFO_TX_BITRATE;
> +
> +   sinfo->expected_throughput =
> +   ewma_sta_txrate_read(>ave_sta_txrate);
> +   sinfo->filled |= BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT);
> +}

This brings me directly to the next point. Why are you changing these values 
here? Isn't sta_set_sinfo is expected to do that? This is at least what we
expect how it works when we call cfg80211_get_station() in batman-adv.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 2/2] ath10k: add debugfs support to configure fwtest parameters

[Sven Eckelmann]

On Montag, 5. März 2018 12:29:08 CET Anilkumar Kolli wrote:
> @@ -496,6 +497,8 @@ struct ath10k_debug {
> u32 reg_addr;
> u32 nf_cal_period;
> void *cal_data;
> +   u32 fw_test_param_id;
> +   u32 fw_test_param_value;
>  };

Why is it necessary to have these two values in ath10k_debug? They seem to be 
used only in the context of ath10k_write_fw_test().

Where can we find the documentation of the possible param_id and param_values?

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

[PATCH 35/52] ath: Map Lebanon to APL1_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: NO_CTL -> FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index dee9db074d84..1b69849b4727 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -434,7 +434,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_KOREA_ROC3, APL9_MKKC, "K3"},
{CTRY_KUWAIT, ETSI3_WORLD, "KW"},
{CTRY_LATVIA, ETSI1_WORLD, "LV"},
-   {CTRY_LEBANON, NULL1_WORLD, "LB"},
+   {CTRY_LEBANON, APL1_WORLD, "LB"},
{CTRY_LIECHTENSTEIN, ETSI1_WORLD, "LI"},
{CTRY_LITHUANIA, ETSI1_WORLD, "LT"},
{CTRY_LUXEMBOURG, ETSI1_WORLD, "LU"},
-- 
2.11.0

[PATCH 36/52] ath: Map Macedonia to ETSI1_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: NO_CTL -> ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 1b69849b4727..f457c9d50bd2 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -439,7 +439,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_LITHUANIA, ETSI1_WORLD, "LT"},
{CTRY_LUXEMBOURG, ETSI1_WORLD, "LU"},
{CTRY_MACAU, FCC2_WORLD, "MO"},
-   {CTRY_MACEDONIA, NULL1_WORLD, "MK"},
+   {CTRY_MACEDONIA, ETSI1_WORLD, "MK"},
{CTRY_MALAYSIA, APL8_WORLD, "MY"},
{CTRY_MALTA, ETSI1_WORLD, "MT"},
{CTRY_MAURITIUS, ETSI1_WORLD, "MU"},
-- 
2.11.0

[PATCH 52/52] ath: Map Zimbabwe to ETSI1_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: NO_CTL -> ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 7e06d1146e8a..cd4e47f48cc8 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -500,7 +500,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_VENEZUELA, FCC1_WORLD, "VE"},
{CTRY_VIET_NAM, ETSI3_WORLD, "VN"},
{CTRY_YEMEN, NULL1_WORLD, "YE"},
-   {CTRY_ZIMBABWE, NULL1_WORLD, "ZW"},
+   {CTRY_ZIMBABWE, ETSI1_WORLD, "ZW"},
 };
 
 #endif
-- 
2.11.0

[PATCH 48/52] ath: Map Ukraine to ETSI9_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: NO_CTL -> ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index a4a55663e58f..e41a0ce332a8 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -486,7 +486,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_TUNISIA, ETSI3_WORLD, "TN"},
{CTRY_TURKEY, ETSI3_WORLD, "TR"},
{CTRY_UGANDA, FCC3_WORLD, "UG"},
-   {CTRY_UKRAINE, NULL1_WORLD, "UA"},
+   {CTRY_UKRAINE, ETSI9_WORLD, "UA"},
{CTRY_UAE, NULL1_WORLD, "AE"},
{CTRY_UNITED_KINGDOM, ETSI1_WORLD, "GB"},
{CTRY_UNITED_STATES, FCC3_FCCA, "US"},
-- 
2.11.0

[PATCH 45/52] ath: Map Saudi Arabia to FCC2_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: NO_CTL -> FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index ba5f112333b8..c20ff7640061 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -467,7 +467,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_ROMANIA, ETSI1_WORLD, "RO"},
{CTRY_RUSSIA, ETSI8_WORLD, "RU"},
{CTRY_RWANDA, APL1_WORLD, "RW"},
-   {CTRY_SAUDI_ARABIA, NULL1_WORLD, "SA"},
+   {CTRY_SAUDI_ARABIA, FCC2_WORLD, "SA"},
{CTRY_SERBIA, ETSI1_WORLD, "RS"},
{CTRY_SERBIA_MONTENEGRO, ETSI1_WORLD, "CS"},
{CTRY_SINGAPORE, APL6_WORLD, "SG"},
-- 
2.11.0

[PATCH 49/52] ath: Map U.A.E. to ETSI1_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: NO_CTL -> ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index e41a0ce332a8..aba44cffce3d 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -487,7 +487,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_TURKEY, ETSI3_WORLD, "TR"},
{CTRY_UGANDA, FCC3_WORLD, "UG"},
{CTRY_UKRAINE, ETSI9_WORLD, "UA"},
-   {CTRY_UAE, NULL1_WORLD, "AE"},
+   {CTRY_UAE, ETSI1_WORLD, "AE"},
{CTRY_UNITED_KINGDOM, ETSI1_WORLD, "GB"},
{CTRY_UNITED_STATES, FCC3_FCCA, "US"},
{CTRY_UNITED_STATES2, FCC6_FCCA, "US"},
-- 
2.11.0

[PATCH 51/52] ath: Map Vietnam to ETSI3_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: NO_CTL -> ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index d22eff3fe75b..7e06d1146e8a 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -498,7 +498,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_URUGUAY, FCC3_WORLD, "UY"},
{CTRY_UZBEKISTAN, FCC3_FCCA, "UZ"},
{CTRY_VENEZUELA, FCC1_WORLD, "VE"},
-   {CTRY_VIET_NAM, NULL1_WORLD, "VN"},
+   {CTRY_VIET_NAM, ETSI3_WORLD, "VN"},
{CTRY_YEMEN, NULL1_WORLD, "YE"},
{CTRY_ZIMBABWE, NULL1_WORLD, "ZW"},
 };
-- 
2.11.0

[PATCH 50/52] ath: Map Venezuela to FCC1_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

This change itself doesn't change the selected CTL of this country and is
only required to stay in sync with the QCA mappings.

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index aba44cffce3d..d22eff3fe75b 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -497,7 +497,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_UNITED_STATES_FCC49, FCC4_FCCA, "PS"},
{CTRY_URUGUAY, FCC3_WORLD, "UY"},
{CTRY_UZBEKISTAN, FCC3_FCCA, "UZ"},
-   {CTRY_VENEZUELA, APL2_ETSIC, "VE"},
+   {CTRY_VENEZUELA, FCC1_WORLD, "VE"},
{CTRY_VIET_NAM, NULL1_WORLD, "VN"},
{CTRY_YEMEN, NULL1_WORLD, "YE"},
{CTRY_ZIMBABWE, NULL1_WORLD, "ZW"},
-- 
2.11.0

[PATCH 46/52] ath: Map Singapore to FCC3_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: ETSI -> FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index c20ff7640061..f0b51858b965 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -470,7 +470,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_SAUDI_ARABIA, FCC2_WORLD, "SA"},
{CTRY_SERBIA, ETSI1_WORLD, "RS"},
{CTRY_SERBIA_MONTENEGRO, ETSI1_WORLD, "CS"},
-   {CTRY_SINGAPORE, APL6_WORLD, "SG"},
+   {CTRY_SINGAPORE, FCC3_WORLD, "SG"},
{CTRY_SLOVAKIA, ETSI1_WORLD, "SK"},
{CTRY_SLOVENIA, ETSI1_WORLD, "SI"},
{CTRY_SOUTH_AFRICA, FCC3_WORLD, "ZA"},
-- 
2.11.0

[PATCH 39/52] ath: Map New Zealand to FCC3_ETSIC

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

This change itself doesn't change the selected CTL of this country and is
only required to stay in sync with the QCA mappings.

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index ca1f07e55aec..6824b1db6d16 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -450,7 +450,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_NEPAL, APL1_WORLD, "NP"},
{CTRY_NETHERLANDS, ETSI1_WORLD, "NL"},
{CTRY_NETHERLANDS_ANTILLES, ETSI1_WORLD, "AN"},
-   {CTRY_NEW_ZEALAND, FCC2_ETSIC, "NZ"},
+   {CTRY_NEW_ZEALAND, FCC3_ETSIC, "NZ"},
{CTRY_NICARAGUA, FCC3_FCCA, "NI"},
{CTRY_NORWAY, ETSI1_WORLD, "NO"},
{CTRY_OMAN, FCC3_WORLD, "OM"},
-- 
2.11.0

[PATCH 44/52] ath: Map Russia to ETSI8_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: NO_CTL -> ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 0baa028ce7a2..ba5f112333b8 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -465,7 +465,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_PUERTO_RICO, FCC1_FCCA, "PR"},
{CTRY_QATAR, APL1_WORLD, "QA"},
{CTRY_ROMANIA, ETSI1_WORLD, "RO"},
-   {CTRY_RUSSIA, NULL1_WORLD, "RU"},
+   {CTRY_RUSSIA, ETSI8_WORLD, "RU"},
{CTRY_RWANDA, APL1_WORLD, "RW"},
{CTRY_SAUDI_ARABIA, NULL1_WORLD, "SA"},
{CTRY_SERBIA, ETSI1_WORLD, "RS"},
-- 
2.11.0

[PATCH 47/52] ath: Map Taiwan to APL7_FCCA

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

This change itself doesn't change the selected CTL of this country and is
only required to stay in sync with the QCA mappings.

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index f0b51858b965..a4a55663e58f 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -479,7 +479,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_SWEDEN, ETSI1_WORLD, "SE"},
{CTRY_SWITZERLAND, ETSI1_WORLD, "CH"},
{CTRY_SYRIA, NULL1_WORLD, "SY"},
-   {CTRY_TAIWAN, APL3_FCCA, "TW"},
+   {CTRY_TAIWAN, APL7_FCCA, "TW"},
{CTRY_TANZANIA, APL1_WORLD, "TZ"},
{CTRY_THAILAND, FCC3_WORLD, "TH"},
{CTRY_TRINIDAD_Y_TOBAGO, FCC3_WORLD, "TT"},
-- 
2.11.0

[PATCH 38/52] ath: Map Mexico to FCC1_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: FCC-> ETSI
* 5GHz: FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index efc363af5e41..ca1f07e55aec 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -443,7 +443,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_MALAYSIA, FCC1_WORLD, "MY"},
{CTRY_MALTA, ETSI1_WORLD, "MT"},
{CTRY_MAURITIUS, ETSI1_WORLD, "MU"},
-   {CTRY_MEXICO, FCC1_FCCA, "MX"},
+   {CTRY_MEXICO, FCC1_WORLD, "MX"},
{CTRY_MONACO, ETSI4_WORLD, "MC"},
{CTRY_MONTENEGRO, ETSI1_WORLD, "ME"},
{CTRY_MOROCCO, APL4_WORLD, "MA"},
-- 
2.11.0

[PATCH 41/52] ath: Map Peru to APL1_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

This change itself doesn't change the selected CTL of this country and is
only required to stay in sync with the QCA mappings.

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 1d49300451a8..983572ea7048 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -458,7 +458,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_PANAMA, FCC1_FCCA, "PA"},
{CTRY_PAPUA_NEW_GUINEA, FCC1_WORLD, "PG"},
{CTRY_PARAGUAY, FCC3_WORLD, "PY"},
-   {CTRY_PERU, APL1_WORLD, "PE"},
+   {CTRY_PERU, FCC3_WORLD, "PE"},
{CTRY_PHILIPPINES, APL1_WORLD, "PH"},
{CTRY_POLAND, ETSI1_WORLD, "PL"},
{CTRY_PORTUGAL, ETSI1_WORLD, "PT"},
-- 
2.11.0

[PATCH 42/52] ath: Map Philippines to FCC3_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

This change itself doesn't change the selected CTL of this country and is
only required to stay in sync with the QCA mappings.

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 983572ea7048..66c4a579cb99 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -459,7 +459,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_PAPUA_NEW_GUINEA, FCC1_WORLD, "PG"},
{CTRY_PARAGUAY, FCC3_WORLD, "PY"},
{CTRY_PERU, FCC3_WORLD, "PE"},
-   {CTRY_PHILIPPINES, APL1_WORLD, "PH"},
+   {CTRY_PHILIPPINES, FCC3_WORLD, "PH"},
{CTRY_POLAND, ETSI1_WORLD, "PL"},
{CTRY_PORTUGAL, ETSI1_WORLD, "PT"},
{CTRY_PUERTO_RICO, FCC1_FCCA, "PR"},
-- 
2.11.0

[PATCH 43/52] ath: Map Romania to ETSI1_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: NO_CTL -> ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 66c4a579cb99..0baa028ce7a2 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -464,7 +464,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_PORTUGAL, ETSI1_WORLD, "PT"},
{CTRY_PUERTO_RICO, FCC1_FCCA, "PR"},
{CTRY_QATAR, APL1_WORLD, "QA"},
-   {CTRY_ROMANIA, NULL1_WORLD, "RO"},
+   {CTRY_ROMANIA, ETSI1_WORLD, "RO"},
{CTRY_RUSSIA, NULL1_WORLD, "RU"},
{CTRY_RWANDA, APL1_WORLD, "RW"},
{CTRY_SAUDI_ARABIA, NULL1_WORLD, "SA"},
-- 
2.11.0

[PATCH 40/52] ath: Map Pakistan to APL1_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: NO_CTL -> FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 6824b1db6d16..1d49300451a8 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -454,7 +454,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_NICARAGUA, FCC3_FCCA, "NI"},
{CTRY_NORWAY, ETSI1_WORLD, "NO"},
{CTRY_OMAN, FCC3_WORLD, "OM"},
-   {CTRY_PAKISTAN, NULL1_WORLD, "PK"},
+   {CTRY_PAKISTAN, APL1_WORLD, "PK"},
{CTRY_PANAMA, FCC1_FCCA, "PA"},
{CTRY_PAPUA_NEW_GUINEA, FCC1_WORLD, "PG"},
{CTRY_PARAGUAY, FCC3_WORLD, "PY"},
-- 
2.11.0

[PATCH 30/52] ath: Map Honduras to FCC3_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: NO_CTL -> FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 29021bf28b89..cfa324592271 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -352,7 +352,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_GUAM, FCC1_FCCA, "GU"},
{CTRY_GUATEMALA, FCC1_FCCA, "GT"},
{CTRY_HAITI, ETSI1_WORLD, "HT"},
-   {CTRY_HONDURAS, NULL1_WORLD, "HN"},
+   {CTRY_HONDURAS, FCC3_WORLD, "HN"},
{CTRY_HONG_KONG, FCC3_WORLD, "HK"},
{CTRY_HUNGARY, ETSI1_WORLD, "HU"},
{CTRY_ICELAND, ETSI1_WORLD, "IS"},
-- 
2.11.0

[PATCH 29/52] ath: Map Czech to ETSI1_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

This change itself doesn't change the selected CTL of this country and is
only required to stay in sync with the QCA mappings.

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index c28347fac774..29021bf28b89 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -335,7 +335,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_COSTA_RICA, FCC1_WORLD, "CR"},
{CTRY_CROATIA, ETSI1_WORLD, "HR"},
{CTRY_CYPRUS, ETSI1_WORLD, "CY"},
-   {CTRY_CZECH, ETSI3_WORLD, "CZ"},
+   {CTRY_CZECH, ETSI1_WORLD, "CZ"},
{CTRY_DENMARK, ETSI1_WORLD, "DK"},
{CTRY_DOMINICAN_REPUBLIC, FCC1_FCCA, "DO"},
{CTRY_ECUADOR, FCC1_WORLD, "EC"},
-- 
2.11.0

[PATCH 37/52] ath: Map Malasia to FCC1_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: ETSI -> FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index f457c9d50bd2..efc363af5e41 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -440,7 +440,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_LUXEMBOURG, ETSI1_WORLD, "LU"},
{CTRY_MACAU, FCC2_WORLD, "MO"},
{CTRY_MACEDONIA, ETSI1_WORLD, "MK"},
-   {CTRY_MALAYSIA, APL8_WORLD, "MY"},
+   {CTRY_MALAYSIA, FCC1_WORLD, "MY"},
{CTRY_MALTA, ETSI1_WORLD, "MT"},
{CTRY_MAURITIUS, ETSI1_WORLD, "MU"},
{CTRY_MEXICO, FCC1_FCCA, "MX"},
-- 
2.11.0

[PATCH 33/52] ath: Map Japan to MKK5_MKKA2

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

This change itself doesn't change the selected CTL of this country and is
only required to stay in sync with the QCA mappings.

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 59145decdb2b..14cb25ab494d 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -364,7 +364,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_ITALY, ETSI1_WORLD, "IT"},
{CTRY_JAMAICA, FCC3_WORLD, "JM"},
 
-   {CTRY_JAPAN, MKK1_MKKA, "JP"},
+   {CTRY_JAPAN, MKK5_MKKA2, "JP"},
{CTRY_JAPAN1, MKK1_MKKB, "JP"},
{CTRY_JAPAN2, MKK1_FCCA, "JP"},
{CTRY_JAPAN3, MKK2_MKKA, "JP"},
-- 
2.11.0

[PATCH 34/52] ath: Map South Korea to APL10_MKKC

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

This change itself doesn't change the selected CTL of this country and is
only required to stay in sync with the QCA mappings.

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 14cb25ab494d..dee9db074d84 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -429,7 +429,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_KAZAKHSTAN, NULL1_WORLD, "KZ"},
{CTRY_KENYA, APL1_WORLD, "KE"},
{CTRY_KOREA_NORTH, APL9_MKKC, "KP"},
-   {CTRY_KOREA_ROC, APL9_MKKC, "KR"},
+   {CTRY_KOREA_ROC, APL10_MKKC, "KR"},
{CTRY_KOREA_ROC2, APL2_WORLD, "K2"},
{CTRY_KOREA_ROC3, APL9_MKKC, "K3"},
{CTRY_KUWAIT, ETSI3_WORLD, "KW"},
-- 
2.11.0

[PATCH 32/52] ath: Map Isreal to ETSI3_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: NO_CTL -> ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 6a325213c163..59145decdb2b 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -360,7 +360,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_INDONESIA, APL2_WORLD, "ID"},
{CTRY_IRAN, APL1_WORLD, "IR"},
{CTRY_IRELAND, ETSI1_WORLD, "IE"},
-   {CTRY_ISRAEL, NULL1_WORLD, "IL"},
+   {CTRY_ISRAEL, ETSI3_WORLD, "IL"},
{CTRY_ITALY, ETSI1_WORLD, "IT"},
{CTRY_JAMAICA, FCC3_WORLD, "JM"},
 
-- 
2.11.0

[PATCH 31/52] ath: Map Indonesia to APL2_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: NO_CTL -> FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index cfa324592271..6a325213c163 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -357,7 +357,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_HUNGARY, ETSI1_WORLD, "HU"},
{CTRY_ICELAND, ETSI1_WORLD, "IS"},
{CTRY_INDIA, APL6_WORLD, "IN"},
-   {CTRY_INDONESIA, NULL1_WORLD, "ID"},
+   {CTRY_INDONESIA, APL2_WORLD, "ID"},
{CTRY_IRAN, APL1_WORLD, "IR"},
{CTRY_IRELAND, ETSI1_WORLD, "IE"},
{CTRY_ISRAEL, NULL1_WORLD, "IL"},
-- 
2.11.0

[PATCH 21/52] ath: Switch APL9_WORLD to 2.4GHz MKK CTL

[Sven Eckelmann]

The regdomain code 0x5E was switched from ETSI conformance test limits
(CTL) on 2.4GHz to MKK. This only affects the different South Korea country
codes.

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 447547c25093..c2074b1cd207 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -75,7 +75,7 @@ enum EnumRd {
APL6_WORLD = 0x5B,
APL7_FCCA = 0x5C,
APL8_WORLD = 0x5D,
-   APL9_WORLD = 0x5E,
+   APL9_MKKC = 0x5E,
APL10_MKKC = 0x5F,
 
WOR0_WORLD = 0x60,
@@ -205,7 +205,7 @@ static struct reg_dmn_pair_mapping regDomainPairs[] = {
{APL13_WORLD, CTL_ETSI, CTL_ETSI},
{APL6_WORLD, CTL_ETSI, CTL_ETSI},
{APL8_WORLD, CTL_ETSI, CTL_ETSI},
-   {APL9_WORLD, CTL_ETSI, CTL_ETSI},
+   {APL9_MKKC, CTL_ETSI, CTL_MKK},
 
{APL10_MKKC, CTL_ETSI, CTL_MKK},
{APL3_FCCA, CTL_FCC, CTL_FCC},
@@ -428,10 +428,10 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_JORDAN, ETSI2_WORLD, "JO"},
{CTRY_KAZAKHSTAN, NULL1_WORLD, "KZ"},
{CTRY_KENYA, APL1_WORLD, "KE"},
-   {CTRY_KOREA_NORTH, APL9_WORLD, "KP"},
-   {CTRY_KOREA_ROC, APL9_WORLD, "KR"},
+   {CTRY_KOREA_NORTH, APL9_MKKC, "KP"},
+   {CTRY_KOREA_ROC, APL9_MKKC, "KR"},
{CTRY_KOREA_ROC2, APL2_WORLD, "K2"},
-   {CTRY_KOREA_ROC3, APL9_WORLD, "K3"},
+   {CTRY_KOREA_ROC3, APL9_MKKC, "K3"},
{CTRY_KUWAIT, ETSI3_WORLD, "KW"},
{CTRY_LATVIA, ETSI1_WORLD, "LV"},
{CTRY_LEBANON, NULL1_WORLD, "LB"},
-- 
2.11.0

[PATCH 27/52] ath: Map Bulgaria to ETSI1_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

This change itself doesn't change the selected CTL of this country and is
only required to stay in sync with the QCA mappings.

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 4edd4c1d99fa..3a7fbd3794bc 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -325,7 +325,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_BOSNIA_HERZ, ETSI1_WORLD, "BA"},
{CTRY_BRAZIL, FCC3_WORLD, "BR"},
{CTRY_BRUNEI_DARUSSALAM, APL6_WORLD, "BN"},
-   {CTRY_BULGARIA, ETSI6_WORLD, "BG"},
+   {CTRY_BULGARIA, ETSI1_WORLD, "BG"},
{CTRY_CAMBODIA, ETSI1_WORLD, "KH"},
{CTRY_CANADA, FCC3_FCCA, "CA"},
{CTRY_CANADA2, FCC6_FCCA, "CA"},
-- 
2.11.0

[PATCH 26/52] ath: Map Brunei Darussalam to APL6_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: FCC -> ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index a5d528367082..4edd4c1d99fa 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -324,7 +324,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_BOLIVIA, APL1_ETSIC, "BO"},
{CTRY_BOSNIA_HERZ, ETSI1_WORLD, "BA"},
{CTRY_BRAZIL, FCC3_WORLD, "BR"},
-   {CTRY_BRUNEI_DARUSSALAM, APL1_WORLD, "BN"},
+   {CTRY_BRUNEI_DARUSSALAM, APL6_WORLD, "BN"},
{CTRY_BULGARIA, ETSI6_WORLD, "BG"},
{CTRY_CAMBODIA, ETSI1_WORLD, "KH"},
{CTRY_CANADA, FCC3_FCCA, "CA"},
-- 
2.11.0

[PATCH 25/52] ath: Map Bangladesh to APL1_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: NO_CTL -> FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 173db6bd1280..a5d528367082 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -314,7 +314,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_AZERBAIJAN, ETSI4_WORLD, "AZ"},
{CTRY_BAHAMAS, FCC3_WORLD, "BS"},
{CTRY_BAHRAIN, APL6_WORLD, "BH"},
-   {CTRY_BANGLADESH, NULL1_WORLD, "BD"},
+   {CTRY_BANGLADESH, APL1_WORLD, "BD"},
{CTRY_BARBADOS, FCC2_WORLD, "BB"},
{CTRY_BELARUS, ETSI1_WORLD, "BY"},
{CTRY_BELGIUM, ETSI1_WORLD, "BE"},
-- 
2.11.0

[PATCH 28/52] ath: Map Colombia to FCC1_FCCA

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

This change itself doesn't change the selected CTL of this country and is
only required to stay in sync with the QCA mappings.

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 3a7fbd3794bc..c28347fac774 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -331,7 +331,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_CANADA2, FCC6_FCCA, "CA"},
{CTRY_CHILE, APL6_WORLD, "CL"},
{CTRY_CHINA, APL1_WORLD, "CN"},
-   {CTRY_COLOMBIA, FCC1_FCCA, "CO"},
+   {CTRY_COLOMBIA, FCC3_WORLD, "CO"},
{CTRY_COSTA_RICA, FCC1_WORLD, "CR"},
{CTRY_CROATIA, ETSI1_WORLD, "HR"},
{CTRY_CYPRUS, ETSI1_WORLD, "CY"},
-- 
2.11.0

[PATCH 24/52] ath: Map Australia to FCC3_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

This change itself doesn't change the selected CTL of this country and is
only required to stay in sync with the QCA mappings.

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 984039073aea..173db6bd1280 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -308,7 +308,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_ARGENTINA, FCC3_WORLD, "AR"},
{CTRY_ARMENIA, ETSI4_WORLD, "AM"},
{CTRY_ARUBA, ETSI1_WORLD, "AW"},
-   {CTRY_AUSTRALIA, FCC2_WORLD, "AU"},
+   {CTRY_AUSTRALIA, FCC3_WORLD, "AU"},
{CTRY_AUSTRALIA2, FCC6_WORLD, "AU"},
{CTRY_AUSTRIA, ETSI1_WORLD, "AT"},
{CTRY_AZERBAIJAN, ETSI4_WORLD, "AZ"},
-- 
2.11.0

[PATCH 22/52] ath: Map Albania to ETSI1_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: NO_CTL -> ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index c2074b1cd207..bdfbdd4e8583 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -303,7 +303,7 @@ static struct reg_dmn_pair_mapping regDomainPairs[] = {
 static struct country_code_to_enum_rd allCountries[] = {
{CTRY_DEBUG, NO_ENUMRD, "DB"},
{CTRY_DEFAULT, FCC1_FCCA, "CO"},
-   {CTRY_ALBANIA, NULL1_WORLD, "AL"},
+   {CTRY_ALBANIA, ETSI1_WORLD, "AL"},
{CTRY_ALGERIA, NULL1_WORLD, "DZ"},
{CTRY_ARGENTINA, FCC3_WORLD, "AR"},
{CTRY_ARMENIA, ETSI4_WORLD, "AM"},
-- 
2.11.0

[PATCH 23/52] ath: Map Algeria to APL13_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't correctly
mapped to the actual CTL entries in EEPROM then it could happen that the
device violates the regulations. But it can also happen that the device is
then not able to be used with its full txpower on all rates.

The CTL mappings for this regdomain code were now changed to:

* 2.4GHz: ETSI
* 5GHz: NO_CTL -> ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index bdfbdd4e8583..984039073aea 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -304,7 +304,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_DEBUG, NO_ENUMRD, "DB"},
{CTRY_DEFAULT, FCC1_FCCA, "CO"},
{CTRY_ALBANIA, ETSI1_WORLD, "AL"},
-   {CTRY_ALGERIA, NULL1_WORLD, "DZ"},
+   {CTRY_ALGERIA, APL13_WORLD, "DZ"},
{CTRY_ARGENTINA, FCC3_WORLD, "AR"},
{CTRY_ARMENIA, ETSI4_WORLD, "AM"},
{CTRY_ARUBA, ETSI1_WORLD, "AW"},
-- 
2.11.0

[PATCH 20/52] ath: Add regulatory mapping for FCC3_ETSIC

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't available and
it is still programmed in the EEPROM then it will cause an error and stop
the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this regdomain code are:

* 2.4GHz: ETSI
* 5GHz: FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index f1735ac67c52..447547c25093 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -35,6 +35,7 @@ enum EnumRd {
FRANCE_RES = 0x31,
FCC3_FCCA = 0x3A,
FCC3_WORLD = 0x3B,
+   FCC3_ETSIC = 0x3F,
 
ETSI1_WORLD = 0x37,
ETSI3_ETSIA = 0x32,
@@ -174,6 +175,7 @@ static struct reg_dmn_pair_mapping regDomainPairs[] = {
{FCC2_ETSIC, CTL_FCC, CTL_ETSI},
{FCC3_FCCA, CTL_FCC, CTL_FCC},
{FCC3_WORLD, CTL_FCC, CTL_ETSI},
+   {FCC3_ETSIC, CTL_FCC, CTL_ETSI},
{FCC4_FCCA, CTL_FCC, CTL_FCC},
{FCC5_FCCA, CTL_FCC, CTL_FCC},
{FCC6_FCCA, CTL_FCC, CTL_FCC},
-- 
2.11.0

[PATCH 16/52] ath: Add regulatory mapping for APL10_MKKC

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't available and
it is still programmed in the EEPROM then it will cause an error and stop
the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this regdomain code are:

* 2.4GHz: MKK
* 5GHz: ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 07c966ad7a67..44e3831c13b1 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -72,6 +72,7 @@ enum EnumRd {
APL7_FCCA = 0x5C,
APL8_WORLD = 0x5D,
APL9_WORLD = 0x5E,
+   APL10_MKKC = 0x5F,
 
WOR0_WORLD = 0x60,
WOR1_WORLD = 0x61,
@@ -198,6 +199,7 @@ static struct reg_dmn_pair_mapping regDomainPairs[] = {
{APL8_WORLD, CTL_ETSI, CTL_ETSI},
{APL9_WORLD, CTL_ETSI, CTL_ETSI},
 
+   {APL10_MKKC, CTL_ETSI, CTL_MKK},
{APL3_FCCA, CTL_FCC, CTL_FCC},
{APL7_FCCA, CTL_FCC, CTL_FCC},
{APL1_ETSIC, CTL_FCC, CTL_ETSI},
-- 
2.11.0

[PATCH 15/52] ath: Add regulatory mapping for APL2_FCCA

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't available and
it is still programmed in the EEPROM then it will cause an error and stop
the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this regdomain code are:

* 2.4GHz: FCC
* 5GHz: FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 5cbd76235248..07c966ad7a67 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -59,6 +59,7 @@ enum EnumRd {
MKK1_MKKA1 = 0x4A,
MKK1_MKKA2 = 0x4B,
MKK1_MKKC = 0x4C,
+   APL2_FCCA = 0x4D,
 
APL3_FCCA = 0x50,
APL1_WORLD = 0x52,
@@ -189,6 +190,7 @@ static struct reg_dmn_pair_mapping regDomainPairs[] = {
{FCC1_FCCA, CTL_FCC, CTL_FCC},
{APL1_WORLD, CTL_FCC, CTL_ETSI},
{APL2_WORLD, CTL_FCC, CTL_ETSI},
+   {APL2_FCCA, CTL_FCC, CTL_FCC},
{APL3_WORLD, CTL_FCC, CTL_ETSI},
{APL4_WORLD, CTL_FCC, CTL_ETSI},
{APL5_WORLD, CTL_FCC, CTL_ETSI},
-- 
2.11.0

[PATCH 14/52] ath: Add regulatory mapping for United States for AP

[Sven Eckelmann]

The country code is used by the ath to detect the ISO 3166-1 alpha-2 name
and to select the correct conformance test limits (CTL) for a country. If
the country isn't available and it is still programmed in the EEPROM then
it will cause an error and stop the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this country are:

* 2.4GHz: FCC
* 5GHz: FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd.h| 1 +
 drivers/net/wireless/ath/regd_common.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index 908163948d59..490efdcddf93 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -186,6 +186,7 @@ enum CountryCode {
CTRY_UKRAINE = 804,
CTRY_UNITED_KINGDOM = 826,
CTRY_UNITED_STATES = 840,
+   CTRY_UNITED_STATES2 = 841,
CTRY_UNITED_STATES_FCC49 = 842,
CTRY_URUGUAY = 858,
CTRY_UZBEKISTAN = 860,
diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index a00be9604d21..5cbd76235248 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -478,6 +478,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_UAE, NULL1_WORLD, "AE"},
{CTRY_UNITED_KINGDOM, ETSI1_WORLD, "GB"},
{CTRY_UNITED_STATES, FCC3_FCCA, "US"},
+   {CTRY_UNITED_STATES2, FCC6_FCCA, "US"},
/* This "PS" is for US public safety actually... to support this we
 * would need to assign new special alpha2 to CRDA db as with the world
 * regdomain and use another alpha2 */
-- 
2.11.0

[PATCH 17/52] ath: Add regulatory mapping for APL13_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't available and
it is still programmed in the EEPROM then it will cause an error and stop
the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this regdomain code are:

* 2.4GHz: ETSI
* 5GHz: ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 44e3831c13b1..14332b84443b 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -68,6 +68,7 @@ enum EnumRd {
APL1_ETSIC = 0x55,
APL2_ETSIC = 0x56,
APL5_WORLD = 0x58,
+   APL13_WORLD = 0x5A,
APL6_WORLD = 0x5B,
APL7_FCCA = 0x5C,
APL8_WORLD = 0x5D,
@@ -195,6 +196,7 @@ static struct reg_dmn_pair_mapping regDomainPairs[] = {
{APL3_WORLD, CTL_FCC, CTL_ETSI},
{APL4_WORLD, CTL_FCC, CTL_ETSI},
{APL5_WORLD, CTL_FCC, CTL_ETSI},
+   {APL13_WORLD, CTL_ETSI, CTL_ETSI},
{APL6_WORLD, CTL_ETSI, CTL_ETSI},
{APL8_WORLD, CTL_ETSI, CTL_ETSI},
{APL9_WORLD, CTL_ETSI, CTL_ETSI},
-- 
2.11.0

[PATCH 18/52] ath: Add regulatory mapping for ETSI8_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't available and
it is still programmed in the EEPROM then it will cause an error and stop
the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this regdomain code are:

* 2.4GHz: ETSI
* 5GHz: ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 14332b84443b..88913c67fed2 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -44,6 +44,7 @@ enum EnumRd {
ETSI4_ETSIC = 0x38,
ETSI5_WORLD = 0x39,
ETSI6_WORLD = 0x34,
+   ETSI8_WORLD = 0x3D,
ETSI_RESERVED = 0x33,
 
MKK1_MKKA = 0x40,
@@ -183,6 +184,7 @@ static struct reg_dmn_pair_mapping regDomainPairs[] = {
{ETSI4_WORLD, CTL_ETSI, CTL_ETSI},
{ETSI5_WORLD, CTL_ETSI, CTL_ETSI},
{ETSI6_WORLD, CTL_ETSI, CTL_ETSI},
+   {ETSI8_WORLD, CTL_ETSI, CTL_ETSI},
 
/* XXX: For ETSI3_ETSIA, Was NO_CTL meant for the 2 GHz band ? */
{ETSI3_ETSIA, CTL_ETSI, CTL_ETSI},
-- 
2.11.0

[PATCH 19/52] ath: Add regulatory mapping for ETSI9_WORLD

[Sven Eckelmann]

The regdomain code is used to select the correct the correct conformance
test limits (CTL) for a country. If the regdomain code isn't available and
it is still programmed in the EEPROM then it will cause an error and stop
the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this regdomain code are:

* 2.4GHz: ETSI
* 5GHz: ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 88913c67fed2..f1735ac67c52 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -45,6 +45,7 @@ enum EnumRd {
ETSI5_WORLD = 0x39,
ETSI6_WORLD = 0x34,
ETSI8_WORLD = 0x3D,
+   ETSI9_WORLD = 0x3E,
ETSI_RESERVED = 0x33,
 
MKK1_MKKA = 0x40,
@@ -185,6 +186,7 @@ static struct reg_dmn_pair_mapping regDomainPairs[] = {
{ETSI5_WORLD, CTL_ETSI, CTL_ETSI},
{ETSI6_WORLD, CTL_ETSI, CTL_ETSI},
{ETSI8_WORLD, CTL_ETSI, CTL_ETSI},
+   {ETSI9_WORLD, CTL_ETSI, CTL_ETSI},
 
/* XXX: For ETSI3_ETSIA, Was NO_CTL meant for the 2 GHz band ? */
{ETSI3_ETSIA, CTL_ETSI, CTL_ETSI},
-- 
2.11.0

[PATCH 12/52] ath: Add regulatory mapping for Tanzania

[Sven Eckelmann]

The country code is used by the ath to detect the ISO 3166-1 alpha-2 name
and to select the correct conformance test limits (CTL) for a country. If
the country isn't available and it is still programmed in the EEPROM then
it will cause an error and stop the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this country are:

* 2.4GHz: ETSI
* 5GHz: FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd.h| 1 +
 drivers/net/wireless/ath/regd_common.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index 9fe4857baaae..191502ff043d 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -176,6 +176,7 @@ enum CountryCode {
CTRY_SWITZERLAND = 756,
CTRY_SYRIA = 760,
CTRY_TAIWAN = 158,
+   CTRY_TANZANIA = 834,
CTRY_THAILAND = 764,
CTRY_TRINIDAD_Y_TOBAGO = 780,
CTRY_TUNISIA = 788,
diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 4c41308e39c1..27b1c76e912c 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -468,6 +468,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_SWITZERLAND, ETSI1_WORLD, "CH"},
{CTRY_SYRIA, NULL1_WORLD, "SY"},
{CTRY_TAIWAN, APL3_FCCA, "TW"},
+   {CTRY_TANZANIA, APL1_WORLD, "TZ"},
{CTRY_THAILAND, FCC3_WORLD, "TH"},
{CTRY_TRINIDAD_Y_TOBAGO, FCC3_WORLD, "TT"},
{CTRY_TUNISIA, ETSI3_WORLD, "TN"},
-- 
2.11.0

[PATCH 11/52] ath: Add regulatory mapping for Serbia

[Sven Eckelmann]

The country code is used by the ath to detect the ISO 3166-1 alpha-2 name
and to select the correct conformance test limits (CTL) for a country. If
the country isn't available and it is still programmed in the EEPROM then
it will cause an error and stop the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this country are:

* 2.4GHz: ETSI
* 5GHz: ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd.h| 1 +
 drivers/net/wireless/ath/regd_common.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index 3021ba5d7ef5..9fe4857baaae 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -164,6 +164,7 @@ enum CountryCode {
CTRY_RUSSIA = 643,
CTRY_RWANDA = 646,
CTRY_SAUDI_ARABIA = 682,
+   CTRY_SERBIA = 688,
CTRY_SERBIA_MONTENEGRO = 891,
CTRY_SINGAPORE = 702,
CTRY_SLOVAKIA = 703,
diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 89a3a9104428..4c41308e39c1 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -456,6 +456,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_RUSSIA, NULL1_WORLD, "RU"},
{CTRY_RWANDA, APL1_WORLD, "RW"},
{CTRY_SAUDI_ARABIA, NULL1_WORLD, "SA"},
+   {CTRY_SERBIA, ETSI1_WORLD, "RS"},
{CTRY_SERBIA_MONTENEGRO, ETSI1_WORLD, "CS"},
{CTRY_SINGAPORE, APL6_WORLD, "SG"},
{CTRY_SLOVAKIA, ETSI1_WORLD, "SK"},
-- 
2.11.0

[PATCH 13/52] ath: Add regulatory mapping for Uganda

[Sven Eckelmann]

The country code is used by the ath to detect the ISO 3166-1 alpha-2 name
and to select the correct conformance test limits (CTL) for a country. If
the country isn't available and it is still programmed in the EEPROM then
it will cause an error and stop the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this country are:

* 2.4GHz: ETSI
* 5GHz: FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd.h| 1 +
 drivers/net/wireless/ath/regd_common.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index 191502ff043d..908163948d59 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -182,6 +182,7 @@ enum CountryCode {
CTRY_TUNISIA = 788,
CTRY_TURKEY = 792,
CTRY_UAE = 784,
+   CTRY_UGANDA = 800,
CTRY_UKRAINE = 804,
CTRY_UNITED_KINGDOM = 826,
CTRY_UNITED_STATES = 840,
diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 27b1c76e912c..a00be9604d21 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -473,6 +473,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_TRINIDAD_Y_TOBAGO, FCC3_WORLD, "TT"},
{CTRY_TUNISIA, ETSI3_WORLD, "TN"},
{CTRY_TURKEY, ETSI3_WORLD, "TR"},
+   {CTRY_UGANDA, FCC3_WORLD, "UG"},
{CTRY_UKRAINE, NULL1_WORLD, "UA"},
{CTRY_UAE, NULL1_WORLD, "AE"},
{CTRY_UNITED_KINGDOM, ETSI1_WORLD, "GB"},
-- 
2.11.0

[PATCH 05/52] ath: Add regulatory mapping for Kenya

[Sven Eckelmann]

The country code is used by the ath to detect the ISO 3166-1 alpha-2 name
and to select the correct conformance test limits (CTL) for a country. If
the country isn't available and it is still programmed in the EEPROM then
it will cause an error and stop the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this country are:

* 2.4GHz: ETSI
* 5GHz: FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index e430e12f90e8..bdc1ff191264 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -415,6 +415,7 @@ static struct country_code_to_enum_rd allCountries[] = {
 
{CTRY_JORDAN, ETSI2_WORLD, "JO"},
{CTRY_KAZAKHSTAN, NULL1_WORLD, "KZ"},
+   {CTRY_KENYA, APL1_WORLD, "KE"},
{CTRY_KOREA_NORTH, APL9_WORLD, "KP"},
{CTRY_KOREA_ROC, APL9_WORLD, "KR"},
{CTRY_KOREA_ROC2, APL2_WORLD, "K2"},
-- 
2.11.0

[PATCH 03/52] ath: Add regulatory mapping for Japan (J56)

[Sven Eckelmann]

The country code is used by the ath to detect the ISO 3166-1 alpha-2 name
and to select the correct conformance test limits (CTL) for a country. If
the country isn't available and it is still programmed in the EEPROM then
it will cause an error and stop the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this country are:

* 2.4GHz: FCC
* 5GHz: MKK

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index a8c7f306fd7b..bba2d156cb21 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -99,6 +99,7 @@ enum EnumRd {
MKK5_MKKB = 0x86,
MKK5_MKKA2 = 0x87,
MKK5_MKKC = 0x88,
+   MKK5_FCCA = 0x9A,
 
MKK6_MKKB = 0x89,
MKK6_MKKA2 = 0x8A,
@@ -226,6 +227,7 @@ static struct reg_dmn_pair_mapping regDomainPairs[] = {
{MKK5_MKKB, CTL_MKK, CTL_MKK},
{MKK5_MKKA2, CTL_MKK, CTL_MKK},
{MKK5_MKKC, CTL_MKK, CTL_MKK},
+   {MKK5_FCCA, CTL_MKK, CTL_FCC},
 
{MKK6_MKKB, CTL_MKK, CTL_MKK},
{MKK6_MKKA1, CTL_MKK, CTL_MKK},
@@ -405,6 +407,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_JAPAN52, MKK12_MKKA1, "JP"},
{CTRY_JAPAN53, MKK12_MKKC, "JP"},
{CTRY_JAPAN54, MKK12_MKKA2, "JP"},
+   {CTRY_JAPAN56, MKK5_FCCA, "JP"},
{CTRY_JAPAN57, MKK13_MKKB, "JP"},
{CTRY_JAPAN58, MKK14_MKKA1, "JP"},
{CTRY_JAPAN59, MKK15_MKKA1, "JP"},
-- 
2.11.0

[PATCH 10/52] ath: Add regulatory mapping for Rwanda

[Sven Eckelmann]

The country code is used by the ath to detect the ISO 3166-1 alpha-2 name
and to select the correct conformance test limits (CTL) for a country. If
the country isn't available and it is still programmed in the EEPROM then
it will cause an error and stop the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this country are:

* 2.4GHz: ETSI
* 5GHz: FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd.h| 1 +
 drivers/net/wireless/ath/regd_common.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index 8575718425b6..3021ba5d7ef5 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -162,6 +162,7 @@ enum CountryCode {
CTRY_QATAR = 634,
CTRY_ROMANIA = 642,
CTRY_RUSSIA = 643,
+   CTRY_RWANDA = 646,
CTRY_SAUDI_ARABIA = 682,
CTRY_SERBIA_MONTENEGRO = 891,
CTRY_SINGAPORE = 702,
diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 679c6bc9035e..89a3a9104428 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -454,6 +454,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_QATAR, APL1_WORLD, "QA"},
{CTRY_ROMANIA, NULL1_WORLD, "RO"},
{CTRY_RUSSIA, NULL1_WORLD, "RU"},
+   {CTRY_RWANDA, APL1_WORLD, "RW"},
{CTRY_SAUDI_ARABIA, NULL1_WORLD, "SA"},
{CTRY_SERBIA_MONTENEGRO, ETSI1_WORLD, "CS"},
{CTRY_SINGAPORE, APL6_WORLD, "SG"},
-- 
2.11.0

[PATCH 08/52] ath: Add regulatory mapping for Nicaragua

[Sven Eckelmann]

The country code is used by the ath to detect the ISO 3166-1 alpha-2 name
and to select the correct conformance test limits (CTL) for a country. If
the country isn't available and it is still programmed in the EEPROM then
it will cause an error and stop the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this country are:

* 2.4GHz: FCC
* 5GHz: FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index df5db47f2930..11132f4a0aad 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -439,6 +439,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_NETHERLANDS, ETSI1_WORLD, "NL"},
{CTRY_NETHERLANDS_ANTILLES, ETSI1_WORLD, "AN"},
{CTRY_NEW_ZEALAND, FCC2_ETSIC, "NZ"},
+   {CTRY_NICARAGUA, FCC3_FCCA, "NI"},
{CTRY_NORWAY, ETSI1_WORLD, "NO"},
{CTRY_OMAN, FCC3_WORLD, "OM"},
{CTRY_PAKISTAN, NULL1_WORLD, "PK"},
-- 
2.11.0

[PATCH 07/52] ath: Add regulatory mapping for Montenegro

[Sven Eckelmann]

The country code is used by the ath to detect the ISO 3166-1 alpha-2 name
and to select the correct conformance test limits (CTL) for a country. If
the country isn't available and it is still programmed in the EEPROM then
it will cause an error and stop the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this country are:

* 2.4GHz: ETSI
* 5GHz: ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd.h| 1 +
 drivers/net/wireless/ath/regd_common.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index f38e42703060..8575718425b6 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -141,6 +141,7 @@ enum CountryCode {
CTRY_MAURITIUS = 480,
CTRY_MEXICO = 484,
CTRY_MONACO = 492,
+   CTRY_MONTENEGRO = 499,
CTRY_MOROCCO = 504,
CTRY_NEPAL = 524,
CTRY_NETHERLANDS = 528,
diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 375f9da6955b..df5db47f2930 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -433,6 +433,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_MAURITIUS, ETSI1_WORLD, "MU"},
{CTRY_MEXICO, FCC1_FCCA, "MX"},
{CTRY_MONACO, ETSI4_WORLD, "MC"},
+   {CTRY_MONTENEGRO, ETSI1_WORLD, "ME"},
{CTRY_MOROCCO, APL4_WORLD, "MA"},
{CTRY_NEPAL, APL1_WORLD, "NP"},
{CTRY_NETHERLANDS, ETSI1_WORLD, "NL"},
-- 
2.11.0

[PATCH 06/52] ath: Add regulatory mapping for Mauritius

[Sven Eckelmann]

The country code is used by the ath to detect the ISO 3166-1 alpha-2 name
and to select the correct conformance test limits (CTL) for a country. If
the country isn't available and it is still programmed in the EEPROM then
it will cause an error and stop the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this country are:

* 2.4GHz: ETSI
* 5GHz: ETSI

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd.h| 1 +
 drivers/net/wireless/ath/regd_common.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index a615a878ac40..f38e42703060 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -138,6 +138,7 @@ enum CountryCode {
CTRY_MACEDONIA = 807,
CTRY_MALAYSIA = 458,
CTRY_MALTA = 470,
+   CTRY_MAURITIUS = 480,
CTRY_MEXICO = 484,
CTRY_MONACO = 492,
CTRY_MOROCCO = 504,
diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index bdc1ff191264..375f9da6955b 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -430,6 +430,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_MACEDONIA, NULL1_WORLD, "MK"},
{CTRY_MALAYSIA, APL8_WORLD, "MY"},
{CTRY_MALTA, ETSI1_WORLD, "MT"},
+   {CTRY_MAURITIUS, ETSI1_WORLD, "MU"},
{CTRY_MEXICO, FCC1_FCCA, "MX"},
{CTRY_MONACO, ETSI4_WORLD, "MC"},
{CTRY_MOROCCO, APL4_WORLD, "MA"},
-- 
2.11.0

[PATCH 04/52] ath: Add regulatory mapping for Japan KDDI

[Sven Eckelmann]

The country code is used by the ath to detect the ISO 3166-1 alpha-2 name
and to select the correct conformance test limits (CTL) for a country. If
the country isn't available and it is still programmed in the EEPROM then
it will cause an error and stop the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this country are:

* 2.4GHz: MKK
* 5GHz: MKK

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd.h| 1 +
 drivers/net/wireless/ath/regd_common.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index e7b43901d195..a615a878ac40 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -246,6 +246,7 @@ enum CountryCode {
CTRY_JAPAN57 = 4057,
CTRY_JAPAN58 = 4058,
CTRY_JAPAN59 = 4059,
+   CTRY_XA = 4100,
CTRY_AUSTRALIA2 = 5000,
CTRY_CANADA2 = 5001,
CTRY_BELGIUM2 = 5002
diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index bba2d156cb21..e430e12f90e8 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -411,6 +411,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_JAPAN57, MKK13_MKKB, "JP"},
{CTRY_JAPAN58, MKK14_MKKA1, "JP"},
{CTRY_JAPAN59, MKK15_MKKA1, "JP"},
+   {CTRY_XA, MKK5_MKKA2, "XA"},
 
{CTRY_JORDAN, ETSI2_WORLD, "JO"},
{CTRY_KAZAKHSTAN, NULL1_WORLD, "KZ"},
-- 
2.11.0

[PATCH 09/52] ath: Add regulatory mapping for Paraguya

[Sven Eckelmann]

The country code is used by the ath to detect the ISO 3166-1 alpha-2 name
and to select the correct conformance test limits (CTL) for a country. If
the country isn't available and it is still programmed in the EEPROM then
it will cause an error and stop the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this country are:

* 2.4GHz: ETSI
* 5GHz: FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd_common.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index 11132f4a0aad..679c6bc9035e 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -445,6 +445,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_PAKISTAN, NULL1_WORLD, "PK"},
{CTRY_PANAMA, FCC1_FCCA, "PA"},
{CTRY_PAPUA_NEW_GUINEA, FCC1_WORLD, "PG"},
+   {CTRY_PARAGUAY, FCC3_WORLD, "PY"},
{CTRY_PERU, APL1_WORLD, "PE"},
{CTRY_PHILIPPINES, APL1_WORLD, "PH"},
{CTRY_POLAND, ETSI1_WORLD, "PL"},
-- 
2.11.0

[PATCH 02/52] ath: Add regulatory mapping for Bermuda

[Sven Eckelmann]

The country code is used by the ath to detect the ISO 3166-1 alpha-2 name
and to select the correct conformance test limits (CTL) for a country. If
the country isn't available and it is still programmed in the EEPROM then
it will cause an error and stop the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this country are:

* 2.4GHz: FCC
* 5GHz: FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd.h| 1 +
 drivers/net/wireless/ath/regd_common.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index f296ff838d2a..e7b43901d195 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -75,6 +75,7 @@ enum CountryCode {
CTRY_BELARUS = 112,
CTRY_BELGIUM = 56,
CTRY_BELIZE = 84,
+   CTRY_BERMUDA = 60,
CTRY_BOLIVIA = 68,
CTRY_BOSNIA_HERZ = 70,
CTRY_BRAZIL = 76,
diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index cde0268cbed6..a8c7f306fd7b 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -306,6 +306,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_BELGIUM, ETSI1_WORLD, "BE"},
{CTRY_BELGIUM2, ETSI4_WORLD, "BL"},
{CTRY_BELIZE, APL1_ETSIC, "BZ"},
+   {CTRY_BERMUDA, FCC3_FCCA, "BM"},
{CTRY_BOLIVIA, APL1_ETSIC, "BO"},
{CTRY_BOSNIA_HERZ, ETSI1_WORLD, "BA"},
{CTRY_BRAZIL, FCC3_WORLD, "BR"},
-- 
2.11.0

[PATCH 01/52] ath: Add regulatory mapping for Bahamas

[Sven Eckelmann]

The country code is used by the ath to detect the ISO 3166-1 alpha-2 name
and to select the correct conformance test limits (CTL) for a country. If
the country isn't available and it is still programmed in the EEPROM then
it will cause an error and stop the initialization with:

  Invalid EEPROM contents

The current CTL mappings for this country are:

* 2.4GHz: ETSI
* 5GHz: FCC

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/regd.h| 1 +
 drivers/net/wireless/ath/regd_common.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index 5d80be213fac..f296ff838d2a 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -68,6 +68,7 @@ enum CountryCode {
CTRY_AUSTRALIA = 36,
CTRY_AUSTRIA = 40,
CTRY_AZERBAIJAN = 31,
+   CTRY_BAHAMAS = 44,
CTRY_BAHRAIN = 48,
CTRY_BANGLADESH = 50,
CTRY_BARBADOS = 52,
diff --git a/drivers/net/wireless/ath/regd_common.h 
b/drivers/net/wireless/ath/regd_common.h
index bdd2b4d61f2f..cde0268cbed6 100644
--- a/drivers/net/wireless/ath/regd_common.h
+++ b/drivers/net/wireless/ath/regd_common.h
@@ -298,6 +298,7 @@ static struct country_code_to_enum_rd allCountries[] = {
{CTRY_AUSTRALIA2, FCC6_WORLD, "AU"},
{CTRY_AUSTRIA, ETSI1_WORLD, "AT"},
{CTRY_AZERBAIJAN, ETSI4_WORLD, "AZ"},
+   {CTRY_BAHAMAS, FCC3_WORLD, "BS"},
{CTRY_BAHRAIN, APL6_WORLD, "BH"},
{CTRY_BANGLADESH, NULL1_WORLD, "BD"},
{CTRY_BARBADOS, FCC2_WORLD, "BB"},
-- 
2.11.0

[PATCH 00/52] ath: Synchronize regd mappings with qcacld-2.0 4.0.11.181

[Sven Eckelmann]

The mappings from ath was not synced with the QCA driver since 2009. Only
two minor fixes were integrated in 2011. Since then, a lot of regd changes
were integrated in the close source QCA driver which are now used but not
supported by the Open Source driver. This either prevents the use of the
OSS driver on such devices or the wrong conformance test limits (CTLs) may
be used.

To get the integrated we would first get access to the closed source QCA
driver and a special OSS-NDA with QCA. This doesn't seem to be possible at
the moment and thus other sources for the changes have to be found. One of
them is the qcacld-2.0 source repository [1] which contains the QCA
regdomain.h and regdomain_common.h which was relicensed by QCA as ISC. It
isn't the newest version from the QCA driver but at least received some
updates which are not present in ath's regd.

This repository [1] (commit 48f9ab5d5c161549be098997fa0e3602c1547213 to be
more precise) was now used to find differences and ad some missing
mappings.

The title of the mappings describe what exactly was changed. The "Add
regulatory mapping for" patches introduce new country codes/mappings and
thus don't change old mappings. The "Add regulatory mapping for" patches
are similar but for regulatory code mappings instead of country code
mappings.

More interesting might be the "Map  to " patches because they
modify already existing mappings. The result are following changes to the
selected CTLs:

* CTRY_ALBANIA: 5GHz: NO_CTL -> ETSI
* CTRY_ALGERIA: 5GHz: NO_CTL -> ETSI
* CTRY_BANGLADESH:  5GHz: NO_CTL -> FCC
* CTRY_BRUNEI_DARUSSALAM:   5GHz: FCC -> ETSI
* CTRY_HONDURAS:5GHz: NO_CTL -> FCC
* CTRY_INDONESIA:   5GHz: NO_CTL -> FCC
* CTRY_ISRAEL:  5GHz: NO_CTL -> ETSI
* CTRY_KOREA_NORTH:   2.4GHz: ETSI -> MKK
* CTRY_KOREA_ROC: 2.4GHz: ETSI -> MKK
* CTRY_KOREA_ROC3:2.4GHz: ETSI -> MKK
* CTRY_LEBANON: 5GHz: NO_CTL -> FCC
* CTRY_MACEDONIA:   5GHz: NO_CTL -> ETSI
* CTRY_MALAYSIA:5GHz: ETSI -> FCC
* CTRY_MEXICO:2.4GHz: FCC-> ETSI
* CTRY_PAKISTAN:5GHz: NO_CTL -> FCC
* CTRY_ROMANIA: 5GHz: NO_CTL -> ETSI
* CTRY_RUSSIA:  5GHz: NO_CTL -> ETSI
* CTRY_SAUDI_ARABIA:5GHz: NO_CTL -> FCC
* CTRY_SINGAPORE:   5GHz: ETSI -> FCC
* CTRY_UKRAINE: 5GHz: NO_CTL -> ETSI
* CTRY_UAE: 5GHz: NO_CTL -> ETSI
* CTRY_VIET_NAM:5GHz: NO_CTL -> ETSI
* CTRY_ZIMBABWE:5GHz: NO_CTL -> ETSI


Btw. I have not removed CTRY_SERBIA_MONTENEGRO, CTRY_KOREA_ROC2 or
APL2_APLD because this might break devices which have these programmed in
the EEPROM. And I have not added APL11_FCCA, APL12_WORLD and CTRY_MALDIVES
because only the code was in the qcacld-2.0 source code but not the actual
mapping.

I am relative confident that QCA also has following extra countries:

* Afghanistan
* American Samoa
* Anguilla
* Bhutan
* Burkina Faso
* Cayman Islands
* Central Africa Republic
* Chad
* Christmas Islands
* Dominica
* Ethiopia
* French Guiana
* French Polynesia
* Ghana
* Guadeloupe
* Guyana
* Cote d'Ivoire
* Lesotho
* Malawi
* Maldives
* Marshall Islands
* Martinique
* Mauitania
* Mayotte
* Micronesia
* Moldova
* Mongolia
* Namibia
* Nigeria
* Northern Mariana Islands
* Palau
* Reunion
* St Barthelemy
* St Kitts Nevis
* St Lucia
* St Martin
* St Pierre Miquelon
* St Vincent Grenadiens
* Samoa
* Senegal
* Suriname
* Togo
* Turks Caicos
* Vanuatu
* Virgin Islands
* Wallis Futuna

+ a lot of extra regdomain codes (0x15, 0x16, 0x17, 0x18, 0x19, 0x3c, 0x4f,
0x51, 0x57, 0x59) and the corresponding mappings.

There might be even a lot more. But we will miss out on them unless QCA
somehow opensources their current:

* regdomain_common.h or at least:

  - enum EnumRd
  - ahCmnRegDomainPairs
  - ahCmnAllCountries
  - ahCmnRegDomains

* regdomain.h or at least:

  - enum CountryCode

Kind regards,
    Sven

[1] 
https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qcacld-2.0

Sven Eckelmann (52):
  ath: Add regulatory mapping for Bahamas
  ath: Add regulatory mapping for Bermuda
  ath: Add regulatory mapping for Japan (J56)
  ath: Add regulatory mapping for Japan KDDI
  ath: Add regulatory mapping for Kenya
  ath: Add regulatory mapping for Mauritius
  ath: Add regulatory mapping for Montenegro
  ath: Add regulatory mapping for Nicaragua
  ath: Add regulatory mapping for Paraguya
  ath: Add regulatory mapping for Rwanda
  ath: Add regulatory mapping for Serbia
  ath: Add regulatory mapping for Tanzania
  ath: Add regulatory mapping for Uganda
  ath: Add regulatory mapping for United States for AP
  ath: Add regulatory mapping for APL2_FCCA
  ath: Add regulatory mapping for APL10_MKKC
  ath: Add regulatory mapping for APL13_WORLD
  ath: Add regulatory mapping for ETSI8_WOR

Re: [PATCH v2 2/2] ath10k: fix CCK h/w rates for QCA99X0 and newer chipsets

[Sven Eckelmann]

On Donnerstag, 2. Juni 2016 12:53:55 CET Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan 
> 
> CCK hardware table mapping from QCA99X0 onwards got revised.
> The CCK hardware rate values are in a proper order wrt. to
> rate and preamble as below
> 
> ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
> ATH10K_HW_RATE_REV2_CCK_LP_2M = 2,
> ATH10K_HW_RATE_REV2_CCK_LP_5_5M = 3,
> ATH10K_HW_RATE_REV2_CCK_LP_11M = 4,
> ATH10K_HW_RATE_REV2_CCK_SP_2M = 5,
> ATH10K_HW_RATE_REV2_CCK_SP_5_5M = 6,
> ATH10K_HW_RATE_REV2_CCK_SP_11M = 7,
> 
> This results in reporting of rx frames (with CCK rates)
> totally wrong for QCA99X0, QCA4019. Fix this by having
> separate CCK rate table for these chipsets with rev2 suffix
> and registering the correct rate mapping to mac80211 based on
> the new hw_param (introduced) 'cck_rate_map_rev2' which shall
> be true for any newchipsets from QCA99X0 onwards

I just tested it here with QCA4019 + 10.4-3.2.1-00050 for beacons. The 
calculated HW code for 1.0 MBit/s would be 0x41 (rate_code) according to this 
new mapping. But when I set it with 

ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
ar->wmi.vdev_param->mcast_data_rate,
rate_code);

then it sends beacons with 5.5Mbit/s and not with 1.0Mbit/s.

Btw. the rate_code was calculated using:

if (ath10k_mac_bitrate_is_cck(sband->bitrates[i].bitrate))
preamble = WMI_RATE_PREAMBLE_CCK;
else
preamble = WMI_RATE_PREAMBLE_OFDM;

rate_code = ATH10K_HW_RATECODE(hw_value, 0, preamble);

It works fine when using the old mapping (0x43).

This made me rather curious and I've connected a client to the AP which was 
only able to send at 1.0 Mbit/s - this actually resulted in the correctly 
reported rates at in the rx field.

Does this mean that the rates are now inconsistent because the QCA fw doesn't 
provide a consistent interface for hw rates or did I miss anything?

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 1/1] ath10k: add LED and GPIO controlling support for various chipsets

[Sven Eckelmann]

On Donnerstag, 15. Februar 2018 15:31:04 CET Sebastian Gottschall wrote:
> Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 and 
> ipq4019 based chipsets with on chipset connected led's
> using WMI Firmware API.
> The LED device will get available named as "ath10k-phyX" at sysfs and 
> can be controlled with various triggers.
> adds also debugfs interface for gpio control.
> 
> Signed-off-by: Sebastian Gottschall 
> 
>   drivers/net/wireless/ath/ath10k/core.c| 168 
> +-
>   drivers/net/wireless/ath/ath10k/core.h|  15 +++
>   drivers/net/wireless/ath/ath10k/debug.c   | 140 +
>   drivers/net/wireless/ath/ath10k/hw.h  |   1 +
>   drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 ++-
>   drivers/net/wireless/ath/ath10k/wmi.c |  43 
>   drivers/net/wireless/ath/ath10k/wmi.h |  36 +++
>   7 files changed, 436 insertions(+), 3 deletions(-)

Looks like your mail program has eaten the patch [1]. It is also not clear why 
it was posted as reply to the "dt: bindings: add bindings for wcn3990 wifi 
block" patch. :)

Kind regards,
Sven

[1] https://www.kernel.org/doc/html/v4.15/process/email-clients.html


signature.asc
Description: This is a digitally signed message part.

Re: 802.11ac devices that use Minstrel_HT

[Sven Eckelmann]

On Dienstag, 13. Februar 2018 07:56:29 CET Ali Abedi wrote:
> > So I would currently bet on hwsim (only useful when you only want to have 
> > some
> > simulations) or mt76. Afaik mt76 was also the one which was used to test the
> > VHT rate injection code for monitor interfaces and is therefore quite
> > flexible.
[...]
> Thank you Sven. I was actually wondering what hardware was used to test 
> the code.

It seems Lorenzo Bianconi used an D-Link DIR-860L rev B1 [1]

Kind regards,
Sven

[1] https://patchwork.kernel.org/patch/8393091/


signature.asc
Description: This is a digitally signed message part.

Re: 802.11ac devices that use Minstrel_HT

[Sven Eckelmann]

On Montag, 12. Februar 2018 14:05:36 CET Ali Abedi wrote:
> Hello,
> 
> It seems that Minstrel_ht rate adaptation algorithm supports 802.11ac 
> VHT rates.
> Can you refer me to some 802.11ac devices that use this rate adaptation 
> algorithm?
> I need to modify the rate adaptation algorithm however all 802.11ac 
> devices that I know have moved this functionality to (closed) firmware.

Following files use IEEE80211_TX_RC_VHT_MCS in drivers/net/wireless:

* intel/iwlwifi/mvm/tx.c
* mac80211_hwsim.c
* mediatek/mt76/mt76x2_mac.c
* mediatek/mt76/mt76x2_tx.c
* realtek/rtlwifi/base.c
* realtek/rtlwifi/rc.c

Following files from the candidates are providing their own rate_control_ops:

* realtek/rtlwifi/
* intel/iwlwifi/mvm/rs.c
* intel/iwlwifi/dvm/rs.c

So I would currently bet on hwsim (only useful when you only want to have some 
simulations) or mt76. Afaik mt76 was also the one which was used to test the 
VHT rate injection code for monitor interfaces and is therefore quite 
flexible.

Kind regards,   
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [1/2] mt76: fix possible NULL pointer dereferencing in mt76x2_ampdu_action()

[Sven Eckelmann]

On Mittwoch, 17. Januar 2018 16:50:23 CET Kalle Valo wrote:
[...]
> >> I didn't see Felix's ack, at least not on patchwork.
> >
> > I sent my ack (for both patches) as a reply to 0/2
> 
> Ah. patchwork is annoying as it doesn't show the cover letter at all so
> I missed that.

Newer version at least can track the series and their cover letters. This is 
not completely what you want but at least there is hope. Here is an example: 
https://patchwork.open-mesh.org/cover/17240/ (you can use "Related" to see all 
the patches in the series).

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ath10k: Add BMI parameters to fix calibration from DT/pre-cal

[Sven Eckelmann]

On Montag, 11. Dezember 2017 18:50:09 CET ako...@codeaurora.org wrote:
[...]
> >> > Just tried this on an QCA9984 which doesn't seem to have the
> >> > calibration data in the PCI EEPROM.
> >> >
> >> > [   71.728929] ath10k_pci :01:00.0: qca9984/qca9994 hw1.0
> >> > target 0x0100 chip_id 0x sub 168c:cafe
> >> > [   71.732926] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1
> >> > tracing 0 dfs 1 testmode 1
> >> > [   71.752282] ath10k_pci :01:00.0: firmware ver
> >> > 10.4-ct-9984-fW-009-dfa0083 api 5 features peer-flow-ctrl crc32
> >> > 7198d117
> >> > [   73.805730] ath10k_pci :01:00.0: unable to read from the
> >> > device
> >> > [   73.805769] ath10k_pci :01:00.0: could not execute otp for
> >> > board id check: -110
[...]
> 
> I tested this on QCA9984 and it worked with below config,
[...]
> 
> Kindly try with the latest firmware from Kalle's git mentioned above.

This didn't change the behavior. It was actually the OTP timeout problem on 
the QCA9984 which Ben Greear fixed [1]. Luckily, LEDE added this patch with 
your patch [2]

Kind regards,
Sven

[1] 
https://git.lede-project.org/?p=source.git;a=blob;f=package/kernel/mac80211/patches/327-ath10k-increase-BMI-timeout.patch;h=c9f493bcd8fe29afe1e08dc31b6370507b95fc72;hb=025cb640cdf27f7c68fc1d89d0698605daa06c43
[2] 
https://git.lede-project.org/?p=source.git;a=commit;h=025cb640cdf27f7c68fc1d89d0698605daa06c43

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ath10k: Add BMI parameters to fix calibration from DT/pre-cal

[Sven Eckelmann]

On Freitag, 8. Dezember 2017 18:05:38 CET ako...@codeaurora.org wrote:
> On 2017-12-08 17:42, Sven Eckelmann wrote:
> > On Donnerstag, 25. Mai 2017 16:21:23 CET ako...@qti.qualcomm.com wrote:
> >> From: Anilkumar Kolli <ako...@qti.qualcomm.com>
> >> 
> >> QCA99X0, QCA9888, QCA9984 supports calibration data in
> >> either OTP or DT/pre-cal file. Current ath10k supports
> >> Calibration data from OTP only.
[...]
> > Just tried this on an QCA9984 which doesn't seem to have the
> > calibration data in the PCI EEPROM.
> > 
> > [   71.728929] ath10k_pci :01:00.0: qca9984/qca9994 hw1.0
> > target 0x0100 chip_id 0x sub 168c:cafe
> > [   71.732926] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1
> > tracing 0 dfs 1 testmode 1
> > [   71.752282] ath10k_pci :01:00.0: firmware ver
> > 10.4-ct-9984-fW-009-dfa0083 api 5 features peer-flow-ctrl crc32
> > 7198d117
> > [   73.805730] ath10k_pci :01:00.0: unable to read from the 
> > device
> > [   73.805769] ath10k_pci :01:00.0: could not execute otp for
> > board id check: -110
> > 
> 
> 'ATH10K driver <-> 10.4 firmware' expects cal data to be either in 
> EEPROM or pre-cal-file or DT.
> Hope the error is observed when there is no cal data loaded.

The problem happens when pre-cal data file is loaded using the userspace 
helper on the QCA9984. I was only able to use the device when I (for a test) 
used the pre-cal data as cal-data (file).

The EEPROM on the on the PCI device doesn't seem to be populated with a valid 
pre-cal data. I've already tested it with a QCA9984 device which had pre-cal 
data in the PCI device's EEPROM and this worked fine (without cal file and 
without pre-cal file).

> > It works when I use the pre-cal data as calibration data. The checksum 
> > in the
> > pre-cal seems to be correct. Also the pre-cal data from 0:ART for the 
> > 2.4GHz
> > and 5GHz QCA4019 seem to work perfectly fine.
> > 
> 
> Do you mean this patch works for only QCA4019 and not working for 
> QCA9984 ?

Worked fine for QCA4019 and QCA9888 - but I had no luck with QCA9984. The 
error shown above it the only thing I get.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ath10k: Add BMI parameters to fix calibration from DT/pre-cal

[Sven Eckelmann]

On Donnerstag, 25. Mai 2017 16:21:23 CET ako...@qti.qualcomm.com wrote:
> From: Anilkumar Kolli 
> 
> QCA99X0, QCA9888, QCA9984 supports calibration data in
> either OTP or DT/pre-cal file. Current ath10k supports
> Calibration data from OTP only.
> 
> If caldata is loaded from DT/pre-cal file, fetching board id
> and applying calibration parameters like tx power gets failed.
> 
> error log:
> [   15.733663] ath10k_pci :01:00.0: failed to fetch board file: -2
> [   15.741474] ath10k_pci :01:00.0: could not probe fw (-2)
> 
> This patch adds calibration data support from DT/pre-cal
> file.  Below parameters are used to get board id and
> applying calibration parameters from cal data.
> 
>   EEPROM[OTP] FLASH[DT/pre-cal file]
> Cal param 0x700   0x1
> Board id  0x100x8000
> 
> Tested on QCA9888 with pre-cal file.
> 
> Signed-off-by: Anilkumar Kolli 
> ---
>  drivers/net/wireless/ath/ath10k/bmi.h  |2 ++
>  drivers/net/wireless/ath/ath10k/core.c |   16 +---
>  2 files changed, 15 insertions(+), 3 deletions(-)

Just tried this on an QCA9984 which doesn't seem to have the calibration data 
in the PCI EEPROM.

[   71.728929] ath10k_pci :01:00.0: qca9984/qca9994 hw1.0 target 
0x0100 chip_id 0x sub 168c:cafe
[   71.732926] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1 tracing 0 
dfs 1 testmode 1
[   71.752282] ath10k_pci :01:00.0: firmware ver 
10.4-ct-9984-fW-009-dfa0083 api 5 features peer-flow-ctrl crc32 7198d117
[   73.805730] ath10k_pci :01:00.0: unable to read from the device
[   73.805769] ath10k_pci :01:00.0: could not execute otp for board id 
check: -110

It works when I use the pre-cal data as calibration data. The checksum in the 
pre-cal seems to be correct. Also the pre-cal data from 0:ART for the 2.4GHz 
and 5GHz QCA4019 seem to work perfectly fine.

Anything which I could have missed or what I could test? Btw. I've also tested 
the non-ct firmware (aka the official one from QCA).

Kind

signature.asc
Description: This is a digitally signed message part.

[PATCH v2 1/2] dt: bindings: add new dt entry for ath10k calibration variant

[Sven Eckelmann]

The bus + bmi-chip-id + bmi-board-id is not enough to identify the correct
board data file on QCA4019 based devices. Multiple different boards share
the same values. Only the original reference designs can currently be
identified and loaded from the board-2.bin. But these will not result in
the correct calibration data when combined with the pre-calibration data
from the device.

An additional "variant" information has to be provided (via SMBIOS or DT)
to select the correct board data for a design which was modified by an ODM.

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
index 74d7f0af209c..3d2a031217da 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
@@ -41,6 +41,9 @@ Optional properties:
 - qcom,msi_addr: MSI interrupt address.
 - qcom,msi_base: Base value to add before writing MSI data into
MSI address register.
+- qcom,ath10k-calibration-variant: string to search for in the board-2.bin
+  variant list with the same bus and device
+  specific ids
 - qcom,ath10k-calibration-data : calibration data + board specific data
 as an array, the length can vary between
 hw versions.
-- 
2.11.0

[PATCH v2 2/2] ath10k: search DT for qcom,ath10k-calibration-variant

[Sven Eckelmann]

Board Data File (BDF) is loaded upon driver boot-up procedure. The right
board data file is identified on QCA4019 using bus, bmi-chip-id and
bmi-board-id.

The problem, however, can occur when the (default) board data file cannot
fulfill with the vendor requirements and it is necessary to use a different
board data file.

This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8.
Something similar has to be provided for systems without SMBIOS but with
device trees. No solution was specified by QCA and therefore a new one has
to be found for ath10k.

The device tree requires addition strings to define the variant name

wifi@a00 {
status = "okay";
qcom,ath10k-calibration-variant = "RT-AC58U";
};

wifi@a80 {
status = "okay";
qcom,ath10k-calibration-variant = "RT-AC58U";
};

This would create the boarddata identifiers for the board-2.bin search

 *  bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U
 *  bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 40 --
 1 file changed, 33 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index b29fdbd21ead..6264e2cc4c0d 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -860,6 +860,28 @@ static int ath10k_core_check_smbios(struct ath10k *ar)
return 0;
 }
 
+static int ath10k_core_check_dt(struct ath10k *ar)
+{
+   struct device_node *node;
+   const char *variant = NULL;
+
+   node = ar->dev->of_node;
+   if (!node)
+   return -ENOENT;
+
+   of_property_read_string(node, "qcom,ath10k-calibration-variant",
+   );
+   if (!variant)
+   return -ENODATA;
+
+   if (strscpy(ar->id.bdf_ext, variant, sizeof(ar->id.bdf_ext)) < 0)
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "bdf variant string is longer than the buffer can 
accommodate (variant: %s)\n",
+   variant);
+
+   return 0;
+}
+
 static int ath10k_download_and_run_otp(struct ath10k *ar)
 {
u32 result, address = ar->hw_params.patch_load_addr;
@@ -1231,19 +1253,19 @@ static int ath10k_core_create_board_name(struct ath10k 
*ar, char *name,
/* strlen(',variant=') + strlen(ar->id.bdf_ext) */
char variant[9 + ATH10K_SMBIOS_BDF_EXT_STR_LENGTH] = { 0 };
 
+   if (ar->id.bdf_ext[0] != '\0')
+   scnprintf(variant, sizeof(variant), ",variant=%s",
+ ar->id.bdf_ext);
+
if (ar->id.bmi_ids_valid) {
scnprintf(name, name_len,
- "bus=%s,bmi-chip-id=%d,bmi-board-id=%d",
+ "bus=%s,bmi-chip-id=%d,bmi-board-id=%d%s",
  ath10k_bus_str(ar->hif.bus),
  ar->id.bmi_chip_id,
- ar->id.bmi_board_id);
+ ar->id.bmi_board_id, variant);
goto out;
}
 
-   if (ar->id.bdf_ext[0] != '\0')
-   scnprintf(variant, sizeof(variant), ",variant=%s",
- ar->id.bdf_ext);
-
scnprintf(name, name_len,
  
"bus=%s,vendor=%04x,device=%04x,subsystem-vendor=%04x,subsystem-device=%04x%s",
  ath10k_bus_str(ar->hif.bus),
@@ -2343,7 +2365,11 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
 
ret = ath10k_core_check_smbios(ar);
if (ret)
-   ath10k_dbg(ar, ATH10K_DBG_BOOT, "bdf variant name not set.\n");
+   ath10k_dbg(ar, ATH10K_DBG_BOOT, "SMBIOS bdf variant name not 
set.\n");
+
+   ret = ath10k_core_check_dt(ar);
+   if (ret)
+   ath10k_dbg(ar, ATH10K_DBG_BOOT, "DT bdf variant name not 
set.\n");
 
ret = ath10k_core_fetch_board_file(ar);
if (ret) {
-- 
2.11.0

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

[Sven Eckelmann]

On Dienstag, 21. November 2017 11:43:36 CET ako...@codeaurora.org wrote:
[...]
> > I think we should add a special case to not print the warning if mcs ==
> > 15 until we figure out what it means.
> 
> Fix identified in Firmware and will push ASAP.

Is it known when this will be released and for which firmware/HW versions? And 
will this also fix the legacy rate reports? At least in the moment, 
ath10k_htt_fetch_peer_stats seems to generate following on QCA4019 for some 
clients:

[ 1627.720177] ath10k_ahb a80.wifi: Invalid legacy rate 26 peer stats
[ 1632.010290] ath10k_ahb a80.wifi: Invalid legacy rate 26 peer stats

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [PATCHv3 1/2] ath10k: add per peer htt tx stats support for 10.4

[Sven Eckelmann]

On Dienstag, 21. November 2017 10:00:20 CET Sebastian Gottschall wrote:
> maybe this one?
> 
> i have this qca988x supporting tx/rx rate patch in my local tree. just 
> need to extract it again
> 
>   ath10k: report per-station tx/rate rates to mac80211

This one sounds like https://patchwork.kernel.org/patch/8597341/ - and it is 
something different (end is implementing get_expected_throughput "wrong" and 
therefore overestimates the expected throughput extremely). This patch is 
using the stuff from fw_stats to fill the station rx/tx information.

It is not the worst thing to do (I want(ed) to use something similar for my 
purposes) but there is a special pktlog message on 10.2 which contains the 
same information as the 10.4 HTT_10_4_T2H_MSG_TYPE_PEER_STATS.

Kind regards,
Sven 


signature.asc
Description: This is a digitally signed message part.

Re: [PATCHv3 1/2] ath10k: add per peer htt tx stats support for 10.4

[Sven Eckelmann]

On Dienstag, 21. November 2017 09:00:54 CET Sebastian Gottschall wrote:
[...]
> >> Why is the support for 10.2.4 firmware not upstreamed? I mean the one 
> >> which is
> >> using pktlog to transfer the PEER_STATS information.
> > I'm not sure what you are asking. If you are asking the firmware release
> > mentioned in the commit log that's in ath10k-firmware:
> >
> > https://github.com/kvalo/ath10k-firmware/tree/master/QCA4019/hw1.0/3.2.1
> >
> > But I'm sure you know that already.
> 
> i believe he is just talking about a patch which allows to get station 
> statistics like rx and tx rate on the firmare 10.2 series which is 
> qca988x mainly
> 
> this patch was posted here months ago but never got upstream

Yes, I was talking about that patch (which I didn't find on the mailing list - 
so a link would be helpful). QCA is gathering a lot of patches (a00-*) at 
https://source.codeaurora.org/quic/qsdk/oss/system/feeds/wlan-open/tree/mac80211/patches?h=coconut
which are often not upstreamed. The patch 
a00-0075-ath10k-Add-support-to-parse-per-station-tx-stats-for.patch is the one 
which is receiving the TX statistics stuff from 10.2.

I had a discussion with some QCA employee (or actually OpenMesh had it and I 
joined the discussion rather late) where the QCA employee was very confident 
that ath10k supports ATH10K_PKTLOG_PEER_STATS (not the fw_stats stuff in 
debugfs). But I couldn't find the code for that in ath10k. Only after some 
guesswork, I was able to find the patch mentioned above and was able to test 
it (after hacking the smart antenna patch dependency away).

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [PATCHv3 1/2] ath10k: add per peer htt tx stats support for 10.4

[Sven Eckelmann]

On Dienstag, 15. November 2016 22:07:29 CET ako...@qti.qualcomm.com wrote:
> From: Anilkumar Kolli 
> 
> Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
> event, Firmware sends one HTT event for every four PPDUs.
> HTT payload has success pkts/bytes, failed pkts/bytes, retry
> pkts/bytes and rate info per ppdu.
> Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
> which are nowadays enabled by default.
> 
> Parse peer stats and update the tx rate information per STA.
> 
> tx rate, Peer stats are tested on QCA4019 with Firmware version
> 10.4-3.2.1-00028.
> 
> Signed-off-by: Anilkumar Kolli 

Why is the support for 10.2.4 firmware not upstreamed? I mean the one which is 
using pktlog to transfer the PEER_STATS information.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

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

[Sven Eckelmann]

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.

Kind regards.
Sven

signature.asc
Description: This is a digitally signed message part.

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

[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
> 
> 
> i tested this with the 10.4.3.5-0038 firmware which isnt official 
> published but made from athwlan.bin i got from qca chipcode

Hm, yes there is most likely something wrong. But not sure whether this patch 
is actually the culprit. It looks to me like this would also be reported the 
same way without the patch. cec17c382140 ("ath10k: add per peer htt tx stats 
support for 10.4") seems to be your problem, right?

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.

Kind regards,
Sven


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] wireless-regdb: Update regulatory rules for Singapore (SG)

[Sven Eckelmann]

On Mittwoch, 23. August 2017 15:52:40 CEST Seth Forshee wrote:
[...]
> > +# Source
> > +# 
> > https://www.imda.gov.sg/~/media/imda/files/regulation%20licensing%20and%20consultations/ict%20standards/telecommunication%20standards/radio-comms/imdatssrd.pdf?la=en
> > +# page 12-14
> > +# The EIRP for 5250 – 5350 can be increased by 3dB if TPC is implemented.
[...]
> > +   # 5470 - 5725 is only allowed when TPC is implemented
> > +   # (5470 - 5725 @ 160), (30), DFS
> 
> I'm not sure that the lack of a specific provision for operating without
> TPC in this range means that it cannot be used. As I understand it, TPC
> would only result in a reduction in EIRP of 3 dB, so as long as we use
> a power limit of half of the maximum allowed we will be safe.
> 
> If this is incorrect I'd appreciate it if someone more knowledgable on
> the topic could chime in.

I would also be happy about feedback regarding this part. But my current 
settings are based on the document [1] mentioned in this change.

Let us look at the range 5250 – 5350 on page 13. There are two entries for the 
same frequency range.

 * 28:
   - up to 200 mW
   - requires TPC for 5250 – 5350 Mhz
 * 29:
   - up to 100 mW
   - requires *no* TPC for 5250 – 5350 Mhz

This is exactly the 3(.01029995...) dB difference which you've talked about. 
Now to the frequency range 5470 - 5725 MHz on page 14. 

 * 30:
   - up to 1000 mW
   - requires TPC for 5470 - 5725 MHz

There is no extra exception rule for non-TPC mode.

Now let us check what IEEE 802.11h-2003 [2] says about TPC.

* 5.4.4.1 TPC:
  - doesn't say anything about 3dB but mentions adaption based on different 
criteria
* 7.3.2.16 Power Capability element
  - nothing regarding 3 dB here (just allows 5 dB tolerance)
* 7.3.2.17 TPC Request element
  - only describes the element
  - nothing relevant regarding the usage
* 7.3.2.18 TPC Report element
  - only describes the element
  - nothing relevant regarding the usage
* 7.4.1.3 TPC Request frame format
  - only describes the element
  - nothing relevant regarding the usage
* 7.4.1.4 TPC Report frame format
  - only describes the element
  - nothing relevant regarding the usage
* 10.3.16 TPC request
  - nothing relevant regarding the limits
* 11.5 TPC procedures
  - refers to 11.5.4 for the power adaption
* 11.5.4 Adaptation of the transmit power
  - has some suggestions to the power reduction methods
  - doesn't go into details
  - nothing about a 3dB only reduction

Ok, where is the 3 dB then coming from? My guess is the mitigation 
requirement. This should be 3 dB as *default* value (page 59). "11.5 TPC 
procedures" says following:

"Potential methods to ensure regulations are met even if TPC is not employed
include using a transmit power that is below the legal maximum (including any 
mitigation factor).".

It informs us also in "11.5.2 Specification of regulatory and local maximum 
transmit power levels" that the mitigation factors are defined in each 
regulatory domain:

"Any calculation of the local maximum transmit power for the channel shall 
ensure the mitigation requirements for the channel in the current regulatory 
domain can be satisfied. The conservative approach is to set the local maximum 
transmit power level equal to the regulatory maximum transmit power level 
minus the mitigation requirement. However, it may be possible to satisfy the 
mitigation requirement using a higher local maximum transmit power level. A 
lower local maximum transmit power level may be used for other purposes (e.g., 
range control, reduction of interference)."

It is therefore now relevant to know how these these statements from 802.11h 
and the statements from the the Singapore document have to be combined 
correctly. My current change now assumes following strict interpretation:

 * Singapore provides a mitigation factor of 3 dB for 5250 – 5350 Mhz (see 
   table entry 28 + 29)
 * Singapore provides now mitigation factor for 5470 - 5725 MHz and requires 
   TPC

I am currently unsure whether it is now valid to say that the default 
mitigation factor would be 3 dB and thus there is an implicit table entry (let 
us call it 30b) which would be:

 * 30b:
   - up to 500 mW
   - requires *no* TPC for 5470 - 5725 MHz

Countries like AU or regions like ETSI (ETSI EN 301 893) seem to have this 
mitigation factor always specified in their rules. But Singapore is missing it 
for this specific frequency range.

Kind regards,
Sven

[1] 
https://www.imda.gov.sg/~/media/imda/files/regulation%20licensing%20and%20consultations/ict%20standards/telecommunication%20standards/radio-comms/imdatssrd.pdf?la=en
[2] http://standards.ieee.org/getieee802/download/802.11h-2003.pdf

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 2/2] ath10k: search DT for qcom,ath10k-calibration-variant

[Sven Eckelmann]

On Freitag, 10. März 2017 19:20:54 CEST Christian Lamparter wrote:
[...]
> @Aeolus Yang / Kalle / QCA: Would it be possible to assign a variant string to
> the Asus RT-AC58U?
> 
> I've attached the necessary bmi-board-id=16 and bmi-board-id=17 board 
> files to this mail as well. So, all that needs to be done is to add
> them to the board-2.bin on your codeaurora / ath10k-firmware project.
> 
> Kalle: Can you please update the board-2.bin for the IPQ40XX on your
> ath10k-firmware project on github?
> 
> https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/ath10k/QCA40XX/hw1.0/board-2.bin
> It looks like this board-2.bin has support for a few more boards.

Any updates on that?

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

ath: Incorrect regDomainPairs/allCountries settings

[Sven Eckelmann]

Hi,

I just had two inquiries from Vietnam and Singapore regarding the used CTL 
limits by Atheros based chips. I've checked through the code and noticed that 
regd_common.h assigns SG to APL6_WORLD and VN to NULL1_WORLD.

 * SG: APL6_WORLD
   - 2.4GHz: CTL_ETSI
   -   5GHz: CTL_ETSI
 * VN: NULL1_WORLD
   - 2.4GHz: CTL_ETSI
   -   5GHz: NO_CTL

But I personally would have expected that both countries would be assigned to 
FCC3_WORLD.

 * FCC3_WORLD
   - 2.4GHz: CTL_ETSI
   -   5GHz: CTL_FCC

Maybe someone from QCA can check with their internal driver.

I have compared the current ath/regd_common.h with what I would have expected 
(which might not be correct after all). I still wanted to list the things 
which I found:

Missing Entries in CountryCode (regd.h):

 * CTRY_AFGHANISTAN = 4,
 * CTRY_AMERICAN_SAMOA = 16,
 * CTRY_ANGUILLA = 660,
 * CTRY_BAHAMAS = 44,
 * CTRY_BERMUDA = 60,
 * CTRY_BHUTAN = 64,
 * CTRY_BURKINA_FASO = 854,
 * CTRY_CAYMAN_ISLANDS = 136,
 * CTRY_CENTRAL_AFRICA_REPUBLIC = 140,
 * CTRY_CHAD = 148,
 * CTRY_CHRISTMAS_ISLAND = 162,
 * CTRY_DOMINICA = 212,
 * CTRY_ETHIOPIA = 231,
 * CTRY_FRENCH_GUIANA = 254,
 * CTRY_FRENCH_POLYNESIA = 258,
 * CTRY_GHANA = 288,
 * CTRY_GUADELOUPE = 312,
 * CTRY_GUYANA = 328,
 * CTRY_COTE_D_IVOIRE = 384,
 * CTRY_LESOTHO = 426,
 * CTRY_MALAWI = 454,
 * CTRY_MALDIVES = 462,
 * CTRY_MARSHALL_ISLANDS = 584,
 * CTRY_MARTINIQUE = 474,
 * CTRY_MAURITANIA = 478,
 * CTRY_MAURITIUS = 480,
 * CTRY_MAYOTTE = 175,
 * CTRY_MICRONESIA = 583,
 * CTRY_MOLDOVA = 498,
 * CTRY_MONGOLIA = 496,
 * CTRY_NAMIBIA = 516,
 * CTRY_NIGERIA = 566,
 * CTRY_NORTHERN_MARIANA_ISLANDS = 580,
 * CTRY_PALAU = 585,
 * CTRY_REUNION = 638,
 * CTRY_RWANDA = 646,
 * CTRY_ST_BARTHELEMY = 652,
 * CTRY_ST_KITTS_NEVIS = 659,
 * CTRY_ST_LUCIA = 662,
 * CTRY_ST_MARTIN = 663,
 * CTRY_ST_PIERRE_MIQUELON = 666,
 * CTRY_ST_VINCENT_GRENADIENS= 670,
 * CTRY_SAMOA = 882,
 * CTRY_SENEGAL = 686,
 * CTRY_SERBIA = 688,
 * CTRY_MONTENEGRO = 499,
 * CTRY_SURINAME = 740,
 * CTRY_TANZANIA = 834,
 * CTRY_TOGO = 768,
 * CTRY_TURKS_CAICOS = 796,
 * CTRY_UGANDA = 800,
 * CTRY_UNITED_STATES2 = 841,
 * CTRY_UNITED_STATES3 = 843,
 * CTRY_VANUATU = 548,
 * CTRY_VIRGIN_ISLANDS = 850,
 * CTRY_WALLIS_FUTUNA = 876,
 * CTRY_ARGENTINA2 = 5003

Entries which most likely shouldn't exist in CountryCode:

 * CTRY_KOREA_ROC2
 * CTRY_SERBIA_MONTENEGRO

Things which I missed in the EnumRd:

 * FCC11_WORLD = 0x19,
 * FCC3_ETSIC = 0x3F,
 * ETSI8_WORLD = 0x3D,
 * ETSI9_WORLD = 0x3E,
 * APL12_WORLD = 0x51,
 * APL14_WORLD = 0x57,
 * APL15_WORLD = 0x59,
 * APL13_WORLD = 0x5A,
 * APL10_WORLD = 0x5F,


The new mappings in regDomainPairs for the used EnumRds would then be:

 * {FCC11_WORLD, CTL_FCC, CTL_ETSI},
 * {FCC3_ETSIC, CTL_FCC, CTL_ETSI},
 * {ETSI8_WORLD, CTL_ETSI, CTL_ETSI},
 * {ETSI9_WORLD, CTL_ETSI, CTL_ETSI},
 * {APL10_WORLD, CTL_ETSI, CTL_ETSI},
 * {APL12_WORLD, CTL_ETSI, CTL_ETSI},
 * {APL13_WORLD, CTL_ETSI, CTL_ETSI},
 * {APL14_WORLD, CTL_FCC, CTL_ETSI},
 * {APL15_WORLD, CTL_FCC, CTL_ETSI},


Things which I missed in allCountries

 * {CTRY_AFGHANISTAN, ETSI1_WORLD, "AF"},
 * {CTRY_AMERICAN_SAMOA, FCC3_FCCA, "AS"},
 * {CTRY_ANGUILLA, ETSI1_WORLD, "AI"},
 * {CTRY_BAHAMAS, FCC3_WORLD, "BS"},
 * {CTRY_BERMUDA, FCC3_FCCA, "BM"},
 * {CTRY_BHUTAN, ETSI1_WORLD, "BT"},
 * {CTRY_BURKINA_FASO,FCC3_WORLD, "BF"},
 * {CTRY_CAYMAN_ISLANDS, FCC3_WORLD, "KY"},
 * {CTRY_CENTRAL_AFRICA_REPUBLIC, FCC3_WORLD, "CF"},
 * {CTRY_CHAD, ETSI1_WORLD, "TD"},
 * {CTRY_CHRISTMAS_ISLAND, FCC3_WORLD, "CX"},
 * {CTRY_DOMINICA, FCC1_FCCA, "DM"},
 * {CTRY_ETHIOPIA, ETSI1_WORLD, "ET"},
 * {CTRY_FRENCH_GUIANA, ETSI1_WORLD, "GF"},
 * {CTRY_FRENCH_POLYNESIA, ETSI1_WORLD, "PF"},
 * {CTRY_GHANA, FCC3_WORLD, "GH"},
 * {CTRY_GUADELOUPE, ETSI1_WORLD, "GP"},
 * {CTRY_GUYANA, APL1_ETSIC, "GY"},
 * {CTRY_COTE_D_IVOIRE, FCC3_WORLD, "CI"},
 * {CTRY_KENYA, APL12_WORLD, "KE"},
 * {CTRY_LESOTHO, ETSI1_WORLD, "LS"},
 * {CTRY_MALDIVES, APL6_WORLD, "MV"},
 * {CTRY_MARSHALL_ISLANDS, FCC3_FCCA, "MH"},
 * {CTRY_MARTINIQUE, ETSI1_WORLD, "MQ"},
 * {CTRY_MAURITANIA, ETSI1_WORLD, "MR"},
 * {CTRY_MAURITIUS, FCC3_WORLD, "MU"},
 * {CTRY_MAYOTTE, ETSI1_WORLD, "YT"},
 * {CTRY_MICRONESIA, FCC3_FCCA, "FM"},
 * {CTRY_MOLDOVA, ETSI1_WORLD, "MD"},
 * {CTRY_MONGOLIA, FCC3_WORLD, "MN"},
 * {CTRY_MONTENEGRO, ETSI1_WORLD, "ME"},
 * {CTRY_NAMIBIA, APL9_WORLD, "NA"},
 * {CTRY_NICARAGUA, FCC3_FCCA, "NI"},
 * {CTRY_NIGERIA, APL8_WORLD, "NG"},
 * {CTRY_NORTHERN_MARIANA_ISLANDS, FCC3_FCCA, "MP"},
 * {CTRY_PALAU, FCC3_FCCA, "PW"},
 * {CTRY_PARAGUAY, FCC3_WORLD, "PY"},
 * {CTRY_REUNION, ETSI1_WORLD, "RE"},
 * {CTRY_RWANDA, FCC3_WORLD, "RW"},
 * {CTRY_SENEGAL, FCC3_WORLD, "SN"},
 * {CTRY_SERBIA, ETSI1_WORLD, "RS"},
 * {CTRY_ST_BARTHELEMY, ETSI1_WORLD, "BL"},
 * {CTRY_ST_KITTS_NEVIS, APL10_WORLD, "KN"},
 * {CTRY_ST_LUCIA, APL10_WORLD, "LC"},
 * {CTRY_ST_MARTIN, ETSI1_WORLD, "MF"},
 * {CTRY_ST_PIERRE_MIQUELON, ETSI1_WORLD, "PM"},
 * {CTRY_ST_VINCENT_GRENADIENS, ETSI1_WORLD, "VC"},
 * {CTRY_SAMOA, ETSI1_WORLD, "WS"},
 * 

[PATCH] wireless-regdb: Update regulatory rules for Singapore (SG)

[Sven Eckelmann]

2.4GHz and the lower 5GHz band can now be use with up to 23dBm. But the DFS
channels in general require TPC to be usable. Only 5150 - 5250 has an
exception which allows the use of it without TPC when reducing the power to
20 dBm.

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
Please check this twice because this is my first attempt in converting an
official regulatory document to an wireless-regdb entry.

 db.txt | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/db.txt b/db.txt
index 0bc068e..df30f37 100644
--- a/db.txt
+++ b/db.txt
@@ -1078,12 +1078,17 @@ country SE: DFS-ETSI
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
 
+# Source
+# 
https://www.imda.gov.sg/~/media/imda/files/regulation%20licensing%20and%20consultations/ict%20standards/telecommunication%20standards/radio-comms/imdatssrd.pdf?la=en
+# page 12-14
+# The EIRP for 5250 – 5350 can be increased by 3dB if TPC is implemented.
 country SG: DFS-FCC
-   (2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (17), AUTO-BW
-   (5250 - 5330 @ 80), (24), DFS, AUTO-BW
-   (5490 - 5730 @ 160), (24), DFS
-   (5735 - 5835 @ 80), (30)
+   (2400 - 2483.5 @ 40), (23)
+   (5150 - 5250 @ 80), (23), AUTO-BW
+   (5250 - 5350 @ 80), (20), DFS, AUTO-BW
+   # 5470 - 5725 is only allowed when TPC is implemented
+   # (5470 - 5725 @ 160), (30), DFS
+   (5725 - 5850 @ 80), (30)
 
 country SI: DFS-ETSI
(2402 - 2482 @ 40), (20)
-- 
2.11.0

Re: [PATCH v2 2/3] ath10k: Configure rxnss_override for 10.4 firmware.

[Sven Eckelmann]

On Freitag, 16. Juni 2017 08:50:13 CEST Kalle Valo wrote:
> We have hw_params for stuff like this so I changed this and the
> following patch to use that. Please review:

Looks good. Thanks for adjusting the patches.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

[PATCH v2 2/3] ath10k: Configure rxnss_override for 10.4 firmware.

[Sven Eckelmann]

From: Ben Greear <gree...@candelatech.com>

QCA9984 hardware can do 4x4 at 80Mhz, but only 2x2 at 160Mhz.

First, report this to user-space by setting the max-tx-speed
and max-rx-speed vht capabilities.

Second, if the peer rx-speed is configured, and if we
are in 160 or 80+80 mode, and the peer rx-speed matches
the max speed for 2x2 or 1x1 at 160Mhz (long guard interval),
then use that info to set the peer_bw_rxnss_override appropriately.

Without this, a 9984 firmware will not use 2x2 ratesets when
transmitting to peer (it will be stuck at 1x1), because
the firmware would not have configured the rxnss_override.

This could use some testing

Signed-off-by: Ben Greear <gree...@candelatech.com>
[sven.eckelm...@openmesh.com: rebase, cleanup, drop 160Mhz workaround cleanup]
Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
v2:
 - rebased patch
 - minor cleanups
 - removal of the 160 MHz workaround (see patch 1)

 drivers/net/wireless/ath/ath10k/mac.c | 31 +++
 drivers/net/wireless/ath/ath10k/wmi.c |  7 ++-
 drivers/net/wireless/ath/ath10k/wmi.h |  2 ++
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 8087b6be5484..0752cf351b4a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2519,6 +2519,20 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
 
ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags 
0x%x\n",
   sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+
+   if (arg->peer_vht_rates.rx_max_rate &&
+   (sta->vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK)) {
+   switch (arg->peer_vht_rates.rx_max_rate) {
+   case 1560:
+   /* Must be 2x2 at 160Mhz is all it can do. */
+   arg->peer_bw_rxnss_override = 2;
+   break;
+   case 780:
+   /* Can only do 1x1 at 160Mhz (Long Guard Interval) */
+   arg->peer_bw_rxnss_override = 1;
+   break;
+   }
+   }
 }
 
 static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
@@ -4408,6 +4422,23 @@ static struct ieee80211_sta_vht_cap 
ath10k_create_vht_cap(struct ath10k *ar)
vht_cap.vht_mcs.rx_mcs_map = cpu_to_le16(mcs_map);
vht_cap.vht_mcs.tx_mcs_map = cpu_to_le16(mcs_map);
 
+   /* If we are supporting 160Mhz or 80+80, then the NIC may be able to do
+* a restricted NSS for 160 or 80+80 vs what it can do for 80Mhz.  Give
+* user-space a clue if that is the case.
+*/
+   if (vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK) {
+   switch (ar->dev_id) {
+   case QCA9984_1_0_DEVICE_ID:
+   /* Can do only 2x2 VHT160 or 80+80.
+* 1560Mbps is 4x4 80Mhz or 2x2 160Mhz,
+* long-guard-interval
+*/
+   vht_cap.vht_mcs.rx_highest = 1560;
+   vht_cap.vht_mcs.tx_highest = 1560;
+   break;
+   }
+   }
+
return vht_cap;
 }
 
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 6afc8d27f0d5..2c3b0214ba5f 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -6757,7 +6757,12 @@ ath10k_wmi_peer_assoc_fill_10_4(struct ath10k *ar, void 
*buf,
struct wmi_10_4_peer_assoc_complete_cmd *cmd = buf;
 
ath10k_wmi_peer_assoc_fill_10_2(ar, buf, arg);
-   cmd->peer_bw_rxnss_override = 0;
+   if (arg->peer_bw_rxnss_override)
+   cmd->peer_bw_rxnss_override =
+   __cpu_to_le32((arg->peer_bw_rxnss_override - 1) |
+ BIT(PEER_BW_RXNSS_OVERRIDE_OFFSET));
+   else
+   cmd->peer_bw_rxnss_override = 0;
 }
 
 static int
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 1b4865a55595..dd6cac150749 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6028,6 +6028,7 @@ struct wmi_10_2_peer_assoc_complete_cmd {
__le32 info0; /* WMI_PEER_ASSOC_INFO0_ */
 } __packed;
 
+#define PEER_BW_RXNSS_OVERRIDE_OFFSET  31
 struct wmi_10_4_peer_assoc_complete_cmd {
struct wmi_10_2_peer_assoc_complete_cmd cmd;
__le32 peer_bw_rxnss_override;
@@ -6051,6 +6052,7 @@ struct wmi_peer_assoc_complete_arg {
u32 peer_vht_caps;
enum wmi_phy_mode peer_phymode;
struct wmi_vht_rate_set_arg peer_vht_rates;
+   u32 peer_bw_rxnss_override;
 };
 
 struct wmi_peer_add_wds_entry_cmd {
-- 
2.11.0

[PATCH v2 1/3] ath10k: Use complete VHT chan width for 160MHz workaround

[Sven Eckelmann]

From: Ben Greear <gree...@candelatech.com>

The ath10k firmware doesn't announce its VHT channel width capabilities in
the vht_cap information from the "service ready event" arguments. The
driver must therefore check whether the 160MHz short GI bit is set and
whether the driver still doesn't set the bits for the 160/80+80 MHz
capabilities.

The two bits for the channel width are a two bit integer and not two
separate bits which cannot be parsed without the knowledge of the other
bit. Using IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ (b10..) as a
mask for this task doesn't make any sense. The correct mask for the VHT
channel width should be used instead to make this check more readable.

Signed-off-by: Ben Greear <gree...@candelatech.com>
[sven.eckelm...@openmesh.com: separate 160Mhz workaround cleanup, add commit
 message]
Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
v2:
 - extracted this cleanup portion and converted it to a separate patch

 drivers/net/wireless/ath/ath10k/mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 4674ff33d320..8087b6be5484 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4391,7 +4391,7 @@ static struct ieee80211_sta_vht_cap 
ath10k_create_vht_cap(struct ath10k *ar)
 * mode until that's resolved.
 */
if ((ar->vht_cap_info & IEEE80211_VHT_CAP_SHORT_GI_160) &&
-   !(ar->vht_cap_info & 
IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ))
+   (ar->vht_cap_info & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK) == 0)
vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
 
mcs_map = 0;
-- 
2.11.0

[PATCH v2 3/3] ath10k: Set rxnss_override for QCA9888

[Sven Eckelmann]

QCA9888 supports VHT80 with 2x2. But it only support 1x1 with VHT160 or
VHT80+80. Inform userspace and the the QCA firmware about that limitation
whenever VHT80+80 or VHT160 is configured.

Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
v2:
 - new patch

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

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 0752cf351b4a..75e90adc8fb4 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4436,6 +4436,14 @@ static struct ieee80211_sta_vht_cap 
ath10k_create_vht_cap(struct ath10k *ar)
vht_cap.vht_mcs.rx_highest = 1560;
vht_cap.vht_mcs.tx_highest = 1560;
break;
+   case QCA9888_2_0_DEVICE_ID:
+   /* Can do only 1x1 VHT160 or 80+80.
+* 780Mbps is 2x2 80Mhz or 1x1 160Mhz,
+* long-guard-interval
+*/
+   vht_cap.vht_mcs.rx_highest = 780;
+   vht_cap.vht_mcs.tx_highest = 780;
+   break;
}
}
 
-- 
2.11.0

Re: ath10k: Configure rxnss_override for 10.4 firmware.

[Sven Eckelmann]

On Mittwoch, 15. Februar 2017 01:26:58 CEST Kalle Valo wrote:
> Ben Greear  wrote:
> > From: Ben Greear 
> > 
> > QCA9984 hardware can do 4x4 at 80Mhz, but only 2x2 at 160Mhz.
[]
> Does not apply:
> 
> error: patch failed: drivers/net/wireless/ath/ath10k/mac.c:2760
> error: drivers/net/wireless/ath/ath10k/mac.c: patch does not apply
> error: patch failed: drivers/net/wireless/ath/ath10k/wmi.h:6173
> error: drivers/net/wireless/ath/ath10k/wmi.h: patch does not apply
> stg import: Diff does not apply cleanly
> 
> Patch set to Changes Requested.

I wanted to use this patch to announce the maximum speed for QCA9888.
I hope it is ok for Ben Greear when I rebase and resubmit it.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] [ath10k] go back to using dma_alloc_coherent() for firmware scratch memory.

[Sven Eckelmann]

236
[9.649615]  [] ? swiotlb_map_page+0x16c/0x190
[9.657526]  [] ? 
ath10k_wmi_event_service_ready_work+0x4d5/0x680 [ath10k_core]
[9.670007]  [] ? process_one_work+0x14b/0x410
[9.677874]  [] ? worker_thread+0x65/0x4a0
[9.685388]  [] ? rescuer_thread+0x340/0x340
[9.693016]  [] ? kthread+0xe0/0x100
[9.699914]  [] ? __switch_to+0x2bb/0x700
[9.707224]  [] ? kthread_park+0x60/0x60
[9.714363]  [] ? ret_from_fork+0x25/0x30
[9.721589] ---[ end trace 6814c79dfe2a14da ]---

Tested-by: Sven Eckelmann <sven.eckelm...@openmesh.com>

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

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

[Sven Eckelmann]

On Donnerstag, 11. Mai 2017 11:39:46 CEST Arend Van Spriel wrote:
[...]
> So you leave VHT as is. Did you check with 11ac device? I am wondering
> if it needs the same change.

VHT MCS rates are reported by drivers with NSS + MCS rates 0-9 [1] as 
separated values. So I would say that the code is correct to report them as 
separate values. But no, I haven't tested with an 802.11ac capable device 
which I can fully trust because I didn't have one in arms reach (and I would 
have to compile a new firmware for it). But the output for a second ath10k 
based device looks ok'ish:

Station ac:86:74:61:6b:30 (on wlan1)
inactive time:  700 ms
rx bytes:   10741
rx packets: 95
tx bytes:   9886
tx packets: 86
tx retries: 0
tx failed:  0
rx drop misc:   1
signal: -22 dBm
signal avg: -21 dBm
tx bitrate: 780.0 MBit/s VHT-MCS 8 80MHz short GI VHT-NSS 2
rx bitrate: 780.0 MBit/s VHT-MCS 8 80MHz short GI VHT-NSS 2
rx duration:8172 us
authorized: yes
authenticated:  yes
associated: yes
preamble:   long
WMM/WME:yes
MFP:no
TDLS peer:  no
DTIM period:2
beacon interval:100
short slot time:yes
connected time: 106 seconds

Kind regards,
Sven

[1] http://mcsindex.com/


signature.asc
Description: This is a digitally signed message part.

[PATCH] ath10k: Fix reported HT MCS rates with NSS > 1

[Sven Eckelmann]

The QCA4019 firmware 10.4-3.2.1-00050 reports only HT MCS rates between
0-9. But 802.11n MCS rates can be larger than that. For example a 2x2
device can send with up to MCS 15.

The firmware encodes the higher MCS rates using the NSS field. The actual
calculation is not documented by QCA but it seems like the NSS field can be
mapped for HT rates to following MCS offsets:

 * NSS 1: 0
 * NSS 2: 8
 * NSS 3: 16
 * NSS 4: 24

This offset therefore has to be added for HT rates before they are stored
in the rate_info struct.

Fixes: cec17c382140 ("ath10k: add per peer htt tx stats support for 10.4")
Signed-off-by: Sven Eckelmann <sven.eckelm...@openmesh.com>
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 84b6067ff6e7..6c0a821fe79d 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2229,9 +2229,15 @@ ath10k_update_per_peer_tx_stats(struct ath10k *ar,
txrate.mcs = ATH10K_HW_MCS_RATE(peer_stats->ratecode);
sgi = ATH10K_HW_GI(peer_stats->flags);
 
-   if (((txrate.flags == WMI_RATE_PREAMBLE_HT) ||
-(txrate.flags == WMI_RATE_PREAMBLE_VHT)) && txrate.mcs > 9) {
-   ath10k_warn(ar, "Invalid mcs %hhd peer stats", txrate.mcs);
+   if (txrate.flags == WMI_RATE_PREAMBLE_VHT && txrate.mcs > 9) {
+   ath10k_warn(ar, "Invalid VHT mcs %hhd peer stats",  txrate.mcs);
+   return;
+   }
+
+   if (txrate.flags == WMI_RATE_PREAMBLE_HT &&
+   (txrate.mcs > 7 || txrate.nss < 1)) {
+   ath10k_warn(ar, "Invalid HT mcs %hhd nss %hhd peer stats",
+   txrate.mcs, txrate.nss);
return;
}
 
@@ -2254,7 +2260,7 @@ ath10k_update_per_peer_tx_stats(struct ath10k *ar,
arsta->txrate.legacy = rate;
} else if (txrate.flags == WMI_RATE_PREAMBLE_HT) {
arsta->txrate.flags = RATE_INFO_FLAGS_MCS;
-   arsta->txrate.mcs = txrate.mcs;
+   arsta->txrate.mcs = txrate.mcs + 8 * (txrate.nss - 1);
} else {
arsta->txrate.flags = RATE_INFO_FLAGS_VHT_MCS;
arsta->txrate.mcs = txrate.mcs;
-- 
2.11.0

Re: [PATCHv3 1/2] ath10k: add per peer htt tx stats support for 10.4

[Sven Eckelmann]

On Dienstag, 15. November 2016 22:07:29 CEST ako...@qti.qualcomm.com wrote:
> From: Anilkumar Kolli 
> 
> Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
> event, Firmware sends one HTT event for every four PPDUs.
> HTT payload has success pkts/bytes, failed pkts/bytes, retry
> pkts/bytes and rate info per ppdu.
> Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
> which are nowadays enabled by default.
> 
> Parse peer stats and update the tx rate information per STA.
> 
> tx rate, Peer stats are tested on QCA4019 with Firmware version
> 10.4-3.2.1-00028.
> 
> Signed-off-by: Anilkumar Kolli 
> ---

Just played a little bit around with it and an 802.11n client (2x2x). The 
thing I've observed was that MCS 0-7 was reported as MCS rate but the client 
received mostly MCS 8-15.

Guessing from this section

>   if (((txrate.flags == WMI_RATE_PREAMBLE_HT) ||
>(txrate.flags == WMI_RATE_PREAMBLE_VHT)) && txrate.mcs > 9) {
>   ath10k_warn(ar, "Invalid mcs %hhd peer stats", txrate.mcs);
>   return;
>   }

it looks like HT rates are reported as 0-9 with an NSS setting (yes, as odd as 
this is). I've printed the values to check it:

[   68.529197] X txrate.flags 2, txrate.bw 1, txrate.nss 2, txrate.mcs 5
[   68.529500] X txrate.flags 2, txrate.bw 1, txrate.nss 2, txrate.mcs 4
[   68.535225] X txrate.flags 2, txrate.bw 1, txrate.nss 2, txrate.mcs 4
[   68.542290] X txrate.flags 2, txrate.bw 1, txrate.nss 2, txrate.mcs 4
[   68.549507] X txrate.flags 2, txrate.bw 1, txrate.nss 2, txrate.mcs 4
[   68.555627] X txrate.flags 2, txrate.bw 1, txrate.nss 2, txrate.mcs 4
[   68.562652] X txrate.flags 2, txrate.bw 1, txrate.nss 2, txrate.mcs 4

I don't know this for sure but my next guess is now that following change is 
missing:

@@ -2231,8 +2231,10 @@ ath10k_update_per_peer_tx_stats(struct ath10k *ar,
sgi = ATH10K_HW_GI(peer_stats->flags);
 
if (((txrate.flags == WMI_RATE_PREAMBLE_HT) ||
-(txrate.flags == WMI_RATE_PREAMBLE_VHT)) && txrate.mcs > 9) {
-   ath10k_warn(ar, "Invalid mcs %hhd peer stats", txrate.mcs);
+(txrate.flags == WMI_RATE_PREAMBLE_VHT)) &&
+   (txrate.mcs > 9 || txrate.nss < 1)) {
+   ath10k_warn(ar, "Invalid mcs %hhd nss %hhd peer stats",
+   txrate.mcs, txrate.nss);
return;
}
 
@@ -2255,7 +2257,7 @@ ath10k_update_per_peer_tx_stats(struct ath10k *ar,
arsta->txrate.legacy = rate;
} else if (txrate.flags == WMI_RATE_PREAMBLE_HT) {
arsta->txrate.flags = RATE_INFO_FLAGS_MCS;
-   arsta->txrate.mcs = txrate.mcs;
+   arsta->txrate.mcs = txrate.mcs + 8 * (txrate.nss - 1);
} else {
arsta->txrate.flags = RATE_INFO_FLAGS_VHT_MCS;
arsta->txrate.mcs = txrate.mcs;

Funny enough, I was spamming following with my 802.11n 2x2 client:

[  115.694987] X txrate.flags 3, txrate.bw 1, txrate.nss 4, txrate.mcs 15
[  115.701851] ath10k_ahb a80.wifi: Invalid mcs 15 peer stats

Firmware was 10.4-3.2.1-00050 on an Dakota (IPQ401X) board.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [REGRESSION] mac80211: IBSS vif queue stopped when started after 11s vif

[Sven Eckelmann]

On Mittwoch, 29. März 2017 13:53:06 CEST Johannes Berg wrote:
[...]
> > Not sure whether removing it in ieee80211_propagate_queue_wake will
> > have other odd side effects with software queuing. Maybe Michal
> > Kazior can tell us if it is safe to remove it.
> 
> No, it's the other way around.
> 
> Michal's patches correctly added a test for this to
> __ieee80211_stop_queue(), the only missing thing is that this test
> should also be in ieee80211_do_open() like this:
> 
> diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
> index 40813dd3301c..5bb0c5012819 100644
> --- a/net/mac80211/iface.c
> +++ b/net/mac80211/iface.c
> @@ -718,7 +718,8 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool 
> coming_up)
>   ieee80211_recalc_ps(local);
>  
>   if (sdata->vif.type == NL80211_IFTYPE_MONITOR ||
> - sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
> + sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
> + local->ops->wake_tx_queue) {
>   /* XXX: for AP_VLAN, actually track AP queues */
>   netif_tx_start_all_queues(dev);
>   } else if (dev) {

Yes, this also works.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [REGRESSION] mac80211: IBSS vif queue stopped when started after 11s vif

[Sven Eckelmann]

On Mittwoch, 29. März 2017 09:49:21 CEST Johannes Berg wrote:
> > But I could be completely wrong about it. It would therefore be
> > interesting for me to know who would be responsible to start the
> > queues when ieee80211_do_open rejected it for IBSS.
> 
> Well, once ieee80211_offchannel_return() is called, that should do the
> needful and end up in ieee80211_propagate_queue_wake().
> 
> Can you check what the IBSS vif's queues are (vif->hw_queue[...])?

I've just dumped the data in ieee80211_propagate_queue_wake and checked when 
the function returns. The test patch (sorry, really ugly debug printk stuff) 
is attached. The most interesting part is that

if (local->ops->wake_tx_queue)
return;

evaluates to true. The rest rest of the function is therefore always skipped 
for ath9k.

This was noticed when looking at the debug output:

root@lede:/# dmesg|grep ieee80211_propagate_queue_wake
[   20.865005] ieee80211_propagate_queue_wake:248 queue 
[   20.870839] ieee80211_propagate_queue_wake:248 queue 0001
[   20.876661] ieee80211_propagate_queue_wake:248 queue 0002
[   20.882487] ieee80211_propagate_queue_wake:248 queue 0003
[   21.794795] ieee80211_propagate_queue_wake:248 queue 
[   21.800629] ieee80211_propagate_queue_wake:248 queue 0001
[   21.806452] ieee80211_propagate_queue_wake:248 queue 0002
[   21.812278] ieee80211_propagate_queue_wake:248 queue 0003
[   21.830078] ieee80211_propagate_queue_wake:248 queue 
[   21.835918] ieee80211_propagate_queue_wake:248 queue 0001
[   21.841740] ieee80211_propagate_queue_wake:248 queue 0002
[   21.847566] ieee80211_propagate_queue_wake:248 queue 0003
[   23.320814] ieee80211_propagate_queue_wake:248 queue 
[   23.326643] ieee80211_propagate_queue_wake:248 queue 0001
[   23.332469] ieee80211_propagate_queue_wake:248 queue 0002
[   23.338294] ieee80211_propagate_queue_wake:248 queue 0003
[   41.930942] ieee80211_propagate_queue_wake:248 queue 
[   41.940709] ieee80211_propagate_queue_wake:248 queue 0002
[   46.949087] ieee80211_propagate_queue_wake:248 queue 
[   82.999021] ieee80211_propagate_queue_wake:248 queue 

Removing this is enough to fix the problem. And now you will propably say 
"hey, this is not my code". And this is the reason why I have now CC'ed the 
author of 80a83cfc434b ("mac80211: skip netdev queue control with software 
queuing"). This change in ieee80211_propagate_queue_wake is basically breaking 
the (delayed) startup of the ibss netdev queue [1] when the device was offchan 
during the ieee80211_do_open of the ibss interface.

Not sure whether removing it in ieee80211_propagate_queue_wake will have other 
odd side effects with software queuing. Maybe Michal Kazior can tell us if it 
is safe to remove it.

> However, I also don't understand the difference between encrypted and
> unencrypted here.

My best guess is timing. LEDE is not using wpa_supplicant when encryption is 
disabled.

Kind regards,
Sven

[1] https://lkml.kernel.org/r/1978424.XTv2Qph05K@bentoboxdiff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 036fa1d..9a1079f 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -517,6 +517,10 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
 	u32 changed = 0;
 	int res;
 	u32 hw_reconf_flags = 0;
+	const char *ifname = "unknown";
+
+	if (sdata->dev)
+		ifname = sdata->dev->name;
 
 	switch (sdata->vif.type) {
 	case NL80211_IFTYPE_WDS:
@@ -745,11 +749,14 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
 	if (sdata->vif.type == NL80211_IFTYPE_MONITOR ||
 	sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
 		/* XXX: for AP_VLAN, actually track AP queues */
+		
+		printk("%s:%u netif_tx_start_all_queues %s\n", __func__, __LINE__, ifname);
 		netif_tx_start_all_queues(dev);
 	} else if (dev) {
 		unsigned long flags;
 		int n_acs = IEEE80211_NUM_ACS;
 		int ac;
+		int started = 0;
 
 		if (local->hw.queues < IEEE80211_NUM_ACS)
 			n_acs = 1;
@@ -762,11 +769,20 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
 int ac_queue = sdata->vif.hw_queue[ac];
 
 if (local->queue_stop_reasons[ac_queue] == 0 &&
-skb_queue_empty(>pending[ac_queue]))
+skb_queue_empty(>pending[ac_queue])) {
+		//printk("%s:%u netif_start_subqueue type %u %s\n", __func__, __LINE__, sdata->vif.type, ifname);
 	netif_start_subqueue(dev, ac);
+	started = 1;
+} else {
+		printk("%s:%u NOT netif_start_subqueue type %u stop_reasons %d queue_empty %d %s\n", __func__, __LINE__, sdata->vif.type, local->queue_stop_reasons[ac_queue], skb_queue_empty(>pending[ac_queue]), ifname);
+}
 			}
+		} else {
+			printk("%s:%u NOT netif_start_subqueue type %u cab_queue %d stop_reasons %d queue_empty %d %s\n", __func__, __LINE__, sdata->vif.type,