From: Jerome Oufella on
Hi,

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.

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 ?

Regards
Jerome Oufella
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mark Brown on
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().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mark Brown on
On 6 Apr 2010, at 17:25, Jonathan Cameron <jic23(a)cam.ac.uk> wrote:

> On 04/06/10 16:27, Liam Girdwood wrote:
>>>
>>>
>>>
>>
>> I suppose this is something we may look into more when we have more
>> clients.
> Makes sense. There will probably be quite a few IIO drivers over
> the next
> few months doing much the same as sht15, where the voltage ref for
> devices
> may well be fed by a regulator. In that case, we may only offer the
> option
> of using an external v_ref if the regulator is available. Many
> devices have
> an internal regulator to provide it so typically we'll start them up
> using that
> and provide an interface to switch to external regulator if one is
> available.
> I haven't thought through exactly how this will work as yet. I'll cc
> people in
> when this comes up.

TBH this seems like a very vanilla use case - there may be some small
advantage to representing the internal regulator via the regulator API
but that's about the only thing I can think might be a bit odd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/