Stephen, On Thu, Feb 14, 2013 at 4:16 PM, Stephen Warren <swar...@wwwdotorg.org> wrote: >> We can avoid that logic with has_full_constraints. That will be some >> work to get done but also should be done at some point in time. Once >> we use has_full_constraints we'll get ERR_PTR(-EPROBE_DEFER); > > That flag is normally set automatically: > > static int __init regulator_init_complete(void) > ... > /* > * Since DT doesn't provide an idiomatic mechanism for > * enabling full constraints and since it's much more natural > * with DT to provide them just assume that a DT enabled > * system has full constraints. > */ > if (of_have_populated_dt()) > has_full_constraints = true; > > Is of_have_populated_dt() not returning true for you? Perhaps when using > the initcall, your regulator_get()s are happening before > regulator_init_complete() gets called, which is the source of the problem?
The regulator_get() calls are before regulator_init_complete() by quite a margin. The regulator_init_complete() is a late_initcall, so that's not too surprising. Are we not supposed to access regulators until after late_init()? That seems like quite a limitation... Note: I did send up a v2 of the patch series that you probably saw. It still uses subsys_initcall(). I can easily send up a v3 if you would like. Worst case I can carry a local patch to hack the arbitrator driver to use subsys_initcall() until we fix everything else. One other argument for using subsys_initcall(), though. Using module_platform_driver() means that we end up going through device_initcall(). I would argue that since we're providing a bus we're much more of a "subsystem" than a "device". ...or is that a BS argument? Certainly if you end up building this code as a module then it'll get called late anyway, but hopefully you wouldn't do that on a system that had really critical components on the provided bus? Let me know if you're happy with v2 or if you'd like me to make a rev. Thanks! :) -Doug _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss