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. >> - 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
