From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com ([134.134.136.20]:3697 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751387AbcDGIEU (ORCPT ); Thu, 7 Apr 2016 04:04:20 -0400 Message-ID: <5706160B.9060902@linux.intel.com> Date: Thu, 07 Apr 2016 11:10:51 +0300 From: Mathias Nyman MIME-Version: 1.0 To: Alan Stern , Greg KH CC: linux-usb@vger.kernel.org, stable@vger.kernel.org, Mike Murdoch Subject: Re: [PATCH 3/7] xhci: Don't suspend a xhci usb bus if there is a pending event. References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: On 07.04.2016 00:25, Alan Stern wrote: > On Wed, 6 Apr 2016, Greg KH wrote: > >> On Wed, Apr 06, 2016 at 04:08:04PM +0300, Mathias Nyman wrote: >>> We don't want to runtime suspend a bus if there is an event pending. >>> The roothub on a NEC uPD720200 host with a single USB3 device connected >>> might go back to runtime suspend immediately after runtime resume as >>> hub might not yet see any port changes in resume. >>> >>> Prevent this by checking if there is a unhandled event pending when >>> calling runtime suspend. >> >> As Alan points out, you didn't actually test this :( No, I couldn't trigger this case at all. Patches 2/7 and 3/7 were based on logs of failing cases seen by Mike Murdoch on hist NEC host. These two patches solved it for him. I'm guessing patch 2/7 changed the situation enough to not trigger the 3/7 case anymore, and it was really never exercised. http://marc.info/?l=linux-usb&m=145477850706552&w=2 But I got no excuses. I really should have spotted that lock. I'm glad Alan found it. > > Also as Björn pointed out, failing a system suspend isn't a good idea. > In general, you should do it only if wakeup is enabled and there is a > pending wakeup event. > > In this case there may be alternatives. For example, you could just > delay a few ms until the pending event has been handled. Or, if you > really just want to prevent runtime suspend, you should check to see if > this was a runtime suspend and not a system suspend. Or you could > prevent the bus from being runtime suspended in the first place by > doing a pm_runtime_get_sync(). I just want to prevent runtime suspend. The pm_message_t msg is lost when hcd_bus_suspend() calls hcd->driver->bus_suspend(hcd). Maybe it could be added? Or is there some other easy way to figure out if it is runtime suspend? -Mathias