From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753091AbdAZHtd (ORCPT ); Thu, 26 Jan 2017 02:49:33 -0500 Received: from mga14.intel.com ([192.55.52.115]:26250 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753074AbdAZHtb (ORCPT ); Thu, 26 Jan 2017 02:49:31 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,288,1477983600"; d="scan'208";a="926807056" Subject: Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability To: Ingo Molnar References: <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> <58896EFF.7030900@linux.intel.com> <20170126071937.GA3399@gmail.com> Cc: Peter Zijlstra , 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: <5889A9FF.5080301@linux.intel.com> Date: Thu, 26 Jan 2017 15:49:19 +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: <20170126071937.GA3399@gmail.com> 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 Ingo, On 01/26/2017 03:19 PM, Ingo Molnar wrote: > * Lu Baolu wrote: > >> Fair enough. >> >> USB connection is stable enough, unless the user unplugs the >> USB cable during debugging. > What does the hardware do in this case? The XHCI registers are in the host > hardware, so they won't disappear, right? Is there some cable connection status > bit we can extract without interrupts? Yes, there are register bits for us to know the cable status. I will go through the spec again and give you more accurate answer later. I'm sorry. I will be off during the next 7 days for Chinese New Year holiday. My email access will be very limited during this time. I will revisit this thread after I am back from holiday. Sorry for the inconvenience. Best regards, Lu Baolu > I.e. if there's any polling component then it would be reasonable to add an error > component: poll the status and if it goes 'disconnected' then disable early-printk > altogether in this case and trigger an emergency printk() so that there's chance > that the user notices [if the system does not misbehave otherwise]. > > I.e. try to be as robust and informative as lockdep - yet don't lock up the host > kernel: lockdep too is called from very deep internals, there are various > conditions where it sees corrupt data structures (i.e. a 'disconnect' - a system > environment outside the normal bounds of operation), yet of the kernel and over > the last 10+ years of lockdep's existence we had very, very few cases of lockdep > itself locking up and behaving unpredictably. > > Thanks, > > Ingo >