public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Jerome Oufella <jerome.oufella@savoirfairelinux.com>,
	lm-sensors <lm-sensors@lm-sensors.org>,
	linux-kernel@vger.kernel.org, Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [lm-sensors] regulator: regulator_get behaviour without  CONFIG_REGULATOR set
Date: Sat, 3 Apr 2010 17:37:45 +0200	[thread overview]
Message-ID: <20100403173745.2bf17ee6@hyperion.delvare> (raw)
In-Reply-To: <20100402204503.GA15237@opensource.wolfsonmicro.com>

Hi Mark,

On Fri, 2 Apr 2010 21:45:03 +0100, Mark Brown wrote:
> On Fri, Apr 02, 2010 at 09:30:10PM +0200, Jean Delvare wrote:
> > looks much better than
> >
> > /* If a regulator is available, query what the supply voltage actually is!*/
> > 	data->reg = regulator_get(data->dev, "vcc");
> > 	if (!IS_ERR(data->reg)) {
> > 		int voltage = regulator_get_voltage(data->reg);
> > 		if (voltage) {
> > 			data->supply_uV = voltage;
> > 			regulator_enable(data->reg);
> > 			/* setup a notifier block to update this if
> > 			 *  another device causes the voltage to change */
> > 			data->nb.notifier_call = &sht15_invalidate_voltage;
> > 			ret = regulator_register_notifier(data->reg, &data->nb);
> > 		}
> > 	}
> 
> In this case you don't need the if (voltage) check - the code that uses
> supply_uV is going to have to cope with it being set to 0 if the driver
> doesn't just give up, and the enable wants to happen anyway (perhaps
> we've got a switchable supply we can't read the voltage of).  It should
> never make any odds if the notifier never gets called since the supply
> could be invariant.

We still need to check if (voltage) to not overwrite the previous value
of data->supply_uV with 0. We will probably do that as an immediate fix
to the sht15 driver. But yes, the rest doesn't need a condition.

Still, I'd prefer if drivers were just able to check for data->reg ==
NULL and skip the whole thing. Would you apply the following patch?

* * * * *

From: Jean Delvare <khali@linux-fr.org>
Subject: regulator: Let drivers know when they use the stub API

Have the stub variant of regulator_get() return NULL, so that drivers
can (but still don't have to) handle this case specifically.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Jerome Oufella <jerome.oufella@savoirfairelinux.com>
---
 include/linux/regulator/consumer.h |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- linux-2.6.34-rc3.orig/include/linux/regulator/consumer.h	2010-03-09 08:25:30.000000000 +0100
+++ linux-2.6.34-rc3/include/linux/regulator/consumer.h	2010-04-03 17:21:08.000000000 +0200
@@ -183,9 +183,13 @@ static inline struct regulator *__must_c
 {
 	/* Nothing except the stubbed out regulator API should be
 	 * looking at the value except to check if it is an error
-	 * value so the actual return value doesn't matter.
+	 * value. Drivers are free to handle NULL specifically by
+	 * skipping all regulator API calls, but they don't have to.
+	 * Drivers which don't, should make sure they properly handle
+	 * corner cases of the API, such as regulator_get_voltage()
+	 * returning 0.
 	 */
-	return (struct regulator *)id;
+	return NULL;
 }
 static inline void regulator_put(struct regulator *regulator)
 {


Thanks,
-- 
Jean Delvare

  reply	other threads:[~2010-04-03 15:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2122967437.461270223106350.JavaMail.root@mail.savoirfairelinux.com>
2010-04-02 15:47 ` regulator: regulator_get behaviour without CONFIG_REGULATOR set Jerome Oufella
2010-04-02 16:00   ` Mark Brown
2010-04-02 16:44     ` [lm-sensors] " Jean Delvare
2010-04-02 18:51       ` Mark Brown
2010-04-02 19:30         ` Jean Delvare
2010-04-02 20:45           ` Mark Brown
2010-04-03 15:37             ` Jean Delvare [this message]
2010-04-05 13:23               ` Mark Brown
2010-04-06 12:04                 ` Jonathan Cameron
2010-04-06 15:27                 ` Liam Girdwood
2010-04-06 16:25                   ` Jonathan Cameron
2010-04-06 18:19                     ` Mark Brown
2010-04-07  9:50                       ` Liam Girdwood
2010-04-07 11:24                       ` Jonathan Cameron
2010-04-07 11:57                         ` Mark Brown

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=20100403173745.2bf17ee6@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=jerome.oufella@savoirfairelinux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.org \
    --cc=lrg@slimlogic.co.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox