Hi Greg, On Mon, Dec 30, 2013 at 12:04 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, Dec 30, 2013 at 11:46:13AM -0600, Bin Liu wrote: >> Hi, >> >> I have a case in which the class layer has tx and rx urbs in sequence, > > What "class layer"? This is a third party proprietary wifi driver sits on top of the usb stack, so I called it class (application) layer. Sorry for the confusion. BTY, I don't have the driver source code. > >> and the class layer expects the rx complete() should be called after >> the tx complete() is called. > > What driver expects this? Sounds like a bug in the driver. I was told the wifi driver is designed like that. And it works on other platforms (I don't know which specifically) including x86, but failed on MUSB+CPPI41. > >> But due to scheduling, I guess, sometimes the tx complete() is called >> after rx_complete(), which confuses the class layer. >> >> So normal case is >> - 1. submit tx/OUT urb; >> - 2. submit rx/IN urb; >> - 3. the device received the tx/OUT packet; >> - 4. the device sent rx/IN packet; >> - 5. tx complete() is called; >> - 6. rx complete() is called; >> >> But in failure case, step 5 & 6 are swapped. > > That's not a "failure", it's a "bug in the driver to assume something > like this would happen". By failure, I meant the wifi driver stopped working due the swapping above. Thanks, -Bin. > >> Is this considered as a bug in the host controller driver, which >> should guarantee the order of the sequence? Or it is a bug in the >> class layer, which should not rely on the behavior in core and host >> controller drivers? > > Again, what do you mean by "class layer"? > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
