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.
> > 
> > > 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

Reply via email to