linux-stable.git/drivers/iio, branch v3.16.69

iio/hid-sensors: Fix IIO_CHAN_INFO_RAW returning wrong values for signed numbers

2019-02-11T17:54:05+00:00

commit 0145b50566e7de5637e80ecba96c7f0e6fff1aad upstream.

Before this commit sensor_hub_input_attr_get_raw_value() failed to take
the signedness of 16 and 8 bit values into account, returning e.g.
65436 instead of -100 for the z-axis reading of an accelerometer.

This commit adds a new is_signed parameter to the function and makes all
callers pass the appropriate value for this.

While at it, this commit also fixes up some neighboring lines where
statements were needlessly split over 2 lines to improve readability.

Signed-off-by: Hans de Goede 
Acked-by: Srinivas Pandruvada 
Acked-by: Benjamin Tissoires 
Signed-off-by: Jonathan Cameron 
[bwh: Backported to 3.16:
 - sensor_hub_input_attr_get_raw_value() doesn't take a sync/async flag
   parameter
 - In sensor_hub_input_attr_get_raw_value() keep using data->pending instead of
   hsdev->pending
 - In magn_3d_read_raw() keep using chan->scan_index intstead of chan->address
 - Drop changes in hid-sensor-{custom,humidity,temperature}
 - Adjust context]
Signed-off-by: Ben Hutchings

iio: ad5064: Fix regulator handling

2019-02-11T17:53:24+00:00

commit 8911a43bc198877fad9f4b0246a866b26bb547ab upstream.

The correct way to handle errors returned by regualtor_get() and friends is
to propagate the error since that means that an regulator was specified,
but something went wrong when requesting it.

For handling optional regulators, e.g. when the device has an internal
vref, regulator_get_optional() should be used to avoid getting the dummy
regulator that the regulator core otherwise provides.

Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Jonathan Cameron 
[bwh: Backported to 3.16: Keep using ad5064_write() instead of
 ad5064_set_config().]
Signed-off-by: Ben Hutchings

iio: adc: at91: fix wrong channel number in triggered buffer mode

2019-02-11T17:53:24+00:00

commit aea835f2dc8a682942b859179c49ad1841a6c8b9 upstream.

When channels are registered, the hardware channel number is not the
actual iio channel number.
This is because the driver is probed with a certain number of accessible
channels. Some pins are routed and some not, depending on the description of
the board in the DT.
Because of that, channels 0,1,2,3 can correspond to hardware channels
2,3,4,5 for example.
In the buffered triggered case, we need to do the translation accordingly.
Fixed the channel number to stop reading the wrong channel.

Fixes: 0e589d5fb ("ARM: AT91: IIO: Add AT91 ADC driver.")
Cc: Maxime Ripard 
Signed-off-by: Eugen Hristev 
Acked-by: Ludovic Desroches 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Ben Hutchings

iio: adc: at91: fix acking DRDY irq on simple conversions

2019-02-11T17:53:23+00:00

commit bc1b45326223e7e890053cf6266357adfa61942d upstream.

When doing simple conversions, the driver did not acknowledge the DRDY irq.
If this irq status is not acked, it will be left pending, and as soon as a
trigger is enabled, the irq handler will be called, it doesn't know why
this status has occurred because no channel is pending, and then it will go
int a irq loop and board will hang.
To avoid this situation, read the LCDR after a raw conversion is done.

Fixes: 0e589d5fb ("ARM: AT91: IIO: Add AT91 ADC driver.")
Cc: Maxime Ripard 
Signed-off-by: Eugen Hristev 
Acked-by: Ludovic Desroches 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Ben Hutchings

iio: ad9523: Fix return value for ad952x_store()

2018-12-16T22:08:29+00:00

commit 9a5094ca29ea9b1da301b31fd377c0c0c4c23034 upstream.

A sysfs write callback function needs to either return the number of
consumed characters or an error.

The ad952x_store() function currently returns 0 if the input value was "0",
this will signal that no characters have been consumed and the function
will be called repeatedly in a loop indefinitely. Fix this by returning
number of supplied characters to indicate that the whole input string has
been consumed.

Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Alexandru Ardelean 
Fixes: cd1678f96329 ("iio: frequency: New driver for AD9523 SPI Low Jitter Clock Generator")
Signed-off-by: Jonathan Cameron 
Signed-off-by: Ben Hutchings

iio: ad9523: Fix displayed phase

2018-12-16T22:08:20+00:00

commit 5a4e33c1c53ae7d4425f7d94e60e4458a37b349e upstream.

Fix the displayed phase for the ad9523 driver. Currently the most
significant decimal place is dropped and all other digits are shifted one
to the left. This is due to a multiplication by 10, which is not necessary,
so remove it.

Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Alexandru Ardelean 
Fixes: cd1678f9632 ("iio: frequency: New driver for AD9523 SPI Low Jitter Clock Generator")
Signed-off-by: Jonathan Cameron 
Signed-off-by: Ben Hutchings

iio:kfifo_buf: check for uint overflow

2018-10-21T07:45:05+00:00

commit 3d13de4b027d5f6276c0f9d3a264f518747d83f2 upstream.

Currently, the following causes a kernel OOPS in memcpy:

echo 1073741825 > buffer/length
echo 1 > buffer/enable

Note that using 1073741824 instead of 1073741825 causes "write error:
Cannot allocate memory" but no OOPS.

This is because 1073741824 == 2^30 and 1073741825 == 2^30+1. Since kfifo
rounds up to the nearest power of 2, it will actually call kmalloc with
roundup_pow_of_two(length) * bytes_per_datum.

Using length == 1073741825 and bytes_per_datum == 2, we get:

kmalloc(roundup_pow_of_two(1073741825) * 2
or kmalloc(2147483648 * 2)
or kmalloc(4294967296)
or kmalloc(UINT_MAX + 1)

so this overflows to 0, causing kmalloc to return ZERO_SIZE_PTR and
subsequent memcpy to fail once the device is enabled.

Fix this by checking for overflow prior to allocating a kfifo. With this
check added, the above code returns -EINVAL when enabling the buffer,
rather than causing an OOPS.

Signed-off-by: Martin Kelly 
Signed-off-by: Jonathan Cameron 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

iio:buffer: make length types match kfifo types

2018-10-21T07:45:05+00:00

commit c043ec1ca5baae63726aae32abbe003192bc6eec upstream.

Currently, we use int for buffer length and bytes_per_datum. However,
kfifo uses unsigned int for length and size_t for element size. We need
to make sure these matches or we will have bugs related to overflow (in
the range between INT_MAX and UINT_MAX for length, for example).

In addition, set_bytes_per_datum uses size_t while bytes_per_datum is an
int, which would cause bugs for large values of bytes_per_datum.

Change buffer length to use unsigned int and bytes_per_datum to use
size_t.

Signed-off-by: Martin Kelly 
Signed-off-by: Jonathan Cameron 
[bwh: Backported to 3.16:
 - Drop change in iio_dma_buffer_set_length()
 - Adjust filenames, context]
Signed-off-by: Ben Hutchings

iio: buffer: check if a buffer has been set up when poll is called

2018-06-16T21:22:19+00:00

commit 4cd140bda6494543f1c1b0ccceceaa44b676eef6 upstream.

If no iio buffer has been set up and poll is called return 0.
Without this check there will be a null pointer dereference when
calling poll on a iio driver without an iio buffer.

Signed-off-by: Stefan Windfeldt-Prytz 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Ben Hutchings

iio: adis_lib: Initialize trigger before requesting interrupt

2018-06-16T21:22:19+00:00

commit f027e0b3a774e10302207e91d304bbf99e3a8b36 upstream.

The adis_probe_trigger() creates a new IIO trigger and requests an
interrupt associated with the trigger. The interrupt uses the generic
iio_trigger_generic_data_rdy_poll() function as its interrupt handler.

Currently the driver initializes some fields of the trigger structure after
the interrupt has been requested. But an interrupt can fire as soon as it
has been requested. This opens up a race condition.

iio_trigger_generic_data_rdy_poll() will access the trigger data structure
and dereference the ops field. If the ops field is not yet initialized this
will result in a NULL pointer deref.

It is not expected that the device generates an interrupt at this point, so
typically this issue did not surface unless e.g. due to a hardware
misconfiguration (wrong interrupt number, wrong polarity, etc.).

But some newer devices from the ADIS family start to generate periodic
interrupts in their power-on reset configuration and unfortunately the
interrupt can not be masked in the device.  This makes the race condition
much more visible and the following crash has been observed occasionally
when booting a system using the ADIS16460.

	Unable to handle kernel NULL pointer dereference at virtual address 00000008
	pgd = c0004000
	[00000008] *pgd=00000000
	Internal error: Oops: 5 [#1] PREEMPT SMP ARM
	Modules linked in:
	CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257
	Hardware name: Xilinx Zynq Platform
	task: ef04f640 task.stack: ef050000
	PC is at iio_trigger_notify_done+0x30/0x68
	LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20
	pc : []    lr : []    psr: 60000193
	sp : ef051bb8  ip : 00000000  fp : ef106400
	r10: c081d80a  r9 : ef3bfa00  r8 : 00000087
	r7 : ef051bec  r6 : 00000000  r5 : ef3bfa00  r4 : ee92ab00
	r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : ee97e400
	Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
	Control: 18c5387d  Table: 0000404a  DAC: 00000051
	Process swapper/0 (pid: 1, stack limit = 0xef050210)
	[] (iio_trigger_notify_done) from [] (__handle_irq_event_percpu+0x88/0x118)
	[] (__handle_irq_event_percpu) from [] (handle_irq_event_percpu+0x1c/0x58)
	[] (handle_irq_event_percpu) from [] (handle_irq_event+0x38/0x5c)
	[] (handle_irq_event) from [] (handle_level_irq+0xa4/0x130)
	[] (handle_level_irq) from [] (generic_handle_irq+0x24/0x34)
	[] (generic_handle_irq) from [] (zynq_gpio_irqhandler+0xb8/0x13c)
	[] (zynq_gpio_irqhandler) from [] (generic_handle_irq+0x24/0x34)
	[] (generic_handle_irq) from [] (__handle_domain_irq+0x5c/0xb4)
	[] (__handle_domain_irq) from [] (gic_handle_irq+0x48/0x8c)
	[] (gic_handle_irq) from [] (__irq_svc+0x6c/0xa8)

To fix this make sure that the trigger is fully initialized before
requesting the interrupt.

Fixes: ccd2b52f4ac6 ("staging:iio: Add common ADIS library")
Reported-by: Robin Getz 
Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Ben Hutchings