On Thu, 2018-11-15 at 09:56 -0500, Alan Stern wrote: > On Thu, 15 Nov 2018, Oliver Neukum wrote: > > > > > On Do, 2018-11-15 at 12:45 +0000, Mayuresh Kulkarni wrote: > > > > > > > > > Understood this for remote-wake part. > > > > > > But still unclear about step (1) for host-wake as below (please note, I am > > > refering to host-wake and remote-wake as per my previous comment) - > > > Pre-condition: device in suspend and link in L2. > > > Use-case: end user wants to sends a control message to device. > > > Assumption: end user is NOT doing any activity that causes remote-wake. > > That is just an assumption you cannot make. > > Users are devious creatures. If it is physically > > possible, you have to be able to deal with it. > That's right. But let's suppose that the user hasn't interacted with > the device. In that case it's simple: The app should submit an URB to > the device (or do pretty much any other ioctl to the usbfs device file > descriptor). When usbfs gets an ioctl, it will automatically wake up > the device by incrementing the runtime PM usage counter. > Thanks for the comments. Based on the info so far, attempting to summarize the probable solution, to ensure that I understand it clearly - Facts - 1. USBFS driver grabs a PM ref-count in .open and drops it in .close which means USB device cannot suspend untill user-space closes it (even if all interface drivers report "idle" to usb-core). 2. Since the .ioctl "knows" that .open has ensured to keep device active, it does not call PM runtime APIs. Proposal - 1. Add new ioctl: suspend & wait-for-resume 2. suspend ioctl: decrements PM ref count and return 3. wait-for-resume ioctl: wait for resume or timeout or signal 4. Modify .ioctl implementation to do PM runtime calls except for above "new" ioctl calls (so pm_runtime_get_sync -> ioctl -> response -> pm_runtime_put_sync). This also means, pm runtime get/put will be in both .open/.close. Use-case analysis - 1. Remote-wake: Due to device's remote wake, wait-for-resume will return successfully. The user space caller then need to queue a request to "know" the reason of remote-wake. 2. Host-wake: The user-space caller issues any ioctl supported by .ioctl method. Due to (4) above, the device will be resumed and the ioctl will be performed. For (2) in use-case analysis, the user-space caller's wait-for-resume will also return, but since it knows that it has initiated the ioctl, it may or may not decide to queue a request. Instead, when ioctl returns it can call wait-for- resume again. Am I getting in sync with your comments? What issue(s) you anticipate in above proposal due to inherent race condition between host and remote-wake? Based on my meagre understanding of usb-core, it feels like usb_lock_device/usb_unlock_device calls around remote-wake and usbfs ioctl should help with race condition, right? > Alan Stern
