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
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
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