Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4304740ybl; Mon, 9 Dec 2019 08:38:35 -0800 (PST) X-Google-Smtp-Source: APXvYqzQgSc9GkOMRLAi3gTk9ET4CfFeBPgWJUDT8uceoxi/3DbrGehBV5gGz6gpqqzCCZkOqqKM X-Received: by 2002:a05:6830:1e30:: with SMTP id t16mr22524585otr.220.1575909515872; Mon, 09 Dec 2019 08:38:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575909515; cv=none; d=google.com; s=arc-20160816; b=USNzLhW3gVKslPH/CAB9qCmaYCaZiov+ZyeKEizvO8irc1svAxlbDGS+QKL1EMFqSD YEIFNxSMo+/yUfu7T4PcE8RYPXqaZDZxzbSHTyoIGBGTqQHfC0y4D9MUR6vkKSlQNZWj t1RLCdQ/8fonLy9XS70s8M5qx9c8n72gneJPujMbh2868uK4ecTTikWe65NGV1kl0ChL +0JtMguAV9L9sVmUPas7QWhsGZEMJJzkuXZuXhqoZPcxsTn2CSdY23q1dw9zja5lDZ5s UCjH4P9JASWEwoZTylpkCKn6eW7ahgjmK4zyUITTgU02oRLQ0zYJdctMYJiZXxLA3TAg lA/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=SpfUXVeurh67n0MMrgmkB9dmQ/xhk4EaRvWdTYnYOmg=; b=zojHAF27pDUQs/iP1klqOJVISpZClpUxahwZzD4Y/JOA+xtQt21dPzG/GCOgm97PPt AShibd+KVgwrWpsxmXth2H+ROMgQxFfUH8t3LRK8yGSiF3ChORNEyr3gtxKlR0FOoTJk oduUyEG03PPTTeilm2oZGFluw3T2UHcc8V3ZtPB5g+fWMv0c3JkI71L6+hIjRb3evZD2 HxcUtD6tyqPVj1GRNArHNiSzFnAW8F1JZpLU/SUElbXwI3YoZJoLUwcpeIDESHbMFVR3 uXpcDVO1so3u14xGi1RkrDOSXc5eD04K0yOXjMEz+luGvgoi+1A1/nc68utl24SiLPSu AuQw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z23si80666otk.166.2019.12.09.08.38.24; Mon, 09 Dec 2019 08:38:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726614AbfLIQh6 (ORCPT + 99 others); Mon, 9 Dec 2019 11:37:58 -0500 Received: from foss.arm.com ([217.140.110.172]:37854 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725904AbfLIQh6 (ORCPT ); Mon, 9 Dec 2019 11:37:58 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 453F01FB; Mon, 9 Dec 2019 08:37:57 -0800 (PST) Received: from localhost (unknown [10.37.6.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B783F3F718; Mon, 9 Dec 2019 08:37:56 -0800 (PST) Date: Mon, 9 Dec 2019 16:37:55 +0000 From: Mark Brown To: Kieran Bingham Cc: Linux-Renesas , Liam Girdwood , Linux Kernel Mailing List , Laurent Pinchart , Jacopo Mondi , Niklas =?iso-8859-1?Q?S=F6derlund?= Subject: Re: Regulator probe on demand (or circular dependencies) Message-ID: <20191209163755.GF5483@sirena.org.uk> References: <23236201-a387-7257-35a4-ee4ed2f6bfd0@ideasonboard.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UBnjLfzoMQYIXCvq" Content-Disposition: inline In-Reply-To: <23236201-a387-7257-35a4-ee4ed2f6bfd0@ideasonboard.com> X-Cookie: We read to say that we have read. User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --UBnjLfzoMQYIXCvq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Dec 06, 2019 at 04:38:04PM +0000, Kieran Bingham wrote: > The MAX9286 also exposes 2 GPIO pins, as such I have configured the > MAX9286 driver [1] to expose a gpio-chip [2]. So this seems like a MFD then? The nice thing about using the MFD subsystem is that it means that the drivers for the various subsystems on the device can instantiate in any order and defer separately without interfering with each other which seems like it's the issue here. > - is there anything I can do here within regulator_dev_lookup() to > attempt creating the regulator_dev 'on-demand' when > of_find_regulator_by_node(node) returns empty? (or is that crazy, and > just a rabbit-hole?) This seems like a terrible idea, you'll have a half baked regulator in the system which will need special casing all over the place and doubtless be an ongoing source of bugs. --UBnjLfzoMQYIXCvq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl3ueGIACgkQJNaLcl1U h9DMDAf8CpQOBN0monPnjHxv964dVMtgkGtKsdUu8Oe9P6GjpeW7mEjijunzKrs6 sleWk7koDmdZlJkRnjYhnZISIOKlrxLG5qWQPXaQDhtEJMcyqMiKNL4lTk5UVDbB sKMmSyFw+cOK03ocOiwZ3qVFXO8SpT3Xw3lp+1sw2z7v+R9LhY0QcicaqYmvtxal DsH+LmdJfATO5dLdHYWBnBGoFMr5o5POk8WkqkualCFU3pSkA6khlR9KegwfzK6l uy1zPcsMkrN47yYTFXREAZarPhmQ5AfSsE/k/qeyJiElP/uXJdhNswPYAO6m/yxr jyWeDQX+l3rCS6EGzdJgNVYymBxFgw== =AasC -----END PGP SIGNATURE----- --UBnjLfzoMQYIXCvq--