Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1686056 > unrolled thread

Regression during 4.13 merge window: Mouse not working (under X)

Back to article view | Back to linux.kernel

Contents

  Regression during 4.13 merge window: Mouse not working (under X) Olof Johansson <olof@lixom.net> - 2017-07-12 23:50 +0200
    Re: Regression during 4.13 merge window: Mouse not working (under X) Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-07-13 00:00 +0200
      Re: Regression during 4.13 merge window: Mouse not working (under X) Olof Johansson <olof@lixom.net> - 2017-07-13 02:10 +0200

#1686056 — Regression during 4.13 merge window: Mouse not working (under X)

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

[toc] | [next] | [standalone]

#1686066

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 <dmitry.torokhov@gmail.com>

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 <olof@lixom.net>
Fixes: e399396a6b0 ("HID: usbhid: remove custom locking from usbhid_open...")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 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;

[toc] | [prev] | [next] | [standalone]

#1686141

On Wed, Jul 12, 2017 at 2:55 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> 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 <dmitry.torokhov@gmail.com>
>
> 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 <olof@lixom.net>
> Fixes: e399396a6b0 ("HID: usbhid: remove custom locking from usbhid_open...")
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Tested-by: Olof Johansson <olof@lixom.net>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web