linux-stable.git/drivers/iio, branch v3.16.41 Linux kernel stable tree iio: hid-sensors: Increase the precision of scale to fix wrong reading interpretation. 2017-02-23T03:54:29+00:00 Song Hongyan hongyan.song@intel.com 2016-10-25T01:30:07+00:00 274b874d00600cf100864a5bbfa4995e76a22c24 commit 6f77199e9e4b84340c751c585691d7642a47d226 upstream. 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 <hongyan.song@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 6f77199e9e4b84340c751c585691d7642a47d226 upstream.

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 <hongyan.song@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
iio: hid-sensors: Fix compilation warning 2017-02-23T03:54:29+00:00 Sachin Kamat sachin.kamat@samsung.com 2014-03-07T07:44:00+00:00 0f1ce2b97e907a4b2ee4865222757b0119c5cdac commit a034234277d2f51104deadd559dd9584ba00a8cc upstream. Move the 'static' keyword to beginning of definition to silence the following compilation warning: drivers/iio/common/hid-sensors/hid-sensor-attributes.c:34:1: warning: ‘static’ is not at beginning of declaration [-Wold-style-declaration] Signed-off-by: Sachin Kamat <sachin.kamat@samsung.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit a034234277d2f51104deadd559dd9584ba00a8cc upstream.

Move the 'static' keyword to beginning of definition to silence the
following compilation warning:
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:34:1: warning: ‘static’ is not at beginning of declaration [-Wold-style-declaration]

Signed-off-by: Sachin Kamat <sachin.kamat@samsung.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
iio:core: fix IIO_VAL_FRACTIONAL sign handling 2016-11-20T01:17:23+00:00 Gregor Boirie gregor.boirie@parrot.com 2016-09-02T18:27:46+00:00 d91d35de32f47d8c886bc0bf43ba8128f9abe9ba commit 171c0091837c81ed5c949fec6966bb5afff2d1cf upstream. 7985e7c100 ("iio: Introduce a new fractional value type") introduced a new IIO_VAL_FRACTIONAL value type meant to represent rational type numbers expressed by a numerator and denominator combination. Formating of IIO_VAL_FRACTIONAL values relies upon do_div() usage. This fails handling negative values properly since parameters are reevaluated as unsigned values. Fix this by using div_s64_rem() instead. Computed integer part will carry properly signed value. Formatted fractional part will always be positive. Fixes: 7985e7c100 ("iio: Introduce a new fractional value type") Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 171c0091837c81ed5c949fec6966bb5afff2d1cf upstream.

7985e7c100 ("iio: Introduce a new fractional value type") introduced a
new IIO_VAL_FRACTIONAL value type meant to represent rational type numbers
expressed by a numerator and denominator combination.

Formating of IIO_VAL_FRACTIONAL values relies upon do_div() usage. This
fails handling negative values properly since parameters are reevaluated
as unsigned values.
Fix this by using div_s64_rem() instead. Computed integer part will carry
properly signed value. Formatted fractional part will always be positive.

Fixes: 7985e7c100 ("iio: Introduce a new fractional value type")
Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
iio: accel: kxsd9: Fix scaling bug 2016-11-20T01:17:22+00:00 Linus Walleij linus.walleij@linaro.org 2016-09-01T09:44:35+00:00 3481ab8a20bbf9f2ac1a40e28ea6b3e708ddaec8 commit 307fe9dd11ae44d4f8881ee449a7cbac36e1f5de upstream. All the scaling of the KXSD9 involves multiplication with a fraction number < 1. However the scaling value returned from IIO_INFO_SCALE was unpredictable as only the micros of the value was assigned, and not the integer part, resulting in scaling like this: $cat in_accel_scale -1057462640.011978 Fix this by assigning zero to the integer part. Tested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 307fe9dd11ae44d4f8881ee449a7cbac36e1f5de upstream.

All the scaling of the KXSD9 involves multiplication with a
fraction number < 1.

However the scaling value returned from IIO_INFO_SCALE was
unpredictable as only the micros of the value was assigned, and
not the integer part, resulting in scaling like this:

$cat in_accel_scale
-1057462640.011978

Fix this by assigning zero to the integer part.

Tested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
iio: fix pressure data output unit in hid-sensor-attributes 2016-11-20T01:17:22+00:00 Kweh, Hock Leong hock.leong.kweh@intel.com 2016-08-29T10:50:56+00:00 ba0410655df097129213d743f24050958c9d714f commit 36afb176d3c9580651d7f410ed7f000ec48b5137 upstream. According to IIO ABI definition, IIO_PRESSURE data output unit is kilopascal: http://lxr.free-electrons.com/source/Documentation/ABI/testing/sysfs-bus-iio This patch fix output unit of HID pressure sensor IIO driver from pascal to kilopascal to follow IIO ABI definition. Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 36afb176d3c9580651d7f410ed7f000ec48b5137 upstream.

According to IIO ABI definition, IIO_PRESSURE data output unit is
kilopascal:
http://lxr.free-electrons.com/source/Documentation/ABI/testing/sysfs-bus-iio

This patch fix output unit of HID pressure sensor IIO driver from pascal to
kilopascal to follow IIO ABI definition.

Signed-off-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
iio: accel: kxsd9: Fix raw read return 2016-11-20T01:17:15+00:00 Linus Walleij linus.walleij@linaro.org 2016-08-16T13:33:28+00:00 2a59b4b0834074103f856542ed4c9082991af65e commit 7ac61a062f3147dc23e3f12b9dfe7c4dd35f9cb8 upstream. Any readings from the raw interface of the KXSD9 driver will return an empty string, because it does not return IIO_VAL_INT but rather some random value from the accelerometer to the caller. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 7ac61a062f3147dc23e3f12b9dfe7c4dd35f9cb8 upstream.

Any readings from the raw interface of the KXSD9 driver will
return an empty string, because it does not return
IIO_VAL_INT but rather some random value from the accelerometer
to the caller.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
iio: adc: ti_am335x_adc: Protect FIFO1 from concurrent access 2016-11-20T01:17:15+00:00 Vignesh R vigneshr@ti.com 2016-08-17T12:13:00+00:00 81e3951541d7f35fe0442da2cbc3ea4d3a7af37f commit 90c43ec6997a892448f1f86180a515f59cafd8a3 upstream. It is possible that two or more ADC channels can be simultaneously requested for raw samples, in which case there can be race in access to FIFO data resulting in loss of samples. If am335x_tsc_se_set_once() is called again from tiadc_read_raw(), when ADC is still acquired to sample one of the channels, the second process might be put into uninterruptible sleep state. Fix these issues, by protecting FIFO access and channel configurations with a mutex. Since tiadc_read_raw() might take anywhere between few microseconds to few milliseconds to finish execution (depending on averaging and delay values supplied via DT), its better to use mutex instead of spinlock. Fixes: 7ca6740cd1cd4 ("mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization") Signed-off-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 90c43ec6997a892448f1f86180a515f59cafd8a3 upstream.

It is possible that two or more ADC channels can be simultaneously
requested for raw samples, in which case there can be race in access to
FIFO data resulting in loss of samples.
If am335x_tsc_se_set_once() is called again from tiadc_read_raw(), when
ADC is still acquired to sample one of the channels, the second process
might be put into uninterruptible sleep state. Fix these issues, by
protecting FIFO access and channel configurations with a mutex. Since
tiadc_read_raw() might take anywhere between few microseconds to few
milliseconds to finish execution (depending on averaging and delay
values supplied via DT), its better to use mutex instead of spinlock.

Fixes: 7ca6740cd1cd4 ("mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization")
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
iio: adc: at91: unbreak channel adc channel 3 2016-11-20T01:17:11+00:00 Anders Darander anders@chargestorm.se 2016-08-08T12:42:16+00:00 f0cee6226aea7aaa184ce821a853303dfb7eb200 commit c2ab447454d498e709d9011c0f2d2945ee321f9b upstream. The driver always assumes that an input device has been created when reading channel 3. This causes a kernel panic when dereferencing st->ts_input. The change was introduced in commit 84882b060301 ("iio: adc: at91_adc: Add support for touchscreens without TSMR"). Earlier versions only entered that part of the if-else statement if only the following flags are set: AT91_ADC_IER_XRDY | AT91_ADC_IER_YRDY | AT91_ADC_IER_PRDY Signed-off-by: Anders Darander <anders@chargestorm.se> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit c2ab447454d498e709d9011c0f2d2945ee321f9b upstream.

The driver always assumes that an input device has been created when
reading channel 3. This causes a kernel panic when dereferencing
st->ts_input.

The change was introduced in
commit 84882b060301 ("iio: adc: at91_adc: Add support for touchscreens
without TSMR"). Earlier versions only entered that part of the if-else
statement if only the following flags are set:

AT91_ADC_IER_XRDY | AT91_ADC_IER_YRDY | AT91_ADC_IER_PRDY

Signed-off-by: Anders Darander <anders@chargestorm.se>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
iio: proximity: as3935: set up buffer timestamps for non-zero values 2016-11-20T01:17:11+00:00 Alison Schofield amsfield22@gmail.com 2016-07-11T15:26:56+00:00 4885627a62ecd9d2f697b878cc0eab55a27906b9 commit f8adf645db03345af2d9a8b6095b02327ea50885 upstream. Use the iio_pollfunc_store_time parameter during triggered buffer set-up to get valid timestamps. Signed-off-by: Alison Schofield <amsfield22@gmail.com> Cc: Daniel Baluta <daniel.baluta@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit f8adf645db03345af2d9a8b6095b02327ea50885 upstream.

Use the iio_pollfunc_store_time parameter during triggered buffer
set-up to get valid timestamps.

Signed-off-by: Alison Schofield <amsfield22@gmail.com>
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
iio:ad7266: Fix probe deferral for vref 2016-08-22T21:38:21+00:00 Mark Brown broonie@kernel.org 2016-06-20T12:53:34+00:00 e5dbfa75116a77d70aaf80e79733c47be4891afc commit 68b356eb3d9f5e38910fb62e22a78e2a18d544ae upstream. Currently the ad7266 driver treats any failure to get vref as though the regulator were not present but this means that if probe deferral is triggered the driver will act as though the regulator were not present. Instead only use the internal reference if we explicitly got -ENODEV which is what is returned for absent regulators. Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 68b356eb3d9f5e38910fb62e22a78e2a18d544ae upstream.

Currently the ad7266 driver treats any failure to get vref as though the
regulator were not present but this means that if probe deferral is
triggered the driver will act as though the regulator were not present.
Instead only use the internal reference if we explicitly got -ENODEV which
is what is returned for absent regulators.

Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>