I've seen two reports of devices that wrongly send a 1-byte reply to Get-Device-Status requests instead of a 2-byte reply. One was a printer and the other a mass-storage device.
This bug causes problems during USB resume, because finish_port_resume() checks the device status and concludes that something has gone wrong if it doesn't get a proper 2-byte reply. When autosuspend starts kicking in and at each autoresume the kernel thinks the device has gone away, obviously we're heading for trouble. In theory, lack of the second byte shouldn't matter much. According to the USB 2.0 spec it must always be equal to 0. So maybe we don't need to be such sticklers about insisting that it always be present. Does anybody object to the patch below? (Note that usb_get_status() returns the actual_length of the reply.) If there's no response, I'll submit it to Greg after a few days. Dave, you might want to try this with your printers. It might enable some of them to work with autosuspend. Alan Stern Index: usb-2.6/drivers/usb/core/hub.c =================================================================== --- usb-2.6.orig/drivers/usb/core/hub.c +++ usb-2.6/drivers/usb/core/hub.c @@ -1764,9 +1764,10 @@ static int finish_port_resume(struct usb * and device drivers will know about any resume quirks. */ if (status == 0) { + devstatus = 0; status = usb_get_status(udev, USB_RECIP_DEVICE, 0, &devstatus); if (status >= 0) - status = (status == 2 ? 0 : -ENODEV); + status = (status > 0 ? 0 : -ENODEV); } if (status) { ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel