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
