From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Jerome Oufella <jerome.oufella@savoirfairelinux.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>,
lm-sensors <lm-sensors@lm-sensors.org>,
linux-kernel@vger.kernel.org
Subject: Re: regulator: regulator_get behaviour without CONFIG_REGULATOR set
Date: Fri, 2 Apr 2010 17:00:59 +0100 [thread overview]
Message-ID: <20100402160058.GE27613@sirena.org.uk> (raw)
In-Reply-To: <1779783481.621270223270264.JavaMail.root@mail.savoirfairelinux.com>
On Fri, Apr 02, 2010 at 11:47:50AM -0400, Jerome Oufella wrote:
Please fix your mail client to word wrap paragraphs, I've manually fixed
this up here.
> Working on drivers/hwmon/sht15.c, I noticed it would return bogus
> temperatures in my case, where CONFIG_REGULATOR is not set.
> This is due to the following section in drivers/hwmon/sht15.c:
>
> /* If a regulator is available, query what the supply voltage actually is!*/
> data->reg = regulator_get(data->dev, "vcc");
> if (!IS_ERR(data->reg)) {
> ...
> Looking at consumer.h, it appears that regulator_get() returns a
> pointer to its second argument when CONFIG_REGULATOR is not set.
Right, it's just returning something that won't match IS_ERR().
> What would be the proper way to determine if the returned value is a
> valid regulator ? Would it be safe to check it against the 2nd
> argument ?
You're asking the wrong question here. The problem here is not that the
regulator got stubbed out, the problem is that the sht15 driver is not
checking the return value of regulator_get_voltage() and so is trying to
use the error code that was returned as a voltage, with predictably poor
results. It is this function that the driver needs to check, not
regulator_get(). There are a range of reasons why an error might be
returned when querying the voltage, all of which would cause the same
result.
It is not sensible to check the return code of regulator_get() for
anything other than IS_ERR().
next prev parent reply other threads:[~2010-04-02 16:01 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 ` Jerome Oufella
2010-04-02 16:00 ` Mark Brown [this message]
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
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=20100402160058.GE27613@sirena.org.uk \
--to=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
all inboxes | Powered by JetHome®