On Thu, 7 Apr 2016, Mathias Nyman wrote: > > In this case there may be alternatives. For example, you could just > > delay a few ms until the pending event has been handled. Or, if you > > really just want to prevent runtime suspend, you should check to see if > > this was a runtime suspend and not a system suspend. Or you could > > prevent the bus from being runtime suspended in the first place by > > doing a pm_runtime_get_sync(). > > I just want to prevent runtime suspend. > The pm_message_t msg is lost when hcd_bus_suspend() calls > hcd->driver->bus_suspend(hcd). > Maybe it could be added?
It could. You'd just have to update all the existing callback routines to accept the additional argument. > Or is there some other easy way to figure out if it is runtime suspend? There isn't. But I still think you might be better off using the existing runtime PM facilities to prevent runtime suspend at bad times -- if possible. The commit message said something about waiting for a newly discovered hub to be probed. Can you go into more detail? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
