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
