user/sven/linux.git/drivers/iio, branch v5.4.43

iio: adc: stm32-dfsdm: fix device used to request dma

2020-05-27T15:46:51Z

[ Upstream commit b455d06e6fb3c035711e8aab1ca18082ccb15d87 ] DMA channel request should use device struct from platform device struct. Currently it's using iio device struct. But at this stage when probing, device struct isn't yet registered (e.g. device_register is done in iio_device_register). Since commit 71723a96b8b1 ("dmaengine: Create symlinks between DMA channels and slaves"), a warning message is printed as the links in sysfs can't be created, due to device isn't yet registered: - Cannot create DMA slave symlink - Cannot create DMA dma:rx symlink Fix this by using device struct from platform device to request dma chan. Fixes: eca949800d2d ("IIO: ADC: add stm32 DFSDM support for PDM microphone") Signed-off-by: Fabrice Gasnier Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: adc: stm32-dfsdm: Use dma_request_chan() instead dma_request_slave_channel()

2020-05-27T15:46:50Z

[ Upstream commit a9ab624edd9186fbad734cfe5d606a6da3ca34db ] dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. By using dma_request_chan() directly the driver can support deferred probing against DMA. Signed-off-by: Peter Ujfalusi Acked-by: Olivier Moysan Acked-by: Fabrice Gasnier Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: adc: stm32-adc: fix device used to request dma

2020-05-27T15:46:50Z

[ Upstream commit 52cd91c27f3908b88e8b25aed4a4d20660abcc45 ] DMA channel request should use device struct from platform device struct. Currently it's using iio device struct. But at this stage when probing, device struct isn't yet registered (e.g. device_register is done in iio_device_register). Since commit 71723a96b8b1 ("dmaengine: Create symlinks between DMA channels and slaves"), a warning message is printed as the links in sysfs can't be created, due to device isn't yet registered: - Cannot create DMA slave symlink - Cannot create DMA dma:rx symlink Fix this by using device struct from platform device to request dma chan. Fixes: 2763ea0585c99 ("iio: adc: stm32: add optional dma support") Signed-off-by: Fabrice Gasnier Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: adc: stm32-adc: Use dma_request_chan() instead dma_request_slave_channel()

2020-05-27T15:46:50Z

[ Upstream commit 735404b846dffcb320264f62b76e6f70012214dd ] dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. By using dma_request_chan() directly the driver can support deferred probing against DMA. Signed-off-by: Peter Ujfalusi Acked-by: Fabrice Gasnier Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: adc: ti-ads8344: Fix channel selection

2020-05-27T15:46:46Z

commit bcfa1e253d2e329e1ebab5c89f3c73f6dd17606c upstream. During initial submission the selection of the channel was done using the scan_index member of the iio_chan_spec structure. It was an abuse because this member is supposed to be used with a buffer so it was removed. However there was still the need to be able to known how to select a channel, the correct member to store this information is address. Thanks to this it is possible to select any other channel than the channel 0. Fixes: 8dd2d7c0fed7 ("iio: adc: Add driver for the TI ADS8344 A/DC chips") Signed-off-by: Gregory CLEMENT Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: dac: vf610: Fix an error handling path in 'vf610_dac_probe()'

2020-05-27T15:46:45Z

commit aad4742fbf0a560c25827adb58695a4497ffc204 upstream. A call to 'vf610_dac_exit()' is missing in an error handling path. Fixes: 1b983bf42fad ("iio: dac: vf610_dac: Add IIO DAC driver for Vybrid SoC") Signed-off-by: Christophe JAILLET Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: sca3000: Remove an erroneous 'get_device()'

2020-05-27T15:46:45Z

commit 928edefbc18cd8433f7df235c6e09a9306e7d580 upstream. This looks really unusual to have a 'get_device()' hidden in a 'dev_err()' call. Remove it. While at it add a missing \n at the end of the message. Fixes: 574fb258d636 ("Staging: IIO: VTI sca3000 series accelerometer driver (spi)") Signed-off-by: Christophe JAILLET Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio:ad7797: Use correct attribute_group

2020-05-02T06:48:44Z

commit 28535877ac5b2b84f0d394fd67a5ec71c0c48b10 upstream. It should use ad7797_attribute_group in ad7797_info, according to commit ("iio:ad7793: Add support for the ad7796 and ad7797"). Scale is fixed for the ad7796 and not programmable, hence should not have the scale_available attribute. Fixes: fd1a8b912841 ("iio:ad7793: Add support for the ad7796 and ad7797") Signed-off-by: YueHaibing Reviewed-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: xilinx-xadc: Make sure not exceed maximum samplerate

2020-04-29T14:33:13Z

commit 3b7f9dbb827ce8680b98490215e698b6079a9ec5 upstream. The XADC supports a samplerate of up to 1MSPS. Unfortunately the hardware does not have a FIFO, which means it generates an interrupt for each conversion sequence. At one 1MSPS this creates an interrupt storm that causes the system to soft-lock. For this reason the driver limits the maximum samplerate to 150kSPS. Currently this check is only done when setting a new samplerate. But it is also possible that the initial samplerate configured in the FPGA bitstream exceeds the limit. In this case when starting to capture data without first changing the samplerate the system can overload. To prevent this check the currently configured samplerate in the probe function and reduce it to the maximum if necessary. Signed-off-by: Lars-Peter Clausen Fixes: bdc8cda1d010 ("iio:adc: Add Xilinx XADC driver") Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: xilinx-xadc: Fix sequencer configuration for aux channels in simultaneous mode

2020-04-29T14:33:13Z

commit 8bef455c8b1694547ee59e8b1939205ed9d901a6 upstream. The XADC has two internal ADCs. Depending on the mode it is operating in either one or both of them are used. The device manual calls this continuous (one ADC) and simultaneous (both ADCs) mode. The meaning of the sequencing register for the aux channels changes depending on the mode. In continuous mode each bit corresponds to one of the 16 aux channels. And the single ADC will convert them one by one in order. In simultaneous mode the aux channels are split into two groups the first 8 channels are assigned to the first ADC and the other 8 channels to the second ADC. The upper 8 bits of the sequencing register are unused and the lower 8 bits control both ADCs. This means a bit needs to be set if either the corresponding channel from the first group or the second group (or both) are set. Currently the driver does not have the special handling required for simultaneous mode. Add it. Signed-off-by: Lars-Peter Clausen Fixes: bdc8cda1d010 ("iio:adc: Add Xilinx XADC driver") Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman