On Tue, 21 Nov 2017, Eudean Sun wrote: > 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@xxxxxxxxxx> > --- > Changes in v2: > - Explain the fix and testing in more detail in the commit message. Applied to for-4.15/upstream-fixes, thanks. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
