1. 22 Sep, 2012 12 commits
    • Lars-Peter Clausen's avatar
      staging:iio:sca3000: Do not return a error in remove function · 67ad4e08
      Lars-Peter Clausen authored
      In the Linux device driver model the remove callback is not allowed to fail and
      the device will be removed regardless of the return value of the remove
      callback. So if we abort in the remove function and do not free all resources we
      will create a resource leak. Also all kinds of undefined behaviour are expected
      to happen since the IIO device is still there while its parent is already gone.
      
      The errors which the driver tries to handle in the remove function are
      non-critical, so we can just ignore them and continue to free all resources and
      remove the IIO device.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      67ad4e08
    • Lars-Peter Clausen's avatar
      staging:iio:lis3l02dq: Do not return a error in remove function · e71a837c
      Lars-Peter Clausen authored
      In the Linux device driver model the remove callback is not allowed to fail and
      the device will be removed regardless of the return value of the remove
      callback. So if we abort in the remove function and do not free all resources we
      will create a resource leak. Also all kinds of undefined behaviour are expected
      to happen since the IIO device is still there while its parent is already gone.
      
      The errors which the driver tries to handle in the remove function are
      non-critical, so we can just ignore them and continue to free all resources and
      remove the IIO device.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      e71a837c
    • Lars-Peter Clausen's avatar
      staging:iio:ade7759: Do not return a error in remove function · e854bcc9
      Lars-Peter Clausen authored
      In the Linux device driver model the remove callback is not allowed to fail and
      the device will be removed regardless of the return value of the remove
      callback. So if we abort in the remove function and do not free all resources we
      will create a resource leak. Also all kinds of undefined behaviour are expected
      to happen since the IIO device is still there while its parent is already gone.
      
      The error which the driver tries to handle in the remove function is
      non-critical, so we can just ignore it and continue to free all resources and
      remove the IIO device.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      e854bcc9
    • Lars-Peter Clausen's avatar
      staging:iio:ade7758: Do not return a error in remove function · 4922fd69
      Lars-Peter Clausen authored
      In the Linux device driver model the remove callback is not allowed to fail and
      the device will be removed regardless of the return value of the remove
      callback. So if we abort in the remove function and do not free all resources we
      will create a resource leak. Also all kinds of undefined behaviour are expected
      to happen since the IIO device is still there while its parent is already gone.
      
      The error which the driver tries to handle in the remove function is
      non-critical, so we can just ignore it and continue to free all resources and
      remove the IIO device.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      4922fd69
    • Lars-Peter Clausen's avatar
      staging:iio:ade7754: Do not return a error in remove function · db314a1a
      Lars-Peter Clausen authored
      In the Linux device driver model the remove callback is not allowed to fail and
      the device will be removed regardless of the return value of the remove
      callback. So if we abort in the remove function and do not free all resources we
      will create a resource leak. Also all kinds of undefined behaviour are expected
      to happen since the IIO device is still there while its parent is already gone.
      
      The error which the driver tries to handle in the remove function is
      non-critical, so we can just ignore it and continue to free all resources and
      remove the IIO device.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      db314a1a
    • Lars-Peter Clausen's avatar
      staging:iio:ade7753: Do not return a error in remove function · d576c755
      Lars-Peter Clausen authored
      In the Linux device driver model the remove callback is not allowed to fail and
      the device will be removed regardless of the return value of the remove
      callback. So if we abort in the remove function and do not free all resources we
      will create a resource leak. Also all kinds of undefined behaviour are expected
      to happen since the IIO device is still there while its parent is already gone.
      
      The error which the driver tries to handle in the remove function is
      non-critical, so we can just ignore it and continue to free all resources and
      remove the IIO device.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      d576c755
    • Lars-Peter Clausen's avatar
      staging:iio:adis16400: Do not return a error in remove function · 0b4ac3dc
      Lars-Peter Clausen authored
      In the Linux device driver model the remove callback is not allowed to fail and
      the device will be removed regardless of the return value of the remove
      callback. So if we abort in the remove function and do not free all resources we
      will create a resource leak. Also all kinds of undefined behaviour are expected
      to happen since the IIO device is still there while its parent is already gone.
      
      The error which the driver tries to handle in the remove function is
      non-critical, so we can just ignore it and continue to free all resources and
      remove the IIO device.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      0b4ac3dc
    • Lars-Peter Clausen's avatar
      staging:iio:adis16200: Do not return a error in remove function · bea3e8a3
      Lars-Peter Clausen authored
      In the Linux device driver model the remove callback is not allowed to fail and
      the device will be removed regardless of the return value of the remove
      callback. So if we abort in the remove function and do not free all resources we
      will create a resource leak. Also all kinds of undefined behaviour are expected
      to happen since the IIO device is still there while its parent is already gone.
      
      The error which the driver tries to handle in the remove function is
      non-critical, so we can just ignore it and continue to free all resources and
      remove the IIO device.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      bea3e8a3
    • Kim, Milo's avatar
      iio: inkern: clean up error return code · 3183bac1
      Kim, Milo authored
       When the IIO consumer tries to get specific IIO channel,
       few error cases can be happened.
       (a) Memory allocation failure
       (b) No matched ADC channel error
       (c) Invalid input arguments
       This patch enables cleaning up error handling in case of (a) and (b).
      
       In error handling code,
       (a): the reference count of the IIO device should be decreased.
       (b): the allocated memory should be freed with restoring the reference count.
       Therefore iio_deivce_put() is called in both cases.
       This can be handled in the last error statement.
      
       Additionally, integer variable is used for stating each error case explicitly.
       Then, the error returns as ERR_PTR() with this value.
      Signed-off-by: default avatarMilo(Woogyom) Kim <milo.kim@ti.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      3183bac1
    • Kim, Milo's avatar
      iio: inkern: put the IIO device when it fails to allocate memory · 801c4b5c
      Kim, Milo authored
       The reference count of the IIO device is increased if the IIO map has
       matched consumer name.
       After then, it tries to allocate the iio_channel which is used by the consumer.
       If it fails to allocate memory, the reference count should be decreased.
      
       This patch enables restoring the reference count of the IIO device.
      Signed-off-by: default avatarMilo(Woogyom) Kim <milo.kim@ti.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      801c4b5c
    • Dan Carpenter's avatar
      iio: dac/ad5755: signedness bug in ad5755_setup_pdata() · 369d0e20
      Dan Carpenter authored
      We need "ret" to be signed for the error handling to work correctly.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      369d0e20
    • Srinivas Pandruvada's avatar
      iio: hid-sensors: Prevent crash during hot-unplug · f07b60b7
      Srinivas Pandruvada authored
      When hid sensor hub is unplugged, there is a crash in
      iio_device_unregister_trigger_consumer.
      In a typical IIO driver when remove is called, it will unregister and free
      trigger and then it will call iio_device_free.
      The function iio_trigger_free() will free the allocated memory for trigger.
      If this trigger was assigned to iio_dev->trig, then it should be set to NULL.
      Othewise when iio_device_free() is called later, it finally calls
      iio_device_unregsister_trigger(), which checks for
             if (indio_dev->trig)
                      iio_trigger_put(indio_dev->trig);
      If indio_dev->trig is not set to NULL, it calls iio_trigger_put on a bad
      pointer causing crash.
      This scenerio can happen in any driver, which is storing trigger pointer in
      iio_dev structure and following current procedure during remove.
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      f07b60b7
  2. 18 Sep, 2012 10 commits
  3. 17 Sep, 2012 18 commits