Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

From: Peter Zijlstra <peterz@infradead.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mathias Nyman <mathias.nyman@linux.intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	tglx@linutronix.de, linux-usb@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, Jiri Slaby <jslaby@suse.cz>
Subject: Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability
Date: Thu, 26 Jan 2017 18:39:35 +0100	[thread overview]
Message-ID: <20170126173935.GE6515@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20170126160104.GA31590@gmail.com>

On Thu, Jan 26, 2017 at 05:01:05PM +0100, Ingo Molnar wrote:
> > > 
> > > 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'.

When you map printk() onto early_printk() dmesg will be empty, there
will be nothing there, and therefore no reason what so ever to look
there. I certainly don't ever look there.

Note that the printk buffer itself is a major part of why printk sucks
donkey balls.  Not to mention that you really cannot have an
early_printk() implementation that depends on printk().

> > 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...

Sure, I'm just not sure what or where makes sense.

If your serial cable is bad you notice because you don't receive the
right amount of characters and or stuff gets mangled. You chuck the
cable and get a new one.

I think the most important part is re-establishing the link when the
cable gets re-inserted. Maybe we should just drop all characters written
when there's no link and leave it at that, same as serial.