Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 30 4月, 2020 3 次提交
  3. 29 4月, 2020 1 次提交
    • A
      HID: usbhid: Fix race between usbhid_close() and usbhid_stop() · 0ed08fad
      由 Alan Stern 提交于 
      The syzbot fuzzer discovered a bad race between in the usbhid driver
between usbhid_stop() and usbhid_close().  In particular,
usbhid_stop() does:

	usb_free_urb(usbhid->urbin);
	...
	usbhid->urbin = NULL; /* don't mess up next start */

and usbhid_close() does:

	usb_kill_urb(usbhid->urbin);

with no mutual exclusion.  If the two routines happen to run
concurrently so that usb_kill_urb() is called in between the
usb_free_urb() and the NULL assignment, it will access the
deallocated urb structure -- a use-after-free bug.

This patch adds a mutex to the usbhid private structure and uses it to
enforce mutual exclusion of the usbhid_start(), usbhid_stop(),
usbhid_open() and usbhid_close() callbacks.

Reported-and-tested-by: syzbot+7bf5a7b0f0a1f9446f4c@syzkaller.appspotmail.com
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      0ed08fad
  5. 17 4月, 2020 1 次提交
    • J
      Revert "HID: wacom: generic: read the number of expected touches on a per collection basis" · b43f977d
      由 Jason Gerecke 提交于 
      This reverts commit 15893fa4.

The referenced commit broke pen and touch input for a variety of devices
such as the Cintiq Pro 32. Affected devices may appear to work normally
for a short amount of time, but eventually loose track of actual touch
state and can leave touch arbitration enabled which prevents the pen
from working. The commit is not itself required for any currently-available
Bluetooth device, and so we revert it to correct the behavior of broken
devices.

This breakage occurs due to a mismatch between the order of collections
and the order of usages on some devices. This commit tries to read the
contact count before processing events, but will fail if the contact
count does not occur prior to the first logical finger collection. This
is the case for devices like the Cintiq Pro 32 which place the contact
count at the very end of the report.

Without the contact count set, touches will only be partially processed.
The `wacom_wac_finger_slot` function will not open any slots since the
number of contacts seen is greater than the expectation of 0, but we will
still end up calling `input_mt_sync_frame` for each finger anyway. This
can cause problems for userspace separate from the issue currently taking
place in the kernel. Only once all of the individual finger collections
have been processed do we finally get to the enclosing collection which
contains the contact count. The value ends up being used for the *next*
report, however.

This delayed use of the contact count can cause the driver to loose track
of the actual touch state and believe that there are contacts down when
there aren't. This leaves touch arbitration enabled and prevents the pen
from working. It can also cause userspace to incorrectly treat single-
finger input as gestures.

Link: https://github.com/linuxwacom/input-wacom/issues/146Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: NAaron Armstrong Skomra <aaron.skomra@wacom.com>
Fixes: 15893fa4 ("HID: wacom: generic: read the number of expected touches on a per collection basis")
Cc: stable@vger.kernel.org # 5.3+
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      b43f977d
  7. 15 4月, 2020 1 次提交
  9. 14 4月, 2020 3 次提交
  11. 03 4月, 2020 1 次提交
  13. 23 3月, 2020 1 次提交
  15. 21 3月, 2020 2 次提交
  17. 18 3月, 2020 3 次提交
    • S
      HID: Add driver fixing Glorious PC Gaming Race mouse report descriptor · 77a36a3a
      由 Samuel Čavoj 提交于 
      The Glorious Model O mice (and also at least the Model O-, which is
driver-wise the same mouse) have a bug in the descriptor of HID
Report with ID 2. This report is used for Consumer Control buttons,
which can be mapped using the provided Windows only software.

Here is an excerpt from the original descriptor:

  INPUT(2)[INPUT]
    Field(0)
      Flags( Constant Variable Absolute )
    Field(1)
      Flags( Constant Variable Absolute )
    Field(2)
      Flags( Constant Variable Absolute )

The issue is the Constant flag specified on all 3 fields, which
causes the hid driver to ignore changes in these fields and
essentialy causes the buttons to not work at all. The submitted driver
patches the descriptor to end up with the following:

  INPUT(2)[INPUT]
    Field(0)
      Flags( Variable Relative )
    Field(1)
      Flags( Variable Relative )
    Field(2)
      Flags( Variable Relative )

The Constant bit is reset and the Relative bit has been set in
order to prevent repeat events when holding down the button.

Additionally, the device name is changed from the hardware-reported
"SINOWEALTH Wired Gaming Mouse" to "Glorious Model O" or "Glorious
Model D".
Signed-off-by: NSamuel Čavoj <sammko@sammserver.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      77a36a3a
    • H
      HID: lg-g15: Do not fail the probe when we fail to disable F# emulation · b8a75ead
      由 Hans de Goede 提交于 
      By default the G1-G12 keys on the Logitech gaming keyboards send
F1 - F12 when in "generic HID" mode.

The first thing the hid-lg-g15 driver does is disable this behavior.

We have received a bugreport that this does not work when the keyboard
is connected through an Aten KVM switch. Using a gaming keyboard with
a KVM is a bit weird setup, but still we can try to fail a bit more
gracefully here.

On the G510 keyboards the same USB-interface which is used for the gaming
keys is also used for the media-keys. Before this commit we would call
hid_hw_stop() on failure to disable the F# emulation and then exit the
probe method with an error code.

This not only causes us to not handle the gaming-keys, but this also
breaks the media keys which is a regression compared to the situation
when these keyboards where handled by the generic hidinput driver.

This commit changes the error handling to clear the hiddev drvdata
(to disable our .raw_event handler) and then returning from the probe
method with success.

The net result of this is that, when connected through a KVM, things
work as well as they did before the hid-lg-g15 driver was introduced.

Fixes: ad4203f5 ("HID: lg-g15: Add support for the G510 keyboards' gaming keys")
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1806321Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      b8a75ead
    • G
      HID: fix Kconfig word ordering · ad81d1c8
      由 Geert Uytterhoeven 提交于 
      Fix a silly word ordering typo.

Fixes: 42337b9d ("HID: add driver for U2F Zero built-in LED and RNG")
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      ad81d1c8
  19. 17 3月, 2020 1 次提交
  21. 16 3月, 2020 1 次提交
  23. 14 3月, 2020 2 次提交
  25. 11 3月, 2020 2 次提交
  27. 10 3月, 2020 2 次提交
  29. 05 3月, 2020 1 次提交
  31. 18 2月, 2020 3 次提交
  33. 14 2月, 2020 1 次提交
  35. 12 2月, 2020 6 次提交
  37. 03 2月, 2020 1 次提交
    • H
      HID: ite: Only bind to keyboard USB interface on Acer SW5-012 keyboard dock · beae5619
      由 Hans de Goede 提交于 
      Commit 8f18eca9 ("HID: ite: Add USB id match for Acer SW5-012 keyboard
dock") added the USB id for the Acer SW5-012's keyboard dock to the
hid-ite driver to fix the rfkill driver not working.

Most keyboard docks with an ITE 8595 keyboard/touchpad controller have the
"Wireless Radio Control" bits which need the special hid-ite driver on the
second USB interface (the mouse interface) and their touchpad only supports
mouse emulation, so using generic hid-input handling for anything but
the "Wireless Radio Control" bits is fine. On these devices we simply bind
to all USB interfaces.

But unlike other ITE8595 using keyboard docks, the Acer Aspire Switch 10
(SW5-012)'s touchpad not only does mouse emulation it also supports
HID-multitouch and all the keys including the "Wireless Radio Control"
bits have been moved to the first USB interface (the keyboard intf).

So we need hid-ite to handle the first (keyboard) USB interface and have
it NOT bind to the second (mouse) USB interface so that that can be
handled by hid-multitouch.c and we get proper multi-touch support.

This commit changes the hid_device_id for the SW5-012 keyboard dock to
only match on hid devices from the HID_GROUP_GENERIC group, this way
hid-ite will not bind the the mouse/multi-touch interface which has
HID_GROUP_MULTITOUCH_WIN_8 as group.
This fixes the regression to mouse-emulation mode introduced by adding
the keyboard dock USB id.

Cc: stable@vger.kernel.org
Fixes: 8f18eca9 ("HID: ite: Add USB id match for Acer SW5-012 keyboard dock")
Reported-by: NZdeněk Rampas <zdenda.rampas@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      beae5619
  39. 28 1月, 2020 1 次提交
    • F
      HID: logitech-hidpp: BatteryVoltage: only read chargeStatus if extPower is active · 4ab2bb3c
      由 Filipe Laíns 提交于 
      In the HID++ 2.0 function getBatteryInfo() from the BatteryVoltage
(0x1001) feature, chargeStatus is only valid if extPower is active.

Previously we were ignoring extPower, which resulted in wrong values.

Example:
    With an unplugged mouse

    $ cat /sys/class/power_supply/hidpp_battery_0/status
    Charging

This patch fixes that, it also renames charge_sts to flags as
charge_sts can be confused with chargeStatus from the spec.

Spec:
+--------+-------------------------------------------------------------------------+
|  byte  |                                    2                                    |
+--------+--------------+------------+------------+----------+----------+----------+
|   bit  |     0..2     |      3     |      4     |     5    |     6    |     7    |
+--------+--------------+------------+------------+----------+----------+----------+
| buffer | chargeStatus | fastCharge | slowCharge | critical | (unused) | extPower |
+--------+--------------+------------+------------+----------+----------+----------+
Table 1 - battery voltage (0x1001), getBatteryInfo() (ASE 0), 3rd byte

+-------+--------------------------------------+
| value |                meaning               |
+-------+--------------------------------------+
|   0   | Charging                             |
+-------+--------------------------------------+
|   1   | End of charge (100% charged)         |
+-------+--------------------------------------+
|   2   | Charge stopped (any "normal" reason) |
+-------+--------------------------------------+
|   7   | Hardware error                       |
+-------+--------------------------------------+
Table 2 - chargeStatus value
Signed-off-by: NFilipe Laíns <lains@archlinux.org>
Tested-by: NPedro Vanzella <pedro@pedrovanzella.com>
Reviewed-by: NPedro Vanzella <pedro@pedrovanzella.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      4ab2bb3c
  41. 13 1月, 2020 1 次提交
  43. 10 1月, 2020 1 次提交
  45. 09 1月, 2020 1 次提交