From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752113AbbIKJ6W (ORCPT ); Fri, 11 Sep 2015 05:58:22 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:59759 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751296AbbIKJ6V (ORCPT ); Fri, 11 Sep 2015 05:58:21 -0400 Date: Fri, 11 Sep 2015 10:57:48 +0100 From: Mark Brown To: Tomeu Vizoso Cc: "linux-kernel@vger.kernel.org" , Rob Herring , Stephen Warren , Javier Martinez Canillas , Thierry Reding , "Rafael J. Wysocki" , "linux-arm-kernel@lists.infradead.org" , Dmitry Torokhov , "devicetree@vger.kernel.org" , Linus Walleij , linux-acpi@vger.kernel.org, Arnd Bergmann Message-ID: <20150911095748.GC12027@sirena.org.uk> References: <1438870315-18689-1-git-send-email-tomeu.vizoso@collabora.com> <1438870315-18689-3-git-send-email-tomeu.vizoso@collabora.com> <20150807121913.GS20873@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4bvUAv41pAMZZO4U" Content-Disposition: inline In-Reply-To: X-Cookie: You are fairminded, just and loving. User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH v3 02/18] of/platform: add of_platform_probe X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --4bvUAv41pAMZZO4U Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Sep 07, 2015 at 02:31:06PM +0200, Tomeu Vizoso wrote: > On 11 August 2015 at 11:37, Tomeu Vizoso wrote: > > On 7 August 2015 at 14:19, Mark Brown wrote: > >> This sounds like it's going to break in the case where we have MFDs that > >> represent their functions in DT (not a pattern I'm a fan of but it's a > >> thing people do). We'll walk back to the platform device for the MFD > >> function, try to probe it and then give up. Perhaps that's good enough > >> anyway but it's not clear to me why we don't just try every parent we > >> find? > > Agreed. In the attempt at probing dependencies before a device is > > probed, I considered that a device's parent is also a dependency and > Actually I'm not sure how we could probe the ascendants on demand, as > currently the parent's device lock is taken when probing so trying to > probe a sibling from within a probe callback will cause a deadlock. How do silbilings come into this? There is an issue there but it's going to happen anyway. > AFAICS this is only needed for USB interface devices and this > behaviour could be limited to them, but I don't like much assuming > that no USB device will ever have a dependency on a sibling (though > that probably won't happen ever). I don't see the connection with USB here, sorry - my initial thought was about MFDs? --4bvUAv41pAMZZO4U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV8qWbAAoJECTWi3JdVIfQtRAIAIKSMpgbcRgxWdpNouUsNPIA hJ8YYMUQ3lNONrAxmnbe2ShJquLWAyDclJxktCTF5O0bUR/YBRtSsCw/VNs1QVHa gkef87/G3//3dKHJiKSFuBNtDoyY6sbCMTCINoJbnhIj3I9HEkdOu5jJE8jv0XwT Vah+s1XtZw5FxG91HPA4OlTFIFa6QUUc5PnvcfTPcazQpg6UNIf2FxjKdK5rYHcd obHUqJp27OFhSqs5ThH1kfvqVmwCyZ6IMyIgyyMhUW6cwmzTjbkxh64Gam4fvylP Ys/FqyFAz6+5YZkwsIyhq8BsDcR8Y/Kjqs1e/AnVoYzKVSzjizCUuURPBjorEt0= =Dg+/ -----END PGP SIGNATURE----- --4bvUAv41pAMZZO4U--