From: Jonathan Cameron <jic23@cam.ac.uk>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: linux-iio@vger.kernel.org
Subject: Re: [PATCH] staging:iio:adc: Add AD7265/AD7266 support
Date: Fri, 22 Jun 2012 08:32:20 +0100 [thread overview]
Message-ID: <4FE41F84.7060809@cam.ac.uk> (raw)
In-Reply-To: <4FE340B7.8060809@metafoo.de>
On 6/21/2012 4:41 PM, Lars-Peter Clausen wrote:
> 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:
I'd still be happier with that than the memcpy. That implies that stuff
in these is not const, whereas it is for a given setup.
>
> 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;
> }
>
Then use an array (little fiddly)
struct chan_set {
struct iio_chan_spec *chans;
int num_chans;
int *scan_masks;
};
//index 0 is fixed_addr,
//index 1 is (st->mode == AD7266_MODE_SINGLE_ENDED)
//index 2 is (st->range == AD7266_RANGE_VREF)
static const
struct chan_set bob[2][2][2]
= {{{{ad7266_channels_u, ARRAY_SIZE(ad7266_channels_u),
ad7266_available_scan_masks},
{ad7266_channels_s, ARRAY_SIZE(ad7266_channels_s),
ad7266_available_scan_masks}},
{{ad7266_channels_diff, ARRAY_SIZE(ad7266_channels_diff),
ad7266_available_scan_masks_diff},
{ad7266_channels_diff, ARRAY_SIZE(ad7266_channels_diff),
ad7266_available_scan_masks_diff}},
{{{ad7266_channels_u_fixed, ARRAY_SIZE(ad7266_channels_u_fixed),
ad7266_available_scan_masks_fixed}},
{ad7266_channels_s_fixed, ARRAY_SIZE(ad7266_channels_s_fixed),
ad7266_available_scan_masks_fixed}},
{{ad7266_channels_channels_diff_fixed,
ARRAY_SIZE(ad7266_channels_diff_fixed), ad7266_available_scan_masks_fixed},
{ad7266_channels_channels_diff_fixed,
ARRAY_SIZE(ad7266_channels_diff_fixed),
ad7266_available_scan_masks_fixed}}}};
channel_template = bob[fixed_addr][st->mode ==
AD7266_MODE_SINGLE_ENDED][st->range == AD7266_RANGE_VREF].chans;
etc.
Hmm. not all that clean here, but does make it explicit that we are
selecting from amongst a set of constant data.
>
>>> + 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.
It doesn't improved readability, but it also doesn't significantly worsen
it. Perhaps shortening the naming might be an idea.
ad7266_av_scan_masks_fixed
seems detailed enough to me!
>
>>> + 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2012-06-22 7:32 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
2012-06-22 7:32 ` Jonathan Cameron [this message]
-- 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=4FE41F84.7060809@cam.ac.uk \
--to=jic23@cam.ac.uk \
--cc=lars@metafoo.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.