On Mon, May 19, 2008 at 06:49:07PM +0200, Jean Delvare wrote: > Hi Wolfram, > > > The dev_err-statements are too strong, IMHO. For example, the > > at24-driver tries to write as fast as possible and may recieve a NACK, > > then it will wait a bit and retry. I wouldn't call this NACK an error > > then. I also wonder if it is worth a warning, as there is a timeout > > message later on, which will be printed as dev_dbg only. As other > > drivers I glimpsed at also don't write anything on NACK, maybe dev_dbg > > consistency would be preferable.
dev_err() for a number of i2c bus errors are too strong, think about the case where a system is having i2cprobe run on it (you will get a lot of errors). It isn't as if the error is lost downstream anyway. > > > + return 0; > > > +} > > I agree that dev_err() on nack is too strong, most drivers log it at > dev_dbg() level. However I fail to see the relation with timeout? A > nack isn't a timeout. A timeout would be very wrong and should be > reported with dev_err() I think. > > Oh, BTW, nacks should be reported with -ENXIO according to: > http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/i2c-document-standard-fault-codes.patch > It might be worth checking that this new driver complies with these > freshly adopted error codes standard. Hmm, where ECONREFUSED or EPIPE (if NAK in already selected device) entertained? -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
