i2c errors while updating sensors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux