On 9 July 2018 at 17:41, Rob Herring <r...@kernel.org> wrote: > All PM domain drivers must be built-in (at least those using DT), so > there is no point deferring probe after initcalls are done. Continuing > to defer probe may prevent booting successfully even if managing PM > domains is not required. This can happen if the user failed to enable > the driver or if power-domains are added to a platform's DT, but there > is not yet a driver (e.g. a new DTB with an old kernel). > > Call the driver core function driver_deferred_probe_check_init_done() > instead of just returning -EPROBE_DEFER to stop deferring probe when > initcalls are done. > > Acked-by: "Rafael J. Wysocki" <r...@rjwysocki.net> > Cc: Kevin Hilman <khil...@kernel.org> > Cc: Ulf Hansson <ulf.hans...@linaro.org> > Cc: Pavel Machek <pa...@ucw.cz> > Cc: Len Brown <len.br...@intel.com> > Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> > Cc: linux...@vger.kernel.org > Signed-off-by: Rob Herring <r...@kernel.org> > --- > v4: > - Add Rafael's ack > > v3: > - Update to new function name > > drivers/base/power/domain.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > index 4925af5c4cf0..8c12213875c6 100644 > --- a/drivers/base/power/domain.c > +++ b/drivers/base/power/domain.c > @@ -2253,7 +2253,7 @@ static int __genpd_dev_pm_attach(struct device *dev, > struct device_node *np, > mutex_unlock(&gpd_list_lock); > dev_dbg(dev, "%s() failed to find PM domain: %ld\n", > __func__, PTR_ERR(pd)); > - return -EPROBE_DEFER; > + return driver_deferred_probe_check_state(dev); > }
This isn't the only error path where -EPROBE_DEFER may be returned during attach in genpd. Have a look at the callers of __genpd_dev_pm_attach() and also have a second look inside __genpd_dev_pm_attach() itself. And in Rafael's tree. > > dev_dbg(dev, "adding to PM domain %s\n", pd->name); > -- > 2.17.1 Besides the above, I am fine with the approach as such. Kind regards Uffe _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
