On Fri, Feb 21, 2014 at 1:17 PM, Alan Stern <st...@rowland.harvard.edu> wrote: > On Fri, 21 Feb 2014, Dan Williams wrote: > >> > Round 2: add usb 3 hcd >> > >> > usb_add_hcd() // secondary usb3 hcd >> > hcd->self.root_hub = usb_alloc_dev() >> > hcd->driver->reset(hcd) -> xhci_gen_setup() >> > if(primary_hcd) // false >> > .. >> > else >> > pm_runtime_put_noidle(hcd->self.controller) // -1 usage, * >> > register_root_hub(hcd) -> usb_new_device(usb_dev) >> > pm_runtime_set_active(&udev->dev); >> > pm_runtime_get_noresume(&udev->dev); >> > pm_runtime_use_autosuspend(&udev->dev); >> > pm_runtime_enable(&udev->dev); >> > ... >> > pm_runtime_put_sync_autosuspend(&udev->dev); // ok to trigger would >> > trigger xhci_suspend if all usages were 0. >> > >> > *) unnecessary to trigger any suspend as we're just about to register the >> > usb3 roothub. but we need to decrement the usage counter. >> >> 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. > (as well as in the error return pathways). Sounds like an example case for a new devm_pm_runtime_get() api. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
