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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 2 Dec 2015 11:20:11 +0100
From:	Marc Titinger <mtitinger@...libre.com>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	jic23@...nel.org, knaack.h@....de, lars@...afoo.de,
	pmeerw@...erw.net, linux-iio@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] iio: ina2xx: add support for TI INA2xx Power
 Monitors

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@...libre.com>
>> ---
>>   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.

Marc.


> Guenter
>

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