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
Date: Sat, 03 Apr 2010 15:37:45 +0000 [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
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
WARNING: multiple messages have this Message-ID (diff)
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: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2122967437.461270223106350.JavaMail.root@mail.savoirfairelinux.com>
2010-04-02 15:47 ` [lm-sensors] regulator: regulator_get behaviour without Jerome Oufella
2010-04-02 15:47 ` regulator: regulator_get behaviour without CONFIG_REGULATOR set Jerome Oufella
2010-04-02 16:00 ` [lm-sensors] regulator: regulator_get behaviour without Mark Brown
2010-04-02 16:00 ` regulator: regulator_get behaviour without CONFIG_REGULATOR set Mark Brown
2010-04-02 16:44 ` [lm-sensors] regulator: regulator_get behaviour without Jean Delvare
2010-04-02 16:44 ` [lm-sensors] regulator: regulator_get behaviour without CONFIG_REGULATOR set Jean Delvare
2010-04-02 18:51 ` [lm-sensors] regulator: regulator_get behaviour Mark Brown
2010-04-02 18:51 ` [lm-sensors] regulator: regulator_get behaviour without CONFIG_REGULATOR set Mark Brown
2010-04-02 19:30 ` [lm-sensors] regulator: regulator_get behaviour without Jean Delvare
2010-04-02 19:30 ` [lm-sensors] regulator: regulator_get behaviour without CONFIG_REGULATOR set Jean Delvare
2010-04-02 20:45 ` [lm-sensors] regulator: regulator_get behaviour Mark Brown
2010-04-02 20:45 ` [lm-sensors] regulator: regulator_get behaviour without CONFIG_REGULATOR set Mark Brown
2010-04-03 15:37 ` Jean Delvare [this message]
2010-04-03 15:37 ` Jean Delvare
2010-04-05 13:23 ` [lm-sensors] regulator: regulator_get behaviour without Mark Brown
2010-04-05 13:23 ` [lm-sensors] regulator: regulator_get behaviour without CONFIG_REGULATOR set Mark Brown
2010-04-06 12:04 ` [lm-sensors] regulator: regulator_get behaviour without Jonathan Cameron
2010-04-06 12:04 ` [lm-sensors] regulator: regulator_get behaviour without CONFIG_REGULATOR set Jonathan Cameron
2010-04-06 15:27 ` [lm-sensors] regulator: regulator_get behaviour without Liam Girdwood
2010-04-06 15:27 ` [lm-sensors] regulator: regulator_get behaviour without CONFIG_REGULATOR set Liam Girdwood
2010-04-06 16:25 ` [lm-sensors] regulator: regulator_get behaviour without Jonathan Cameron
2010-04-06 16:25 ` [lm-sensors] regulator: regulator_get behaviour without CONFIG_REGULATOR set Jonathan Cameron
2010-04-06 18:19 ` [lm-sensors] regulator: regulator_get behaviour without Mark Brown
2010-04-06 18:19 ` [lm-sensors] regulator: regulator_get behaviour without CONFIG_REGULATOR set Mark Brown
2010-04-07 9:50 ` [lm-sensors] regulator: regulator_get behaviour without Liam Girdwood
2010-04-07 9:50 ` [lm-sensors] regulator: regulator_get behaviour without CONFIG_REGULATOR set Liam Girdwood
2010-04-07 11:24 ` [lm-sensors] regulator: regulator_get behaviour without Jonathan Cameron
2010-04-07 11:24 ` [lm-sensors] regulator: regulator_get behaviour without CONFIG_REGULATOR set Jonathan Cameron
2010-04-07 11:57 ` [lm-sensors] regulator: regulator_get behaviour without Mark Brown
2010-04-07 11:57 ` [lm-sensors] regulator: regulator_get behaviour without CONFIG_REGULATOR set 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 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.