On Wed, Aug 01, 2018 at 10:43:14AM +0200, Hans de Goede wrote:
> Hi,
>
> On 01-08-18 10:13, Mika Westerberg wrote:
> > Hi,
> >
> > On Sun, Jul 01, 2018 at 02:23:43PM +0200, Hans de Goede wrote:
> > > +static const struct acpi_device_id i2c_multi_inst_acpi_ids[] = {
> > > + { "BSG1160", (unsigned long)bsg1160_data },
> > > + { }
> > > +};
> >
> > This seems to affect only these combo devices with accelerometer and
> > some other sensor in a single package or so. I wonder if it makes more
> > sense to handle this in a driver for BSG1160 and leave I2C/ACPI core
> > untouched?
>
> That would require injecting a whole lot of platform specific code
> into the platform agnostic drivers/iio/accel/bmc150-accel-i2c.c
> driver, something which I've tried before and has pretty much
> been nacked.
>
> Heikki has another use-case with a single ACPI fwnode describing
> multiple independent i2c clients.
>
> The existing drivers/platform/x86/intel_cht_int33fe.c is yet another
> case of this, except that in that case we don't care about the
> i2c_client described by the 1st ACPI i2c resource, so it just binds
> directly to that i2c-client as it is otherwise unused.
I see. Thanks for the explanation.
> IOW there is a pattern here and I would like to come up with
> a fix for the pattern, rather then adding ugly hacks to various
> otherwise platform agnostic drivers.
I agree.
