From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754550AbcIIMSD (ORCPT ); Fri, 9 Sep 2016 08:18:03 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:55512 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751120AbcIIMSB (ORCPT ); Fri, 9 Sep 2016 08:18:01 -0400 Date: Fri, 9 Sep 2016 13:17:49 +0100 From: Mark Brown To: Andy Shevchenko Cc: "linux-kernel@vger.kernel.org" , "Hunter, Adrian" Message-ID: <20160909121749.GR27946@sirena.org.uk> References: <1472741623.4887.482.camel@linux.intel.com> <20160901153836.GI5967@sirena.org.uk> <1472746516.4887.489.camel@linux.intel.com> <20160901170215.GJ5967@sirena.org.uk> <1473091312.11323.20.camel@linux.intel.com> <20160906102407.GF3950@sirena.org.uk> <1473258241.11323.83.camel@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TDVcAd+kFgbLxwBe" Content-Disposition: inline In-Reply-To: <1473258241.11323.83.camel@linux.intel.com> X-Cookie: Question authority. User-Agent: Mutt/1.6.0 (2016-04-01) X-SA-Exim-Connect-IP: 2a01:348:6:8808:fab::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: Regulator probe X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: No (on mezzanine.sirena.org.uk); Unknown failure Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --TDVcAd+kFgbLxwBe Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 07, 2016 at 05:24:01PM +0300, Andy Shevchenko wrote: > On Tue, 2016-09-06 at 11:24 +0100, Mark Brown wrote: > > Nothing says you have to describe all regulators, you just need to > > tell the core you have told it about everything you're going to tell > > it about.=A0=A0Until you do that the core has to assume that something = may > > come along later and describe that supply. > That's I would like to make work. For now we have fixed voltage > regulator which returns EPROBE_DEFER since GPIO IP is not initialized > yet at that point. But regulator framework decides that it's not > possible case and overrides the error code. What do you mean? Of course we should handle probe deferral if we fail to get a resource like a GPIO. Are you trying to say that this doesn't work for you? > For me it still looks that regulator framework would not intercept > deferred regulators in case of full constraints. Feels like I'm missing > something... I can't parse the above, sorry. --TDVcAd+kFgbLxwBe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX0qhsAAoJECTWi3JdVIfQ544H/jYwwzAZAwNAlm9IToDof1Rr ZCmBVlWKsdDvPD9IpgDslhCQvDSbS9L5LsjDeKwDVxDG5vaY0Eq+oFVS4aSM0Qh8 QRuMpWL7Emw4GdpUjwolvMpp5fC0gqP5kpV6cAWVURfuMiZ9I6DcraKRghklvvKz 4kvlPLeX1sypUk2H/kJSlSdpI2iA8egKjbiPswa8SZkbxl1U+uFTQQG8Z/0wZjj/ sci28JU5Z21bhhJfg4Wj70/hWWjiV605nRreKn7rH1E//X4RwcoebMOQwHncVtmr cSUGCi0+tYUr3h2hybJJrPV7WcehrwzUP57bnNOm8dCVzmatBAwFMvixvWkm0hA= =0YP6 -----END PGP SIGNATURE----- --TDVcAd+kFgbLxwBe--