linux-kernel - Re: [PATCH] iio: adc: add exynos5 adc driver under iio framwork

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]

Message-ID: <51017B4D.7000105@metafoo.de>
Date:	Thu, 24 Jan 2013 19:19:57 +0100
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Doug Anderson <dianders@...omium.org>
CC:	Naveen Krishna Chatradhi <ch.naveen@...sung.com>,
	linux-iio@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-samsung-soc@...r.kernel.org, gregkh@...uxfoundation.org,
	Naveen Krishna <naveenkrishna.ch@...il.com>
Subject: Re: [PATCH] iio: adc: add exynos5 adc driver under iio framwork

On 01/24/2013 05:12 PM, Doug Anderson wrote:
> Lars,
> 
> Thank you for your comments / thoughts...
> 

Hi,

> 
> On Thu, Jan 24, 2013 at 1:54 AM, Lars-Peter Clausen <lars@...afoo.de> wrote:
>> adc: adc@...10000 {
>>
>>         #io-channel-cells = <1>;
>>         io-channel-output-names = "adc1", "adc2", ...;
>>
>>         ncp15wb473@0 {
>>                 compatible = "ntc,ncp15wb473";
>>                 ...
>>                 io-channels = <&adc 0>; // First ADC channel
> 
> I'm not an expert, but I think the typical way is:
> * No need to include a handle to &adc.  It's logically our parent.  In
> a similar way i2c devices don't specify their parent bus--they are
> just listed under it.
> * The "0" should be specified with reg = <0>

The relationship between the IIO sensor device and the consumer device is
not always a parent child relationship. In this case it makes sense to have
the ADC as the parent for the thermistors. But for other cases this may not
be true. E.g. take a touchscreen or power monitoring platform device which
uses the IIO device to do measurements.

> 
> To implement this I'd imagine that we'll need a new API call, right?
> In this case the thermistor driver won't know the name of the channel.
>  It can find the ADC (the struct device and probably other things) and
> knows a channel index.  Am I understanding properly?

This can be done by adding a new api call, but it would be best if both dt
and non-dt based consumers can use the same function. I outlined one
possible solution how this can be done in the previous mail to Naveen.

- Lars

--
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/