[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=X0SAEk_iUGQ=J-PWk_MzVc7ZikBM3N8rrnhGFzcdBNpw@mail.gmail.com>
Date: Thu, 23 Mar 2023 11:00:32 -0700
From: Doug Anderson <dianders@...omium.org>
To: Charles Keepax <ckeepax@...nsource.cirrus.com>
Cc: Marek Szyprowski <m.szyprowski@...sung.com>,
linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>, patches@...nsource.cirrus.com
Subject: Re: [PATCH] regulator: wm8994: Use PROBE_FORCE_SYNCHRONOUS
Hi,
On Thu, Mar 23, 2023 at 10:45 AM Charles Keepax
<ckeepax@...nsource.cirrus.com> 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.
I think something like your suggestion could be made to work for the
"microphone" supply in the arizona MFD, but not for the others looked
at here.
The problem is that if the MFD driver gets -EPROBE_DEFER then it will
go through its error handling path and call mfd_remove_devices().
That'll remove the sub-device providing the regulator. If you try
again, you'll just do the same. :-)
Specifically in wm8994 after we've populated the regulator sub-devices
then we turn them on and start talking to the device.
I think the two options I have could both work for wm8994's case:
either add some type of "my children have done probing" to MFD and
move the turning on of regulators / talking to devices there, or add
another stub-device and add it there. ;-)
-Doug
Powered by blists - more mailing lists