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

iio: adc: stm32-adc: fix a regression when using dma and irq

2020-11-24T12:39:10Z

commit 695e2f5c289bb7f8b85351dcfa35fa236e0200a4 upstream. Since overrun interrupt support has been added, there's a regression when two ADCs are used at the same time, with: - an ADC configured to use IRQs. EOCIE bit is set. The handler is normally called in this case. - an ADC configured to use DMA. EOCIE bit isn't set. EOC triggers the DMA request. It's then automatically cleared by DMA read. But the handler gets called due to status bit is temporarily set (IRQ triggered by the other ADC). This is a regression as similar issue had been fixed earlier by commit dcb10920179a ("iio: adc: stm32-adc: fix a race when using several adcs with dma and irq"). Issue is that stm32_adc_eoc_enabled() returns non-zero value (always) since OVR bit has been added and enabled for both DMA and IRQ case. Remove OVR mask in IER register, and rely only on CSR status for overrun. To avoid subsequent calls to interrupt routine on overrun, CSR OVR bit has to be cleared. CSR OVR bit cannot be cleared directly by software. To do this ADC must be stopped first, and OVR bit in ADC ISR has to be cleared. Also add a check in ADC IRQ handler to report spurious IRQs. Fixes: cc06e67d8fa5 ("iio: adc: stm32-adc: Add check on overrun interrupt") Signed-off-by: Olivier Moysan Signed-off-by: Fabrice Gasnier Cc: Link: https://lore.kernel.org/r/20201021085313.5335-1-olivier.moysan@st.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio/adc: ingenic: Fix battery VREF for JZ4770 SoC

2020-11-24T12:39:10Z

commit c91ebcc578e09783cfa4d85c1b437790f140f29a upstream. The reference voltage for the battery is clearly marked as 1.2V in the programming manual. With this fixed, the battery channel now returns correct values. Fixes: a515d6488505 ("IIO: Ingenic JZ47xx: Add support for JZ4770 SoC ADC.") Signed-off-by: Paul Cercueil Acked-by: Artur Rojek Cc: Link: https://lore.kernel.org/r/20201104192843.67187-1-paul@crapouillou.net Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio/adc: ingenic: Fix AUX/VBAT readings when touchscreen is used

2020-11-24T12:39:10Z

commit 6d6aa2907d59ddd3c0ebb2b93e1ddc84e474485b upstream. When the command feature of the ADC is used, it is possible to program the ADC, and specify at each step what input should be processed, and in comparison to what reference. This broke the AUX and battery readings when the touchscreen was enabled, most likely because the CMD feature would change the VREF all the time. Now, when AUX or battery are read, we temporarily disable the CMD feature, which means that we won't get touchscreen readings in that time frame. But it now gives correct values for AUX / battery, and the touchscreen isn't disabled for long enough to be an actual issue. Fixes: b96952f498db ("IIO: Ingenic JZ47xx: Add touchscreen mode.") Signed-off-by: Paul Cercueil Acked-by: Artur Rojek Cc: Link: https://lore.kernel.org/r/20201103201238.161083-1-paul@crapouillou.net Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: adc: mediatek: fix unset field

2020-11-24T12:39:10Z

commit 15207a92e019803d62687455d8aa2ff9eb3dc82c upstream. dev_comp field is used in a couple of places but it is never set. This results in kernel oops when dereferencing a NULL pointer. Set the `dev_comp` field correctly in the probe function. Fixes: 6d97024dce23 ("iio: adc: mediatek: mt6577-auxadc, add mt6765 support") Signed-off-by: Fabien Parent Reviewed-by: Matthias Brugger Cc: Link: https://lore.kernel.org/r/20201018194644.3366846-1-fparent@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio:adc:ti-adc12138 Fix alignment issue with timestamp

2020-11-05T10:51:43Z

commit 293e809b2e8e608b65a949101aaf7c0bd1224247 upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. We move to a suitable structure in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc so no data can leak apart from previous readings. Note that previously no leak at all could occur, but previous readings should never be a problem. In this case the timestamp location depends on what other channels are enabled. As such we can't use a structure without misleading by suggesting only one possible timestamp location. Fixes: 50a6edb1b6e0 ("iio: adc: add ADC12130/ADC12132/ADC12138 ADC driver") Reported-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Cc: Akinobu Mita Cc: Link: https://lore.kernel.org/r/20200722155103.979802-26-jic23@kernel.org Signed-off-by: Greg Kroah-Hartman

iio:adc:ti-adc0832 Fix alignment issue with timestamp

2020-11-05T10:51:42Z

commit 39e91f3be4cba51c1560bcda3a343ed1f64dc916 upstream. One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. We fix this issues by moving to a suitable structure in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc so no data can leak apart from previous readings. Note that previously no data could leak 'including' previous readings but I don't think it is an issue to potentially leak them like this now does. In this case the postioning of the timestamp is depends on what other channels are enabled. As such we cannot use a structure to make the alignment explicit as it would be missleading by suggesting only one possible location for the timestamp. Fixes: 815bbc87462a ("iio: ti-adc0832: add triggered buffer support") Reported-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Cc: Akinobu Mita Cc: Link: https://lore.kernel.org/r/20200722155103.979802-25-jic23@kernel.org Signed-off-by: Greg Kroah-Hartman

iio: ad7292: Fix of_node refcounting

2020-11-05T10:51:42Z

commit b8a533f3c24b3b8f1fdbefc5ada6a7d5733d63e6 upstream. When returning or breaking early from a `for_each_available_child_of_node()` loop, we need to explicitly call `of_node_put()` on the child node to possibly release the node. Fixes: 506d2e317a0a0 ("iio: adc: Add driver support for AD7292") Signed-off-by: Nuno Sá Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200925091045.302-2-nuno.sa@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: adc: gyroadc: fix leak of device node iterator

2020-11-05T10:51:42Z

commit da4410d4078ba4ead9d6f1027d6db77c5a74ecee upstream. Add missing of_node_put calls when exiting the for_each_child_of_node loop in rcar_gyroadc_parse_subdevs early. Also add goto-exception handling for the error paths in that loop. Fixes: 059c53b32329 ("iio: adc: Add Renesas GyroADC driver") Signed-off-by: Tobias Jordan Link: https://lore.kernel.org/r/20200926161946.GA10240@agrajag.zerfleddert.de Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: adc: at91-sama5d2_adc: fix DMA conversion crash

2020-11-05T10:51:42Z

commit 1a198794451449113fa86994ed491d6986802c23 upstream. After the move of the postenable code to preenable, the DMA start was done before the DMA init, which is not correct. The DMA is initialized in set_watermark. Because of this, we need to call the DMA start functions in set_watermark, after the DMA init, instead of preenable hook, when the DMA is not properly setup yet. Fixes: f3c034f61775 ("iio: at91-sama5d2_adc: adjust iio_triggered_buffer_{predisable,postenable} positions") Signed-off-by: Eugen Hristev Link: https://lore.kernel.org/r/20200923121748.49384-1-eugen.hristev@microchip.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: adc: stm32-adc: fix runtime autosuspend delay when slow polling

2020-10-29T09:11:31Z

[ Upstream commit c537d3457542a398caa1fe58e0976c5f83cf7281 ] When the ADC is runtime suspended and starting a conversion, the stm32-adc driver calls pm_runtime_get_sync() that gets cascaded to the parent (e.g. runtime resume of stm32-adc-core driver). This also kicks the autosuspend delay (e.g. 2s) of the parent. Once the ADC is active, calling pm_runtime_get_sync() again (upon a new capture) won't kick the autosuspend delay for the parent (stm32-adc-core driver) as already active. Currently, this makes the stm32-adc-core driver go in suspend state every 2s when doing slow polling. As an example, doing a capture, e.g. cat in_voltageY_raw at a 0.2s rate, the auto suspend delay for the parent isn't refreshed. Once it expires, the parent immediately falls into runtime suspended state, in between two captures, as soon as the child driver falls into runtime suspend state: - e.g. after 2s, + child calls pm_runtime_put_autosuspend() + 100ms autosuspend delay of the child. - stm32-adc-core switches off regulators, clocks and so on. - They get switched on back again 100ms later in this example (at 2.2s). So, use runtime_idle() callback in stm32-adc-core driver to call pm_runtime_mark_last_busy() for the parent driver (stm32-adc-core), to avoid this. Fixes: 9bdbb1139ca1 ("iio: adc: stm32-adc: add power management support") Signed-off-by: Fabrice Gasnier Reviewed-by: Ulf Hansson Link: https://lore.kernel.org/r/1593615328-5180-1-git-send-email-fabrice.gasnier@st.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin