From patchwork Fri Aug 10 12:27:14 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 10562657 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 8F5BE13B4 for ; Fri, 10 Aug 2018 12:27:20 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7DC3B2B9D6 for ; Fri, 10 Aug 2018 12:27:20 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 71C8B2B9E1; Fri, 10 Aug 2018 12:27:20 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2522D2B9D6 for ; Fri, 10 Aug 2018 12:27:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728084AbeHJO5B (ORCPT ); Fri, 10 Aug 2018 10:57:01 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:51980 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727352AbeHJO5A (ORCPT ); Fri, 10 Aug 2018 10:57:00 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A1C1040241C3; Fri, 10 Aug 2018 12:27:17 +0000 (UTC) Received: from shalem.localdomain.com (ovpn-116-24.ams2.redhat.com [10.36.116.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id 717A910EE991; Fri, 10 Aug 2018 12:27:16 +0000 (UTC) From: Hans de Goede To: Wolfram Sang , Mika Westerberg Cc: Hans de Goede , linux-i2c@vger.kernel.org, linux-acpi@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH] i2c: core: ACPI: Properly set status byte to 0 for multi-byte writes Date: Fri, 10 Aug 2018 14:27:14 +0200 Message-Id: <20180810122714.690-1-hdegoede@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Fri, 10 Aug 2018 12:27:17 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Fri, 10 Aug 2018 12:27:17 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hdegoede@redhat.com' RCPT:'' Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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@vger.kernel.org Signed-off-by: Hans de Goede Acked-by: Mika Westerberg --- 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; } break;