Re: [TESTPATCH v2] xhci: fix usb2 resume timing and races.

From: Mathias Nyman
Date: Tue Dec 08 2015 - 06:11:20 EST


On 05.12.2015 06:02, Daniel J Blueman wrote:
On 1 December 2015 at 16:26, Mathias Nyman
<mathias.nyman@xxxxxxxxxxxxxxx> wrote:
usb2 ports need to signal resume for 20ms before moving to U0 state.
Both device and host can initiate resume.

On host initated resume port is set to resume state, sleep 20ms,
and finally set port to U0 state.

On device initated resume a port status interrupt with a port in resume
state in issued. The interrupt handler tags a resume_done[port]
timestamp with current time + 20ms, and kick roothub timer.
Root hub timer requests for port status, finds the port in resume state,
checks if resume_done[port] timestamp passed, and set port to U0 state.

There are a few issues with this approach,
1. A host initated resume will also generate a resume event, the event
handler will find the port in resume state, believe it's a device
initated and act accordingly.

2. A port status request might cut the 20ms resume signalling short if a
get_port_status request is handled during the 20ms host resume.
The port will be found in resume state. The timestamp is not set leading
to time_after_eq(jiffoes, timestamp) returning true, as timestamp = 0.
get_port_status will proceed with moving the port to U0.

3. If an error, or anything else happends to the port during device
initated 20ms resume signalling it will leave all device resume
parameters hanging uncleared preventing further resume.

Fix this by using the existing resuming_ports bitfield to indicate if
resume signalling timing is taken care of.
Also check if the resume_done[port] is set before using it in time
comparison. Also clear out any resume signalling related variables if port
is not in U0 or Resume state.

v2. fix parentheses when checking for uncleared resume variables.
we want: if ((unclear1 OR unclear2 ) AND !in_resume AND !in_U3) { .. }

Signed-off-by: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>

Excellent; this correctly prevents the cyclic chain of suspend
attempts, resolving the issue.

Tested-by: Daniel J Blueman <daniel@xxxxxxxxx>

Thanks Mathias!
Daniel


Thanks for testing it
I'll do some minor cleanups and add it to the queue

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/