Messages in this thread | | | Date | Tue, 1 Dec 2015 10:47:50 -0500 (EST) | From | Alan Stern <> | Subject | Re: [TESTPATCH] xhci: fix usb2 resume timing and races. |
| |
On Mon, 30 Nov 2015, Mathias Nyman 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.
That's an odd approach. The assumption in usbcore is that the HCD will not sleep here.
> 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.
ehci-hcd does the same thing, except that it also uses this resume_done timestamp with host-initiated resumes.
> 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.
Wouldn't it be better to change the host-initiated resume mechanism to be consisten with device-initiated resumes? Or would that be too big a change for the time being?
Alan Stern
| |