On Thu, 5 Jul 2012, Lan Tianyu wrote:
> >> --- a/drivers/usb/core/config.c
> >> +++ b/drivers/usb/core/config.c
> >> @@ -702,9 +702,7 @@ int usb_get_configuration(struct usb_device *dev)
> >> if (result< 0) {
> >> dev_err(ddev, "unable to read config index %d "
> >> "descriptor/%s: %d\n", cfgno, "start", result);
> >> - dev_err(ddev, "chopping to %d config(s)\n", cfgno);
> >> - dev->descriptor.bNumConfigurations = cfgno;
> >> - break;
> >> + goto err;
> >
> > I really would prefer it if you goto err only when result != -EPIPE.
> > Otherwise, do the same thing as the existing code.
> Oh sorry. I miss your comment at your last mail. I get it. But return error is
> -71 (EPROTO)
-EPROTO is one possible low-level error, but there are lots of other
ones. By contrast, -EPIPE is the the only possible protocol-level
error.
> How about this?
> dev_err(ddev, "unable to read config index %d "
> "descriptor/%s: %d\n", cfgno, "start", result)
> if (result == -EPROTO)
> goto err;
> dev_err(ddev, "chopping to %d config(s)\n", cfgno);
> dev->descriptor.bNumConfigurations = cfgno;
> break;
> Why did you suggest "result != -EPIPE"?
If the problem was caused by a bug in the device's firmware, the most
likely response to a Get-Config-Descriptor request (other than actually
sending the descriptor information) is a stall. In that case
truncating the set of configs is the right approach. But if the
problem was caused by anything else, there's probably no way to
recover.
> And if we use it, the judgement should be before dev_err("chopping to %d
> config(s)\n"...).
> Becasue the error info is not necessary. Right?
Right.
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
