On Fri, 22 Jun 2007, Pete Zaitcev wrote: > On Fri, 15 Jun 2007 12:55:42 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> > wrote: > > > > Autosuspend kills printers > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243038 > > > By the way, the symptoms with the two printers weren't quite the same. > > dave's disconnected itself, but Barry's issued a remote wakeup request > > (in spite of the fact that remote wakeup wasn't enabled) and then > > failed to respond to a Get-Device-Status query -- it returned 1 byte > > instead of 2. That failure is why it was disconnected. > > So, should we do something like this, then: > > diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c > index 739f520..971c7ad 100644 > --- a/drivers/usb/core/quirks.c > +++ b/drivers/usb/core/quirks.c > @@ -32,6 +32,8 @@ static const struct usb_device_id usb_quirk_list[] = { > { USB_DEVICE(0x03f0, 0x0701), .driver_info = USB_QUIRK_STRING_FETCH_255 > }, > /* Seiko Epson Corp - Perfection 1670 */ > { USB_DEVICE(0x04b8, 0x011f), .driver_info = USB_QUIRK_NO_AUTOSUSPEND }, > + /* Samsung ML-2010: wakes up by itself and cycles; bad GET_STATUS */ > + { USB_DEVICE(0x04e8, 0x326c), .driver_info = USB_QUIRK_NO_AUTOSUSPEND }, > /* Elsa MicroLink 56k (V.250) */ > { USB_DEVICE(0x05cc, 0x2267), .driver_info = USB_QUIRK_NO_AUTOSUSPEND }, > > > And then there's the Prolific, and maybe a bunch of others as well.
That's certainly one way to solve the problem. Likely things would still go wrong if the user tried to suspend-to-RAM... To tell the truth, it's a little discouraging to see how many different devices can't cope with being suspended. No doubt they were never tested properly because Windows doesn't do runtime suspend (as far as I know). > I am wondering if we should issue GET_STATUS for device first and see > how that goes. If it fails, disable the autosuspend. Although, what > to do if it crashes the device? We'd need to forward this knowledge > to the newly reconnected device somehow, maybe with some kind of a > dynamic blacklist... For a while there was a Get-Status call as part of enumeration and config selection. You can still see the remnants in a "#if 0" portion plus some preceding comments in choose_configuration() in generic.c; the Get-Status request was to find out if the device was self-powered or bus-powered. It was removed because some devices didn't like it and some lied about their power source. There's a pointer to Bugzilla #6448. Adding faulty devices to a blacklist is easy enough. I don't know how much farther we should go in trying to handle them. (And I'm still not sure about the best approach to use for hubs that can't suspend or resume some of their ports.) Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
