On Wed, 20 Apr 2011, Paul Stewart wrote: > > Is there a reason for this patch? Does it solve any problems for you? > > > > You mustn't change any of the USB stacks return codes without > > making the appropriate change to Documentation/usb/error-codes.txt. > > > > I'd like to disambiguate because in suspend-resume of usbnet, it is > unclear from the driver perspective whether the interrupt URB has been > (re) submitted, due to complications related to resume-time > enumeration of devices. I'd like to be able to say "the submit failed > because it is already submitted, not because of some other serious > error with the request. This is not a failure." Especially in the > case of interrupt URBs where you just want to assert that an URB is > perpetually in flight to catch device state changes, it's nice to be > able to partition off this case from others. I'll re-post the patch > with a change to the docs. Maybe... but I'm not so sure this is a good idea. That is, there's nothing wrong with changing the return code; that's harmless. But the mind set that leads you to _want_ to change the return code is very bad indeed. A driver should always keep track of its own URBs. In other words, this case (URB already in flight) should never come up at all -- and if it does, it most definitely _is_ a serious failure. Not a failure in the URB, but a failure in the driver. Bear in mind also that the code you changed is not 100% foolproof. There are windows during which an URB is still in flight but urb->hcpriv is NULL. Alan Stern -- 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
