From: "jonathan.cameron@gmail.com" <jic23@cam.ac.uk>
To: "Hennerich, Michael" <Michael.Hennerich@analog.com>,
"Hennerich, Michael" <Michael.Hennerich@analog.com>
Cc: "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"Device-drivers-devel@blackfin.uclinux.org"
<Device-drivers-devel@blackfin.uclinux.org>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"Device-drivers-devel@blackfin.uclinux.org"
<Device-drivers-devel@blackfin.uclinux.org>
Subject: RE: const members of struct iio_chan_spec?
Date: Sat, 02 Jul 2011 09:35:37 +0100 [thread overview]
Message-ID: <a56f2e32-dbfa-494b-b4e7-db51af230eed@email.android.com> (raw)
In-Reply-To: <544AC56F16B56944AEC3BD4E3D5917713EA0BC5BBF@LIMKCMBX1.ad.analog.com>
"Hennerich, Michael" <Michael.Hennerich@analog.com> wrote:
>Jonathan Cameron wrote on 2011-06-30:
>> On 06/30/11 15:04, Hennerich, Michael wrote:
>>> Hi Jonathan,
>>>
>>> static int ad7280_channel_init(struct ad7280_state *st) {
>>> int dev, ch, cnt;
>>>
>>> st->channels = kzalloc(sizeof(*st->channels) *
>>> ((st->slave_num + 1) * 12 + 1), GFP_KERNEL);
>>> if (st->channels == NULL)
>>> return -ENOMEM;
>>> for (dev = 0, cnt = 0; dev <= st->slave_num; dev++)
>>> for (ch = AD7280A_CELL_VOLTAGE_1; ch <=
>> AD7280A_AUX_ADC_6; ch++, cnt++) {
>>> st->channels[cnt].type = IIO_IN;
>>> st->channels[cnt].indexed = 1;
>>> st->channels[cnt].extend_name = NULL;
>>> st->channels[cnt].channel = cnt;
>>> st->channels[cnt].info_mask = (1 <<
>>> IIO_CHAN_INFO_SCALE_SHARED);
>>> st->channels[cnt].address = dev << 8 | ch;
>>> st->channels[cnt].scan_index = cnt;
>>> st->channels[cnt].scan_type.sign = 'u';
>>> st->channels[cnt].scan_type.realbits = 12;
>>> st->channels[cnt].scan_type.storagebits =
>32;
>>> st->channels[cnt].scan_type.shift = 0;
>>> }
>>> return cnt;
>>> }
>>>
>>> Trying to dynamically allocate and populate a channel spec.
>>> However some members are declared const. Do they really need to be
>> const?
>> hmm.. technically no, although a large point in the purpose of moving
>> to chan spec based registration was to allow all this stuff to be
>> constant static arrays. I guess there is no particular harm in
>taking
>> them away from const though. The functions should all assume they
>are
>> constant, but they don't really need to be before any are called.
>>
>> As to whether it is the right thing to do here, I guess it depends on
>> how large slave num can be. Google tells me the answer is really
>quite
>> large (50)! Hence I'm convinced you have a very good reason.
>
>Well that's true for the AD7280. It supports up to 50 chained devices
>each handling
>6 cells. However this drivers targets the AD7280A which only supports 8
>chain devices.
>
>Still a good reason?
Still a lot of channels so I think yes.
>
>> I'll push back on any drivers doing dynamic just to handle small
>> numbers of channels with variants, but here I'm convinced you have a
>> very good reason.
>>
>> Please send the patch to make these elements non constant with your
>> driver (as that will clearly provide justification)
>>
>> I'll admit I never conceived of anyone having the ability to chain
>> this many sensors.
>> For smaller chained devices I'd just advise doing them as a big
>static
>> array then setting num_channels appropriately. (glad you brought this
>> up as it just made me realise my bug in the previous set I sent out!)
>>
>> Jonathan
>>
>>>
>>> drivers/staging/iio/adc/ad7280a_core.c: In function
>>> 'ad7280_channel_init': drivers/staging/iio/adc/ad7280a_core.c:231:
>>> error: assignment of read-only member 'info_mask'
>>>
>>> Regards,
>>> Michael
>>>
>>> ------------------------------------------------------------------
>>> ********* Analog Devices GmbH
>>> ** *****
>>> ** ** Wilhelm-Wagenfeld-Strasse 6
>>> ** ***** D-80807 Munich
>>> ********* Germany
>>> Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB
>>> 40368;
>>> Geschaeftsfuehrer: Dr.Carsten Suckrow, Thomas Wessel, William A.
>>> Martin, Margaret Seif
>>>
>>>
>>>
>>
>
>Greetings,
>Michael
>
>--
>Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
>Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
>Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
>Margaret Seif
>
>
>--
>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
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
prev parent reply other threads:[~2011-07-02 8:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-30 14:04 const members of struct iio_chan_spec? Hennerich, Michael
2011-06-30 14:58 ` Jonathan Cameron
2011-07-01 19:27 ` Hennerich, Michael
2011-07-02 8:35 ` jonathan.cameron@gmail.com [this message]
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=a56f2e32-dbfa-494b-b4e7-db51af230eed@email.android.com \
--to=jic23@cam.ac.uk \
--cc=Device-drivers-devel@blackfin.uclinux.org \
--cc=Michael.Hennerich@analog.com \
--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