Re: BCM4313 & brcmsmac & 3.12: only semi-working?

2014-11-23 Thread Arend van Spriel 
On 19-11-14 22:00, Michael Tokarev wrote:
> 19.11.2014 22:58, Michael Tokarev wrote:
>> 19.11.2014 20:54, Arend van Spriel wrote:
> []
>>> I submitted two patches upstream and additionally I have attached two other 
>>> that are still under review. Could you try these patches and sent me the 
>>> content of the two debugfs files 'macstat' and 'hardware' after a stall has 
>>> occurred.
>>
>> You didn't tell which kernel it is based on.  So I tried it on 3.16,
> 
> Ok, I misunderstood you apparently, -- I only tried 2 patches,
> while I should try all 4.  So here it goes.
> 
> The hardware info again:
> 
>> chipnum 0x4313
>> chiprev 0x1
>> chippackage 0x8
>> corerev 0x18
>> boardid 0x1795
>> boardvendor 0x103c
>> boardrev P107
>> boardflags 0x402201
>> boardflags2 0x884
>> ucoderev 0x262032c
>> radiorev 0x1
>> phytype 0x8
>> phyrev 0x1
>> anarev 0xa
>> nvramrev 8
> 
> Macstat:
> 
> txallfrm: 287
> txrtsfrm: 118
> txctsfrm: 25
> txackfrm: 60
> txdnlfrm: 0
> txbcnfrm: 0
> txfunfl[8]: 0 0 0 0 0 0 0 0
> txtplunfl: 0
> txphyerr: 0
> pktengrxducast: 0
> pktengrxdmcast: 0
> rxfrmtoolong: 330
> rxfrmtooshrt: 16
> rxinvmachdr: 722
> rxbadfcs: 4306
> rxbadplcp: 7257
> rxcrsglitch: 61757
> rxstrt: 6667
> rxdfrmucastmbss: 41
> rxmfrmucastmbss: 25
> rxcfrmucast: 116
> rxrtsucast: 0
> rxctsucast: 59
> rxackucast: 19
> rxdfrmocast: 70
> rxmfrmocast: 84
> rxcfrmocast: 211
> rxrtsocast: 3
> rxctsocast: 20
> rxdfrmmcast: 9
> rxmfrmmcast: 1486
> rxcfrmmcast: 0
> rxbeaconmbss: 377
> rxdfrmucastobss: 0
> rxbeaconobss: 1086
> rxrsptmout: 94
> bcntxcancl: 0
> rxf0ovfl: 0
> rxf1ovfl: 0
> rxf2ovfl: 0
> txsfovfl: 0
> pmqovfl: 0
> rxcgprqfrm: 0
> rxcgprsqovfl: 0
> txcgprsfail: 0
> txcgprssuc: 0
> prs_timeout: 0
> rxnack: 0
> frmscons: 0
> txnack: 0
> txglitch_nack: 38
> txburst: 4
> bphy_rxcrsglitch: 2
> phywatchdog: 0
> bphy_badplcp: 0
> 
> 
> As far as I can see, the stats are never updated during stall,
> no numbers are changing, at least while the download is waiting
> for the next packet.  Sometimes wpa_supplicant does something
> little, so some stats gets updated, eg, this is how it looks like
> after about 2..3 minutes:
> 
> txallfrm: 420
> txrtsfrm: 201
> txctsfrm: 25
> txackfrm: 69
> txdnlfrm: 0
> txbcnfrm: 0
> txfunfl[8]: 0 0 0 0 0 0 0 0
> txtplunfl: 0
> txphyerr: 0
> pktengrxducast: 0
> pktengrxdmcast: 0
> rxfrmtoolong: 1908
> rxfrmtooshrt: 73
> rxinvmachdr: 4115
> rxbadfcs: 15064
> rxbadplcp: 42368
> rxcrsglitch: 36620
> rxstrt: 26393
> rxdfrmucastmbss: 48
> rxmfrmucastmbss: 27
> rxcfrmucast: 158
> rxrtsucast: 0
> rxctsucast: 92
> rxackucast: 25
> rxdfrmocast: 113
> rxmfrmocast: 390
> rxcfrmocast: 962
> rxrtsocast: 38
> rxctsocast: 59
> rxdfrmmcast: 48
> rxmfrmmcast: 7681
> rxcfrmmcast: 0
> rxbeaconmbss: 1505
> rxdfrmucastobss: 0
> rxbeaconobss: 6059
> rxrsptmout: 171
> bcntxcancl: 0
> rxf0ovfl: 0
> rxf1ovfl: 0
> rxf2ovfl: 0
> txsfovfl: 0
> pmqovfl: 0
> rxcgprqfrm: 0
> rxcgprsqovfl: 0
> txcgprsfail: 0
> txcgprssuc: 0
> prs_timeout: 0
> rxnack: 0
> frmscons: 0
> txnack: 0
> txglitch_nack: 41
> txburst: 4
> bphy_rxcrsglitch: 5
> phywatchdog: 0
> bphy_badplcp: 0
> 
> 
> This is with 3.18-tobe kernel (current Linus git).
> 
> Dunno if this is helpful or not...

Well, it shows tx looks ok, but with download there is not much of that
going on. At least no large packets. However, I did find some missing
pieces related to bt-coex. Given that you device is a wifi-bt combo card
that is likely an issue for you. One of the missing pieces looks in
sprom for parameters and that is provided by bcma. However, it does not
seem to extract bt-coex related stuff. So I have attached a patch based
on 3.18-rc5 for bcma that dumps the sprom contents. Could you sent that
content to me.

Regards,
Arend

> Thanks,
> 
> /mjt
> 

>From 29cfa8ec164e2d742f98ddb2c5368b70540f5fab Mon Sep 17 00:00:00 2001
From: Arend van Spriel 
Date: Sun, 23 Nov 2014 10:26:17 +0100
Subject: [PATCH] bcma: dump raw sprom content for debugging

Signed-off-by: Arend van Spriel 
---
 drivers/bcma/sprom.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/bcma/sprom.c b/drivers/bcma/sprom.c
index efb037f..0c246a4 100644
--- a/drivers/bcma/sprom.c
+++ b/drivers/bcma/sprom.c
@@ -129,10 +129,16 @@ static u8 bcma_sprom_crc(const u16 *sprom, size_t words)
 	int word;
 	u8 crc = 0xFF;
 
+	pr_debug(KBUILD_MODNAME "sprom:");
 	for (word = 0; word < words - 1; word++) {
+		if ((word % 10) == 0)
+			pr_debug("\n\t");
+		pr_debug("%04X ", sprom[word]);
 		crc = bcma_crc8(crc, sprom[word] & 0x00FF);
 		crc = bcma_crc8(crc, (sprom[word] & 0xFF00) >> 8);
 	}
+	if ((word % 10) == 0)
+		pr_debug("\n");
 	crc = bcma_crc8(crc, sprom[words - 1] & 0x00FF);
 	crc ^= 0xFF;
 
-- 
1.9.1

Re: [PATCH v3] ath3k: Add support of MCI 13d3:3408 bt device

2014-11-23 Thread Dmitry Tunin 

After some testing on a few laptops it looks like the firmware loads always
correctly only using AR3012 variant.

So the correct patch follows

---

diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index d85ced2..086240c 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -105,6 +105,7 @@ static const struct usb_device_id ath3k_table[] = {
 { USB_DEVICE(0x13d3, 0x3375) },
 { USB_DEVICE(0x13d3, 0x3393) },
 { USB_DEVICE(0x13d3, 0x3402) },
+{ USB_DEVICE(0x13d3, 0x3408) },
 { USB_DEVICE(0x13d3, 0x3432) },

 /* Atheros AR5BBU12 with sflash firmware */
@@ -156,6 +157,7 @@ static const struct usb_device_id ath3k_blist_tbl[] = {
 { USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
 { USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
 { USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },
+{ USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 },
 { USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 },

 /* Atheros AR5BBU22 with sflash firmware */
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index edfc17b..091c813 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -182,6 +182,7 @@ static const struct usb_device_id blacklist_table[] = {
 { USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
 { USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
 { USB_DEVICE(0x13d3, 0x3402), .driver_info = BTUSB_ATH3012 },
+{ USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 },
 { USB_DEVICE(0x13d3, 0x3432), .driver_info = BTUSB_ATH3012 },

 /* Atheros AR5BBU12 with sflash firmware */

--

19.11.2014 13:06, Dmitry Tunin wrote:

It seems that I am too stupid.
It is neither AR3012 or AR3011 device.
It is AR9565 with sflash.
Probably it makes sense to do a separate section for these devices.

But still
{ USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_IGNORE },
works better than

{ USB_DEVICE(0x13d3, 0x3408), .driver_info = BTUSB_ATH3012 },

With the latter I have some issues with turning bt on and off.

19.11.2014 12:40, Michel Memeteau - EKIMIA wrote:

Hi,

I tried to understand why this "0x13d3, 0x3408" device support
wouldn't go in btusb as it's really close to IMC BT chip found in
Realtek Wifi devices which is on the path to go in btusb [1]

then I guess there is a lot of code that could be shared to support
all IMC usb devices in the btusb module.

Regards.

[1] https://github.com/lwfinger/rtl8723au_bt/tree/new

<-->
  Michel Memeteau  - Directeur.

  Notre Boutique Ordinateurs GNU/Linux : http://shop.ekimia.fr
  49 chemin de l'union 13720 La Bouilladisse - France.
  Fixe :  +33 (0) 972308334   Mobile : +33(0) 624808051
<-->

  2014-11-19 7:46 GMT+01:00 Dmitry Tunin :

Hi Marcel,

Here is information from /sys/kernel/debug/usb/devices

T:  Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 20 Spd=12 MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P:  Vendor=13d3 ProdID=3408 Rev= 0.02
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms


I hope this mail client is OK now.

Add support for bluetooth MCI WB335 (AR9565) Wi-Fi+bt module.
It is AR3011 device according to iProduct == 0.
So btusb should be blacklisted
I submitted a wrong patch before asif  it was an AR3012 device,
but it works both ways. This is the right one.

Signed-off-by: Dmitry Tunin

---

diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index d85ced2..3b53116 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -69,6 +69,7 @

[PATCH v3 1/3] cfg80211: leave invalid channels on regdomain change

2014-11-23 Thread Arik Nemtsov 
When the regulatory settings change, some channels might become invalid.
Disconnect interfaces acting on these channels, after giving userspace
code a grace period to leave them.

This mode is currently opt-in, and not all interface operating modes are
supported for regulatory-enforcement checks. A wiphy that wishes to use
the new enforcement code must specify an appropriate regulatory flag,
and all its supported interface modes must be supported by the chekcing
code.

Signed-off-by: Arik Nemtsov 
---
 include/net/regulatory.h |   6 +++
 net/wireless/core.c  |  13 ++
 net/wireless/reg.c   | 106 ++-
 3 files changed, 124 insertions(+), 1 deletion(-)

diff --git a/include/net/regulatory.h b/include/net/regulatory.h
index dad7ab2..701177c 100644
--- a/include/net/regulatory.h
+++ b/include/net/regulatory.h
@@ -136,6 +136,11 @@ struct regulatory_request {
  *  otherwise initiating radiation is not allowed. This will enable the
  *  relaxations enabled under the CFG80211_REG_RELAX_NO_IR configuration
  *  option
+ * @REGULATORY_ENFORCE_CHANNELS: the regulatory core will make sure all
+ * interfaces on this wiphy reside on allowed channels. Upon a regdomain
+ * change, the interfaces are given a grace period to disconnect or move
+ * to an allowed channels. Interfaces on forbidden channels are forcibly
+ * disconnected.
  */
 enum ieee80211_regulatory_flags {
REGULATORY_CUSTOM_REG   = BIT(0),
@@ -144,6 +149,7 @@ enum ieee80211_regulatory_flags {
REGULATORY_COUNTRY_IE_FOLLOW_POWER  = BIT(3),
REGULATORY_COUNTRY_IE_IGNORE= BIT(4),
REGULATORY_ENABLE_RELAX_NO_IR   = BIT(5),
+   REGULATORY_ENFORCE_CHANNELS = BIT(6),
 };
 
 struct ieee80211_freq_range {
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 4c2e501..5295456 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -546,6 +546,19 @@ int wiphy_register(struct wiphy *wiphy)
 !rdev->ops->tdls_cancel_channel_switch)))
return -EINVAL;
 
+   /*
+* a wiphy that wishes to enable channel enforcement must have only
+* modes where enforcement is supported.
+*/
+   if (WARN_ON((wiphy->regulatory_flags & REGULATORY_ENFORCE_CHANNELS) &&
+   (wiphy->interface_modes & ~(BIT(NL80211_IFTYPE_STATION) |
+BIT(NL80211_IFTYPE_P2P_CLIENT) | BIT(NL80211_IFTYPE_AP) |
+BIT(NL80211_IFTYPE_P2P_GO) | BIT(NL80211_IFTYPE_ADHOC) |
+BIT(NL80211_IFTYPE_P2P_DEVICE) |
+BIT(NL80211_IFTYPE_AP_VLAN) |
+BIT(NL80211_IFTYPE_MONITOR)
+   return -EINVAL;
+
if (WARN_ON(wiphy->coalesce &&
(!wiphy->coalesce->n_rules ||
 !wiphy->coalesce->n_patterns) &&
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 32d8310..922d00a 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -56,6 +56,7 @@
 #include 
 #include "core.h"
 #include "reg.h"
+#include "rdev-ops.h"
 #include "regdb.h"
 #include "nl80211.h"
 
@@ -66,6 +67,12 @@
 #define REG_DBG_PRINT(args...)
 #endif
 
+/*
+ * Grace period we give before making sure all current interfaces reside on
+ * channels allowed by the current regulatory domain.
+ */
+#define REG_ENFORCE_GRACE_MS 6
+
 /**
  * enum reg_request_treatment - regulatory request treatment
  *
@@ -210,6 +217,9 @@ struct reg_beacon {
struct ieee80211_channel chan;
 };
 
+static void reg_check_chans_work(struct work_struct *work);
+static DECLARE_DELAYED_WORK(reg_check_chans, reg_check_chans_work);
+
 static void reg_todo(struct work_struct *work);
 static DECLARE_WORK(reg_work, reg_todo);
 
@@ -1518,6 +1528,95 @@ static void reg_call_notifier(struct wiphy *wiphy,
wiphy->reg_notifier(wiphy, request);
 }
 
+static bool reg_wdev_chan_valid(struct wiphy *wiphy, struct wireless_dev *wdev)
+{
+   struct ieee80211_channel *ch;
+   struct cfg80211_chan_def chandef;
+   struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy);
+   bool ret = true;
+
+   wdev_lock(wdev);
+
+   if (!wdev->netdev || !netif_running(wdev->netdev))
+   goto out;
+
+   switch (wdev->iftype) {
+   case NL80211_IFTYPE_AP:
+   case NL80211_IFTYPE_P2P_GO:
+   if (!wdev->beacon_interval)
+   goto out;
+
+   ret = cfg80211_reg_can_beacon(wiphy,
+ &wdev->chandef, wdev->iftype);
+   break;
+   case NL80211_IFTYPE_STATION:
+   case NL80211_IFTYPE_P2P_CLIENT:
+   case NL80211_IFTYPE_ADHOC:
+   if (!wdev->current_bss ||
+   !wdev->current_bss->pub.channel)
+   goto out;
+
+   ch = wdev->current_bss->pub.channel;
+   if (rdev->ops->get_channe

[PATCH v3 2/3] cfg80211: allow wiphy specific regdomain management

2014-11-23 Thread Arik Nemtsov 
From: Jonathan Doron 

Add a new regulatory flag that allows a driver to manage regdomain
changes/updates for its own wiphy.
A self-managed wiphys only employs regulatory information obtained from
the FW and driver and does not use other cfg80211 sources like
beacon-hints, country-code IEs and hints from other devices on the same
system. Conversely, a self-managed wiphy does not share its regulatory
hints with other devices in the system. If a system contains several
devices, one or more of which are self-managed, there might be
contradictory regulatory settings between them. Usage of flag is
generally discouraged. Only use it if the FW/driver is incompatible
with non-locally originated hints.

A new API lets the driver send a complete regdomain, to be applied on
its wiphy only.

After a wiphy-specific regdomain change takes place, usermode will get
a new type of change notification. The regulatory core also takes care
enforce regulatory restrictions, in case some interfaces are on
forbidden channels.

Signed-off-by: Jonathan Doron 
Signed-off-by: Arik Nemtsov 
---
 include/net/cfg80211.h   | 16 +
 include/net/regulatory.h | 19 +++
 include/uapi/linux/nl80211.h |  5 +++
 net/wireless/core.c  |  8 +
 net/wireless/nl80211.c   | 80 ++--
 net/wireless/nl80211.h   |  1 +
 net/wireless/reg.c   | 59 
 7 files changed, 170 insertions(+), 18 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index bb748c4..bfe630f 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3808,6 +3808,22 @@ const u8 *cfg80211_find_vendor_ie(unsigned int oui, u8 
oui_type,
 int regulatory_hint(struct wiphy *wiphy, const char *alpha2);
 
 /**
+ * regulatory_set_wiphy_regd_rtnl - set regdom info for self managed drivers
+ * @wiphy: the wireless device we want to process the regulatory domain on
+ * @rd: the regulatory domain informatoin to use for this wiphy
+ *
+ * Set the regulatory domain information for self-managed wiphys, only they
+ * may use this function. See %REGULATORY_WIPHY_SELF_MANAGED for more
+ * information.
+ *
+ * This function requires the caller to hold the rtnl_lock.
+ *
+ * Return: 0 on success. -EINVAL, -EPERM
+ */
+int regulatory_set_wiphy_regd_rtnl(struct wiphy *wiphy,
+  struct ieee80211_regdomain *rd);
+
+/**
  * wiphy_apply_custom_regulatory - apply a custom driver regulatory domain
  * @wiphy: the wireless device we want to process the regulatory domain on
  * @regd: the custom regulatory domain to use for this wiphy
diff --git a/include/net/regulatory.h b/include/net/regulatory.h
index 701177c..d69c3db 100644
--- a/include/net/regulatory.h
+++ b/include/net/regulatory.h
@@ -141,6 +141,24 @@ struct regulatory_request {
  * change, the interfaces are given a grace period to disconnect or move
  * to an allowed channels. Interfaces on forbidden channels are forcibly
  * disconnected.
+ * @REGULATORY_WIPHY_SELF_MANAGED: for devices that employ wiphy-specific
+ * regdom management. These devices will ignore all regdom changes not
+ * originating from their own wiphy.
+ * A self-managed wiphys only employs regulatory information obtained from
+ * the FW and driver and does not use other cfg80211 sources like
+ * beacon-hints, country-code IEs and hints from other devices on the same
+ * system. Conversely, a self-managed wiphy does not share its regulatory
+ * hints with other devices in the system. If a system contains several
+ * devices, one or more of which are self-managed, there might be
+ * contradictory regulatory settings between them. Usage of flag is
+ * generally discouraged. Only use it if the FW/driver is incompatible
+ * with non-locally originated hints.
+ * This flag is incompatible with the flags: %REGULATORY_CUSTOM_REG,
+ * %REGULATORY_STRICT_REG, %REGULATORY_COUNTRY_IE_FOLLOW_POWER,
+ * %REGULATORY_COUNTRY_IE_IGNORE and %REGULATORY_DISABLE_BEACON_HINTS.
+ * Mixing any of the above flags with this flag will result in a failure
+ * to register the wiphy. This flag implies
+ * %REGULATORY_DISABLE_BEACON_HINTS.
  */
 enum ieee80211_regulatory_flags {
REGULATORY_CUSTOM_REG   = BIT(0),
@@ -150,6 +168,7 @@ enum ieee80211_regulatory_flags {
REGULATORY_COUNTRY_IE_IGNORE= BIT(4),
REGULATORY_ENABLE_RELAX_NO_IR   = BIT(5),
REGULATORY_ENFORCE_CHANNELS = BIT(6),
+   REGULATORY_WIPHY_SELF_MANAGED   = BIT(7),
 };
 
 struct ieee80211_freq_range {
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index d775245..3771e7d 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -774,6 +774,9 @@
  * peer given by %NL80211_ATTR_MAC. Both peers must be on the base channel
  * when this command completes.

[PATCH v3 3/3] cfg80211: Allow usermode to query wiphy specific regd info

2014-11-23 Thread Arik Nemtsov 
From: Jonathan Doron 

Allow usermode to query wiphy-specific regd info, for drivers that use
wiphy-specific regulatory management.

Use the existing API for sending regdomain info to usermode, but return
the wiphy-specific regd in case wiphy index is provided and the driver
employs wiphy-specific management. This implies user and kernel-mode
support for the feature and is backward compatible.

Signed-off-by: Jonathan Doron 
Signed-off-by: Arik Nemtsov 
---
 include/uapi/linux/nl80211.h | 18 ++-
 net/wireless/nl80211.c   | 71 
 net/wireless/reg.c   |  2 +-
 net/wireless/reg.h   |  1 +
 4 files changed, 78 insertions(+), 14 deletions(-)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 3771e7d..b222e5c 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -252,7 +252,12 @@
  * %NL80211_ATTR_IFINDEX.
  *
  * @NL80211_CMD_GET_REG: ask the wireless core to send us its currently set
- * regulatory domain.
+ * regulatory domain. If %NL80211_ATTR_WIPHY is specified and the device
+ * self-manages its regulatory settings, its private regulatory domain
+ * will be returned.
+ * If %NL80211_ATTR_WIPHY_GET_PRIV_REG is specified in addition to
+ * %NL80211_ATTR_WIPHY, a device's private regulatory domain will be
+ * returned, even if it's regulatory is not self-managed.
  * @NL80211_CMD_SET_REG: Set current regulatory domain. CRDA sends this command
  * after being queried by the kernel. CRDA replies by sending a regulatory
  * domain structure which consists of %NL80211_ATTR_REG_ALPHA set to our
@@ -1693,6 +1698,14 @@ enum nl80211_commands {
  *
  * @NL80211_ATTR_MAC_MASK: MAC address mask
  *
+ * @NL80211_ATTR_WIPHY_SELF_MANAGED_REG: flag attribute indicating the
+ * regulatory information was obtained from the private regdomain
+ * of a device with self-managed regulatory.
+ * @NL80211_ATTR_WIPHY_GET_PRIV_REG: flag attribute indicating the regulatory
+ * information should be obtained from a device's private regdomain,
+ * if it exists. This will happen even if the device is not self-managing
+ * its regulatory.
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2050,6 +2063,9 @@ enum nl80211_attrs {
 
NL80211_ATTR_MAC_MASK,
 
+   NL80211_ATTR_WIPHY_SELF_MANAGED_REG,
+   NL80211_ATTR_WIPHY_GET_PRIV_REG,
+
/* add attributes here, update the policy in nl80211.c */
 
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index de3a47a..42ccca7 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -396,6 +396,8 @@ static const struct nla_policy 
nl80211_policy[NUM_NL80211_ATTR] = {
[NL80211_ATTR_ADMITTED_TIME] = { .type = NLA_U16 },
[NL80211_ATTR_SMPS_MODE] = { .type = NLA_U8 },
[NL80211_ATTR_MAC_MASK] = { .len = ETH_ALEN },
+   [NL80211_ATTR_WIPHY_SELF_MANAGED_REG] = { .type = NLA_FLAG },
+   [NL80211_ATTR_WIPHY_GET_PRIV_REG] = { .type = NLA_FLAG },
 };
 
 /* policy for the key attributes */
@@ -5328,15 +5330,12 @@ static int nl80211_update_mesh_config(struct sk_buff 
*skb,
 
 static int nl80211_get_reg(struct sk_buff *skb, struct genl_info *info)
 {
-   const struct ieee80211_regdomain *regdom;
+   const struct ieee80211_regdomain *regdom = NULL;
struct sk_buff *msg;
void *hdr = NULL;
struct nlattr *nl_reg_rules;
unsigned int i;
 
-   if (!cfg80211_regdomain)
-   return -EINVAL;
-
msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
if (!msg)
return -ENOBUFS;
@@ -5346,13 +5345,54 @@ static int nl80211_get_reg(struct sk_buff *skb, struct 
genl_info *info)
if (!hdr)
goto put_failure;
 
-   if (reg_last_request_cell_base() &&
-   nla_put_u32(msg, NL80211_ATTR_USER_REG_HINT_TYPE,
-   NL80211_USER_REG_HINT_CELL_BASE))
-   goto nla_put_failure;
+   if (info->attrs[NL80211_ATTR_WIPHY]) {
+   u32 reg_flags;
+   struct wiphy *wiphy;
+   struct cfg80211_registered_device *rdev =
+   cfg80211_get_dev_from_info(genl_info_net(info), info);
+
+   if (IS_ERR(rdev)) {
+   nlmsg_free(msg);
+   return PTR_ERR(rdev);
+   }
+
+   wiphy = &rdev->wiphy;
+   reg_flags = wiphy->regulatory_flags;
+   if (reg_flags & REGULATORY_WIPHY_SELF_MANAGED ||
+   info->attrs[NL80211_ATTR_WIPHY_GET_PRIV_REG]) {
+   regdom = get_wiphy_regdom(wiphy);
+   if (!regdom) {
+   nlmsg_free(msg);
+   return -EINVAL;
+

pull request: iwlwifi 2014-11-23

2014-11-23 Thread Emmanuel Grumbach 
Hi John,

I have a trivial patch for 3.18. details below.
Thanks!

The following changes since commit 87dd634ae72bb8f6d0dd12f1cbbc67c7da6dba3b:

  iwlwifi: pcie: fix prph dump length (2014-11-11 07:24:57 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-john-2014-11-23

for you to fetch changes up to 5ac6c72e594471acfa5b00210c51d533a73413ad:

  iwlwifi: mvm: check TLV flag before trying to use hotspot firmware commands 
(2014-11-23 21:50:57 +0200)


Not all the firmware know how to handle the HOT_SPOT_CMD.
Make sure that the firmware will know this command before
sending it. This avoids a firmware crash.


Luciano Coelho (1):
  iwlwifi: mvm: check TLV flag before trying to use hotspot firmware 
commands

 drivers/net/wireless/iwlwifi/iwl-fw.h   |  2 ++
 drivers/net/wireless/iwlwifi/mvm/mac80211.c | 12 +---
 2 files changed, 11 insertions(+), 3 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] iwlwifi: mvm: check TLV flag before trying to use hotspot firmware commands

2014-11-23 Thread Emmanuel Grumbach 
From: Luciano Coelho 

Older firmwares do not provide support for the HOT_SPOT_CMD command.
Check for the appropriate TLV flag that declares hotspot support in
the firmware to prevent a firmware assertion failure that can be
triggered from the userspace,

Cc: sta...@vger.kernel.org [3.17+]
Signed-off-by: Luciano Coelho 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/iwlwifi/iwl-fw.h   |  2 ++
 drivers/net/wireless/iwlwifi/mvm/mac80211.c | 12 +---
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-fw.h 
b/drivers/net/wireless/iwlwifi/iwl-fw.h
index 4f6e668..b894a84 100644
--- a/drivers/net/wireless/iwlwifi/iwl-fw.h
+++ b/drivers/net/wireless/iwlwifi/iwl-fw.h
@@ -155,6 +155,7 @@ enum iwl_ucode_tlv_api {
  * @IWL_UCODE_TLV_CAPA_QUIET_PERIOD_SUPPORT: supports Quiet Period requests
  * @IWL_UCODE_TLV_CAPA_DQA_SUPPORT: supports dynamic queue allocation (DQA),
  * which also implies support for the scheduler configuration command
+ * @IWL_UCODE_TLV_CAPA_HOTSPOT_SUPPORT: supports Hot Spot Command
  */
 enum iwl_ucode_tlv_capa {
IWL_UCODE_TLV_CAPA_D0I3_SUPPORT = BIT(0),
@@ -163,6 +164,7 @@ enum iwl_ucode_tlv_capa {
IWL_UCODE_TLV_CAPA_WFA_TPC_REP_IE_SUPPORT   = BIT(10),
IWL_UCODE_TLV_CAPA_QUIET_PERIOD_SUPPORT = BIT(11),
IWL_UCODE_TLV_CAPA_DQA_SUPPORT  = BIT(12),
+   IWL_UCODE_TLV_CAPA_HOTSPOT_SUPPORT  = BIT(18),
 };
 
 /* The default calibrate table size if not specified by firmware file */
diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c 
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index b624058..b6d2683 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -2448,9 +2448,15 @@ static int iwl_mvm_roc(struct ieee80211_hw *hw,
 
switch (vif->type) {
case NL80211_IFTYPE_STATION:
-   /* Use aux roc framework (HS20) */
-   ret = iwl_mvm_send_aux_roc_cmd(mvm, channel,
-  vif, duration);
+   if (mvm->fw->ucode_capa.capa[0] &
+   IWL_UCODE_TLV_CAPA_HOTSPOT_SUPPORT) {
+   /* Use aux roc framework (HS20) */
+   ret = iwl_mvm_send_aux_roc_cmd(mvm, channel,
+  vif, duration);
+   goto out_unlock;
+   }
+   IWL_ERR(mvm, "hotspot not supported\n");
+   ret = -EINVAL;
goto out_unlock;
case NL80211_IFTYPE_P2P_DEVICE:
/* handle below */
-- 
1.9.1

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

pull request: firmware updates for Intel Wireless devices 3160/7260/7265

2014-11-23 Thread Emmanuel Grumbach 
Hello,

Intel officially released a new spin of the -9 version of the firmware for 
devices 3160, 7260 and 7265.
This release had been announced a while ago, but the linux-firmware.git's 
maintainers didn't pick it up.
This is a new pull request with almost the exact same -9 version - it has one 
more bug fix.
Version: 25.228.9.0.

We also release new version (-10) of the firmware for the same devices. This 
firmware includes new features
such as TDLS, Channel switch and others.
Version: 23.10.10.0.

Please pull...

The following changes since commit 0e5f63771d0df6d7859f7c4100a74d737c62ac88:

  linux-firmware: Add firmware patch for Intel Bluetooth 7265 ROM-spin(D0) 
(2014-10-09 11:59:44 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/egrumbach/linux-firmware.git 
master

for you to fetch changes up to 064309720ed861dde985c39cdc1a34e7bcf93cc9:

  iwlwifi: add new firmware for 3160 / 7260 / 7265 / 7265D (2014-11-21 11:11:06 
+0200)


Emmanuel Grumbach (2):
  iwlwifi: update firmware for 3160 / 7260 / 7265
  iwlwifi: add new firmware for 3160 / 7260 / 7265 / 7265D

 WHENCE |  18 +++---
 iwlwifi-3160-10.ucode  | Bin 0 -> 610168 bytes
 iwlwifi-3160-9.ucode   | Bin 669156 -> 669872 bytes
 iwlwifi-7260-10.ucode  | Bin 0 -> 672480 bytes
 iwlwifi-7260-9.ucode   | Bin 681464 -> 680508 bytes
 iwlwifi-7265-10.ucode  | Bin 0 -> 736968 bytes
 iwlwifi-7265-9.ucode   | Bin 697012 -> 697828 bytes
 iwlwifi-7265D-10.ucode | Bin 0 -> 740636 bytes
 8 files changed, 15 insertions(+), 3 deletions(-)
 create mode 100644 iwlwifi-3160-10.ucode
 create mode 100644 iwlwifi-7260-10.ucode
 create mode 100644 iwlwifi-7265-10.ucode
 create mode 100644 iwlwifi-7265D-10.ucode

diff --git a/WHENCE b/WHENCE
index b77516d..a4bf645 100644
--- a/WHENCE
+++ b/WHENCE
@@ -813,7 +813,10 @@ File: iwlwifi-7260-8.ucode
 Version: 22.24.8.0
 
 File: iwlwifi-7260-9.ucode
-Version: 25.222.9.0
+Version: 25.228.9.0
+
+File: iwlwifi-7260-10.ucode
+Version: 23.10.10.0
 
 File: iwlwifi-3160-7.ucode
 Version: 22.1.7.0
@@ -822,13 +825,22 @@ File: iwlwifi-3160-8.ucode
 Version: 22.24.8.0
 
 File: iwlwifi-3160-9.ucode
-Version: 25.222.9.0
+Version: 25.228.9.0
+
+File: iwlwifi-3160-10.ucode
+Version: 23.10.10.0
 
 File: iwlwifi-7265-8.ucode
 Version: 22.24.8.0
 
 File: iwlwifi-7265-9.ucode
-Version: 25.222.9.0
+Version: 25.228.9.0
+
+File: iwlwifi-7265-10.ucode
+Version: 23.10.10.0
+
+File: iwlwifi-7265D-10.ucode
+Version: 23.10.10.0
 
 Licence: Redistributable. See LICENCE.iwlwifi_firmware for details
 
diff --git a/iwlwifi-3160-10.ucode b/iwlwifi-3160-10.ucode
new file mode 100644
index 000..8cec7bf
Binary files /dev/null and b/iwlwifi-3160-10.ucode differ
diff --git a/iwlwifi-3160-9.ucode b/iwlwifi-3160-9.ucode
index 638c7fa..287a3a5 100644
Binary files a/iwlwifi-3160-9.ucode and b/iwlwifi-3160-9.ucode differ
diff --git a/iwlwifi-7260-10.ucode b/iwlwifi-7260-10.ucode
new file mode 100644
index 000..9e5b930
Binary files /dev/null and b/iwlwifi-7260-10.ucode differ
diff --git a/iwlwifi-7260-9.ucode b/iwlwifi-7260-9.ucode
index 3175322..b271e86 100644
Binary files a/iwlwifi-7260-9.ucode and b/iwlwifi-7260-9.ucode differ
diff --git a/iwlwifi-7265-10.ucode b/iwlwifi-7265-10.ucode
new file mode 100644
index 000..488ddd0
Binary files /dev/null and b/iwlwifi-7265-10.ucode differ
diff --git a/iwlwifi-7265-9.ucode b/iwlwifi-7265-9.ucode
index 1767a33..bbca2fe 100644
Binary files a/iwlwifi-7265-9.ucode and b/iwlwifi-7265-9.ucode differ
diff --git a/iwlwifi-7265D-10.ucode b/iwlwifi-7265D-10.ucode
new file mode 100644
index 000..01194db
Binary files /dev/null and b/iwlwifi-7265D-10.ucode differ



signature.asc
Description: OpenPGP digital signature

RE: wireless-regdb: Update regulatory rules for New Zealand (NZ) on 5GHz and 60 GHz [UNCLASSIFIED]

2014-11-23 Thread Peter Gent 
Hi,

John - thank you for the suggested patch. 

We have a couple of queries and comments on what is proposed so far for the 
list. 
1) Our top 2 GHz in the 60 GHz band "64000 - 66000 MHz" is indoor only and 
comments are edited as such
2) Is it possible to define an indoor / outdoor limit inside the processing 
rules? I guess sensing this might prove problematic but could anyone advise on 
what other countries do?
3) As our limits are in EIRP, suggest to modify the patch to match the EIRP 
formatting in the processing rules
4) Can Transmitter power control be added to the patch, if so how is it 
enabled? 
5) Finally can someone confirm to me the use of AUTO-BW as I can't find any 
direct reference to it in the processing rules? 

There is still a little more work on this, but this is our next iteration of 
the New Zealand patch


+# 5150 MHz  - 5250 MHz  80MHz channels, indoor use only at -7.0 dBW 
+EIRP TPC enabled # 5250 MHz -  5350 MHz  80 MHz channels, indoor use at 
+-7.0 dBW EIRP, outdoor use at 0 dBW EIRP with DFS and TPC enabled* # 
+5470 MHz  - 5725 MHz  80 MHz channels, 0 dBW EIRP with DFS and TPC 
+enabled* # 5725 MHz  - 5875 MHz  80 MHz channels, 6.0 dBW EIRP 
+# 57000 MHz - 64000 MHz, at 13.0 dBW EIRP # 64000 - 66000 MHz, 
+indoor use only at 13.0 dBW EIRP # *if TPC is not enabled, than transmit power 
must be 
+reduced by 3dB # 
+http://www.rsm.govt.nz/cms/licensees/types-of-licence/general-user-licences/short-range-devices



country NZ: DFS-FCC
(2402 - 2482 @ 40), (30)
-   (5170 - 5250 @ 80), (17), AUTO-BW
-   (5250 - 5330 @ 80), (24), DFS, AUTO-BW
-   (5490 - 5730 @ 160), (24), DFS
-   (5735 - 5835 @ 80), (30)
+   (5150 - 5250 @ 80), (N/A,23), AUTO-BW
+   (5250 - 5350 @ 80), (N/A, 23), DFS, AUTO-BW
+   (5470 - 5725 @ 160), (N/A, 30), DFS
+   (5725 - 5875 @ 80), (N/A, 36)
+   (57000 - 64000 @ 2160), (N/A, 43)



-Original Message-
From: John W. Linville [mailto:linvi...@tuxdriver.com] 
Sent: Saturday, 8 November 2014 10:21 a.m.
To: Peter Gent
Cc: wireless-re...@lists.infradead.org; linux-wireless@vger.kernel.org
Subject: Re: wireless-regdb: Update regulatory rules for New Zealand (NZ) on 
5GHz and 60 GHz [UNCLASSIFIED]

On Tue, Oct 28, 2014 at 01:04:10AM +, Peter Gent wrote:
> Hi,
> 
> We wish to note the following changes should be made to the wireless 
> regulatory database to reflect some recent changes to the 60 GHz band here in 
> New Zealand. In additional there are some inaccuracies when compared to our 
> current licencing for the 5 GHz "Wi-Fi" band.
> 
> The updated entry for New Zealand should read:
> 
> 5150 MHz  - 5250 MHz  80MHz channels, indoor use only at -7.0 dBW EIRP 
> TPC enabled
> 5250 MHz -  5350 MHz  80 MHz channels, indoor use at -7.0 dBW EIRP, 
> outdoor use at 0 dBW EIRP with DFS and TPC enabled*
> 5470 MHz  - 5725 MHz  80 MHz channels, 0 dBW EIRP with DFS and TPC 
> enabled*
> 5725 MHz  - 5875 MHz  80 MHz channels, 6.0 dBW EIRP with frequency 
> hopping enabled
> 57000 MHz - 66000 MHz, indoor use only at 13.0 dBW EIRP
> 
> *if TPC is not enabled, than transmit power must be reduced by 3dB
> 
> Further information on SRD licencing rules can be found at 
> http://www.rsm.govt.nz/cms/licensees/types-of-licence/general-user-lic
> ences/short-range-devices
> 
> Regards
> 
> Peter

Peter,

Thanks for making us aware of this info.  I'm sorry that there has been no 
other response so far.

Changes to our regulatory rules database are typically proposed in the form of 
a patch.  This promotes specificity in making such changes.
I suspect that you are unfamiliar with this form of change proposal, so I have 
taken a first whack at it.

While I maintain the database, I am not as radio proficient as I perhaps should 
be.  I normally leave writing such patches for others, and wait for some level 
of agreement to be reached before applying changes.  In this case, it is quite 
likely that I have overlooked something or misinterpreted (or simply 
misunderstood) your change suggestions.

I hope that you and others will take a moment to comment and/or suggest further 
changes to my proposed changes below.  Without some affirmative commentary I 
will not apply any derivative of the changes specified below.

Thanks!

John

diff --git a/db.txt b/db.txt
index 6cf86e15627b..3b9db42309dc 100644
--- a/db.txt
+++ b/db.txt
@@ -848,12 +848,20 @@ country NP: DFS-JP
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5735 - 5835 @ 80), (20)
 
+# 5150 MHz  - 5250 MHz  80MHz channels, indoor use only at -7.0 dBW 
+EIRP TPC enabled # 5250 MHz -  5350 MHz  80 MHz channels, indoor use at 
+-7.0 dBW EIRP, outdoor use at 0 dBW EIRP with DFS and TPC enabled* # 
+5470 MHz  - 5725 MHz  80 MHz channels, 0 dBW EIRP with DFS and TPC 
+enabled* # 5725 MHz  - 5875 MHz  80 MHz channels, 6.0 dBW EIRP with 
+frequency hopping enabled # 57000 MHz - 66000 MHz, indoor use only at 
+13.0 dBW EIRP # *if TPC is not enabled, than transmit power must be 
+reduc

[PATCH 1/3] ath10k: Fix shared WEP

2014-11-23 Thread Sujith Manoharan 
From: Sujith Manoharan 

When static keys are used in shared WEP, when a
station is associated, message 3 is sent with an
encrypted payload. But, for subsequent
authentications that are triggered without a
deauth, the auth frame is decrypted by the HW.

To handle this, check if the WEP keys have already
been set for the peer and if so, mark the
frame as decrypted. This scenario can happen
when a station changes its default TX key and initiates
a new authentication sequence.

Signed-off-by: Sujith Manoharan 
---
 drivers/net/wireless/ath/ath10k/mac.c | 23 +++
 drivers/net/wireless/ath/ath10k/mac.h |  2 ++
 drivers/net/wireless/ath/ath10k/wmi.c | 33 +
 3 files changed, 58 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 1245ac8..23116c2 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -179,6 +179,29 @@ static int ath10k_clear_peer_keys(struct ath10k_vif *arvif,
return first_errno;
 }
 
+bool ath10k_mac_is_peer_wep_key_set(struct ath10k *ar, const u8 *addr,
+   u8 keyidx)
+{
+   struct ath10k_peer *peer;
+   int i;
+
+   /* We don't know which vdev this peer belongs to,
+* since WMI doesn't give us that information.
+*
+* FIXME: multi-bss needs to be handled.
+*/
+   peer = ath10k_peer_find(ar, 0, addr);
+   if (!peer)
+   return false;
+
+   for (i = 0; i < ARRAY_SIZE(peer->keys); i++) {
+   if (peer->keys[i] && peer->keys[i]->keyidx == keyidx)
+   return true;
+   }
+
+   return false;
+}
+
 static int ath10k_clear_vdev_key(struct ath10k_vif *arvif,
 struct ieee80211_key_conf *key)
 {
diff --git a/drivers/net/wireless/ath/ath10k/mac.h 
b/drivers/net/wireless/ath/ath10k/mac.h
index 4e3c989..cfa4d5d 100644
--- a/drivers/net/wireless/ath/ath10k/mac.h
+++ b/drivers/net/wireless/ath/ath10k/mac.h
@@ -41,6 +41,8 @@ void ath10k_mgmt_over_wmi_tx_work(struct work_struct *work);
 void ath10k_halt(struct ath10k *ar);
 void ath10k_mac_vif_beacon_free(struct ath10k_vif *arvif);
 void ath10k_drain_tx(struct ath10k *ar);
+bool ath10k_mac_is_peer_wep_key_set(struct ath10k *ar, const u8 *addr,
+   u8 keyidx);
 
 static inline struct ath10k_vif *ath10k_vif_to_arvif(struct ieee80211_vif *vif)
 {
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index c2bc828..a12bba4 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1113,6 +1113,37 @@ static inline u8 get_rate_idx(u32 rate, enum 
ieee80211_band band)
return rate_idx;
 }
 
+static void ath10k_wmi_handle_wep_reauth(struct ath10k *ar,
+struct sk_buff *skb,
+struct ieee80211_rx_status *status)
+{
+   struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
+   unsigned int hdrlen;
+   bool peer_key;
+   u8 *addr, keyidx;
+
+   if (!ieee80211_is_auth(hdr->frame_control) ||
+   !ieee80211_has_protected(hdr->frame_control))
+   return;
+
+   hdrlen = ieee80211_hdrlen(hdr->frame_control);
+   if (skb->len < (hdrlen + IEEE80211_WEP_IV_LEN))
+   return;
+
+   keyidx = skb->data[hdrlen + 3] >> 6;
+   addr = ieee80211_get_SA(hdr);
+
+   spin_lock_bh(&ar->data_lock);
+   peer_key = ath10k_mac_is_peer_wep_key_set(ar, addr, keyidx);
+   spin_unlock_bh(&ar->data_lock);
+
+   if (peer_key) {
+   ath10k_dbg(ar, ATH10K_DBG_MAC,
+  "wep key present for peer: %pM\n", addr);
+   status->flag |= RX_FLAG_DECRYPTED;
+   }
+}
+
 static int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
 {
struct wmi_mgmt_rx_event_v1 *ev_v1;
@@ -1200,6 +1231,8 @@ static int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, 
struct sk_buff *skb)
hdr = (struct ieee80211_hdr *)skb->data;
fc = le16_to_cpu(hdr->frame_control);
 
+   ath10k_wmi_handle_wep_reauth(ar, skb, status);
+
/* FW delivers WEP Shared Auth frame with Protected Bit set and
 * encrypted payload. However in case of PMF it delivers decrypted
 * frames with Protected Bit set. */
-- 
2.1.3

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

[PATCH 0/3] ath10k patches

2014-11-23 Thread Sujith Manoharan 
From: Sujith Manoharan 

Fixes for WEP.

Sujith Manoharan (3):
  ath10k: Fix shared WEP
  ath10k: Fix locking for WEP keys
  ath10k: Fix bug reported by lockdep

 drivers/net/wireless/ath/ath10k/mac.c | 31 +--
 drivers/net/wireless/ath/ath10k/mac.h |  2 ++
 drivers/net/wireless/ath/ath10k/wmi.c | 33 +
 3 files changed, 64 insertions(+), 2 deletions(-)

-- 
2.1.3

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

[PATCH 2/3] ath10k: Fix locking for WEP keys

2014-11-23 Thread Sujith Manoharan 
From: Sujith Manoharan 

peer->keys needs to be protected by data_lock
since it is also accessed from the WMI path.

Both install() and clear() routines for peer
keys modify the key contents, so use the data_lock
to avoid races.

Signed-off-by: Sujith Manoharan 
---
 drivers/net/wireless/ath/ath10k/mac.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 23116c2..2200c64 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -136,7 +136,9 @@ static int ath10k_install_peer_wep_keys(struct ath10k_vif 
*arvif,
if (ret)
return ret;
 
+   spin_lock_bh(&ar->data_lock);
peer->keys[i] = arvif->wep_keys[i];
+   spin_unlock_bh(&ar->data_lock);
}
 
return 0;
@@ -173,7 +175,9 @@ static int ath10k_clear_peer_keys(struct ath10k_vif *arvif,
ath10k_warn(ar, "failed to remove peer wep key %d: 
%d\n",
i, ret);
 
+   spin_lock_bh(&ar->data_lock);
peer->keys[i] = NULL;
+   spin_unlock_bh(&ar->data_lock);
}
 
return first_errno;
-- 
2.1.3

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

[PATCH 3/3] ath10k: Fix bug reported by lockdep

2014-11-23 Thread Sujith Manoharan 
From: Sujith Manoharan 

ath10k_tx_wep_key_work() acquires conf_mutex, so
cancelling it when conf_mutex is already taken
in ath10k_remove_interface() is incorrect, so
move it outside the lock.

Snippet from the lockdep report:

kernel: ==
kernel: [ INFO: possible circular locking dependency detected ]
kernel: 3.18.0-rc5-wl-debug #34 Tainted: G   O
kernel: ---
kernel: hostapd/451 is trying to acquire lock:
kernel:  ((&arvif->wep_key_work)){+.+...}, at: [] 
flush_work+0x5/0x290
kernel: but task is already holding lock:
kernel:  (&ar->conf_mutex){+.+.+.}, at: [] 
ath10k_remove_interface+0x40/0x290 [ath10k_core]
kernel: which lock already depends on the new lock.

Signed-off-by: Sujith Manoharan 
---
 drivers/net/wireless/ath/ath10k/mac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 2200c64..651e318 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3041,10 +3041,10 @@ static void ath10k_remove_interface(struct ieee80211_hw 
*hw,
struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
int ret;
 
-   mutex_lock(&ar->conf_mutex);
-
cancel_work_sync(&arvif->wep_key_work);
 
+   mutex_lock(&ar->conf_mutex);
+
spin_lock_bh(&ar->data_lock);
ath10k_mac_vif_beacon_cleanup(arvif);
spin_unlock_bh(&ar->data_lock);
-- 
2.1.3

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

Re: Fwd: Linux kernel 3.12 PN-KEY Mismatch in wpa.c, packet drop

2014-11-23 Thread deepak kumar Pradhan 
Thank you Johannes for your response. Since we were facing this issue,
i looked at the available patches. None solved the issue for us.
I may be missing something, can you please let me know if the solution
for this is already available?
Any inputs much appreciated.

regards

On Fri, Nov 21, 2014 at 8:49 PM, Johannes Berg
 wrote:
> On Fri, 2014-11-21 at 20:42 +0530, deepak kumar Pradhan wrote:
>> Hi,
>>
>> Sorry for interrupting you.
>> The below patch do recovers from pn-key mismatch in kernel 3.12 kernel
>> packet drop issue.
>> I don't know where I need to submit this patch for proper solution.
>
> This is the right place for submitting a proper solution, but I believe
> you've already been told that what you're doing isn't a proper solution
> at all.
>
> johannes
>



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

..hello...

2014-11-23 Thread hi 
Samsung S5 270 euro, iphone 6plus, 430euro , ipad, ...
si te :assr . 
conN�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{甭*���,�{ay��,j��f＂�h���z��wア�
⒎�j:+v���w�j�m��赙zZ+�茛j"��!�i