Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933420AbbLHLLR (ORCPT ); Tue, 8 Dec 2015 06:11:17 -0500 Received: from mga11.intel.com ([192.55.52.93]:25184 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932569AbbLHLLP (ORCPT ); Tue, 8 Dec 2015 06:11:15 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,399,1444719600"; d="scan'208";a="614455991" Message-ID: <5666BC0E.1070301@linux.intel.com> Date: Tue, 08 Dec 2015 13:16:30 +0200 From: Mathias Nyman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Daniel J Blueman CC: USB list , Alan Stern , Linux Kernel Subject: Re: [TESTPATCH v2] xhci: fix usb2 resume timing and races. References: <1448958418-6114-1-git-send-email-mathias.nyman@linux.intel.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2560 Lines: 59 On 05.12.2015 06:02, Daniel J Blueman wrote: > On 1 December 2015 at 16:26, 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. >> >> 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 > > Excellent; this correctly prevents the cyclic chain of suspend > attempts, resolving the issue. > > Tested-by: Daniel J Blueman > > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/