On Thu, Jun 9, 2022 at 4:45 AM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > On Wed, 1 Jun 2022 at 09:07, Saravana Kannan <saravanak@xxxxxxxxxx> wrote: > > > > Now that fw_devlink=on by default and fw_devlink supports > > "power-domains" property, the execution will never get to the point > > where driver_deferred_probe_check_state() is called before the supplier > > has probed successfully or before deferred probe timeout has expired. > > > > So, delete the call and replace it with -ENODEV. > > With fw_devlink=on by default - does that mean that the parameter > can't be changed? > > Or perhaps the point is that we don't want to go back, but rather drop > the fw_devlink parameter altogether when moving forward? Good question. For now, keeping fw_devlink=off and fw_devlink=permissive as debugging options that I can ask people to try if some probe is getting blocked. Or maybe if some ultra low memory use case wants to avoid create device links, fwnode links, etc and can build everything in and have init/probe happen in the right order. But in the long run, I see a strong possibility for fw_devlink=off/permissive being removed. I'd still want to keep it for implementing =rpm where it'd also automatically enable PM runtime tracking, but I don't understand that well enough yet to do it by default. > > > > Signed-off-by: Saravana Kannan <saravanak@xxxxxxxxxx> > > Just a minor nitpick below. Nevertheless, feel free to add: > > Reviewed-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx> Thanks! > > > --- > > 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 739e52cd4aba..3e86772d5fac 100644 > > --- a/drivers/base/power/domain.c > > +++ b/drivers/base/power/domain.c > > @@ -2730,7 +2730,7 @@ static int __genpd_dev_pm_attach(struct device *dev, struct device *base_dev, > > mutex_unlock(&gpd_list_lock); > > dev_dbg(dev, "%s() failed to find PM domain: %ld\n", > > __func__, PTR_ERR(pd)); > > - return driver_deferred_probe_check_state(base_dev); > > Adding a brief comment about why -EPROBE_DEFER doesn't make sense > here, would be nice. Will do once all the reviews comeout/when I send v3. I'm thinking something like: /* fw_devlink will take care of retrying for missing suppliers */ -Saravana > > > + return -ENODEV; > > } > > > > dev_dbg(dev, "adding to PM domain %s\n", pd->name); > > -- > > 2.36.1.255.ge46751e96f-goog > > > > Kind regards > Uffe