On 05/21/2018 03:13 PM, Andy Shevchenko wrote: > On Mon, 2018-05-21 at 14:34 +0200, Hans de Goede wrote: >> On 21-05-18 11:19, Andy Shevchenko wrote: > >>>> 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. >>> >>> I suppose it's better to do an "MFD" type of IIO driver for that >>> chip. >>> Check, for example, drivers/iio/imu/bmi160/bmi160_core.c >> >> That seems to be a single chip listening on a single i2c address / spi >> chip-select. > > Ooops, wrong reference. > >> In the BSG1160 case the 3 sensors are listening on 3 different i2c >> addresses. > > There is a Bosh magnetometer + accelerometer chip (BMC150). We have just > two independent drivers for them. Luckily for ACPI they have different > IDs (on the platforms where it's used like that). > > So, my series targeting the series of same IPs under one device... > >> We could use the drivers/mfd framework, but the we get platform >> devices >> and we would need to patch all 3 existing drivers to support platform >> bindings and get a regmap from there (converting them to regmap where >> necessary). > > ...and in your case MFD sounds better. Though why do you need to have a > common regmap? I'm not convinced MFD is the right place. You wouldn't really utilize anything of the MFD subsystem. And in a sense it is not a multi-function device. It's just multiple devices that are described by the same firmware description table entry. But I think some kind of board driver might be useful here that translates the ACPI description into something more reasonable. I.e. bind to the ACPI ID and then instantiate the 3 child I2C devices on the same bus. Those do not have to be platform drivers and you do not have to use regmap. The current approach adds board specific workarounds to each of the device drivers. It might be easier to have that managed in a central place. The problem with ACPI is that the description in the tables is often for vendor device drivers that ship together with the hardware. If you want to use the same tables with upstream drivers some kind of translation table might be required.
