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 S1753823AbbCSRFB (ORCPT <rfc822;w@1wt.eu>);
	Thu, 19 Mar 2015 13:05:01 -0400
Received: from mail-ie0-f179.google.com ([209.85.223.179]:36778 "EHLO
	mail-ie0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751453AbbCSRE5 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 19 Mar 2015 13:04:57 -0400
Date: Thu, 19 Mar 2015 10:04:52 -0700
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Luis R . Rodriguez" <mcgrof@suse.com>, linux-kernel@vger.kernel.org,
        Arjan van de Ven <arjan@linux.intel.com>,
        Rusty Russell <rusty@rustcorp.com.au>, Olof Johansson <olof@lixom.net>,
        Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Subject: Re: [PATCH 6/8] amd64_edac: enforce synchronous probe
Message-ID: <20150319170452.GJ30732@dtor-ws>
References: <20150318202605.GI11485@dtor-ws>
 <20150318210226.GE25365@htj.duckdns.org>
 <20150318214126.GJ11485@dtor-ws>
 <20150318215028.GF25365@htj.duckdns.org>
 <20150318221530.GK11485@dtor-ws>
 <20150318232401.GG25365@htj.duckdns.org>
 <20150319002619.GM11485@dtor-ws>
 <20150319154141.GJ25365@htj.duckdns.org>
 <20150319160146.GB30732@dtor-ws>
 <20150319161927.GM25365@htj.duckdns.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150319161927.GM25365@htj.duckdns.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Mar 19, 2015 at 12:19:27PM -0400, Tejun Heo wrote:
> Hello,
> 
> On Thu, Mar 19, 2015 at 09:01:46AM -0700, Dmitry Torokhov wrote:
> > I think that would be the goal, yes, but I think we'd need some "trial"
> > period before we can do that: I need to look into at least serial and
> > regulators to make it work (not even considering any userspace). We are
> > definitely not ready just yet and that is why I have a whitelist: there
> > are classes of devices that all userspaces learned to deal with long ago
> > and we can make them not stall boot right now.
> 
> Yeah, as I wrote before, as long as there's a plan and push to finish
> the conversion, it's fine.  I'm just worried that this might rot in
> the grey area.  Can we please update the patches so that it's clear
> that the whitelist is a temporary measure both in the description and
> code?

OK, will do.

Thanks.

-- 
Dmitry