linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: "Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Darren Hart <dvhart@infradead.org>,
	Wolfram Sang <wsa@the-dreams.de>
Cc: Hans de Goede <hdegoede@redhat.com>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	linux-acpi@vger.kernel.org, platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	linux-i2c@vger.kernel.org
Subject: [PATCH v5 0/4] i2c-multi-instantiate pseudo driver
Date: Thu,  9 Aug 2018 11:15:54 +0200	[thread overview]
Message-ID: <20180809091558.4317-1-hdegoede@redhat.com> (raw)

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

             reply	other threads:[~2018-08-09  9:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-09  9:15 Hans de Goede [this message]
2018-08-09  9:15 ` [PATCH v5 1/4] ACPI / scan: Initialize status to ACPI_STA_DEFAULT Hans de Goede
2018-08-09  9:35   ` Rafael J. Wysocki
2018-08-09  9:39     ` Hans de Goede
2018-08-09  9:51       ` Andy Shevchenko
2018-08-09  9:58         ` Hans de Goede
2018-08-09  9:59           ` Rafael J. Wysocki
2018-08-09 11:36             ` Hans de Goede
2018-08-09 11:48               ` Andy Shevchenko
2018-08-09 10:00     ` Wolfram Sang
2018-08-09  9:15 ` [PATCH v5 2/4] ACPI / scan: Create platform device for fwnodes with multiple i2c devices Hans de Goede
2018-08-09 10:08   ` Andy Shevchenko
2018-08-09  9:15 ` [PATCH v5 3/4] ACPI / x86-utils: Remove status workaround from acpi_device_always_present() Hans de Goede
2018-08-09 10:08   ` Andy Shevchenko
2018-08-09  9:15 ` [PATCH v5 4/4] platform/x86: Add ACPI i2c-multi-instantiate pseudo driver Hans de Goede
2018-08-09  9:59   ` Wolfram Sang
2018-08-09 10:12   ` Andy Shevchenko
2018-08-09 11:09   ` Heikki Krogerus
2018-08-09 11:30     ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180809091558.4317-1-hdegoede@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dvhart@infradead.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=wsa@the-dreams.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).