On Fri, 9 Nov 2018, Mayuresh Kulkarni wrote: > > The driver has no way to tell whether the resume was caused by the > > host or by the device. (In fact, it's possible for a resume to be > > caused by _both_ the host and the device, if they request it at the > > same time.) In the end, it doesn't matter anyway. > > > > Yes agreed to the point that driver as such does not know if its resume is > called due to host or remote wake. > But based on ioctl call, it should be possible to know, if resume happened due > to resume-ioctl or remote-wake (e.g.: using a flag in resume-ioctl), right? No, I keep telling you, it is not possible. Furthermore, you should never care what the cause was. After all, what difference would it make to your program? It shouldn't make any difference -- you should do exactly the same thing no matter what the wakeup cause was. > As I understand, the calling sequence by user-space would be like - > > ioctl(fd, USBDEVFS_SUSPEND); ==> put-down PM ref-count and return > > ret = ioctl(fd, USBDVEFS_WAIT_FOR_REMOTE_WAKE); ==> will block for resume This should be WAIT_FOR_RESUME, not WAIT_FOR_REMOTE_WAKE. > if (ret == EHOST_WAKE) > /* handle host wake case */ > else if (ret == EREMOTE_WAKE) > /* handle remote wake case */ > else > /* handle other return values */ No way to tell the difference between wakeup causes. The return value would be 0 for a resume and -1 if the ioctl was interrupted by a signal before the device resumed (or perhaps if the device file was closed before the ioctl returned). I still think this should be implemented in the runtime PM core through poll/select in sysfs. But we may as well also offer an interface through usbfs. > When user wants to interact with the device, user space should call - > > ioctl(fd, USBDEVFS_RESUME); ==> gets PM ref-count, unblock wait-for-remote and > return Not necessary, although I suppose we should support this. The device would automatically be resumed anyway, when the user interacts with it. > Here the "get PM ref-count" should cause the resume of root-hub and its port > followed by resume of device, right? > As I understand, as a result of this operation, the host controller should bring > back the link to L0. Right. > Am I missing some important aspect here? If yes, could you please help explain? Only the things noted above. Alan Stern
