summaryrefslogtreecommitdiffstats
path: root/drivers/hid/hid-logitech-dj.c
Commit message (Collapse)AuthorAgeFilesLines
* HID: logitech-dj: allow devices to request full pairing informationBenjamin Tissoires2017-04-061-8/+11
| | | | | | | | | | Register 0xB5 should be handled specially no matter what function is used. This allows to retrieve the serial and the Quad ID from hid-logitech-hidpp directly. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-dj: check report lengthPeter Wu2014-12-171-1/+15
| | | | | | | | | | Malicious USB devices can send bogus reports smaller than the expected buffer size. Ensure that the length is valid to avoid reading out of bounds. Signed-off-by: Peter Wu <peter@lekensteyn.nl> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-dj: enable notifications on connect/disconnectBenjamin Tissoires2014-10-291-1/+26
| | | | | | | | | | | | | The receiver can send HID++ notifications to the DJ devices when the physical devices are connected/disconnected. Enable this feature by default. This command uses a HID++ command instead of a DJ one, so use a direct call to usbhid instead of using logi_dj_recv_send_report() Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech: allow the DJ device to request the unifying nameBenjamin Tissoires2014-10-291-3/+21
| | | | | | | | | | | | | | | | | The names of the DJ devices are stored in the receiver. These names can be retrieved through a HID++ command. However, the protocol says that you have to ask the receiver for that, not the device iteself. Introduce a special case in the DJ handling where a device can request its unifying name, and when such a name is given, forward it also to the corresponding device. On the HID++ side, the receiver talks only HID++ 1.0, so we need to implement this part of the protocol in the module. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-dj: allow transfer of HID++ reports from/to the correct dj deviceBenjamin Tissoires2014-10-291-28/+160
| | | | | | | | | | | | | | | HID++ is a Logitech-specific protocol for communicating with HID devices. DJ devices implement HID++, and so we can add the HID++ collection in the report descriptor and forward the incoming reports from the receiver to the appropriate DJ device. The same can be done in the other way, if someone calls a .raw_request(), we can forward it to the correct dj device by overriding the device_index in the HID++ report. Signed-off-by: Benjamin Tisssoires <benjamin.tissoires@redhat.com> Tested-by: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech: move dj devices to the HID++ moduleBenjamin Tissoires2014-10-291-41/+1Star
| | | | | | | | | | | Devices connected through the Logitech Wireless Receiver are HID++ devices. We can handle them here to benefit from this new module and activate enhaced support of the various wireless touchpad or mice with touch sensors on them. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-dj: merge header file into the sourceBenjamin Tissoires2014-10-291-1/+87
| | | | | | | | | There is no point in keeping the header in a separate file, nobody but hid-logitech-dj should have access to its content. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-dj: rely on hid groups to separate receivers from dj devicesBenjamin Tissoires2014-10-291-28/+10Star
| | | | | | | | | | | | | | | | Several benefits here: - we can drop the macro is_dj_device: I never been really conviced by this macro as we could fall into a null pointer anytime. Anyway time showed that this never happened. - we can simplify the hid driver logitech-djdevice, and make it aware of any new receiver VID/PID. - we can use the Wireless PID of the DJ device as the product id of the hid device, this way the sysfs will differentiate between different DJ devices. Signed-off-by: Benjamin Tisssoires <benjamin.tissoires@redhat.com> Tested-by: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-dj: break out testing of validity of dj_deviceBenjamin Tissoires2014-08-271-24/+11Star
| | | | | | | | We can do once the test of the validity of the dj_device, which removes some duplicated code in various functions. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-dj: prevent false errors to be shownBenjamin Tissoires2014-08-251-18/+25
| | | | | | | | | | | | | | | | | | | | Commit "HID: logitech: perform bounds checking on device_id early enough" unfortunately leaks some errors to dmesg which are not real ones: - if the report is not a DJ one, then there is not point in checking the device_id - the receiver (index 0) can also receive some notifications which can be safely ignored given the current implementation Move out the test regarding the report_id and also discards printing errors when the receiver got notified. Fixes: ad3e14d7c5268c2e24477c6ef54bbdf88add5d36 Cc: stable@vger.kernel.org Reported-and-tested-by: Markus Trippelsdorf <markus@trippelsdorf.de> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech: perform bounds checking on device_id early enoughJiri Kosina2014-08-211-7/+6Star
| | | | | | | | | | | | | | | | | | | | device_index is a char type and the size of paired_dj_deivces is 7 elements, therefore proper bounds checking has to be applied to device_index before it is used. We are currently performing the bounds checking in logi_dj_recv_add_djhid_device(), which is too late, as malicious device could send REPORT_TYPE_NOTIF_DEVICE_UNPAIRED early enough and trigger the problem in one of the report forwarding functions called from logi_dj_raw_event(). Fix this by performing the check at the earliest possible ocasion in logi_dj_raw_event(). Cc: stable@vger.kernel.org Reported-by: Ben Hawkes <hawkes@google.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech: fix bounds checking on LED report sizeJiri Kosina2014-08-211-1/+1
| | | | | | | | | | | | | | | | The check on report size for REPORT_TYPE_LEDS in logi_dj_ll_raw_request() is wrong; the current check doesn't make any sense -- the report allocated by HID core in hid_hw_raw_request() can be much larger than DJREPORT_SHORT_LENGTH, and currently logi_dj_ll_raw_request() doesn't handle this properly at all. Fix the check by actually trimming down the report size properly if it is too large. Cc: stable@vger.kernel.org Reported-by: Ben Hawkes <hawkes@google.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-dj: remove hid_output_raw_report callBenjamin Tissoires2014-02-171-15/+6Star
| | | | | | | | | hid-input do not use anymore hid_output_raw_report() to set the LEDs. Use the correct implementation now and make them working again. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-dj: remove hidinput_input_eventBenjamin Tissoires2014-02-171-64/+42Star
| | | | | | | | | | | | hid-logitech-dj uses its own ->hidinput_input_event() instead of the generic binding in hid-input. Moving the handling of LEDs towards logi_dj_output_hidraw_report() allows two things: - remove hidinput_input_event in struct hid_device - hidraw user space programs can also set the LEDs Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-dj: Fix USB 3.0 issueBenjamin Tisssoires2014-01-161-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fix (not very clean though) should fix the long time USB3 issue that was spotted last year. The rational has been given by Hans de Goede: ---- I think the most likely cause for this is a firmware bug in the unifying receiver, likely a race condition. The most prominent difference between having a USB-2 device plugged into an EHCI (so USB-2 only) port versus an XHCI port will be inter packet timing. Specifically if you send packets (ie hid reports) one at a time, then with the EHCI controller their will be a significant pause between them, where with XHCI they will be very close together in time. The reason for this is the difference in EHCI / XHCI controller OS <-> driver interfaces. For non periodic endpoints (control, bulk) the EHCI uses a circular linked-list of commands in dma-memory, which it follows to execute commands, if the list is empty, it will go into an idle state and re-check periodically. The XHCI uses a ring of commands per endpoint, and if the OS places anything new on the ring it will do an ioport write, waking up the XHCI making it send the new packet immediately. For periodic transfers (isoc, interrupt) the delay between packets when sending one at a time (rather then queuing them up) will be even larger, because they need to be inserted into the EHCI schedule 2 ms in the future so the OS driver can be sure that the EHCI driver does not try to start executing the time slot in question before the insertion has completed. So a possible fix may be to insert a delay between packets being send to the receiver. ---- I tested this on a buggy Haswell USB 3.0 motherboard, and I always get the notification after adding the msleep. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-dj: small cleanup in rdcat()Dan Carpenter2013-10-301-7/+7
| | | | | | | | We could pass the "rdsec" pointer instead of the address of the "rdesc" and it's a little simpler. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech-dj: validate output report detailsKees Cook2013-09-131-2/+8
| | | | | | | | | | | | | | | | | | A HID device could send a malicious output report that would cause the logitech-dj HID driver to leak kernel memory contents to the device, or trigger a NULL dereference during initialization: [ 304.424553] usb 1-1: New USB device found, idVendor=046d, idProduct=c52b ... [ 304.780467] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 [ 304.781409] IP: [<ffffffff815d50aa>] logi_dj_recv_send_report.isra.11+0x1a/0x90 CVE-2013-2895 Signed-off-by: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
*-----. Merge branches 'for-3.12/devm', 'for-3.12/i2c-hid', 'for-3.12/i2c-hid-dt', ↵Jiri Kosina2013-09-061-7/+15
|\ \ \ \ | | | | | | | | | | | | | | | 'for-3.12/logitech', 'for-3.12/multitouch-win8', 'for-3.12/trasnport-driver-cleanup', 'for-3.12/uhid', 'for-3.12/upstream' and 'for-3.12/wiimote' into for-linus
| | | * \ Merge branch 'master' into for-3.12/upstreamJiri Kosina2013-09-041-0/+45
| | | |\ \ | |_|_|/ / |/| | | / | | | |/ | | | | | | | | | | | | Sync with Linus' tree to be able to apply fixup patch on top of 9d9a04ee75 ("HID: apple: Add support for the 2013 Macbook Air") Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| | | * HID: logitech-dj: Fix non-atomic kmalloc in logi_dj_ll_input_event()Peter Hurley2013-08-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ll_driver's .hidinput_input_event() method is called from atomic context [1]. Use GFP_ATOMIC for allocation of the synthesized hid report. BUG: sleeping function called from invalid context at /home/peter/src/kernels/next/mm/slub.c:941 in_atomic(): 1, irqs_disabled(): 1, pid: 2095, name: Xorg INFO: lockdep is turned off. irq event stamp: 1502178 hardirqs last enabled at (1502177): [<ffffffff81785e55>] _raw_spin_unlock_irqrestore+0x65/0x80 hardirqs last disabled at (1502178): [<ffffffff8178632a>] common_interrupt+0x6a/0x6f softirqs last enabled at (1501802): [<ffffffff81051ed3>] __do_softirq+0x183/0x420 softirqs last disabled at (1501799): [<ffffffff81052315>] irq_exit+0xb5/0xc0 CPU: 3 PID: 2095 Comm: Xorg Not tainted 3.11-next-20130725-xeon+lockdep #20130725 Hardware name: Dell Inc. Precision WorkStation T5400 /0RW203, BIOS A11 04/30/2012 ffffffff81a662e0 ffff8802adcf9ca8 ffffffff8177c330 0000000000000000 ffff8802a76d2440 ffff8802adcf9cd8 ffffffff810867d0 ffff8802a7ac8000 0000000000000010 00000000ffffffff 00000000000000d0 ffff8802adcf9d38 Call Trace: [<ffffffff8177c330>] dump_stack+0x4f/0x84 [<ffffffff810867d0>] __might_sleep+0x140/0x1f0 [<ffffffff811ad93b>] __kmalloc+0x6b/0x2e0 [<ffffffffa026cb08>] ? hid_alloc_report_buf+0x28/0x30 [hid] [<ffffffffa026cb08>] hid_alloc_report_buf+0x28/0x30 [hid] [<ffffffffa00700b0>] logi_dj_ll_input_event+0xb0/0x1b0 [hid_logitech_dj] [<ffffffff815a559e>] input_handle_event+0x8e/0x540 [<ffffffff815a5aad>] ? input_inject_event+0x5d/0x220 [<ffffffff815a5c10>] input_inject_event+0x1c0/0x220 [<ffffffff815a5a94>] ? input_inject_event+0x44/0x220 [<ffffffff81181660>] ? might_fault+0xa0/0xb0 [<ffffffff81181617>] ? might_fault+0x57/0xb0 [<ffffffff815a909e>] evdev_write+0xde/0x160 [<ffffffff811c0ad8>] vfs_write+0xc8/0x1f0 [<ffffffff811c0fe5>] SyS_write+0x55/0xa0 [<ffffffff8178e682>] system_call_fastpath+0x16/0x1b Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| | | * HID: fix data access in implement()Jiri Kosina2013-07-221-2/+10
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | implement() is setting bytes in LE data stream. In case the data is not aligned to 64bits, it reads past the allocated buffer. It doesn't really change any value there (it's properly bitmasked), but in case that this read past the boundary hits a page boundary, pagefault happens when accessing 64bits of 'x' in implement(), and kernel oopses. This happens much more often when numbered reports are in use, as the initial 8bit skip in the buffer makes the whole process work on values which are not aligned to 64bits. This problem dates back to attempts in 2005 and 2006 to make implement() and extract() as generic as possible, and even back then the problem was realized by Adam Kroperlin, but falsely assumed to be impossible to cause any harm: http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html I have made several attempts at fixing it "on the spot" directly in implement(), but the results were horrible; the special casing for processing last 64bit chunk and switching to different math makes it unreadable mess. I therefore took a path to allocate a few bytes more which will never make it into final report, but are there as a cushion for all the 64bit math operations happening in implement() and extract(). All callers of hid_output_report() are converted at the same time to allocate the buffer by newly introduced hid_alloc_report_buf() helper. Bruno noticed that the whole raw_size test can be dropped as well, as hid_alloc_report_buf() makes sure that the buffer is always of a proper size. Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| | * HID: logitech-dj: use inlined helpers hid_hw_open/closeBenjamin Tissoires2013-07-121-5/+5
| |/ | | | | | | | | | | | | | | Use the inlined helpers hid_hw_open/close instead of direct calls to ->ll_driver->open() and ->ll_driver->close(). Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | Revert "HID: hid-logitech-dj: querying_devices was never set"Jiri Kosina2013-08-091-2/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 407a2c2a4d85100c8c67953e4bac2f4a6c942335. Explanation provided by Benjamin Tissoires: Commit "HID: hid-logitech-dj, querying_devices was never set" activate a flag which guarantees that we do not ask the receiver for too many enumeration. When the flag is set, each following enumeration call is discarded (the usb request is not forwarded to the receiver). The flag is then released when the driver receive a pairing information event, which normally follows the enumeration request. However, the USB3 bug makes the driver think the enumeration request has been forwarded to the receiver. However, it is actually not the case because the USB stack returns -EPIPE. So, when a new unknown device appears, the workaround consisting in asking for a new enumeration is not working anymore: this new enumeration is discarded because of the flag, which is never reset. A solution could be to trigger a timeout before releasing it, but for now, let's just revert the patch. Reported-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Tested-by: Sune Mølgaard <sune@molgaard.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | HID: hid-logitech-dj: querying_devices was never setNestor Lopez Casado2013-07-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | Set querying_devices flag to true when we start the enumeration process. This was missing from the original patch. It never produced undesirable effects as it is highly improbable to have a second enumeration triggered while a first one was still in progress. Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | HID: Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""Nestor Lopez Casado2013-07-221-0/+45
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 8af6c08830b1ae114d1a8b548b1f8b056e068887. This patch re-adds the workaround introduced by 596264082f10dd4 which was reverted by 8af6c08830b1ae114. The original patch 596264 was needed to overcome a situation where the hid-core would drop incoming reports while probe() was being executed. This issue was solved by c849a6143bec520af which added hid_device_io_start() and hid_device_io_stop() that enable a specific hid driver to opt-in for input reports while its probe() is being executed. Commit a9dd22b730857347 modified hid-logitech-dj so as to use the functionality added to hid-core. Having done that, workaround 596264 was no longer necessary and was reverted by 8af6c08. We now encounter a different problem that ends up 'again' thwarting the Unifying receiver enumeration. The problem is time and usb controller dependent. Ocasionally the reports sent to the usb receiver to start the paired devices enumeration fail with -EPIPE and the receiver never gets to enumerate the paired devices. With dcd9006b1b053c7b1c the problem was "hidden" as the call to the usb driver became asynchronous and none was catching the error from the failing URB. As the root cause for this failing SET_REPORT is not understood yet, -possibly a race on the usb controller drivers or a problem with the Unifying receiver- reintroducing this workaround solves the problem. Overall what this workaround does is: If an input report from an unknown device is received, then a (re)enumeration is performed. related bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1194649 Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
*-. Merge branches 'for-3.10/appleir', 'for-3.10/hid-debug', ↵Jiri Kosina2013-04-301-48/+5Star
|\ \ | | | | | | | | | 'for-3.10/hid-driver-transport-cleanups', 'for-3.10/i2c-hid' and 'for-3.10/logitech' into for-linus
| | * Revert "HID: Fix logitech-dj: missing Unifying device issue"Andrew de los Reyes2013-03-011-45/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 596264082f10dd4a567c43d4526b2f54ac5520bc. The reverted commit was a workaround needed when drivers became unable to communicate with devices during probe(). Now that such communication is possible, the workaround is not needed. Signed-off-by: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| | * HID: logitech-dj: Allow incoming packets during probe().Andrew de los Reyes2013-03-011-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Historically, logitech-dj communicated with the device during probe() to query the list of devices attached. Later, a change was introduced to hid-core that prevented incoming packets for a device during probe(), as many drivers are unable to handle such input. That change broke the device enumeration in logitech-dj, so commit 596264082f10dd4a56 was introduced to workaround that by waiting for normal input before enumerating devices. Now that drivers can opt-in to receive input during probe, this patch changes logitech-dj to do that, so that it can successfully complete enumeration of devices during probe(). Signed-off-by: Andrew de los Reyes <adlr@chromium.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| * | HID: Merge branch 'master' into for-3.10/hid-driver-transport-cleanupsJiri Kosina2013-03-091-8/+14
| |\ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | Sync with Linus' tree. This is necessary to resolve build conflict caused by dcd9006b1b053c7b ("HID: logitech-dj: do not directly call hid_output_raw_report() during probe") which issues direct call to usbhid_submit_report(), but that is gone in this branch and hid_hw_request() has to be used instead. Signed-off-by: Jiri Kosina <jkosina@suse.cz>
| * | HID: use hid_hw_request() instead of direct call to usbhidBenjamin Tissoires2013-02-251-2/+1Star
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows the hid drivers to be independent from the transport layer. The patch was constructed by replacing all occurences of usbhid_submit_report() by its hid_hw_request() counterpart. Then, drivers not requiring USB_HID anymore have their USB_HID dependency cleaned in the Kconfig file. Finally, few drivers still depends on USB_HID. Many of them are requiring the io wait callback. They are found in the next patch. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> For the sensor-hub part: Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* / HID: logitech-dj: do not directly call hid_output_raw_report() during probeBenjamin Tissoires2013-03-071-8/+14
|/ | | | | | | | | | | | | | | | | | | | | | | hid_output_raw_report() makes a direct call to usb_control_msg(). However, some USB3 boards have shown that the usb device is not ready during the .probe(). This blocks the entire usb device, and the paired mice, keyboards are not functional. The dmesg output is the following: [ 11.912287] logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-2/input2 [ 11.912537] logitech-djreceiver 0003:046D:C52B.0003: logi_dj_probe:logi_dj_recv_query_paired_devices error:-32 [ 11.912636] logitech-djreceiver: probe of 0003:046D:C52B.0003 failed with error -32 Relying on the scheduled call to usbhid_submit_report() fixes the problem. related bugs: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039143 https://bugzilla.redhat.com/show_bug.cgi?id=840391 https://bugzilla.kernel.org/show_bug.cgi?id=49781 Reported-and-tested-by: Bob Bowles <bobjohnbowles@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: Fix logitech-dj: missing Unifying device issueNestor Lopez Casado2012-09-221-0/+45
| | | | | | | | | | | | | | | | | | | | | | This patch fixes an issue introduced after commit 4ea5454203d991ec ("HID: Fix race condition between driver core and ll-driver"). After that commit, hid-core discards any incoming packet that arrives while hid driver's probe function is being executed. This broke the enumeration process of hid-logitech-dj, that must receive control packets in-band with the mouse and keyboard packets. Discarding mouse or keyboard data at the very begining is usually fine, but it is not the case for control packets. This patch forces a re-enumeration of the paired devices when a packet arrives that comes from an unknown device. Based on a patch originally written by Benjamin Tissoires. Cc: stable@vger.kernel.org # v3.2+ Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* dj: memory scribble in logi_djAlan Cox2012-09-061-2/+2
| | | | | | | Allocate a structure not a pointer to it ! Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* HID: logitech: don't use stack based dj_report structuresMarc Dionne2012-06-031-14/+24
| | | | | | | | | | | | | | | On a system with a logitech wireless keyboard/mouse and DMA-API debugging enabled, this warning appears at boot: kernel: WARNING: at lib/dma-debug.c:929 check_for_stack.part.12+0x70/0xa7() kernel: Hardware name: MS-7593 kernel: uhci_hcd 0000:00:1d.1: DMA-API: device driver maps memory fromstack [addr=ffff8801b0079c29] Make logi_dj_recv_query_paired_devices and logi_dj_recv_switch_to_dj_mode use a structure allocated with kzalloc rather than a stack based one. Signed-off-by: Marc Dionne <marc.c.dionne@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
*-. Merge branches 'upstream-fixes', 'wacom' and 'waltop' into for-linusJiri Kosina2012-05-221-2/+3
|\ \ | | | | | | | | | | | | Conflicts: drivers/hid/hid-core.c
| * | HID: logitech: read all 32 bits of report type bitfieldJonathan Nieder2012-05-111-2/+3
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On big-endian systems (e.g., Apple PowerBook), trying to use a logitech wireless mouse with the Logitech Unifying Receiver does not work with v3.2 and later kernels. The device doesn't show up in /dev/input. Older kernels work fine. That is because the new hid-logitech-dj driver claims the device. The device arrival notification appears: 20 00 41 02 00 00 00 00 00 00 00 00 00 00 00 and we read the report_types bitfield (02 00 00 00) to find out what kind of device it is. Unfortunately the driver only reads the first 8 bits and treats that value as a 32-bit little-endian number, so on a powerpc the report type seems to be 0x02000000 and is not recognized. Even on little-endian machines, connecting a media center remote control (report type 00 01 00 00) with this driver loaded would presumably fail for the same reason. Fix both problems by using get_unaligned_le32() to read all four bytes, which is a little clearer anyway. After this change, the wireless mouse works on Hugo's PowerBook again. Based on a patch by Nestor Lopez Casado. Addresses http://bugs.debian.org/671292 Reported-by: Hugo Osvaldo Barrera <hugo@osvaldobarrera.com.ar> Inspired-by: Nestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com> Cc: <stable@vger.kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* / HID: hid-logitech: Collect report descriptors before sendingHenrik Rydberg2012-05-011-42/+29Star
|/ | | | | | | | | | | | The current code allows several consecutive calls to hid_parse_report(), which may have happened to work before, but would cause a memory leak and generally be incorrect. This patch collects all the reports before sending them once. Cc: Nestor Lopez Casado <nlopezcasad@logitech.com> Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com Signed-off-by: Henrik Rydberg <rydberg@euromail.se> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: logitech: fix mask to enable DJ modeNestor Lopez Casado2012-02-021-1/+1
| | | | | | | | | | | | | | | The user can only experience the bug if she pairs 6 devices to a Unifying receiver. The sixth paired device would not work. The value changed is actually a bitmask that enables reporting from each paired device. As the sixth bit was not set, the sixth device reports are ignored by the receiver and never get to the driver. Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com> drivers/hid/hid-logitech-dj.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: hid-logitech-dj: fix off by oneNestor Lopez Casado2011-09-201-4/+1Star
| | | | | | | | | | | | There is a bug where a device with index 6 would write out of bounds in the array of paired devices. This patch fixes that problem. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Reviewed-by: Olivier Gay <ogay@logitech.com> Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: Add full support for Logitech Unifying receiversNestor Lopez Casado2011-09-151-0/+925
With this driver, all the devices paired to a single Unifying receiver are exposed to user processes in separated /input/dev nodes. Keyboards with different layouts can be treated differently, Multiplayer games on single PC (like home theater PC) can differentiate input coming from different kbds paired to the same receiver. Up to now, when Logitech Unifying receivers are connected to a Linux based system, a single keyboard and a single mouse are presented to the HID Layer, even if the Unifying receiver can pair up to six compatible devices. The Unifying receiver by default multiplexes all incoming events (from multiple keyboards/mice) into these two. Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-11-14 19:19:51 +0100