On Wed, Apr 20, 2011 at 9:18 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 20 Apr 2011, Paul Stewart wrote: > >> Disambiguate between invalid URBs (ones that seem impossible >> to submit because they are broken) and ones that should not be >> submitted because they are already in flight. >> >> Signed-off-by: Paul Stewart <pstew@xxxxxxxxxxxx> >> --- >> drivers/usb/core/urb.c | 5 +++-- >> 1 files changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c >> index ae334b0..fd6bcdb 100644 >> --- a/drivers/usb/core/urb.c >> +++ b/drivers/usb/core/urb.c >> @@ -305,8 +305,10 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags) >> struct usb_host_endpoint *ep; >> int is_out; >> >> - if (!urb || urb->hcpriv || !urb->complete) >> + if (!urb || !urb->complete) >> return -EINVAL; >> + if (urb->hcpriv) >> + return -EALREADY; >> dev = urb->dev; >> if ((!dev) || (dev->state < USB_STATE_UNAUTHENTICATED)) >> return -ENODEV; > > 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. -- Paul -- 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
