Hi Kieran, On 2019-12-09 17:03:38 +0000, Kieran Bingham wrote: > Hi Mark, > > Thanks for getting back to me, > > On 09/12/2019 16:37, Mark Brown wrote: > > On Fri, Dec 06, 2019 at 04:38:04PM +0000, Kieran Bingham wrote: > > > >> The MAX9286 also exposes 2 GPIO pins, as such I have configured the > >> MAX9286 driver [1] to expose a gpio-chip [2]. > > > > So this seems like a MFD then? The nice thing about using the MFD > > subsystem is that it means that the drivers for the various subsystems > > on the device can instantiate in any order and defer separately without > > interfering with each other which seems like it's the issue here. > > Well that's part of the problem... the V4L2 async framework can not > currently support the device performing a probe-defer at all, so it > *will* fail later (and crash currently). > > I hope we can fix this sometime - but it's a recurring pain point it > seems. Unless it's just our video-capture driver, I'll have to dig > deeper here, and check with Niklas. The problem is that we can't register, unregister and re-regsiter a video device in a sane way. One easy solution to this is to not register the max9286 v4l2 subdevice until we know that the probe do not need to be deferred as this would sidestep the whole v4l2 issue described above. > > > >> - is there anything I can do here within regulator_dev_lookup() to > >> attempt creating the regulator_dev 'on-demand' when > >> of_find_regulator_by_node(node) returns empty? (or is that crazy, and > >> just a rabbit-hole?) > > > > This seems like a terrible idea, you'll have a half baked regulator in > > the system which will need special casing all over the place and > > doubtless be an ongoing source of bugs. > > Thanks - that's essentially what I'm glad to hear /before/ going down > some rabbit hole. I'll re-evaluate with the team, and see what the next > best steps are. > > -- > Regards > -- > Kieran -- Regards, Niklas Söderlund
