Hi Hans,
thanks for fixing this!
On Fri, Aug 10, 2018 at 02:27:14PM +0200, Hans de Goede wrote:
> acpi_gsb_i2c_write_bytes() returns i2c_transfer()'s return value, which
> is the number of transfers executed on success, so 1.
>
> The ACPI code expects us to store 0 in gsb->status for success, not 1.
>
> Specifically this breaks the following code in the Thinkpad 8 DSDT:
>
> ECWR = I2CW = ECWR /* \_SB_.I2C1.BAT0.ECWR */
> If ((ECST == Zero))
> {
> ECRD = I2CR /* \_SB_.I2C1.I2CR */
> }
>
> Before this commit we set ECST to 1, causing the read to never happen
> breaking battery monitoring on the Thinkpad 8. Note the Thinkpad 8 also
> has some unrelated issues where i2c transfers are unreliable.
>
> This commit sets status to 0 if it was bigger then 0 (so success),
> mirroring the multi-byte read path, fixing this.
>
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
> ---
> drivers/i2c/i2c-core-acpi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
> index 7c3b4740b94b..10ad851bd277 100644
> --- a/drivers/i2c/i2c-core-acpi.c
> +++ b/drivers/i2c/i2c-core-acpi.c
> @@ -595,6 +595,8 @@ i2c_acpi_space_handler(u32 function, acpi_physical_address command,
> } else {
> status = acpi_gsb_i2c_write_bytes(client, command,
> gsb->data, info->access_length);
> + if (status > 0)
> + status = 0;
I think we should fix the function we are calling (and the read
function, too). It doesn't make much sense to return the number of
successful messages when the paramters of the function deal with bytes,
not messages. Otherwise we probably will have the bug somewhere else
again.
We should also return 0 only iff all messages were sent, otherwise -EIO
or something.
Makes sense?
Regards,
Wolfram
