aboutsummaryrefslogtreecommitdiff
path: root/drivers/hid
AgeCommit message (Collapse)AuthorFilesLines
2022-11-21HID: hid-elan: use default remove for hid deviceMarcus Folkesson1-6/+0
hid_device_remove() will call hid_hw_stop() as default .remove function if no function is specified. Signed-off-by: Marcus Folkesson <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-21HID: hid-alps: use default remove for hid deviceMarcus Folkesson1-6/+0
hid_device_remove() will call hid_hw_stop() as default .remove function if no function is specified. Signed-off-by: Marcus Folkesson <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-21HID: hid-sensor-custom: set fixed size for custom attributesMarcus Folkesson1-1/+1
This is no bugfix (so no Fixes: tag is necessary) as it is taken care of in hid_sensor_custom_add_attributes(). The motivation for this patch is that: hid_sensor_custom_field.attr_name and hid_sensor_custom_field.attrs has the size of HID_CUSTOM_TOTAL_ATTRS and used in same context. We compare against HID_CUSTOM_TOTAL_ATTRS when looping through hid_custom_attrs. We will silent the smatch error: hid_sensor_custom_add_attributes() error: buffer overflow 'hid_custom_attrs' 8 <= 10 Signed-off-by: Marcus Folkesson <[email protected]> Acked-by: Jonathan Cameron <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-21HID: core: fix shift-out-of-bounds in hid_report_raw_eventZhangPeng1-0/+3
Syzbot reported shift-out-of-bounds in hid_report_raw_event. microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) > 32! (swapper/0) ====================================================================== UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20 shift exponent 127 is too large for 32-bit type 'int' CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322 snto32 drivers/hid/hid-core.c:1323 [inline] hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline] hid_process_report drivers/hid/hid-core.c:1665 [inline] hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998 hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066 hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284 __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671 dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988 call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [inline] __run_timers+0x76a/0x980 kernel/time/timer.c:1790 run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803 __do_softirq+0x277/0x75b kernel/softirq.c:571 __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107 ====================================================================== If the size of the integer (unsigned n) is bigger than 32 in snto32(), shift exponent will be too large for 32-bit type 'int', resulting in a shift-out-of-bounds bug. Fix this by adding a check on the size of the integer (unsigned n) in snto32(). To add support for n greater than 32 bits, set n to 32, if n is greater than 32. Reported-by: [email protected] Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split") Signed-off-by: ZhangPeng <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-21HID: i2c: let RMI devices decide what constitutes wakeup eventDmitry Torokhov2-1/+4
HID-RMI is special in the sense that it does not carry HID events directly, but rather uses HID protocol as a wrapper/transport for RMI protocol. Therefore we should not assume that all data coming from the device via interrupt is associated with user activity and report wakeup event indiscriminately, but rather let HID-RMI do that when appropriate. HID-RMI devices tag responses to the commands issued by the host as RMI_READ_DATA_REPORT_ID whereas motion and other input events from the device are tagged as RMI_ATTN_REPORT_ID. Change hid-rmi to report wakeup events when receiving the latter packets. This allows ChromeOS to accurately identify wakeup source and make correct decision on the mode of the resume the system should take ("dark" where the display stays off vs normal one). Fixes: d951ae1ce803 ("HID: i2c-hid: Report wakeup events") Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-21HID: force HID depending on INPUTBenjamin Tissoires1-0/+1
In most configurations, INPUT is actually a boolean: either y or disabled, but when it's disabled, you can't do much on your average laptop. But it turns out that there is a possibility to have INPUT as a module: you have to disable VT and TTY (of course), but also enable EXPERT. I'll leave how to disable VT and TTY as an exercise for the bravest. Anyway, if INPUT is m, we can still configure HID as y, which is not correct because hid-input.c depends on the input API, meaning that vmlinuz can not link. So: add depends on INPUT too at the HID level, to ensure that if INPUT=m, HID can only be m or disabled. Fixes: 25621bcc8976 ("HID: Kconfig: split HID support and hid-core compilation") Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-21HID: uclogic: Add HID_QUIRK_HIDINPUT_FORCE quirkJosé Expósito1-0/+1
Commit f7d8e387d9ae ("HID: uclogic: Switch to Digitizer usage for styluses") changed the usage used in UCLogic from "Pen" to "Digitizer". However, the IS_INPUT_APPLICATION() macro evaluates to false for HID_DG_DIGITIZER causing issues with the XP-Pen Star G640 tablet. Add the HID_QUIRK_HIDINPUT_FORCE quirk to bypass the IS_INPUT_APPLICATION() check. Reported-by: Torge Matthies <[email protected]> Reported-by: Alexander Zhang <[email protected]> Tested-by: Alexander Zhang <[email protected]> Signed-off-by: José Expósito <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-21Merge 6.1-rc6 into driver-core-nextGreg Kroah-Hartman9-18/+91
We need the kernfs changes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2022-11-17HID: playstation: fix DualShock4 bluetooth CRC endian issue.Roderick Colenbrander1-1/+2
The driver was by accident reading the CRC directly from a hardware structure instead of using get_unaligned_le32. Fixes: 2d77474a2392 ("HID: playstation: add DualShock4 bluetooth support.") Reported-by: kernel test robot <[email protected]> Signed-off-by: Roderick Colenbrander <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-17HID: playstation: fix DualShock4 bluetooth memory corruption bug.Roderick Colenbrander1-1/+1
The size of the output buffer used for output reports was not updated to the larger size needed for Bluetooth. This ultimately resulted in memory corruption of surrounding structures e.g. due to memsets. Fixes: 2d77474a2392 ("HID: playstation: add DualShock4 bluetooth support.") Reported-by: Benjamin Tissoires <[email protected]> Signed-off-by: Roderick Colenbrander <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-15HID: bpf: allow to change the report descriptorBenjamin Tissoires4-2/+89
Add a new tracepoint hid_bpf_rdesc_fixup() so we can trigger a report descriptor fixup in the bpf world. Whenever the program gets attached/detached, the device is reconnected meaning that userspace will see it disappearing and reappearing with the new report descriptor. Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-15HID: bpf: introduce hid_hw_request()Benjamin Tissoires2-0/+136
This function can not be called under IRQ, thus it is only available while in SEC("syscall"). For consistency, this function requires a HID-BPF context to work with, and so we also provide a helper to create one based on the HID unique ID. Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Benjamin Tissoires <[email protected]> -- changes in v12: - variable dereferenced before check 'ctx' |Reported-by: kernel test robot <[email protected]> |Reported-by: Dan Carpenter <[email protected]> no changes in v11 no changes in v10 changes in v9: - fixed kfunc declaration aaccording to latest upstream changes no changes in v8 changes in v7: - hid_bpf_allocate_context: remove unused variable - ensures buf is not NULL changes in v6: - rename parameter size into buf__sz to teach the verifier about the actual buffer size used by the call - remove the allocated data in the user created context, it's not used new-ish in v5 Signed-off-by: Jiri Kosina <[email protected]>
2022-11-15HID: bpf: allocate data memory for device_event BPF programsBenjamin Tissoires3-13/+119
We need to also be able to change the size of the report. Reducing it is easy, because we already have the incoming buffer that is big enough, but extending it is harder. Pre-allocate a buffer that is big enough to handle all reports of the device, and use that as the primary buffer for BPF programs. To be able to change the size of the buffer, we change the device_event API and request it to return the size of the buffer. Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-15HID: bpf jmp table: simplify the logic of cleaning up programsBenjamin Tissoires5-573/+211
Kind of a hack, but works for now: Instead of listening for any close of eBPF program, we now decrement the refcount when we insert it in our internal map of fd progs. This is safe to do because: - we listen to any call of destructor of programs - when a program is being destroyed, we disable it by removing it from any RCU list used by any HID device (so it will never be called) - we then trigger a job to cleanup the prog fd map, but we overwrite the removal of the elements to not do anything on the programs, just remove the allocated space This is better than previously because we can remove the map of known programs and their usage count. We now rely on the refcount of bpf, which has greater chances of being accurate. Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-15HID: initial BPF implementationBenjamin Tissoires12-0/+1682
Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-15HID: Kconfig: split HID support and hid-core compilationBenjamin Tissoires2-6/+12
Currently, we step into drivers/hid/ based on the value of CONFIG_HID. However, that value is a tristate, meaning that it can be a module. As per the documentation, if we jump into the subdirectory by following an obj-m, we can not compile anything inside that subdirectory in vmlinux. It is considered as a bug. To make things more friendly to HID-BPF, split HID (the HID core parameter) from HID_SUPPORT (do we want any kind of HID support in the system?), and make this new config a boolean. Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-15HID: fix I2C_HID not selected when I2C_HID_OF_ELAN isBenjamin Tissoires1-2/+2
When I2C_HID_OF_ELAN is set, we need to turn on I2C_HID_CORE to ensure we get all the HID requirements. Fixes: bd3cba00dcc6 ("HID: i2c-hid: elan: Add support for Elan eKTH6915 i2c-hid touchscreens") Reported-by: kernel test robot <[email protected]> Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-14HID: hid-lg4ff: Add check for empty lbufAnastasia Belova1-0/+6
If an empty buf is received, lbuf is also empty. So lbuf is accessed by index -1. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: f31a2de3fe36 ("HID: hid-lg4ff: Allow switching of Logitech gaming wheels between compatibility modes") Signed-off-by: Anastasia Belova <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-14HID: ite: Enable QUIRK_TOUCHPAD_ON_OFF_REPORT on Acer Aspire Switch V 10Hans de Goede2-0/+6
The Acer Aspire Switch V 10 (SW5-017)'s keyboard-dock uses the same ITE controller setup as other Acer Switch 2-in-1's. This needs special handling for the wifi on/off toggle hotkey as well as to properly report touchpad on/off keypresses. Add the USB-ids for the SW5-017's keyboard-dock with a quirk setting of QUIRK_TOUCHPAD_ON_OFF_REPORT to fix both issues. Cc: Rudolf Polzer <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-14HID: apple: Swap Control and Command keys on Apple keyboardsAditya Garg1-1/+22
This patch allows users to swap the control and command keys. This can be useful for the Mac users who are used to using Command instead of Control in macOS for various commonly used shortcuts. Signed-off-by: Aditya Garg <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-14HID: intel-ish-hid: ishtp: remove variable rb_countColin Ian King1-3/+0
The variable rb_count is being incremented but it is never referenced, it is redundant and can be removed. Signed-off-by: Colin Ian King <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-14HID: uclogic: Standardize test name prefixJosé Expósito2-4/+4
Commit 961bcdf956a4 ("drm/tests: Change "igt_" prefix to "drm_test_"") introduced a new naming convention for the KUnit tests present in the DRM subsystem: "drm_test_<module>_<test name>". This naming convention is very convenient because it allows to easily run all subsystem tests or all driver tests using kunit.py's wildcards. Follow the naming conventions used in the DRM subsystem adapted to the HID subsystem: "hid_test_<module>_<test name>". Signed-off-by: José Expósito <[email protected]> Reviewed-by: Maíra Canal <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-14HID: uclogic: Fix frame templates for big endian architecturesJosé Expósito1-1/+1
When parsing a frame template with a placeholder indicating the number of buttons present on the frame its value was incorrectly set on big endian architectures due to double little endian conversion. In order to reproduce the issue and verify the fix, run the HID KUnit tests on the PowerPC architecture: $ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/hid \ --arch=powerpc --cross_compile=powerpc64-linux-gnu- Fixes: 867c89254425 ("HID: uclogic: Allow to generate frame templates") Signed-off-by: José Expósito <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-14HID: hid-sensor-custom: Allow more than one hinge angle sensorYauhen Kharuzhy1-1/+1
Some devices has two sets of accelerometers and the sensor hub exports two hinge angle 'sensors' based on accelerometer values. To allow more than one sensor of the same type, use PLATFORM_DEVID_AUTO instead of PLATFORM_DEVID_NONE when registering platform device for it. Checked on the Lenovo Yoga Book YB1-X91L tablet. Signed-off-by: Yauhen Kharuzhy <[email protected]> Reviewed-by: Jonathan Cameron <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11Merge tag 'for-linus-2022111101' of ↵Linus Torvalds3-9/+8
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fixes from Jiri Kosina: - fix for memory leak (on error path) in Hyper-V driver (Yang Yingliang) - regression fix for handling 3rd barrel switch emulation in Wacom driver (Jason Gerecke) * tag 'for-linus-2022111101' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: wacom: Fix logic used for 3rd barrel switch emulation HID: hyperv: fix possible memory leak in mousevsc_probe() HID: asus: Remove unused variable in asus_report_tool_width()
2022-11-11HID: ft260: fix 'cast to restricted' kernel CI bot warningsMichael Zaidman1-7/+7
Fix 'cast to restricted' sparse warnings reported by kernel test robot in https://lore.kernel.org/all/[email protected]/ Reported-by: kernel test robot <[email protected]> Signed-off-by: Michael Zaidman <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: ft260: missed NACK from busy deviceMichael Zaidman1-5/+22
When writing into a slow device like an EEPROM chip, the controller may exit the busy state before the device releases the bus. In this case, the ft260_xfer_status returns success before the data transfer completion. The patch fixes it by returning from the ft260_xfer_status() with the "-EAGAIN" on both controller and bus busy status when appropriate. It does not apply to the i2c combined transactions when after the write IO, the controller keeps the bus busy until the read IO and then between reading IOs to ensure an atomic operation. Co-developed-by: Germain Hebert <[email protected]> Signed-off-by: Germain Hebert <[email protected]> Signed-off-by: Michael Zaidman <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: ft260: fix a NULL pointer dereference in ft260_i2c_writeMichael Zaidman1-0/+3
The zero-length passed into the ft260_i2c_write() triggered the NULL pointer dereference in the debug message on data[0] access. Since the controller does not support a write of zero length, let's not allow it. Before: $ sudo i2ctransfer -y 13 w0@0x51 Killed After: $ sudo i2ctransfer -y 13 w0@0x51 Error: Sending messages failed: Invalid argument Reported-by: Enrik Berkhan <[email protected]> Signed-off-by: Michael Zaidman <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: ft260: wake up device from power saving modeMichael Zaidman1-0/+17
The FT260 can enter a power saving mode after being idle for longer than 5 seconds. When being woken up from power saving mode by an I2C write request, a possible NACK is not correctly reported by the controller. As a workaround, the driver will issue an I2C status report two times in ft260_xfer_status() after the chip has been idle for more than 5s. Co-developed-by: Enrik Berkhan <[email protected]> Signed-off-by: Enrik Berkhan <[email protected]> Signed-off-by: Michael Zaidman <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: ft260: missed NACK from big i2c readMichael Zaidman1-2/+4
The FT260 controller does not return NACK when performing a big read (of multiple hid reports size) from a non-existing device or from the device responding with NACK when it is not ready to serve the request. However, it responds correctly with NACK to a read of up to a single hid report size. To overcome this issue, we split the muli-report read request into a read of a single HID report of 60 bytes size and a multi-report read. Big read of 256 bytes with first read of 60 bytes: $ sudo ./i2cperf -d 2 -o 2 -s 256 -r 0-0xff 1 0x50 -S [ +5.633280] ft260_i2c_write_read: off 0x0 rlen 255 wlen 2 [ +0.000006] ft260_i2c_write: rep 0xd0 addr 0x50 off 0 len 2 wlen 2 flag 0x2 d[0] 0x0 [ +0.013205] ft260_xfer_status: bus_status 0x20, clock 100 [ +0.000007] ft260_i2c_read: rep 0xc2 addr 0x50 len 255 rlen 60 flag 0x3 [ +0.010932] ft260_raw_event: i2c resp: rep 0xde len 60 [ +0.004733] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.000006] ft260_i2c_read: rep 0xc2 addr 0x50 len 195 rlen 128 flag 0x0 [ +0.012572] ft260_raw_event: i2c resp: rep 0xde len 60 [ +0.005789] ft260_raw_event: i2c resp: rep 0xde len 60 [ +0.003189] ft260_raw_event: i2c resp: rep 0xd1 len 8 [ +0.004092] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.000010] ft260_i2c_read: rep 0xc2 addr 0x50 len 67 rlen 67 flag 0x4 [ +0.011688] ft260_raw_event: i2c resp: rep 0xde len 60 [ +0.004700] ft260_raw_event: i2c resp: rep 0xd1 len 7 [ +0.004858] ft260_xfer_status: bus_status 0x20, clock 100 Read from non-existing device at address 8. The first 60 read responded with NACK. $ sudo ./i2cperf -d 2 -o 2 -s 256 -r 0-0xff 1 0x8 -S [Oct19 15:37] ft260_i2c_write_read: off 0x0 rlen 255 wlen 2 [ +0.000007] ft260_i2c_write: rep 0xd0 addr 0x8 off 0 len 2 wlen 2 flag 0x2 d[0] 0x0 [ +0.022820] ft260_xfer_status: bus_status 0x20, clock 100 [ +0.000007] ft260_i2c_read: rep 0xc2 addr 0x8 len 255 rlen 60 flag 0x3 [ +0.010658] ft260_raw_event: i2c resp: rep 0xde len 60 [ +0.005965] ft260_xfer_status: bus_status 0x46, clock 100 <-- NACK [ +0.000009] ft260 0003:0403:6030.0004: i2c bus error: 0x46 [ +0.007784] ft260_i2c_reset: done Co-developed-by: Enrik Berkhan <[email protected]> Signed-off-by: Enrik Berkhan <[email protected]> Signed-off-by: Michael Zaidman <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: ft260: remove SMBus Quick command supportMichael Zaidman1-9/+1
The i2cdetect uses the SMBus Quick command by default to scan devices on the I2C bus. The FT260 implements an I2C bus controller. The SMBus is derived from I2C, but there are several differences between the specifications of the two buses in the areas of timing, protocols, operation modes, and electrical characteristics. One of the differences is that the I2C devices allow the slave not to ACK its slave address, but SMBus requires it to always ACK it as a mechanism to detect a detachable device’s presence on the bus. Since FT260 is the I2C bus controller, it does not acknowledge the SMBus Quick write command, which sends a single bit to the device at the place of the RD/WR bit. The ft260 driver attempted to mimic the SMBus Quick Write functionality by writing a single byte as the SMBus Byte Write command does. Usually, one byte in the SMBus Quick Write will be fine. However, it may cause problems with devices with a control register at offset 0, like i2c muxes, for example, when scanned with the i2cdetect utility. The i2cdetect with the "-r" option uses the SMBus Read Byte command, which is a reasonable workaround. To prevent the I2C bus from locking at write-only devices (most notably clock chips at address 0x69), use the "-r" option in conjunction with scanning range parameters. This patch removes the SMBus Quick command support. $ sudo i2cdetect -y 13 Warning: Can't use SMBus Quick Write command, will skip some addresses 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: 10: 20: 30: -- -- -- -- -- -- -- -- 40: 50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: 70: $ sudo i2cdetect -y -r 13 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Reported-by: Vince Asbridge <[email protected]> Reported-by: Stephen Shirron <[email protected]> Reported-by: Enrik Berkhan <[email protected]> Signed-off-by: Michael Zaidman <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: ft260: skip unexpected HID input reportsMichael Zaidman1-12/+24
The FT260 is not supposed to generate unexpected HID reports. However, in theory, the unsolicited HID Input reports can be issued by a specially crafted malicious USB device masquerading as FT260 when the attacker has physical access to the USB port. In this case, the read_buf pointer points to the final data portion of the previous I2C Read transfer, and the memcpy invoked in the ft260_raw_event() will try copying the content of the unexpected report into the wrong location. This commit sets the Read buffer pointer to NULL on the I2C Read transaction completion and checks it in the ft260_raw_event() to detect and skip the unsolicited Input report. Reported-by: Enrik Berkhan <[email protected]> Signed-off-by: Michael Zaidman <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: ft260: do not populate /dev/hidraw deviceMichael Zaidman1-3/+6
Do not populate the /dev/hidraw on ft260 interfaces when the hid-ft260 driver is loaded. $ sudo insmod hid-ft260.ko $ ls /dev/hidraw* /dev/hidraw0 $ sudo rmmod hid-ft260.ko $ ls /dev/hidraw* /dev/hidraw0 /dev/hidraw1 /dev/hidraw2 Reported-by: Enrik Berkhan <[email protected]> Signed-off-by: Michael Zaidman <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: ft260: improve i2c large reads performanceMichael Zaidman1-5/+12
The patch increases the read buffer size to 180 bytes. It reduces the number of ft260_i2c_read() calls by three, improving the big reads performance. $ sudo i2ctransfer -y -f 13 w2@0x51 0x0 0x0 r180 Before: [ +4.071878] ft260_i2c_write_read: off 0x0 rlen 180 wlen 2 [ +0.000005] ft260_i2c_write: rep 0xd0 addr 0x51 off 0 len 2 wlen 2 flag 0x2 d[0] 0x0 [ +0.001097] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000175] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.000004] ft260_i2c_read: rep 0xc2 addr 0x51 len 180 rlen 60 flag 0x3 [ +0.008579] ft260_raw_event: i2c resp: rep 0xde len 60 [ +0.000208] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.000001] ft260_i2c_read: rep 0xc2 addr 0x51 len 120 rlen 60 flag 0x0 [ +0.008794] ft260_raw_event: i2c resp: rep 0xde len 60 [ +0.000181] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.000002] ft260_i2c_read: rep 0xc2 addr 0x51 len 60 rlen 60 flag 0x4 [ +0.008817] ft260_raw_event: i2c resp: rep 0xde len 60 [ +0.000223] ft260_xfer_status: bus_status 0x20, clock 100 After: [ +11.611642] ft260_i2c_write_read: off 0x0 rlen 180 wlen 2 [ +0.000005] ft260_i2c_write: rep 0xd0 addr 0x51 off 0 len 2 wlen 2 flag 0x2 d[0] 0x0 [ +0.008001] ft260_xfer_status: bus_status 0x20, clock 100 [ +0.000001] ft260_i2c_read: rep 0xc2 addr 0x51 len 180 rlen 180 flag 0x7 [ +0.008994] ft260_raw_event: i2c resp: rep 0xde len 60 [ +0.007987] ft260_raw_event: i2c resp: rep 0xde len 60 [ +0.007992] ft260_raw_event: i2c resp: rep 0xde len 60 [ +0.000206] ft260_xfer_status: bus_status 0x20, clock 100 Suggested-by: Enrik Berkhan <[email protected]> Signed-off-by: Michael Zaidman <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: ft260: support i2c reads greater than HID report sizeMichael Zaidman1-61/+66
A random i2c read operation in EEPROM devices is implemented as a dummy write operation, followed by a current address read operation. The dummy write operation is used to load the target byte or word address (a.k.a offset) into the offset counter, from which the subsequent read operation then reads. To support longer than one HID report size random read, the ft260 driver issues multiple pairs of i2c write offset + read data transactions of HID report size so that the EEPROM device sees many i2c random read requests from different offsets. Two issues with the current implementation: - This approach suffers from extra overhead caused by writing offset requests. - Necessity to handle offset per HID report in big-endian representation as EEPROM devices expect. The current implementation does not do it and correctly handles the reads up to 60 bytes only. This patch addresses both issues by implementing more efficient approach. It issues a single i2c read request of up to the EEPROM page size and then waits for the data to arrive in multiple HID reports. For example, to read the 256 bytes from a 24LC512 chip, which has 128 bytes page size, the old method performs six ft260_i2c_write_read transactions while the new - two only. Before: $ sudo ./i2cperf -d 2 -o 2 -s 128 -r 0-0xff 13 0x51 -S Read block via i2ctransfer by chunks ------------------------------------------------------------------- data rate(bps) efficiency(%) data size(B) total IOs IO size(B) ------------------------------------------------------------------- 40803 85 256 2 128 Kernel log of a single 128 bytes read request: [ +2.376308] ft260_i2c_write_read: read_off 0x0 left_len 128 len 60 [ +0.000002] ft260_i2c_write: rep 0xd0 addr 0x51 off 0 len 2 wlen 2 flag 0x2 d[0] 0x0 [ +0.000707] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000173] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.000001] ft260_i2c_read: rep 0xc2 addr 0x51 len 60 [ +0.008660] ft260_raw_event: i2c resp: rep 0xde len 60 [ +0.000156] ft260_xfer_status: bus_status 0x20, clock 100 [ +0.000001] ft260_i2c_write_read: read_off 0x3c left_len 68 len 60 [ +0.000001] ft260_i2c_write: rep 0xd0 addr 0x51 off 0 len 2 wlen 2 flag 0x2 d[0] 0x3c [ +0.001034] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000191] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.000001] ft260_i2c_read: rep 0xc2 addr 0x51 len 60 [ +0.008614] ft260_raw_event: i2c resp: rep 0xde len 60 [ +0.000203] ft260_xfer_status: bus_status 0x20, clock 100 [ +0.000001] ft260_i2c_write_read: read_off 0x78 left_len 8 len 8 [ +0.000001] ft260_i2c_write: rep 0xd0 addr 0x51 off 0 len 2 wlen 2 flag 0x2 d[0] 0x78 [ +0.000987] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000192] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.000001] ft260_i2c_read: rep 0xc2 addr 0x51 len 8 [ +0.002614] ft260_raw_event: i2c resp: rep 0xd1 len 8 [ +0.000200] ft260_xfer_status: bus_status 0x20, clock 100 After: $ sudo ./i2cperf -d 2 -o 2 -s 128 -r 0-0xff 13 0x51 -S Read block via i2ctransfer by chunks ------------------------------------------------------------------- data rate(bps) efficiency(%) data size(B) total IOs IO size(B) ------------------------------------------------------------------- 43990 85 256 2 128 Kernel log of a single 128 bytes read request: [ +1.464346] ft260_i2c_write_read: off 0x0 rlen 128 wlen 2 [ +0.000002] ft260_i2c_write: rep 0xd0 addr 0x51 off 0 len 2 wlen 2 flag 0x2 d[0] 0x0 [ +0.001653] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000188] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.000002] ft260_i2c_read: rep 0xc2 addr 0x51 len 128 rlen 60 flag 0x3 [ +0.008609] ft260_raw_event: i2c resp: rep 0xde len 60 [ +0.000157] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.000002] ft260_i2c_read: rep 0xc2 addr 0x51 len 68 rlen 60 flag 0x0 [ +0.008840] ft260_raw_event: i2c resp: rep 0xde len 60 [ +0.000203] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.000002] ft260_i2c_read: rep 0xc2 addr 0x51 len 8 rlen 8 flag 0x4 [ +0.002794] ft260_raw_event: i2c resp: rep 0xd1 len 8 [ +0.000201] ft260_xfer_status: bus_status 0x20, clock 100 Signed-off-by: Michael Zaidman <[email protected]> Tested-by: Guillaume Champagne <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: ft260: support i2c writes larger than HID report sizeMichael Zaidman1-18/+23
To support longer than one HID report size write, the driver splits a single i2c message data payload into multiple i2c messages of HID report size. However, it does not replicate the offset bytes within the EEPROM chip in every consequent HID report because it is not and should not be aware of the EEPROM type. It breaks the i2c write message integrity and causes the EEPROM device not to acknowledge the second HID report keeping the i2c bus busy until the ft260 controller reports failure. This patch preserves the i2c write message integrity by manipulating the i2c flag bits across multiple HID reports to be seen by the EEPROM device as a single i2c write transfer. Before: $ sudo ./i2cperf -f 2 -o 2 -s 64 -r 0-0xff 13 0x51 -S Error: Sending messages failed: Input/output error [ +3.667741] ft260_i2c_write: rep 0xde addr 0x51 off 0 len 60 d[0] 0x0 [ +0.007330] ft260_hid_output_report_check_status: wait 6400 usec, len 64 [ +0.000203] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.000001] ft260_i2c_write: rep 0xd1 addr 0x51 off 60 len 6 d[0] 0x0 [ +0.002337] ft260_hid_output_report_check_status: wait 1000 usec, len 10 [ +0.000157] ft260_xfer_status: bus_status 0x2e, clock 100 [ +0.000241] ft260_i2c_reset: done [ +0.000003] ft260_i2c_write: failed to start transfer, ret -5 After: $ sudo ./i2cperf -f 2 -o 2 -s 128 -r 0-0xff 13 0x51 -S Fill block with increment via i2ctransfer by chunks ------------------------------------------------------------------- data rate(bps) efficiency(%) data size(B) total IOs IO size(B) ------------------------------------------------------------------- 71260 86 256 2 128 Signed-off-by: Michael Zaidman <[email protected]> Tested-by: Guillaume Champagne <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: ft260: improve i2c write performanceMichael Zaidman1-5/+9
The patch improves the I2C write performance by 20 - 30 percent by revising the sleep time in the ft260_hid_output_report_check_status() in the following ways: 1. Reduce the wait time and start to poll earlier. Sending a large amount of data at a low I2C clock rate saturates the internal FT260 buffer and causes hiccups in status readiness, as shown below in the log fragment. Aligning the status check wait time to the worst case significantly reduces the write performance. [Oct22 10:28] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0 [ +0.005296] ft260_xfer_status: bus_status 0x20, clock 100 [ +0.013460] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0 [ +0.003244] ft260_hid_output_report_check_status: wait 1920 usec, len 38 [ +0.000190] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.015324] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0 [ +0.003491] ft260_hid_output_report_check_status: wait 1920 usec, len 38 [ +0.000202] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.016047] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0 [ +0.002768] ft260_hid_output_report_check_status: wait 1920 usec, len 38 [ +0.000150] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.011389] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0 [ +0.003467] ft260_hid_output_report_check_status: wait 1920 usec, len 38 [ +0.000191] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000172] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000131] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000241] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000233] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000190] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000196] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.011314] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0 [ +0.003334] ft260_hid_output_report_check_status: wait 1920 usec, len 38 [ +0.000227] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000204] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000198] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000147] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.011060] ft260_i2c_write: rep 0xd8 addr 0x51 off 0 len 34 d[0] 0x0 Before: $ sudo ./i2cperf -f 2 -o 2 -s 32 -r 0-0xff 13 0x51 -S Fill block with increment via i2ctransfer by chunks ------------------------------------------------------------------- data rate(bps) efficiency(%) data size(B) total IOs IO size(B) ------------------------------------------------------------------- 40510 80 256 8 32 After: $ sudo ./i2cperf -f 2 -o 2 -s 32 -r 0-0xff 13 0x51 -S Fill block with increment via i2ctransfer by chunks ------------------------------------------------------------------- data rate(bps) efficiency(%) data size(B) total IOs IO size(B) ------------------------------------------------------------------- 52584 80 256 8 32 2. Do not sleep if the estimated I2C transfer time is below 2 ms since the first xfer status query frequently takes around 1.5 ms, and the following status queries take about 200us on average. So we usually return from the routine after the first 1 - 3 status checks. [Oct22 11:14] ft260_i2c_write: rep 0xd4 addr 0x51 off 0 len 18 d[0] 0x0 [ +0.004270] ft260_xfer_status: bus_status 0x20, clock 100 [ +0.013889] ft260_i2c_write: rep 0xd4 addr 0x51 off 0 len 18 d[0] 0x0 [ +0.000856] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000138] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.013352] ft260_i2c_write: rep 0xd4 addr 0x51 off 0 len 18 d[0] 0x0 [ +0.001501] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000177] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.014477] ft260_i2c_write: rep 0xd4 addr 0x51 off 0 len 18 d[0] 0x0 [ +0.001377] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000233] ft260_xfer_status: bus_status 0x41, clock 100 [ +0.000191] ft260_xfer_status: bus_status 0x40, clock 100 [ +0.013197] ft260_i2c_write: rep 0xd4 addr 0x51 off 0 len 18 d[0] 0x0 Before: $ sudo ./i2cperf -f 2 -o 2 -s 16 -r 0-0xff 13 0x51 -S Fill block with increment via i2ctransfer by chunks ------------------------------------------------------------------- data rate(bps) efficiency(%) data size(B) total IOs IO size(B) ------------------------------------------------------------------- 28826 73 256 16 16 After: $ sudo ./i2cperf -f 2 -o 2 -s 16 -r 0-0xff 13 0x51 -S Fill block with increment via i2ctransfer by chunks ------------------------------------------------------------------- data rate(bps) efficiency(%) data size(B) total IOs IO size(B) ------------------------------------------------------------------- 45138 73 256 16 16 Signed-off-by: Michael Zaidman <[email protected]> Tested-by: Guillaume Champagne <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: ft260: ft260_xfer_status routine cleanupMichael Zaidman1-20/+10
After clarifying with FTDI's support, it turned out that the error condition (bit 1) in byte 1 of the i2c status HID report is a status bit reflecting all error conditions. When bits 2, 3, or 4 are raised to 1, bit 1 is set to 1 also. Since the ft260_xfer_status routine tests the error condition bit and exits in the case of an error, the program flow never reaches the conditional expressions for 2, 3, and 4 bits when any of them indicates an error state. Though these expressions are never evaluated to true, they are checked several times per IO, increasing the ft260_xfer_status polling cycle duration. The patch removes the conditional expressions for 2, 3, and 4 bits in byte 1 of the i2c status HID report. Signed-off-by: Michael Zaidman <[email protected]> Tested-by: Guillaume Champagne <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: playstation: add DualShock4 dongle support.Roderick Colenbrander1-6/+140
This patch adds support for the DualShock4 dongle in a very similar way we contributed to hid-sony before. The dongle is a USB to Bluetooth bridge and uses the same HID reports as a USB device. It reports data through the DS4's main USB input report independent on whether a Bluetooth controller is connected. For this reason there is custom dongle report parsing code to detect controller hotplug and kick of calibration work until we are ready to process actual input reports. The logic also incorporates a workaround needed for Steam in which hid-playstation and Steam using hidraw can fight. Signed-off-by: Roderick Colenbrander <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: playstation: set default DualShock4 BT poll interval to 4ms.Roderick Colenbrander1-0/+29
The poll interval for DualShock4 in Bluetooth mode is adjustable through the main output report. Configure it to 4ms, which is similar to USB. Signed-off-by: Roderick Colenbrander <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: playstation: add DualShock4 bluetooth support.Roderick Colenbrander1-26/+144
Add support for DualShock4 in Bluetooth mode. In Bluetooth, the device is a bit strange in that after 'calibration' it switches sending all its input data from a basic report (only containing buttons/sticks) to an extended report, which also contains touchpad, motion sensors and other data. The overall design of this code is similar to the DualSense code. Signed-off-by: Roderick Colenbrander <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: playstation: add option to ignore CRC in ps_get_report.Roderick Colenbrander1-8/+9
This patch adds a parameter to ps_get_report to ignore CRC checks. This prepares for DualShock4, which has some HID reports, which lack CRC. Signed-off-by: Roderick Colenbrander <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: playstation: support DualShock4 lightbar blink.Roderick Colenbrander1-1/+46
Support lightbar blink through LEDs framework. Signed-off-by: Roderick Colenbrander <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: playstation: support DualShock4 lightbar.Roderick Colenbrander1-3/+138
Expose the lightbar LEDs in the same manner as hid-sony through individual LEDs for backwards compatibility reasons. There is a slight change in LED naming to use the input device name as opposed to the MAC address like hid-sony did. This is expected to not cause any issues and should make the naming more compliant. In addition set a default lightbar color based on player ID. Signed-off-by: Roderick Colenbrander <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: playstation: make LED brightness adjustable in ps_led_register.Roderick Colenbrander1-6/+7
Make the max_brightness adjustable through ps_led_info struct. This paves the way for a next DualShock4 patch to allow larger brightness values. Signed-off-by: Roderick Colenbrander <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: playstation: Add DualShock4 rumble support.Roderick Colenbrander1-1/+147
This patch implements DualShock4 rumble support in a similar manner as the DualSense implementation. It adds an output worker with granular control of different features of the main DualShock4 output report. Signed-off-by: Roderick Colenbrander <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: playstation: add DualShock4 accelerometer and gyroscope support.Roderick Colenbrander1-2/+168
Support accelerometer and gyroscope as separate input devices similar how DualSense and hid-sony do it. Signed-off-by: Roderick Colenbrander <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: playstation: add DualShock4 touchpad support.Roderick Colenbrander1-3/+63
Support the DualShock4 touchpad as a separate input device. The code describes the touchpad input reports through structures similar a bit to the DualSense code. Signed-off-by: Roderick Colenbrander <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: playstation: add DualShock4 battery support.Roderick Colenbrander1-4/+66
Provide DualShock4 battery support through powersupply framework. Signed-off-by: Roderick Colenbrander <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2022-11-11HID: playstation: report DualShock4 hardware and firmware version.Roderick Colenbrander1-0/+38
Report DualShock4 hardware and firmware version info through sysfs. It uses the same sysfs nodes as the DualSense did (and hid-sony). Signed-off-by: Roderick Colenbrander <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.