Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752975AbbLEEDD (ORCPT ); Fri, 4 Dec 2015 23:03:03 -0500 Received: from mail-oi0-f42.google.com ([209.85.218.42]:34152 "EHLO mail-oi0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752368AbbLEEC7 (ORCPT ); Fri, 4 Dec 2015 23:02:59 -0500 MIME-Version: 1.0 X-Originating-IP: [175.156.160.103] In-Reply-To: <1448958418-6114-1-git-send-email-mathias.nyman@linux.intel.com> References: <1448958418-6114-1-git-send-email-mathias.nyman@linux.intel.com> Date: Sat, 5 Dec 2015 12:02:58 +0800 Message-ID: Subject: Re: [TESTPATCH v2] xhci: fix usb2 resume timing and races. From: Daniel J Blueman To: Mathias Nyman Cc: USB list , Alan Stern , Linux Kernel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2365 Lines: 52 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 -- 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/