From patchwork Fri Sep 22 18:38:03 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: 9966815 X-Patchwork-Delegate: andy.shevchenko@gmail.com 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 24C8C60381 for ; Fri, 22 Sep 2017 18:39:24 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1A38725223 for ; Fri, 22 Sep 2017 18:39:24 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0E9A8298FA; Fri, 22 Sep 2017 18:39:24 +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=unavailable 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 BA66725223 for ; Fri, 22 Sep 2017 18:39:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752425AbdIVSjJ (ORCPT ); Fri, 22 Sep 2017 14:39:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46874 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752416AbdIVSjG (ORCPT ); Fri, 22 Sep 2017 14:39:06 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 007BF7F3F6; Fri, 22 Sep 2017 18:39:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 007BF7F3F6 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hdegoede@redhat.com Received: from dhcp-45-79.space.revspace.nl.com (ovpn-112-18.ams2.redhat.com [10.36.112.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id 56E6661353; Fri, 22 Sep 2017 18:39:02 +0000 (UTC) From: Hans de Goede To: MyungJoo Ham , Chanwoo Choi , Guenter Roeck , Heikki Krogerus , Darren Hart , Andy Shevchenko , Peter Rosin , Mathias Nyman Cc: Hans de Goede , linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org, devel@driverdev.osuosl.org, Kuppuswamy Sathyanarayanan , Sathyanarayanan Kuppuswamy Natarajan , Greg Kroah-Hartman , linux-usb@vger.kernel.org Subject: [PATCH v3 14/14] platform/x86: intel_cht_int33fe: Add mux mappings for the Type-C port Date: Fri, 22 Sep 2017 20:38:03 +0200 Message-Id: <20170922183803.10701-14-hdegoede@redhat.com> In-Reply-To: <20170922183803.10701-1-hdegoede@redhat.com> References: <20170922183803.10701-1-hdegoede@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 22 Sep 2017 18:39:06 +0000 (UTC) Sender: platform-driver-x86-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: platform-driver-x86@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP We need to add mappings for the mux subsys to be able to find the muxes for the fusb302 driver to be able to control the PI3USB30532 Type-C mux and the device/host mux integrated in the CHT SoC. Signed-off-by: Hans de Goede Acked-by: Andy Shevchenko --- drivers/platform/x86/Kconfig | 1 + drivers/platform/x86/intel_cht_int33fe.c | 23 +++++++++++++++++++++++ 2 files changed, 24 insertions(+) diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig index 312d2472b8b3..830ff8d0a1eb 100644 --- a/drivers/platform/x86/Kconfig +++ b/drivers/platform/x86/Kconfig @@ -794,6 +794,7 @@ config ACPI_CMPC config INTEL_CHT_INT33FE tristate "Intel Cherry Trail ACPI INT33FE Driver" depends on X86 && ACPI && I2C && REGULATOR + select MULTIPLEXER ---help--- This driver add support for the INT33FE ACPI device found on some Intel Cherry Trail devices. diff --git a/drivers/platform/x86/intel_cht_int33fe.c b/drivers/platform/x86/intel_cht_int33fe.c index b2925d996613..89ba510dac78 100644 --- a/drivers/platform/x86/intel_cht_int33fe.c +++ b/drivers/platform/x86/intel_cht_int33fe.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include @@ -35,6 +36,19 @@ struct cht_int33fe_data { struct i2c_client *pi3usb30532; }; +static struct mux_lookup cht_int33fe_mux_lookup[] = { + { + .provider = "i2c-pi3usb30532", + .dev_id = "i2c-fusb302", + .mux_name = "type-c-mode-mux", + }, + { + .provider = "intel_cht_usb_mux", + .dev_id = "i2c-fusb302", + .mux_name = "usb-role-mux", + }, +}; + /* * Grrr I severly dislike buggy BIOS-es. At least one BIOS enumerates * the max17047 both through the INT33FE ACPI device (it is right there @@ -177,6 +191,9 @@ static int cht_int33fe_probe(struct i2c_client *client) board_info.properties = fusb302_props; board_info.irq = fusb302_irq; + mux_add_table(cht_int33fe_mux_lookup, + ARRAY_SIZE(cht_int33fe_mux_lookup)); + data->fusb302 = i2c_acpi_new_device(dev, 2, &board_info); if (!data->fusb302) goto out_unregister_max17047; @@ -200,6 +217,9 @@ static int cht_int33fe_probe(struct i2c_client *client) if (data->max17047) i2c_unregister_device(data->max17047); + mux_remove_table(cht_int33fe_mux_lookup, + ARRAY_SIZE(cht_int33fe_mux_lookup)); + return -EPROBE_DEFER; /* Wait for the i2c-adapter to load */ } @@ -212,6 +232,9 @@ static int cht_int33fe_remove(struct i2c_client *i2c) if (data->max17047) i2c_unregister_device(data->max17047); + mux_remove_table(cht_int33fe_mux_lookup, + ARRAY_SIZE(cht_int33fe_mux_lookup)); + return 0; }