[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <nycvar.YFH.7.76.1711212141170.11505@cbobk.fhfr.pm>
Date: Tue, 21 Nov 2017 21:41:36 +0100 (CET)
From: Jiri Kosina <jikos@...nel.org>
To: Eudean Sun <eudean@...sta.com>
cc: Benjamin Tissoires <benjamin.tissoires@...hat.com>,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] HID: cp2112: Fix I2C_BLOCK_DATA transactions
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@...sta.com>
> ---
> 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
Powered by blists - more mailing lists