This reverts commit 532223c8ac.
As reported in [0], hid-logitech-hidpp now binds on all bluetooth mice,
but there are corner cases where hid-logitech-hidpp just gives up on
the mouse. This leads the end user with a dead mouse.
Given that we are at -rc8, we are definitively too late to find a proper
fix. We already identified 2 issues less than 24 hours after the bug
report. One in that ->match() was never designed to be used anywhere else
than in hid-generic, and the other that hid-logitech-hidpp has corner
cases where it gives up on devices it is not supposed to.
So we have no choice but postpone this patch to the next kernel release.
[0] https://lore.kernel.org/linux-input/CAJZ5v0g-_o4AqMgNwihCb0jrwrcJZfRrX=jv8aH54WNKO7QB8A@mail.gmail.com/
Reported-by: Rafael J . Wysocki <rjw@rjwysocki.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This reverts commit 8544c812e4.
We need to revert commit 532223c8ac ("HID: logitech-hidpp: Enable HID++
for all the Logitech Bluetooth devices") because that commit might make
hid-logitech-hidpp bind on mice that are not well enough supported by
hid-logitech-hidpp, and the end result is that the probe of those mice
is now returning -ENODEV, leaving the end user with a dead mouse.
Given that commit 8544c812e4 ("HID: logitech-hidpp: Remove special-casing
of Bluetooth devices") is a direct dependency of 532223c8ac, revert it
too.
Note that this also adapt according to commit 908d325e16 ("HID:
logitech-hidpp: Detect hi-res scrolling support") to re-add support of
the devices that were removed from that commit too.
I have locally an MX Master and I tested this device with that revert,
ensuring we still have high-res scrolling.
Reported-by: Rafael J . Wysocki <rjw@rjwysocki.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some additional USB mouse devices are needing ALWAYS_POLL quirk without
which they disconnect and reconnect every 60s.
Add below devices to the known quirk list.
CHERRY VID 0x046a, PID 0x000c
MICROSOFT VID 0x045e, PID 0x0783
PRIMAX VID 0x0461, PID 0x4e2a
Signed-off-by: Ankit Patel <anpatel@nvidia.com>
Signed-off-by: Haotien Hsu <haotienh@nvidia.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
According to docs a SwID should be sent for GetProtocolVersion.
> 0x10.DeviceIndex.0x00.0x1n
where n is SwID.
Signed-off-by: Andreas Bergmeier <abergmeier@gmx.net>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
hid_device_remove() will call hid_hw_stop() as default .remove function
if no function is specified.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
hid_device_remove() will call hid_hw_stop() as default .remove function
if no function is specified.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <marcus.folkesson@gmail.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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: syzbot+8b1641d2f14732407e23@syzkaller.appspotmail.com
Fixes: dde5845a52 ("[PATCH] Generic HID layer - code split")
Signed-off-by: ZhangPeng <zhangpeng362@huawei.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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: d951ae1ce8 ("HID: i2c-hid: Report wakeup events")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit f7d8e387d9 ("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 <openglfreak@googlemail.com>
Reported-by: Alexander Zhang <alex@alexyzhang.dev>
Tested-by: Alexander Zhang <alex@alexyzhang.dev>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The driver was by accident reading the CRC directly from a hardware
structure instead of using get_unaligned_le32.
Fixes: 2d77474a23 ("HID: playstation: add DualShock4 bluetooth support.")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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: 2d77474a23 ("HID: playstation: add DualShock4 bluetooth support.")
Reported-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When I2C_HID_OF_ELAN is set, we need to turn on I2C_HID_CORE to
ensure we get all the HID requirements.
Fixes: bd3cba00dc ("HID: i2c-hid: elan: Add support for Elan eKTH6915 i2c-hid touchscreens")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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: f31a2de3fe ("HID: hid-lg4ff: Allow switching of Logitech gaming wheels between compatibility modes")
Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <rpolzer@google.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <gargaditya08@live.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <colin.i.king@gmail.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit 961bcdf956 ("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 <jose.exposito89@gmail.com>
Reviewed-by: Maíra Canal <mairacanal@riseup.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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: 867c892544 ("HID: uclogic: Allow to generate frame templates")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <jekhor@gmail.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Things look calming down, as this contains only a few small fixes.
- Fix for a corner-case bug with SG-buffer page allocation helper
- A regression fix for Roland USB-audio device probe
- A potential memory leak fix at the error path
- Handful quirks and device-specific fixes for HD- and USB-audio
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmNt/G8OHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE+t/Q//bmvq2YLb1RL0T0wIJQGGi3vuigxzx9J+r4ny
5fNel816R9JVHnimA7J1GbFIj8l63qiUu/dHMOmNDjqdSZ1KLbu8DpAZu4tL+KKo
XpmiXuFZlepgPGYY10kQG85EiuHriF7z1yKJ8QoP3ELIqBi/m77+qJ4JUk2XlPoT
4o4FCit9UQwd4xJ4EmUw3N6bPUumb6Uw0as8Qdfrw5P14VB5ev882eW7iQaeMxhd
S35IdXdqLGHVdPJXq38Wx8cvEyCFhS2SsG0QT5kul1Zg0ld5HSaN3V7rg0uKYcLQ
+2JfW5wcZwmcYTLpvfdMF/HNWN8RbEoexCUIlWsd7xzlFpB8Z6/EOPGxy2tXIwVb
rsElYlb9yeKTnyvTe2hRfHIWZH6s6eYqncv+/gpzxIwVBJ9Is8sMm7upxxki5bky
QPwnjWU3iiyJ7sjA+kU25aTdjdHQawz2ds0GILkoi5EnfcAj1fz4FJ+3l4C+Epsf
SL+OhcWxDeTggpK3p4lbJIIRY4k38VYXRXjE4gaYn7wdLlXS3SMQgFa6lU6uU286
m4OU/6clOctbBtkX41bicZcG7RzLyb/ns8W0hIhxaJA/QQP/7Jg03PebYe0fyQhu
wfMoeqnTHJaRfAOo8K7sEdmffHEJMifUzwNn7NoSxVsvPLWx/HvivdMx0hzGUgai
eTqQcEg=
=vmwO
-----END PGP SIGNATURE-----
Merge tag 'sound-6.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Things look calming down, as this contains only a few small fixes:
- Fix for a corner-case bug with SG-buffer page allocation helper
- A regression fix for Roland USB-audio device probe
- A potential memory leak fix at the error path
- Handful quirks and device-specific fixes for HD- and USB-audio"
* tag 'sound-6.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda: fix potential memleak in 'add_widget_node'
ALSA: memalloc: Don't fall back for SG-buffer with IOMMU
ALSA: usb-audio: add quirk to fix Hamedal C20 disconnect issue
ALSA: hda/realtek: Add Positivo C6300 model quirk
ALSA: usb-audio: Add DSD support for Accuphase DAC-60
ALSA: usb-audio: Add quirk entry for M-Audio Micro
ALSA: hda/hdmi - enable runtime pm for more AMD display audio
ALSA: usb-audio: Remove redundant workaround for Roland quirk
ALSA: usb-audio: Yet more regression for for the delayed card registration
ALSA: hda/ca0132: add quirk for EVGA Z390 DARK
ALSA: hda: clarify comments on SCF changes
ALSA: arm: pxa: pxa2xx-ac97-lib: fix return value check of platform_get_irq()
ALSA: hda/realtek: Add quirk for ASUS Zenbook using CS35L41
amdgpu:
- Fix s/r in amdgpu_vram_mgr_new
- SMU 13.0.4 update
- GPUVM TLB race fix
- DCN 3.1.4 fixes
- DCN 3.2.x fixes
- Vega10 fan fix
- BACO fix for Beige Goby board
- PSR fix
- GPU VM PT locking fixes
amdkfd:
- CRIU fixes
vc4:
- HDMI fixes to vc4.
panfrost:
- Make panfrost's uapi header compile with C++.
- Handle 1 gb boundary correctly in panfrost mmu code.
panel:
- Add rotation quirks for 2 panels.
rcar-du:
- DSI Kconfig fix
i915:
- Fix sg_table handling in map_dma_buf
- Send PSR update also on invalidate
- Do not set cache_dirty for DGFX
- Restore userptr probe_range behaviour
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmNtrMsACgkQDHTzWXnE
hr5EaRAApbJSzuhittt3I3WJ/w92+oyAmFo+gDuZ+IhXPNJm3QJ9pI92lWjKCi95
15Y+h6ao+it/6o6f3MbuKlgb+STTNztMDDutLl1W4K0vLCO7HBH/8YEt8JZFjHz0
l9TWmE/6fnHhLqBqdEtIn14kRaCrn9ALVsyKVhRMf5FIL4TamuTufLmY+SHvlVr7
bduqzxzlEys6DP0KBhgklRXCdARkPuj8OEoRgyuDcjHELz02Y/XBv2n4VyiUe61f
cs0iLxkzFm8s3CkZ4FAGhUFzNujQAeGHrdU37vbT0zL7OLLXap5EqSx6Iexm13Wv
x55/rKarbpSUqxCBYzEMqytxk9OBCDSer7YP/Z/7MgEmcdReW5JDFqTTsL97rpJr
AMegpz4jDmPSL0xRXlDqEpkCuvuVKOgZUpIacLg4kIdIN6/m+cK3LErWlGHJTlsx
q4Qt4qB58esZLN66cMlbr1zkk47O+FUzoWiz3OkZmegysmVz9FOFyN6wHR33rkE8
rmzjl7s0BKbxq34raGMwPtzEzvT9KaDZraHaVsZ11ucMiMAPUJHjIpgEc3hsSMSB
rPOJUfTv8V+LMosiGEJWTGHXrrX69S01iLqHvwtC2ndLl+ZWpNtQ5lffV+mF4RA4
fC4rfb+f3vnLEHVCsaRsF11Z5w0q+JgK6pb0PiLcRYAjZR6gtIg=
=vcrG
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2022-11-11' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"Weekly pull request for graphics, mostly amdgpu and i915, with a
couple of fixes for vc4 and panfrost, panel quirks and a kconfig
change for rcar-du. Nothing seems to be too strange at this stage.
amdgpu:
- Fix s/r in amdgpu_vram_mgr_new
- SMU 13.0.4 update
- GPUVM TLB race fix
- DCN 3.1.4 fixes
- DCN 3.2.x fixes
- Vega10 fan fix
- BACO fix for Beige Goby board
- PSR fix
- GPU VM PT locking fixes
amdkfd:
- CRIU fixes
vc4:
- HDMI fixes to vc4.
panfrost:
- Make panfrost's uapi header compile with C++.
- Handle 1 gb boundary correctly in panfrost mmu code.
panel:
- Add rotation quirks for 2 panels.
rcar-du:
- DSI Kconfig fix
i915:
- Fix sg_table handling in map_dma_buf
- Send PSR update also on invalidate
- Do not set cache_dirty for DGFX
- Restore userptr probe_range behaviour"
* tag 'drm-fixes-2022-11-11' of git://anongit.freedesktop.org/drm/drm: (29 commits)
drm/amd/display: only fill dirty rectangles when PSR is enabled
drm/amdgpu: disable BACO on special BEIGE_GOBY card
drm/amdgpu: Drop eviction lock when allocating PT BO
drm/amdgpu: Unlock bo_list_mutex after error handling
Revert "drm/amdgpu: Revert "drm/amdgpu: getting fan speed pwm for vega10 properly""
drm/amd/display: Enforce minimum prefetch time for low memclk on DCN32
drm/amd/display: Fix gpio port mapping issue
drm/amd/display: Fix reg timeout in enc314_enable_fifo
drm/amd/display: Fix FCLK deviation and tool compile issues
drm/amd/display: Zeromem mypipe heap struct before using it
drm/amd/display: Update SR watermarks for DCN314
drm/amdgpu: workaround for TLB seq race
drm/amdkfd: Fix error handling in criu_checkpoint
drm/amdkfd: Fix error handling in kfd_criu_restore_events
drm/amd/pm: update SMU IP v13.0.4 msg interface header
drm: rcar-du: Fix Kconfig dependency between RCAR_DU and RCAR_MIPI_DSI
drm/panfrost: Split io-pgtable requests properly
drm/amdgpu: Fix the lpfn checking condition in drm buddy
drm: panel-orientation-quirks: Add quirk for Acer Switch V 10 (SW5-017)
drm: panel-orientation-quirks: Add quirk for Nanote UMPC-01
...
Fix 'cast to restricted' sparse warnings reported by kernel test robot
in https://lore.kernel.org/all/202211021607.ssjymlKi-lkp@intel.com/
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <germain.hebert@ca.abb.com>
Signed-off-by: Germain Hebert <germain.hebert@ca.abb.com>
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <Enrik.Berkhan@inka.de>
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <Enrik.Berkhan@inka.de>
Signed-off-by: Enrik Berkhan <Enrik.Berkhan@inka.de>
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <Enrik.Berkhan@inka.de>
Signed-off-by: Enrik Berkhan <Enrik.Berkhan@inka.de>
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <VAsbridge@sanblaze.com>
Reported-by: Stephen Shirron <SShirron@sanblaze.com>
Reported-by: Enrik Berkhan <Enrik.Berkhan@inka.de>
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <Enrik.Berkhan@inka.de>
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <Enrik.Berkhan@inka.de>
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <michael.zaidman@gmail.com>
Tested-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <michael.zaidman@gmail.com>
Tested-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <michael.zaidman@gmail.com>
Tested-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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 <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
