Re: [PATCH v2 1/2] iio: ina2xx: add support for TI INA2xx Power Monitors

[Guenter Roeck]

On 12/02/2015 02:20 AM, Marc Titinger wrote:
> On 02/12/2015 03:14, Guenter Roeck wrote:
> > On Mon, Nov 30, 2015 at 12:49:14PM +0100, Marc Titinger wrote:
> > > in SOFTWARE buffer mode, a kthread will capture the active scan_elements
> > > into a kfifo, then compute the remaining time until the next capture tick
> > > and do an active wait (udelay).
> > >
> > > This will produce a stream of up to fours channels plus a 64bits
> > > timestamps (ns).
> > >
> > > Tested with ina226, on BeagleBoneBlack.
> > >
> > > Datasheet: http://www.ti.com/lit/gpn/ina226
> > >
> > > Signed-off-by: Marc Titinger <mtitinger@xxxxxxxxxxxx>
> > > ---
> > >   drivers/iio/adc/Kconfig      |   9 +
> > >   drivers/iio/adc/Makefile     |   1 +
> > >   drivers/iio/adc/ina2xx-iio.c | 678 +++++++++++++++++++++++++++++++++++++++++++
> > >   3 files changed, 688 insertions(+)
> > >   create mode 100644 drivers/iio/adc/ina2xx-iio.c
> > > +
> > [ ... ]
> > > +
> > > +static const struct i2c_device_id ina2xx_id[] = {
> > > +    {"ina219", ina219},
> > > +    {"ina220", ina219},
> > > +    {"ina226", ina226},
> > > +    {"ina230", ina226},
> > > +    {"ina231", ina226},
> > > +    {}
> > > +};
> >
> > I wonder what is going to happen if both this driver and the hwmon
> > driver for the same chips are configured in a system which supports
> > devicetree (or any system, really). Unless I am missing something,
> > the result will be that both drivers will try to instantiate, and
> > one will fail with -EBUSY. Or the instantiated driver is more or less
> > random, depending on which one happens to be loaded. Not a good
> > situation to be in.
>
> I agree, we should put a mutual exclusion in Kconfig, plus maybe a cross-reference in the help section.
>
> > For the time being, it might make sense to add cross-dependencies
> > in Kconfig to only permit one of the two drivers to be configured.
> >
> > Ultimately we may need a better solution for the iio-hwmon bridge,
> > one that makes the underlying driver transparent in both devicetree
> > properties and user space ABI. No idea how to do that, though.
>
> IDK if ina2xx is a special case or if this matter of dual driver stacks for the same chip already occurred and requires specific plumbing. Making the user aware of the mutual of the exclusion sounds fine with me.
htu21. We'll drop that driver from hwmon with the 4.5 kernel.
We could just drop ina2xx as well, but it is more widely used
and referenced from dts files. The ABI changes, so I am not sure
if we can just do that.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/