Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755306AbbFBKOj (ORCPT ); Tue, 2 Jun 2015 06:14:39 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:35711 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752507AbbFBKOa (ORCPT ); Tue, 2 Jun 2015 06:14:30 -0400 MIME-Version: 1.0 In-Reply-To: References: <1432565608-26036-1-git-send-email-tomeu.vizoso@collabora.com> From: Tomeu Vizoso Date: Tue, 2 Jun 2015 12:14:06 +0200 X-Google-Sender-Auth: mXXOJmiVMwiw4vu0N7fEUIXIgko Message-ID: Subject: Re: [PATCH 00/21] On-demand device registration To: Linus Walleij Cc: Grant Likely , Mark Rutland , "devicetree@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , linux-samsung-soc , "linux-tegra@vger.kernel.org" , "linux-gpio@vger.kernel.org" , "linux-pm@vger.kernel.org" , Dmitry Torokhov , "linux-kernel@vger.kernel.org" , Rob Herring , "linux-pwm@vger.kernel.org" , "open list:DRM PANEL DRIVERS" , dmaengine@vger.kernel.org, Alexander Holler , Dan Williams , "linux-usb@vger.kernel.org" , linux-clk@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" , "linux-i2c@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2871 Lines: 70 On 2 June 2015 at 10:48, Linus Walleij wrote: > On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso > wrote: > >> have looked into ordered probing as a >> better way of solving this than moving nodes around in the DT or playing with >> initcall levels. >> >> While reading the thread [1] that Alexander Holler started with his series to >> make probing order deterministic, it occurred to me that it should be possible >> to achieve the same by registering devices as they are referenced by other >> devices. > > This is pretty cool, but a too local solution to a global problem. > > Deferred probe and initcall reordering, silly as they may seem, > does not require you to use device tree. > > The real solution, which I think I pointed out already when we > added deferred probe, is to put dependency graphs in the drivers By this you mean something like what Thierry suggested here? http://article.gmane.org/gmane.linux.kernel/1774623 > and have the kernel device driver core percolate dependecies by > walking the graph on probing driver, removing driver (usually the > inverse use case), [runtime] suspend and [runtime] resumeing > a driver. Possibly the dependencies will even be different > depending on use case. > > This is what systemd is doing in userspace for starting services: > ask for your dependencies and wait for them if they are not > there. So drivers ask for resources and wait for them. It also > needs to be abstract, so for example we need to be able to > hang on regulator_get() until the driver is up and providing that > regulator, and as long as everything is in slowpath it should > be OK. (And vice versa mutatis mutandis for clk, gpio, pin > control, interrupts (!) and DMA channels for example.) I understood above that you propose probing devices in order, but now you mention that resource getters would block until the dependency is fulfilled which confuses me because if we are probing in order then all dependencies would be fulfilled before the device in question gets probed. > So if this should be solved it should be solved in an abstract way > in the device driver core available for all, then have calls calling > out to DT, ACPI, possibly even PCI or USB (as these > enumerate devices themselves) to obtain a certain > dependency. Yeah, I was planning looking into this now that I got it working with async probing. Thanks, Tomeu > Yours, > Linus Walleij > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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/