From patchwork Sun May 20 13:28:48 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: 917158 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-i2c-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 40pjRm3z7Bz9s3x for ; Sun, 20 May 2018 23:29:08 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751347AbeETN3E (ORCPT ); Sun, 20 May 2018 09:29:04 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:41348 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751292AbeETN3D (ORCPT ); Sun, 20 May 2018 09:29:03 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EB2704022407; Sun, 20 May 2018 13:29:02 +0000 (UTC) Received: from shalem.localdomain.com (ovpn-116-92.ams2.redhat.com [10.36.116.92]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0D063215CDA7; Sun, 20 May 2018 13:28:58 +0000 (UTC) From: Hans de Goede To: "Rafael J . Wysocki" , Len Brown , Andy Shevchenko , Mika Westerberg , Wolfram Sang , Jonathan Cameron Cc: Hans de Goede , linux-acpi@vger.kernel.org, linux-i2c@vger.kernel.org, Hartmut Knaack , Lars-Peter Clausen , linux-iio@vger.kernel.org Subject: [PATCH 0/9] ACPI/i2c Enumerate several instances out of one fwnode Date: Sun, 20 May 2018 15:28:48 +0200 Message-Id: <20180520132857.8103-1-hdegoede@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Sun, 20 May 2018 13:29:03 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Sun, 20 May 2018 13:29:03 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hdegoede@redhat.com' RCPT:'' Sender: linux-i2c-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-i2c@vger.kernel.org Hi All, This series really consists of 2 series, patches 1-5 add support for interesting ACPI tables which describe multiple i2c chips in a single fwnode, sometimes multiple cases of the same chip on different addresses, sometimes a bunch of related chips. Andy Shevchenko has come up with the solution of adding a quirk based on the ACPI HID of the fwnode for these devices which makes the drivers/i2c/i2c-core-acpi.c code instantiate separate i2c_client devices for each I2cSerialBusV2 in the fwnode. I agree with him that this is the best (least ugly) solution for this. I've been testing this solution on a device if mine which needs a solution for this, the HP Pavilion x2 - 10-n000nd 2-in-1 has an acpi_device / fwnode with a HID of BSG1160 which describes 3 different i2c sensors in an accel / magneto / gyro sensor cluster on the tablet. This has let to some extra prep. patches and some fixes to Andy's patches. Patches 6-9 use the new functionality creating one i2c-client per I2cSerialBusV2 resource to make the sensor cluster on the HP X2 work and are posted as part of this series to show how this functionality can be used. Assuming everyone is ok with this series (I'm not expecting anyone to be really happy about the need for this), then I suggest that patches 1-6 get merged togther through either the ACPI or the i2c tree, I guess the i2c tree would make somewhat more sense, since most patches are there. Then once those are accepted patches 7-9 can be merged into the iio tree, there is no compile time dependency between the 2, so these can be merged separately. Note merging 7-9 before there is agreement that this is the right way to fix this is probably not a good idea. Regards, Hans