summaryrefslogtreecommitdiffstats
path: root/drivers/iio/accel/Makefile
diff options
context:
space:
mode:
authorLars-Peter Clausen <lars@metafoo.de>2015-05-18 13:34:49 +0200
committerJonathan Cameron <jic23@kernel.org>2015-05-23 12:44:38 +0100
commit1250186a936a169a32f5101392deec18788877b9 (patch)
tree6f8626150eccc079ccb5ad3c97b842bd1c34ff86 /drivers/iio/accel/Makefile
parent623d74e37f12c9276b15c2c0540b438e684af0d2 (diff)
downloadop-kernel-dev-1250186a936a169a32f5101392deec18788877b9.zip
op-kernel-dev-1250186a936a169a32f5101392deec18788877b9.tar.gz
iio: __iio_update_buffers: Leave device in sane state on error
Currently when something goes wrong at some step when disabling the buffers we immediately abort. This has the effect that the enable/disable calls are no longer balanced. So make sure that even if one step in the disable sequence fails the other steps are still executed. The other issue is that when either enable or disable fails buffers that were active at that time stay active while the device itself is disabled. This leaves things in a inconsistent state and can cause unbalanced enable/disable calls. Furthermore when enable fails we restore the old scan mask, but still keeps things disabled. Given that verification of the configuration was performed earlier and it is valid at the point where we try to enable/disable the most likely reason of failure is a communication failure with the device or maybe a out-of-memory situation. There is not really a good recovery strategy in such a case, so it makes sense to leave the device disabled, but we should still leave it in a consistent state. What the patch does if disable/enable fails is to deactivate all buffers and make sure that the device will be in the same state as if all buffers had been manually disabled. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Diffstat (limited to 'drivers/iio/accel/Makefile')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud