On Wednesday, June 13, 2018 12:17:24 AM CEST Dmitry Torokhov wrote:
> On Sat, Jun 09, 2018 at 04:02:18PM +0200, Janusz Krzysztofik wrote:
> > ...
> > + priv->vcc = devm_regulator_get(&pdev->dev, "vcc");
> > + if (IS_ERR(priv->vcc)) {
> > + err = PTR_ERR(priv->vcc);
> > + dev_err(&pdev->dev, "regulator request failed (%d)\n", err);
> > + /* Fail softly if the regulator is not available yet */
> > + if (err == -ENODEV)
> > + err = -EPROBE_DEFER;
>
> Hmm, if regulator is not ready yet, devm_regulator_get() should be
> returning -EPROBE_DEFER already, we should not have to convert -ENODEV
> to -EPROBE_DEFER...
Regulator is not ready because its initialization at subsys_initcall is
deferred by not ready GPIO pin, that in turn is caused by gpio-mmio driver,
unlike many other GPIO drivers, registered as late as at device_initcall.
I agree devm_regulator_get() could return -EPROBE_DEFER in this case, but I
can see it does that only when of_get_regulator() indicates the regulator
should exist. In non-dt case there is apparently no way to justify if it
should unless its consumer supply table was already in place. For that,
registration of that table would have to be independent of successful
registration of the regulator itself while it's not. Maybe it should, but
that's a separate topic for a separate discussion, I think.
> Is it because we have_full_constraints() returns false? You might need
> to add call to regulator_has_full_constraints() to your board file.
If have_full_constraints() returned true before the regulator or its consumer
supply table is ready, devm_regulator_get() would happily return a dummy
regulator and our keyboard would never get its power.
I'm afraid we have to live with that return code conversion as long as the
only user of this driver is not migrated to dt.
Thanks,
Janusz
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
