2015-04-01 12:41:32

by Oliver Neukum

[permalink] [raw]
Subject: Re: [PATCH 6/6] USB / PM: Allow USB devices to remain runtime-suspended when sleeping

On Tue, 2015-03-31 at 13:09 -0400, Alan Stern wrote:
> In other words, if the device is currently in runtime suspend with
> remote wakeup enabled, but device_may_wakeup() returns 0 (so that the
> device should be disabled for wakeup when the system goes into
> suspend), then the prepare callback has to return 0.
>
> Therefore what you need to do here is something like this:
>
> struct usb_device *udev = to_usb_device(dev);
>
> /* Return 0 if the current wakeup setting is wrong, otherwise
> 1 */

And the other way round?

Regards
Oliver



2015-04-01 14:01:35

by Alan Stern

[permalink] [raw]
Subject: Re: [PATCH 6/6] USB / PM: Allow USB devices to remain runtime-suspended when sleeping

On Wed, 1 Apr 2015, Oliver Neukum wrote:

> On Tue, 2015-03-31 at 13:09 -0400, Alan Stern wrote:
> > In other words, if the device is currently in runtime suspend with
> > remote wakeup enabled, but device_may_wakeup() returns 0 (so that the
> > device should be disabled for wakeup when the system goes into
> > suspend), then the prepare callback has to return 0.
> >
> > Therefore what you need to do here is something like this:
> >
> > struct usb_device *udev = to_usb_device(dev);
> >
> > /* Return 0 if the current wakeup setting is wrong, otherwise
> > 1 */
>
> And the other way round?

Your meaning isn't clear. Are you asking what should happen if the
device is in runtime suspend with remote wakeup disabled, but
device_may_wakeup() returns 1? That case should never happen -- but
if it does then the prepare callback should return 0.

Alan Stern

2015-04-01 14:27:30

by Oliver Neukum

[permalink] [raw]
Subject: Re: [PATCH 6/6] USB / PM: Allow USB devices to remain runtime-suspended when sleeping

On Wed, 2015-04-01 at 10:01 -0400, Alan Stern wrote:
> On Wed, 1 Apr 2015, Oliver Neukum wrote:
>
> > On Tue, 2015-03-31 at 13:09 -0400, Alan Stern wrote:
> > > In other words, if the device is currently in runtime suspend with
> > > remote wakeup enabled, but device_may_wakeup() returns 0 (so that the
> > > device should be disabled for wakeup when the system goes into
> > > suspend), then the prepare callback has to return 0.
> > >
> > > Therefore what you need to do here is something like this:
> > >
> > > struct usb_device *udev = to_usb_device(dev);
> > >
> > > /* Return 0 if the current wakeup setting is wrong, otherwise
> > > 1 */
> >
> > And the other way round?
>
> Your meaning isn't clear. Are you asking what should happen if the
> device is in runtime suspend with remote wakeup disabled, but
> device_may_wakeup() returns 1?

Yes. I was thinking about that case.

> That case should never happen -- but
> if it does then the prepare callback should return 0.

Exactly. It didn't seem to do so.

Regards
Oliver




2015-04-01 14:36:53

by Alan Stern

[permalink] [raw]
Subject: Re: [PATCH 6/6] USB / PM: Allow USB devices to remain runtime-suspended when sleeping

On Wed, 1 Apr 2015, Oliver Neukum wrote:

> On Wed, 2015-04-01 at 10:01 -0400, Alan Stern wrote:
> > On Wed, 1 Apr 2015, Oliver Neukum wrote:
> >
> > > On Tue, 2015-03-31 at 13:09 -0400, Alan Stern wrote:
> > > > In other words, if the device is currently in runtime suspend with
> > > > remote wakeup enabled, but device_may_wakeup() returns 0 (so that the
> > > > device should be disabled for wakeup when the system goes into
> > > > suspend), then the prepare callback has to return 0.
> > > >
> > > > Therefore what you need to do here is something like this:
> > > >
> > > > struct usb_device *udev = to_usb_device(dev);
> > > >
> > > > /* Return 0 if the current wakeup setting is wrong, otherwise
> > > > 1 */
> > >
> > > And the other way round?
> >
> > Your meaning isn't clear. Are you asking what should happen if the
> > device is in runtime suspend with remote wakeup disabled, but
> > device_may_wakeup() returns 1?
>
> Yes. I was thinking about that case.
>
> > That case should never happen -- but
> > if it does then the prepare callback should return 0.
>
> Exactly. It didn't seem to do so.

Well, Tomeu can fix it up to handle both cases properly.

Alan Stern