Re: Autosuspending devices that seem to need reset_resume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 08, 2009 at 07:47:06PM -0400, Alan Stern wrote:
> 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.

The needs_binding option only seems to be set in the case where 
USB_QUIRK_RESET_RESUME is present but there's no reset_resume callback 
in the driver? I don't have enough experience of the USB core to know 
what that's actually doing.

> > 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 card comes up in a dumb state and then gets fed 16MB worth of armel 
ELF object which causes it to reboot into a more useful form. It stays 
in that state until the power plane is entirely cut, which happens in 
system suspend but not in autosuspend.

> > 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).

I'll grab those shortly.

-- 
Matthew Garrett | mjg59@xxxxxxxxxxxxx
--
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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux