On Sun, Feb 03, 2002 at 10:16:29AM +0100, Oliver Neukum wrote: > > >> > For this case, I'd argue that a driver shouldn't be allocating a urb > >> > within an interrupt at all :) > >> > >> In this case that can be done. But it's not an answer to all such problems. > > > >Why not? Are there other times we need to allocate an urb in this > >manner (where we can't call schedule())? > > Then you start coding around a limitation in the API. > As submitting with a spinlock held must work and needs a gfp > parameter to work cleanly, we might as well make a consistent change.
Hm, I'm almost persuaded. Anyone else have an opinion here? > >> int usb_revoke_urb_sync(struct urb *urb); > >> int usb_revoke_urb_async(struct urb *urb); > > > >Are you trying to split up the current usb_unlink_urb() case? Do you > >think this is really necessary? > > Much better. The networking drivers have a need to unlink > the same urb both asynchronously and synchronously. > Furthermore it allows functionality to be shifted from the HCDs > to usbcore. Ok, can you change it to usb_unlink_urb_sync() and usb_unlink_urb_async()? > >> void usb_wait_completion(struct urb *urb); > > > >I like this. It would probably clean up a lot of driver code, right? > > Make it free of races. As recent discussions have showed there's > a fundamental disagreement on how usb_unlink_urb() should > work with respect to running completion handlers. > As a completion handler may be running even after a synchronous > unlink has returned, almost all drivers have a race on disconnect. This is seen by lots of people in the visor driver :) thanks, greg k-h _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
