Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932115AbcDKNJT (ORCPT ); Mon, 11 Apr 2016 09:09:19 -0400 Received: from mail-wm0-f43.google.com ([74.125.82.43]:35940 "EHLO mail-wm0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932086AbcDKNJS (ORCPT ); Mon, 11 Apr 2016 09:09:18 -0400 Date: Mon, 11 Apr 2016 15:09:14 +0200 From: Thierry Reding To: Mark Brown Cc: Jon Hunter , Liam Girdwood , linux-kernel@vger.kernel.org, Javier Martinez Canillas Subject: Re: [PATCH 1/5] regulator: core: Resolve supply earlier Message-ID: <20160411130914.GA16994@ulmo.ba.sec> References: <1460038959-21592-1-git-send-email-thierry.reding@gmail.com> <570B8376.6030505@nvidia.com> <20160411114612.GD17743@ulmo.ba.sec> <20160411125814.GE3351@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: <20160411125814.GE3351@sirena.org.uk> 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 Content-Length: 2232 Lines: 54 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 11, 2016 at 01:58:14PM +0100, Mark Brown wrote: > On Mon, Apr 11, 2016 at 01:46:12PM +0200, Thierry Reding wrote: > > On Mon, Apr 11, 2016 at 11:59:02AM +0100, Jon Hunter wrote: >=20 > > > Also, if we add this call, then I am wondering if we still need ... > > >=20 > > > class_for_each_device(®ulator_class, NULL, NULL, > > > regulator_register_resolve_supply); >=20 > > Possibly not. That line was introduced to hook up existing orphan > > regulators with their parents when they were registered, but I guess > > since we now always defer probe if a parent isn't registered yet the > > line would become a no-op. >=20 > That then takes us right the way back to the original problem where > people we're getting upset at the number of probe deferrals they were > seeing and more importantly we didn't have any way of sorting out > dependencies within a single PMIC if the parents weren't registered > before their children. Isn't that usually solved by making each regulator of a PMIC a separate device (platform device, typically, for MFD devices? That way each of them is probed separately allowing the dependency cycle to be broken. Thierry --liOOAslEiF7prFVr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXC6H4AAoJEN0jrNd/PrOh+IYP/RjejBh/l4BeFP+15/q0PRqP 4LU91PLzXtuKSuAaHQ33Hs4C4/QcQjvsAF1/KuT17wONNnK5JhqYmsohC3Dju1wH h6zMO3b1UzC7Grjbt+nsiUOQZI077kLtlvcw8PT6ZIwd3HfTo6kTW+KPdOj0GZ0j /3w+ZZSq5Ub4Pao+cygaZMaQeXFKXIBoFyyHl6m9EhJjkbkxJmQHfZokMB9eij0s sksLR/Dx+7otwsimnx7ZplMHxIka0UTZ2A1a2cpKyKy0t6NCr8I06u5BVw9g0vfK TmMP+eQjzGKvidParaELsY6IFlcm/GrPx8EIETD9YKbwDt7YnMA355glx8P/fIJ7 5iBjksDnNaiv8WkUdmLLTsvpyzm4TU3O1obotEO8ZUqkn8MI6T4V8/Enw4FGWh8j ABnv99wYWKP+G4QN1lQ14eUK7k0kCbBmxNc4qpa8/kSfxj8QSd1pfy1ZVF8rYGVC bQJFBojoo/TDfXnY0fqioKSOzMPIVgkHQF87XKZqpl9Bzo+yLWHQwPz3MyAZE0WO R5OE9pj52A4O7FT66nuD3LYohYSMYTMu0GE3cy9mv1f48YaB/4Ct1exzsYY4NRUW WstVDSJPmmPpVp+AcMqL/XFUjPoN/trJRVApeiL902vP/gUajucmC9l+clLDNL3k xKmvwtJMNplgFYNmhw45 =DPRw -----END PGP SIGNATURE----- --liOOAslEiF7prFVr--