On Di, 2018-10-16 at 12:10 +0100, Mayuresh Kulkarni wrote: > On Mon, 15 Oct 2018 09:50:46 -0400 > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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. > The exact semantics this ioctl() should have is what we are currently discussing. > 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. That is one of the designs we are looking at. > 3. Compatibility is maintained with current user-space implementation as only "newer" user-space will call this new ioctl. Yes. > The USB device can suspend between (1) and (2). Yes. > 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)? Here, the URB will be queued forcing the link to be active (and we probably land into same issue). Remote wakeup does not carry information with it. In fact a wake up from the host can race with remote wake up. Any wake up would require a user space driver to do IO with the device and query it for a reason to wake up. > In such a case, is it expected from user-space to dequeue the URB after a while and follow (1) and (2) above? Yes. > Apologies if this is implied but I am just trying to get my head around with the proposal, hence being verbose. Please feel free and encouraged to state your requirements as clearly and verbosely as you like. It would suck to introduce an API only to find that it cannot do the job. Regards Oliver
