On Sat, 28 Jul 2012, Rafael J. Wysocki wrote: > On Saturday, July 28, 2012, Alan Stern wrote: > > On Fri, 27 Jul 2012, Rafael J. Wysocki wrote: > > > > > > > > > + if (parent) > > > > > > > + pm_runtime_put(parent); > > > > > > > > > > > > You should use pm_runtime_put_sync(), not pm_runtime_put(). > > > > > > > > > > Hmm, why exactly? > > > > > > > > Because it's more efficient to do something directly than to run it in > > > > a workqueue. > > > > > > Well, depends. If that results in a power off (the parent goes into > > > D3 for example), we may wait as long as 10 ms for that to complete. > > > > True, but so what? You'd also have to wait 10 ms for the workqueue > > item to complete if pm_runtime_put() was used, > > Are you sure? pm_runtime_put() leads to rpm_idle() with the RPM_ASYNC > flag set, which causes it to queue up the work item and return immediately > without waiting. Why exactly do you think I'd need to wait, then? What I mean is, it takes 10 ms for the parent to suspend regardless of whether or not you use the _sync form of the call. If you're waiting for the parent to suspend, you would therefore have to wait 10 ms in either case. Likewise, if you're waiting for the PCI device to become usable then you don't have to wait for 10 ms, because you can use it as soon as the probe routine returns. > > plus the additional overhead of scheduling the workqueue thread. > > > > Now, if the length of time required for the probe to run were an issue > > then yes, the synchronous routine could make things take longer. But > > probing is generally done asynchronously anyway, right? And usually > > what matters is the time before the device becomes available, not the > > time for the probe to run. > > Still, I see no reason to wait synchronously for the _parent_ to suspend. Why not? There's no penalty, particularly since most device probing happens asynchronously these days anyway. 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
