Hi, On Thu, Mar 23, 2023 at 10:45 AM Charles Keepax <ckeepax@xxxxxxxxxxxxxxxxxxxxx> 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
