From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752741AbdAZDhj (ORCPT ); Wed, 25 Jan 2017 22:37:39 -0500 Received: from mga11.intel.com ([192.55.52.93]:41116 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752576AbdAZDhi (ORCPT ); Wed, 25 Jan 2017 22:37:38 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,287,1477983600"; d="scan'208";a="52510970" Subject: Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability To: Peter Zijlstra References: <58817A25.6080305@linux.intel.com> <20170122090423.GA15061@gmail.com> <5886DBB7.4070501@linux.intel.com> <20170124082039.GB8667@gmail.com> <5888377F.8090709@linux.intel.com> <20170125092355.GA24580@gmail.com> <20170125095736.GP6515@twins.programming.kicks-ass.net> <588899BA.7040108@linux.intel.com> <20170125143829.GS6515@twins.programming.kicks-ass.net> <5888C986.4020809@linux.intel.com> <20170125161644.GT6515@twins.programming.kicks-ass.net> Cc: Ingo Molnar , Greg Kroah-Hartman , Mathias Nyman , Ingo Molnar , tglx@linutronix.de, linux-usb@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, Jiri Slaby From: Lu Baolu Message-ID: <58896EFF.7030900@linux.intel.com> Date: Thu, 26 Jan 2017 11:37:35 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20170125161644.GT6515@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 01/26/2017 12:16 AM, Peter Zijlstra wrote: > On Wed, Jan 25, 2017 at 11:51:34PM +0800, Lu Baolu wrote: > >>> What is timeout and why? >> Put it in simple: >> >> The driver sets the RUN bit in control register and polls READY >> bit in status register for the successful USB device enumeration. >> As the USB device enumeration might fail and the READY bit will >> never be set, the driver must have a timeout logic to avoid >> endless loop. >> >> More details: >> >> The operational model is that driver sets up all necessary registers >> and data structures, and then starts the debug engine by setting >> the RUN/STOP bit in the control register. >> >> The debug engine then brings up itself as a ready-for-enumeration >> USB device. The USB link between host and device starts link training >> and then host will detect the connected device. The hub driver in >> host will then starts the USB device enumeration processes (as defined >> in USB spec). If everything goes smoothly, the device gets enumerated >> and host can talk with the debug device. >> >> After that, xdbc firmware will set the READY bit in status register. And >> the driver can go ahead with data transfer over USB. > I have vague memories from a prior discussion where you said this READY > state can be lost at any time (cable unplug or whatnot) and at that > point the driver should re-start the setup, right? Yes. So the documentation requires users not to unplug the usb cable during debugging. This rule applies to other debug methods as well. > >>> If there is an error other than !ready, I would >>> expect the hardware to inform you of this through another status bit, >>> no? >> Yeah, this might be another choice of hardware design. But it's not a >> topic for this driver. > So is there really no way to way to distinguish between "I did setup and > am waiting for READY", "I did setup, am waiting for READY, but things > got hosed" and "I was READY, things be hosed" ? > > I suppose the first and last can be distinguished by remembering if you > ever saw READY, but the first and second are the interesting case I > think. > >>> So why can't you poll indefinitely for either ready or error? >>> >> Even if the hardware has both ready and error status bits, it's still >> nice to have a time out watch dog. Buggy hardware or firmware >> might not set any of these bits. Polling indefinitely might result in >> a endless loop. > Loosing output, esp. without indication, is very _very_ annoying when > you're debugging things. Its just about on par with a stuck system, at > least then you know something bad happened. Fair enough. USB connection is stable enough, unless the user unplugs the USB cable during debugging. Best regards, Lu Baolu