Messages in this thread | | | Date | Fri, 4 Sep 2020 13:45:23 +0100 | From | Mark Brown <> | Subject | Re: [RFC 09/10] misc: hisi_hikey_usb: add support for Hikey 970 |
| |
On Fri, Sep 04, 2020 at 02:38:48PM +0200, Mauro Carvalho Chehab wrote: > Em Fri, 4 Sep 2020 13:23:03 +0100 > Mark Brown <broonie@kernel.org> escreveu: > > > On Fri, Sep 04, 2020 at 12:23:31PM +0200, Mauro Carvalho Chehab wrote: > > > > > + regulator = devm_regulator_get_optional(&pdev->dev, "hub-vdd"); > > > + if (IS_ERR(regulator)) { > > > + if (PTR_ERR(regulator) == -EPROBE_DEFER) { > > > + dev_info(&pdev->dev, > > > + "waiting for hub-vdd-supply to be probed\n"); > > > + return PTR_ERR(regulator); > > > + } > > > + > > > + /* let it fall back to regulator dummy */ > > > + regulator = devm_regulator_get(&pdev->dev, "hub-vdd"); > > > + if (IS_ERR(regulator)) { > > > + dev_err(&pdev->dev, > > > + "get hub-vdd-supply failed with error %ld\n", > > > + PTR_ERR(regulator)); > > > + return PTR_ERR(regulator); > > > + } > > > + }
> > This seems weird - if the supply is non-optional why is the code trying > > with devm_regulator_get_optional()? Just use normal get directly.
> That's meant to avoid problems with EPROBE_DEFER.
Which problems and in what way does it avoid them?
> See, Hikey 970 need to initialize 4 drivers for the regulators: > SPMI core, SPMI bus controller, MFD and regulator. This can take > some time. So, a first call to *regulator_get() may return > EPROBE_DEFER, specially if both regulator drivers and USB HUB > are builtin.
This is totally normal and works fine with normal regulator_get().
> I ended doing the same as some other DRM drivers do (like adv7535).
I can't find any references to regulator_get_optional() drivers/gpu/drm/bridge/adv7511/adv7511_drv.c? [unhandled content-type:application/pgp-signature] | |