[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200904154715.70cba0d3@coco.lan>
Date: Fri, 4 Sep 2020 15:47:15 +0200
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Mark Brown <broonie@...nel.org>
Cc: linuxarm@...wei.com, mauro.chehab@...wei.com,
John Stultz <john.stultz@...aro.org>,
Manivannan Sadhasivam <mani@...nel.org>,
Robin Murphy <robin.murphy@....com>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Liam Girdwood <lgirdwood@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC 09/10] misc: hisi_hikey_usb: add support for Hikey 970
Em Fri, 4 Sep 2020 13:45:23 +0100
Mark Brown <broonie@...nel.org> escreveu:
> 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@...nel.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().
When I was porting the drm driver (first from OOT Kernel 4.9 to 4.19.5,
and then from 4.19.5 to 5.7), I'm pretty sure I got several of those
messages:
"supply %s not found, using dummy regulator\n"
due to EPROBE_DEFER. I remember I ended checked the implementation
of the regulator code on that time. Yet, looking at the current
implementation of _regulator_get():
rdev = regulator_dev_lookup(dev, id);
if (IS_ERR(rdev)) {
ret = PTR_ERR(rdev);
I see that devm_regulator_get() will do the right thing with
EPROBE_DEFER.
So, I'll replace it at the driver. Thanks for the review!
Thanks,
Mauro
Powered by blists - more mailing lists