* Re: [lm-sensors] [PATCH 1/1] lm73: detect i2c bus errors before scnprintf()
2012-12-21 9:58 [lm-sensors] [PATCH 1/1] lm73: detect i2c bus errors before scnprintf() Chris Verges
@ 2012-12-22 1:30 ` Guenter Roeck
2012-12-22 1:37 ` Chris Verges
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Guenter Roeck @ 2012-12-22 1:30 UTC (permalink / raw)
To: lm-sensors
On Fri, Dec 21, 2012 at 01:58:34AM -0800, Chris Verges wrote:
> If an LM73 device does not exist on an I2C bus, attempts to communicate
> with the device result in an error code returned from the i2c read/write
> functions. The current lm73 driver casts that return value from a s32
> type to a s16 type, then converts it to a temperature in celsius.
> Because negative temperatures are valid, it is difficult to distinguish
> between an error code printed to the response buffer and a negative
> temperature recorded by the sensor.
>
> The solution is to evaluate the return value from the i2c functions
> before performing any temperature calculations. If the i2c function did
> not succeed, the error code should be passed back through the virtual
> file system layer instead of being printed into the response buffer.
>
> Before:
>
> $ cat /sys/class/hwmon/hwmon0/device/temp1_input
> -46
>
> After:
>
> $ cat /sys/class/hwmon/hwmon0/device/temp1_input
> cat: read error: No such device or address
>
> Signed-off-by: Chris Verges <kg4ysn@gmail.com>
Applied.
Just wondering - how comes the detect function did not report the error ?
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [lm-sensors] [PATCH 1/1] lm73: detect i2c bus errors before scnprintf()
2012-12-21 9:58 [lm-sensors] [PATCH 1/1] lm73: detect i2c bus errors before scnprintf() Chris Verges
2012-12-22 1:30 ` Guenter Roeck
@ 2012-12-22 1:37 ` Chris Verges
2012-12-22 6:59 ` Guenter Roeck
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Chris Verges @ 2012-12-22 1:37 UTC (permalink / raw)
To: lm-sensors
On Fri, Dec 21, 2012 at 5:30 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>
> Just wondering - how comes the detect function did not report the error ?
>
Excellent question. I didn't debug into this any further, but it is a good
area for additional investigation.
Chris
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [lm-sensors] [PATCH 1/1] lm73: detect i2c bus errors before scnprintf()
2012-12-21 9:58 [lm-sensors] [PATCH 1/1] lm73: detect i2c bus errors before scnprintf() Chris Verges
2012-12-22 1:30 ` Guenter Roeck
2012-12-22 1:37 ` Chris Verges
@ 2012-12-22 6:59 ` Guenter Roeck
2012-12-22 7:37 ` Chris Verges
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Guenter Roeck @ 2012-12-22 6:59 UTC (permalink / raw)
To: lm-sensors
On Fri, Dec 21, 2012 at 05:37:38PM -0800, Chris Verges wrote:
> On Fri, Dec 21, 2012 at 5:30 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Just wondering - how comes the detect function did not report the error ?
> >
>
> Excellent question. I didn't debug into this any further, but it is a good
> area for additional investigation.
>
Depends on how it is instantiated. Is this a PC, or some embedded device ?
It could be configured with devicetree, for example.
Question though is if there is some other chip on that address, and it is
wrongly detected as LM73. Do you know by any chance ?
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [lm-sensors] [PATCH 1/1] lm73: detect i2c bus errors before scnprintf()
2012-12-21 9:58 [lm-sensors] [PATCH 1/1] lm73: detect i2c bus errors before scnprintf() Chris Verges
` (2 preceding siblings ...)
2012-12-22 6:59 ` Guenter Roeck
@ 2012-12-22 7:37 ` Chris Verges
2012-12-22 11:07 ` Guenter Roeck
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Chris Verges @ 2012-12-22 7:37 UTC (permalink / raw)
To: lm-sensors
On Fri, Dec 21, 2012 at 10:59 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> On Fri, Dec 21, 2012 at 05:37:38PM -0800, Chris Verges wrote:
>> On Fri, Dec 21, 2012 at 5:30 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>> >
>> > Just wondering - how comes the detect function did not report the
>> > error ?
>>
>> Excellent question. I didn't debug into this any further, but it is
>> a good area for additional investigation.
>>
> Depends on how it is instantiated. Is this a PC, or some embedded
> device ? It could be configured with devicetree, for example.
This is an embedded device. In looking further at the BSP, it is
defined in the i2c device list there. (Pre-device-tree.)
> Question though is if there is some other chip on that address, and it
> is wrongly detected as LM73. Do you know by any chance?
Definitely not another chip at that address. This board only has lm73's
on the i2c bus -- 2 at different addresses, in fact. Plus, the detect
function in the lm73 appears to be quite thorough in vetting
LM73-specific registers.
There may be error conditions or corner cases whereby this issue could
arise independently from the detect function. For example:
1. if an i2c bus adapter has a bug which causes i2c transfers to
terminate prematurely, this could result in the detect functioning
properly and the temperature poll to return an error code.
2. if the lm73's power rail is being controlled by a
GPIO-connected FET, and the lm73 is powered down to save power.
(Admittedly, the lm73 doesn't eat up much power, but every electron
counts in some applications.)
I discovered this issue through a combination of the sensor not being
connected, yet being defined statically in the i2c device list for the
board, and then there also being an i2c bus adapter bug causing transfer
truncation. So even if the sensor was connected, 1 out of every 100
polls would return an error. (Software blaming hardware? Unthinkable.)
Related to the lm73, but off the main topic ...
There are some potential other checks which could be performed at the
driver layer to validate the responses back. I couldn't decide whether
they would be valuable or not. For example, the lm73 should only return
temperature values inside its operating range. If something goes
haywire on the bus and causes all 1's to be received by the master, this
could translate to ~256 C ... outside the 150 C spec for the sensor.
Any advice for whether to go forth with these changes?
I'd also like to find a way to expose the variable precision control
available to the driver. I submitted a patch previously, but it was a
first pass and not well conceived. Does hwmon have a standard way of
exposing resolution settings? Perhaps this should be a compile-time
Kconfig option? Or maybe a module option?
Thanks,
Chris
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [lm-sensors] [PATCH 1/1] lm73: detect i2c bus errors before scnprintf()
2012-12-21 9:58 [lm-sensors] [PATCH 1/1] lm73: detect i2c bus errors before scnprintf() Chris Verges
` (3 preceding siblings ...)
2012-12-22 7:37 ` Chris Verges
@ 2012-12-22 11:07 ` Guenter Roeck
2012-12-22 21:48 ` Chris Verges
2012-12-22 22:59 ` Guenter Roeck
6 siblings, 0 replies; 8+ messages in thread
From: Guenter Roeck @ 2012-12-22 11:07 UTC (permalink / raw)
To: lm-sensors
On Fri, Dec 21, 2012 at 11:37:29PM -0800, Chris Verges wrote:
> On Fri, Dec 21, 2012 at 10:59 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > On Fri, Dec 21, 2012 at 05:37:38PM -0800, Chris Verges wrote:
> >> On Fri, Dec 21, 2012 at 5:30 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> >> >
> >> > Just wondering - how comes the detect function did not report the
> >> > error ?
> >>
> >> Excellent question. I didn't debug into this any further, but it is
> >> a good area for additional investigation.
> >>
> > Depends on how it is instantiated. Is this a PC, or some embedded
> > device ? It could be configured with devicetree, for example.
>
> This is an embedded device. In looking further at the BSP, it is
> defined in the i2c device list there. (Pre-device-tree.)
>
> > Question though is if there is some other chip on that address, and it
> > is wrongly detected as LM73. Do you know by any chance?
>
> Definitely not another chip at that address. This board only has lm73's
> on the i2c bus -- 2 at different addresses, in fact. Plus, the detect
> function in the lm73 appears to be quite thorough in vetting
> LM73-specific registers.
>
> There may be error conditions or corner cases whereby this issue could
> arise independently from the detect function. For example:
>
> 1. if an i2c bus adapter has a bug which causes i2c transfers to
> terminate prematurely, this could result in the detect functioning
> properly and the temperature poll to return an error code.
>
> 2. if the lm73's power rail is being controlled by a
> GPIO-connected FET, and the lm73 is powered down to save power.
> (Admittedly, the lm73 doesn't eat up much power, but every electron
> counts in some applications.)
>
> I discovered this issue through a combination of the sensor not being
> connected, yet being defined statically in the i2c device list for the
> board, and then there also being an i2c bus adapter bug causing transfer
Guess that explains that.
> truncation. So even if the sensor was connected, 1 out of every 100
> polls would return an error. (Software blaming hardware? Unthinkable.)
>
Can always be a driver bug (see 1. above...).
> Related to the lm73, but off the main topic ...
>
> There are some potential other checks which could be performed at the
> driver layer to validate the responses back. I couldn't decide whether
> they would be valuable or not. For example, the lm73 should only return
> temperature values inside its operating range. If something goes
> haywire on the bus and causes all 1's to be received by the master, this
> could translate to ~256 C ... outside the 150 C spec for the sensor.
> Any advice for whether to go forth with these changes?
>
All 1s would be invalid per spec - bit 0 and 1 of the returned value should
always be 0. You could check for that and return an error (-EIO ?) if this
condition is seen. Usually I'd say that kind of thing is so unlikely not to
bother, but if you see a transfer error every 100 readings who knows.
> I'd also like to find a way to expose the variable precision control
> available to the driver. I submitted a patch previously, but it was a
> first pass and not well conceived. Does hwmon have a standard way of
But then you didn't even reply to my comments as far as I can see ...
> exposing resolution settings? Perhaps this should be a compile-time
> Kconfig option? Or maybe a module option?
>
Not Kconfig. module option applies to all sensors on the system, so that is not
a good idea either.
Your options are:
- Platform data
- Device tree data (or better both)
- Use the update_interval attribute. Not directly applicable, but the resolution
impacts the conversion time so the case could be made. And resolution does
impact conversion time, so the only reason for not selecting 14 bit resolution
all the time would be its impact on conversion time. The datasheet also
specifically mentions that the reason for the configurable resolution is its
impact on conversion time. Might as well specify it directly.
- Add a resolution sysfs attribute. There are other chips with a configurable
resolution, so again the case could be made to introduce that. As I said
earlier, that would have to be standardized and consistent, though.
Would this ever be changed at runtime, or is it a startup configuration option ?
In the latter case, platform and/or device tree data would be the better choice.
Since you suggested Kconfig/module option above, which does suggest startup
configuration, platform and/or device tree data might be your answer.
From an overall functionality perspective, adding support for alarm flags might
be more or at least equally important, though. Hint hint ;)
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [lm-sensors] [PATCH 1/1] lm73: detect i2c bus errors before scnprintf()
2012-12-21 9:58 [lm-sensors] [PATCH 1/1] lm73: detect i2c bus errors before scnprintf() Chris Verges
` (4 preceding siblings ...)
2012-12-22 11:07 ` Guenter Roeck
@ 2012-12-22 21:48 ` Chris Verges
2012-12-22 22:59 ` Guenter Roeck
6 siblings, 0 replies; 8+ messages in thread
From: Chris Verges @ 2012-12-22 21:48 UTC (permalink / raw)
To: lm-sensors
On Sat, Dec 22, 2012 at 3:07 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> On Fri, Dec 21, 2012 at 11:37:29PM -0800, Chris Verges wrote:
>> Related to the lm73, but off the main topic ...
>>
>> Any advice for whether to go forth with these changes?
>
> All 1s would be invalid per spec - bit 0 and 1 of the returned value
> should always be 0. You could check for that and return an error (-EIO
> ?) if this condition is seen. Usually I'd say that kind of thing is so
> unlikely not to bother, but if you see a transfer error every 100
> readings who knows.
OK, I'll add it to the "if I touch the driver again, take a look at it"
category. Though it will likely happen since I'll probably take on the
resolution / alarm stuff below.
>> I'd also like to find a way to expose the variable precision control
>> available to the driver. I submitted a patch previously, but it was a
>> first pass and not well conceived. Does hwmon have a standard way of
>
> But then you didn't even reply to my comments as far as I can see ...
I didn't reply at the time, but I did see them. I've actually been
pondering the best way to handle this since then. (Not a lot of time
was spent on these musings, as I was heavily on other projects.) This
is why there hasn't been an updated patch sent.
> Your options are:
> - Platform data
> - Device tree data (or better both)
> - Use the update_interval attribute. Not directly applicable, but the
> resolution impacts the conversion time so the case could be made.
> And resolution does impact conversion time, so the only reason for
> not selecting 14 bit resolution all the time would be its impact on
> conversion time. The datasheet also specifically mentions that the
> reason for the configurable resolution is its impact on conversion
> time. Might as well specify it directly.
> - Add a resolution sysfs attribute. There are other chips with a
> configurable resolution, so again the case could be made to
> introduce that. As I said earlier, that would have to be
> standardized and consistent, though.
>
> Would this ever be changed at runtime, or is it a startup
> configuration option ? In the latter case, platform and/or device
> tree data would be the better choice. Since you suggested
> Kconfig/module option above, which does suggest startup configuration,
> platform and/or device tree data might be your answer.
Your points about Kconfig and module options are well heard. I agree
that it needs to be sensor-specific, not shared across all sensors on a
system.
I'll take a stab at platform data and device tree data at a minimum.
Support for both should be easy enough.
I do see the reason to make it configurable at runtime. Using the
update_interval attribute is an interesting idea. There is perhaps a
concern about intuitiveness of the interface being a problem. Not all
users looking for more precision will necessarily think of adjusting
conversion time at first. However, in lack of a "resolution" attribute
being available, perhaps this is the next best step. I'll give it a
shot and we can rip apart the code proposal.
> From an overall functionality perspective, adding support for alarm
> flags might be more or at least equally important, though. Hint hint
> ;)
That's simple enough. I assume using the sysfs_notify() mechanism to
allow epoll support would be wanted. We'd need the platform/device tree
to specify the IRQ to use, so it would have to be one of those
"specify-if-desired" features.
Chris
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [lm-sensors] [PATCH 1/1] lm73: detect i2c bus errors before scnprintf()
2012-12-21 9:58 [lm-sensors] [PATCH 1/1] lm73: detect i2c bus errors before scnprintf() Chris Verges
` (5 preceding siblings ...)
2012-12-22 21:48 ` Chris Verges
@ 2012-12-22 22:59 ` Guenter Roeck
6 siblings, 0 replies; 8+ messages in thread
From: Guenter Roeck @ 2012-12-22 22:59 UTC (permalink / raw)
To: lm-sensors
On Sat, Dec 22, 2012 at 01:48:26PM -0800, Chris Verges wrote:
> On Sat, Dec 22, 2012 at 3:07 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> > On Fri, Dec 21, 2012 at 11:37:29PM -0800, Chris Verges wrote:
> >> Related to the lm73, but off the main topic ...
> >>
> >> Any advice for whether to go forth with these changes?
> >
> > All 1s would be invalid per spec - bit 0 and 1 of the returned value
> > should always be 0. You could check for that and return an error (-EIO
> > ?) if this condition is seen. Usually I'd say that kind of thing is so
> > unlikely not to bother, but if you see a transfer error every 100
> > readings who knows.
>
> OK, I'll add it to the "if I touch the driver again, take a look at it"
> category. Though it will likely happen since I'll probably take on the
> resolution / alarm stuff below.
>
> >> I'd also like to find a way to expose the variable precision control
> >> available to the driver. I submitted a patch previously, but it was a
> >> first pass and not well conceived. Does hwmon have a standard way of
> >
> > But then you didn't even reply to my comments as far as I can see ...
>
> I didn't reply at the time, but I did see them. I've actually been
> pondering the best way to handle this since then. (Not a lot of time
> was spent on these musings, as I was heavily on other projects.) This
> is why there hasn't been an updated patch sent.
>
> > Your options are:
> > - Platform data
> > - Device tree data (or better both)
> > - Use the update_interval attribute. Not directly applicable, but the
> > resolution impacts the conversion time so the case could be made.
> > And resolution does impact conversion time, so the only reason for
> > not selecting 14 bit resolution all the time would be its impact on
> > conversion time. The datasheet also specifically mentions that the
> > reason for the configurable resolution is its impact on conversion
> > time. Might as well specify it directly.
> > - Add a resolution sysfs attribute. There are other chips with a
> > configurable resolution, so again the case could be made to
> > introduce that. As I said earlier, that would have to be
> > standardized and consistent, though.
> >
> > Would this ever be changed at runtime, or is it a startup
> > configuration option ? In the latter case, platform and/or device
> > tree data would be the better choice. Since you suggested
> > Kconfig/module option above, which does suggest startup configuration,
> > platform and/or device tree data might be your answer.
>
> Your points about Kconfig and module options are well heard. I agree
> that it needs to be sensor-specific, not shared across all sensors on a
> system.
>
> I'll take a stab at platform data and device tree data at a minimum.
> Support for both should be easy enough.
>
> I do see the reason to make it configurable at runtime. Using the
> update_interval attribute is an interesting idea. There is perhaps a
> concern about intuitiveness of the interface being a problem. Not all
> users looking for more precision will necessarily think of adjusting
> conversion time at first. However, in lack of a "resolution" attribute
> being available, perhaps this is the next best step. I'll give it a
> shot and we can rip apart the code proposal.
>
It would be unusual, though, to have both dt/platform data _and_ an attribute.
Having an attribute makes platform data redundant.
As for the attribute name, question is really what people are looking for.
There are multiple possible reasons for configuring the resolution and/or
conversion time.
- optimize for power consumption
- optimize for resolution
- optimize for conversion time
The LM73 datasheet mentions the last two. For other chips, it is possible
to configure the conversion time to reduce power consumption.
There is always a trade-off; either it is power consumption vs. conversion
time, or it is resolution vs. conversion time. The common attribute for both
trade-offs seems to be conversion time (or update interval).
Given that, using conversion time as common atribute doesn't seem too
far off track.
We _could_ of course support both attributes, but that seems to be redundant.
> > From an overall functionality perspective, adding support for alarm
> > flags might be more or at least equally important, though. Hint hint
> > ;)
>
> That's simple enough. I assume using the sysfs_notify() mechanism to
> allow epoll support would be wanted. We'd need the platform/device tree
> to specify the IRQ to use, so it would have to be one of those
> "specify-if-desired" features.
>
epoll and notification support is nice to have, but not mandatory. Most drivers
don't support it. Question is if we can come up with a common mechanism. It
isn't just that the interrupt needs to be specified - it may also make sense or
even be necessary to be able to specify gpio pins (which would then be used as
interrupt source). I'll have to check how other drivers handle this.
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 8+ messages in thread