On Monday 02 June 2008, Jean Delvare wrote: > > > Sorry, I meant what happens if a NAK is received after the address > > part of the i2c_msg has been sent, when sending the msg data? Is this > > a case for an error like EPIPE, ENOLINK or EREMOTEIO? > > Our current error codes document suggests EIO.
And also says it's sufficiently vague as to make avoiding it be worthwhile. :) > EPIPE and ENOLINK do not > make much sense IMHO. EREMOTEIO would make some sense, but I suspect > that many drivers won't be able to isolate this specific error and thus > will still return EIO. David, what do you think? This is one of those cases where the I2C programming interface is insufficient. As noted in the comment added to i2c_transfer() by the patch updating fault code passthrough handling in i2c-core.c: > > * - When we get a NAK after transmitting N bytes to a slave, > > * there is no way to report "N" ... or to let the master > > * continue executing the rest of this combined message, if > > * that's the appropriate response. As I mentioned earlier, the best way to address this issue would be to carve a 16 bit field out of the existing struct padding and use that from updated i2c_adapter drivers to report N (actual_len). The standard way to report short writes is not via errno values... but by reporting how many bytes were written. See "man 2 write". It's not what the I2C stack does now, though. That could be done if i2c-core got some updates, at least with any i2c adapters that get updated to better report this fault (using that new field living in what's now struct padding). Failing such updates, I'd avoid EREMOTEIO since that's what USB uses to indicate short *reads* (not writes) when they're flagged for reporting as errors (not the default). EFBIG (too big) would make more sense if short writes must be reported as some kind of fault. - Dave _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
