From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754329AbcKJHOc (ORCPT ); Thu, 10 Nov 2016 02:14:32 -0500 Received: from galahad.ideasonboard.com ([185.26.127.97]:51481 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753412AbcKJHOa (ORCPT ); Thu, 10 Nov 2016 02:14:30 -0500 From: Laurent Pinchart To: "Luis R. Rodriguez" Cc: "Rafael J. Wysocki" , Greg Kroah-Hartman , 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 Subject: Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support Date: Thu, 10 Nov 2016 09:14:32 +0200 Message-ID: <2305706.WydXUuMppH@avalon> User-Agent: KMail/4.14.10 (Linux/4.8.6-gentoo; KDE/4.14.24; x86_64; ; ) In-Reply-To: References: <27296716.H9VWo8ShOm@vostro.rjw.lan> MIME-Version: 1.0 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-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uAA7EbEO021422 Hi Luis, On Wednesday 09 Nov 2016 16:59:30 Luis R. Rodriguez wrote: > On Wed, Nov 9, 2016 at 4:43 PM, Rafael J. Wysocki wrote: > > On Mon, Nov 7, 2016 at 10:22 PM, Luis R. Rodriguez wrote: > >> On Thu, Oct 27, 2016 at 05:25:51PM +0200, Greg Kroah-Hartman wrote: > >>> On Wed, Oct 26, 2016 at 01:19:02PM +0200, Lukas Wunner wrote: > >>>> Hi Rafael, > >>>> > >>>> sorry for not responding to v5 of your series earlier, just sending > >>>> this out now in the hope that it reaches you before your travels. > >>>> > >>>> On Mon, Oct 10, 2016 at 02:51:04PM +0200, Rafael J. Wysocki wrote: > >>>>> - Modify device_links_check_suppliers(), > >>>>> device_links_driver_bound(), > >>>>> > >>>>> device_links_no_driver(), device_links_driver_cleanup(), > >>>>> device_links_busy(), and device_links_unbind_consumers() to walk > >>>>> link lists under device_links_lock (to make the new "driver > >>>>> presence tracking" mechanism work reliably). > >>>> > >>>> This change might increase boot time if drivers return -EPROBE_DEFER. > >>> > >>> "might"? Please verify this before guessing.... > >>> > >>> And don't make this more complex than needed before actually determining > >>> a real issue. > >> > >> As clarified by Rafael at Plumbers, this functional dependencies > >> framework assumes your driver / subsystem supports deferred probe, > > > > It isn't particularly clear what you mean by "support" here. > > I noted some folks had reported issues, and you acknowledged that if > deferred probe was used in some drivers and if this created an issue > the same issue would be seen with this framework. AFAICT there are two > possible issues to consider: > > 1) the one Geert Uytterhoeven noted. Again I'll note what he had mentioned > [0]. > > "Some drivers / subsystems don’t support deferred probe yet, such failures > usually don’t blow up, but cause subtle malfunctioning. Example, an > Ethernet phy could not get its interrupt as the primary IRQ chip had not > been probed yet, it reverted to polling though. Sub-optimal." [0] > > [0] > https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003 > 425.html > > Geert can you provide more details? This is a more global issue. In many cases drivers depend on optional resources. They are able to operate in a degraded mode (reduced feature set, reduced performances, ...) when those resources are not present. They can easily determine at probe time whether those resources are present, but have no way to know, in case they're absent, whether they will be present at some point in the near future (due to another driver probing the device providing the resource for instance) or if they will never be present (for instance because the required driver is missing). In the first case it would make sense to defer probe, in the latter case deferring probe forever for missing optional resources would prevent the device from being probed successfully at all. The functional dependencies tracking patch series isn't meant to address this issue. I can imagine a framework that would notify drivers of optional resource availability after probe time, but it would come at a high cost for drivers as switching between modes of operation at runtime based on the availability of such resources would be way more complex than a mechanism based on probe deferral. > 2) Since deferred probe relies on late_initcall() if your driver must > load earlier than this deferred probe can create an issue. Andrzej had > you identified a driver that ran into this and had issues ? If not > this seems like a semantics thing we should consider in extending the > documentation for drivers so that driver writers are aware of this > limitation. I would suppose candidates for this would be anything not > using module_init() or late_initcall() on their inits and have a > probe. > > >> if it does not support its not clear what will happen.... > > > > I don't see any problems here, but if you see any, please just say > > what they are. > > > >> We have no explicit semantics to check if a driver / subsystem > >> supports deferred probe. > > > > That's correct, but then do we need it? > > We can determine this by reviewing the two items above. -- Regards, Laurent Pinchart