On Thursday 15 October 2009, Oliver Neukum wrote: > > Can somebody explain to me why a waitqueue and the loop with msleep > is used? ISTR that when it was written, that was the best option. Recall that there could be several dozen RX urbs queued, and packets still streaming in over a network link, if the device is still even connected. So while that code is running, completions can be streaming in. And ... that particular code dates from somewhere back in the late 2.4 kernel days, so among other things it had to dodge quite a variety of HCD-specific bugs. They tended to cause oopsing in one or more of those code paths. That's commented somewhere else in the driver. Many or most of those HCD and usbcore issues should now be resolved. > This makes no sense to me. Is there some deep reasoning going on? Part of it is surely the need to dodge those HCD-specific oopsing code paths back in those 2.4 days. Getting URB queues to work back then was a bit dicey; any simple/obvious strategy oopsed some HCD. There's an open issue in that code, where if unlinks complete synchronously -- as they can, with some HCDs -- things misbehave. But I don't recall that anyone has submitted patches to change how that works. The code basically is very robust, except for that one case where some HCDs don't always unlink asynchronously. So there's not been much incentive to change it. Did you have some better solution in mind? - Dave -- 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
