[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMVG2stPwDz79L71fGuEuw1UARwFkPPe1g7LeNpDuzMZGK+8sA@mail.gmail.com>
Date: Sat, 5 Dec 2015 12:02:58 +0800
From: Daniel J Blueman <daniel@...ra.org>
To: Mathias Nyman <mathias.nyman@...ux.intel.com>
Cc: USB list <linux-usb@...r.kernel.org>,
Alan Stern <stern@...land.harvard.edu>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [TESTPATCH v2] xhci: fix usb2 resume timing and races.
On 1 December 2015 at 16:26, Mathias Nyman
<mathias.nyman@...ux.intel.com> 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@...ux.intel.com>
Excellent; this correctly prevents the cyclic chain of suspend
attempts, resolving the issue.
Tested-by: Daniel J Blueman <daniel@...ra.org>
Thanks Mathias!
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists