On Thu, Mar 23, 2023 at 09:53:18AM -0700, Doug Anderson wrote: > On Thu, Mar 23, 2023 at 4:40 AM Charles Keepax > If my analysis is correct, there's still potential to run into similar > problems even with PROBE_FORCE_SYNCHRONOUS. I don't think that > mfd_add_devices() is _guaranteed_ to finish probing all the > sub-devices by the time it returns. Specifically, imagine that > wm8994_ldo_probe() tries to get a GPIO that that system hasn't made > available yet. Potentially the system could return -EPROBE_DEFER there > and that would put the LDO on the deferred probe list. Doing so won't > cause mfd_add_devices() to fail. Now we'll end up with a dummy > regulator again. Admittedly most cases GPIO providers probe really > early and so this argument is a bit of a stretch, but I guess the > point is that there's no official guarantee that mfd_add_devices() > will finish probing all sub-devices so it's not ideal to rely on. > Also, other drivers with a similar pattern might have other reasons to > -EPROBE_DEFER. > > These types of issues are the same ones I faced with DP AUX bus and > the solutions were never super amazing... > > One solution we ended up with for the DP AUX bus was to add a > "done_probing" callback argument to devm_of_dp_aux_populate_bus(). > This allowed the parent to be called back when all the children were > done probing. This implementation is easier for DP AUX bus than it > would be in the generic MFD case, but conceivably it would be possible > there too? > > Another possible solution is to somehow break the driver up into more > sub-drivers. Essentially, you have a top-level "wm8994" that's not > much more than a container. Then you create a new-sub-device and > relegate anything that needs the regulators to the new sub-device. The > new sub-device can just -EPROBE_DEFER until it detects that the > regulators have finished probing. I ended up doing stuff like this for > "ti-sn65dsi86.c" using the Linux aux bus (not to be confused with the > DP Aux bus) and it was a bit odd but worked OK. Yes I believe you are correct, there is still an issue here, indeed a quick test suggests I can still cause this by forcing a probe defer in the regulator driver. 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 will see if I can find some time to think about that further but very unlikely to happen this week. Thanks, Charles
