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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
