linux-stable.git/drivers/iio/common, branch linux-3.17.y

iio: st_sensors: Fix buffer copy

2014-11-14T18:10:32+00:00

commit 4250c90b30b8bf2a1a21122ba0484f8f351f152d upstream.

Use byte_for_channel as iterator to properly initialize the buffer.

Signed-off-by: Robin van der Gracht 
Acked-by: Denis Ciocca 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: st_sensors: Fix indio_dev->trig assignment

2014-08-25T20:48:49+00:00

This can result in wrong reference count for trigger device, call
iio_trigger_get to increment reference.
Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion
with Jonathan.

Signed-off-by: Srinivas Pandruvada 
Signed-off-by: Jonathan Cameron 
Cc: Stable@vger.kernel.org

iio: hid_sensor_hub: Fix indio_dev->trig assignment

2014-08-25T20:48:39+00:00

This can result in wrong reference count for trigger device, call
iio_trigger_get to increment reference.
Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion
with Jonathan.

Signed-off-by: Srinivas Pandruvada 
Signed-off-by: Jonathan Cameron 
Cc: Stable@vger.kernel.org

iio: st_sensors: add devicetree probing support

2014-07-11T20:09:49+00:00

The I2C devices that make up the STMicroelectronics MEMS sensors
may be sneakily enabled by cleverly giving the device node the same
name as a string match from the platform device ID table. However
the right method is to use the compatible string.

On detection, the ST sensors use the ID string to probe and
instatiate the right sensor driver, so pass the kernel-internal ID
string in the .data field of the OF match table, and set the I2C
client name to this name when a compatible match is used.

This avoids having misc Linux-specific strings floating around in
the device tree.

Cc: Lee Jones 
Cc: Denis CIOCCA 
Signed-off-by: Linus Walleij 
Signed-off-by: Jonathan Cameron

iio: hid-sensors: make hid_sensor_get_reporting_interval static

2014-07-07T12:29:49+00:00

This fixes the following sparse warning:

  CHECK   drivers/iio/common/hid-sensors/hid-sensor-attributes.c
drivers/iio/common/hid-sensors/hid-sensor-attributes.c:346:5: warning:
symbol 'hid_sensor_get_reporting_interval' was not declared. Should it be static?

Signed-off-by: Daniel Baluta 
Signed-off-by: Jonathan Cameron

iio: st_sensors: get platform data from device tree

2014-07-07T12:11:28+00:00

Currently the STMicroelectronics sensors only support one single
platform data item: configuration of the DRDY (data ready) pin
for a particular design. Augment the core to prioritize and take
this information from the device tree if the parent device has an
assigned device node, else fall back to passed in platform data
(usually the default data).

Cc: Lee Jones 
Cc: Denis CIOCCA 
Signed-off-by: Linus Walleij 
Signed-off-by: Jonathan Cameron

iio:st sensors: remove custom sampling frequence attribute in favour of core support.

2014-07-07T08:39:57+00:00

This allows in kernel client drivers to access this

Signed-off-by: Jonathan Cameron 
Cc: Denis Ciocca 
Reviewed-by: Hartmut Knaack

iio: hid-sensors: Fix compilation warning

2014-07-05T10:21:09+00:00

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 
Cc: Srinivas Pandruvada 
Signed-off-by: Jonathan Cameron

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

2014-06-18T17:41:08+00:00

Jonathan writes:

First set of IIO fixes for the 3.16 cycle.

A mixed bag of fixes, many of which feel just to late for 3.15.

* hid sensors - some devices need a feature report request in order to
  change power state.  This isn't part of the spec, but has been observed
  on several devices and does no harm to others.
* mpl3115 has had two errors in the buffer description fixed. The presure is
  signed, not unsigned and the temperature has 12 bits rather than 16.
  These could lead to incorrect interpretation of the data in userspace.
* tsl2x7x - the high byte of the proximity thresholds should be written along
  with the low byte (which was). This could lead to interesting results
  with large thresholds.
* twl4030 - a flag to specify processed values were required was not set
  when initializing a reading.  As such values returned were in an unknown
  state. Fixed by simply initializing it appropriately.
* IIO_SIMPLE_DUMMY_BUFFER did not select IIO_BUFFER leading to randconfig
  build errors.
* ak8975 was applying an unwanted le16_to_cpu conversion as the i2c framework
  already performs one.  As such for big endian systems, the bytes would be
  in the wrong order in the magnetic field measurements reported.
* mxs-lradc - the controllable voltage dividers were not enabled / disabled for
  later channels than the first one during conversion.
* at91_adc error handling returned -ENOMEM in a u8. Return value of
  at91_adc_get_trigger_value_by_name changed to int thus allowing -ENOMEM and
  also original values to be returned.
* mcb - mcb_request_mem returns and ERR_PTR but the caller was checking for
  NULL to detect an error.

iio: hid-sensors: Get feature report from sensor hub after changing power state

2014-05-29T16:38:33+00:00

Some sensor hubs require a get feature report call to be issued soon after
changing the power state of the sensor. Without this, the sensor remains in
the current state. This patch adds a call soon after the power state.

This is retained as a generic call across all sensor hubs since the behavior
has been noticed on more than one implementation.

Signed-off-by: Archana Patni 
Signed-off-by: Subramony Sesha 
Reviewed-by: Srinivas Pandruvada 
Signed-off-by: Jonathan Cameron