linux-stable.git/drivers/iio, branch v4.9.3

iio: accel: st_accel: fix LIS3LV02 reading and scaling

2017-01-12T10:39:21+00:00

commit 65e4345c8ef8811bbb4860fe5f2df10646b7f2e1 upstream.

The LIS3LV02 has a special bit that need to be set to get the
read values left aligned. Before this patch we get gibberish
like this:

iio_generic_buffer -a -c10 -n lis3lv02dl_accel
(...)
0.000000 -0.010042 -0.642688 19155832931907
0.000000 -0.010042 -0.642688 19155858751073

Which is because we read a raw value for 1g as 64 which is
the nominal 1024 for 1g shifted 4 bits to the left by being
right-aligned rather than left aligned.

Since all other sensors are left aligned, add some code to
set the special DAS (data alignment setting) bit to 1 so that
the right value is now read like this:

iio_generic_buffer -a -c10 -n lis3lv02dl_accel
(...)
0.000000 -0.147095 -10.120135 24761614364956
-0.029419 -0.176514 -10.120135 24761631624540

The scaling was weird as well: we have a gain of 1000 for 1g
and 3000 for 6g. I don't even remember how I came up with the
old values but they are wrong.

Fixes: 3acddf74f807 ("iio: st-sensors: add support for lis3lv02d accelerometer")
Cc: Lorenzo Bianconi 
Cc: Giuseppe Barba 
Cc: Denis Ciocca 
Signed-off-by: Linus Walleij 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: bmi160: Fix time needed to sleep after command execution

2017-01-12T10:39:05+00:00

commit 01d1f7a99e457952aa51849ed7c1cc4ced7bca4b upstream.

Datasheet specifies typical and maximum execution times for which CMD
register is occupied after previous command execution. We took these
values as minimum and maximum time for usleep_range() call before making
a new command execution.

To be sure, that the CMD register is no longer occupied we need to wait
*at least* the maximum time specified by datasheet.

Signed-off-by: Marcin Niestroj 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: max44000: correct value in illuminance_integration_time_available

2017-01-12T10:39:04+00:00

commit b4e8a0eb718749455601fa7b283febc42cca8957 upstream.

According to the datasheet, the shortest available integration time for
ALS ADC conversion is 1.5625ms but illuminance_integration_time_available
sysfs file shows wrong value.

Cc: Crestez Dan Leonard 
Cc: Jonathan Cameron 
Cc: Hartmut Knaack 
Cc: Lars-Peter Clausen 
Cc: Peter Meerwald-Stadler 
Signed-off-by: Akinobu Mita 
Fixes: d5d8f49b6 ("max44000: Expose ambient sensor scaling")
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: common: st_sensors: fix channel data parsing

2017-01-12T10:39:04+00:00

commit 65c8aea07de11b6507efa175edb44bd8b4488218 upstream.

Using realbits as i2c/spi read len, when that value is not byte aligned
(e.g 12 bits), lead to skip msb part of out data registers.
Fix this taking into account scan_type.shift in addition to
scan_type.realbits as read length:

read_len = DIV_ROUND_UP(realbits + shift, 8)

This fix has been tested on 8, 12, 16, 24 bit sensors

Fixes: e7385de5291e ("iio:st_sensors: align on storagebits boundaries")
Signed-off-by: Lorenzo Bianconi 
Tested-by: Linus Walleij 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: maxim_thermocouple: detect invalid storage size in read()

2016-11-13T09:08:32+00:00

As found by gcc -Wmaybe-uninitialized, having a storage_bytes value other
than 2 or 4 will result in undefined behavior:

drivers/iio/temperature/maxim_thermocouple.c: In function 'maxim_thermocouple_read':
drivers/iio/temperature/maxim_thermocouple.c:141:5: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This probably cannot happen, but returning -EINVAL here is appropriate
and makes gcc happy and the code more robust.

Fixes: 231147ee77f3 ("iio: maxim_thermocouple: Align 16 bit big endian value of raw reads")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Jonathan Cameron 
(cherry picked from commit 32cb7d27e65df9daa7cee8f1fdf7b259f214bee2)
Signed-off-by: Greg Kroah-Hartman

iio: hid-sensors: Increase the precision of scale to fix wrong reading interpretation.

2016-11-05T17:50:56+00:00

While testing, it was observed that on some platforms the scale value
from iio sysfs for gyroscope is always 0 (E.g. Yoga 260). This results
in the final angular velocity component values to be zeros.

This is caused by insufficient precision of scale value displayed in sysfs.
If the precision is changed to nano from current micro, then this is
sufficient to display the scale value on this platform.
Since this can be a problem for all other HID sensors, increase scale
precision of all HID sensors to nano from current micro.

Results on Yoga 260:

name		scale before	scale now
--------------------------------------------
gyro_3d		0.000000	0.000000174
als			0.001000	0.001000000
magn_3d		0.000001	0.000001000
accel_3d		0.000009	0.000009806

Signed-off-by: Song Hongyan 
Acked-by: Srinivas Pandruvada 
Cc: 
Signed-off-by: Jonathan Cameron

iio: orientation: hid-sensor-rotation: Add PM function (fix non working driver)

2016-11-05T17:47:47+00:00

This fix makes newer ISH hubs work. Previous ones worked by lucky
coincidence.

Rotation sensor function does not work due to miss PM function.
Add common hid sensor iio pm function for rotation sensor.

Further clarification from Srinivas:

If CONFIG_PM is not defined, then this prevents this sensor to
function. So above commit caused this.

This sensor was supposed to be always on to trigger wake up in prior
external hubs. But with the new ISH hub this is not the case.

Signed-off-by: Song Hongyan 
Fixes: 2b89635e9a9e ("iio: hid_sensor_hub: Common PM functions")
Cc: 
Signed-off-by: Jonathan Cameron

iio: st_sensors: fix scale configuration for h3lis331dl

2016-10-30T16:46:46+00:00

fix scale configuration/parsing for h3lis331dl accel driver
when sensitivity is higher than 1(m/s^2)/digit

Signed-off-by: Lorenzo Bianconi 
Fixes: 1e52fefc9b0c ("iio: accel: Add support for the h3lis331dl accelerometer")
Cc: 
Signed-off-by: Jonathan Cameron

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

2016-10-24T08:50:13+00:00

Jonathan writes:

First set of IIO fixes for the 4.9 cycle.

* atlas chemical
  - Fix alignment of big endian values in a larger storage (by using the right
  size storage)
* maxim thermocouple
  - Fix alignment of big endian values in larger (by using the correct
  sized storage).
* sca3000
  - Handle unexpected mode values.
* ti-adc081
  - Select IIO_TRIGGERED_BUFFER to avoid build errors

iio:chemical:atlas-ph-sensor: Fix use of 32 bit int to hold 16 bit big endian value

2016-10-23T21:18:27+00:00

This will result in a random value being reported on big endian architectures.
(thanks to Lars-Peter Clausen for pointing out the effects of this bug)

Only effects a value printed to the log, but as this reports the settings of
the probe in question it may be of direct interest to users.

Also, fixes the following sparse endianness warnings:

drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16

Signed-off-by: Sandhya Bankar 
Fixes: e8dd92bfbff25 ("iio: chemical: atlas-ph-sensor: add EC feature")
Cc: 
Signed-off-by: Jonathan Cameron