From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754140AbcKJA77 convert rfc822-to-8bit (ORCPT ); Wed, 9 Nov 2016 19:59:59 -0500 Received: from mail.kernel.org ([198.145.29.136]:60900 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753088AbcKJA76 (ORCPT ); Wed, 9 Nov 2016 19:59:58 -0500 MIME-Version: 1.0 In-Reply-To: References: <27296716.H9VWo8ShOm@vostro.rjw.lan> <13957403.ZrB4mMbICz@vostro.rjw.lan> <2715729.9U1nlcpFb3@vostro.rjw.lan> <20161026111902.GA6447@wunner.de> <20161027152551.GA15718@kroah.com> <20161107212250.GH1764@wotan.suse.de> From: "Luis R. Rodriguez" Date: Wed, 9 Nov 2016 16:59:30 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support To: "Rafael J. Wysocki" Cc: 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 , Laurent Pinchart , Lars-Peter Clausen , Grant Likely , Mauro Carvalho Chehab , Dmitry Torokhov , Andrzej Hajda Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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/003425.html Geert can you provide more details? 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. Luis