One other thing, the change in 2.4 / CVS probably won't create a binary compatibility problem because of alignment, but to be safe we may want to change it back. 2.6 change of course is fine. Comments? Jean Delvare wrote: > Ohaio Hideki, > > >>I want to ask about the following comment in i2c.h. >>What does "one more for read length in block process call" mean? >>In i2c_smbus_block_process_call and i2c_smbus_xfer_emulated, >>block[0] is used for the read length. > > > As strange as it may sound considering that this comment has been > around since June 2002, my reading of the code confirms that you are > right and this comment isn't. Digging through the CVS history, I found > that the i2c_smbus_block_process_call used to work differently in its > first incarnation (2002-06-18). It was originally expecing the > underlying implementation (whether hardware or software emulated) to > append the received bytes after the sent ones in the data buffer. This > explains the additional byte required and the comment. It was changed > to the current logic (received bytes overwrite sent bytes at the > beginning of the data buffer) a few weeks after (2002-07-08), but the > changes to union i2c_smbus_data were not reverted. > > I fixed this in i2c CVS (kernel/i2c.h) and lm_sensors CVS > (kernel/include/i2c-dev.h), and have prepared a patch for Linux 2.6 > which I will send to Greg KH later. You get credits for the discovery, > thanks a lot for reporting. > > Arigato,
