22 Jul, 2020
11 commits
-
[ Upstream commit b0536f9826a5ed3328d527b4fc1686867a9f3041 ]
If 'ad7780_init_gpios()' fails, we must not release some resources that
have not been allocated yet. Return directly instead.Fixes: 5bb30e7daf00 ("staging: iio: ad7780: move regulator to after GPIO init")
Fixes: 9085daa4abcc ("staging: iio: ad7780: add gain & filter gpio support")
Signed-off-by: Christophe JAILLET
Acked-by: Renato Lui Geh
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin -
[ Upstream commit f88ecccac4be348bbcc6d056bdbc622a8955c04d ]
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 a 40 byte array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both 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 appart from previous readings.Fixes: 87aec56e27ef ("iio: health: Add driver for the TI AFE4404 heart monitor")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Acked-by: Andrew F. Davis
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin -
commit 3f9c6d38797e9903937b007a341dad0c251765d6 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 a 32 byte array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both 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 appart from previous readings.Fixes: eec96d1e2d31 ("iio: health: Add driver for the TI AFE4403 heart monitor")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Acked-by: Andrew F. Davis
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 8db4afe163bbdd93dca6fcefbb831ef12ecc6b4d 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.
Here there is no data leak possibility so use an explicit structure
on the stack to ensure alignment and nice readable fashion.The forced alignment of ts isn't strictly necessary in this driver
as the padding will be correct anyway (there isn't any). However
it is probably less fragile to have it there and it acts as
documentation of the requirement.Fixes: 713bbb4efb9dc ("iio: pressure: ms5611: Add triggered buffer support")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Acked-by: Tomasz Duszynski
Cc:
Signed-off-by: Greg Kroah-Hartman -
commit 5c49056ad9f3c786f7716da2dd47e4488fc6bd25 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.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data.
This data is allocated with kzalloc so no data can leak
apart from previous readings.Explicit alignment of ts needed to ensure consistent padding
on all architectures (particularly x86_32 with it's 4 byte alignment
of s64)Fixes: e4a70e3e7d84 ("iio: humidity: add support to hts221 rh/temp combo device")
Reported-by: Lars-Peter Clausen
Acked-by: Lorenzo Bianconi
Signed-off-by: Jonathan Cameron
Cc:
Signed-off-by: Greg Kroah-Hartman -
commit d88de040e1df38414fc1e4380be9d0e997ab4d58 upstream.
Calling pm_runtime_get_sync increments the counter even in case of
failure, causing incorrect ref count. Call pm_runtime_put if
pm_runtime_get_sync fails.Signed-off-by: Navid Emamdoost
Fixes: 03b262f2bbf4 ("iio:pressure: initial zpa2326 barometer support")
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit d7369ae1f4d7cffa7574d15e1f787dcca184c49d upstream.
The function iio_device_register() was called in mma8452_probe().
But the function iio_device_unregister() was not called after
a call of the function mma8452_set_freefall_mode() failed.
Thus add the missed function call for one error case.Fixes: 1a965d405fc6 ("drivers:iio:accel:mma8452: added cleanup provision in case of failure.")
Signed-off-by: Chuhong Yuan
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 25f02d3242ab4d16d0cee2dec0d89cedb3747fa9 upstream.
Add missing strings to iio_modifier_names[] for proper modification
of channels.Fixes: b170f7d48443d (iio: Add modifiers for ethanol and H2 gases)
Signed-off-by: Matt Ranostay
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 0187294d227dfc42889e1da8f8ce1e44fc25f147 upstream.
When devm_regmap_init_i2c() returns an error code, a pairing
runtime PM usage counter decrement is needed to keep the
counter balanced. For error paths after ak8974_set_power(),
ak8974_detect() and ak8974_reset(), things are the same.However, When iio_triggered_buffer_setup() returns an error
code, there will be two PM usgae counter decrements.Signed-off-by: Dinghao Liu
Fixes: 7c94a8b2ee8c ("iio: magn: add a driver for AK8974")
Reviewed-by: Linus Walleij
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit ea5e7a7bb6205d24371373cd80325db1bc15eded 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.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data.
This data is allocated with kzalloc so no data can leak apart
from previous readings.Fixes: 16bf793f86b2 ("iio: humidity: hdc100x: add triggered buffer support for HDC100X")
Reported-by: Lars-Peter Clausen
Acked-by: Matt Ranostay
Cc: Alison Schofield
Signed-off-by: Jonathan Cameron
Cc:
Signed-off-by: Greg Kroah-Hartman -
commit 838e00b13bfd4cac8b24df25bfc58e2eb99bcc70 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.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data.This data is allocated with kzalloc so no data can leak appart from
previous readings.Fixes: 7c94a8b2ee8cf ("iio: magn: add a driver for AK8974")
Reported-by: Lars-Peter Clausen
Reviewed-by: Linus Walleij
Signed-off-by: Jonathan Cameron
Cc:
Signed-off-by: Greg Kroah-Hartman
24 Jun, 2020
2 commits
-
[ Upstream commit dee2dabc0e4115b80945fe2c91603e634f4b4686 ]
Limit the output of humidity compensation to the range between 0 and 100
percent.Depending on the calibration parameters of the individual sensor it
happens, that a humidity above 100 percent or below 0 percent is
calculated, which don't make sense in terms of relative humidity.Add a clamp to the compensation formula as described in the datasheet of
the sensor in chapter 4.2.3.Although this clamp is documented, it was never in the driver of the
kernel.It depends on the circumstances (calibration parameters, temperature,
humidity) if one can see a value above 100 percent without the clamp.
The writer of this patch was working with this type of sensor without
noting this error. So it seems to be a rare event when this bug occures.Signed-off-by: Andreas Klinger
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin -
[ Upstream commit 97b31a6f5fb95b1ec6575b78a7240baddba34384 ]
With DEBUG_SHIRQ enabled we have a kernel crash
[ 116.482696] BUG: kernel NULL pointer dereference, address: 0000000000000000
...
[ 116.606571] Call Trace:
[ 116.609023]
[ 116.611047] complete+0x34/0x50
[ 116.614206] bmp085_eoc_irq+0x9/0x10 [bmp280]because DEBUG_SHIRQ mechanism fires an IRQ before registration and drivers
ought to be able to handle an interrupt happening before request_irq() returns.Fixes: aae953949651 ("iio: pressure: bmp280: add support for BMP085 EOC interrupt")
Signed-off-by: Andy Shevchenko
Acked-by: Linus Walleij
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin
11 Jun, 2020
4 commits
-
commit 10134ec3f8cefa6a40fe84987f1795e9e0da9715 upstream.
A wrong error message is printed out currently, like on STM32MP15:
- stm32-adc-core 48003000.adc: IRQ index 2 not found.This is seen since commit 7723f4c5ecdb ("driver core: platform: Add an
error message to platform_get_irq*()").
The STM32 ADC core driver wrongly requests up to 3 interrupt lines. It
should request only the necessary IRQs, based on the compatible:
- stm32f4/h7 ADCs share a common interrupt
- stm32mp1, has one interrupt line per ADC.
So add the number of required interrupts to the compatible data.Fixes: d58c67d1d851 ("iio: adc: stm32-adc: add support for STM32MP1")
Signed-off-by: Fabrice Gasnier
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 13e945631c2ffb946c0af342812a3cd39227de6e 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.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both 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 appart from previous readings.Fixes: a1d642266c14 ("iio: chemical: add support for Plantower PMS7003 sensor")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Cc:
Acked-by: Tomasz Duszynski
Signed-off-by: Greg Kroah-Hartman -
commit 18dfb5326370991c81a6d1ed6d1aeee055cb8c05 upstream.
The bytes returned by the i2c reading need to be swapped
unconditionally. Otherwise, on be16 platforms, an incorrect value will be
returned.Taking the slow path via next merge window as its been around a while
and we have a patch set dependent on this which would be held up.Fixes: 62a1efb9f868 ("iio: add vcnl4000 combined ALS and proximity sensor")
Signed-off-by: Mathieu Othacehe
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit a5bf6fdd19c327bcfd9073a8740fa19ca4525fd4 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.Fixes: 232e0f6ddeae ("iio: chemical: add support for Sensirion SPS30 sensor")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Cc:
Acked-by: Tomasz Duszynski
Signed-off-by: Greg Kroah-Hartman
27 May, 2020
7 commits
-
[ 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 symlinkFix 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 -
[ 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 -
[ 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 symlinkFix 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 -
[ 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 -
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 -
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 -
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
02 May, 2020
1 commit
-
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
29 Apr, 2020
7 commits
-
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 -
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 -
commit f954b098fbac4d183219ce5b42d76d6df2aed50a upstream.
When enabling the trigger and unmasking the end-of-sequence (EOS) interrupt
the EOS interrupt should be cleared from the status register. Otherwise it
is possible that it was still set from a previous capture. If that is the
case the interrupt would fire immediately even though no conversion has
been done yet and stale data is being read from the device.The old code only clears the interrupt if the interrupt was previously
unmasked. Which does not make much sense since the interrupt is always
masked at this point and in addition masking the interrupt does not clear
the interrupt from the status register. So the clearing needs to be done
unconditionally.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 -
commit e44ec7794d88f918805d700240211a9ec05ed89d upstream.
The check for shutting down the second ADC is inverted. This causes it to
be powered down when it should be enabled. As a result channels that are
supposed to be handled by the second ADC return invalid conversion results.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 -
commit dd7de4c0023e7564cabe39d64b2822a522890792 upstream.
The first received byte is the MSB, followed by the LSB so the value needs
to be byte swapped.Also, the ADC actually has a delay of one clock on the SPI bus. Read three
bytes to get the last bit.Fixes: 8dd2d7c0fed7 ("iio: adc: Add driver for the TI ADS8344 A/DC chips")
Signed-off-by: Alexandre Belloni
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit e2042d2936dfc84e9c600fe9b9d0039ca0e54b7d upstream.
This commit fixes the following error:
"BUG: sleeping function called from invalid context at kernel/irq/chip.c"In DMA mode suppress the trigger irq handler, and make the buffer
transfers directly in DMA callback, instead.Fixes: 2763ea0585c9 ("iio: adc: stm32: add optional dma support")
Signed-off-by: Olivier Moysan
Acked-by: Fabrice Gasnier
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit e450e07c14abae563ad13b064cbce9fdccc6bc8d upstream.
Indeed, relying on addr being not 0 cannot work because some device have
their register to set odr at address 0. As a matter of fact, if the odr
can be set, then there is a mask.Sensors with ODR register at address 0 are: lsm303dlh, lsm303dlhc, lsm303dlm
Fixes: 7d245172675a ("iio: common: st_sensors: check odr address value in st_sensors_set_odr()")
Signed-off-by: Lary Gibaud
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman
23 Apr, 2020
1 commit
-
commit 328b50e9a0ad1fe8accdf8c19923deebab5e0c01 upstream.
The chip is configured in 24 bit mode. The values read from
it must always be treated as is. This fixes the issue by
replacing the previous 16 bits value by a 24 bits buffer.This changes affects the value output by previous version of
the driver, since the least significant byte was missing.
The upper half of 16 bit values previously output are now
the upper half of a 24 bit value.Fixes: e01e7eaf37d8 ("iio: light: introduce si1133")
Reported-by: Simon Goyette
Co-authored-by: Guillaume Champagne
Signed-off-by: Maxime Roussin-Bélanger
Signed-off-by: Guillaume Champagne
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman
25 Mar, 2020
7 commits
-
commit 2ca5a8792d617b4035aacd0a8be527f667fbf912 upstream.
Vishay has published a new version of "Designing the VCNL4200 Into an
Application" application note in October 2019. The new version specifies
that there is +-20% of part to part tolerance. Although the application
note is related to vcnl4200, according to support the vcnl4040's "ASIC
is quite similar to that one for the VCNL4200".So update the sampling periods (and comment), including the correct
sampling period for proximity. Both sampling periods are lower. Users
relying on the blocking behaviour of reading will get proximity
measurements much earlier.Fixes: 5a441aade5b3 ("iio: light: vcnl4000 add support for the VCNL4040 proximity and light sensor")
Reviewed-by: Guido Günther
Tested-by: Guido Günther
Signed-off-by: Tomas Novotny
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit b42aa97ed5f1169cfd37175ef388ea62ff2dcf43 upstream.
Vishay has published a new version of "Designing the VCNL4200 Into an
Application" application note in October 2019. The new version specifies
that there is +-20% of part to part tolerance. This explains the drift
seen during experiments. The proximity pulse width is also changed from
32us to 30us. According to the support, the tolerance also applies to
ambient light.So update the sampling periods. As the reading is blocking, current
users may notice slightly longer response time.Fixes: be38866fbb97 ("iio: vcnl4000: add support for VCNL4200")
Reviewed-by: Guido Günther
Signed-off-by: Tomas Novotny
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit a500f3bd787f8224341e44b238f318c407b10897 upstream.
The differential channels require writing the channel offset register (COR).
Otherwise they do not work in differential mode.
The configuration of COR is missing in triggered mode.Fixes: 5e1a1da0f8c9 ("iio: adc: at91-sama5d2_adc: add hw trigger and buffer support")
Signed-off-by: Eugen Hristev
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit e19ac9d9a978f8238a85a28ed624094a497d5ae6 upstream.
This commit fixes the error message:
"BUG: sleeping function called from invalid context at kernel/irq/chip.c"
Suppress the trigger irq handler. Make the buffer transfers directly
in DMA callback, instead.
Push buffers without timestamps, as timestamps are not supported
in DFSDM driver.Fixes: 11646e81d775 ("iio: adc: stm32-dfsdm: add support for buffer modes")
Signed-off-by: Olivier Moysan
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit b500c086e4110829a308c23e83a7cdc65b26228a upstream.
At the moment, reading from in_magn_*_raw in sysfs tends to return
large values around 65000, even though the output of ak8974 is actually
limited to ±32768. This happens because the value is never converted
to the signed 16-bit integer variant.Add an explicit cast to s16 to fix this.
Fixes: 7c94a8b2ee8c ("iio: magn: add a driver for AK8974")
Signed-off-by: Stephan Gerhold
Reviewed-by: Linus Waleij
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit cb2116ff97859d34fda6cb561ac654415f4c6230 upstream.
Data stored in the iio-buffer is BE and this
should be specified in the iio_chan_spec struct.Fixes: f4f55ce38e5f8 ("iio:adxl372: Add FIFO and interrupts support")
Signed-off-by: Alexandru Tachici
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 29e8c8253d7d5265f58122c0a7902e26df6c6f61 upstream.
Master mode should be disabled when stopping. This mainly impacts
possible other use-case after timer has been stopped. Currently,
master mode remains set (from start routine).Fixes: 6fb34812c2a2 ("iio: stm32 trigger: Add support for TRGO2 triggers")
Signed-off-by: Fabrice Gasnier
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman
