[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170323043334.GD12094@vireshk-i7>
Date: Thu, 23 Mar 2017 10:03:34 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Leonard Crestez <leonard.crestez@....com>
Cc: Mark Brown <broonie@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <kernel@...gutronix.de>,
Robin Gong <yibin.gong@....com>,
Anson Huang <Anson.Huang@....com>,
Irina Tirdea <irina.tirdea@....com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Fabio Estevam <fabio.estevam@....com>,
Octavian Purdila <octavian.purdila@....com>,
linux-pm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 2/8] cpufreq: imx6q: Fix handling EPROBE_DEFER from
regulator
On 22-03-17, 18:53, Leonard Crestez wrote:
> From: Irina Tirdea <irina.tirdea@....com>
>
> If there are any errors in getting the cpu0 regulators, the driver returns
> -ENOENT. In case the regulators are not yet available, the devm_regulator_get
> calls will return -EPROBE_DEFER, so that the driver can be probed later.
> If we return -ENOENT, the driver will fail its initialization and will
> not try to probe again (when the regulators become available).
>
> Return the actual error received from regulator_get in probe. Print a
> differentiated message in case we need to probe the device later and
> in case we actually failed. Also add a message to inform when the
> driver has been successfully registered.
>
> Signed-off-by: Irina Tirdea <irina.tirdea@....com>
> Signed-off-by: Leonard Crestez <leonard.crestez@....com>
> ---
> drivers/cpufreq/imx6q-cpufreq.c | 7 +++++++
> 1 file changed, 7 insertions(+)
Acked-by: Viresh Kumar <viresh.kumar@...aro.org>
--
viresh
Powered by blists - more mailing lists