HID: Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""

HID: Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""

This reverts commit 2f371a06bb80fdbe35948975b4be0a5fcee0a7dc.

This patch re-adds the workaround introduced by 8f21ad6c3f28802
which was reverted by 2f371a06bb80fdbe3.

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 155893bd9490382ef 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 1e7ef3bcd573bbf9 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 2f371a0.

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 13d5f06365bbeaddc1 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>