From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com ([192.55.52.88]:44863 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757443AbcDHKJr (ORCPT ); Fri, 8 Apr 2016 06:09:47 -0400 Message-ID: <570784F5.1080804@linux.intel.com> Date: Fri, 08 Apr 2016 13:16:21 +0300 From: Mathias Nyman MIME-Version: 1.0 To: Alan Stern CC: Greg KH , 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=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: On 07.04.2016 17:23, Alan Stern wrote: > On Thu, 7 Apr 2016, Mathias Nyman wrote: > >>> 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? > > It could. You'd just have to update all the existing callback routines > to accept the additional argument. > >> Or is there some other easy way to figure out if it is runtime suspend? > > There isn't. But I still think you might be better off using the > existing runtime PM facilities to prevent runtime suspend at bad times > -- if possible. > > The commit message said something about waiting for a newly discovered > hub to be probed. Can you go into more detail? A USB3 device connected to a runtime suspended host woke up the host, polled the roothub, found nothing and immediately tried to suspend again. Logs show: Feb 16 20:03:33 xhci_hcd 0000:0e:00.0: // Setting command ring address to 0xffffe001 Feb 16 20:03:33 xhci_hcd 0000:0e:00.0: xhci_resume: starting port polling. Feb 16 20:03:33 xhci_hcd 0000:0e:00.0: xhci_hub_status_data: stopping port polling. Feb 16 20:03:33 xhci_hcd 0000:0e:00.0: xhci_suspend: stopping port polling. Feb 16 20:03:33 xhci_hcd 0000:0e:00.0: Port Status Change Event for port 3 Feb 16 20:03:33 xhci_hcd 0000:0e:00.0: resume root hub ..other entries.. Feb 16 20:03:33 xhci_hcd 0000:0e:00.0: Port Status Change Event for port 1 Feb 16 20:03:33 xhci_hcd 0000:0e:00.0: resume root hub So what probably happened here was that connecting the usb device caused a PCI PME# event to wake up the xhci PCI controller, calling xhci_pci_resume(), calling xhci_resume(), calling usb_hcd_resume_root_hub(both usb2 and usb3 hcds) and usb_hcd_poll_rh_status(both usb2 and usb3 hcd). polling rh status calls hcd->driver->hub_status_data() -> xhci_hub_status_data() xhci_hub_status_data() reads PORTSCs -> no change -> stop polling -> return 0 In core/hub.c hub_probe() autosuspend is set to 0 for roothubs with a long explanation why. I assume that as xhci_hub_status_data clears the HCD_FLAG_POLL_RH flag and returns 0 (no changes) we immediately runtime suspend the hub -> runtime suspend host. -Mathias