[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230324154407.GP68926@ediswmail.ad.cirrus.com>
Date: Fri, 24 Mar 2023 15:44:07 +0000
From: Charles Keepax <ckeepax@...nsource.cirrus.com>
To: Doug Anderson <dianders@...omium.org>
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
On Fri, Mar 24, 2023 at 08:06:15AM -0700, Doug Anderson wrote:
> On Fri, Mar 24, 2023 at 2:23 AM Charles Keepax
> > On Thu, Mar 23, 2023 at 11:00:32AM -0700, Doug Anderson wrote:
> > > On Thu, Mar 23, 2023 at 10:45 AM Charles Keepax
> I've spent a whole lot of time dealing with similar issues, though,
> and I think there is actually another related concern with that design
> (where the regulator is synchronous). ;-) If the child device ends up
> depending on a resource that _never_ shows up then you can get into an
> infinite probe deferral loop at bootup. If it works the way it did
> last time I analyzed similar code:
>
> 1. Your MFD starts to probe and kicks off probing of its children
> (including the regulator).
>
> 2. Your regulator tries to probe and tries to get a resource that will
> never exist, maybe because of a bug in dts or maybe because it won't
> show up until userspace loads a module. It returns -EPROBE_DEFER.
>
> 3. The MFD realizes that the regulator didn't come up and it also
> returns -EPROBE_DEFER after removing all its children.
>
> 4. That fact that we added/removed devices in the above means that the
> kernel thinks it should retry probes of previously deferred devices
> because, maybe, the device showed up that everyone was waiting for.
> Thus, we go back to step #1.
>
> ...the system can actually loop forever in steps #1 - #4 and we ended
> up in that situation several times during development with similar
> architected systems.
Hmm... shoot yes you are correct that would indeed happen.
Thanks,
Charles
Powered by blists - more mailing lists