On Thu, 6 May 2010, Rob Duncan wrote: > 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? I don't understand. The disable_depth value should be 0 -- the patch sets it to 0 by means of the call to pm_runtime_enable() added in usb_probe_interface(). Can you check at that spot to see if it really does what it's supposed to do? 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
