1. 06 12月, 2018 1 次提交
  2. 05 9月, 2018 1 次提交
  3. 13 6月, 2018 1 次提交
    • K
      treewide: devm_kzalloc() -> devm_kcalloc() · a86854d0
      Kees Cook 提交于
      The devm_kzalloc() function has a 2-factor argument form, devm_kcalloc().
      This patch replaces cases of:
      
              devm_kzalloc(handle, a * b, gfp)
      
      with:
              devm_kcalloc(handle, a * b, gfp)
      
      as well as handling cases of:
      
              devm_kzalloc(handle, a * b * c, gfp)
      
      with:
      
              devm_kzalloc(handle, array3_size(a, b, c), gfp)
      
      as it's slightly less ugly than:
      
              devm_kcalloc(handle, array_size(a, b), c, gfp)
      
      This does, however, attempt to ignore constant size factors like:
      
              devm_kzalloc(handle, 4 * 1024, gfp)
      
      though any constants defined via macros get caught up in the conversion.
      
      Any factors with a sizeof() of "unsigned char", "char", and "u8" were
      dropped, since they're redundant.
      
      Some manual whitespace fixes were needed in this patch, as Coccinelle
      really liked to write "=devm_kcalloc..." instead of "= devm_kcalloc...".
      
      The Coccinelle script used for this was:
      
      // Fix redundant parens around sizeof().
      @@
      expression HANDLE;
      type TYPE;
      expression THING, E;
      @@
      
      (
        devm_kzalloc(HANDLE,
      -	(sizeof(TYPE)) * E
      +	sizeof(TYPE) * E
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	(sizeof(THING)) * E
      +	sizeof(THING) * E
        , ...)
      )
      
      // Drop single-byte sizes and redundant parens.
      @@
      expression HANDLE;
      expression COUNT;
      typedef u8;
      typedef __u8;
      @@
      
      (
        devm_kzalloc(HANDLE,
      -	sizeof(u8) * (COUNT)
      +	COUNT
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(__u8) * (COUNT)
      +	COUNT
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(char) * (COUNT)
      +	COUNT
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(unsigned char) * (COUNT)
      +	COUNT
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(u8) * COUNT
      +	COUNT
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(__u8) * COUNT
      +	COUNT
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(char) * COUNT
      +	COUNT
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(unsigned char) * COUNT
      +	COUNT
        , ...)
      )
      
      // 2-factor product with sizeof(type/expression) and identifier or constant.
      @@
      expression HANDLE;
      type TYPE;
      expression THING;
      identifier COUNT_ID;
      constant COUNT_CONST;
      @@
      
      (
      - devm_kzalloc
      + devm_kcalloc
        (HANDLE,
      -	sizeof(TYPE) * (COUNT_ID)
      +	COUNT_ID, sizeof(TYPE)
        , ...)
      |
      - devm_kzalloc
      + devm_kcalloc
        (HANDLE,
      -	sizeof(TYPE) * COUNT_ID
      +	COUNT_ID, sizeof(TYPE)
        , ...)
      |
      - devm_kzalloc
      + devm_kcalloc
        (HANDLE,
      -	sizeof(TYPE) * (COUNT_CONST)
      +	COUNT_CONST, sizeof(TYPE)
        , ...)
      |
      - devm_kzalloc
      + devm_kcalloc
        (HANDLE,
      -	sizeof(TYPE) * COUNT_CONST
      +	COUNT_CONST, sizeof(TYPE)
        , ...)
      |
      - devm_kzalloc
      + devm_kcalloc
        (HANDLE,
      -	sizeof(THING) * (COUNT_ID)
      +	COUNT_ID, sizeof(THING)
        , ...)
      |
      - devm_kzalloc
      + devm_kcalloc
        (HANDLE,
      -	sizeof(THING) * COUNT_ID
      +	COUNT_ID, sizeof(THING)
        , ...)
      |
      - devm_kzalloc
      + devm_kcalloc
        (HANDLE,
      -	sizeof(THING) * (COUNT_CONST)
      +	COUNT_CONST, sizeof(THING)
        , ...)
      |
      - devm_kzalloc
      + devm_kcalloc
        (HANDLE,
      -	sizeof(THING) * COUNT_CONST
      +	COUNT_CONST, sizeof(THING)
        , ...)
      )
      
      // 2-factor product, only identifiers.
      @@
      expression HANDLE;
      identifier SIZE, COUNT;
      @@
      
      - devm_kzalloc
      + devm_kcalloc
        (HANDLE,
      -	SIZE * COUNT
      +	COUNT, SIZE
        , ...)
      
      // 3-factor product with 1 sizeof(type) or sizeof(expression), with
      // redundant parens removed.
      @@
      expression HANDLE;
      expression THING;
      identifier STRIDE, COUNT;
      type TYPE;
      @@
      
      (
        devm_kzalloc(HANDLE,
      -	sizeof(TYPE) * (COUNT) * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(TYPE) * (COUNT) * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(TYPE) * COUNT * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(TYPE) * COUNT * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(THING) * (COUNT) * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(THING) * (COUNT) * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(THING) * COUNT * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(THING) * COUNT * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      )
      
      // 3-factor product with 2 sizeof(variable), with redundant parens removed.
      @@
      expression HANDLE;
      expression THING1, THING2;
      identifier COUNT;
      type TYPE1, TYPE2;
      @@
      
      (
        devm_kzalloc(HANDLE,
      -	sizeof(TYPE1) * sizeof(TYPE2) * COUNT
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(TYPE1) * sizeof(THING2) * (COUNT)
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(THING1) * sizeof(THING2) * COUNT
      +	array3_size(COUNT, sizeof(THING1), sizeof(THING2))
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(THING1) * sizeof(THING2) * (COUNT)
      +	array3_size(COUNT, sizeof(THING1), sizeof(THING2))
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(TYPE1) * sizeof(THING2) * COUNT
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	sizeof(TYPE1) * sizeof(THING2) * (COUNT)
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
        , ...)
      )
      
      // 3-factor product, only identifiers, with redundant parens removed.
      @@
      expression HANDLE;
      identifier STRIDE, SIZE, COUNT;
      @@
      
      (
        devm_kzalloc(HANDLE,
      -	(COUNT) * STRIDE * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	COUNT * (STRIDE) * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	COUNT * STRIDE * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	(COUNT) * (STRIDE) * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	COUNT * (STRIDE) * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	(COUNT) * STRIDE * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	(COUNT) * (STRIDE) * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	COUNT * STRIDE * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      )
      
      // Any remaining multi-factor products, first at least 3-factor products,
      // when they're not all constants...
      @@
      expression HANDLE;
      expression E1, E2, E3;
      constant C1, C2, C3;
      @@
      
      (
        devm_kzalloc(HANDLE, C1 * C2 * C3, ...)
      |
        devm_kzalloc(HANDLE,
      -	(E1) * E2 * E3
      +	array3_size(E1, E2, E3)
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	(E1) * (E2) * E3
      +	array3_size(E1, E2, E3)
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	(E1) * (E2) * (E3)
      +	array3_size(E1, E2, E3)
        , ...)
      |
        devm_kzalloc(HANDLE,
      -	E1 * E2 * E3
      +	array3_size(E1, E2, E3)
        , ...)
      )
      
      // And then all remaining 2 factors products when they're not all constants,
      // keeping sizeof() as the second factor argument.
      @@
      expression HANDLE;
      expression THING, E1, E2;
      type TYPE;
      constant C1, C2, C3;
      @@
      
      (
        devm_kzalloc(HANDLE, sizeof(THING) * C2, ...)
      |
        devm_kzalloc(HANDLE, sizeof(TYPE) * C2, ...)
      |
        devm_kzalloc(HANDLE, C1 * C2 * C3, ...)
      |
        devm_kzalloc(HANDLE, C1 * C2, ...)
      |
      - devm_kzalloc
      + devm_kcalloc
        (HANDLE,
      -	sizeof(TYPE) * (E2)
      +	E2, sizeof(TYPE)
        , ...)
      |
      - devm_kzalloc
      + devm_kcalloc
        (HANDLE,
      -	sizeof(TYPE) * E2
      +	E2, sizeof(TYPE)
        , ...)
      |
      - devm_kzalloc
      + devm_kcalloc
        (HANDLE,
      -	sizeof(THING) * (E2)
      +	E2, sizeof(THING)
        , ...)
      |
      - devm_kzalloc
      + devm_kcalloc
        (HANDLE,
      -	sizeof(THING) * E2
      +	E2, sizeof(THING)
        , ...)
      |
      - devm_kzalloc
      + devm_kcalloc
        (HANDLE,
      -	(E1) * E2
      +	E1, E2
        , ...)
      |
      - devm_kzalloc
      + devm_kcalloc
        (HANDLE,
      -	(E1) * (E2)
      +	E1, E2
        , ...)
      |
      - devm_kzalloc
      + devm_kcalloc
        (HANDLE,
      -	E1 * E2
      +	E1, E2
        , ...)
      )
      Signed-off-by: NKees Cook <keescook@chromium.org>
      a86854d0
  4. 10 8月, 2017 1 次提交
    • S
      HID: hid-sensor-hub: Force logical minimum to 1 for power and report state · b0f847e1
      Srinivas Pandruvada 提交于
      In the reference HID sensor hub firmware all Named array enums were
      0-based. There is no description of the default base of enums in HID
      sensor hub specification as logical minimum should have set this base
      value.
      
      Every sensor hub implemented enum as 1-based, without explicitly setting
      logical minimum to 1, because of the implementation by one of the major
      OS vendor. In Linux we used logical minimum to decide the enum base.
      
      Some sensor hub FWs already changed logical minimum from 0 to 1. We hoped
      that every other vendor will follow. But that didn't happen and we had to
      fix the report header for every sensor hub to change logical minimum to 1
      by using .report_fixup() callback. So for every new sensor hub we had to
      modify source code by adding this quirk based on the vendor and device id.
      This is becoming a maintenance burden.
      
      This patch hardcodes the logical minimum of power and report state
      attributes to 1. In this way we can remove the existing quirks and also
      we don't have to add more quirks.
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Acked-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      b0f847e1
  5. 02 1月, 2017 1 次提交
  6. 28 11月, 2016 2 次提交
  7. 24 11月, 2016 1 次提交
    • S
      HID: hid-sensor-hub: clear memory to avoid random data · d443a0aa
      Song Hongyan 提交于
      When user tried to read some fields like hysteresis from IIO sysfs on some
      systems, it fails. The reason is that this field is a byte field and caller
      of sensor_hub_get_feature() passes a buffer of 4 bytes. Here the function
      sensor_hub_get_feature() copies the single byte from the report to the
      caller buffer and returns "1" as the number of bytes copied. So caller
      can use the return value.
      
      But this is done by multiple callers, so if we just change the
      sensor_hub_get_feature so that caller buffer is initialized with 0s
      then we don't to change all functions.
      Signed-off-by: NSong Hongyan <hongyan.song@intel.com>
      Acked-by: NJonathan Cameron <jic23@kernel.org>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      d443a0aa
  8. 04 11月, 2016 1 次提交
    • S
      HID: sensor-hub: Fix packing of result buffer for feature report · 5459ada2
      Srinivas Pandruvada 提交于
      When report count is more than one and report size is not 4 bytes, then we
      need some packing into result buffer from the caller of function
      sensor_hub_get_feature.
      By default the value extracted from a field is 4 bytes from hid core
      (using hid_hw_request(hsdev->hdev, report, HID_REQ_GET_REPORT)), even
      if report size if less than 4 byte. So when we copy data to user buffer in
      sensor_hub_get_feature, we need to only copy report size bytes even
      when report count is more than 1. This is
      not an issue for most of the sensor hub fields as report count will be 1
      where we already copy only report size bytes, but some string fields
      like description, it is a problem as the report count will be more than 1.
      For example:
          Field(6)
            Physical(Sensor.OtherCustom)
            Application(Sensor.Sensor)
            Usage(11)
              Sensor.0306
              Sensor.0306
              Sensor.0306
              Sensor.0306
              Sensor.0306
              Sensor.0306
              Sensor.0306
              Sensor.0306
              Sensor.0306
              Sensor.0306
              Sensor.0306
            Report Size(16)
            Report Count(11)
      
      Here since the report size is 2 bytes, we will have 2 additional bytes of
      0s copied into user buffer, if we directly copy to user buffer from
      report->field[]->value
      
      This change will copy report size bytes into the buffer of caller for each
      usage report->field[]->value. So for example without this change, the
      data displayed for a custom sensor field "sensor-model":
      
      76 00 101 00 110 00 111 00 118 00 111
      (truncated to report count of 11)
      
      With change
      
      76 101 110 111 118 111 32 89 111 103 97
      ("Lenovo Yoga" in ASCII )
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      5459ada2
  9. 17 8月, 2016 1 次提交
  10. 08 1月, 2016 1 次提交
  11. 17 11月, 2015 1 次提交
  12. 21 10月, 2015 1 次提交
  13. 06 10月, 2015 1 次提交
    • R
      HID: sensor-hub: Add quirk for Lenovo Yoga 2 with ITE Chips · e8e88438
      Ritesh Raj Sarraf 提交于
      This patch is a follow-up to 47eeca8a48 (" HID: sensor-hub: Add in quirk
      for Lenovo Yogas with ITE")
      
      The Lenovo Yoga 2 13 seems to be sold in multiple variants with minor
      difference3s. IN my case, the USB ID for ITE chip is different than the
      Yoga 2 11 and Yoga 3 14.
      
      Without the quirk, no data is received from the accelerometer. I have
      verified the patch, testing this on 4.3-rc4 (and 4.2 stable). With this
      patch, proper orientation data is received.
      
      rrs@learner:~/Community/UpstreamSources/linux-upstream_GIT (stable-42)$
      monitor-sensor
      ** Message: Accelerometer orientation changed: bottom-up
      ** Message: Light changed: 0.000000 (lux)
      ±** Message: Accelerometer orientation changed: left-up
      ** Message: Accelerometer orientation changed: bottom-up
      ** Message: Accelerometer orientation changed: left-up
      ** Message: Accelerometer orientation changed: normal
      ** Message: Light changed: 29.999999 (lux)
      
      monitor-sensor can be found in the iio-sensor-proxy tool.
      Signed-off-by: NRitesh Raj Sarraf <rrs@debian.org>
      Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      e8e88438
  14. 04 9月, 2015 1 次提交
    • F
      HID: sensor-hub: Fixup for Lenovo ThinkPad Helix 2 sensor hub report · 9fe8ecca
      Fernando D S Lima 提交于
      There is an error in the report descriptor of the Thinkpad Helix 2 where
      logical minimum value (557376) is greater than logical maximum (491200)
      for all of the magnetic flux axis data fields. This error results in a
      report descriptor parsing failure that causes the sensors attached to the
      hub not to be detected.
      
      dmesg excerpt:
      [   19.866905] drivers/hid/hid-core.c: logical range invalid 0x88140 0x77ec0
      [   19.866914] hid-sensor-hub 0018:2047:0855.0007: item 0 1 0 8 parsing failed
      [   19.866926] hid-sensor-hub 0018:2047:0855.0007: parse failed
      [   19.866933] hid-sensor-hub: probe of 0018:2047:0855.0007 failed with error -22
      
      Add a report fixup to change magnetic flux logical minimums to -557376
      for the parsing to succeed and the sensors to get detected.
      After applying the fix the sensors get detected, with corresponding drivers
      (hid-accel-3d,hid-gyro-3d,etc) loaded, and its possible to read their values.
      Signed-off-by: NFernando D S Lima <fernandodsl@gmail.com>
      Reviewed-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      9fe8ecca
  15. 08 7月, 2015 1 次提交
  16. 12 5月, 2015 1 次提交
    • S
      HID: hid-sensor-hub: Fix debug lock warning · 2d94e522
      Srinivas Pandruvada 提交于
      When CONFIG_DEBUG_LOCK_ALLOC is defined, mutex magic is compared and
      warned for (l->magic != l), here l is the address of mutex pointer.
      In hid-sensor-hub as part of hsdev creation, a per hsdev mutex is
      initialized during MFD cell creation. This hsdev, which contains, mutex
      is part of platform data for the a cell. But platform_data is copied
      in platform_device_add_data() in platform.c. This copy will copy the
      whole hsdev structure including mutex. But once copied the magic
      will no longer match. So when client driver call
      sensor_hub_input_attr_get_raw_value, this will trigger mutex warning.
      So to avoid this allocate mutex dynamically. This will be same even
      after copy.
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      2d94e522
  17. 16 3月, 2015 2 次提交
  18. 23 2月, 2015 5 次提交
  19. 17 2月, 2015 1 次提交
  20. 26 11月, 2014 1 次提交
  21. 04 9月, 2014 1 次提交
  22. 15 8月, 2014 1 次提交
  23. 12 8月, 2014 1 次提交
  24. 30 6月, 2014 1 次提交
    • J
      HID: sensor-hub: fix potential memory leak · ceec6340
      Jiri Slaby 提交于
      hsdev is not freed in sensor_hub_probe when kasprintf inside the for
      loop fails. This is because hsdev is not set to platform_data yet (to
      be freed by the code in the err_no_mem label). So free the memory
      explicitly in the 'if' branch, as this is the only place where this is
      (and will) be needed.
      
      Reported-by: coverity
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: srinivas pandruvada <srinivas.pandruvada@intel.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      ceec6340
  25. 10 6月, 2014 1 次提交
  26. 02 6月, 2014 1 次提交
  27. 28 5月, 2014 1 次提交
  28. 06 5月, 2014 1 次提交
  29. 04 4月, 2014 1 次提交
  30. 25 3月, 2014 1 次提交
    • S
      HID: hid-sensor-hub: fix sleeping function called from invalid context · f74346a0
      Srinivas Pandruvada 提交于
      Fix issue with the sleeping calling hid_hw_request under spinlock.
      When i2c is used as HID transport, this is calling kmalloc, which
      can sleep. So remove call to this function while under spinlock.
       [ 1067.021961] Call Trace:
       [ 1067.021970]  [<ffffffff8192f5f2>] dump_stack+0x4d/0x6f
       [ 1067.021976]  [<ffffffff811109f2>] __might_sleep+0xd2/0xf0
       [ 1067.021981]  [<ffffffff811ea15b>] __kmalloc+0xeb/0x200
       [ 1067.021989]  [<ffffffff816e0cb3>] ? hid_alloc_report_buf+0x23/0x30
       [ 1067.021993]  [<ffffffff816e0cb3>] hid_alloc_report_buf+0x23/0x30
       [ 1067.021997]  [<ffffffff816f4cb7>] i2c_hid_request+0x57/0x110
       [ 1067.022006]  [<ffffffffa02bc61c>] sensor_hub_input_attr_get_raw_value+0xbc/0x100 [hid_sensor_hub]
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      f74346a0
  31. 18 2月, 2014 1 次提交
    • S
      HID: hid-sensor-hub: Processing for duplicate physical ids · ca2ed12f
      Srinivas Pandruvada 提交于
      In HID sensor hub, HID physical ids are used to represent different sensors.
      For example physical id of 0x73 in usage page = 0x20, represents an
      accelerometer. The HID sensor hub driver uses this physical ids to create
      platform devices using MFD. There is 1:1 correspondence between an phy id and a
      client driver.
      
      But in some cases these physical ids are reused. There is a phy id 0xe1, which
      specifies a custom sensor, which can exist multiple times to represent various
      custom sensors. In this case there can be multiple instances of client MFD
      drivers, processing specific custom sensor. In this case when client driver
      looks for report id or a field index, it should still get the report id
      specific to its own type. This is also true for reports, they should be
      directed towards correct instance.  This change introduce a way to parse and
      tie physical devices to their correct instance.
      
      Summary of changes:
      - To get physical ids, use collections. If a collection of type=physical
        exist then use usage id as in the name of platform device name
      - As part of the platform data, we assign a hdsev instance, which has
        start and end of collection indexes. Using these indexes attributes
        can be tied to correct MFD client instances
      - When a report is received, call callback with correct hsdev instance.
        In this way using its private data stored as part of its registry, it
        can distinguish different sensors even when they have same physical and
        logical ids.
      
        This patch is co-authored with Archana Patni <archna.patni@intel.com>.
      Reported-by: NArchana Patni <archana.patni@intel.com>
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NArchana Patni <archana.patni@intel.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      ca2ed12f
  32. 17 2月, 2014 2 次提交
  33. 17 1月, 2014 1 次提交
    • S
      HID: hid-sensor-hub: Fix buggy report descriptors · 875e36f8
      Srinivas Pandruvada 提交于
      This addresses regression caused by commit id "751d17e2"
       iio: hid-sensors: Fix power and report state.
      This commit removed a quirk, to change the enumeration base
      to 1 from 0 based on an CONFIG paramter. There was objection to
      add more changes under this quirk, instead suggested to add an
      HID quirk. But there is no easy way to add HID qurik as the
      reports are not properly using collection class.
      
      The solution was to use logical minimum, which is a correct way.
      There were changes done in firmware to address this.
      
      Unfortunately some devices, still use old FW and can't be upgraded
      to newer version on Linux devices as there is no FW upgrade tool
      available for Linux devices. So we need to fix report descriptors,
      for such devices. This will not have any impact, if the FW uses
      logical 1 as minimum.
      
      In this patch we look for usage id for "power and report state", and
      modify logical minimum value to 1.
      
      Background on enum:
      In the original HID sensor hub firmwares all Named array enums were
      to 0-based. But the most recent hub implemented as 1-based,
      because of the implementation by one of the major OS vendor.
      Using logical minimum for the field as the base of enum. So we add
      logical minimum to the selector values before setting those fields.
      Some sensor hub FWs already changed logical minimum from 0 to 1
      to reflect this and hope every other vendor will follow.
      There is no easy way to add a common HID quirk for NAry elements,
      even if the standard specifies these field as NAry, the collection
      used to describe selectors is still just "logical".
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      875e36f8