[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191209163755.GF5483@sirena.org.uk>
Date: Mon, 9 Dec 2019 16:37:55 +0000
From: Mark Brown <broonie@...nel.org>
To: Kieran Bingham <kieran.bingham@...asonboard.com>
Cc: Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
Liam Girdwood <lgirdwood@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Jacopo Mondi <jacopo@...ndi.org>,
Niklas Söderlund
<niklas.soderlund@...natech.se>
Subject: Re: Regulator probe on demand (or circular dependencies)
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.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists