From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751669AbdAYQQ6 (ORCPT ); Wed, 25 Jan 2017 11:16:58 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:56746 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751008AbdAYQQ4 (ORCPT ); Wed, 25 Jan 2017 11:16:56 -0500 Date: Wed, 25 Jan 2017 17:16:44 +0100 From: Peter Zijlstra To: Lu Baolu 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 Subject: Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability Message-ID: <20170125161644.GT6515@twins.programming.kicks-ass.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5888C986.4020809@linux.intel.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? > > 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.