Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756177AbbGFXd7 (ORCPT ); Mon, 6 Jul 2015 19:33:59 -0400 Received: from mail-ie0-f175.google.com ([209.85.223.175]:36723 "EHLO mail-ie0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751862AbbGFXdu (ORCPT ); Mon, 6 Jul 2015 19:33:50 -0400 Date: Mon, 6 Jul 2015 16:33:45 -0700 From: Dmitry Torokhov To: Dan Williams Cc: Greg Kroah-Hartman , "Luis R . Rodriguez" , Tejun Heo , Linux Kernel Mailing List , Arjan van de Ven , Rusty Russell , Olof Johansson , Tetsuo Handa Subject: Re: [PATCH 2/8] driver-core: add asynchronous probing support for drivers Message-ID: <20150706233345.GE32140@dtor-ws> References: <1427757610-27882-1-git-send-email-dmitry.torokhov@gmail.com> <1427757610-27882-3-git-send-email-dmitry.torokhov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3673 Lines: 77 On Sat, Jun 27, 2015 at 04:45:25PM -0700, Dan Williams wrote: > On Mon, Mar 30, 2015 at 4:20 PM, Dmitry Torokhov > wrote: > > Some devices take a long time when initializing, and not all drivers are > > suited to initialize their devices when they are open. For example, > > input drivers need to interrogate their devices in order to publish > > device's capabilities before userspace will open them. When such drivers > > are compiled into kernel they may stall entire kernel initialization. > > > > This change allows drivers request for their probe functions to be > > called asynchronously during driver and device registration (manual > > binding is still synchronous). Because async_schedule is used to perform > > asynchronous calls module loading will still wait for the probing to > > complete. > > > > Note that the end goal is to make the probing asynchronous by default, > > so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a temporary > > measure that allows us to speed up boot process while we validating and > > fixing the rest of the drivers and preparing userspace. > > > > This change is based on earlier patch by "Luis R. Rodriguez" > > > > > > Signed-off-by: Dmitry Torokhov > > --- > > drivers/base/base.h | 1 + > > drivers/base/bus.c | 31 +++++++--- > > drivers/base/dd.c | 149 ++++++++++++++++++++++++++++++++++++++++++------- > > include/linux/device.h | 28 ++++++++++ > > 4 files changed, 182 insertions(+), 27 deletions(-) > > Just noticed this patch. It caught my eye because I had a hard time > getting an open coded implementation of asynchronous probing to work > in the new libnvdimm subsystem. Especially the messy races of tearing > things down while probing is still in flight. And that is exactly the reason why asynchronous probing was moved into driver code. It knows the state of the device and knows when it is OK to remove it or start suspend transitions, etc. > I ended up implementing > asynchronous device registration which eliminated a lot of complexity > and of course the bugs. serio and gameport subsystems have been using asynchronous registration for ages (not because of probing but because of issues with serio ports - such as Synaptics pass-through - stacked on top of each other and historicaly driver code deadlocking if you try to register child device on the same bus that parent is). However I was never too happy with it because with asynchronous registration you can't really handle errors. What do you do if device registartion fails? > In general I tend to think that async > registration is less risky than async probe since it keeps wider > portions of the traditional device model synchronous and leverages the > fact that the device model is already well prepared for asynchronous > arrival of devices due to hotplug. Splitting the "initial probe" from > the "manual probe" case seems like a recipe for confusion. The split is because again serio and USB subsystems resort to somewhat manual binding due to the need of handling recursion on the bus. But otherwise we already have asynchronous probing, because we have deferred probes and also driver modules can be loaded asynchronously with device registration. If you have concrete examples where asynchronous probig as it merged causes issues I'd love to hear and fix them. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/