Hi all, With runtime pm enabled udc driver, we may put controller to low power mode when vbus is off or with SRP request. But gadget driver may not know the udc status when it calls usb_ep_ops and usb_gadget_ops. I meet this problem when I plug out usb cable from PC (using g_mass_storage), my callstack like: vbus interrupt->.vbus_session->composite_disconnect ->pm_runtime_put_sync(&_gadget->dev), the composite_disconnect will call fsg_disable, but fsg_disable calls usb_ep_disable using async way, there are register accesses for usb_ep_disable. So sometimes, I get system hang due to visit register without clock, sometimes not. Another use case is uvc, it enables dp pullup (call .pullup) by application, but at that time, the udc may be in low power mode. The ways I can think for dealing with above cases: - Add pm_runtime_get{_sync} and pm_runtime_put{_sync} during usb_ep_ops and usb_gadget_ops APIs, it needs to change every runtime pm enabled udc driver's related APIs, I don't think it is a good way. - Like hcd driver, we maintain some controller status, such as HCD_HW_ACCESSIBLE(hcd), etc, and udc dirver (or udc-core) update the status, and composite.c decides whether it needs to call pm_runtime_get{_sync} and pm_runtime_put{_sync} according to hardware status, for example, it needs to wait gadget to finish its hardware operation if it is async (like g_mass_storage). Any other good suggestions? -- Best Regards, Peter Chen -- 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