diff options
author | Eudean Sun <eudean@arista.com> | 2017-11-21 10:43:24 -0800 |
---|---|---|
committer | Jiri Kosina <jkosina@suse.cz> | 2017-11-21 21:39:45 +0100 |
commit | 542134c0375b5ca2b1d18490c02b8a20bfdd8d74 (patch) | |
tree | 5e00d617d6608e4914dcf7ac381b6e170ee0ca85 /drivers/lightnvm | |
parent | 20df15783a44a289aaa8c8f83b3f715f9040c9c2 (diff) | |
download | linux-542134c0375b5ca2b1d18490c02b8a20bfdd8d74.tar.bz2 |
HID: cp2112: Fix I2C_BLOCK_DATA transactions
The existing driver erroneously treats I2C_BLOCK_DATA and BLOCK_DATA
commands the same.
For I2C_BLOCK_DATA reads, the length of the read is provided in
data->block[0], but the length itself should not be sent to the slave. In
contrast, for BLOCK_DATA reads no length is specified since the length
will be the first byte returned from the slave. When copying data back
to the data buffer, for an I2C_BLOCK_DATA read we have to take care not to
overwrite data->block[0] to avoid overwriting the length. A BLOCK_DATA
read doesn't have this concern since the first byte returned by the device
is the length and belongs in data->block[0].
For I2C_BLOCK_DATA writes, the length is also provided in data->block[0],
but the length itself is not sent to the slave (in contrast to BLOCK_DATA
writes where the length prefixes the data sent to the slave).
This was tested on physical hardware using i2cdump with the i and s flags
to test the behavior of I2C_BLOCK_DATA reads and BLOCK_DATA reads,
respectively. Writes were not tested but the I2C_BLOCK_DATA write change
is pretty simple to verify by inspection.
Signed-off-by: Eudean Sun <eudean@arista.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Diffstat (limited to 'drivers/lightnvm')
0 files changed, 0 insertions, 0 deletions