From patchwork Sun Apr 26 10:47:12 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 11510427 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id A72D615AB for ; Sun, 26 Apr 2020 10:47:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8F4B92071C for ; Sun, 26 Apr 2020 10:47:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="cO16BoF/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726166AbgDZKr1 (ORCPT ); Sun, 26 Apr 2020 06:47:27 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:38484 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726139AbgDZKr0 (ORCPT ); Sun, 26 Apr 2020 06:47:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587898045; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rR1VWAX5n/MzP2zWX8Dox7ig/TvsvH/ThCSY7sIXksw=; b=cO16BoF/DtP0qwtMropNdth8UtneFMXS6ZfMGz3X0mCZjLe0+uClp1NLBHKiTpJm4MHZqP Ir6yd7Xbchwt3juLpEs4MXA/bKAzQvA5ZcSnYNuMk8P6+NCU0/kKMPuD00WrRXJOEnGkxx Z1D76X3s5eiKv3vvh8YRqlnQkvNBt5E= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-268-oY_6SS6PNzqWjCWyv53M5A-1; Sun, 26 Apr 2020 06:47:21 -0400 X-MC-Unique: oY_6SS6PNzqWjCWyv53M5A-1 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id B7C11107ACCA; Sun, 26 Apr 2020 10:47:19 +0000 (UTC) Received: from x1.localdomain.com (ovpn-112-32.ams2.redhat.com [10.36.112.32]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2356E5D716; Sun, 26 Apr 2020 10:47:17 +0000 (UTC) From: Hans de Goede To: "Rafael J . Wysocki" , Len Brown , Darren Hart , Andy Shevchenko Cc: Hans de Goede , linux-acpi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 1/2] platform/x86: i2c-multi-instantiate: Add flag for passing fwnode Date: Sun, 26 Apr 2020 12:47:12 +0200 Message-Id: <20200426104713.216896-2-hdegoede@redhat.com> In-Reply-To: <20200426104713.216896-1-hdegoede@redhat.com> References: <20200426104713.216896-1-hdegoede@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Sender: platform-driver-x86-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: platform-driver-x86@vger.kernel.org In some cases the driver for the i2c_client-s which i2c-multi-instantiate instantiates may need access some fields / methods from to the ACPI fwnode for which i2c_clients are being instantiated. An example of this are CPLM3218 ACPI device-s. These contain CPM0 and CPM1 packages with various information (e.g. register init values) which the driver needs. Passing the fwnode through the i2c_board_info struct also gives the i2c-core access to it, and if we do not pass an IRQ then the i2c-core will use the fwnode to get an IRQ, see i2c_acpi_get_irq(). This is a problem when there is only an IRQ for 1 of the clients described in the ACPI device we are instantiating clients for. If we unconditionally pass the fwnode, then i2c_acpi_get_irq() will assign the same IRQ to all clients instantiated, leading to kernel-oopses like this (BSG1160 device): [ 27.340557] genirq: Flags mismatch irq 76. 00002001 (bmc150_magn_event) vs. 00000001 (bmc150_accel_event) [ 27.340567] Call Trace: ... So we cannot simply always pass the fwnode. This commit adds a PASS_FWNODE flag, which can be used to pass the fwnode in cases where we do not have the IRQ problem and the driver for the instantiated client(s) needs access to the fwnode. Signed-off-by: Hans de Goede --- drivers/platform/x86/i2c-multi-instantiate.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/platform/x86/i2c-multi-instantiate.c b/drivers/platform/x86/i2c-multi-instantiate.c index 6acc8457866e..dcafb1a29d17 100644 --- a/drivers/platform/x86/i2c-multi-instantiate.c +++ b/drivers/platform/x86/i2c-multi-instantiate.c @@ -20,6 +20,8 @@ #define IRQ_RESOURCE_GPIO 1 #define IRQ_RESOURCE_APIC 2 +#define PASS_FWNODE BIT(2) + struct i2c_inst_data { const char *type; unsigned int flags; @@ -93,6 +95,10 @@ static int i2c_multi_inst_probe(struct platform_device *pdev) snprintf(name, sizeof(name), "%s-%s.%d", dev_name(dev), inst_data[i].type, i); board_info.dev_name = name; + + if (inst_data[i].flags & PASS_FWNODE) + board_info.fwnode = dev->fwnode; + switch (inst_data[i].flags & IRQ_RESOURCE_TYPE) { case IRQ_RESOURCE_GPIO: ret = acpi_dev_gpio_irq_get(adev, inst_data[i].irq_idx); From patchwork Sun Apr 26 10:47:13 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 11510433 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id D7C751667 for ; Sun, 26 Apr 2020 10:47:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BA18C21D80 for ; Sun, 26 Apr 2020 10:47:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="bMWRnq5l" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726169AbgDZKr2 (ORCPT ); Sun, 26 Apr 2020 06:47:28 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:41683 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726143AbgDZKr1 (ORCPT ); Sun, 26 Apr 2020 06:47:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587898044; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ameLghCB4urIBaiOFKoYPKuTDYVd0O7mLx3+vt0PmiM=; b=bMWRnq5lSpP8NTk2O+0lPhqV35DrtWlf26dbI1gx+cprtT7ydKlNxfYitU+Q+72oDt67zb B/C7Mv8nytk7cP2zyL1cYJElzBgO2oSmZ1Qn/BGlpktB9N1deHWeNOUmF6XPjdKgZavzp7 F0pab9xsfM/z1uWAdA+/Yq5PF4MLeCk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-125-qLBDTMThPXi08NF_M3g5Hg-1; Sun, 26 Apr 2020 06:47:23 -0400 X-MC-Unique: qLBDTMThPXi08NF_M3g5Hg-1 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9BE8B800D24; Sun, 26 Apr 2020 10:47:21 +0000 (UTC) Received: from x1.localdomain.com (ovpn-112-32.ams2.redhat.com [10.36.112.32]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0A2C55D715; Sun, 26 Apr 2020 10:47:19 +0000 (UTC) From: Hans de Goede To: "Rafael J . Wysocki" , Len Brown , Darren Hart , Andy Shevchenko Cc: Hans de Goede , linux-acpi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/2] ACPI / scan: Create platform device for CPLM3218 ACPI nodes Date: Sun, 26 Apr 2020 12:47:13 +0200 Message-Id: <20200426104713.216896-3-hdegoede@redhat.com> In-Reply-To: <20200426104713.216896-1-hdegoede@redhat.com> References: <20200426104713.216896-1-hdegoede@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Sender: platform-driver-x86-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: platform-driver-x86@vger.kernel.org Some CPLM3218 ACPI nodes also put the SMBus Alert Response Address (0x0c) in their ACPI resource table; and they put it there as the first entry, here is an example from the CPLM3218 device in the DSDT of an Asus T100TA: Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (SBUF, ResourceTemplate () { I2cSerialBusV2 (0x000C, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2C3", 0x00, ResourceConsumer, , Exclusive, ) I2cSerialBusV2 (0x0048, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2C3", 0x00, ResourceConsumer, , Exclusive, ) Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) { 0x00000033, } }) Return (SBUF) /* \_SB_.I2C3.ALSD._CRS.SBUF */ } The actual I2C address of the sensor in this case is the 0x48 address from the second resource-table entry. On some other devices (e.g. HP X2 Bay Trail models, Acer SW5-012) the CPLM3218 node contains only 1 I2C resource. Add the CPLM3218 to the I2C multi instantiate list, so that the i2c-multi-instantiate.c driver can handle it. Note in the case where there are 2 I2C resources we simply instatiate i2c-clients for both and let the cm32181 driver figure out that the first one is not the one it wants. Doing things this way is actually desirable because on devices where there are 2 I2C resources it seems that we first need to do a SMBus read of the 0x0c address before the sensor will respond to I2C transfers on its actual address. Signed-off-by: Hans de Goede Acked-by: Rafael J. Wysocki --- drivers/acpi/scan.c | 1 + drivers/platform/x86/i2c-multi-instantiate.c | 7 +++++++ 2 files changed, 8 insertions(+) diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 6d3448895382..937d72fc212c 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -1544,6 +1544,7 @@ static bool acpi_device_enumeration_by_parent(struct acpi_device *device) static const struct acpi_device_id i2c_multi_instantiate_ids[] = { {"BSG1160", }, {"BSG2150", }, + {"CPLM3218", }, {"INT33FE", }, {"INT3515", }, {} diff --git a/drivers/platform/x86/i2c-multi-instantiate.c b/drivers/platform/x86/i2c-multi-instantiate.c index dcafb1a29d17..e1cdc44e6f57 100644 --- a/drivers/platform/x86/i2c-multi-instantiate.c +++ b/drivers/platform/x86/i2c-multi-instantiate.c @@ -180,6 +180,12 @@ static const struct i2c_inst_data int3515_data[] = { {} }; +static const struct i2c_inst_data cplm3218_data[] = { + { "cm32181", PASS_FWNODE }, + { "cm32181", PASS_FWNODE }, + {} +}; + /* * Note new device-ids must also be added to i2c_multi_instantiate_ids in * drivers/acpi/scan.c: acpi_device_enumeration_by_parent(). @@ -187,6 +193,7 @@ static const struct i2c_inst_data int3515_data[] = { static const struct acpi_device_id i2c_multi_inst_acpi_ids[] = { { "BSG1160", (unsigned long)bsg1160_data }, { "BSG2150", (unsigned long)bsg2150_data }, + { "CPLM3218", (unsigned long)cplm3218_data }, { "INT3515", (unsigned long)int3515_data }, { } };