On Mon, Feb 24, 2014 at 8:22 AM, Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> wrote: > On 02/23/2014 12:51 AM, Alan Stern wrote: > >>>>> >>>>> Right, but I assume you'd want to hold the reference until after the >>>>> hub is registered, otherwise there's still a chance we suspend right >>>>> before register. So I'm saying hold the reference until the >>>>> registration process takes its own. >>>> >>>> >>>> To be really safe about it, you should call pm_runtime_get_noresume at >>>> the start of xhci_pci_probe, and pm_runtime_put_noidle at the end >>> >>> >>> Why _put_noidle? The fact that we suspend between registrations means >>> the controller is getting suspend requests that we will block with >>> _get_noresume. However, once probe is done our final put might be the >>> only one to trigger the deferred suspension. I.e. just worried about >>> the case where the controller's usage count is 0, but it remains >>> active indefinitely. >> >> >> Either _put_sync or _put_noidle would be okay. The reason is because >> the device core always calls pm_request_idle after probing a driver >> (see driver_probe_device()). >> > > Thanks Dan and Alan for the input, I did the following changes: > > - Take and release the reference in xhci_pci_probe to avoid releasing the > reference for a moment just before usb3 roothub registration. > - Make sure we release the reference in error cases > - Still use _put_noidle as driver_probe_device calls pm_request_idle Sounds ok, and it is documented that the core calls pm_request_idle() on a driver's behalf. But it still seems a small layering violation and more future-proof to call _put_sync(). -- 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
