3f3ba6ffeb
In some cases of system suspend, it's possible a runtime resume may be called on a device if it's already autosuspended (say, in order to set a device- or port-specific feature, such as the remote wakeup setting) just prior to putting it back into low power mode. In this case, if the controller was also auto-suspended it will also be temporarily runtime resumed by the fact that it is an ancestor to said device. The incoming wakelock re-implementation from Google based on wakeup sources breaks this driver in the above scenario since now acquiring a wakelock (which calls __pm_stay_awake) during runtime resume while a simultaneous asynchronous suspend callback of another device is called will cause it to abort the entire suspend attempt. This prompts reconsideration of why a wakelock is needed in this driver. One apparent use is to ensure this controller's runtime suspend is called before system suspend is allowed. In other words, we wish to guarantee the HSIC child devices are suspended before suspending the controller. This can be done by checking that the root hub device is suspended, else we can abort the suspend callback by returning -EBUSY. To handle the cases of interrupts happening during systemwide suspend but after the controller was already suspended (and thus its runtime PM disabled), call the pm_stay_awake() to denote a wakeup event. This will cause the suspend to abort as well as block it from happening until the interrupt can be serviced--after the controller resumes. Change-Id: I4fab47c54f7d57065833d96261de08dcdd7238dc Signed-off-by: Jack Pham <jackp@codeaurora.org>