pull request: wireless 2011-12-15

pull request: wireless 2011-12-15

[John W. Linville]

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

commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e

Dave,

Here are a few more fixes intended for the 3.2 release.  They are
all small and narrowly focused.

First is a one liner fix for a signedness problem in NFC that could
lead to an incorrect return code being propogated.  Next are two
iwlwifi regression fixes that received some recent attention on the
linux-wireless mailing list.  A third iwlwifi fix corrects a sequence
numbering error, which can cause a lot of bad behaviour in the wireless
network.  The ath9k fix corrects a potential for an array underrun.
Finally, the mwifiex fix corrects a double list deletion.

Please let me know if there are problems!

Thanks,

John

---

The following changes since commit 3f1e6d3fd37bd4f25e5b19f1c7ca21850426c33f:

  sch_gred: should not use GFP_KERNEL while holding a spinlock (2011-12-12 19:08:54 -0500)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem

Dan Carpenter (1):
      nfc: signedness bug in __nci_request()

Johannes Berg (1):
      iwlwifi: tx_sync only on PAN context

John W. Linville (1):
      Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem

Rajkumar Manoharan (1):
      ath9k: fix max phy rate at rate control init

Wey-Yi Guy (2):
      iwlwifi: do not set the sequence control bit is not needed
      iwlwifi: allow to switch to HT40 if not associated

Yogesh Ashok Powar (1):
      mwifiex: avoid double list_del in command cancel path

 drivers/net/wireless/ath/ath9k/rc.c         |    4 +++-
 drivers/net/wireless/iwlwifi/iwl-agn-rxon.c |    4 ++--
 drivers/net/wireless/iwlwifi/iwl-agn-tx.c   |    5 ++++-
 drivers/net/wireless/iwlwifi/iwl-agn.c      |    6 ++++++
 drivers/net/wireless/mwifiex/cmdevt.c       |    9 ++-------
 net/nfc/nci/core.c                          |    2 +-
 6 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/rc.c b/drivers/net/wireless/ath/ath9k/rc.c
index 888abc2..528d5f3 100644
--- a/drivers/net/wireless/ath/ath9k/rc.c
+++ b/drivers/net/wireless/ath/ath9k/rc.c
@@ -1271,7 +1271,9 @@ static void ath_rc_init(struct ath_softc *sc,
 
 	ath_rc_priv->max_valid_rate = k;
 	ath_rc_sort_validrates(rate_table, ath_rc_priv);
-	ath_rc_priv->rate_max_phy = ath_rc_priv->valid_rate_index[k-4];
+	ath_rc_priv->rate_max_phy = (k > 4) ?
+					ath_rc_priv->valid_rate_index[k-4] :
+					ath_rc_priv->valid_rate_index[k-1];
 	ath_rc_priv->rate_table = rate_table;
 
 	ath_dbg(common, ATH_DBG_CONFIG,
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c b/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
index a7a6def..5c7c17c 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c
@@ -606,8 +606,8 @@ int iwlagn_mac_config(struct ieee80211_hw *hw, u32 changed)
 			if (ctx->ht.enabled) {
 				/* if HT40 is used, it should not change
 				 * after associated except channel switch */
-				if (iwl_is_associated_ctx(ctx) &&
-				     !ctx->ht.is_40mhz)
+				if (!ctx->ht.is_40mhz ||
+						!iwl_is_associated_ctx(ctx))
 					iwlagn_config_ht40(conf, ctx);
 			} else
 				ctx->ht.is_40mhz = false;
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-tx.c b/drivers/net/wireless/iwlwifi/iwl-agn-tx.c
index 35a6b71..df1540c 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-tx.c
@@ -91,7 +91,10 @@ static void iwlagn_tx_cmd_build_basic(struct iwl_priv *priv,
 		tx_cmd->tid_tspec = qc[0] & 0xf;
 		tx_flags &= ~TX_CMD_FLG_SEQ_CTL_MSK;
 	} else {
-		tx_flags |= TX_CMD_FLG_SEQ_CTL_MSK;
+		if (info->flags & IEEE80211_TX_CTL_ASSIGN_SEQ)
+			tx_flags |= TX_CMD_FLG_SEQ_CTL_MSK;
+		else
+			tx_flags &= ~TX_CMD_FLG_SEQ_CTL_MSK;
 	}
 
 	iwlagn_tx_cmd_protection(priv, info, fc, &tx_flags);
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index bacc06c..e0e9a3d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -2850,6 +2850,9 @@ static int iwlagn_mac_tx_sync(struct ieee80211_hw *hw,
 	int ret;
 	u8 sta_id;
 
+	if (ctx->ctxid != IWL_RXON_CTX_PAN)
+		return 0;
+
 	IWL_DEBUG_MAC80211(priv, "enter\n");
 	mutex_lock(&priv->shrd->mutex);
 
@@ -2898,6 +2901,9 @@ static void iwlagn_mac_finish_tx_sync(struct ieee80211_hw *hw,
 	struct iwl_vif_priv *vif_priv = (void *)vif->drv_priv;
 	struct iwl_rxon_context *ctx = vif_priv->ctx;
 
+	if (ctx->ctxid != IWL_RXON_CTX_PAN)
+		return;
+
 	IWL_DEBUG_MAC80211(priv, "enter\n");
 	mutex_lock(&priv->shrd->mutex);
 
diff --git a/drivers/net/wireless/mwifiex/cmdevt.c b/drivers/net/wireless/mwifiex/cmdevt.c
index ac27815..6e0a3ea 100644
--- a/drivers/net/wireless/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/mwifiex/cmdevt.c
@@ -939,7 +939,6 @@ mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter)
 {
 	struct cmd_ctrl_node *cmd_node = NULL, *tmp_node = NULL;
 	unsigned long cmd_flags;
-	unsigned long cmd_pending_q_flags;
 	unsigned long scan_pending_q_flags;
 	uint16_t cancel_scan_cmd = false;
 
@@ -949,12 +948,9 @@ mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter)
 		cmd_node = adapter->curr_cmd;
 		cmd_node->wait_q_enabled = false;
 		cmd_node->cmd_flag |= CMD_F_CANCELED;
-		spin_lock_irqsave(&adapter->cmd_pending_q_lock,
-				  cmd_pending_q_flags);
-		list_del(&cmd_node->list);
-		spin_unlock_irqrestore(&adapter->cmd_pending_q_lock,
-				       cmd_pending_q_flags);
 		mwifiex_insert_cmd_to_free_q(adapter, cmd_node);
+		mwifiex_complete_cmd(adapter, adapter->curr_cmd);
+		adapter->curr_cmd = NULL;
 		spin_unlock_irqrestore(&adapter->mwifiex_cmd_lock, cmd_flags);
 	}
 
@@ -981,7 +977,6 @@ mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter)
 		spin_unlock_irqrestore(&adapter->mwifiex_cmd_lock, cmd_flags);
 	}
 	adapter->cmd_wait_q.status = -1;
-	mwifiex_complete_cmd(adapter, adapter->curr_cmd);
 }
 
 /*
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 3925c65..ea66034 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -69,7 +69,7 @@ static int __nci_request(struct nci_dev *ndev,
 	__u32 timeout)
 {
 	int rc = 0;
-	unsigned long completion_rc;
+	long completion_rc;
 
 	ndev->req_status = NCI_REQ_PEND;
 
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: pull request: wireless 2011-12-15

[Rafał Miłecki]

2011/12/15 John W. Linville <linville@tuxdriver.com>:
> commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e
>
> Dave,
>
> Here are a few more fixes intended for the 3.2 release.  They are
> all small and narrowly focused.

John, I've made a mistake and didn't use [PATCH 3.2] header to make it
clean my patch is fix. Could you take a look at
[PATCH] bcma: support for suspend and resume
please?

It's not one-liner, but fixes lock ups, which I believe - we really
want to avoid.

-- 
Rafał

Re: pull request: wireless 2011-12-15

[John W. Linville]

On Thu, Dec 15, 2011 at 09:04:29PM +0100, Rafał Miłecki wrote:
> 2011/12/15 John W. Linville <linville@tuxdriver.com>:
> > commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e
> >
> > Dave,
> >
> > Here are a few more fixes intended for the 3.2 release.  They are
> > all small and narrowly focused.
> 
> John, I've made a mistake and didn't use [PATCH 3.2] header to make it
> clean my patch is fix. Could you take a look at
> [PATCH] bcma: support for suspend and resume
> please?
> 
> It's not one-liner, but fixes lock ups, which I believe - we really
> want to avoid.

It's late in the release cycle, and Dave specifically asked me to slow down.

Are these suspend/resume lockups a regression?  Or have they always
been there?  Do they happen to everyone?

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

Re: pull request: wireless 2011-12-15

[David Miller]

From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 15 Dec 2011 14:15:24 -0500

> Here are a few more fixes intended for the 3.2 release.  They are
> all small and narrowly focused.
> 
> First is a one liner fix for a signedness problem in NFC that could
> lead to an incorrect return code being propogated.  Next are two
> iwlwifi regression fixes that received some recent attention on the
> linux-wireless mailing list.  A third iwlwifi fix corrects a sequence
> numbering error, which can cause a lot of bad behaviour in the wireless
> network.  The ath9k fix corrects a potential for an array underrun.
> Finally, the mwifiex fix corrects a double list deletion.
> 
> Please let me know if there are problems!

Pulled, thanks John.

Re: pull request: wireless 2011-12-15

[Rafał Miłecki]

W dniu 15 grudnia 2011 22:38 użytkownik John W. Linville
<linville@tuxdriver.com> napisał:
> On Thu, Dec 15, 2011 at 09:04:29PM +0100, Rafał Miłecki wrote:
>> 2011/12/15 John W. Linville <linville@tuxdriver.com>:
>> > commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e
>> >
>> > Dave,
>> >
>> > Here are a few more fixes intended for the 3.2 release.  They are
>> > all small and narrowly focused.
>>
>> John, I've made a mistake and didn't use [PATCH 3.2] header to make it
>> clean my patch is fix. Could you take a look at
>> [PATCH] bcma: support for suspend and resume
>> please?
>>
>> It's not one-liner, but fixes lock ups, which I believe - we really
>> want to avoid.
>
> It's late in the release cycle, and Dave specifically asked me to slow down.
>
> Are these suspend/resume lockups a regression?  Or have they always
> been there?  Do they happen to everyone?

The bug is present since first days of bcma. That's why I even decided
to add stable to CC.

Personally I've tested that only on 1 machine (I don't have more
suspendable machines with mini PCIe slot). However all Macbook 8.1/8.2
users have to remove b43 & bcma before suspending [0], they complain
about that since ever.

Arend: I know you're also complaining for suspend in bcma. Can you
comment on this?

[0] http://ubuntuforums.org/showthread.php?t=1695746

-- 
Rafał

Re: pull request: wireless 2011-12-15

[Rafał Miłecki]

W dniu 16 grudnia 2011 07:40 użytkownik Rafał Miłecki
<zajec5@gmail.com> napisał:
> W dniu 15 grudnia 2011 22:38 użytkownik John W. Linville
> <linville@tuxdriver.com> napisał:
>> On Thu, Dec 15, 2011 at 09:04:29PM +0100, Rafał Miłecki wrote:
>>> 2011/12/15 John W. Linville <linville@tuxdriver.com>:
>>> > commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e
>>> >
>>> > Dave,
>>> >
>>> > Here are a few more fixes intended for the 3.2 release.  They are
>>> > all small and narrowly focused.
>>>
>>> John, I've made a mistake and didn't use [PATCH 3.2] header to make it
>>> clean my patch is fix. Could you take a look at
>>> [PATCH] bcma: support for suspend and resume
>>> please?
>>>
>>> It's not one-liner, but fixes lock ups, which I believe - we really
>>> want to avoid.
>>
>> It's late in the release cycle, and Dave specifically asked me to slow down.
>>
>> Are these suspend/resume lockups a regression?  Or have they always
>> been there?  Do they happen to everyone?
>
> The bug is present since first days of bcma. That's why I even decided
> to add stable to CC.
>
> Personally I've tested that only on 1 machine (I don't have more
> suspendable machines with mini PCIe slot). However all Macbook 8.1/8.2
> users have to remove b43 & bcma before suspending [0], they complain
> about that since ever.
>
> Arend: I know you're also complaining for suspend in bcma. Can you
> comment on this?
>
> [0] http://ubuntuforums.org/showthread.php?t=1695746

User nephyrin on #bcm-users has confirmed this patch fixes
suspend&resume for him. Without this patch he got deadlock without
seeing any kernel panic logs - quite an ugly case.

I still think this patch may be worth taking as fix and backporting too.

-- 
Rafał

Re: pull request: wireless 2011-12-15

[Greg KH]

On Mon, Dec 26, 2011 at 12:36:59AM +0100, Rafał Miłecki wrote:
> W dniu 16 grudnia 2011 07:40 użytkownik Rafał Miłecki
> <zajec5@gmail.com> napisał:
> > W dniu 15 grudnia 2011 22:38 użytkownik John W. Linville
> > <linville@tuxdriver.com> napisał:
> >> On Thu, Dec 15, 2011 at 09:04:29PM +0100, Rafał Miłecki wrote:
> >>> 2011/12/15 John W. Linville <linville@tuxdriver.com>:
> >>> > commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e
> >>> >
> >>> > Dave,
> >>> >
> >>> > Here are a few more fixes intended for the 3.2 release.  They are
> >>> > all small and narrowly focused.
> >>>
> >>> John, I've made a mistake and didn't use [PATCH 3.2] header to make it
> >>> clean my patch is fix. Could you take a look at
> >>> [PATCH] bcma: support for suspend and resume
> >>> please?
> >>>
> >>> It's not one-liner, but fixes lock ups, which I believe - we really
> >>> want to avoid.
> >>
> >> It's late in the release cycle, and Dave specifically asked me to slow down.
> >>
> >> Are these suspend/resume lockups a regression?  Or have they always
> >> been there?  Do they happen to everyone?
> >
> > The bug is present since first days of bcma. That's why I even decided
> > to add stable to CC.
> >
> > Personally I've tested that only on 1 machine (I don't have more
> > suspendable machines with mini PCIe slot). However all Macbook 8.1/8.2
> > users have to remove b43 & bcma before suspending [0], they complain
> > about that since ever.
> >
> > Arend: I know you're also complaining for suspend in bcma. Can you
> > comment on this?
> >
> > [0] http://ubuntuforums.org/showthread.php?t=1695746
> 
> User nephyrin on #bcm-users has confirmed this patch fixes
> suspend&resume for him. Without this patch he got deadlock without
> seeing any kernel panic logs - quite an ugly case.
> 
> I still think this patch may be worth taking as fix and backporting too.

What patch specifically?  What is the git commit id of it in Linus's
tree?  Without that information, telling stable@ about it is
pointless...

greg k-h

Re: pull request: wireless 2011-12-15

[Rafał Miłecki]

W dniu 3 stycznia 2012 21:52 użytkownik Greg KH <greg@kroah.com> napisał:
> On Mon, Dec 26, 2011 at 12:36:59AM +0100, Rafał Miłecki wrote:
>> W dniu 16 grudnia 2011 07:40 użytkownik Rafał Miłecki
>> <zajec5@gmail.com> napisał:
>> > W dniu 15 grudnia 2011 22:38 użytkownik John W. Linville
>> > <linville@tuxdriver.com> napisał:
>> >> On Thu, Dec 15, 2011 at 09:04:29PM +0100, Rafał Miłecki wrote:
>> >>> 2011/12/15 John W. Linville <linville@tuxdriver.com>:
>> >>> > commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e
>> >>> >
>> >>> > Dave,
>> >>> >
>> >>> > Here are a few more fixes intended for the 3.2 release.  They are
>> >>> > all small and narrowly focused.
>> >>>
>> >>> John, I've made a mistake and didn't use [PATCH 3.2] header to make it
>> >>> clean my patch is fix. Could you take a look at
>> >>> [PATCH] bcma: support for suspend and resume
>> >>> please?
>> >>>
>> >>> It's not one-liner, but fixes lock ups, which I believe - we really
>> >>> want to avoid.
>> >>
>> >> It's late in the release cycle, and Dave specifically asked me to slow down.
>> >>
>> >> Are these suspend/resume lockups a regression?  Or have they always
>> >> been there?  Do they happen to everyone?
>> >
>> > The bug is present since first days of bcma. That's why I even decided
>> > to add stable to CC.
>> >
>> > Personally I've tested that only on 1 machine (I don't have more
>> > suspendable machines with mini PCIe slot). However all Macbook 8.1/8.2
>> > users have to remove b43 & bcma before suspending [0], they complain
>> > about that since ever.
>> >
>> > Arend: I know you're also complaining for suspend in bcma. Can you
>> > comment on this?
>> >
>> > [0] http://ubuntuforums.org/showthread.php?t=1695746
>>
>> User nephyrin on #bcm-users has confirmed this patch fixes
>> suspend&resume for him. Without this patch he got deadlock without
>> seeing any kernel panic logs - quite an ugly case.
>>
>> I still think this patch may be worth taking as fix and backporting too.
>
> What patch specifically?  What is the git commit id of it in Linus's
> tree?  Without that information, telling stable@ about it is
> pointless...

Sorry Greg, it's about

commit 775ab52142b02237a54184238e922251c59a2b5c
Author: Rafał Miłecki <zajec5@gmail.com>
Date:   Fri Dec 9 22:16:07 2011 +0100

    bcma: support for suspend and resume

    bcma used to lock up machine without enabling PCI or initializing CC.

    Cc: stable@vger.kernel.org
    Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

it's located in wireless-testing:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git

John didn't pass this to Linus yet.

-- 
Rafał

Re: pull request: wireless 2011-12-15

[Greg KH]

On Tue, Jan 03, 2012 at 11:06:59PM +0100, Rafał Miłecki wrote:
> W dniu 3 stycznia 2012 21:52 użytkownik Greg KH <greg@kroah.com> napisał:
> > On Mon, Dec 26, 2011 at 12:36:59AM +0100, Rafał Miłecki wrote:
> >> W dniu 16 grudnia 2011 07:40 użytkownik Rafał Miłecki
> >> <zajec5@gmail.com> napisał:
> >> > W dniu 15 grudnia 2011 22:38 użytkownik John W. Linville
> >> > <linville@tuxdriver.com> napisał:
> >> >> On Thu, Dec 15, 2011 at 09:04:29PM +0100, Rafał Miłecki wrote:
> >> >>> 2011/12/15 John W. Linville <linville@tuxdriver.com>:
> >> >>> > commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e
> >> >>> >
> >> >>> > Dave,
> >> >>> >
> >> >>> > Here are a few more fixes intended for the 3.2 release.  They are
> >> >>> > all small and narrowly focused.
> >> >>>
> >> >>> John, I've made a mistake and didn't use [PATCH 3.2] header to make it
> >> >>> clean my patch is fix. Could you take a look at
> >> >>> [PATCH] bcma: support for suspend and resume
> >> >>> please?
> >> >>>
> >> >>> It's not one-liner, but fixes lock ups, which I believe - we really
> >> >>> want to avoid.
> >> >>
> >> >> It's late in the release cycle, and Dave specifically asked me to slow down.
> >> >>
> >> >> Are these suspend/resume lockups a regression?  Or have they always
> >> >> been there?  Do they happen to everyone?
> >> >
> >> > The bug is present since first days of bcma. That's why I even decided
> >> > to add stable to CC.
> >> >
> >> > Personally I've tested that only on 1 machine (I don't have more
> >> > suspendable machines with mini PCIe slot). However all Macbook 8.1/8.2
> >> > users have to remove b43 & bcma before suspending [0], they complain
> >> > about that since ever.
> >> >
> >> > Arend: I know you're also complaining for suspend in bcma. Can you
> >> > comment on this?
> >> >
> >> > [0] http://ubuntuforums.org/showthread.php?t=1695746
> >>
> >> User nephyrin on #bcm-users has confirmed this patch fixes
> >> suspend&resume for him. Without this patch he got deadlock without
> >> seeing any kernel panic logs - quite an ugly case.
> >>
> >> I still think this patch may be worth taking as fix and backporting too.
> >
> > What patch specifically?  What is the git commit id of it in Linus's
> > tree?  Without that information, telling stable@ about it is
> > pointless...
> 
> Sorry Greg, it's about
> 
> commit 775ab52142b02237a54184238e922251c59a2b5c
> Author: Rafał Miłecki <zajec5@gmail.com>
> Date:   Fri Dec 9 22:16:07 2011 +0100
> 
>     bcma: support for suspend and resume
> 
>     bcma used to lock up machine without enabling PCI or initializing CC.
> 
>     Cc: stable@vger.kernel.org
>     Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
>     Signed-off-by: John W. Linville <linville@tuxdriver.com>
> 
> it's located in wireless-testing:
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
> 
> John didn't pass this to Linus yet.

Then there's nothing I can do about it.

As it's properly tagged, I'll pick it up when it gets to Linus.

thanks,

greg k-h