From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753549AbdAZQH2 (ORCPT ); Thu, 26 Jan 2017 11:07:28 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:33877 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753000AbdAZQHP (ORCPT ); Thu, 26 Jan 2017 11:07:15 -0500 Date: Thu, 26 Jan 2017 17:01:05 +0100 From: Ingo Molnar To: Peter Zijlstra Cc: Lu Baolu , 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: <20170126160104.GA31590@gmail.com> References: <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> <20170126102848.GZ6515@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170126102848.GZ6515@twins.programming.kicks-ass.net> 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 * Peter Zijlstra wrote: > On Thu, Jan 26, 2017 at 08:19:37AM +0100, 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? > > > > 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]. > > That'll be fun when printk() == early_printk() :-) My suggestion would be to just print into the printk buffer directly in this case, without console output - the developer will notice it in 'dmesg'. > I myself wouldn't mind the system getting stuck until the link is > re-established. My own damn fault for taking that cable out etc. That's fine too, although beyond the obvious "yanked the cable without realizing it" case there are corner cases where usability is increased massively if the kernel is more proactive about error conditions: for example there are sub-standard USB cables and there are too long USB pathways from overloaded USB hubs which can result in intermittent behavior, etc. A clear diagnostic message in 'dmesg' that the USB host controller is unhappy about the USB-debug dongle device is a _lot_ more useful when troubleshooting such problems than the occasional weird, non-deterministic hang... Thanks, Ingo