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

iio: bmg160: reset chip when probing

2017-04-12T10:41:11+00:00

commit 4bdc9029685ac03be50b320b29691766d2326c2b upstream.

The gyroscope chip might need to be reset to be used.

Without the chip being reset, the driver stopped at the first
regmap_read (to get the CHIP_ID) and failed to probe.

The datasheet of the gyroscope says that a minimum wait of 30ms after
the reset has to be done.

This patch has been checked on a BMX055 and the datasheet of the BMG160
and the BMI055 give the same reset register and bits.

Signed-off-by: Quentin Schulz 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: magnetometer: ak8974: remove incorrect __exit markups

2017-03-30T07:41:25+00:00

commit 3ff861f59f6c1f5bf2bc03d2cd36ac3f992cbc06 upstream.

Even if bus is not hot-pluggable, devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.

Signed-off-by: Dmitry Torokhov 
Reviewed-by: Linus Walleij 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3

2017-03-30T07:41:25+00:00

commit 3bec247474469f769af41e8c80d3a100dd97dd76 upstream.

In function _hid_sensor_power_state(), when hid_sensor_read_poll_value()
is called, sensor's all properties will be updated by the value from
sensor hardware/firmware.
In some implementation, sensor hardware/firmware will do a power cycle
during S3. In this case, after resume, once hid_sensor_read_poll_value()
is called, sensor's all properties which are kept by driver during S3
will be changed to default value.
But instead, if a set feature function is called first, sensor
hardware/firmware will be recovered to the last status. So change the
sensor_hub_set_feature() calling order to behind of set feature function
to avoid sensor properties lose.

Signed-off-by: Song Hongyan 
Acked-by: Srinivas Pandruvada 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: adc: ti_am335x_adc: fix fifo overrun recovery

2017-03-30T07:41:25+00:00

commit e83bb3e6f3efa21f4a9d883a25d0ecd9dfb431e1 upstream.

The tiadc_irq_h(int irq, void *private) function is handling FIFO
overruns by clearing flags, disabling and enabling the ADC to
recover.

If the ADC is running in continuous mode a FIFO overrun happens
regularly. If the disabling of the ADC happens concurrently with
a new conversion. It might happen that the enabling of the ADC
is ignored by the hardware. This stops the ADC permanently. No
more interrupts are triggered.

According to the AM335x Reference Manual (SPRUH73H October 2011 -
Revised April 2013 - Chapter 12.4 and 12.5) it is necessary to
check the ADC FSM bits in REG_ADCFSM before enabling the ADC
again. Because the disabling of the ADC is done right after the
current conversion has been finished.

To trigger this bug it is necessary to run the ADC in continuous
mode. The ADC values of all channels need to be read in an endless
loop. The bug appears within the first 6 hours (~5.4 million
handled FIFO overruns). The user space application will hang on
reading new values from the character device.

Fixes: ca9a563805f7a ("iio: ti_am335x_adc: Add continuous sampling support")
Signed-off-by: Michael Engl 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: pressure: mpl3115: do not rely on structure field ordering

2017-03-12T05:41:48+00:00

commit 9cf6cdba586ced75c69b8314b88b2d2f5ce9b3ed upstream.

Fixes a regression triggered by a change in the layout of
struct iio_chan_spec, but the real bug is in the driver which assumed
a specific structure layout in the first place. Hint: the two bits were
not OR:ed together as implied by the indentation prior to this patch,
there was a comma between them, which accidentally moved the ..._SCALE
bit to the next structure field. That field was .info_mask_shared_by_type
before the _available attributes was added by commit 51239600074b
("iio:core: add a callback to allow drivers to provide _available
attributes") and .info_mask_separate_available afterwards, and the
regression happened.

info_mask_shared_by_type is actually a better choice than the originally
intended info_mask_separate for the ..._SCALE bit since a constant is
returned from mpl3115_read_raw for the scale. Using
info_mask_shared_by_type also preserves the behavior from before the
regression and is therefore less likely to cause other interesting side
effects.

The above mentioned regression causes an unintended sysfs attibute to
show up that is not backed by code, in turn causing the following NULL
pointer defererence to happen on access.

Segmentation fault

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = ecc3c000
[00000000] *pgd=87f91831
Internal error: Oops: 80000007 [#1] SMP ARM
Modules linked in:
CPU: 1 PID: 1051 Comm: cat Not tainted 4.10.0-rc5-00009-gffd8858-dirty #3
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: ed54ec00 task.stack: ee2bc000
PC is at 0x0
LR is at iio_read_channel_info_avail+0x40/0x280
pc : [<00000000>]    lr : []    psr: a0070013
sp : ee2bdda8  ip : 00000000  fp : ee2bddf4
r10: c0a53c74  r9 : ed79f000  r8 : ee8d1018
r7 : 00001000  r6 : 00000fff  r5 : ee8b9a00  r4 : ed79f000
r3 : ee2bddc4  r2 : ee2bddbc  r1 : c0a86dcc  r0 : ee8d1000
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 3cc3c04a  DAC: 00000051
Process cat (pid: 1051, stack limit = 0xee2bc210)
Stack: (0xee2bdda8 to 0xee2be000)
dda0:                   ee2bddc0 00000002 c016d720 c016d394 ed54ec00 00000000
ddc0: 60070013 ed413780 00000001 edffd480 ee8b9a00 00000fff 00001000 ee8d1018
dde0: ed79f000 c0a53c74 ee2bde0c ee2bddf8 c0513c58 c06fbbe8 edffd480 edffd540
de00: ee2bde3c ee2bde10 c0293474 c0513c40 c02933e4 ee2bde60 00000001 ed413780
de20: 00000001 ed413780 00000000 edffd480 ee2bde4c ee2bde40 c0291d00 c02933f0
de40: ee2bde9c ee2bde50 c024679c c0291ce0 edffd4b0 b6e37000 00020000 ee2bdf78
de60: 00000000 00000000 ed54ec00 ed013200 00000817 c0a111fc edffd540 ed413780
de80: b6e37000 00020000 00020000 ee2bdf78 ee2bded4 ee2bdea0 c0292890 c0246604
dea0: c0117940 c016ba50 00000025 c0a111fc b6e37000 ed413780 ee2bdf78 00020000
dec0: ee2bc000 b6e37000 ee2bdf44 ee2bded8 c021d158 c0292770 c0117764 b6e36004
dee0: c0f0d7c4 ee2bdfb0 b6f89228 00021008 ee2bdfac ee2bdf00 c0101374 c0117770
df00: 00000000 00000000 ee2bc000 00000000 ee2bdf34 ee2bdf20 c016ba04 c0171080
df20: 00000000 00020000 ed413780 b6e37000 00000000 ee2bdf78 ee2bdf74 ee2bdf48
df40: c021e7a0 c021d130 c023e300 c023e280 ee2bdf74 00000000 00000000 ed413780
df60: ed413780 00020000 ee2bdfa4 ee2bdf78 c021e870 c021e71c 00000000 00000000
df80: 00020000 00020000 b6e37000 00000003 c0108084 00000000 00000000 ee2bdfa8
dfa0: c0107ee0 c021e838 00020000 00020000 00000003 b6e37000 00020000 0001a2b4
dfc0: 00020000 00020000 b6e37000 00000003 7fffe000 00000000 00000000 00020000
dfe0: 00000000 be98eb4c 0000c740 b6f1985c 60070010 00000003 00000000 00000000
Backtrace:
[] (iio_read_channel_info_avail) from [] (dev_attr_show+0x24/0x50)
 r10:c0a53c74 r9:ed79f000 r8:ee8d1018 r7:00001000 r6:00000fff r5:ee8b9a00
 r4:edffd480
[] (dev_attr_show) from [] (sysfs_kf_seq_show+0x90/0x110)
 r5:edffd540 r4:edffd480
[] (sysfs_kf_seq_show) from [] (kernfs_seq_show+0x2c/0x30)
 r10:edffd480 r9:00000000 r8:ed413780 r7:00000001 r6:ed413780 r5:00000001
 r4:ee2bde60 r3:c02933e4
[] (kernfs_seq_show) from [] (seq_read+0x1a4/0x4e0)
[] (seq_read) from [] (kernfs_fop_read+0x12c/0x1cc)
 r10:ee2bdf78 r9:00020000 r8:00020000 r7:b6e37000 r6:ed413780 r5:edffd540
 r4:c0a111fc
[] (kernfs_fop_read) from [] (__vfs_read+0x34/0x118)
 r10:b6e37000 r9:ee2bc000 r8:00020000 r7:ee2bdf78 r6:ed413780 r5:b6e37000
 r4:c0a111fc
[] (__vfs_read) from [] (vfs_read+0x90/0x11c)
 r8:ee2bdf78 r7:00000000 r6:b6e37000 r5:ed413780 r4:00020000
[] (vfs_read) from [] (SyS_read+0x44/0x90)
 r8:00020000 r7:ed413780 r6:ed413780 r5:00000000 r4:00000000
[] (SyS_read) from [] (ret_fast_syscall+0x0/0x1c)
 r10:00000000 r8:c0108084 r7:00000003 r6:b6e37000 r5:00020000 r4:00020000
Code: bad PC value
---[ end trace 9c4938ccd0389004 ]---

Fixes: cc26ad455f57 ("iio: Add Freescale MPL3115A2 pressure / temperature sensor driver")
Fixes: 51239600074b ("iio:core: add a callback to allow drivers to provide _available attributes")
Reported-by: Ken Lin 
Tested-by: Ken Lin 
Signed-off-by: Peter Rosin 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: pressure: mpl115: do not rely on structure field ordering

2017-03-12T05:41:48+00:00

commit 6a6e1d56a0769795a36c0461c64bf5e5b9bbb4c0 upstream.

Fixes a regression triggered by a change in the layout of
struct iio_chan_spec, but the real bug is in the driver which assumed
a specific structure layout in the first place. Hint: the three bits were
not OR:ed together as implied by the indentation prior to this patch,
there was a comma between the first two, which accidentally moved the
..._SCALE and ..._OFFSET bits to the next structure field. That field
was .info_mask_shared_by_type before the _available attributes was added
by commit 51239600074b ("iio:core: add a callback to allow drivers to
provide _available attributes") and .info_mask_separate_available
afterwards, and the regression happened.

info_mask_shared_by_type is actually a better choice than the originally
intended info_mask_separate for the ..._SCALE and ..._OFFSET bits since
a constant is returned from mpl115_read_raw for the scale/offset. Using
info_mask_shared_by_type also preserves the behavior from before the
regression and is therefore less likely to cause other interesting side
effects.

The above mentioned regression causes unintended sysfs attibutes to
show up that are not backed by code, in turn causing a NULL pointer
defererence to happen on access.

Fixes: 3017d90e8931 ("iio: Add Freescale MPL115A2 pressure / temperature sensor driver")
Fixes: 51239600074b ("iio:core: add a callback to allow drivers to provide _available attributes")
Signed-off-by: Peter Rosin 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: health: max30100: fixed parenthesis around FIFO count check

2017-02-09T07:08:30+00:00

commit 828f84ee8f84710ea1818b3565add268bcb824c8 upstream.

FIFO was being read every sample after the "almost full" state was
reached. This was due to an incorrect placement of the parenthesis
in the while condition check.

Note - the fixes tag is not actually correct, but the fix in this patch
would also be needed for it to function correctly so we'll go with that
one.  Backports should pick up both.

Signed-off-by: Matt Ranostay 
Fixes: b74fccad7 ("iio: health: max30100: correct FIFO check condition")
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: dht11: Use usleep_range instead of msleep for start signal

2017-02-09T07:08:30+00:00

commit 5c113b5e0082e90d2e1c7b12e96a7b8cf0623e27 upstream.

The DHT22 (AM2302) datasheet specifies that the LOW start pulse should not
exceed 20ms. However, observations with an oscilloscope of an RPi Model 2B
(rev 1.1) communicating with a DHT22 sensor showed that the driver was
consistently sending start pulses longer than 20ms:

Kernel 4.7.10-v7+ (n=132):
    Minimum pulse length: 20.20ms
    Maximum:              29.84ms
    Mean:                 24.96ms
    StDev:                2.82ms
    Sensor response rate: 100%
    Read success rate:    76%

On kernel 4.8, the start pulse was so long that the sensor would not even
respond 97% of the time:

Kernel 4.8.16-v7+ (n=100):
    Minimum pulse length: 30.4ms
    Maximum:              74.4ms
    Mean:                 39.3ms
    StDev:                10.2ms
    Sensor response rate: 3%
    Read success rate:    3%

The driver would return ETIMEDOUT and write log messages like this:

[   51.430987] dht11 dht11@0: Only 1 signal edges detected
[   66.311019] dht11 dht11@0: Only 0 signal edges detected

Replacing msleep(18) with usleep_range(18000, 20000) made the pulse length
sane again and restored responsiveness:

Kernel 4.8.16-v7+ with usleep_range (n=123):
    Minimum pulse length: 18.16ms
    Maximum:              20.20ms
    Mean:                 19.85ms
    StDev:                0.51ms
    Sensor response rate: 100%
    Read success rate:    84%

Signed-off-by: John Brooks 
Reviewed-by: Harald Geyer 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: health: afe4403: retrieve a valid iio_dev in suspend/resume

2017-02-09T07:08:30+00:00

commit a5badd1e97e6caeca78ad74191f12fc923c403a8 upstream.

The suspend/resume functions were using dev_to_iio_dev() to get
the iio_dev. That only works on IIO dev's.  Replace it with spi
functions to get the correct iio_dev.

Signed-off-by: Alison Schofield 
Acked-by: Andrew F. Davis 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: health: afe4404: retrieve a valid iio_dev in suspend/resume

2017-02-09T07:08:30+00:00

commit 802ecfc113df1e15af1d028427cbbe785ae9cc4a upstream.

The suspend/resume functions were using dev_to_iio_dev() to get
the iio_dev. That only works on IIO dev's.  Replace it with i2c
functions to get the correct iio_dev.

Signed-off-by: Alison Schofield 
Acked-by: Andrew F. Davis 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman