On Thu, 25 Jan 2007, Oliver Neukum wrote: > > I think this patch could be generalized. We may have other quirks to > > worry about besides PM/autosuspend. This should become a general USB > > blacklist mechanism. > > If you want the grand solution, you shall get it.
Thank you. If only the rest of Life's problems could be solved so easily... > > One example that comes up immediately is the HP scanner which crashes > > when we try to read the string descriptors. Others may crop up in the > > future. > > Do you have the ID? Searching hasn't yielded what I need. The problematic HP scanner is identified in here: http://marc.theaimsgroup.com/?l=linux-usb-devel&m=116322995102416&w=2 It has these IDs: idVendor 0x03f0 Hewlett-Packard idProduct 0x0701 ScanJet 5300c/5370c bcdDevice 0.01 Probably a lot of HP devices suffer from the same bug. > > > +/* Power management quirks */ > > > +#define USB_PM_DISCONNECT 1 /* devices which disconnect when > > > resuming */ > > > > Make the name USB_QUIRK_NO_AUTOSUSPEND. We don't really care that the > > device disconnects when resuming; the only important part is that we > > should never try to autosuspend it. > > This seems contradictory. If you want a generic blacklisting, you cannot > limit the information to autosuspending. It isn't contradictory. Autosuspend requests come exclusively from within usbcore, and we can easily prevent ourselves from making them. But general suspend commands come from outside (generally from the user), and we cannot prevent them from arriving. > The device won't care why it > is suspended. Such devices should be treated differently under certain > situations. Either refuse to suspend or disconnect when asked to suspend. We can't refuse to suspend. The user wouldn't be able to do suspend-to-disk, for example. I'm not sure what you mean by "disconnect". Unbind the device from its drivers? Disable the port? That won't solve anything. And if the device is going to disconnect itself anyway, why do we need to bother? The fact is, some devices cannot resume correctly. If the user asks for them to be suspended and then resumed, we cannot always fix the resulting problem. The best we can do is to try a USB reset during the resume. However that is a completely separate matter from whether we should avoid autosuspending the device. We could add a USB_QUIRK_RESET_ON_RESUME flag. But it would be distinct from USB_QUIRK_NO_AUTOSUSPEND. > +#define USB_QUIRK_AUTOSUSPEND_DISCONNECT 1 /* devices which disconnect > when resuming */ No, no! I still say, we don't care what problem the device has with autosuspend. It might disconnect, it might crash, it might even explode! All we care about is that we shouldn't autosuspend it. > +/* > + * detect any quirks the device as opposed to the interfaces the device has > + */ > + > +void usb_detect_quirks(struct usb_device *udev) > +{ > + udev->quirks = usb_autosuspend_search_quirk(udev); > + > + if (udev->quirks & USB_QUIRK_AUTOSUSPEND_DISCONNECT) { > + /* unbalanced resume that'll prevent autosuspension */ > + usb_autoresume_device(udev); > + dev_dbg(&udev->dev, "USB power management quirks: %d\n", > udev->quirks); > + } That last part is a little surprising. But I guess it's okay to do it here rather than someplace else. > +static const struct usb_blacklist { > + u16 idVendor; /* vendor id of the quirky device */ > + u16 idProduct; /* product id of the quirky device */ > + u16 bcdVersionMin; /* minimum version id of the afflicted devices */ > + u16 bcdVersionMax; /* maximum version id of the afflicted devices */ > + int quirks; /* the actual qirks, several to be joined with binary > or */ > +} usb_blacklist[] = { > + /* Elsa MicroLink 56k (V.250) */ > + {0x05cc, 0x2267, 0x0100, 0x0100, USB_QUIRK_AUTOSUSPEND_DISCONNECT}, > + {0, 0, 0, 0, 0} /* keep this last */ > +}; A few more blank lines please, to make this easier to read. Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
