From: Lars-Peter Clausen <lars@metafoo.de>
To: Jonathan Cameron <jic23@cam.ac.uk>
Cc: linux-iio@vger.kernel.org
Subject: Re: [PATCH] staging:iio:adc: Add AD7265/AD7266 support
Date: Thu, 21 Jun 2012 17:41:43 +0200 [thread overview]
Message-ID: <4FE340B7.8060809@metafoo.de> (raw)
In-Reply-To: <4FE32CDA.7040001@cam.ac.uk>
On 06/21/2012 04:16 PM, Jonathan Cameron wrote:
> On 6/18/2012 6:14 PM, Lars-Peter Clausen wrote:
>> This patch adds support for the Analog Devices AD7265 and AD7266
>> Analog-to-Digital converters.
> Mostly fine. I'm unconvinced the complexity around the
> channel array creation is necessary. Might save a little on
> data but loses in readability!
>
> Jonathan
>>
>> [...]
>> +static int __devinit ad7266_alloc_channels(struct iio_dev *indio_dev)
>> +{
>> + struct ad7266_state *st = iio_priv(indio_dev);
>> + const struct iio_chan_spec *channel_template;
>> + struct iio_chan_spec *channels;
>> + unsigned long *scan_masks;
>> + unsigned int num_channels;
>> +
>
> I'm unclear on why all this complexity is necessary.
> We aren't dealing with huge numbers of channels here.
> Why can't we just have a couple of const static arrays and
> pick between them? This is just nasty to read for a
> fairly small gain.
>
Hm, I doubt that the code looks less messy if we do it that way. It would
add another level of indention and we'd have the same code twice once for
the fixed case and once for the non-fixed case. It would more or less look
like this:
if (!st->fixed_addr) {
if (st->mode == AD7266_MODE_SINGLE_ENDED) {
if (st->range == AD7266_RANGE_VREF) {
channel_template = ad7266_channels_u;
num_channels = ARRAY_SIZE(ad7266_channels_u);
} else {
channel_template = ad7266_channels_s;
num_channels = ARRAY_SIZE(ad7266_channels_s);
}
scan_masks = ad7266_available_scan_masks;
} else {
channel_template = ad7266_channels_diff;
num_channels = ARRAY_SIZE(ad7266_channels_diff);
scan_masks = ad7266_available_scan_masks_diff;
}
else {
if (st->mode == AD7266_MODE_SINGLE_ENDED) {
if (st->range == AD7266_RANGE_VREF) {
channel_template = ad7266_channels_u_fixed;
num_channels = ARRAY_SIZE(ad7266_channels_u_fixed);
} else {
channel_template = ad7266_channels_s_fixed;
num_channels = ARRAY_SIZE(ad7266_channels_s_fixed);
}
} else {
channel_template = ad7266_channels_diff_fixed;
num_channels = ARRAY_SIZE(ad7266_channels_diff_fixed);
}
indio_dev->available_scan_masks = ad7266_available_scan_masks_fixed;
}
>> + if (st->mode == AD7266_MODE_SINGLE_ENDED) {
>> + if (st->range == AD7266_RANGE_VREF) {
>> + channel_template = ad7266_channels_u;
>> + num_channels = ARRAY_SIZE(ad7266_channels_u);
>> + } else {
>> + channel_template = ad7266_channels_s;
>> + num_channels = ARRAY_SIZE(ad7266_channels_s);
>> + }
>> + scan_masks = ad7266_available_scan_masks;
>> + } else {
>> + channel_template = ad7266_channels_diff;
>> + num_channels = ARRAY_SIZE(ad7266_channels_diff);
>> + scan_masks = ad7266_available_scan_masks_diff;
>> + }
>> +
>> + if (!st->fixed_addr) {
>> + indio_dev->available_scan_masks = scan_masks;
>> + indio_dev->masklength = indio_dev->num_channels;
>> + } else {
> check patch is moaning at me about this next line being two long.
But breaking the line here certainly does not improve readability. The 80
chars is more of a soft limit.
>> + indio_dev->available_scan_masks = ad7266_available_scan_masks_fixed;
>> + indio_dev->masklength = 2;
>> + num_channels = 2;
>> + }
>> +
>> + channels = kcalloc(num_channels + 1, sizeof(*channels),
>> + GFP_KERNEL);
>> + if (!channels)
>> + return -ENOMEM;
>> +
>> + memcpy(channels, channel_template, num_channels * sizeof(*channels));
>> + channels[num_channels] =
>> + (struct iio_chan_spec)IIO_CHAN_SOFT_TIMESTAMP(num_channels);
>> +
>> + indio_dev->num_channels = num_channels + 1;
>> + indio_dev->channels = channels;
>> +
>> + return 0;
>> +}
>> +
[...]
Thanks,
- Lars
next prev parent reply other threads:[~2012-06-21 15:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-18 17:14 [PATCH] staging:iio:adc: Add AD7265/AD7266 support Lars-Peter Clausen
2012-06-21 14:16 ` Jonathan Cameron
2012-06-21 15:41 ` Lars-Peter Clausen [this message]
2012-06-22 7:32 ` Jonathan Cameron
-- strict thread matches above, loose matches on Subject: below --
2011-12-08 8:44 Lars-Peter Clausen
2011-12-10 13:59 ` Jonathan Cameron
2011-12-11 16:54 ` Lars-Peter Clausen
2011-12-12 21:02 ` Jonathan Cameron
2011-12-12 21:17 ` Lars-Peter Clausen
2011-12-14 20:06 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FE340B7.8060809@metafoo.de \
--to=lars@metafoo.de \
--cc=jic23@cam.ac.uk \
--cc=linux-iio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).