On Sun, 22 Apr 2012, Ming Lei wrote: > On Sun, Apr 22, 2012 at 1:31 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Sat, 21 Apr 2012, Ming Lei wrote: > >> How about always scheduling a tasklet to run what usb_unlink_urb does? > >> just implement usb_unlink_urb as something like > >> tasklet_schedule(unlink_tasklet). > >> > >> Then we can have a uniform lock requirement and no changes are involved > >> on host controller drivers. > > > > The return values would not be correct. > > If you run 'git grep -n usb_unlink_urb drivers/usb/', it may show that > most of callers do not check its return value, and the others only check > for dumping warnings. If usb_unlink_urb is converted into tasklet > implementation, we still can dump these warnings inside its tasklet function. That sounds rather awkward. How would the "tasklet-ized" version of usb_unlink_urb know what warnings to issue? > > On the other hand, usbnet could call usb_unlink_urb from within a > > tasklet. > > Sorry, you mean tasklet_schedule can't be called inside a tasklet? What I meant is: If you're going to run in a tasklet, it doesn't matter whether the tasklet is started by the usb_unlink_urb function or by its caller. The end result should be the same either way. However Oliver has already objected to using a tasklet for unlinking. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html