This reverts commit 407a2c2a.

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: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Tested-by: NSune Mølgaard <sune@molgaard.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NNestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This reverts commit 8af6c088.

This patch re-adds the workaround introduced by 59626408
which was reverted by 8af6c088.

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 c849a614 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 a9dd22b7 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 8af6c088.

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 dcd9006b 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/1194649Signed-off-by: NNestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Use the inlined helpers hid_hw_open/close instead of direct calls to
->ll_driver->open() and ->ll_driver->close().
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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=49781Reported-and-tested-by: NBob Bowles <bobjohnbowles@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This reverts commit 59626408.

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: NAndrew de los Reyes <adlr@chromium.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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
59626408 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: NAndrew de los Reyes <adlr@chromium.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>

For the sensor-hub part:
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch fixes an issue introduced after commit 4ea54542
("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: NNestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Allocate a structure not a pointer to it !
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NMarc Dionne <marc.c.dionne@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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/671292Reported-by: NHugo Osvaldo Barrera <hugo@osvaldobarrera.com.ar>
Inspired-by: NNestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NNestor Lopez Casado <nlopezcasad@logitech.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NNestor Lopez Casado <nlopezcasad@logitech.com>

 drivers/hid/hid-logitech-dj.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NOlivier Gay <ogay@logitech.com>
Signed-off-by: NNestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NNestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>