From patchwork Sat Jul 22 18:55:37 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 9858137 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 4DA47600CA for ; Sat, 22 Jul 2017 18:55:45 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2E3DF2851A for ; Sat, 22 Jul 2017 18:55:45 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 22F0928524; Sat, 22 Jul 2017 18:55:45 +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=-6.9 required=2.0 tests=BAYES_00,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 C23DA2851A for ; Sat, 22 Jul 2017 18:55:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751416AbdGVSzn (ORCPT ); Sat, 22 Jul 2017 14:55:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43630 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750873AbdGVSzn (ORCPT ); Sat, 22 Jul 2017 14:55:43 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B33E880F63; Sat, 22 Jul 2017 18:55:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B33E880F63 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hdegoede@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com B33E880F63 Received: from shalem.localdomain.com (ovpn-116-48.ams2.redhat.com [10.36.116.48]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7256A5D6A4; Sat, 22 Jul 2017 18:55:41 +0000 (UTC) From: Hans de Goede To: Jiri Kosina , Benjamin Tissoires , Wolfram Sang Cc: Hans de Goede , linux-input@vger.kernel.org, linux-i2c@vger.kernel.org Subject: [PATCH 2/2] HID: i2c-hid: Do not bind to CHPN0001 touchscreen Date: Sat, 22 Jul 2017 20:55:37 +0200 Message-Id: <20170722185537.12696-2-hdegoede@redhat.com> In-Reply-To: <20170722185537.12696-1-hdegoede@redhat.com> References: <20170722185537.12696-1-hdegoede@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Sat, 22 Jul 2017 18:55:42 +0000 (UTC) Sender: linux-input-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The CHPN0001 ACPI device has a _CID of PNP0C50 but is not HID compatible, it uses its own protocol which is handled by the chipone_icn8318 driver. If the i2c_hid_driver's probe functon gets called it will fail with a "hid_descr_cmd failed" error. Worse, after the probe failure the i2c / ACPI core code will put the ACPI device in D3 state and when the chipone_icn8318 driver then loads the device is put back in D0 state, executing its PS0 ACPI method, which resets the controller, causing the controller to loose its firmware which was loaded by the BIOS. The chipone_icn8318 driver has a workaround for this, but that requires it to be the only (or the first) driver to probe the device. This commit adds a match callback and returns -ENODEV for i2c_client-s with a CHPN0001 ACPI device id, so that the probe function never gets called, fixing the controller losing its firmware. Signed-off-by: Hans de Goede Reviewed-By: Benjamin Tissoires --- Changes in v2: -Use the new i2c_driver match callback to only filter out the CHPN0001 ACPI device, rather then use acpi_dev_present in probe and not registering the driver at all when the system has a CHPN0001 device --- drivers/hid/i2c-hid/i2c-hid.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c index 046f692fd0a2..79bed9afc388 100644 --- a/drivers/hid/i2c-hid/i2c-hid.c +++ b/drivers/hid/i2c-hid/i2c-hid.c @@ -891,6 +891,26 @@ static void i2c_hid_acpi_fix_up_power(struct device *dev) acpi_device_fix_up_power(adev); } +static const struct acpi_device_id i2c_hid_acpi_blacklist[] = { + /* + * The CHPN0001 ACPI device has a _CID of PNP0C50 but is not HID + * compatible, just probing it puts the device in an unusable state due + * to it also have ACPI power management issues. + */ + {"CHPN0001", 0 }, + { }, +}; + +static int i2c_hid_match(struct i2c_client *client) +{ + struct acpi_device *adev = ACPI_COMPANION(&client->dev); + + if (adev && acpi_match_device_ids(adev, i2c_hid_acpi_blacklist) == 0) + return -ENODEV; + + return 0; +} + static const struct acpi_device_id i2c_hid_acpi_match[] = { {"ACPI0C50", 0 }, {"PNP0C50", 0 }, @@ -905,6 +925,7 @@ static inline int i2c_hid_acpi_pdata(struct i2c_client *client, } static inline void i2c_hid_acpi_fix_up_power(struct device *dev) {} +static int i2c_hid_match(struct i2c_client *client) { return 0; } #endif #ifdef CONFIG_OF @@ -1255,6 +1276,7 @@ static struct i2c_driver i2c_hid_driver = { .of_match_table = of_match_ptr(i2c_hid_of_match), }, + .match = i2c_hid_match, .probe = i2c_hid_probe, .remove = i2c_hid_remove, .shutdown = i2c_hid_shutdown,