On Wed, Dec 11, 2019 at 10:42:43PM +0000, Kieran Bingham wrote: > On 09/12/2019 16:37, Mark Brown wrote: > >> - 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 > Ohh eep, I just re-read my description, and I don't think I described my > intention very well at all. (or at all!) > I wouldn't want to have just a half baked struct regulator_dev on it's > own ... I was more wondering if we can kick the core driver framework to > fully probe this regulator (which would thus create the required > regulator_dev structures). It was more a question of can we guide the > core driver framework that it really needs to probe this device > immediately ... Oh, I see. Last time I looked at this in any detail the driver core did probe things pretty much immediately when it got a new driver to match a device (or vice versa), some existing MFDs rely on that. > I was sort of wondering if something like this could optimise away some > of the -EPROBE_DEFER iterations at a more global level, but I don't know > how or if that would work anyway. In theory someone could try to do some sort of sorting with the DT graph, people keep talking about it but nobody's done anything that I'm aware of.
Attachment:
signature.asc
Description: PGP signature
