On Mon, 8 Jun 2009, Matthew Garrett wrote: > If I indicate it needs a reset-resume then it doesn't seem to actually > be reset unless I add the needs_binding option in the reset_resume > callback, which strikes me as being absolutely the wrong thing to do. It sure is. I don't understand why you don't get a reset. In driver.c, usb_resume_device() includes this code: if (udev->quirks & USB_QUIRK_RESET_RESUME) udev->reset_resume = 1; That's why setting the quirk bit in udev should be all you need to do. > > > I've got no documentation for > > > the card, but there's no relevant state kept when there isn't an open > > > interface. > > > > But what about when there _is_ an open interface? The reset_resume > > method has to handle all cases. > > When system suspend takes place it reboots itself and appears as a > different USB ID, so there's no hope of restoring state. In theory, the behavior during a system suspend should be the same as the behavior during an autosuspend. Which means that after an autoresume, the device should show up with a different USB ID and so the reset would fail. But that's probably not what's really happening. > The remaining > case would presumably be one where userspace forces a suspend despite > the device being open? I'm not sure how to handle that. Don't worry about it until everything else is working. > It's possible that this is unnecessary in the first place and I'm > working around some other problem. With vanilla code, if I echo > "suspended" to power/level and then echo "on" to it, the device works. > If I echo "auto" to it and leave it to suspend, then it stops working > until I switch it back to "on", even if I don't explicitly reset it. I'm > not sure why this makes a difference. It should not make any difference. Can you provide dmesg output with CONFIG_USB_DEBUG enabled, together with a usbmon trace? You might also want to #define VERBOSE_DEBUG at the start of drivers.c (before the #include lines). 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
