First of all thanks for the comments. It is really helpful to get better insights of this driver.
On Mon, 8 Oct 2018 21:59:44 +0200 Oliver Neukum <oneu...@suse.com> wrote: > On Mo, 2018-10-08 at 11:16 -0400, Alan Stern wrote: > > 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. > > > The USB core driver has a module-param "usb_autosuspend_delay" whose default value is 2 sec. AFAIU, the PM core will wait at-least 2 sec before scheduling the suspend of this USB device. So, if the user-space driving any of the above devices sends "new" URB request before usb_autosuspend_delay expires, the PM core will cancel suspend. This will essentially mean the device remained active and link never entered L2. I could be wrong, but 2 sec seems like a pretty good time-out to me, from end user's perspective. But because usb_autosuspend_delay is a module-param, a previledged user space can change it and even set it 0 on a particular platform. In such cases, the device will suspend ASAP. > > > > 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. > > Hi, > > we had this discussion years ago. Then the majority view was that an > application should close the device. Do we have a reason to revisit > that decision? > > Regards > Oliver With all due respect, one of the possible reason for this could be, power saving on mobile/tablet platforms (running Android). These platforms usually have a single USB port. Specifically from our point of view, these platforms are removing 3.5 mm jack and hence the only interface available for headsets is USB. So, for any such USB devices that connect to these platforms and communicated by user space, such a change might allow the USB device and link go into suspend for prolonged period, saving battery power. With that said, above example might be on a very small scale as comapred to vast amount of USB devices in the world, so please feel to disagree :-). Best Regards, Mayuresh
