kernel.git/drivers/iio/adc, branch linux-4.1.y

iio: adc: axp288: remove redundant duplicate const on axp288_adc_channels

2018-03-04T15:28:31Z

[ Upstream commit 7ca6574a7afb669b0b4b30dd63adeb310e97e250 ] duplicate const can be removed, it is redundant. Found by static analysis using smatch. Signed-off-by: Colin Ian King Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: adc: ti_am335x_adc: fix fifo overrun recovery

2018-01-17T17:30:25Z

[ Upstream commit e83bb3e6f3efa21f4a9d883a25d0ecd9dfb431e1 ] The tiadc_irq_h(int irq, void *private) function is handling FIFO overruns by clearing flags, disabling and enabling the ADC to recover. If the ADC is running in continuous mode a FIFO overrun happens regularly. If the disabling of the ADC happens concurrently with a new conversion. It might happen that the enabling of the ADC is ignored by the hardware. This stops the ADC permanently. No more interrupts are triggered. According to the AM335x Reference Manual (SPRUH73H October 2011 - Revised April 2013 - Chapter 12.4 and 12.5) it is necessary to check the ADC FSM bits in REG_ADCFSM before enabling the ADC again. Because the disabling of the ADC is done right after the current conversion has been finished. To trigger this bug it is necessary to run the ADC in continuous mode. The ADC values of all channels need to be read in an endless loop. The bug appears within the first 6 hours (~5.4 million handled FIFO overruns). The user space application will hang on reading new values from the character device. Fixes: ca9a563805f7a ("iio: ti_am335x_adc: Add continuous sampling support") Signed-off-by: Michael Engl Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: adc: xilinx: Fix error handling

2017-11-06T04:54:31Z

[ Upstream commit ca1c39ef76376b67303d01f94fe98bb68bb3861a ] Reorder error handling labels in order to match the way resources have been allocated. Signed-off-by: Christophe JAILLET Acked-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: adc: mcp320x: Fix oops on module unload

2017-11-06T04:54:22Z

[ Upstream commit 0964e40947a630a2a6f724e968246992f97bcf1c ] The driver calls spi_get_drvdata() in its ->remove hook even though it has never called spi_set_drvdata(). Stack trace for posterity: Unable to handle kernel NULL pointer dereference at virtual address 00000220 Internal error: Oops: 5 [#1] SMP ARM [<8072f564>] (mutex_lock) from [<7f1400d0>] (iio_device_unregister+0x24/0x7c [industrialio]) [<7f1400d0>] (iio_device_unregister [industrialio]) from [<7f15e020>] (mcp320x_remove+0x20/0x30 [mcp320x]) [<7f15e020>] (mcp320x_remove [mcp320x]) from [<8055a8cc>] (spi_drv_remove+0x2c/0x44) [<8055a8cc>] (spi_drv_remove) from [<805087bc>] (__device_release_driver+0x98/0x134) [<805087bc>] (__device_release_driver) from [<80509180>] (driver_detach+0xdc/0xe0) [<80509180>] (driver_detach) from [<8050823c>] (bus_remove_driver+0x5c/0xb0) [<8050823c>] (bus_remove_driver) from [<80509ab0>] (driver_unregister+0x38/0x58) [<80509ab0>] (driver_unregister) from [<7f15e69c>] (mcp320x_driver_exit+0x14/0x1c [mcp320x]) [<7f15e69c>] (mcp320x_driver_exit [mcp320x]) from [<801a78d0>] (SyS_delete_module+0x184/0x1d0) [<801a78d0>] (SyS_delete_module) from [<80108100>] (ret_fast_syscall+0x0/0x1c) Fixes: f5ce4a7a9291 ("iio: adc: add driver for MCP3204/08 12-bit ADC") Cc: Oskar Andero Signed-off-by: Lukas Wunner Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: ad_sigma_delta: Implement a dedicated reset function

2017-11-06T04:54:21Z

[ Upstream commit 7fc10de8d49a748c476532c9d8e8fe19e548dd67 ] Since most of the SD ADCs have the option of reseting the serial interface by sending a number of SCLKs with CS = 0 and DIN = 1, a dedicated function that can do this is usefull. Needed for the patch: iio: ad7793: Fix the serial interface reset Signed-off-by: Dragos Bogdan Acked-by: Lars-Peter Clausen Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: adc: axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications

2017-11-06T04:54:14Z

[ Upstream commit fa2849e9649b5180ffc4cb3c3b005261c403093a ] For some reason the axp288_adc driver was modifying the AXP288_ADC_TS_PIN_CTRL register, changing bits 0-1 depending on whether the GP_ADC channel or another channel was written. These bits control when a bias current is send to the TS_PIN, the GP_ADC has its own pin and a separate bit in another register to control the bias current. Not only does changing when to enable the TS_PIN bias current (always or only when sampling) when reading the GP_ADC make no sense at all, the code is modifying these bits is writing the entire register, assuming that all the other bits have their default value. So if the firmware has configured a different bias-current for either pin, then that change gets clobbered by the write, likewise if the firmware has set bit 2 to indicate that the battery has no thermal sensor, this will get clobbered by the write. This commit fixes all this, by simply removing all writes to the AXP288_ADC_TS_PIN_CTRL register, they are not needed to read the GP_ADC pin, and can actually be harmful. Signed-off-by: Hans de Goede Acked-by: Chen-Yu Tsai Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: adc: vf610_adc: Fix VALT selection value for REFSEL bits

2017-09-10T20:36:11Z

[ Upstream commit d466d3c1217406b14b834335b5b4b33c0d45bd09 ] In order to select the alternate voltage reference pair (VALTH/VALTL), the right value for the REFSEL field in the ADCx_CFG register is "01", leading to 0x800 as register mask. See section 8.2.6.4 in the reference manual[1]. [1] http://www.nxp.com/docs/en/reference-manual/VFXXXRM.pdf Fixes: a775427632fd ("iio:adc:imx: add Freescale Vybrid vf610 adc driver") Signed-off-by: Stefan-Gabriel Mirea Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio:ad7266: Fix probe deferral for vref

2016-08-20T03:08:44Z

[ Upstream commit 68b356eb3d9f5e38910fb62e22a78e2a18d544ae ] 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 Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio:ad7266: Fix support for optional regulators

2016-08-20T03:08:44Z

[ Upstream commit e5511c816e5ac4909bdd38e85ac344e2b9b8e984 ] 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 Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio:ad7266: Fix broken regulator error handling

2016-08-20T03:08:44Z

[ Upstream commit 6b7f4e25f3309f106a5c7ff42c8231494cf285d3 ] 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 Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin