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 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