On May 6, 2010, at 7:06 AM, Alan Stern wrote: > Okay, I see what the problem is. It's a subtle thing, involving the > difference between the runtime PM state and the usage_count. It also > involves what the driver does: If it doesn't ever call > usb_autopm_get_interface() or usb_autopm_put_interface(), should the > device be autosuspended? > > I guess it should. This patch ought to fix the problem. A side-effect of the patch is that after the suspend a subsequent open() call fail with -EAGAIN. I added some tracing and see this: May 6 18:06:09 localhost kernel: exar 3-3:1.1: __pm_runtime_resume()! May 6 18:06:09 localhost kernel: exar 3-3:1.1: __pm_runtime_resume power.disable_depth=1 returning -EAGAIN May 6 18:06:09 localhost kernel: exar 3-3:1.1: __pm_runtime_resume() returns -11! May 6 18:06:09 localhost kernel: exar 3-3:1.1: __pm_runtime_idle power.usage_count=0 power.disable_depth=1 power.runtime_status=2 May 6 18:06:09 localhost kernel: exar 3-3:1.1: usb_autopm_get_interface: cnt 0 -> -11 With disable_depth == 1 the call to pm_runtime_resume() fails with -EAGAIN. Is there some sequence of calls I should make in my driver probe or attach that will make the patch unnecessary? Rob. The information and any attached documents contained in this message may be confidential and/or legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender immediately by return e-mail and destroy all copies of the original message. -- 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
