From patchwork Thu Aug 9 09:15:54 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: 10561155 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 2D62C1515 for ; Thu, 9 Aug 2018 09:16:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1BDDC29CFA for ; Thu, 9 Aug 2018 09:16:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0E30B2AB15; Thu, 9 Aug 2018 09:16:36 +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=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, 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 AF5B029CFA for ; Thu, 9 Aug 2018 09:16:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730333AbeHILj6 (ORCPT ); Thu, 9 Aug 2018 07:39:58 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:34646 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727786AbeHILj6 (ORCPT ); Thu, 9 Aug 2018 07:39:58 -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 8494D40241C3; Thu, 9 Aug 2018 09:16:01 +0000 (UTC) Received: from shalem.localdomain.com (unknown [10.36.118.2]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6504B2166BA2; Thu, 9 Aug 2018 09:15:59 +0000 (UTC) From: Hans de Goede To: "Rafael J . Wysocki" , Len Brown , Andy Shevchenko , Mika Westerberg , Darren Hart , Wolfram Sang Cc: Hans de Goede , Srinivas Pandruvada , linux-acpi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org, Heikki Krogerus , linux-i2c@vger.kernel.org Subject: [PATCH v5 0/4] i2c-multi-instantiate pseudo driver Date: Thu, 9 Aug 2018 11:15:54 +0200 Message-Id: <20180809091558.4317-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.7]); Thu, 09 Aug 2018 09:16:01 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Thu, 09 Aug 2018 09:16:01 +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: 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 Hi All, Here is v5 of my patch-series for dealing with multiple independent i2c devices being described in a single ACPI fwnode. Changes in v5: -s/no_clients/num_clients/ -Change patch 4 Subject prefix to platform/x86 Changes in v4: -Rewrite commit message of first patch as this is NOT a bug fix for acpi_is_indirect_io_slave() as I thought at first, it is still necessary as a preperation patch for the rest of the series -MAINTAINER and Kconfig entry fixes -Some minor coding style fixes Changes in v3: -Drop the patch adding the I2C_CLIENT_IGNORE_BUSY flag/hack -Add patches to make ACPI fwnode-s with affected acpi_ids get enumerated as platform device instead of i2c-client -Change the i2c-multi-instantiate driver to a platform driver Changes in v2: -Rebase on 4.18-rc2 Changes in v1: -Second attempt at dealing with this using a new design where a separate driver (which can be build as a module) is used to instantiate the i2c-clients instead of modifying the i2c core -Add an I2C_CLIENT_IGNORE_BUSY flag to make it possible for this driver to bind to the client instantiated for the first i2c resource and still create a new client using the i2c_client_id for the actual driver for the first resource, resulting in 2 clients at the same address (of which one is inactive) About merging this series, the platform-driver and ACPI patches can be merged independently of each other, they platform driver relies on the ACPI changes to gets its platform device instantiated, but if those changes are not in place yet, nothing bad happens. So if everyone is happy with this series I suggest that each part gets merged separately through the relevant trees. Regards, Hans