Hi David, On Mon, 17 Sep 2007 13:50:24 -0700, David Brownell wrote: > When "i2cdetect -F" says "SMBus PEC", it's extremely misleading. The > issue is whether or not PEC has *HARDWARE* support, not whether PEC > itself is supported. (PEC is portably implemented in software.) > > --- lm_sensors-2.10.4.orig/prog/detect/i2cdetect.c > +++ lm_sensors-2.10.4/prog/detect/i2cdetect.c > @@ -147,7 +147,7 @@ static const struct func all_func[] = { > { .value = I2C_FUNC_SMBUS_BLOCK_PROC_CALL, > .name = "SMBus Block Process Call" }, > { .value = I2C_FUNC_SMBUS_HWPEC_CALC, > - .name = "SMBus PEC" }, > + .name = "SMBus PEC in Hardware" }, > { .value = I2C_FUNC_SMBUS_WRITE_I2C_BLOCK, > .name = "I2C Block Write" }, > { .value = I2C_FUNC_SMBUS_READ_I2C_BLOCK, I agree that the current situation is confusing, I had noticed this already when reworking the PEC support in 2.6.15, but postponed fixing it. However, I don't think that what you proposed is the proper fix. We don't care whether PEC is implemented in hardware or software. What really matters is whether it is implemented at all, or not. So I'd rather rename I2C_FUNC_SMBUS_HWPEC_CALC to I2C_FUNC_SMBUS_PEC, and have i2c-algo-bit and other drivers declare that they support it. What do you think? -- Jean Delvare