On Mon, 8 Oct 2018, Oliver Neukum wrote: > On Mo, 2018-10-08 at 10:50 +0100, Mayuresh Kulkarni wrote: > > > > As a result of this, the USB suspend (L2) does not seem to happen, even if > > all the interface drivers of a composite USB device report "idle" to USB > > core driver. The USB suspend seem to happen only when the caller in > > user-space (in our case) closes the device file. > > > > Is this correct understanding? > > Yes, it is. > > > If yes, could you please help understand - > > 1. Any specific reason to choose this design approach? Apologies, but "git > > blame" does not reveal much information (or maybe I did not do git blame on > > correct kernel version). > > We cannot assume that a device is done executing a command as soon as > communication is done. Think of a scanner moving its sensor bar > or a printer printing a page. Or a display displaying something. > > > 2. Is it possible to modify this driver to take PM ref-count on USB device, > > only when user-space is actively interacting with the USB device (so in > > open/close and appropriate ioctl calls, with special handling for async URB > > submission)? > > Technically this is possible, but it is a bad idea. > > > 3. Will (2) break any known existing device(s)? > > Yes, it would and that makes it a bad idea.
In theory we could add ioctls to perform the runtime PM put and get operations. Alan Stern
