Re: Query on usb/core/devio.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 22 Oct 2018 10:24:46 -0400
Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:

> On Mon, 22 Oct 2018, Oliver Neukum wrote:
> 
> > On Do, 2018-10-18 at 13:42 -0400, Alan Stern wrote:
> > > On Thu, 18 Oct 2018, Mayuresh Kulkarni wrote:
> > > 
> > > > > The only way to make the ioctl work properly is to have it do a 
> > > > > runtime-PM put at the start and then a runtime-PM get before it
> > 
> > If and only if you want to do this with one ioctl()
> > If you separate the runtime-PM put and the get, you can do it without
> > the waiting part.
> 
> Sure, but you still need a runtime-PM put at the start and a runtime-PM 
> get at the end.  In fact, if you separate this into two calls then you 
> run the risk that the user may never perform the second call, and you 
> would end up with an unbalanced put.
> 

I am tending to agree towards having a single ioctl call here. It is better to give minimal control to user-space w.r.t. runtime PM. The current proposal of user-space giving an hint to USB-FS/core that - it is not using the device, sounds better.

> > > > /*
> > > >  * There are 3 possibilities here:
> > > >  * 1. Device did suspend and resume (success)
> > > >  * 2. Signal was received (failed suspend)
> > > >  * 3. Time-out happened (failed suspend)
> > > 
> > > 4. Device did suspend but a signal was received before the device 
> > > resumed.
> > > 
> > > >  * In any of above cases, we need to resume device.
> > > >  */
> > > > usb_autoresume_device(dev);
> > 
> > Yes and that is the problem. Why do you want to wait for the result
> > of runtime-PM put ? If we need a channel for notifying user space
> > about resume of a device, why wait for the result of suspend instead
> > of using the same channel?
> 
> This is not meant to be a general-purpose channel for notifying 
> userspace when a device resumes.  Such a channel should be defined in 
> the runtime-PM layer, not in the USB layer.
> 
> This is instead meant to be a special-purpose mechanism for adding a
> runtime-suspend/resume interface to usbfs.
> 

Just to be clear here - the worst case wait-time from user-space perspective will be <time-out - 1 HZ> + <time-to-resume>, right?
If yes then, timeout argument means "wait at-least timeout sec".

> > > > 
> > > > ps->resume_done = false;
> > > > 
> > > > "ps->resume_done = true;" will be done by the runtime resume call-back.
> > 
> > No. You cannot do that in this way. It needs to be a unified device
> > state or a sequence of multiple suspends and resumes will have strange
> > results.
> 
> They won't, because such a sequence cannot occur.  The ioctl thread
> will wake up when the first resume occurs and it will do a runtime-PM
> get, thus preventing any further suspends.
> 
> Alan Stern



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux