On 10/19/2011 11:04 PM, Dan Carpenter wrote:
> On Wed, Oct 19, 2011 at 05:47:50PM +0200, Lars-Peter Clausen wrote:
>> @@ -225,6 +226,7 @@ static int ad5791_read_raw(struct iio_dev *indio_dev,
>> long m)
>> {
>> struct ad5791_state *st = iio_priv(indio_dev);
>> + u64 val64;
>> int ret;
>>
>> switch (m) {
>> @@ -234,12 +236,16 @@ static int ad5791_read_raw(struct iio_dev *indio_dev,
>> return ret;
>> *val &= AD5791_DAC_MASK;
>> *val >>= chan->scan_type.shift;
>> - *val -= (1 << (chan->scan_type.realbits - 1));
>> return IIO_VAL_INT;
>> case (1 << IIO_CHAN_INFO_SCALE_SHARED):
>> *val = 0;
>> *val2 = (st->vref_mv * 1000) >> chan->scan_type.realbits;
>> return IIO_VAL_INT_PLUS_MICRO;
>> + case (1 << IIO_CHAN_INFO_OFFSET_SHARED):
>> + val64 = (((u64)st->vref_neg_mv) << chan->scan_type.realbits);
>> + do_div(val64, st->vref_mv);
>> + *val = -val64;
>> + return IIO_VAL_INT;
>
> Why does iio use switch over a bitfield? If the values are mutually
> exclusive then why not just use an enum?
>
I wondered the very same and couldn't find a good explanation. I wanted to
write a small RFC today converting the core and maybe 2-3 drivers to use the
unshifted variants to see what Jonathan thinks about it.
> Hm... "m" stands for mask and it gets created using the
> IIO_UNMOD_EVENT_CODE() macro or sometimes it's just one bit at a
> time copied from &chan->info_mask... Odd.
>
IIO_UNMOD_EVENT_CODE is only used for events which use a different callback
function, so for the read_raw/write_raw callbacks we currently only ever
pass one channel info type at a time.
- Lars
_______________________________________________
devel mailing list
[email protected]
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
