USB wifi adapter integration

Hi,

We weren't able to make it work even trying with multiple different Realtek based USB keys with the official Realtek driver so we changed to Atheros based keys with the kernel included ath9k_htc driver (branch origin/rowboat-am335x-kernel-3.2).

Using this setup we got it working but the driver was crashing when running with heavy network traffic on the wireless hotspot. We did a lot of tests using the ubuntu kernel also based on 3.2.0 which is not crashing and came up with with a working version by merging a small section of the ubuntu driver/usb/musb/musb_host.c into the TI version. 

As of now we have no idea how this patch influences the USB behaviour other than fixing our specific hotspot crash problem.

Can somebody tell us if it's safe to let this patch in our production kernel or if there is a better way to fix the problem doing something else?

I've included the patch below and also as an attachment along with the kernel crash dump.

Thanks

4478.ath_crash_dump.txt

8688.musb_host.patch.txt

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index f4919ca..bc7be6f 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -332,6 +332,8 @@ start:
 
 /* Context: caller owns controller lock, IRQs are blocked */
 static void musb_giveback(struct musb *musb, struct urb *urb, int status)
+__releases(musb->lock)
+__acquires(musb->lock)
 {
 	dev_dbg(musb->controller,
 			"complete %p %pF (%d), dev%d ep%d%s, %d/%d\n",
@@ -342,7 +344,10 @@ static void musb_giveback(struct musb *musb, struct urb *urb, int status)
 			urb->actual_length, urb->transfer_buffer_length
 			);
 
+	usb_hcd_unlink_urb_from_ep(musb_to_hcd(musb), urb);
+	spin_unlock(&musb->lock);
 	usb_hcd_giveback_urb(musb_to_hcd(musb), urb, status);
+	spin_lock(&musb->lock);
 }
 
 /* For bulk/interrupt endpoints only */
@@ -411,6 +416,7 @@ static void musb_advance_schedule(struct musb *musb, struct urb *urb,
 {
 	struct musb_qh		*qh = musb_ep_get_qh(hw_ep, is_in);
 	struct musb_hw_ep	*ep = qh->hw_ep;
+	int			ready = qh->is_ready;
 	int			status;
 
 	status = (urb->status == -EINPROGRESS) ? 0 : urb->status;
@@ -427,7 +433,9 @@ static void musb_advance_schedule(struct musb *musb, struct urb *urb,
 		break;
 	}
 
-	usb_hcd_unlink_urb_from_ep(musb_to_hcd(musb), urb);
+	qh->is_ready = 0;
+	musb_giveback(musb, urb, status);
+	qh->is_ready = ready;
 
 	/* reclaim resources (and bandwidth) ASAP; deschedule it, and
 	 * invalidate qh as soon as list_empty(&hep->urb_list)
@@ -493,17 +501,6 @@ static void musb_advance_schedule(struct musb *musb, struct urb *urb,
 		    hw_ep->epnum, is_in ? 'R' : 'T', next_urb(qh));
 		musb_start_urb(musb, is_in, qh);
 	}
-
-	/* if we had set the status as -ECANCELED for dequeued URBs
-	 * now the status has to be changed to -EINPROGRESS
-	 * stack/application will not like -ECANCELED status
-	 */
-	if (urb->status == -ECANCELED)
-		urb->status = -EINPROGRESS;
-
-	/* if URB is successfully completed then giveback in workqueue */
-	push_queue(musb, urb);
-	queue_work(musb->gb_queue, &musb->gb_work);
 }

Can you tell which is the source of this ubuntu 3.2.0 kernel? Meanwhile we shall go through this patch and see if it has any side effects.

Regards,

Arun

It's name is "3.2.0-52-generic". This corresponds to tag "Ubuntu-3.2.0-52.78" on git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git

Hi Francois,

Sorry, I completely missed to reply this thread.

Can you give the exact crash messages you got when you tried the atheros wifi dongle?

The section

Hi Arun,

The crash log is included in my earlier post. The file is named 4478.ath_crash_dump.txt.

Other than that, I'll try to isolate the code section as requested soon and I'll take a look at the link provided.

Thanks

Hi Arun,

I follow up on your fix isolation question.

I did some tests and the patch provided in my earlier post won't work if partially applied. The end results of a partially applied fix will range from kernel lockup on usb init to full kernel crash when using the atheros driver.

How's the investigation going on your side?

HI Francois,

The crash actually looks more from a atheros driver, than an issue with the MUSB driver. Can you analyse the USB packets and check if the atheros driver does not receive any of the expected packet in correct order?

It will be difficult for us to analyse the crash since we do not have the required hardware.

I think you should be safe to go ahead with the UBUNTU patch since all USB use cases will work without patch for the out of order giveback of URBs.

Regards,

Arun