On Di, 2018-10-16 at 10:46 -0400, Alan Stern wrote: > On Tue, 16 Oct 2018, Mayuresh Kulkarni wrote: > > > 1. User space decides when it is time to suspend the device and calls > > this ioctl. The implmentation takes care to ensure, no URB is in > > flight from this caller to this device. Then proceed with suspend. > > Well, I did not imagine the ioctl would try to ensure that no URBs are > in flight. The user would be responsible for that. Well, we have to check for URBs in flight. In fact we would have to "plug" the device against new URBs. Now, we could use a new counter. But if we check asynclist, we may just as well walk it and kill the URBs. It just seems a bit silly not to do that. > Also, proceeding with the suspend is difficult, as Oliver has pointed > out. There is no guarantee that the device will go into suspend, > merely because the userspace driver isn't accessing it. (In fact, > there's no guarantee that the device will _ever_ go into suspend.) The > ioctl would probably have to include some sort of timeout; it would > return early if the timeout expired before the device was suspended. Exactly. The alternative is to have an ioctl() to just allow or block suspend, more or less just exporting autopm_get/put(). The disadvantage is that 1. The kernel has to cancel URBs in flight 2. There needs to be a mechanism to notify user space about events > > 2. In an another thread, the user-space calls poll(USB-device-fd). > > When poll() returns, that means the device is active now. User space > > can then request an URB to read out the async notification, if any. > > No; no other thread or polling is needed. The ioctl call returns when > the device resumes. At that point the user program can check whether > there is an async notification pending. This is problematic. For example, what do we do if a signal needs to be delivered? The obvious solution of just repeating the call will not work. It races with wakeup. You'd need to restart IO to query the device. But the device may be suspended. Or do you want a signal to up the PM counter again? Making Ctrl-C wake up an unrelated device? What do we do in case of a failed suspend or resume? How about reset_resume? > > If this is correct interpretation, what will happen when USB device > > sends remote-wake to host, but the reason is not async notification > > but something other than that (e.g.: something standard UAC or HID)? > > The reason for the wakeup won't make any difference; the behavior would > be the same regardless. Exactly. Anything else is a race that can drop events. Regards Oliver
