summaryrefslogtreecommitdiffstats
path: root/drivers/tee
diff options
context:
space:
mode:
authorEudean Sun <eudean@arista.com>2017-11-21 10:43:24 -0800
committerJiri Kosina <jkosina@suse.cz>2017-11-21 21:39:45 +0100
commit542134c0375b5ca2b1d18490c02b8a20bfdd8d74 (patch)
tree5e00d617d6608e4914dcf7ac381b6e170ee0ca85 /drivers/tee
parent20df15783a44a289aaa8c8f83b3f715f9040c9c2 (diff)
downloadlinux-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/tee')
0 files changed, 0 insertions, 0 deletions