1. 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
  2. 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
  3. 08 Mar, 2019 37 commits