1. 22 Sep, 2012 16 commits
    • Axel Lin's avatar
      HID: hid-sensor-hub: Remove hdev->claimed setting · 3f257caf
      Axel Lin authored
      Current implementation of hid_hw_start() allows connect_mask to be 0.
      Setting hdev->claimed = HID_CLAIMED_INPUT before calling hid_hw_start()
      is not necessary. Remove it.
      Signed-off-by: default avatarAxel Lin <axel.lin@gmail.com>
      Acked-by: default avatarJiri Kosina <jkosina@suse.cz>
      Acked-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      3f257caf
    • Kim, Milo's avatar
      iio: adc: add new lp8788 adc driver · f0347c36
      Kim, Milo authored
       TI LP8788 PMU provides regulators, battery charger, ADC,
       RTC, backlight driver and current sinks.
      
       This patch enables the LP8788 ADC functions.
      
       The LP8788 ADC has several ADC input selection and supports 12bit resolution.
       Internal operation of getting ADC is access to registers of LP8788.
       The LP8788 ADC uses exported functions for accessing these registers.
       (exported by LP8788 MFD device driver)
      
       This driver supports IIO_CHAN_INFO_RAW and SCALE.
       So the IIO consumer can calculate the value with raw and scale.
       The unit of scale is micro.
      
       (ADC Input Selection)
      
       Voltage: battery voltage (MAX 5.0, 5.5 and 6.0V)
                charger input voltage
                four general ADC inputs
                coin cell voltage
       Current: battery charging current
       Temperature: IC temperature
      
       (The IIO map for the IIO consumer)
      
       The ADC input is configurable in the platform side.
       Even though this platform data is not defined,
       the default IIO map is created for supporting the power supply driver.
       The battery voltage and temperature are used inside this driver.
      
       (History)
      
       Patch v6.
       (a) Fix scale value for each ADC input selection
       Voltage and current type are mili unit and temperature is degree.
       To calculate the IC temperature,
       temp = raw * scaleint + (raw * scalepart)/ 1000000, scaleint is always 0.
            = raw * 0.061050, raw: 0 ~ 4095
       Then range of IC temperature(ADC result) is 0 ~ 250'C
      
       (b) Reorganization of the IIO channel Spec
       Remove address, scan_type and scan_index and rollback the datasheet name.
       The reason why 'address' field is unnecessary is no relation with each channel.
       Moreover, to get the raw ADC value, the address info is not only one register
       but also several registers.
       Therefore specific function(lp8788_get_adc_result) is called rather than
       using one 'address' field.
      
       (c) Fix coding style
       Remove duplicated checking routine while unregistering the IIO map.
       Fix code for space and parenthesis.
      
       Patch v5.
       Fix default consumer name as 'lp8788-charger'.
       Add mutex for ADC read operation.
       Reorganization on lp8788_adc_read_raw().
      
       Patch v4.
       Fix adc_raw function: support RAW and SCALE channel info.
       Change LP8788 ADC platform data - iio map.
       Enables the default IIO map.
      
       Patch v3.
       Fix wrong size of allocating iio private data.
       Fix coding styles.
      
       Patch v2.
       Support RAW and SCALE interface for IIO consumer.
       Clean up the iio channel spec macro.
      Signed-off-by: default avatarMilo(Woogyom) Kim <milo.kim@ti.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      f0347c36
    • Lars-Peter Clausen's avatar
      staging:iio:ad7780: Add support for the ad7170/ad7171 · 7aecec98
      Lars-Peter Clausen authored
      The ad7170/ad7171 have a software interface similar to the ad7780. They do not
      have an external pin which allows to change the internal gain and the what is
      used for the gain bit in the ad7780/ad7781 becomes part of the check pattern.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      7aecec98
    • Lars-Peter Clausen's avatar
      staging:iio:ad7780: Make powerdown GPIO optional · 332ed63e
      Lars-Peter Clausen authored
      Some designs hardwire the PDRST pin to always on. In this case there is no GPIO
      to control the mode of the device, so make the GPIO optional. Since now all of
      the the platform data fields are optional now, make the platform data as a whole
      optional as well.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      332ed63e
    • 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 14 commits