From: Richard Kennedy <richard@rsk.demon.co.uk>
To: gregkh <gregkh@suse.de>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: [PATCH 3/8] hfa384x_usb.c use newest version of 384x_drvr_start
Date: Mon, 03 Nov 2008 11:16:09 +0000 [thread overview]
Message-ID: <1225710969.3113.19.camel@castor.localdomain> (raw)
In-Reply-To: <1225710353.3113.5.camel@castor.localdomain>
include the needed fixes from Karl Relton
<karllinuxtest.relton@ntlworld.com>
see thread on linux-wlan-devel mailing list
"Possible cause of those pesky hfa384x_usbctlx_complete_sync errors"
Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk>
---
drivers/staging/wlan-ng/hfa384x_usb.c | 68 ++++++++++++++++++++++++++------
1 files changed, 55 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c b/drivers/staging/wlan-ng/hfa384x_usb.c
index 53c547d..4b1d24e 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -3140,19 +3140,38 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, UINT16 rid, void *buf, UINT16 len)
* Call context:
* process
----------------------------------------------------------------*/
+
int hfa384x_drvr_start(hfa384x_t *hw)
{
- int result;
+ int result, result1, result2;
+ u16 status;
DBFENTER;
might_sleep();
-
- if (usb_clear_halt(hw->usb, hw->endp_in)) {
+
+ /* Clear endpoint stalls - but only do this if the endpoint
+ * is showing a stall status. Some prism2 cards seem to behave
+ * badly if a clear_halt is called when the endpoint is already
+ * ok
+ */
+ result = usb_get_status(hw->usb, USB_RECIP_ENDPOINT, hw->endp_in, &status);
+ if (result < 0) {
+ WLAN_LOG_ERROR(
+ "Cannot get bulk in endpoint status.\n");
+ goto done;
+ }
+ if ((status == 1) && usb_clear_halt(hw->usb, hw->endp_in)) {
WLAN_LOG_ERROR(
"Failed to reset bulk in endpoint.\n");
}
- if (usb_clear_halt(hw->usb, hw->endp_out)) {
+ result = usb_get_status(hw->usb, USB_RECIP_ENDPOINT, hw->endp_out, &status);
+ if (result < 0) {
+ WLAN_LOG_ERROR(
+ "Cannot get bulk out endpoint status.\n");
+ goto done;
+ }
+ if ((status == 1) && usb_clear_halt(hw->usb, hw->endp_out)) {
WLAN_LOG_ERROR(
"Failed to reset bulk out endpoint.\n");
}
@@ -3169,18 +3188,41 @@ int hfa384x_drvr_start(hfa384x_t *hw)
goto done;
}
- /* call initialize */
- result = hfa384x_cmd_initialize(hw);
- if (result != 0) {
- usb_kill_urb(&hw->rx_urb);
- WLAN_LOG_ERROR(
- "cmd_initialize() failed, result=%d\n",
- result);
- goto done;
+ /* Call initialize twice, with a 1 second sleep in between.
+ * This is a nasty work-around since many prism2 cards seem to
+ * need time to settle after an init from cold. The second
+ * call to initialize in theory is not necessary - but we call
+ * it anyway as a double insurance policy:
+ * 1) If the first init should fail, the second may well succeed
+ * and the card can still be used
+ * 2) It helps ensures all is well with the card after the first
+ * init and settle time.
+ */
+ result1 = hfa384x_cmd_initialize(hw);
+ msleep(1000);
+ result = result2 = hfa384x_cmd_initialize(hw);
+ if (result1 != 0) {
+ if (result2 != 0) {
+ WLAN_LOG_ERROR(
+ "cmd_initialize() failed on two attempts, results %d and %d\n",
+ result1, result2);
+ usb_kill_urb(&hw->rx_urb);
+ goto done;
+ } else {
+ WLAN_LOG_DEBUG(0, "First cmd_initialize() failed (result %d),\n",
+ result1);
+ WLAN_LOG_DEBUG(0, "but second attempt succeeded. All should be ok\n");
+ }
+ } else if (result2 != 0) {
+ WLAN_LOG_WARNING(
+ "First cmd_initialize() succeeded, but second attempt failed (result=%d)\n",
+ result2);
+ WLAN_LOG_WARNING("Most likely the card will be functional\n");
+ goto done;
}
hw->state = HFA384x_STATE_RUNNING;
-
+
done:
DBFEXIT;
return result;
--
1.5.6.5
next prev parent reply other threads:[~2008-11-03 11:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-03 11:05 [PATCH 0/8] staging/wlan-ng: apply changes from wlan-ng-devel that get the driver working Richard Kennedy
2008-11-03 11:09 ` [PATCH 1/8] p80211netdev.c fix netdev alloc to prevent oops on device start Richard Kennedy
2008-11-03 11:13 ` [PATCH 2/8] prism2_usb.c always enable the card in probe_usb Richard Kennedy
2008-11-03 11:25 ` Oliver Neukum
2008-11-03 11:47 ` Richard Kennedy
2008-11-03 11:16 ` Richard Kennedy [this message]
2008-11-03 11:18 ` [PATCH 4/8] p80211netdev.c correctly enable wext handlers Richard Kennedy
2008-11-12 22:30 ` Greg KH
2008-11-03 11:20 ` [PATCH 5/8] p80211wext.c add latest changes & remove extra nulls from wext_handlers Richard Kennedy
2008-11-03 11:21 ` [PATCH 6/8] p80211wext don't set default key id twice Richard Kennedy
2008-11-03 11:22 ` [PATCH 7/8] hfa384x_usbin_callback: check for hardware removed Richard Kennedy
2008-11-03 11:24 ` [PATCH 8/8] p80211conv.c copy code from wlan-ng-devel branch to not drop packets Richard Kennedy
2008-11-12 23:15 ` patch staging-wlan-ng-p80211conv.c-copy-code-from-wlan-ng-devel-branch-to-not-drop-packets.patch added to gregkh-2.6 tree gregkh
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=1225710969.3113.19.camel@castor.localdomain \
--to=richard@rsk.demon.co.uk \
--cc=gregkh@suse.de \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®