From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Kroah-Hartman Subject: Re: [RFD] Functional dependencies between devices Date: Thu, 7 Jan 2016 13:29:24 -0800 Message-ID: <20160107212924.GA3899@kroah.com> References: <1623682.7KVblAB3KQ@vostro.rjw.lan> <20151030225242.GA2480@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail.linuxfoundation.org ([140.211.169.12]:54380 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753146AbcAGV30 (ORCPT ); Thu, 7 Jan 2016 16:29:26 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Tomeu Vizoso Cc: "Rafael J. Wysocki" , Linux PM list , Linux Kernel Mailing List , Alan Stern , Grant Likely , Mark Brown , Rob Herring , Thierry Reding , Dmitry Torokhov , Geert Uytterhoeven , Michael Turquette On Thu, Jan 07, 2016 at 03:55:43PM +0100, Tomeu Vizoso wrote: > On 30 October 2015 at 23:52, Greg Kroah-Hartman > wrote: > > On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote: > >> My idea is to represent a supplier-consumer dependency between devices (or > >> more precisely between device+driver combos) as a "link" object containing > >> pointers to the devices in question, a list node for each of them and some > >> additional information related to the management of those objects, ie. > >> something like: > >> > >> struct device_link { > >> struct device *supplier; > >> struct list_head supplier_node; > >> struct device *consumer; > >> struct list_head consumer_node; > >> > >> }; > >> > >> In general, there will be two lists of those things per device, one list > >> of links to consumers and one list of links to suppliers. > >> > >> In that picture, links will be created by calling, say: > >> > >> int device_add_link(struct device *me, struct device *my_supplier, unsigned int flags); > > > > At first glance, I like this, nice. Now to see how well it can be > > implemented :) > > Hi Greg, > > what's your opinion on using this to order device probes so we don't > try to probe a device that we know it has unfulfilled dependencies? Why would that matter, unless you can prove it's faster, I wouldn't bother. greg k-h