This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git. Pull mirroring updated .
  1. 26 Jun, 2021 2 commits
    • Kai-Heng Feng's avatar
      Bluetooth: Shutdown controller after workqueues are flushed or cancelled · 0ea9fd00
      Kai-Heng Feng authored
      
      
      Rfkill block and unblock Intel USB Bluetooth [8087:0026] may make it
      stops working:
      [  509.691509] Bluetooth: hci0: HCI reset during shutdown failed
      [  514.897584] Bluetooth: hci0: MSFT filter_enable is already on
      [  530.044751] usb 3-10: reset full-speed USB device number 5 using xhci_hcd
      [  545.660350] usb 3-10: device descriptor read/64, error -110
      [  561.283530] usb 3-10: device descriptor read/64, error -110
      [  561.519682] usb 3-10: reset full-speed USB device number 5 using xhci_hcd
      [  566.686650] Bluetooth: hci0: unexpected event for opcode 0x0500
      [  568.752452] Bluetooth: hci0: urb 0000000096cd309b failed to resubmit (113)
      [  578.797955] Bluetooth: hci0: Failed to read MSFT supported features (-110)
      [  586.286565] Bluetooth: hci0: urb 00000000c522f633 failed to resubmit (113)
      [  596.215302] Bluetooth: hci0: Failed to read MSFT supported features (-110)
      
      Or kernel panics because other workqueues already freed skb:
      [ 2048.663763] BUG: kernel NULL pointer dereference, address: 0000000000000000
      [ 2048.663775] #PF: supervisor read access in kernel mode
      [ 2048.663779] #PF: error_code(0x0000) - not-present page
      [ 2048.663782] PGD 0 P4D 0
      [ 2048.663787] Oops: 0000 [#1] SMP NOPTI
      [ 2048.663793] CPU: 3 PID: 4491 Comm: rfkill Tainted: G        W         5.13.0-rc1-next-20210510+ #20
      [ 2048.663799] Hardware name: HP HP EliteBook 850 G8 Notebook PC/8846, BIOS T76 Ver. 01.01.04 12/02/2020
      [ 2048.663801] RIP: 0010:__skb_ext_put+0x6/0x50
      [ 2048.663814] Code: 8b 1b 48 85 db 75 db 5b 41 5c 5d c3 be 01 00 00 00 e8 de 13 c0 ff eb e7 be 02 00 00 00 e8 d2 13 c0 ff eb db 0f 1f 44 00 00 55 <8b> 07 48 89 e5 83 f8 01 74 14 b8 ff ff ff ff f0 0f c1
      07 83 f8 01
      [ 2048.663819] RSP: 0018:ffffc1d105b6fd80 EFLAGS: 00010286
      [ 2048.663824] RAX: 0000000000000000 RBX: ffff9d9ac5649000 RCX: 0000000000000000
      [ 2048.663827] RDX: ffffffffc0d1daf6 RSI: 0000000000000206 RDI: 0000000000000000
      [ 2048.663830] RBP: ffffc1d105b6fd98 R08: 0000000000000001 R09: ffff9d9ace8ceac0
      [ 2048.663834] R10: ffff9d9ace8ceac0 R11: 0000000000000001 R12: ffff9d9ac5649000
      [ 2048.663838] R13: 0000000000000000 R14: 00007ffe0354d650 R15: 0000000000000000
      [ 2048.663843] FS:  00007fe02ab19740(0000) GS:ffff9d9e5f8c0000(0000) knlGS:0000000000000000
      [ 2048.663849] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 2048.663853] CR2: 0000000000000000 CR3: 0000000111a52004 CR4: 0000000000770ee0
      [ 2048.663856] PKRU: 55555554
      [ 2048.663859] Call Trace:
      [ 2048.663865]  ? skb_release_head_state+0x5e/0x80
      [ 2048.663873]  kfree_skb+0x2f/0xb0
      [ 2048.663881]  btusb_shutdown_intel_new+0x36/0x60 [btusb]
      [ 2048.663905]  hci_dev_do_close+0x48c/0x5e0 [bluetooth]
      [ 2048.663954]  ? __cond_resched+0x1a/0x50
      [ 2048.663962]  hci_rfkill_set_block+0x56/0xa0 [bluetooth]
      [ 2048.664007]  rfkill_set_block+0x98/0x170
      [ 2048.664016]  rfkill_fop_write+0x136/0x1e0
      [ 2048.664022]  vfs_write+0xc7/0x260
      [ 2048.664030]  ksys_write+0xb1/0xe0
      [ 2048.664035]  ? exit_to_user_mode_prepare+0x37/0x1c0
      [ 2048.664042]  __x64_sys_write+0x1a/0x20
      [ 2048.664048]  do_syscall_64+0x40/0xb0
      [ 2048.664055]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      [ 2048.664060] RIP: 0033:0x7fe02ac23c27
      [ 2048.664066] Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
      [ 2048.664070] RSP: 002b:00007ffe0354d638 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      [ 2048.664075] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fe02ac23c27
      [ 2048.664078] RDX: 0000000000000008 RSI: 00007ffe0354d650 RDI: 0000000000000003
      [ 2048.664081] RBP: 0000000000000000 R08: 0000559b05998440 R09: 0000559b05998440
      [ 2048.664084] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003
      [ 2048.664086] R13: 0000000000000000 R14: ffffffff00000000 R15: 00000000ffffffff
      
      So move the shutdown callback to a place where workqueues are either
      flushed or cancelled to resolve the issue.
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      0ea9fd00
    • Manish Mandlik's avatar
      Bluetooth: Add ncmd=0 recovery handling · de75cd0d
      Manish Mandlik authored
      
      
      During command status or command complete event, the controller may set
      ncmd=0 indicating that it is not accepting any more commands. In such a
      case, host holds off sending any more commands to the controller. If the
      controller doesn't recover from such condition, host will wait forever,
      until the user decides that the Bluetooth is broken and may power cycles
      the Bluetooth.
      
      This patch triggers the hardware error to reset the controller and
      driver when it gets into such state as there is no other wat out.
      Reviewed-by: default avatarAbhishek Pandit-Subedi <abhishekpandit@chromium.org>
      Signed-off-by: default avatarManish Mandlik <mmandlik@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      de75cd0d
  2. 02 Jun, 2021 1 commit
  3. 27 May, 2021 1 commit
    • Lin Ma's avatar
      Bluetooth: fix the erroneous flush_work() order · 6a137cae
      Lin Ma authored
      
      
      In the cleanup routine for failed initialization of HCI device,
      the flush_work(&hdev->rx_work) need to be finished before the
      flush_work(&hdev->cmd_work). Otherwise, the hci_rx_work() can
      possibly invoke new cmd_work and cause a bug, like double free,
      in late processings.
      
      This was assigned CVE-2021-3564.
      
      This patch reorder the flush_work() to fix this bug.
      
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Johan Hedberg <johan.hedberg@gmail.com>
      Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: linux-bluetooth@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarLin Ma <linma@zju.edu.cn>
      Signed-off-by: default avatarHao Xiong <mart1n@zju.edu.cn>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      6a137cae
  4. 08 Apr, 2021 1 commit
  5. 06 Apr, 2021 1 commit
  6. 29 Jan, 2021 1 commit
    • Hans de Goede's avatar
      Bluetooth: Add new HCI_QUIRK_NO_SUSPEND_NOTIFIER quirk · 219991e6
      Hans de Goede authored
      
      
      Some devices, e.g. the RTL8723BS bluetooth part, some USB attached devices,
      completely drop from the bus on a system-suspend. These devices will
      have their driver unbound and rebound on resume (when the dropping of
      the bus gets detected) and will show up as a new HCI after resume.
      
      These devices do not benefit from the suspend / resume handling work done
      by the hci_suspend_notifier. At best this unnecessarily adds some time to
      the suspend/resume time. But this may also actually cause problems, if the
      code doing the driver unbinding runs after the pm-notifier then the
      hci_suspend_notifier code will try to talk to a device which is now in
      an uninitialized state.
      
      This commit adds a new HCI_QUIRK_NO_SUSPEND_NOTIFIER quirk which allows
      drivers to opt-out of the hci_suspend_notifier when they know beforehand
      that their device will be fully re-initialized / reprobed on resume.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarAbhishek Pandit-Subedi <abhishekpandit@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      219991e6
  7. 25 Jan, 2021 4 commits
    • Vamshi K Sthambamkadi's avatar
      Bluetooth: btusb: fix memory leak on suspend and resume · 5ff20cbe
      Vamshi K Sthambamkadi authored
      
      
      kmemleak report:
      unreferenced object 0xffff9b1127f00500 (size 208):
        comm "kworker/u17:2", pid 500, jiffies 4294937470 (age 580.136s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 60 ed 05 11 9b ff ff 00 00 00 00 00 00 00 00  .`..............
        backtrace:
          [<000000006ab3fd59>] kmem_cache_alloc_node+0x17a/0x480
          [<0000000051a5f6f9>] __alloc_skb+0x5b/0x1d0
          [<0000000037e2d252>] hci_prepare_cmd+0x32/0xc0 [bluetooth]
          [<0000000010b586d5>] hci_req_add_ev+0x84/0xe0 [bluetooth]
          [<00000000d2deb520>] hci_req_clear_event_filter+0x42/0x70 [bluetooth]
          [<00000000f864bd8c>] hci_req_prepare_suspend+0x84/0x470 [bluetooth]
          [<000000001deb2cc4>] hci_prepare_suspend+0x31/0x40 [bluetooth]
          [<000000002677dd79>] process_one_work+0x209/0x3b0
          [<00000000aaa62b07>] worker_thread+0x34/0x400
          [<00000000826d176c>] kthread+0x126/0x140
          [<000000002305e558>] ret_from_fork+0x22/0x30
      unreferenced object 0xffff9b1125c6ee00 (size 512):
        comm "kworker/u17:2", pid 500, jiffies 4294937470 (age 580.136s)
        hex dump (first 32 bytes):
          04 00 00 00 0d 00 00 00 05 0c 01 00 11 9b ff ff  ................
          00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
        backtrace:
          [<000000009f07c0cc>] slab_post_alloc_hook+0x59/0x270
          [<0000000049431dc2>] __kmalloc_node_track_caller+0x15f/0x330
          [<00000000027a42f6>] __kmalloc_reserve.isra.70+0x31/0x90
          [<00000000e8e3e76a>] __alloc_skb+0x87/0x1d0
          [<0000000037e2d252>] hci_prepare_cmd+0x32/0xc0 [bluetooth]
          [<0000000010b586d5>] hci_req_add_ev+0x84/0xe0 [bluetooth]
          [<00000000d2deb520>] hci_req_clear_event_filter+0x42/0x70 [bluetooth]
          [<00000000f864bd8c>] hci_req_prepare_suspend+0x84/0x470 [bluetooth]
          [<000000001deb2cc4>] hci_prepare_suspend+0x31/0x40 [bluetooth]
          [<000000002677dd79>] process_one_work+0x209/0x3b0
          [<00000000aaa62b07>] worker_thread+0x34/0x400
          [<00000000826d176c>] kthread+0x126/0x140
          [<000000002305e558>] ret_from_fork+0x22/0x30
      unreferenced object 0xffff9b112b395788 (size 8):
        comm "kworker/u17:2", pid 500, jiffies 4294937470 (age 580.136s)
        hex dump (first 8 bytes):
          20 00 00 00 00 00 04 00                           .......
        backtrace:
          [<0000000052dc28d2>] kmem_cache_alloc_trace+0x15e/0x460
          [<0000000046147591>] alloc_ctrl_urb+0x52/0xe0 [btusb]
          [<00000000a2ed3e9e>] btusb_send_frame+0x91/0x100 [btusb]
          [<000000001e66030e>] hci_send_frame+0x7e/0xf0 [bluetooth]
          [<00000000bf6b7269>] hci_cmd_work+0xc5/0x130 [bluetooth]
          [<000000002677dd79>] process_one_work+0x209/0x3b0
          [<00000000aaa62b07>] worker_thread+0x34/0x400
          [<00000000826d176c>] kthread+0x126/0x140
          [<000000002305e558>] ret_from_fork+0x22/0x30
      
      In pm sleep-resume context, while the btusb device rebinds, it enters
      hci_unregister_dev(), whilst there is a possibility of hdev receiving
      PM_POST_SUSPEND suspend_notifier event, leading to generation of msg
      frames. When hci_unregister_dev() completes, i.e. hdev context is
      destroyed/freed, those intermittently sent msg frames cause memory
      leak.
      
      BUG details:
      Below is stack trace of thread that enters hci_unregister_dev(), marks
      the hdev flag HCI_UNREGISTER to 1, and then goes onto to wait on notifier
      lock - refer unregister_pm_notifier().
      
        hci_unregister_dev+0xa5/0x320 [bluetoot]
        btusb_disconnect+0x68/0x150 [btusb]
        usb_unbind_interface+0x77/0x250
        ? kernfs_remove_by_name_ns+0x75/0xa0
        device_release_driver_internal+0xfe/0x1
        device_release_driver+0x12/0x20
        bus_remove_device+0xe1/0x150
        device_del+0x192/0x3e0
        ? usb_remove_ep_devs+0x1f/0x30
        usb_disable_device+0x92/0x1b0
        usb_disconnect+0xc2/0x270
        hub_event+0x9f6/0x15d0
        ? rpm_idle+0x23/0x360
        ? rpm_idle+0x26b/0x360
        process_one_work+0x209/0x3b0
        worker_thread+0x34/0x400
        ? process_one_work+0x3b0/0x3b0
        kthread+0x126/0x140
        ? kthread_park+0x90/0x90
        ret_from_fork+0x22/0x30
      
      Below is stack trace of thread executing hci_suspend_notifier() which
      processes the PM_POST_SUSPEND event, while the unbinding thread is
      waiting on lock.
      
        hci_suspend_notifier.cold.39+0x5/0x2b [bluetooth]
        blocking_notifier_call_chain+0x69/0x90
        pm_notifier_call_chain+0x1a/0x20
        pm_suspend.cold.9+0x334/0x352
        state_store+0x84/0xf0
        kobj_attr_store+0x12/0x20
        sysfs_kf_write+0x3b/0x40
        kernfs_fop_write+0xda/0x1c0
        vfs_write+0xbb/0x250
        ksys_write+0x61/0xe0
        __x64_sys_write+0x1a/0x20
        do_syscall_64+0x37/0x80
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fix hci_suspend_notifer(), not to act on events when flag HCI_UNREGISTER
      is set.
      Signed-off-by: default avatarVamshi K Sthambamkadi <vamshi.k.sthambamkadi@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      5ff20cbe
    • Pan Bian's avatar
      Bluetooth: Put HCI device if inquiry procedure interrupts · 28a758c8
      Pan Bian authored
      Jump to the label done to decrement the reference count of HCI device
      hdev on path that the Inquiry procedure is interrupted.
      
      Fixes: 3e13fa1e
      
       ("Bluetooth: Fix hci_inquiry ioctl usage")
      Signed-off-by: default avatarPan Bian <bianpan2016@163.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      28a758c8
    • Archie Pusaka's avatar
      Bluetooth: advmon offload MSFT remove monitor · 66bd095a
      Archie Pusaka authored
      
      
      Implements the monitor removal functionality for advertising monitor
      offloading to MSFT controllers. Supply handle = 0 to remove all
      monitors.
      Signed-off-by: default avatarArchie Pusaka <apusaka@chromium.org>
      Reviewed-by: default avatarMiao-chen Chou <mcchou@chromium.org>
      Reviewed-by: default avatarYun-Hao Chung <howardchung@google.com>
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      66bd095a
    • Archie Pusaka's avatar
      Bluetooth: advmon offload MSFT add monitor · a2a4dedf
      Archie Pusaka authored
      
      
      Enables advertising monitor offloading to the controller, if MSFT
      extension is supported. The kernel won't adjust the monitor parameters
      to match what the controller supports - that is the user space's
      responsibility.
      
      This patch only manages the addition of monitors. Monitor removal is
      going to be handled by another patch.
      Signed-off-by: default avatarArchie Pusaka <apusaka@chromium.org>
      Reviewed-by: default avatarManish Mandlik <mmandlik@chromium.org>
      Reviewed-by: default avatarMiao-chen Chou <mcchou@chromium.org>
      Reviewed-by: default avatarYun-Hao Chung <howardchung@google.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a2a4dedf
  8. 07 Dec, 2020 6 commits
  9. 20 Sep, 2020 1 commit
  10. 18 Sep, 2020 1 commit
  11. 13 Sep, 2020 1 commit
    • Abhishek Pandit-Subedi's avatar
      Bluetooth: Emit controller suspend and resume events · 2f20216c
      Abhishek Pandit-Subedi authored
      
      
      Emit controller suspend and resume events when we are ready for suspend
      and we've resumed from suspend.
      
      The controller suspend event will report whatever suspend state was
      successfully entered. The controller resume event will check the first
      HCI event that was received after we finished preparing for suspend and,
      if it was a connection event, store the address of the peer that caused
      the event. If it was not a connection event, we mark the wake reason as
      an unexpected event.
      
      Here is a sample btmon trace with these events:
      
      @ MGMT Event: Controller Suspended (0x002d) plen 1
              Suspend state: Page scanning and/or passive scanning (2)
      
      @ MGMT Event: Controller Resumed (0x002e) plen 8
              Wake reason: Remote wake due to peer device connection (2)
              LE Address: CD:F3:CD:13:C5:9A (OUI CD-F3-CD)
      Signed-off-by: default avatarAbhishek Pandit-Subedi <abhishekpandit@chromium.org>
      Reviewed-by: default avatarMiao-chen Chou <mcchou@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      2f20216c
  12. 11 Sep, 2020 2 commits
  13. 01 Sep, 2020 1 commit
  14. 30 Jul, 2020 2 commits
  15. 28 Jul, 2020 3 commits
    • Abhishek Pandit-Subedi's avatar
      Bluetooth: Fix suspend notifier race · 4e8c36c3
      Abhishek Pandit-Subedi authored
      Unregister from suspend notifications and cancel suspend preparations
      before running hci_dev_do_close. Otherwise, the suspend notifier may
      race with unregister and cause cmd_timeout even after hdev has been
      freed.
      
      Below is the trace from when this panic was seen:
      
      [  832.578518] Bluetooth: hci_core.c:hci_cmd_timeout() hci0: command 0x0c05 tx timeout
      [  832.586200] BUG: kernel NULL pointer dereference, address: 0000000000000000
      [  832.586203] #PF: supervisor read access in kernel mode
      [  832.586205] #PF: error_code(0x0000) - not-present page
      [  832.586206] PGD 0 P4D 0
      [  832.586210] PM: suspend exit
      [  832.608870] Oops: 0000 [#1] PREEMPT SMP NOPTI
      [  832.613232] CPU: 3 PID: 10755 Comm: kworker/3:7 Not tainted 5.4.44-04894-g1e9dbb96a161 #1
      [  832.630036] Workqueue: events hci_cmd_timeout [bluetooth]
      [  832.630046] RIP: 0010:__queue_work+0xf0/0x374
      [  832.630051] RSP: 0018:ffff9b5285f1fdf8 EFLAGS: 00010046
      [  832.674033] RAX: ffff8a97681bac00 RBX: 0000000000000000 RCX: ffff8a976a000600
      [  832.681162] RDX: 0000000000000000 RSI: 0000000000000009 RDI: ffff8a976a000748
      [  832.688289] RBP: ffff9b5285f1fe38 R08: 0000000000000000 R09: ffff8a97681bac00
      [  832.695418] R10: 0000000000000002 R11: ffff8a976a0006d8 R12: ffff8a9745107600
      [  832.698045] usb 1-6: new full-speed USB device number 119 using xhci_hcd
      [  832.702547] R13: ffff8a9673658850 R14: 0000000000000040 R15: 000000000000001e
      [  832.702549] FS:  0000000000000000(0000) GS:ffff8a976af80000(0000) knlGS:0000000000000000
      [  832.702550] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  832.702550] CR2: 0000000000000000 CR3: 000000010415a000 CR4: 00000000003406e0
      [  832.702551] Call Trace:
      [  832.702558]  queue_work_on+0x3f/0x68
      [  832.702562]  process_one_work+0x1db/0x396
      [  832.747397]  worker_thread+0x216/0x375
      [  832.751147]  kthread+0x138/0x140
      [  832.754377]  ? pr_cont_work+0x58/0x58
      [  832.758037]  ? kthread_blkcg+0x2e/0x2e
      [  832.761787]  ret_from_fork+0x22/0x40
      [  832.846191] ---[ end trace fa93f466da517212 ]---
      
      Fixes: 9952d90e
      
       ("Bluetooth: Handle PM_SUSPEND_PREPARE and PM_POST_SUSPEND")
      Signed-off-by: default avatarAbhishek Pandit-Subedi <abhishekpandit@chromium.org>
      Reviewed-by: default avatarMiao-chen Chou <mcchou@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      4e8c36c3
    • Max Chou's avatar
      Bluetooth: Return NOTIFY_DONE for hci_suspend_notifier · 24b06572
      Max Chou authored
      
      
      The original return is NOTIFY_STOP, but notifier_call_chain would stop
      the future call for register_pm_notifier even registered on other Kernel
      modules with the same priority which value is zero.
      Signed-off-by: default avatarMax Chou <max.chou@realtek.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      24b06572
    • Ismael Ferreras Morezuelas's avatar
      Bluetooth: btusb: Fix and detect most of the Chinese Bluetooth controllers · cde1a8a9
      Ismael Ferreras Morezuelas authored
      For some reason they tend to squat on the very first CSR/
      Cambridge Silicon Radio VID/PID instead of paying fees.
      
      This is an extremely common problem; the issue goes as back as 2013
      and these devices are only getting more popular, even rebranded by
      reputable vendors and sold by retailers everywhere.
      
      So, at this point in time there are hundreds of modern dongles reusing
      the ID of what originally was an early Bluetooth 1.1 controller.
      
      Linux is the only place where they don't work due to spotty checks
      in our detection code. It only covered a minimum subset.
      
      So what's the big idea? Take advantage of the fact that all CSR
      chips report the same internal version as both the LMP sub-version and
      HCI revision number. It always matches, couple that with the manufacturer
      code, that rarely lies, and we now have a good idea of who is who.
      
      Additionally, by compiling a list of user-reported HCI/lsusb dumps, and
      searching around for legit CSR dongles in similar product ranges we can
      find what CSR BlueCore firmware supported which Bluetooth versions.
      
      That way we can narrow down ranges of fakes for each of them.
      
      e.g. Real CSR dongles with LMP subversion 0x73 are old enough that
           support BT 1.1 only; so it's a dead giveaway when some
           third-party BT 4.0 dongle reuses it.
      
      So, to sum things up; there are multiple classes of fake controllers
      reusing the same 0A12:0001 VID/PID. This has been broken for a while.
      
      Known 'fake' bcdDevices: 0x0100, 0x0134, 0x1915, 0x2520, 0x7558, 0x8891
        IC markings on 0x7558: FR3191AHAL 749H15143 (???)
      
      https://bugzilla.kernel.org/show_bug.cgi?id=60824
      
      Fixes: 81cac64b
      
       (Deal with USB devices that are faking CSR vendor)
      Reported-by: default avatarMichał Wiśniewski <brylozketrzyn@gmail.com>
      Tested-by: default avatarMike Johnson <yuyuyak@gmail.com>
      Tested-by: default avatarRicardo Rodrigues <ekatonb@gmail.com>
      Tested-by: default avatarM.Hanny Sabbagh <mhsabbagh@outlook.com>
      Tested-by: default avatarOussama BEN BRAHIM <b.brahim.oussama@gmail.com>
      Tested-by: default avatarIsmael Ferreras Morezuelas <swyterzone@gmail.com>
      Signed-off-by: default avatarIsmael Ferreras Morezuelas <swyterzone@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      cde1a8a9
  16. 07 Jul, 2020 2 commits
  17. 18 Jun, 2020 6 commits
  18. 12 Jun, 2020 2 commits
  19. 08 Jun, 2020 1 commit
  20. 13 May, 2020 1 commit