From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756026AbcKJWNH (ORCPT ); Thu, 10 Nov 2016 17:13:07 -0500 Received: from mx2.suse.de ([195.135.220.15]:49228 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755957AbcKJWNF (ORCPT ); Thu, 10 Nov 2016 17:13:05 -0500 Date: Thu, 10 Nov 2016 23:12:59 +0100 From: "Luis R. Rodriguez" To: Geert Uytterhoeven Cc: "Luis R. Rodriguez" , "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 , Laurent Pinchart , Lars-Peter Clausen , Grant Likely , Mauro Carvalho Chehab , Dmitry Torokhov , Andrzej Hajda , Christoph Hellwig , Arnd Bergmann , Joerg Roedel Subject: Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support Message-ID: <20161110221259.GS13978@wotan.suse.de> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 10, 2016 at 09:46:42AM +0100, Geert Uytterhoeven wrote: > On Thu, Nov 10, 2016 at 1:59 AM, 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: > >>> 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? > > Issue reported in "of_mdiobus_register_phy() and deferred probe" > (http://lkml.iu.edu/hypermail/linux/kernel/1510.2/05770.html) > > Key point is: > "However, of_mdiobus_register_phy() uses irq_of_parse_and_map(), which plainly > ignores EPROBE_DEFER, and it just continues." > > At that time, the PHY driver fell back to polling, but as of commit d5c3d8465 > ("net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS") that's no longer the > case, and now the PHY fails to work completely. > > Workaround is "[PATCH v2] irqchip/renesas-irqc: Postpone driver initialization" > (https://www.spinics.net/lists/netdev/msg403325.html), which seems to have > sparked some interest in fixing the issue for good ;-) Ah playing with init levels. You are lucky here that this suffices, the IOMMU folks already ran out with enough levels to play with so they cannot resolve their issue this way, for instance. Luis From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Luis R. Rodriguez" Subject: Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support Date: Thu, 10 Nov 2016 23:12:59 +0100 Message-ID: <20161110221259.GS13978@wotan.suse.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Geert Uytterhoeven Cc: "Luis R. Rodriguez" , "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 , Laurent Pinchart , Lars-Peter Clausen , Grant Likely , Mauro Carvalho Chehab , Dmitry Torokhov List-Id: linux-pm@vger.kernel.org On Thu, Nov 10, 2016 at 09:46:42AM +0100, Geert Uytterhoeven wrote: > On Thu, Nov 10, 2016 at 1:59 AM, 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: > >>> 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? > > Issue reported in "of_mdiobus_register_phy() and deferred probe" > (http://lkml.iu.edu/hypermail/linux/kernel/1510.2/05770.html) > > Key point is: > "However, of_mdiobus_register_phy() uses irq_of_parse_and_map(), which plainly > ignores EPROBE_DEFER, and it just continues." > > At that time, the PHY driver fell back to polling, but as of commit d5c3d8465 > ("net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS") that's no longer the > case, and now the PHY fails to work completely. > > Workaround is "[PATCH v2] irqchip/renesas-irqc: Postpone driver initialization" > (https://www.spinics.net/lists/netdev/msg403325.html), which seems to have > sparked some interest in fixing the issue for good ;-) Ah playing with init levels. You are lucky here that this suffices, the IOMMU folks already ran out with enough levels to play with so they cannot resolve their issue this way, for instance. Luis