From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751841AbdAYJ5t (ORCPT <rfc822;w@1wt.eu>);
        Wed, 25 Jan 2017 04:57:49 -0500
Received: from bombadil.infradead.org ([65.50.211.133]:57286 "EHLO
        bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751655AbdAYJ5o (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 25 Jan 2017 04:57:44 -0500
Date: Wed, 25 Jan 2017 10:57:36 +0100
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
Message-ID: <20170125095736.GP6515@twins.programming.kicks-ass.net>
References: <1479189731-2728-1-git-send-email-baolu.lu@linux.intel.com>
 <1479189731-2728-2-git-send-email-baolu.lu@linux.intel.com>
 <20170119093743.GC22865@gmail.com>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170125092355.GA24580@gmail.com>
User-Agent: Mutt/1.5.23.1 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Jan 25, 2017 at 10:23:55AM +0100, Ingo Molnar wrote:
> 
> * Lu Baolu <baolu.lu@linux.intel.com> wrote:
> 
> > > Hiding essentially an early udelay() implementation in an early-printk driver is 
> > > ugly and counterproductive.

> Yeah - so could we do this in a more generic fashion, not in the early-printk 
> driver but in core x86 code?

So ideally early_printk() would not depend on udelay() being setup.

In fact, ideally early_printk() wouldn't even use udelay -- this very
much includes its own copy.

Why is udelay() required? Can't the thing simply poll its own register
state to wait for completion?

This all sounds like xdbc cruft is still unreliably garbage..