On Sun, 2018-07-01 at 14:23 +0200, Hans de Goede wrote: > On systems with ACPI instantiated i2c-clients, normally there is 1 > fw_node > per i2c-device and that fw-node contains 1 I2cSerialBus resource for > that 1 > i2c-device. > > But in some rare cases the manufacturer has decided to describe > multiple > i2c-devices in a single ACPI fwnode with multiple I2cSerialBus > resources. > > An earlier attempt to fix this in the i2c-core resulted in a lot of > extra > code to support this corner-case. > > This commitintroduces a new i2c-multi-instantiate driver which fixes > this > in a different way. This new driver can be built as a module which > will > only loaded on affected systems. > > This driver will instantiate a new i2c-client per I2cSerialBus > resource, > using the driver_data from the acpi_device_id it is binding to to tell > it > which chip-type (and optional irq-resource) to use when instantiating. > > Note this means that we will be instantiating 2 i2c_client-s for the > first > I2cSerialBus resource, this is not pretty, but since the multi- > instantiate > driver does exactly 0 i2c-transfers this is not a problem. Hmm... I was thinking about somelike MFD for I2C devices where we have a real tree, thus, we instantiate parent device (that has nothing to do with I2C per se) and per each I2cSerialBus resource we would instantiate its children. I think it would be slightly cleaner approach (no need to care about parent device being I2C client). I dunno if it's possible to implement in a tiny way, though. -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Intel Finland Oy
