Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1281525
| From | Mathias Nyman <mathias.nyman@linux.intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [TESTPATCH] xhci: fix usb2 resume timing and races. |
| Date | 2015-12-02 09:50 +0100 |
| Message-ID | <qBbgR-4Mq-5@gated-at.bofh.it> (permalink) |
| References | <qAVlL-34y-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 01.12.2015 17:47, Alan Stern wrote: > 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 > Yes, changing host initiated resume code would make sense. Hence the comment in the testpatch: /* Host initated resume doesn't time the resume * signalling using resume_done[]. * It manually sets RESUME state, sleeps 20ms * and sets U0 state. This should probably be * changed, but not right now, do nothing */ I was focusing more on clearing the stale resume related variables and didn't want to dig into the history of host initiated resume code at that moment. If ehci-hcd is using the timestamp + kick roothub approach for host resume, then I don't see why xhci can't do the same. -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [TESTPATCH] xhci: fix usb2 resume timing and races. Alan Stern <stern@rowland.harvard.edu> - 2015-12-01 16:50 +0100 Re: [TESTPATCH] xhci: fix usb2 resume timing and races. Mathias Nyman <mathias.nyman@linux.intel.com> - 2015-12-02 09:50 +0100
csiph-web