Re: [PATCH 3/7] xhci: Don't suspend a xhci usb bus if there is a pending event.

[Mathias Nyman <mathias.nyman@linux.intel.com>]

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