Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752511AbdIEQna (ORCPT ); Tue, 5 Sep 2017 12:43:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35802 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752481AbdIEQnW (ORCPT ); Tue, 5 Sep 2017 12:43:22 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3583F5F7BB Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hdegoede@redhat.com 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 v2 11/11] platform/x86: intel_cht_int33fe: Add mux mappings for the Type-C port Date: Tue, 5 Sep 2017 18:42:21 +0200 Message-Id: <20170905164221.11266-12-hdegoede@redhat.com> In-Reply-To: <20170905164221.11266-1-hdegoede@redhat.com> References: <20170905164221.11266-1-hdegoede@redhat.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 05 Sep 2017 16:43:22 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2790 Lines: 87 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; } -- 2.13.5