On Thu, 18 Oct 2018, Mayuresh Kulkarni wrote: > As I understand, you seem to mention - user-space to tell the USB > device when to remote-wake. > But in our case, we cannot tell the device when to remote-wake as the > USB device needs to detect an "activity" by end user (after link goes > into L2), which can happen at anytime. That's not how it works. The userspace program doesn't tell the device anything, as far as suspend and wakeup are concerned. It just tells the kernel that it has stopped using the device. When nothing is using the device, the kernel tells the device to go into suspend. At the same time, the kernel tells the device to enable remote wakeup. Thus, the device will send a wakeup request if any activity occurs while it is suspended. > I think the approach we are discussing here seems to hint the > USB-core to attempt suspend from user-space's point-of-view, if there > is no other outstanding PM ref-count, but still have ability for > user-space to know if suspend/resume happened or not. Not quite; in the scheme I described, the userspace program would not know whether the device went into suspend. But perhaps that information could be encoded into the ioctl's return value. For example, the ioctl could return 1 if the timeout expired or some other signal arrived before the device went into suspend, or 2 if the device did go into suspend and the call was interrupted by a signal, or 0 if the call was terminated by the device resuming after a suspend. In the end, though, do you really care whether the device suspended? Alan Stern
