From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f65.google.com ([209.85.215.65]:35648 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755414AbcECHvk (ORCPT ); Tue, 3 May 2016 03:51:40 -0400 Date: Tue, 3 May 2016 09:51:38 +0200 From: Johan Hovold To: Alan Stern Cc: Johan Hovold , Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Tomeu Vizoso , "Rafael J . Wysocki" , stable@vger.kernel.org Subject: Re: [PATCH] Revert "USB / PM: Allow USB devices to remain runtime-suspended when sleeping" Message-ID: <20160503075138.GB25025@localhost> References: <1462196157-22005-1-git-send-email-johan@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: stable-owner@vger.kernel.org List-ID: 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 # 4.5 > > Signed-off-by: Johan Hovold > > --- > > > > 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. I was trying to describe how things broke but not necessarily to suggest how this should be fixed. Could have put the last paragraph below the cut-off line I guess. > 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. Thanks, Johan