On Thu, 27 Jun 2019, Mayuresh Kulkarni wrote: > Thanks for all the comments and clarifications, Alan. > > I will check the 3-ioctl approach on the platform I have using the test > program I had used to send my original patch. > > Just for my understanding, the below sequence should also work - > 1. Call ALLOW_SUSPEND > 2. Previously queued URB fails ==> device no longer active > 3. Call WAIT_FOR_RESUME You don't have to perform (2) if you don't want to. You can proceed directly to (3); the WAIT_FOR_RESUME ioctl won't return until the device has both suspended and resumed (or the call is interrupted by a signal -- such as a 10-second timer expiring). > 4. After a while (say > 10 sec), assume no remote-wake by device. But > user-space wants to communicate with the device (due to some end-user > activity). > In this case, the user space needs to call FORBID_SUSPEND ioctl. When > that returns, it is safe to assume device is active. Or maybe the WAIT_FOR_RESUME ioctl returns because there was a remote wakeup. In this case also you would call FORBID_SUSPEND. In fact, you should call FORBID_SUSPEND _whenever_ WAIT_FOR_RESUME returns, unless your program has decided not to use the device any more (in which case you don't care whether the device is suspended or resumed). > 5. Once done, go-to (1). > > Could you please cross-confirm? Thanks, That's all correct. Alan Stern
