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-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html