On Tue, 16 Oct 2018, Mayuresh Kulkarni wrote: > > It seems that a better approach would be to have an ioctl which would: > > > > fail if there are any active user URBs; > > > > drop the usbfs PM reference so the device can suspend; > > > > block interruptibly until the device resumes; > > > > reacquire the PM reference (forcing the device to resume) > > if the ioctl call is interrupted. > > > > Please correct me if wrong, but as I understand, with this new ioctl > proposal, below should be possible - > 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. 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. > 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. > 3. Compatibility is maintained with current user-space implementation as only "newer" user-space will call this new ioctl. Correct. > The USB device can suspend between (1) and (2). > > 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. > Here, the URB will be queued forcing the link to be active (and we > probably land into same issue). > In such a case, is it expected from user-space to dequeue the URB > after a while and follow (1) and (2) above? Of course. Isn't that what you would do if the reason for the wakeup _was_ an async notification? So you should do the same thing even if the reason is something else. > Apologies if this is implied but I am just trying to get my head > around with the proposal, hence being verbose. Perfectly okay. As Oliver mentioned, it's foolish to design an API that doesn't do what the user wants. Alan Stern
