[lm-sensors] i2c errors while updating sensors

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Fri Dec 23 15:44:35 CET 2011


I was peeking at lm75/lm80 i2c error message handing.

The problem I am facing is that I am using lm75 for temperature monitoring
and lm80 for temperature and fan tacho monitoring.
This is an embedded (powerpc) system using a 2.6.38 kernel, and accessing
the sensors through the sysfs interface.

The customer wants to be able to detect if someone accidently disconnects
the fan (or the monitoring chip dies).
I know i2c is not hot pluggable, but would have expected to be able to
detect this error condition

However, from peeking at the sources, it seems I am not.


lm75.c says (function lm75_update_device)
        for (i = 0; i < ARRAY_SIZE(data->temp); i++) {
            int status;

            status = lm75_read_value(client, LM75_REG_TEMP[i]);
            if (status < 0)
                dev_dbg(&client->dev, "reg %d, err %d\n",
                        LM75_REG_TEMP[i], status);
            else
                data->temp[i] = status;
        }
        data->last_updated = jiffies;
        data->valid = 1;
So there is an error message if dbg is on, but a user will still get the
old data as temp[i] is not updated.

Wouldn't it be nice to e.g. add a (bool) attribute data-valid or or so and
drop that to 0 on a read fail (or maybe 3 subsequent read fails)?
Or is there a better way do detect such a problem in user space (e.g. by
putting an "error" value in the var)

I've also peeked at lm80.c
Here the situation seems to be a little bit worse.
E.g. I see:

static int lm80_read_value(struct i2c_client *client, u8 reg)
{
    return i2c_smbus_read_byte_data(client, reg);
}

...

        data->temp =
            (lm80_read_value(client, LM80_REG_TEMP) << 8) |
            (lm80_read_value(client, LM80_REG_RES) & 0xf0);

but i2c_smbus_read_byte_data may return a negative value upon error.
To me it seems this is not going to return a sensible value in case the
read fails (and also not e.g. something like -1)

Is this desired? Should this be fixed? Or is there a better way to do so?
If needed, I can have a stab at the code to fix it, but in that case I
would appreciate some guidance in the direction of the preferred solution
(so my work is not rejected because it was felt a faulty solution).

Best regards & seasons greetings,
Frans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20111223/58183eda/attachment.html>


More information about the lm-sensors mailing list