On Mon, 12 Nov 2018, Mayuresh Kulkarni wrote: > 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. Oliver gave a good explanation of where you are going wrong, but I will fill in some of the missing steps here. > 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. Wrong. For all you know, the user may have both toggled a control in the app _and_ pressed a button on the device. Therefore the host needs to queue a request to read out what happened _and_ it needs to take whatever actions have been requested by the user. > 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. Wrong. The user may have triggered a sensor on the device as well as toggled a control in the app, in which case the host does not need to wake up the device (the device will have issued its own remote wakeup) but it does need to queue a request to see if anything has happened. > 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. In both cases, you always need to query the device's state and you may need to send a command to the device. Hence there's no point in trying to distinguish the two cases. > 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? My earlier response still stands. > > > > > > 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. But we are not able to distinguish the cause, and even if we were, it's quite possible that the user could interact with the device after the time the host woke it up but before any commands were issued. Therefore the app must always query the device's state. What would you do if the device _wasn't_ suspended when the user interacted with the app? Wouldn't the app still need to find out somehow that the user had also triggered a sensor? The same remains true if the device _was_ suspended. Alan Stern > > 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 > >
