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
next prev parent 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