Dmitry,
I installed current mainline (as of 3b06b1a744) on a z840 here, and
lost the mouse.
Bisecting down, it seems like "HID: usbhid: remove custom locking from
usbhid_open/close" (e399396a6b0) is at fault, and if I revert that and
283a21da1239 I get a working system again. Userspace is Ubuntu 16.04.
Looking at X and dmesg logs, the only delta I see is that in the
_good_ case I have a couple of these in dmesg:
usb 3-12: Device not responding to setup address.
usb 3-12: Device not responding to setup address.
3-12 unrelated to keyboard/mouse though (it's a 4-port hub, likely
internal to the PC), so seems like a red herring.
So, not sure just what's the root cause here, but allowing concurrent
opens seems to make for unhappiness. It's a pretty small patch and
nothing in it seems wrong, besides the change in behavior on allowing
concurrent opens (removal of the mutex).
-Olof
On Wed, Jul 12, 2017 at 02:45:18PM -0700, Olof Johansson wrote:
> Dmitry,
>
> I installed current mainline (as of 3b06b1a744) on a z840 here, and
> lost the mouse.
>
> Bisecting down, it seems like "HID: usbhid: remove custom locking from
> usbhid_open/close" (e399396a6b0) is at fault, and if I revert that and
> 283a21da1239 I get a working system again. Userspace is Ubuntu 16.04.
Olof, does the patch below work for you?
--
Dmitry
HID: usbhid: fix "always poll" quirk
From: Dmitry Torokhov <[email protected]>
Even though the IO for devices with "always poll" quirk is already running,
we still need to set HID_OPENED bit in usbhid->iofl so the interrupt
handler does not ignore the data coming from the device.
Reported-by: Olof Johansson <[email protected]>
Fixes: e399396a6b0 ("HID: usbhid: remove custom locking from usbhid_open...")
Signed-off-by: Dmitry Torokhov <[email protected]>
---
drivers/hid/usbhid/hid-core.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 76013eb5cb7f..c008847e0b20 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -680,18 +680,21 @@ static int usbhid_open(struct hid_device *hid)
struct usbhid_device *usbhid = hid->driver_data;
int res;
+ set_bit(HID_OPENED, &usbhid->iofl);
+
if (hid->quirks & HID_QUIRK_ALWAYS_POLL)
return 0;
res = usb_autopm_get_interface(usbhid->intf);
/* the device must be awake to reliably request remote wakeup */
- if (res < 0)
+ if (res < 0) {
+ clear_bit(HID_OPENED, &usbhid->iofl);
return -EIO;
+ }
usbhid->intf->needs_remote_wakeup = 1;
set_bit(HID_RESUME_RUNNING, &usbhid->iofl);
- set_bit(HID_OPENED, &usbhid->iofl);
set_bit(HID_IN_POLLING, &usbhid->iofl);
res = hid_start_in(hid);
@@ -727,19 +730,20 @@ static void usbhid_close(struct hid_device *hid)
{
struct usbhid_device *usbhid = hid->driver_data;
- if (hid->quirks & HID_QUIRK_ALWAYS_POLL)
- return;
-
/*
* Make sure we don't restart data acquisition due to
* a resumption we no longer care about by avoiding racing
* with hid_start_in().
*/
spin_lock_irq(&usbhid->lock);
- clear_bit(HID_IN_POLLING, &usbhid->iofl);
clear_bit(HID_OPENED, &usbhid->iofl);
+ if (!(hid->quirks & HID_QUIRK_ALWAYS_POLL))
+ clear_bit(HID_IN_POLLING, &usbhid->iofl);
spin_unlock_irq(&usbhid->lock);
+ if (hid->quirks & HID_QUIRK_ALWAYS_POLL)
+ return;
+
hid_cancel_delayed_stuff(usbhid);
usb_kill_urb(usbhid->urbin);
usbhid->intf->needs_remote_wakeup = 0;
On Wed, Jul 12, 2017 at 2:55 PM, Dmitry Torokhov
<[email protected]> wrote:
> On Wed, Jul 12, 2017 at 02:45:18PM -0700, Olof Johansson wrote:
>> Dmitry,
>>
>> I installed current mainline (as of 3b06b1a744) on a z840 here, and
>> lost the mouse.
>>
>> Bisecting down, it seems like "HID: usbhid: remove custom locking from
>> usbhid_open/close" (e399396a6b0) is at fault, and if I revert that and
>> 283a21da1239 I get a working system again. Userspace is Ubuntu 16.04.
>
> Olof, does the patch below work for you?
Yup! Thanks!
> --
> Dmitry
>
> HID: usbhid: fix "always poll" quirk
>
> From: Dmitry Torokhov <[email protected]>
>
> Even though the IO for devices with "always poll" quirk is already running,
> we still need to set HID_OPENED bit in usbhid->iofl so the interrupt
> handler does not ignore the data coming from the device.
>
> Reported-by: Olof Johansson <[email protected]>
> Fixes: e399396a6b0 ("HID: usbhid: remove custom locking from usbhid_open...")
> Signed-off-by: Dmitry Torokhov <[email protected]>
Tested-by: Olof Johansson <[email protected]>