Re: Query on usb/core/devio.c

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

 



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.

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

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