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.
> > > returns. This is true regardless of the reason for returning: normal
> > > termination, timeout, signal, whatever. Nothing else would be safe.
> > >
> >
> > Will below steps work safely (sometimes pseudo-code/snippets help to
> > align)? -
> >
> > "new" ioctl -
> >
> > timeout is parameter to ioctl.
> >
> > /* attempt suspend of device */
> > usb_autosuspend_device(dev);
> >
> > usb_unlock_device(dev);
> > r = wait_event_interruptible_timeout(ps->resume_wait,
> > (ps->resume_done == true), timeout * HZ);
>
> Not exactly. The condition to test here is whether the device has been
> suspended, so it's more like this:
>
> r = wait_event_interruptible_timeout(ps->suspend_wait,
> (ps->suspend_done == true), timeout * HZ);
>
> where ps->suspend_done is set by the runtime_suspend callback. After
> this we will do:
>
> if (r > 0) /* Device suspended before the timeout expired */
> r = wait_event_interruptible(ps->resume_wait,
> (ps->resume_done == true));
>
> > usb_lock_device(dev);
> >
> > /*
> > * 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?
> >
> > 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.
Regards
Oliver
