summaryrefslogtreecommitdiff
path: root/drivers/iio
AgeCommit message (Collapse)Author
2016-07-03iio: Add driver for Broadcom iproc-static-adcRaveendra Padasalagi
This patch adds basic driver implementation for Broadcom's static adc controller used in iProc SoC's family. Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com> Reviewed-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-07-03iio: pressure: bmp280: read calibration data onceLinus Walleij
The calibration data is described as coming from an E2PROM and that means it does not change. Just read it once at probe time and store it in the device state container. Also toss the calibration data into the entropy pool since it is device unique. Reviewed-by: Vlad Dogaru <vlad.dogaru@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-07-03iio: pressure: bmp280: add power managementLinus Walleij
The PM280 has an internal standby-mode, but to really save power we should shut the sensor down and disconnect the power. With the proper .pm hooks we can enable both runtime and system power management of the sensor. We use the *force callbacks from the system PM hooks. When the sensor comes back we always reconfigure it to make sure it is ready to roll as expected. Cc: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-07-03iio: pressure: bmp280: add support for BMP085 EOC interruptLinus Walleij
The first version of this sensor, BMP085, supports sending an End-of-Conversion (EOC) interrupt. Add code to support this using a completion, in a similar vein as drivers/misc/bmp085.c does. Make sure to check that we are given a rising edge, because the EOC line goes from low-to-high when the conversion is ready. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-07-03iio: pressure: bmp280: add SPI interface driverLinus Walleij
This patch mimics the SPI functionality found in the misc driver in drivers/misc/bh085-spi.c to make it possible to reuse the existing BMP280/BMP180/BMP085 driver with all clients of the other driver. The adoption is straight-forward since like the other driver, it is a simple matter of using regmap. This driver is also so obviously inspired/copied from the old misc driver in drivers/misc/bmp085.c that I just took the liberty to add in the authors of the other drivers + self in the core driver file. The MISC driver also supports a variant named "BMP181" so include that here to be complete in comparison to the old driver. The bus mapping code for SPI was written by Akinobu Mita. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Tested-by: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-07-03iio: pressure: bmp280: split off an I2C Kconfig entryLinus Walleij
This creates a separate BMP280_I2C Kconfig entry that gets selected by BMP280 for I2C transport. As we currently only support I2C transport there is not much practical change other than getting a separate object file (or module) for the I2C driver part. The old Kconfig symbol BMP280 will still select the stuff we need so that oldconfig and old defconfigs works fine. Tested-by: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-07-03iio: pressure: bmp280: split driver in logical partsLinus Walleij
This splits the BMP280 driver in three logical parts: the core driver bmp280-core that only operated on a struct device * and a struct regmap *, the regmap driver bmp280-regmap that can be shared between I2C and other transports and the I2C module driver bmp280-i2c. Cleverly bake all functionality into a single object bmp280.o so that we still get the same module binary built for the device in the end, without any fuzz exporting symbols to the left and right. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-07-03iio: pressure: bmp280: support supply regulatorsLinus Walleij
The BMP085/BMP180/BMP280 is supplied with two power sources: VDDA (analog power) and VDDD (digital power). As these may come from regulators (as on the APQ8060 Dragonboard) we need the driver to attempt to fetch and enable these regulators. We FAIL if we cannot: boards should either define: - Proper regulators if present - Define fixed regulators if power is hardwired to the component - Rely on dummy regulators (will be present on all DT systems and any boardfile system that calls regulator_has_full_constraints(). Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-07-03drivers:iio:light:isl29125: added macros for sensing rangeBijosh Thykkoottathil
Added macros for sensing range as the corresponding magic numbers were used at multiple places. - ISL29125_SENSING_RANGE_0 for 375 lux full range - ISL29125_SENSING_RANGE_1 for 10k lux full range Signed-off-by: Bijosh Thykkoottathil <bijosh.t@hotmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-07-02iio: st_sensors: harden interrupt handlingLinus Walleij
Leonard Crestez observed the following phenomenon: when using hard interrupt triggers (the DRDY line coming out of an ST sensor) sometimes a new value would arrive while reading the previous value, due to latencies in the system. We discovered that the ST hardware as far as can be observed is designed for level interrupts: the DRDY line will be held asserted as long as there are new values coming. The interrupt handler should be re-entered until we're out of values to handle from the sensor. If interrupts were handled as occurring on the edges (usually low-to-high) new values could appear and the line be held asserted after that, and these values would be missed, the interrupt handler would also lock up as new data was available, but as no new edges occurs on the DRDY signal, nothing happens: the edge detector only detects edges. To counter this, do the following: - Accept interrupt lines to be flagged as level interrupts using IRQF_TRIGGER_HIGH and IRQF_TRIGGER_LOW. If the line is marked like this (in the device tree node or ACPI table or similar) it will be utilized as a level IRQ. We mark the line with IRQF_ONESHOT and mask the IRQ while processing a sample, then the top half will be entered again if new values are available. - If we are flagged as using edge interrupts with IRQF_TRIGGER_RISING or IRQF_TRIGGER_FALLING: remove IRQF_ONESHOT so that the interrupt line is not masked while running the thread part of the interrupt. This way we will never miss an interrupt, then introduce a loop that polls the data ready registers repeatedly until no new samples are available, then exit the interrupt handler. This way we know no new values are available when the interrupt handler exits and new (edge) interrupts will be triggered when data arrives. Take some extra care to update the timestamp in the poll loop if this happens. The timestamp will not be 100% perfect, but it will at least be closer to the actual events. Usually the extra poll loop will handle the new samples, but once in a blue moon, we get a new IRQ while exiting the loop, before returning from the thread IRQ bottom half with IRQ_HANDLED. On these rare occasions, the removal of IRQF_ONESHOT means the interrupt will immediately fire again. - If no interrupt type is indicated from the DT/ACPI, choose IRQF_TRIGGER_RISING as default, as this is necessary for legacy boards. Tested successfully on the LIS331DL and L3G4200D by setting sampling frequency to 400Hz/800Hz and stressing the system: extra reads in the threaded interrupt handler occurs. Cc: Giuseppe Barba <giuseppe.barba@st.com> Cc: Denis Ciocca <denis.ciocca@st.com> Tested-by: Crestez Dan Leonard <cdleonard@gmail.com> Reported-by: Crestez Dan Leonard <cdleonard@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-30iio: magn: ak8975: deploy runtime and system PMLinus Walleij
This adds runtime PM support to the AK8975 driver. It solves two problems: - After reading the first value the chip was left in MODE_ONCE, meaning (presumably) it may be consuming more power. Now the runtime PM hooks kick in and set it to POWER_DOWN. - Regulators were simply enabled and left on, making it impossible to turn the power consuming regulators off because of the increased refcount. We now disable the regulators at autosuspend. - We also handle system suspend: by using pm_runtime_force_suspend() and pm_runtime_force_resume() from the system PM sleep hooks, the runtime PM code is managing the power also for this case. It is currently not completely optimal: when the system resumes the AK8975 goes into active mode even if noone is going to use it: currently the force calls need to be paired, but the runtime PM people are working on making it possible to leave devices runtime suspended when coming back from sleep. Inspired by my work on the BH1780 light sensor driver. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-30iio: magn: ak8975: make sure to power down at remove()Linus Walleij
The code was not powering the magnetometer down properly at remove(): just cutting the regulators without first setting the device in power off mode. Fix this. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-30iio: magn: ak8975: allow a delay after enabling regulatorsLinus Walleij
The datasheet actually specifies that we need to wait atleast 500us after powering on the device before trying to set mode. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-30iio: magn: ak8975: refactor regulator handlersLinus Walleij
Move the regulator_get() calls directly into the probe() function, keep only the power_on()/power_off() functions to flick the regulators on/off. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-30iio: magn: ak8975: add Vid regulatorLinus Walleij
The AK8975 has two power sources: Vdd (analog voltage supply) and Vid (digital voltage supply). Optionally also obtain the Vid supply regulator and enable it. If an error occurs when enabling one of the regulators: bail out. Cc: Gregor Boirie <gregor.boirie@parrot.com> Cc: Richard Leitner <dev@g0hl1n.net> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-30iio: magn: ak8975: fix regulator usageLinus Walleij
IS_ERR_OR_NULL() should never be used with regulators because a NULL pointer may be a perfectly valid dummy regulator We should always succeed to fetch and enable a regulator, but it may be a dummy. That is fine, so bail out for any real errors or probe deferrals Include the error code in the warning print so we know what kind of problem we're dealing with (for example it is nice to see if it is a probe deferral). As we will bail out of probe if the regulator is erroneous, just issue regulator_disable() on the poweroff path: it will succeed. Cc: Mark Brown <broonie@kernel.org> Cc: Lars-Peter Clausen Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-30iio: pressure: bmp280: add reset GPIO line handlingLinus Walleij
On the APQ8060 Dragonboard the reset line to the BMP085 pressure sensor is not deasserted on boot, so the driver needs to handle this. For a simple GPIO line supplied as a descriptor (from a board file, device tree or ACPI) this does the trick. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-30iio: pressure: bmp280: support device tree initializationLinus Walleij
This adds device tree support to the BMP085, BMP180 and BMP280 pressure sensors. Tested on the Qualcomm APQ8060 Dragonboard: iio:device1$ cat in_temp_input 26700 iio:device1$ cat in_pressure_input 99.185000000 Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-30iio:core: timestamping clock selection supportGregor Boirie
Adds a new per-device sysfs attribute "current_timestamp_clock" to allow userspace to select a particular POSIX clock for buffered samples and events timestamping. Following clocks, as listed in clock_gettime(2), are supported: CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME and CLOCK_TAI. Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com> Acked-by: Sanchayan Maity <maitysanchayan@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-29Merge tag 'iio-for-4.8b' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: Second round of new iio device support, features and cleanups in the 4.8 cycle Firstly some contact detail updates: * NXP took over freescale. Update the mma8452 header to reflect this. * Martin Kepplinger email address change in mma8452 header. * Adriana Reus has changed email address. Update .mailmap. * Matt Ranostay has changed email address. Update .mailmap. New Device Support * max1363 - add the missing i2c_device_ids for a couple of parts so they can actually be used. * ms5867 - add device ids for ms5805 and ms5837 parts. New Features * ad5755 - DT support. This one was a bit controversial and under review for a long time. Still no one could come up with a better solution. * stx104 - add gpio support * ti-adc081c - Add ACPI device ID matching. Core changes * Refuse to register triggers with duplicate names. There is no way to distinguish between them so this makes no sense. A few drivers do not generate unique names for each instance of the device present. We can't fix this without changing ABI so leave them and wait for someone to actually take the rare step of two identical accelerometers on the same board. * buffer-dma - use ARRAY_SIZE in a few appropriate locations. Tools * Fix the fact that the --trigger-num option in generic_buffer didn't allow 0 which is perfectly valid in the ABI. Cleanups * as3935 - improve error reporting. - remove redundant zeroing of a field in iio_priv. * gp2ap020a00f - use the iio_device_claim_*_mode helpers rather than open coding locking around mode changes. * isl29125 - use the iio_device_claim_*_mode helpers rather than open coding locking. * lidar - use the iio_device_claim_*_mode helpers rather than open coding locking. * mma8452 - more detail in devices supported description in comments (addresses and similar) * sca3000 - add a missing error check. * tcs3414 - use the iio_device_claim_*_mode helpers rather than open coding locking. * tcs3472 - use the iio_device_claim_*_mode helpers rather than open coding locking.
2016-06-27iio: ad5755: add support for dt bindingsSean Nyekjaer
Devicetree can provide platform data Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-27iio: buffer-dma: Use ARRAY_SIZE in for loop rangePhil Reid
Use the ARRAY_SIZE macro in the for loops that access queue->fileio.blocks. Macro is already used in a couple of places where this access occurs, but range was hardcoded in these locations. Signed-off-by: Phil Reid <preid@electromag.com.au> Acked-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-27iio: adc: max1363: Fix missing i2c_device_id for MAX1164x partsFlorian Vaussard
The driver supports MAX11644, MAX11645, MAX11646 and MAX11647 parts. But the corresponding i2c_device_id are missing. Add them! Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-27iio: proximity: as3935: remove redundant zeroing of tune_capMatt Ranostay
This is redundant as the containing stucture is allocated as part of iio_device_alloc using kzalloc and hence is already 0. Signed-off-by: Matt Ranostay <mranostay@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-27iio: stx104: Add GPIO support for the Apex Embedded Systems STX104William Breathitt Gray
The Apex Embedded Systems STX104 device features eight lines of digital I/O (four digital inputs and four digital outputs). This patch adds GPIO support for these eight lines of digital I/O via GPIOLIB. Cc: Alexandre Courbot <gnurou@gmail.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-27iio: as3935: improve error reporting in as3935_event_workArnd Bergmann
gcc warns about a potentially uninitialized variable use in as3935_event_work: drivers/iio/proximity/as3935.c: In function ‘as3935_event_work’: drivers/iio/proximity/as3935.c:231:6: error: ‘val’ may be used uninitialized in this function [-Werror=maybe-uninitialized] This case specifically happens when spi_w8r8() fails with a negative return code. We check all other users of this function except this one. As the error is rather unlikely to happen after the device has already been initialized, this just adds a dev_warn(). Another warning already exists in the same function, but is missing a trailing '\n' character, so I'm fixing that too. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Matt Ranostay <mranostay@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-27iio: adc: ti-adc081c: add ACPI device ID matchingDan O'Donovan
Add ACPI device ID matching for TI ADC081C/ADC101C/ADC121C ADCs. Signed-off-by: Dan O'Donovan <dan@emutex.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-27iio: Refuse to register triggers with duplicate namesCrestez Dan Leonard
The trigger name is documented as unique but drivers are currently allowed to register triggers with duplicate names. This should be considered a bug since it makes the 'current_trigger' interface unusable. Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-26iio:ad7266: Fix probe deferral for vrefMark Brown
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 Brown
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 Brown
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 Walleij
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 ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus 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-20Merge 4.7-rc4 into staging-nextGreg Kroah-Hartman
We want the fixes in here, and we can resolve a merge issue in drivers/iio/industrialio-trigger.c Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-18Merge tag 'staging-4.7-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging 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 Gray
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: ms5637 Add Measurement Specialties explicit MS5805 and MS5837 supportMarkezana, William
Signed-off-by: William Markezana <william.markezana@meas-spec.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-11iio: mma8452: update Freescale company informationMartin Kepplinger
NXP took over Freescale, so add NXP to the driver descriptions Signed-off-by: Martin Kepplinger <martink@posteo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-11iio: mma8452: update device description in header commentsMartin Kepplinger
Signed-off-by: Martin Kepplinger <martink@posteo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-11iio: mma8452: update contact information for Martin KepplingerMartin Kepplinger
Signed-off-by: Martin Kepplinger <martink@posteo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-11iio: inv_mpu6050: Fix use-after-free in ACPI codeCrestez Dan Leonard
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-11iio: light: gp2ap020a00f: use iio helper function to lock direct modeAlison Schofield
Replace the code that guarantees the device stays in direct mode with iio_device_claim_direct_mode() which does same. Includes a tiny bit of refactoring (single case -> if) and simplified return flow. Also prevents a theoretical race condition by effectively taking the lock a little earlier than before. Signed-off-by: Alison Schofield <amsfield22@gmail.com> Cc: Daniel Baluta <daniel.baluta@gmail.com> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-11iio: light: isl29125: use iio helper function to guarantee direct modeAlison Schofield
Replace the code that guarantees the device stays in direct mode with iio_device_claim_direct_mode() which does same. This allows removal of an unused lock in the device private global data. Signed-off-by: Alison Schofield <amsfield22@gmail.com> Cc: Daniel Baluta <daniel.baluta@gmail.com> Acked-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-11iio: light: tcs3472: use iio helper function to guarantee direct modeAlison Schofield
Replace the code that guarantees the device stays in direct mode with iio_device_claim_direct_mode() which does same. This allows removal of an unused lock in the device private global data. Also prevents a previous race condition when a buffer is enabled whilst a raw read is going on. Signed-off-by: Alison Schofield <amsfield22@gmail.com> Cc: Daniel Baluta <daniel.baluta@gmail.com> Acked-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-11iio: light: tcs3414: use iio helper function to guarantee direct modeAlison Schofield
Replace the code that guarantees the device stays in direct mode with iio_device_claim_direct_mode() which does same. This allows removal of an unused lock in the device private global data. Also prevents a possible race around a buffer being enabled whilst a read is going on. Signed-off-by: Alison Schofield <amsfield22@gmail.com> Cc: Daniel Baluta <daniel.baluta@gmail.com> Acked-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-11iio: proximity: lidar: switch to iio_device_claim_*_mode helpersMatt Ranostay
Switch from using indio_dev->mlock to the iio_device_claim_*_mode helper functions. Signed-off-by: Matt Ranostay <mranostay@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-09Merge tag 'iio-for-4.8a' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: First round of IIO new device support, features and cleanups for the 4.8 cycle. New device support * ads1015 - add ads1115 support * bma220 accelerometer - new driver - triggered buffer support. * bmc150 - add bmm150 support. * bmp280 - bme280 support with addition of humidity channel. * max5487 potentiometer - new driver * MMA7660FC accelerometer. - New driver * st-pressure - support for the lps22hb * loop trigger. - This one is *nasty* but we have real applications (parrot drones) where it is useful. The trigger basically spins as hard as it can firing off a new trigger each time all triggered devices come back to say they are done. It doesn't hang a machine even when doing it on a dummy driver. A lot nicer than having this implemented within lots of device drivers anyway. Core stuff * Add support to create IIO devices via configfs (similar to we did for triggers a while back) + docs. * New channel types - IIO_ELECTRICAL_CONDUCTIVITY * Couple of MAINTAINERS patches to list the device tree bindings. * Make trigger ops structure non optional (comment fix). It hasn't been for an awful long time, but that's not what the description said. New features * ak8975 - support adapters that are limited to byte data only by allowing the emulated block read i2c function that was recently introduced. * atlas-ph - support atlas-ec (electrical conductivity sensor) * bmi160 - add available frequency and scale attributes to make the driver more user friendly (and avoid having to read the datasheet to know what will work). * dummy - move creation to configfs interface. It's not real hardware so we are not that worried about the ABI breakage ;) * mma8452 - oversampling ration support * nau7802 - expose available gains to make life easier for userspace. * st-sensors - allow use of emulation for SMBus block reads as all the st parts support it. * ti-ads1015 - list datasheet names to allow their use by inkernel consumers. * Various module alias additions to help auto probing. Drop one redundant one as well. Cleanups * ad7266, ad7476, ad7887, ad7923, ad799x - use direct mode claim function rather than open coding it during sensor read (prevents switching on buffers mid read). * ad7793, ad7791 - use direct mode claim to prevent frequency changes when buffers running. * afe440x - These are ABI breaking but the driver requires custom userspace code to do anything useful anyway and that is still being written and under control of TI. Ultimately we may have other libraries to do pulse oximetry with these devices but we aren't aware of any yet. - kernel-doc format fixes - drop ifdef fun around of_match_ptr - it's not worth the mess to save a tiny amount of space. - drop some unnecessary register initializations. - drop the weird locked gain modes as they gain us nothing (can just set all gains separately). - remove handling of offset attributes seeing as no channels actually have them (oops) - Drop the LED3 input channel as it's an alias for ALED2. - *big one* remove channel names - an experiment that turned out to not make sense - see patch for details. - use regmap fields to clean up code. - tie the tia gain stages to appropriate channels in the ABI as that is what they really effect. Same with the LED currents. - cleanout some unused defines and fix a missnamed one. * atlas-ph - reorganise to allow support of other similar parts. * bmc150 - document supported chips in kconfig help. * jsa1212 - drop an unneeded i2c functionality check for functionality the driver doesn't use. * mxs-lradc - simply touch screen registration code. - remove the touch screen unregister as all devm based now. - disable only those channels that are masked in hardware stop (others are already dealt with elsewhere) * st-sensors - unexport st_sensors_get_buffer_element as nothing outside the st-sensors core driver uses it. - fix handling of failure to start up regulators. * tpl0102 - drop an i2c functionality test for features that aren't needed. * ti-am335x - use variable name rather than type in sizeof for clarity. - use SIMPLE_DEV_PM_OPS helper macro to tidy up a bit. Tools * Add install / uninstall to makefile. Someone cares, so presumably some people will find it useful! * generic_buffer - rename to iio_generic_buffer to line up with other tools. - handle cleanup when receiving signals - Add a --device-num option and a --trigger-num option rather than relying on naming which doesn't work if you have two of the same part.
2016-06-07Merge tag 'iio-fixes-for-4.7a' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus 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 Ranostay
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:trigger: Experimental kthread tight loop trigger (thread only)Jonathan Cameron
This patch is in response to that of Gregor Boirie <gregor.boirie@parrot.com> who proposed using a tight kthread within a device driver (be it with the support factored out into a helper library) in order to basically spin as fast as possible. It is meant as a talking point rather than a formal proposal of the code (though we are heading towards that I think). Also gives people some working code to mess around with. I proposed that this could be done with a trigger with a few constraints and this is the proof (be it ugly) of that. There are some constraints though, some of which we would want to relax if this were to move forward. * Will only run the thread part of the registered pollfunc. This is to avoid the overhead of jumping in and out of interrupt context. Is the overhead significant? Not certain but feels like it should be! * This limitation precludes any device that 'must' do some work in interrupt context. However, that is true of few if any drivers and I suspect that any that do will be restricted to using triggers they provide themselves. Usually we have a top half mainly to grab a timestamp as soon after the dataready type signal as possible. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Acked-by: Daniel Baluta <daniel.baluta@intel.com>