linux-stable.git/drivers/bluetooth, branch linux-4.5.y Linux kernel stable tree Bluetooth: vhci: Fix race at creating hci device 2016-06-01T19:16:59+00:00 Takashi Iwai tiwai@suse.de 2016-04-14T15:32:19+00:00 42c021d1bfe919e6b2fe36a0de74b539dae6c4fc commit c7c999cb18da88a881e10e07f0724ad0bfaff770 upstream. hci_vhci driver creates a hci device object dynamically upon each HCI_VENDOR_PKT write. Although it checks the already created object and returns an error, it's still racy and may build multiple hci_dev objects concurrently when parallel writes are performed, as the device tracks only a single hci_dev object. This patch introduces a mutex to protect against the concurrent device creations. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit c7c999cb18da88a881e10e07f0724ad0bfaff770 upstream.

hci_vhci driver creates a hci device object dynamically upon each
HCI_VENDOR_PKT write.  Although it checks the already created object
and returns an error, it's still racy and may build multiple hci_dev
objects concurrently when parallel writes are performed, as the device
tracks only a single hci_dev object.

This patch introduces a mutex to protect against the concurrent device
creations.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bluetooth: vhci: purge unhandled skbs 2016-06-01T19:16:59+00:00 Jiri Slaby jslaby@suse.cz 2016-03-19T10:49:43+00:00 d071b444851fa2bd2e2fa7f16eb54876b1d36397 commit 13407376b255325fa817798800117a839f3aa055 upstream. The write handler allocates skbs and queues them into data->readq. Read side should read them, if there is any. If there is none, skbs should be dropped by hdev->flush. But this happens only if the device is HCI_UP, i.e. hdev->power_on work was triggered already. When it was not, skbs stay allocated in the queue when /dev/vhci is closed. So purge the queue in ->release. Program to reproduce: #include <err.h> #include <fcntl.h> #include <stdio.h> #include <unistd.h> #include <sys/stat.h> #include <sys/types.h> #include <sys/uio.h> int main() { char buf[] = { 0xff, 0 }; struct iovec iov = { .iov_base = buf, .iov_len = sizeof(buf), }; int fd; while (1) { fd = open("/dev/vhci", O_RDWR); if (fd < 0) err(1, "open"); usleep(50); if (writev(fd, &iov, 1) < 0) err(1, "writev"); usleep(50); close(fd); } return 0; } Result: kmemleak: 4609 new suspected memory leaks unreferenced object 0xffff88059f4d5440 (size 232): comm "vhci", pid 1084, jiffies 4294912542 (age 37569.296s) hex dump (first 32 bytes): 20 f0 23 87 05 88 ff ff 20 f0 23 87 05 88 ff ff .#..... .#..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: ... [<ffffffff81ece010>] __alloc_skb+0x0/0x5a0 [<ffffffffa021886c>] vhci_create_device+0x5c/0x580 [hci_vhci] [<ffffffffa0219436>] vhci_write+0x306/0x4c8 [hci_vhci] Fixes: 23424c0d31 (Bluetooth: Add support creating virtual AMP controllers) Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 13407376b255325fa817798800117a839f3aa055 upstream.

The write handler allocates skbs and queues them into data->readq.
Read side should read them, if there is any. If there is none, skbs
should be dropped by hdev->flush. But this happens only if the device
is HCI_UP, i.e. hdev->power_on work was triggered already. When it was
not, skbs stay allocated in the queue when /dev/vhci is closed. So
purge the queue in ->release.

Program to reproduce:
	#include <err.h>
	#include <fcntl.h>
	#include <stdio.h>
	#include <unistd.h>

	#include <sys/stat.h>
	#include <sys/types.h>
	#include <sys/uio.h>

	int main()
	{
		char buf[] = { 0xff, 0 };
		struct iovec iov = {
			.iov_base = buf,
			.iov_len = sizeof(buf),
		};
		int fd;

		while (1) {
			fd = open("/dev/vhci", O_RDWR);
			if (fd < 0)
				err(1, "open");

			usleep(50);

			if (writev(fd, &iov, 1) < 0)
				err(1, "writev");

			usleep(50);

			close(fd);
		}

		return 0;
	}

Result:
kmemleak: 4609 new suspected memory leaks
unreferenced object 0xffff88059f4d5440 (size 232):
  comm "vhci", pid 1084, jiffies 4294912542 (age 37569.296s)
  hex dump (first 32 bytes):
    20 f0 23 87 05 88 ff ff 20 f0 23 87 05 88 ff ff   .#..... .#.....
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
...
    [<ffffffff81ece010>] __alloc_skb+0x0/0x5a0
    [<ffffffffa021886c>] vhci_create_device+0x5c/0x580 [hci_vhci]
    [<ffffffffa0219436>] vhci_write+0x306/0x4c8 [hci_vhci]

Fixes: 23424c0d31 (Bluetooth: Add support creating virtual AMP controllers)
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bluetooth: vhci: fix open_timeout vs. hdev race 2016-06-01T19:16:59+00:00 Jiri Slaby jslaby@suse.cz 2016-03-19T10:05:18+00:00 e2b5fee43d27733bc417dae40e107efab22c8ba0 commit 373a32c848ae3a1c03618517cce85f9211a6facf upstream. Both vhci_get_user and vhci_release race with open_timeout work. They both contain cancel_delayed_work_sync, but do not test whether the work actually created hdev or not. Since the work can be in progress and _sync will wait for finishing it, we can have data->hdev allocated when cancel_delayed_work_sync returns. But the call sites do 'if (data->hdev)' *before* cancel_delayed_work_sync. As a result: * vhci_get_user allocates a second hdev and puts it into data->hdev. The former is leaked. * vhci_release does not release data->hdev properly as it thinks there is none. Fix both cases by moving the actual test *after* the call to cancel_delayed_work_sync. This can be hit by this program: #include <err.h> #include <fcntl.h> #include <stdio.h> #include <stdlib.h> #include <time.h> #include <unistd.h> #include <sys/stat.h> #include <sys/types.h> int main(int argc, char **argv) { int fd; srand(time(NULL)); while (1) { const int delta = (rand() % 200 - 100) * 100; fd = open("/dev/vhci", O_RDWR); if (fd < 0) err(1, "open"); usleep(1000000 + delta); close(fd); } return 0; } And the result is: BUG: KASAN: use-after-free in skb_queue_tail+0x13e/0x150 at addr ffff88006b0c1228 Read of size 8 by task kworker/u13:1/32068 ============================================================================= BUG kmalloc-192 (Tainted: G E ): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in vhci_open+0x50/0x330 [hci_vhci] age=260 cpu=3 pid=32040 ... kmem_cache_alloc_trace+0x150/0x190 vhci_open+0x50/0x330 [hci_vhci] misc_open+0x35b/0x4e0 chrdev_open+0x23b/0x510 ... INFO: Freed in vhci_release+0xa4/0xd0 [hci_vhci] age=9 cpu=2 pid=32040 ... __slab_free+0x204/0x310 vhci_release+0xa4/0xd0 [hci_vhci] ... INFO: Slab 0xffffea0001ac3000 objects=16 used=13 fp=0xffff88006b0c1e00 flags=0x5fffff80004080 INFO: Object 0xffff88006b0c1200 @offset=4608 fp=0xffff88006b0c0600 Bytes b4 ffff88006b0c11f0: 09 df 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006b0c1200: 00 06 0c 6b 00 88 ff ff 00 00 00 00 00 00 00 00 ...k............ Object ffff88006b0c1210: 10 12 0c 6b 00 88 ff ff 10 12 0c 6b 00 88 ff ff ...k.......k.... Object ffff88006b0c1220: c0 46 c2 6b 00 88 ff ff c0 46 c2 6b 00 88 ff ff .F.k.....F.k.... Object ffff88006b0c1230: 01 00 00 00 01 00 00 00 e0 ff ff ff 0f 00 00 00 ................ Object ffff88006b0c1240: 40 12 0c 6b 00 88 ff ff 40 12 0c 6b 00 88 ff ff @..k....@..k.... Object ffff88006b0c1250: 50 0d 6e a0 ff ff ff ff 00 02 00 00 00 00 ad de P.n............. Object ffff88006b0c1260: 00 00 00 00 00 00 00 00 ab 62 02 00 01 00 00 00 .........b...... Object ffff88006b0c1270: 90 b9 19 81 ff ff ff ff 38 12 0c 6b 00 88 ff ff ........8..k.... Object ffff88006b0c1280: 03 00 20 00 ff ff ff ff ff ff ff ff 00 00 00 00 .. ............. Object ffff88006b0c1290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006b0c12a0: 00 00 00 00 00 00 00 00 00 80 cd 3d 00 88 ff ff ...........=.... Object ffff88006b0c12b0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 . .............. Redzone ffff88006b0c12c0: bb bb bb bb bb bb bb bb ........ Padding ffff88006b0c13f8: 00 00 00 00 00 00 00 00 ........ CPU: 3 PID: 32068 Comm: kworker/u13:1 Tainted: G B E 4.4.6-0-default #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014 Workqueue: hci0 hci_cmd_work [bluetooth] 00000000ffffffff ffffffff81926cfa ffff88006be37c68 ffff88006bc27180 ffff88006b0c1200 ffff88006b0c1234 ffffffff81577993 ffffffff82489320 ffff88006bc24240 0000000000000046 ffff88006a100000 000000026e51eb80 Call Trace: ... [<ffffffff81ec8ebe>] ? skb_queue_tail+0x13e/0x150 [<ffffffffa06e027c>] ? vhci_send_frame+0xac/0x100 [hci_vhci] [<ffffffffa0c61268>] ? hci_send_frame+0x188/0x320 [bluetooth] [<ffffffffa0c61515>] ? hci_cmd_work+0x115/0x310 [bluetooth] [<ffffffff811a1375>] ? process_one_work+0x815/0x1340 [<ffffffff811a1f85>] ? worker_thread+0xe5/0x11f0 [<ffffffff811a1ea0>] ? process_one_work+0x1340/0x1340 [<ffffffff811b3c68>] ? kthread+0x1c8/0x230 ... Memory state around the buggy address: ffff88006b0c1100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006b0c1180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88006b0c1200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88006b0c1280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff88006b0c1300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Fixes: 23424c0d31 (Bluetooth: Add support creating virtual AMP controllers) Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 373a32c848ae3a1c03618517cce85f9211a6facf upstream.

Both vhci_get_user and vhci_release race with open_timeout work. They
both contain cancel_delayed_work_sync, but do not test whether the
work actually created hdev or not. Since the work can be in progress
and _sync will wait for finishing it, we can have data->hdev allocated
when cancel_delayed_work_sync returns. But the call sites do 'if
(data->hdev)' *before* cancel_delayed_work_sync.

As a result:
* vhci_get_user allocates a second hdev and puts it into
  data->hdev. The former is leaked.
* vhci_release does not release data->hdev properly as it thinks there
  is none.

Fix both cases by moving the actual test *after* the call to
cancel_delayed_work_sync.

This can be hit by this program:
	#include <err.h>
	#include <fcntl.h>
	#include <stdio.h>
	#include <stdlib.h>
	#include <time.h>
	#include <unistd.h>

	#include <sys/stat.h>
	#include <sys/types.h>

	int main(int argc, char **argv)
	{
		int fd;

		srand(time(NULL));

		while (1) {
			const int delta = (rand() % 200 - 100) * 100;

			fd = open("/dev/vhci", O_RDWR);
			if (fd < 0)
				err(1, "open");

			usleep(1000000 + delta);

			close(fd);
		}

		return 0;
	}

And the result is:
BUG: KASAN: use-after-free in skb_queue_tail+0x13e/0x150 at addr ffff88006b0c1228
Read of size 8 by task kworker/u13:1/32068
=============================================================================
BUG kmalloc-192 (Tainted: G            E     ): kasan: bad access detected
-----------------------------------------------------------------------------

Disabling lock debugging due to kernel taint
INFO: Allocated in vhci_open+0x50/0x330 [hci_vhci] age=260 cpu=3 pid=32040
...
	kmem_cache_alloc_trace+0x150/0x190
	vhci_open+0x50/0x330 [hci_vhci]
	misc_open+0x35b/0x4e0
	chrdev_open+0x23b/0x510
...
INFO: Freed in vhci_release+0xa4/0xd0 [hci_vhci] age=9 cpu=2 pid=32040
...
	__slab_free+0x204/0x310
	vhci_release+0xa4/0xd0 [hci_vhci]
...
INFO: Slab 0xffffea0001ac3000 objects=16 used=13 fp=0xffff88006b0c1e00 flags=0x5fffff80004080
INFO: Object 0xffff88006b0c1200 @offset=4608 fp=0xffff88006b0c0600
Bytes b4 ffff88006b0c11f0: 09 df 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff88006b0c1200: 00 06 0c 6b 00 88 ff ff 00 00 00 00 00 00 00 00  ...k............
Object ffff88006b0c1210: 10 12 0c 6b 00 88 ff ff 10 12 0c 6b 00 88 ff ff  ...k.......k....
Object ffff88006b0c1220: c0 46 c2 6b 00 88 ff ff c0 46 c2 6b 00 88 ff ff  .F.k.....F.k....
Object ffff88006b0c1230: 01 00 00 00 01 00 00 00 e0 ff ff ff 0f 00 00 00  ................
Object ffff88006b0c1240: 40 12 0c 6b 00 88 ff ff 40 12 0c 6b 00 88 ff ff  @..k....@..k....
Object ffff88006b0c1250: 50 0d 6e a0 ff ff ff ff 00 02 00 00 00 00 ad de  P.n.............
Object ffff88006b0c1260: 00 00 00 00 00 00 00 00 ab 62 02 00 01 00 00 00  .........b......
Object ffff88006b0c1270: 90 b9 19 81 ff ff ff ff 38 12 0c 6b 00 88 ff ff  ........8..k....
Object ffff88006b0c1280: 03 00 20 00 ff ff ff ff ff ff ff ff 00 00 00 00  .. .............
Object ffff88006b0c1290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffff88006b0c12a0: 00 00 00 00 00 00 00 00 00 80 cd 3d 00 88 ff ff  ...........=....
Object ffff88006b0c12b0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00  . ..............
Redzone ffff88006b0c12c0: bb bb bb bb bb bb bb bb                          ........
Padding ffff88006b0c13f8: 00 00 00 00 00 00 00 00                          ........
CPU: 3 PID: 32068 Comm: kworker/u13:1 Tainted: G    B       E      4.4.6-0-default #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014
Workqueue: hci0 hci_cmd_work [bluetooth]
 00000000ffffffff ffffffff81926cfa ffff88006be37c68 ffff88006bc27180
 ffff88006b0c1200 ffff88006b0c1234 ffffffff81577993 ffffffff82489320
 ffff88006bc24240 0000000000000046 ffff88006a100000 000000026e51eb80
Call Trace:
...
 [<ffffffff81ec8ebe>] ? skb_queue_tail+0x13e/0x150
 [<ffffffffa06e027c>] ? vhci_send_frame+0xac/0x100 [hci_vhci]
 [<ffffffffa0c61268>] ? hci_send_frame+0x188/0x320 [bluetooth]
 [<ffffffffa0c61515>] ? hci_cmd_work+0x115/0x310 [bluetooth]
 [<ffffffff811a1375>] ? process_one_work+0x815/0x1340
 [<ffffffff811a1f85>] ? worker_thread+0xe5/0x11f0
 [<ffffffff811a1ea0>] ? process_one_work+0x1340/0x1340
 [<ffffffff811b3c68>] ? kthread+0x1c8/0x230
...
Memory state around the buggy address:
 ffff88006b0c1100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff88006b0c1180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88006b0c1200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                  ^
 ffff88006b0c1280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
 ffff88006b0c1300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

Fixes: 23424c0d31 (Bluetooth: Add support creating virtual AMP controllers)
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bluetooth: Add new AR3012 ID 0489:e095 2016-04-12T14:33:36+00:00 Dmitry Tunin hanipouspilot@gmail.com 2016-02-09T21:49:11+00:00 407cecfa130ae083363b1e805df050203d7d95e7 commit 28c971d82fb58ef7cba22e5308be6d2d2590473d upstream. T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e095 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb This device requires ar3k/AthrBT_0x31010100.dfu and ar3k/ramps_0x31010100_40.dfu firmware files that are not in linux-firmware yet. BugLink: https://bugs.launchpad.net/bugs/1542944 Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 28c971d82fb58ef7cba22e5308be6d2d2590473d upstream.

T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e095 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

This device requires ar3k/AthrBT_0x31010100.dfu and
ar3k/ramps_0x31010100_40.dfu firmware files that are not in
linux-firmware yet.

BugLink: https://bugs.launchpad.net/bugs/1542944

Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bluetooth: btusb: Add a new AR3012 ID 13d3:3472 2016-04-12T14:33:24+00:00 Dmitry Tunin hanipouspilot@gmail.com 2016-03-03T22:32:19+00:00 99ed371f70ead62f6f171f6571fcd247371986c7 commit 75c6aca4765dbe3d0c1507ab5052f2e373dc2331 upstream. T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3472 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb BugLink: https://bugs.launchpad.net/bugs/1552925 Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 75c6aca4765dbe3d0c1507ab5052f2e373dc2331 upstream.

T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3472 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

BugLink: https://bugs.launchpad.net/bugs/1552925

Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bluetooth: btusb: Add a new AR3012 ID 04ca:3014 2016-04-12T14:33:24+00:00 Dmitry Tunin hanipouspilot@gmail.com 2016-02-28T08:04:06+00:00 4fea7c5a157018933c8f65a46100d476972de30d commit 81d90442eac779938217c3444b240aa51fd3db47 upstream. T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=03 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3014 Rev=00.02 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb BugLink: https://bugs.launchpad.net/bugs/1546694 Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 81d90442eac779938217c3444b240aa51fd3db47 upstream.

T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=03 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=04ca ProdID=3014 Rev=00.02
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

BugLink: https://bugs.launchpad.net/bugs/1546694

Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bluetooth: btusb: Add new AR3012 ID 13d3:3395 2016-04-12T14:33:24+00:00 Dmitry Tunin hanipouspilot@gmail.com 2016-02-10T12:33:17+00:00 09e8ddc6a250c79db9234a4d3250f1cc926eb8e8 commit 609574eb46335cfac1421a07c0505627cbbab1f0 upstream. T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3395 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb BugLink: https://bugs.launchpad.net/bugs/1542564 Reported-and-tested-by: Christopher Simerly <kilikopela29@gmail.com> Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 609574eb46335cfac1421a07c0505627cbbab1f0 upstream.

T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3395 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

BugLink: https://bugs.launchpad.net/bugs/1542564

Reported-and-tested-by: Christopher Simerly <kilikopela29@gmail.com>
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bluetooth: btmrvl: don't send data to firmware while processing suspend 2016-01-06T15:37:14+00:00 Chin-Ran Lo crlo@marvell.com 2016-01-06T14:34:38+00:00 8cf60cf238ce1bea38593321e6ea8561fc32e38d Usually when driver sends data to firmware it receives TX_DONE (DN_LD_HOST_INT_STATUS) interrupt from firmware right away. It's also observed that some times the fireware could delay sending DN_LD_HOST_INT_STATUS interrupt. If driver sends data to firmware during suspend processing and the TX_DONE interrupt is delayed, it may come back at wrong time when SDIO host driver is in the middle of suspending. Block any data from stack while suspending. Also skip sending data that are already in driver tx_queue. Don't purge the skb queue on suspend to avoid intermittent music after system resumes from S3. Signed-off-by: Chin-Ran Lo <crlo@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
Usually when driver sends data to firmware it receives TX_DONE
(DN_LD_HOST_INT_STATUS) interrupt from firmware right away.
It's also observed that some times the fireware could delay
sending DN_LD_HOST_INT_STATUS interrupt. If driver sends data to
firmware during suspend processing and the TX_DONE interrupt is
delayed, it may come back at wrong time when SDIO host driver is
in the middle of suspending.

Block any data from stack while suspending. Also skip sending
data that are already in driver tx_queue.

Don't purge the skb queue on suspend to avoid intermittent music
after system resumes from S3.

Signed-off-by: Chin-Ran Lo <crlo@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: btmrvl: max out host sleep parameter 'gap' 2016-01-06T15:37:14+00:00 Chin-Ran Lo crlo@marvell.com 2016-01-06T14:34:37+00:00 d716892f0827dd29ae2488ab3005dfc84ff8fed0 For gpio=0xff (wake up host through SDIO interface) case, gap=0xff means no delay (same as gap=0) for incoming data packet to be sent to host after host sleep is activated. Change it to the maximum delay to reduce the chance that RX interrupt could be delivered while host controller suspends. Signed-off-by: Chin-Ran Lo <crlo@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
For gpio=0xff (wake up host through SDIO interface) case,
gap=0xff means no delay (same as gap=0) for incoming data packet
to be sent to host after host sleep is activated.
Change it to the maximum delay to reduce the chance that RX
interrupt could be delivered while host controller suspends.

Signed-off-by: Chin-Ran Lo <crlo@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: btmrvl: fix hung task warning dump 2016-01-04T18:25:56+00:00 Chin-Ran Lo crlo@marvell.com 2015-12-29T12:26:33+00:00 86f7ac77d4035e22ec7e58dcdb96327e2ecc3a9b It's been observed that when bluetooth driver fails to activate the firmware, below hung task warning dump is displayed after 120 seconds. [ 36.461022] Bluetooth: vendor=0x2df, device=0x912e, class=255, fn=2 [ 56.512128] Bluetooth: FW failed to be active in time! [ 56.517264] Bluetooth: Downloading firmware failed! [ 240.252176] INFO: task kworker/3:2:129 blocked for more than 120 seconds. [ 240.258931] Not tainted 3.18.0 #254 [ 240.262972] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.270751] kworker/3:2 D ffffffc000205760 0 129 2 0x00000000 [ 240.277825] Workqueue: events request_firmware_work_func [ 240.283134] Call trace: [ 240.285581] [<ffffffc000205760>] __switch_to+0x80/0x8c [ 240.290693] [<ffffffc00088dae0>] __schedule+0x540/0x7b8 [ 240.295921] [<ffffffc00088ddd0>] schedule+0x78/0x84 [ 240.300764] [<ffffffc0006dfd48>] __mmc_claim_host+0xe8/0x1c8 [ 240.306395] [<ffffffc0006edd6c>] sdio_claim_host+0x74/0x84 [ 240.311840] [<ffffffbffc163d08>] 0xffffffbffc163d08 [ 240.316685] [<ffffffbffc165104>] 0xffffffbffc165104 [ 240.321524] [<ffffffbffc130cf8>] mwifiex_dnld_fw+0x98/0x110 [mwifiex] [ 240.327918] [<ffffffbffc12ee88>] mwifiex_remove_card+0x2c4/0x5fc [mwifiex] [ 240.334741] [<ffffffc000596780>] request_firmware_work_func+0x44/0x80 [ 240.341127] [<ffffffc00023b934>] process_one_work+0x2ec/0x50c [ 240.346831] [<ffffffc00023c6a0>] worker_thread+0x350/0x470 [ 240.352272] [<ffffffc0002419bc>] kthread+0xf0/0xfc [ 240.357019] 2 locks held by kworker/3:2/129: [ 240.361248] #0: ("events"){.+.+.+}, at: [<ffffffc00023b840>] process_one_work+0x1f8/0x50c [ 240.369562] #1: ((&fw_work->work)){+.+.+.}, at: [<ffffffc00023b840>] process_one_work+0x1f8/0x50c [ 240.378589] task PC stack pid father [ 240.384501] kworker/1:1 D ffffffc000205760 0 40 2 0x00000000 [ 240.391524] Workqueue: events mtk_atomic_work [ 240.395884] Call trace: [ 240.398317] [<ffffffc000205760>] __switch_to+0x80/0x8c [ 240.403448] [<ffffffc00027279c>] lock_acquire+0x128/0x164 [ 240.408821] kworker/3:2 D ffffffc000205760 0 129 2 0x00000000 [ 240.415867] Workqueue: events request_firmware_work_func [ 240.421138] Call trace: [ 240.423589] [<ffffffc000205760>] __switch_to+0x80/0x8c [ 240.428688] [<ffffffc00088dae0>] __schedule+0x540/0x7b8 [ 240.433886] [<ffffffc00088ddd0>] schedule+0x78/0x84 [ 240.438732] [<ffffffc0006dfd48>] __mmc_claim_host+0xe8/0x1c8 [ 240.444361] [<ffffffc0006edd6c>] sdio_claim_host+0x74/0x84 [ 240.449801] [<ffffffbffc163d08>] 0xffffffbffc163d08 [ 240.454649] [<ffffffbffc165104>] 0xffffffbffc165104 [ 240.459486] [<ffffffbffc130cf8>] mwifiex_dnld_fw+0x98/0x110 [mwifiex] [ 240.465882] [<ffffffbffc12ee88>] mwifiex_remove_card+0x2c4/0x5fc [mwifiex] [ 240.472705] [<ffffffc000596780>] request_firmware_work_func+0x44/0x80 [ 240.479090] [<ffffffc00023b934>] process_one_work+0x2ec/0x50c [ 240.484794] [<ffffffc00023c6a0>] worker_thread+0x350/0x470 [ 240.490231] [<ffffffc0002419bc>] kthread+0xf0/0xfc This patch adds missing sdio_release_host() call so that wlan driver thread can claim sdio host. Fixes: 4863e4cc31d647e1 ("Bluetooth: btmrvl: release sdio bus after firmware is up") Signed-off-by: Chin-Ran Lo <crlo@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
It's been observed that when bluetooth driver fails to
activate the firmware, below hung task warning dump is
displayed after 120 seconds.

[   36.461022] Bluetooth: vendor=0x2df, device=0x912e, class=255, fn=2
[   56.512128] Bluetooth: FW failed to be active in time!
[   56.517264] Bluetooth: Downloading firmware failed!
[  240.252176] INFO: task kworker/3:2:129 blocked for more than 120 seconds.
[  240.258931]       Not tainted 3.18.0 #254
[  240.262972] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  240.270751] kworker/3:2     D ffffffc000205760     0   129      2 0x00000000
[  240.277825] Workqueue: events request_firmware_work_func
[  240.283134] Call trace:
[  240.285581] [<ffffffc000205760>] __switch_to+0x80/0x8c
[  240.290693] [<ffffffc00088dae0>] __schedule+0x540/0x7b8
[  240.295921] [<ffffffc00088ddd0>] schedule+0x78/0x84
[  240.300764] [<ffffffc0006dfd48>] __mmc_claim_host+0xe8/0x1c8
[  240.306395] [<ffffffc0006edd6c>] sdio_claim_host+0x74/0x84
[  240.311840] [<ffffffbffc163d08>] 0xffffffbffc163d08
[  240.316685] [<ffffffbffc165104>] 0xffffffbffc165104
[  240.321524] [<ffffffbffc130cf8>] mwifiex_dnld_fw+0x98/0x110 [mwifiex]
[  240.327918] [<ffffffbffc12ee88>] mwifiex_remove_card+0x2c4/0x5fc [mwifiex]
[  240.334741] [<ffffffc000596780>] request_firmware_work_func+0x44/0x80
[  240.341127] [<ffffffc00023b934>] process_one_work+0x2ec/0x50c
[  240.346831] [<ffffffc00023c6a0>] worker_thread+0x350/0x470
[  240.352272] [<ffffffc0002419bc>] kthread+0xf0/0xfc
[  240.357019] 2 locks held by kworker/3:2/129:
[  240.361248]  #0:  ("events"){.+.+.+}, at: [<ffffffc00023b840>] process_one_work+0x1f8/0x50c
[  240.369562]  #1:  ((&fw_work->work)){+.+.+.}, at: [<ffffffc00023b840>] process_one_work+0x1f8/0x50c
[  240.378589]   task                        PC stack   pid father
[  240.384501] kworker/1:1     D ffffffc000205760     0    40      2 0x00000000
[  240.391524] Workqueue: events mtk_atomic_work
[  240.395884] Call trace:
[  240.398317] [<ffffffc000205760>] __switch_to+0x80/0x8c
[  240.403448] [<ffffffc00027279c>] lock_acquire+0x128/0x164
[  240.408821] kworker/3:2     D ffffffc000205760     0   129      2 0x00000000
[  240.415867] Workqueue: events request_firmware_work_func
[  240.421138] Call trace:
[  240.423589] [<ffffffc000205760>] __switch_to+0x80/0x8c
[  240.428688] [<ffffffc00088dae0>] __schedule+0x540/0x7b8
[  240.433886] [<ffffffc00088ddd0>] schedule+0x78/0x84
[  240.438732] [<ffffffc0006dfd48>] __mmc_claim_host+0xe8/0x1c8
[  240.444361] [<ffffffc0006edd6c>] sdio_claim_host+0x74/0x84
[  240.449801] [<ffffffbffc163d08>] 0xffffffbffc163d08
[  240.454649] [<ffffffbffc165104>] 0xffffffbffc165104
[  240.459486] [<ffffffbffc130cf8>] mwifiex_dnld_fw+0x98/0x110 [mwifiex]
[  240.465882] [<ffffffbffc12ee88>] mwifiex_remove_card+0x2c4/0x5fc [mwifiex]
[  240.472705] [<ffffffc000596780>] request_firmware_work_func+0x44/0x80
[  240.479090] [<ffffffc00023b934>] process_one_work+0x2ec/0x50c
[  240.484794] [<ffffffc00023c6a0>] worker_thread+0x350/0x470
[  240.490231] [<ffffffc0002419bc>] kthread+0xf0/0xfc

This patch adds missing sdio_release_host() call so that wlan driver
thread can claim sdio host.

Fixes: 4863e4cc31d647e1 ("Bluetooth: btmrvl: release sdio bus after firmware is up")
Signed-off-by: Chin-Ran Lo <crlo@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>