lkml.org 
[lkml]   [2016]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Revert "USB / PM: Allow USB devices to remain runtime-suspended when sleeping"
On Mon, 2 May 2016, Greg Kroah-Hartman wrote:

> On Mon, May 02, 2016 at 11:13:10AM -0400, Alan Stern wrote:
> > On Mon, 2 May 2016, Johan Hovold wrote:
> >
> > > This reverts commit e3345db85068ddb937fc0ba40dfc39c293dad977, which
> > > broke system resume for a large class of devices.
> > >
> > > Devices that after having been reset during resume need to be rebound
> > > due to a missing reset_resume callback, are now left in a suspended
> > > state. This specifically broke resume of common USB-serial devices,
> > > which are now unusable after system suspend (until disconnected and
> > > reconnected) when USB persist is enabled.
> > >
> > > During resume, usb_resume_interface will set the needs_binding flag for
> > > such interfaces, but unlike system resume, run-time resume does not
> > > honour it.
> > >
> > > Cc: stable <stable@vger.kernel.org> # 4.5
> > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > ---
> > >
> > > Greg, Alan,
> > >
> > > This patch for v4.6-rc7 fixes a 4.5-regression that broke system suspend
> > > for a large class of devices, including USB-serial devices, for example
> > > when USB persist is enabled.
> > >
> > > We may be able to find a way around this, but since it's a user-visible
> > > regression and late in the rc-cycle, I believe reverting the offending
> > > commit is the right thing to do.
> >
> > The description of the problem doesn't sound right to me. For
> > instance, would it help if usb_runtime_resume() did honor the
> > needs_binding flag? I doubt it. Things like the wakeup setting would
> > still be lost before the runtime resume occurred.
> >
> > I suspect the right answer is always to resume a USB device if it needs
> > a reset-resume, but otherwise allow it to remain in runtime suspend.
> >
> > Reverting the patch for now is okay with me. Tomeu may want to work on
> > a better solution. Part of the difficulty is that the PM core wants to
> > know before suspending whether skipping resume will be okay, but the
> > USB stack doesn't know until after the host controller has been
> > resumed.
> >
> > In the end, we'll probably have the PM core call usb_resume all the
> > time, but usb_resume will leave the device in runtime suspend if it
> > can. This isn't ideal but it may be the best we can do.
>
> So is that an "acked-by" for this revert?

Yes.

Alan Stern

\
 
 \ /
  Last update: 2016-05-02 18:01    [W:0.051 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site