All of lore.kernel.org
 help / color / mirror / Atom feed
From: <gregkh@linuxfoundation.org>
To: Larry.Finger@lwfinger.net, gregkh@linuxfoundation.org,
	james@nurealm.net, kvalo@codeaurora.org
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "rtlwifi: Fix scheduling while atomic error from commit 49f86ec21c01" has been added to the 4.6-stable tree
Date: Mon, 11 Jul 2016 15:48:29 -0700	[thread overview]
Message-ID: <146827730934140@kroah.com> (raw)


This is a note to let you know that I've just added the patch titled

    rtlwifi: Fix scheduling while atomic error from commit 49f86ec21c01

to the 4.6-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     rtlwifi-fix-scheduling-while-atomic-error-from-commit-49f86ec21c01.patch
and it can be found in the queue-4.6 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>From de26859dcf363d520cc44e59f6dcaf20ebe0aadf Mon Sep 17 00:00:00 2001
From: Larry Finger <Larry.Finger@lwfinger.net>
Date: Sat, 21 May 2016 11:50:35 -0500
Subject: rtlwifi: Fix scheduling while atomic error from commit 49f86ec21c01

From: Larry Finger <Larry.Finger@lwfinger.net>

commit de26859dcf363d520cc44e59f6dcaf20ebe0aadf upstream.

Commit 49f86ec21c01 ("rtlwifi: Change long delays to sleeps") was correct
for most cases; however, driver rtl8192ce calls the affected routines while
in atomic context. The kernel bug output is as follows:

BUG: scheduling while atomic: wpa_supplicant/627/0x00000002
[...]
  [<ffffffff815c2b39>] __schedule+0x899/0xad0
  [<ffffffff815c2dac>] schedule+0x3c/0x90
  [<ffffffff815c5bb2>] schedule_hrtimeout_range_clock+0xa2/0x120
  [<ffffffff810e8b80>] ? hrtimer_init+0x120/0x120
  [<ffffffff815c5ba6>] ? schedule_hrtimeout_range_clock+0x96/0x120
  [<ffffffff815c5c43>] schedule_hrtimeout_range+0x13/0x20
  [<ffffffff815c568f>] usleep_range+0x4f/0x70
  [<ffffffffa0667218>] rtl_rfreg_delay+0x38/0x50 [rtlwifi]
  [<ffffffffa06dd0e7>] rtl92c_phy_config_rf_with_headerfile+0xc7/0xe0 [rtl8192ce]

To fix this bug, three of the changes from delay to sleep are reverted.
Unfortunately, one of the changes involves a delay of 50 msec. The calling
code will be modified so that this long delay can be avoided; however,
this change is being pushed now to fix the problem in kernel 4.6.0.

Fixes: 49f86ec21c01 ("rtlwifi: Change long delays to sleeps")
Reported-by: James Feeney <james@nurealm.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: James Feeney <james@nurealm.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/wireless/realtek/rtlwifi/core.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -54,7 +54,7 @@ EXPORT_SYMBOL(channel5g_80m);
 void rtl_addr_delay(u32 addr)
 {
 	if (addr == 0xfe)
-		msleep(50);
+		mdelay(50);
 	else if (addr == 0xfd)
 		msleep(5);
 	else if (addr == 0xfc)
@@ -75,7 +75,7 @@ void rtl_rfreg_delay(struct ieee80211_hw
 		rtl_addr_delay(addr);
 	} else {
 		rtl_set_rfreg(hw, rfpath, addr, mask, data);
-		usleep_range(1, 2);
+		udelay(1);
 	}
 }
 EXPORT_SYMBOL(rtl_rfreg_delay);
@@ -86,7 +86,7 @@ void rtl_bb_delay(struct ieee80211_hw *h
 		rtl_addr_delay(addr);
 	} else {
 		rtl_set_bbreg(hw, addr, MASKDWORD, data);
-		usleep_range(1, 2);
+		udelay(1);
 	}
 }
 EXPORT_SYMBOL(rtl_bb_delay);


Patches currently in stable-queue which might be from Larry.Finger@lwfinger.net are

queue-4.6/rtlwifi-fix-scheduling-while-atomic-error-from-commit-49f86ec21c01.patch

                 reply	other threads:[~2016-07-11 23:49 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=146827730934140@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Larry.Finger@lwfinger.net \
    --cc=james@nurealm.net \
    --cc=kvalo@codeaurora.org \
    --cc=stable-commits@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.