1. 22 9月, 2012 18 次提交
    • A
      power: battery: Generic battery driver using IIO · e60fea79
      anish kumar 提交于
      Driver to allow use of the ADC drivers supported by the IIO
      subsystem for battery status monitoring. Connecting this
      driver to the relevant IIO device requires registration of
      the appropriate iio_map structure array by the IIO device
      driver (usually from platform data).  If specified the driver
      will also make use of a gpio to provide interrupt driven
      notification that the battery is fully charged.
      
      In last version:
      Addressed concerns raised by lars:
      a. made the adc_bat per device.
      b. get the IIO channel using hardcoded channel names.
      c. Minor issues related to gpio_is_valid and some code
         refactoring.
      
      In V1:
      Addressed concerns raised by Anton:
      a. changed the struct name to gab(generic adc battery).
      b. Added some functions to neaten the code.
      c. Some minor coding guidelines changes.
      d. Used the latest function introduce by lars:
         iio_read_channel_processed to streamline the code.
      
      In V2:
      Addressed concerns by lars:
      a. No need of allocating memory for channels.Make it array.
      b. Code restructring, coding style and following kernel guidelines changes
         suggested by him.
      
      In V3:
      Addressed conerns by Anton:
      a. Added the copyright.
      b. Coding guidelines changes suggested by him.
      c. Added Makefile and Kconfig
      Signed-off-by: Nanish kumar <anish198519851985@gmail.com>
      Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      e60fea79
    • A
      HID: hid-sensor-hub: Fix sensor_hub_probe error handling · f2f13a68
      Axel Lin 提交于
      Fix below issues:
      1. In the case of goto err_close, hid_hw_stop(hdev) is called twice. Fix it.
      2. If fails to allocate MFD device name, we also need to free all
         successfully allocated names in previous iterations.
      3. In sensor_hub_remove(), Call hid_hw_close() before hid_hw_stop().
      4. Adjust unnecessary change lines for hid_err.
      Signed-off-by: NAxel Lin <axel.lin@gmail.com>
      Acked-by: NJiri Kosina <jkosina@suse.cz>
      Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      f2f13a68
    • A
      HID: hid-sensor-hub: Remove hdev->claimed setting · 3f257caf
      Axel Lin 提交于
      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: NAxel Lin <axel.lin@gmail.com>
      Acked-by: NJiri Kosina <jkosina@suse.cz>
      Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      3f257caf
    • K
      iio: adc: add new lp8788 adc driver · f0347c36
      Kim, Milo 提交于
       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: NMilo(Woogyom) Kim <milo.kim@ti.com>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      f0347c36
    • L
      staging:iio:ad7780: Add support for the ad7170/ad7171 · 7aecec98
      Lars-Peter Clausen 提交于
      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: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      7aecec98
    • L
      staging:iio:ad7780: Make powerdown GPIO optional · 332ed63e
      Lars-Peter Clausen 提交于
      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: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      332ed63e
    • L
      staging:iio:sca3000: Do not return a error in remove function · 67ad4e08
      Lars-Peter Clausen 提交于
      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: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      67ad4e08
    • L
      staging:iio:lis3l02dq: Do not return a error in remove function · e71a837c
      Lars-Peter Clausen 提交于
      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: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      e71a837c
    • L
      staging:iio:ade7759: Do not return a error in remove function · e854bcc9
      Lars-Peter Clausen 提交于
      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: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      e854bcc9
    • L
      staging:iio:ade7758: Do not return a error in remove function · 4922fd69
      Lars-Peter Clausen 提交于
      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: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      4922fd69
    • L
      staging:iio:ade7754: Do not return a error in remove function · db314a1a
      Lars-Peter Clausen 提交于
      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: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      db314a1a
    • L
      staging:iio:ade7753: Do not return a error in remove function · d576c755
      Lars-Peter Clausen 提交于
      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: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      d576c755
    • L
      staging:iio:adis16400: Do not return a error in remove function · 0b4ac3dc
      Lars-Peter Clausen 提交于
      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: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      0b4ac3dc
    • L
      staging:iio:adis16200: Do not return a error in remove function · bea3e8a3
      Lars-Peter Clausen 提交于
      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: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      bea3e8a3
    • K
      iio: inkern: clean up error return code · 3183bac1
      Kim, Milo 提交于
       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: NMilo(Woogyom) Kim <milo.kim@ti.com>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      3183bac1
    • K
      iio: inkern: put the IIO device when it fails to allocate memory · 801c4b5c
      Kim, Milo 提交于
       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: NMilo(Woogyom) Kim <milo.kim@ti.com>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      801c4b5c
    • D
      iio: dac/ad5755: signedness bug in ad5755_setup_pdata() · 369d0e20
      Dan Carpenter 提交于
      We need "ret" to be signed for the error handling to work correctly.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      369d0e20
    • S
      iio: hid-sensors: Prevent crash during hot-unplug · f07b60b7
      Srinivas Pandruvada 提交于
      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: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      f07b60b7
  2. 19 9月, 2012 3 次提交
  3. 18 9月, 2012 19 次提交