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: <50916FA2.2000802@metafoo.de>
Date:	Wed, 31 Oct 2012 19:36:18 +0100
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Pantelis Antoniou <panto@...oniou-consulting.com>
CC:	Jonathan Cameron <jic23@....ac.uk>,
	"Patil, Rachna" <rachna@...com>, linux-iio@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Koen Kooi <koen@...inion.thruhere.net>,
	Matt Porter <mporter@...com>, Russ Dill <Russ.Dill@...com>,
	linux-omap@...r.kernel.org
Subject: Re: [PATCH 1/3] ti_adc: Update with IIO map interface

On 10/31/2012 07:12 PM, Pantelis Antoniou wrote:
> 
> On Oct 31, 2012, at 8:07 PM, Lars-Peter Clausen wrote:
> 
>> On 10/31/2012 06:55 PM, Pantelis Antoniou wrote:
>>> [...]
>>>>> 	}
>>>>>
>>>>> 	indio_dev->channels = chan_array;
>>>>> +	indio_dev->num_channels = channels;
>>>>> +
>>>>> +	size = (channels + 1) * sizeof(struct iio_map);
>>>>> +	adc_dev->map = kzalloc(size, GFP_KERNEL);
>>>>> +	if (adc_dev->map == NULL) {
>>>>> +		kfree(chan_array);
>>>>> +		return -ENOMEM;
>>>>> +	}
>>>>> +
>>>>> +	for (i = 0; i < indio_dev->num_channels; i++) {
>>>>> +		adc_dev->map[i].adc_channel_label = chan_array[i].datasheet_name;
>>>>> +		adc_dev->map[i].consumer_dev_name = "any";
>>>>> +		adc_dev->map[i].consumer_channel = chan_array[i].datasheet_name;
>>>>> +	}
>>>>> +	adc_dev->map[i].adc_channel_label = NULL;
>>>>> +	adc_dev->map[i].consumer_dev_name = NULL;
>>>>> +	adc_dev->map[i].consumer_channel = NULL;
>>>>
>>>> The map should be passed in via platform data or similar. All the fields of
>>>> the map depend on the specific user, so you can't use a generic map. In fact
>>>> if we were able to use a generic map, we wouldn't need a map at all.
>>>
>>> There's no platform data in the board I'm using. It's board-generic using
>>> device tree only.
>>
>> That's the 'or similar' ;) Unfortunately we do not have a device tree
>> binding for IIO yet. But I think we should aim at a interface similar like
>> we have in other subsystems like the clk, regulator or dma framework.
>>
>> - Lars
> 
> So in the meantime no-one can use IIO ADC in any OF only platform.

Yes, nobody can use it until somebody implements it. So far nobody needed
it, so that's why it hasn't been implemented yet. The whole in kernel
consumer API for IIO is still very young and only a very few drivers support
it yet.

> 
> In the meantime, this is pretty reasonable IMO. This is only for a specific 
> board with known channel mappings.

Unfortunately it is not. It is adding a device specific hack to a generic
driver and it is also completely misusing the API.

> 
> I'm not out to fix IIO, I'm out to fix a single board.
> 

It's not about fixing IIO, it's about extending IIO to be able to serve your
needs. See, the issue is if everybody would work around the lack of DT
bindings we'll never have DT bindings for IIO, so the right thing to do is
to implement them instead of working around the lack of.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ