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 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).