1. 12 Sep, 2016 1 commit
    • Hans de Goede's avatar
      iio: accel: mxc6255: Fix chip-id check · 1696566f
      Hans de Goede authored
      The initial commit adding support for the mxc6225 assumed the
      mxc6225 has a chip-id of 0xe5 based on testing on a single Allwinner
      A23 tablet with a mxc6225. Testing on a bunch of other Allwinner
      tablets have shown that the chip-id for the mxc6225 is not constant.
      
      A datasheet for the MXC6255 which I've found online says that bits
      7 and 6 of the chip-id register are undefined (for the mxc6255), testing
      on 5 different tablets with a mxc6225 has found the following ids:
      0x25, 0x45, 0x65, 0x85, 0xe5. So it seems that for the mxc6225 bits
      7, 6 and 5 of the chip-id register are undefined.
      
      This commit adjusts the chip-id check so that the mxc6255 driver
      properly recognizes the mxc6225 in all these tablets.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      1696566f
  2. 10 Sep, 2016 3 commits
    • Linus Walleij's avatar
      iio: st_sensors: use the helper function · 7ba4b884
      Linus Walleij authored
      The ST sensors can be used as a trigger for its own triggered buffer
      but it is also possible to use an external trigger: a HRTimer or
      even a different sensor (!) as trigger. In that case we should not
      pick the timestamp from our own interrupt top half even if it is
      active.
      
      This could practically happen if some other sensor is using the
      ST sensor as trigger but the ST sensor itself is using e.g.
      an HRTimer as trigger. So the trigger is on, but not used by us.
      
      We used to assume that whenever the hardware interrupt is turned
      on, we are using it for our own trigger, but this is an
      oversimplification.
      
      Handle this logically by using the iio_trigger_using_own() helper.
      
      Cc: Giuseppe Barba <giuseppe.barba@st.com>
      Cc: Denis Ciocca <denis.ciocca@st.com>
      Cc: Crestez Dan Leonard <leonard.crestez@intel.com>
      Cc: Gregor Boirie <gregor.boirie@parrot.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      7ba4b884
    • Linus Walleij's avatar
      iio: trigger: helpers to determine own trigger · 702a7b8e
      Linus Walleij authored
      This adds a helper function to the IIO trigger framework:
      
      iio_trigger_using_own(): for an IIO device, this tells
        whether the device is using itself as a trigger.
        This is true if the indio device:
        (A) supplies a trigger and
        (B) has assigned its own buffer poll function to use this
            trigger.
      
      This helper function is good when constructing triggered,
      buffered drivers that can either use its own hardware *OR*
      an external trigger such as a HRTimer or even the trigger from
      a totally different sensor.
      
      Under such circumstances it is important to know for example
      if the timestamp from the same trigger hardware should be used
      when populating the buffer: if iio_trigger_using_own() is true,
      we can use this timestamp, else we need to pick a unique
      timestamp directly in the trigger handler.
      
      For this to work of course IIO devices registering hardware
      triggers must follow the convention to set the parent device
      properly, as as well as setting the parent of the IIO device
      itself.
      
      When a new poll function is attached, we check if the parent
      device of the IIO of the poll function is the same as the
      parent device of the trigger and in that case we conclude that
      the hardware is using itself as trigger.
      
      Cc: Giuseppe Barba <giuseppe.barba@st.com>
      Cc: Denis Ciocca <denis.ciocca@st.com>
      Cc: Crestez Dan Leonard <leonard.crestez@intel.com>
      Cc: Gregor Boirie <gregor.boirie@parrot.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      702a7b8e
    • Lars-Peter Clausen's avatar
      iio: iio_push_event(): Don't crash if the event interface is not registered · 4b1a9380
      Lars-Peter Clausen authored
      iio_push_event() operates on a struct iio_dev. This struct can be allocated
      using iio_device_alloc() which returns a valid struct iio_dev pointer. But
      iio_push_event() is not safe to use on such a iio_dev until
      iio_device_register() for the same device has successfully completed.
      
      This restriction is not documented anywhere and most drivers are written
      with the assumption that this restriction does not exist. The basic pattern
      that is followed by all drivers looks like the following:
      
      	irqreturn_t event_callback(int irq, void *devid)
      	{
      		struct iio_dev *indio_dev = devid;
      		...
      		iio_push_event(indio_dev, ...);
      
      		return IRQ_HANDLED;
      	}
      
      	int driver_probe(struct device *dev)
      	{
      		struct iio_dev *indio_dev;
      
      		indio_dev = iio_device_alloc(...);
      
      		request_irq(event_irq, event_callback, ..., indio_dev);
      
      		return iio_device_register(indio_dev);
      	}
      
      And while it is unlikely that the IRQ fires before iio_device_register()
      completes (e.g. because the IRQ is disabled in the device) it is not
      impossible and might be triggered by glitches on the signal line or
      incorrect hardware configuration.
      
      To avoid undefined behaviour in such a case extend iio_push_event() to
      check if the event has been registered and discard generated events if it
      has not.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      4b1a9380
  3. 05 Sep, 2016 4 commits
  4. 04 Sep, 2016 2 commits
  5. 03 Sep, 2016 6 commits
  6. 31 Aug, 2016 1 commit
  7. 29 Aug, 2016 16 commits
  8. 23 Aug, 2016 1 commit
    • Greg Kroah-Hartman's avatar
      Merge tag 'iio-for-4.9a' of... · d5bd1eba
      Greg Kroah-Hartman authored
      Merge tag 'iio-for-4.9a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into work-testing
      
      Jonathan writes:
      
      First round of new features, device support and cleanups for IIO in the 4.9 cycle.
      
      Device support
      
      * ak8974
        - New driver and bindings for this 2009 vintage magnetometer (it was very
          popular back then!)
      * atlas-ph-sensor
        -  ORP sensor support(I had to look up what one of these was)
      * cio-dac
        - New driver for Measurement Computing DAC boards
      * dmard06
        - New driver for Domintech DMARDO6 accelerometer. Also vendor prefix.
      * dmard09
        - New driver for Domintech DMARD09 accelerometer.
      * maxim-thermocouple
        - max6675 and max31855 new driver
      * mt6577 auxdac
        - new driver for this Mediatek chip mt2701, mt6577 and mt8173 have this
          hardware.
      * ti-adc161s626
        - new driver for this TI single channel differential ADC.
      * vcnl4000
        - support vcnl4010 and vcnl4020 which are compatible for all features
          currently supported by this driver.
      
      New features
      
      * Core
        - Allow retrieving of underlying iio_dev from a callback buffer handle.
          This is needed to allow client drivers to perform operations such as
          configuring the trigger used.
      * hid-sensors
        - asynchronous resume support to avoid really long resume times.
      * kxcjk-1013
        - add the mysterious KIOX000A ACPI id seen in the wild.
      * Tools
        - lsiio now enumerates processed as well as raw channels.
      
      Cleanup
      
      * ad7298
        - use iio_device_claim_direct_mode and friends to simplify locking around
          mode switching and drop some boilerplate.
      * ad7793
        - use iio_device_claim_direct_mode and friends to simplify locking around
          mode switching and drop some boilerplate.
      * ade7854
        - checkpatch fixups (alignment of parameters)
      * atlas-ph-sensor
        - use iio_device_claim_direct_mode and friends to simplify locking around
          mode switching and drop some boilerplate.
        - Switch to REGCACHE_NONE as there are no useful register to cache.
      * bma180
        - use iio_device_claim_direct_mode and friends to simplify locking around
          mode switching and drop some boilerplate.
      * hdc100x
        - Add mention of the HDC1000 and HDC1008 to the Kconfig help text.
      * isl29018
        - Add driver specific prefixes to defines and function names.
        - Remove excessive logging.
        - Drop newlines which add nothing to readability.
        - General tidying up of comments.
        - Drop I2C_CLASS_HWMON as irrelevant to driver.
      * isl29028
        - Add driver specific prefixes to defines, enums and function names.
        - Drop comma's from available attribute output as not ABI compliant.
        - Drop I2C_CLASS_HWMON as irrelevant to driver.
      * kxsd9
        - devicetree bindings.
      * mag3110
        - This one wasn't locking to protect against mode switches during
          raw_reads.  Use the iio_claim_direct_mode function to fix this buglet.
      * maxim-theromcouple
        - Fix missing selects for triggered buffer support in Kconfig.
      * nau7802
        - Use complete instead of complete_all as only one completion at a time.
      * sx9500
        - Use complete instead of complete_all as only one completion at a time.
      * us5182d
        - Add a missing error code asignment instead of checking the result of
          an already checked statement.
      * vcnl4000
        - Use BIT macro where appropriate.
        - Refactor return codes in read_raw callback.
        - Add some missing locking for concurrent accesses to the device.
      d5bd1eba
  9. 22 Aug, 2016 2 commits
  10. 21 Aug, 2016 4 commits