From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753865AbbCEA4j (ORCPT ); Wed, 4 Mar 2015 19:56:39 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:50342 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753811AbbCEA4h (ORCPT ); Wed, 4 Mar 2015 19:56:37 -0500 Date: Thu, 5 Mar 2015 00:56:14 +0000 From: Mark Brown To: Bjorn Andersson Cc: Stephen Boyd , Ian Campbell , Kumar Gala , Lee Jones , Liam Girdwood , Mark Rutland , Pawel Moll , Rob Herring , Andy Gross , Chanwoo Choi , Krzysztof Kozlowski , Srinivas Kandagatla , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-msm@vger.kernel.org" Message-ID: <20150305005614.GC21293@sirena.org.uk> References: <1425356740-26285-1-git-send-email-bjorn.andersson@sonymobile.com> <1425356740-26285-5-git-send-email-bjorn.andersson@sonymobile.com> <54F75E8F.2070900@codeaurora.org> <20150304235146.GP26334@sonymobile.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DEyyzOu/laT6xolt" Content-Disposition: inline In-Reply-To: <20150304235146.GP26334@sonymobile.com> X-Cookie: My LESLIE GORE record is BROKEN ... 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 4/4] regulator: qcom: Rework to single platform device 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 --DEyyzOu/laT6xolt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Mar 04, 2015 at 03:51:46PM -0800, Bjorn Andersson wrote: > I took a stab at implementing EPROBE_DEFER within qcom_rpm-regulator, > but as it's a mixture of internal and external dependencies (e.g. > <&pm8921_s4> vs <&pm8921_mpp 7>) this became quite messy. I started > looking at using the dt dependencies sort and iterate over the entries > in a way that adheres to their dependencies, but that's also a lot of > code. This is why I don't like trying to open code in subsystems, it's too much work. > So I think you're right, we should be able to alter the supply lookup > code to defer the EPROBE_DEFER until we actually need the supply to be > there; e.g. attempt to map supplies when an external consumer request > the regulator. > Some care needs to be taken with regards to e.g. always-on regulators. I'm not sure why always on regulators would need special casing here? Enabling is orthogonal to supply mapping. Like I said in reply to Stephen's mail I'm more worried about discoverability of problems with this approach and with interactions with dependencies on other subsystems (mainly GPIOs). Thinking about it some more the other subsystems will probably sort themselves out but the diagnosics are an issue. I do like the idea of a general mechanism for registering dependency resources and deferring completion until they're ready more - I'm not sure it's even that much more work, especially if the first cut only handles regulators as a dependency... that feels like attacking the right problem, there's other things people are raising with deferred probe like your complaint about logging. --DEyyzOu/laT6xolt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJU96mtAAoJECTWi3JdVIfQwsIIAIboJ7G/1gX+xd/Bf9e0ufaw 5xzMIFDTN52UATPye4HrnNIi55e89DTK/6SLlt2+bvh+yICh8d+ra5awdFT0t7jy /JByNUvqxmiHkyNBr3A0tYCsiCQhRn+2lV0hC7aJtgT+LawA/Iip5LhtdKZgul2B 5NRsiPygklm5Cng1l7ThC7hGgMJzDsMNCqte/90hvkHQNHwwciZW67eo0oT/dXOX DdiCet5vgSWKyAWAg0fn94GbMGLrh3QVH1GKiCykMmt+/1XAqsH/p29wsxBv5I98 E1RlnvHAvu8zjVMB2w2rq6UnNph03EFrTY0696XAujEOjFKMklQj5I915HDZIz8= =Piw/ -----END PGP SIGNATURE----- --DEyyzOu/laT6xolt--