On Fri, 2018-11-09 at 10:33 -0500, Alan Stern wrote: > 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. > I think I now understand the disconnect between us this point. Below is an attempt to bridge that, so please bear with me: 1. In our use-case(s), the end user can "interact" with composite USB device either by physically interacting with or via an app on Android. 2. When the interaction is "physical" (e.g.: something that is sensed by a sensor or a button press), we need "remote-wake" from USB device to host. 3. When the interaction is via app (e.g.: to toggle some control), we need "host-wake" from host to USB device. And this is where, the knowledge of wake-up source and difference in handling comes into picture. For (2), the host needs to first wake-up and then queue a request to read-out "what" happened. For (3), the host needs to first wake-up the device and then queue the command(s) to the take action asked by the end user. I agree that in both of above cases, "a USB request" needs to be send from user- space to kernel to device. But in my opinion, each of the them has a different context associated with it. E.g.: for (2), a single read request is sufficient to "know" what happened while for (3), a write and a read request is needed. With that said, due to above reason(s), it is proposed to add 3 "new" ioctls. Does the calling sequence by user-space I mentioned in previous response, seems sensible now? > > > > 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. > OK. > > > > 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). Based on above comment, if we are able to distinguish the "resume" cause, the user-space will be in better position to take action. > > 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. > I think the first comment above applies to this part as well (part related to how end user can interact with the composite USB device). > > > > 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
