Fifth set of fixes for IIO in the 3.16 cycle.

One nasty one that has been around a long time and a couple of non compliant
 ABI fixes.
 
 * The demux code used to split out desired channels for devices that only
   support reading sets of channels at one time had a bug where it was
   building it's conversion tables against the wrong bitmap resulting in
   it never actually demuxing anything.  This is an old bug, but will be
   effecting an increasing number of drivers as it is often used to avoid
   some fiddly code in the individual drivers.
 
 * bma180 and mma8452 weren't obeying the ABI wrt to units for acceleration.
   Were in G rather than m/s^2. A little input check was missing from bma180
   that might lead to acceptance of incorrect values.  This last one is minor
   but might lead to incorrect userspace code working and problems in the
   future.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABAgAGBQJTzA9MAAoJEFSFNJnE9BaI+kgP/RuIbx7zMGEZC0G1o3suKcgk
 2N4SyUhrnz0MvX7HyckpLlAFr5YU1l5sRvBi+RW9NRtAjbZcRH7c3uc8AqptWIuF
 DuqNCM/WLSOEsFWV8kRzClKcTBwz1O59cAtR1jNz7r6CsmehPDQljhRW/wg6+v5h
 MvYr4zvgsVbaT+x6/iGnJUIMnEcsPiwRfbmyXkPa9uvv6KFixiG3NUEz1maeRJ/T
 a9Xpvl/T4Bl+0dhS0kIMYC4tInUdfG4HygJeUTLxVOsDkrpHKn2x23Peco1UpAUd
 4k1cNDUzUzQHYH8kKi+j8N7MQdLvVS2NbJ4lwcR6zME57ocvXYZ8nVrjRWWonnON
 BkYRdmXQrDUes7d1A+0s3x8LDJf0jCHvBqqkmLqMe7F1BiOhQfbV5Mm/nrxHIWBJ
 ssW0V5t9jxZDdt4IBEOA8DaqSxNeyqdHJPMMysvBxfvOtxmCVlU2QEwW8Sy3J54k
 K1YHqfoefDbZpPGVT78B7eBVr7PgE5H4Btuz6hulSo1f5w13l1eVcRO7PHBCCKQQ
 /9pSLaGQekTuZSFQVHPJoqlFmHh9r70pkvzPezEdqhURdYgR+vWGYPCPJ63X6Y9h
 7unl5tvVLU0vvuEaUVo4BemnpfniNuEVsASp1KIjTF6fpM3MjgVmOOPY0pfLEgxa
 86ztLa8DGsO1oz0HgGwJ
 =Q+s/
 -----END PGP SIGNATURE-----

Merge tag 'iio-fixes-for-3.16e' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus

Jonathan writes:

Fifth set of fixes for IIO in the 3.16 cycle.

One nasty one that has been around a long time and a couple of non compliant
ABI fixes.

* The demux code used to split out desired channels for devices that only
  support reading sets of channels at one time had a bug where it was
  building it's conversion tables against the wrong bitmap resulting in
  it never actually demuxing anything.  This is an old bug, but will be
  effecting an increasing number of drivers as it is often used to avoid
  some fiddly code in the individual drivers.

* bma180 and mma8452 weren't obeying the ABI wrt to units for acceleration.
  Were in G rather than m/s^2. A little input check was missing from bma180
  that might lead to acceptance of incorrect values.  This last one is minor
  but might lead to incorrect userspace code working and problems in the
  future.
This commit is contained in:
Greg Kroah-Hartman 2014-07-21 10:58:51 -07:00
commit 1f31c3f0e1
2 changed files with 6 additions and 4 deletions

View File

@ -68,13 +68,13 @@
/* Defaults values */
#define BMA180_DEF_PMODE 0
#define BMA180_DEF_BW 20
#define BMA180_DEF_SCALE 250
#define BMA180_DEF_SCALE 2452
/* Available values for sysfs */
#define BMA180_FLP_FREQ_AVAILABLE \
"10 20 40 75 150 300"
#define BMA180_SCALE_AVAILABLE \
"0.000130 0.000190 0.000250 0.000380 0.000500 0.000990 0.001980"
"0.001275 0.001863 0.002452 0.003727 0.004903 0.009709 0.019417"
struct bma180_data {
struct i2c_client *client;
@ -94,7 +94,7 @@ enum bma180_axis {
};
static int bw_table[] = { 10, 20, 40, 75, 150, 300 }; /* Hz */
static int scale_table[] = { 130, 190, 250, 380, 500, 990, 1980 };
static int scale_table[] = { 1275, 1863, 2452, 3727, 4903, 9709, 19417 };
static int bma180_get_acc_reg(struct bma180_data *data, enum bma180_axis axis)
{
@ -376,6 +376,8 @@ static int bma180_write_raw(struct iio_dev *indio_dev,
mutex_unlock(&data->mutex);
return ret;
case IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY:
if (val2)
return -EINVAL;
mutex_lock(&data->mutex);
ret = bma180_set_bw(data, val);
mutex_unlock(&data->mutex);

View File

@ -966,7 +966,7 @@ static int iio_buffer_update_demux(struct iio_dev *indio_dev,
/* Now we have the two masks, work from least sig and build up sizes */
for_each_set_bit(out_ind,
indio_dev->active_scan_mask,
buffer->scan_mask,
indio_dev->masklength) {
in_ind = find_next_bit(indio_dev->active_scan_mask,
indio_dev->masklength,