[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230324092141.GN68926@ediswmail.ad.cirrus.com>
Date: Fri, 24 Mar 2023 09:21:41 +0000
From: Charles Keepax <ckeepax@...nsource.cirrus.com>
To: Mark Brown <broonie@...nel.org>
CC: Doug Anderson <dianders@...omium.org>,
Marek Szyprowski <m.szyprowski@...sung.com>,
<linux-kernel@...r.kernel.org>,
<linux-samsung-soc@...r.kernel.org>,
Liam Girdwood <lgirdwood@...il.com>,
<patches@...nsource.cirrus.com>
Subject: Re: [PATCH] regulator: wm8994: Use PROBE_FORCE_SYNCHRONOUS
On Thu, Mar 23, 2023 at 05:49:28PM +0000, Mark Brown wrote:
> On Thu, Mar 23, 2023 at 05:45:31PM +0000, Charles Keepax wrote:
>
> > I think really the best place to look at this would be at the
> > regulator level. It is fine if mfd_add_devices passes, the problem
> > really is that the regulator core doesn't realise the regulator is
> > going to be arriving, and thus returns a dummy regulator, rather
> > than returning EPROBE_DEFER. If it did the MFD driver would probe
> > defer at the point of requesting the regulator, which would all
> > make sense.
>
> You need the MFD to tell the regulator subsystem that there's a
> regulator bound there, or to force all the users to explicitly do the
> mapping of the regulator in their firmwares (which isn't really a
> viable approach).
Yeah changing the firmware situation is definitely not a goer. I
need to just clarify in my head exactly what is missing, with
respect to the know the regulator exists.
Thanks,
Charles
Powered by blists - more mailing lists