From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757384AbbJ2ObK (ORCPT ); Thu, 29 Oct 2015 10:31:10 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:54120 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751045AbbJ2ObJ (ORCPT ); Thu, 29 Oct 2015 10:31:09 -0400 Date: Thu, 29 Oct 2015 10:31:08 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Tomeu Vizoso cc: "Rafael J. Wysocki" , Linux PM list , Greg Kroah-Hartman , Linux Kernel Mailing List , Grant Likely , Mark Brown , Rob Herring , Thierry Reding , Dmitry Torokhov , Geert Uytterhoeven , Michael Turquette Subject: Re: [RFD] Functional dependencies between devices In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Good grief, don't you guys ever trim unwanted material from your emails? I had to erase more than 4 screens worth of useless stuff before getting to the relevant portions. On Thu, 29 Oct 2015, Tomeu Vizoso wrote: > >> Also, have you considered that not only drivers request resources? For > >> example, the on-demand probing series would probe a device that is > >> needed by an initcall, simplifying synchronization. Did Rafael ever say that only drivers could create these functional dependencies? I don't recall seeing that anywhere. Presumably any part of the kernel will be allowed to do it. > > You really need to explain what you mean here or maybe give an example. > > There are initcalls that assume that a given resource is available. > Because of async probes, or because the resource's driver being built > as a module, or because the resource's driver gained a dependency > (direct or not), those initcalls break unexpectedly at times. > > If resource getters could probe dependencies on-demand, those > initcalls would be more robust to changes in other parts of the > codebase. > > AFAIUI, your proposal would help with a device's dependencies being > there when it's probed, but initcalls could still run into unfulfilled > dependencies. One possible approach is to have a "wait_for_driver" flag, along with a timeout value (or perhaps using a fixed timeout value). When a dependency gets registered with this flag set, the function call wouldn't return until the target device is bound to a driver or the timeout has elapsed. This would make it easy to insert dependencies at probe time without relying on deferred probing. Alan Stern