From: Sascha Hauer <s.hauer@pengutronix.de>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
Viresh Kumar <viresh.kumar@linaro.org>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
kernel@pengutronix.de, Shawn Guo <shawnguo@kernel.org>,
Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH 4/4] cpufreq: imx6q: check regulator_get_optional return value
Date: Mon, 26 Oct 2015 09:17:46 +0100 [thread overview]
Message-ID: <20151026081746.GX14476@pengutronix.de> (raw)
In-Reply-To: <1445509395.3173.31.camel@pengutronix.de>
On Thu, Oct 22, 2015 at 12:23:15PM +0200, Lucas Stach wrote:
> Am Donnerstag, den 22.10.2015, 10:47 +0200 schrieb Sascha Hauer:
> > While pu_reg is an optional regulator we still have to check
> > the return value for -EPROBE_DEFER to properly detect the
> > case when we have a pu regulator but it is not yet present.
> >
> > While at it, set pu_reg to NULL for an erroneous regulator
> > so that we can check for the regulator with if (pu_reg)
> > instead of the slightly less readable IS_ERR().
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
> > drivers/cpufreq/imx6q-cpufreq.c | 11 ++++++++---
> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
> > index ce0c6bd..b643614 100644
> > --- a/drivers/cpufreq/imx6q-cpufreq.c
> > +++ b/drivers/cpufreq/imx6q-cpufreq.c
> > @@ -71,7 +71,7 @@ static int imx6q_set_target(struct cpufreq_policy *policy, unsigned int index)
> >
> > /* scaling up? scale voltage before frequency */
> > if (new_freq > old_freq) {
> > - if (!IS_ERR(pu_reg)) {
> > + if (pu_reg) {
> > ret = regulator_set_voltage_tol(pu_reg, imx6_soc_volt[index], 0);
> > if (ret) {
> > dev_err(cpu_dev, "failed to scale vddpu up: %d\n", ret);
> > @@ -148,7 +148,7 @@ static int imx6q_set_target(struct cpufreq_policy *policy, unsigned int index)
> > dev_warn(cpu_dev, "failed to scale vddsoc down: %d\n", ret);
> > ret = 0;
> > }
> > - if (!IS_ERR(pu_reg)) {
> > + if (pu_reg) {
> > ret = regulator_set_voltage_tol(pu_reg, imx6_soc_volt[index], 0);
> > if (ret) {
> > dev_warn(cpu_dev, "failed to scale vddpu down: %d\n", ret);
> > @@ -217,6 +217,11 @@ static int imx6q_cpufreq_get_resources(struct platform_device *pdev)
> > return PTR_ERR(arm_reg);
> >
> > pu_reg = regulator_get_optional(cpu_dev, "pu");
> > + if (IS_ERR(pu_reg)) {
> > + if (PTR_ERR(pu_reg) == -EPROBE_DEFER)
> > + return -EPROBE_DEFER;
> > + pu_reg = NULL;
> > + }
>
> The PU regulator isn't really optional for MX6 Q/DL (where it is present
> in hardware) as the datasheet clearly specifies that it needs to be set
> to the same voltage as SOC. Could you change this to request this
> regulator as non-optional for those chip derivatives and skip the
> request otherwise?
i.MX6SL also has the pu-reg, so this would become
if (of_machine_is_compatible("fsl,imx6q") ||
of_machine_is_compatible("fsl,imx6dl") ||
of_machine_is_compatible("fsl,imx6sl))
Not really nice. Also we already have a
of_machine_is_compatible("fsl,imx6ul") in the driver. It seems the
knowledge about (struct platform_device)->id_table is already lost
nowadays. I think this should be used here to distinguish between the
different devices.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
WARNING: multiple messages have this Message-ID (diff)
From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/4] cpufreq: imx6q: check regulator_get_optional return value
Date: Mon, 26 Oct 2015 09:17:46 +0100 [thread overview]
Message-ID: <20151026081746.GX14476@pengutronix.de> (raw)
In-Reply-To: <1445509395.3173.31.camel@pengutronix.de>
On Thu, Oct 22, 2015 at 12:23:15PM +0200, Lucas Stach wrote:
> Am Donnerstag, den 22.10.2015, 10:47 +0200 schrieb Sascha Hauer:
> > While pu_reg is an optional regulator we still have to check
> > the return value for -EPROBE_DEFER to properly detect the
> > case when we have a pu regulator but it is not yet present.
> >
> > While at it, set pu_reg to NULL for an erroneous regulator
> > so that we can check for the regulator with if (pu_reg)
> > instead of the slightly less readable IS_ERR().
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
> > drivers/cpufreq/imx6q-cpufreq.c | 11 ++++++++---
> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
> > index ce0c6bd..b643614 100644
> > --- a/drivers/cpufreq/imx6q-cpufreq.c
> > +++ b/drivers/cpufreq/imx6q-cpufreq.c
> > @@ -71,7 +71,7 @@ static int imx6q_set_target(struct cpufreq_policy *policy, unsigned int index)
> >
> > /* scaling up? scale voltage before frequency */
> > if (new_freq > old_freq) {
> > - if (!IS_ERR(pu_reg)) {
> > + if (pu_reg) {
> > ret = regulator_set_voltage_tol(pu_reg, imx6_soc_volt[index], 0);
> > if (ret) {
> > dev_err(cpu_dev, "failed to scale vddpu up: %d\n", ret);
> > @@ -148,7 +148,7 @@ static int imx6q_set_target(struct cpufreq_policy *policy, unsigned int index)
> > dev_warn(cpu_dev, "failed to scale vddsoc down: %d\n", ret);
> > ret = 0;
> > }
> > - if (!IS_ERR(pu_reg)) {
> > + if (pu_reg) {
> > ret = regulator_set_voltage_tol(pu_reg, imx6_soc_volt[index], 0);
> > if (ret) {
> > dev_warn(cpu_dev, "failed to scale vddpu down: %d\n", ret);
> > @@ -217,6 +217,11 @@ static int imx6q_cpufreq_get_resources(struct platform_device *pdev)
> > return PTR_ERR(arm_reg);
> >
> > pu_reg = regulator_get_optional(cpu_dev, "pu");
> > + if (IS_ERR(pu_reg)) {
> > + if (PTR_ERR(pu_reg) == -EPROBE_DEFER)
> > + return -EPROBE_DEFER;
> > + pu_reg = NULL;
> > + }
>
> The PU regulator isn't really optional for MX6 Q/DL (where it is present
> in hardware) as the datasheet clearly specifies that it needs to be set
> to the same voltage as SOC. Could you change this to request this
> regulator as non-optional for those chip derivatives and skip the
> request otherwise?
i.MX6SL also has the pu-reg, so this would become
if (of_machine_is_compatible("fsl,imx6q") ||
of_machine_is_compatible("fsl,imx6dl") ||
of_machine_is_compatible("fsl,imx6sl))
Not really nice. Also we already have a
of_machine_is_compatible("fsl,imx6ul") in the driver. It seems the
knowledge about (struct platform_device)->id_table is already lost
nowadays. I think this should be used here to distinguish between the
different devices.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2015-10-26 8:17 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-22 8:47 cpufreq: i.MX6: -EPROBE_DEFER fixes Sascha Hauer
2015-10-22 8:47 ` Sascha Hauer
2015-10-22 8:47 ` [PATCH 1/4] cpufreq: imx6q: Fix goto wrong error label Sascha Hauer
2015-10-22 8:47 ` Sascha Hauer
2015-10-22 10:11 ` Lucas Stach
2015-10-22 10:11 ` Lucas Stach
2015-10-22 8:47 ` [PATCH 2/4] cpufreq: imx6q: Fix wrong device in devm_kzalloc Sascha Hauer
2015-10-22 8:47 ` Sascha Hauer
2015-10-22 10:11 ` Lucas Stach
2015-10-22 10:11 ` Lucas Stach
2015-10-22 13:29 ` Viresh Kumar
2015-10-22 13:29 ` Viresh Kumar
2015-10-22 8:47 ` [PATCH 3/4] cpufreq: imx6q: Fix regulator/clock error handling Sascha Hauer
2015-10-22 8:47 ` Sascha Hauer
2015-10-22 10:18 ` Lucas Stach
2015-10-22 10:18 ` Lucas Stach
2015-10-22 13:33 ` Viresh Kumar
2015-10-22 13:33 ` Viresh Kumar
2015-10-26 7:38 ` Sascha Hauer
2015-10-26 7:38 ` Sascha Hauer
2015-10-22 8:47 ` [PATCH 4/4] cpufreq: imx6q: check regulator_get_optional return value Sascha Hauer
2015-10-22 8:47 ` Sascha Hauer
2015-10-22 10:23 ` Lucas Stach
2015-10-22 10:23 ` Lucas Stach
2015-10-26 8:17 ` Sascha Hauer [this message]
2015-10-26 8:17 ` Sascha Hauer
2015-10-28 3:27 ` cpufreq: i.MX6: -EPROBE_DEFER fixes Rafael J. Wysocki
2015-10-28 3:27 ` Rafael J. Wysocki
2015-10-28 7:59 ` Sascha Hauer
2015-10-28 7:59 ` Sascha Hauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151026081746.GX14476@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=hkallweit1@gmail.com \
--cc=kernel@pengutronix.de \
--cc=l.stach@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=shawnguo@kernel.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.