On 10 July 2018 at 16:25, Rob Herring <robh@xxxxxxxxxx> wrote: > On Mon, Jul 9, 2018 at 4:49 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >> >> On 9 July 2018 at 17:41, Rob Herring <robh@xxxxxxxxxx> 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" <rjw@xxxxxxxxxxxxx> >> > Cc: Kevin Hilman <khilman@xxxxxxxxxx> >> > Cc: Ulf Hansson <ulf.hansson@xxxxxxxxxx> >> > Cc: Pavel Machek <pavel@xxxxxx> >> > Cc: Len Brown <len.brown@xxxxxxxxx> >> > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> >> > Cc: linux-pm@xxxxxxxxxxxxxxx >> > Signed-off-by: Rob Herring <robh@xxxxxxxxxx> >> > --- >> > 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. > > Yes, but I think this is the only place you can fail to get the PD > device from DT. The case we care about is properties exist in the DT, > but no driver exists. That's correct. Thanks for clarifying! > > What would cause deferring in the latter cases? To power on the PM domain for example, which often is required to be able to probe the device. > > Rob Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
