Bug 39882

Your dmesg trace makes it look like the problem is when your mouse disconnects since it's after the main loop in hidp_session(). Is this true? Your comments above make it sound otherwise.

Also, is the call to down_write() where the problem happens (ie: are there other printk() messages after the call to down_write()?)?

Yes, it happens outside the main loop in hidp_session() but I had just turned the mouse on. For some reason the connection did not work, the session ended and the kthread oopsed.

The down_write printk is located after the down_write call ("depois" means "after" in Brazilian Portuguese). Probably the problem is in the next function call (hidp_del_timer(session)). I think printk is buffered, right? If so then it is not a reliable indication of where the problem really happens.

Interesting. So it sounds like the main loop in hidp_session() never gets going and thus exits before the device actually gets added to the system (by calling hid_add_device()).

The real problem here that the main loop exits on the first pass. See if you can add some logging to see which place session->terminate is getting set.

Created attachment 66602 [details]
New dmesg log

Here is the new dmesg. I forgot to add a '\n' at the end of the printk (I am used to use kDebug() in KDE which automatically adds the '\n'), but it is easy to see the terminate is set in err_add_device label, which is trigged because hid_add_device has failed.

Now I must say that this mouse is blacklisted for hid session in drivers/hid/hid-core.c, see the line with:

{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_KYE, 0x0058) },

The mouse works with hid but with laggy. Using input session it works much better, that is why I asked to blacklist it two years ago.

I think I know what is happening:

With your patch applied:

1. hidp_add_connection calls hidp_setup_hid, which returns 0 and set ups a hid session. This is wrong, the mouse is blacklisted although it works with hid.
2. after session->waiting_for_startup hidp_add_connection calls hid_add_device, which fails probably because of the blacklist I mentioned before;
3. because of the failed above hidp_add_connection reaches err_add_device.

Without your patch applied:

1. hidp_add_connection calls hidp_setup_hid, which returns error because hid_add_device is inside hidp_setup_hid;
2. hidp_add_connection tries to setup a input session instead, which works and everything else works.

The problem is that with your patch hidp_setup_hid does not take the blacklist into account anymore.

Created attachment 66632 [details]
Checks blacklist before allocating hid device

The attached patch fixes the problem for me. I am just not sure if that is the right place to check the blacklist since hid_add_device already checks for it.

Added Jiri Kosina (HID Maintainer) to CC.

Jiri, is there any problem moving the quirk blacklist checking to hid_allocate_device() instead of hid_add_device() like Lamarque suggests in his patch?

Lamarque, the checking for blacklist should probably only be done in one place, either hid_allocate_device() or hid_add_device(). I'd suggest removing it from hid_add_device() if you are going to move it to hid_allocate_device().

I'm still not 100% sure that the ordering is correct in this case still. I'll look at it again in the morning.

Patch: https://bugzilla.kernel.org/attachment.cgi?id=66632

Is this patch gonna be merged?

The patch http://bugzilla.kernel.org/attachment.cgi?id=66632 does not work because the hdev struct does not contain the vendor and the product ids when hid_allocate_device is called. Checking the blacklist there does not work because of that.

This bug is still an open issue, the only solution I have found so far is reverting 0f69dca20f77dc374b67e17e10b30cec37e778c4. Another solution is exporting the hid_ignore function to other kernel modules and use it in net/bluetooth/hidp/core.c:hidp_setup_hid(). What do you think?

Ignore-Patch: https://bugzilla.kernel.org/attachment.cgi?id=66632

Created attachment 70332 [details]
Checks blacklist before creating hid session

The attached patch exports function hid_ignore and adds a check in hidp_setup_hid, which will return -ENODEV if the device is blacklisted. It fixes the problem for me. Is the patch ok to submit to the kernel?

Created attachment 70342 [details]
Checks blacklist before creating hid session (v2)

Small change in the patch.

Patch : https://bugzilla.kernel.org/attachment.cgi?id=70342

Created attachment 72921 [details]
Checks blacklist before creating hid session (kernel 3.3)

Kernel 3.3 introduced one change that broke the last patch I sent. This one works.

Is the issue still present in current vanilla?

If so, could you please refresh the patch against the current vanilla, add proper changelog and signoff line, so that I could review and apply it? Thanks.

By current vanilla you mean 3.7-rc7, right? If so I will update the patch until tomorrow.

I guess this problem is still reproducible. The problem only happens with bluetooth mice that support both input and hid that are blacklisted in drivers/hid/hid-core.c. That is a rare combination, so most people is not affected by this bug. I myself blacklisted my mouse in drivers/hid/hid-core.c because its hid implementation is buggy (either it causes too much laggy, like in Windows, or the mouse pointer is always stuck at the top left corner).

Created attachment 88491 [details]
Checks blacklist before creating hid session (kernel 3.7.0-rc8)

Patch updated to apply to 3.7-rc8, which by the way still contains this bug.

Thanks for the refresh.

What is still missing is changelog, explaining what is the bug it fixes and how it fixes it, and Signed-off-by line, as documented in Documentation/SubmittingPatches

Ideally, send the patch with all these to me (jkosina@suse.cz) and cc linux-input@ and LKML.

Without this, I can't really review/apply it.

Thanks!

A patch referencing this bug report has been merged in Linux v3.8-rc1:

commit 4529eefad087f97b33c0f31984d924b1f15d7bae
Author: Lamarque V. Souza <lamarque@gmail.com>
Date:   Thu Dec 6 12:39:55 2012 -0200

    HID: hidp: fallback to input session properly if hid is blacklisted