Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1280977 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#1280977 — 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

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

[toc] | [next] | [standalone]

#1281525

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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web