summaryrefslogtreecommitdiff
path: root/drivers/iio
AgeCommit message (Collapse)Author
2016-04-20iio: gyro: bmg160: fix endianness when reading axesIrina Tirdea
commit 95e7ff034175db7d8aefabe7716c4d42bea24fde upstream. For big endian platforms, reading the axes will return invalid values. The device stores each axis value in a 16 bit little endian register. The driver uses regmap_read_bulk to get the axis value, resulting in a 16 bit little endian value. This needs to be converted to cpu endianness to work on big endian platforms. Fix endianness for big endian platforms by converting the values for the axes read from little endian to cpu. This is also partially fixed in commit 82d8e5da1a33 ("iio: accel: bmg160: optimize transfers in trigger handler"). Signed-off-by: Irina Tirdea <irina.tirdea@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-04-20iio: gyro: bmg160: fix buffer read valuesIrina Tirdea
commit b475c59b113db1e66eb9527ffdec3c5241c847e5 upstream. When reading gyroscope axes using iio buffers, the values returned are always 0. In the interrupt handler, the return value of the read operation is returned to the user instead of the value read. Return the value read to the user. This is also fixed in commit 82d8e5da1a33 ("iio: accel: bmg160: optimize transfers in trigger handler"). Signed-off-by: Irina Tirdea <irina.tirdea@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-04-20iio: accel: bmc150: fix endianness when reading axesIrina Tirdea
commit 2215f31dc6f88634c1916362e922b1ecdce0a6b3 upstream. For big endian platforms, reading the axes will return invalid values. The device stores each axis value in a 16 bit little endian register. The driver uses regmap_read_bulk to get the axis value, resulting in a 16 bit little endian value. This needs to be converted to cpu endianness to work on big endian platforms. Fix endianness for big endian platforms by converting the values for the axes read from little endian to cpu. This is also partially fixed in commit b6fb9b6d6552 ("iio: accel: bmc150: optimize transfers in trigger handler"). Signed-off-by: Irina Tirdea <irina.tirdea@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-04-20iio: st_magn: always define ST_MAGN_TRIGGER_SET_STATEArnd Bergmann
commit 9b090a98e95c2530ef0ce474e3b6218621b8ae25 upstream. When CONFIG_IIO_TRIGGER is enabled but CONFIG_IIO_BUFFER is not, we get a build error in the st_magn driver: drivers/iio/magnetometer/st_magn_core.c:573:23: error: 'ST_MAGN_TRIGGER_SET_STATE' undeclared here (not in a function) .set_trigger_state = ST_MAGN_TRIGGER_SET_STATE, ^~~~~~~~~~~~~~~~~~~~~~~~~ Apparently, this ST_MAGN_TRIGGER_SET_STATE macro was meant to be set to NULL when the definition is not available because st_magn_buffer.c is not compiled, but the alternative definition was not included in the original patch. This adds it. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 74f5683f35fe ("iio: st_magn: Add irq trigger handling") Acked-by: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25iio: inkern: fix a NULL dereference on errorDan Carpenter
commit d81dac3c1c5295c61b15293074ac2bd3254e1875 upstream. In twl4030_bci_probe() there are some failure paths where we call iio_channel_release() with a NULL pointer. (Apparently, that driver can opperate without a valid channel pointer). Let's fix it by adding a NULL check in iio_channel_release(). Fixes: 2202e1fc5a29 ('drivers: power: twl4030_charger: fix link problems when building as module') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25iio: pressure: mpl115: fix temperature offset signAkinobu Mita
commit 431386e783a3a6c8b7707bee32d18c353b8688b2 upstream. According to the datasheet, the resolusion of temperature sensor is -5.35 counts/C. Temperature ADC is 472 counts at 25C. (https://www.sparkfun.com/datasheets/Sensors/Pressure/MPL115A1.pdf NOTE: This is older revision, but this information is removed from the latest datasheet from nxp somehow) Temp [C] = (Tadc - 472) / -5.35 + 25 = (Tadc - 605.750000) * -0.186915888 So the correct offset is -605.750000. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Acked-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25iio: light: acpi-als: Report data as processedGabriele Mazzotta
commit fa34e6dd44d7c02c8a8468ce4a52a7506f907bef upstream. 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 <gabriele.mzt@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25iio: dac: mcp4725: set iio name property in sysfsYong Li
commit 97a249e98a72d6b79fb7350a8dd56b147e9d5bdb upstream. Without this change, the name entity for mcp4725 is missing in /sys/bus/iio/devices/iio\:device*/name With this change, name is reported correctly Signed-off-by: Yong Li <sdliyong@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25iio: add IIO_TRIGGER dependency to STK8BA50Vegard Nossum
commit 01cc5235604d61018712c11a14d74230f6a38bf4 upstream. Ran into this on UML: drivers/iio/accel/stk8ba50.c: In function ‘stk8ba50_data_rdy_trigger_set_state’: drivers/iio/accel/stk8ba50.c:163:9: error: implicit declaration of function ‘iio_trigger_get_drvdata’ [-Werror=implicit-function-declaration] iio_trigger_get_drvdata() is defined only when IIO_TRIGGER is selected. Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25iio: add HAS_IOMEM dependency to VF610_ADCVegard Nossum
commit 005ce0713006a76d2b0c924ce0e2629e5d8510c3 upstream. Ran into this on UML: drivers/built-in.o: In function `vf610_adc_probe': drivers/iio/adc/vf610_adc.c:744: undefined reference to `devm_ioremap_resource' devm_ioremap_resource() is defined only when HAS_IOMEM is selected. Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25iio-light: Use a signed return type for ltr501_match_samp_freq()Markus Elfring
commit c08ae18560aaed50fed306a2e11f36ce70130f65 upstream. The return type "unsigned int" was used by the ltr501_match_samp_freq() function despite of the aspect that it will eventually return a negative error code. Improve this implementation detail by deletion of the type modifier then. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25iio:adc:ti_am335x_adc Fix buffered mode by identifying as software buffer.Jonathan Cameron
commit 9d0be85d4e2cfa2519ae16efe7ff4a7150c43c0b upstream. Whilst this part has a hardware buffer, the identifcation that IIO cares about is the userspace facing end. It this case we push individual elements from the hardware fifo into the software interface (specifically a kfifo) rather than providing direct reads through to a hardware buffer (as we still do in the sca3000 for example). Technically the original specification as a hardware buffer could be considered wrong, but it didn't matter until the patch listed below. Result is that any attempt to enable the buffer will return -EINVAL Fixes: 225d59adf1c8 ("iio: Specify supported modes for buffers") Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-25iio: adis_buffer: Fix out-of-bounds memory accessLars-Peter Clausen
commit d590faf9e8f8509a0a0aa79c38e87fcc6b913248 upstream. The SPI tx and rx buffers are both supposed to be scan_bytes amount of bytes large and a common allocation is used to allocate both buffers. This puts the beginning of the tx buffer scan_bytes bytes after the rx buffer. The initialization of the tx buffer pointer is done adding scan_bytes to the beginning of the rx buffer, but since the rx buffer is of type __be16 this will actually add two times as much and the tx buffer ends up pointing after the allocated buffer. Fix this by using scan_count, which is scan_bytes / 2, instead of scan_bytes when initializing the tx buffer pointer. Fixes: aacff892cbd5 ("staging:iio:adis: Preallocate transfer message") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-11-21iio: adc: spmi-vadc: add missing of_node_putJulia Lawall
for_each_available_child_of_node performs an of_node_get on each iteration, so a break out of the loop requires an of_node_put. A simplified version of the semantic patch that fixes this problem is as follows (http://coccinelle.lip6.fr): // <smpl> @@ expression root,e; local idexpression child; @@ for_each_available_child_of_node(root, child) { ... when != of_node_put(child) when != e = child ( return child; | + of_node_put(child); ? return ...; ) ... } // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-11-21iio: fix some warning messagesDan Carpenter
WARN_ON() only takes a condition argument. I have changed these to WARN() instead. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-11-21iio: light: apds9960: correct ->last_busy countMatt Ranostay
Add missing pm_runtime_mark_last_busy to apds9960_set_power_state function. Unless pm_runtime_mark_last_busy is called the pm_runtime_put_autosuspend may put the device into suspend before the delay time requested. Signed-off-by: Matt Ranostay <mranostay@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-11-21iio: lidar: return -EINVAL on invalid signalMatt Ranostay
Returning zero from the measurment function has the side effect of corrupting the triggered buffer readings, better to use -EINVAL than a zero measurement reading. The INVALID status happens even it isn't out of range sometimes roughly once every second or two. This can be from an invalid second signal return path. Hence there are spurious zero readings from the triggered buffer, and warning messages in the kernel log. Signed-off-by: Matt Ranostay <mranostay@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-11-18Merge tag 'iio-fixes-for-4.4a' of ↵Greg Kroah-Hartman
ssh://ra.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus Jonathan writes: First set of IIO fixes for the 4.4 cycle. This set does not include those for issues introduced during the merge window. Fixes of those will follow in a future series. * ad5064 - Make sure the local i2c_write returns 0 on success rather than the number of bytes transfered. Otherwise we report an error on all writes. - Fix a shift for ad5629 and ad5669 which gives incorrect DAC output on these parts. * ad7793 - The product ID on the datasheet is wrong. Fix it in the driver. * IIO_DUMMY_EVGEN - select IRQ_WORK as a dependency. * lpc32xx - make sure clock is prepared before enabling. * si7020 - data byte order was reversed. Fix it. * vf610 - Internal temperature calculation was wrong if a different reference voltage was used. Now use a linear interpolation function to make it work over the full range. - Fix a division by zero in the case of a device tree property not being present (same issue two fixes). * xilinx XADC - VREFN scale was wrong - fix it.
2015-11-15iio: adc: xilinx: Fix VREFN scaleThomas Betker
The scaling factor for VREFN is 3.0/4096 (not 1.0/4096), just as for VREFP. This is not immediately obvious from the specification (Xilinx UG480), but has been confirmed by Xilinx support. Suggested-by: Hartmut Knaack <knaack.h@gmx.de> Signed-off-by: Thomas Betker <thomas.betker@rohde-schwarz.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-11-15iio: si7020: Swap data byte orderChris Lesiak
The Silicon Labs Si7013, Si7020, and Si7021 family of I2C humidity and temperature sensors deliver 16 bit data high byte first. See the datasheet available at: https://www.silabs.com/Support%20Documents%2fTechnicalDocs%2fSi7020-A20.pdf But as documented in Documentation/i2c/smbus-protocol, i2c_smbus_read_word_data() expects the low byte first. Change the driver to use i2c_smbus_read_word_swapped to get correct byte order. Signed-off-by: Chris Lesiak <chris.lesiak@licor.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-11-08iio: adc: vf610_adc: Fix division by zero errorSanchayan Maity
In case the fsl,adck-max-frequency property is not present in the device tree, a division by zero error results during the probe call on kernel boot (see below). This patch fixes it and also restores device tree compatibility in case kernels are booting with old device trees without this property specified. [ 1.063229] Division by zero in kernel. [ 1.067152] CPU: 0 PID: 1 Comm: swapper Not tainted 4.3.0-rc5-00212-gcc88cef #37 [ 1.074650] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) [ 1.081135] Backtrace: [ 1.083694] [<800134a4>] (dump_backtrace) from [<8001369c>] (show_stack+0x18/0x1c) [ 1.091340] r7:00000008 r6:8e0ae210 r5:00000000 r4:8e299800 [ 1.097146] [<80013684>] (show_stack) from [<80297b1c>] (dump_stack+0x24/0x28) [ 1.104483] [<80297af8>] (dump_stack) from [<80013608>] (__div0+0x1c/0x20) [ 1.111421] [<800135ec>] (__div0) from [<802968b4>] (Ldiv0+0x8/0x10) [ 1.117865] [<80424350>] (vf610_adc_probe) from [<803153b4>] (platform_drv_probe+0x4c/0xac) [ 1.126311] r10:00000000 r9:8076a5ec r8:00000000 r7:fffffdfb r6:807cc67c r5:8e0ae210 [ 1.134319] r4:807f6c54 [ 1.136915] [<80315368>] (platform_drv_probe) from [<803138bc>] (driver_probe_device+0x20c/0x2f8) [ 1.145882] r7:807cc67c r6:00000000 r5:8e0ae210 r4:807f6c54 [ 1.151657] [<803136b0>] (driver_probe_device) from [<80313a3c>] (__driver_attach+0x94/0x98) [ 1.160190] r9:8076a5ec r8:00000098 r7:00000000 r6:8e0ae244 r5:807cc67c r4:8e0ae210 [ 1.168112] [<803139a8>] (__driver_attach) from [<80311cb8>] (bus_for_each_dev+0x70/0xa4) [ 1.176383] r7:00000000 r6:803139a8 r5:807cc67c r4:00000000 [ 1.182159] [<80311c48>] (bus_for_each_dev) from [<80313318>] (driver_attach+0x24/0x28) [ 1.190260] r6:807bb568 r5:8e2a5b00 r4:807cc67c [ 1.194996] [<803132f4>] (driver_attach) from [<80312f50>] (bus_add_driver+0x1a4/0x21c) [ 1.203113] [<80312dac>] (bus_add_driver) from [<803142a8>] (driver_register+0x80/0x100) [ 1.211275] r7:8e2a7dc0 r6:807a8160 r5:80789e14 r4:807cc67c [ 1.217075] [<80314228>] (driver_register) from [<803152f8>] (__platform_driver_register+0x5c/0x64) [ 1.226216] r5:80789e14 r4:807a8160 [ 1.229877] [<8031529c>] (__platform_driver_register) from [<80789e30>] (vf610_adc_driver_init+0x1c/0x20) [ 1.239556] [<80789e14>] (vf610_adc_driver_init) from [<800095f8>] (do_one_initcall+0x94/0x1dc) [ 1.248365] [<80009564>] (do_one_initcall) from [<8076ae34>] (kernel_init_freeable+0x13c/0x1e0) [ 1.257155] r10:80794830 r9:8076a5ec r8:00000098 r7:807d5780 r6:807d5780 r5:00000006 [ 1.265153] r4:807a0ee8 [ 1.267753] [<8076acf8>] (kernel_init_freeable) from [<80590ef0>] (kernel_init+0x18/0xf0) [ 1.276021] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:80590ed8 [ 1.284015] r4:807d5780 [ 1.286615] [<80590ed8>] (kernel_init) from [<8000f878>] (ret_from_fork+0x14/0x3c) [ 1.294278] r5:80590ed8 r4:00000000 Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com> Acked-by: Fugang Duan <B38611@freescale.com> Acked-by: Stefan Agner <stefan@agner.ch> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-11-05Merge tag 'spi-v4.4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi updates from Mark Brown: "Quite a lot of activity in SPI this cycle, almost all of it in drivers with a few minor improvements and tweaks in the core. - Updates to pxa2xx to support Intel Broxton and multiple chip selects. - Support for big endian in the bcm63xx driver. - Multiple slave support for the mt8173 - New driver for the auxiliary SPI controller in bcm2835 SoCs. - Support for Layerscale SoCs in the Freescale DSPI driver" * tag 'spi-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (87 commits) spi: pxa2xx: Rework self-initiated platform data creation for non-ACPI spi: pxa2xx: Add support for Intel Broxton spi: pxa2xx: Detect number of enabled Intel LPSS SPI chip select signals spi: pxa2xx: Add output control for multiple Intel LPSS chip selects spi: pxa2xx: Use LPSS prefix for defines that are Intel LPSS specific spi: Add DSPI support for layerscape family spi: ti-qspi: improve ->remove() callback spi/spi-xilinx: Fix race condition on last word read spi: Drop owner assignment from spi_drivers spi: Add THIS_MODULE to spi_driver in SPI core spi: Setup the master controller driver before setting the chipselect spi: dw: replace magic constant by DW_SPI_DR spi: mediatek: mt8173 spi multiple devices support spi: mediatek: handle controller_data in mtk_spi_setup spi: mediatek: remove mtk_spi_config spi: mediatek: Update document devicetree bindings to support multiple devices spi: fix kernel-doc warnings about missing return desc in spi.c spi: fix kernel-doc warnings about missing return desc in spi.h spi: pxa2xx: Align a few defines spi: pxa2xx: Save other reg_cs_ctrl bits when configuring chip select ...
2015-11-04Merge remote-tracking branches 'spi/topic/omap-100k', ↵Mark Brown
'spi/topic/omap-uwire', 'spi/topic/owner', 'spi/topic/pxa' and 'spi/topic/pxa2xx' into spi-next
2015-10-28spi: Drop owner assignment from spi_driversAndrew F. Davis
An spi_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Andrew F. Davis <afd@ti.com> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-27Merge 4.3-rc7 into staging-nextGreg Kroah-Hartman
We want the other staging patches in this branch as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-25iio:ad7793: Fix ad7785 product IDLars-Peter Clausen
While the datasheet for the AD7785 lists 0xXB as the product ID the actual product ID is 0xX3. Fix the product ID otherwise the driver will reject the device due to non matching IDs. Fixes: e786cc26dcc5 ("staging:iio:ad7793: Implement stricter id checking") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-25iio: ad5064: Fix ad5629/ad5669 shiftLars-Peter Clausen
The ad5629/ad5669 are the I2C variant of the ad5628/ad5668, which has a SPI interface. They are mostly identical with the exception that the shift factor is different. Currently the driver does not take care of this difference which leads to incorrect DAC output values. Fix this by introducing a custom channel spec for the ad5629/ad5669 with the correct shift factor. Fixes: commit 6a17a0768f77 ("iio:dac:ad5064: Add support for the ad5629r and ad5669r") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-25iio:ad5064: Make sure ad5064_i2c_write() returns 0 on successMichael Hennerich
i2c_master_send() returns the number of bytes transferred on success while the ad5064 driver expects that the write() callback returns 0 on success. Fix that by translating any non negative return value of i2c_master_send() to 0. Fixes: commit 6a17a0768f77 ("iio:dac:ad5064: Add support for the ad5629r and ad5669r") Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-25vf610_adc: Fix internal temperature calculationBhuvanchandra DV
Calculate ADCR_VTEMP25 using VTEMP25 at VREFH_ADC 3V3. Existing calculations consider the typical values provided in datasheet. Those typical values are valid for VREFH_ADC at 3.0V. VTEMP25 is different for different VREFH_ADC voltages. With VREFH_ADC at 3.3V, voltage at 25°C is 0.699V. Hence update the VTEMP25 to 0.699V which gives ADCR@Temp25 as 867. Formula for finding ADCR@Temp25: ADCR@Temp25 = (ADCR@Vdd * V@TEMP25 * 10) / VDDconv ADCR@Vdd for 12-Bit ADC = 4095 VDDconv = VREFH_ADC * 10 VREFH_ADC@3.3V ADCR@Temp25 = (4095 * .699 * 10) / 33 ADCR@Temp25 ~= 867 | VREFH_ADC | V@TEMP25 | VDDconv | ADCR@Temp25 | | 3.0V | 0.696mV | 30 | 950 | | 3.3V | 0.699mV | 33 | 867 | Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> Acked-by: Fugang Duan <B38611@freescale.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-12iio:light:apds9960 Fix sparse endian warnings.Jonathan Cameron
This patch is a tidy up of warnings from the autobuilder. >> drivers/iio/light/apds9960.c:495:32: sparse: cast to restricted __le16 drivers/iio/light/apds9960.c:635:24: sparse: cast to restricted __le16 >> drivers/iio/light/apds9960.c:672:21: sparse: incorrect type in assignment (different base types) drivers/iio/light/apds9960.c:672:21: expected unsigned short [unsigned] [usertype] buf drivers/iio/light/apds9960.c:672:21: got restricted __le16 [usertype] <noident> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Cc: mranostay@gmail.com Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-12iio:measurement specialties core: Fix endian sparse warnings.Jonathan Cameron
This patch changes various types to the appropriate endian specific versions. Also introduces an additional local variable to avoid a single variable being used for both be and cpu endianness. These aren't bugs as such, but clearing them up does make the code clearer. Warning was: sparse warnings: (new ones prefixed by >>) >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:126:9: sparse: cast to restricted __be32 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:127:16: sparse: cast to restricted __be32 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:208:18: sparse: incorrect type in assignment (different base types) drivers/iio/common/ms_sensors/ms_sensors_i2c.c:208:18: expected unsigned short [unsigned] [addressable] [usertype] send_buf drivers/iio/common/ms_sensors/ms_sensors_i2c.c:208:18: got restricted __be16 [usertype] <noident> >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 >> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:216:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:230:18: sparse: incorrect type in assignment (different base types) drivers/iio/common/ms_sensors/ms_sensors_i2c.c:230:18: expected unsigned short [unsigned] [addressable] [usertype] send_buf drivers/iio/common/ms_sensors/ms_sensors_i2c.c:230:18: got restricted __be16 [usertype] <noident> drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 drivers/iio/common/ms_sensors/ms_sensors_i2c.c:239:19: sparse: cast to restricted __be64 Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-11iio:dac:m62332: use dynamic scaleHartmut Knaack
Some regulators can supply multiple voltages. To take changing voltages into account, the scale needs to be calculated on every read access. Signed-off-by: Hartmut Knaack <knaack.h@gmx.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-11iio:dac:m62332: address some style issuesHartmut Knaack
Fix some indentation issues and separate returns by empty lines (IIO style). Also rename the channel mask in _read_raw() to mask. Signed-off-by: Hartmut Knaack <knaack.h@gmx.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-11iio:dac:m62332: drop unrequired variableHartmut Knaack
A return variable is not required in _write_raw(), and dropping it reduces complexity, as well. Signed-off-by: Hartmut Knaack <knaack.h@gmx.de> Acked-by: Daniel Baluta <daniel.baluta@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-11iio:dac:m62332: use ARRAY_SIZEHartmut Knaack
Make use of ARRAY_SIZE to prevent buffer issues. Signed-off-by: Hartmut Knaack <knaack.h@gmx.de> Acked-by: Daniel Baluta <daniel.baluta@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-11iio:dac:m62332: shutdown on removeHartmut Knaack
The regulator framework requests to balance regulator_enable() calls with regulator_disable() calls. To meet this requirement, set channels to 0 on remove, which implies a regulator_disable() call in case that channel was enabled. Signed-off-by: Hartmut Knaack <knaack.h@gmx.de> Acked-by: Daniel Baluta <daniel.baluta@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-11iio:dac:m62332: share scale and offsetHartmut Knaack
This device simply uses its Vcc as reference voltage, so the same scale applies for all channels. Also offset doesn't appear to be different for any channel. Represent this by switching these two attributes to info_mask_shared_by_type. Signed-off-by: Hartmut Knaack <knaack.h@gmx.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-11iio: hdc100x: correct IIO_CHAN_INFO_OFFSET valueMatt Ranostay
Previous offset wasn't applied in the correct order and invalid. This patchset fixes this issue, and also has the correct scale value applied to the offset. Signed-off-by: Matt Ranostay <mranostay@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-11Add ms8607 meas-spec driver supportLudovic Tancerel
Support for MS8607 temperature, pressure & humidity sensor. This part is using functions from MS5637 for temperature and pressure and HTU21 for humidity Signed-off-by: Ludovic Tancerel <ludovic.tancerel@maplehightech.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-11Add ms5637 meas-spec driver supportLudovic Tancerel
Support for MS5637 temperature & pressure sensor Signed-off-by: Ludovic Tancerel <ludovic.tancerel@maplehightech.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-11Add htu21 meas-spec driver supportLudovic Tancerel
Support for HTU21 temperature & humidity sensor Signed-off-by: Ludovic Tancerel <ludovic.tancerel@maplehightech.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-11Add tsys02d meas-spec driver supportLudovic Tancerel
Support for TSYS02D temperature sensor Signed-off-by: Ludovic Tancerel <ludovic.tancerel@maplehightech.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-04Add tsys01 meas-spec driver supportLudovic Tancerel
Support for TSYS01 temperature sensor Signed-off-by: Ludovic Tancerel <ludovic.tancerel@maplehightech.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-04Add meas-spec sensors common partLudovic Tancerel
Measurement specialties drivers common part. These functions are used by further drivers in the patchset: TSYS01, TSYS02D, HTU21, MS5637, MS8607 Signed-off-by: Ludovic Tancerel <ludovic.tancerel@maplehightech.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-03iio: bmc150: Add SPI driverMarkus Pargmann
Add a simple SPI driver which initializes the spi regmap for the bmc150 core driver. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-03iio: bmc150: Split the driver into core and i2cMarkus Pargmann
Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Tested-by: Irina Tirdea <irina.tirdea@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-03iio: bcm150: Remove i2c_client from private dataMarkus Pargmann
i2c_client struct is now only used for debugging output. We can use the device struct as well so we can remove all struct i2c_client usage. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Tested-by: Irina Tirdea <irina.tirdea@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-03iio: bmc150: Use i2c regmapMarkus Pargmann
This replaces all usage of direct i2c accesses with regmap accesses. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Tested-by: Irina Tirdea <irina.tirdea@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-03iio: remove gpio interrupt probing from drivers that use a single interruptOctavian Purdila
Commit 845c877009cf014b ("i2c / ACPI: Assign IRQ for devices that have GpioInt automatically") automatically assigns the first ACPI GPIO interrupt in client->irq, so we can remove the probing code from drivers that use only one interrupt. Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2015-10-03iio: fix drivers that use 0 as a valid IRQ in client->irq (part 2)Octavian Purdila
Since commit dab472eb931bc291 ("i2c / ACPI: Use 0 to indicate that device does not have interrupt assigned") 0 is not a valid i2c client irq anymore, so change all driver's checks accordingly. The same issue occurs when the device is instantiated via device tree with no IRQ, or from the i2c sysfs interface, even before the patch above. Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-10-11 12:30:01 +0000