linux.git/drivers/hid, branch v5.16-rc4

HID: multitouch: Fix Iiyama ProLite T1931SAW (0eef:0001 again!)

2021-11-19T15:00:21+00:00

Iiyama ProLite T1931SAW does not work with Linux - input devices are
created but cursor does not move.

It has the infamous 0eef:0001 ID which has been reused for various
devices before.

It seems to require export_all_inputs = true.

Hopefully there are no HID devices using this ID that will break.
It should not break non-HID devices (handled by usbtouchscreen).

Signed-off-by: Ondrej Zary 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina

HID: nintendo: eliminate dead datastructures in !CONFIG_NINTENDO_FF case

2021-11-19T14:58:30+00:00

The rumbling-related identifiers are never used in !CONFIG_NINTENDO_FF
case, so let's hide them in order to avoid unused warnings.

Reported-by: kernel test robot 
Signed-off-by: Jiri Kosina

HID: magicmouse: prevent division by 0 on scroll

2021-11-19T14:54:31+00:00

In hid_magicmouse, if the user has set scroll_speed to a value between
55 and 63 and scrolls seven times in quick succession, the
step_hr variable in the magicmouse_emit_touch function becomes 0.

That causes a division by zero further down in the function when
it does `step_x_hr /= step_hr`.

To reproduce, create `/etc/modprobe.d/hid_magicmouse.conf` with the
following content:

```
options hid_magicmouse scroll_acceleration=1 scroll_speed=55
```

Then reboot, connect a Magic Mouse and scroll seven times quickly.
The system will freeze for a minute, and after that `dmesg` will
confirm that a division by zero occurred.

Enforce a minimum of 1 for the variable so the high resolution
step count can never reach 0 even at maximum scroll acceleration.

Fixes: d4b9f10a0eb6 ("HID: magicmouse: enable high-resolution scroll")

Signed-off-by: Claudia Pellegrino 
Tested-by: José Expósito 
Signed-off-by: Jiri Kosina

HID: thrustmaster: fix sparse warnings

2021-11-19T14:53:31+00:00

Changed 0 to NULL to fix following sparse warnings:

    drivers/hid/hid-thrustmaster.c:208:43: warning: Using plain integer as NULL pointer
    drivers/hid/hid-thrustmaster.c:241:17: warning: Using plain integer as NULL pointer
    drivers/hid/hid-thrustmaster.c:275:37: warning: Using plain integer as NULL pointer

Signed-off-by: Vihas Mak 
Signed-off-by: Jiri Kosina

HID: Ignore battery for Elan touchscreen on HP Envy X360 15-eu0xxx

2021-11-19T14:51:17+00:00

Battery status is reported for the HP Envy X360 Convertible 15-eu0xxx
even if it does not have a battery. Prevent it from always reporting the
battery as low.

Signed-off-by: Trevor Davenport 
Signed-off-by: Jiri Kosina

HID: input: set usage type to key on keycode remap

2021-11-19T14:48:22+00:00

When a scancode is manually remapped that previously was not handled as
key, then the old usage type was incorrectly reused.

This caused issues on a "04b3:301b IBM Corp. SK-8815 Keyboard" which has
marked some of its keys with an invalid HID usage.  These invalid usage
keys are being ignored since support for USB programmable buttons was
added.

The scancodes are however remapped explicitly by the systemd hwdb to the
keycodes that are printed on the physical buttons.  During this mapping
step the existing usage is retrieved which will be found with a default
type of 0 (EV_SYN) instead of EV_KEY.

The events with the correct code but EV_SYN type are not forwarded to
userspace.

This also leads to a kernel oops when trying to print the report descriptor
via debugfs.  hid_resolv_event() tries to resolve a EV_SYN event with an
EV_KEY code which leads to an out-of-bounds access in the EV_SYN names
array.

Fixes: bcfa8d1457 ("HID: input: Add support for Programmable Buttons")
Fixes: f5854fad39 ("Input: hid-input - allow mapping unknown usages")
Reported-by: Brent Roman 
Tested-by: Brent Roman 
Signed-off-by: Thomas Weißschuh 
Reviewed-by: Dmitry Torokhov 
Signed-off-by: Jiri Kosina

HID: input: Fix parsing of HID_CP_CONSUMER_CONTROL fields

2021-11-19T14:47:38+00:00

Fix parsing of HID_CP_CONSUMER_CONTROL fields which are not in
the HID_CP_PROGRAMMABLEBUTTONS collection.

Fixes: bcfa8d14570d ("HID: input: Add support for Programmable Buttons")
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=2018096
Cc: Thomas Weißschuh 
Suggested-by: Benjamin Tissoires 
Signed-off-by: Hans de Goede 
Reviewed-By: Thomas Weißschuh 
Signed-off-by: Jiri Kosina

HID: ft260: fix i2c probing for hwmon devices

2021-11-19T14:46:06+00:00

The below scenario causes the kernel NULL pointer dereference failure:
1. sudo insmod hid-ft260.ko
2. sudo modprobe lm75
3. unplug USB hid-ft260
4. plug USB hid-ft260

[  +0.000006] Call Trace:
[  +0.000004]  __i2c_smbus_xfer.part.0+0xd1/0x310
[  +0.000007]  ? ft260_smbus_write+0x140/0x140 [hid_ft260]
[  +0.000005]  __i2c_smbus_xfer+0x2b/0x80
[  +0.000004]  i2c_smbus_xfer+0x61/0xf0
[  +0.000005]  i2c_default_probe+0xf9/0x130
[  +0.000004]  i2c_detect_address+0x84/0x160
[  +0.000004]  ? kmem_cache_alloc_trace+0xf6/0x200
[  +0.000009]  ? i2c_detect.isra.0+0x69/0x130
[  +0.000005]  i2c_detect.isra.0+0xbf/0x130
[  +0.000004]  ? __process_new_driver+0x30/0x30
[  +0.000004]  __process_new_adapter+0x18/0x20
[  +0.000004]  bus_for_each_drv+0x84/0xd0
[  +0.000003]  i2c_register_adapter+0x1e4/0x400
[  +0.000005]  i2c_add_adapter+0x5c/0x80
[  +0.000004]  ft260_probe.cold+0x222/0x2e2 [hid_ft260]
[  +0.000006]  hid_device_probe+0x10e/0x170 [hid]
[  +0.000009]  really_probe+0xff/0x460
[  +0.000004]  driver_probe_device+0xe9/0x160
[  +0.000003]  __device_attach_driver+0x71/0xd0
[  +0.000004]  ? driver_allows_async_probing+0x50/0x50
[  +0.000004]  bus_for_each_drv+0x84/0xd0
[  +0.000002]  __device_attach+0xde/0x1e0
[  +0.000004]  device_initial_probe+0x13/0x20
[  +0.000004]  bus_probe_device+0x8f/0xa0
[  +0.000003]  device_add+0x333/0x5f0

It happened when i2c core probed for the devices associated with the lm75
driver by invoking 2c_detect()-->..-->ft260_smbus_write() from within the
ft260_probe before setting the adapter data with i2c_set_adapdata().

Moving the i2c_set_adapdata() before i2c_add_adapter() fixed the failure.

Signed-off-by: Michael Zaidman 
Signed-off-by: Germain Hebert 
Signed-off-by: Jiri Kosina

Revert "HID: hid-asus.c: Maps key 0x35 (display off) to KEY_SCREENLOCK"

2021-11-12T10:28:18+00:00

This reverts commit 2ea5999d07d2a0ab6ad92ccf65524707f2c5e456.

As Dmitry Torokhov pointed out, the previous code (KEY_DISPLAY_OFF) is
actually correct. The real issue is that current desktop environments
don't deal it properly. Mapping it to another event does not solve the
issue.

So I'm reverting that change, keeping key 0x35 mapped to KEY_DISPLAY_OFF

Signed-off-by: Vinícius Angiolucci Reis 
Signed-off-by: Jiri Kosina

HID: intel-ish-hid: fix module device-id handling

2021-11-11T21:45:40+00:00

A late addititon to the intel-ish-hid framework caused a build failure
with clang, and introduced an ABI to the module loader that stops working
if any driver ever needs to bind to more than one UUID:

drivers/hid/intel-ish-hid/ishtp-fw-loader.c:1067:4: error: initializer element is not a compile-time constant

Change the ishtp_device_id to have correct documentation and a driver_data
field like all the other ones, and change the drivers to use the ID table
as the primary identification in a way that works with all compilers
and avoids duplciating the identifiers.

Fixes: f155dfeaa4ee ("platform/x86: isthp_eclite: only load for matching devices")
Fixes: facfe0a4fdce ("platform/chrome: chros_ec_ishtp: only load for matching devices")
Fixes: 0d0cccc0fd83 ("HID: intel-ish-hid: hid-client: only load for matching devices")
Fixes: 44e2a58cb880 ("HID: intel-ish-hid: fw-loader: only load for matching devices")
Fixes: cb1a2c6847f7 ("HID: intel-ish-hid: use constants for modaliases")
Fixes: fa443bc3c1e4 ("HID: intel-ish-hid: add support for MODULE_DEVICE_TABLE()")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Hans de Goede 
[jkosina@suse.cz: fix ecl_ishtp_cl_driver.id initialization]
[jkosina@suse.cz: fix conflict with already fixed kerneldoc]
Signed-off-by: Jiri Kosina