linux-stable.git/drivers/iio/light, branch linux-4.6.y

iio: light apds9960: Add the missing dev.parent

2016-07-27T15:42:20+00:00

commit 590b92a30242dd3f73de3d9a51d9924f1ab33e93 upstream.

Without this, the iio:deviceX is missing in the /sys/bus/i2c/devices/0-0039
Some userspace tools use this path to identify a specific instance of the
device.

Signed-off-by: Yong Li 
Reviewed-By: Matt Ranostay 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

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

2016-04-04T19:59:48+00:00

Jonathan writes:

First round of IIO fixes for the 4.6 cycle.

Again I've ended up with two early fix sets, depending on whether they are
dependent on elements of the merge window or simply came in after I had
patches with that dependency already, vs older fixes that were just too
late for the last cycle.  This first set is for the older ones.

- max1353
  * Add a missing adc to max1363_id - the driver has supported the
    max11644-11647 for a while, but as they weren't in the id table there
    was no way of actually initializing it.
  * Fix a wrong reference voltage for the above models.  Given you couldn't
    initialize the driver for these parts without patching, no one noticed
    that the reference voltage used in computing the scaling was wrong.
 - apds9960
   * The fifo last enelement was read twice (and hence pushed out twice) due
     to a small logic bug.

iio: light: apds9960: correct FIFO check condition

2016-03-20T10:33:33+00:00

Correct issue that the last entry in FIFO was being read twice due
to an incorrect decrement of entry count variable before condition
check.

Signed-off-by: Matt Ranostay 
Signed-off-by: Jonathan Cameron

iio: convert to common i2c_check_functionality() return value

2016-02-27T17:17:43+00:00

Previously most drivers that used a i2c_check_functionality() check
condition required various error codes on failure. This patchset
converts to a standard of -EOPNOTSUPP

Signed-off-by: Matt Ranostay 
Signed-off-by: Jonathan Cameron

Merge 4.5-rc3 into staging-next

2016-02-08T01:34:04+00:00

We want the upstream staging fixes in here as well.

Signed-off-by: Greg Kroah-Hartman

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

2016-02-01T21:07:38+00:00

Jonathan writes:

First set of IIO fixes for the 4.5 cycle.

This set comprises those not dependent on patches in the 4.5 merge cycle.
A second set will follow shortly with ones that are.

* core in kernel interfaces
  - fix a possible NULL dereference that is a theoretical possibility
    via odd usage of iio_channel_release. Pretty much a hardening of
    the interface, but observed in the wild with the twl4030_charger
    driver.
* acpi-als
  - report the data as processed as it is in lux.  This fixes a wrong
    use of the IIO ABI.  However, old _raw version retained to avoid
    breaking any userspace in the wild that is relying on that (none
    known but it doesn't hurt us much to retain it)
* ade7753
  - fix some error handling to avoid use of unitialized data.
* ltr501
  - use a signed return type for ltr501_match_samp_freq so as to allow
    returning of an error code.
* mcp4725
  - set name field of struct iio_dev to ensure the sysfs name attribute
    doesn't give NULL.
* mpl115
  - temperature offset sign is wrong.
* stk8ba50
  - IIO_TRIGGER dependency added
* ti_am335x_adc
  - Label buffer as a software buffer. It's actually a hybrid of a
    true hardware buffer feeding a kfifo, but the meaning of these fields
    has changed a little recently and in this case it should be labeled
    a software buffer ensure it is allowed to use the kfifo.
* vf610_adc
  - HAS_IOMEM dependency

iio: light: opt3001: enable operation w/o IRQ

2016-01-30T16:26:47+00:00

Enable operation of the TI OPT3001 light sensor without having an
interrupt line available to connect the INT pin to.

In this operation mode, we issue a conversion request and simply wait
for the conversion time available as timeout value, determined from
integration time configuration and the worst-case time given in the data
sheet (sect. 6.5, table on p. 5):

  short integration time (100ms): 110ms + 3ms = 113ms
   long integration time (800ms): 880ms + 3ms = 883ms

This change is transparent as behaviour defaults to using the interrupt
method if an interrupt no. is configured via device tree. Interrupt-less
operation mode is performed when no valid interrupt no. is given.

Signed-off-by: Alexander Koch 
Signed-off-by: Michael Hornung 
Tested-by: Andreas Dannenberg 
Signed-off-by: Jonathan Cameron

iio: light: opt3001: trivial type refactoring

2016-01-30T16:26:33+00:00

Change variable type of struct opt3001 members 'ok_to_ignore_lock' and
'result_ready' uint16-bitfield of length one to bool.

They are used as bool, let the compiler do the optimization.

Signed-off-by: Alexander Koch 
Signed-off-by: Michael Hornung 
Tested-by: Andreas Dannenberg 
Signed-off-by: Jonathan Cameron

iio: light: opt3001: extract int. time constants

2016-01-30T16:26:12+00:00

Extract integration times as #define constants. This prepares using them
for delay/timeout length determination.

Signed-off-by: Alexander Koch 
Signed-off-by: Michael Hornung 
Tested-by: Andreas Dannenberg 
Signed-off-by: Jonathan Cameron

iio: light: acpi-als: Report data as processed

2016-01-16T12:58:18+00:00

As per the ACPI specification (Revision 5.0) [1], the data coming
from the sensor represent the ambient light illuminance reading
expressed in lux. So use IIO_CHAN_INFO_PROCESSED to signify that
the data are pre-processed.

However, to keep backward ABI compatibility, the IIO_CHAN_INFO_RAW
bit is not removed.

[1] http://www.acpi.info/DOWNLOADS/ACPIspec50.pdf

This issue has also been responsible for at least one userspace bug
report hence marking what is a small semantic fix really for stable.
[2] https://github.com/hadess/iio-sensor-proxy/issues/46

Signed-off-by: Gabriele Mazzotta 
Cc: 
Signed-off-by: Jonathan Cameron