1. 05 Jun, 2019 3 commits
  2. 30 May, 2019 1 commit
  3. 24 Apr, 2019 1 commit
  4. 05 Apr, 2019 1 commit
    • Hans de Goede's avatar
      HID: core: Do not call request_module() in async context · 4ceabaf7
      Hans de Goede authored
      request_module() may not be called form async context and in some cases
      hid devices may be added from an async context. One example of this
      happening is under hyperv, where this was triggering a WARN_ON in
      request_module():
      
      [   11.174497]  hid_add_device+0xee/0x2b0 [hid]
      [   11.174499]  mousevsc_probe+0x223/0x2eb [hid_hyperv]
      [   11.174501]  vmbus_probe+0x3a/0x90
      [   11.174504]  really_probe+0x229/0x420
      [   11.174506]  driver_probe_device+0x115/0x130
      [   11.174507]  __driver_attach_async_helper+0x87/0x90
      [   11.174509]  async_run_entry_fn+0x37/0x150
      
      This commit skips the request_module(), falling back to the old behavior
      of letting userspace deal with this, in case we are called from an async
      context.
      
      Cc: Lili Deng <v-lide@microsoft.com>
      Reported-by: default avatarLili Deng <v-lide@microsoft.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      4ceabaf7
  5. 02 Apr, 2019 2 commits
    • Hans de Goede's avatar
      HID: core: Call request_module before doing device_add · a025a18f
      Hans de Goede authored
      Recent kernels allow the generic-hid driver to be used as fallback for
      devices with a specialized driver, when the hiddev is not listed in
      hid_have_special_driver. Over time we are removing more and more
      devices from the hid_have_special_driver table as devices get tested
      to support this setup.
      
      Before this commit the following happens when a HID device which has a
      special-driver and is no longer listed in hid_have_special_driver, gets
      enumerated:
      
      1) device_add() gets called
      2) bus_add_device() looks for a matching already registered hid driver,
         and bind hid-generic to the new device
      3) kobject_uevent(&dev->kobj, KOBJ_ADD) gets called notifying userspace of
         the new hid_dev. udev calls modprobe based on the modalias in the uevent
      4) The special driver gets loaded by modprobe
      5) __hid_bus_reprobe_drivers() unbinds hid-generic and binds the new driver
      
      There are a couple of downsides to this:
      
      a) The probing messages printend when a HID driver bounds show up twice in
      dmesg, which is confusing for the user
      
      b) The (un)binding typically causes one or more evdev device-nodes to get
      (un)registered firing of udev events to which e.g. the xserver responds by
      (un)registering xinput devices and reporting this to interested clients.
      IOW the i. bind generic, ii. unbind generic, iii. bind special driver dance
      sets in motion a whole chain of events each step, while we really only want
      the events from step iii. to be reported to userspace.
      
      This commits introduces a request_module call before the device_add()
      call, so that the special-driver is loaded when step 2) looks for a
      matching driver and we directly bind the specialized driver.
      
      Note the request_module call translates to an execve("/sbin/modprobe", ...)
      and we now do this for each HID device added. So this is not entirely free,
      but adding HID devices is not something which happens 100s of times a
      second, so this should be fine.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      [bentiss: fixed typo in commit message found by checkpatch.pl]
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      a025a18f
    • Nicolas Saenz Julienne's avatar
      HID: core: move Usage Page concatenation to Main item · 58e75155
      Nicolas Saenz Julienne authored
      As seen on some USB wireless keyboards manufactured by Primax, the HID
      parser was using some assumptions that are not always true. In this case
      it's s the fact that, inside the scope of a main item, an Usage Page
      will always precede an Usage.
      
      The spec is not pretty clear as 6.2.2.7 states "Any usage that follows
      is interpreted as a Usage ID and concatenated with the Usage Page".
      While 6.2.2.8 states "When the parser encounters a main item it
      concatenates the last declared Usage Page with a Usage to form a
      complete usage value." Being somewhat contradictory it was decided to
      match Window's implementation, which follows 6.2.2.8.
      
      In summary, the patch moves the Usage Page concatenation from the local
      item parsing function to the main item parsing function.
      Signed-off-by: default avatarNicolas Saenz Julienne <nsaenzjulienne@suse.de>
      Reviewed-by: default avatarTerry Junge <terry.junge@poly.com>
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      58e75155
  6. 18 Mar, 2019 1 commit
  7. 16 Jan, 2019 1 commit
  8. 10 Jan, 2019 1 commit
  9. 07 Dec, 2018 2 commits
    • Peter Hutterer's avatar
      HID: core: process the Resolution Multiplier · 5a4abb36
      Peter Hutterer authored
      The Resolution Multiplier is a feature report that modifies the value of
      Usages within the same Logical Collection. If the multiplier is set to
      anything but 1, the hardware reports (value * multiplier) for the same amount
      of physical movement, i.e. the value we receive in the kernel is
      pre-multiplied.
      
      The hardware may either send a single (value * multiplier), or by sending
      multiplier as many reports with the same value, or a combination of these two
      options. For example, when the Microsoft Sculpt Ergonomic mouse Resolution
      Multiplier is set to 12, the Wheel sends out 12 for every detent but AC Pan
      sends out a value of 3 at 4 times the frequency.
      
      The effective multiplier is based on the physical min/max of the multiplier
      field, a logical min/max of [0,1] with a physical min/max of [1,8] means the
      multiplier is either 1 or 8.
      
      The Resolution Multiplier was introduced for high-resolution scrolling in
      Windows Vista and is commonly used on Microsoft mice.
      
      The recommendation for the Resolution Multiplier is to default to 1 for
      backwards compatibility. This patch adds an arbitrary upper limit at 255. The
      only known use case for the Resolution Multiplier is for scroll wheels where the
      multiplier has to be a fraction of 120 to work with Windows.
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      Verified-by: default avatarHarry Cutts <hcutts@chromium.org>
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      5a4abb36
    • Peter Hutterer's avatar
      HID: core: store the collections as a basic tree · c53431eb
      Peter Hutterer authored
      For each collection parsed, store a pointer to the parent collection
      (if any). This makes it a lot easier to look up which collection(s)
      any given item is part of
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      Verified-by: default avatarHarry Cutts <hcutts@chromium.org>
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      c53431eb
  10. 05 Sep, 2018 1 commit
  11. 28 Aug, 2018 2 commits
    • Stefan Agner's avatar
      HID: core: fix memory leak on probe · b2dd9f2e
      Stefan Agner authored
      The dynamically allocted collection stack does not get freed in
      all situations. Make sure to also free the collection stack when
      using the parser in hid_open_report().
      
      Fixes: 08a8a7cf ("HID: core: do not upper bound the collection stack")
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      b2dd9f2e
    • Song, Hongyan's avatar
      HID: increase maximum global item tag report size to 256 · 71f6fa90
      Song, Hongyan authored
      The maximum globale report size has changed from 32->...->96->128 in the past
      years.  With the development usage of HID, the report_size max value 128 cannot
      satisfy all requirements.
      
      There are applications need to expose intrinsic metadata to camera stabilizing
      applications such as 3DFE application. 3DFE intrinsic is designed to express
      environmental information about sensor that may dynamically change while the
      sensor is running (such data include noise spectral density, bias standard
      deviation)
      
      A sensor data field is SENSOR_VALUE_PAIR that consists of a PROPERTYKEY and
      PROPVARIANT pair. It need to report a unique PROPERTYKEY for each data field.
      
      Take “Noise Spectral Density” as an example, it report count will be
      defined as below:
      
      	"Size of Property key GUID(16 Byte) + property key index(4 Byte) +
      	size of Noise Spectral Density value(4 Byte)"
      
      In this case, the data report max is totally 192(24Byte), which is larger than
      128, while max size 128 blocked it as illegal length. So increase the report
      size to satisfy it and more demands in the future.
      Signed-off-by: default avatarSong Hongyan <hongyan.song@intel.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      71f6fa90
  12. 23 Jul, 2018 1 commit
  13. 17 Jul, 2018 1 commit
  14. 25 Jun, 2018 1 commit
  15. 12 Jun, 2018 1 commit
    • Kees Cook's avatar
      treewide: kmalloc() -> kmalloc_array() · 6da2ec56
      Kees Cook authored
      The kmalloc() function has a 2-factor argument form, kmalloc_array(). This
      patch replaces cases of:
      
              kmalloc(a * b, gfp)
      
      with:
              kmalloc_array(a * b, gfp)
      
      as well as handling cases of:
      
              kmalloc(a * b * c, gfp)
      
      with:
      
              kmalloc(array3_size(a, b, c), gfp)
      
      as it's slightly less ugly than:
      
              kmalloc_array(array_size(a, b), c, gfp)
      
      This does, however, attempt to ignore constant size factors like:
      
              kmalloc(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.
      
      The tools/ directory was manually excluded, since it has its own
      implementation of kmalloc().
      
      The Coccinelle script used for this was:
      
      // Fix redundant parens around sizeof().
      @@
      type TYPE;
      expression THING, E;
      @@
      
      (
        kmalloc(
      -	(sizeof(TYPE)) * E
      +	sizeof(TYPE) * E
        , ...)
      |
        kmalloc(
      -	(sizeof(THING)) * E
      +	sizeof(THING) * E
        , ...)
      )
      
      // Drop single-byte sizes and redundant parens.
      @@
      expression COUNT;
      typedef u8;
      typedef __u8;
      @@
      
      (
        kmalloc(
      -	sizeof(u8) * (COUNT)
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(__u8) * (COUNT)
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(char) * (COUNT)
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(unsigned char) * (COUNT)
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(u8) * COUNT
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(__u8) * COUNT
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(char) * COUNT
      +	COUNT
        , ...)
      |
        kmalloc(
      -	sizeof(unsigned char) * COUNT
      +	COUNT
        , ...)
      )
      
      // 2-factor product with sizeof(type/expression) and identifier or constant.
      @@
      type TYPE;
      expression THING;
      identifier COUNT_ID;
      constant COUNT_CONST;
      @@
      
      (
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * (COUNT_ID)
      +	COUNT_ID, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * COUNT_ID
      +	COUNT_ID, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * (COUNT_CONST)
      +	COUNT_CONST, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * COUNT_CONST
      +	COUNT_CONST, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * (COUNT_ID)
      +	COUNT_ID, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * COUNT_ID
      +	COUNT_ID, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * (COUNT_CONST)
      +	COUNT_CONST, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * COUNT_CONST
      +	COUNT_CONST, sizeof(THING)
        , ...)
      )
      
      // 2-factor product, only identifiers.
      @@
      identifier SIZE, COUNT;
      @@
      
      - kmalloc
      + kmalloc_array
        (
      -	SIZE * COUNT
      +	COUNT, SIZE
        , ...)
      
      // 3-factor product with 1 sizeof(type) or sizeof(expression), with
      // redundant parens removed.
      @@
      expression THING;
      identifier STRIDE, COUNT;
      type TYPE;
      @@
      
      (
        kmalloc(
      -	sizeof(TYPE) * (COUNT) * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE) * (COUNT) * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE) * COUNT * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE) * COUNT * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(TYPE))
        , ...)
      |
        kmalloc(
      -	sizeof(THING) * (COUNT) * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      |
        kmalloc(
      -	sizeof(THING) * (COUNT) * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      |
        kmalloc(
      -	sizeof(THING) * COUNT * (STRIDE)
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      |
        kmalloc(
      -	sizeof(THING) * COUNT * STRIDE
      +	array3_size(COUNT, STRIDE, sizeof(THING))
        , ...)
      )
      
      // 3-factor product with 2 sizeof(variable), with redundant parens removed.
      @@
      expression THING1, THING2;
      identifier COUNT;
      type TYPE1, TYPE2;
      @@
      
      (
        kmalloc(
      -	sizeof(TYPE1) * sizeof(TYPE2) * COUNT
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE1) * sizeof(THING2) * (COUNT)
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
        , ...)
      |
        kmalloc(
      -	sizeof(THING1) * sizeof(THING2) * COUNT
      +	array3_size(COUNT, sizeof(THING1), sizeof(THING2))
        , ...)
      |
        kmalloc(
      -	sizeof(THING1) * sizeof(THING2) * (COUNT)
      +	array3_size(COUNT, sizeof(THING1), sizeof(THING2))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE1) * sizeof(THING2) * COUNT
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
        , ...)
      |
        kmalloc(
      -	sizeof(TYPE1) * sizeof(THING2) * (COUNT)
      +	array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
        , ...)
      )
      
      // 3-factor product, only identifiers, with redundant parens removed.
      @@
      identifier STRIDE, SIZE, COUNT;
      @@
      
      (
        kmalloc(
      -	(COUNT) * STRIDE * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	COUNT * (STRIDE) * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	COUNT * STRIDE * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	(COUNT) * (STRIDE) * SIZE
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	COUNT * (STRIDE) * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	(COUNT) * STRIDE * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	(COUNT) * (STRIDE) * (SIZE)
      +	array3_size(COUNT, STRIDE, SIZE)
        , ...)
      |
        kmalloc(
      -	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 E1, E2, E3;
      constant C1, C2, C3;
      @@
      
      (
        kmalloc(C1 * C2 * C3, ...)
      |
        kmalloc(
      -	(E1) * E2 * E3
      +	array3_size(E1, E2, E3)
        , ...)
      |
        kmalloc(
      -	(E1) * (E2) * E3
      +	array3_size(E1, E2, E3)
        , ...)
      |
        kmalloc(
      -	(E1) * (E2) * (E3)
      +	array3_size(E1, E2, E3)
        , ...)
      |
        kmalloc(
      -	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 THING, E1, E2;
      type TYPE;
      constant C1, C2, C3;
      @@
      
      (
        kmalloc(sizeof(THING) * C2, ...)
      |
        kmalloc(sizeof(TYPE) * C2, ...)
      |
        kmalloc(C1 * C2 * C3, ...)
      |
        kmalloc(C1 * C2, ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * (E2)
      +	E2, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(TYPE) * E2
      +	E2, sizeof(TYPE)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * (E2)
      +	E2, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	sizeof(THING) * E2
      +	E2, sizeof(THING)
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	(E1) * E2
      +	E1, E2
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	(E1) * (E2)
      +	E1, E2
        , ...)
      |
      - kmalloc
      + kmalloc_array
        (
      -	E1 * E2
      +	E1, E2
        , ...)
      )
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      6da2ec56
  16. 16 May, 2018 1 commit
  17. 26 Apr, 2018 1 commit
    • Benjamin Tissoires's avatar
      HID: generic: create one input report per application type · f07b3c1d
      Benjamin Tissoires authored
      It is not a good idea to try to fit all types of applications in the
      same input report. There are a lot of devices that are needing
      the quirk HID_MULTI_INPUT but this quirk doesn't match the actual HID
      description as it is based on the report ID.
      
      Given that most devices with MULTI_INPUT I can think of split nicely
      the devices inputs into application, it is a good thing to split the
      devices by default based on this assumption.
      
      Also make hid-multitouch following this rule, to not have to deal
      with too many input created.
      
      While we are at it, fix some checkpatch complaints about converting
      'unsigned' to 'unsigned int'.
      Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      f07b3c1d
  18. 23 Mar, 2018 1 commit
  19. 06 Mar, 2018 1 commit
  20. 16 Feb, 2018 1 commit
  21. 07 Dec, 2017 1 commit
  22. 21 Nov, 2017 4 commits
  23. 07 Nov, 2017 1 commit
  24. 17 Oct, 2017 2 commits
    • Masaki Ota's avatar
      HID: alps: add new U1 device ID · 287b8e11
      Masaki Ota authored
      Add new U1 device Product ID This device is used on HP Elite book x360 series.
      
      [jkosina@suse.cz: update changelog]
      Signed-off-by: default avatarMasaki Ota <masaki.ota@jp.alps.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      287b8e11
    • Masaki Ota's avatar
      HID: alps: add support for Alps T4 Touchpad device · 73196ebe
      Masaki Ota authored
      - Define T4 device specification value for support T4 device.
      
      - Creeate "t4_contact_data" and "t4_input_report" structure for decoding and
        storing T4-specific data
      
      - Create "t4_calc_check_sum()" function for calculating checksum value to send
        to the device. T4 needs to send this value when reading or writing device
        address value.
      
      - Create "t4_read_write_register()" function for reading and writing device
        address value.
      
      - Create "t4_raw_event()" function for decodin XYZ, palm and button data.
      
      - Replace "MAX_TOUCHES" fixed variable to "max_fingers" variable.
      
      - Add T4 devuce product ID. (0x120C)
      
      T4 device is used on HP EliteBook 1000 series and Zbook Stduio
      
      [jkosina@suse.cz: rewrite changelog]
      Signed-off-by: default avatarMasaki Ota <masaki.ota@jp.alps.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      73196ebe
  25. 11 Oct, 2017 1 commit
  26. 16 Sep, 2017 1 commit
  27. 06 Sep, 2017 1 commit
  28. 01 Aug, 2017 1 commit
  29. 24 Jul, 2017 1 commit
  30. 20 Jul, 2017 1 commit
  31. 22 Jun, 2017 1 commit