From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752850AbdAZHTo (ORCPT ); Thu, 26 Jan 2017 02:19:44 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:36141 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752358AbdAZHTm (ORCPT ); Thu, 26 Jan 2017 02:19:42 -0500 Date: Thu, 26 Jan 2017 08:19:37 +0100 From: Ingo Molnar To: Lu Baolu 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 Subject: Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability Message-ID: <20170126071937.GA3399@gmail.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58896EFF.7030900@linux.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * 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? 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