Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965975AbcKKAIg (ORCPT ); Thu, 10 Nov 2016 19:08:36 -0500 Received: from galahad.ideasonboard.com ([185.26.127.97]:55079 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933073AbcKKAId (ORCPT ); Thu, 10 Nov 2016 19:08:33 -0500 From: Laurent Pinchart To: Greg Kroah-Hartman Cc: "Luis R. Rodriguez" , "Rafael J. Wysocki" , Lukas Wunner , "Rafael J. Wysocki" , Linux PM list , Alan Stern , Linux Kernel Mailing List , Tomeu Vizoso , Mark Brown , Marek Szyprowski , Kevin Hilman , Ulf Hansson , Geert Uytterhoeven , Lars-Peter Clausen , Grant Likely , Mauro Carvalho Chehab , Dmitry Torokhov , Andrzej Hajda , Christoph Hellwig , Arnd Bergmann Subject: Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support Date: Fri, 11 Nov 2016 02:08:35 +0200 Message-ID: <3465624.0TqEj8I9ee@avalon> User-Agent: KMail/4.14.10 (Linux/4.8.6-gentoo; KDE/4.14.24; x86_64; ; ) In-Reply-To: <20161110224054.GA10575@kroah.com> References: <27296716.H9VWo8ShOm@vostro.rjw.lan> <20161110220407.GQ13978@wotan.suse.de> <20161110224054.GA10575@kroah.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3787 Lines: 73 Hi Greg, On Thursday 10 Nov 2016 23:40:54 Greg Kroah-Hartman wrote: > On Thu, Nov 10, 2016 at 11:04:07PM +0100, Luis R. Rodriguez wrote: > > This is more forward looking, but -- if we had an annotation in > > Kconfig/turned to a mod info section, or to start off with just a driver > > MODULE_SUGGESTS() macro to start off with it might suffice for the driver > > core to request_module() annotated dependencies, such requests could be > > explicitly suggested as synchronous so init + probe do run together > > (as-is today), after which it could know that all possible drivers that > > needed to be loaded should now be loaded. If this sounds plausible to > > help, do we have drivers where we can test this on? For instance, since > > the functional dependency framework annotates functional dependencies for > > consumers/providers for suspend/resume and un time PM could such > > MODULE_SUGGESTS() annotations be considered on the consumers to suggest > > the provider drivers so their own probe yields to their providers to try > > first ? > > No. > > Stop. > > First off, the "driver core" NEVER can "know" if "all possible drivers > that should be loaded, are loaded. That way lies madness and > impossibility. > > Secondly, yet-another-section isn't going to help anything here, we > alredy "suggest" to userspace a bunch of stuff, so we get the needed > modules loaded, at sometime in the future, if they are around, and > userspace feels like it. That's the best we can ever do. > > Don't try to make this more difficult than it is please. DEFER works > today really really well, and it's really really simple. > Inter-dependancy of modules and devices connected to each other are two > different things, be careful about this. One issue we don't address today is handling of optional dependencies. A simple example is an SPI controller that can use a DMA engine or work in PIO mode. At probe time the driver will request a DMA channel if the platform (ACPI, DT, platform data) specifies that DMA is available. This can fail for various reasons, one of them being that the DMA engine driver hasn't probed the DMA device yet. In that case the SPI controller driver will continue in PIO mode, ignoring the DMA engine that will later be probed. We can't defer probing of the SPI controller as the DMA engine driver might never get loaded, which would result in the SPI controller probe being deferred forever. One solution for this type of dependency issue would be to notify the SPI controller driver after probe that the DMA channel is now available. I'd like to avoid that though, as it would drastically increase the complexity of lots of drivers and create lots of race conditions. There are certain configurations that we could possibly consider as invalid. For instance if the SPI controller driver is built-in and the DMA engine driver built as a module, the user clearly shot themselves in the foot and the kernel can't be blamed. For resources that can't be built as a module (IOMMUs for instance) we thus only have to consider the case where both drivers are built-in, as the resource built-in and consumer as a module should work properly from an ordering point of view (at least as long as we don't allow asynchronous probing of built-in drivers to be delayed enough for modules to be loaded...). In this case, if the resource driver isn't available when the consumer is probed, if will never be available at the consumer can safely proceed in a degraded mode. We would thus only need to solve the probe ordering issue. I'm not sure how far these simple(r) solutions that consider certain cases as invalid would scale though, and whether we won't need a more generic solution at some point anyway. -- Regards, Laurent Pinchart