1. 20 Oct, 2018 1 commit
  2. 10 Oct, 2018 3 commits
  3. 04 Oct, 2018 1 commit
  4. 15 Sep, 2018 1 commit
    • Dave Young's avatar
      HID: add quirk for another PIXART OEM mouse used by HP · 44e5d0b6
      Dave Young authored
      commit 01cffe9d upstream.
      
      This mouse keep disconnecting in runleve 3 like below, add it needs the
      quirk to mute the anoying messages.
      
      [  111.230555] usb 2-2: USB disconnect, device number 6
      [  112.718156] usb 2-2: new low-speed USB device number 7 using xhci_hcd
      [  112.941594] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
      [  112.984866] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
      [  113.027731] usb 2-2: Product: HP USB Optical Mouse
      [  113.069977] usb 2-2: Manufacturer: PixArt
      [  113.113500] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0002/input/input14
      [  113.156787] hid-generic 0003:03F0:094A.0002: input: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:00:14.0-2/input0
      [  173.262642] usb 2-2: USB disconnect, device number 7
      [  174.750244] usb 2-2: new low-speed USB device number 8 using xhci_hcd
      [  174.935740] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
      [  174.990435] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
      [  175.014984] usb 2-2: Product: HP USB Optical Mouse
      [  175.037886] usb 2-2: Manufacturer: PixArt
      [  175.061794] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0003/input/input15
      [  175.084946] hid-generic 0003:03F0:094A.0003: input: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:00:14.0-2/input0
      Signed-off-by: default avatarDave Young <dyoung@redhat.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      44e5d0b6
  5. 24 Aug, 2018 1 commit
  6. 03 Aug, 2018 2 commits
  7. 11 Jul, 2018 3 commits
  8. 26 Jun, 2018 2 commits
  9. 20 Jun, 2018 3 commits
  10. 26 Apr, 2018 1 commit
  11. 24 Apr, 2018 6 commits
  12. 19 Mar, 2018 2 commits
  13. 28 Feb, 2018 1 commit
  14. 16 Feb, 2018 1 commit
  15. 03 Feb, 2018 2 commits
    • Jason Gerecke's avatar
      HID: wacom: Fix reporting of touch toggle (WACOM_HID_WD_MUTE_DEVICE) events · c76133af
      Jason Gerecke authored
      commit 403c0f68 upstream.
      
      Touch toggle softkeys send a '1' while pressed and a '0' while released,
      requring the kernel to keep track of wether touch should be enabled or
      disabled. The code does not handle the state transitions properly,
      however. If the key is pressed repeatedly, the following four states
      of states are cycled through (assuming touch starts out enabled):
      
      Press:   shared->is_touch_on => 0, SW_MUTE_DEVICE => 1
      Release: shared->is_touch_on => 0, SW_MUTE_DEVICE => 1
      Press:   shared->is_touch_on => 1, SW_MUTE_DEVICE => 0
      Release: shared->is_touch_on => 1, SW_MUTE_DEVICE => 1
      
      The hardware always properly enables/disables touch when the key is
      pressed but applications that listen for SW_MUTE_DEVICE events to provide
      feedback about the state will only ever show touch as being enabled while
      the key is held, and only every-other time. This sequence occurs because
      the fallthrough WACOM_HID_WD_TOUCHONOFF case is always handled, and it
      uses the value of the *local* is_touch_on variable as the value to
      report to userspace. The local value is equal to the shared value when
      the button is pressed, but equal to zero when the button is released.
      
      Reporting the shared value to userspace fixes this problem, but the
      fallthrough case needs to update the shared value in an incompatible
      way (which is why the local variable was introduced in the first place).
      To work around this, we just handle both cases in a single block of code
      and update the shared variable as appropriate.
      
      Fixes: d793ff81 ("HID: wacom: generic: support touch on/off softkey")
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: default avatarAaron Skomra <aaron.skomra@wacom.com>
      Tested-by: default avatarAaron Skomra <aaron.skomra@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c76133af
    • Aaron Armstrong Skomra's avatar
      HID: wacom: EKR: ensure devres groups at higher indexes are released · e3f7e6f2
      Aaron Armstrong Skomra authored
      commit 791ae273 upstream.
      
      Background: ExpressKey Remotes communicate their events via usb dongle.
      Each dongle can hold up to 5 pairings at one time and one EKR (identified
      by its serial number) can unfortunately be paired with its dongle
      more than once. The pairing takes place in a round-robin fashion.
      
      Input devices are only created once per EKR, when a new serial number
      is seen in the list of pairings. However, if a device is created for
      a "higher" paring index and subsequently a second pairing occurs at a
      lower pairing index, unpairing the remote with that serial number from
      any pairing index will currently cause a driver crash. This occurs
      infrequently, as two remotes are necessary to trigger this bug and most
      users have only one remote.
      
      As an illustration, to trigger the bug you need to have two remotes,
      and pair them in this order:
      
      1. slot 0 -> remote 1 (input device created for remote 1)
      2. slot 1 -> remote 1 (duplicate pairing - no device created)
      3. slot 2 -> remote 1 (duplicate pairing - no device created)
      4. slot 3 -> remote 1 (duplicate pairing - no device created)
      5. slot 4 -> remote 2 (input device created for remote 2)
      
      6. slot 0 -> remote 2 (1 destroyed and recreated at slot 1)
      7. slot 1 -> remote 2 (1 destroyed and recreated at slot 2)
      8. slot 2 -> remote 2 (1 destroyed and recreated at slot 3)
      9. slot 3 -> remote 2 (1 destroyed and not recreated)
      10. slot 4 -> remote 2 (2 was already in this slot so no changes)
      
      11. slot 0 -> remote 1 (The current code sees remote 2 was paired over in
                              one of the dongle slots it occupied and attempts
                              to remove all information about remote 2 [1]. It
                              calls wacom_remote_destroy_one for remote 2, but
                              the destroy function assumes the lowest index is
                              where the remote's input device was created. The
                              code "cleans up" the other remote 2 pairings
                              including the one which the input device was based
                              on, assuming they were were just duplicate
                              pairings. However, the cleanup doesn't call the
                              devres release function for the input device that
                              was created in slot 4).
      
      This issue is fixed by this commit.
      
      [1] Remote 2 should subsequently be re-created on the next packet from the
      EKR at the lowest numbered slot that it occupies (here slot 1).
      
      Fixes: f9036bd4 ("HID: wacom: EKR: use devres groups to manage resources")
      Signed-off-by: default avatarAaron Armstrong Skomra <aaron.skomra@wacom.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e3f7e6f2
  16. 20 Dec, 2017 1 commit
  17. 21 Nov, 2017 2 commits
  18. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  19. 11 Oct, 2017 2 commits
    • Alex Manoussakis's avatar
      HID: hid-elecom: extend to fix descriptor for HUGE trackball · a0933a45
      Alex Manoussakis authored
      In addition to DEFT, Elecom introduced a larger trackball called HUGE, in
      both wired (M-HT1URBK) and wireless (M-HT1DRBK) versions. It has the same
      buttons and behavior as the DEFT. This patch adds the two relevant USB IDs
      to enable operation of the three Fn buttons on the top of the device.
      
      Cc: Diego Elio Petteno <flameeyes@flameeyes.eu>
      Signed-off-by: default avatarAlex Manoussakis <amanou@gnu.org>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      a0933a45
    • Jaejoong Kim's avatar
      HID: usbhid: fix out-of-bounds bug · f043bfc9
      Jaejoong Kim authored
      The hid descriptor identifies the length and type of subordinate
      descriptors for a device. If the received hid descriptor is smaller than
      the size of the struct hid_descriptor, it is possible to cause
      out-of-bounds.
      
      In addition, if bNumDescriptors of the hid descriptor have an incorrect
      value, this can also cause out-of-bounds while approaching hdesc->desc[n].
      
      So check the size of hid descriptor and bNumDescriptors.
      
      	BUG: KASAN: slab-out-of-bounds in usbhid_parse+0x9b1/0xa20
      	Read of size 1 at addr ffff88006c5f8edf by task kworker/1:2/1261
      
      	CPU: 1 PID: 1261 Comm: kworker/1:2 Not tainted
      	4.14.0-rc1-42251-gebb2c243 #169
      	Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      	Workqueue: usb_hub_wq hub_event
      	Call Trace:
      	__dump_stack lib/dump_stack.c:16
      	dump_stack+0x292/0x395 lib/dump_stack.c:52
      	print_address_description+0x78/0x280 mm/kasan/report.c:252
      	kasan_report_error mm/kasan/report.c:351
      	kasan_report+0x22f/0x340 mm/kasan/report.c:409
      	__asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
      	usbhid_parse+0x9b1/0xa20 drivers/hid/usbhid/hid-core.c:1004
      	hid_add_device+0x16b/0xb30 drivers/hid/hid-core.c:2944
      	usbhid_probe+0xc28/0x1100 drivers/hid/usbhid/hid-core.c:1369
      	usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
      	really_probe drivers/base/dd.c:413
      	driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
      	__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
      	bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
      	__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
      	device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
      	bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
      	device_add+0xd0b/0x1660 drivers/base/core.c:1835
      	usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
      	generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
      	usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
      	really_probe drivers/base/dd.c:413
      	driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
      	__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
      	bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
      	__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
      	device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
      	bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
      	device_add+0xd0b/0x1660 drivers/base/core.c:1835
      	usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
      	hub_port_connect drivers/usb/core/hub.c:4903
      	hub_port_connect_change drivers/usb/core/hub.c:5009
      	port_event drivers/usb/core/hub.c:5115
      	hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
      	process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
      	worker_thread+0x221/0x1850 kernel/workqueue.c:2253
      	kthread+0x3a1/0x470 kernel/kthread.c:231
      	ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarJaejoong Kim <climbbb.kim@gmail.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      f043bfc9
  20. 02 Oct, 2017 3 commits
  21. 13 Sep, 2017 1 commit