Linux wireless drivers development
 help / color / mirror / Atom feed
* Re: mac80211:  3.9.0+:  Invalid WDS/flush state and non-connecting station.
From: Ben Greear @ 2013-05-08 16:18 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <5182D078.4020605@candelatech.com>

On 05/02/2013 01:45 PM, Ben Greear wrote:
> On 05/02/2013 01:24 PM, Johannes Berg wrote:
>> On Thu, 2013-05-02 at 12:50 -0700, Ben Greear wrote:
>>> Kernel is hacked 3.9.0+
>>
>> Clearly :)
>>
>>> I've been seeing this problem for a while (and posted about it previously).  The problem
>>> is that a station appears to associate fine, but never actually 'connects'.  This problem
>>> is not easy to reproduce...
>>
>> It would be useful to know what you added ... the message you point to
>> (invalid wds/flush whatever) doesn't exist upstream.
>
> Gobs of stuff, as usual.  Thought I had that WDS thing pushed upstream,
> but I guess not.

Ok, I reproduced this with yet more debugging printouts in the kernel.

The symptom is this:

The sme_state is SME_CONNECTED, so it bails out below before sending the
'connected' message to user-space.

void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
                                const u8 *req_ie, size_t req_ie_len,
                                const u8 *resp_ie, size_t resp_ie_len,
                                u16 status, bool wextev,
                                struct cfg80211_bss *bss)
{
         struct wireless_dev *wdev = dev->ieee80211_ptr;
         const u8 *country_ie;
#ifdef CONFIG_CFG80211_WEXT
         union iwreq_data wrqu;
#endif

         ASSERT_WDEV_LOCK(wdev);

         printk("connect_result: %s: type: %i  sme_state: %i\n",
                dev->name, (int)(wdev->iftype), (int)(wdev->sme_state));

         if (WARN_ON(wdev->iftype != NL80211_IFTYPE_STATION &&
                     wdev->iftype != NL80211_IFTYPE_P2P_CLIENT))
                 return;

         if (wdev->sme_state != CFG80211_SME_CONNECTING)
                 return;

>
> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.9.dev.y/.git;a=summary
>
> That message comes from:
>
>      /*
>       * Remove all stations associated with this interface.
>       *
>       * This must be done before calling ops->remove_interface()
>       * because otherwise we can later invoke ops->sta_notify()
>       * whenever the STAs are removed, and that invalidates driver
>       * assumptions about always getting a vif pointer that is valid
>       * (because if we remove a STA after ops->remove_interface()
>       * the driver will have removed the vif info already!)
>       *
>       * This is relevant only in WDS mode, in all other modes we've
>       * already removed all stations when disconnecting or similar,
>       * so warn otherwise.
>       *
>       * We call sta_info_flush_cleanup() later, to combine RCU waits.
>       */
>      flushed = sta_info_flush_defer(sdata);
>      if ((sdata->vif.type != NL80211_IFTYPE_WDS && flushed > 0) ||
>          (sdata->vif.type == NL80211_IFTYPE_WDS && flushed != 1)) {
>          sdata_info(sdata,
>                 "Invalid WDS/flush state, type: %i  WDS: %i  flushed: %i\n",
>                 sdata->vif.type, NL80211_IFTYPE_WDS, flushed);
>          WARN_ON_ONCE(1);
>      }
>
> I notice __cfg80211_connect_result checks the wdev state, so I added some
> printouts there to see if it is bailing due to some funny state, but will
> probably be a while before I reproduce it again and know for sure.
>
> Thanks,
> Ben
>
>
>>
>> johannes
>>
>
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


^ permalink raw reply

* Re: Linux driver for Realtek RTL8723AU devices with USB ID 0bda:1724 such as found in Lenovo IdeaPad Yoga 13
From: Greg KH @ 2013-05-08 16:23 UTC (permalink / raw)
  To: Larry Finger
  Cc: H. Peter Anvin, linux-wireless, LKML, netdev, Dan Williams,
	'George0505', Joon Ro
In-Reply-To: <518A7814.1070604@lwfinger.net>

On Wed, May 08, 2013 at 11:06:44AM -0500, Larry Finger wrote:
> On 05/07/2013 09:32 PM, H. Peter Anvin wrote:
> >
> >So I can verify that this driver works against 3.8.11 (not against
> >current -linus because of a build failure), and yes, there is Bluetooth
> >in this device.  In fact, it seems to work better than some in-tree
> >drivers I have seen in the past.
> >
> >However, I'm confused as to the above and what it implies for the
> >purpose of the staging tree.  Wasn't the whole point of the staging tree
> >to have a working-but-ugly driver upstream and have the work to clean it
> >up happen in the mainline tree instead of off somewhere.
> 
> Yes, but even staging has some standards.

I have standards?  That's a first :)

> For example, they frown on inclusion of firmware in a massive data
> block in a file in the driver - it should be in a separate file the
> /lib/firmware/ tree.

Sure, that would be "nice", but it's not something that I should reject
a driver for, have I done that?

> In addition, the mainline drivers/net/wireless/ tree is only available
> to devices that use mac80211 for the software-based MAC layer. That
> conversion is a serious effort that may never be done, thus the
> 8723au driver may never leave staging.

That's a bigger deal, but note, some drivers have done it, it is not
impossible.

thanks,

greg k-h

^ permalink raw reply

* Re: Linux driver for Realtek RTL8723AU devices with USB ID 0bda:1724 such as found in Lenovo IdeaPad Yoga 13
From: H. Peter Anvin @ 2013-05-08 16:29 UTC (permalink / raw)
  To: Larry Finger
  Cc: linux-wireless, LKML, netdev, Dan Williams, 'George0505',
	Joon Ro, Greg KH
In-Reply-To: <518A7814.1070604@lwfinger.net>

On 05/08/2013 09:06 AM, Larry Finger wrote:
> On 05/07/2013 09:32 PM, H. Peter Anvin wrote:
>>
>> So I can verify that this driver works against 3.8.11 (not against
>> current -linus because of a build failure), and yes, there is Bluetooth
>> in this device.  In fact, it seems to work better than some in-tree
>> drivers I have seen in the past.
>>
>> However, I'm confused as to the above and what it implies for the
>> purpose of the staging tree.  Wasn't the whole point of the staging tree
>> to have a working-but-ugly driver upstream and have the work to clean it
>> up happen in the mainline tree instead of off somewhere.
>
> Yes, but even staging has some standards. For example, they frown on
> inclusion of firmware in a massive data block in a file in the driver -
> it should be in a separate file the /lib/firmware/ tree. In addition,
> the mainline drivers/net/wireless/ tree is only available to devices
> that use mac80211 for the software-based MAC layer. That conversion is a
> serious effort that may never be done, thus the 8723au driver may never
> leave staging.
>
> What are the details of the build failure on the mainline tree? It
> builds fine here. One possibility is that your source tree has a
> leftover copy of include/linux/version.h that contains a stale coded
> value of the kernel version. I just pushed a Makefile fix that causes
> the compiler to look in the new location for version.h first. If that
> doesn't work, please post the error.
>

Unlikely, since the kernel source tree is clean.

The error is on os_dep/os_intfs.c:

/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c: In function 
‘rtw_proc_init_one’:
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:315:3: error: implicit 
declaration of function ‘create_proc_entry’ 
[-Werror=implicit-function-declaration]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:315:11: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:322:3: error: implicit 
declaration of function ‘create_proc_read_entry’ 
[-Werror=implicit-function-declaration]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:322:9: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:333:21: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:364:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:370:7: error: dereferencing 
pointer to incomplete type
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:372:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:378:7: error: dereferencing 
pointer to incomplete type
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:381:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:389:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:397:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:405:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:412:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:419:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:426:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:433:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:440:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:447:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:454:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:461:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:468:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:475:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:482:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:489:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:496:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:505:9: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:512:9: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:522:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:539:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:545:7: error: dereferencing 
pointer to incomplete type
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:547:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:553:7: error: dereferencing 
pointer to incomplete type
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:555:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:561:7: error: dereferencing 
pointer to incomplete type
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:563:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:569:7: error: dereferencing 
pointer to incomplete type
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:572:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:576:8: warning: assignment 
makes pointer from integer without a cast [enabled by default]
/home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:582:7: error: dereferencing 
pointer to incomplete type


^ permalink raw reply

* Re: Linux driver for Realtek RTL8723AU devices with USB ID 0bda:1724 such as found in Lenovo IdeaPad Yoga 13
From: Al Viro @ 2013-05-08 16:43 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Larry Finger, linux-wireless, LKML, netdev, Dan Williams,
	'George0505', Joon Ro, Greg KH
In-Reply-To: <518A7D56.3050502@zytor.com>

On Wed, May 08, 2013 at 09:29:10AM -0700, H. Peter Anvin wrote:
> Unlikely, since the kernel source tree is clean.
> 
> The error is on os_dep/os_intfs.c:
> 
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c: In function
> ?rtw_proc_init_one?:
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:315:3: error: implicit
> declaration of function ?create_proc_entry?

create_proc_entry is gone (and good riddance); use proc_create()

> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:322:3: error: implicit
> declaration of function ?create_proc_read_entry?

ditto.

> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:370:7: error:
> dereferencing pointer to incomplete type

... and don't poke in proc_dir_entry innards, while we are at it.

^ permalink raw reply

* [PATCH 1/3] ath9k_htc: Add support for mesh interfaces
From: Thomas Pedersen @ 2013-05-08 17:16 UTC (permalink / raw)
  To: John W. Linville; +Cc: ath9k, linux-wirelss, Javier Cardona, Thomas Pedersen

From: Javier Cardona <javier@cozybit.com>

More specifically, enable AP-style beaconing on mesh
ifaces and change the hw capabilities to reflect mesh
support.

Coexistence with a virtual STA interface was tested as
working fine.

Signed-off-by: Javier Cardona <javier@cozybit.com>
[rebase, add iface combinations]
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
---
 drivers/net/wireless/ath/ath9k/htc.h            |    7 ++++++
 drivers/net/wireless/ath/ath9k/htc_drv_beacon.c |    5 +++-
 drivers/net/wireless/ath/ath9k/htc_drv_init.c   |    6 +++--
 drivers/net/wireless/ath/ath9k/htc_drv_main.c   |   29 ++++++++++++++++-------
 drivers/net/wireless/ath/ath9k/htc_drv_txrx.c   |    2 +-
 5 files changed, 37 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index d3b099d..0085e64 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -208,6 +208,9 @@ struct ath9k_htc_target_rx_stats {
 		case NL80211_IFTYPE_AP:		\
 			_priv->num_ap_vif++;	\
 			break;			\
+		case NL80211_IFTYPE_MESH_POINT:	\
+			_priv->num_mbss_vif++;	\
+			break;			\
 		default:			\
 			break;			\
 		}				\
@@ -224,6 +227,9 @@ struct ath9k_htc_target_rx_stats {
 		case NL80211_IFTYPE_AP:		\
 			_priv->num_ap_vif--;	\
 			break;			\
+		case NL80211_IFTYPE_MESH_POINT:	\
+			_priv->num_mbss_vif--;	\
+			break;			\
 		default:			\
 			break;			\
 		}				\
@@ -450,6 +456,7 @@ struct ath9k_htc_priv {
 	u8 sta_slot;
 	u8 vif_sta_pos[ATH9K_HTC_MAX_VIF];
 	u8 num_ibss_vif;
+	u8 num_mbss_vif;
 	u8 num_sta_vif;
 	u8 num_sta_assoc_vif;
 	u8 num_ap_vif;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c b/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c
index f13f458..e0c03bd 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c
@@ -28,7 +28,8 @@ void ath9k_htc_beaconq_config(struct ath9k_htc_priv *priv)
 
 	ath9k_hw_get_txq_props(ah, priv->beaconq, &qi);
 
-	if (priv->ah->opmode == NL80211_IFTYPE_AP) {
+	if (priv->ah->opmode == NL80211_IFTYPE_AP ||
+	    priv->ah->opmode == NL80211_IFTYPE_MESH_POINT) {
 		qi.tqi_aifs = 1;
 		qi.tqi_cwmin = 0;
 		qi.tqi_cwmax = 0;
@@ -628,6 +629,7 @@ void ath9k_htc_beacon_config(struct ath9k_htc_priv *priv,
 	case NL80211_IFTYPE_ADHOC:
 		ath9k_htc_beacon_config_adhoc(priv, cur_conf);
 		break;
+	case NL80211_IFTYPE_MESH_POINT:
 	case NL80211_IFTYPE_AP:
 		ath9k_htc_beacon_config_ap(priv, cur_conf);
 		break;
@@ -649,6 +651,7 @@ void ath9k_htc_beacon_reconfig(struct ath9k_htc_priv *priv)
 	case NL80211_IFTYPE_ADHOC:
 		ath9k_htc_beacon_config_adhoc(priv, cur_conf);
 		break;
+	case NL80211_IFTYPE_MESH_POINT:
 	case NL80211_IFTYPE_AP:
 		ath9k_htc_beacon_config_ap(priv, cur_conf);
 		break;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index a47f5e0..6eb4199 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -698,7 +698,8 @@ static const struct ieee80211_iface_limit if_limits[] = {
 	{ .max = 2,	.types = BIT(NL80211_IFTYPE_STATION) |
 				 BIT(NL80211_IFTYPE_P2P_CLIENT) },
 	{ .max = 2,	.types = BIT(NL80211_IFTYPE_AP) |
-				 BIT(NL80211_IFTYPE_P2P_GO) },
+				 BIT(NL80211_IFTYPE_P2P_GO) |
+				 BIT(NL80211_IFTYPE_MESH_POINT) },
 };
 
 static const struct ieee80211_iface_combination if_comb = {
@@ -728,7 +729,8 @@ static void ath9k_set_hw_capab(struct ath9k_htc_priv *priv,
 		BIT(NL80211_IFTYPE_ADHOC) |
 		BIT(NL80211_IFTYPE_AP) |
 		BIT(NL80211_IFTYPE_P2P_GO) |
-		BIT(NL80211_IFTYPE_P2P_CLIENT);
+		BIT(NL80211_IFTYPE_P2P_CLIENT) |
+		BIT(NL80211_IFTYPE_MESH_POINT);
 
 	hw->wiphy->iface_combinations = &if_comb;
 	hw->wiphy->n_iface_combinations = 1;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 0743a47..2a67b57 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -113,7 +113,9 @@ static void ath9k_htc_vif_iter(void *data, u8 *mac, struct ieee80211_vif *vif)
 	struct ath9k_htc_priv *priv = data;
 	struct ieee80211_bss_conf *bss_conf = &vif->bss_conf;
 
-	if ((vif->type == NL80211_IFTYPE_AP) && bss_conf->enable_beacon)
+	if ((vif->type == NL80211_IFTYPE_AP ||
+	     vif->type == NL80211_IFTYPE_MESH_POINT) &&
+	    bss_conf->enable_beacon)
 		priv->reconfig_beacon = true;
 
 	if (bss_conf->assoc) {
@@ -180,6 +182,8 @@ static void ath9k_htc_set_opmode(struct ath9k_htc_priv *priv)
 		priv->ah->opmode = NL80211_IFTYPE_ADHOC;
 	else if (priv->num_ap_vif)
 		priv->ah->opmode = NL80211_IFTYPE_AP;
+	else if (priv->num_mbss_vif)
+		priv->ah->opmode = NL80211_IFTYPE_MESH_POINT;
 	else
 		priv->ah->opmode = NL80211_IFTYPE_STATION;
 
@@ -1052,6 +1056,9 @@ static int ath9k_htc_add_interface(struct ieee80211_hw *hw,
 	case NL80211_IFTYPE_AP:
 		hvif.opmode = HTC_M_HOSTAP;
 		break;
+	case NL80211_IFTYPE_MESH_POINT:
+		hvif.opmode = HTC_M_WDS;	/* close enough */
+		break;
 	default:
 		ath_err(common,
 			"Interface type %d not yet supported\n", vif->type);
@@ -1084,6 +1091,7 @@ static int ath9k_htc_add_interface(struct ieee80211_hw *hw,
 	INC_VIF(priv, vif->type);
 
 	if ((vif->type == NL80211_IFTYPE_AP) ||
+	    (vif->type == NL80211_IFTYPE_MESH_POINT) ||
 	    (vif->type == NL80211_IFTYPE_ADHOC))
 		ath9k_htc_assign_bslot(priv, vif);
 
@@ -1134,6 +1142,7 @@ static void ath9k_htc_remove_interface(struct ieee80211_hw *hw,
 	DEC_VIF(priv, vif->type);
 
 	if ((vif->type == NL80211_IFTYPE_AP) ||
+	     vif->type == NL80211_IFTYPE_MESH_POINT ||
 	    (vif->type == NL80211_IFTYPE_ADHOC))
 		ath9k_htc_remove_bslot(priv, vif);
 
@@ -1525,9 +1534,10 @@ static void ath9k_htc_bss_info_changed(struct ieee80211_hw *hw,
 	if ((changed & BSS_CHANGED_BEACON_ENABLED) && !bss_conf->enable_beacon) {
 		/*
 		 * Disable SWBA interrupt only if there are no
-		 * AP/IBSS interfaces.
+		 * concurrent AP/mesh or IBSS interfaces.
 		 */
-		if ((priv->num_ap_vif <= 1) || priv->num_ibss_vif) {
+		if ((priv->num_ap_vif + priv->num_mbss_vif <= 1) ||
+		     priv->num_ibss_vif) {
 			ath_dbg(common, CONFIG,
 				"Beacon disabled for BSS: %pM\n",
 				bss_conf->bssid);
@@ -1538,12 +1548,15 @@ static void ath9k_htc_bss_info_changed(struct ieee80211_hw *hw,
 
 	if (changed & BSS_CHANGED_BEACON_INT) {
 		/*
-		 * Reset the HW TSF for the first AP interface.
+		 * Reset the HW TSF for the first AP or mesh interface.
 		 */
-		if ((priv->ah->opmode == NL80211_IFTYPE_AP) &&
-		    (priv->nvifs == 1) &&
-		    (priv->num_ap_vif == 1) &&
-		    (vif->type == NL80211_IFTYPE_AP)) {
+		if (priv->nvifs == 1 &&
+		    ((priv->ah->opmode == NL80211_IFTYPE_AP &&
+		      vif->type == NL80211_IFTYPE_AP &&
+		      priv->num_ap_vif == 1) ||
+		    (priv->ah->opmode == NL80211_IFTYPE_MESH_POINT &&
+		      vif->type == NL80211_IFTYPE_MESH_POINT &&
+		      priv->num_mbss_vif == 1))) {
 			set_bit(OP_TSF_RESET, &priv->op_flags);
 		}
 		ath_dbg(common, CONFIG,
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index 6bd0e92..e602c95 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -887,7 +887,7 @@ u32 ath9k_htc_calcrxfilter(struct ath9k_htc_priv *priv)
 	if (priv->rxfilter & FIF_PSPOLL)
 		rfilt |= ATH9K_RX_FILTER_PSPOLL;
 
-	if (priv->nvifs > 1)
+	if (priv->nvifs > 1 || priv->rxfilter & FIF_OTHER_BSS)
 		rfilt |= ATH9K_RX_FILTER_MCAST_BCAST_ALL;
 
 	return rfilt;
-- 
1.7.10.4


^ permalink raw reply related

* [PATCH 2/3] ath9k_htc: Claim support for mgmt frame protection
From: Thomas Pedersen @ 2013-05-08 17:16 UTC (permalink / raw)
  To: John W. Linville; +Cc: ath9k, linux-wirelss, Javier Cardona
In-Reply-To: <1368033408-3994-1-git-send-email-thomas@cozybit.com>

From: Javier Cardona <javier@cozybit.com>

Advertise support for management frame protection in hardware.

Signed-off-by: Javier Cardona <javier@cozybit.com>
---
 drivers/net/wireless/ath/ath9k/htc_drv_init.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 6eb4199..59f6436 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -722,6 +722,7 @@ static void ath9k_set_hw_capab(struct ath9k_htc_priv *priv,
 		IEEE80211_HW_SUPPORTS_PS |
 		IEEE80211_HW_PS_NULLFUNC_STACK |
 		IEEE80211_HW_REPORTS_TX_ACK_STATUS |
+		IEEE80211_HW_MFP_CAPABLE |
 		IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING;
 
 	hw->wiphy->interface_modes =
-- 
1.7.10.4


^ permalink raw reply related

* [PATCH 3/3] ath9k: use ap style beaconing for mesh
From: Thomas Pedersen @ 2013-05-08 17:16 UTC (permalink / raw)
  To: John W. Linville; +Cc: ath9k, linux-wirelss, Thomas Pedersen
In-Reply-To: <1368033408-3994-1-git-send-email-thomas@cozybit.com>

Chun-Yeow and Javier Lopez contributed these changes to
make mesh mode use the more similar AP beaconing mode and
queue parameters. Should improve PS performance, interface
concurrency (AP modes can coexist), and beacon interval
stability.

AR9271 (ath9k_htc) mesh interfaces also need to be in AP
operating mode.

Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
---
 drivers/net/wireless/ath/ath9k/beacon.c |    8 +++++---
 drivers/net/wireless/ath/ath9k/hw.c     |    4 ++--
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/beacon.c b/drivers/net/wireless/ath/ath9k/beacon.c
index 2ff570f..fd1eeba 100644
--- a/drivers/net/wireless/ath/ath9k/beacon.c
+++ b/drivers/net/wireless/ath/ath9k/beacon.c
@@ -39,7 +39,8 @@ static void ath9k_beaconq_config(struct ath_softc *sc)
 
 	ath9k_hw_get_txq_props(ah, sc->beacon.beaconq, &qi);
 
-	if (sc->sc_ah->opmode == NL80211_IFTYPE_AP) {
+	if (sc->sc_ah->opmode == NL80211_IFTYPE_AP ||
+	    sc->sc_ah->opmode == NL80211_IFTYPE_MESH_POINT) {
 		/* Always burst out beacon and CAB traffic. */
 		qi.tqi_aifs = 1;
 		qi.tqi_cwmin = 0;
@@ -273,7 +274,8 @@ static int ath9k_beacon_choose_slot(struct ath_softc *sc)
 	u64 tsf;
 	int slot;
 
-	if (sc->sc_ah->opmode != NL80211_IFTYPE_AP) {
+	if (sc->sc_ah->opmode != NL80211_IFTYPE_AP &&
+	    sc->sc_ah->opmode != NL80211_IFTYPE_MESH_POINT) {
 		ath_dbg(common, BEACON, "slot 0, tsf: %llu\n",
 			ath9k_hw_gettsf64(sc->sc_ah));
 		return 0;
@@ -765,10 +767,10 @@ void ath9k_set_beacon(struct ath_softc *sc)
 
 	switch (sc->sc_ah->opmode) {
 	case NL80211_IFTYPE_AP:
+	case NL80211_IFTYPE_MESH_POINT:
 		ath9k_beacon_config_ap(sc, cur_conf);
 		break;
 	case NL80211_IFTYPE_ADHOC:
-	case NL80211_IFTYPE_MESH_POINT:
 		ath9k_beacon_config_adhoc(sc, cur_conf);
 		break;
 	case NL80211_IFTYPE_STATION:
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 7f25da8..a263ccc 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1245,10 +1245,10 @@ static void ath9k_hw_set_operating_mode(struct ath_hw *ah, int opmode)
 
 	switch (opmode) {
 	case NL80211_IFTYPE_ADHOC:
-	case NL80211_IFTYPE_MESH_POINT:
 		set |= AR_STA_ID1_ADHOC;
 		REG_SET_BIT(ah, AR_CFG, AR_CFG_AP_ADHOC_INDICATION);
 		break;
+	case NL80211_IFTYPE_MESH_POINT:
 	case NL80211_IFTYPE_AP:
 		set |= AR_STA_ID1_STA_AP;
 		/* fall through */
@@ -2246,12 +2246,12 @@ void ath9k_hw_beaconinit(struct ath_hw *ah, u32 next_beacon, u32 beacon_period)
 
 	switch (ah->opmode) {
 	case NL80211_IFTYPE_ADHOC:
-	case NL80211_IFTYPE_MESH_POINT:
 		REG_SET_BIT(ah, AR_TXCFG,
 			    AR_TXCFG_ADHOC_BEACON_ATIM_TX_POLICY);
 		REG_WRITE(ah, AR_NEXT_NDP_TIMER, next_beacon +
 			  TU_TO_USEC(ah->atim_window ? ah->atim_window : 1));
 		flags |= AR_NDP_TIMER_EN;
+	case NL80211_IFTYPE_MESH_POINT:
 	case NL80211_IFTYPE_AP:
 		REG_WRITE(ah, AR_NEXT_TBTT_TIMER, next_beacon);
 		REG_WRITE(ah, AR_NEXT_DMA_BEACON_ALERT, next_beacon -
-- 
1.7.10.4


^ permalink raw reply related

* mac80211 warning in 3.9.0+ when unloading ath9k driver.
From: Ben Greear @ 2013-05-08 17:38 UTC (permalink / raw)
  To: linux-wireless@vger.kernel.org

I saw the WARN_ON_ONCE hit below on 3.9.0+ (+ hacks)
on a system with ath9k and ath9k_htc driver.

I'll be happy to add more debugging if someone has suggestions.

static void ieee80211_recalc_chanctx_chantype(struct ieee80211_local *local,
					      struct ieee80211_chanctx *ctx)
{
	struct ieee80211_chanctx_conf *conf = &ctx->conf;
	struct ieee80211_sub_if_data *sdata;
	const struct cfg80211_chan_def *compat = NULL;

	lockdep_assert_held(&local->chanctx_mtx);

	rcu_read_lock();
	list_for_each_entry_rcu(sdata, &local->interfaces, list) {

		if (!ieee80211_sdata_running(sdata))
			continue;
		if (rcu_access_pointer(sdata->vif.chanctx_conf) != conf)
			continue;

		if (!compat)
			compat = &sdata->vif.bss_conf.chandef;

		compat = cfg80211_chandef_compatible(
				&sdata->vif.bss_conf.chandef, compat);
		if (!compat)
			break;
	}
	rcu_read_unlock();

	if (WARN_ON_ONCE(!compat))
		return;

	ieee80211_change_chanctx(local, ctx, compat);
}


May  8 09:39:16 localhost kernel: [412775.378116] wlan0: deauthenticating from 80:01:02:03:04:05 by local choice (reason=3)
May  8 09:39:17 localhost kernel: [412776.206878] ------------[ cut here ]------------
May  8 09:39:17 localhost kernel: [412776.219968] WARNING: at /home/greearb/git/linux-3.9.dev.y/net/mac80211/chan.c:186 
ieee80211_recalc_chanctx_chantype+0x9f/0xe0 [mac80211]()
May  8 09:39:17 localhost kernel: [412776.246245] Hardware name: To Be Filled By O.E.M.
May  8 09:39:17 localhost kernel: [412776.254609] Modules linked in: iptable_raw xt_CT nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 
bluetooth 8021q mrp garp stp llc fuse macvlan wanlink(O) pktgen w83627ehf hwmon_vid nfsv3 nfs_acl nfsv4 auth_rpcgss nfs fscache lockd sunrpc binfmt_misc uinput 
arc4 ath9k(-) ath9k_htc mac80211 coretemp gpio_ich iTCO_wdt snd_hda_codec_realtek iTCO_vendor_support ath9k_common snd_hda_intel ath9k_hw snd_hda_codec ath 
snd_hwdep snd_seq snd_seq_device microcode lpc_ich i2c_i801 pcspkr serio_raw snd_pcm cfg80211 snd_timer rfkill snd r8169 soundcore snd_page_alloc mii i915 
drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: iptable_nat]
May  8 09:39:17 localhost kernel: [412776.339435] Pid: 11945, comm: rmmod Tainted: G        WC O 3.9.0+ #25
May  8 09:39:17 localhost kernel: [412776.350098] Call Trace:
May  8 09:39:17 localhost kernel: [412776.356658]  [<c0450fc2>] warn_slowpath_common+0x72/0xa0
May  8 09:39:17 localhost kernel: [412776.366123]  [<f99fd14f>] ? ieee80211_recalc_chanctx_chantype+0x9f/0xe0 [mac80211]
May  8 09:39:17 localhost kernel: [412776.377810]  [<f99fd14f>] ? ieee80211_recalc_chanctx_chantype+0x9f/0xe0 [mac80211]
May  8 09:39:17 localhost kernel: [412776.389318]  [<c0451012>] warn_slowpath_null+0x22/0x30
May  8 09:39:17 localhost kernel: [412776.398267]  [<f99fd14f>] ieee80211_recalc_chanctx_chantype+0x9f/0xe0 [mac80211]
May  8 09:39:17 localhost kernel: [412776.409563]  [<f99fd85c>] __ieee80211_vif_release_channel+0xac/0x220 [mac80211]
May  8 09:39:17 localhost kernel: [412776.421161]  [<f99fda12>] ieee80211_vif_release_channel+0x42/0x60 [mac80211]
May  8 09:39:17 localhost kernel: [412776.432570]  [<f9a15a3e>] ieee80211_set_disassoc+0x21e/0x460 [mac80211]
May  8 09:39:17 localhost kernel: [412776.443246]  [<f9a15fa4>] ieee80211_mgd_deauth+0x234/0x2a0 [mac80211]
May  8 09:39:17 localhost kernel: [412776.453685]  [<f99e91f5>] ieee80211_deauth+0x15/0x20 [mac80211]
May  8 09:39:17 localhost kernel: [412776.463615]  [<f861df37>] cfg80211_mlme_down+0x97/0x1b0 [cfg80211]
May  8 09:39:17 localhost kernel: [412776.473670]  [<f862188d>] __cfg80211_disconnect+0x22d/0x280 [cfg80211]
May  8 09:39:17 localhost kernel: [412776.484487]  [<c0412ade>] ? __switch_to+0xee/0x390
May  8 09:39:17 localhost kernel: [412776.493283]  [<f86017b6>] cfg80211_netdev_notifier_call+0x576/0x6a0 [cfg80211]
May  8 09:39:17 localhost kernel: [412776.504497]  [<c092d7a9>] ? inetdev_event+0x29/0x4f0
May  8 09:39:17 localhost kernel: [412776.513376]  [<c08e2d3d>] ? fib_rules_event+0x1d/0x180
May  8 09:39:17 localhost kernel: [412776.522437]  [<c099b06d>] ? packet_notifier+0x9d/0x170
May  8 09:39:17 localhost kernel: [412776.531532]  [<c09bd443>] notifier_call_chain+0x43/0x60
May  8 09:39:17 localhost kernel: [412776.540791]  [<c047773f>] raw_notifier_call_chain+0x1f/0x30
May  8 09:39:17 localhost kernel: [412776.550452]  [<c08c9c8c>] call_netdevice_notifiers+0x2c/0x60
May  8 09:39:17 localhost kernel: [412776.560253]  [<c09b6d85>] ? schedule_timeout+0x185/0x1c0
May  8 09:39:17 localhost kernel: [412776.569707]  [<c077e5c3>] ? device_release+0x33/0x90
May  8 09:39:17 localhost kernel: [412776.578886]  [<c077e5c3>] ? device_release+0x33/0x90
May  8 09:39:17 localhost kernel: [412776.588098]  [<c08c9cf4>] __dev_close_many+0x34/0xb0
May  8 09:39:17 localhost kernel: [412776.597330]  [<c0549450>] ? kfree+0x100/0x130
May  8 09:39:17 localhost kernel: [412776.605808]  [<c0691428>] ? kobject_release+0x98/0x1c0
May  8 09:39:17 localhost kernel: [412776.615088]  [<c08c9e5c>] dev_close_many+0x6c/0xc0
May  8 09:39:17 localhost kernel: [412776.624071]  [<c08c9fef>] rollback_registered_many+0xaf/0x1f0
May  8 09:39:17 localhost kernel: [412776.634068]  [<c08ca1aa>] ? unregister_netdevice_queue+0x1a/0xc0
May  8 09:39:17 localhost kernel: [412776.644431]  [<c04d3ff0>] ? call_rcu_bh+0x20/0x20
May  8 09:39:17 localhost kernel: [412776.653502]  [<c08ca144>] unregister_netdevice_many+0x14/0x60
May  8 09:39:17 localhost kernel: [412776.663814]  [<f99e3383>] ieee80211_remove_interfaces+0xb3/0x140 [mac80211]
May  8 09:39:17 localhost kernel: [412776.675363]  [<f99d3156>] ieee80211_unregister_hw+0x56/0x100 [mac80211]
May  8 09:39:17 localhost kernel: [412776.686637]  [<f987d69a>] ath9k_deinit_device+0x3a/0x60 [ath9k]
May  8 09:39:17 localhost kernel: [412776.697266]  [<f988d4a1>] ath_pci_remove+0x31/0x50 [ath9k]
May  8 09:39:17 localhost kernel: [412776.707386]  [<c06c1d68>] pci_device_remove+0x38/0xc0
May  8 09:39:17 localhost kernel: [412776.717151]  [<c07819cf>] __device_release_driver+0x5f/0xb0
May  8 09:39:17 localhost kernel: [412776.727339]  [<c0781aaf>] driver_detach+0x8f/0xa0
May  8 09:39:17 localhost kernel: [412776.736509]  [<c0780abc>] bus_remove_driver+0x6c/0xe0
May  8 09:39:17 localhost kernel: [412776.746057]  [<c07801c7>] ? bus_put+0x17/0x20
May  8 09:39:17 localhost kernel: [412776.754775]  [<c0780ad3>] ? bus_remove_driver+0x83/0xe0
May  8 09:39:17 localhost kernel: [412776.764283]  [<c07825f9>] driver_unregister+0x49/0x80
May  8 09:39:17 localhost kernel: [412776.773412]  [<c06c1ea8>] pci_unregister_driver+0x18/0x70
May  8 09:39:17 localhost kernel: [412776.782780]  [<f988d2b2>] ath_pci_exit+0x12/0x20 [ath9k]
May  8 09:39:17 localhost kernel: [412776.791971]  [<f98968c0>] ath9k_exit+0x17/0x757 [ath9k]
May  8 09:39:17 localhost kernel: [412776.800982]  [<c04b0fca>] sys_delete_module+0x17a/0x250
May  8 09:39:17 localhost kernel: [412776.809871]  [<c0532848>] ? do_munmap+0x238/0x2c0
May  8 09:39:17 localhost kernel: [412776.818268]  [<c04c7ff6>] ? __audit_syscall_exit+0x1f6/0x280
May  8 09:39:17 localhost kernel: [412776.827617]  [<c09c06cd>] sysenter_do_call+0x12/0x28
May  8 09:39:17 localhost kernel: [412776.836150] ---[ end trace aff91972ce67584d ]---
May  8 09:39:17 localhost dhcpd: receive_packet failed on vap0: Network is down
May  8 09:39:18 localhost kernel: [412777.276473] ath9k: ath9k: Driver unloaded


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


^ permalink raw reply

* RE: Memory leak in mwifiex_cfg80211_scan
From: Bing Zhao @ 2013-05-08 17:58 UTC (permalink / raw)
  To: Daniel Drake; +Cc: linux-wireless@vger.kernel.org, Amitkumar Karwar
In-Reply-To: <CAMLZHHQdBuy=7bBsifA4i5ZKQcjnEhKZqVumRE=qu+Jkn3dZug@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 239 bytes --]

Hi Daniel,

> I think you should use del_timer_sync() though, for the SMP case where
> the timer may be running on a different processor.

Thanks for the comment. Please find attached updated patch.

Regards,
Bing

> 
> Daniel

[-- Attachment #2: v2_0001-mwifiex-scan-delay-timer-cleanup-in-unload-path.patch --]
[-- Type: application/octet-stream, Size: 1769 bytes --]

From 4fc80dda50d62960f2823891355a5f5382f4ce67 Mon Sep 17 00:00:00 2001
From: Amitkumar Karwar <akarwar@marvell.com>
Date: Mon, 6 May 2013 17:28:44 -0700
Subject: [PATCH] mwifiex: scan delay timer cleanup in unload path

Return from scan delay timer routine if surprise_removed flag
is true. Also, cancel the timer in unload path.

This fixes a crash when scan delay timer accesses structures
that have been freed already.

Tested with "iwlist mlan0 scan & sleep 1; rmmod mwifiex_sdio"

Reported-by: Daniel Drake <dsd@laptop.org>
Tested-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
 drivers/net/wireless/mwifiex/init.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/mwifiex/init.c b/drivers/net/wireless/mwifiex/init.c
index bca500a..1343725f 100644
--- a/drivers/net/wireless/mwifiex/init.c
+++ b/drivers/net/wireless/mwifiex/init.c
@@ -59,6 +59,9 @@ static void scan_delay_timer_fn(unsigned long data)
 	struct cmd_ctrl_node *cmd_node, *tmp_node;
 	unsigned long flags;
 
+	if (adapter->surprise_removed)
+		return;
+
 	if (adapter->scan_delay_cnt == MWIFIEX_MAX_SCAN_DELAY_CNT) {
 		/*
 		 * Abort scan operation by cancelling all pending scan
@@ -452,11 +455,18 @@ static void mwifiex_free_lock_list(struct mwifiex_adapter *adapter)
 static void
 mwifiex_adapter_cleanup(struct mwifiex_adapter *adapter)
 {
+	int i;
+
 	if (!adapter) {
 		pr_err("%s: adapter is NULL\n", __func__);
 		return;
 	}
 
+	for (i = 0; i < adapter->priv_num; i++) {
+		if (adapter->priv[i])
+			del_timer_sync(&adapter->priv[i]->scan_delay_timer);
+	}
+
 	mwifiex_cancel_all_pending_cmd(adapter);
 
 	/* Free lock variables */
-- 
1.7.3.4


^ permalink raw reply related

* Re: mac80211:  3.9.0+:  Invalid WDS/flush state and non-connecting station.
From: Johannes Berg @ 2013-05-08 17:58 UTC (permalink / raw)
  To: Ben Greear; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <518A7AD4.2060100@candelatech.com>

On Wed, 2013-05-08 at 09:18 -0700, Ben Greear wrote:

> Ok, I reproduced this with yet more debugging printouts in the kernel.
> 
> The symptom is this:
> 
> The sme_state is SME_CONNECTED, so it bails out below before sending the
> 'connected' message to user-space.

Is your system being really really really slow and/or are threads
getting pre-empted a lot? This maybe seem like a bit of a stretch, but
it seems possible that this happens:

ieee80211_sta_rx_queued_mgmt() is running, possibly on one CPU, and is
somewhere between printing "associated" and calling
cfg80211_send_rx_assoc() (or in the call already, before taking the lock
though.)

Then your interface is set down at the same time, possibly on a
different CPU. Here's where the scenario gets stretched, clearly your
interface is getting set down over a minute later, I don't see how you
could have stalled the other thread for that long.

But if you did, then that thread is still processing things while the
interface is going down, cfg80211 didn't know anything about the
association having completed so it won't have disconnected, etc.

So far, I haven't found any other scenario, nor a solution.

johannes


^ permalink raw reply

* Re: mac80211 warning in 3.9.0+ when unloading ath9k driver.
From: Johannes Berg @ 2013-05-08 18:04 UTC (permalink / raw)
  To: Ben Greear; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <518A8DB1.7080904@candelatech.com>

On Wed, 2013-05-08 at 10:38 -0700, Ben Greear wrote:
> I saw the WARN_ON_ONCE hit below on 3.9.0+ (+ hacks)
> on a system with ath9k and ath9k_htc driver.

Were you using VLANs?

> I'll be happy to add more debugging if someone has suggestions.

> 		compat = cfg80211_chandef_compatible(
> 				&sdata->vif.bss_conf.chandef, compat);
> 		if (!compat)
> 			break;
> 	}
> 	rcu_read_unlock();
> 
> 	if (WARN_ON_ONCE(!compat))
> 		return;

Might be helpful to know whether chandef_compatible() returned NULL, or
if the loop simply never found an interface with a matching pointer.

johannes


^ permalink raw reply

* Re: Linux driver for Realtek RTL8723AU devices with USB ID 0bda:1724 such as found in Lenovo IdeaPad Yoga 13
From: Larry Finger @ 2013-05-08 18:12 UTC (permalink / raw)
  To: Greg KH
  Cc: H. Peter Anvin, linux-wireless, LKML, netdev, Dan Williams,
	'George0505', Joon Ro
In-Reply-To: <20130508162350.GC28080@kroah.com>

On 05/08/2013 11:23 AM, Greg KH wrote:
> On Wed, May 08, 2013 at 11:06:44AM -0500, Larry Finger wrote:
>> On 05/07/2013 09:32 PM, H. Peter Anvin wrote:
>>>
>>> So I can verify that this driver works against 3.8.11 (not against
>>> current -linus because of a build failure), and yes, there is Bluetooth
>>> in this device.  In fact, it seems to work better than some in-tree
>>> drivers I have seen in the past.
>>>
>>> However, I'm confused as to the above and what it implies for the
>>> purpose of the staging tree.  Wasn't the whole point of the staging tree
>>> to have a working-but-ugly driver upstream and have the work to clean it
>>> up happen in the mainline tree instead of off somewhere.
>>
>> Yes, but even staging has some standards.
>
> I have standards?  That's a first :)
>
>> For example, they frown on inclusion of firmware in a massive data
>> block in a file in the driver - it should be in a separate file the
>> /lib/firmware/ tree.
>
> Sure, that would be "nice", but it's not something that I should reject
> a driver for, have I done that?

No. You merely "recommended" that it be the #1 item in the TODO list, which 
forced me to fix it fairly quickly for r8712u.

>
>> In addition, the mainline drivers/net/wireless/ tree is only available
>> to devices that use mac80211 for the software-based MAC layer. That
>> conversion is a serious effort that may never be done, thus the
>> 8723au driver may never leave staging.
>
> That's a bigger deal, but note, some drivers have done it, it is not
> impossible.

Most of them were in the kernel before mac80211, and have been given a pass as 
part of a "grandfather" clause.

Unfortunately, I forgot the main reason for development in an off-line repo. I 
do not have one of these devices, and I have drawn the line at purchasing a 
$1000 Lenovo tablet just to get one. Making "small" untested changes in the 
off-line repo for the users to verify is a lot simpler than working through 
staging, no matter how accommodating you are. :)

If someone wants to donate a device, that would speed up the process.

Larry


^ permalink raw reply

* Re: mac80211:  3.9.0+:  Invalid WDS/flush state and non-connecting station.
From: Ben Greear @ 2013-05-08 18:14 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1368035937.8279.25.camel@jlt4.sipsolutions.net>

On 05/08/2013 10:58 AM, Johannes Berg wrote:
> On Wed, 2013-05-08 at 09:18 -0700, Ben Greear wrote:
>
>> Ok, I reproduced this with yet more debugging printouts in the kernel.
>>
>> The symptom is this:
>>
>> The sme_state is SME_CONNECTED, so it bails out below before sending the
>> 'connected' message to user-space.
>
> Is your system being really really really slow and/or are threads
> getting pre-empted a lot? This maybe seem like a bit of a stretch, but
> it seems possible that this happens:
>
> ieee80211_sta_rx_queued_mgmt() is running, possibly on one CPU, and is
> somewhere between printing "associated" and calling
> cfg80211_send_rx_assoc() (or in the call already, before taking the lock
> though.)
>
> Then your interface is set down at the same time, possibly on a
> different CPU. Here's where the scenario gets stretched, clearly your
> interface is getting set down over a minute later, I don't see how you
> could have stalled the other thread for that long.
>
> But if you did, then that thread is still processing things while the
> interface is going down, cfg80211 didn't know anything about the
> association having completed so it won't have disconnected, etc.
>
> So far, I haven't found any other scenario, nor a solution.

It is not that slow or overloaded (at least most of the time,
and in particular, I only had 20 virtual stations up on this system
not doing much traffic...it easily handles 100's of stations).

And, once it gets in this state..it stays there (overnight,
with my app resetting the port (via 'ip link set down' and
poking at wpa_supplicant) every minute or so in this case.

I was wondering..in the cfg80211_mlme_down method (or perhaps
some place similar), should we force sme state to IDLE
with a big WARN_ON_ONCE or similar.

That way, if it does get stuck somehow, we can recover by
downing the interface and bringing it back up?

For what it's worth, I don't recall ever seeing this problem
in 5.7, but it's way to rare to be able to bisect...

Thanks,
Ben

>
> johannes
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


^ permalink raw reply

* Re: mac80211 warning in 3.9.0+ when unloading ath9k driver.
From: Ben Greear @ 2013-05-08 18:45 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1368036259.8279.26.camel@jlt4.sipsolutions.net>

On 05/08/2013 11:04 AM, Johannes Berg wrote:
> On Wed, 2013-05-08 at 10:38 -0700, Ben Greear wrote:
>> I saw the WARN_ON_ONCE hit below on 3.9.0+ (+ hacks)
>> on a system with ath9k and ath9k_htc driver.
>
> Were you using VLANs?

No.

>
>> I'll be happy to add more debugging if someone has suggestions.
>
>> 		compat = cfg80211_chandef_compatible(
>> 				&sdata->vif.bss_conf.chandef, compat);
>> 		if (!compat)
>> 			break;
>> 	}
>> 	rcu_read_unlock();
>>
>> 	if (WARN_ON_ONCE(!compat))
>> 		return;
>
> Might be helpful to know whether chandef_compatible() returned NULL, or
> if the loop simply never found an interface with a matching pointer.

Ok, I'll add this.

Probably un-related, but the system usually crashes shortly after.  With
memory debugging enabled, it appears to be relayfs and/or ath9k accessing
freed memory.

I'm digging into that one first on an un-hacked kernel..then will
get back to this warning...

Thanks,
Ben

>
> johannes
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


^ permalink raw reply

* [PATCH v3 1/2] cfg80211: Userspace may inform kernel of mesh auth method.
From: Colleen Twitty @ 2013-05-08 18:45 UTC (permalink / raw)
  To: Johannes Berg; +Cc: open80211s, linux-wirelss

Authentication takes place in userspace, but the beacon is
generated in the kernel.  Allow userspace to inform the
kernel of the authentication method so the appropriate
mesh config IE can be set prior to beacon generation when
joining the MBSS.

Signed-off-by: Colleen Twitty <colleen@cozybit.com>
---
  If user_mpm is set, allow userspace to set authentication bit.  (Johannes)

 include/net/cfg80211.h       |    2 ++
 include/uapi/linux/nl80211.h |    5 +++++
 net/wireless/mesh.c          |    1 +
 net/wireless/nl80211.c       |    8 ++++++++
 4 files changed, 16 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 26e9113..32a2f1b 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1161,6 +1161,7 @@ struct mesh_config {
  * @sync_method: which synchronization method to use
  * @path_sel_proto: which path selection protocol to use
  * @path_metric: which metric to use
+ * @auth_id: which authentication method this mesh is using
  * @ie: vendor information elements (optional)
  * @ie_len: length of vendor information elements
  * @is_authenticated: this mesh requires authentication
@@ -1179,6 +1180,7 @@ struct mesh_setup {
 	u8 sync_method;
 	u8 path_sel_proto;
 	u8 path_metric;
+	u8 auth_id;
 	const u8 *ie;
 	u8 ie_len;
 	bool is_authenticated;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index b484307..0632071 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2645,6 +2645,10 @@ enum nl80211_meshconf_params {
  * @NL80211_MESH_SETUP_USERSPACE_MPM: Enable this option if userspace will
  *	implement an MPM which handles peer allocation and state.
  *
+ * @NL80211_MESH_SETUP_AUTH_PROTOCOL: Inform the kernel of the authentication
+ *	method (u8, as defined in IEEE 8.4.2.100.6, e.g. 0x1 for SAE).
+ *	Default is no authentication method required.
+ *
  * @NL80211_MESH_SETUP_ATTR_MAX: highest possible mesh setup attribute number
  *
  * @__NL80211_MESH_SETUP_ATTR_AFTER_LAST: Internal use
@@ -2658,6 +2662,7 @@ enum nl80211_mesh_setup_params {
 	NL80211_MESH_SETUP_USERSPACE_AMPE,
 	NL80211_MESH_SETUP_ENABLE_VENDOR_SYNC,
 	NL80211_MESH_SETUP_USERSPACE_MPM,
+	NL80211_MESH_SETUP_AUTH_PROTOCOL,
 
 	/* keep last */
 	__NL80211_MESH_SETUP_ATTR_AFTER_LAST,
diff --git a/net/wireless/mesh.c b/net/wireless/mesh.c
index 0bb93f3..9546ad2 100644
--- a/net/wireless/mesh.c
+++ b/net/wireless/mesh.c
@@ -82,6 +82,7 @@ const struct mesh_setup default_mesh_setup = {
 	.sync_method = IEEE80211_SYNC_METHOD_NEIGHBOR_OFFSET,
 	.path_sel_proto = IEEE80211_PATH_PROTOCOL_HWMP,
 	.path_metric = IEEE80211_PATH_METRIC_AIRTIME,
+	.auth_id = 0, /* open */
 	.ie = NULL,
 	.ie_len = 0,
 	.is_secure = false,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 9cdcd9e..5f10f7a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -4672,6 +4672,7 @@ static const struct nla_policy
 	[NL80211_MESH_SETUP_ENABLE_VENDOR_PATH_SEL] = { .type = NLA_U8 },
 	[NL80211_MESH_SETUP_ENABLE_VENDOR_METRIC] = { .type = NLA_U8 },
 	[NL80211_MESH_SETUP_USERSPACE_AUTH] = { .type = NLA_FLAG },
+	[NL80211_MESH_SETUP_AUTH_PROTOCOL] = { .type = NLA_U8 },
 	[NL80211_MESH_SETUP_USERSPACE_MPM] = { .type = NLA_FLAG },
 	[NL80211_MESH_SETUP_IE] = { .type = NLA_BINARY,
 				    .len = IEEE80211_MAX_DATA_LEN },
@@ -4857,6 +4858,13 @@ static int nl80211_parse_mesh_setup(struct genl_info *info,
 	if (setup->is_secure)
 		setup->user_mpm = true;
 
+	if (tb[NL80211_MESH_SETUP_AUTH_PROTOCOL]) {
+		if (!setup->user_mpm)
+			return -EINVAL;
+		setup->auth_id =
+			nla_get_u8(tb[NL80211_MESH_SETUP_AUTH_PROTOCOL]);
+	}
+
 	return 0;
 }
 
-- 
1.7.9.5


^ permalink raw reply related

* [PATCH v3 2/2] mac80211: enable Auth Protocol Identifier on mesh config.
From: Colleen Twitty @ 2013-05-08 18:46 UTC (permalink / raw)
  To: Johannes Berg; +Cc: open80211s, linux-wirelss
In-Reply-To: <1368038760-17752-1-git-send-email-colleen@cozybit.com>

Previously the mesh_auth_id was disabled.  Instead set the
correct mesh authentication bit based on the mesh setup.

Signed-off-by: Colleen Twitty <colleen@cozybit.com>
---
 net/mac80211/cfg.c  |    1 +
 net/mac80211/mesh.c |    1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 1f51bdf..65b9cab 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1746,6 +1746,7 @@ static int copy_mesh_setup(struct ieee80211_if_mesh *ifmsh,
 	ifmsh->mesh_pp_id = setup->path_sel_proto;
 	ifmsh->mesh_pm_id = setup->path_metric;
 	ifmsh->user_mpm = setup->user_mpm;
+	ifmsh->mesh_auth_id = setup->auth_id;
 	ifmsh->security = IEEE80211_MESH_SEC_NONE;
 	if (setup->is_authenticated)
 		ifmsh->security |= IEEE80211_MESH_SEC_AUTHED;
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 6952760..c13db9a 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -748,7 +748,6 @@ int ieee80211_start_mesh(struct ieee80211_sub_if_data *sdata)
 	ieee80211_configure_filter(local);
 
 	ifmsh->mesh_cc_id = 0;	/* Disabled */
-	ifmsh->mesh_auth_id = 0;	/* Disabled */
 	/* register sync ops from extensible synchronization framework */
 	ifmsh->sync_ops = ieee80211_mesh_sync_ops_get(ifmsh->mesh_sp_id);
 	ifmsh->adjusting_tbtt = false;
-- 
1.7.9.5


^ permalink raw reply related

* Re: Memory leak in mwifiex_cfg80211_scan
From: Daniel Drake @ 2013-05-08 19:23 UTC (permalink / raw)
  To: Bing Zhao; +Cc: linux-wireless@vger.kernel.org, Amitkumar Karwar
In-Reply-To: <477F20668A386D41ADCC57781B1F70430DD2CA03F7@SC-VEXCH1.marvell.com>

On Wed, May 8, 2013 at 11:58 AM, Bing Zhao <bzhao@marvell.com> wrote:
> Thanks for the comment. Please find attached updated patch.

This looks better, thanks.

Daniel

^ permalink raw reply

* [PATCH] mwifiex: fix setting of multicast filter
From: Daniel Drake @ 2013-05-08 19:37 UTC (permalink / raw)
  To: linville; +Cc: linux-wireless

A small bug in this code was causing the ALLMULTI filter to be set
when in fact we were just wanting to program a selective multicast list
to the hardware.

Fix that bug and remove a redundant if condition in the code that
follows.

This fixes wakeup behaviour when multicast WOL is enabled. Previously,
all multicast packets would wake up the system. Now, only those that the
host intended to receive trigger wakeups.

Signed-off-by: Daniel Drake <dsd@laptop.org>
---
 drivers/net/wireless/mwifiex/sta_ioctl.c | 21 ++++++---------------
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/mwifiex/sta_ioctl.c b/drivers/net/wireless/mwifiex/sta_ioctl.c
index 311d0b2..1a8a19d 100644
--- a/drivers/net/wireless/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/mwifiex/sta_ioctl.c
@@ -96,7 +96,7 @@ int mwifiex_request_set_multicast_list(struct mwifiex_private *priv,
 	} else {
 		/* Multicast */
 		priv->curr_pkt_filter &= ~HostCmd_ACT_MAC_PROMISCUOUS_ENABLE;
-		if (mcast_list->mode == MWIFIEX_MULTICAST_MODE) {
+		if (mcast_list->mode == MWIFIEX_ALL_MULTI_MODE) {
 			dev_dbg(priv->adapter->dev,
 				"info: Enabling All Multicast!\n");
 			priv->curr_pkt_filter |=
@@ -108,20 +108,11 @@ int mwifiex_request_set_multicast_list(struct mwifiex_private *priv,
 				dev_dbg(priv->adapter->dev,
 					"info: Set multicast list=%d\n",
 				       mcast_list->num_multicast_addr);
-				/* Set multicast addresses to firmware */
-				if (old_pkt_filter == priv->curr_pkt_filter) {
-					/* Send request to firmware */
-					ret = mwifiex_send_cmd_async(priv,
-						HostCmd_CMD_MAC_MULTICAST_ADR,
-						HostCmd_ACT_GEN_SET, 0,
-						mcast_list);
-				} else {
-					/* Send request to firmware */
-					ret = mwifiex_send_cmd_async(priv,
-						HostCmd_CMD_MAC_MULTICAST_ADR,
-						HostCmd_ACT_GEN_SET, 0,
-						mcast_list);
-				}
+				/* Send multicast addresses to firmware */
+				ret = mwifiex_send_cmd_async(priv,
+					HostCmd_CMD_MAC_MULTICAST_ADR,
+					HostCmd_ACT_GEN_SET, 0,
+					mcast_list);
 			}
 		}
 	}
-- 
1.8.1.4


^ permalink raw reply related

* Re: Linux driver for Realtek RTL8723AU devices with USB ID 0bda:1724 such as found in Lenovo IdeaPad Yoga 13
From: Larry Finger @ 2013-05-08 20:17 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: linux-wireless, LKML, netdev, Dan Williams, 'George0505',
	Joon Ro, Greg KH
In-Reply-To: <518A7D56.3050502@zytor.com>

On 05/08/2013 11:29 AM, H. Peter Anvin wrote:
> On 05/08/2013 09:06 AM, Larry Finger wrote:
>> On 05/07/2013 09:32 PM, H. Peter Anvin wrote:
>>>
>>> So I can verify that this driver works against 3.8.11 (not against
>>> current -linus because of a build failure), and yes, there is Bluetooth
>>> in this device.  In fact, it seems to work better than some in-tree
>>> drivers I have seen in the past.
>>>
>>> However, I'm confused as to the above and what it implies for the
>>> purpose of the staging tree.  Wasn't the whole point of the staging tree
>>> to have a working-but-ugly driver upstream and have the work to clean it
>>> up happen in the mainline tree instead of off somewhere.
>>
>> Yes, but even staging has some standards. For example, they frown on
>> inclusion of firmware in a massive data block in a file in the driver -
>> it should be in a separate file the /lib/firmware/ tree. In addition,
>> the mainline drivers/net/wireless/ tree is only available to devices
>> that use mac80211 for the software-based MAC layer. That conversion is a
>> serious effort that may never be done, thus the 8723au driver may never
>> leave staging.
>>
>> What are the details of the build failure on the mainline tree? It
>> builds fine here. One possibility is that your source tree has a
>> leftover copy of include/linux/version.h that contains a stale coded
>> value of the kernel version. I just pushed a Makefile fix that causes
>> the compiler to look in the new location for version.h first. If that
>> doesn't work, please post the error.
>>
>
> Unlikely, since the kernel source tree is clean.
>
> The error is on os_dep/os_intfs.c:
>
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c: In function ‘rtw_proc_init_one’:
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:315:3: error: implicit declaration
> of function ‘create_proc_entry’ [-Werror=implicit-function-declaration]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:315:11: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:322:3: error: implicit declaration
> of function ‘create_proc_read_entry’ [-Werror=implicit-function-declaration]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:322:9: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:333:21: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:364:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:370:7: error: dereferencing pointer
> to incomplete type
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:372:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:378:7: error: dereferencing pointer
> to incomplete type
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:381:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:389:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:397:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:405:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:412:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:419:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:426:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:433:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:440:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:447:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:454:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:461:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:468:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:475:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:482:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:489:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:496:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:505:9: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:512:9: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:522:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:539:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:545:7: error: dereferencing pointer
> to incomplete type
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:547:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:553:7: error: dereferencing pointer
> to incomplete type
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:555:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:561:7: error: dereferencing pointer
> to incomplete type
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:563:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:569:7: error: dereferencing pointer
> to incomplete type
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:572:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:576:8: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:582:7: error: dereferencing pointer
> to incomplete type

I just pushed a "fix" that will allow the driver to build on kernel 3.10-rc0 
(aka 3.9-git). This one removes all the procfs stuff. It will be added back in 
/sysfs later.

Larry



^ permalink raw reply

* RE: [PATCH] mwifiex: fix setting of multicast filter
From: Bing Zhao @ 2013-05-08 21:04 UTC (permalink / raw)
  To: Daniel Drake, linville@tuxdriver.com; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20130508193719.BC51FFA9CF@dev.laptop.org>

Hi Daniel,

Thanks for the patch.

> A small bug in this code was causing the ALLMULTI filter to be set
> when in fact we were just wanting to program a selective multicast list
> to the hardware.
> 
> Fix that bug and remove a redundant if condition in the code that
> follows.
> 
> This fixes wakeup behaviour when multicast WOL is enabled. Previously,
> all multicast packets would wake up the system. Now, only those that the
> host intended to receive trigger wakeups.
> 
> Signed-off-by: Daniel Drake <dsd@laptop.org>

Cc: <stable@vger.kernel.org>
Acked-by: Bing Zhao <bzhao@marvell.com>

Regards,
Bing

> ---
>  drivers/net/wireless/mwifiex/sta_ioctl.c | 21 ++++++---------------
>  1 file changed, 6 insertions(+), 15 deletions(-)


^ permalink raw reply

* [PATCH] ath9k:  Disable spectral scan code to fix crash on rmmod.
From: greearb @ 2013-05-08 22:08 UTC (permalink / raw)
  To: linux-wireless; +Cc: ath9k-devel, Ben Greear

From: Ben Greear <greearb@candelatech.com>

With CONFIG_ATH9K_DEBUGFS enabled, and slub memory poisoning
enabled, I see this crash on rmmod of ath9k.  I'm not sure how
to fix this properly, but in the meantime, this patch to disable
the spectral scan code works around the problem for me.

With memory poisoning and the verify_mem_not_deleted code
below added, the crash looks as follows...  The dentry
is not *always* freed at this point, probably because rcu
callbacks haven't completed.  You still get a crash soon
after, however.

Problem appears to be introduced by commit:

commit e93d083f42a126b5ad8137b5f0e8d6f900b332b8
Author: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
Date:   Tue Jan 8 14:48:58 2013 +0100

    ath9k: add spectral scan feature

    Adds the spectral scan feature for ath9k. AR92xx and AR93xx chips
    are supported for now. The spectral scan is triggered by configuring
    a mode through a debugfs control file. Samples can be gathered via
    another relay debugfs file.

static int remove_buf_file_handler(struct dentry *dentry)
{
    printk("dentry: %p\n", dentry);
    verify_mem_not_deleted(dentry);
    debugfs_remove(dentry);

    return 0;
}

lec2010-ath9k-1 login: [   64.320480] rfs_chan_spec_scan: f7318000
[   64.325371] dentry: f2fbb8f8
[   64.328627] =============================================================================
[   64.329412] BUG dentry (Tainted: G         C  ): Object is on free-list
[   64.329412] -----------------------------------------------------------------------------
[   64.329412]
[   64.329412] Disabling lock debugging due to kernel taint
[   64.329412] INFO: Allocated in __d_alloc+0x22/0x140 age=42489 cpu=1 pid=337
[   64.329412]  __slab_alloc.clone.3+0x64e/0x6e0
[   64.329412]  kmem_cache_alloc+0x13a/0x150
[   64.329412]  __d_alloc+0x22/0x140
[   64.329412]  d_alloc+0x20/0x80
[   64.329412]  lookup_dcache+0x79/0xa0
[   64.383501]  __lookup_hash+0x22/0x40
[   64.383501]  lookup_one_len+0xe1/0x130
[   64.383501]  __create_file+0x6b/0x280
[   64.383501]  debugfs_create_file+0x2e/0x40
[   64.383501]  create_buf_file_handler+0x26/0x40 [ath9k]
[   64.383501]  relay_create_buf_file+0x89/0xb0
[   64.383501]  relay_open_buf+0x171/0x250
[   64.383501]  relay_open+0x142/0x230
[   64.383501]  ath9k_init_debug+0x34c/0x4b0 [ath9k]
[   64.383501]  ath9k_init_device+0x67e/0x9e0 [ath9k]
[   64.383501]  ath_pci_probe+0x1ff/0x2f0 [ath9k]
[   64.383501] INFO: Freed in __d_free+0x34/0x50 age=129 cpu=1 pid=2065
[   64.383501]  __slab_free+0x2eb/0x460
[   64.383501]  kmem_cache_free+0x1a4/0x1b0
[   64.383501]  __d_free+0x34/0x50
[   64.383501]  rcu_process_callbacks+0x1e6/0x5f0
[   64.383501]  __do_softirq+0xba/0x250
[   64.383501]  irq_exit+0xb5/0xc0
[   64.383501]  smp_apic_timer_interrupt+0x59/0x88
[   64.383501]  apic_timer_interrupt+0x39/0x40
[   64.383501]  __slab_free+0x2cd/0x460
[   64.383501]  kmem_cache_free+0x1a4/0x1b0
[   64.383501]  unlink_anon_vmas+0xf3/0x160
[   64.383501]  free_pgtables+0x89/0xf0
[   64.383501]  exit_mmap+0x84/0x130
[   64.383501]  mmput+0x57/0x100
[   64.383501]  flush_old_exec+0x2d4/0x690
[   64.383501]  load_elf_binary+0x24b/0x1620
[   64.383501] INFO: Slab 0xf6634760 objects=12 used=1 fp=0xf2fbb000 flags=0x40000081
[   64.383501] INFO: Object 0xf2fbb8f8 @offset=2296 fp=0xf2fbb7b0
[   64.383501]
[   64.383501] Bytes b4 f2fbb8e8: 01 00 00 00 11 08 00 00 20 67 fc ff 5a 5a 5a 5a  ........ g..ZZZZ
[   64.383501] Object f2fbb8f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[   64.383501] Object f2fbb908: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[   64.383501] Object f2fbb918: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[   64.383501] Object f2fbb928: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[   64.383501] Object f2fbb938: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[   64.383501] Object f2fbb948: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[   64.383501] Object f2fbb958: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[   64.383501] Object f2fbb968: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[   64.383501] Object f2fbb978: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
[   64.383501] Object f2fbb988: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5              kkkkkkkkkkk.
[   64.383501] Redzone f2fbb994: bb bb bb bb                                      ....
[   64.383501] Padding f2fbba3c: 5a 5a 5a 5a                                      ZZZZ
[   64.383501] Pid: 2064, comm: rmmod Tainted: G    B    C   3.9.1+ #6
[   64.383501] Call Trace:
[   64.383501]  [<c055549d>] print_trailer+0xdd/0x130
[   64.383501]  [<c055552c>] object_err+0x3c/0x50
[   64.383501]  [<c0556ffd>] verify_mem_not_deleted+0xed/0x160
[   64.383501]  [<f875c995>] remove_buf_file_handler+0x25/0x40 [ath9k]
[   64.383501]  [<c04e3088>] relay_remove_buf+0x18/0x30
[   64.383501]  [<c04e30fe>] relay_close_buf+0x2e/0x40
[   64.383501]  [<c04e3187>] relay_close+0x77/0xf0
[   64.383501]  [<f8749684>] ath9k_deinit_softc+0xb4/0xc0 [ath9k]
[   64.383501]  [<f87496d8>] ath9k_deinit_device+0x48/0x60 [ath9k]
[   64.383501]  [<f8759811>] ath_pci_remove+0x31/0x50 [ath9k]
[   64.383501]  [<c06dbff8>] pci_device_remove+0x38/0xc0
[   64.383501]  [<c079daa4>] __device_release_driver+0x64/0xc0
[   64.383501]  [<c079db97>] driver_detach+0x97/0xa0
[   64.383501]  [<c079cacc>] bus_remove_driver+0x6c/0xe0
[   64.383501]  [<c079c197>] ? bus_put+0x17/0x20
[   64.383501]  [<c079cae3>] ? bus_remove_driver+0x83/0xe0
[   64.383501]  [<c079e709>] driver_unregister+0x49/0x80
[   64.383501]  [<c06dc138>] pci_unregister_driver+0x18/0x80
[   64.383501]  [<f8759622>] ath_pci_exit+0x12/0x20 [ath9k]
[   64.383501]  [<f8762d30>] ath9k_exit+0x17/0x2e7 [ath9k]
[   64.383501]  [<c09e537d>] ? mutex_unlock+0xd/0x10
[   64.383501]  [<c04bd36c>] sys_delete_module+0x17c/0x250
[   64.383501]  [<c0540dc4>] ? do_munmap+0x244/0x2d0
[   64.383501]  [<c0540e96>] ? vm_munmap+0x46/0x60
[   64.383501]  [<c09e8dc4>] ? restore_all+0xf/0xf
[   64.383501]  [<c09ebf50>] ? __do_page_fault+0x4c0/0x4c0
[   64.383501]  [<c04b18e4>] ? trace_hardirqs_on_caller+0xf4/0x180
[   64.383501]  [<c09ef28d>] sysenter_do_call+0x12/0x38
[   64.889940] BUG: unable to handle kernel paging request at 6b6b6b8b
[   64.890530] IP: [<c063d0d6>] debugfs_remove+0x26/0x80
[   64.890530] *pdpt = 000000002f1dc001 *pde = 0000000000000000
[   64.890530] Oops: 0000 [#1] PREEMPT SMP
[   64.890530] Modules linked in: fuse macvlan pktgen nfsv3 nfs_acl nfsv4 auth_rpcgss nfs fscache lockdo
[   64.890530] Pid: 2064, comm: rmmod Tainted: G    B    C   3.9.1+ #6 To Be Filled By O.E.M. To Be Fil.
[   64.890530] EIP: 0060:[<c063d0d6>] EFLAGS: 00010202 CPU: 0
[   64.890530] EIP is at debugfs_remove+0x26/0x80
[   64.890530] EAX: f2fbb8f8 EBX: f2fbb8f8 ECX: 00000000 EDX: 00000000
[   64.890530] ESI: 6b6b6b6b EDI: 00000001 EBP: ef255e00 ESP: ef255df8
[   64.890530]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[   64.890530] CR0: 8005003b CR2: 6b6b6b8b CR3: 2f238000 CR4: 000007e0
[   64.890530] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[   64.890530] DR6: ffff0ff0 DR7: 00000400
[   64.890530] Process rmmod (pid: 2064, ti=ef254000 task=efa192b0 task.ti=ef254000)
[   64.890530] Stack:
[   64.890530]  f2fbb8f8 0000000a ef255e14 f875c99c f87695e4 f2fbb8f8 f11a0170 ef255e20
[   64.890530]  c04e3088 f11a0170 ef255e2c c04e30fe f7318000 ef255e4c c04e3187 00000286
[   64.890530]  00000004 00000286 f24d1e20 0000000a 00000001 ef255e68 f8749684 f87689d4
[   64.890530] Call Trace:
[   64.890530]  [<f875c99c>] remove_buf_file_handler+0x2c/0x40 [ath9k]
[   64.890530]  [<c04e3088>] relay_remove_buf+0x18/0x30
[   64.890530]  [<c04e30fe>] relay_close_buf+0x2e/0x40
[   64.890530]  [<c04e3187>] relay_close+0x77/0xf0
[   64.890530]  [<f8749684>] ath9k_deinit_softc+0xb4/0xc0 [ath9k]
[   64.890530]  [<f87496d8>] ath9k_deinit_device+0x48/0x60 [ath9k]
[   64.890530]  [<f8759811>] ath_pci_remove+0x31/0x50 [ath9k]
[   64.890530]  [<c06dbff8>] pci_device_remove+0x38/0xc0
[   64.890530]  [<c079daa4>] __device_release_driver+0x64/0xc0
[   64.890530]  [<c079db97>] driver_detach+0x97/0xa0
[   64.890530]  [<c079cacc>] bus_remove_driver+0x6c/0xe0
[   64.890530]  [<c079c197>] ? bus_put+0x17/0x20
[   64.890530]  [<c079cae3>] ? bus_remove_driver+0x83/0xe0
[   64.890530]  [<c079e709>] driver_unregister+0x49/0x80
[   64.890530]  [<c06dc138>] pci_unregister_driver+0x18/0x80
[   64.890530]  [<f8759622>] ath_pci_exit+0x12/0x20 [ath9k]
[   64.890530]  [<f8762d30>] ath9k_exit+0x17/0x2e7 [ath9k]
[   64.890530]  [<c09e537d>] ? mutex_unlock+0xd/0x10
[   64.890530]  [<c04bd36c>] sys_delete_module+0x17c/0x250
[   64.890530]  [<c0540dc4>] ? do_munmap+0x244/0x2d0
[   64.890530]  [<c0540e96>] ? vm_munmap+0x46/0x60
[   64.890530]  [<c09e8dc4>] ? restore_all+0xf/0xf
[   64.890530]  [<c09ebf50>] ? __do_page_fault+0x4c0/0x4c0
[   64.890530]  [<c04b18e4>] ? trace_hardirqs_on_caller+0xf4/0x180
[   64.890530]  [<c09ef28d>] sysenter_do_call+0x12/0x38
[   64.890530] Code: 90 8d 74 26 00 55 89 e5 83 ec 08 89 1c 24 89 74 24 04 3e 8d 74 26 00 85 c0 89 c3 72
[   64.890530] EIP: [<c063d0d6>] debugfs_remove+0x26/0x80 SS:ESP 0068:ef255df8
[   64.890530] CR2: 000000006b6b6b8b
[   65.403974] ---[ end trace 5de288532140fead ]---

Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 ff3812c... b8f94fe... M	drivers/net/wireless/ath/ath9k/debug.c
:100644 100644 ee156e5... bf15c86... M	drivers/net/wireless/ath/ath9k/recv.c
 drivers/net/wireless/ath/ath9k/debug.c |    5 ++++-
 drivers/net/wireless/ath/ath9k/recv.c  |    4 ++--
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index ff3812c..b8f94fe 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -970,6 +970,7 @@ static const struct file_operations fops_recv = {
 	.llseek = default_llseek,
 };
 
+#if 0
 static ssize_t read_file_spec_scan_ctl(struct file *file, char __user *user_buf,
 				       size_t count, loff_t *ppos)
 {
@@ -1252,7 +1253,7 @@ static struct rchan_callbacks rfs_spec_scan_cb = {
 	.create_buf_file = create_buf_file_handler,
 	.remove_buf_file = remove_buf_file_handler,
 };
-
+#endif
 
 static ssize_t read_file_regidx(struct file *file, char __user *user_buf,
                                 size_t count, loff_t *ppos)
@@ -2071,6 +2072,7 @@ int ath9k_init_debug(struct ath_hw *ah)
 			    &fops_base_eeprom);
 	debugfs_create_file("modal_eeprom", S_IRUSR, sc->debug.debugfs_phy, sc,
 			    &fops_modal_eeprom);
+#if 0
 	sc->rfs_chan_spec_scan = relay_open("spectral_scan",
 					    sc->debug.debugfs_phy,
 					    262144, 4, &rfs_spec_scan_cb,
@@ -2088,6 +2090,7 @@ int ath9k_init_debug(struct ath_hw *ah)
 	debugfs_create_file("spectral_fft_period", S_IRUSR | S_IWUSR,
 			    sc->debug.debugfs_phy, sc,
 			    &fops_spectral_fft_period);
+#endif
 
 #ifdef CONFIG_ATH9K_MAC_DEBUG
 	debugfs_create_file("samples", S_IRUSR, sc->debug.debugfs_phy, sc,
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index ee156e5..bf15c86 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1016,7 +1016,7 @@ static void ath9k_rx_skb_postprocess(struct ath_common *common,
 		rxs->flag &= ~RX_FLAG_DECRYPTED;
 }
 
-#ifdef CONFIG_ATH9K_DEBUGFS
+#if 0 /*def CONFIG_ATH9K_DEBUGFS */
 static s8 fix_rssi_inv_only(u8 rssi_val)
 {
 	if (rssi_val == 128)
@@ -1029,7 +1029,7 @@ static s8 fix_rssi_inv_only(u8 rssi_val)
 static int ath_process_fft(struct ath_softc *sc, struct ieee80211_hdr *hdr,
 			   struct ath_rx_status *rs, u64 tsf)
 {
-#ifdef CONFIG_ATH9K_DEBUGFS
+#if 0 /*def CONFIG_ATH9K_DEBUGFS*/
 	struct ath_hw *ah = sc->sc_ah;
 	u8 bins[SPECTRAL_HT20_NUM_BINS];
 	u8 *vdata = (u8 *)hdr;
-- 
1.7.3.4


^ permalink raw reply related

* Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
From: Adrian Chadd @ 2013-05-08 22:45 UTC (permalink / raw)
  To: Ben Greear
  Cc: Sujith Manoharan, Felix Fietkau, Oleksij Rempel, ath9k-devel,
	linux-wireless
In-Reply-To: <518A784A.6040704@candelatech.com>

On 8 May 2013 09:07, Ben Greear <greearb@candelatech.com> wrote:

> I think it's good to keep global counters too..otherwise it is going to be
> a lot of work to gather per NIC stats, and since you would have to read for
> each
> station, your stats might not be quite as atomic as they used to be.
>
> But, I'm fine with adding per-station counters on top of the global
> stats.

As a reference point, one of my in-progress hacks in FreeBSD is to add
some macros to the ath(4) driver to keep per-state and global stats,
using the same sample pointers.

So, a macro would look like this:

ATH_STAT_INC(sc, ath_node, stat_name, 1);

* if I've enabled global stat counting, the sc->sc_stats.sc_stat_name
stat would be bumped.
* if I've enabled node stat counting, the
ath_node->an_stats.an_stat_name would be bumped.

I have similar ideas with net80211 - right now there's some per-node
stats, but lots of stats are per-VAP. I'm going to do the same thing -
take the vap and the node as part of the stat macro, and bump the
per-node and per-VAP stats. Again, leaving it as a build-time option.

I've found both global device / VAP stats _and_ per-node stats equally
useful for debugging. They're good for debugging different sets of
issues - I use the global stats for figuring out what is breaking
things, and I use the per-node stats to try and understand how the AP
is "viewing" a particular station, separate from all the other
stations currently chatting.

Stats are hard. Let's go shopping. :-)



Adrian



Adrian

^ permalink raw reply

* Re: atheros AR5B22, using ath9k, can't switch between inscure and WEP/WPA
From: Adrian Chadd @ 2013-05-08 22:46 UTC (permalink / raw)
  To: Wally; +Cc: linux-wireless
In-Reply-To: <1368015905.17674.11.camel@bigdick-desktop>

.. AR5B22? Which chip does that probe as?



Adrian


On 8 May 2013 05:25, Wally <wally.yeh@a-trust.com.tw> wrote:
> Hi, guys:
>     Recently I got a atheros mini-PCIE wifi module AR5B22, so I download
> the latest version of compat-driver(compat-drivers-2013-03-28.tar.gz),
> and build it for armel on my arm board, it works great but with one
> little problem:
>
> If I connect to an inscure AP then change to a WEP/WPA AP, I can't
> connect the inscure one again, I have to run "modprobe -r ath9k;
> modprobe ath9k" to connect the inscure AP.
>
>     I think this may be a bug in the ath9k driver, I also search this
> bug on web but without an answer, so I send this letter for help.
>
>     Any advice would be grateful, thanks.
>
> Wally
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* RE: Memory leak in mwifiex_cfg80211_scan
From: Bing Zhao @ 2013-05-08 23:27 UTC (permalink / raw)
  To: Daniel Drake; +Cc: linux-wireless@vger.kernel.org, Amitkumar Karwar
In-Reply-To: <CAMLZHHSZh7J-iA3aYwEFM5CsDpvystWTu8FfyysWckPcvv86Rg@mail.gmail.com>

Hi Daniel,

> > Thanks for the comment. Please find attached updated patch.
> 
> This looks better, thanks.

I will post these patches to the list after the 3.10 merge window.

905c907 mwifiex: scan delay timer cleanup in unload path
a11b504 mwifiex: rename mwifiex_free_adapter() routine in init.c
7841fa6 mwifiex: remove global user_scan_cfg variable

Thanks,
Bing

> 
> Daniel

^ permalink raw reply

* Re: atheros AR5B22, using ath9k, can't switch between inscure and WEP/WPA
From: Wally @ 2013-05-09  1:28 UTC (permalink / raw)
  To: Adrian Chadd; +Cc: linux-wireless
In-Reply-To: <CAJ-Vmonq1YN2NoWFMXtqVYr16eTD=mZ0n74CCEhMHK=05M1xyQ@mail.gmail.com>

Hi, Adrian:
    Here is it's wiki:http://wikidevi.com/wiki/Atheros_AR5B22

    As I modprobe ath9k. dmesg give these messages:
----------------------------------------------------------------------
[49603.281250] compat-drivers backport release:
compat-drivers-2013-03-28
[49603.281250] Backport based on linux-next.git next-20130328
[49603.281250] compat.git: linux-next.git
[49603.367187] cfg80211: Calling CRDA to update world regulatory domain
[49603.609375] ath: EEPROM regdomain: 0x60
[49603.609375] ath: EEPROM indicates we should expect a direct regpair
map
[49603.609375] ath: Country alpha2 being used: 00
[49603.609375] ath: Regpair used: 0x60
[49603.609375] ieee80211 phy0: Selected rate control algorithm
'ath9k_rate_control'
[49603.609375] Registered led device: ath9k-phy0
[49603.609375] ieee80211 phy0: Atheros AR9462 Rev:2 mem=0xe1300000,
irq=48
-----------------------------------------------------------------------
    so it seems ath9k probe this chip as Atheros AR9462. do you have
some idea? 

Wally



於 三,2013-05-08 於 15:46 -0700,Adrian Chadd 提到:
> .. AR5B22? Which chip does that probe as?
> 
> 
> 
> Adrian
> 
> 
> On 8 May 2013 05:25, Wally <wally.yeh@a-trust.com.tw> wrote:
> > Hi, guys:
> >     Recently I got a atheros mini-PCIE wifi module AR5B22, so I download
> > the latest version of compat-driver(compat-drivers-2013-03-28.tar.gz),
> > and build it for armel on my arm board, it works great but with one
> > little problem:
> >
> > If I connect to an inscure AP then change to a WEP/WPA AP, I can't
> > connect the inscure one again, I have to run "modprobe -r ath9k;
> > modprobe ath9k" to connect the inscure AP.
> >
> >     I think this may be a bug in the ath9k driver, I also search this
> > bug on web but without an answer, so I send this letter for help.
> >
> >     Any advice would be grateful, thanks.
> >
> > Wally
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html



^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox