aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/iio (follow)
AgeCommit message (Collapse)AuthorFilesLines
2016-06-26iio:ad7266: Fix probe deferral for vrefMark Brown1-0/+3
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> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-26iio:ad7266: Fix support for optional regulatorsMark Brown1-1/+1
The ad7266 driver attempts to support deciding between the use of internal and external power supplies by checking to see if an error is returned when requesting the regulator. This doesn't work with the current code since the driver uses a normal regulator_get() which is for non-optional supplies and so assumes that if a regulator is not provided by the platform then this is a bug in the platform integration and so substitutes a dummy regulator. Use regulator_get_optional() instead which indicates to the framework that the regulator may be absent and provides a dummy regulator instead. Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-26iio:ad7266: Fix broken regulator error handlingMark Brown1-1/+1
All regulator_get() variants return either a pointer to a regulator or an ERR_PTR() so testing for NULL makes no sense and may lead to bugs if we use NULL as a valid regulator. Fix this by using IS_ERR() as expected. Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-26iio: accel: kxsd9: fix the usage of spi_w8r8()Linus Walleij1-2/+2
These two spi_w8r8() calls return a value with is used by the code following the error check. The dubious use was caused by a cleanup patch. Fixes: d34dbee8ac8e ("staging:iio:accel:kxsd9 cleanup and conversion to iio_chan_spec.") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-22Merge tag 'iio-fixes-for-4.7b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linusGreg Kroah-Hartman1-2/+3
Jonathan writes: Second set of IIO fixes for the 4.7 cycle. This includes one tracked regression (Arnd's patch for the ad7606). The other two have I think always been broken. * inv_mpu6050 - Fix a use after free in the ACPI code. * ad5933 - The code for setting the cycles had a bug that meant it was simply wrong. * ad7606_spi - Fix a regression that got introduced in a buggy cleanup of a sparse warning.
2016-06-18Merge tag 'staging-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/stagingLinus Torvalds21-98/+221
Pull IIO and staging fixes from Greg KH: "Here are a number of IIO and staging bugfixes for 4.7-rc4. Nothing huge, the normal amount of iio driver fixes, and some small staging driver bugfixes for some reported problems (2 are reverts of patches that went into 4.7-rc1). All have been in linux-next with no reported issues" * tag 'staging-4.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (24 commits) Revert "Staging: rtl8188eu: rtw_efuse: Use sizeof type *pointer instead of sizeof type." Revert "Staging: drivers: rtl8188eu: use sizeof(*ptr) instead of sizeof(struct)" staging: lustre: lnet: Don't access NULL NI on failure path iio: hudmidity: hdc100x: fix incorrect shifting and scaling iio: light apds9960: Add the missing dev.parent iio: Fix error handling in iio_trigger_attach_poll_func iio: st_sensors: Disable DRDY at init time iio: st_sensors: Init trigger before irq request iio: st_sensors: switch to a threaded interrupt iio: light: bh1780: assign a static name iio: bh1780: dereference the client properly iio: humidity: hdc100x: fix IIO_TEMP channel reporting iio:st_pressure: fix sampling gains (bring inline with ABI) iio: proximity: as3935: fix buffer stack trashing iio: proximity: as3935: remove triggered buffer processing iio: proximity: as3935: correct IIO_CHAN_INFO_RAW output max44000: Remove scale from proximity iio: humidity: am2315: Remove a stray unlock iio: humidity: hdc100x: correct humidity integration time mask iio: pressure: bmp280: fix error message for wrong chip id ...
2016-06-17iio: stx104: Allow build for X86_64William Breathitt Gray1-1/+1
With the introduction of the ISA_BUS_API Kconfig option, ISA-style drivers may be built for X86_64 architectures. This patch changes the ISA Kconfig option dependency of the Apex Embedded Systems STX104 DAC driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is expected to. Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-11iio: inv_mpu6050: Fix use-after-free in ACPI codeCrestez Dan Leonard1-2/+3
In some cases this can result in incorrectly returning a negative value from asus_acpi_get_sensor_info and the AK8963 magnetometer failing to show up. Note cpm is an alias for buffer.pointer which isn't apparent in this patch on it's own. Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Acked-by: Daniel Baluta <daniel.baluta@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-07Merge tag 'iio-fixes-for-4.7a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linusGreg Kroah-Hartman21-98/+221
Jonathan writes: First round of iio fixes for the 4.7 cycle. A slightly bumper set due to travel delaying the pull request and a fair few issues with the recent merge window patches. Patches all over the place. The st-sensors one is probably the most involved, but definitly solves the issues seen. Note there are some other issues around that handler (and the fact that a lot of boards tie a level interrupt chip to an edge interrupt only irq chip). These are not regressions however, so will turn up the slow route. * core - iio_trigger_attach_pollfunc had some really badly wrong error handling. Another nasty triggered whilst chasing down issues with the st sensors rework below. * ad5592r - fix an off by one error when allocating channels. * am2315 - a stray mutex unlock before we ever take the lock. * apds9960 - missing a parent in the driver model (which should be the i2c device). Result is it doesn't turn up under /sys/bus/i2c/devices which some userspace code uses for repeatable device identification. * as3935 - ABI usage bug which meant a processed value was reported as raw. Now reporting scale as well to ensure userspace has the info it needs. - Don't return processed value via the buffer - it doesn't conform to the ABI and will overflow in some cases. - Fix a wrongly sized buffer which would overflow trashing part of the stack. Also move it onto the heap as part of the fix. * bh1780 - a missing return after write in debugfs lead to an incorrect read and a null pointer dereference. - dereferencing the wrong pointer in suspend and resume leading to unpredictable results. - assign a static name to avoid accidentally ending up with no name if loaded via device tree. * bmi160 - output data rate for the accelerometer was incorrectly reported. Fix it. - writing the output data rate was also wrong due to reverse parameters. * bmp280 - error message for wrong chip ID gave the wrong expected value. * hdc100x - mask for writing the integration time was wrong allowin g us to get 'stuck' in a particular value with no way back. - temperature reported in celsius rather than millicelsius as per the ABI. - Get rid of some incorrect data shifting which lead to readings being rather incorrect. * max44000 - drop scale attribute for proximity as it is an unscaled value (depends on what is in range rather than anything knowable at the detector). * st-pressure - ABI compliance fixes - units were wrong. * st-sensors - We introduced some nasty issues with the recent switch over to a a somewhat threaded handler in that we broke using a software trigger with these devices. Now do it properly. It's a larger patch than ideal for a fix, but the logic is straight forward. - Make sure the trigger is initialized before requesting the interrupt. This matters now the interrupt can be shared. Before it was ugly and wrong but short of flakey hardware could not be triggered. - Hammer down the dataready pin at boot - otherwise with really unlucky timing things could get interestingly wedged requiring a hard power down of the chip.
2016-06-03iio: hudmidity: hdc100x: fix incorrect shifting and scalingMatt Ranostay1-8/+8
Shifting sensor data to the right 2 bits was incorrect and caused the scaling values + offsets to be invalid. Reported-by: Alison Schofield <amsfield22@gmail.com> Signed-off-by: Matt Ranostay <mranostay@gmail.com> Tested-by: Alison Schofield <amsfield22@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-03iio: light apds9960: Add the missing dev.parentYong Li1-0/+1
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 <sdliyong@gmail.com> Reviewed-By: Matt Ranostay <mranostay@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-03iio: Fix error handling in iio_trigger_attach_poll_funcCrestez Dan Leonard1-5/+18
When attaching a pollfunc iio_trigger_attach_poll_func will allocate a virtual irq and call the driver's set_trigger_state function. Fix error handling to undo previous steps if any fails. In particular this fixes handling errors from a driver's set_trigger_state function. When using triggered buffers a failure to enable the trigger used to make the buffer unusable. Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-29iio: st_sensors: Disable DRDY at init timeCrestez Dan Leonard1-0/+5
This fixes odd behavior after reboot. The fact that we set the device to powerdown mode is not sufficient to prevent DRDY being active because we might still have an unread sample. Even if powerdown was sufficient keeping DRDY disabled while trigger is not active is a good idea. Cc: Giuseppe Barba <giuseppe.barba@st.com> Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-29iio: st_sensors: Init trigger before irq requestCrestez Dan Leonard1-4/+4
This fixes a possible race where an interrupt arrives before complete initialization and crashes because iio_trigger_get_drvdata returns NULL. Cc: Giuseppe Barba <giuseppe.barba@st.com> Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-29iio: st_sensors: switch to a threaded interruptLinus Walleij11-25/+103
commit 98ad8b41f58dff6b30713d7f09ae3834b8df7ded ("iio: st_sensors: verify interrupt event to status") caused a regression when reading ST sensors from a HRTimer trigger rather than the intrinsic interrupts: the HRTimer may trigger faster than the sensor provides new values, and as the check against new values available as a cause of the interrupt trigger was done in the poll function, this would bail out of the HRTimer interrupt with IRQ_NONE. So clearly we need to only check the new values available from the proper interrupt handler and not from the poll function, which should rather just read the raw values from the registers, put them into the buffer and be happy. To achieve this: switch the ST Sensors over to using a true threaded interrupt handler. In the interrupt thread, check if new values are available, else yield to the (potential) next device on the same interrupt line to check the registers. If the interrupt was ours, proceed to poll the values. Instead of relying on iio_trigger_generic_data_rdy_poll() as a top half to wake up the thread that polls the sensor for new data, have the thread call iio_trigger_poll_chained() after determining that is is the proper source of the interrupt. This is modelled on drivers/iio/accel/mma8452.c which is already using a properly threaded interrupt handler. In order to get the same precision in timestamps as previously, where samples would be timestamped in the poll function pf->timestamp when calling iio_trigger_generic_data_rdy_poll() we introduce a local timestamp in the sensor data, set it in the top half (fastpath) of the interrupt handler and provide that to the core when calling iio_push_to_buffers_with_timestamp(). Additionally: if the active scanmask is not set for the sensor no IRQs should be enabled and we need to bail out with IRQ_NONE. This can happen if spurious IRQs fire when installing the threaded interrupt handler. Tested with hard interrupt triggers on LIS331DL, then also tested with hrtimers on the same sensor by creating a 75Hz HRTimer and using it to poll the sensor. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Cc: Giuseppe Barba <giuseppe.barba@st.com> Cc: Denis Ciocca <denis.ciocca@st.com> Reported-by: Crestez Dan Leonard <cdleonard@gmail.com> Tested-by: Crestez Dan Leonard <cdleonard@gmail.com> Tested-by: Jonathan Cameron <jic23@kernel.org> Fixes: 97865fe41322 ("iio: st_sensors: verify interrupt event to status") Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-29iio: light: bh1780: assign a static nameLinus Walleij1-1/+1
Using the struct i2c_device->id field for naming the light sensor is a bad idea: when booting from the pure device tree this is NULL and that causes the device not to have the "name" property in sysfs and that in turn confuses the "lsiio" command to stop listing devices. So instead of using the device .id, use the hard string "bh1780", which works just fine. Fixes: 1f0477f18306 ("iio: light: new driver for the ROHM BH1780") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-29iio: bh1780: dereference the client properlyLinus Walleij1-2/+4
The code in runtime_[suspend|resume] was assuming that the i2c client data was the bh1780 state container, but it contains the IIO device. So first dereference the IIO device from the i2c client, then get the state container using the iio_priv() call. Fixes: 1f0477f18306 ("iio: light: new driver for the ROHM BH1780") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-29iio: humidity: hdc100x: fix IIO_TEMP channel reportingMatt Ranostay1-1/+1
IIO_TEMP channel was being incorrectly reported back as Celsius when it should have been milliCelsius. This is via an incorrect scale value being returned to userspace. Signed-off-by: Matt Ranostay <mranostay@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-29iio:st_pressure: fix sampling gains (bring inline with ABI)Gregor Boirie1-30/+50
Temperature channels report scaled samples in Celsius although expected as milli degree Celsius in Documentation/ABI/testing/sysfs-bus-iio. Gains are not implemented at all for LPS001WP pressure and temperature channels. This patch ensures that proper offsets and scales are exposed to userpace for both pressure and temperature channels. Also fix a NULL pointer exception when userspace reads content of sysfs scale attribute when gains are not defined. Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-22iio: proximity: as3935: fix buffer stack trashingMatt Ranostay1-2/+4
Buffer wasn't of a valid size to allow the timestamp, and correct padding. This patchset also moves the buffer off the stack, and onto the heap. Cc: george.mccollister@gmail.com Signed-off-by: Matt Ranostay <mranostay@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-22iio: proximity: as3935: remove triggered buffer processingMatt Ranostay1-1/+0
Triggered buffers shouldn't return processed data, and the respective conversion was overflowing the defined .realbits for the channel. Cc: george.mccollister@gmail.com Signed-off-by: Matt Ranostay <mranostay@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-22iio: proximity: as3935: correct IIO_CHAN_INFO_RAW outputMatt Ranostay1-2/+8
IIO_CHAN_INFO_RAW was returning processed data which was incorrect. This also adds the IIO_CHAN_INFO_SCALE value to convert to a processed value. Signed-off-by: Matt Ranostay <mranostay@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-21max44000: Remove scale from proximityCrestez Dan Leonard1-1/+0
This is not implemented and doesn't really make sense because IIO proximity is unit-less. Remove IIO_CHAN_INFO_SCALE from info_mask because so that the _scale sysfs entry won't appear. This fixes userspace tools like generic_buffer which abort when reads returns an error. Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-21iio: humidity: am2315: Remove a stray unlockDan Carpenter1-3/+1
We haven't taken the lock yet so we don't need to unlock here. Fixes: 0d96d5ead3f7 ('iio: humidity: Add triggered buffer support for AM2315') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Tiberiu Breana <tiberiu.a.breana@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-21iio: humidity: hdc100x: correct humidity integration time maskAlison Schofield1-1/+1
Apply the correct mask to enable all available humidity integration times. Currently, the driver defaults to 6500 and all is okay with that. However, if 3850 is selected we get a stuck bit and can't change back to 6500 or select 2500. (Verified with HDC1008) Signed-off-by: Alison Schofield <amsfield22@gmail.com> Cc: Daniel Baluta <daniel.baluta@gmail.com> Reviewed-by: Matt Ranostay <mranostay@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-20Merge tag 'staging-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/stagingLinus Torvalds99-643/+7634
Pull staging and IIO driver updates from Greg KH: "Here's the big staging and iio driver update for 4.7-rc1. I think we almost broke even with this release, only adding a few more lines than we removed, which isn't bad overall given that there's a bunch of new iio drivers added. The Lustre developers seem to have woken up from their sleep and have been doing a great job in cleaning up the code and pruning unused or old cruft, the filesystem is almost readable :) Other than that, just a lot of basic coding style cleanups in the churn. All have been in linux-next for a while with no reported issues" * tag 'staging-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (938 commits) Staging: emxx_udc: emxx_udc: fixed coding style issue staging/gdm724x: fix "alignment should match open parenthesis" issues staging/gdm724x: Fix avoid CamelCase staging: unisys: rename misleading var ii with frag staging: unisys: visorhba: switch success handling to error handling staging: unisys: visorhba: main path needs to flow down the left margin staging: unisys: visorinput: handle_locking_key() simplifications staging: unisys: visorhba: fail gracefully for thread creation failures staging: unisys: visornic: comment restructuring and removing bad diction staging: unisys: fix format string %Lx to %llx for u64 staging: unisys: remove unused struct members staging: unisys: visorchannel: correct variable misspelling staging: unisys: visorhba: replace functionlike macro with function staging: dgnc: Need to check for NULL of ch staging: dgnc: remove redundant condition check staging: dgnc: fix 'line over 80 characters' staging: dgnc: clean up the dgnc_get_modem_info() staging: lustre: lnet: enable configuration per NI interface staging: lustre: o2iblnd: properly set ibr_why staging: lustre: o2iblnd: remove last of kiblnd_tunables_fini ...
2016-05-20Merge tag 'driver-core-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-coreLinus Torvalds2-22/+4
Pull driver core updates from Greg KH: "Here's the "big" driver core update for 4.7-rc1. Mostly just debugfs changes, the long-known and messy races with removing debugfs files should be fixed thanks to the great work of Nicolai Stange. We also have some isa updates in here (the x86 maintainers told me to take it through this tree), a new warning when we run out of dynamic char major numbers, and a few other assorted changes, details in the shortlog. All have been in linux-next for some time with no reported issues" * tag 'driver-core-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (32 commits) Revert "base: dd: don't remove driver_data in -EPROBE_DEFER case" gpio: ws16c48: Utilize the ISA bus driver gpio: 104-idio-16: Utilize the ISA bus driver gpio: 104-idi-48: Utilize the ISA bus driver gpio: 104-dio-48e: Utilize the ISA bus driver watchdog: ebc-c384_wdt: Utilize the ISA bus driver iio: stx104: Utilize the module_isa_driver and max_num_isa_dev macros iio: stx104: Add X86 dependency to STX104 Kconfig option Documentation: Add ISA bus driver documentation isa: Implement the max_num_isa_dev macro isa: Implement the module_isa_driver macro pnp: pnpbios: Add explicit X86_32 dependency to PNPBIOS isa: Decouple X86_32 dependency from the ISA Kconfig option driver-core: use 'dev' argument in dev_dbg_ratelimited stub base: dd: don't remove driver_data in -EPROBE_DEFER case kernfs: Move faulting copy_user operations outside of the mutex devcoredump: add scatterlist support debugfs: unproxify files created through debugfs_create_u32_array() debugfs: unproxify files created through debugfs_create_blob() debugfs: unproxify files created through debugfs_create_bool() ...
2016-05-19Merge branch 'i2c/for-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds4-59/+26
Pull i2c updates from Wolfram Sang: - Peter Rosin did some major rework on the locking of i2c muxes by seperating parent-locked muxes and mux-locked muxes. This avoids deadlocks/workarounds when the mux itself needs i2c commands for muxing. And as a side-effect, other workarounds in the media layer could be eliminated. Also, Peter stepped up as the i2c mux maintainer and will keep an eye on these changes. - major updates to the octeon driver - add a helper to the core to generate the address+rw_bit octal and make drivers use it - quite a bunch of driver updates * 'i2c/for-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (84 commits) i2c: rcar: add DMA support i2c: st: Implement bus clear i2c: only check scl functions when using generic recovery i2c: algo-bit: declare i2c_bit_quirk_no_clk_stretch as static i2c: tegra: disable clock before returning error [media] rtl2832: regmap is aware of lockdep, drop local locking hack [media] rtl2832_sdr: get rid of empty regmap wrappers [media] rtl2832: change the i2c gate to be mux-locked [media] si2168: change the i2c gate to be mux-locked iio: imu: inv_mpu6050: change the i2c gate to be mux-locked i2c: mux: document i2c muxes and elaborate on parent-/mux-locked muxes i2c: mux: relax locking of the top i2c adapter during mux-locked muxing i2c: muxes always lock the parent adapter i2c: allow adapter drivers to override the adapter locking i2c: uniphier: add "\n" at the end of error log i2c: mv64xxx: remove CONFIG_HAVE_CLK conditionals i2c: mv64xxx: use clk_{prepare_enable,disable_unprepare} i2c: mv64xxx: handle probe deferral for the clock i2c: mv64xxx: enable the driver on ARCH_MVEBU i2c: octeon: Add workaround for broken irqs on CN3860 ...
2016-05-14iio: pressure: bmp280: fix error message for wrong chip idAkinobu Mita1-2/+2
The bmp280 driver also supports BMP180 which has a different chip id with BMP280. The probe routine verifies that the device reports the correct chip id but the error message is confusing as if BMP280's chip id is always expected. Reported-by: Matt Ranostay <mranostay@gmail.com> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: Matt Ranostay <mranostay@gmail.com> Cc: Vlad Dogaru <vlad.dogaru@intel.com> Cc: Christoph Mair <christoph.mair@gmail.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-09Merge 4.6-rc7 into staging-nextGreg Kroah-Hartman2-3/+5
This fixes some merge issues with some iio drivers that were found in linux-next. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-05-04iio: imu: inv_mpu6050: change the i2c gate to be mux-lockedPeter Rosin1-42/+10
The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the code that makes the unlocked i2c accesses and just use ordinary regmap_write accesses. This also happens to fix the deadlock described in http://patchwork.ozlabs.org/patch/584776/ authored by Adriana Reus <adriana.reus@intel.com> and submitted by Daniel Baluta <daniel.baluta@intel.com> ----------8<---------- iio: imu: inv_mpu6050: Fix deadlock between i2c adapter lock and mpu lock This deadlock occurs if the accel/gyro and the sensor on the auxiliary I2C (in my setup it's an ak8975) are working at the same time. Scenario: T1 T2 ==== ==== inv_mpu6050_read_fifo aux sensor op (eg. ak8975_read_raw) | | mutex_lock(&indio_dev->mlock) i2c_transfer | | i2c transaction i2c adapter lock | | i2c adapter lock i2c_mux_master_xfer | inv_mpu6050_select_bypass | mutex_lock(&indio_dev->mlock) When we operate on an mpu sensor the order of locking is mpu lock followed by the i2c adapter lock. However, when we operate the auxiliary sensor the order of locking is the other way around. ... ----------8<---------- The reason this patch fixes the deadlock is that T2 does not grab the i2c adapter lock until the very end (and grabs the newfangled i2c mux lock where it previously grabbed the i2c adapter lock). Acked-by: Jonathan Cameron <jic23@kernel.org> Acked-by: Daniel Baluta <daniel.baluta@intel.com> Tested-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2016-05-04iio: light: bh1780: return after writeLinus Walleij1-1/+1
When writing a value using direct reg access from debugfs we need to return and not fall through to reading the value, lest we'll dereference a NULL pointer. Cc: Dan Carpenter <dan.carpenter@oracle.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-04iio: dac: ad5592r: Off by one bug in ad5592r_alloc_channels()Dan Carpenter1-1/+1
The > here should be >= or we go beyond the end for the array. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-04iio: bmi160: Fix ODR settingDaniel Baluta1-2/+2
mask and val parameters of regmap_update_bits were reveresed. Fixes: 77c4ad2d6a9 ("iio: imu: Add initial support for Bosch BMI160") Signed-off-by: Daniel Baluta <daniel.baluta@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-04iio: bmi160: Fix output data rate for accelDaniel Baluta1-6/+6
Format is INT_PLUS_MICRO and micro odr part of ODR should be parts of a micro. Also s/8000/800 this is obviously a typo. Fixes: 77c4ad2d6a9 ("iio: imu: Add initial support for Bosch BMI160") Signed-off-by: Daniel Baluta <daniel.baluta@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-04iio: imu: mpu6050: Fix name/chip_id when using ACPIDaniel Baluta1-3/+26
When using ACPI, id is NULL and the current code automatically defaults name to NULL and chip id to 0. We should instead use the data provided in the ACPI device table. Fixes: c816d9e7a57b ("iio: imu: mpu6050: fix possible NULL dereferences") Signed-off-by: Daniel Baluta <daniel.baluta@intel.com> Reviewed-By: Matt Ranostay <matt.ranostay@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-04iio: imu: mpu6050: fix possible NULL dereferencesMatt Ranostay2-2/+4
Fix possible null dereferencing of i2c and spi driver data. Signed-off-by: Matt Ranostay <matt.ranostay@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-02iio: stx104: Utilize the module_isa_driver and max_num_isa_dev macrosWilliam Breathitt Gray1-21/+3
The Apex Embedded Systems STX104 DAC drivers does not do anything special in module init/exit. This patch eliminates the module init/exit boilerplate code by utilizing the module_isa_driver macro. Additionally, the max_num_isa_dev macro is utilized to simplify the determination of maximum possible STX104 devices in the system. Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-05-02iio: stx104: Add X86 dependency to STX104 Kconfig optionWilliam Breathitt Gray1-1/+1
The Apex Embedded Systems STX104 DAC driver expects the STX104 device to be I/O port-mapped addressable on an X86 platform. This patch adds an explicit X86 dependency to the STX104 configuration option to prevent building on non-X86 architectures. Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-04-26Merge tag 'iio-for-4.7b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-testingGreg Kroah-Hartman72-401/+5491
Jonathan writes: 2nd set of new device support, features and cleanup for IIO in the 4.7 cycle. Bit of a bumper set for new drivers but plenty of other stuff here as well! New device support * ad5592R ADC/DAC - new driver supporting ad5592r and ad5593r combined ADC/DAC and gpio chips. * Aosong am2315 relative humidity - new driver with triggered buffer support in follow up patch. * bmi160 imu - new driver * bmp280 - bmp180 support - note there is support in the misc/bmp085 driver. Intent is to remove that driver long term. * invensense mpu6050 - cleanup leading to explicit support of mpu9150 with a good few cleanups along the way. * Hope RF hp03 pressure and temperature sensor. - new driver * maxim DS1803 potentiometer - new driver * maxim max44000 light and proximity sensor - new driver built in a series of steps to support pretty much everything. * ROHM BH1780 light sensor - new driver. There is an existing driver in misc that this is pretty much intended to replace. The discussion on whether to support the non standard interface of that driver is some way is continuing. * st-gyro - lsm9ds0-gyro. The accel/magn side of this will take a while longer as extensions to the st library are needed for cases where two types of sensor share a single i2c address. * ti-adc081c - support the adc101c and adc121c * Vishay VEML6070 UV sensor - new driver. New features * core - devm_ APIs for channel_get and channel_get_all. The first user of these is the generic ADC based thermal driver. As it is going through the thermal tree these will be picked up as a patch to that next cycle as that is how the author preferred to do it. - mounting matrix support. This new core support allows devices to provide to userspace (typically from the device tree) allowing compensation for how the sensor is mounted on the device. First examples are on UAVs but it has a more mundane use on typical phone where the chip may be on the front or the back of the circuit board and soldered at any angle. Includes support for this ABI in ak8975 (which has an older interface, now deprecated) and mpu6050. * tools - add a -a option to enable all available channels in generic_buffer sample. Makes it somewhat easier to use. * adis library and drivers - support manual self test flag clearing. This has technically been broken for a very long time - result is an offset on readings as the applied field is on all the time. * ak8975 - triggered buffer support * bmc150 - spi support (including splitting the driver into core and i2c parts) * bmp280 - oversampling support. * dht11 - improved logging - useful to debug timing issues on this quirky device. * st-sensors - read each channel invidivually as not all support the optimization of reading in bulk. This is technically a fix, but will need to be backported if desired. - support open drain and shared interrupts. * ti-adc081c - triggered buffer support. Cleanups * inkern - white space fix. * ad7606 - use the iio_device_claim_direct_mode call rather than open coding equiv. * ad799x - white space fix. * ad9523 - unsigned -> unsigned int * apds9660 - brace location tidying up. - silence an uninitialized variable warning. * ak8975 - else and brace on same line fix. * at91_adc - white space fixes. * bmc150 - use regmap stored copy of the device pointer rather than having an additional copy. * bmg160 - use regmap stored copy of the device pointer rather than having an additional copy. * hid-sensors - white space fixes. * mcp3422 - white space fix. * mma7455 - use regmap to retrieve the device struct rather than carrying another copy in the private data. * ms_sensors - white space fix. * mxs-lradc - move current bindings out of staging - some will be shortly deprecated but the reality is that we have device trees out there using them so they will need to be supported for some time. They accidentally got left behind when the driver graduated from staging. - white space cleanup. - set INPUT_PROP_DIRECT. - move ts config into a better function. - move the STMP reset out of the ADC init. * vf610_adc - case label indenting fix.
2016-04-25iio: inv_mpu6050: Add explicit support for MPU9150Crestez Dan Leonard5-6/+14
This device is a package containing a MPU6050-like sensor and an AK8975 magnetometer. The magnetometer component is supported by the existing ak8975 driver. This patch also rephrases the Kconfig descriptions. Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Acked-by: Ge Gao <ggao@invensense.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-04-25iio: inv_mpu6050: Add spi_device_id for INV_MPU6500Crestez Dan Leonard1-0/+1
Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Acked-by: Ge Gao <ggao@invensense.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-04-25iio: inv_mpu6050: Check WHO_AM_I register on probeCrestez Dan Leonard2-0/+23
This can be used to distinguish mpu6500. This is a warning rather than an error because the differences are mostly irrelevant and it's nice to avoid breaking users with slightly incorrect ACPI/DT. Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Acked-by: Ge Gao <ggao@invensense.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-04-25iio: inv_mpu6050: Remove inv_mpu6050_hw.num_regCrestez Dan Leonard2-5/+0
This field was unused and incorrect for mpu6500. Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-04-25iio: inv_mpu6050: Cleanup hw_info mappingCrestez Dan Leonard3-6/+29
The hw_info array was indexed by enum inv_devices chip_type despite the fact that the enumeration had more members than the array and was ordered differently. The patch cleans this up and adds explicit chip_types to i2c/spi/acpi IDs. It also adds some stricter checks inside the driver core. This happened to work so far because the differences between the supported models are very minor. Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Acked-by: Ge Gao <ggao@invensense.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-04-25iio: pressure: bmp280: add ability to control oversampling rateAkinobu Mita1-18/+185
This adds ability to control the oversampling ratio of the temperature and pressure measurement for both bmp180 and bmp280. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Acked-by: Vlad Dogaru <vlad.dogaru@intel.com> Cc: Christoph Mair <christoph.mair@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-04-25iio: pressure: bmp280: add support for BMP180Akinobu Mita2-17/+357
This adds support for the BMP180 to the bmp280 iio driver. The BMP180 has already been supported by misc/bmp085 driver but it doesn't use iio framework. This change adds the kconfig dependency not to be selected both of them in order to avoid any issues. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Acked-by: Vlad Dogaru <vlad.dogaru@intel.com> Cc: Christoph Mair <christoph.mair@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-04-24max44000: Initial triggered buffer supportCrestez Dan Leonard1-0/+62
Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-04-24max44000: Expose ambient sensor scalingCrestez Dan Leonard1-5/+162
This patch exposes ALSTIM as illuminance_integration_time and ALSPGA as illuminance_scale. Changing ALSTIM also changes the number of bits available in the data register. This is handled inside raw value reading because: * It's very easy to shift a few bits * It allows SCALE and INT_TIME to be completely independent controls * Buffer support requires constant scan_type.realbits per-channel Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-04-24max44000: Support controlling LED current outputCrestez Dan Leonard1-0/+53
This is exposed as an output channel with "led" as an extend_name. Other sensors also have support for controlling an external LED. It's not clear that simply exposing an undecorated output channel is the correct approach. Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>