On Do, 2018-10-11 at 14:29 -0400, Alan Stern wrote: > On Thu, 11 Oct 2018, Mayuresh Kulkarni wrote: [..] > > We are looking into closing the device instance during normal operation i.e.: only open/close device when needed. > > > > However, we still have one particular use-case where our USB device sends async notification to USB-host via the above interface. For that, as of now, we queue a URB from user-space. But because, the link never enters suspend (L2), we receive this async notification. > > > > I am not sure, how this use-case will work, if we open-close device only when needed. > > > > Assuming we have PM calls moved from open/close to ioctl or some other appropriate method, is the following sequence possible - > > * Queue an URB -> suspend (L2) > > * Device does remote wake & sends async notification > > * URB above returns with that notification > > It won't work like that. When a device goes into suspend there can't > be any outstanding URBs. Exactly. Yet in case the device is active the URB must be kept running. > How about instead having a mechanism whereby your usrspace driver can > tell when the device does a remote wakeup? At that point it could select() and trigger a wake up from resume()? > submit an URB via usbfs and receive the async notification. I am afraid that design includes an inevitable race condition. It works fine for resume(). It fails for suspend(). If you require user space to cancel periodic transfers before the device can suspend, you will introduce a window of at least two seconds between the cancellation and the eventual suspend() during which the device will not work. In fact events may be outright lost. If you want to suspend with user space drivers active, the kernel will have to kill all active URBs originating from user space drivers. And notify user space when the device is resumed. IMHO select() is the syscall designed for that. Regards Oliver
