Hi Sebastian,
On Jun 10, 2013, at 10:40 AM, Sebastian Andrzej Siewior wrote:
> On 06/09/2013 06:41 PM, Lars-Peter Clausen wrote:
>> On 06/05/2013 06:24 PM, Sebastian Andrzej Siewior wrote:
>> [...]
>>> - return indio_dev->num_channels;
>>> + adc_dev->map = kcalloc(channels + 1, sizeof(struct iio_map),
>>> + GFP_KERNEL);
>>> + if (adc_dev->map == NULL)
>>> + goto err_free_chan;
>>> +
>>> + for (i = 0; i < 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;
>>> + }
>>
>> This is not the way the IIO map interface is supposed to be used and I doubt it
>> will actually work at all. The map either needs to be provided by board code
>> with the proper consumer device and channel name filled in or in your case
>> where you use devicetree you don't need to provide a map at all since this will
>> all be handled by the generic IIO devicetree bindings. So I'd just drop this patch.
>
> The channels are not described in the device tree. If so how would that
> be the case? Right now, I don't have any consumer. How do I test this
> easily if this is done correctly?
> If in doubt it will probably drop this until someone comes along who
> actually needs this.
>
Please don't remove this immediately. We need the hardcoded names until
we use DT bindings that get a handle of the IIO channels.
I realize this is a temporary solution though until the driver is reworked
to use DT properly.
>>
>> - Lars
>
> Sebastian
Regards
-- Pantelis
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
