Hi Guenter, On Mon, 7 Jul 2014 07:23:03 -0700, Guenter Roeck wrote: > SMBus block commands are different to I2C block commands since > the returned data is not normally accessible with byte or word > commands on other command offsets. Add linked list of 'block' > commands to support those commands. > > Access mechanism is quite simple: Block commands must be written > before they can be read. The first write selects the block length. > Subsequent writes can be partial. Block read commands always return > the number of bytes selected with the first write. > > Signed-off-by: Guenter Roeck <linux@xxxxxxxxxxxx> > --- > v2: Make new functionality only available on request via functionality > module parameter > Add more details about SMBus block mode support to documentation > Use correct sizeof() variable in devm_kzalloc > Use stub_find_block() only in SMBus block command itself. > Store first word of block data in chip->words[]. > When writing block data and the written data is longer than > the first write, bail out with debug message indicating the reason > for the error. Looks good, thanks for the quick update. Reviewed-by: Jean Delvare <jdelvare@xxxxxxx> Just one thing I have been thinking about while reviewing the updated code... You decided to make the first SMBus block write select the maximum block length, and you always use that for SMBus block reads. However you accept partial writes. The fact that the order in which writes are performed has an effect on which writes are accepted is somewhat unexpected. Wouldn't it make more sense to accept all SMBus block writes, regardless of the size (as long as it is within the limits of the SMBus standard, of course)? Then the only thing left to decide is whether SMBus block reads use the maximum size or the size of the most recent SMBus block write. I suspect this would mimic the behavior of real chips better. What do you think? -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
