Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758744AbbLBQEx (ORCPT ); Wed, 2 Dec 2015 11:04:53 -0500 Received: from bh-25.webhostbox.net ([208.91.199.152]:59737 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750809AbbLBQEv (ORCPT ); Wed, 2 Dec 2015 11:04:51 -0500 Subject: Re: [PATCH v2 1/2] iio: ina2xx: add support for TI INA2xx Power Monitors To: Marc Titinger References: <1448884155-2546-1-git-send-email-mtitinger@baylibre.com> <1448884155-2546-2-git-send-email-mtitinger@baylibre.com> <20151202021429.GA19098@roeck-us.net> <565EC5DB.5040401@baylibre.com> Cc: jic23@kernel.org, knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org From: Guenter Roeck Message-ID: <565F169D.2050709@roeck-us.net> Date: Wed, 2 Dec 2015 08:04:45 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565EC5DB.5040401@baylibre.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: linux@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2717 Lines: 66 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 >>> --- >>> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/