[PATCH 0/2] iwlwifi fix for 2.6.35

[PATCH 0/2] iwlwifi fix for 2.6.35

[Wey-Yi Guy]

Don't check WEP keys in AP mode.
Also handle the scan abort condition, iwlwifi should not tell
mac80211 later when scan completed. 

Johannes Berg (2):
  iwlagn: do not check for AP mode for WEP keys
  iwlwifi: do not spuriously call ieee80211_scan_completed

these patches are also available from wireless-2.6 branch on
 git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git

 drivers/net/wireless/iwlwifi/iwl-agn.c  |    2 +-
 drivers/net/wireless/iwlwifi/iwl-scan.c |    6 ++++--
 2 files changed, 5 insertions(+), 3 deletions(-)

[PATCH 1/2] iwlagn: do not check for AP mode for WEP keys

[Wey-Yi Guy]

From: Johannes Berg <johannes.berg@intel.com>

Even when we configure WEP keys in AP mode
ones without a station pointer are default
keys, so don't check for AP mode here.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
 drivers/net/wireless/iwlwifi/iwl-agn.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index 10d7b9b..2d309d1 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -3386,7 +3386,7 @@ static int iwl_mac_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
 	 * in 1X mode.
 	 * In legacy wep mode, we use another host command to the uCode.
 	 */
-	if (key->alg == ALG_WEP && !sta && vif->type != NL80211_IFTYPE_AP) {
+	if (key->alg == ALG_WEP && !sta) {
 		if (cmd == SET_KEY)
 			is_default_wep_key = !priv->key_mapping_key;
 		else
-- 
1.7.0.4

Re: [PATCH 1/2] iwlagn: do not check for AP mode for WEP keys

[Johannes Berg]

On Wed, 2010-08-18 at 09:35 -0700, Wey-Yi Guy wrote:
> From: Johannes Berg <johannes.berg@intel.com>
> 
> Even when we configure WEP keys in AP mode
> ones without a station pointer are default
> keys, so don't check for AP mode here.

I don't think this needs to go into 2.6.35 (or 2.6.36, which I think you
meant?) since we don't support AP mode.

johannes

Re: [PATCH 1/2] iwlagn: do not check for AP mode for WEP keys

[Guy, Wey-Yi]

On Wed, 2010-08-18 at 09:40 -0700, Johannes Berg wrote:
> On Wed, 2010-08-18 at 09:35 -0700, Wey-Yi Guy wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> > 
> > Even when we configure WEP keys in AP mode
> > ones without a station pointer are default
> > keys, so don't check for AP mode here.
> 
> I don't think this needs to go into 2.6.35 (or 2.6.36, which I think you
> meant?) since we don't support AP mode.
> 
so 2.6.37?

Wey

[PATCH 2/2] iwlwifi: do not spuriously call ieee80211_scan_completed

[Wey-Yi Guy]

From: Johannes Berg <johannes.berg@intel.com>

When a scan is aborted because the corresponding
virtual interface is removed, we may still later
attempt to tell mac80211 that the scan completed.
This is obviously wrong, since we already told it
that it was aborted, so don't do that.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
 drivers/net/wireless/iwlwifi/iwl-scan.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-scan.c b/drivers/net/wireless/iwlwifi/iwl-scan.c
index a4b3663..0749363 100644
--- a/drivers/net/wireless/iwlwifi/iwl-scan.c
+++ b/drivers/net/wireless/iwlwifi/iwl-scan.c
@@ -511,6 +511,7 @@ void iwl_bg_scan_completed(struct work_struct *work)
 	struct iwl_priv *priv =
 	    container_of(work, struct iwl_priv, scan_completed);
 	bool internal = false;
+	bool scan_completed = false;
 
 	IWL_DEBUG_SCAN(priv, "SCAN complete scan\n");
 
@@ -521,7 +522,8 @@ void iwl_bg_scan_completed(struct work_struct *work)
 		priv->is_internal_short_scan = false;
 		IWL_DEBUG_SCAN(priv, "internal short scan completed\n");
 		internal = true;
-	} else {
+	} else if (priv->scan_request) {
+		scan_completed = true;
 		priv->scan_request = NULL;
 		priv->scan_vif = NULL;
 	}
@@ -552,7 +554,7 @@ void iwl_bg_scan_completed(struct work_struct *work)
 	 * into driver again into functions that will attempt to take
 	 * mutex.
 	 */
-	if (!internal)
+	if (scan_completed)
 		ieee80211_scan_completed(priv->hw, false);
 }
 EXPORT_SYMBOL(iwl_bg_scan_completed);
-- 
1.7.0.4

Re: [PATCH 2/2] iwlwifi: do not spuriously call ieee80211_scan_completed

[John W. Linville]

On Wed, Aug 18, 2010 at 09:35:22AM -0700, Wey-Yi Guy wrote:
> From: Johannes Berg <johannes.berg@intel.com>
> 
> When a scan is aborted because the corresponding
> virtual interface is removed, we may still later
> attempt to tell mac80211 that the scan completed.
> This is obviously wrong, since we already told it
> that it was aborted, so don't do that.
> 
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Does this really qualify as a fix for 2.6.36?  Is it a regression?
Does it generate an oops?  Or loss of connectivity?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: [PATCH 2/2] iwlwifi: do not spuriously call ieee80211_scan_completed

[Guy, Wey-Yi]

On Wed, 2010-08-18 at 09:44 -0700, John W. Linville wrote:
> On Wed, Aug 18, 2010 at 09:35:22AM -0700, Wey-Yi Guy wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> > 
> > When a scan is aborted because the corresponding
> > virtual interface is removed, we may still later
> > attempt to tell mac80211 that the scan completed.
> > This is obviously wrong, since we already told it
> > that it was aborted, so don't do that.
> > 
> > Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> > Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> 
> Does this really qualify as a fix for 2.6.36?  Is it a regression?
> Does it generate an oops?  Or loss of connectivity?
> 
Johannes, could you help to answer.

Thanks
Wey

RE: [PATCH 2/2] iwlwifi: do not spuriously call ieee80211_scan_completed

[Berg, Johannes]

> > When a scan is aborted because the corresponding
> > virtual interface is removed, we may still later
> > attempt to tell mac80211 that the scan completed.
> > This is obviously wrong, since we already told it
> > that it was aborted, so don't do that.


> Does this really qualify as a fix for 2.6.36?  Is it a regression?
> Does it generate an oops?  Or loss of connectivity?

It only creates a spurious warning.

johannes
--------------------------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland 
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052