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: <510104BD.2020500@metafoo.de>
Date:	Thu, 24 Jan 2013 10:54:05 +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 01:42 AM, Doug Anderson wrote:
> Lars,
> 
> On Wed, Jan 23, 2013 at 4:52 AM, Lars-Peter Clausen <lars@...afoo.de> wrote:
>>> Few doubts regarding the mappings and child device handling.
>>> Kindly, suggest me better methods.
>>
>> The patch looks mostly good now. As for the mappings, the problem is that we
>> currently do not have any device tree bindings for IIO. So a proper solution
>> would be to add dt bindings for IIO.
> 
> Can you explain more how you think this would work?  It seems like
> just having child nodes as platform drivers would be OK (to me) and
> having them instantiated with of_platform_populate() seems reasonable.
> 
> ...but the one thing that is missing is a way for children to get
> access to the channel properly.
> 
> The children have access to the ADC "struct device" (it is their
> parent device) and have a channel number (their "reg" field), but
> there is no API call to map this to a "struct iio_channel".  Is that
> all that's needed in this case?  ...or are you envisioning something
> more?

Well, the idea is that the consumer doesn't need to know the channel number.
That's what the mapping takes care of. It basically creates a consumer alias
for the channel. When requesting the channel the consumer always uses the
same name.

iio_channel_get(dev_name(&pdev->dev), "voltage");

And the mapping contains an entry which maps the tuple of device name and
channel name to a real IIO channel which as been registered by a IIO device.
Note if there is only one channel you can also just use NULL for the channel
name. This is similar to how clocks are managed with the clk framework.

Now for the dt bindings I think we should stick to something similar to what
the clk framework does.

E.g.

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
		io-channel-names = "voltage";
	};

	ncp15wb473@0 {
		compatible = "ntc,ncp15wb473";
		...
		io-channels = <&adc 1>; // Second ADC channel
		io-channel-names = "voltage";
	}
};

io-channel-output-names and io-channel-names can be optional. In the case
where there is only one channel it's not really necessary to use
io-channel-names.

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